【服务化架构】SOA和微服务架构、灵活架构

---

导读

SOA和微服务是服务化架构的两种实现方式，服务化架构是一种分布式架构。

SOA和微服务的关系区别很容易分不清楚，所以本文将二者放在一起整理。

最后的"灵活架构"，则简单了表述了我对如何设计一个自定架构的观点。

---

一、SOA

SOA 架构（Service-Oriented Architecture），即面向服务的架构。定义了一种通过服务接口使软件组件可重用和互操作的方法。服务使用通用的接口标准和架构模式，因此它们可以迅速地被纳入新的应用程序。 这就免除了应用程序开发人员的任务，因为他们以前要重新开发或重复现有的功能，或必须知道如何与现有功能连接或提供互操作性。
SOA中的每个服务都体现了执行一个完整的、独立的业务功能所需的代码和数据。服务接口提供了松散的耦合，这意味着它们可以在很少或根本不知道下面的服务是如何实现的情况下被调用，从而减少应用程序之间的依赖性。
(摘自 IBM, What is SOA)

我搜索了几个比较权威的平台，发现SOA似乎并没有十分明确统一的标准和定义

IBM, What is SOA
W3C, SOA
redhat, What is service-oriented architecture (SOA)?
geekforgeeks, Service-Oriented Architecture
wiki, Service-oriented architecture
这个问题在wiki中也有提到

最终以 wiki和geekforgeeks中的描述 结合出如下 —— SOA的指导原则

• 标准化服务契约：服务遵守标准通信协议，通过一份或多份服务描述文件来规定
• 服务松耦合：服务被设计成独立的组件，保持着对其他服务的依赖性最小的关系。
• 服务抽象：对消费者来说，服务是一个黑匣子，即它们内部逻辑对消费者是隐藏的。
• 服务自治：服务对其封装的逻辑有控制权，从服务消费者的角度来看，没有必要了解其实现。
• 服务可重用性：逻辑被划分为各种服务，可以更有效地被重用，从而减少开发时间和相关成本。
• 服务可发现性：服务由构成补充元数据的描述文档来定义，通过这些文档可以有效地发现服务。服务发现提供了利用第三方资源的有效手段。
• 服务可组合性：服务可以用于组合其它服务。可以实现更复杂的操作。

只要我们在架构设计的时候符合这些思想即是SOA。
SOA旨在解决"如何使用多个独立的分布式服务共同构建一个更大型系统"，是一次具体地、系统性地成功解决分布式服务主要问题的架构模式。

发展过程 (凤凰架构, SOA 时代)
SOA 的概念最早由 Gartner 公司在 1994 年提出，当时的 SOA 还不具备发展的条件。直至 2006 年情况才有所变化，由 IBM、Oracle、SAP 等公司共同成立了 OSOA 联盟（Open Service Oriented Architecture），用于联合制定和推进 SOA 相关行业标准。2007 年，在结构化资讯标准促进组织（Organization for the Advancement of Structured Information Standards，OASIS）的倡议与支持下，OSOA 由一个软件厂商组成的松散联盟，转变为一个制定行业标准的国际组织，联合 OASIS 共同新成立了的Open CSA组织（Open Composite Services Architecture），这便是 SOA 的官方管理机构。
软件架构来到 SOA 时代，许多概念、思想都已经能在今天微服务中找到对应的身影了，譬如服务之间的松散耦合、注册、发现、治理，隔离、编排等等。这些在今天微服务中耳熟能详的名词概念，大多数也是在分布式服务刚被提出时就已经可以预见的困难点。SOA 针对这些问题，甚至是针对“软件开发”这件事情本身，都进行了更加系统性、更加具体的探索。

就像当初的"WebServices"一样，从一个"Web服务"的广义概念，被大厂构建成了一种基于SOAP的用于构建Web服务的技术标准。
SOA实际发展起来后，大厂也开始为SOA构建一种事实标准，其中最重要的就是ESB

ESB

参考：浅谈SOA、ESB、分布式、微服务架构演变之路

随着我们的业务越来越复杂，会发现服务越来越多，SOA架构下，他们的调用关系会变成

怎么去清理这一团糟的东西呢？ESB(企业服务总线) 来了！

ESB是一个服务集成平台，它就像一根管道，用来连接各个服务节点。
ESB的核心功能在于集成基于不同协议的不同服务，提供不同协议、报文服务之间通过 ESB 实现互联互通。ESB 提供协议转换、解释以及路由寻址等功能。在整个服务调用过程中起到至关重要的作用。

用SOA集成新老组件和服务需要一个能够连接任意组件或服务的基础设施，通过这个基础设施就不需要考虑组件和服务的位置、消息协议和消息格式。为了能够通过这个基础设施串联起这些服务和组件，必须作很多的客户化定制。
满足上述需求的SOA基础设施我们称为"ESB"。

从名称就能知道，ESB的概念借鉴了计算机组成原理中的通信模型——总线，所有需要和外部系统通信的系统，统统接入ESB，岂不是完美地兼容了现有的互相隔离的异构系统，可以利用现有的系统构建一个全新的松耦合的异构的分布式系统。
一个ESB就是一个预先组装的SOA实现，它包含了实现SOA分层目标所必需的基础功能部件。

传统的ESB的服务调用方式是，每一次服务的调用者要向服务提供者进行服务交互请求时都必须通过中心的ESB来进行路由。

ESB的实现原理 (参考 IBM, What is an ESB?、CSDN, ESB实现原理)
ESB使用当时主流的WebServices技术作为统一的通信手段，即采用WSDL+SOAP连接所有服务的接口。后来我们都知道，WebServices越来越重量化，逐渐被RESTful取代，这也是ESB没落的一个重要原因

ESB的命运 (参考 IBM, ESB 的命运、IBM, What is an ESB?)
虽然ESB在许多组织中成功部署，但在其他许多组织中，ESB逐渐被视为瓶颈。
ESB是一个集中式服务，基于WebServices等功能的重量级组件，提供协议转换、解释以及路由寻址等功能。ESB模式的一些挑战是：
对接口进行更改可能会破坏集成中其它接口的稳定性，因此执行任何更新都需要进行大量的测试。
由于运行时包含的集成数量很多，运行时的规模很大，因此启动和停止ESB是非常不受欢迎的。ESB必须保持运行并尽可能实施修补，因此难以复制用于测试和诊断的环境，这对添加和更改造成了很大的阻力
为ESB这种大型服务器实施高可用和容灾回复功能的成本很高。
集成仍然是一个复杂的事情，很少有系统公开良好的接口，因此需要深厚的技能。只有少数集成专家可以信任来创建、维护和管理集成。这成为了企业引入ESB的阻力。

最终，事实证明，维护、更新和扩展集中式ESB的挑战是如此不堪重负和昂贵，以至于ESB常常延迟了它和 SOA 旨在产生的生产力收益，这使那些期待更快速度的业务团队感到沮丧。

SOA 在 21 世纪最初的十年里曾经盛行一时，有 IBM 等一众行业巨头厂商为其呐喊冲锋，吸引了不少软件开发商、尤其是企业级软件的开发商的跟随，最终却还是偃旗息鼓，沉寂了下去

---

二、微服务

参考
微服务与SOA
认识微服务
“四个维度” 讲明白什么是微服务！
凤凰架构-微服务时代

最初的微服务在2005年被提出，当时只是作为SOA的一个变体。随着技术的发展，到了2014年以后，微服务已经演进为一种云原生的架构方法，基础设施自动化，开发者无需考虑底层的技术实现，就可以充分发挥云平台的弹性和分布式优势，实现快速部署、按需伸缩、不停机交付等
(什么是云原生、云原生)

微服务的主要特征
微服务没有单一的定义，随着时间的推移，业界形成了一种共识。一些经常被引用的定义特征包括：

• 面向服务：服务提供统一标准的接口，与语言和技术无关。
• 单一职责、松散耦合：微服务拆分粒度更小，每个服务都是针对唯一的业务能力而设计的，并专注于解决特定的问题。
• 独立自治：团队独立、技术独立、数据独立，独立部署和交付。
• 隔离性强：服务调用做好隔离、容错、降级，避免出现级联问题
• 轻量通信：通常使用RESTful API通信
• 演进式设计：演进式架构以增量的、非破坏的变更作为第一原则，演进式设计也是微服务所提倡的。例如，要对一个巨型单体应用进行微服务转型，肯定不是把这个大的单体应用直接干掉不要，建一个新的微服务平台出来，而是要以增量的、非破坏的方式把某项业务一步步抽离形成新的服务。
  

尽管几乎任何现代工具或语言都可以在微服务体系结构中使用，但有一些核心工具已成为微服务必不可少的基本定义：例如容器技术(Docker)、Kubernetes、CI/CD、API网关、服务发现中间件、消息队列中间件等等

SOA和微服务的对比

一、服务粒度

• SOA并没有对粒度提出明确的要求，一般认为SOA要求服务有一个适中的粒度。而微服务则明确要求服务是细粒度的
• 例如，对一个大型企业来说，“员工管理系统”就是一个SOA架构中的服务；而如果采用微服务架构，则“员工管理系统”会被拆分为更多的服务，比如“员工信息管理”“员工考勤管理”“员工假期管理”和“员工福利管理”等更多服务

二、服务通讯

• SOA采用了ESB作为服务间通信的关键组件，使用WebServices技术栈。ESB负责服务定义、服务路由、消息转换、消息传递，总体上是重量级的实现；
• 微服务推荐采用轻量化的通讯方式，通常采用HTTP RESTful。服务发现也采用专门的服务发现中间件，如consul、zookeeper。

三、服务交付

• SOA对服务的交付并没有特殊要求，因为SOA更多考虑的是兼容已有的系统；
• 微服务的架构理念要求“快速交付”，相应地要求采取自动化测试、持续集成、自动化部署等敏捷开发相关的最佳实践。这就用到了云原生技术(Docker、Kubernetes等)

四、应用场景

• SOA更加适合于庞大、负责、异构的企业级系统，这类系统都发展多年，采用不同的企业级技术，有的是内部开发的，有的是外部购买的，无法完全推倒重来 或者进行大规模的优化和重构，由于成本和影响太大，只能采用兼容的方式进行处理，而承担兼容任务的就是ESB
• 微服务更加适合于快速、轻量级、基于Web的互联网系统，这类系统业务变化快，需要快速尝试、快速交付；虽然开发技术可能差异很大（Java、C++、.NET等），但对外接口基本都是提供HTTP RESTful风格的接口，无须考虑在接口层进行类似SOA的ESB处理

直观的对比如下

对比维度	SOA	微服务
服务粒度	粗	细
服务通信	重量级，ESB	轻量级，例如HTTP RESTful、Consul、API网关
服务交付	慢	快
应用场景	企业级	互联网/团队

微服务也带来了一些挑战

1. 服务划分过细，服务间关系复杂
2. 服务数量太多，团队效率急剧下降
3. 调用链太长，性能下降
4. 调用链太长，问题定位困难

————
微服务的发展过程

参考 凤凰架构-微服务时代

最初
“微服务”这个技术名词最早在 2005 年就已经被提出，它是由 Peter Rodgers 博士在 2005 年度的云计算博览会（Web Services Edge 2005）上首次使用。
最初的微服务是作为一种 SOA 的轻量化的补救方案而被提出的。时至今日，在英文版的维基百科上，仍然将微服务定义为一种 SOA 的变种形式，所以微服务在最初阶段与 SOA有所牵扯也完全可以理解，但现在来看，维基百科对微服务的定义已经颇有些过时了。

A microservice architecture – a variant of the service-oriented architecture structural style – is an architectural pattern that arranges an application as a collection of loosely coupled, fine-grained services, communicating through lightweight protocols.
—— Wikipedia，Microservices

发展
微服务的概念提出后，在将近十年的时间里面，并没有受到太多的追捧。如果只是对现有 SOA 架构的修修补补，确实难以唤起广大技术人员的更多激情。不过，在这十年时间里，微服务本身也在思考蜕变。
2012 年，Thoughtworks 首席咨询师 James Lewis 做了题为《Microservices - Java, the Unix Way》的主题演讲，其中提到了单一服务职责、康威定律、自动扩展、领域驱动设计等原则，却只字未提 SOA。
微服务已经迫不及待地要脱离 SOA 的附庸，成为一种独立的架构风格，也许，未来还将会是 SOA 的革命者。

崛起
微服务真正的崛起是在 2014 年，Martin Fowler 与 James Lewis 合写了文章《Microservices: A Definition of This New Architectural Term》。准确地说，今天大家所了解的“微服务”是这篇文章中定义的“微服务”。在此文中，首先给出了现代微服务的概念：“微服务是一种通过多个小型服务组合来构建单个应用的架构风格，这些服务围绕业务能力而非特定的技术标准来构建。各个服务可以采用不同的编程语言，不同的数据存储技术，运行在不同的进程之中。服务采取轻量级的通信机制和自动化的部署机制实现通信与运维”。
此外，文中列举了微服务的九个核心的业务与技术特征：围绕业务能力构建（Organized around Business Capability）、分散治理（Decentralized Governance）、通过服务来实现独立自治的组件（Componentization via Services）、产品化思维（Products not Projects）、数据去中心化（Decentralized Data Management）、强终端弱管道（Smart Endpoint and Dumb Pipe）、容错性设计（Design for Failure）、演进式设计（Evolutionary Design）、基础设施自动化（Infrastructure Automation）。(前面有提到-“微服务的主要特征”)

微服务和Docker

【原创】微服务为什么一定要用docker
容器技术之发展简史

Docker是容器技术的一种，也是容器技术的代表。
Docker发行于2013年，在此之前也有其它容器技术，但都不温不火。Docker的核心创新是容器镜像（docker image），一种新型的应用打包、分发和运行机制。容器镜像将应用运行环境，包括代码、依赖库、工具、资源文件和元信息等，打包成一种操作系统发行版无关的不可变更软件包。
Docker的出现引爆了容器技术，加上微服务的加持，使得二者发展迅速

前面"微服务的发展过程"提到，微服务的真正崛起是在2014年，Martin Fowler的文章中给出了具体的微服务定义。定义中的"基础设施自动化"与Docker不谋而合。

在现在微服务的架构中，一个应用拆成几十个微服务，每个微服务都对应有开发、测试、生产三套环境需要搭建，单靠运维根本管不过来，不仅需要花费大量的时间，而且很容易出错。一旦出错就需要开发人员开始关心环境交付这件事情。例如配置改了什么，创建了哪些目录，如何配置权限，只有开发最清楚，这些信息很难通过文档的方式又及时又准确地同步到运维部门来，就算是同步过来了，运维部门的维护量也非常的大。

让Docker成为微服务的交付工具
用上Docker容器后，可以实现开发、测试和生产环境的统一化和标准化。Docker镜像作为标准的交付件，可在开发、测试和生产环境上以容器来运行，最终实现三套环境上的应用以及运行所依赖内容的完全一致。每个开发多花 5% 的时间，去换取运维 200% 的劳动，极大提高了生产效率和稳定性。

可以说，Docker和微服务相辅相成，完美地结合在了一起，使得二者迅速发展

---

三、关于 SOA和微服务关系 的几种观点

SOA的本质一个"面向服务的架构"架构思想，但却逐渐倾向于表示一种技术标准，这就像当初的WebServices一样：WebServices表示的就是Web服务，但逐渐变成了一种基于SOAP的用于构建Web服务的技术栈。

从本质上来讲，我个人认为微服务是属于SOA的，因为微服务也是"面向服务的架构"(Service-Oriented Architecture)，它的本质没变。
然而微服务本身非常不愿意承认自己是SOA的子集，这在前面"微服务的发展过程"中有提到，这一诱导是造成歧义的关键性因素。

本文前述中，倾向于从SOA和微服务的发展过程来讲述，所以看起来更偏向于将SOA和微服务作为两个技术来看待。
这样的明确区分其实很方便讲述，否则如果把"微服务"看为"SOA"的子集，那我们就需要用"基于ESB的SOA"、"传统SOA"这种词语来指代早期的SOA，这显然很啰嗦、很麻烦，尽管现在我们完全明白这种含义，但如果在文章开头就这样描述就会让人难以接受。

关于SOA和微服务的关系和区别，大概分为以下几个典型的观点。
这些观点都是存在且合理的，也体现出了用辩证的思想看待问题、以全面的认识问题。

一、微服务是SOA的实现方式
该观点从本质出发，认为SOA依旧只是"面向服务的架构"一个架构思想，也是偏向广义的理解。
而SOA的实现思路有两个，一个是中心化的ESB，另一个是去中心化的微服务

例如，“微服务就是使用HTTP RESTful协议来实现ESB的SOA”、“微服务就是更细粒度的SOA”

二、微服务是去掉ESB后的SOA
观点认为传统SOA架构最广为人诟病的就是庞大、复杂、低效的ESB。所以将ESB去掉，改成轻量级的HTTP、服务发现中间件等职责单一的各种组件实现，就是微服务

三、微服务是一种和SOA类似但本质上不一样的架构理念
类似点在于二者都关注“服务”，都是经过服务的拆分来解决可扩展性问题
本质上不一样的地方在于几个核心理念的差别：是否有ESB、服务的粒度、架构设计的目标

---

四、QA

关于ESB的单点故障

有些文章会提到"ESB是所有服务的中心，会出现单点故障"。
但我觉得：SOA的ESB会出现单点故障，那微服务的API网关不会出现单点故障吗？

ESB虽然笨重，部署集群做高可用的成本很高，但是搜索"ESB集群"还是有一些靠谱的结果的，这说明单点故障是可以解决的。
ESB除了承担API网关的职责，还承担了服务发现的任务(这一功能很可能是由WebServices技术栈中的UDDI提供的)。把这么多且重要的任务都交给ESB这一个组件去承担，做集群的复杂度应该是比较高的。所以小企业可能不愿意这么去做。

而微服务的API网关的职责就像它的名字一样单一，服务发现则由专门的服务发现中间件提供，如consul、zookeeper等，无论是网关还是服务发现中间件，都是职责单一的轻量级组件，很方便做集群

关于微服务的去中心化 和 API网关

有很多观点认为，微服务和ESB的一个区别在于去中心化和中心化。

但是随着微服务越来越多，API 网关是不可避免要被引入的一个中心化组件

不过相比于重量级的ESB，API网关职责单一，很容易做高可用集群，所以它并没有难以解决的单点故障

---

五、灵活架构

“灵活架构"并不是一个架构规范，而只是我想出的一个描述词，它的意思是"如何进行灵活的架构”

有时我们的架构即不想做单体，又不想拆分的像微服务这般细致，也不想像SOA这般重量化，就可以采取一些灵活的自定义架构

以游戏架构为例，但除去单体架构的小游戏。
相比于Web，游戏中用户之间的交互操作非常多，且要求的即时性也更高，所以难以采用微服务这种细致化的拆分，否则会服务间会存在极大的耦合，这种耦合会拖慢运行的效率
而SOA又过于中心化、中心组件过于重量化，很容易成为性能瓶颈

SOA和微服务架构自然更倾向于Web架构，但游戏架构也能从中吸收到很多经验
通常游戏会将系统拆分为 逻辑/业务服、场景服、聊天服 等等
因为服务少、API种类少，所以它们之间的可以直接通信而不需要网关，通常使用RPC。但还需要利用"服务发现"中间件得知其它服务的地址
网关依然有，但他只用来处理玩家请求，并分发给对应的服务

从服务拆分上来看，这并没有符合微服务"粒度小"的设计理念。但相比于SOA，又没有了ESB一样笨重的组件
我们很难说这到底是SOA还是微服务，既有二者的特征，又不完全满足二者。纠结起来，很可能会白白浪费你大量的时间

提到"灵活架构"的目的是，我认为我们不应该被束缚在某一个或某几个架构之中，从而陷入"八股文"一样的深渊，让开发者的思维变得呆板。
往大了说，任何一个架构在被提出之前都不是已经存在的东西，成为一个架构师最重要的特性是不能故步自封，当然，这一切要先建立在你已经对很多架构都熟悉的基础之上，否则也难以驾驭架构。
当你已经熟悉了很多架构，在结合到实际运用中时，总会或多或少看到其中的缺陷或不适用于你的系统的内容，如果你已经具备了相应的能力，那么希望你能够成为"架构的主人"