教科书般阐述SOA和微服务的区别

一、演变历史

随着互联网的发展，网站应用的规模不断扩大，常规的垂直应用架构已无法应对，分布式服务架构以及流动计算架构势在必行，亟需一个治理系统确保架构有 条不紊的演进。

1.1单一应用架构

当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。 

此时，用于简化增删改查工作量的 数据访问框架(ORM) 是关键。

1.2垂直应用架构

当访问量逐渐增大，单一应用增加机器带来的加速度越来越小，将应用拆成互不相干的几个应用，以提升效率。 

此时，用于加速前端页面开发的 Web框架(MVC) 是关键。

1.3分布式服务框架

当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。 

此时，用于提高业务复用及整合的 分布式服务框架(RPC) 是关键。

1.4流动计算架构

当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率。

此时，用于提高机器利用率的 资源调度和治理中心(SOA) 是关键。

1.5微服务架构

大量服务之间耦合日趋加强，单一职责原则逐渐遭到破坏，ESB单点问题开始暴露，牵一发而动全身。

此时，专注于脱钩、DevOps和持续交付，简化通信的MSA(微服务)是关键。

二、SOA和微服务的区别

关于这两种架构之间的差异，或者是否存在任何差异，已经有很多大惊小怪。为了深入研究引发数百次辩论的这个问题，我将首先简要地定义SOA和微服务架构及其起源，然后我们将对它们进行比较，看看我们如何才能最好地区分它们。

 

面向服务的体系结构（SOA）

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

面向服务的体系结构不是关于如何模块化应用程序，而是关于如何通过集成分布式，单独维护和部署的软件组件来组合应用程序。它通过技术和标准实现，使组件更容易通过网络进行通信和协作，尤其是IP网络。

SOA中有两个主要角色：服务提供者和服务使用者。软件代理可以扮演两种角色。该消费层是用户（人，应用程序，或第三方的其他部件）与SOA交互的点，和提供者层由SOA内的所有服务。

 

SOA首先在90年代中期得名，当时一家名为Gartner Group的公司认识到这种软件架构的新趋势，采用它并在全球范围内推广它。通过这样做，他们成功地大大加快了这种架构模式的采用和进一步发展。但是，使用分布式服务作为软件架构的第一个记录可以追溯到80年代早期。

微服务

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

这个词本身源于2011年5月在威尼斯附近举办的软件架构师研讨会。他们首次使用“微服务”这一术语来描述参与者所看到的许多人最近一直在探索的共同建筑风格。2012年5月，同一小组决定将“微服务”作为最合适的名称。然而，微软，亚马逊，Netflix和Facebook等主要科技公司已经使用微服务超过十年。在提出普遍接受的名称之前，其他人称他们为“微网络服务”或“细粒度SOA”。

是的，乍一看，我们似乎在谈论与SOA相同的事情。但是，我将请求微软服务领域的先驱Martin Flower的话，他曾经说过我们应该将SOA视为微服务的超集。

那么，差异在哪里？

我们可以说两种架构都有相似之处而不是差异，但是，最终，它们是两种不同类型的架构。为了支持我的主张，首先，我将以表格的形式介绍将它们区分开来的架构的特定部分。稍后，我将更详细地阐述其中的一些内容。开始了！
 

面向服务的体系结构	MICROSERVICES体系结构
最大化应用程序服务可重用性	专注于脱钩
系统的变化需要修改整体结构	系统的变化是创造一种新的服务
DevOps和持续交付正在变得流行，但不是主流	专注于DevOps和持续交付
专注于业务功能重用	更加重视“有界语境”的概念
对于通信，它使用企业服务总线（ESB）	对于通信使用不那么复杂和简单的消息系统
支持多种消息协议	使用轻量级协议，如HTTP，REST或Thrift API
为部署到它的所有服务使用通用平台	应用服务器并未真正使用，通常使用云平台
使用容器（如Docker）不太受欢迎	容器与微服务一起工作得很好
SOA服务共享数据存储	每个微服务可以具有独立的数据存储
共同治理和标准	轻松治理，更加注重团队协作和选择自由

 

上表中显示的某些方面进一步详细说明，并进一步解释其中的差异：

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

   

• “有界上下文” - SOA鼓励共享组件，而微服务试图通过“有界上下文”最小化共享。有界上下文指的是将组件及其数据作为单个单元耦合，具有最小的依赖性。由于SOA依赖于多种服务来满足业务请求，因此基于SOA构建的系统可能比微服务慢。

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

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

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

结论

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

加我微信进技术交流群，各大教学资源免费领取，大厂内推！关注订阅号：一只可爱的小码农，不定时推送高质量学习文章。