架构师训练营 week10 学习笔记

• 微服务：服务本身的设计、维护以及治理

Service Mesh 服务网格

Service Mesh 是一个基础设施层，用于处理服务间的通信，通常表现为一组轻量级网络代理，他们与应用程序部署在一起，而对应用程序透明。

Service Mesh 的 Sidecar 模式

• 微服务：落地实践的策略与思路

命令与查询职责隔离（CQRS）

在服务接口层面将查询（读操作）与命令（写操作）隔离，实现服务层的读写分离。

• 更清晰的领域模型

• 针对读写分别优化，实现更好的性能

• 查询服务不会修改数据，更好地保护数据

事件溯源

将用户请求处理过程中的每次状态变化都记录到事件日志中，并按时间序列进行持久化存储。

断路器

服务重试及调用超时

最重要的是需求

• 微服务网关的技术架构

开放平台网关

• API 接口:是开放平台暴露给合作者使用的一组 API，其形式可以是 RESTful、 WebService、RPC 等各种形式

• 协议转换:将各种 API 输入转换成内部服务可以识别的形式，并将内部服务的返回 封装成 API 的格式。

• 安全:除了一般应用需要的身份识别、权限控制等安全手段，开放平台还需要分级 的访问带宽限制，保证平台资源被第三方应用公平合理使用，也保护网站内部服务不会 被外部

应用拖垮。

• 审计:记录第三方应用的访问情况，并进行监控、计费等。

• 路由:将开放平台的各种访问路由映射到具体的内部服务。

• 流程:将一组离散的服务组织成一个上下文相关的新服务，隐藏服务细节，提供统 一接口供开发者调用。

开放授权协议 OAuth2.0

• 领域驱动设计 DDD

贫血模型 VS 充血模型

由于事务脚本模式中，Service、Dao 这些对象只有方法，没有数值成员变量，而方法调用时传递的数值对象，比如 Contract，没有方法（或者只有一些 getter、setter 方法），

因此事务脚本又被称作贫血模型。

领域模型的对象则包含了对象的数据和计算逻辑，比如合同对象，既包含合同数据，也包含合同相关的计算。因此从面向对象的角度看，领域模型才是真正的面向对象。 收入

确认是和合同强相关的，是合同对象的一个职责，那么合同对象就应该提供一个 calculateRecognition 方法计算收入。

领域模型是合并了行为和数据的领域的对象模型。通过领域模型对象的交互完成业务逻辑的实现，也就是说，设计好了领域模型对象，也就设计好了业务逻辑实现。和事务脚

本被称作贫血模型相对应的，领域模型也被称为充血模型。

DDD 战略设计与战术设计

领域、子域、界限上下文、上下文映射图，这些是 DDD 的战略设计。

实体、值对象、聚合、CQRS、事件溯源，这些是 DDD 战术设计。

通过战略设计，划分模块和服务的边界及依赖关系，对微服务架构的设计至关重要。

• 软件组件设计原则

组件内聚原则

组件内聚原则主要讨论哪些类应该聚合在同一个组件中，以便组件既能提供相对完整的功能，又不至于太过庞大。

复用发布等同原则

共同封闭原则

共同复用原则

组件耦合原则

无循环依赖原则

稳定依赖原则

稳定抽象原则

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