微服务设计原则_微服务系列：微服务设计原则

最新推荐文章于 2024-03-26 12:57:29 发布

danpu0978

最新推荐文章于 2024-03-26 12:57:29 发布

阅读量245

点赞数

文章标签： java python 设计模式数据库分布式

原文链接：https://www.javacodegeeks.com/2016/12/microservices-series-microservices-design-principles.html

版权

微服务设计原则

介绍

每个体系结构都是根据某些设计原则构成的，微服务也是如此。本文不会讨论微服务的全部内容。已经有很多文章和博客可以做到这一点。在本文中，我将讨论设计基于微服务的体系结构需要做什么。我们将研究设计基于微服务的应用程序时应考虑的一些设计原则。

隔离

服务必须设计为独立运行。当您将一个整体系统分解为一组服务时，有必要使这些服务彼此分离，使其更具凝聚力和自给自足。每个服务应能够处理其故障而不会破坏整个应用程序或系统。隔离和解耦使服务能够快速从故障状态中恢复。该服务的隔离特性具有以下优点：易于采用连续交付，更好的扩展性，有效的监视和可测试性。

自主性

隔离为自治铺平了道路。服务必须设计为自治的。它必须具有凝聚力，并能够独立完成其功能。每个服务都可以使用定义良好的API（URI）独立调用。 API以某种方式标识服务功能。自治服务还必须处理其自身的数据。流行的术语是多语言持久性，其中每个服务都有自己的持久性存储。自治还确保了弹性。自主服务具有以下优点：有效的服务编排和协调，更好的扩展，通过定义明确的API进行通信，更快和受控的部署。

单一责任

服务必须设计成具有高度凝聚力。单一责任原则是服务仅执行一项重要功能。单一责任方面与术语“微型”紧密结合。微型确实意味着小型，细粒度，并且仅在其职责范围内相关。单一职责功能具有以下好处：服务组合是无缝的，更好的扩展性，可重用性，可扩展性和可维护性。

有界上下文

您的服务大小应该是多少？百万美元的问题？答案就在于所谓的“ 绑定上下文”设计原则。这是设计域驱动设计（DDD）建模方法时的关键模式。有界上下文就是有关定义微服务将在其中提供其服务的上下文的。这是关于评估域模型并确定离散边界，并相应地设计微服务以使其更具凝聚力和自治性。这也意味着跨边界的通信变得更加高效，并且在一个有限的上下文中您的服务不需要太多依赖于另一个有限的上下文中的服务。

异步通讯

在绘制离散边界并使用其自己的有限上下文设计服务时，跨边界的服务通信必须是异步的。通信的异步模式自然会导致服务之间的松散耦合，并允许更好的扩展。使用同步通信，您将阻止呼叫并等待响应。处于阻塞状态的服务无法执行其他任务，直到接收到响应并释放基础线程。这会导致网络拥塞，并影响延迟和吞吐量。异步通信还可以引入实现定义良好的集成或通信模式的概念，以实现涉及不同服务的逻辑工作流。

位置无关

从设计上来说，微服务是部署在虚拟化环境或Docker容器中的不错选择。随着云计算的到来，我们可以拥有大量可以利用动态扩展环境的服务实例。这些服务可以在小型或大型群集的多个节点上运行。服务本身可以根据基础计算资源的可用性或效率进行重定位。一个人必须能够以与位置无关的方式来寻址或定位服务。通常，可以使用不同的查找发现模式来使用您的服务。服务的客户端或使用者不必担心特定服务的部署或配置位置。它只是使用某种逻辑或虚拟地址来定位服务。有关服务发现的更多信息，您可以参考服务发现模式文章。

微服务不是技术，框架或解决方案。它是一种体系结构样式，可为您提供一种处理整体应用程序复杂性的方法或方法。该方法从上述设计原则开始，您可以使用这些设计原则来构建基于微服务的应用程序。