第十周学习总结

微服务

可能会让项目更烂，为什么?



单体程序的问题：

1. 项目太大，编译部署困难

2. 项目参与人员多，代码分支管理困难

3. 业务处理过程复杂，导致长时间占用数据库连接，数据库链接耗尽

4. 业务太庞杂，牵一发动全局，新增业务困难

解决方案是拆分：纵向按业务拆成不同web应用，横向拆分出复用部分



Webservice过于复杂，xml数据冗余过高序列化低效



微服务框架要解决的问题：

失效转移，让每个微服务实现高可用

对于集群部署的服务使用负载均衡（比如加权轮训）

高效的远程通信

对应用最少侵入，远程调用和本地调用对现有代码无感知。

服务版本管理，接口改变，怎样做到调用者与接口同时升级（无法做到）或者对接口进行版本管理，旧版本会存在一段时间支持调用。



Service Mesh



微服务落地：微服务的关键点不在技术，在业务。

1. 业务先行，理顺业务边界和依赖（最重要）

2. 现有独立模块，后又分布式的服务



CQRS

事件溯源

断路器

服务调用重试和超时

needs-> values-> principles-> practices-> tools



拆分业务：先大后小

------------------------------------------

领域模型



DDD

为什么：

1. 需求零散、不断变更

2. 实现功能的代码放置的位置很随意

3. 软件的功能模块没有真正设计

4. 功能特性不是按照领域的内在逻辑设计

遥控器的设计



贫血模型(事务脚本)vs充血模型（领域模型）

DDD是实现充血模型的一个方式，如果设计时就可以实现领域模型，就没必要使用DDD了

战略设计：领域 -> 子域(低耦合、内聚性。子域往往就是微服务中的一个服务) -> 界限上下文（上下文映射图）

战术设计：实体，值对象（不改变，如果改变实际就成了一个新对象），聚合（关联的对象集合），DDD分层架构（三层，六边形）



DDD重构：

1. 使用方真正的需求或目的

2. 统一语言，领域通用词

3. 业务梳理

依赖倒置将提供API导致的不规范的被调用过程，变成了使用核心领域调用其他子领域的规范化框架。这是核心领域角色的转变。