该书作者以FTGO应用程序从单体应用逐步演进为微服务架构为例子，解释了微服务架构的设计模式和主要概念。
单体地狱
FTGO的应用程序是一个单体的，它由一个单一的JAVA WAR文件构成。随着时间的推移，应用程序变得异常复杂，且难以维护和扩展。这是一个典型泥球模式（the Big Ball of Mud Pattern， 随意架构的、庞大的、草率的、布满了胶带和线路，如同个意大利面条一般的代码丛林）。
但单体应用并非一无是处，在项目早起单体应用体相对较小：
- 开发简单
- 易于大规模更改：船小好调头
- 测试简单
- 部署简单
- 横向扩展简单：部署多个实例，一个负载均衡器进行调度
可怕的是随着时间的推移，单体应用逐渐发展为单体地狱。
过度的复杂性会吓退开发者
系统本身过于庞大和复杂，开发者需要对整个系统都有清楚的了解。对于项目中的老鸟，这没有问题。但对于新成员来说，就是噩梦。一个恶性循环随之产生，代码库难以理解，开发容易出错，hotfix的补丁又使代码库更为复杂和难懂。开发速度缓慢
项目太大，每次编辑、构建、运行、测试都变得异常艰难，严重影响团队开发效率。从代码提交到实际部署周期过长，容易出问题
多个团队使用一个repo进行开发，使用主干开发，团队成员会互相影戏；使用feature开发，又会面临代码的合并。即使合并成功，之后的测试也需要耗费极大时间和精力，一个issue的出现需要多个团队，协同排查。难以扩展
系统中各个模块对于服务器性能要求各不相同，单体应用的系统就需要满足所有模块的需求，这对服务器的性能也提出了挑战。交付可靠的单体应用是一个挑战
单体应用由于过于庞大，难以充分测试，issue将会被带到线上环境。另外，单体应用对于故障也缺乏隔离，应用中的一个模块出现故障，如内存泄漏，将会导致整个应用无法使用。长期依赖过时技术栈
必须使用同一套技术栈，任何的升级和改造，都可能引起致命的错误。
微服务架构
今天，针对大型复杂应用的开发，越来越多的共识趋向于考虑使用微服务架构。
有人把，微服务架构，定义为：面向服务的架构，它们由松耦合和具有边界上下文的元素组成。而作者受到扩展立方体的启发，则将微服务定义为：把应用程序功能性分解为一组服务的架构风格。
《The Art of Scalability》中提到了一个三位可扩展模型，扩展立方体。
X轴扩展：主要是面向单体应用程序的扩展，多个实例通过负载均衡器去分配请求，主要用于提升系统吞吐量和可用性。常见的方式：集群。
Z轴扩展：也需要实现单体应用的多个实例，但不同的是实例之间并不是相同的，每个实例只负责数据集的一个子集，路由网关通过请求的属性将请求路由到特定的实例，主要用于提升系统的吞吐量，常见方式：分库分表。例如以userId为标志，不同的用户分配到不同的实例上。
Y轴扩展：X轴扩展和Z轴扩展都可以提升系统的吞吐量，但并没有解决日益增长的开发问题和应用复杂性的问题，Y轴扩展通过拆分功能解决此类问题，主要用于降低系统耦合性，常见方式：微服务。
微服务架构的优势
- 使得大型应用可以做到持续交付和持续部署。
能够做到持续交付和持续部署，这主要是由于微服务架构的特性所致：- 可测试性：服务相对较小，方便测试
- 可部署性：每个服务都可以独立部署，
- 团队自主性和松散耦合：服务之间的隔离性使得每个团队可以独立于其他团队，开发、部署、扩展他们的服务。
持续交付和持续部署，也带来了一些业务价值：
- 所短新功能上市时间，快速获得用户反馈
- 整个系统可靠性提升
- 团队满意度提高
- 每个服务相对较小且易于维护
- 服务可以独立扩展，无论在X轴上还是Z轴上，都可以方便扩展。
- 更好的容错性，故障隔离。
- 易于使用新技术
微服务架构的劣势
- 服务拆分和定义是一项挑战
- 分布式系统更为复杂，使得开发、测试、部署都更困难
- 开发跨多个服务的功能时，需要多个团队协同开发。需要制定开发计划，按照服务依赖关系，依次开发和部署。
- 微服务架构不适用于软件开发的所有阶段。初创的系统，应该先使用单体应用，快速迭代和试错。一开始就是用微服务架构，反而会拖慢开发效率。在完成MVP后，就要逐步转向微服务架构。
微服务架构的模式语言
什么是模式和模式语言？
模式：针对特定上下文中发生的问题的可重用解决方案。
模式语言：解决特定领域内问题的相关模式的集合。
--建筑理论家，Christopher Alexander
《Design Patterns: Elements of Reusable Object-Oriented Software》的作者受到Christopher Alexander的启发写了这本书。书中，描述了面向对象设计模式的合计。Christopher Alexander理解：软件模式就是通过定义一组互相协作的软件元素来解决软件架构或设计问题。
常用的模式结构包含三个方面：
- 需求（Forces）：必须解决的问题。需求描述必须解决的问题和围绕这个问题的特定上下文环境。
- 结果上下文（Resulting context）：采用模式后可能带来的后果
- 好处：这个模式的优势和解决了什么问题
- 弊端：这个模式的劣势和它没有解决哪些需求
- 问题：新引入的问题
- 相关模式（Related patterns），描述了这个模式和其他模式之间的关系。
- 前导：催生这个模式的需求的模式。
- 后续：用来解决当前模式引入的新问题的模式。例如引入微服务，那就需要一系列后续模式（服务发现，断路器），解决微服务带来的问题。
- 代替：可以互相替换的另外的解决方案。单体架构和微服务架构师互为代替的模式。
- 泛化：针对一个问题的一般性解决方案
- 特化：针对一个问题的具体解决方案
把解决类似问题的模式组成，一组模式。通过这些关系相关的模式集合形成所谓的模式语言。模式语言中的模式共同解决特定领域中的问题。
微服务架构的语言模式
微服务之上：流程和组织
除了拥有正确的架构之外，成功的软件开发还需要在组织、开发和交付流程方面做一些工作。
人多并不一定力量大，团队规模增加，也会伴随着其他问题的出现。《人月神话》这本书中提到的，沟通成本会随着团队的规模呈O(N2)的速度上升。
解决之道是把大团队拆分成一系列小团队。每个团队都足够小，人员规模为8～12人。
- 每个团队都有一个明确的职责：开发并且可能也负责运维一个或者多个服务，这些服务实现了一个或多个业务能力。
- 这些团队都是跨职能的。
- 他们可以独立地完成开发、测试和部署等任务，而不需要频繁地与其他团队沟通或者协调。
落地微服务架构，需要考虑到康威定律(Conway's law)。
Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations. - Melvin Conway(1967)
翻译成中文就是：设计系统的组织....往往被组织的架构所限制，最终设计的结果是这些组织的沟通结构的副本。换句话说，应用程序的架构往往反映了开发它的组织的结构。所以除了软件结构的改变，同时
- 需要对软件开发和交付流程进行改造。Scrum或Kanban这类敏捷开发和不数时间，持续交付（之需交付能够以刻之需的方式安全、快速的将所有类型的变更，包括新功能、配置更改、错误修复和试验，交付到生产环境或用户手中）和持续部署。
- 需要改变组织结构和开发的流程。
