面向服务的架构 (SOA, Service-Oriented Architecture) 是一种围绕一组独立的 “服务 (service)”设计应用的架构方法。服务可以是完成某项操作并提供特定结果的任何业务功能，例如处理客户订单或编制库存报告。它可将各个服务整合在一起来创建复合应用，从而为最终用户提供更强大的功能。
SOA 方法的优势包括更易于维护和更新服务组件 — 每个组件更加紧凑和独立，因此有助于更轻松地修复代码或替换元素且不会影响所有其他元素。然而，当我们确定如何最好地实现服务之间的通信时，问题出现了。SOA 通常搭配企业服务总线 (ESB, Enterprise Service Bus) 使用，将后者作为服务之间主要的通信方式。ESB 通常无法很好地响应变化，往往会带来更多复杂性，使得确定服务的开始位置和结束位置变得更为困难。
SOA 与微服务
如果您认为 SOA 听起来很像微服务的当前定义，那么并非您一人如此。微服务也是小型自包含服务，旨在独立运行，同时也可以协同工作。但 SOA 和微服务之间有一些主要区别。需要注意的几点如下：
- 微服务是非常细粒度的服务，出于“功能”原因以一定的细粒度级别进行拆分。这意味着在微服务架构中，服务（包括数据库和应用服务器及产品支持）由同一团队执行端到端管理。而 SOA 则按“逻辑”拆分服务。此处的区别在于，逻辑分组的服务在功能之间共享。听起来不错……直到这种服务发生故障，所有依赖它的功能都受到影响。微服务架构能够消除这种影响，因为业务服务完全包含在其独特功能中，而且该架构还具有实现这些功能和交付业务价值所需的一切 — 即使这意味着同时会重复某些内容。
- 因为微服务在功能上完全自包含，所以也不受最终限制 SOA 的那些通信框架、协议及规范的约束。微服务侧重于将智能特性内置于每组端点，并使用简单的结构将它们连接起来。通常最好的方法就是实施单个 API 网关，该网关采用内部系统架构，并使用 REST 等轻量级 Web 协议将请求路由到每个独立的微服务。此外，每个微服务通常使用来自其他服务的 API — 但网关会阻止移动应用访问后端。这种级别的灵活性是 SOA 永远无法实现的，因为它被 Web 服务规范所束缚并依赖 ESB 来连接应用。
尽管许多人认为微服务从根本上是 SOA，但实际上两者之间存在许多关键差异 — 在许多方面，这些差异优势让微服务成为了对于复杂应用更有效的架构选择。有关 SOA 和微服务的更多信息，请下载免费的电子书《构建微服务：设计细粒度系统》。
NGINX Plus 如何助一臂之力？
作为出色的负载均衡解决方案，NGINX Plus 和 NGINX 在 Dropbox、Netflix 和 Zynga 等高流量网站中有着广泛的应用。全球超过 3.5 亿个网站都使用 NGINX Plus 和 NGINX 开源版快速、可靠、安全地交付内容。
作为基于软件的应用交付控制器 (ADC)，NGINX Plus 能够比具有类似功能的硬件解决方案更高效、更经济地助力构建微服务架构。
- NGINX Plus 提供了全面的应用交付和负载均衡解决方案，可提高每个微服务的性能和可靠性
- NGINX Plus 具备出色的灵活性和可扩展性，可作为 API 网关和每个服务的端点整合至您的堆栈中
- NGINX Plus 能够充当高性能 HTTP 服务器，最快速、最高效地完成微服务操作
