重点摘要
1. 微服务：小型、自治的服务协同工作
微服务是小型、自治的服务，它们协同工作。
微服务的基础。 微服务架构基于将软件开发为一组小型、独立服务的原则。每个服务专注于做好一件事，运行在自己的进程中，并通过轻量级机制如HTTP/REST API进行通信。与单体架构相比，这种方法允许更大的灵活性、可扩展性和可维护性。
优点和挑战。 微服务的主要优点包括：
- 改善模块化
- 更容易扩展单个组件
- 技术多样性
- 增强故障隔离
- 更快的部署周期
然而，微服务也带来了挑战，如：
- 增加的操作复杂性
- 分布式系统问题（如网络延迟、容错）
- 服务间的数据一致性
2. 进化架构：适应不断变化的需求
架构师的角色是看大局，并理解这种平衡。
拥抱变化。 进化架构强调系统需要随着时间的推移适应不断变化的需求。这种方法认识到不可能预测所有未来的需求，因此专注于创建一个可以演变的灵活基础。
关键原则：
- 渐进式变化：进行小而频繁的更新，而不是大而不频繁的更新
- 指导性变化：使用原则和实践来指导架构决策
- 多种架构：认识到系统的不同部分可能以不同的速度演变
在这种模型中，架构师更像是城市规划者，设定指导方针和约束，而不是规定每一个细节。这允许团队在确保整体系统一致性的同时做出本地决策。
3. 建模服务：定义边界和上下文
我们将服务边界集中在业务边界上，使得代码所在的位置对于特定功能来说是显而易见的。
领域驱动设计。 有效地建模服务需要对业务领域有深刻的理解。领域驱动设计（DDD）提供了定义服务边界的有价值概念：
- 有界上下文：具有明确边界的领域区域
- 普遍语言：开发人员和领域专家共享的通用语言
- 聚合：作为一个单元处理的领域对象集群
识别服务边界：
- 与业务能力对齐
- 封装数据和行为
- 最小化服务之间的依赖
- 考虑团队结构和沟通模式
定义良好的边界导致更具凝聚力的服务和更松散的耦合，促进独立开发和部署。
4. 集成策略：选择合适的通信方式
保守地做你该做的事，宽容地接受他人所做的事。
集成的重要性。 有效的集成对于微服务无缝协作至关重要。集成技术的选择显著影响系统的灵活性、性能和可维护性。
关键集成模式：
- 同步通信：REST，gRPC
- 异步通信：消息队列，事件流
- API网关：用于请求路由和组合
- 服务网格：用于处理服务间通信
最佳实践：
- 使用与技术无关的协议（如HTTP）
- 实施容错读者以优雅地处理变化
- 设计故障处理机制，如断路器和隔板
- 考虑事件驱动架构以实现松散耦合
合适的集成策略取决于具体的用例、性能要求和团队专业知识。
5. 拆分单体：向微服务过渡
将我们的单体视为一块大理石。我们可以将其炸毁，但这很少有好结果。更明智的做法是逐步削减它。
渐进式方法。 从单体架构向微服务过渡最好逐步进行。这允许团队在最小化风险的同时学习和适应。
拆分单体的步骤：
- 识别现有代码库中的接缝
- 将有界上下文提取到单独的模块中
- 重构共享数据结构和数据库
- 创建用于模块间通信的API
- 将模块提取为单独的服务
- 将新功能实现为微服务
需要考虑的挑战：
- 服务间的数据依赖
- 跨服务边界的事务完整性
- 网络通信的性能影响
- 管理多个服务的操作复杂性
从最简单、风险最小的提取开始，建立信心和经验，然后再处理系统中更复杂的部分。
6. 部署技术：确保可靠性和可扩展性
如果做某事是正确的但很困难，我们应该努力使事情变得更容易。
自动化部署。 可靠和可扩展的部署对于微服务的成功至关重要。持续集成和持续交付（CI/CD）实践对于管理增加的部署复杂性至关重要。
关键部署技术：
- 基础设施即代码（IaC）
- 容器化（如Docker）
- 编排平台（如Kubernetes）
- 蓝绿部署
- 金丝雀发布
部署考虑：
- 服务发现和配置管理
- 监控和日志记录
- 安全性和访问控制
- 数据库迁移和数据一致性
投资于工具和自动化，使部署更容易、更快、更可靠。这使团队能够自信地频繁部署，实现微服务架构的全部优势。
7. 测试微服务：在分布式系统中保持质量
移动部件越多，我们的测试可能越脆弱，确定性越低。
全面的测试策略。 测试微服务需要多层次的方法，以确保单个服务的质量和整体系统行为。
微服务的测试金字塔：
- 单元测试：快速、集中的组件测试
- 集成测试：验证服务之间的交互
- 合同测试：确保服务符合约定的接口
- 端到端测试：验证整个系统的行为
测试挑战：
- 由于分布式特性而增加的复杂性
- 管理跨服务的测试数据
- 模拟生产环境
- 处理异步交互
强调通过单元和集成测试实现快速反馈循环，同时使用较少、精心选择的端到端测试来验证关键路径。考虑使用消费者驱动的合同来有效管理服务依赖。
8. 监控和安全：保持微服务的健康和保护
良好的日志记录，特别是从多个系统聚合日志的能力，不是为了预防，而是有助于检测和恢复不良事件。
整体方法。 有效的监控和安全对于维护健康的微服务生态系统至关重要。在分布式系统中，这些方面变得更加具有挑战性和重要性。
监控最佳实践：
- 集中日志记录和日志聚合
- 分布式追踪（如使用关联ID）
- 实时警报和仪表板
- 应用性能监控（APM）
- 对关键路径进行合成监控
安全考虑：
- 服务间的身份验证和授权
- 用于边缘安全的API网关
- 秘密管理
- 网络分段
- 定期安全审计和渗透测试
实施纵深防御策略，保护外围和各个服务。使用自动化确保在所有服务中一致应用安全策略。
9. 康威定律：对齐组织和系统设计
康威定律强调了试图强制执行与组织不匹配的系统设计的危险。
组织影响。 康威定律指出，系统设计反映了组织内的沟通结构。这一原则对微服务架构有重要影响。
对齐团队和服务：
- 围绕业务能力组织团队
- 赋予团队对服务的端到端所有权
- 最小化跨团队依赖
- 培养协作和共同责任的文化
考虑事项：
- 团队规模和组成
- 沟通模式和工具
- 决策过程
- 技能发展和知识共享
认识到组织结构和系统架构是相互关联的。同步演变两者，以创建有利于成功的微服务开发和运营的环境。
10. 扩展微服务：处理增长和故障
在规模上，即使你购买最好的设备，最昂贵的硬件，你也无法避免事情会失败的事实。
为扩展和弹性设计。 微服务架构必须设计为能够优雅地处理需求增长和不可避免的故障。
扩展策略：
- 水平扩展（增加更多实例）
- 垂直扩展（增加每个实例的资源）
- 缓存（内存中，分布式）
- 数据库分片和复制
- 异步处理和事件驱动架构
弹性模式：
- 断路器以防止级联故障
- 隔板用于故障隔离
- 带指数退避的超时和重试
- 功能的优雅降级
CAP定理考虑：
- 一致性
- 可用性
- 分区容忍
理解在扩展分布式系统时需要权衡。根据具体需求和约束进行优先排序。实施可观察性和混沌工程实践，以持续改进系统弹性。
Last updated:
评论
《构建微服务》获得了褒贬不一的评价，许多人称赞其对微服务概念的全面概述和实用建议。读者欣赏作者谨慎的态度和真实的案例。批评者指出该书在某些主题上缺乏深度，并有可能过度推销微服务。许多人认为这本书对初学者很有价值，但对有经验的架构师来说用处不大。该书涵盖了微服务的各个方面，包括设计、部署、测试和扩展。一些读者希望能有更多具体的实现细节，而另一些人则重视其对软件架构的高层次视角。