打破微服务的垄断：12个最佳实践与架构设计原则

导读：打破单体模式并切换到微服务体系架构似乎不那么难，但是许多情况下都低估了整体架构的复杂性。

 
传统上将应用程序整体开发出来，然后打包成一个应用程序包并做一个整体单元部署到服务器上。随着业务运营的发展，要维护整体架构的复杂性，加上业务和产品的复杂性，导致开发速度滞后。在后来，企业们开始寻求更可持续、灵活并易于集成的替代解决方案。
 
尽管下定决心要切换到微服务架构上，这似乎从理论和部分实践上并不那么难，但是很多企业低估了整体的复杂性，而且会犯下灾难性的错误。
 
微服务架构代表了执行单一业务功能，小型的，自动化且自运行的服务。我们找到一个比较经典的图片，显示了通过微服务API网关访问多个微服务。
 

 
如果想从单体架构快速到达“新时代”的微服务架构，那么贸然行动会造成大跃进式的错误。我想，你一定不会希望成倍的成本提升，以及在软件生命周期中遇到致命的问题。
 
 
以下是我们为你提供的微服务应该遵循的12个最佳实践。
 

具有独立的数据存储
 
在准备迁移到微服务之前，需要厘清不同构成的微服务进行分离数据存储。可用CQRS（命令与查询责任分隔）体系结构模式来实现，以保证数据对每个微服务来说都是独立并私有化。
 
如果不能将每个服务的成为数据唯一的所有者，即多个服务访问一个私有数据库，导致耦合性问题。
 
当然这并不是说微服务之间不能共享数据，它们之间只能通过API进行。
 
建立专用团队
 
微服务只有成为云原生应用时才会真正闪耀光芒。云原生应用需要相对快速并实时上线发布，如果出现停机，即使一秒钟都会给业务造成重大损失。
 
我们需要按计划线性高效的扩张，这时需要有专门的团队。
 
开发者已经很难掌握大型应用程序中每个端的解决方案，转换技术栈以及编程心态需要有一段时间。有一支熟悉管理的专家团队，了解细微差别并确保最大的效率，遵循微服务的最佳实践。
 
自动化进行独立部署
 
如果不能将单体架构分解为单一的微服务，是没有价值的。此外，需要确保自动化的实现构建和发布过程，这不仅帮助开发者减少交付的时间，还可以加快发布速度，改善部署过程。
 
活用REST API的优势 
 
使用和创建 REST API 为微服务插上翅膀，它不需要开发安装其它软件或库，没有绑定任何特定方法或资源，为我们提供了很大灵活性。
 
REST API可以处理多种类型的调用，返回不同的数据格式以及正确实施超媒体等能力。
 
理解文化的转变
 
从单体架构过渡到微服务，对于资深的开发者而言，迁移也并不像那么想像的顺利。人们以前都是在端到端的测试环境中工作，而到了微服务，人们需要突然转向大范围的一小部分，而管理层面则期望收益最大化。
 
这里需要了解，这不仅是操作上的而是文化上的转变。开发人员需要对新工作环境的预期和公司愿景有一定的了解，从而更好的进行日常开发。
 
将迁移拆分为多步骤
 
整体架构通常涉及一个存储库，包括部署、监视和其他复杂任务，想一次完成更改或迁移对于团队来说不可能，一定会留下错误和BUG。
 
解决最佳方案是保留（暂时）单体架构，开发独立功能作为微服务。一旦团队对新的流程清晰，前有了新微服务，就能弄清晰旧的架构如何转换为组件，并逐一迁移。
 
 
 
 

作者：老夏
来源：21CTO