现代软件开发越来越依赖于分布式、基于服务的架构模式，以实现可扩展性、可靠性和快速构建、测试和发布周期。两个最流行的基于服务的方法是面向服务的架构（SOA）和微服务。在这篇文章中，我们将研究这两种方法，以确定它们的异同，以及各自的一些用例。
由于SOA是一种公认的老式方法，它可能不适合现代云原生应用。但它仍然提供了许多好处，使它在许多不同的场景中成为一个伟大的选择。通过了解SOA的哪些方面仍有意义，哪些部分已被抛弃以支持微服务，你将有能力为你的下一个基于服务的应用在这两者之间做出选择。
让我们先来了解一下SOA到底是什么。
什么是面向服务的架构？
全球研究和咨询公司Gartner最初在90年代中期创造了 "面向服务的架构 "这个术语。结构化信息标准促进组织（OASIS）--IT行业标准委员会--将SOA定义为 "一种组织和利用可能在不同所有权领域控制下的分布式能力的范式"。
SOA是建立一个可以在开发中扩展的后端--换句话说，一个可以快速增加新的开发人员和额外功能的方法。请注意，SOA是一种架构风格，而不是一种具体的实现。在这种架构风格中，一切都以服务为中心（因此得名）。在这里，一个服务是一个业务领域的功能表示。
通常情况下，服务通过服务总线进行通信，并由一个服务库来识别它们。因此，服务以松散耦合的方式整合，只能在线使用。契约必须固定一个通信API。这个合同建立了一个指定的接口来触发业务逻辑或访问数据。所以，它使用一些标准化的消息传递协议，这些协议通常比简单的REST复杂得多。
由于通信是通过服务总线进行的，所以当需求或不需求时，它可以定位收件人。在理论上，这允许请求排队和异步工作负载执行。但这里大多数协议都是同步的，这意味着即使是异步的工作负载也需要立即响应。
每个服务都应该被隔离开来，以便有人能够独立地开发它。然而，由于SOA是关于重用的，任何服务都可以共享或重用甚至是基本的组件，如数据存储。对服务没有框架或编程语言的要求。这样一来，平台的访问和开发是普遍可能的。
什么是微服务？
微服务架构是后端系统的另一种方法。UNIX操作系统范式--"做一件事，并把它做好"--指导着这种架构。
事实上，微服务是关于模块化和解耦的后端能力。小规模的开发者团队不是创建一个大型服务，而是创建和发布较小的实体。
虽然Netflix在2000年代末普及了微服务的方法，但在这之前还有很多人玩过这种模式。事实上，它的起源可以追溯到2004年，与SOA有很大的相似之处。这可能就是为什么开发人员首先将微服务方法描述为 "细粒度的SOA"。
它对DevOps的严重依赖使微服务与众不同。在一个理想的微服务实现中，整个真相的来源在于代码--从开发到部署到运行时的协调。因此，任何微服务都应该是尽可能独立的，提供自己的数据存储和通信协议。它还应该尽可能地轻量化；DevOps倾向于使用简单的HTTP与REST。
虽然微服务的目标是轻量级的，但它们仍然是复杂的，而且是资源匮乏的。给予每个团队自己的服务世界，会导致重复和协调的开销。因此，复杂性从构建一个巨大的应用程序的调整转移到这些小规模服务的协调。
虽然DevOps工程师仍然大量讨论合适的微服务规模，但我们总是可以回到SOA的定义，即从根本上代表一个业务（子）领域。尽管如此，当SOA最大限度地重用时，微服务试图对限定的上下文进行清理，这最终导致了（想要的）重复。
基于服务的架构和微服务架构能解决什么问题？
虽然在外表上很相似，但SOA和微服务在很多方面都不同。根本的区别在于共享代码和责任。SOA试图将共享的组件带到相互的服务中去，并尽可能地重用，而微服务的方法则是尽可能少地共享。
一个完整的微服务可能有自己的日志系统、认证处理和其他纯粹的技术功能。同时，SOA肯定会把这些共同的方面放到一个专门的服务中，以尽可能多地共享。
SOA解决了大型企业应用中的一个常见问题，即公司需要将一组现有的应用（或服务）置于一个伞下。他们相当频繁地使用诸如 "企业服务总线 "或 "服务库模式 "等字眼。SOA包含服务库和服务总线等元素，这并不奇怪。
另一方面，微服务方法是为云原生时代开发的，单个服务在内部和外部都会暴露。这种设置通常结合了第三方服务、协调平台和自定义服务，都在云中。
与SOA相比，微服务提供的正式API指导和规范较少。如前所述，DevOps团队通常使用HTTP和RESTful原则实现微服务API，但这绝不是一成不变的。另外，微服务不需要API网关等组件--最好是根本不使用API网关。SOA范式需要一个中心服务来访问各个服务。
除了共享之外，我们发现这两种方法对服务实体的解释也不同。在微服务的背景下，一个服务对于构造一个单一的应用程序至关重要，而SOA使用服务来整合多个应用程序。
SOA与微服务：你应该使用哪种方法？
这些天，看到新的SOA项目是比较少见的。原因很简单：限制太多，知识太少。大多数开发者要么更熟悉微服务方法，要么更青睐它提供的一些自由。
所以，问题是，你应该在什么时候使用SOA？如果你正在建立一个应该（而且永远）作为一个平台工作，但需要强大的功能扩展和遵守预先定义的业务领域，SOA是一个很好的选择。在这些考虑下，SOA是包括许多不同应用和服务的大规模企业平台的理想候选者。
如果你努力追求单个服务的独立性，那么微服务方法是更好的选择。这种方法把几乎所有的具体选择都留给了服务。这样，每个团队可以完全自主，从编码到部署和运行时行为都有完全的控制。
SOA诞生于经典的企业运营中，这一点应该不奇怪。即使在今天，SOA仍然提供了许多大型后端平台所需要的方面。该架构处理数据一致性和治理，让公司对平台有完全的中央控制。相比之下，一个真正的微服务平台有许多单独的所有者，它不能从一个地方被控制。
总结
如果你曾经建立过一个基于微服务的后端，你有可能已经遇到了一些SOA可以为你解决的挑战。另一方面，SOA也有其自身的复杂性和限制。毕竟，人们如此迅速地跳上微服务的行列是有原因的。
了解SOA和微服务之间的差异是为特定问题选择正确架构的关键。虽然单体在许多方面仍有其用武之地，但不要忽视SOA的分布式开发方面和微服务等衍生架构模式。
仅仅是问题应该决定你选择哪种方法，而不是当前的趋势。选择适合特定情况和可用资源的架构模式，你的项目就会走上正轨。
