Recently there has been substantial discussion around the downsides of service oriented architectures and microservice architectures in particular.
最近，围绕面向服务的架构，特别是微服务架构的缺点进行了大量讨论。
While only a few years ago, many people readily adopted microservice architectures due to the numerous benefits they provide such as flexibility in the form of independent deployments, clear ownership, improvements in system stability, and better separation of concerns, in recent years people have begun to decry microservices for their tendency to greatly increase complexity, sometimes making even
虽然就在几年前，许多人很容易采用微服务架构，因为它们提供了众多好处，例如独立部署形式的灵活性、清晰的所有权、系统稳定性的改进以及更好的关注点分离，但近年来，人们已经开始开始采用微服务架构。谴责微服务大大增加复杂性的趋势，有时甚至使trivial features difficult to build.
琐碎的功能很难构建。

As Uber has grown to around 2,200 critical microservices, we experienced these tradeoffs first hand. Over the last two years, Uber has attempted to reduce microservice complexity while still maintaining the benefits of a microservice architecture.
随着 Uber 发展到大约 2,200 个关键微服务，我们亲身经历了这些权衡。在过去的两年里，Uber 一直在尝试降低微服务的复杂性，同时仍然保持微服务架构的优势。
With this blog post we hope to introduce our generalized approach to microservice architectures, which we refer to as “Domain-Oriented Microservice Architecture” (DOMA).
通过这篇博文，我们希望介绍微服务架构的通用方法，我们将其称为“面向领域的微服务架构”（DOMA）。

While it’s been popular in recent years to criticize microservice architectures because of these downsides, few people have advocated an outright rejection of microservice architectures.
尽管近年来由于这些缺点而批评微服务架构很流行，但很少有人主张彻底拒绝微服务架构。
The operational benefits are too important, and it seems that there are no, or limited, alternatives.
运营效益太重要了，而且似乎没有或有限的替代方案。Our goal with DOMA is to provide a way forward for organizations that want to reduce overall system complexity while maintaining the flexibility associated with microservice architectures.
DOMA 的目标是为希望降低整体系统复杂性同时保持与微服务架构相关的灵活性的组织提供一条前进的道路。

This piece explains DOMA, the concerns that led to the adoption of this architecture for Uber, its benefits for platform and product teams, and, finally, some advice for teams who want to adopt this architecture. 
本文解释了 DOMA、导致 Uber 采用此架构的担忧、它对平台和产品团队的好处，以及最后为想要采用此架构的团队的一些建议。

Microservices are an extension of service oriented architectures. As opposed to the fairly large “services” of the 2000s, microservices are applications that represent a set of narrowly scoped functionality.
微服务是面向服务的架构的扩展。与 2000 年代相当大的“服务”相反，微服务是代表一组范围狭窄的功能的应用程序。
These applications are hosted and available over the network and expose a well-defined interface. Other applications call this interface by making a “
这些应用程序通过网络托管和可用，并公开定义良好的接口。其他应用程序通过创建“remote procedure call” (RPC).
远程过程调用（RPC）。

The key characteristic of microservice architecture is the way in which code is hosted, called, and deployed. If we think about large, monolithic applications, they are generally split into encapsulated components with well-defined interfaces.
微服务架构的关键特征是代码的托管、调用和部署方式。如果我们考虑大型的整体应用程序，它们通常被分成具有明确定义的接口的封装组件。
These interfaces would then be called directly in-process as opposed to over the network. In this way, we can start to think of a microservice as a library with a performance hit (network I/O and serialization / deserialization) in order to call any of its functions.
然后，这些接口将在进程内直接调用，而不是通过网络调用。通过这种方式，我们可以开始将微服务视为一个具有性能影响（网络 I/O 和序列化/反序列化）的库，以便调用其任何功能。

When we think about microservices this way, we might question why we would adopt a microservice architecture at all. The answer is often independent deployments and scaling. With a large, monolithic application, an organization is forced to deploy or release all of their code at once. Each new version of an application can involve numerous changes. Deployments become risky and time consuming. Anyone can bring the whole system down. 
当我们以这种方式思考微服务时，我们可能会质疑为什么要采用微服务架构。答案通常是独立部署和扩展。对于大型整体应用程序，组织被迫立即部署或发布所有代码。应用程序的每个新版本都可能涉及大量更改。部署变得充满风险且耗时。任何人都可以搞垮整个系统。

In other words, organizations adopt microservices for an operational benefit at the expense of performance. Organizations also must take on the cost to maintain the infrastructure necessary to support microservices. In many situations, it turns out, this trade-off makes a lot of sense, but it is also a strong argument against a premature adoption of a microservice architecture.
换句话说，组织采用微服务是为了以牺牲性能为代价来获得运营效益。组织还必须承担维护支持微服务所需的基础设施的成本。事实证明，在许多情况下，这种权衡很有意义，但它也是反对过早采用微服务架构的有力论据。

At Uber, we adopted a microservice architecture because we had (circa 2012-2013) primarily two monolithic services and ran into many of the operational issues that microservices solve.
在 Uber，我们采用了微服务架构，因为我们（大约 2012-2013 年）主要有两个整体服务，并遇到了微服务解决的许多运营问题。

In other words, as Uber grew from 10s to 100s of engineers with multiple teams owning pieces of the tech stack, the monolithic architecture tied the fate of teams together and made it difficult to operate independently.
换句话说，随着 Uber 从 10 多位工程师发展到 100 多位工程师，多个团队拥有部分技术堆栈，单一架构将团队的命运绑在一起，很难独立运营。

As a result, we adopted a microservice architecture. Ultimately our systems became more flexible, which allowed teams to be more autonomous.
因此，我们采用了微服务架构。最终我们的系统变得更加灵活，这使得团队更加自主。

It’s not an exaggeration to say that Uber would not have been able to accomplish the scale and quality of execution that we maintain today without a microservice architecture.
可以毫不夸张地说，如果没有微服务架构，Uber 就无法实现我们今天所维持的规模和执行质量。

However, as the company grew even larger, 100s of engineers to 1000s, we began to notice a set of issues associated with greatly increased system complexity. With a microservice architecture one trades a single monolithic code base for black boxes whose functionality can change at any time and easily cause unexpected behavior.
然而，随着公司规模不断扩大，工程师数量从数百名增加到数千名，我们开始注意到一系列与系统复杂性大幅增加相关的问题。通过微服务架构，人们可以将单一的整体代码库换成黑匣子，黑匣子的功能可以随时更改，并且很容易导致意外行为。

For instance, engineers had to work through around 50 services across 12 different teams in order to investigate the root cause of the problem.
例如，工程师必须处理 12 个不同团队的大约 50 项服务，才能调查问题的根本原因。

Understanding dependencies between services can become quite difficult, as calls between services can go many layers deep. A latency spike in the nth dependency can cause a cascade of issues upstream.
理解服务之间的依赖关系可能会变得相当困难，因为服务之间的调用可能会深入很多层。第 n 个依赖项中的延迟峰值可能会导致上游出现一系列问题。
Visibility into what’s actually happening is impossible without the right tools, making debugging difficult.
如果没有正确的工具，就不可能了解实际发生的情况，从而使调试变得困难。

In order to build a simple feature an engineer often has to work across multiple services, all of which are owned by different individuals and teams. This requires extensive collaboration with time spent on meetings, design, and code review.
为了构建一个简单的功能，工程师通常必须跨多个服务工作，所有这些服务都由不同的个人和团队拥有。这需要在会议、设计和代码审查上花费时间进行广泛的协作。
The earlier promise of clear lines of service ownership is compromised as teams build code within each other’s services, modify each other’s data models, and even perform deployments on behalf of service owners.
当团队在彼此的服务中构建代码、修改彼此的数据模型、甚至代表服务所有者执行部署时，早期明确的服务所有权界限的承诺就会受到损害。
Networked monoliths can form, where services that appear to be independent all have to be deployed together to safely perform any change.
网络化的整体架构可能会形成，其中看似独立的所有服务都必须部署在一起才能安全地执行任何更改。

The result is a slower developer experience, instability for service owners, more painful migrations, etc. For organizations that have already adopted a microservice architecture there is no turning back. It becomes a case of “can’t live with them, can’t live without them.” 
其结果是开发人员体验变慢、服务所有者不稳定、迁移更加痛苦等等。对于已经采用微服务架构的组织来说，这是没有回头路的。这就变成了“不能和他们一起生活，没有他们就不能生活”的情况。

If we can think of microservices as I/O bound libraries and a “microservice architecture” as a large, distributed application then we can use well understood architectures to think about how to organize our code. 
如果我们可以将微服务视为 I/O 绑定库，并将“微服务架构”视为大型分布式应用程序，那么我们就可以使用易于理解的架构来思考如何组织我们的代码。

“Domain-Oriented Microservice Architecture” thus draws heavily from established ways to organize code such as Domain-driven Design, Clean Architecture, Service-Oriented Architecture, and object- and interface-oriented design patterns. We think of DOMA as innovative only insofar as it is a relatively novel way to leverage established design principles in large distributed systems in large organizations.
因此，“面向领域的微服务架构”大量借鉴了组织代码的既定方法，例如领域驱动设计、简洁架构、面向服务的架构以及面向对象和接口的设计模式。我们认为 DOMA 具有创新性，因为它是一种相对新颖的方式，可以在大型组织的大型分布式系统中利用既定的设计原则。

The core principles and terminology associated with DOMA are as follows:
DOMA 相关的核心原则和术语如下：

In other words, by providing a systematic architecture, domain gateways, and predefined extension points, DOMA intends to transform microservice architectures from something complex to something comprehensible: a structured set of flexible, reusable, and layered components. 
换句话说，通过提供系统架构、域网关和预定义的扩展点，DOMA 旨在将微服务架构从复杂的东西转变为易于理解的东西：一组灵活的、可重用的、分层的组件的结构化集合。

The rest of this post digs into Uber’s implementation of DOMA, the benefits we’ve seen, and practical advice for companies which might want to adopt this approach.

Uber domains represent a collection of one or more microservices tied to a logical grouping of functionality. A common question in designing a domain is “how big should a domain be?” We give no guidance here.
Some domains can include tens of services, some domains only a single service. The important task is to think carefully about the logical role of each collection. For instance, our map search services constitute a domain, fare services are a domain, matching platform (matching riders and drivers) are a domain. These also don’t always follow company org structure.
The Uber Maps org itself is split into three domains, with 80 microservices behind 3 different gateways.

Layer design answers the question of “what service can call what other service?” within Uber’s microservice architecture.
As a result, we can think of layer design as “separation of concerns at scale.” Alternatively, we can think of layer design as “dependency management at scale.” 

Layer design describes a mechanism for thinking about failure blast radius and product specificity across service dependencies at Uber. As domains move from the bottom layer to the top layer, they impact fewer services in the case of an outage and represent more specific product use cases. Conversely, functionality at the bottom layers have more dependents and as a result tend to have a larger blast radius and represent a more general set of business functionality. The figure below illustrates this concept.

One can think of the top layers as specific user experiences (such as mobile features), and the bottom layers as generalized business functionality (such as account management or marketplace trips).
Layers only depend on the layers under them, which gives us a useful heuristic to think about questions like blast radius and domain integration.

It’s worth noting that functionality often moves “down” this chart from specific to more general. One can imagine a simple feature that eventually becomes more and more of a platform as requirements evolve.
In fact, this sort of migration downward is expected, and many of Uber’s core business platforms started as rider or driver specific functionality that became more generalized as we developed more lines of business and they took on more dependencies (such as Uber Eats or Uber Freight).

Within Uber, we established the following five layers.

As you can see, each subsequent layer represents an increasingly specific grouping of functionality, and has a smaller and smaller blast radius (or, in other words, less components depend on the functionality within that layer). 

The term “Gateway API” is already a broadly established concept within microservice architectures. Our definition does not vary greatly from the established definition, except that we tend to think of gateways exclusively as a single entry-point into a collection of underlying services, which we call a domain. The success of a gateway relies on the success of the API design.

Since upstream consumers only operate on a single service, gateways provide numerous benefits in terms of future migrations, discoverability, and overall reduction in system complexity with upstream services only taking a single dependency as opposed to dependencies on several downstream services that might exist within a domain.
If we think about gateways in the sense of OO design, they are interface definitions, which enable us to do whatever we want in terms of the underlying “implementation” (in this case the collection of underlying microservices).

Extensions represent a mechanism to extend domains. The basic definition of an extension is that it provides a mechanism for extending the functionality of an underlying service without changing the actual implementation of that service and without impacting its overall reliability.
At Uber we provide two different extension models: logic extensions and data extensions. The concept of extensions has allowed us to scale our architecture to multiple teams being able to work independently of each other.

Logic extensions provide a mechanism for extending the underlying logic of a service. For logic extensions we use a variation of a provider or plugin pattern with an interface defined on a service-by-service basis. This makes it so that extending teams can implement extension logic in an interface-driven way without modifying the core code of the underlying platform.

For example, a driver goes online. Typically, we make various checks to ensure that a driver is allowed to go online (safety checks, compliance, etc.). Each of these is owned by an individual team.
One way to implement this would be to have each team write logic in the same endpoint, but this can introduce complexity. Each check would require custom, and entirely unrelated, logic. 

In the case of logic extensions, the “go online” endpoint would define an interface that they expect each extension to conform to with a predefined request type and a response. Each team would register an extension that would be responsible for the execution of this logic.
In this case, they might simply take some context about the driver and return a bool, saying if the driver can go online or not. The go online endpoint would simply iterate through these responses, and determine if any of them are false.

This decouples the core code from each extension, and provides isolation between extensions, which don’t know what other logic is executing. It’s easy to build up more functionality around this, such as observability or feature flagging. 

Data extensions provide a mechanism for attaching arbitrary data to an interface to avoid bloat in core platform data models. For data extensions, we leverage Protobuf’s Any functionality so that teams can add arbitrary data to requests. Services will often store this data or pass it to a logic extension so that the core platform is never responsible for deserializing (and thus “knowing about”) this arbitrary context.
Protobuf’s Any implementation comes with some infrastructure overhead in exchange for stronger typing. For a simpler implementation, one could just as easily use a JSON string to represent arbitrary data.

Outside of logic and data extensions, many teams at Uber have introduced their own extension patterns that are appropriate for their domain. For example, much of the integrations tied to our presentation architecture uses DAG based task execution logic.

Almost every major domain at Uber has been influenced on some level by DOMA. Over the last year, we have focused primarily on Uber’s business layer which provides generalized logic for each of our various lines of business. 

DOMA is still young at Uber, and we are excited to share more data and in-depth examples of our architecture in the future. However, early signs have been extremely positive in terms of a simplified developer experience and a reduction in overall system complexity.

DOMA was the result of a consensus effort across product and platform teams at Uber. Platform support costs often dropped an order of magnitude. Product teams benefited from guard rails and accelerated development.

For example, an early platform consumer of our extensions architecture was able to drop the time to prioritize and integrate a new feature from three days to three hours by adopting an extension architecture with reduced time for code review, planning, and learning curve for consumers.

Previously product teams would have to call numerous downstream services to leverage a domain; they now have to call just one. By reducing the number of touchpoints to onboard a new feature, platforms were able to reduce onboarding time by 25-50%.
Furthermore, we were able to classify 2200 microservices into 70 domains. Roughly 50% of which have been implemented, and most of which have some plan for future adoption.

At Uber, we calculated that the half-life of a microservice was 1.5 years, which means that every 1.5 years 50% of our microservices churn. Without gateways it’s easy for a microservice architecture to fall into a “migration hell” as a result of this churn.
Ever changing microservices constantly require upstream migrations. Gateways enable teams to avoid dependencies on the underlying domain services, which means those services can change without forcing an upstream migration. 

Two of Uber’s largest platform rewrites in the last year happened behind gateways. These platforms had hundreds of services that depended on them that would have had to migrate existing consumers.
The cost of migration in these cases would have been extremely high, making a complete platform rewrite infeasible.

Platforms designed using DOMA have proven to be much more extensible and easier to maintain. Most teams at Uber who adopted DOMA did so because supporting new lines of business had become too expensive.

This section provides some practical advice for companies that might want to adopt DOMA. The guiding principle here is that in our experience a mature and thoughtful microservice architecture stems from quiet nudges in the right direction at the right time.
The reality is that a true “rewrite” is never possible for one’s entire microservice architecture.

As a result, we think of evolving a microservice architecture more like “trimming a hedge” so that it eventually grows correctly, rather than a top-down or one-time architecture (or re-architecture) effort. It’s a dynamic and progressive process.

The driving questions should be “when should we adopt a microservice architecture?” and “does it make sense for our organization?” As we’ve seen above, while microservices provide an operational benefit to organizations with a large number of engineers, this trades off with an increase in complexity that can make features more difficult to build.

In small organizations, the operational benefit likely does not offset the increase in architectural complexity.
Furthermore, microservice architectures often require dedicated engineering resources to support which may be out of budget for an early stage company or else suboptimal from a prioritization perspective. 

With this in mind, it isn’t unreasonable to hold off on microservices altogether for some time.
If an organization does choose to adopt microservices, it should think about the “microservice as large distributed application” analogy, and the separation of concerns between microservices it wants to build.
Also, recognize that the first microservices will likely be the most important and longest lasting as they truly describe the core of the business.

Once a company becomes midsized with multiple teams and the clear separation of concerns becomes hazy between different features and platforms, microservice architectures become more obviously useful.

It’s at this stage that one can begin to think about hierarchies between microservices. Dependency management may become more important, as some services begin to become more obviously critical to business operation, and more and more teams rely on them. 

Early investment in platformization may pay dividends down the road. There is the possibility to avoid tech debt here if one can create completely product agnostic business platforms and avoid arbitrary product logic in core platform services.
It might make sense to adopt extensions at this point to accomplish that goal.

Given that the number of microservices is likely still quite low, it may not make sense to cluster them together.
However, it’s worth noting here that a domain in the context of Uber’s DOMA implementation can contain a single service, so it may still be useful to think in a “domain-oriented” way.

Larger engineering organizations may have hundreds of engineers and microservices and several dependencies. At this point DOMA reaches its full usefulness.
There will likely be obvious clusters of microservices that can be easily grouped together into domains with a gateway in front of them.
Legacy services often begin to need to be refactored or rewritten and then migrated, which means that gateways will soon begin to provide value in terms of ease of migration if they are already in place.

Clear hierarchy will also become increasingly important with some services operating as “product” services for particular features or grouping of features, and other services will increasingly support multiple products and be thought of as “platforms.” It’s critical at this stage to keep arbitrary product logic decoupled from platforms, so as to avoid a heavy operational burden on platform teams as well as system-wide instability.

We are still actively evolving DOMA as more and more teams at Uber come to adopt it.
The critical insight of DOMA is that a microservice architecture is really just one, large, distributed program and you can apply the same principles to its evolution that you would apply to any piece of software.
DOMA is simply an approach for thinking about these principles in practice. We hope others find it useful and we look forward to feedback!

DOMA itself was the result of a cross-functional effort, which involved nearly 60 engineers across every org at Uber. Some particular acknowledgements, for people who invested heavily into this effort over the last 2 years…

Alex Zylman, Alexandre Wilhelm, Allen Lu, Ankit Srivastava, Anthony Tran, Anupam Dikshit, Anurag Biyani, Daniel Wolf, Davide D’Agostino, Deepti Chedda, Dmitriy Bryndin, Gaurav Tungatkar, Jacob Greenleaf, Jaikumar Ganesh, Jennie Ngyuen, Joe McCabe, Joshua Shinavier, Julia Law, Kusha Kapoor, Linda Fu, Madan Thangavelu, Nimish Sheth, Parth Shah, Shawn Burke, Simon Newton, Steve Sherwood, Uday Kiran Medisetty, and Waleed Kadous 

Acknowledgements:

This work brings multiple existing design patterns in the industry to solve problems at Uber while also suggesting new patterns like extensions. We are thankful to the industry for the work on them. We are also thankful to the engineers at Linkedin who worked on Superblocks, who spoke to us about their experiences.