微服务先决条件

在我与人们谈论使用微服务架构风格时，我听到了很多乐观的声音。开发人员喜欢使用更小的单元，并且期望比单体架构更好的模块化。但与任何架构决策一样，都需要权衡利弊。特别是对于微服务，运维会产生严重的影响，他们现在必须处理的是一个小型服务的生态系统，而不是一个定义明确的单体应用。因此，如果您不具备某些基本能力，则不应考虑使用微服务风格。

快速配置：您应该能够在几个小时内启动一台新服务器。这自然适合云计算，但这也是可以在没有完整云服务的情况下完成的事情。为了能够进行如此快速的配置，您需要大量的自动化——它可能不需要一开始就完全自动化，但要稍后进行严肃的微服务，它就需要自动化。

基本监控：在生产环境中，许多松散耦合的服务协同工作，事情必然会以在测试环境中难以检测到的方式出错。因此，必须建立一个监控机制来快速检测严重问题。这里的基线是检测技术问题（统计错误、服务可用性等），但监控业务问题（例如检测订单下降）也很有价值。如果出现突发问题，您需要确保可以快速回滚，因此…

快速应用程序部署：由于要管理许多服务，您需要能够快速部署它们，无论是到测试环境还是生产环境。这通常涉及一个部署流水线，它可以在不超过几个小时内执行。在早期阶段，一些人工干预是可以的，但您很快就会希望将其完全自动化。

这些能力意味着一个重要的组织转变——开发人员和运维人员之间的密切合作：DevOps文化。这种协作是确保快速配置和部署所必需的，它对于确保您在监控指示问题时能够快速反应也很重要。特别是任何事件管理都需要开发团队和运维团队的参与，无论是解决眼前的问题，还是进行根本原因分析以确保底层问题得到解决。

有了这种设置，您就可以准备使用少量微服务的第一个系统了。部署此系统并在生产环境中使用它，期望学习很多关于如何保持其健康以及确保开发运维协作良好运作的知识。给自己时间去做这件事，从中学习，并在增加服务数量之前培养更多能力。

如果您现在不具备这些能力，您应该确保培养它们，以便在您将微服务系统投入生产环境时做好准备。事实上，这些能力也是单体系统应该具备的能力。虽然它们在软件组织中并不普遍存在，但在很少有地方不应该将其作为高度优先事项。

超越少数服务需要更多。您需要跟踪跨多个服务的业务交易，并通过完全拥抱持续交付来自动化您的配置和部署。还需要开始向以产品为中心的团队转变。您需要组织您的开发环境，以便开发人员可以轻松地在多个存储库、库和语言之间切换。我的一些联系人感觉到，这里可能有一个有用的成熟度模型，可以帮助组织采用更多的微服务实现——我们应该会在未来几年看到更多关于这方面的讨论。