微服务架构设计模式-第一章

microservices patterns with examples in java

微服务架构设计模式

[美]克里斯·理查森（chris richardson）著 喻勇 译

2019.6 第一版第 3 次印刷

ISBN：9787 1116 24127

---

第一，要记住微服务不是解决所有问题的万能“银弹”。

第二，编写整洁的代码和使用自动化测试至关重要，因为这是现代软件开发的基础。

第三，关注微服务的本质，即服务的分解和定义，而不是技术，如容器和其他工具。

第四，确保你的服务松耦合，并且可以独立开发、测试和部署，不要搞成分布式单体，那将会是巨大的灾难。

第五，也是最重要的，不能只是在技术上采用微服务架构。拥抱DevOps的原则和实践，在组织结构上实现跨职能的自治团队，这必不可少。

最后还必须记住：实现微服务架构并不是你的目标。你的目标是加速大型复杂应用程序的开发。

第1章 逃离单体地狱

1.1 迈向单体地狱的漫长旅程

FTGO的核心业务其实非常简单：消费者使用FTGO的网站或移动应用，在本地的餐馆下订单；FTGO会协调一个由送餐员组成的快递网络，来完成订单食品的运送。显然，给送餐员和餐馆支付费用，也是FTGO的重要任务之一。餐馆则使用FTGO的网站编辑菜单并管理订单。

这套应用程序使用了多个Web服务，例如使用Stripe管理支付、使用Twilio实现消息传递、使用Amazon SES发送电子邮件，等等。

与其他陈旧的企业应用程序一样，FTGO的应用程序是一个单体，它由一个单一的Java WAR文件构成。随着时间的推移，这个文件变成了一个庞大而复杂的应用程序。

尽管FTGO开发团队做出了最大的努力，但这个应用程序已成为“泥球模式”的一个典型例子。泥球模式的作者Brian Foote和Joseph Yoder把这样的软件比喻为“随意架构的、庞大的、草率的、布满了胶带和线路，如同意大利面条一般的代码丛林”。

软件交付的步伐已经放缓。更糟糕的是，FTGO应用程序是使用一些日益过时的框架编写的。FTGO应用程序展示了单体地狱的几乎所有症状。

1.1.1 FTGO应用程序的架构

1.1.2 单体架构的好处

• 应用开发简单
• 易于对应用程序进行大规模的更改
• 测试相对简单直观
• 部署简单明了
• 横向扩展不费吹灰之力

1.1.3 什么是单体地狱

• 过度的复杂性会吓退开发者，任何一个开发者都很难理解他的全部。因此，修复软件中的问题和正确地实现新功能就变得困难且耗时。
• 开发速度缓慢
• 从代码提交到实际部署的周期很长，而且容易出问题
• 难以扩展
• 交付可靠的单体应用是一项挑战
• 需要长期依赖某个可能已经过时的技术栈

1.2 为什么本书与你有关

略

1.3 你会在本书中学到什么

• 微服务架构的基本特点，它的好处与弊端，以及应该在什么情况下使用微服务架构
• 分布式数据管理的架构模式
• 针对微服务架构应用程序的有效测试策略
• 微服务架构应用程序的部署方式
• 把单体应用重构为微服务架构的策略
• 使用微服务的架构模式来设计应用程序的架构
• 为服务开发业务逻辑
• 使用 sage 在进程间维护数据的一致性
• 实现跨服务的数据查询
• 更高效地测试微服务架构应用程序
• 开发生产环境就绪的应用程序，实现安全性、可配置性和可观测性
• 把现有的单体应用重构为服务

1.4 拯救之道：微服务架构

有趣的是，软甲架构其实对功能性需求影响并不大。架构的重要性在于它影响了应用的非功能性需求，也称为质量属性或其他能力。

1.4.1 扩展立方体和服务

martin abbott 和 michael fisher 的名著《the art of scalability》

三维可扩展模型：扩展立方体

• X 轴：水平复制，通过克隆实例的方式扩展，在多个相同实例之间实现请求的负载均衡（负载均衡器）
• Y 轴：功能性分解，通过分解不同功能的方式来实现扩展
• Z 轴：数据分区，通过类似客户 ID 的方式，把相似的数据分区进行扩展。根据请求的属性路由请求

微服务架构的概括性定义：把应用程序功能性分解为一组服务的架构风格。重要的是，每一个服务都是由一组专注的、内聚的功能职责组成。

1.4.2 微服务架构作为模块化的一种形式

在单体应用中，模块通常由一组编程语言所提供的结构（例如 Java 的包），或者 Java JAR 文件这样的构建制品（artifact）来定义。

微服务架构使用服务作为模块化的单元。服务的 API 为它自身构筑了一个不可逾越的边界，你无法越过 API 去访问服务内部的类。

1.4.3 每个服务都拥有自己的数据库

1.4.4 FTGO的微服务架构

1.4.5 微服务架构与SOA的异同

	SOA	微服务
服务间通信	智能管道，例如 Enterprise Service Bus（ESB），往往采用重量级协议，例如 SOAP 或其他 WS* 标准	使用哑管道，例如消息代理，或者服务之间点对点通信，使用例如 REST 或 gRPC类的轻量级协议
数据管理	全局数据模型并共享数据库	每个服务都有自己的数据模型和数据库
典型服务的规模	较大的单体应用	较小的服务

SOA 和微服务架构之间的另一个重要区别，就是服务的尺寸（规模）。SOA 善于集成大型、复杂的单体应用程序。微服务架构的服务虽然不是必须要做到很小，但是通常都比较小。

1.5 微服务架构的好处和弊端

1.5.1 微服务架构的好处

• 使大型的复杂应用程序可以持续交付和持续部署
  • 拥有持续交付和持续部署所需要的可测试性。自动化测试
  • 拥有持续交付和持续部署所需要的可部署性，每个服务都可以独立于其他服务进行部署
  • 使开发团队能够自主且松耦合
• 每个服务都相对较小且容易维护
  • 不会把 IDEA 等开发工具拖慢
  • 服务的启动速度也比大型的单体应用快很多
• 服务可以独立部署
• 服务可以独立扩展
  • 每个服务可以部署在适合他们需求的硬件之上（有些组件是 CPU 运算密集型的，有的可能需要更多的内存空间）
• 微服务架构可以实现团队的自洽
• 更容易实验和采纳新的技术
• 更好的容错性

1.5.2 微服务架构的弊端

• 服务的拆分和定义是一项挑战
• 分布式系统带来的各种复杂性，使开发、测试和部署变得更困难
  • 服务间必须使用进程间通信机制
  • 必须设计服务来处理局部故障
  • 处理远程服务不可用或出现高延迟的各种情况
  • 实现跨多个服务的用例需要使用不熟悉的技术
  • 每个服务有自己的数据库，使得实现跨服务的事务和查询成为一项挑战
  • IDE 等开发工具都是为单体应用设计的，不具备分布式应用所需要的特定功能支持
  • 编写包含多项服务的自动化测试也令人头疼
  • 开发人员必须具备先进的软件开发和交付能力才能成功使用微服务
  • 显著的运维复杂性，必须在生产环境中管理更多活动组件
  • 要成功部署微服务，需要高度自动化的基础设施，必须使用以下技术：
    • 自动化部署工具
    • 产品化的 paas 平台
    • docker 容器编排平台
• 当部署跨越多个服务的功能时需要谨慎地协调更多开发团队
  • 必须指定一个发布计划，把服务按照依赖关系排序
• 开发者需要思考到底应该在应用的什么阶段使用微服务架构
  • 在开发应用程序的第一个版本时，你通常不会遇到需要微服务架构才能解决的问题。此外，使用精心设计的分布式架构将减缓开发速度，这对初创公司来说可能是得不偿失的
  • 最大的问题通常是在快速发展业务模型和维护一个优雅的应用架构之间的取舍（微服务架构使得项目开始阶段的快速迭代变得非常困难）
  • 但是稍后，当问题变得如何处理复杂性时，那就是将应用程序功能性地分解为一组服务的时候了。由于盘根错节的依赖关系，你会发现重构很困难

1.6 微服务架构的模式语言

1.6.1 微服务架构并不是“银弹”

1.6.2 模式和模式语言

christopher alexander《a pattern language: Towns,Buildings,Construction》

常用的模式结构包括三个重要部分：

• 需求（forces）
• 结果上下文（resulting context）
• 相关模式（related patterns）

需求：必须解决的问题

需求部分描述了必须解决的问题和围绕这个问题的特定上下文环境。需求有时候是互相冲突的，所以不能指望把它们全部都解决（必须取舍）。按优先级排序。

结果上下文：采用模式后可能带来的后果

• 好处：这个模式的好处和他解决了什么需求
• 弊端：这个模式的弊端和它没有解决哪些需求
• 问题：使用这个模式所引入的新问题

相关模式：5种不同类型的关系

相关模式部分描述了这个模式和其他模式之间的关系。模式之间存在5种关系：

• 前导（predecessor）：前导模式是催生这个模式的需求的模式，例如，微服务架构模式是除单体架构模式以外整个模式语言中所有模式的前导模式
• 后续（successor）：后续模式是指用来解决当前模式引入的新问题的模式，例如，如果你采纳了微服务架构模式，你需要一系列的后续模式来解决诸如服务发现、断路器等微服务带来的新问题
• 替代（alternative）：当前模式的替代模式，提供了另外的解决方案，例如，单体架构和微服务架构就是互为替代的模式，它们都是应用的架构风格，你可以选择其一
• 泛化（gereralization）：针对一个问题的一般性解决方案。
• 特化（specialization）：针对特定模式的具体解决方案

此外，你可以把解决类似问题的模式组成一组模式

1.6.3 微服务架构的模式语言概述

微服务架构的模式语言是一组模式，可帮助架构师使用微服务架构构建应用程序。

模式语言首先帮助架构师决定是否使用微服务架构。它描述了单体架构和微服务架构，以及它们的好处与弊端。然后，如果微服务架构非常适合当前的应用程序，那么模式语言可以帮助架构师通过解决各种架构和设计问题来有效地使用它。

这些模式分为三组：

• 基础设施相关模式组：这些模式解决通常实在开发环节跟基础设施有关的问题
• 应用基础设施相关模式组：这些模式解决应用层面的基础设施相关问题
• 应用相关模式组：这些模式解决开发人员面对的具体技术和架构问题

1.7 微服务之上: 流程和组织

1.7.1 进行软件开发和交付的组织

略

1.7.2 进行软件开发和交付的流程

scrum或kanban

jez humble把持续交付定义为：持续交付能够以可持续的方式安全、快速地将所有类型的更改（包括新功能、配置更改、错误修复和实验）交付到生产环境或用户手中

评估软件开发的四个有用指标如下：

• 部署频率：软件部署到生产环境中的频率
• 交付时间：从开发人员提交变更到变更被部署的时间
• 平均恢复时间：从生产环境问题中恢复的时间
• 变更失败率：导致生产环境问题的变更提交百分比

1.7.3 采用微服务架构时的人为因素

《managing transitions》，人们如何对变化做出情绪化的反应。包括三个阶段：

1. 结束、失落和放弃：当人们被告知某种变化，这类变化会把他们从舒适区中拉出，这类情绪开始滋生和蔓延。人们会念叨失去之前的种种好处。例如，当被重组到一个新的跨职能团队时，人们会想念他们之前的同事。再比如，对于负责全局数据建模的团队来说，每个服务团队负责自己的数据建模，这对他们是一种威胁。

2. 中立区：处理新旧工作方式交替过程中，人们普遍会对新的工作方式无所适从。人们开始纠结并必须要学习处理新工作的方式。

3. 新的开始：最终阶段，人们开始发自内心地热情拥抱新的工作方式，并且开始体验到新工作方式所带来的种种好处。