架构师训练营第 10 周学习总结

单体应用的问题

编译部署困难，发布包很大

代码分支管理困难，容易冲突

数据库连接耗尽

新增业务困难

微服务框架

Web Service

注册/发现机制复杂

XML序列化效率不高

HTTP通信效率低

核心需求

服务注册与发现

负载均衡保证高并发

失效转移保证高可用

高效的远程通信保证高性能

无侵入应用接入

版本管理

Service Mesh

应用通过Sidecar调用远程服务

Sidecar 连接形成网络

微服务架构落地

业务先行，技术是手段而不是目的

先有独立的模块，后有分布式的服务

CQRS - 命令与查询职责隔离

事件溯源

断路器

服务重试 - 上游超时时间要大于下游超时时间之和

先需求，后价值、原则，再实践、工具

微服务网关

网关职能

统一接入

安全防护

协议适配

流量管控与容错

实现技术

职责链模式实现的管道技术

异步服务调用：Flower / Servlet3

开放平台网关：OAuth

领域驱动设计DDD

事务脚本模型

Service/Dao对象只有方法，没有数值成员变量

传递的业务对象没有方法，属于POCO对象

贫血模型

领域模型

业务对象即包含数据，也有方法

充血模型

战略设计

拆分子域

限界上下文

上下文映射图

战术设计

实体设计

值对象 - 不变性

聚合

分层架构

六边形架构

组件设计原则

组件内聚原则

服用发布等同原则

｜ 以复用的粒度来进行发布

共同封闭原则

｜ 同时修改的类放到同一个组件中

共同复用原则

｜ 互相依赖、共同复用的类放到一个组件中

组件耦合原则

无循环依赖原则

｜ 组件依赖关系不应该出现环

稳定依赖原则

｜ 组件依赖关系必须指向更稳定的方向

稳定抽象原则

｜ 组件的抽象化程度应该与其稳定性程度一致

案例：用领域驱动设计驱动系统重构

微服务架构的关键是设计服务的职责与依赖关系

低复杂度项目用CRUD开发成本更低，高复杂度项目DDD更有优势

用限界上下文识别微服务的功能、边界和依赖关系（带泳道的活动图、康威定理）