学习总结 -- Week 10

为什么需要微服务

传统的单体式服务（Monolith）部署，随着服务接口规模不断增大，接口之间调用日趋复杂，单体式服务的部署和维护变得越来越不可持续。为了化解由单体式部署带来的痛点，微服务（Microservice）应运而生。相较单体式服务，微服务将服务分解成许多可以独立部署的微型服务，使得每个服务都可以独立开发和发布，从而使得单个服务的改进不会影响整体。

微服务是一种分布式服务，因此微服务的部署需要满足以下要求：

1. 失效转移（Failover）

2. 负载均衡

3. 高效的远程通信

4. 支持渐进式部署

5. 版本管理

如何实现微服务

在决定实施微服务之前，应当先搞清楚“我们真的需要微服务吗？”不要为了应用微服务而实施微服务。始终要把业务价值作为首要考量因素，其次要明确业务模块，以及模块的边界。一个成功的微服务架构应当包含：

• 命令与查询职责隔离（CQRS）：在服务接口层进行读写隔离，

• 事件溯源：将用户请求的每次状态变化都记录到日志中，可以更精确地复现用户状态，并有利于实施分布式事物。

• 断路器：当服务出现故障时，使用断路器将故障服务从服务网络中隔离

• 微服务网关：统一的服务入口，不包含业务处理逻辑，只过滤和转发请求

• 可靠的安全验证：必须实现统一，可靠的安全验证模块来保证每个微服务的安全。例如OAuth2.

领域驱动设计（DDD）

微服务架构设计中，很重要的一点是要明确业务模块及其边界。DDD正是将系统模块按照领域（业务模块）划分的一种系统设计模式。DDD的要点在领域划分，这同时也是DDD实践中的难点。

DDD的一些要点：

• 充血模型：不同于POJO，DDD提倡将业务行为（方法）与数据模型一起放入领域模型中。

• 子域：在现实案例中，一个“领域”通常过于庞大和复杂。为了降低实现难度，通常将领域划分成多个子域。

• 界限上下文：每一个子域都包含一个概念上的领域边界，在这个边界中，任何领域对象都只表示特定于该边界内部的含义。因此边界被成为界限上下文。通常，界限上下文对应一个组件或者模块，或者一个微服务。

• 上下文映射图：DDD使用上下文映射图来表示各个模块（即界限上下文）之间的交互关系。

• 实体：领域模型对象也被称为实体。每个实体都是唯一的，有唯一标识。实体是DDD的核心所在，在设计实体时要明确实体的逻辑，设计合适的属性和方法。

• 值对象：DDD中，仅仅用来描述和度量实体的对象称为值对象。例如，房子可以是一个实体，但是地址则应当是一个描述房子的值对象。值对象的特点是不可改变，一旦创建，就不会再变化。

• 聚合：聚合是一个关联对象的集合，用来作为一个处理数据更改的单元。每个集合都包含一个根和一个边界。边界定义了聚合的内容，根则是将多个实体和值对象聚合在一起的实体。



DDD的战略设计与战术设计：

领域，子域，界限上下文，上下文映射图，这些事DDD的战略设计。实体，值对象，聚合，CQRS，事件溯源，这些事DDD的战术设计。通过战略设计，划分模块和服务的边界及依赖关系，对实现微服务架构设计至关重要。



组件设计原则

“软件的复杂度和它的规模成指数关系”

1. 组件内聚原则：关注哪些类应该包含在组件中，使得组件能提供完整功能，又不至于太过庞大。

a. 复用发布等同原则：软件复用的最小粒度应该等于发布的最小粒度。

b. 共同封闭原则：为了相同目的而同时需要修改的类应该放在一个组件中。

c. 共同复用原则：不要强迫组件的使用者依赖他们不需要的类。

1. 组件耦合原则：关注组件之间的耦合关系

a. 无循环依赖原则：组件之间不应该循环依赖。

b. 稳定依赖原则：不稳定的组件应该依赖稳定的组件，而不是相反。

c. 稳定抽象原则：一个稳定的组件应该是抽象的。



组件的边界与依赖关系，不仅仅是技术问题。应该综合考虑业务甚至人（使用者）的因素来设计组件。