共计 939 个字符,预计需要花费 3 分钟才能阅读完成。
服务拆分准则
有很多个准则,这里拿两个罕用的介绍
繁多职责 (SRP)
- 扭转一个类应该只有一个理由。
如果一个类承载了多个职责,那么,这个类就会非常不稳固。
微服务架构下,应设计小、内聚、繁多职责的服务,那么会大大提高服务的稳定性。
- 扭转一个类应该只有一个理由。
闭包准则 (CCP)
- 包中所有类,应该是同类变动的一个汇合。
- 也就是说,如果须要对包做调整,须要调整的类、变量等,都应在这个包之内。
需要变更,改变须要两个耦合的包做调整,这是很大的危险。
如果业务变更,只需调整同一个包下的类,那么就能够极大的改善,我的项目可维护性。
微服务架构下,雷同起因须要扭转的服务,放在一个组件内。
需要变动的变更、部署,代价升高;能够管制服务的数量。
现实的状况下,一个变更只会影响一个团队。
失常开发中,在评估阶段,有很多因素导致,不能齐全的遵循原则。
为了保障日后的可维护性,尽量的依照准则,若不能齐全遵循,则提前准备分段,给日后保护应用。
- 代码是首先是给人读,而不是机器。
- 性能要求不高时,尽可能进步可读性。
拆分服务难点
- 网络延时
大量的接口调用。
例如,http 接口的调用
解决办法:
apigateway,内网中先对某项性能 http、rpc 接口进行聚合
合并相干性能的服务,应用函数调用,取代接口调用 - 同步过程通信,可用性问题
解决过程通信可用性问题。
例如,创立订单,调用户服务验证,用户服务不可拜访
解决办法:
应用异步事件机制
针对例子,应用异步事件,批改流程,创立订单分为:提交订单,验证用户等校验阶段,创立胜利,分阶段进步服务可用性 - 服务间数据一致性
某些操作,可能更改多个服务的数据。
例子:
餐馆承受订单,需更改 kitchen service 状态、delivery service 状态
解决办法:
TCC(Try Confirm Cancle)、
SAGA、
等
https://zhuanlan.zhihu.com/p/… - 获取统一的数据视图
- 上帝类
上帝类是整个应用程序中,应用的全局类。
例子:
订单,蕴含,restaurant、delivery 等信息
而 order 数据表蕴含了所有信息,拆分为 kitchen service、delivery service 就存在问题
解决办法:
应用 DDD
对于例子,对 kitchen service、delivery service 别离实现本人服务外部的订单
正文完