本文翻译自：https://martinfowler.com/bliki/MicroservicePrerequisites.html
当我与人们谈论使用微服务架构时，我听到了很多乐观的观点。 开发人员喜欢与较小的单元一起工作，并期望具有比整体更好的模块化。 但是，与任何架构决策一样，需要权衡利弊。 特别是对于微服务，操作会产生严重后果，他们现在必须处理小型服务的生态系统，而不是单一整体的、定义明确的巨型服务。 因此，如果您没有某些基线能力，则不应考虑使用微服务风格。
快速配置
您应该能够在几小时内启动新服务。 当然，这适用于云计算，但它也可以在没有完整云服务的情况下完成。 为了能够进行这样的快速配置，您需要进行大量的自动化 - 它可能不必完全自动化，但是为了做到严肃的微服务，它将需要这样做。
基本监控
由于许多松散耦合的服务在生产中协作，因此在测试环境中难以检测到的方式肯定会出错。 因此，必须建立监控机制，以便迅速发现严重问题。 这里的基线是检测技术问题（计算错误，服务可用性等），但也值得监控业务问题（例如检测订单下降）。 如果出现突然问题，那么您需要确保可以快速回滚，因此需要下面的快速部署能力。
2点：
- 技术问题监控
- 业务问题监控
快速应用程序部署
要管理许多服务，您需要能够快速部署它们，以便测试环境和生产。 通常这将涉及可以在不超过几个小时内执行的部署流水线。 在早期阶段，一些人工干预是正常的，但您将很快寻求完全自动化。
总结
这些功能意味着重要的组织转变 - 开发人员和运营之间的密切合作：开发运维文化。 需要进行此协作以确保快速完成配置和部署，确保在监控指示问题时能够快速做出反应也很重要。 特别是任何事件管理都需要涉及开发团队和运维团队，既可以解决当前问题，也可以追寻根本原因分析，以确保解决潜在问题。
有了这种设置，您就可以使用一些微服务为第一个系统做好准备。 部署此系统并在生产中使用它，期望学到很多关于保持健康并确保devops协作运行良好的信息。 在增加服务数量之前，给自己时间做这些，从中学习，增加更多能力。
如果您现在没有这些功能，那么您应该确保开发它们，以便在您将微服务系统投入生产时做好准备。 实际上，这些功能对于单片系统来说也应该是你应该拥有的。 虽然它们并非普遍存在于软件组织中，但很少有地方不重视它。
超越少数服务将需要更多服务。 您需要通过多种服务跟踪业务事务，并通过完全接受持续发布来自动化您的配置和部署。 还需要启动以产品为中心的团队转变。 您需要组织开发环境，以便开发人员可以轻松地在多个存储库，库和语言之间进行交换。 我的一些联系人感觉到这里可能有一个有用的成熟模型可以帮助组织进行更多的微服务实现 - 我们应该在未来几年内看到更多的成果。