您应该了解的33家物联网

自定义

除了逻辑和数据扩展，Uber的许多团队都引入了适合自己领域的扩展模式。例如，与presentation架构绑定的许多集成使用基于DAG的任务执行逻辑。

价值所在

Uber的几乎每个主要域都在某种程度上受到了DOMA的影响。在过去的一年里，Uber主要关注业务层，它为不同的业务线提供了通用的逻辑。

DOMA在Uber还很年轻，然而从简化开发人员体验和降低整个系统复杂性的角度来看，它的早期表现非常积极。

产品与平台

DOMA是Uber跨产品和平台团队一致努力的结果。平台支持成本通常会下降一个数量级。产品团队受益于guard rails和加速的开发。

例如，我们的扩展架构的早期平台使用者能够通过采用扩展架构减少代码审查、规划和用户学习曲线的时间，将优先级和集成新特性的时间从三天减少到三小时。

降低复杂性

以前的产品团队必须调用大量的下游服务来利用一个域;现在只需要调用一个。通过减少加载新功能的接触点数量，平台能够减少25-50%的登陆时间。此外，能够将2200个微服务划分为70个域。其中大约有50%已经实现，而且大多数都有未来采用的计划。

未来的迁移

在Uber，计算出微服务的半衰期是1.5年，这意味着每1.5年我们的微服务就会有50%的变动。如果没有网关，微服务架构很容易因此陷入“迁移的噩梦”。不断变化的微服务需要不断进行上游迁移。

网关使团队能够避免对基础域服务的依赖，这意味着这些服务可以在不强制上游迁移的情况下进行更改。

这些平台有数百个依赖于它们的服务，而这些服务将不得不迁移现有的消费者。在这些情况下，迁移的成本会非常高，使得重写一个完整的平台变得不可行。


 

上图说明了网关的高级图。它抽象出域的内部细节——多个服务、数据表、ETL管道等。只有接口—RPC api、消息传递事件和查询被公开给其他域。

由于上游使用者只在单个服务上操作，因此通过上游服务只接受单个依赖项(而不是依赖于某个域中可能存在的多个下游服务)，网关在未来的迁移、可发现性和系统复杂性的整体降低方面提供了许多好处。如果从面向对象设计的角度来考虑网关，那么它们就是接口定义，它使Uber能够根据底层“实现”(在本例中是底层微服务的集合)来做任何想做的事情。

扩展

扩展表示一种扩展域的机制。扩展的基本定义是，它提供了一种机制来扩展基础服务的功能，而不改变该服务的实际实现，也不影响其总体可靠性。在Uber，提供两种不同的扩展模型：逻辑扩展和数据扩展。扩展的概念允许Uber将架构扩展到多个团队，从而能够彼此独立地工作。

逻辑扩展

逻辑扩展为扩展服务的底层逻辑提供了一种机制。对于逻辑扩展，Uber使用provider or plugin模式的变体，并在逐个服务的基础上定义接口。这使得扩展团队能够以接口驱动的方式实现扩展逻辑，而无需修改底层平台的核心代码。

如，一个司机上线(go online)。通常，我们会进行各种检查，来确保司机可以运营(安全检查、合规等)。每一个都属于一个单独的团队。实现这一点的一种方法是让每个团队在相同的端点编写逻辑，但这可能会引入复杂性。每个检查都需要定制的、完全不相关的逻辑。

对于逻辑扩展，“go online”端点将定义一个接口，希望每个扩展都符合预定义的请求类型和响应。每个团队将注册一个负责执行此逻辑的扩展。在这种情况下，它们可能只是取一些关于驱动程序的上下文，然后返回一个bool，说明驱动程序是否可以上线。go online端点将简单地遍历这些响应，并确定其中是否有错误。

这将核心代码与每个扩展解耦，并提供扩展之间的隔离，而不知道其他逻辑正在执行。围绕它构建更多的功能很容易，比如可观察性或特性标记。

数据扩展

数据扩展提供了将任意数据附加到接口，来避免核心平台数据模型膨胀的机制。对于数据扩展，Uber利用了Protobuf的Any功能，让团队可以向请求添加任意数据。服务通常会存储这些数据或将其传递给逻辑扩展，便于核心平台永远不会对这个任意上下文进行反序列化(从而“knowing about”)。Protobuf的Any实现带来了一些基础设施开销，以换取更强的类型。对于更简单的实现，可以简单地使用JSON字符串表示任意数据。


 

（编辑：阜新站长网）

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