Shulou(Shulou.com)06/03 Report--

This article focuses on "how to understand the domain-oriented micro-service architecture". Interested friends may wish to take a look. The method introduced in this paper is simple, fast and practical. Let's let the editor take you to learn how to understand the domain-oriented micro-service architecture.

What is a microservice?

Microservice is an extension of service-oriented architecture. Compared with the sizeable "services" of the 2000s, microservices are applications that represent a set of small functions. These applications are hosted over the network and expose a clearly defined interface. Other applications call this interface through remote procedure call (RPC).

The microservice architecture is characterized by the way code is hosted, invoked, and deployed. For example, large monolithic applications are usually divided into encapsulated components with clearly defined interfaces. These interfaces can then be called directly in the process rather than over the network. In this way, we think of the microservice as a library whose performance is affected (network Imax O and serialization / deserialization) so that any of its functions can be invoked.

When we think about microservices in this way, we may question why we adopt the microservices architecture. The answer is usually independent deployment and expansion. For a large monolithic application, the application is forced to deploy or release all the code at once. Each new version of the application can involve many changes. Deployment becomes risky and time-consuming. Anyone can paralyze the whole system.

In other words, the business uses microservices to gain operational benefits at the expense of performance. The business must also bear the cost of maintaining the infrastructure needed to support microservices. This trade-off has proved to be meaningful in many cases, but it is also a strong argument against the early adoption of a micro-services architecture.

motivation

At Uber, we also adopted the micro-service architecture, because we (about 2012-2013) mainly had two single services and encountered a lot of operational problems solved by micro-services.

Availability risk. A single rollback within a single code base paralyzes the entire system (in this case, all of Uber).

Deployment risk is high and cost is high. In cases where frequent rollbacks are required, performing these operations is difficult and time-consuming.

Unsmooth separation of concerns. In a large code base, it is difficult to maintain a good separation of concerns. Especially in an environment of exponential growth, expediency can sometimes lead to unclear boundaries between logic and components.

The execution is inefficient. Taken together, these problems make it difficult for the team to carry out tasks independently.

As Uber has grown from more than 10 engineers to more than 100 engineers, when multiple teams have fragments of the technology stack, this single architecture binds the fate of the team together, making it difficult to operate independently.

Therefore, we adopt the micro-service architecture. Eventually, our system becomes more flexible, which makes the team more autonomous.

The reliability of the system. In the micro-service architecture, the reliability of the overall system increases. A single service can be down (and rolled back) without affecting the entire system.

The separation of concerns. Architecturally, the microservice architecture forces you to ask, "Why does this service exist?" Define the roles of different components more clearly.

Clear ownership. The owner of the code becomes clearer. Services are often owned at the individual, team, or organization level, resulting in faster growth.

Execute it independently. Independent deployment of clearer ownership rights, so that different product and platform teams can execute independently.

The speed of the developer. Application teams can deploy their code independently, which allows them to execute according to their own project schedule

It is no exaggeration to say that without a micro-service architecture, Uber would not be able to achieve the scale and quality of execution it maintains today.

However, with the further expansion of the company, from more than 100 engineers to more than 1000 engineers, we began to notice a series of problems related to the greatly increased complexity of the system. In the micro-service architecture, people exchange a single overall code base for a black box, and the function of the black box may change at any time, which can easily lead to unexpected situations.

For example, engineers have to investigate the root cause of the problem through about 50 services from 12 different teams.

It can be difficult to understand the dependencies between services because invocations between services can go deep into many layers. The delay peak of the nth dependency may lead to a series of problems upstream. Without the right tools, it's impossible to see what's actually happening, which makes debugging difficult.

To build a simple function, engineers often need to work across multiple services, all of which are owned by different individuals and teams. This requires cross-departmental and cross-team collaboration, spending time on meetings, design, and code review. Early clear demarcation of service ownership was affected by teams building code in each other's services, modifying each other's data models, and even performing deployments on behalf of service owners. Networked monomers may form, and seemingly independent services must be deployed together to securely implement any changes.

The result is slower development, unstable service ownership, more difficult migration, and so on. For enterprises that have adopted micro-service architecture, there is no turning back. This becomes "you can't live without them, you can't live without them."

Domain-oriented micro-service architecture

If we can think of micro-services as I / O-bound libraries and "micro-service architectures" as large distributed applications, we can use well-known architectures to think about how to organize code.

Therefore, the domain-oriented micro-service architecture draws heavily on the established methods of organizing code, such as domain-driven design, clear architecture, service-oriented architecture, and object-oriented and interface-oriented design patterns. We think that DOMA is just an innovation because it is a relatively novel way to take advantage of established design principles in distributed systems for large applications.

The core principles and terminology related to DOMA are as follows:

Hongmeng official Strategic Cooperation to build HarmonyOS Technology Community

A collection of related micro-services, called domains

A collection of domains is called a layer. The layer to which the domain belongs determines what dependencies are allowed for micro-services in the domain, called layer design.

Provides interfaces for domains that are treated as a single entry point to a collection, called gateways

Determine that each domain should be agnostic to other domains, and that a domain should not have logic associated with another domain hard-coded within its code base or data model. Because teams often need to include logic in another team's domain (for example, custom validation logic or some meta-context on the data model), we provide an extension architecture to support well-defined extension points in that domain.

By providing the system's architecture, domain gateways, and predefined extension points, DOMA intends to transform the micro-service architecture from something complex to something understandable: a structured set of flexible, reusable and hierarchical components.

The rest of this article will delve into the implementation of Uber in DOMA, the benefits we have seen, and practical advice for companies that may want to adopt this approach.

Measures of Uber

Domain

The Uber domain represents a collection of one or more micro-services that are bound to logical function groups. A common question when designing a domain is "how big should the domain be?" Some domains can contain dozens of services, while others can contain only a single service. The important task is to carefully consider the logical roles of each collection. For example, our map search service constitutes a domain, the fare service is a domain, and the matching platform (matching rider and driver) is a domain. These do not always follow the organizational structure of the company. The Uber Maps organization itself is divided into three domains, with 80 microservices behind three different gateways.

Layer design

The layer design answers "what service can invoke what other services?" It's a problem. In Uber's micro-service architecture, we can think of layer design as "large-scale separation of concerns", or we can think of layer design as "large-scale dependency management".

The layer design describes a mechanism for considering the scope of failure impact of Uber and product specificity across service dependencies. As domains move from the bottom to the top, they affect fewer services in the event of disruption and represent more specific product use cases. On the contrary, the underlying functions have more dependencies, so they tend to have a larger radius of influence and represent a more general set of business functions. The following figure illustrates this concept.

You can think of the top layer as a specific user experience (such as mobile capabilities) and the bottom layer as a common business function (such as account management or marketing trips). The layer depends only on the layer below, which provides us with a useful heuristic to think about issues such as scope of influence and regional integration.

It is worth noting that features often move "down" from this chart, from specific to more common. It is conceivable that a simple function, with more requirements, will eventually become more and more platforms. In fact, this downward shift is to be expected. Many of Uber's core business platforms are aimed at riders or drivers at first, but as we develop more lines of business, they become more dependent and become more and more general (such as Uber Eats or Uber Freight).

Within Uber, we have established the following five levels.

Hongmeng official Strategic Cooperation to build HarmonyOS Technology Community

Infrastructure layer. Provide functions that can be used by any engineering project. This is how Uber handles major engineering issues such as storage or networking.

Business layer. Provides Uber functions that can be used by applications, but not specific to specific product categories or lines of business (LOB), such as transportation, dining, or shipping.

Product layer. Provides functionality related to a specific product category or LOB but independent of mobile applications, such as Rider,Rider "Lite" (m.uber.com) logic utilized by multiple application-oriented Rides.

Presentation layer. Provides functionality that is directly related to functionality that exists in consumer-facing applications (mobile / network).

Edge layer. Securely expose Uber services to the outside world. This layer also supports mobile applications.

Each layer represents more and more specific functional groupings, and the radius of influence is getting smaller (or, in other words, fewer components depend on the functions in that layer).

Gateway

I believe you are familiar with the term "API gateway" in the micro-service architecture. In fact, the gateway we define in DOMA is almost the same as the well-known concept of "API gateway", except that we tend to regard the gateway as a single entry point into the basic service set (called domain). The success of the gateway depends on the success of the API design.

Because upstream consumers only run on a single service, gateways provide many benefits in terms of migration, service discovery, and overall system complexity, and upstream services require only one dependency. rather than relying on several downstream services that may exist in the domain. If we think about gateways from an object-oriented design perspective, they are interface definitions that enable us to do whatever we want based on the underlying "implementation" (in this case, a collection of underlying microservices).

Expansion

Extension represents a mechanism for extending a domain. The basic definition of an extension is that it provides a mechanism to extend the functionality of the underlying service without changing the actual implementation of the service and without affecting its overall reliability. At Uber, we provide two different extension models: logical extension and data extension. The concept of extension enables us to extend the architecture to multiple teams that can work independently.

Logical extension

Logical extension provides an underlying logical mechanism for extending services. For logical extensions, we use variants of the provider or plug-in pattern whose interfaces are defined on a service-based basis. This enables the extension team to implement the extension logic in an interface-driven way without modifying the core code of the underlying platform.

For example, a driver is online. Usually, we conduct various checks to ensure that the driver is allowed to go online (security checks, compliance, etc.). These are owned by a separate team. One way to do this is to have each team write logic at the same endpoint, but this can add complexity. Each check requires custom and completely irrelevant logic.

For logical extensions, the "live" endpoints define an interface that they want each extension to conform to a predefined request type and response. Each team will register an extension responsible for performing this logic. In this case, they may simply get some context about the driver and then return a Boolean value to determine whether the driver can go online. The "go online" endpoint will simply traverse these responses and determine if there is a problem with them.

This decouples the core code from each extension and provides isolation between extensions that don't know what other logic is doing. Around this point, it is easy to build more functions, such as observability or characteristics.

Data expansion

Data extensions provide a mechanism for attaching arbitrary data to interfaces to avoid bloating in the core platform data model. For data extensions, we take advantage of Protobuf's Any feature so that the team can add arbitrary data to the request. Services typically store this data or pass it to logical extensions so that the core platform is never responsible for deserializing (and thus "knowing") this arbitrary context. Any implementation of Protobuf will have some infrastructure overhead in exchange for stronger typing. For a simpler implementation, we can directly use JSON strings to represent arbitrary data.

Custom extension

In addition to logical and data extensions, many Uber teams have launched their own extension models that suit their own domain. For example, many of the sets bundled with our presentation architecture use DAG-based task execution logic.

Benefit

Almost every major area of Uber is affected by DOMA to some extent. Over the past year, we have focused on the business layer of Uber, which provides common logic for all our business lines.

DOMA is still young at Uber and we are pleased to share more data and in-depth examples of our architecture in the future. However, the early signs are very positive in terms of simplifying the developer experience and reducing overall system complexity.

Products and platforms

DOMA is the result of a consensus reached by the entire product and platform team of Uber. Platform support costs tend to fall by an order of magnitude. Product teams benefit from guardrails and accelerated development.

For example, an early platform consumer of our extended architecture reduced code review, planning, and consumer learning curve time by adopting an extended architecture, and was able to reduce the priority and integration time of a new feature from three days to three hours.

Reduce complexity

In the past, the product team needed to invoke many downstream services to take advantage of a domain, but now it only needs to invoke one service. By reducing the number of touchpoints for new features, the platform can reduce dwell time by 25-50%. In addition, we can divide 2200 microservices into 70 domains. About 50% of them have been implemented, and most of them have plans for future adoption.

Future migration

At Uber, we calculated that the half-life of microservices is 1.5 years, which means we lose 50% of microservices every 1.5 years. If there is no gateway, the micro-service architecture can easily fall into "migration hell" because of this loss. Changing microservices require continuous upstream migration. The gateway enables the team to avoid dependence on the underlying domain services, which means that these services can change without forcing upstream migration.

The two biggest platform rewrites of Uber last year took place behind the gateway. Hundreds of these platforms depend on their services, which will have to migrate existing platforms. In these cases, the cost of migration can be so high that complete platform rewriting is not feasible.

New business and product lines

It turns out that platforms designed with DOMA are more scalable and easier to maintain. Most Uber teams adopt DOMA because the cost of supporting new lines of business is too high.

Some suggestions

This section provides some practical advice for companies that may want to adopt DOMA. The guiding principle here is that, in our experience, a mature and thoughtful micro-service architecture comes from quietly deliberating in the right direction at the right time. The reality is that for a person's entire microservice architecture, a real "rewrite" is never possible.

Therefore, we think that the evolution of micro-service architecture is more like "pruning the hedge" to make it grow correctly, rather than top-down or one-off architecture (or re-architecture) work. This is a dynamic and gradual process.

Start-up company

The question of driver should be "when should we adopt the micro-service architecture?" And "does it make sense for our organization?" As we have seen above, while microservices provide operational benefits for organizations with a large number of engineers, it also increases complexity and makes it more difficult to build functions.

In small companies, operational benefits may not offset the increase in architectural complexity. In addition, microservices architectures often require dedicated engineering resources to support, which may be over budget for early-stage companies, otherwise it is suboptimal from a priority point of view.

With this in mind, it is not unreasonable to completely suspend the use of microservices for a period of time. If an organization really chooses to adopt micro-services, it should consider the analogy of "micro-services as large distributed applications" and the separation of concerns between the micro-services they want to build. In addition, realize that the first microservices are probably the most important and longest-lasting, because they really describe the core of the business.

Medium-sized

Once the company is medium-sized, with multiple teams, and the clear separation of concerns between different functions and platforms becomes hazy, the micro-services architecture becomes more useful.

At this stage, people can start to think about the hierarchy between microservices. Dependency management may become more important as some services become more critical to business operations and more and more teams rely on these services.

Early investments in platforms may pay off on the future. If you can create a completely product-agnostic business platform and avoid any product logic in the core platform services, it is possible to avoid technical debt. It may make sense to use extensions to achieve this goal at this time.

Given that the number of microservices may still be quite small, there may be no point in grouping them together. It is worth noting, however, that in the context of Uber's DOMA implementation, a domain can contain a service, so it may be useful to think in a "domain-oriented" way.

Large scale

Larger engineering organizations may have hundreds of engineers and micro-services as well as multiple dependencies. At this point, DOMA achieved its full function. There are likely to be obvious micro-service clusters that can be easily classified as domains with a gateway in front of them. Legacy services often need to be refactored or rewritten at first, and then migrated, which means that if the gateway is already in place, it will soon begin to provide value in terms of the convenience of migration.

A clear hierarchy will also become more and more important, with some services running as "product" services to implement specific functions or functional groups, while other services will increasingly support multiple products and are considered "platforms". At this stage, the key is to keep any product logic decoupled from the platform, so as to avoid bringing a heavy operational burden to the platform team and the instability of the whole system.

The last feeling

As more and more teams of Uber adopt DOMA, we are still actively evolving DOMA. The key insight of DOMA is that the micro-service architecture is really just a large distributed program, and you can apply the same principles to its evolution, just as you apply to any software. DOMA is just a way to think about these principles in practice. We want others to find it useful, and we look forward to feedback.

At this point, I believe you have a deeper understanding of "how to understand the domain-oriented micro-service architecture". You might as well do it in practice. Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.