凤凰架构-架构演进

周志明《凤凰架构：构建可靠的大型分布式系统》
https://icyfenix.cn/

架构演进，原始分布式时代->单体系统时代->SOA时代->微服务时代->后微服务时代->无服务时代

架构并不是被“发明”出来的，而是持续进化的结果。

整个“演进中的架构”这部分，一条重要的逻辑线索就是软件工业对如何拆分业务、隔离技术复杂性的探索。从最初的不拆分，到通过越来越复杂的技术手段逐渐满足了业务的拆分与协作，再到追求隔离掉这些复杂技术手段，将它们掩埋于基础设施之中，到未来（有可能的）重新回到无需考虑算力、无需拆分的云端系统。

原始分布式时代

Unix的分布式设计哲学：
保持接口与实现的简单性，比系统的任何其他属性，包括准确性、一致性和完整性，都来得更加重要。

20世纪70年代末期到80年代初，计算机科学刚经历了从以大型机为主向以微型机为主的蜕变。当时计算机硬件局促的运算处理能力，已直接妨碍到了在单台计算机上信息系统软件能够达到的最大规模。为突破硬件算力的限制，各个高校、研究机构、软硬件厂商开始分头探索，寻找使用多台计算机共同协作来支撑同一套软件系统运行的可行方案。

当时研究这些技术都带着浓厚的UNIX设计风格，有一个预设的重要原则是使分布式环境中的服务调用、资源访问、数据存储等操作尽可能透明化、简单化，使开发人员不必过于关注他们访问的方法或其他资源是位于本地还是远程。

但是“调用远程方法”与“调用本地方法”两者的复杂度就完全不可同日而语，一旦要考虑性能上的差异，那远程和本地的鸿沟是无比深刻的，两者的速度往往有着数量级上的差距，完全不可调和。

在那个时代的机器硬件条件下，为了让程序在运行效率上可被用户接受，开发者在某些场景只能被迫将几个原本毫无关系的方法打包到一个方法体内，一块进行远程调用，以提升性能。这本身与期望的分布式相矛盾，另外开发者需要时刻注意是在编写分布式程序。最终导致设计向性能做出的妥协，本地与远程无论是编码、设计、部署还是运行效率角度上看，都有着天壤之别。

原始分布式时代的教训：
某个功能能够进行分布式，并不意味着它就应该进行分布式，强行追求透明的分布式操作，只会自寻苦果。

以上结论是有违UNIX设计哲学的，却是当时现实情况下不得不做出的让步。摆在计算机科学面前有两条通往更大规模软件系统的道路，一条是尽快提升单机的处理能力，以避免分布式带来的种种问题；另一条路是找到更完美的解决如何构筑分布式系统的解决方案。

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

单体系统时代

单体意味着自包含。单体应用描述了一种由同一技术平台的不同组件构成的单层软件。

单体架构是出现时间最早、应用范围最广、使用人数最多、统治历史最长的一种架构风格。但“单体”这个名称，却是从微服务开始流行之后，才“事后追认”所形成的概念。在这之前，并没有多少人会把“单体”看成一种架构。

优点：

• 易于开发、易于测试、易于部署
• 进程内的高效交互

缺点：

• 性能要求难以超越单机
• 开发人员规模难以超过“2 Pizza Teams”
• 所有代码运行在同一个进程空间之内，某一个功能一旦出问题（内存泄漏、线程爆炸、阻塞、死循环等），都将会影响到整个程序的运行
• 代码无法隔离，无法做到单独停止、更新、升级某一部分代码
• 无法技术异构（技术异构是说允许系统的每个模块，自由选择不一样的程序语言、不一样的编程框架等技术栈去实现）

单体系统的真正缺陷实际上并不在于要如何拆分，而在于拆分之后，它会存在隔离与自治能力上的欠缺。

单体架构并不会消失，因其架构简单，易于开发测试和部署，适用于项目初始阶段，便于业务的快速上线。

SOA时代

SOA架构模式之前，三种有代表性服务拆分架构模式

1. 烟筒式架构：系统独立，信息孤岛
2. 微内核架构：共享公共主数据，子系统无法直接互通
3. 事件驱动架构：建立事件队列管道，子系统通过管道解耦交互

“面向服务的架构”（Service Oriented Architecture，SOA）的概念最早1994年提出，2006成立OSOA联盟来联合制定和推进 SOA 相关行业标准，2007在OASIS的倡议与支持下，共同新成立了Open CSA组织，管理制定SOA的行业标准。

SOA最根本的目标，就是希望能够总结出一套自上而下的软件研发方法论，它有完善的理论和工具，让企业只需要跟着它的思路，就能够一揽子解决掉软件开发过程中的全套问题。如真如此可以大幅提升整个社会实施信息化的效率。

但遗憾的是，因为SOA架构过于严谨精密的流程与理论，给架构带来了过度的复杂性，需要有懂得复杂概念的专业人员才能够驾驭。它可以实现多个异构大型系统之间的复杂集成交互，却很难作为一种具有广泛普适性的软件架构风格来推广。

微服务时代

“Micro-Web-Service”，指的是一种专注于单一职责的、与语言无关的、细粒度的 Web 服务。

微服务是一种通过多个小型服务的组合，来构建单个应用的架构风格，这些服务会围绕业务能力而非特定的技术标准来构建。各个服务可以采用不同的编程语言、不同的数据存储技术、运行在不同的进程之中。服务会采取轻量级的通讯机制和自动化的部署机制，来实现通讯与运维。

微服务的九个核心的业务与技术特征

1. 围绕业务能力构建：康威定律(有怎样的结构、规模和能力的团队，就会产生出对应结构、规模、能力的产品)
2. 分散治理：谁家孩子谁来管，技术异构
3. 通过服务来实现独立自治的组件：独立、自治
4. 产品化思维：把服务看做持续改进、提升的产品
5. 数据去中心化：数据应该按领域来分散管理、更新、维护和存储
6. 轻量级通讯机制：处理事务、一致性、认证授权等一系列工作应该在服务自己的Endpoint上解决
7. 容错性设计：接受服务总会出错的现实
8. 演进式设计：承认服务会被报废淘汰
9. 基础设施自动化：CI/CD，大大降低了构建、发布、运维工作的复杂性

微服务追求的是更加自由的架构风格，它摒弃了SOA中几乎所有可以抛弃的约束和规定，提倡以“实践标准”代替“规范标准”。

服务的注册发现、跟踪治理、负载均衡、故障隔离、认证授权、伸缩扩展、传输通讯、事务处理等问题，在微服务中，都不再会有统一的解决方案。

Spring Cloud这样的胶水式的全家桶工具集，通过一致的接口、声明和配置，进一步屏蔽了源自于具体工具、框架的复杂性，降低了在不同工具、框架之间切换的成本。

后微服务时代/云原生时代

微服务时代，注册发现、跟踪治理、负载均衡、传输通讯等，这些问题我们都需要在应用服务层面处理，而不是基础设施层面去解决这些分布式问题，完全是因为由硬件构成的基础设施，跟不上由软件构成的应用服务的灵活性。随着虚拟化和容器化技术的发展，这些问题好像都可以解决了。

针对同一个分布式服务的问题，对比下 Spring Cloud 中提供的应用层面的解决方案，以及 Kubernetes 中提供的基础设施层面的解决方案

Kubernetes 的确提供了一条全新的、前途更加广阔的解题思路。

当虚拟化的基础设施，开始从单个服务的容器发展到由多个容器构成的服务集群，以及集群所需的所有通讯、存储设施的时候，软件与硬件的界限就开始模糊了。
原来只能从软件层面解决的分布式架构问题，于是有了另外一种解法：应用代码与基础设施软硬一体，合力应对。

无服务时代

“无服务“与“微服务”和“云原生”并没有继承替代关系，“无服务比微服务更加先进“是的错误想法。

无服务架构简单，分为两块内容

• 后端设施：是指数据库、消息队列、日志、存储等这一类用于支撑业务逻辑运行，但本身无业务含义的技术组件。这些后端设施都运行在云中，也就是无服务中的“后端即服务”（Backend as a Service，BaaS）
• 函数：业务逻辑代码。这里函数的概念与粒度，都已经和程序编码角度的函数非常接近了，区别就在于，无服务中的函数运行在云端，不必考虑算力问题和容量规划

无服务的愿景是让开发者只需要纯粹地关注业务

1. 不用考虑技术组件，因为后端的技术组件是现成的，可以直接取用，没有采购、版权和选型的烦恼
2. 不需要考虑如何部署，因为部署过程完全是托管到云端的，由云端自动完成
3. 不需要考虑算力，因为有整个数据中心的支撑，算力可以认为是无限的
4. 不需要操心运维，维护系统持续地平稳运行是云服务商的责任，而不再是开发者的责任

无服务中短期内的发展局限性

• 与单体架构、微服务架构不同，无服务架构天生的一些特点，比如冷启动、 无状态、运行时间有限制等等，决定了它不是一种具有普适性的架构模式
• 擅长短链接、无状态、适合事件驱动的交互形式，不适用于具有业务逻辑复杂、依赖服务端状态、响应速度要求较高、需要长连接等特征的应用

如果说微服务架构是分布式系统这条路当前所能做到的极致，那无服务架构，也许就是“不分布式”的云端系统这条路的起点。