微服务的设计原则

淩亂°似流年 2022-01-25 14:46 375阅读 0赞

### 一 前言 ###

微服务是一种架构风格。一个大型的复杂软件应用，由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好的完成该任务。那么关于微服务的设计原则有哪些呢？如下:

*  AKF 拆分原则
 *  前后端分离原则
 *  无状态服务
 *  RestFul 的通信风格

### 二 AKF 拆分原则 ###

有句挺流行的话:没有什么事是一顿烧烤解决不了的，如果有，那就两顿....。这跟我们之前设计可扩展的系统架构的理念很相像，

通过加机器就可以解决容量和可用性问题 。( 如果一台不行那就两台) 。这个理念在当前也得到了广泛的认可！对于一个规模迅速增长的系统而言，容量和性能问题当然是首当其冲的。但是随着现在业务的更迭不穷以及功能模块的不断拓展，许多系统在设计的时候并没有充分考虑到这一点，所以如果架构重设，必然会导致财力跟人力的浪费。对此，《可扩展的艺术》一书提出了一  
个更加系统的可扩展模型—— AKF 可扩展立方（Scalability Cube）。这个立方体中沿着三个坐标轴设置分别为：X、Y、Z。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzMjIzMjk5_size_16_color_FFFFFF_t_70][]

*  Y 轴(功能) —— 关注应用中功能划分，基于不同的业务拆分
 *  X 轴(水平扩展) —— 关注水平扩展，也就是”加机器解决问题”
 *  Z 轴(数据分区) —— 关注服务和数据的优先级划分，如按地域划分

**2.1 Y 轴（****功能）**

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

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzMjIzMjk5_size_16_color_FFFFFF_t_70 1][]

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

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzMjIzMjk5_size_16_color_FFFFFF_t_70 2][]

**2.2 X 轴(水平扩展)**

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

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzMjIzMjk5_size_16_color_FFFFFF_t_70 3][]

**2.3 Z 轴( 数据分区)**

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

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

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzMjIzMjk5_size_16_color_FFFFFF_t_70 4][]

2 数据分区  
为了性能数据安全上的考虑，我们将一个完整的数据集按一定的维度划分出不同的子集。 一个分区（Shard），就是是整体数据集的一个子集。比如用尾号来划分用户，那同样尾号的那部分用户就可以认为是一个分区。数据分区为一般包括以下几种数据划分的方式：  
数据类型（如：业务类型）  
数据范围（如：时间段，用户 ID）  
数据热度（如：用户活跃度，商品热度）  
按读写分（如：商品描述，商品库存）

举个例子:比如美团，滴滴遍布全国，各个城市的业务进展不太一样，所以可以根据城市来进行数据分区。

### 三 前后端分离原则 ###

这个我们应该很常见，前端做前端的事情，后端做后端的业务模块，分工更加明确。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzMjIzMjk5_size_16_color_FFFFFF_t_70 5][]![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzMjIzMjk5_size_16_color_FFFFFF_t_70 6][]

那么前后段分离有什么好处呢?

这种分离方式有几个好处：

*  前后端技术分离，可以由各自的专家来对各自的领域进行优化，这样前段的用户体验优化效果更好。
 *  分离模式下，前后端交互界面更清晰，就剩下了接口模型，后端的接口简洁明了，更容易维护。
 *  前端多渠道集成场景更容易实现，后端服务无需变更，采用统一的数据和模型，可以支持多个前端：例如：微信 h5 前端、PC 前端、安卓前端、IOS 前端。

### 四 无状态服务 ###

什么是状态？

如果一个数据需要被多个服务共享，才能完成一笔交易，那么这个数据被称为状态。进而依赖这个“状态”数据的服务被称为有状态服务，反之称为无状态服务。更好的说明见下图：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzMjIzMjk5_size_16_color_FFFFFF_t_70 7][]

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

### 五 RestFul通讯风格 ###

作为一个原则来讲本来应该是个“无状态通信原则”，在这里我们直接推荐一个实践优选的 Restful 通信风格 ，因为他有很多好处：

1.  无状态协议 HTTP，具备先天优势，扩展能力很强。例如需要安全加密，有现成的成熟方案 HTTPS 即可。
2.  JSON 报文序列化，轻量简单，人与机器均可读，学习成本低，搜索引擎友好。
3.  语言无关，各大热门语言都提供成熟的 Restful API 框架，相对其他的一些RPC 框架生态更完善。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzMjIzMjk5_size_16_color_FFFFFF_t_70]: /images/20220125/67777fa305e34074b96bc338a966cc04.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzMjIzMjk5_size_16_color_FFFFFF_t_70 1]: /images/20220125/1a6911163bca41aeb1292f3ff906b363.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzMjIzMjk5_size_16_color_FFFFFF_t_70 2]: /images/20220125/420229e0b06a40c582bd2c938d4fd99e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzMjIzMjk5_size_16_color_FFFFFF_t_70 3]: /images/20220125/c4a69431e15848e9a9ab0b95a23e1dd4.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzMjIzMjk5_size_16_color_FFFFFF_t_70 4]: /images/20220125/f79fb296315b4aa692a5683e3e00d7f4.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzMjIzMjk5_size_16_color_FFFFFF_t_70 5]: https://img-blog.csdnimg.cn/20190530194845543.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzMjIzMjk5,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzMjIzMjk5_size_16_color_FFFFFF_t_70 6]: /images/20220125/43cb225ecfaf4f24ac2465cdce391337.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzMjIzMjk5_size_16_color_FFFFFF_t_70 7]: /images/20220125/25c238037bae44f2b78d143d7385b7b8.png