prchann

发展历史： 1. 起初，微服务是作为 SOA 的一种补救方案被提出的；该阶段的微服务并不起眼； 2. 2012-2014 年，开始有人独立定义微服务（抛开 SOA）。 [《Microservices: A Definition of This New Architectural Term》](https://martinfowler.com/articles/microservices.html)列举了微服务的九个核心的业务与技术特征： 1. 围绕业务能力构建：强调技术架构为业务服务，与业务发展阶段匹配； 1. 分散治理：允许技术异构。对应团队为其服务的质量负责，同时允许该团队根据自身情况选择语言/框架等异构技术； 1. 通过服务来实现独立自治的组件：“服务”而非“组件/类库”，因前者隔离和自治能力好； 1. 产品化思维：把“服务”看成“产品”，关注服务的整个生命周期； 1. 数据去中心化：不同服务关注同个数据的重点/视角不同，使用统一的数据容易耦合或相互限制； 1. 强终端弱管道：管道指通信机制；管道提供基本的通信机制即可，特殊的能力需求由终端/业务服务定制化解决； 1....

图 16-3 的[图片来源](https://cloud-google-drive.blogspot.com/2019/11/adoption-of-cloud-native-architecture.html)已失效。

> 治理就是让产品能够符合预期地稳定运行，并能够持续保持在一定的质量水平上。 ### 静态的治理 治理的难处来自于复杂性；软件的复杂性主要来自“认知负荷”和“协作成本”。 前提和定义： * 康威定律：组织架构适配软件架构； * 协作成本主要来自沟通成本；沟通成本 = N×(N-1)/2； * N: 团队规模； * k: 系数。 单体的复杂性 d = O(k1N) + O(N2) * 认知负荷：O(k1N) * 协作成本：O(N2) 微服务的复杂性 w...

> @zwxisboy > 想问问tcc中的回滚，和saga中的补偿是一种意思吧？ 不是的。当扣除了用户的余额后，如果后续步骤出现异常， * TCC 的回滚：把用户余额恢复原样 -- 要求开发者能够控制用户余额数据； * SAGA 的补偿：执行将商家账户转账给用户 -- 要求开发者有补偿的方法，但无需控制用户余额数据。

## CAP * 分布式环境下，不可避免网络分区，所以**分区容忍性**是不得不选择的选项； * 追求强一致性时，不得不妥协可用性； * 追求高可用性时，不得不采取弱一致性（最终一致性）。 ## BASE 1. 尽最大努力交付：借助**可靠事件队列**并采用**尽最大努力交付**，BASE 的逻辑比较简单（无需提前冻结资源，也无需回滚） 1. 优点：简单 1. 缺点：隔离性差，必须成功（无回滚） 1. 适合场景：隔离要求低，成功概率高，小事务（快，从而降低失败可能性） ## TCC: Try-Confirm-Cancel 1. 两个 C 阶段均是尽最大努力交付 1. 优点：隔离性好，性能好（已预留的资源归当前事务所有，无竞争，免锁） 1. 缺点：Try...

## 实现原子性和持久性 原子性的难点：磁盘操作存在中间状态“写中”。如果**写中** Crash，需要有机制来恢复现场，并执行回滚/重写。 解决思路： 1. 把事务（单条 SQL 时本身就是一个事务）的各步操作先写到 log（这种 log 称为 Redo Log）； 1. 事务成功提交时，在 log 中追加“提交记录” (Commit Record) 进行标记 -- 此时整个事务（的日志）均已落盘（落日志盘），实现了持久化； 1. 数据库系统看到 Commit Record 后，再根据 log 对真正的数据进行修改，修改完成则在...

最终一致：内部不一致的情况可能被外部感知；CDN。 Gossip 流行病算法: 1. 简单 1. 随机性，全网统一的时间难以精准计算 1. 随机性可能重复发送给同一节点，消息冗余 1. 反墒 VS 传谣

这里作者主要讲非技术层面的条件，技术层面的可参考[《Microservice Prerequisites》](https://martinfowler.com/bliki/MicroservicePrerequisites.html)。 一、决策者与执行者都能意识到**康威定律**在软件设计中的关键作用 根据产品的功能分组，来适配地调整员工的组织架构。 二、组织中具备一些对微服务有充分理解、有一定实践经验的技术专家 三、系统应具有以**自治**为目标的自动化与监控度量能力 鱼缸的例子非常形象。 完全的自治很难，但能做到非自治的部分是收敛的也不错。 四、复杂性已经成为制约生产力的主要矛盾 参考微服务与单体的生产力随复杂度变化的曲线图。

为了拆分大型单体，让每一个子系统都能独立地部署、允许、更新。架构演进不断演进： 一、烟囱式架构：孤岛式，系统间完全不协作。隔离性好，但不现实（系统间协作是常态）。 二、微内核架构：插件式，公共数据和能力放在 Core，其他可插拔。 特点：隔离性好。插件间不可预知存在性，也不能直接通信。 适合桌面应用程序。 三、事件驱动架构：建立一套事件队列管道，各系统可从中生产和消费感兴趣的事件。借助该机制可实现系统间灵活的、直接的、异步的通信。 四、SOA * 1994年，Gartner 提出 SOA 概念，但此时还不具备发展条件。 * 时间推移，SOAP 远程调用等技术出现/成熟，SOA 发展条件开始完备。 * 2006 年，IBM 等 ToB 公司联合成立 OSOA 联盟，专注制定和推进 SOA 标准。 与前面三个架构对比，SOA： * 更具体：清晰的指导原则，制定协议，出方案；...

Serverless = BaaS + FaaS * BaaS: 后端即服务，指 DB、MQ、日志、存储、网关等用于支撑业务逻辑运行，但本身无业务含义的技术组件。 * FaaS: 函数即服务，指业务逻辑代码。函数的概念和粒度接近程序编码中的函数，主要区别是无服务中的函数运行在云端，无需考虑算力问题和容量规划。 无服务让开发者需要关注的东西更少了。 * 微服务：需关注弹性伸缩策略、服务间通信、架构、日志、告警等； * 无服务：无需关注运行时。函数间是平等关系。 （当前）无服务适合场景：短链接、无状态、适合事件驱动的交互形式，比如 Web 网站、定时任务、小程序/App 后台等。 不适合逻辑复杂、依赖服务端状态、响应速度要求较高、长链接等应用，比如网络游戏、直播等。