实施微服务架构前，你得想明白这几件事

对于任何一家技术企业来说，敏捷性都是至关重要的。面对不断变化的技术和行业环境，如果一家公司需要花很长时间才能对变革做出反应，那么结果很可能是将市场份额拱手让给更敏捷的公司。

而微服务将应用拆分成小业务单元进行开发和部署，使用轻量级协议通信，通过协同工作实现应用逻辑的架构模式，给予了应用更高的敏捷性、可伸缩性和可用性，而这也正是公司在扩大和推出新业务时所急需的。

听起来很有价值，事实上微服务架构也的确称为了众多前沿公司的可行选择，但在实施之前，你得想明白这几件事：

业务是否足够大

你的业务是否足够大，有必要让开发团队在复杂项目上分头工作？如果没有，你可能暂时并不需要微服务架构。就像Martin Fowler所说，微服务架构的生产力成本只适用于大型复杂的软件项目。

是否需要独立部署组件

如果你部署的软件项目有至少两个domain，每个domain代表完全独立的业务能力或流程，那么实施微服务架构将是一个适合的选项。这样做可以使应用的各个组件开生命周期独立开来，在更新或部署应用程序时，不会影响其他组件。此外，可以让每个组件采用不同的编码语言。当然，微服务架构同时会需求单一组件由专门的开发团队动态管理，因此你需要确保有足够的人才和预算来这么做。

团队是否有足够能力

微服务架构意味着，你需要创建专门从事某些专业领域的小型开发团队，提高新功能开发和增强竞争优势的能力。

因此团队是否成熟，是否可以实现CI/CD，是否理解DevOps？如果答案是否定的，着手建立更强大的工程师团队，或找到可以帮助补充团队能力的外部资源，例如像Heroku、好雨云这样的提供开发、运维、应用交付支持的云平台。

公司的roadmap是否实际

指数级的扩张能力让一些巨头公司发展成了现在的样子。例如Airbnb，在不到10年的时间里，从床位租赁网站发展成为了300亿美元规模的数据驱动型marketplace。对于成长型公司来说敏捷十分重要，但不是所有公司都有很大的扩张需求。如果你不需要面对复杂性的问题，那么其实是没必要实施微服务架构的。

因此要对公司的发展有一个客观的判断，至少是短时间内的成长判断，最好不要让开发流程在不需要复杂的时候过于复杂。

最后，当你确定要实施微服务架构，以下几点经验值得留意：

实施微服务架构后，一定要广泛使用一旦实现了微服务架构，一定要广泛使用领域驱动设计（DDD，Domain Driven Design），特别是bounded contexts

对于bounded contexts的定义没有特别的规定，这取决于你使用的domain，当然一般情况下，context map是不错的选择

每个微服务应代表一个业务能力的，你应该专注于把组件做好，独立于其他服务

确保你的团队结构跟定制的bounded contexts保持一致。为了更好的享受微服务架构的优势，你的团队应该围绕业务能力建立，而不是建立会增加额外负担的“横向”团队