3.2.2 MSA与SOA的区别
MSA与SOA虽然有许多相似之处和联系，但它们是两种不同类型的架构。表3-1总结了两种架构的不同之处，我们将在之后对其进行详细说明。
表3-1 MSA与SOA的区别
1. MSA与SOA在服务化概念上的区别
虽然前文提到MSA和SOA都将“服务”作为主要组件，但它们在服务特性方面的差异很大。首先，在服务类型上，SOA定义了四种服务类型，如图3-6所示，分别是业务服务、企业服务、应用程序服务、基础结构服务。
图3-6 SOA的四种服务类型
业务服务是定义核心业务运营的粗粒度服务，它们通常通过XML、Web服务来定义语言或规范业务流程，从而执行语言表示，实现企业的业务服务等功能。业务服务依靠应用程序服务和基础结构服务来满足业务请求。应用程序服务是绑定到特定应用程序上下文中的细粒度服务，可以通过专用用户界面直接调用这些服务。基础结构服务完成非功能性任务，如身份验证、审计、安全性和日志记录，可以从应用程序服务或企业服务中调用它们。
相比之下，MSA的服务分类十分有限。该体系结构由两种服务类型组成，如图3-7所示，分别是功能服务和基础结构服务。功能服务支持特定的业务运营。这些服务是从外部访问的，通常不与任何其他服务共享。与SOA一样，基础结构服务实现审计、安全性和日志记录等任务。这些服务不会暴露给外部世界，而是在内部提供。
图3-7 MSA的两种服务类型
下面通过对关键词的对比来区分SOA与MSA。
（1）松耦合。
耦合是交互的系统彼此间的依赖。在微服务中，每个微服务内部都可以使用DDD（领域驱动设计）的思想设计领域模型。DDD是指在开发某个自己不了解的行业领域的软件的过程中，开发前，在业务知识梳理的过程中必须形成领域知识，根据形成的领域知识来一步步驱动软件设计过程。其像是更小粒度的迭代设计，它的最小单元是领域模型（Domain Model）。领域模型就是能够精确反映领域中某一知识元素的载体，需要与领域专家（Domain Expert）进行频繁的沟通才能将专业知识转化为领域模型。在微服务中，使用DDD对业务进行分析时，首先会使用“聚合”这个概念把关联性强的业务概念划分在一个边界下，并限定聚合和聚合之间只能通过聚合根来访问，这是第一层边界。然后在聚合基础上，根据业务相关性、业务变化频率、组织结构等约束条件来定义限界上下文，这是第二层边界。有了这两层边界作为约束和限制，微服务的边界也就清晰了，拆分微服务也就不再困难了。这个过程让服务间减少了同步的调用，使用消息的方式让服务间的领域事件进行解耦，保证了微服务能够独立修改及部署单个微服务而不需要修改系统的其他部分，从而做到了服务之间的松耦合。
在SOA中，在不同服务之间也要求保持一种松耦合的关系，也就是保持一种相对独立、无依赖的关系。一个服务就是一个单独的代码模块，但其松耦合实现的策略是使用Service Interface（如果是SOAP Web Service的话，就是指WSDL）来限制它的依赖性，从而达到对消费者隐藏服务的目的。虽然二者都要求保持一种松耦合的关系，但它们的实现方法和策略迥然不同。
（2）轻量级协议。
SOA体系结构将消息传递（AMQP、MSMQ）和SOAP作为主要的远程访问协议。AMQP是基于平台与开放标准的业务消息传递的规范。这样的规范对许多客户来说非常有用。它必须在MSMQ和WebSphere MQ之间进行集成。SOPA是交换数据的一种协议规范，是一种轻量、简单、基于XML的协议，它被设计成在Web上交换结构化和固化的信息。
大多数MSA依赖两种协议：REST和简单消息传递（JMS、MSMQ）。REST，即Representational State Transfer的缩写，直接翻译的意思是“表现层状态转化”。它是一种互联网应用程序的API设计理念：URL定位资源，用HTTP动词（GET、POST、DELETE、DETC）描述操作。随着移动互联网的不断发展，新兴电子设备不断涌入市场，如手机、平板电脑、桌面电脑，在这种情况下，就需要一个统一的机制，实现前端设备与后台的通信。在这种推动作用下，Restful诞生了，它提供了一套统一的机制——接口API，从而实现了前端设备与后台的通信。
（3）高度自治和持续集成。
从底层的角度来说，SOA更加倾向于基于虚拟机或者服务器的部署，每个应用都部署在不同的机器上。一般的持续集成工具都是由运维团队通过写一些Shell脚本及提供基于共同协议（如淘宝使用的Dubbo管理页面）的开发部署页面来实现的。
一个微服务就是一个独立的实体，它可以独立地部署在PaaS上，也可以作为一个操作系统进程。服务之间均通过网络调用进行通信，从而加强服务之间的隔离性，避免紧耦合，这些服务的修改相互独立，并且某一个服务的部署不会引起该服务消费方的变动，他们自身具有强大的自治性。与此同时，微服务还可以与容器技术很好地结合，从而更好地实现持续集成的功能。容器技术的出现让微服务的实施更加简便，目前Docker已经成为很多微服务实践的基础容器。因为容器的特色，所以一台机器上可以部署几十个、几百个不同的微服务。如果某个微服务流量压力比其他微服务大，可以在不增加机器的情况下，在一台机器上多分配一些该微服务的容器实例。同时，因为Docker的容器编排社区日渐成熟，类似Mesos、Kubernetes及Docker官方提供的Swarm都可以作为持续集成部署的技术选择。
2. MSA与SOA在硬件上的区别
通过如图3-8所示的MSA和SOA在硬件上的区别可以发现，它们最大的区别在于服务API的调用。SOA中采用企业服务总线的工作机制来提供和调用集成系统的服务，即每个系统和企业服务总线（ESB）之间只需要定义一个访问方法（API）即可。而MSA中，每一个服务对应一个API接口，系统直接与这些服务提供的API接口进行通信。
图3-8 MSA和SOA在硬件上的区别
3. MSA与SOA在服务互联和编写服务时所使用的技术方面的区别
实现SOA架构的常用技术有ESB、Web Services、JMS和BPEL等。
1）ESB技术
企业服务总线（ESB）是构建基于SOA解决方案时所使用的基础架构的关键部分，是由中间件技术实现并支持SOA的一组基础架构功能。它有助于协调和安排网络上以分布式服务的形式存在的不同元素。这种技术认为系统是离散的分布式服务，它们通过异步的、面向消息的基础设施相互连接。这种面向消息的基础架构使得在独立服务或模块之间建立松耦合的连接成为可能。基于开放的标准，其为应用提供了一个可靠的、可度量的和高度安全的环境，并可帮助企业对业务流程进行设计和模拟，对每个业务流程实施控制和跟踪，分析并改进流程和性能。目前各大IT公司都推出了基于自己的平台工具的ESB产品，如IBM的WebSphere ESB、BEA的AqusLogic Service Bus等。除此之外，也出现了众多的开源ESB产品，如Mule、Service Mix和Apache Synapse等。
2）Web Services技术
Web Services是通过一组标准协议和技术与客户通信的服务。这些标准在所有主要软件供应商的平台和产品中实现，使客户端和服务能够以一致的方式在各种平台和操作环境中进行通信。这种普遍性使Web Services成为实现SOA的最普遍的方法。
Web Services的主要目的是使原来各孤立的站点之间能够相互通信、共享信息。它隐藏了服务实现的细节，允许通过独立于服务实现、独立于硬件或软件平台、独立于编写服务所使用的编程语言的方式使用该服务。Web Services可以通过HTTP、SOAP（XML）、SMTP等协议的组合被访问，利用标准网络协议和XML数据进行通信，具有良好的普适性和灵活性。这使得基于Web Services的应用程序具备松耦合、面向组件和跨技术实现的特点。
3）JMS技术
Java消息服务（JMS）是Sun Microsystems的一个应用程序接口，它提供了标准消息传递协议的通用接口，也提供了支持Java程序的特殊消息传递服务，并提倡将Java Message Service用于开发Java应用程序，这些应用程序可以在主要的操作系统平台中运行。JMS技术采用异步通信模式，发送消息者将需要变更的数据消息提交给消息平台后，就完成了自己的任务，可以进行其他的操作，不需要等待服务器端的消息处理结果。这时，即使网络出现故障甚至服务器崩溃也不会造成数据的丢失或不一致，消息会保存在消息队列中直到最终被接收。
而微服务推崇执行的标准（如HTTP）是人们广泛了解并共同使用的。微服务架构的常用技术有服务网关Zuul、服务注册发现Eureka+Ribbon、服务配置中心Apollo、认证授权中心Spring Security OAuth、服务框架Spring/Boot。
（1）服务网关Zuul。
Zuul主要用于智能路由，同时也支持认证、区域和内容感知路由，将多个底层服务聚合成统一的对外API。Zuul的一大亮点是动态可编程，配置可以以秒级生效，由此可以看到Zuul网关对微服务基础架构的重要性。
Zuul在Netflix中经过生产级验证，在纳入Spring Cloud体系之后，在社区中也有众多成功的应用。Zuul在携程（日流量超50亿）、拍拍贷等公司也有成功的落地实践，是微服务基础架构中网关的首选。其他开源产品，如Kong和Nginx等也可以支持网关功能，但是较为复杂。
Zuul虽然不完全支持异步，但是同步模型反而使其简单轻量，易于编程和扩展，当然同步模型需要做好限流熔断（和限流熔断组件Hystrix配合），否则可能造成资源耗尽甚至产生雪崩效应（Avalanche Effect）。
（2）服务注册发现Eureka+Ribbon。
针对微服务注册发现场景，在社区里的开源产品中，通过生产级大流量验证的目前只有NetflixEureka，它也已经纳入Spring Cloud体系，在社区中有众多成功应用，例如，携程Apollo配置中心将Eureka作为软负载。
Ribbon是可以和Eureka配套对接的客户端软负载库，在Eureka的配合下，能够支持多种灵活的动态路由和负载均衡策略。内部微服务直连可以直接经过Ribbon客户端软负载网关，也可以部署Ribbon，这时网关相当于一个具有路由和软负载能力的超级客户端。
（3）服务配置中心Apollo。
携程框架研发部开源的Apollo是一款在携程和其他众多互联网公司生产落地的产品，其支持完善的管理界面，具备多环境、配置变更实时生效、权限和配置审计等多种生产级功能。Apollo既可以用于连接字符串等常规配置场景，也可用于发布开关（Feature Flag）和业务配置等高级场景。
（4）认证授权中心Spring Security OAuth。
OAuth是一种基于令牌（Token）的授权框架，已经得到众多企业（如Google、Facebook、Twitter等）的支持，可以认为是微服务的安全协议标准。其适用于开放平台联合登录、现代微服务安全（包括单页浏览器App、无线原生App、服务器端Web App接入微服务，以及微服务之间的调用等）和企业内部应用认证授权（IAM/SSO）等多种场景。
Spring Security OAuth 2是在Spring Security基础上的扩展，支持4种主要的OAuth 2 Flows，基本可以作为微服务认证授权中心的推荐产品。但是Spring Security OAuth 2还只是一个框架，不是一个端到端的开箱即用的产品，企业级应用仍须在其上进行定制，如提供Web端管理界面、对接企业内部的用户认证登录系统、使用Cache缓存令牌、和微服务网关对接等。
（5）服务框架Spring/Boot。
Spring可以说是史上最成功的Web App/API开发框架之一，它融入了Java社区中多年来沉淀下来的最佳实践，虽然有将近15年的历史，但目前的社区活跃度仍呈上升趋势。Spring Boot在Spring的基础上进一步打包封装，提供更贴心的Starter工程、自启动能力、自动依赖管理。其基于代码的配置等特性进一步降低了接入门槛。另外，Spring Boot也提供Actuator这样的生产级监控特性，支持DevOps研发模式，它是微服务开发框架的首选。REST契约规范Swagger和Spring有比较好的集成，使得Spring也支持契约驱动开发模型。
对于一些中大规模的企业，如果业务复杂、团队较多，考虑到互操作性和集成成本，建议其采用契约驱动开发模型，也就是开发时先定Swagger契约，然后再通过契约生成服务端接口，实现客户端业务逻辑。这种开发模型能够标准化接口，降低系统间的集成成本，对于多团队协同并行开发非常重要。
4. MSA与SOA的中心化区别
是否能去中心化是MSA与SOA最大的区别。在面向SOA的软件中，数据往往存储在单个大型的数据库中，服务之间会共享领域模型，从而体现了SOA架构的数据中心化。SOA采用了企业服务总线技术，企业服务总线是SOA架构中的中心总线，是星形的中心化的设计图形。它的重要功能就是集成不同的系统，并将接入的系统映射成Web服务，从而体现了SOA的管理中心化。也就是说，SOA无论在数据上还是管理上都体现了中心化的思想。
而MSA却恰恰相反，微服务的目标是去中心化。微服务有管理的去中心化，也有数据的去中心化。以数据去中心化为例，相比于构建超大的数据库，微服务选择根据业务单元来对数据进行拆分，分散数据管理，从而实现其去中心化的思想。为了以分散的方式正确地组织数据，微服务采用REST方法，即为应用程序中的每个资源提供一个URL，然后使用标准HTTP谓词与资源进行交互。基本社交消息应用程序的API组织如表3-2所示。
表3-2 基本社交消息应用程序的API组织
此API有三种原始资源类型：users、messages和friends。为其提供微服务部署帮助的服务类型有三种：一种用于用户资源的服务，一种用于消息资源的服务，一种用于朋友关系的服务，并且每个服务都有自己的数据库。图3-9给出了微服务架构的分散数据管理。每个微服务都有自己的数据库并不意味着需要3个数据库服务器。在平台的早期，3个数据库可能仅仅具有逻辑上的区别，因为这些数据库都由单个物理SQL服务器托管。但是，创建此逻辑区别可以使平台在未来轻松实现物理扩展。
图3-9 微服务架构的分散数据管理
这种分散数据管理的方式使得微服务实现了数据去中心化的目的。它不需要重型的企业服务总线，而是把消息中间件所提供的功能融入各微服务节点，从而有效地解决了企业服务总线中心化的问题。