“系统”和“架构”这两个词相对独立而又有机统一。在漫长的岁月里，市场、用户需求、产品功能在变化，技术理论、软硬件性能、人才能力在变化，系统架构也在随着这些变化而进行着持续不断的适应性的演进。
一、原始分布式探索
上世纪70、80年代，大规模集成电路技术发展起来了，让计算机不再是国家机构、科研机构的专属。微型机的应用范围逐渐扩大，产生了工业化、商业化应用的苗头，使得计算机进入了“普惠”时代。
那时候的微机单机硬件性能通常是：
CPU主频5MHz（对比如今的GHz单位的主频）；
16位寻址能力（对比如今的64位）；
几百KB内存（对比如今的GB单位的内存）；
存储设备是打孔纸、磁带、软盘（对比如今的固态硬盘）。
这样的性能连今天绝大多数的边缘设备都比不上，比如快递柜上寄件取件的自助机。所以硬件的局限让大家最先开始探索的就是如何把多台微机协调起来完成一个复杂的事情，即对分布式架构的探索，这可能和很多人的认知相悖——一般都认为对单体架构的讨论发生在分布式架构之前。
探索的结果称不上成功，因为要完成分布式系统内各节点的协调，实现通信、服务发现、数据一致性、等分布式的技术要求也是需要付出代价的，需要专业的知识、极高的编程技巧，需要占用本就不富裕的硬件资源。这样的代价在那个时代太大了，与产生收益无法匹配。
然而对分布式架构的原始探索并也非一无是处，期间也产生的很多分布式技术原型，在如今常用的分布式技术中也能看到它们的影子。
由于这阶段只是不成功的探索过程，严格来说并不能算作是一种架构形态。
二、单体架构
对信息系统处理能力的提高，不外乎两个方向：
其一：提高单机的性能；
其二：增加机器的数量。
上世纪80年代时候对分布式架构的探索证明了第二个方向在那个时代是基本行不通的，所以大家把力气大都使在了突破单机性能这个方向上，造就了“摩尔定律”的出现。随着技术发展，单台微机性能已经达到可以支持信息系统运行的程度。所以单体架构的系统就出现了，并且作为主流持续了很长时间，甚至直到今天也还是很多小型信息系统采用的架构形式。
单体架构系统就是整个在一台机器上运行，完成所有的处理操作的系统。它并不意味着只能有一个整体的程序封装，一开始的时候基本上就是在一个进程里面运行，后面根据功能模块拆分成同一台机器的多个进程运行，也能被认为单体架构系统。
单体架构 ≠ 小、旧和落后
在很多写分布式架构的书里都把单体架构描绘成了旧时代的落后产物，似乎只能用于小型、简单系统，这其实是“屁股决定脑袋”罢了。在前述的对分布式架构的原始探索中，大家很早就认识到了分布式架构是有使用代价的。如果在单机单进程性能就足够强大到能满足系统的运行，并且硬件成本等各种因素都相差不大的时候，不会有人会想舍近求远，付出这些额外的软硬件成本、维护成本、人力成本等代价去折腾一套分布式架构系统。
架构选择也应遵循“猫爪老鼠理论”，能用、够用、好用就行。单体架构也能用于大型系统，一些大型银行的重要系统就是以单体的形式在IBM的大型机、中型机、小型机上稳稳地运行了几十年，每秒处理几千上万笔金融交易。单体架构的不足，更多体现在系统性能需求超过了单机性能，或者单台大型机器的成本远超多台小型机器，或者系统开发维护复杂度或开发维护人员数量超过了一定程度难以管理。
单体架构 ≠ 一团糟
很多人认为单体系统就是什么东西都塞到一起，往往从开发到测试到部署都会是一团糟。但其实单体系统也是可以分层的，在实践中也是这样做的，比如在垂直方向从上到下分为接口层、业务层、持久层、存储层。甚至不必只局限于单一进程内，比如在水平方向可以按功能划分进程，不同组件启动不同进程进行处理。毕竟同一台机器内的进程间通信远远比不同机器间基于网络的进程间通信简单和高效。
单体架构的真正困境
真正让分布式架构成为当今各大企业中大型信息系统主流架构形态的原因并不是简单的服务器硬件性能限制，更重要的是其他考虑：
可靠性和可用性：出错是无法完全避免的，所以信息系统要接受局部出现问题，但要保证全局的服务依然可用且正确，单体架构下显然无法实现（HA热备等内容应在容灾备份的话题内讨论，这里暂不考虑）。
技术异构：单机架构是封闭的，从硬件到操作系统到运行环境再到应用系统，它的技术栈已经固定了。无论是维修更换还是性能升级都只能沿用原来厂商或属于同一套技术体系的部件，相当于被严格绑定了，无法总是获得最适合业务场景、最高性价比的方案。
资源弹性伸缩：系统的服务流量是有周期、有波峰波谷的，按照波峰来设计单机系统显然会造成资源严重浪费，无法把资源及时调配到其他需要的地方。
版本发布和团队管理：企业的业务范围广泛，每个团队负责一部分的业务功能。如果都集中到同一个单机系统中，则每个团队都需要十分了解系统中一些公共的、底层的东西，但其实有很多内容与他们负责的业务功能并无关系。如果每次重新部署单体系统都需要重启进程，每天可能十几二十个来自不同团队的功能上线要求就要重启十几二十次系统，这在对外的服务可用要求和对内的发布变更管理上是绝对不能接受的。
总而言之：
Just because something can be distributed doesn’t mean it should be distributed. （某个系统能够做成分布式，并不意味着它一定要做成分布式）
——《Beyond Buzzwords: A Brief History of Microservices Patterns》
三、分布式架构初阶：SOA架构
架构变迁是一个演进的过程，对单体架构系统的拆分并不是一蹴而就的。首先做的事情是把单体系统中毫无关联的各个模块组件拆分开来，形成单独的小系统，分别部署到不同的机器上，避免结构的杂糅和资源的争抢。这些分散在各个地方的系统没有公共的功能、基本不进行交互，是一种“各玩各的”状态。没有横向联系就像一个又一个高高竖起的烟囱，所以被大家很形象的称为烟囱式架构。
当然在实践中发现完全烟囱式的非常少，这些烟囱式系统中还是有很多可以共用的模块，比如公共参数模块、用户管理模块。显然在企业中为每个烟囱式系统重复构建和部署这些可以共享的模块组件是一种很浪费资源的行为。所以第二步要做的事情是把这些公共模块从各个烟囱式系统中抽象出来，形成一个统一的、公共的核心模块，原本各系统的业务模块就作为插件去使用这个核心模块的公共能力。如此一来既能避免重复造轮子，又能满足各个业务插件之间的自治和隔离。这种形式被称为微内核架构（Microkernel Architecture）。
不过微内核架构在面对变化的时候还是有点不够的，因为每个插件都无法预知其他插件是否在使用、未来是否会被使用，所以每个插件也是封闭和固定的，插件之间难以有效关联，一旦面对需要两个或以上插件共同协作完成某个业务逻辑，就没办法做到了。第三步就是要让这些业务系统之间也能通信交互，通过建立消息队列在各个系统之间形成一条事件队列管道，各个子系统可以往管道里发布事件和抓取其关注的事件进行处理，甚至与公共模块之间的通信也可以同质化成事件来处理。这就是事件驱动架构（Event Driven Architecture， EDA架构）。
系统之间的通信除了可以通过消息队列这种异步方式，也可以使用同步的通信方式，例如HTTP/HTTPS。几乎与事件驱动架构发展的同时，SOAP协议（Simple Object Access Protocol，简单对象访问协议）的诞生成就了面向服务架构（Service Oriented Architecture，SOA架构），让它在21世纪的首个十年风靡一时0。SOA架构就是把系统拆成一个个独立、可复用的 “服务”，通过统一的方式互相调用，搭积木一样构建整个系统，一般由企业服务总线（Enterprise Service Bus，ESB系统）负责各个服务的注册和发现、报文转换和转发等。相比于EDA架构专注于在消息管道中流转的“事件”，SOA架构则以“服务”为中心，强调业务能力封装、标准化接口、可复用。
SOA这个概念其实早在之前就已经被提出了，但是一直没有形成一套统一的远程调用标准，大家都在各玩各的，直到SOAP协议的出现。当然SOA架构并不只是局限于使用SOAP协议，还有其他的实现方式，只是因为SOAP的历史意义造就了它的影响力。
EDA和SOA之间的区别：
四、分布式架构二阶：微服务架构
其实上面所说的SOA架构已经足够优秀、足够规范化地在大型信息系统的建设中应用了，为什么只是在21世纪前十多年风靡了一阵而后就被盖过热度了呢？其实恰恰是因为它太过标准、太过规范了：
有效数据传输效率很低：SOAP协议使用的是XML格式承载传输的数据，用过XML格式文件的人都知道，为了规范数据定义格式，往往要用上很多冗余的标签字符；
服务总线有成为单点故障的风险：SOA架构基本上所有服务都要经过ESB进行报文解析、转换、转发，造成了ESB逐渐成为了最核心的组件。其重要程度甚至超过了承担主要业务的系统，一旦实效会有全局服务崩溃的危险；
整套规范用起来太沉重和复杂：SOAP协议真正用起来不单单只有SOAP，通常还搭配了WSDL、UDDI等等一整套规范，用起来实在太过重了、约束太多，团队的学习成本、维护成本实在高昂。
The microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms (often an HTTP resource API). These services are built around business capabilities, independently deployable by fully automated deployment machinery, with a bare minimum of centralized management. They may be written in different programming languages and use different data storage technologies. （微服务是一种通过多个小型服务组合来构建单个应用的架构风格，这些服务围绕业务能力而非特定的技术标准来构建。各个服务可以采用不同的编程语言、不同的数据存储技术，运行在不同的进程之中）
——《Microservices：A Definition of This New Architectural Term》
有人认为微服务架构（Microservice Architecture）其实是SOA架构的一种变体，有人认为它虽然和SOA架构一样都是关注“服务”但本质已经完全变了，是一种全新的架构形态。本文就不纠结这点了，无论是否属于SOA架构的变体，微服务架构都是分布式架构演进过程中浓墨重彩的一笔。
对微服务架构的定义最体系化的就是以上引用的这篇文章《Microservices：A Definition of This New Architectural Term》发表于2014年，其中提出的9大特质定义我认为对微服务架构设计具有很高的指导性意义，这里不展开了感兴趣的可以自己去查阅：
Componentization via Services (Not Libraries)--通过服务而非库来实现组件化
Organized Around Business Capabilities (Not Technical Layers)--围绕业务能力而非技术层次去设计
Products, Not Projects--产品思维而非项目思维
Smart Endpoints & Dumb Pipes--强终端而弱管道
Decentralized Governance--分散治理
Decentralized Data Management--去中心化的数据管理
Infrastructure Automation--基础设施自动化
Design for Failure--为面对故障而设计
Evolutionary Design--演进式设计
可以发现微服务架构挣脱了SOA架构诸多标准规范的约束，比如只要能实现服务注册和发现，用Nacos、Consul、Zookeeper等哪种注册中心都可以；只要能实现服务远程调用，用REST、gRPC、Dubbo等哪种框架都可以，它践行的正是“抓老鼠的好猫”理念。这让开发人员用起来非常舒服，在熟悉了一种微服务生态后的开发工作复杂度没有原来那么高。但是却又让架构师抓狂，原本SOA架构只需要掌握小范围的知识，现在却要什么都懂才可能在架构设计、组件选型时获得正确的解决方案，你看前面列举的服务注册和发现组件、远程调用框架都不止一款两款了。
五、分布式架构进阶：云原生架构
微服务架构已经基本完善了，但还能再进一步拆分。大家发现了其实用于维护微服务系统集群的底层硬件、操作系统、网络其实不需要每个服务自己去管理他们的全生命周期，注册发现、负载均衡、通信传输、状态监控等分布式系统的基础功能也可以从每个微服务中进一步拆分出来，在一个统一的地方进行处理，由一套专业的团队进行维护。
得益于以Docker和Kubernates为代表的容器技术的发展，和云计算技术的发展，这个目标正在被实现并逐渐成熟。例如K8s的KubeDNS就可以承担服务注册发现的功能；Ingress Controller就可以承担技术网关的功能；Load Balancer就可以承担负载均衡的功能。又例如打开主流云服务供应商的产品目录，可以看到微服务引擎、API网关、MySQL数据库、Redis缓存、应用监控服务等已经封装好的分布式基础组件。这些基础的功能对开发者来说越来越透明，开发人员只需要简单的配置地址、端口等参数就能用起来。
这种依托容器化技术和云计算技术的架构模式被称为云原生架构（Cloud Native Architecture）。近年来比较兴起的服务网格也属于云原生架构的一种，业务逻辑和技术层面进一步分离，通信等底层技术进一步透明化。
六、无服务架构
云计算技术的广泛应用已经十多年了，通过不断下沉技术能力，各大云服务提供商先后推出了无服务产品，基于这种产品实现的就是无服务架构（Serverless Architecture）。无服务架构下业务与技术完全剥离，开发人员只需要写好业务处理用的函数并上传，就能直接自动生成生成访问地址以供外部访问，而不需要关注系统状态、扩容缩容等技术层面的内容。这时候根本就不用再关注是集中的还是分布的了，所以兜兜转转还是回来了不是吗？
虽然Serveless概念从2012年提出到现在已经十多年了，但是并没有被大规模运用，因为目前看来还是有其局限性的。我认为最大的问题是它目前很难支持复杂的交互，也就难以嵌入复杂的业务流程中，基本只能面向一些静态的咨询网站、小程序等的开发。不管怎么说，它还处在一个应用化探索的阶段，后续能否发展起来可以持续关注。
写在最后
架构是一个演进的过程，每一次演进都是为了解决一些现实问题。通过对架构形态的发展历程的粗浅了解，也能在一定程度上理解架构的深层次哲学。
如果你对系统架构设计有不一样的理解希望和我探讨，如果你希望对使用中的信息系统架构进行优化但无从下手，欢迎联系我一起探讨。