系统拆分

为什么应用拆分

1 人员的角度。

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

2 业务的角度

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

3 从架构的角度

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

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

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

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

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

2 ）应用服务拆分

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

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

最终就演变成下图，按照业务为单位拆分和部署服务，用户中心、商品中心等：总之，系统拆分是单体程序向分布式系统演变的关键一步，也是很重要的一步，拆分的好坏直接关系到未来系统的扩展性、可维护性和可伸缩性等，拆分工作不难理解，但是如何正确拆分、有什么样的方法和原则能帮助我们拆分得到一个我们理想中的系统：高可用、可扩展、可维护、可伸缩的分布式系统。

拆分需求

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

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

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

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

AKF拆分原则

业界对于可扩展系统架构设计有一个朴素的理念：通过加机器就可以解决容量和可用性问题。

　　这一理念在云计算概念疯狂流行的今天，得到了广泛的认可，对于一个规模迅速增长的系统而言，容量和性能问题当然是首当其冲的。但随着时间的向前，系统规模的增长，除了面对性能与容量的问题外，还要面对功能与模块数量上的增长带来的系统复杂性问题以及业务的变化带来的提供差异化服务的问题。

　　然而许多系统在架构设计时为充分考虑这些问题，导致系统重构成为常态，而影响业务交付能力，还浪费人力财力。对此《可扩展艺术》一书提出了一个系统可扩展模型--AKF可扩展立方（Scalability Cube）。

Y轴（功能）关注应用中功能划分，基于不同的业务拆分

Y轴扩展会将庞大的整体应用拆分为多个服务，每个服务实现一组相关的功能，如订单管理、客户管理等。在工程上常见的方案是服务化架构（SOA），比如对于一个电子商务平台，我们可以拆分成不同的服务，组成类似下面的架构：

但通过上图可以发现，当服务数量增多时，服务调用关系变得复杂，为系统添加一个新功能，要调用的服务数变得不可控，由此引发了服务管理上的混乱，所以一般情况下，需要采用服务注册的机制形成服务网关来进行服务治理

X轴（水平扩展）关注水平扩展，也就是“加速器解决问题”

X轴扩展与我们前面朴素理念是一致的，通过绝对平等的复制服务与数据，以解决容量与可用性的问题，其实就是将微服务运行多个实例，做集群加负载均衡的模式。

　　为了提升单个服务的可用性与容量，对每一个服务进行X轴扩展划分。

Z轴（数据分区）关注服务与数据的优先级划分，如按地域划分

Z轴扩展通常是指基于请求者或用户独特的需求，进行系统划分，并使得划分出来的子系统相互隔离但又是完整的。以生产汽车的工厂来举例：福特公司为了发展在中国的业务，或者利用中国的廉价劳动力，在中国建立一个完整的子工厂，与美国工厂一样，负责完整的汽车生产。这就是一种Z 轴扩展。

工程领域常见的Z轴扩展有以下两种方案

1，单元化架构

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

2，数据分区

　　为了性能数据安全上的考虑，我们将一个完整的数据集按一定维度划分出不同的子集。一个分区（Shard），就是整体数据集的一个子集。比如用尾号来划分用户，那同样尾号的那部分用户就可以认为是同一个分区，数据分区一般包括以下几种数据划分形式：

　　数据类型：如业务类型

　　数据范围：如时间段、用户ID

　　数据热度：如用户活跃度、商品热度

　　按读写分：如商品描述、商品库存

面试题积累 https://www.cnblogs.com/skyme/p/13212296.html

微服务微信交流群添加微信，备注微服务进群交流

本文分享自微信公众号 - soft张三丰（aguzhangsanfeng）。
如有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。

来源：oschina

链接：https://my.oschina.net/u/2335629/blog/4642063