译者注：原文 Microservice Prerequisites，作者 Martin Fowler 在 ThoughtWorks 任首席科学家，著作包括《重构 改善既有代码的设计》和《企业应用架构模式》等。

当我与人们聊微服务架构时，总能收到许多乐观的观点。开发者们更喜欢在一些较小的单元上开展工作，期望一个比单体系统更模块化的东西。但是任何架构决策必然要权衡利弊，有得有失。具体到微服务上：开发者不再面对一个明确的单体应用，而是许多小型服务构成的生态系统。因此如果你不具备某些基本能力，就不应该考虑使用微服务。

快速配置（Rapid Provisioning）

你应当能够在几小时内配置好一台新的服务器。云服务商通常有完备的解决方案，不过没有的话事情也是可以进行的。如此快速的配置需要大量自动化工作 —— 一开始不必完全自动化，但是严肃的微服务（译者注：考虑到我们要拿它来赚钱）最终总会要求这一点。

基础监控（Basic Monitoring）

生产环节中松散耦合的微服务必然会出现测试环境中难以检测的问题。因此需要建立一个监测机制来快速发现问题。系统至少要能够监测一些技术问题，例如错误计数、服务可用性等等。业务问题例如订单量下降，也是有监控价值的。为了应对突发状况，你得保证能够迅速回滚系统，这就来到了……

应用程序快速部署（Rapid Application Deployment）

有这么多服务需要管理，你得实现测试环境和生产环境的快速部署。通常这事涉及到一个几小时内可以完成任务的部署管线。人工介入是可接受，不过很快就要找一种完全自动化的方法来接管。

DevOps 文化

以上这些能力意味着组织需要实现一个重要的转变 —— 开发团队和运维团队之间能够紧密合作，而这就是 DevOps 文化。只有存在这种合作，快速部署才能够实现。也只有这种合作，线上监测到故障时才能够快速响应。任何故障事件都需要开发团队和运维团队的参与，既要立即解决问题，又要寻找问题的根源。

在这样的前提下，你可以开始用几个微服务构建新系统了。在生产环境中部署和使用这个系统，学习如何维护这个系统，如何维护 DevOps 合作关系。慢慢掌握这些能力，然后适当地增加服务的数量。

就算是处理单体应用，以上能力也是每一位开发者应该具备的。虽然不是所有的企业和相关职位都要求这个，很少有地方不认为它们是加分项。

管理一大堆微服务比几个微服务难得多。你得在多个服务间追踪业务事务，并且要完全拥抱持续集成。这时候团队也开始转向"产品优先"。你也得组织好开发环境，这样开发者在不同仓库和语言间切换也更加轻松。

译者提供的延伸阅读

雪花与凤凰

什么是雪花实例？你使用一台 ECS /虚拟机/容器或是别的什么东西，用 SSH 连上了，yum 还是 apt 什么的，如此这般那般配置好了服务。你不知道实例重启之后会发生什么，其他人也不知道些东西是如何配置的，这就是雪花实例，就像雪花一样独一无二且脆弱。

什么是凤凰实例？你把上面这些写成了脚本，使用脚本来部署，如果服务出了问题，你 SSH 上去，找到问题。你从来不在服务器上解决问题，你只是返回来更正了脚本并提交到版本控制，然后重新部署这个实例，就像凤凰浴火重生。

如果要做微服务，你得站在凤凰这边。

Amazon 的设计原则

• Deployment Independence: updates to an individual microservice have no negative impact to any other component of the system. Optimized for Replacement
• Organized around business capabilities
• Products not Projects
• API-Focused
• Smart endpoints and dumb pipes
• Decentralized Governance
• Decentralized Data Management
• Infrastructure Automation (infrastructure as code)
• Design for failure
• Evolutionary Design