服务架构演进史
本文大部分内容摘录自《凤凰架构：构建可靠的大型分布式系统》。
前言
架构并不是被发明出来的，而是持续演进的结果。
从大型机（Mainframe）、原始分布式（Distributed）、大型单体（Monolithic）、面向服务（Service-Oriented）、微服务（Microservice）、服务网格（Service Mesh）到无服务（Serverless）等，技术架构确实呈现出"从大到小"的发展趋势。
在《凤凰架构》作者看来，架构演变最重要的驱动力，或者说这种"从大到小"的变化趋势的最根本驱动力，始终都是为了方便某个服务能够顺利的"死去"与"重生"。个体服务的生死更迭，是关系到整个系统能否可靠存续的关键因素。
不同的架构风格，其区别是到底要在技术规范上提供统一的解决方案，由应用系统自行解决，还是在基础设施层面将这类问题隔离掉。
原始分布式时代：
20世纪70年代末期到80年代初，计算机科学刚经历了从以大型机为主向以微型机为主的蜕变。此时微型机硬件处理能力有限，为突破硬件算力的限制，高校、研究机构、软硬件厂商开始分头探索，寻找多台计算机共同协作来支持同一套软件系统的可行方案。
这一阶段是对分布式架构最原始的探索。
譬如：
- 惠普公司提出的网络运算架构（Network Computing Architecture，NCA）是未来远程服务调用的雏形。
- 卡内基·梅隆大学提出的AFS是日后分布式文件系统的最早实现。
- 麻省理工学院提出的Kerberos协议是服务认证和访问控制的基础性协议，也是分布式服务安全性的重要支撑。
6.x 版本 Kerberos 的工作方式
为避免UNIX系统的版本战争在分布式领域重演，国际开放标准组织邀请了当时业界主流的计算机厂商一起参与，共同制订了名为"分布式运算环境（DCE）"的分布式技术体系。包含了一套相对完整的分布式服务组件规范和参考实现。与后来Sun公司提交的ONC RPC被认为是现代RPC的共同鼻祖。
DCE中提出的分布式服务的设计主旨：开发人员能够透明地调用服务或访问资源，而不需要关心服务是本地还是远程。通过这种松耦合的设计，我们可以更高效地实现服务复用与业务创新。
现在程序中常用的通用标识符UUID也是在DCE中发明出来的。
**原始分布式时代的教训：**某个功能能够进行分布式，并不意味着它就应该进行分布式，强行追求透明的分布式操作，只会自寻苦果。
单体系统时代
来到了20世纪80年代，摩尔定律开始发挥作用，微型计算机的性能以每两年增长一倍的惊人速度提升，信息系统进入以单台或少量几台计算机即可作为服务器来支撑大型信息系统运作的单体时代，在很长的一段时间内，单体都将是软件架构的主流。
对于小型系统，单台机器就足以支撑其良好运行的系统。易于开发、测试、部署，不会发生进程间通信（Inter-Process Communication, IPC）。
单体系统的不足，必须在软件的性能需求超过了单机、软件的开发人员规模明显超过了"2 Pizza Team"范畴的前提下才有讨论的价值。
单体意味着包含。单体应用描述了一种由同一技术平台的不同组件构成的单层软件。
分层架构已是现在所有信息系统建设中普遍认可、采用的软件设计方法，无论是单体还是微服务，抑或是其他架构风格，都会对代码进行纵向层次划分，收到的外部请求在各层之间以不同形式的数据结构进行流转传递，触及最末端的数据库后按相反的顺序回馈响应。
在"拆分"这方面，单体系统的真正缺陷不在如何拆分，而在拆分之后的自治与隔离能力上。
对于单体系统，在对程序升级、修改时往往需要定制专门的停机更新计划，做灰度发布、A/B测试也相对更复杂。
由于隔离能力的缺失，单体除了难以阻断错误传播、不便于动态更新程序以外，还面临难以技术异构的困难，每个模块的代码通常都需要使用一样的程序语言，乃至一样的编程框架去开发。
构建可靠系统的观念从"追求尽量不出错"到正视"出错是必然"的转变，才是微服务架构得以挑战并逐步取代单体架构的底气所在。
SOA时代
人们曾探索过几种服务拆分方法，将一个大的单体系统拆分成为若干个更小的、不运行在同一个进程的独立服务，这些服务拆分方法为后来带来了面向服务架构（Service-Oriented Architecture）的一段兴盛期，我们称其为"SOA时代"。
对于大型单体系统的拆分，有三种代表性的架构模式：
烟囱式架构
Information Silo Architecture：信息烟囱又名信息孤岛。
所谓烟囱式架构，也就是垂直项目体系结构，每当公司内部启动一个项目时，所有的服务都是从底层开始建立的。这样导致公司内部不同的项目不共享资源，更不能互相访问调用资源，这样的项目像烟囱一样树立在公司内，每个项目变成一个个的资源孤岛和信息孤岛。
这种架构导致底层服务的重复建设，并大大增加了开发时间。
微内核架构
Microkernel Architecture：又称插件式架构（Plug-in Architecture）
业务系统以插件模块的形式存在，这样也可提供可扩展的、灵活的、天然隔离的功能特性，即微内核架构。
微内核架构也有局限性，它假设系统中各个插件模块之间互不认识，且不可预知系统将安装哪些模块，因此这些插件可以访问内核中一些公共的资源，但不会直接交互。
和管道-过滤器风格一样属于扩展性架构风格。通过插件向核心应用添加额外的功能，提供了可扩展性，也可以实现功能的独立和分离。微内核架构包含两部分组件，即内核系统 和插件。微内核架构的内核系统通常提供系统运行所需的最小功能集，插件是独立的组件，包含特定的处理，额外的功能和自定义代码，用来向内核系统增强或扩展额外的业务能力。
Dubbo中SPI机制就是微内核架构中扩展性解决思路的实现。
事件驱动架构
Event-Driven Architecture：为了让子系统互相通信，一种可行的方案是在子系统之间建立一套事件队列管道（Event Queue），来自系统外部的消息将以事件的形式发送至管道中。
事件驱动架构可以帮助你将一系列事件衔接在一起，以完成完整的功能流程。
事件驱动架构在给软件带来好处的同时，又会增加额外的复杂性，比如调试的困难性，又比如并不直观的最终一致性。
SOA
SOA的概念最早由Gartner公司在1994年提出，当时的SOA还不具备发展的条件，直到2006年IBM、Oracle、SAP等公司共同成立了OSOA联盟，用于制定和推进SOA相关行业标准。
2007年，在结构化资讯标准促进组织的倡议与支持下，OSOA由一个软件厂商组成的松散联盟，转变为一个制定行业标准的国际组织，并联合OASIS共同新成立了Open CSA组织，这便是SOA的官方管理机构。
SOA理念最核心的价值：
- 松耦合的服务带来业务的复用。
- 通过服务的编排助力业务的快速响应和创新。
当架构演化至事件驱动架构时，并行发展的远程服务调用也迎来了SOAP协议的诞生。
SOAP协议被边缘化的本质原因：过于严格的规范定义带来过度的复杂性，而构建在SOAP基础之上的ESB、BPM、SCA、SDO等诸多上层建筑，进一步加剧了这种复杂性。
微服务时代
微服务是一种软件开发技术，是SOA的一种变体。
"微服务"这个技术名词最早在2005年被提出，2014年真正崛起。
Martin Fowler的文章定义了微服务的概念：微服务是一种通过多个小型服务组合来构建单个应用的架构风格，这些服务围绕业务能力而非特定的技术标准来构建。各个服务可以采用不同的编程语言、不同的数据存储技术，运行在不同的进程之中。服务采用轻量级的通信机制和自动化的部署机制实现通信和运维。
文中列举了微服务九个核心的业务与技术特征：
- 围绕业务能力构建：有怎样结构、规模、能力的团队，就会产生对应结构、规模、能力的产品。
- 分散治理：服务对应的开发团队有直接对服务运行质量负责的责任，也有不受外界干预地掌控服务各个方面的权利。
- 通过服务来实现独立自治的组件：通过远程服务来提供功能。
- 产品化思维：避免把软件研发视作要去完成某种功能，而是视作一种持续改进、提升的过程。
- 数据去中心化：如果使用中心化存储，所有领域都必须修改和映射到同一个实体之中，这很可能使不同服务相互影响而丧失独立性。
- 强终端弱管道：数据处理、业务逻辑尽量靠近终端，通信管道应尽量简单。
- 容错性设计：能够有自动的机制对其依赖的服务进行快速故障检测，在持续出错的时候进行隔离，在服务恢复的时候重新联通。
- 演进式设计：容器性设计承认服务会出错，演进式设计则承认服务会被报废淘汰。一个良好的服务，应该是能够报废的，而不是期望得到长存永生。
- 基础设施自动化：CI/CD的长足发展，显著减少了构建、发布、运维工作的复杂性。
微服务追求的是更加自由的架构风格，摒弃了几乎所有SOA里可以抛弃的约束和规范，提倡以"实践标准"代替"规范标准"。
后微服务时代
一旦虚拟化的硬件能够跟上软件的灵活性，那些与业务无关的技术性问题便有可能从软件层面剥离，悄无声息的在硬件基础设施之内解决，让软件得以只专注业务，真正围绕业务能力构建团队与产品。
服务网格也将会成为微服务之间通信交互的主流模式，把"选择什么通信协议""怎样调度流量""如何认证授权"之类的技术问题隔离于程序代码之外，取代今天Spring Cloud全家桶中大部分组件的功能。
服务网格（网图）
无服务时代
2012年Iron.io公司率先提出了无服务的概念。
无服务涉及两块内容：后端设施和函数。
后端设施：指数据库、消息队列、日志、存储等这类用于支撑业务逻辑运行，但本身无业务含义的技术组件，这些设施都运行在云中，在无服务中将它们称为"后端即服务"。
函数：指业务逻辑代码，函数运行在云端，不必考虑算力问题，也不必考虑容量规划，在无服务中将其称为"函数即服务"。
无服务的愿景是让开发者只需要纯粹的关注业务：不需要考虑技术组件，不需要考虑如何部署，不需要考虑算力，不需要考虑运维。
无服务架构
小结
服务架构的演进不仅是技术发展的见证，更是业务需求不断变化的缩影。从单体架构到微服务，再到事件驱动与 Serverless，每个阶段都推动了灵活性、扩展性和敏捷性的发展。未来，智能化架构优化和无边界计算环境等趋势，将进一步塑造架构的形态和能力。
理解每种架构的出现意义与被淘汰的原因，是为了解决当下的现实问题，同时探索未来架构演进的可能路径。知其然，更要知其所以然，唯有如此，才能在架构设计和演进中把握核心本质，助力技术发展与业务腾飞。
参考资料
- 《凤凰架构：构建可靠的大型分布式系统》
本文由mdnice多平台发布