最近对公司内部进行了微服务开发的系列培训课程，本文是微服务开发相关，后续还有微服务治理等系列分享培训。

1. 个人介绍

  • 刘晋勋，曾在华为、阿里云、字节跳动担任多年技术架构师和技术团队TL，阿里云技术最佳实践、阿里云CADT作者
  • 开源爱好者，Kubernetes和lstio贡献者，多年关注云原生、软件架构与开发、云基础架构、Al
  • GitHub: https://github.com/mingyu110
  • 个人公众号：公共云与AI

2. 微服务架构的优劣势

微服务架构作为系统设计的四大支柱之一（Scalability)，在近年的技术架构设计里得到了越来越多的应用

2.1 “两个披萨"团队法则

亚马逊CEO杰夫·贝索斯提出的"两个披萨团队”(Two PizzaTeam)法则：团队规模应小到两个披萨能够喂饱，通常为6-8人。该法则与微服务架构高度契合：

  • 小团队提高沟通效率，减少协调成本
  • 团队规模对应服务粒度：每个"两个披萨团队"(6-8人)通常负责一个或少数几个微服务
  • 增强团队自主性和对服务的端到端责任感
  • 允许团队专注于单一业务能力或服务
  • 促进快速决策和迭代
  • 支持敏捷开发和DevOps文化
  • 康威定律体现：系统设计反映组织通信结构，小团队自然产生边界清晰的微服务
  • 团队边界应与服务边界一致：避免一个服务由多个团队维护，除了共享服务（基础设施团队或者平台团队可以负责多个共享服务）

2.2 微服务架构的优势

  • 技术异构性：可使用不同技术栈构建不同服务
  • 弹性：单个服务故障不会导致整个系统崩溃
  • 可扩展性：可按需独立扩展各服务而非整体应用
  • 易于部署：支持独立部署，降低整体风险
  • 组织对齐：团队可围绕业务能力组织，而非技术层次
  • 可组合性：服务可灵活组合构建新功能
  • 可替代性：服务可独立替换或重写，减少大规模重构
  • 独立演进：各服务可按不同速度和方向发展

2.3 微服务架构的劣势

  • 分布式系统复杂性：引入网络延迟、分区容错等挑战
  • 运维成本高：需管理更多服务、监控和基础设施
  • 服务间通信成本：增加网络开销和故障点
  • 跨服务事务难：分布式事务实现复杂
  • 测试复杂度增加：集成测试和端到端测试变得困难
  • 数据一致性挑战：多数据库环境下保持一致性困难
  • 服务治理难度大：需要更完善的服务发现、配置管理等

2.4 单体应用拆分为微服务架构应用的示范和理念

2.4.1 拆分示范

2.4.2 单一代码仓库模式

  • 谷歌、Facebook和微软等科技巨头在管理数百个微服务时都采用monorepo（单一代码仓库）模式，证明了即使在非常大规模的微服务架构下，monorepo依然可行且高效。Monorepo不会消除微服务间的边界，而是提供一个更高效的协作环境，使微服务开发更加顺畅和一致。解决微服务特有问题：

    • 依赖管理: 简化服务间共享代码的版本控制和依赖传播
    • 重构友好：跨服务API变更可同步进行，消除多仓库协调开销
    • 开发体验：简化本地开发环境设置，一次克隆可访问所有服务
    • 知识共享：促进团队间代码复用和最佳实践传播

  • Monorepo（单一代码仓库）架构示范

2.4.3 数据库拆分模式

  • 微服务拆分的前提理念除了上述的单一代码仓库，数据库拆分模式也需要架构师提前根据不同的维度考虑选择，如下是微服务数据库拆分模式方案示意图以及选型考量表

2.4.4 API-First设计理念

  • API-First的原则
    • 以API设计作为基础：在API优先的方法中，API是整个应用构建的基础。这需要精心规划和设计，以确保API满足所有利益相关者的需求，包括但不限于开发者、测试、合作伙伴和最终用户。

  • 一致性与可重用性：API设计为在不同项目和应用中具有一致性和可重用性。这使得标准化变得简单,减少了开发时间，提升了解决方案的可扩展性。

  • 协作与文档：API优先的方法强调开发团队、业务利益相关者和外部合作伙伴之间的协作。全面的文档对于确保每个人了解如何有效使用API至关重要。

  • 测试驱动开发：从一开始就对API进行严格的测试，以便在开发过程中尽早识别和解决问题。这有助于保持高质量标准，并降低后期出现昂贵错误的风险。

  • API-First的收益

    • 提供更好的开发体验：设计完善的API和详尽的文档，使开发者更容易理解和实现，降低沟通成本。
    • 提升开发协作的效率：可以先通过API接口描述以及API Mock能力进行快速开发协同，测试可以提前准备测试用例，同时前端也可以基于API接口以及Mock数据完成页面的开发，此时后端的业务接口可以同步进行开发。另外，不同的微服务开发团队之间可以基于API展开工作，多个开发团队可以并行工作在应用的不同组件上，显著加速整个开发流程。

3. 不同的微服务架构及应用场景

3.1 微服务架构应用系统的基础模块

3.2 不同的微服务架构及其应用场景

3.2.1 GATEWAY PATTERN

3.2.2 SERVICE REGISTRY PATTERN

3.2.6 BULKHEAD PATTERN

3.2.8 API COMPOSITION PATTERN

3.2.9 EVENT-DRIVEN ARCHITECTURE PATTERN

3.2.10 RETRY PATTERN

3.2.11 CONFIGURATION EXTERNALIZATION PATTERN

3.2.12 STRANGLER FIG PATTERN

3.2.13 LEADER ELECTION PATTERN

3.3 模式组合应用建议

原则：这些微服务设计模式不应孤立使用，而是根据具体业务场景和技术环境组合应用，构建健壮、可扩展、易维护的微服务架构。

  1. 基础设施层面组合:

    • Gateway Pattern + Service Registry + Circuit Breaker 形成强大的服务网关层
    • Sidecar Pattern + Configuration Externalization 实现基础设施与业务解耦

  2. 数据管理组合:

    • Database Per Service + CQRS+ Event-Driven Architecture 构建高性能数据架构
    • Saga Pattern + Retry Pattern 处理分布式事务

  3. 系统弹性组合:

    • Circuit Breaker + Bulkhead + Retry 提供多层次故障保护
    • Leader Election + Bulkhead 实现高可用协调服务

  4. 系统演进组合:

    • Strangler Fig + API Composition 支持渐进式系统更新
    • Event-Driven + Saga 支持业务流程演进

4. 领域驱动设计（DDD）

4.1 DDD核心要素

领域驱动设计(Domain-Driven Design)是一种通过将实现与持续进化的领域模型相连接来满足复杂需求的软件开发方法。DDD关注点包括：

  1. 领域(Domain): 业务问题空间，如电商领域包含订单管理、库存、支付等业务功能集合
  2. 通用语言(Ubiquitous Language): 开发人员和领域专家共同使用的语言，减少沟通成本

4.2 领域模型的组成部分

DDD领域层通常由以下部分组成：

  • 实体(Entity): 具有唯一标识的对象(如Order, Customer)
  • 值对象(Value Object): 无唯一标识，通过属性值定义的对象(如Address, Money)
  • 聚合(Aggregate): 实体和值对象的集合，通过聚合根访问
  • 聚合根(Aggregate Root): 聚合的入口点，负责维护聚合内一致性
  • 领域服务(Domain Service): 处理跨多个聚合的业务逻辑
  • 领域事件(Domain Event): 领域内发生的事件，有助于解耦和事件驱动设计

4.3 DDD与领域架构师协作的必要性

DDD需要架构师和软件架构师共同参与的原因包括：

  1. 跨领域知识整合

    • 业务架构师提供业务领域知识和战略层面设计，软件架构师提供技术实现和战术层面设计

  2. 界限上下文的确定

    • 领域边界定义需要业务理解和技术考量相结合
    • 界限上下文影响系统解耦和团队组织

  3. 通用语言的建立

    • 软件架构师充当业务与技术团队的桥梁
    • 确保领域语言在各层次一致使用

  4. 技术与业务的平衡

    • 确保技术实现不牺牲业务需求
    • 确保业务模型考虑技术约束

  5. 战略设计与战术设计的结合

    • 战略设计(领域、界限上下文、上下文映射)需要领域架构师参与
    • 战术设计(实体、值对象、聚合等)需要软件架构师参与

4.4 Clean Architecture与DDD的结合

Clean Architecture提倡依赖倒置原则，将系统分为四个层次：

  1. 实体层(Entities): 业务规则和数据结构
  2. 用例层(Use Cases): 应用程序特定业务规则
  3. 接口适配层(Interface Adapters): 转换数据格式，连接外部系统
  4. 框架与驱动层(Frameworks & Drivers): 外部框架如数据库、Web框架等

结合DDD，可以将DDD的领域模型放在Clean Architecture的核心层，实现业务逻辑与技术实现的分离。

DDD 与 Clean Architecture 结合的优势:

  1. 关注点分离：每层都有明确职责，减少耦合
  2. 业务逻辑集中：核心业务逻辑不受外部技术影响
  3. 可测试性：业务逻辑可独立测试，不依赖基础设施
  4. 灵活性：外层可以替换而不影响核心业务逻辑
  5. 模型一致性：确保领域模型在整个应用中一致使用

这种结合为复杂业务领域提供了清晰的架构结构，既保持了业务逻辑的纯粹性，又提供了与外部系统交互的灵活机制。

5. 优秀实践介绍

一些优秀的开源项目，例如Dify；优秀的开源项目是学习微服务架构的最好帮助;

Dify采用了多种微服务架构模式：

  1. 微服务架构：将不同功能模块划分为相对独立的服务
  2. BFF模式（Backend For Frontend）：专为前端优化的API设计（多端适配)
  3. 分层架构：清晰的API层、应用服务层、领域服务层和数据访问层
  4. API网关模式：统一入口处理认证、路由和请求处理

6. 微服务治理概述

  • SDK模式
  • Agent模式
  • 服务网格模式