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

This article introduces the knowledge of "how to understand the process of micro-service architecture from ideal to reality". Many people will encounter such a dilemma in the operation of actual cases. next, let the editor lead you to learn how to deal with these situations! I hope you can read it carefully and be able to achieve something!

The emergence of any new architecture mode or method must be a problem with the traditional architecture model. For monomer applications, the common problems mainly include the following points.

The scale of single application is too large, which leads to a sharp increase in complexity and is difficult to develop and manage.

The cycle of single application development, delivery and change becomes longer, and agility can't keep up.

The monomer application itself has problems in performance and scalability.

In software architecture design, divide and conquer has always been a key way of thinking to solve complexity. Including in the traditional software architecture design, the large system will be divided into subsystems or components, interface design, integration design and so on.

The core thinking of architecture is still: decomposition + integration.

However, when decomposing, the traditional architecture does not achieve a high degree of autonomy and complete deconstruction of a single component. This high degree of independence and autonomy actually requires components or modules to be highly independent from development, design, testing, online operation, and later operation and maintenance throughout the life cycle; at the same time, it also requires the development team to cooperate with, and the organizational structure design is also independent.

It is for this reason that the micro-service architecture has been further developed. In other words, the micro-service architecture is actually a further strengthening of the traditional component-based architecture design idea, and the core of the strengthening is independence and decoupling.

One of the key points of the idea of micro-service architecture is the separation of single applications.

When it comes to microservices, we are sure to talk about expanding cubes.

Generally speaking, the method of expansion for traditional monomer applications can only be the horizontal expansion of the X axis by extending an example. The other two important extensions are functional split and database split.

For function split is actually nothing new, in the early component architecture design, we have done to deploy different application components to different App Server servers, for the application layer you only need to consider to solve problems such as Session session saving, global configuration and distribution, and will not involve complex data persistence problems.

What is really difficult is to split the database. Because database splitting introduces two big problems, one is the distributed transaction problem, and the other is the distributed transaction problem caused by a large number of operations across the database.

Why is the database split?

After the monomer application has developed to a certain stage, the performance problems are often difficult to solve at the DB level. Database cluster is difficult to achieve horizontal elastic expansion, even for commercial cluster software such as Oracle RAC, it also has its own performance expansion bottleneck. After the performance has been extended to 2 to 3 times, it can no longer be scaled.

Therefore, purely from the expansion of instance expansion, a read-write separation cluster is derived. Read-write separation cluster is actually the best way to expand in response to business scenarios with a large proportion of read operations. in this way, the database itself is not split into multiple instances, and the two major problems encountered earlier will not be introduced. As long as a DaaS database access middleware is built on the database, the split and change at the bottom of the database can be transparent to the upper application development.

When it comes to this, it will be clearer to review some of the core points of microservices.

Micro service is the separation of traditional monomers, and it needs to be highly independent and autonomous.

The split of micro-service is not only the function split, but also the database split.

Asynchronism and decoupling are important guiding ideas for micro-service architecture design.

Micro services interact and cooperate with each other through lightweight and efficient Http API interface

Micro-service practice needs to be supported by development organization, continuous integration, testing and delivery methods.

Scenario and problem driven

When talking about micro-services, I mentioned that the micro-service architecture itself will lead to an increase in the complexity of development, integration, and operation and maintenance. Even for the so-called high availability, it is only an increase in high availability and elastic scalability, but a decrease in high reliability.

So what is the reason for an enterprise or team to practice microservices? It is just that micro-service is an architectural development trend and a hot spot of technology. are all Internet companies using it?

In fact, for many enterprise application micro-services, we can see that there are always some technology fanatics in the team who are keen on new architectures and new technologies, but do not care about which business scenarios these technologies solve. This directly leads to a large number of technologies being used at inappropriate times.

This is not to say that microservices are bad, but that architects should consider when and which technology is the most appropriate based on business, technology, team resources, cost and other dimensions.

E-commerce platform like Alibaba has hundreds of millions of visits a day, nearly a million TPS, and hundreds of thousands of transactions in the peak seconds. In this business scenario, each module is divided into independent centers, and independent databases are inevitable. It is not that what technology is advanced must be used, but in order to meet and support the business must be micro-service.

Then traditional enterprises to practice micro-services must think about what problems can be solved by micro-services. If you don't think about this problem clearly, don't go to microservices easily. Secondly, it is not easy to idealize the practical micro-service architecture that can be solved by other traditional ways.

For example, if there is a performance bottleneck in the database during the operation of a business system, what you can consider at this time is to migrate the historical data to the standby database to increase the query ability of the database documents; or to build a read-write separation cluster of the database or build a secondary index cache on the database to solve the performance problem.

For example, when some business systems have bottlenecks, it is not the conventional OLTP scenario that causes problems, but a single business system database that supports both OLTP and OLAP capabilities. At this time, you should remove a large number of query statistics and data analysis functions, rather than split the data of the entire business system.

There are many examples in this respect, in fact, I want to illustrate that the complexity and performance problems of many business systems are far from the point that they must be split into functions and databases.

Micro-service split strategy

When talking about micro-service splitting, let's first talk about the component splitting in traditional software architecture design.

For component splitting, you can see that the regular component split is actually in the application layer without going to the specific database. As a result, after the component is split, the underlying database is still a central point and a tightly coupled point. Including after the component split, the actual architecture planning hopes to call cooperation through the interface between the components, and there is often a deviation in the subsequent development and implementation, that is, it is often said that the problem is still solved through the associated sql query of the underlying database. So what you can see is that there are no interface calls between components, and a lot of coupling goes to the coupling of the underlying database.

When it comes to the split of the micro-service phase, it has actually become two important things, one is the split of the database, and the other is based on the functional split after the split of the database.

For the split, I have written two articles earlier, which can be referred to:

Rethinking of dividing Micro-Services by Domain Model and context Boundary Analysis

Talk about database split under DaaS database as a service and micro-service

Whether it is the traditional structured analysis method, or the current similar DDD domain-driven modeling in the sub-domain division, context boundary identification and so on. The focus of the split is still on the database split, but it is understood as the core domain object split in the DDD method, and the corresponding database and functions are split naturally.

First sort out the boundary and split the service, and then sort out and define the API interface based on business collaboration and business function implementation, that is to say, the micro-service split work actually includes three aspects.

That is, database split, function split, API interface identification and definition.

For micro-service splitting, the real difficulty lies in the granularity of micro-service split. When we reread this book, we are glad that we did not practice micro-service in such an idealized way as in the book, to split micro-service into such fine details, otherwise it is really a train of thought.

Therefore, an important point needs to be reiterated here.

Micro-service split should not be idealized to which granularity according to the standard theory, but should be split to an appropriate granularity according to the actual business scenario and scalability requirements.

For example, what you are doing now is a takeout ordering system. If it is a fine-grained micro-service split on a scale like Meituan APP, it is inevitable. But if your system faces only private cloud deployment scenarios such as communities, campuses, etc. Then this system from the business scenarios and concurrency are not necessary to do a large micro-service split, the actual architecture for front-end separation, independent cache, read-write separation can basically solve the problem.

Therefore, the extent to which the micro-service is split is related to the business scenarios and problems faced by the business system, rather than using the standard similar split strategy.

There are no problems with these methods, such as object-oriented analysis and design, DDD domain-driven and domain object analysis and recognition. These methods can be applied within the application, and component-based splitting is also needed within the application, not that each component must be divided into independent and highly autonomous micro-services.

From API interface to asynchronous decoupling

I have written a special article to describe the API interface design in the micro-service architecture. Here I would like to restate two important points about API interface design and exposure.

Understanding of Http Rest API standards and specifications

You should know that Rest API is more of a resource-oriented API interface design method. In the early days, I myself insisted on the need to install an idealized Rest interface design method to design the interface. But at present, I prefer to only use Http API as the interface implementation, whether the Rest style is not the point.

That is to say, in the interface implementation, it is possible to implement POST interface methods for all interfaces without distinguishing which must use GET and which still use PUT methods. Although the implementation of the POST method will bring some inconvenience to the online access and testing of some interfaces, this can be solved in other ways.

Front and rear separation and exposure of a large number of API interfaces

The API interface itself should be coarse-grained, but in many projects, we often see that all the CRUD methods of database tables are exposed as API interface methods. On the one hand, it is the anemia of the domain object layer, and the other is that the separation of the front and rear ends leads to the internal API interface of the original data access layer all need to be exposed through the Http API interface.

An internal IT system, which is only used in the internal LAN, only provides the BS browsing interface on the PC side, and there is no need for support on the app side, so there is no need to separate the front and rear ends in this case. On the contrary, the separation of front and rear ends brings a large number of problems, such as a large number of exposure of back-end API interfaces, front-end and back-end integration cooperation and so on.

In this scenario, if the IT system is divided into five micro-service modules, the API interface design and integration between these five micro-service modules is the problem that we really need to pay attention to.

In the current micro-service architecture design, the interface collaboration between micro-services and the front-and back-end interface coordination of micro-services are all mixed together, which actually leads to the complete loss of control of API governance in the whole micro-service system.

Distributed transaction based on Saga

When we talk about distributed transactions, we talk more about transaction compensation or transaction consistency guarantee, but many long-cycle transactions are still implemented by synchronous calls of the API interface. That is, when the API interface is called synchronously, there is no complete decoupling between microservices. Decoupling must be an asynchronous invocation based on an event or message pattern.

Saga is a distributed transaction solution based on asynchronous message event mechanism. Saga is made up of a series of local transactions. After each local transaction updates the database, a message or an event is issued to trigger the execution of the next local transaction in the Saga. If a local transaction fails because some business rules cannot be satisfied, Saga performs compensation operations for all transactions that were successfully committed before the failed transaction.

There are many ways to implement Saga, two of which are the most popular:

Event-based approach. There is no coordination center in this way, and the whole mode works like a dance, with each dancer performing according to the pre-choreographed movements and movements, eventually forming a dance.

Command-based approach. This way of working is like a band, with a conductor (coordination center) coordinating everyone's work. The coordination center tells the participants in Saga which local transaction should be performed.

When rethinking distributed transactions, I once again confirm my view that the fine splitting of microservices leads to the introduction of many unnecessary distributed transaction problems, which increases the workload and complexity of development, integration, testing and subsequent monitoring of operations and maintenance.

For example, in an example mentioned in the book, for an online ordering system to submit an order, this in itself is an easy function, but after microservice, order submission involves user verification, account verification, and kitchen work orders generate multiple independent API service interface calls. This involves the event choreography of these API interfaces, and you also need to consider the compensation fallback in the event of an exception, the order of message execution and many other issues.

These dramatically increase the complexity of the implementation of a function. When your own system does not have massive concurrency and high-performance requirements, it is hard for me to find any reason to split micro-services into so much detail and introduce so much complexity.

In fact, the above distributed transaction scenarios should be more applied to the distributed transaction collaboration between large systems, such as when the procurement system submits an order, and involves the startup of workflow instances in the workflow platform. It is necessary to implement distributed transactions at this time when it involves budget verification of the budget system.

The above distributed transaction processing and collaboration scenarios occur across systems, and this amount is completely controllable. But your micro-service is split too fine, and you introduce the above distributed transaction problem into any function in your application. Event-based scheduling and compensation is not a simple complexity problem. It is a later system reliability and operation and maintenance problem.

How to decouple completely?

I talked about how to handle query operations if CUD operations can be decoupled asynchronously. If a query lookup itself also involves the combination of multiple microservice API interfaces, how to achieve decoupling at this time.

Generally speaking, query operations are synchronous operations. Users will wait for the data to be returned after clicking the query. At this time, if you need to call multiple micro-service API API data to combine them, such an exception of one of the underlying micro-service modules will directly cause the whole query function to remain abnormal.

That is, if there is a query operation, then the micro-services are still tightly coupled. The goal of complete decoupling between microservices through messaging and asynchronism has not been achieved.

Of course, there are actually two ways to solve this problem.

One is to cache the commonly used data and access the cache directly when querying.

The second is to synchronize the shared data in the underlying database of micro-services to a large shared ODS reading library to provide query services.

In the practice of CQRS command query responsibility separation in some projects, this idea is basically adopted. In this way, complete decoupling between micro-services can be achieved. Of course, two other dependency points are introduced, one is message middleware, and the other is cache library or distributed ODS reader library. The stability of these two points directly affects the stability of the whole system.

One of the biggest problems in using CQRS mode is that it is impossible to guarantee the strong consistency between command and query, that is, it is very likely that the data queried on your interface is not the latest data in the persistent database, which itself has something to do with the real-time performance of asynchronous writing in the message pipeline.

Secondly, when using the CQRS pattern, there is an important assumption that after the event and command are issued, the event receiver must be able to receive and handle the event successfully, otherwise there will be a large number of asynchronous write-back of abnormal error messages, which will increase the complexity of the system.

The overall complexity introduced by the implementation of CQRS is not affordable for ordinary small projects.

At the same time, for the implementation of the CQRS framework, it is not a simple design pattern and development complexity, but still more important is whether it can accept the final consistency requirements. At the same time, under this requirement, the traditional business function and logic processing mechanism under synchronous requests are transformed into event chain-driven patterns under the value of asynchronous events. To achieve this transformation, it is necessary to be able to split independent, autonomous commands and events, while ensuring that these events can be successfully handled when sent to back-end business functions and logic modules (that is, the verification that should be done must be done in advance).

Micro service gateway and API gateway

For API gateways, you can also refer to the relevant articles published in my headlines.

The core functions implemented by the API gateway and the micro-service gateway are basically the same, but it should be noted that the micro-service gateway is generally in the micro-service architecture. The API gateway is generally the content that can be independent of the micro-service architecture.

In other words, the API gateway and the overall framework of micro-services are more loosely coupled.

API gateways generally have independent service registration access, load balancing and routing capabilities, while micro-service gateways generally realize service registration discovery, load balancing and routing through integration with service registries.

The difference in the scope of application

It is re-emphasized here that there is an obvious difference in the scope of application between the micro-service gateway and the API gateway. That is, micro-service gateways are generally applied within a single micro-service application, especially in the case of front-end separation. For API gateway, it is applied at the organization level to realize the integration and collaboration among multiple micro-service applications.

For a single micro-service application, it is not necessary to use the API gateway, but directly use the micro-service gateway. For example, when you adopt the SpringCLoud framework, you can directly use the Zuul or SpringCLoud Gateway in the framework.

But when you are doing the integration of multiple micro-service applications at the organizational level, you need an external integration middleware that is separated from a single micro-service framework, so you can't bind to the micro-service framework too hard. Second, you will see that the granularity of cross-application integration control is not to micro-service components, but to refine to individual API interfaces. Therefore, it is necessary to enable the API gateway at this time.

When you enable the API gateway at the organizational level, you find a new problem.

That is to say, for the whole organization level, the micro-service of legacy system and single application has its own process, in which the traditional architecture and micro-service architecture must coexist. The coexistence phase of the new Rest API interface and the old SOAP interface and message protocol. However, the API gateway itself is not adaptable to the old interface protocols. Although it is too heavy for a similar ESB bus, it can be fully compatible with and cover the capabilities of API gateways.

Therefore, in this case, the API gateway becomes a chicken rib.

Should API gateways do something like service orchestration and composition?

To put it simply, API gateways should not do this. Traditional ESB buses often have this capability, but API gateways are not suitable to carry this capability. If the service orchestration is done, one is to change the API gateway itself from a simple technical middleware to a middleware that carries business logic, and the second is that the capability itself will also make the API gateway more serious.

Therefore, the best way is still to implement service composition and choreography by a separate micro-service, and to publish the domain service or composite service capability after composition, which I specifically talked about in my previous article.

The centralization of API Gateway itself

Do not simply think that the centralized architecture is not good. Through centralized control and interception, the centralized architecture itself can easily achieve various management and control capabilities such as API interface security, logging, routing, flow control and so on.

When talking about micro-service governance, centralized API gateway is an important implementation idea and means, of course, I also mentioned earlier that the overall development trend should be ServiceMeshization, to achieve a complete decentralized architecture. This ServiceMesh itself can form a complete whole with cloud native technologies such as DevOps and container cloud.

But the point to be aware of is still the strength of organizational control and standardization. If many technical standards are inconsistent at the organizational level and the application system transformation gradually evolves before and after the existence, then it is difficult to simply implement the ServiceMeshized architecture at this time. To put it simply:

For the gradual micro-service of the traditional IT architecture, it is not suitable to adopt ServiceMesh.

When talking about micro-service architecture, people often talk about complete decentralization, but it is not clear why it should be decentralized. Even with asynchronous message integration, message middleware is still the central point. When the organization-level standards and technical requirements are not unified, it is difficult to completely decentralized when the management and control capabilities are not reached. At this time, centralization is a good choice.

Finally, a brief summary is made as follows:

According to the ideal micro-service method to design and implement micro-service, it is not suitable for most traditional enterprise informatization, and it is also not suitable to copy the Internet micro-service architecture method. In the process of micro-service transformation, enterprise IT architecture should be based on business scenarios and problem-driven, learn from the idea of micro-service split and decoupling, and fully consider agile delivery, elastic expansion and performance, development difficulty and resource cost input, and the balance of management and governance in the later stage.

This is the end of the content of "how to understand the process of microservice architecture from ideal to reality". Thank you for reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

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.