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

In this issue, the editor will bring you what are the 4 design principles and 19 solutions for microservices. The article is rich in content and analyzes and describes for you from a professional point of view. I hope you can get something after reading this article.

Micro-service architecture is now a topic that must be talked about when talking about enterprise application architecture. the reason why micro-services are hot is that compared with previous application development methods, micro-services have many advantages, such as more flexible and more adaptable to the current environment of rapidly changing requirements.

The editor will introduce the evolution, advantages and disadvantages of micro-service architecture and the design principles of micro-service applications, and then focus on what capabilities and problems need to be provided as a "micro-service application platform" to better support enterprise application architecture.

The micro-service platform is also a platform product that I am currently involved in and is still in the process of research and development. the platform is a micro-service application platform gradually incubated based on SpringCloud and combining Puyuan's understanding of enterprise applications and product design experience for many years.

I. the evolution process of micro-service architecture

In recent years, we have all realized the benefits of the Internet and mobile interconnection. As IT practitioners, while they always feel the benefits of the Internet in life, they may feel some pressure from the Internet in their work, that is, the IT construction of our traditional enterprises is also in urgent need of transformation, need to face external customers, and we also need to cope with the rapid changes in the external environment and rapid innovation. Then our IT architecture also needs to learn from Internet enterprises to make corresponding improvements to support the digital transformation of enterprises.

Let's take a look at the evolution of the application architecture and recall how the micro-service architecture evolved step by step. At first, the application was a single-block architecture, and later, in order to have a certain degree of expansion and reliability, there was a vertical architecture, that is, adding a load balancer, followed by SOA, which was popular a few years ago, mainly talking about how to integrate and intercommunicate between application systems. Up to now, the micro-service architecture is further exploring how to design an application system so that it can be better developed and managed more flexibly and efficiently.

The basic idea of micro-service architecture is to "create applications around business domain components, so that applications can be developed, managed and accelerated independently".

Second, the benefits of micro-service architecture

We summarize the advantages in four aspects, which are as follows:

Is that each micro-service component is simple and flexible and can be deployed independently. Unlike before, applications no longer need a large application server to support.

A small team can be responsible for being more professional and correspondingly more efficient and reliable.

The micro-services are loosely coupled, the micro-services are highly cohesive, and each micro-service is easy to expand on demand.

Micro-service architecture has nothing to do with language tools, so you can freely choose the appropriate language and tools to achieve business goals efficiently.

Seeing here, people will think that the micro-service architecture is quite good, but there will still be some questions, what kind of application is a micro-service architecture application? How to design an application of micro-service architecture? Let's take a look at the design principles of our recommended microservice applications.

III. Four design principles for micro-service applications

We have summarized four principles and recommended them to you:

AKF split principle

Front and rear end separation

Stateless service

Restful communication style

1.AKF split principle

The AKF extension cube (see "The Art of Scalability") is the three dimensions of the application extension abstracted by technical experts of a company called AKF. In theory, according to these three expansion modes, a single system can be extended.

X axis: refers to horizontal replication, which is easy to understand, that is, a single system runs several more instances and makes a cluster plus load balancing mode.

Z axis: it is based on similar data partitioning, for example, an Internet ride-hailing application suddenly or suddenly, the number of users increases rapidly, and the cluster mode can no longer support, so partition the data according to the region requested by the user. Build several more clusters in Beijing, Shanghai, Sichuan and so on.

Y-axis: what we call the split mode of micro-services, which is based on different business splits.

Scenario description: for example, when a cluster cannot hold up, a taxi-hailing app is divided into multiple clusters, but the number of users is still not enough. After analysis, it is found that there is a large number of visitors from passengers and car owners. The taxi-hailing app is divided into three passenger services, car owner services and payment services. The business characteristics of the three services are different, they are maintained independently, and each can be expanded again on demand.

two。 Front and rear end separation

The principle of front-end and back-end separation is simply the separation of front-end and back-end code, that is, technical separation. Our recommended model is to deploy directly by physical separation to further promote a more thorough separation. Do not continue the previous server-side template technology, such as JSP, where the Java JS HTML CSS is all piled into one page, and slightly more complex pages cannot be maintained. This separation mode has several benefits:

The front-end technology is separated, and the respective experts can optimize their respective fields, so that the front-end user experience optimization effect will be better.

In the separation mode, the front-end interface is clearer, leaving only the interface and model, and the back-end interface is concise and easier to maintain.

The front-end multi-channel integration scenario is easier to implement, and the back-end service does not need to be changed. The unified data and model can be used to support the front-end access such as web UI / Mobile App.

3. Stateless service

For stateless services, let's first talk about what state is: if data needs to be shared by multiple services to complete a transaction, that data is called status. A service that relies on this "state" data is called a stateful service, whereas it is called a stateless service.

Then this stateless service principle does not mean that there is no state in the micro-service architecture, but what it really means is to change a stateful business service into a stateless computing service. then the state data is migrated to the corresponding "stateful data service" accordingly.

Scenario description: for example, the data cache and Session cache previously established in local memory should be migrated to distributed cache for storage in the current micro-service architecture, so that the business service becomes a stateless computing node. After migration, we can dynamically scale on demand, and micro-service applications dynamically add and delete nodes at run time, so there is no need to consider how to synchronize cache data.

4.Restful communication style

As a principle, it should be a "stateless communication principle". Here we directly recommend a practical preferred Restful communication style, because it has many benefits:

HTTP, a stateless protocol, has inherent advantages and strong scalability. For example, the need for secure encryption is that there is a ready-made mature scheme HTTPS available.

JSON message serialization, lightweight and simple, human and machine readable, low learning cost, search engine friendly.

Language-independent, all the popular languages provide mature Restful API frameworks, which are more ecologically sound than some other RPC frameworks.

Of course, in some special business scenarios, we also need to use other RPC frameworks, such as thrift, avro-rpc, grpc. But in most cases, Restful is sufficient.

Fourth, the problems brought by the micro-service architecture

If you achieve the four principles mentioned above, it can be said that you have built a micro-service application, which does not feel complicated. But in fact, micro-service is not a panacea, and it has both advantages and disadvantages. next, let's take a look at the problems brought about by the introduction of micro-service architecture.

Dependent service changes are difficult to track, what if the service interface documents of other teams are out of date? The dependent service is not ready, how to verify the functionality I developed.

Some modules are built repeatedly, and there will be a lot of repeated construction across teams, systems and languages.

Microservices magnify a series of problems of distributed architecture, such as how to handle distributed transactions? What if the dependent service is unstable?

The complexity of operation and maintenance increases sharply, for example, the large number of deployments and the large number of monitoring processes lead to the increase of overall operation and maintenance complexity.

We should have encountered all these problems, and there will also be some solutions, such as providing tools and frameworks for document management, service governance and service simulation; realizing unified authentication, unified configuration, unified log framework, distributed summary analysis; using global transaction scheme, asynchronous simulation synchronization; building continuous integration platform, unified monitoring platform, and so on.

These solutions have finally figured out that we need a micro-service application platform to solve these problems as a whole.

Fifthly, 19 landing practices of micro service platform

1. Three basic environments for the Construction of Enterprise IT

Let's take a macro look at an enterprise's IT construction of three very important basic environments: team collaboration environment, personal infrastructure environment, IT infrastructure.

Team collaboration environment: mainly in the area of DevOps, responsible for everything from requirements to planning tasks, teamwork, to quality management, continuous integration and release.

Personal basic environment: it is the micro-service application platform introduced in this paper, and its main goal is to support the design, development and testing of micro-service applications, business data processing and application management and monitoring.

IT infrastructure: what we usually call the implementation of various operating environments such as IaaS (VM Virtualization) and CaaS (Container Virtualization).

two。 Overall architecture of micro-service application platform

The overall architecture of micro-service application platform is mainly divided from the dimensions of development integration, micro-service operation container and platform, runtime monitoring governance and external channel access.

Development integration: mainly to build some tools and warehouses necessary for a micro-service platform.

Runtime: to have a micro-service platform to provide some basic capabilities and distributed support capabilities, our micro-service runtime container will run on this platform.

Monitoring governance: it is committed to the ability to uniformly monitor and configure managed micro-services at runtime.

Service gateway: it is responsible for integrating with the front-end WEB applications, mobile APP and other channels, carefully authenticating the front-end requests, and then routing and forwarding.

3. Operation view of micro-service application platform

Referring to the figure above, during the run-time, as a micro-service architecture platform and business system, in addition to the business application itself, platform-level services such as access services, unified portals and basic services are also needed to ensure the reliable operation of the business system. The public services in the figure are some of the optional services that need to be used in the business process.

4. The design goal of micro-service platform

The main goal of the micro-service platform is to support the full lifecycle management of micro-service applications, from requirements to design, development and testing, runtime business data processing, application management and monitoring, and so on. In the follow-up, we will start from several important stages of the application life cycle, and introduce the capability support provided by the platform in combination with the previously mentioned design principles and problems.

5. Micro service development: front end, back end, hybrid

Let's take a look at some screenshots of some development tools of our developing micro-service application platform EOS8.0 to see what key capability supports are provided during the development period.

The previous design principle mentions a principle of front-end separation, so our development environment currently supports the creation of front-end projects, back-end projects, and hybrid projects. Among them, the front-end project and back-end project correspond to the principle of front-end separation, and the front-end and back-end development can be separated by using the integrated development tools and framework in the platform. Using continuous integration tools, the front-end and back-end projects can be compiled and packaged into programs that can be run independently. Hybrid projects are reserved for compatibility with traditional models and provide a transition solution for the evolution of enterprise applications to micro-service architecture.

6. Service contract and API Management

For the dependency management problems caused by microservices mentioned earlier, we can solve them through the API management capabilities provided by the platform. When it comes to API management, first mention the service contract. The platform development tools provide convenient service publishing capabilities, which can quickly release business functions and generate service specification contracts. Of course, we can also design service contracts first and generate the default implementation code of services according to the contract.

To emphasize here, the service contract we mentioned is a very important thing, which is somewhat similar to the wsdl description of web service, mainly describing the input and output specifications of the service interface and other specifications related to service invocation integration.

7. Service contract and Service Simulation

With the service contract, we can automatically generate service documents and service simulation test environment according to the contract, so that developers can easily get the change of dependent service. can timely adjust their programs according to the changes of dependent services, and can easily carry out simulation testing and verification.

Generate a simulation service according to the contract, which is what we often call a service bezel, so that we can conduct joint debugging testing through the bezel, even if other dependent services are unable to provide functionality.

8. Service contract and Service arrangement

With the service contract, then there is the input and output specification of the service interface, and the service orchestration of restful becomes feasible. In the contract standard we designed, we also define the content related to the invocation integration, such as the transaction pattern supported by the service, and so on. Through these conventions, we can use a simple graphical way to orchestrate business service processes. Choreography can greatly simplify the complexity of distributed service invocation, such as synchronous, asynchronous, asynchronous simulation synchronization, timeout retry, transaction compensation, etc., which are completed by the service orchestration engine, and no longer rely entirely on the coding ability of the old master.

Service choreography plays a great role and significance, which can quickly combine and release the micro-service capabilities that have been provided, which is very suitable for the rapid innovation of the business.

But you should note that the logical flow orchestration is a business process, as far as possible to be simple and clear, at a glance to understand the meaning of the business. The business rules are recommended to be implemented by coding within the service. Do not completely replace program coding with our "logical flow" graphical service orchestration, which may go to the other extreme, such as designing a spider-like logical flow diagram, which is simply a disaster.

9. Micro service container

Let's take a look at a logic diagram of the micro-service running container. You can see that we need to do a lot of things to do micro-service architecture applications, reliable and efficient micro-service applications. Without a unified micro-service container, these capabilities need to be built in each micro-service component, and they will be varied and difficult to integrate. With a unified micro-service running container and some public basic services, the problem of repeated construction of some components under the micro-service architecture mentioned above can also be easily solved.

10. Description of tripartite capability integration

Our API management contract document API simulates that we are an integrated Swagger tool chain. The foundation of the micro-service application platform is SpringCloud, which is supported by his capabilities, from container framework to registration discovery to security authentication. Let's take a brief look at some of the open source frameworks and tools we integrated.

The positioning of SpringCloud in the micro-service platform is the basic framework. This paper focuses on introducing some design principles and solutions of an enterprise-level micro-service platform in the landing process. Specific Spring Cloud-related technologies will not be introduced in the article, you can check the relevant articles in our official account.

11. Service registration discovery route

Next, let's talk about registration and find that it is OK to configure an IP when calling each other between single applications, but in the micro-service architecture, there will be many service providers, so it is not feasible to configure IP addresses manually. Then the solution of service auto-registration discovery solves this problem.

Our service registration discovery capability relies on SpringCloud Eureka components. When the service is started, it registers the service to be published with the service registry. At runtime, if you need to call the interfaces of other micro-services, you must first go to the registry to obtain the address of the service provider. After getting the address, it is used for routing through the simple load balancing period within the micro-service container.

In general, the invocation of micro-services in the system is carried out through this client load pattern, otherwise there will be a lot of load balancing processes. This decentralized routing method can also be used for service invocation across business systems. Of course, using the SOA model, the centralized service network management to manage the invocation between systems is also another choice, which should be combined with the current situation and needs of the enterprise IT.

twelve。 Unified authentication and authentication

In terms of security authentication, we use Spring Security combined with Auth3 and JWT (Json web token) as security tokens to achieve unified security authentication and authentication, so that micro-services can be isolated and securely interconnected on demand. In the follow-up, in terms of unified authentication and permissions, our products will gradually launch more perfect and scalable micro-service components, which can be used as public authentication and authentication services for the micro-service platform. In another word, authentication and authentication must be a public service, not the construction of multiple systems.

13. Log and pipelining design

As a micro-service application platform, in addition to providing technical components and frameworks to support development and operation, we also provide some operation and maintenance friendly experience summary. Let's take a look at our recommended log and pipelining implementation. First, let's take a look at the log. There are three main types of logs provided by the platform by default: system log, engine log and trace log. With these logs, when something goes wrong, it can help us to get some key information to locate the problem.

If we want to be able to trace the source of the problem, the design of these serial numbers on the right is also very important. The log together with various serial numbers allows us to quickly locate the specific time and place of the problem and relevant information, and quickly restore the full link of the business transaction. The details of these logs and pipelining are of great help for the positioning of system operation and maintenance problems. Without these useful log contents, no matter how beautiful the ELK log collection suite is, it is useless to collect a pair of junk logs. Usually, the open source framework only provides a framework for developers to play freely, while designing a platform must consider directly providing the basic capabilities of a unified specification.

14. Centralized configuration management

In the micro-service distributed environment, a system is divided into many micro-services, so we must bid farewell to the way of putting into production or operation and maintenance to manually modify the configuration. Centralized configuration management is needed to improve the efficiency of operation and maintenance.

There are mainly two kinds of configuration files: static configuration before operation and dynamic configuration at run time. Static configuration is usually set up before the deployment package is compiled. Dynamic configuration is the system variables or business parameters that need to be adjusted during the operation of the system. To achieve centralized configuration management, you need to pay attention to the following points.

It is the separation of the configuration and the media, which needs to be controlled through the formulation of specifications. Never put the configuration in the Jar package.

The way of configuration should be unified, the format, the way of reading and writing, and the mode of change and hot update should be unified as far as possible, and a unified configuration framework should be adopted.

That is, the runtime needs a configuration center to manage the configuration information in the business system, which requires a platform to provide configuration center services and configuration management portals.

15. Unified Management Portal

Under the micro-service architecture, a large EAR and WAR application is split into several small micro-service programs that can run independently, usually these micro-service programs no longer rely on the application server, and if they do not rely on the traditional application server, the management console provided by the application server will be useless, so the runtime management of micro-service needs to be supported by a unified management portal. We have planned a unified and centralized micro-service portal, which can support application development, business processing, application management, system monitoring and so on. The above figure is the application management page, which is to manage our traditional business system. By clicking on a business system, we can see what micro-services are under the system, and each micro-service has several node instances to run again. You can monitor the status of the sub-nodes of the micro-service, and configure and monitor the micro-service.

16. Distributed transaction problem

In the system of micro-service architecture, the number of processes increases exponentially, so the problem of distributed transaction consistency becomes more obvious. The transaction consistency we are talking about here is not the traditional technical transaction based on database implementation. Microservices are independent of each other, and the invocation protocol is stateless, so the database transaction solution is no longer under our consideration from the very beginning. What we need to solve is to achieve the final consistent state of the data after a certain period of time, to be exact, to adopt the traditional way of business compensation and correction.

There are three recommended transaction consistency scenarios:

Reliable event mode: that is, the sending and receiving of events ensure high reliability to achieve transaction consistency.

Compensation mode: Confirm Cancel, if the confirmation fails, all will be cancelled in reverse order.

TCC mode: Try Confirm Cancel, a special implementation of the compensation model. This mode is usually used in transfer transactions.

17. Distributed synchronous invocation problem

Under the micro-service architecture, there are more distributed calls than the traditional deployment mode, so the sentence "how to deliver a determined service in an uncertain environment" can be simply understood as: when the reliability of the service I rely on cannot be guaranteed, how can I ensure that I can provide services normally and not be dragged down by other services I rely on?

We recommend the SEDA architecture to solve this problem.

SEDA: staged event-driven architecture is essentially a solution that adopts distributed event-driven mode, synchronous with asynchronous simulation, non-blocking waiting, and resource allocation isolation.

18. Continuous Integration and continuous delivery Design

In terms of operation and maintenance, the first thing we need to solve is continuous integration and continuous delivery, while the scope of responsibility of the micro-service application platform is currently planned to only do continuous integration, and can easily compile programs into media packages and deployment packages in a continuous integration environment. (currently, continuous deployment is planned to be provided by the DevOps platform, and the micro-service platform can be integrated with the DevOps platform.)

Here to clarify a concept: media, is the product of source code compilation, independent of the environment, multi-environment should be shared, such as: jar, dockerfile; configuration: it is environment-related information. Configuration + Media = deployment package.

After obtaining the deployment package, the responsibility of the micro-service application platform is completed, and then the operation and maintenance personnel show their talents to deploy online.

19. The relationship between Micro Service platform and Container Cloud and DevOps

As far as the micro-service application platform itself is concerned, it does not rely on DevOps and container cloud, and the developed deployment package can run in a physical machine, a virtual machine or a container.

However, when the micro-service application platform combines DevOps and container cloud, we will find that continuous integration and delivery has become a very simple, convenient and reliable process.

With a few simple steps, a complete set of development, testing, pre-release or production environment can be built. The complexity of the whole process is shielded by the platform. Through the integration of the three basic environments, we can make the decentralized micro-service components more simple and convenient for unified management and operation and maintenance delivery.

VI. Summary and prospect

Let's review the relationship between the three basic environments. Micro-service application platform is responsible for application development, operation and management; DevOps is responsible for project management, plan management, CI, CD and team communication and cooperation; and container cloud platform is responsible for basic setting management, shielding the complexity of the environment.

The construction of these three basic environments directly reflects the level of IT capability of enterprises. These three basic environments are what technicians and enterprises want to have. they are the basis for enterprises to win competition and drive business innovation, and the only way for enterprises to accelerate digital transformation.

Let's take a look at the new generation of The Platform platform that Puyuan is developing.

The content in the red box above is related to the micro-service application platform we share today. The whole The Platform platform is from the point of view of the overall enterprise architecture planning, starting from multiple dimensions, the goal is to build a sustainable development IT ecological environment for enterprises and accelerate the digitization of enterprises.

These are the 4 design principles and 19 solutions of microservices shared by the editor. If you happen to have similar doubts, please refer to the above analysis to understand. If you want to know more about it, you are welcome to follow the industry information channel.

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.