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

1.1.1 FTGO 应用程序的架构

image.png

业务立即由包含了服务和领域对象的模块组成:

  1. Order Management
  2. Delivery Management
  3. Billing
  4. Payments

与外部系统对接的适配器:

  • 入站 (inbound) 适配器, 调用业务逻辑处理请求
    • REST API
    • Web 用户界面
  • 出站 (outbound) 适配器
    • MySQL
    • Twilio
    • Stripe

1.1.2 单体架构的好处

image.png

1.1.3 什么是单体地狱

image.png

过度的复杂性会吓退开发者:

  • 难于理解
  • 修复和实现功能困难且耗时
  • 会形成恶性循环

开发速度缓慢:

  • 编辑
  • 构建
  • 运行
  • 测试

从代码提交到实际部署的周期很长, 而且容易出问题:

  • “无法” 在业务时间部署
  • 多个开发人员提交的代码使得代码库处于无法交付的状态
  • 分支带来了漫长且痛苦的合并过程
  • 运行测试需要很长时间

难以扩展:

  • 单体应用的不同模块需要不同的资源 (CPU, 内存) , 在选用服务器时必须满足所有模块的需要

交付可靠的单体应用是一项挑战:

  • 缺乏可靠性
  • 缺乏故障隔离

需要长期依赖某个可能已经过时的技术栈:

  • 采用新的框架和编程语言变得困难

1.2 为什么本书与你有关

1.3 你会在本书中学到什么

image.png

1.4 拯救之道: 微服务架构

软件架构对功能性需求影响并不大. 架构的重要性在于它影响了应用的非公能性需求, 也称质量属性或者其他的能力:

  • 可维护性
  • 可扩展性
  • 可测试性

Page9:

image.png

1.4.1 扩展立方体和服务

<> 中描述了一个非常有用的三维可扩展模型: 扩展立方体

image.png

X 轴扩展: 在多个实例之间实现请求的负载均衡

  • 可提高应用程序吞吐量和可用性

image.png

Z 轴扩展: 根据请求的属性路由请求

  • 用于应用程序需要处理增加的事务和数据量时

image.png

Y 轴扩展: 根据功能把应用拆分为服务

  • 解决开发问题和应用复杂性

image.png

对微服务架构的概括性定义: 把应用程序功能性分解为一组服务的架构风格.

  • 该定义中没有包含任何与规模有关的内容
  • 每一个服务都是由一组专注的, 内聚的功能职责组成

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

image.png

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

服务不会因为其他的服务锁住了数据库而进入堵塞的状态.

image.png

1.4.4 FTGO 的微服务架构

image.png

前端服务:

  • API Gateway
  • Web 用户界面 (Restaurant Web UI)

业务逻辑由众多后端服务组成:

  • REST API
  • 私有数据库

image.png

1.4.5 微服务架构与 SOA 的异同

SOA 和微服务架构都是特定的架构风格, 它们都以一系列的服务方式来把一个系统组织在一起.

微服务和 SOA 之间的差异:

image.png

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

1.5.1 微服务架构的好处

image.png

使大型的复杂应用程序可以持续交付和持续部署

微服务架构以三种方式实现:

  • 拥有可测试性
    • 编写和执行自动化测试容易
  • 拥有可部署性
    • 每个服务可以独立其他服务部署
    • 可频繁部署到生产
  • 是开发团队能够自主且松散耦合
    • 将工程组织构建为一个小型团队的集合
    • 每个团队可以独立于其他团队进行开发, 部署和扩展他们的服务, 结果开发速度变快

image.png

各个过程都是独立的.

image.png

每个服务都相对较小并容易维护

  • 开发者更容易理解服务中的代码
  • 较小规模的代码库不会把 IDE 等开发工具拖慢

服务可以独立扩展

  • X 轴扩展的实例克隆
  • Z 轴扩展的流量分区
  • 可以针对组件对资源的需求来购置服务器

更好的容错性

  • 故障隔离

更容易实验和采纳新的技术

  • 消除对某项技术栈的长期依赖
  • 使用新的编程语言和技术重写一个服务的风险低

1.5.2 微服务架构的弊端

image.png

服务的拆分和定义是一项挑战:

image.png

分布式系统带来的各种复杂性:

  • 进程间通信
  • 局部故障
  • 远程服务不可用
  • 高延迟
  • 跨服务的事务和查询
  • IDE 不具备开发分布式应用所需要的特定功能
  • 引入运维复杂性

当部署跨越多个服务的功能时需要谨慎地协调更多开发团队:

  • 必须制定一个发布计划, 把服务按照依赖关系进行排序

开发者需要思考到底应该在应用的什么阶段使用微服务架构:

  • 初创公司几乎肯定应该从单体的应用程序开始

https://microservices.io/ 介绍了模式细节

1.6 微服务架构的模式语言

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

作为软件开发社区的一员, 需要克服我们情绪化的本能, 找到一种讨论和应用技术的更好方法, 这个方法便是采用模式 (Pattern) 的形态. 模式是一个客观工具, 在通过模式的形态描述一项技术时, 必须包括它的弊病.

1.6.2 模式和模式语言

模式是针对特定上下文中发生的问题的可重用解决方案.

模式有价值的一个原因是模式必须描述它所适用的上下文场景.

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

  • 需求 (Forces)
  • 结果上下文 (Resulting context)
  • 相关模式 (Related patterns)

需求: 必须解决的问题

  • 必须把需求按优先级进行排序, 然后进行解决

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

image.png

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

  • 相关模式部分描述了这个模式和其他模式之间的关系

image.png
image.png

image.png

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

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

image.png

这些模式被分为三组:

image.png

服务拆分的相关模式

2章.
**
image.png

通信的相关模式

3章.

image.png

image.png

实现事务管理的数据一致性相关模式

4~6章.

  • 两步式提交 (two phase commit, 2PC) 分布式事务机制

image.png

  • Saga 模式

image.png

在微服务架构中查询数据的相关模式

7~8章.

不能直接针对服务的数据库执行分布式查询.

image.png

  • CQRS: 命令查询职责隔离

服务部署的相关模式

12章

image.png

可观测性的相关模式

11章.

相当于服务监控, 跟踪.

image.png

实现服务自动化测试的相关模式

9~10章.

通过单独测试服务来简化测试的模式:

image.png

解决基础设施和边界问题的相关模式

11章.

包括:

  • 可观测性模式
  • 服务发现模式
  • 外部化配置模式
  • 微服务基底模式

安全相关的模式

11章.

将有关用户的信息传递给它调用的服务.

  • 应用访问令牌模式

架构不是唯一需要关注的领域, 还必须思考流程和组织.

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

image.png

image.png

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

  • 沟通成本

逆向的康威定律:

image.png

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

采用类似 Scrum 或 Kanban 这类敏捷开发和部署实践.

  • 还需实践持续交付和持续部署

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

畅销书 <> 介绍了转型 (transition) 的概念, 其中阐述了人们如何对变化做出情绪化的反应, 它包括以下三个阶段:

  1. 结束, 失落和放弃 (怀念之前的舒适区)
  2. 中立区 (学习新知识)
  3. 新的开始 (拥抱新的工作方式)

本章小结

image.png
image.png