微服务演进式设计与优缺点

演进式设计

微服务实践者通常来自演进式设计背景，并将服务分解视为进一步的工具，使应用程序开发人员能够控制应用程序中的更改，而不会降低变更速度。变更控制并不一定意味着改变 - 通过正确的态度和工具，您可以对软件进行频繁，快速和良好控制的更改。

每当您尝试将软件系统分解为组件时，您就面临着如何划分各个部分的决定 - 我们决定将应用程序分割的原则是什么？ 组件的关键属性是独立替换和可升级性的 - 这意味着我们寻找可以想象在不影响其协作者的情况下重写组件的点。实际上，许多微服务组织通过明确期望许多服务被废弃而不是长期发展来进一步考虑这一点。

Guardian 网站是一个设计和构建为整体的应用程序的一个很好的例子，但是已经在微服务方向上发展。单体应用仍然是网站的核心，但他们更喜欢通过构建使用单体应用 API 到微服务的演进。这种方法对于本质上是临时的功能尤其方便，例如处理体育赛事的专用页面。网站的这一部分可以使用快速开发语言快速组合在一起，并在事件结束后删除。我们在金融机构看到了类似的方法，为市场机会添加新服务，并在几个月甚至几周后丢弃。

这种对可替换性的强调是模块化设计的更一般原则的一个特例，即通过变化模式驱使我们朝着模块化方向演进。您希望在同一模块中保持同时更改的内容。很少变化的系统部分应该与目前正在经历大量流失的系统处于不同的服务中。如果您发现自己一再改变两项服务，那就表明它们应该合并。

将组件放入服务中可以为更细粒度的发布计划添加机会。对于单体应用，任何更改都需要完整构建和部署整个应用程序。但是，使用微服务，您只需要重新部署您修改的服务。 这可以简化并加快发布过程。缺点是您必须担心一项服务的变化会其消费者出现问题。传统的集成方法是尝试使用版本控制来解决这个问题，但微服务领域，不得已才采用版本控制这种方式。我们可以通过将服务设计为对供应商变更尽可能宽容来避免大量版本控制。

注意：上面的“版本控制”指代的是 api 的版本，比如某个 APP 从 2.0 升级到了 4.0。内部的 api 也跟着升级了，从 2.0 升级到 4.0，为了保证用户不更新 app 也能正常使用，所以这里 api 就会维护多个版本。

微服务是未来么？

我们写这篇文章的主要目的是解释微服务的主要思想和原则。通过花时间来做到这一点，我们清楚地认为微服务架构风格是一个重要的想法 - 值得认真考虑企业应用程序。我们最近使用这种方式构建了几个系统，并了解其他已经使用并支持这种方法的系统。

我们知道谁在某种程度上开创了架构风格，包括亚马逊，Netflix，The Guardian，the UK Government Digital Service，realestate.com.au，Forward and comparethemarket.com。2013年的会议电路充满了一些公司的例子，这些公司正在转向可以归类为微服务的公司 - 包括 Travis CI。此外，有很多组织长期以来一直在做我们称之为微服务的东西，但没有使用过这个名字。（通常这被标记为 SOA - 尽管如我们所说，SOA 有许多相互矛盾的形式。[15]）

然而，尽管有这些积极的经验，但我们并不认为我们确信微服务是软件架构的未来发展方向。虽然到目前为止我们的经验与单体应用相比是积极的，但我们意识到没有足够的时间让我们做出充分的判断。

通常，您的架构决策的真正后果只有在您制作它们几年后才会明显。我们已经看到一个项目，一个优秀的团队，对模块化的强烈渴望，已经建立了一个多年来已经腐朽的单体应用架构。许多人认为微服务不太可能出现这种衰退，因为服务边界是明确的，很难修补。然而，在我们看到足够多的系统、足够多的时间之前，我们无法完全认为微服务架构是已经成熟了。

人们可能会期望微服务成熟得很好。在组件化的任何努力中，成功取决于软件在组件中的适用程度。很难弄清楚组件边界的确切位置。演进式的设计会认识到正确边界的困难，因此很容易重构它们的重要性。但是当您的组件是具有远程通信的服务时，那么重构比使用进程内库要困难得多。跨服务边界移动代码很困难，需要在参与者之间协调任何接口更改，向后兼容也会变得复杂，并且测试变得更加复杂。

上面加粗的地方就是微服务架构的主要缺点！

另一个问题是如果组件没有清晰地组成，那么您所做的就是将复杂性从组件内部转移到组件之间的连接。这不仅仅是移动复杂性，而是将其移动到一个不那么明确且难以控制的地方。当你在一个小而简单的组件内部查看时，很容易认为事情会更好，同时缺少服务之间的混乱连接。（复杂性的转移）

最后，还有团队技能的因素。新技术往往被更熟练的团队所采用。但对于技能更高的团队来说，一种更有效的技术并不一定适用于技能较低的团队。我们已经看到很多不太熟练的团队构建混乱的单体应用架构，但是当微服务发生这种混乱时，需要花时间看看会发生什么。一个糟糕的团队总是会创建一个糟糕的系统 - 很难说微服务是否可以减少这种情况下的混乱或使情况变得更糟。（微服务架构是跟团队中每一个人的能力是息息相关的）

我们听到的一个合理的论点是，您不应该从微服务架构开始。相反，从单体应用开始，保持模块化，并在单体应用成为问题时将其拆分为微服务。（虽然这个建议并不理想，但是好的进程内接口通常不是一个好的服务接口。）

因此，我们谨慎乐观地写下这一点。到目前为止，我们已经看到了足够多的微服务风格，觉得它是一条值得走的路。我们无法确定最终会在哪里结束，但软件开发的挑战之一是您只能根据您当前必须提供的不完善信息做出决策。