读《凤凰架构》
起因
我读《凤凰架构》这本书是想系统化了解一下架构的知识，扩展知识边界。帮助自己更高层次的纵览全局，把握脉络。
以下是读后总结，目前读完整理了第一部分内容，目前进度60/707……
全书总结
尚未读完，第一部分主要以全局的视角，介绍原始分布、单体系统、SOA、微服务、云原生、无服务六个时代。
在软件开发的未来，多种架构风格将会融合互补，“分布式”与“不分布式”的边界将逐渐模糊，两条路线将在云端的数据中心交汇。
详情
自序
- 总结
- 从系统服务出错的必然性开始，引出”构建大规模但可靠的软件系统，是否可行“的思考分析，最后提出从架构层面保证稳定健壮服务的方案
- 详情
- 系统服务不可避免会出错，所以服务本身是不可靠的，允许错误的出现。
- 如何用不可靠的服务构建一个可靠稳定的系统
- 理论上错误积累，系统崩溃
- 反例：大量不可靠的细胞构成遗传迭代的人类
- 整体架构设计有恰当且自动化的错误熔断、服务淘汰和重建机制，即便有问题，也能确保系统稳定可用。
前言
- 总结
- 构建一套可靠的大型分布式系统是叙述主线，并鼓励实践中学习，概括总结了全书每一部分的内容。
- 书籍在线阅读：凤凰架构。
- 详情
- 主线
- “如何构建一套可靠的大型分布式系统”
- 简介五部分内容
- 第一部分 演进中的架构
- 全书的绪论，后文的铺垫。不谈具体的技术，着重介绍软件开发历史中多种主流架构出现的契机、解决的问题以及带来的新缺陷。
- 第二部分 架构师的视角
- 介绍一名架构师应该在架构设计时思考的问题，有哪些主流的解决方案和行业标准做法，各种方案有什么优缺点，不同的解决方法会带来什么不同的影响。
- 第三部分 分布式的基石
- 选择了分布式架构涉及的一系列通用问题的解决思路、方法和常见工具。
- 第四部分 不可变基础设施
- 介绍基础设施不变性的目的、原理与实现途径。
- 第五部分 技术方法论
- 几点与分布式、微服务、架构等相关的相对务虚的话题。
- 第一部分 演进中的架构
- 学习建议
- 实践中学习
- 费曼学习获取反馈
- 主线
第一部分 演进中的架构
第1章 服务架构演进史
- 总结
- 以全局的视角，介绍原始分布、单体系统、SOA、微服务、云原生、无服务六个时代。
- 在软件开发的未来，多种架构风格将会融合互补，“分布式”与“不分布式”的边界将逐渐模糊，两条路线将在云端的数据中心交汇。
- 详情
- 1.1 原始分布式时代
- 总结
- 在原始分布式时代，分布式运算环境”(Distributed Computing Environment，DCE) 中简单透明调用的美好愿景由于现实问题（硬件问题、性能问题）被迫搁浅。时间流逝40年后，微服务架构，分布式系统的设想应用在今天又大行其道了
- 两个原则
- 保持接口与实现的简单性，比系统的任何其他属性，包括准确性、一致性和完整性，都来得更加重要。
- 某个功能能够进行分布式，并不意味着它就应该进行分布式，强行追求透明的分布式操作，只会自寻苦果。
- 总结
- 1.2 单体系统时代
- 总结
- 较系统全面的说明了单体架构的优劣，并阐述了选择分布式的根本原因
- 单体架构
- 优
- 易于开发测试部署
- 纵向代码分层，横向模块扩展、负载均衡都支持
- 劣
- 自治与隔离能力差，出现问题影响全局
- 测试发布更为复杂
- 难以技术异构，实现不够优雅
- 选择分布式的根本原因
- 随着系统的规模越来越大，程序出错是必然。允许错误的发生，获得自治与隔离的能力才是选择分布式的根本原因
- 优
- 总结
- 1.3 SOA时代
- 总结
- 列举介绍了三种较有代表性的架构模式：烟囱式架构、微内核(插件式)架构、事件驱动架构。
- 当架构演化至事件驱动架构时，软件架构来到SOA时代，SOA针对“软件开发”进行了更具体、更系统的探索。然而由于SOPA协议的精密复杂，走向了边缘化的结局。
- 详情
- 三种架构
- 烟囱式架构
- 信息烟囱又名信息孤岛（Information Island）。它指的是一种与其他相关信息系统完全没有互操作或者协调工作的设计模式。
- 微内核架构
- 也被称为插件式架构（Plug-in Architecture）。
- 将这些人员、组织、权限等主数据，连同其他可能被各子系统用到的公共服务、数据、资源集中到一块，组成一个被所有业务系统共同依赖的核心（Kernel，也称为Core System），具体的业务系统以插件模块（Plug-in Module）的形式存在，这样也可提供可扩展的、灵活的、天然隔离的功能特性。
- 微内核架构也有局限性，它假设系统中各个插件模块之间互不认识，且不可预知系统将安装哪些模块，因此这些插件可以访问内核中一些公共的资源，但不会直接交互。
- 事件驱动架构
- 在子系统之间建立一套事件队列管道（EventQueue），来自系统外部的消息将以事件的形式发送至管道中，各个子系统可以从管道里获取、处理的事件消息，新增或者修。如此，每一条消息的处理者都是独立的、高度解耦的，但又能与其他处理者（如果存在其他消息处理者的话）通过事件管道进行交互。
- 烟囱式架构
- 淘汰原因
- SOAP协议被逐渐边缘化的本质原因：
- 复杂：过于严格的规范定义带来过度的复杂性，而构建在SOAP基础之上的ESB、BPM、SCA、SDO等诸多上层建筑，进一步加剧了这种复杂性。
- 过于精密的流程和理论需要懂得复杂概念的专业人员才能够驾驭，很难作为一种具有广泛普适性的软件架构风格来推广。
- 三种架构
- 总结
- 1.4 微服务时代
- 总结
- 介绍微服务的概念，相比于SOA更自由的架构风格，更为开放多元的问题解决方案，列举了微服务的九个核心业务与技术特征。
- 详情
- 微服务概括
- 概念
- 微服务是一种通过多个小型服务组合来构建单个应用的架构风格，这些服务围绕业务能力而非特定的技术标准来构建。各个服务可以采用不同的编程语言、不同的数据存储技术，运行在不同的进程之中。服务采取轻量级的通信机制和自动化的部署机制实现通信与运维。
- 风格
- 微服务追求的是更加自由的架构风格，摒弃了几乎所有SOA里可以抛弃的约束和规定，提倡以“实践标准”代替“规范标准”。
- 评价
- 作为一个普通的服务开发者，作为一个“螺丝钉”式的程序员，微服务架构是友善的。可是，微服务对架构者却是满满的“恶意”，对架构能力的要求已提升到史无前例的程度。
- 概念
- 九个核心的业务与技术特征
- 围绕业务能力构建（Organized around Business Capability）。强调了康威定律的重要性，有怎样结构、规模、能力的团队，就会产生对应结构、规模、能力的产品。
- 分散治理（Decentralized Governance）。服务对应的开发团队有直接对服务运行质量负责的责任，也有不受外界干预地掌控服务各个方面的权力
- 通过服务来实现独立自治的组件（Componentization via Service）。远程服务有更高昂的调用成本，但这是为组件带来自治与隔离能力的必要代价。
- 产品化思维（Product not Project）。微服务下，要求开发团队中每个人都具有产品化思维（个人觉得不切实际），要对软件产品的整个生命周期负责。
- 数据去中心化（Decentralized Data Management）。微服务明确提倡数据应该按领域分散管理、更新、维护、存储。数据库拆分需要在分布式中处理好一致性问题。
- 强终端弱管道（Smart Endpoint and Dumb Pipe）提倡RESTful风格的通信
- 容错性设计（Design for Failure）。接受服务总会出错的现实，在微服务的设计中，有自动的机制对其依赖的服务进行快速故障检测，在持续出错的时候进行隔离，在服务恢复的时候重新联通。
- 演进式设计（Evolutionary Design）。承认服务会被报废淘汰。一个设计良好的服务，应该是能够报废的，而不是期望得到长存永生。
- 基础设施自动化（Infrastructure Automation）。引入CI/CD发展，减少了构建、发布、运维工作的复杂性。
- 微服务概括
- 总结
- 1.5 后微服务时代（即云原生时代）
- 从微服务时代硬件构成的基础设施跟不上软件构成的应用服务的灵活性的无奈现实说起，引出诉求：“通过键盘命令变出相应的硬件设施”；
- Kubernetes取得容器战争的胜利，标志着云原生时代的开启，使得分布式架构问题可以从应用代码与基础设施软件、硬件一体，合力应对。
- 接着说明了Kubernetes的不足，为了实现精细化管理，又引入了今天被称为“服务网格”（Service Mesh）的“边车代理模式”（SidecarProxy），实现了既不需要在应用层面加入额外的处理代码，也提供了几乎不亚于程序代码的精细管理能力。
- 1.6 无服务时代
- 介绍了无服务的简单特性，涉及的两块主要内容：后端设施（Backend）和函数（Function）。
- 无服务架构的计费特点决定了它现在不是、也很难成为一种普适性的架构模式。
- 1.1 原始分布式时代
