云计算和边缘计算协同发展带来广阔空间

可以将顶层看作是特定的用户体验(比如移动功能)，而底层看作是通用的业务功能(比如账户管理)。这为我们思考故障面和域集成等问题提供了有益的启发。

值得注意的是，在这个图表中，功能常常从特定的“向下”到更普遍的“向下”。可以想象，随着需求的发展，一个简单的特性最终会越来越像一个平台。事实上，这种向下的迁移是意料之中的，而且Uber的许多核心业务平台一开始只是针对乘客或司机的特定功能，随着我们发展了更多的业务线，它们变得越来越普遍(比如Uber Eats或Uber Freight)。

在Uber内部，建立了以下五个层次。

• 基础设施层。提供任何工程团队可以使用的功能。这是Uber对诸如存储或网络等重大工程问题的解答。
• 业务层。提供Uber作为一个组织可以使用的功能，但这并不特定于特定的产品类别或业务(LOB)，如乘车、餐饮或货运。
• 产品层。提供与特定产品类别或LOB相关的功能，但与移动应用程序无关，比如“请求搭车”逻辑，它被多个搭车应用程序(Rider、Rider“Lite”、m.uber.com等)利用。
• 演示层。提供与面向消费者的应用程序(移动/web)中存在的特性直接相关的功能。
• 边缘层。安全向外界开放优步服务。这一层也支持移动应用程序。

如您所见，后续的每一层都代表了越来越具体的功能分组，并且具有越来越小的故障面(换句话说，更少的组件依赖于该层内的功能)。

网关

术语“网关API”在微服务架构中已经是一个广泛建立的概念。Uber的定义与已建立的定义差别不大，除了倾向于将网关专门看作底层服务集合(称之为域)的单个入口点之外。网关的成功依赖于API设计的成功。


 

大约在2018年Uber的复杂流程示例，在DOMA之前需要10个接触点才能进行简单集成。

结果是开发人员体验变慢，服务所有者不稳定，迁移更加痛苦等等。对于已经采用微服务架构的企业而言，没有回头路。需要找到解决方案来克服这些挑战

面向“域”的微服务架构

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

因此，“面向域的微服务架构”大量借鉴了已建立的组织代码的方式，例如域驱动设计，干净架构，面向服务的架构，以及面向对象和面向接口的设计模式。Uber将DOMA视为创新，因为它是在大型组织的大型分布式系统中，利用既定设计原则的相对新颖的方法。

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

• Uber不是围绕单个微服务，而是围绕相关微服务的集合——称为域。
• Uber进一步创建称为图层的域的集合。域所属的层确定了允许该域内的微服务承担什么依赖性——称为层设计。
• Uber为域提供干净的接口，这些域被视为集合的单个入口点——称为网关。
• 最后，Uber确定每个域都应该与其他域不可知，也就是说，一个域不应该具有与在其代码库或数据模型内部进行硬编码的另一个域相关的逻辑。由于团队经常需要在另一个团队的域中，包括逻辑(如，自定义验证逻辑或数据模型上的某些元上下文)，因此我们提供了一种扩展架构，以支持该域中定义明确的扩展点。

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

以下将深入研究Uber在DOMA中的实施，已经看到的价值，以及为可能希望采用这种方法的企业提供的实用建议。

DOMA的实施

域

Uber域代表一个或多个与逻辑功能分组绑定的微服务的集合。设计域时常见的问题是“域应该有多大?” 在此Uber不提供任何指导。有些域可以包含数十个服务，有些域只能包含一个服务。

重要的任务是仔细考虑每个集合的逻辑角色。例如，Uber的地图搜索服务构成一个域，票价服务是一个领域，匹配平台(匹配驾驶员)是一个域。这些也不总是遵循企业的组织结构。Uber Maps组织本身分为三个域，在三个不同的网关后面有80个微服务。

层设计

层设计回答了“什么服务可以调用什么其他服务?”的问题。在Uber的微服务架构中，可以将层设计视为“按比例分离关注点”。另外，可以将层设计视为“大规模依赖管理”。

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

（编辑：阜新站长网）

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