Cloud Native Architecture | Microservices

Cloud-native microservices

1: Microservice development background

In the past, the most direct way to develop a back-end application was to provide and integrate all services through a single back-end application, that is, the monolithic model. With the continuous increase of business development and demand, the function of a single application becomes more and more complex. The scale of engineers involved in the development may grow from the first few to more than a dozen people, and the application iteration efficiency drops significantly due to the centralized R&D, testing, release, and communication mode. . In order to solve the over-centralized project iteration process derived from the monolithic application model, the microservice model came into being.

The microservice pattern splits the back-end monolithic application into multiple loosely coupled sub-applications, each of which is responsible for a set of sub-functions. These sub-applications are called "microservices", and multiple "microservices" together form a physically independent but logically complete distributed microservice system. These microservices are relatively independent, and improve the overall iteration efficiency by decoupling the R&D, testing, and deployment processes. In addition, the micro-service mode expands the application horizontally and deploys it redundantly through the distributed architecture, which fundamentally solves the inherent architectural defects of the scalability and stability of the single application. However, it should also be noted that the microservice model also faces typical challenges of distributed systems: how to efficiently invoke remote methods, how to achieve reliable system capacity estimation, how to establish a load balancing system, how to perform integration testing for loosely coupled systems, and how to The deployment and operation of large-scale complex related applications...

In the cloud-native era, the cloud-native microservice system will make full use of the high availability and security system of cloud resources , allowing applications to obtain more guaranteed elasticity, availability, and security. The application is built on the infrastructure and basic services provided by the cloud, making full use of the convenience and stability brought by the cloud service and reducing the complexity of the application architecture. The cloud-native microservice system will also help the application architecture to be comprehensively upgraded, so that the application naturally has better observability, controllability, fault tolerance and other characteristics.

2: Microservice Design Constraints

Compared with monolithic applications, the architectural transformation of microservice architecture not only improves the flexibility of development and deployment, but also increases the complexity of operation, maintenance and monitoring. After summarizing with practice, we believe that designing an excellent microservice system should follow the following design constraints:

Microservice Design Constraints

a well-designed microservice application , the completed functions should be independent of each other in terms of business domain division. Compared with the monolithic application forcibly binding the language and technology stack , the advantage of this is that different business domains have different technology choices. For example, the implementation efficiency of the recommendation system using python may be much more efficient than java. Organizationally, microservices correspond to smaller teams and higher development efficiency. "A microservice team can eat two pizzas in one meal " and "a microservice application should be able to complete an iteration at least once every two weeks" are metaphors and standards for how to correctly divide the boundaries of microservices in the business domain . To sum up, the "micro" of microservices is not for micro and micro, but to reasonably split the single application according to the problem domain .

Further, microservices should also have the characteristics of orthogonal decomposition, focusing on specific business and doing well in the division of responsibilities, that is, the Single Responsibility Principle (SRP, Single Responsibility Principle) in the SOLID principle. If a microservice is modified or released, it should not affect the business interaction of another microservice in the same system.

Horizontal relationship between microservices and microservices

After reasonably dividing the boundaries between microservices , the horizontal relationship between services is mainly dealt with from the discoverability and interactivity of microservices.

microservices refers to how service B, which depends on service A, can automatically perceive changes in service A without re-publishing when service A is released and scaled up or down? It is necessary to introduce a third-party service registry to meet the discoverability of services; especially for large-scale microservice clusters , the push and expansion capabilities of the service registry are particularly critical. The interoperability of microservices refers to the way in which service A can call service B. Due to the constraints of service autonomy, calls between services need to use language-independent remote invocation protocols. For example, the REST protocol satisfies the two important factors of "language-independent" and "standardization", but in high-performance scenarios, An IDL-based binary protocol might be a better choice. In addition, most of the current microservice practices in the industry often do not achieve HATEOAS-inspired REST calls, and services need to be called through pre-agreed interfaces. In order to further realize the decoupling between services , there needs to be an independent metadata center in the microservice system to store the metadata information of the service, and the service can understand the details of the invocation by querying the center .

As the service link continues to grow, the entire microservice system becomes more and more fragile, so the principle of failure-oriented design is particularly important in the microservice system. For individual microservice applications, mechanisms to enhance service resilience, such as current limiting, circuit breakers, compartmentalization, and load balancing, have become standard. In order to further improve the system throughput and make full use of machine resources, it can be achieved by means of coroutines , Rx models, asynchronous calls, and backpressure.

Vertical constraints between microservices and the data layer

In the field of microservices , the principle of Data Storage Segregation (DSS) is advocated, that is, data is the private asset of microservices, and access to this data must be accessed through the API provided by the current microservices . Otherwise, the data layer will be coupled, which violates the principle of high cohesion and low coupling. At the same time, for performance reasons, read-write separation (CQRS) is usually adopted.

Similarly, due to the unpredictable impact of container scheduling on the stability of underlying facilities, the design of microservices should follow the principle of stateless design as much as possible, which means the decoupling of upper-layer applications and underlying infrastructure, and microservices can be freely distributed between different containers. is scheduled. For microservices with data access (that is, stateful), the separation of computing and storage is usually used to sink data into distributed storage, and achieve a certain degree of statelessness in this way.

Distributed Constraints from a Global Perspective

From the very beginning of microservice system design, the following factors need to be considered:

efficiently operate and maintain the entire system, technically, a fully automated CI/CD pipeline should be prepared to meet the demands for development efficiency, and on this basis, different release strategies such as blue-green and canary should be supported to meet the requirements for business release stability. appeal.
Faced with complex systems, full-link, real-time, and multi-dimensional observability capabilities have become standard. In order to prevent various operation and maintenance risks in a timely and effective manner , it is necessary to aggregate and analyze relevant data from various event sources of the microservice system, and then display it in multiple dimensions in a centralized monitoring system. With the continuous splitting of microservices , the timeliness of fault detection and the accuracy of root causes have always been the core demands of development and operation and maintenance personnel .

3: Typical architecture of cloud-native microservices

Since the concept of microservice architecture was proposed in 2011, typical architectural patterns have been roughly divided into four generations in the order of appearance.

the first-generation microservice architecture, in addition to implementing business logic, applications also need to solve upstream and downstream addressing, communication, and fault tolerance by themselves . As the scale of microservices expands, the processing of service addressing logic becomes more and more complex. Even if it is another application of the same programming language, the basic capabilities of the above-mentioned microservices need to be reimplemented.

In the second-generation microservice architecture, the bypass service registry is introduced as the coordinator to complete the automatic registration and discovery of services. The communication between services and the fault tolerance mechanism begin to be modularized to form an independent service framework. However, with the increasing number of functions in the service framework, it is very difficult to reuse basic functions in different languages, which means that the developers of microservices are forced to be bound to a specific language, which violates the requirements of microservices . Agile iteration principles.

In 2016, the third generation of microservice architecture - service mesh appeared. The basic capabilities of microservices that were originally modularized into the service framework were further evolved from an SDK to an independent process - sidecar. This change completely solves the multi-language support problem in the second-generation architecture, and completely decouples the evolution of basic microservice capabilities and business logic iteration . This architecture is the microservice architecture in the cloud native era - Cloud Native Microservices. The sidecar process begins to take over the traffic between microservice applications, carrying the functions of the second-generation service framework, including service discovery, call fault tolerance, etc. Rich service governance functions, such as weighted routing, grayscale routing, traffic replay, service camouflage, etc.

In the past two years, with the emergence of AWS Lambda, some applications have begun to use serverless to build microservices, which is called the fourth-generation microservice architecture . In this architecture, microservices are further simplified from an application to micrologic (Micrologic), which puts forward higher demands on the sidecar model, and more reusable distributed capabilities are stripped from the application and sunk to the sidecar Among them, for example: state management, resource binding, link tracking, transaction management, security, etc. At the same time, on the development side, the concept of localhost-oriented programming has been advocated, and standard APIs are provided to shield the differences in underlying resources, services, and infrastructure, and further reduce the difficulty of microservice development . This is also the multi-runtime microservices architecture (Multi-Runtime Microservices) proposed by the industry .

4: Main Microservice Technologies

As an open source high-performance RPC framework from Alibaba, Apache Dubbo features transparent interface-based RPC, intelligent load balancing, automatic service registration and discovery, high scalability, runtime traffic routing, and visualized service governance. After several years of development, it has become the most widely used microservice framework in China and has built a strong ecosystem. In order to consolidate the overall competitiveness of the Dubbo ecosystem, in 2018, Alibaba successively opened up SpringCloud -Alibaba (distributed application framework), Nacos (registration center & configuration center), Sentinel ( flow control protection ), Seata (distributed transaction), Chaosblade (Fault injection), so that users can enjoy the micro-service system that Alibaba has accumulated for ten years , and obtain core capabilities such as ease of use, high performance, and high availability . Dubbo develops Service Mesh in v3. At present, the Dubbo protocol has been supported by Envoy . The work on data layer location, load balancing and service governance is continuing, and the control layer is currently enriched... Istio/Pilot-discovery.

microservice choices for developers, Spring Cloud provides developers with configuration management, service discovery, circuit breakers, intelligent routing, micro-agents, control buses, one-time tokens, global locks, and decision-making campaigns required by distributed systems. , distributed session and cluster state management capabilities and development tools.

a basic programming model for Java microservice development, Eclipse MicroProfile is dedicated to defining enterprise Java microservice specifications. MicroProfile provides metrics, API documentation, health checks, fault tolerance, and distributed tracing capabilities. Cloud-native microservices created with it can Freedom to deploy anywhere, including service mesh architectures.

Tars is an open source project summed up by Tencent's internal microservice framework TAF (Total Application Framework) . .Js and PHP developers. Tars includes a complete set of development framework and management platform, taking into account multi-language, ease of use, high performance and service governance. The idea is to make development more focused on business logic and make operation and maintenance more efficient.

SOFAStack (Scalable Open Financial Architecture Stack) is a set of middleware open sourced by Ant Financial for rapidly building a financial-level distributed architecture, and it is also a best practice tempered in financial scenarios. MOSN is a component of SOFAStack . It is a Service Mesh data plane proxy developed in Go language. Its functions and positioning are similar to Envoy. It aims to provide distributed, modular, observable, and intelligent proxy capabilities. MOSN supports Envoy and Istio APIs and can be integrated with Istio.

Dapr (Distributed Application Runtime) is a new Microsoft launch, a portable, serverless, event-driven runtime that enables developers to easily build elastic, stateless and stateful microservices, These services run on the cloud and the edge and include multiple languages and development frameworks.

Related Articles

Explore More Special Offers

  1. Short Message Service(SMS) & Mail Service

    50,000 email package starts as low as USD 1.99, 120 short messages start at only USD 1.00

phone Contact Us