微服务设计

一、微服务架构的六种常用设计模式

在使用微服务架构设计模式中，通常情况下是混合使用的。这里列举的是单一的模式。商业开发中，大多数都是混合使用的

1. 代理设计模式
   

2. 聚合设计模式
   保证多个服务配合执行的时候，可以由一个严格的逻辑顺序
   

3. 链条设计模式
   是多个服务通过链条式调用，得到最终结果的设计方式。类似责任链。链条长度不超过5。2~4之间。链条太长会导致网络通讯次数增多，降低效率。如果链条长度超过5，建议使用异步通讯
   

4. 聚合链条设计模式
   就是聚合设计模式+链条设计模式。是一个常见的组合设计模式。
   在聚合设计模式的开发过程中，某一个被聚合子服务，有链条调用的时候，使用的设计模式。链条长度不超过5
   

5. 数据共享设计模式
   是多服务配合的一种常用设计模式。一般用于前后台数据交互使用。
   这里的前后台，是针对业务上的前后台，不是代码逻辑上的前后台系统。
   如：电商（JD），业务上的前台就是客户可使用的平台（www.jd.com）。业务上的后台就是JD工作人员使用的平台。
   如：后台人员增加新的商品数据，需要通过中间服务实现数据的存储。因为前台客户也需要看到新的商品数据。如果后台人员做商品数据的查看统计，可以不通过中间服务，直接访问数据库，实现数据的读取统计。
   数据共享设计模式，在现在的互联网行业应用较少。毕竟互联网行业效率优先，所以缓存设备几乎无处不在。
   

6. 异步消息设计模式
   就是集合MQ实现异步处理的设计模式。通常使用在即时性要求不高的业务中
   

二、微服务拆分

在拆分上没有固定的逻辑套用方式。主要是根据经验来实现拆分。
常见经验：

1. 业务拆分。每个业务一个独立的服务。如：登录、注册、用户管理（修改密码、修改个人信息），分别是一个业务。需要拆分。
2. 数据拆分。当业务逻辑过于复杂的时候，可以配合数据实现更明确的拆分。如：用户表操作、订单表操作、商品表操作等。如果数据关联度太高，容易有服务耦合的情况。如：订单和商品有关联、用户和地址有关联、用户和订单有关联。
3. 读写拆分。建议为读写操作拆分服务。读写操作与幂等性相关，与数据安全性相关。建议读写分离。
   一般来说，大型项目都是根据业务拆分，保证读写分离。中小型项目一般是根据数据拆分，保证读写分离（通常会为了业务的实现简易性，增加数据的冗余）