1.1 迈向单体地狱的漫长旅程
1.1.1 FTGO 应用程序的架构
业务立即由包含了服务和领域对象的模块组成:
- Order Management
- Delivery Management
- Billing
- Payments
与外部系统对接的适配器:
- 入站 (inbound) 适配器, 调用业务逻辑处理请求
- REST API
- Web 用户界面
- 出站 (outbound) 适配器
- MySQL
- Twilio
- Stripe
1.1.2 单体架构的好处
1.1.3 什么是单体地狱
过度的复杂性会吓退开发者:
- 难于理解
- 修复和实现功能困难且耗时
- 会形成恶性循环
开发速度缓慢:
- 编辑
- 构建
- 运行
- 测试
从代码提交到实际部署的周期很长, 而且容易出问题:
- “无法” 在业务时间部署
- 多个开发人员提交的代码使得代码库处于无法交付的状态
- 分支带来了漫长且痛苦的合并过程
- 运行测试需要很长时间
难以扩展:
- 单体应用的不同模块需要不同的资源 (CPU, 内存) , 在选用服务器时必须满足所有模块的需要
交付可靠的单体应用是一项挑战:
- 缺乏可靠性
- 缺乏故障隔离
需要长期依赖某个可能已经过时的技术栈:
- 采用新的框架和编程语言变得困难
1.2 为什么本书与你有关
1.3 你会在本书中学到什么
1.4 拯救之道: 微服务架构
软件架构对功能性需求影响并不大. 架构的重要性在于它影响了应用的非公能性需求, 也称质量属性或者其他的能力:
- 可维护性
- 可扩展性
- 可测试性
Page9:
1.4.1 扩展立方体和服务
<
X 轴扩展: 在多个实例之间实现请求的负载均衡
- 可提高应用程序吞吐量和可用性
Z 轴扩展: 根据请求的属性路由请求
- 用于应用程序需要处理增加的事务和数据量时
Y 轴扩展: 根据功能把应用拆分为服务
- 解决开发问题和应用复杂性
对微服务架构的概括性定义: 把应用程序功能性分解为一组服务的架构风格.
- 该定义中没有包含任何与规模有关的内容
- 每一个服务都是由一组专注的, 内聚的功能职责组成
1.4.2 微服务架构作为模块化的一种形式
1.4.3 每个服务都拥有自己的数据库
服务不会因为其他的服务锁住了数据库而进入堵塞的状态.
1.4.4 FTGO 的微服务架构
前端服务:
- API Gateway
- Web 用户界面 (Restaurant Web UI)
业务逻辑由众多后端服务组成:
- REST API
- 私有数据库
1.4.5 微服务架构与 SOA 的异同
SOA 和微服务架构都是特定的架构风格, 它们都以一系列的服务方式来把一个系统组织在一起.
微服务和 SOA 之间的差异:
1.5 微服务架构的好处和弊端
1.5.1 微服务架构的好处
使大型的复杂应用程序可以持续交付和持续部署
微服务架构以三种方式实现:
- 拥有可测试性
- 编写和执行自动化测试容易
- 拥有可部署性
- 每个服务可以独立其他服务部署
- 可频繁部署到生产
- 是开发团队能够自主且松散耦合
- 将工程组织构建为一个小型团队的集合
- 每个团队可以独立于其他团队进行开发, 部署和扩展他们的服务, 结果开发速度变快
各个过程都是独立的.
每个服务都相对较小并容易维护
- 开发者更容易理解服务中的代码
- 较小规模的代码库不会把 IDE 等开发工具拖慢
服务可以独立扩展
- X 轴扩展的实例克隆
- Z 轴扩展的流量分区
- 可以针对组件对资源的需求来购置服务器
更好的容错性
- 故障隔离
更容易实验和采纳新的技术
- 消除对某项技术栈的长期依赖
- 使用新的编程语言和技术重写一个服务的风险低
1.5.2 微服务架构的弊端
服务的拆分和定义是一项挑战:
分布式系统带来的各种复杂性:
- 进程间通信
- 局部故障
- 远程服务不可用
- 高延迟
- 跨服务的事务和查询
- IDE 不具备开发分布式应用所需要的特定功能
- 引入运维复杂性
当部署跨越多个服务的功能时需要谨慎地协调更多开发团队:
- 必须制定一个发布计划, 把服务按照依赖关系进行排序
开发者需要思考到底应该在应用的什么阶段使用微服务架构:
- 初创公司几乎肯定应该从单体的应用程序开始
https://microservices.io/ 介绍了模式细节
1.6 微服务架构的模式语言
1.6.1 微服务架构并不是 “银弹”
作为软件开发社区的一员, 需要克服我们情绪化的本能, 找到一种讨论和应用技术的更好方法, 这个方法便是采用模式 (Pattern) 的形态. 模式是一个客观工具, 在通过模式的形态描述一项技术时, 必须包括它的弊病.
1.6.2 模式和模式语言
模式是针对特定上下文中发生的问题的可重用解决方案.
模式有价值的一个原因是模式必须描述它所适用的上下文场景.
常用的模式结构包括三个重要部分:
- 需求 (Forces)
- 结果上下文 (Resulting context)
- 相关模式 (Related patterns)
需求: 必须解决的问题
- 必须把需求按优先级进行排序, 然后进行解决
结果上下文: 采用模式后可能带来的后果
相关模式: 5种不同类型的关系
- 相关模式部分描述了这个模式和其他模式之间的关系
1.6.3 微服务架构的模式语言概述
微服务架构的模式语言是一组模式, 可帮助架构师使用微服务架构构建应用程序.
这些模式被分为三组:
服务拆分的相关模式
2章.
**
通信的相关模式
3章.
实现事务管理的数据一致性相关模式
4~6章.
- 两步式提交 (two phase commit, 2PC) 分布式事务机制
- Saga 模式
在微服务架构中查询数据的相关模式
7~8章.
不能直接针对服务的数据库执行分布式查询.
- CQRS: 命令查询职责隔离
服务部署的相关模式
12章
可观测性的相关模式
11章.
相当于服务监控, 跟踪.
实现服务自动化测试的相关模式
9~10章.
通过单独测试服务来简化测试的模式:
解决基础设施和边界问题的相关模式
11章.
包括:
- 可观测性模式
- 服务发现模式
- 外部化配置模式
- 微服务基底模式
安全相关的模式
11章.
将有关用户的信息传递给它调用的服务.
- 应用访问令牌模式
架构不是唯一需要关注的领域, 还必须思考流程和组织.
1.7 微服务之上: 流程和组织
1.7.1 进行软件开发和交付的组织
- 沟通成本
逆向的康威定律:
1.7.2 进行软件开发和交付的流程
采用类似 Scrum 或 Kanban 这类敏捷开发和部署实践.
- 还需实践持续交付和持续部署
1.7.3 采用微服务架构时的人为因素
畅销书 <
- 结束, 失落和放弃 (怀念之前的舒适区)
- 中立区 (学习新知识)
- 新的开始 (拥抱新的工作方式)