面向领域的微服务架构解析

如果我们可以将微服务视为I / O绑定的库，而将“微服务架构”视为大型的分布式应用程序，则可以使用众所周知的架构来思考如何组织代码。

因此，“面向领域的微服务体系结构”大量借鉴了组织代码的既定方法，例如 域驱动设计 ， 清晰架构 ， 面向服务的体系架构 以及面向对象和面向接口的设计模式。 我们认为DOMA仅是创新，因为它是在大型应用的分布式系统中利用既定设计原则的相对新颖的方法。

DOMA相关的核心原理和术语如下：

1.  围绕相关微服务的集合，称为 域
2.  域的集合称之为层。域所属的层确定了允许该域内的微服务承担什么依赖性，称为 层设计
3.  为域提供接口，这些域被视为集合的单个入口点，称为 网关
4.  确定每个域都应该与其他域不可知，一个域不应该具有与其代码库或数据模型内部硬编码的另一个域相关的逻辑。由于团队经常需要在另一个团队的域中包含逻辑（例如，自定义验证逻辑或数据模型上的某些元上下文），因此我们提供了一种 扩展架构 ，以支持该域中定义明确的扩展点。

通过提供系统的体系结构，域网关和预定义的扩展点，DOMA打算将微服务体系结构从复杂的东西转变为可理解的东西：结构化的一组灵活，可重用和分层的组件。

这篇文章的其余部分将深入研究Uber在DOMA中的实施，我们已经看到的好处以及为可能希望采用这种方法的公司提供的实用建议。

Uber的措施

域

Uber域代表一个或多个与逻辑功能分组绑定的微服务的集合。设计域时常见的问题是“域应该有多大？”有些域可以包含数十个服务，有些域只能包含单个服务。重要的任务是仔细考虑每个集合的 逻辑 角色。例如，我们的地图搜索服务构成一个域，票价服务是一个域，匹配平台（匹配骑手和驾驶员）是一个域。这些也不总是遵循公司的组织结构。Uber Maps组织本身分为三个域，在三个不同的网关后面有80个微服务。

层设计

层设计回答了“什么服务可以调用其他什么服务？”的问题。在Uber的微服务架构中，我们可以将层设计视为“规模化的关注点分离”，或者，我们可以将层设计视为“规模化的依赖管理”。

层设计描述了一种机制，用于考虑Uber的故障影响范围和跨服务依赖的产品特异性。 当域从底层移到顶层时，它们在中断的情况下会影响较少的服务，并代表更多特定的产品使用案例。 相反，底层的功能具有更多的依存关系，因此趋向于具有更大的影响半径，并代表了更通用的业务功能集。下图说明了此概念。

（编辑：应用网_丽江站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!