精华内容
下载资源
问答
  • 转载:...我以淘宝技术架构演进为例,淘宝从一个大系统工程向分布式架构演变过程,你就能很清楚的知道为什么要需要进行应用拆分。 1 人员的角度。 维护一个代名工程Denali...

    转载:http://youzhixueyuan.com/the-principles-and-steps-of-distributed-architecture-system-resolution.html

    为什么需要应用拆分

    我以淘宝技术架构演进为例,淘宝从一个大系统工程向分布式架构演变过程,你就能很清楚的知道为什么要需要进行应用拆分。

    阿里P8架构师谈:分布式架构系统拆分原则、需求、微服务拆分步骤

    1 人员的角度。

    维护一个代名工程Denali的百万级代码怪兽(虽然物理部署是分离的),从发布到上线,从人员的角度,百号人同时在一个工程上开发,一旦线上出问题,所有代码都需要回滚,从人员的角度,也基本忍受到了极致。

    2 业务的角度

    淘宝包含太多业务:用户、商品、交易、支付…等等,所有的代码早期都在denali一个工程里,代码已经严重影响到业务的效率,每个业务有各自的需求,需要给自己应用部署,各自开发需求。

    3 从架构的角度

    从数据库端oracle数据库集中式架构的瓶颈问题,连接池数量限制(oracle数据库大约提供5000个连接),数据库的CPU已经到达了极限90%。数据库端也需要考虑垂直拆分了。

    4.急需走向一个大型的分布式时代,率先需要应用拆分。

    1 )首先工程代码垂直拆分

    把整个工程代码按照业务为单元进行垂直拆分。

    淘宝按照业务为单位拆分成了类似这样的系统:UM(UserManger)、SM(ShopManager)..等等几十个工程代码。

    2 )应用服务拆分

    按照业务为单位,把所有调用相关的接口以业务为单元进行拆分。

    比如,一个店铺系统,需要访问一个用户的头像的接口,用户头像的接口是独立部署在用户中心(UIC)这边的集群服务器上的。随着拆分的进行,淘宝的业务接口中心就变成了:UIC(用户中心服务)、SIC(店铺中心服务)等等以业务为单元部署的集群。

    最终就演变成下图,按照业务为单位拆分和部署服务,用户中心、商品中心等:

    阿里P8架构师谈:分布式架构系统拆分原则、需求、微服务拆分步骤

    总之,系统拆分是单体程序向分布式系统演变的关键一步,也是很重要的一步,拆分的好坏直接关系到未来系统的扩展性、可维护性和可伸缩性等,拆分工作不难理解,但是如何正确拆分、有什么样的方法和原则能帮助我们拆分得到一个我们理想中的系统:高可用、可扩展、可维护、可伸缩的分布式系统。

    以下主要再从拆分需求、拆分原则和拆分步骤谈起:

    拆分需求

    1、组织结构变化:从最初的一个团队逐渐成长并拆分为几个团队,团队按照业务线不同进行划分,为了减少各个业务系统和代码间的关联和耦合,几个团队不再可能共同向一个代码库中提交代码,必须对原有系统进行拆分,以减少团队间的干扰。

    2、安全:这里所指的安全不是系统级别的安全,而是指代码或成果的安全,尤其是对于很多具有核心算法的系统,为了代码不被泄露,需要对相关系统进行模块化拆分,隔离核心功能,保护知识产权。

    3、替换性:有些产品为了提供差异化的服务,需要产品具有可定制功能,根据用户的选择自由组合为一个完整的系统,比如一些模块,免费用户使用的功能与收费用户使用的功能肯定是不一样的,这就需要这些模块具有替换性,判断是免费用户还是收费用户使用不同的模块组装,这也需要对系统进行模块化拆分。

    4、交付速度:单体程序最大的问题在于系统错综复杂,牵一发而动全身,也许一个小的改动就造成很多功能没办法正常工作,极大的降低了软件的交付速度,因为每次改动都需要大量的回归测试确保每个模块都能正确工作,因为我们不清楚改动会影响到什么,所以需要做大量重复工作,增加了测试成本。这时候就需要对系统进行拆分,理清各个功能间的关系并解耦。

    5、技术需求:

    1)单体程序由于技术栈固定,尤其的是比较庞大的系统,不能很方便的进行技术升级,或者说对引入新技术或框架等处于封闭状态;每种语言都有自己的特点,单体程序没有办法享受到其它语言带来的便利;对应到团队中,团队技术相对比较单一。

    2)相比于基于业务的垂直拆分,基于技术的横向拆分也很重要,使用数据访问层可以很好的隐藏对数据库的直接访问、减少数据库连接数、增加数据使用效率等;横向拆分可以极大的提高各个层级模块的重用性。

    6、业务需求:由于业务上的某些特殊要求,比如对某个功能或模块的高可用性、高性能、可伸缩性等的要求,虽然也可以将单体整体部署到分布式环境中实现高可用、高性能等,但是从系统维护的角度来考虑,每次改动都要重新部署所有节点,显然会增加很多潜在的风险和不确定定性因素,所以有时候不得不选择将那些有特殊要求的功能从系统中抽取出来,独立部署和扩展。

    如何拆分

    1.拆分原则

    • 单一职责
    • 服务粒度适中
    • 考虑团队结构
    • 以业务模型切入
    • 演进式拆分
    • 避免环形依赖和双向依赖

    2.分布式应用拆分实战

    下面是拆分代码过程实践经验:

    1). 设计module骨架

    module骨架的设计是基础,影响最终拆分结果,拆分成功的向导。按照技术,业务,部署打包,测试这几个维度来规划设计,下面是一个参考。

    最终骨架模型层级:

    root web app

    webapp //war module,打包为单体war,整体部署

    micro-services //微服务pom module

    user-service

    customer-service

    order-service

    other-service

    api-gateway

    biz //业务相关的module

    entitys //所有实体类

    biz-base //一些无法拆分的代码上有依赖的服务

    biz-user //用户业务

    biz-customer //客户业务

    biz-order //订单业务

    commons

    async-framework //一部框架

    utils //工具类

    2). 拆分技术commons

    作为第一步,先对整个工程按业务和功能进行了maven多module的拆分。

    首先是分离出技术上的commons,感觉这应该是最好拆分的了,把相关的类重构到一个包里,在分离出一个module即可。

    3). 拆分entity

    很多在业务代码上都会共享entity类,通常没法也没法把entity类分门别类,最简单就是把所有的entity类放到一个module,谁需要谁依赖的原则。entity类也没有太多jar依赖和业务依赖,也不会形成污染源。

    4)公共业务

    同commons和entity方法,不在复述,也被各个业务依赖,这种业务大部分是过渡性的,在未来迭代演进时可以通过其他方式抽象集成。

    5)拆分业务代码

    拆分业务是最痛苦的事情了,这个要看原来的代码整洁度和互相依赖程度,一般采取2中方法:

    • 新建业务module,加入基础module的pom依赖,再从源module复制和该业务module相关的代码(包括单元测试代码)过来,解决编译错误和单元测试错误,完成本业务拆分。
    • 从源module复制一个新业务module,保持代码一致,先删除和本义务无关的代码(包括单元测试代码),再删除无关的pom依赖,解决编译错误和单元测试错误,完成本业务拆分。

    选择哪种方法,可以根据代码整洁度和互相依赖程度,如果代码很整洁且相互依赖较弱,可以采取前者,否则就采取后者。

    6)拆分微服务

    有了以上的拆分基础,可以在合适的业务迭代将各个微服务module迁移到不同的代码仓库,完成进一步隔离管理。

    微服务架构框架

    阿里P8架构师谈:分布式架构系统拆分原则、需求、微服务拆分步骤

    业界开源微服务架构框架提供了微服务的关键思路,例如 Dubbo 和 Spring Cloud(请关注后续文章,我会详解区别和优劣势)

    阿里P8架构师谈:分布式架构系统拆分原则、需求、微服务拆分步骤

    Dubbo是Alibaba开源的分布式服务框架,它最大的特点是按照分层的方式来架构,使用这种方式可以使各个层之间解耦合(或者最大限度地松耦合)。

    Spring Cloud是一个微服务框架,相比Dubbo等RPC框架, Spring Cloud提供的全套的分布式系统解决方案。

    阿里P8架构师谈:分布式架构系统拆分原则、需求、微服务拆分步骤

    微服务架构是互联网技术发展的必然结果,它提倡将单一应用程序划分成一组小的服务,服务之间互相协调、互相配合,为用户提供最终价值。

    分布式架构之应用拆分总结:

    1.明确拆分原则和拆分需求。

    2.梳理出业务模块和之间的依赖关联关系。

    3.按照业务为单位,拆分实体、以及应用工程单独部署。

    4.按照业务为单位拆分应用服务,避免环形依赖和双向依赖。

    5.抽离出公用的接口、实体,以及服务单独部署为公用服务。

    展开全文
  • 分布式架构率先开始的就是应用工程拆分,如何拆分,什么情况拆分拆分原则是什么,能否实战详解拆分步骤?让我一一娓娓道来。 为什么需要应用拆分 我以淘宝技术架构演进为例,淘宝从一个大系统工程向分布式架构...

    分布式架构率先开始的就是应用工程拆分,如何拆分,什么情况拆分,拆分的原则是什么,能否实战详解拆分步骤?让我一一娓娓道来。

    为什么需要应用拆分

    我以淘宝技术架构演进为例,淘宝从一个大系统工程向分布式架构演变过程,你就能很清楚的知道为什么要需要进行应用拆分。

    在这里插入图片描述

    1 人员的角度。

    维护一个代名工程Denali的百万级代码怪兽(虽然物理部署是分离的),从发布到上线,从人员的角度,百号人同时在一个工程上开发,一旦线上出问题,所有代码都需要回滚,从人员的角度,也基本忍受到了极致。

    2 业务的角度

    淘宝包含太多业务:用户、商品、交易、支付…等等,所有的代码早期都在denali一个工程里,代码已经严重影响到业务的效率,每个业务有各自的需求,需要给自己应用部署,各自开发需求。

    3 从架构的角度

    从数据库端oracle数据库集中式架构的瓶颈问题,连接池数量限制(oracle数据库大约提供5000个连接),数据库的CPU已经到达了极限90%。数据库端也需要考虑垂直拆分了。

    4.急需走向一个大型的分布式时代,率先需要应用拆分。

    1 )首先工程代码垂直拆分

    把整个工程代码按照业务为单元进行垂直拆分。

    淘宝按照业务为单位拆分成了类似这样的系统:UM(UserManger)、SM(ShopManager)…等等几十个工程代码。

    2 )应用服务拆分

    按照业务为单位,把所有调用相关的接口以业务为单元进行拆分。

    比如,一个店铺系统,需要访问一个用户的头像的接口,用户头像的接口是独立部署在用户中心(UIC)这边的集群服务器上的。随着拆分的进行,淘宝的业务接口中心就变成了:UIC(用户中心服务)、SIC(店铺中心服务)等等以业务为单元部署的集群。

    最终就演变成下图,按照业务为单位拆分和部署服务,用户中心、商品中心等:

    在这里插入图片描述

    总之,系统拆分是单体程序向分布式系统演变的关键一步,也是很重要的一步,拆分的好坏直接关系到未来系统的扩展性、可维护性和可伸缩性等,拆分工作不难理解,但是如何正确拆分、有什么样的方法和原则能帮助我们拆分得到一个我们理想中的系统:高可用、可扩展、可维护、可伸缩的分布式系统。

    以下主要再从拆分需求、拆分原则和拆分步骤谈起:

    什么情况需要拆分

    1、组织结构变化:从最初的一个团队逐渐成长并拆分为几个团队,团队按照业务线不同进行划分,为了减少各个业务系统和代码间的关联和耦合,几个团队不再可能共同向一个代码库中提交代码,必须对原有系统进行拆分,以减少团队间的干扰。

    2、安全:这里所指的安全不是系统级别的安全,而是指代码或成果的安全,尤其是对于很多具有核心算法的系统,为了代码不被泄露,需要对相关系统进行模块化拆分,隔离核心功能,保护知识产权。

    3、替换性:有些产品为了提供差异化的服务,需要产品具有可定制功能,根据用户的选择自由组合为一个完整的系统,比如一些模块,免费用户使用的功能与收费用户使用的功能肯定是不一样的,这就需要这些模块具有替换性,判断是免费用户还是收费用户使用不同的模块组装,这也需要对系统进行模块化拆分。

    4、交付速度:单体程序最大的问题在于系统错综复杂,牵一发而动全身,也许一个小的改动就造成很多功能没办法正常工作,极大的降低了软件的交付速度,因为每次改动都需要大量的回归测试确保每个模块都能正确工作,因为我们不清楚改动会影响到什么,所以需要做大量重复工作,增加了测试成本。这时候就需要对系统进行拆分,理清各个功能间的关系并解耦。

    5、技术需求:

    1)单体程序由于技术栈固定,尤其的是比较庞大的系统,不能很方便的进行技术升级,或者说对引入新技术或框架等处于封闭状态;每种语言都有自己的特点,单体程序没有办法享受到其它语言带来的便利;对应到团队中,团队技术相对比较单一。

    2)相比于基于业务的垂直拆分,基于技术的横向拆分也很重要,使用数据访问层可以很好的隐藏对数据库的直接访问、减少数据库连接数、增加数据使用效率等;横向拆分可以极大的提高各个层级模块的重用性。

    6、业务需求:由于业务上的某些特殊要求,比如对某个功能或模块的高可用性、高性能、可伸缩性等的要求,虽然也可以将单体整体部署到分布式环境中实现高可用、高性能等,但是从系统维护的角度来考虑,每次改动都要重新部署所有节点,显然会增加很多潜在的风险和不确定定性因素,所以有时候不得不选择将那些有特殊要求的功能从系统中抽取出来,独立部署和扩展。

    如何应用拆分

    1.拆分原则

    • 单一职责
    • 服务粒度适中
    • 考虑团队结构
    • 以业务模型切入
    • 演进式拆分
    • 避免环形依赖和双向依赖

    2.分布式应用拆分实战

    下面是拆分代码过程实践经验:

    1). 设计module骨架

    module骨架的设计是基础,影响最终拆分结果,拆分成功的向导。按照技术,业务,部署打包,测试这几个维度来规划设计,下面是一个参考。

    最终骨架模型层级:

    root web app

    webapp //war module,打包为单体war,整体部署

    micro-services //微服务pom module

    user-service

    customer-service

    order-service

    other-service

    api-gateway

    biz //业务相关的module

    entitys //所有实体类

    biz-base //一些无法拆分的代码上有依赖的服务

    biz-user //用户业务

    biz-customer //客户业务

    biz-order //订单业务

    commons

    async-framework //一部框架

    utils //工具类

    2). 拆分技术commons

    作为第一步,先对整个工程按业务和功能进行了maven多module的拆分。

    首先是分离出技术上的commons,感觉这应该是最好拆分的了,把相关的类重构到一个包里,在分离出一个module即可。

    3). 拆分entity

    很多在业务代码上都会共享entity类,通常没法也没法把entity类分门别类,最简单就是把所有的entity类放到一个module,谁需要谁依赖的原则。entity类也没有太多jar依赖和业务依赖,也不会形成污染源。

    4)公共业务

    同commons和entity方法,不在复述,也被各个业务依赖,这种业务大部分是过渡性的,在未来迭代演进时可以通过其他方式抽象集成。

    5)拆分业务代码

    拆分业务是最痛苦的事情了,这个要看原来的代码整洁度和互相依赖程度,一般采取2中方法:

    • 新建业务module,加入基础module的pom依赖,再从源module复制和该业务module相关的代码(包括单元测试代码)过来,解决编译错误和单元测试错误,完成本业务拆分。
    • 从源module复制一个新业务module,保持代码一致,先删除和本义务无关的代码(包括单元测试代码),再删除无关的pom依赖,解决编译错误和单元测试错误,完成本业务拆分。

    选择哪种方法,可以根据代码整洁度和互相依赖程度,如果代码很整洁且相互依赖较弱,可以采取前者,否则就采取后者。

    6)拆分微服务

    有了以上的拆分基础,可以在合适的业务迭代将各个微服务module迁移到不同的代码仓库,完成进一步隔离管理。

    微服务架构框架

    在这里插入图片描述

    业界开源微服务架构框架提供了微服务的关键思路,例如 Dubbo 和 Spring Cloud(请关注后续文章,我会详解区别和优劣势)

    在这里插入图片描述

    Dubbo是Alibaba开源的分布式服务框架,它最大的特点是按照分层的方式来架构,使用这种方式可以使各个层之间解耦合(或者最大限度地松耦合)。

    Spring Cloud是一个微服务框架,相比Dubbo等RPC框架, Spring Cloud提供的全套的分布式系统解决方案。

    微服务架构是互联网技术发展的必然结果,它提倡将单一应用程序划分成一组小的服务,服务之间互相协调、互相配合,为用户提供最终价值。

    分布式架构之应用拆分总结

    1.明确拆分原则和拆分需求。

    2.梳理出业务模块和之间的依赖关联关系。

    3.按照业务为单位,拆分实体、以及应用工程单独部署。

    4.按照业务为单位拆分应用服务,避免环形依赖和双向依赖。

    5.抽离出公用的接口、实体,以及服务单独部署为公用服务。

    展开全文
  • 系统拆分原则

    千次阅读 2015-08-08 21:15:42
    细数到今天,拆分系统已经断断续续进行了一个月了,希望在这里整理一下,对接下来的拆分工作有益。 这里记录一下在实际工作中总结的几条原则吧,主要是达到各系统间低耦合,系统内部高内聚。 1. db不能跨系统访问。...

    细数到今天,拆分系统已经断断续续进行了一个月了,希望在这里整理一下,对接下来的拆分工作有益。

    这里记录一下在实际工作中总结的几条原则吧,主要是达到各系统间低耦合,系统内部高内聚。

    1. db不能跨系统访问。自己的db自己管理,简单好维护,降低各系统间的数据耦合度。需要做成这样很多以前的联合查询都得改造。
    1. 各子系统要封装得足够好。所有子系统通过自己的api项目向其它子系统提供数据服务,这些api项目打包成jar包供其它子系统使用,以降低业务耦合性。
    1. 子系统不缓存其它子系统的数据。因为只要缓存其它子系统的数据就可能会造成数据不一致,但是这样严格做起来有一定的难度(系统间调用耗时)。所以有的时候为了性能考虑会缓存少量关键数据。比如说一个用户小李注册后,他的基本信息存在用户系统。他又申请成为了特约投稿人,那他特约投稿人的信息就存在投稿系统。如果业务系统有很多对用户不同身份而进行不同的操作,就可以把小李是特约投稿人的身份存在用户系统里,而不用每次都到投稿系统查询。
    1.  缓存距离用户越近越好。顾名思义就是将变动比较少的数据缓存放到http服务器上,这样可以达到最快的响应。变动比较大的数据在前端用js来请求并渲染,充分利用浏览器的性能来提高用户体验,分担服务器的压力。
    1. 如果数据必须不能丢失,拉比推更安全。首先拉有序列,只要有序列就可以通过记录最后一条回执来保证之前的都已获取,而不用像推送那样来记录每一条记录的回执;其次,推送需要有回执才能证明对方已经接收到,如果拉的话由自己来记录自己拿到第几条,不需要有回执这一步了。


    先写这些吧,以后发现再补充。

    展开全文
  • AKF拆分原则

    千次阅读 2019-09-16 14:07:43
    我们讲一下如何去设计...服务,第四个就是Restful通信风格,我们先来看第一个原则,AKF拆分原则,业界对可扩展的系统架构设计有一个 朴素的理念,理念是什么呢,我们通过加机器就可以解决容量和可用性的问题,当你的系统...
    我们讲一下如何去设计我们的微服务,以及微服务的设计原则是什么,我们一般在设计我们的微服务的时候,
    
    都会遵循四个原则,哪四个原则呢,第一个就是AKF拆分原则,第二个就是前后端分离原则,第三个就是无状态
    
    服务,第四个就是Restful通信风格,我们先来看第一个原则,AKF拆分原则,业界对可扩展的系统架构设计有一个
    
    朴素的理念,理念是什么呢,我们通过加机器就可以解决容量和可用性的问题,当你的系统遇到容量和可用性
    
    瓶颈的时候,其实我们可以对系统做水平扩展,通过加机器,来解决容量和可用性的问题,当然这句话是我自己加的,
    
    如果一台不行那就两台,做集群,这种解决问题的方式呢,跟我们生活当中一个段子比较相似,世界上没有什么事
    
    是一顿烧烤不能解决的,如果有,那就两顿,我们接下来就往下看,这一理念在云计算疯狂流行的今天,得到了广泛
    
    的认可,通过加机器可以解决容量和可用性的问题,是不行的,容量和性能当然是首当其冲的,但是随着时间的向前,
    
    系统规模的增长,除了面对性能和容量的问题外,还需要面对功能和模块上的增长,所带来的系统复杂性的问题,以及
    
    业务的变化带来的提供差异化的问题,而许多系统在架构设计时,并未充分考虑到这些问题,导致系统的重构成为
    
    常态,从而影响系统的交互能力,浪费人力财力,对此,有一本书叫可扩展的艺术,在这本书提出一个更加系统的
    
    可扩展模型,叫AKF可扩展立方,英文名字叫Scalability Cube,在这个立方体中,沿着这三个坐标轴设计分别为X,Y,Z,
    
    这是什么意思呢,我们现在的系统,特别是互联网项目,他的需求的变更,或者功能的迭代次数是非常频繁的,还有什么
    
    呢,性能问题也是我们需要考虑的一个非常重要的问题,比如互联网项目他的特点就是,用户群体一大了,就意味着我们的
    
    访问量和请求量就成指数上涨,那么我们的系统能不能取处理这些请求,也就是你系统的请求量是什么样的,那就提出了一个
    
    很高的标准了,还有什么呢,我们当前的互联网项目,他的需求或者他的功能,会经常发生一些改变的,要对我们的系统经常
    
    做一些功能上的迭代,来提高对系统业务功能的一个能力,所以面对这样的一个复杂环境,我们系统怎么具备一个可扩展性呢,
    
    什么架构能够让我们的系统具备一个很好地可扩展性呢,其实是摆在我们勉强一个非常头痛的问题,那么AKF拆分原则,其实是一个
    
    很好的积累原则,他分别用三个坐标来表示,那么三个坐标表示的是什么含义呢,我们来看一下

    分别有Y轴,X轴,Z轴,原点在这个位置,如果我们用的是单体系统的话,我们肯定要对系统做改造了,
    
    那么怎么改造呢,Y,X,Z的坐标,如果我们系统满足了这三种坐标,我们的系统就可以做无限的扩展了,
    
    这三个坐标分别表示什么含义,Y轴更多的是表达功能上的内容,关注应用中的功能划分,基于不同的业务
    
    来拆分,如果你的系统想做很强的可扩展性,那么你单体系统肯定是做不到的了,我们必须把单体系统划分为不同的服务,
    
    按什么拆分呢,我们可以按照功能或者是业务,来进行拆分,这是他所具备的一个必要的条件,必须把原来一个的单体拆分
    
    为多个的服务,第二个X轴,X轴表示的是什么意思呢,水平复制,其实水平复制是什么呢,就是水平扩展,关于水平扩展就是
    
    加机器,当我们拆分出来的这些服务,在这些服务当中,如果有某些服务它的需求量,请求量比较大,我们肯定要对这样的
    
    服务做性能的提升,那么怎么对她做性能的提升呢,这个就说到刚才比较朴素的理念,加机器就可以解决,对你这个服务做集群处理,
    
    做水平扩展或者横向扩展,只要你做集群了,就会有一个问题,就是负载均衡的问题,以前我们一个服务运行在一个服务器当中,
    
    现在是一个服务要部署到多个服务器当中,那么在有请求过来的时候,我这个请求要交给哪个服务器当中呢,这个时候就需要
    
    我们的负载均衡来解决了,比如我们可以采用负载均衡当中最基本的一个策略,就是轮询策略,让不同的服务区处理相同的请求,
    
    以此来轮询,处理请求的方式,所以如果我们要做集群了,是我们需要考虑的一个点,还有一个就是Z轴数据分区,数据分区主要关注的是
    
    什么呢,其实就是关注服务和数据的优先级划分,如按地域划分,那么Z轴数据分区是什么意思呢,这个我们先放到这里,我们讲Z轴的
    
    时候再重点讲这一块,所以如果我们的系统在设计的时候,就考虑到了Y轴,X轴,Z轴这样一个体现的话,那么其实我们的系统,在
    
    扩展性这块也变得非常的容易了,他具有无限扩展的能力

    我们接下来对可扩展的Y轴,X轴,Z轴做一个详细的介绍,因为这个东西确实很重要,我们来看Y轴,它主要关注的
    
    是功能,Y轴会将扩展的整体应用拆分为多个服务,每个服务实现一组相关的功能,如订单管理,客户管理等,在工程上
    
    常见的架构就是服务化架构,SOA,就是面向服务架构,比如对于一个电子商务平台,拆分成不同的服务,我们来看一下
    
    这个图

    Y轴是按功能拆分,左侧这一端就是客户端了,比如有PC端用户登陆,还有 移动端用户登陆,PC端用户购买,
    
    移动端用户购买,他们都会向我们不同的服务发请求,来去做一个请求的处理,其实我们通过上面的图可以很容易发现,
    
    当服务的数量增多时,服务调用关系变得复杂,为系统添加了一个新的功能,要调用的服务数量也变得不可控,由此引发
    
    服务管理上的混乱,所以一般情况下,我们要采用服务注册的机制,形成服务网关来形成服务的治理,其实这种架构方式,
    
    和讲的RPC,架构是一样的,因为RPC是直接由我们的应用来调用我们的服务,那么这个时候如果服务量大的时候,我们服务
    
    治理这块就会麻烦,非常的难的,所以我们可以通过注册的机制,其实下面就是解决服务的这个问题
    其实就是SOA架构和微服务架构,到底是SOA架构还是微服务架构,看你中间这一层用的是什么,
    
    SOA用的是企业的总线,企业服务总线,而微服务架构用的是注册,服务的注册与发现,那么其实这些都
    
    无关紧要了,咱们就以微服务来讲,微服务采用的是注册的机制,现在所有的服务都注册到服务网关上,
    
    然后其他的设备通过服务网关,来决定去访问哪个服务,对我们的服务区做一些管理,比如说服务的注册,
    
    还有服务的发现,还有服务的查询,我们都可以在这个服务网关当中,针对性的去操作我们想要操作的
    
    服务,所以说这是Y轴所体现的
    

    X轴表示的是什么呢,是我们的系统做水平扩展,X轴扩展和我们前面的理念是一致的,通过绝对平等的
    
    复制,服务于数据,以解决容量和可用性的问题,其实就是讲微服务运行在多个实例,做集群加负载均衡的模式,
    
    你看我们当前这个图形,其实在这些服务当中,比如某个服务的压力比较大了,那么这个时候我们肯定需要用到X
    
    轴的概念来解决,就是做水平扩展,但是现在是没有体现X轴扩展的

    原来我们对于服务的治理都是指向一个服务,现在我的每一个相同的服务,都放到不同的服务器当中,
    
    这个就等于对这个服务做了集群处理,他指向的是这一部分的集群,那么一旦我们做水平扩展了,对服务的
    
    性能肯定有一个呈指数的提高的,所以说现在这个图形,就是带X轴的,这个原来只有Y轴的,这个是带X轴的

    Z轴指的是什么呢,指的是数据分区,Z轴扩展通常是指基于请求或者用户独特的需求,进行系统的划分,
    
    并使得划分出来的子系统,是相互隔离但是又是完整的,后面有一个例子,这个例子说的很清楚了,以生产
    
    汽车的工厂来举例,福特为了发展在中国的业务,或者是利用中国的廉价劳动力,在中国建立一个完整的子
    
    工厂,与美国的工厂是一样的,然后也是负责完整的汽车生产,那么这个就是Z轴的生产,我相信通过这个例子,
    
    应该很容易理解什么是Z轴扩展

    一个是单元化架构,一个是数据分区,我们先来看第一个单元化架构,什么是单元化架构呢,
    
    就是在分布式服务设计领域,一个单元就是满足某个分区所有业务操作的子包含闭环,如上面我们
    
    说到的Y轴扩展的SOA架构,客户端对服务端节点的选择,一般是随机的,但是如果在此加上Z轴扩展,
    
    服务节点的选择将不再是随机的了,而是每一个单元自成一体了

    PC端的也可以,移动端的也可以,但是如果我们要做一个单元化结构的一个扩展呢,
    
    就会变成这种结构了,相同的系统我完全部署两份,创造两份,这两个系统之间是完全隔离的,
    
    然后PC端的用户呢只能访问PC端的系统,移动端的用户只能访问移动端的系统,所以这个就和我们
    
    上面所说的造车是一样的案例,这是福特美国厂商,这是福特中国厂商,而且他们之间也是互相隔离的

    再来看数据分区,还有一种方式就是数据分区,那么数据分区是什么含义呢,为了性能数据安全上的考虑,
    
    我们将一个完整的数据集按一定的维度划分出不同的子集,一个分区,就是整个数据集的一个子集,比如用尾号
    
    来划分用户,那同样尾号的哪些用户,就可以认为是一个分区,数据分区一般包括以下几种数据划分方式,比如根据
    
    数据类型,数据范围,数据热度,还有读写分离,其实按照数据去分区,其实这一块并不是很难理解,我给大家举一个例子,
    
    让大家理解一下,什么是数据分区,比如打车软件,最常见的互联网打车软件,他已经支持国内好多的城市了,比如我在北京
    
    用打车软件来打车,在上海,在南京,在天津,都可以做预约,其实从城市的规模来看,不同的城市规模是不一样的,如果互联网的
    
    打车系统,他所有的数据都整合到一起了,你会发现数据量还是非常大的,而且在一些小城市里面,用打车软件去打车,这个时候
    
    由于数据都是耦合到一起的,数据量大了,也就是他的性能肯定是会受到影响的,由于把所有的城市的数据整合到一个数据当中,
    
    性能上肯定会受到影响,那怎么解决这个问题呢,很简单,我们可以针对不同的城市,去做不同的数据存储,那么不同城市的数据
    
    存储呢,其实就是一个分区,换句话就是,在不同的城市建立不同的数据分区,然后当你在某个城市打车的时候,其实访问的是这个
    
    城市的分区,然后数据分区是整个数据集的一个子集,我们最终还会将这些分区的数据,合成一个完整的数据集,然后我们的管理
    
    系统,管理平台,可以对整合进来的数据集做一些管理,这样就提高了我们系统的一个性能,非常直观的一种表现形式,所以数据分区的
    
    概念并不是很抽象,我们理解起来应该是很容易的,以上就是AKF概念上的讲解,如果我们要采用微服务的方式来设计的话,那么AKF拆分的
    
    原则在我们架构的时候呢,将会起到一个非常重要的指导性作用,所以我建议大家,花点时间,把我讲的这一块的内容呢,好好消化,这是非常
    
    重要的一个原则

     

    展开全文
  • 微服务化系统拆分设计的原则

    千次阅读 2016-12-08 15:07:20
    最近刚好有机会处理把巨型运用拆分成微服务,无意中看到这个,觉得很赞的! x轴:水平复制,即在负载均衡服务器后增加多个web服务器; z轴扩展:是对数据库的扩展,即sharding(分库关注垂直方向是将关系紧密的表...
  • 系统架构设计模块拆分维度和原则

    千次阅读 2018-08-06 20:46:03
    在我们从零开始做一个新系统的时候,会首先进行系统功能模块架构设计,那么是直接做一个大而全的垂直的MVC系统,使用一个war包进行发布管理,还是需要按一些规则进行模块拆分,设计成SOA或者微服务系统比较好呢?...
  • 微服务拆分微服务拆分时机为了快速迭代高并发场景可重用提交代码经常冲突小功能要积累到大版本才能上线服务拆分原则原则一:高内聚和低耦合。原则二:服务拆分正交性原则原则三:服务粒度适中、演进式拆分原则四:...
  • 用户故事及拆分原则

    2021-07-27 15:40:28
    用户故事及拆分 1.什么是用户故事 用户角度描述系统行为的变化。用户想通过系统做的事情,或系统为他们做的事情。 模板 作为XX角色 我想要XX功能或行动 以便于实现XX价值或目标 模板优点 WHO(讨论用户角色) ​ 讨论...
  • 微服务拆分原则

    千次阅读 2020-07-07 23:40:51
    1)AKF拆分原则 2)前后端分离原则 3)无状态服务 4)restful的通信风格 AKF拆分原则 对于一个规模迅速增长的系统而言,容量和性能问题当然是首当其冲的。但是随着系统规模的增长,除了面对性能与容量的问题外...
  • 个人对系统拆分的理解

    千次阅读 2018-07-18 14:25:41
    1,为什么要进行系统拆分 首先我们需要想想,到底什么样的系统需要进行拆分?并不是所有的系统都需要进行拆分,拆分系统是一件耗时并且有风险的操作,所以再拆分前需要再三考虑是否真的需要拆分,拆分的好处是否...
  • 微服务与单体服务的拆分原则

    千次阅读 2019-08-26 17:19:22
    (1)、微服务拆分原则:领域模型、组织结构、康威定律、单一职责 (2)、微服务拥有独立数据库 (3)、微服务之间确定服务边界 2、数据一致性 (1)、可靠性事件模式 (2)、补偿模式-sagas模式 3、服务通信 (1)、通信...
  • 1) AKF 拆分原则 2) 前后端分离原则 3) 无状态服务 4) RestFul 的通信风格 1 AKF 拆分原则 业界对于可扩展的系统架构设计有一个朴素的理念,就是: 通过加机器(水平扩展)就可以解决容量和可用性问题 。( 如果一台...
  • 数据库拆分原则

    千次阅读 2018-08-22 14:29:22
    这将会导致应用卡顿延迟,更严重甚至会导致系统整个崩溃。而解决这种情况的发生,下意识便是如何降低用户对系统数据的读操作。 1、采用redis,memcache等缓存技术,降低对数据库的读操作。 2、其次可以考虑进行...
  • 微服务合并拆分原则

    2021-06-07 17:11:41
    拆分原则 单一职责:高内聚,低耦合,实现单一功能,如单表操作。 颗粒度适当:100个接口不能拆100个服务,适当的分组。 团队结构:1个系统不能由2个团队维护,需要根据团队负责内容进行拆分。 业务模型:不同的...
  • 《持续交付2.0业务引领的DevOps精要》书籍中有一节讲需求拆分的方法的原则写得非常好。其中的INVEST原则,需求拆分的5大技法及用户故事地图等工具的使用在实际的工作中有很好的指导意义。好多产品经理面对一堆用户...
  • 微服务——服务拆分策略与原则

    千次阅读 2020-09-17 09:40:05
    我们应该按照什么原则将现有的业务进行拆分?是否拆分得越细就越好?这里我想结合易企秀商城服务(以下简称商城)的实际情况谈谈服务拆分的策略和坚持的原则。 1.服务拆分策略 1.1根据业务能力进行服务拆分和定义 ...
  • 系统拆分粒度

    2019-10-29 19:51:02
    系统拆分粒度 https://copyfuture.com/blogs-details/201910291948235480dyaua5tzwp25mk ​在什么情况下要进行系统拆分,为什么需要拆分在本篇就不进行说明了。 拆分系统,带来的基本性问题就是,拆分到什么粒度是最...
  • 微服务的拆分规范和原则

    千次阅读 2020-05-28 12:05:02
    目录拆迁方案1、压力模型拆分2、业务模型拆分2.1 主链路拆分2.2 领域模型拆分2.3 用户群体拆分2.4 前后台业务分离 前面我们了解了什么是微服务和为什么需要做微服务架构(What & Why),这一章我们就来探讨如何...
  • 微服务设计、拆分原则-AFK

    千次阅读 2019-11-21 11:20:04
    一、AKF拆分原则  业界对于可扩展系统架构设计有一个朴素的理念:通过加机器就可以解决容量和可用性问题。  这一理念在云计算概念疯狂流行的今天,得到了广泛的认可,对于一个规模迅速增长的系统而言,容量和...
  • 项目工程拆分原则

    千次阅读 2018-08-22 22:07:00
    好多推荐的都是以功能分成进行拆分,真不知道这种模式的好处在哪!!! 功能分层拆分、业务功能拆分?下面一个电商项目(Jmall)为例: 功能分层拆分 按照项目功能分层,分为common(java工程)、dao(java工程)、...
  • 业务模型拆分:前后台业务拆分、主链路查费、领域模型拆分、用户群体拆分 压力模型拆分:对于高并发量的业务,尽可能独立成微服务拆分 1.压力模型拆分 压力模型拆分,就是说根据用户对业务的访问量的高频进行拆分,...
  • 分布式架构之系统拆分

    万次阅读 2016-09-18 18:26:42
    系统拆分是单体程序向分布式系统演变的关键一步,也是很重要的一步,拆分的好坏直接关系到未来系统的扩展性、可维护性和可伸缩性等,拆分工作不难理解,但是如何正确拆分、有什么样的方法和原则能帮助我们拆分得到一...
  • 系统拆分和微服务化

    2019-07-21 16:08:27
    一 为什么需要进行系统拆分 二 如何对系统进行拆分 三 系统拆分实践 一 为什么需要进行系统拆分 一个系统,在不断的迭代和发展过程中将变得越来越复杂。其中复杂主要体现在两方面:一方面是代码量的增加、一...
  • 一个BUG可能引起整个项目的运行 5、阻碍技术创新 微服务架构的优势: 1、易于开发和维护 2、独立部署 3、伸缩性强 4、与组织结构相匹配 5、技术异构性 微服务面临的挑战: 1、服务拆分: (1)、微服务拆分原则:...
  • AKF 拆分原则 业界对于可扩展的系统架构设计有一个朴素的理念,就是: 通过加机器(水平扩展)就可以解决容量和可用性问题 。( 如果一台不行那就两台) 。 我是个段子:( 世界上没有什么事是一顿烧烤不能解决的。如果有...
  • 服务拆分原则

    2019-09-24 06:40:03
    服务拆分有以下几个原则和大家分享 横向拆分。按照不同的业务域进行拆分,例如订单、营销、风控、积分资源等。形成独立的业务领域微服务集群。 纵向拆分。把一个业务功能里的不同模块或者组件进行拆分。例如把公共...
  • Scrum中,拆分故事的INVEST原则

    千次阅读 2018-06-15 10:54:00
     极限编程(XP)倡导者Bill Wake描述用户故事有如下6个属性,简称INVEST原则,可以作为我们拟定用户故事的现实参考。       1、独立的(Independent) 独立性和传统软件工程的松耦合的概念有...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 64,983
精华内容 25,993
关键字:

系统拆分原则