微服务架构设计模式笔记--第一章 逃离单体地狱

迈向单体地狱的漫长旅途

单体架构存在着巨大的局限性，渴求成功的应用程序，往往都不断地在单体架构的基础之上扩展。每一次开发冲刺(Sprint)，开发团队就会实现更多的功能，显然这会导致代码库膨胀。而且，随着公司的成功，研发团队的规模不断壮大。代码库规模变大的同时，团队的管理成本也不断提高。
那个曾经小巧的、简单的、由一个小团队开发维护的应用程序，已经演变成一个由大团队开发的巨无霸单体应用程序。开发变得缓慢和痛苦。敏捷开发和部署已经不可能。

• 过度的复杂性会吓退开发者
• 开发速度缓慢
• 从代码提交到实际部署的周期很长，而且容易出问题
• 难以扩展
• 交付可靠的单体应用是一项挑战
• 需要长期的依赖某个可能已经过时的技术栈

拯救之道：微服务架构

今天，针对大型复杂应用的开发，越来越多的共识趋向于考虑使用微服务架构。但微服务到底是什么？不幸的是，微服务这个叫法本身暗示和强调了尺寸。

1. 扩展立方体和服务

这个模型描述了扩展一个应用程序的三种维度:X、Y和Z。

• X轴扩展:在多个实例之间实现请求的负载均衡
  
• Z轴扩展:根据请求的属性路由请求
  
• Y轴扩展:根据功能把应用拆分为服务
  

服务本质上是一个麻雀虽小但五脏俱全的应用程序，它实现了一组相关的功能，例如订单管理、客户管理等。服务可以在需要的时候借助X轴或Z轴方式进行扩展。例如,订单服务可以被部署为一组负载均衡的服务实例。
我对微服务架构的概括性定义是：把应用程序功能性分解为一组服务的架构风格。请注意这个定义中并没有包含任何与规模有关的内容。重要的是,每一个服务都是由一组专注的、内聚的功能职责组成。

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

模块化是开发大型、复杂应用程序的基础。应用程序规模太大很难作为一个整体开发，也很难让一个人完全理解。为了让不同的人开发和理解，大型应用需要拆分为模块。
微服务架构使用服务作为模块化的单元。服务的API为它自身构筑了一个不可逾越的边界,你无法越过API去访问服务内部的类，这与采用Java包的单体应用完全不同。因此模块化的服务更容易随着时间推移而不断演化。微服务架构也带来其他的好处,例如服务可以独立进行部署和扩展。

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

微服务架构的一个关键特性是每一个服务之间都是松耦合的，它们仅通过API进行通信。实现这种松耦合的方式之一，是每个服务都拥有自己的私有数据库。在开发阶段，开发者可以修改自己服务的数据库模式，而不必同其他服务的开发者协调。在运行时,服务实现了相互之间的独立。服务不会因为其他的服务锁住了数据库而进入堵塞的状态。

4. FTGO的微服务架构

前端服务包括 API Gateway和餐馆的Web用户界面(Restaurant Web UI)。 API Gateway扮演了一个对外的角色，它提供了供消费者和快递员的移动应用程序使用的 REST API。餐馆的网页界面实现了餐馆用来管理菜单和订单流程的Web用户界面。
FTGO应用程序的业务逻辑由众多后端服务组成。每个后端服务都有一个 REST API和它自己的私有数据库。后端服务包括以下内容:

• Order Service:管理订单。
• Delivery Service:管理从餐馆到客户之间的订单派送(送餐)。
• Restaurant service:维护餐馆有关的信息。
• Kitchen service:管理订单的准备过程。
• Accounting service:处理账单和付款。

每个服务及其API都有非常清晰的定义。每个都可以独立开发、测试、部署和扩展。此外,该架构在保持模块化方面做得很好。开发人员无法绕过服务的API并访问其内部组件。

微服务架构的好处和弊端

1. 微服务架构的好处

• 使大型的复杂应用程序可以持续交付和持续部署。
• 每个服务都相对较小并容易维护。
• 服务可以独立部署。
• 服务可以独立扩展。
• 微服务架构可以实现团队的自治。
• 更容易实验和采纳新的技术。
• 更好的容错性。

2. 微服务架构的弊端

• 服务的拆分和定义是一项挑战。
• 分布式系统带来的各种复杂性，使开发、测试和部署变得更困难。
• 当部署跨越多个服务的功能时需要谨慎地协调更多开发团队。
• 开发者需要思考到底应该在应用的什么阶段使用微服务架构。

微服务架构的模式语言

• 服务拆分的相关模式
• 通信的相关模式
• 实现事务管理的数据一致性相关模式
• 在微服务架构中查询数据的相关模式
• 服务部署的相关模式
• 可观测性的相关模式
• 实现服务自动化测试的相关模式
• 解决基础设施和边界问题的相关模式
• 安全相关的模式

微服务之上：流程和组织

对于大型和复杂的应用程序，微服务架构往往是最佳的选择。然而，除了拥有正确的架构之外，成功的软件开发还需要在组织、开发和交付流程方面做一些工作。

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

成功往往意味着研发团队规模的扩大。一方面，这是个好事，因为人多力量大。但是团队大了以后，正如 Fred Brooks在《人月神话》这本书中提到的，沟通成本会随着团队的规模呈O(N²)的速度上升。如果团队太大,由于沟通成本过高,往往会使得团队的效率降低。
想想看，如果每天早上的站会规模达到20人会是怎样？
解决之道是把大团队拆分成一系列小团队。每个团队都足够小，人员规模为8~12人。每个团队都有一个明确的职责:开发并且可能也负责运维一个或者多个服务,这些服务实现了一个或多个业务能力。这些团队都是跨职能的。他们可以独立地完成开发、测试和部署等任务,而不需要频繁地与其他团队沟通或者协调。

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

采用微服务架构以后，如果仍旧沿用瀑布式开发流程,那就跟用一匹马来拉法拉利跑车没什么区别——我们需要充分利用微服务带来的各种便利。如果你希望通过微服务架构来完成一个应用程序的开发,那么采用类似 Scrum或 Kanban这类敏捷开发和部署实践就是必不可少的。同时也需要积极实践持续交付和持续部署，这是 DevOps中的关键环节。