场景五：微服务中的服务划分问题 微服务拆分原则、方法与最佳实践
目录
image.png应该怎样去拆分服务呢？
基本原则：
- 低耦合，高内聚。单一原则：一个服务只负责一件事情，可以独立部署。
- 最小知识原则，一个组件或者是对象不应该知道其他组件或者对象的内部实现细节
- 不允许循环依赖，不允许从低层向高层依赖。不能让稳定的服务依赖一个不稳定的服务
-
根据业务发展情况不同，公司所处阶段不同，服务拆分的粒度也不相同。粒度越小，维护成本越大。
image.png
常见的拆分方法
- 根据业务进行建模，依据业务领域的边界划分，这也是当前微服务社区十分推崇的领域驱动设计（Domain Driven Design，简称DDD）方法；清楚各个服务的职责边界是什么，比如：购物车、订单管理、单品页、实时库存等等；最常使用的方式。
- 按照系统功能划分，比如：接入子系统、消息推送子系统、客户端监控管理子系统等等
- 根据资源使用类型划分，这种方式主要使用在对硬件资源需求很高、或对特定硬件类型存在依赖的大型服务系统，例如系统的某些功能非常消耗CPU。此时可以依据对不同资源的需求作为边界进行的划分，以最大化运行效率
-
根据边界划分，直接从数据表结构活数据源着手，依据数据归属关系界定服务。这种划分方法简单粗暴
image.png
服务划分的最佳实践-不要从数据库开始建模
- 传统软件开发中，数据模型被认为是整个系统的核心，架构评审会花很多时间来讨论系统庞大的ER图（实体关系图）设计
- 微服务架构设计时，服务划分时采用ER图进行建模甚至是十分有害的。
危害
- ER图设计时使用的是关系型说的数据库，设计出来的表结构冗余度很低，且使用非常灵活，但正是这种灵活性往往导致系统中多个业务逻辑表出现错综缠绕的关系，从而使剥离单独服务进行异构设计变得困难；
-
ER图还会导致实体相似的不同业务逻辑在设计时被耦合在一起
image.png -
ER图设计时假定？
image.png
服务划分的最佳实践-推荐使用领域建模
image.png服务划分的最佳实践-端到端的划分服务
image.png服务划分的最佳实践-识别核心业务服务
image.png微服务的设计模式
image.png微服务的设计模式-服务代理模式
用途：灰度发布、ABtest、新老切换
image.png
微服务的设计模式-服务聚合模式（最常用）
image.png-
优点
image.png -
应用案例
image.png
微服务的设计模式-服务串联模式
image.png-
优点
image.png -
案例
image.png
微服务的设计模式-服务分支模式
-
应用案例
image.png
微服务的设计模式-服务异步消息模式
image.png-
应用案例
image.png
微服务的设计模式-服务共享数据模式
其实是反模式
image.png
- 应用场景
image.png
image.png
除了上面提到的两个场景，任何场景都不能使用服务数据共享模式
如果系统大量存在共享模式，那就说明需要进行数据治理了。
微服务的隔离容错
舱壁隔离模式
image.png线程隔离
image.png-
业务线程之间的隔离
image.png
降级
比如系统推荐功能，随着系统性能吃紧，就要降低相关体验
千人千面-->千人百面-->千人十面-->停用服务
image.png
限流
最外层限流效果最好，但不好管理控制，越内层越好控制，需要人工参与
Nginx+lua
image.png
熔断
不需要人工参与，自动实现。直接引入Hystrix（晚上详细讲解）实现熔断，但缺乏可视化功能及通知报警灯。比如系统可用性低于99.9%自动熔断，设置时间窗口默认5s后自动重试，判断是否需要自动恢复。
熔断自动化的东西，用不好的话会不好判断问题，如果流量不大的话，有人为降级的时间的情况，可以考虑不使用。
image.png
快速失败-链路中的超时
默认超时时间是180s，比较慢，需要自行设置。最重要的超时是网络相关的超时。
image.png
动态更改，实时生效。经验值，比如正常时间是5ms，则可配置5-10倍，如50ms，需要不断调整尝试。
image.png
微服务架构中职能团队的划分
image.png推荐业务性团队
image.png协作
image.png本章小结
image.png下午答疑环节：
spring cloud：ip 更新速度较慢
dubbo：tcp 国内，看9月份的发布情况
ServiceMesh：业务性弱，sidecar