摘录 - 凤凰架构

书籍信息

[!info] 简介
内容简介 这是一本从架构视角讲解如何构建大型分布式系统的著作，是《深入理解 Java 虚拟机》的作者周志明多年架构和研发经验的总结，全书以实践为导向，一个案例贯穿全书，同时给出了基于 Spring Boot、Spring Cloud、Kubernetes、Istio、AWS Lambda 五种架构风格的样例工程。

[!abstract] 书籍信息

• 
• 作者：周志明
• 出版时间：2021-06-25
• ISBN：9787111683919
• 分类：计算机 - 编程设计
• 出版社：机械工业出版社

前言

本篇文章是阅读《凤凰架构》一书后汇总的摘录笔记，书评总结详见：读《凤凰架构》。

摘录

赞誉

• 从大型机到单体架构，从微服务架构到无服务架构，每一次架构模式的演进都是一次涅槃。每一个软件系统都是由大量服务构成的生态体系，个体服务的“死亡”和“重生”是整个系统能否持续可靠运行的关键因素。—— 刘志勇 新浪微博平台研发部架构师 P9

• 从小型系统迭代到大型系统，从单体走向分布式，每一个成功的系统都会经历一次次“涅槃重生”，从失败中站起来，从故障里爬出来，从经验中成长起来。——王晓波 同程旅行机票事业群CTO P10

自序

从系统服务出错的必然性开始，引出”构建大规模但可靠的软件系统，是否可行“的思考分析，最后提出从架构层面保证稳定健壮服务的方案

• 在软件工程里，任何产品的研发，如果持续时间很长，人总免不了疏忽、犯错，导致代码存在缺陷，电脑宕机崩溃，网络堵塞中断……
  如果一项工程需要大量的人员共同研发某个大规模的软件产品，并使其分布在网络中的大量的服务器节点中同时运行，随着项目规模增大、运作时间变长，其必然会受到墨菲定律的无情打击。 P12

  系统服务不可避免会出错，所以服务本身是不可靠的，允许错误的出现。

• 为了得到高质量的软件产品，我们是应该把精力更多地集中在提升其中每一个人员、过程、产出物的能力和质量上？还是应该把更多精力放在整体流程和架构上？
  这两者都重要。前者重术，更多与编码能力相关，由开发者个体的水平决定。
  而后者重道，更多与软件架构相关，主要由技术决策者的水平决定。 P12

  巨石架构注重前者，分布式更注重后者

• 构建一个大规模但依然可靠的软件系统，是否可行？ P13

  理论上错误积累，系统崩溃。 反例：大量不可靠的细胞构成遗传迭代的人类

• 如何用一些“不可靠”部件构造出一个可靠的系统。 P13

  如何用不可靠变动的自我状态构造一个稳定工作的自成长系统。

• 从大型机（Mainframe）、原始分布式（Distributed）、大型单体（Monolithic）、面向服务（Service-Oriented）、微服务（Microservice）、服务网格（Service Mesh）到无服务（Serverless）等，技术架构确实呈现出“从大到小”的发展趋势。 P14

  架构的演进拆分越来越小，确保系统稳定可用。

• 微服务架构的视角下，所谓系统检修，不过只是一次在线服务更新而已，先停掉1/3的机器，升级新的软件版本，再有条不紊地导流、测试、做金丝雀发布，一切都显得如此理所当然、平淡寻常。 P15

• 只要在整体架构设计有恰当且自动化的错误熔断、服务淘汰和重建机制，即便某些部件采用了有问题的程序，哪怕存在严重的内存泄漏问题，哪怕最多只能服务三分钟就会崩溃，从系统外部来观察，架构仍然有可能表现出稳定和健壮的服务能力。 P15

  人类这种不可靠的部件组成了公司，构成了社会。偌大的草台班子，一盘散沙岌岌可危又稳定存续

前言

构建一套可靠的大型分布式系统是叙述主线，并鼓励实践中学习，概括总结了全书每一部分的内容
书籍在线网站：https://icyfenix.cn

• 本书是一本以“如何构建一套可靠的大型分布式系统”为叙述主线的技术手册。 P17

  主线任务：”如何构建一套可靠的大型分布式系统”

• 要深入理解一门技术，不仅要去看、去读、去想、去用，更要去说、去写。将自己“认为掌握了的”知识叙述出来，尽量将知识说得条理清晰，让他人听得明白，释去心中疑惑，同时把自己的观点交予别人审视，乃至质疑，在此过程之中，自己也会挖掘出很多潜藏在“已知”背后的“未知”。 P17

• 如果你是一名驾驶初学者，最合理的学习路径应该是先把汽车发动，然后慢慢行驶起来，而不是先从“引擎动力原理”“变速箱构造”入手去深刻地了解一辆汽车。计算机技术也是同理，先从运行程序开始，看看效果，搭建好开发、调试环境，对即将学习的内容先有一个整体的认知是很有好处的。 P18

• 第一部分 演进中的架构

第一部分只是着重介绍了软件开发历史中多种主流架构出现的契机、解决的问题以及带来的新缺陷。 P18

• 第二部分 架构师的视角

介绍一名架构师应该在架构设计时思考哪些问题，有哪些主流的解决方案和行业标准做法，各种方案有什么优缺点，不同的解决方法会带来什么不同的影响。
作为后续实践的基础，第二部分的内容与具体的架构风格无关，讨论的是普适的架构技术与使用技巧。无论你是否关注微服务、云原生这些概念，无论你从事架构设计还是编码开发，了解这里所列的基础知识，都是有实用价值的。 P18

• 第三部分 分布式的基石

只要选择了分布式架构，无论是SOA、微服务、服务网格或者其他架构风格，涉及与远程服务的交互时，服务的注册发现、跟踪治理、负载均衡、故障隔离、认证授权、伸缩扩展、传输通信、事务处理等一系列问题都是不可避免的。
不同的架构风格，其区别是到底要在技术规范上提供统一的解决方案，由应用系统自行解决，还是在基础设施层面将这类问题隔离掉。
第三部分将重点讨论这类问题的解决思路、方法和常见工具。 P19

选择分布式架构涉及的一系列通用问题的解决思路、方法和常见工具。

• 第四部分 不可变基础设施

在定义的“云原生”概念中，“不可变基础设施”被提升到与微服务平级的重要程度，此时它已不再局限于方便运维、程序升级和部署的手段，而是升华为向应用代码隐藏分布式架构复杂度、让分布式架构得以成为一种可普遍推广的普适架构风格的必要前提。
在云原生时代，软件与硬件之间的界线已经彻底模糊，无论是基础设施的运维人员，抑或是技术平台的开发人员，都有必要深入理解基础设施不变性的目的、原理与实现途径。 P19

• 第五部分 技术方法论

对于一个技术人员，成长的主要驱动力是实践，是在开发程序、解决问题中增长知识，再将知识归纳、总结、升华成为理论， P20

第一部分 演进中的架构

第 1 章 服务架构演进史

• 以全局的视角，介绍原始分布、单体系统、SOA、微服务、云原生、无服务六个时代。
• 在软件开发的未来，多种架构风格将会融合互补，“分布式”与“不分布式”的边界将逐渐模糊，两条路线将在云端的数据中心交汇。

1.1 原始分布式时代

在原始分布式时代，分布式运算环境”(Distributed Computing Environment，DCE) 中简单透明调用的美好愿景由于现实问题（硬件问题、性问题能）被迫搁浅。时间流逝40年后，微服务架构，分布式系统的设想应用在今天又大行其道了

• 保持接口与实现的简单性，比系统的任何其他属性，包括准确性、一致性和完整性，都来得更加重要。 P25

• 尽管“调用远程方法”与“调用本地方法”只有两字之差，但若要兼顾简单、透明、性能、正确、鲁棒、一致等特点，两者的复杂度就完全不可同日而语了。远程方法不能再依靠本地方法那些以内联为代表的传统编译优化来提升速度，光是“远程”二字带来的网络环境下的新问题，都需要设计者耗费大量精力。譬如：

  • 远程的服务在哪里（服务发现）
  • 有多少个（负载均衡）
  • 网络出现分区、超时或者服务出错了怎么办（熔断、隔离、降级）
  • 方法的参数与返回结果如何表示（序列化协议）
  • 信息如何传输（传输协议）
  • 服务权限如何管理（认证、授权）
  • 如何保证通信安全（网络安全层）
  • 如何令调用不同机器的服务返回相同的结果（分布式数据一致性）等 P26

• 某个功能能够进行分布式，并不意味着它就应该进行分布式，强行追求透明的分布式操作，只会自寻苦果。 P27

• 原始分布式时代提出的构建符合UNIX设计哲学的、如同本地调用一般简单透明的分布式系统的这个目标，是软件开发者对分布式系统最初的美好愿景，但迫于现实，它会在一定时期内被妥协、被舍弃。 P28

1.2 原始分布式时代

较系统全面的说明了单体架构的优劣，并阐述了选择分布式的根本原因。随着系统规模的扩大，为了允许程序出错，获得自治与隔离的能力，才是选择分布式的根本原因。

• 优点在于：
  • 易于开发测试部署；
  • 纵向代码分层，横向模块扩展、负载均衡都支持。
• 缺点在于：
  • 自治与隔离能力差，出现问题影响全局；
  • 发布更新更为复杂；
  • 难以技术异构，实现不够优雅。

• 对于小型系统，单台机器就足以支撑其良好运行的系统，不仅易于开发、测试、部署，且由于系统中各个功能、模块、方法的调用过程都是进程内调用，不会发生进程间通信 P29

• 单体系统的不足，必须在软件的性能需求超过了单机、软件的开发人员规模明显超过了6~12人的前提下才有讨论的价值 P29

• 从纵向向角度来看，收到的外部请求在各层之间以不同形式的数据结构进行流转传递，触及最末端的数据库后按相反的顺序回馈响应，对于这个意义上的“可拆分”，单体架构完全不会展露出丝毫的弱势，反而可能会因更容易开发、部署、测试而获得更好的便捷性。 P30

• 从横向角度来看，单体架构也支持按照技术、功能、职责等维度，将软件拆分为各种模块，以便重用和管理代码。单体系统并不意味着只能有一个整体的程序封装形式，如果需要，它完全可以由多个JAR、WAR、DLL、Assembly或者其他模块格式来构成。即使是横向扩展的需求，在负载均衡器之后同时部署若干个相同的单体系统副本，也可以达到分摊流量压力的效果。 P31

• 单体系统的真正缺陷不在如何拆分，而在拆分之后的自治与隔离能力上。
  由于所有代码都运行在同一个进程内，所有模块、方法的调用都无须考虑网络分区、对象复制这些麻烦的事和性能损失，但在获得进程内调用的简单、高效等好处的同时，也意味着如果任何一部分代码出现缺陷，过度消耗了进程空间内的资源，所造成的影响也是全局性的、难以隔离的。
  譬如内存泄漏、线程爆炸、阻塞、死循环等问题，都将会影响整个程序，而不仅仅是影响某一个功能、模块本身的正常运作。如果出现问题的是某些更高层次的公共资源，譬如端口号或者数据库连接池泄漏，还将会影响整台机器甚至集群中其他单体副本的正常工作。 P31

• 从可维护性来说，单体系统也是不占优势的。对于单体系统，在对程序升级、修改时往往需要制定专门的停机更新计划，做灰度发布、A/B测试也相对更复杂。 P32

• 如果说共享同一进程获得简单、高效的代价是同时损失了各个功能模块的自治与隔离能力，那这两者孰轻孰重呢？这个问题的潜台词似乎是在比较微服务、单体架构哪种更好用、更优秀。 P32

• 由于隔离能力的缺失，单体除了难以阻断错误传播、不便于动态更新程序以外，还面临难以技术异构的困难，每个模块的代码通常都需要使用一样的程序语言，乃至一样的编程框架去开发。单体系统的技术栈异构并非一定做不到，譬如JNI就可以让Java混用C或C++实现，但这通常是迫不得已的，并不是优雅的选择。 P33

• 单体系统很难兼容“Phoenix”的特性。这种架构风格潜在的要求是希望系统的每一个部件、每一处代码都尽量可靠，尽量不出或少出缺陷。然而战术层面再优秀，也很难弥补战略层面的不足。单体系统靠高质量来保证高可靠性的思路，在小规模软件上还能运作良好，但当系统规模越来越大时，交付一个可靠的单体系统就变得越来越具有挑战性。如本书前言所说，正是随着软件架构演进，构建可靠系统的观念从“追求尽量不出错”到正视“出错是必然”的转变，才是微服务架构得以挑战并逐步取代单体架构的底气所在。 P33

• 为了允许程序出错，获得自治与隔离的能力，以及实现可以技术异构等目标，是继性能与算力之后，让程序再次选择分布式的理由。 P33

1.3 SOA时代

列举介绍了三种较有代表性的架构模式：烟囱式架构、微内核(插件式)架构、事件驱动架构。
当架构演化至事件驱动架构时，软件架构来到SOA时代，SOA针对“软件开发”进行了更具体、更系统的探索。然而由于SOPA协议的精密复杂，走向了边缘化的结局。

• 烟囱式架构（Information Silo Architecture）：信息烟囱又名信息孤岛（Information Island），使用这种架构的系统也被称为孤岛式信息系统或者烟囱式信息系统。它指的是一种与其他相关信息系统完全没有互操作或者协调工作的设计模式。 P35

• 微内核架构（Microkernel Architecture）：微内核架构也被称为插件式架构（Plug-in Architecture）。将这些人员、组织、权限等主数据，连同其他可能被各子系统用到的公共服务、数据、资源集中到一块，组成一个被所有业务系统共同依赖的核心（Kernel，也称为Core System），具体的业务系统以插件模块（Plug-in Module）的形式存在，这样也可提供可扩展的、灵活的、天然隔离的功能特性，即微内核架构。
  微内核架构也有局限性，它假设系统中各个插件模块之间互不认识，且不可预知系统将安装哪些模块，因此这些插件可以访问内核中一些公共的资源，但不会直接交互。 P35

• 事件驱动架构（Event-Driven Architecture）：在子系统之间建立一套事件队列管道（EventQueue），来自系统外部的消息将以事件的形式发送至管道中，各个子系统可以从管道里获取、处理的事件消息，新增或者修。如此，每一条消息的处理者都是独立的、高度解耦的，但又能与其他处理者（如果存在其他消息处理者的话）通过事件管道进行交互。 P37

• 当架构演化至事件驱动架构时，软件架构来到SOA时代，SOA针对服务之间的松散耦合、注册、发现、治理，隔离、编排等这些问题，甚至是针对“软件开发”这件事情本身，都进行了更具体、更系统的探索。