微服务设计，拆分原则

电玩女神 2022-09-07 14:59 200阅读 0赞

**目录**

一、AKF拆分原则

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

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

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

二、前后端分离原则

三、无状态服务原则

四、RestFul 通讯风格

五、现状思考

--------------------

# 一、AKF拆分原则 #

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

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

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

![6cdea52ffdfd367c0dd9785dd8c194b4.png][]

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

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

![0d6b848af6a9c7c39dc79e7ed5184636.png][]

、

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

![ae249cb59228e68a3f861938809bbcac.png][]

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

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

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

![255f47b37f31fafdbeb88fe73cf52982.png][]

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

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

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

**1，单元化架构**

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

![07279ff6566cd61f750ca9e42f86e107.png][]

**2，数据分区**

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

数据类型：如业务类型

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

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

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

# 二、前后端分离原则 #

![2821361765d31d36b5d6327fa119ed16.png][]

何为前后端分离？前后端本来不就是分离的吗？这要从jsp开始讲起。分工精细化从来都是蛋糕做大的原则，多个领域工程师最好在不需要接触其他领域知识的情况下合作，才能使效率越来越高，维护也会变得简单。jsp的模板技术融合了html和java代码，使得传统MVC开发中的前后端如胶似漆，前端做好页面，后端转成模板，发现问题再找前端，前端又看不懂java代码，前后端分离的目的就是打破这尴尬的局面，**我们需要的是一个全能的团队，而不是一个个全能的人**。

前后端分离原则，简单的将就是前端和后端的代码分离，我们推荐的模式是最好采用物理分离的方式部署，进一步促使更彻底的分离。如果继续使用服务端模板技术，如jsp，把java、js、css、html都堆到一个页面里，稍微复杂一点的页面就无法维护了。

这种前后端分离有几个好处：

1，前后端技术分离，可以由各自的专家来对各自的领域进行优化，这样前端的用户体验会更好。

2，分离模式下，前后端交互界面更清晰，就剩下接口模型，后端接口简介明了，更易于维护。

3，前端多渠道继承场景更容易实现，后端服务无需变更，采用统一的数据和模型，可以支持多个前端，例如：微信h5前端、PC前端、安卓前端、IOS前端。

# 三、无状态服务原则 #

![483e9d76b72cc26c12ae078ddb470df9.png][]

对于无状态服务，首先说一下什么是状态：如果一个数据需要被多个服务共享，才能完成一笔交易，那么这个数据被称为状态。进而依赖这个状态的服务被称为有状态的服务，反之成为无状态服务。

这个无状态服务原则并不是说在微服务架构里不允许存在状态，表达的真实意思就是要把有状态的业务服务改变为无状态的计算类服务，那么状态数据也就相应的迁移到对应的“有状态数据服务”中。

场景说明：例如我们从前在本地内存中建立的数据缓存、Session缓存，到现在微服务架构中就应该把数据迁移到分布式缓存中存储，让业务服务变成一个无状态的计算节点。迁移后，就可以做到按需动态伸缩，微服务应用在运行时动态增删节点，就不再需要考虑缓存数据如何同步的问题。

# 四、RestFul 通讯风格 #

![9d9d39e8fc0ebce7fe38041916fd8817.png][]

这里介绍一个“无状态通讯原则”-Restful通讯风格，它有许多优点：

1，无状态协议HTTP，具备先天优势，扩展能力强，例如安全加密有成熟的https。

2，JSON报文序列化，轻量简单，人与机均可读，学习成本低，搜索引擎友好。

3，语言无关，各大热门语言都提供成熟的Restful API框架，相对一些其他RPC框架生态更加完善。

# 五、现状思考 #

当前我们的业务架构中已有几十种服务，每一种服务之间的调用也是盘根错杂，虽然已有服务注册中心，有网关进行路由，但是服务根据业务拆分的比较细，一些根据业务独立的服务又根据子业务进行Y轴拆分也是比较细，针对X轴的拆分，我们也在尝试，其实这里根据X轴的实现，不是拆分了，而是为了高可用，提升性能，进行的一个服务扩充，多实例部署；在我们对一些定制化的服务的时候，也是需要Z轴的一个拆分，为定制化的需求，单独部署一整套的服务来实现，与其他服务完全隔离开来。

在服务越来越多的时候，瓶颈就在于网关，其他的服务都可以部署成非单点的模式，哪怕某个服务实例停止了服务，其他实例也可以顶上来，但是网关是千万不能出问题的，包括我们现在用的nginx再最外层还进行了一层网关路由，这里的nginx和zuul一定是重中之重。

[6cdea52ffdfd367c0dd9785dd8c194b4.png]: /images/20220829/ddd686265ad84a42b9058187f15590b1.png
[0d6b848af6a9c7c39dc79e7ed5184636.png]: /images/20220829/83fa042baa33415b9e99747ca46ed9f6.png
[ae249cb59228e68a3f861938809bbcac.png]: /images/20220829/e8a8aca561e34570b3d8fe7c0b3577f5.png
[255f47b37f31fafdbeb88fe73cf52982.png]: /images/20220829/c43d174f52894f22b094f374b05fb40c.png
[07279ff6566cd61f750ca9e42f86e107.png]: /images/20220829/244c9ba94d17423c98dc0e86fc587806.png
[2821361765d31d36b5d6327fa119ed16.png]: /images/20220829/176106b5e0b44032864e8231a3a2a0bb.png
[483e9d76b72cc26c12ae078ddb470df9.png]: /images/20220829/24d96150be7445738bce40c355135572.png
[9d9d39e8fc0ebce7fe38041916fd8817.png]: /images/20220829/29aeda45539d4c78bdad4c7969dd4b90.png