8 key ideas, practices, and experiences from single-unit architecture to MicroServices

Reproduced in this article should be annotated source: EAII Enterprise Structure Innovation Research Institute (No.: Eaworld), offenders must investigate. To join the group participation in micro-classroom, architecture design and discussion live please respond directly to this public number: "Add group name Company Position No.".

As the microservices architecture continues to burn, more and more discussions are being devoted to microservices and monolithic architectures on the web. Last year, the community was more focused on the difference between the two and the pros and cons, and this year, more and more people began to focus on how to move from the monolithic architecture to microservices. There is no doubt that the concept of microservices is sweeping through the developer community, and companies like Netflix and Uber are a very successful application case.

But it is important to note that the implementation of MicroServices also requires additional costs, as Martin once said, unless you are faced with a monolithic application that is too complex to manage, never consider using microservices. Most software systems should be built as separate, monolithic programs. Be sure to focus on the modularity of the monomer application itself, rather than trying to separate them into separate services.

Primeton Software PRODUCT Department technical manager Liu Xiang has a lot of practice and thinking on the micro-service architecture, INFOQ reporters interviewed 8 key questions about single application migration to MicroServices, covering the challenges of traditional monolithic architectures, paving the groundwork for implementing microservices architectures, Transformation principles, databases, middleware , distributed transactions, risk avoidance, and so on.

InfoQ : Why do companies move from monolithic architectures to microservices architectures, as you see in your current observations? What's the biggest problem they're having?

Liu Xiang : Most of the enterprises I serve are traditional enterprises, the code in 1 million lines of projects abound, large and complex projects make development, testing, maintenance, operation is extremely complex, flexibility, scalability, maintainability is also difficult. In addition, the traditional monolithic architecture has encountered the following problems:

1 , the team took over the difficulties

8 years ago, I took over a 1 million-line project that was a nightmare: it took 3 months to read through the code, and every time I changed the code, it was possible to modify a bug with a variety of hidden flaws.

2 , bloated deployment

Single application each time the function or the change of the defect causes the entire application to redeploy, this kind of deployment way has the big influence, the risk is high, decides the deployment frequency is low, causes the two releases to have the massive function or the flaw needs to change, the error probability increases.

3 , limited elasticity and ability to expand

Monomer application as a strong coupling of the whole, can not be scaled according to business functions, only as a whole to expand. This creates a waste of resources and does not have targeted scaling for the characteristics of different business modules, such as compute-intensive services, IO-intensive services.

4 and hinder technological innovation

The team's desire for new technology is self-evident, and team morale will be reduced by continued focus on the technology stack of the boulder application. Organizations in a single-piece architecture typically have a single, team-technical capability that is relatively thin and attractive to the team.

In addition, for the service level, security requirements, business supervision and other dimensions of the need for different services to achieve different governance, migration to the micro-service architecture becomes inevitable.

InfoQ : Micro-services have its inherent advantages, but the infrastructure and team requirements of the enterprise is also relatively high. What do you think you need to prepare before your business is ready to move to a microservices architecture?

Liu Xiang : Before the enterprise migrated to the MicroServices architecture, the 0th principle was to fully understand the business, a large number of enterprises because of historical reasons to understand the business system is a handful of people, trying to turn to the micro-service architecture, even with the best technology, tools, architecture, Team, The end of the fall is painful (causing endless splits and changes).

With a full understanding of the business, I think the migration to microservices also needs to be prepared in the following three dimensions:

1 , repayment of technical debt

Automated testing, continuous integration, and automated deployment are technical debts that must be compensated before a large-scale migration to the microservices architecture. Under the MicroServices architecture, the team manages a large number of services, its complexity and testing difficulty is the geometric level increase, the use of automated testing can help the team to quickly and effectively validate the application, continuous integration and automated Deployment Assurance team faster and easier to modify the code, lack of continuous integration and automated deployment, the transition to the microservices architecture will be extremely painful.

2 , the new architecture design principles

With a microservices architecture, application delivery is highly complex. Architecture design principles need to be from the original monolithic architecture of the focus on function, performance and other dimensions to the MVP (the smallest available products), the design for failure (hug failure, not to prevent failure), wide into the strict (to the request wide into strict, the external response to strict normalization), Ning Flower Machine A point, do not spend one second (automatic and Complex duplication of things to the platform tools to do, so that programmers to do more valuable things, all resources and other design principles of change, the formation of a progressive optimization design style.

3 , Team Change

"Exploring the duality between Product and Organizationalarchitectures" gives a very interesting view that the coupling of the organization is proportional to the modularity of the system. The higher the coupling degree of the organization, the higher the coupling degree of the product is, the lower the coupling degree of the organization is, the lower the coupling degree of the product is developed. The microservices architecture essentially emphasizes loosely coupled architectures, so we need to fine-tune the organization (not change, have a big impact on the organization) before the MicroServices architecture is migrated, and ensure that a single, small team delivers a micro-service, while the small team is the owner of the microservices (in addition to being responsible for testing and operations). This will greatly provide a sense of responsibility for the team, accelerating the autonomy and delivery capabilities of the microservices.

InfoQ : What rules do you think you can follow in the entire architecture transformation process?

Liu Xiang : The principle of micro-service architecture transformation The industry has summed up a lot, including: Based on business split, the adoption of automation culture, de-centralized, service independent deployment, service complete autonomy, isolation failure, progressive split, avoid large-scale transformation of the original code, etc. These principles believe that the focus on the micro-service architecture is relatively clear. Combined with our specific practice, provide some practical micro-service Transformation Experience Summary:

1 , separate database, post-separation service

Whether the data model can be separated completely determines the boundary function of microservices. We've seen too many cases of refactoring and rework directly from service separation;

2 , adopting the "strangling pattern"

For legacy systems that cannot be modified, it is recommended to use the Strangling model: Add new functions outside the legacy system to make microservices, instead of directly modifying the original system, gradually replacing the old system;

3 , establish a unified log specification

Standardize the entire system and not the micro-service log system, the use of standard log format is very convenient for subsequent log aggregation retrieval, convenient for the overall perspective analysis, monitoring, viewing system;

4 , select a mature framework

At the same time do two things that are not controllable (micro-service transformation, the impact of new technology) is doomed to a low probability of success of the project, you should not repeat the invention of the wheel, as far as possible to choose the market mature open Source technology framework for support, such as spring Boot, Spring Cloud, Netflix, WildFly Swarm, Docker, kubernetes and other frameworks;

Of course, there are a lot of detail specifications, such as the front-end separation principle, the use of the global unique serial number principle to achieve full-link transaction tracking, how to service the document management and service test mock.

InfoQ : Does the database have to be adjusted accordingly?

Liu Xiang : This topic is very meaningful, micro-service transformation, the first thing needs to be broken up against the database model, the data model boundary is clear, the service smooth Cheng Zhang easy to draw a line. The principle that we strongly recommend in our practice is that a micro-service corresponds to a library . Of course, with the scale of micro-services, can be targeted to do read and write separation, if the single table data is large, can be divided into tables to solve.

InfoQ : How do I resolve distributed transactional consistency?

Liu Xiang : Under the microservices architecture, complete transactions run across multiple systems, and transactional consistency is a challenging topic. Based on the CAP theory, a choice must be made between availability (avaliablitity) and consistency (consistency). We believe that usability should be chosen under the MicroServices architecture, and then the final consistency of the data will be ensured. In our practice, we summarize three modes: Reliable event mode, service compensation mode and TCC mode.

Reliable Event Mode : A reliable event pattern is an event-driven architecture that, when something important happens, such as updating a business entity, MicroServices publishes an event to the message agent that pushes events to the microservices that subscribe to events, and when the microservices that subscribe to those events accept this event, will be able to complete their own business, may cause more events to be released.

Business Compensation Mode : Compensation mode Use an additional coordination service to coordinate the various work services that need to ensure consistency, and the coordination service invokes the individual work services sequentially, and if a work service invocation fails, all previously completed work services are revoked. Requires that a consistent work service is required to provide compensation operations.

TCC mode : A full TCC business consists of a primary business service and several from the business services, the primary business service initiates and completes the entire business activity, and the TCC mode requires three interface try (responsible for resource checking) from the service, Confirm (true execution of the business), Cancel (Frees resources reserved in the try phase).

Detailed descriptions of the three modes can be found in the micro-classroom articles of colleague Tian Xiangyang (click on the title to view):

· Data consistency assurance under micro-service architecture (I.)

· Data consistency assurance under micro-service Architecture (II.)

· Data consistency assurance under micro-service Architecture (III)

InfoQ : Does the middleware need to be tuned or re-planning many new middleware?

Liu Xiang : For existing middleware, apply Gartner popular word "two-mode", such as MySQL, Redis and other middleware suitable as a micro-service to appear independently; for big Oracle, DB2 database, or products such as queue, Not suitable as a standalone microservices and can work in an integrated way.

MicroServices architectures need to be converged with new middleware platforms, such as IAAS platforms, PAAs platforms, and more. Of course, within the micro-service framework, there are a lot of new middleware products, such as ETCD, Motan, resteasy, elk and so on.

For the use of middleware, we have always maintained a principle: business logic in the service, as far as possible to keep the middleware simple.

InfoQ : How do you think you should avoid risk to ensure a smooth transition throughout the entire transformation process?

Liu Xiang : Micro-service architecture migration is challenging both in business and technology. From the risk aversion level, to give you two points of advice:

1 and attach importance to the construction of Operation platform

Before the implementation of micro-service transformation, it is recommended to set up an operational support platform, the platform to provide at least the micro-service compilation, integration, packaging, deployment, configuration and other work; If you have the ability to recommend a PAAs platform to address the full lifecycle management of microservices from development to operation, while providing heterogeneous environment management, container resource isolation and interoperability, Service scaling drift, service upgrade and fallback, service fuse and downgrade, service registration and discovery. The platform helps developers solve more technical problems, and developers focus on the splitting of business functions.

2 , starting from the pilot, and gradually advancing

For the enterprise's business application classification, first from the external application pilot, after the experience, the core application of the current migration and large-scale transformation.

InfoQ : In combination with your actual combat experience, share what you think are some of the key points in the process of migrating from a monolithic architecture to a micro-service architecture?

Liu Xiang : Combined with our own experience in micro-service, the migration process can be summed up three key points:

1, for the business system, re-comb the concept model + data model, cut off the loose coupling, high cohesion micro-services, to ensure that the project team do the right thing;

2, develop the micro-service development specification (including technical framework, springboot+motan+etcd+resteasy+elasticsearch+docker+kubernetes is our technical structure selection), Ensure that the project team is doing the right thing in accordance with the Harmonized Development Specification (technical framework);

3, micro-service after the split, the biggest challenge comes from operations, monitoring, fault handling, if the team does not have experience in micro-service operation, after the failure can not quickly locate, rapid response, will be subject to greater business pressure, Therefore, the late micro-service operation platform or management platform (the specific function of the first part of question 7) is very important to the team, need to keep up with the design, supporting the operation of micro-service management.

8 key ideas, practices, and experiences from single-unit architecture to MicroServices