你好，我是看山。

前面我们聊了微服务的话题，现在微服务已经是业内通识。但凡系统开发、系统设计，必然采用微服务架构，或者宣称是微服务架构。

但大家有没有想过，微服务架构不是一开始就有的。如果追溯历史，微服务最早在 2005 的云计算博览会，由 Peter Rodgers 博士提出（那时候称为微 Web 服务（Micro-Web-Service））。到了 2014 年，Martin Fowler 与 James Lewis 共同提出微服务（Micron-Service）的概念，算是对概念归纳总结，天下一统。这一年也被称为微服务元年。

看山的小屋

那就要问了，在 2014 年之前呢？大家用啥架构？再往前呢？上次互联网大潮的时候，大家又是用啥？我们今天来聊聊这段历史，可能你会对现在习以为常的架构，产生一些新的看法。在架构上，可以有更多的选择。

人人喊打的单体架构

单体架构，人人都说这种架构不好，为什么不好呢？真的不好吗？可能真相并不是你认为的那样简单。

当前来说，如果有人说某个系统是单体架构，一定会有人投来怀疑的眼神，有的会带着些许不可思议，甚至带有一丝鄙夷。但是不得不说，单体架构（又称巨石系统，Monolithic）是整个软件发展过程中，出现时间最早、应用范围最广的一种架构风格。从另一个方面，原来本没有单体架构这个称呼，只是后来有了微服务架构，为了区分，才把所有“自包含”的系统称为单体架构。

人人喊打的单体架构构

上面这个图就是单体架构，所谓“自包含”，简单说就是自给自足，所有业务功能靠自己，不依赖其他业务系统。其优点有下面这些：

• 不涉及进程间通信，效率可控；

• 不依赖网络通讯，可以规避不可靠的网络通讯带来难以预知的故障；

• 开发生态良好，目前的 IDE 对单体架构的支持更好；

• 编码重构容易，单体架构完全的自控制，只要修改自己即可，不需要上下游支持；

• 端到端测试简单，因为没有上下游依赖，测试起来更加方便，部署一套环境，就可以实现当前功能的完全测试；

• 部署简单，只要打包成 EAR、WAR、JAR 等需要的运行包，扔进服务器就能跑；

• 运维简单，一个进程运行的服务，无论是日志还是运行态，都能够很简单的监控；

• 横向扩展容易，前面一个负载均衡器做代理，后面可以无限扩展。

从这个角度，只要单机优势明显，就不该把单体架构视为地狱。

所谓“成也萧何败也萧何”，统一“集中”成就了单体架构，难以“隔离”也成为了单体架构最大的弊端。这里将隔离简单分为开发期隔离和运行期隔离。

单体架构省去了进程间通信、性能损失这些麻烦事，但因为在一个进程中执行，如果内部的某处逻辑异常，可能会造成整个系统的崩溃。最常见的内存溢出，可能仅仅是一个不相干的功能查了全表，整个系统都都会宕掉。

系统崩溃

运行期没有办法隔离，升级的时候也没有办法隔离。想要对某些模块功能升级，只能重启整个服务。还要担心会不会有没有覆盖测试的点，提前做好预案，挂好停机维护页。

因此，一个成功的单体架构系统隐含了一个要求，需要一个对系统完全了解的大脑（一个人或一组人），大脑可以总控系统的开发、升级、运行，把控这个系统的每个细节，实现系统中的各个组件、模块有很高的品质，从而保障系统可在其生命周期内可以稳定的运行。

比如，SAP 和 Hyperion，妥妥的单体架构，作为国际化的软件公司，为什么不对它们升级改造？是能力不行，还是技术不行？是没有必要。所以，单体架构也不是一无是处，一切都要在合适的前提下评价。

开疆拓土的 SOA 架构

都说 SOA 架构太重，但他是开创服务化江山的鼻祖。

开疆拓土的 SOA 架构

单体架构对团队的要求较高，随着团队的扩大，必然会有短板或薄弱的环节，或者是组织、或者是个人，这样就会给系统代理风险。于是，很多前辈就开始思考，一个庞然大物难以维护，那就分为治之，拆分成多个规模小一些的单体架构，彼此之间通过某种方式交互。这种方案被称为面向服务架构（SOA，Service-Oriented Architecture）。

SOA 在 1994 年就被提出，这种架构风格是自然演化来的。只不过当时没有足够的条件支持，一直只能处于理论阶段。后来随着 webservice 等技术的提出，才有了技术支撑。到 2006 年，OSOA 成立，共同制定 SOA 架构相关行业标准，这套架构有了理论、技术、规范等一系列约定，从而真正落地。

SOA 架构开疆拓土，开创了很多目前也在使用的概念，比如服务注册/发现、服务治理、系统隔离、服务编排等。是不是觉得这些概念很熟悉，是的，在微服务架构中，同样有这些概念的身影。SOA 架构有自己的一套风格，使用下面一些组件实现普适的方法论：

1. 采用 SOAP 作为远程调用的协议；

2. 利用 ESB（Enterprise Service Bus，企业服务总线）实现各个子系统之间的通信交互；

3. 使用 BPM（Business Process Management，业务流程管理系统）实现业务流程编排；

4. 使用 SDO（Service Data Object，服务数据对象）来访问和表示数据；

5. 使用 SCA（Service Component Architecture，服务组件架构）来定义服务封装的形式和服务运行的容器；

6. ……

SOA 架构是各大软件服务商共同愿景下的产物，总结出了一套自上而下的软件研发方法论，期望能够解决软件开发过程中的所有问题。有些类似于八股文，规定好起承转合，只要按照要求来，系统就不会出现太多问题。

愿景虽好，但是却忽略了一点，一套大而全的架构体系，不是所有公司都能够支撑起来的。有时候，大而全不如小而美。但是，我们不能否认 SOA 架构对于面向服务理论的贡献，在某些场景下的企业内部，SOA 是能够快速打破信息孤岛的重要手段。

另立门户的微服务架构

本来是作为 SOA 的一种简化方案，结果直接发动宣武门之变，逼着 SAO 禅让。

另立门户的微服务架构

如开篇所说，微服务架构是在 2005 年提出，在 2014 年崛起。经历了将近 10 年的时间，之所以没有得到太多重视，是因为 2014 年之前，微服务只是在作为 SOA 架构的简化版出现。直到 2014 年才作为独立的架构风格，与 SOA 架构划清界限。

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

文中还提出了微服务架构的 9 个核心特征：

1. 通过服务来实现独立自治的组件（Componentization via Services）
2. 围绕业务能力构建（Organized around Business Capability）
3. 产品化思维（Products not Projects）
4. 强终端弱管道（Smart Endpoint and Dumb Pipe）
5. 分散治理（Decentralized Governance）
6. 数据去中心化（Decentralized Data Management）
7. 基础设施自动化（Infrastructure Automation）
8. 容错性设计（Design for Failure）
9. 演进式设计（Evolutionary Design）

由于微服务架构是从 SOA 架构中演化而来，所以很多的表现形式都是一致的。从《Microservices》对微服务架构全面细致阐述之后，也算是将微服务架构与 SOA 架构彻底划清界限。

在笔者看来，微服务架构与 SOA 架构最大的不同在于对于实现的约束，SOA 架构有一套完整的规约，微服务架构只有建议，追求的是根据实际情况自由变化，简单的理解就是“想怎么玩就怎么玩”。比如通信协议，SOA 架构明确要求使用 SOAP 通信协议；微服务架构只要求使用轻量级的 RPC 协议，这个选择就比较宽泛了，常见的就有 HTTP（一般采用 Restful 风格）、gRPC、Dubbo、Thrift、Motan2 等等。

自由意味着可以根据实际情况变化，需要什么引入什么，哪种技术能更好的解决问题就使用哪种技术。在 Java 栈中，也出现了 SpringCloud Netflix 和 SpringCloud Alibaba 之类的全家桶组件，作为开发者，只需要在需要的时候添加依赖即可。

从架构师的角度，自由带来的是约束力的下降，同时也缺少了规约的指导性。我们需要更加了解系统本身，也要更加了解各种技术的优缺点，才能够在架构设计时，更好的权衡利弊，做好取舍。加油，少年。

架构师养成计划

我们来看下微服务中的基础组件：弹性伸缩、服务发现、配置中心、服务网关、负载均衡、服务安全、跟踪监控、降级熔断等等，其实从本质来说，这些组件都是业务无关的。实现软件开发过程中，可以将这些与业务隔离开，也就是所谓的“透明化”。

比如服务发现，可选的方案包括 Nginx、HAProxy、DNS、Eureka、Nacos、KubeDNS，但是我们真的关心吗？不需要，只需要知道我们要进行网络调用，有一个目标即可，至于这个目标是通过哪种方式发现、传输、寻址，都与我们要实现的功能无关。那就将服务发现与业务剥离，通过承载服务的运行环境处理。这就是所谓的边车模型。

边车模型

微服务之所以应用普及，不仅仅在于其独特优势，还与容器化技术的普及有密切关系。微服务与 Docker 虚拟化的高效结合，相当于给了微服务二次加速的动力，资源调度 Kubernetes 的成功，可以认为是直接实现了曲速推进。先进的理念还需要先进的技术实现。

有待成熟的无服务架构

又想要快，还想要简单。那就不要服务了，随便写个函数跑跑得了。

有待成熟的无服务架构

就目前而言，绝大部分的系统开发都是为了解决业务问题。在这个过程中，我们需要选择一些业务无关的技术组件。有时候，我们受限于研发环境，需要的某种技术组件不存在时，需要采购部署，或者使用替代方案。这就会分散我们的注意力。

于是，很多云服务商提出了无服务架构。无服务架构将系统开发涉及的资源分为两部分：后端设施（Backend）、函数（Function），对应的就是 BaaS（Backend as a Service，后端即服务）和 FaaS（Function as a Service，函数即服务）。

这种不能算是架构风格，只能算是一种系统开发过程中的美好愿景。让开发者只需要关注业务，需要的基础设施全部由云服务提供，不需要考虑运行容器、基础设施的部署、服务器运行能力等。只要将开发好的代码上传，就可以拥有一个可运行的系统。

但是愿景虽好，但是与自己掌控部署的区别仅在于对于基础设施的管控程度上。除非出现重大变革，否则这种架构很难像微服务架构一样普适。但是对于小程序、小型 web 网站、咨询平台等模板化的小型系统，采用这种架构还是有很大优势的。

文末总结

本文从架构演进的角度分析了单体架构、SOA 架构、微服务架构、无服务架构的适用场景，作为架构师，我们在选择架构师，不应该一味追求主流，也不能盲从大厂的思路。我们要根据自身情况权衡利弊，找到适合的架构风

原文链接：https://juejin.cn/post/7054205571511091208