《凤凰架构》读书笔记（1）--------演进中的架构

服务架构演进史

原始分布式时代

        使用多个独立的分布式服务共同构建一个更大型系统的设想与实际尝试，要比大型单体系统出现的时间更早。

        在20世纪70年代末期到80年代初期，计算机科学刚经历了从以大型机为主向以微型机为主的蜕变，计算机逐渐从一种存在于研究机构、实验室当中的科研设备，转变为存在于商业企业中的生产设备，甚至是面向家庭、个人用户的娱乐设备。但是计算机硬件有限的运算处理能力，已直接影响到了单台计算机上信息系统软件能够达到的最大规模。为突破硬件算力的限制，高校、研究机构、软硬件厂商开始分头探索，寻找使用多台计算机共同协作来支撑同一套软件系统的可行方案。这一阶段是对分布式架构最原始的探索。

        为了避免UNIX系统的版本战争在分布式领域重演，负责制定UNIX系统技术标准的“开放软件基金会”（OSF）邀请了当时业界主流的计算机厂商一起参与，共同制订了名为“分布式运算环境”的分布式技术体系。由于OSF本身的UNIX背景，当时对这些技术的研究都带着浓厚的UNIX设计风格，有一个预设的重要原则是要使分布式环境中的服务调用、资源访问、数据存储等操作尽可能透明化、简单化，从而使开发人员不必过于关注他们访问的方法或其他资源是位于本地还是远程。

        20世纪80年代正是摩尔定律开始稳定发挥作用的黄金时期，微型计算机的性能以每两年增长一倍的惊人速度提升，硬件算计束缚软件规模的链条很快变得松动，信息系统进入以单台或少量几台计算机即可作为服务器来支撑大型信息系统运作的单体时代，且在很长的一段时间内，单体都将是软件架构的绝对主流。

        原始分布式时代提出的构建符合UNIX设计哲学的、如同本地调用一般简单透明的分布式系统的这个目标，是软件开发者对分布式系统最初的美好愿景，但迫于现实，它会在一定时期内被妥协、被舍弃。不过，在30多年后的21世纪10年代，随着分布式架构逐渐成熟、完善，并取代单体成为大型软件的主流架构风格以后，这个美好的愿景终将会重新被开发者拾起。

单体系统时代

        也称作巨石系统。单体架构是今天绝大多数软件开发者都学习、实践过的一种软件架构，是在整个软件架构演进的历史进程里，出现时间最早、应用范围最广、使用人数最多、统治历史最长的一种架构风格，但是“单体”这个名称却是在微服务开始流行之后才事后追认所形成的概念。此前并没有多少人把“单体”看作一种架构。这一方面体现了单体架构本身的简单性，另一方面也体现出在相当长的时间里，大家都已经习惯了软件架构就应该是单体这种样子。

        单体系统不应该被贴上反派角色的标签。单体系统的不足，必须在软件的性能需求超过了单机、软件的开发人员规模明显超过了“2 Pizza Team”（衡量团队大小的量词，指两个披萨能喂饱的人数，大概是6~12人）范畴的前提下才有讨论的价值。

        单体架构并不是不可拆分的。分层架构已是现在所有信息系统建设中普遍认可、采用的软件设计方法，无论是单体还是微服务，都会对代码进行纵向层次划分，收到的外部请求在各层之间以不同形式的数据结构进行流转传递，触及最末端的数据库后按相反的顺序回馈响应。从横向角度看，单体架构也支持按照技术、功能、职责等纬度，将软件拆分为各种模块，以便重用和管理代码。

        单体系统的真正缺陷不在于如何拆分，而在于拆分之后的自治与隔离能力上。由于所有代码都运行再同一个进程内，所有模块、方法的调用都无须考虑网络分区、对象复制这些麻烦的事和性能损失，但在获得进程内调用的简单、高效等好处的同时，也意味着如果任何一部分代码出现缺陷，过度消耗了进程空间内的资源，所造成的影响也是全局性的、难以隔离的。同样，由于所有代码都共享同一个进程，不能隔离，也就无法做到单独停止、更新、升级某一部分代码。从可维护性来说，单体系统也是不占优势的。对于单体系统，在对程序升级、修改时往往需要制定专门的停机更新计划，做灰度发布、A/B测试也相对更复杂。

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

        不过，以上问题不是微服务取代单体系统成为潮流趋势的根本原因，最重要的原因是：单体系统很难兼容“Phoenix”的特性。这种架构风格潜在的要求是希望系统的每一个部件、每一处代码都尽量可靠，尽量不出或少出缺陷。单体系统靠高质量来保证高可靠性的思路，在小规模软件上还能运作良好，但当系统规模越来越大时，交付一个可靠的单体系统就变得越来越具有挑战性。

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

SOA时代

为了对大型的单体系统进行拆分，让每一个子系统都能独立地部署、运行、更新，开发者尝试过很多种方案，这里列举三种较有代表性的架构模式：

• 烟囱式架构。信息烟囱又名信息孤岛，指的是一种与其他相关信息系统完全没有互操作或者协调工作的设计模式。
• 微内核架构。微内核架构也被称为插件式架构。把公共的主数据连同其他可能被各子系统用到的公共服务、数据、资源集中到一块，组成一个被所有业务系统共同依赖的核心，具体的业务系统以插件模块的形式存在，这样也可提供可扩展的、灵活的、天然隔离的功能特性。
• 事件驱动架构。为了能让子系统互相通信，一种可行的方案是在子系统之间建立一套事件队列管道，来自系统外部的消息将以事件的形式发送至管道中。各个子系统可以从管道里获取自己感兴趣、能够处理的事件消息，也可以为事件新增或者修改其中的附加信息，甚至可以自己发布一些新的事件到管道队列中去。如此，每一条消息的处理者都是独立的、高度解耦的，但又能与其他处理者通过事件管道进行交互。