如何设计最佳的微服务架构 -DZone

原文转载自 「解道JDON」 ( https://www.jdon.com/53706 ) By 解道

预计阅读时间 0 分钟(共 0 个字, 0 张图片, 0 个链接)

企业正在迅速采用微服务架构来创建灵活,可扩展的应用程序,这些应用程序可以快速迭代,具有较高的容错能力和较低的停机时间。您如何构建正确的微服务架构?

尽管确切的架构会有所不同,但是有一些最佳实践可以帮助设计有效和最佳的微服务架构。

领域驱动设计

微服务的重点是将统一架构分解为更小,更易管理的部分。必须以对所有利益相关者都有意义的方式来完成这种分解。

定义单个微服务范围的几种常用方法:

  • 创建与应用程序开发过程中存在的不同运营团队相对应的微服务。例如,一个团队可能正在研究用户身份验证,另一个团队正在研究数据收集,并且每个团队都应负责创建一组实现特定任务的微服务。
  • 创建与特定功能相对应的微服务。例如,分析应用程序可以具有聊天机器人功能,可视仪表板,数据分析功能等。这些中的每一个都可以创建为单独的片段,并通过API进行交流。

这个想法是创建一组独立的服务,以提供集中的增值服务。面临的挑战是避免将过多的功能过度填充到一个微服务中。通常建议将代码保持足够简单,以便在需要时可以轻松地重新部署。

独立微服务

微服务的独立性是其有效性的关键。它们松散耦合并且可以在没有复杂的相互依赖性的情况下工作,这一事实确保了整个应用程序不会由于单点故障而崩溃。因此,在一些关键领域中必须确保独立性:

  • 独立团队:理想情况下,每个微服务都应拥有自己的专门团队,其中包括产品经理和DevOps团队。一支团队将每项服务从开发到部署的过程,都有助于减少发布频率和最大程度地延长正常运行时间。
  • 自动进行独立部署:自动化构建和发布周期,并确保每个微服务都可以独立于其他微服务进行部署,这对于设计良好的应用程序至关重要。这样,它们可以在任何环境下启动并运行。
  • 单独的存储:每个微服务都应拥有自己的特定数据库,而其他所有需要该数据的服务都应仅通过API进行访问。在短期内,共享数据库似乎是一个方便的选择。但是随着微服务的扩展,这种共享导致它们相互耦合,从而破坏了目标。
  • 隔离故障:为了确保即使一项服务出现故障,应用程序也可以继续运行,微服务架构需要隔离故障。一种常用的方法是在应用程序中建立断路器。当服务失败超过设置次数后,断路器将跳闸,并立即使给定时间段内对该服务的所有请求失败。该服务提供的功能在该时间段内仍然不可用,即使应用程序的其余部分保持正常工作也是如此。超时后,断路器允许通过几个请求,如果成功,则恢复为正常操作。

与此类似,其他设计模式(例如异步通信和事件驱动的体系结构)也可以用于故障隔离。

不变的基础设施

不变的基础架构将服务分为数据和“其他”,并且在每个版本中都将“其他”部分替换。创建新版本的微服务,而不是立即更新当前版本。新版本经过测试和微调,而旧版本是应用程序正在使用的版本。仅当新版本稳定时,才可以将其与前一个版本合并。

标准制定​​​​​​​

随着组织更多地依赖微服务架构,不同的团队从事不同的服务,流程和实践可能会因团队而异。每个团队可以开始进行不同的开发,部署和错误处理。这可能导致不同团队重复执行许多代码,从而影响效率和周转时间。

因此,建议创建团队可以遵守的组织范围的标准。微服务创建和部署的过程以及它们相应的API应该有充分的文档记录。这也使不同的团队可以了解正在使用的其他微服务API,以及如何最好地使用它们。​​​​​​​

 

              
more_vert