从企业视角来看微服务与集成

Kim Clark 在集成小组以及大公司围绕的业务中所遇到的常见误区有微服务就是精细粒度的 WSDL 操作，或者 APIs 就是微服务。在今年举办在伦敦的微服务会议上，Clark 在一篇演讲中声称产生这种现象的一个原因就是他们把接口粒度和组件粒度混淆在一起，他讨论了微服务的运动以及与集成架构相比的异同之处。这种关于微服务和它们与集成的关系之间的混淆让他想知道，是否_ 微服务架构_ 真的应该被称为_ 微组件架构_。

Clark，在 IBM 工作专注于集成，声称 SOA 真的试图重构 IT 规划，把它变成与更好的业务需求保持一致的组成部分，并且公开所需的服务。把一些事分成更小的组成部分也是微服务式的架构并且微服务之后开始正确使用 SOA。由于这个原因，他认为可能 SOA 原则会再一次正确运作。但是 SOA 有个他所描述的巨大的问题就是资金。没有一个项目想要承担初始成本，因为它没有为企业带来任何好处。他相信如今这已经改变了, 当我们可以公开 APIs 到企业之外并且随着真正的钱进入组织来潜在地寻找融资模式时。

Clark 强调大企业的前景是可怕的，由于兼并和收购等，可能导致超过一个系统拥有相同类型的数据。有极长生命周期的实体或数据，比如，抵押贷款或退休金，随着模型的复杂性增加并且商业规则也加入那张蓝图中。

当展望 Clark 的愿景时，在未来，企业内部的所有应用程序都是用标准化的接口来绑定。并且最重要的是，随着这些接口的公开，并由团队管理编写程序，而不是由一个完全独立的集成团队用如今很常见的自己的工具来做。实际上，这就意味着联合和分散整个集成问题到团队。事实上，Clark 相信这会对许多组织来说是持久的，这将是一些后端系统现代化的进化，可能分解成许多微服务应用，但也有大量的应用程序完全没有改变，对此没有任何理由可以解释。

Clark 最后描述了在他与客户谈话时他所碰到的一些容易混淆的比较，谈话往往始于一些术语斗争：

• 微服务与 SOA。这是比较一个架构中的组成成分。它的意图可能是把 SOA 和微服务架构作比较。
• 微服务与 APIs。这是比较接口，一种揭示业务功能的机制，随着组件实现那些无意义的功能。
• 微服务与服务。服务是一个抽象的概念并且必须适用于一项有意义的比较。

明年的微服务会议计划在2016 年11 月7 日至8 日在伦敦召开。

查看英文原文： Microservices and Integration from an Enterprise Perspective

感谢张龙对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们，并与我们的编辑和其他读者朋友交流（欢迎加入 InfoQ 读者交流群（已满），InfoQ 读者交流群（#2））。