你好，我是看山。
前面我们聊了微服务的话题，现在微服务已经是业内通识。但凡系统开发、系统设计，必然采用微服务架构，或者宣称是微服务架构。
但大家有没有想过，微服务架构不是一开始就有的。如果追溯历史，微服务最早在 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，Service-Oriented Architecture）。
SOA 在 1994 年就被提出，这种架构风格是自然演化来的。只不过当时没有足够的条件支持，一直只能处于理论阶段。后来随着 webservice 等技术的提出，才有了技术支撑。到 2006 年，OSOA 成立，共同指定 SOA 架构相关行业标准，这套架构有了理论、技术、规范等一系列约定，从而真正落地。
SOA 架构开疆拓土，开创了很多目前也在使用的概念，比如服务注册/发现、服务治理、系统隔离、服务编排等。是不是觉得这些概念很熟悉，是的，在微服务架构中，同样有这些概念的身影。SOA 架构又自己的一套风格，使用下面一些组件实现普适的方法论：
采用 SOAP 作为远程调用的协议；
利用 ESB（Enterprise Service Bus，企业服务总线）实现各个子系统之间的通信交互；
使用 BPM（Business Process Management，业务流程管理系统）实现业务流程编排；
使用 SDO（Service Data Object，服务数据对象）来访问和表示数据；
使用 SCA（Service Component Architecture，服务组件架构）来定义服务封装的形式和服务运行的容器；
……
SOA 架构是各大软件服务商共同愿景下的产物，总结出了一套自上而下的软件研发方法论，期望能够解决软件开发过程中的所有问题。有些类似于八股文，规定好起承转合，只要按照要求来，系统就不会出现太多问题。
愿景虽好，但是却忽略了一点，一套大而全的架构体系，不是所有公司都能够支撑起来的。有时候，大而全不如小而美。但是，我们不能否认 SOA 架构对于面向服务理论的贡献，在某些场景下的企业内部，SOA 是能够快速打破信息孤岛的重要手段。
另立门户的微服务架构
本来是作为 SOA 的一种简化方案，结果直接发动宣武门之变，逼着 SAO 禅让。
如开篇所说，微服务架构是在 2005 年提出，在 2014 年崛起。经历了将近 10 年的时间，之所以没有得到太多重视，是因为 2014 年之前，微服务只是在作为 SOA 架构的简化版出现。直到 2014 年才作为独立的架构风格，与 SOA 架构划清界限。
Martin Fowler 与 James Lewis 在合写的 《Microservices》 对微服务下了定义：“微服务是一种通过多个小型服务组合来构建单个应用的架构风格，这些服务围绕业务能力而非特定的技术标准来构建。各个服务可以采用不同的编程语言，不同的数据存储技术，运行在不同的进程之中。服务采取轻量级的通信机制和自动化的部署机制实现通信与运维。”
文中还提出了微服务架构的 9 个核心特征：
通过服务来实现独立自治的组件（Componentization via Services）
围绕业务能力构建（Organized around Business Capability）
产品化思维（Products not Projects）
强终端弱管道（Smart Endpoint and Dumb Pipe）
分散治理（Decentralized Governance）
数据去中心化（Decentralized Data Management）
基础设施自动化（Infrastructure Automation）
容错性设计（Design for Failure）
演进式设计（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 架构、微服务架构、无服务架构的适用场景，作为架构师，我们在选择架构师，不应该一味追求主流，也不能盲从大厂的思路。我们要根据自身情况权衡利弊，找到适合的架构风格。
推荐阅读
什么是微服务？
微服务编程范式
微服务的基建工作
微服务中服务注册和发现的可行性方案
从单体架构到微服务架构
如何在微服务团队中高效使用 Git 管理代码？
关于微服务系统中数据一致性的总结
实现DevOps的三步工作法
系统设计系列之如何设计一个短链服务
系统设计系列之任务队列
软件架构-缓存技术
软件架构-事件驱动架构
