12从单体架构过渡到微服务的设计原则和最佳实践代码包反过来作为一个整体进行部署。一直以来，这种单体架构本身以及与之相关的维护都异常复杂，开发迭代的速度也相当缓慢。这些都在推动软件开发公司不断寻求可持续、灵活且易于集成的新替代方案。微服务架构的出现打破了这个僵局。它代表许多小型、自动化和独立服务的单一集合。下图展示了系统如何通过API网关访问多个微服务的逻辑。虽然微服务架构有很多优势，但贸然从单体架构转向，可能会导致很多公司低估整体的复杂性，导致成本激增，在研发的关键时刻出现灾难性的意外错误。让我们讨论十二个值得遵循的设计原则和良好实践，以便从单体架构过渡到微服务。1.提供单独的数据存储在考虑迁移之前，请提前想好数据的存储将如何根据各种微服务组件进行分离。您可以通过使用诸如命令和查询责任分离（CQRS，请参阅：https://dzone.com/articles/microservices-with-cqrs-and-event-sourcing）模式之类的架构来使数据对每个微服务私有.如果每个服务不能是其数据的唯一所有者，就会导致多个服务需要访问同一个私有数据库的情况，即出现耦合问题。也就是说，我们最好不要直接在微服务之间共享数据，而是通过API。2、建立专门的团队微服务的主要优势体现在云原生应用上。这意味着：任何更新都需要相对快速且实时地发布。也就是说，任何停机时间对企业来说都是代价高昂的。因此，如果你想线性高效地扩展，你需要为每个微服务分配一个专门的开发团队。然而，仅靠开发人员很难掌握大型应用程序的全面端到端解决方案。我们需要有一个专业的团队，在熟悉管理细微差别的基础上，依靠转换技术和开发效率来遵循微服务的最佳实践。3.独立部署使用自动化为了将单体架构分解成多个独立的微服务，我们需要确保“构建和发布”的自动化结构。这不仅有助于缩短整体交付时间，还可以加快发布速度，从而改进整体部署流程。可以说，有了自动化，微服务就可以被恰当地打包到容器中，有效地部署到包括云端在内的任何环境中。4.使用RESTAPI的好处开发者在创建REST（RepresentationalStateTransfer）API时不需要安装任何其他软件和库，因此它为微服务提供了极大的灵活性，数据不再绑定到任何特定的方法或资源上。通过RESTAPI，微服务可以处理多种类型的调用，返回不同的数据格式，并具有通过超媒体的正确实现来修改结构的能力。5.了解文化转变对于传统开发人员来说，他们习惯于端到端的测试环境。当他们从单一架构转向基于微服务的架构时，他们不得不突然从大局转向专注于一小部分功能，而管理层也预料到了这一点。可以看出，这更多的是一种文化变革，而不仅仅是开发技术的变革。换句话说，开发人员需要了解并平衡公司愿景和自己工作方式的转变。6.将迁移分解为多个步骤如果您过去从未处理过这种类型的迁移，请做好它不会在一夜之间发生的准备。单体架构通常涉及存储库、部署、监控和其他复杂任务的协作网络。因此，最好的方式之一就是在暂时保留单体结构的基础上，将其他功能并行开发为微服务。一旦新的服务实现了，团队了解了新的流程，我们就可以在弄清楚如何将旧架构分解成相关组件后，开始一个一个地迁移。7.在混合系统上构建单独的系统定义不同复杂部分之间的交互和流程是微服务的关键设计原则和最佳实践之一。因此，我们应该在迁移项目的初期就考虑拆分系统。每个拆分系统对于正在构建的体系结构都应该是唯一的。我们可以通过检查单体结构来持续监控每个组件的性能，以了解每个组件之间的差异以及微服务转换过程中可能出现的问题。流程监控可以参考以下工具：NewRelicDatadogInfluxDBGrafana8。隔离运行时（Runtime）进程由于我们经常会有不同的垂直段不同的进程，所以我们需要在运行时级别隔离有一定的控制。例如，您可以通过某种形式的分布式计算分别实现容器化、事件架构、各种HTTP管理方法、服务网格和断路器。9.将正确的技术与正确的微服务配对是一回事。或许在你的团队中，不同的成员更喜欢使用不同的技术和编程语言来实现微服务，但请尽量选择未来容易改变或替换的技术，以实现快速启动和直接迭代。当然，如果您不确定哪种技术最适合您的项目，请在决策过程中考虑以下因素：可维护性。容错。可扩展性。建设成本。易于部署。10.考虑使用领域驱动设计（Domain-DrivenDesign）领域驱动设计在某种程度上可以理解为：面向对象编程应用于业务模型。作为一种设计原则，它使用实践规则和思想来表达面向对象模型。简单地说：我们需要围绕我们的业务领域设计微服务。例如，Netflix等平台在不同的服务器上使用微服务进行内容交付和相关跟踪服务。11.区分专用资源和按需资源如果您的主要目标是提供出色的客户体验，那么请考虑区分专用资源和按需资源。例如，对于电子商务平台，我们可以通过构建其微服务和云架构，在内部平台和云环境之间快速、安全地部署和传输不同的工作负载。这不仅缩短了资源的响应时间，也让迁移到云端的流量和资源更加直观。12.对开源工具的治理依赖对于开发者来说，使用开源微服务工具进行安全、监控、调试、日志等工作可谓是“家常便饭”。但是，请确保您不会因过度依赖某些库和工具而影响架构的性能或安全性。我们可以参考以下几个方面，根据实际开发需要和使用的工具种类，实施各种合适的组织策略。为批准的软件版本建立正式的存储库。了解开源软件的供应关系。建立处理异常的治理方案。总结综上所述，从单体架构到微服务架构的转变确实极具挑战性。以上设计原则和良好实践为大家提供了思路和方法，供大家参考。在实际的开发和迁移过程中，可以根据实际情况采取循序渐进的方式，即从整个系统的一小部分开始，然后从非关键部分开始，建立渐进式迁移通过明确每个当前组件的工作原理并了解微服务的相关技术和文化来进行规划。同时，也更容易获得利益相关者乃至组织层面的支持。原标题：BreakaMonolithtoMicroservices—12BestPracticesandDesignPrinciples，作者：MitulMakadia
