Introducing Domain-Oriented Microservice ArchitectureUber 面向领域的微服务架构
Uber最开始用单体架构 然后随着规模的扩大 开始拆用微服务架构 但是后来 发展到50个微服务。这个微服务之前错综复杂。
为了构建一个简单的特性，工程师通常需要跨多个服务，而这些服务可能归不同的团队维护。这使花费在会议、设计和代码审查上的时间变得更多。随着团队在彼此的服务中构建代码、修改彼此的数据模型，甚至代替服务所有者进行部署，这又使之前清晰的服务界限遭到破坏。这形成了网络化的整体，让看似独立的服务都必须部署在一起才能安全地执行更改。结果是开发人员体验变慢、服务所有者职责不清晰、迁移变得更加痛苦等等。对于已经采用微服务架构的组织来说，没有回头路可走。
所以现在我们有：
domain oriented microservice architecture. DOMA
DOMA 相关的核心原则和术语如下：
我们不是面向单个微服务，而是面向相关微服务的集合。我们称这些为域
我们进一步创建称为层的域集合。域所属的层确定该域中的微服务可以承担哪些依赖关系。我们称之为分层设计。
我们为域集合的入口点提供清晰的接口。我们称之为网关。
最后，每个域应该与其他域无关，也就是说，一个域不应该在其代码库或数据模型中硬编码与另一个域相关的逻辑。由于团队经常需要在另一个团队的域中共享逻辑(例如，自定义验证逻辑或数据模型上的一些元上下文)，因此我们提供了一个扩展架构使域具有良好的扩展性。
Uber的实践：
分层设计微服务
在 Uber 内部，我们建立了以下五层。
**基础设施层。**提供任何工程组织都可以使用的功能。这是 Uber 大的工程问题的解决手段，如存储或网络等。
**业务层。**提供可以使用的功能，但不特定于特定的产品类别或业务线，如顺风车、餐饮或运费。
**产品层。**提供与特定产品类别或业务线相关但与移动应用无关的功能，例如面向多个骑行的应用(Rider、Rider-Lite、m.uber.com 等)使用的“request a ride”逻辑。
**展示。**提供面向消费者的应用(移动 app/web)。
**边缘层。**安全对外公开 Uber 服务。这一层也是移动应用感知的。
