服务拆分原则及难点

服务拆分原则

有很多个原则，这里拿两个常用的介绍

1. 单一职责(SRP)

   • 改变一个类应该只有一个理由。
     如果一个类承载了多个职责，那么，这个类就会十分不稳定。
     微服务架构下，应设计小、内聚、单一职责的服务，那么会大大提高服务的稳定性。
     
     

2. 闭包原则(CCP)

   • 包中所有类，应该是同类变化的一个集合。
   • 也就是说，如果需要对包做调整，需要调整的类、变量等，都应在这个包之内。
     
     需求变更，改动需要两个耦合的包做调整，这是很大的风险。
     假如业务变更，只需调整同一个包下的类，那么就可以极大的改善，项目可维护性。
     微服务架构下，相同原因需要改变的服务，放在一个组件内。
     需求变化的变更、部署，代价降低；可以控制服务的数量。
     理想的情况下，一个变更只会影响一个团队。

正常开发中，在评估阶段，有很多因素导致，不能完全的遵循原则。
为了保证日后的可维护性，尽量的按照原则，若不能完全遵循，则提前准备分段，给日后维护使用。

• 代码是首先是给人读，而不是机器。
• 性能要求不高时，尽可能提高可读性。

服务拆分难点

1. 网络延时
   
   大量的接口调用。
   例如，http接口的调用
   解决办法：
   apigateway，内网中先对某项功能http、rpc接口进行聚合
   合并相关功能的服务，使用函数调用，取代接口调用
   
   
2. 同步进程通信，可用性问题
   
   处理进程通信可用性问题。
   例如，创建订单，调用户服务验证，用户服务不可访问
   解决办法：
   使用异步事件机制
   针对例子，使用异步事件，修改流程，创建订单分为：提交订单，验证用户等校验阶段，创建成功，分阶段提高服务可用性
   
   
3. 服务间数据一致性
   
   某些操作，可能更改多个服务的数据。
   例子：
   餐馆接受订单，需更改kitchen service状态、delivery service状态
   解决办法：
   TCC(Try Confirm Cancle)、
   SAGA、
   等
   https://zhuanlan.zhihu.com/p/...
   
   
4. 获取一致的数据视图
   
5. 上帝类
   
   上帝类是整个应用程序中，使用的全局类。
   例子：
   订单，包含，restaurant、delivery等信息
   而order数据表包含了所有信息，拆分为kitchen service、delivery service就存在问题
   解决办法：
   使用DDD
   对于例子，对kitchen service、delivery service 分别实现自己服务内部的订单