凤凰架构-读书笔记
自复制机恰好就是一个最好的用不可靠部件构造的可靠的系统例子。这里，“不可靠部件”可以理解为构成生命的大量细胞、甚至是分子。由于热力学扰动、生物复制差错等因素干扰，这些分子本身并不可靠。但是生命系统之所以可靠的本质，恰是因为它可以使用不可靠的部件来完成遗传迭代。这其中的关键点便是承认细胞等这些零部件可能会出错，某个具体的零部件可能会崩溃消亡，但在存续生命的微生态系统中一定会有其后代的出现，重新代替该零部件的作用，以维持系统的整体稳定。在这个微生态里，每一个部件都可以看作一只不死鸟（Phoenix），它会老迈，而之后又能涅槃重生。
演进中的架构
原始分布式
原始分布式时代提出的构建“符合 UNIX 的设计哲学的”“如同本地调用一般简单透明的”分布式系统这个目标，是软件开发者对分布式系统最初的美好愿景
单体
单体意味着自包含。单体应用描述了一种由同一技术平台的不同组件构成的单层软件。
SOA
软件架构来到 SOA 时代，许多概念、思想都已经能在今天微服务中找到对应的身影了，譬如服务之间的松散耦合、注册、发现、治理，隔离、编排，等等
过于严格的规范定义带来过度的复杂性。而构建在 SOAP 基础之上的 ESB、BPM、SCA、SDO 等诸多上层建筑，进一步加剧了这种复杂性
SOA 诞生的那一天起，就已经注定了它只能是少数系统阳春白雪式的精致奢侈品，它可以实现多个异构大型系统之间的复杂集成交互，却很难作为一种具有广泛普适性的软件架构风格来推广
微服务
微服务是一种通过多个小型服务组合来构建单个应用的架构风格，这些服务围绕业务能力而非特定的技术标准来构建。各个服务可以采用不同的编程语言，不同的数据存储技术，运行在不同的进程之中。服务采取轻量级的通信机制和自动化的部署机制实现通信与运维
微服务真正的崛起是在 2014 年，相信阅读此文的大多数读者，也是从 Martin Fowler 与 James Lewis 合写的文章《Microservices: A Definition of This New Architectural Term》中首次了解到微服务的。这
后微服务
2017 年是容器生态发展历史中具有里程碑意义的一年
Kubernetes 成为容器战争胜利者标志着后微服务时代的开端
服务网格”（Service Mesh）的“边车代理模式”
无服务
无服务中称其为“函数即服务”（Function as a Service，FaaS）
无服务的愿景是让开发者只需要纯粹地关注业务，不需要考虑技术组件，后端的技术组件是现成的，可以直接取用，没有采购、版权和选型的烦恼；不需要考虑如何部署，部署过程完全是托管到云端的，工作由云端自动完成；不需要考虑算力，有整个数据中心支撑，算力可以认为是无限的；也不需要操心运维，维护系统持续平稳运行是云计算服务商的责任而不再是开发者的责任。
远程服务调用
RPC
通过网络进行分布式运算的八宗罪（8 Fallacies of Distributed Computing）：
- The network is reliable —— 网络是可靠的。
- Latency is zero —— 延迟是不存在的。
- Bandwidth is infinite —— 带宽是无限的。
- The network is secure —— 网络是安全的。
- Topology doesn't change —— 拓扑结构是一成不变的。
- There is one administrator —— 总会有一个管理员。
- Transport cost is zero —— 不必考虑传输成本。
- The network is homogeneous —— 网络是同质化的
如何表示数据：这里数据包括了传递给方法的参数，以及方法执行后的返回值。序列化与反序列化
如何传递数据：准确地说，是指如何通过网络，在两个服务的 Endpoint 之间相互操作、交换数据。这里“交换数据”通常指的是应用层协议，实际传输一般是基于标准的 TCP、UDP 等标准的传输层协议来完成的。
如何确定方法：这在本地方法调用中并不是太大的问题，编译器或者解释器会根据语言规范，将调用的方法签名转换为进程空间中子过程入口位置的指针。接口描述语言（Interface Description Language，IDL）
由于一直没有一个同时满足以上三点的“完美 RPC 协议”出现，所以远程服务器调用这个小小的领域里，逐渐进入了群雄混战、百家争鸣的战国时代
到了最近几年，RPC 框架有明显的朝着更高层次（不仅仅负责调用远程服务，还管理远程服务）与插件化方向发展的趋势，不再追求独立地解决 RPC 的全部三个问题（表示数据、传递数据、表示方法），而是将一部分功能设计成扩展点，让用户自己去选择。
REST
降低的服务接口的学习成本。
资源天然具有集合与层次结构。
REST 绑定于 HTTP 协议。
事物处理
本地事物
ACID：
原子、持久 ：
redolog、 undolog
隔离：
读锁、写锁、范围锁
MVCC 是只针对“读+写”场景的优化， 无锁优化方案被主流的商业数据库广泛采用
分布式事务：
可靠消息队列-
将最有可能出错的业务以本地事务的方式完成后，采用不断重试的方式（不限于消息系统）来促使同一个分布式事务中的其他关联业务全部完成。
TCC-
TCC 是位于用户代码层面，而不是在基础设施层面；
TCC 在业务执行时只操作预留资源，几乎不会涉及锁和资源的争用，具有很高的性能潜力
但是 TCC 并非纯粹只有好处，它也带来了更高的开发成本和业务侵入性，意味着有更高的开发成本和更换事务实现方案的替换成本，所以，通常我们并不会完全靠裸编码来实现 TCC，而是基于某些分布式事务中间件
SAGA-
大致思路是把一个大事务分解为可以交错运行的一系列子事务集合。原本 SAGA 的目的是避免大事务长时间锁定数据库的资源，后来才发展成将一个分布式环境中的大事务分解为一系列本地事务的设计模式
透明多级分流：
如无必要，勿增实体
缓存风险：
穿透、击穿、雪崩、污染（cache aside）
架构安全性：
- 认证（Authentication）：系统如何正确分辨出操作用户的真实身份？
- 授权（ Authorization）：系统如何控制一个用户该看到哪些数据、能操作哪些功能？
- 凭证（Credential）：系统如何保证它与用户之间的承诺是双方当时真实意图的体现，是准确、完整且不可抵赖的？
- 保密（Confidentiality）：系统如何保证敏感数据无法被包括系统管理员在内的内外部人员所窃取、滥用？
- 传输（Transport Security）：系统如何保证通过网络传输的信息无法被第三方窃听、篡改和冒充？
- 验证（Verification）：系统如何确保提交到每项服务中的数据是合乎规则的，不会对系统稳定性、数据一致性、正确性产生风险？
分布式基石
世界上只有一种共识协议，就是 Paxos，其他所有共识算法都是 Paxos 的退化版本。
Paxos、Raft、ZAB 等分布式算法经常会被称作是“强一致性”的分布式共识协议，其实这样的描述扣细节概念的话是很别扭的，会有语病嫌疑，但我们都明白它的意思其实是在说“尽管系统内部节点可以存在不一致的状态，但从系统外部看来，不一致的情况并不会被观察到，所以整体上看系统是强一致性的”。
从类库到服务
服务发现：
可用性与一致性的矛盾，是分布式系统永恒的话题，在服务发现这个场景里，权衡的主要关注点是能相对更能容忍出现服务列表不可用的后果，还是出现服务数据不准确的后果
网管路由
网关 = 路由器（基础职能） + 过滤器（可选职能）
流量治理 - 服务容错、流量控制
由于服务随时都有可能崩溃，因此快速的失败检测和自动恢复就显得至关重要。
服务容错-
设计模式：
断路器模式、舱壁隔离模式，重试模式
熔断、隔离、重试、降级、超时等概念都是建立具有韧性的微服务系统的必须的保障措施
流量控制 -
滑动时间窗模式、漏桶模式、令牌桶模式
可靠通讯
令信任网络
可观测性
事件日志、链路追踪、聚合度量
不可变基础设施
容器是云计算、微服务等诸多软件业界核心技术的共同基石，容器的首要目标是让软件分发部署过程从传统的发布安装包、靠人工部署转变为直接发布已经部署好的、包含整套运行环境的虚拟化镜像。
技术方法论
微服务的目的是有效的拆分应用，实现敏捷开发和部署。
系统的架构趋同于系统设计团队的沟通结构。
微服务粒度的下界是它至少应满足独立——能够独立发布、独立部署、独立运行与独立测试，内聚——强相关的功能与数据在同一个服务中处理，完备——一个服务包含至少一项业务实体与对应的完整操作。
