微服务理论之五：微服务架构 vs. SOA架构

一、面向服务的架构SOA

面向服务的架构是一种软件体系结构，应用程序的不同组件通过网络上的通信协议向其他组件提供服务。通信可以是简单的数据传递，也可以是两个或多个服务彼此协调连接。这些独特的服务执行一些小功能，例如验证付款、创建用户帐户或提供社交登录等。

面向服务的架构不太关于如何对应用程序进行模块化构建，更多的是关于如何通过分布式、单独维护和部署的软件组件的集成来组成应用程序。这些通过技术和标准来实现，通过技术和标准使得组件能够更容易地通过网络（尤其是IP网络）进行通信和协作。

SOA架构中有两个主要角色：服务提供者（Provider）和服务使用者（Consumer）。而软件代理则可以扮演这两个角色。该Consumer层是用户（人、应用程序或第三方的其它组件）与SOA交互的点，和Provider层则由SOA架构内的所有服务所构成。

SOA首先在90年代中期得名，当时一家名为Gartner Group的公司认识到了这个软件架构的新趋势，并在全球推广。通过这样做，他们设法大大加快了这种架构模式的采用和进一步发展。然而，使用分布式服务作为软件体系结构的最早记录可追溯到二十世纪80年代初。

二、微服务架构

微服务架构在某种程度上是面向服务的架构SOA继续发展的下一步。基本上，这种架构类型是开发软件，网络或移动应用程序作为独立服务套件（又称微服务）的一种特殊方式。这些服务的创建仅限于一个特定的业务功能，如用户管理、用户角色、电子商务车、搜索引擎、社交媒体登录等。此外，它们是完全独立的，也就是说它们可以写入不同的编程语言并使用不同的数据库。集中式服务管理几乎不存在，微服务使用轻量级HTTP、REST或Thrift API进行通信。

这个词本身起源于2011年5月在威尼斯附近举行的软件架构师研讨会。他们第一次使用“微服务”这个术语来描述参与者看到的一个共同的架构风格，其中许多参会者都在探索相似的内容。2012年5月，同一个团队决定将“微服务”作为最合适的名称。然而实际上，微软、亚马逊、Netflix和Facebook等主要的科技公司已经在微服务架构方面工作了十多年。

乍一看，微服务架构似乎谈论的是与SOA相同的事情。不过，如果引用微软服务领域的先驱Martin Flower的话，他曾经说过，“我们应该把SOA看作微服务的超集”。

微服务中的这个“微”字给很多人带来了很多误解。从字面意思上，“微”会让人联想到一个微服务就应该是功能足够单一，甚至出现一个服务的实现可能只需要几十或者上百行代码的说法，这应该是最误导人的观点。从技术角度出发，确实可以通过简短的代码实现功能单一的服务，但从一个整体架构考虑，如果是以这样的方式实现各个微服务，则在整个服务体系范畴当中包含太多功能边界，那么对于服务运营的分工和边界就很难界定，给服务接下来的持续运营和维护带来困扰；另外拆分过于细化的服务，势必将带来大量无谓的分布式事务调用，给业务带来额外的工作量和风险。

正因为有了“微服务”中所谓“微”服务的说法，那如何对这些微服务进行快速的部署、发布，更高效的利用服务计算资源。（Docker本身提供的核心能力还是在技术资源层面），还有一系列问题，远不是单单的Docker平台能解决的问题：

微服务化的应用架构如何进行有效的服务管控。

在分布式服务体系下，服务链路跟踪、链路分析、实时业务指标的监控等问题，也都是事先微服务架构时一定会面临的问题，扩大到更大范围就是整体服务平台的管控能力。

分布式事务难题

服务化后的应用如何解决随之而来的分布式事务问题，一定需要针对业务的需求在事务一致性和性能间做好平衡，一套稳定、成熟的分布式事务解决方案也是构建微服务架构首先要思考好的技术方向问题。

自动化运维和平台稳定性。

微服务架构相比之前独立应用的部署方式，从服务器的数量以及服务交互复杂程度都上升到一个新的等级，原有运维平台和工具是否能高效支撑微服务架构的运维也需要好好斟酌。

　　微服务带来了服务间错综复杂的调用关系，如何能在大促、秒杀、机器故障时，这些服务都能稳定提供服务？这对于整个平台的高可用性和稳定性提出了非常高的要求：

1、微服务的服务设计：

　　微服务中服务边界的划分一定是从业务的维度，以什么样的服务颗粒度定义服务？什么样的数据模型支撑服务能力的线性扩展？如何保持设计出的服务具有很好的业务前瞻性？在高效满足现有业务需求的前提下，还能保持整个服务能力的通用性，为接下来其他业务的服务接入提供业务的扩展能力？这些问题都是微服务架构在落地过程中，实施团队都将面临的问题。

2、原有组织架构是否满足微服务架构持续发展的需要：

　　服务强调持续的演变，需要组建对应的组织或者对现有的组织架构进行调整，围绕以服务为中心的持续运营，这对应很多企业原有的信息中心架构是一个不大的冲击和改变。

那么，差异在哪里呢？可以说，两种架构比起不同的架构有更多的相似之处，然而，它们是两种不同类型的架构。下面会详细分析这一点。

三、SOA特点、微服务特性特点

SOA的主要特性：

IBM对SOA的定义：SOA是一种构造分布式系统的方法，它将业务应用功能以服务的形式提供给最终用户应用或其他服务。

• 面向服务的分布式计算
• 服务间松散耦合
• 支持服务的组装
• 服务的注册和自动发现
• 以服务契约方式定义服务交互方式

“中心化”的SOA服务架构，即传统软件厂商提出的以ESB（企业服务总线）实现SOA的方案；还有一种是“去中心化”的服务架构。

微服务的主要特性：

定义：围绕业务领域组件来创建应用，这些应用可独立地进行开发、管理和迭代。在分散的组件中使用云架构和平台式部署、管理和服务功能，使产品交付变得更加简单。

以下是Martin Fowler对于微服务架构的典型特征的描述：

• 分布式服务组成的系统。
• 按照业务而不是技术来划分组织。
• 做有生命的产品而不是项目
• 智能化服务端点与傻瓜式服务编排。
• 自动化运维。
• 系统容错。
• 基础设施自动化
• 服务快速演化。
• 去中心化的治理技术。
• 去中心化的管理数据。

从本质上来说，“微服务”是SOA的一种演变后的形态，与SOA的方法和原理没有本质上的区别。将传统SOA与微服务典型特征做一个对比解读，会发现鲜明差异：（67页）

四、SOA vs. MicroServices

SOA简单理解为应用的垂直拆分，微服务理解为应用的垂直拆分+水平拆分，是SOA的演进。提高了灵活性，但是需要额外考虑分布式锁、分布式事务等问题。

下面进一步解释上表所述的不同之处：

• 开发方面 - 在这两种体系结构中，可以使用不同的编程语言和工具开发服务，从而将技术多样性带入开发团队。开发可以在多个团队中组织，但是在SOA中，每个团队都需要了解常见的通信机制。另一方面，使用微服务，服务可以独立于其他服务运行和部署。因此，频繁部署新版本的微服务或独立扩展服务会更容易。您可以在这里进一步阅读有关微服务的这些好处。

• “上下文边界” - SOA鼓励组件的共享，而微服务尝试通过“上下文边界”来最小化共享。上下文边界是指以最小的依赖关系将组件及其数据耦合为单个单元。由于SOA依靠多个服务来完成业务请求，构建在SOA上的系统可能比微服务要慢。

• 通信 - 在SOA中，ESB可能成为影响整个系统的单一故障点。由于每个服务都通过ESB进行通信，如果其中一个服务变慢，可能会阻塞ESB并请求该服务。另一方面，微服务在容错方面要好得多。例如，如果一个微服务存在内存错误，那么只有该微服务会受到影响。所有其他微服务将继续定期处理请求。

• 互操作性 - SOA通过消息中间件组件促进了多种异构协议的使用。微服务试图通过减少集成选择的数量来简化架构模式。因此，如果您想要在异构环境中使用不同协议来集成多个系统，则需要考虑SOA。如果您的所有服务都可以通过相同的远程访问协议访问，那么微服务对您来说是一个更好的选择。

• 大小Size - 最后一点但并非最不重要的一点，SOA和微服务的主要区别在于规模和范围。微服务架构中的前缀“微”是指内部组件的粒度，意味着它们必须比SOA架构的服务往往要小得多。微服务中的服务组件通常有一个单一的目的，他们做得很好。另一方面，在SOA服务中通​​常包含更多的业务功能，并且通常将它们实现为完整的子系统。

五、结论

我们不能简单地说一种架构比另一种架构更好。这主要取决于您正在构建的应用程序的目的。SOA更适合需要与许多其他应用程序集成的大型复杂企业应用程序环境。这就是说，小型应用程序不适合SOA架构，因为它们不需要消息中间件组件。而微服务架构，在另一方面，是更适合于较小和良好的分割，基于Web的系统。另外，如果您正在开发移动或Web应用程序，那么微服务作为开发人员可以为您提供更大的控制权。最后，我们可以得出结论，因为它们服务于不同的目的，微服务和SOA确实是不同类型的体系结构。