|
|
51CTO旗下网站
|
|
移动端

12种从单体架构向微服务转型的设计原则与优秀实践

微服务架构虽然有着诸多优势,但是贸然从单体架构切换过去,可能导致成本的激增,以及灾难性的意外错误。本文和您一起讨论十二种值得遵循的,从单体架构向微服务转型的设计原则与优秀实践。

作者:陈峻编译来源:51CTO|2020-03-05 09:00

【51CTO.com快译】不知您是否还记得,过去传统的应用程序往往是作为一个整体被开发出来,然后被打包成为一个代码包,进而作为一个整体单元被部署的。一直以来,这种单体架构本身和与之相关的维护极具复杂性,而且开发与迭代速度也相当缓慢。这些都在促进软件开发企业去不断地寻求具有可持续性、灵活性、以及易于集成的新型替代方案。

微服务架构的出现打破了这样的僵局。它代表了众多小型、自动化和自包含的服务的单一集合。下图展示了系统如何通过一个API网关,去访问多个微服务的逻辑。

微服务架构虽然有着诸多优势,但是贸然从单体架构切换过去,可能会让许多企业由于低估了整体的复杂性,而导致成本的激增,以及在研发的关键时刻出现灾难性的意外错误。下面让我们一起讨论十二种值得遵循的,从单体架构向微服务转型的设计原则与优秀实践。

1. 提供单独的数据存储

在考虑迁移之前,请事先弄清楚将会如何根据各种微服务组件来分离数据的存储。您可以通过使用诸如“命令与查询责任隔离”(Command and Query Responsibility Segregation,CQRS,请参考:https://dzone.com/articles/microservices-with-cqrs-and-event-sourcing)之类的架构模式来实现,以使得数据对每一个微服务都是私有的。

如果各个服务都无法成为其数据的唯一所有者,那么就会导致多个服务需要访问同一个私有数据库的情况,即:产生了耦合问题。也就是说,我们最好不要在微服务之间直接共享数据,而是要通过API来实现。

2. 建立专门的团队

微服务的主要优势体现在云原生的应用上。这就意味着:任何更新,都需要相对快速且实时的发布。也就是说,任何停机都会给业务造成重大的损失。因此,如果您想进行线性且高效的扩展,就需要为每个微服务分配专门的开发团队。

不过,光靠开发人员则很难掌控大型应用全面的端到端方案。我们需要拥有一支专业的团队,在熟悉管理细微差别的基础上,凭借转换技术与开发效率,进而遵循微服务的各项优秀实践。

3. 使用自动化进行独立部署

为了将单体架构分解成为多个单独的微服务,我们需要确保实现“构建和发布”的自动化结构。这样不仅可以有助于减少总体的交付时间,而且可以加快发布的速度,进而改善部署的整个过程。可以说,有了自动化,微服务就能够被妥善地封装到容器中,并能够有效地部署到包括云端在内的任何环境里。

4. 利用REST API的好处

开发人员在创建REST(Representational State Transfer,表示性状态传输)API时无需安装任何其他的软件与库,因此它为微服务提供了巨大的灵活性,数据也不再绑定到任何特定的方法或资源之上。通过REST API,微服务可以处理多种类型的调用,返回不同的数据格式,以及具有通过正确地实施超媒体,来修改结构的能力。

5. 了解文化的转变

对于传统的开发人员而言,他们习惯了端到端的测试环境。而随着从单体架构迁移过渡到基于微服务的架构,他们必须突然从大的格局转为关注一小部分的功能,而且管理层对此还充满了期望。可见,这更大程度上是文化上的转变,而不仅仅是开发技术上的变化。也就是说,开发人员需要理解和平衡公司愿景与自身工作方式的转换。

6. 将迁移分解为多步骤

如果您过去从未处理过此类迁移,那么请您做好无法一蹴而就的准备。单体架构通常会涉及一个包含有存储库、部署、监控、以及其他复杂任务的协作网络。因此,最好的方法之一就是:在暂时保留单体结构的基础上,并行开发其他作为微服务的功能。一旦实现了新的服务,同时团队也已对新的流程有所了解,我们就可以在厘清如何将旧的架构分解成为相关组件的基础上,开始逐一进行迁移。

7. 在混合系统上构建分离系统

定义不同复杂部分之间的交互作用和过程,是微服务的关键设计原则与优秀实践之一。因此,我们在迁移项目的初始阶段,就应当考虑到拆分系统。每个拆分系统都应当对于正在构建的架构来说是唯一的。我们可以通过检查单体结构,来持续监控各个组件的性能,以便了解各个组件之间的差异性,以及在微服务转换时可能出现的问题。

我们可以参考如下监视过程的工具:

8. 隔离运行时(Runtime)进程

由于我们往往针对不同的垂直细分领域有着不同的流程,因此我们需要在运行时的级别上也具有一定的隔离性。例如,您可以通过某种形式的分布式计算,来分别实现容器化、事件架构、各种HTTP管理方法、服务网格和断路器(circuit breakers)等。

9. 将正确的技术与正确的微服务相配对

正所谓殊途同归。也许在您的团队中,不同的成员会偏好使用不同的技术和编程语言来实现微服务,但是请尽量选用那些易于日后方便更改或替换的技术,来实现快速上手与直接迭代。当然,如果您并不确定哪种技术最适合自己的项目,那么请在决策过程中考虑以下方面:

  • 可维护性。
  • 容错性。
  • 可扩展性。
  • 构建成本。
  • 易部署性。

10. 考虑使用域驱动式设计(Domain-Driven Design)

域驱动式设计在某种程度上可以被理解为:应用于业务模型的面向对象编程。作为一种设计原则,它利用实践规则和思想来表达面向对象的模型。简单来说:我们需要围绕着自己的业务领域来设计微服务。例如,Netflix等平台就是使用不同服务器上的微服务,来进行内容交付和相关的跟踪服务。

11. 区分专用资源和按需资源

如果您的主要目标是提供卓越的客户体验,那么请考虑将专用资源和按需资源区分开来。例如,针对某个电子商务平台,我们可以通过构建其微服务和云架构,来实现快速且安全地在内部平台和云环境之间,部署并转移不同的工作负载。这样不仅缩短了资源的响应时间,也使得迁移到云端的流量与资源更加直观。

12. 治理对开源工具的依赖

对于开发人员来说,使用开源的微服务工具进行安全性、监控、调试、以及日志记录,可谓“家常便饭”。但是,请确保不会以过分依赖某些库和工具的方式,去干扰架构的性能或安全性。我们可以参考如下方面,同时根据实际的开发需求和所用到工具的类型,来实施各种适当的组织策略。

  • 为已批准的软件版本,建立正式的存储库。
  • 了解开源软件的供给关系。
  • 建立处理异常的治理方案。

总结

综上所述,从单体架构向微服务架构转型的确极富挑战性。上述设计原则与优秀实践为您提供了参考的思路与方法,您可以在实际开发与迁移过程中,根据实际情况,按需采取逐步的方法,即:先从整体系统中的一小部分,而且是非关键的部分入手,通过厘清当前各个组件的工作原理,以及了解微服务的相关技术与文化,进而建立逐步的迁移计划。同时,这样也更容易获取利益相关者,乃至组织层面上的支持。

原文标题:Break a Monolith to Microservices — 12 Best Practices and Design Principles,作者:Mitul Makadia

【51CTO译稿,合作站点转载请注明原文译者和出处为51CTO.com】

【编辑推荐】

  1. 在数据科学中使用 C 和 C++
  2. Kafka架构原理,也就这么回事!
  3. 每个程序员都必须知道的8种通用数据结构
  4. 4种更快更简单实现Python数据可视化的方法
  5. 无代码,如何重燃你与数据科学的关系?
【责任编辑:张燕妮 TEL:(010)68476606】

点赞 0
分享:
大家都在看
猜你喜欢

订阅专栏+更多

VMware NSX 入门到实战

VMware NSX 入门到实战

网络虚拟化革命性技术
共16章 | Cloud袁

108人订阅学习

消息队列Kafka运维实践攻略

消息队列Kafka运维实践攻略

入门级消息队列
共3章 | 独行侠梦

105人订阅学习

编程零基础,Scratch 开发小游戏

编程零基础,Scratch 开发小游戏

游戏化编程
共5章 | googlingman

42人订阅学习

视频课程+更多

你必学的SSM实战案例

你必学的SSM实战案例

讲师:齐毅24661人学习过

Excel企业实战与解决方案开发教程3

Excel企业实战与解决方案开发教程3

讲师:王子宁110278人学习过

IPv6技术精讲-Wakin出品

IPv6技术精讲-Wakin出品

讲师:谢斌1360人学习过

订阅51CTO邮刊

点击这里查看样刊

订阅51CTO邮刊

51CTO服务号

51CTO官微