本文共 4068 字，大约阅读时间需要 13 分钟。
在过去一年左右的时间里，我们看到有关微服务的不断涌现，其主题包括微服务的、以及。最近，来自C2B2的顾问主管也加入了微服务与SOA的关联这一话题的讨论之中。
\\\\\最近，人们对于微服务的概念进行了大量的讨论，其中有许多讨论是关于微服务与SOA之间的关联。微服务究竟是压垮SOA的最后一根稻草，还是能够拯救整个软件工程行业的万能药？人们对此众说纷纭。
\
Matt在文中对于微服务概念产生背后的原因以及SOA的原则进行了一些基本的概括。这篇文章的基本思想是：这两种架构在原则上确实是相当近似的，但面向SOA或微服务进行架构的产品确实存在着各种不同之处，使得他们各自适用于不同的用例。Matt在对微服务的总体介绍中是这样说的：
\\\\\经过分离的组件可以各自拥有独立的生命周期，并且按需进行扩展。不仅如此，这种方式也打破了组件之间的技术依赖，这就允许每个服务各自选择最适合的技术进行实现。通过将较大的问题分解为几个较小的问题，让每个问题更易于进行分析，也更利于开发者选择最适合的解决方案。
\
尽管有这些优点，但微服务也存在着一些不足之处。虽然在这一领域中具有实际工作经验的开发者基本上都已经很好地理解了这些问题，但针对他们的报道与讨论却相对很少：
\\\\\通过这种方式对大问题进行分解也增加了整个解决方案的复杂度，尤其是在那些使用不同技术或方式创建各种服务的系统中体现得更为明显。这种架构将系统的整合点推移到了服务之间的接口，因此这些服务的接口需要进行良好的定义，在系统中也要对服务级别达成一致，并且还需要定义其他的非功能性需求。
\
在目前来看，微服务还是一种相对较新的技术，架构师与开发者们通常所使用的一些辅助性工具也还处于发展阶段，以上所提及的这些问题可能迟早会得到解决。但在Matt看来，微服务的应用还存在着一个关键问题，那就是数据的管理和所有权：
\\\\\当某个原本采用一体性应用程序架构的系统被分解为多个小型服务时，在原本的一体性架构中集中保存在某处的数据，在新的微服务应用中经常会改为保存在多个地方，这种改变可能会带来维护数据一致性的挑战。
\
Matt指出，与微服务相关的产品通常会专注于服务组件的生命周期，鼓励开发者在实现服务时选择某些推荐的实现方式，例如Docker，并通过某些推荐的协议进行服务之间的交互，通常来说RESTful风格是一种自然的选择。
\\\\\通常来说，RESTful服务最适合于为某个数据模型提供CRUD操作，而微服务架构中的服务往往能够被轻易地分解为这些CRUD类型的服务，因此它与RESTful就能够很好地结合在一起。而对于其他类型的服务来说，类RESTful风格的服务通常也是一种良好的选择，这种类RESTful的风格也会使用HTTP作为传输协议，但服务本身并不一定要100%地符合RESTful的原则。
\
在Matt在文中提到SOA之后，他很快深入地谈论了SOA与微服务之间的关联：
\\\\\现如今，谈论SOA的各种不足似乎已经成为了一件很普遍的事。但如果你认真地观察，就会发现SOA的缺陷中的绝大部分与微服务是相同的，只是有关他们的案例更为具体一些。而两者的优势其实也大体相同，因为从本质上看，这两种技术所做的都是同一件事：将一个较大的问题分解为多个较小的问题。
\
随后，Matt进一步指出，那些通常被认为在，往往也乐于将他们的架构描述为面向服务的架构。不过，为了实现目标，这些公司通常会倾向于避免使用传统的SOA产品。按照Matt的观点来看，这些产品就是指专注于基于企业服务总线（ESB）的方案。但在Matt看来，之所以这些SOA产品名声不佳，是因为使用者在某些项目中将这些产品错误地用于进行应用程序的设计，而不是用于企业级架构的设计。这些产品本身在交付面向服务架构的方案开发时并不存在问题。
\\\\\就其本身而论，这些产品的特性主要专注于企业级的用例，并提供了多种方法用于追踪业务单元级别的SLA。大多数SOA产品都要求在服务的通信中使用一种或是少量的协议及消息格式，例如HTTP、FTP、SOAP和JMS等等，并提供连接器的代码库以实现通信功能。
\
实际上，相信ESB仍未消亡，它仍然能够在微服务架构中扮演重要的角色。
\\\\\通过使用ESB，你能够实现这一产品原本的目标，包括集成、编排、路由、（某些类型的）事件处理、相关性以及业务活动的监控。你也可以通过（微）服务构建你的应用，通过这些服务实现你的需求，解决你在业务上的问题。随后，你将自动地将这些服务独立地部署到某个可伸缩的运行时平台上，为这些服务提供标准化的接口。这些服务是松耦合的，他们能够通过大量一般水平的硬件实现线性的扩展。
\
显然，不仅仅是Matt，还有也相信，只是在组织中的应用层次不同。SOA专注于对“大型服务”进行编排操作，但这些大型服务也可以通过对一系列微服务进行组合而实现。当然，正如我们在中所说，服务的大小并不是一种定义微服务的好方法：
\\\\\在中表达了他对于的观点，以及他在同步的双向通信方案所看到的耦合问题。在他看来，仅仅使用服务的大小定义微服务并不是一种良好的衡量方法，并且也无助于判断某个服务是否具有正确的职责。
\
实际上，Matt相信，微服务的出现应当归功于SOA原则的成功（另一部分人则发现通过实施微服务，将），他的总结如下：
\\\\\作为一名开发者，如果你正在开发一个应用程序，那么微服务框架将能够带来更大的敏捷性，并为你提供更好的控制能力。而如果你的任务是在整个企业中对于大量的业务过程进行编排，那么SOA产品或许能够为你提供更适合的工具。
\
在2014年，我们曾经在一篇文章中过在来自Cap Gemini的Steve Jones与其他人之间进行的一次讨论，其观点是微服务并不是什么新鲜的东西。在当时，Steve是这么说的：
\\\\\在我看来，微服务只是一种为经过良好架构设计的SOA解决方案实现的面向服务的交付方案。SOA提供了上下文的框架，同时也提供了微服务所坚持的大部分规则。不仅如此，SOA还提供了一种更宽泛的上下文，使微服务能够在复杂的企业中符合这些上下文。许多人在不断地抱怨SOA中的各种WS-*协议、ESB的庞大以及各种极端复杂的项目，其实这只是面临的挑战不同而已。
\
这样看来，Matt并不是唯一一个认为SOA与微服务之间存在着密切联系的人，只是这些讨论往往是由具有深厚SOA背景的人所发起的。或许是因为那些微服务的提倡者在过去几年中没有深入地钻研过SOA，也可能是他们发现SOA或是那些旨在帮助用户通过SOA方法进行开发的工具中缺少了某些方面的内容？举例来说，，Bob Rhubart曾引用了Eberhard Wolff的文章，后者是adesso AG的技术咨询公告板的主管，同时也是一位自由职业的顾问以及培训师，他是这样谈论SOA与微服务的：
\\\\\SOA是一种能够改变整个企业的IT结构的战略创新，它将企业系统划分为不同的服务，为企业赋予了更大的灵活性……微服务必须能够独立地进行部署，而SOA服务往往是按照一体性的部署方式实现的。因此，虽然SOA与微服务技术有一定程度的相似性，但他们的本质是完全不同的。
\
然而，就在同一篇文章中，Oracle ACE部门的总监Torsten Winterberg说到：在他看来，“微服务正是我们在过去十年间一直在谈论的那种SOA”。这种SOA与微服务之间的关联的争论很可能还会持续很长一段时间，或许就像一样。实际上，TIBCO亚洲区的CTO Kevin Pool就将此称为一种。
\\\\\那么微服务的不同之处体现在哪里呢？在微服务架构中，每个操作（或方法）都是独立开发的。（在他的文章前半部分）我们所描述的那个单用户的SOA服务将分别实现为多个独立的微服务。这些服务之间一般不会定义正式的接口，或者仅仅是定义一种非常简单直接的接口。也无需定义具有复杂的架构层次和结构的中央式数据模型。好吧，或许我们需要定义某种通用的数据字典，但这一点在每个微服务中并非是强制性的，因为每个微服务都可以按照自身的需要，独立地整合相应的变更。每个微服务都实现了独立部署、停用或是重启等操作。在大多数场景中，各个独立的微服务将在一个统一的平台中执行。
\
Kevin在比较和对比SOA与微服务的不同之处时选择了一种非常特定于实现的视角，SOA的实现专注于ESB、SOAP和WSDL。不过，在今年早些时候，Coert van den Thillart在他的中对此给出了或许是最好的一次总结：
\\\\\微服务架构风格与SOA究竟有多大区别，回答完全取决于个人观点。在围绕着服务的概念创建架构这一方面，微服务提供了一种更清晰、定义更良好的方式。两者之间最关键的区别在于，微服务专注于以自治的方式产生价值。
\
在对SOA和微服务的各方面特性与实现途径进行比较与对比后，George Lawton相信，并且“修正了SOA中的一些遗留问题”：
\\\\\微服务的原则与思想是高度一致的，而它与SOA原则的演化的目标也是相同的，则减少传统的开发的高复杂性。
\
对于他的这篇文章，目前看来至少有一位留言者表示了赞同意见：
\\\\\我同意（包括其他留言）微服务并不是一种新思想的方法。在我看来，它更像是一种思想的精炼，并且更好地利用了先进的技术以解决问题，例如容器与自动化。
\
那么，你对此问题的观点是怎样的呢？微服务与SOA之间是否存在关联？我们所讨论的方向是否应偏重于如何通过技术（实现）手段以支持这两种架构，而不是专注于他们在架构上的区别？还是如同Matt所说，真正的区别在于数据的管理与所有权？这一争论是否完全没有存在的必要？或者是否正如所说的，那些不能铭记过去的人注定要重蹈覆辙呢？
\\查看英文原文：
转载地址：http://swwzx.baihongyu.com/