Guided reading
This article is the second article in the Boyun microservice transformation series.
In the previous article, we talked about the digital transformation of enterprises ( review in detail: the troubles of digital transformation of rural commercial banks ). Usually, the use of two technologies represents the practice of digital transformation, one is container technology and the other is microservice technology. The construction and use of container technology are operations and maintenance, so it is easier to get started and build quickly. However, the microservice technology is different. The starting point of the microservice architecture is research and development, but the governance is in the operation and maintenance. The feedback and improvement of the architecture must return to the research and development (of course, this is under the traditional enterprise management mode ), so traditional enterprises are in the microservices. During service construction, there will be many problems and misunderstandings related to microservices.
In this article, we will sort out the common misunderstandings of microservice transformation, and share some suggestions and ideas on how to avoid these misunderstandings .
Usually, the digital transformation of an enterprise and the transformation of the system into microservices are easily discussed together. This argument means that putting microservices at a system level has become the task of a department or a team. This is actually the biggest misunderstanding of an enterprise just starting to do microservice transformation.
The microservice transformation is an enterprise-level transformation project, and the specific implementation is the system transformation. If only focusing on the microservice transformation of the system, it will inevitably be "guarded in one corner and left behind". In fact, many misunderstandings in the transformation of enterprise microservices are generated in this way.
01 Misunderstandings of Microservice Splitting
Boyun has always provided consulting services for microservice splitting for enterprises, so it often receives projects on microservice splitting. Some customers usually only need to consult, only need the methodology, and only need to split the services of a single system. In fact, this method has entered the misunderstanding of microservice construction . For example, we encountered a microservice transformation project of a large enterprise before, which involved the transformation and construction of microservices of nearly 100 business systems. Faced with such a large-scale microservice construction, the customer's idea is very simple, and the overall transformation plan is divided into three steps:
Step 1: Find a company that is specialized in microservice splitting, help with the splitting of the first system, and learn the essence of microservice splitting.
Step 2: With the help of a consulting company, split 20 or 30 business systems by yourself as a training exercise.
Step 3: Get rid of the help of the consulting firm and split the rest of the system.
Clearly this is split for split's sake. This kind of construction is equivalent to replacing the monolithic application system with the application of the microservice system equally, resulting in the disappearance of the advantages of the monolithic application, and the advantages of the microservices are not reflected. It is foreseeable that there will be a lot of trouble if you continue to build like this:
-
The business system has changed from nearly 100 to nearly 1,000, completely subverting the original management model. In the past, only monitoring operation and maintenance at the resource level and network level was required, but the observation at the current service level is simply helpless.
-
If only a single system is considered for splitting, the consumption brought by microservices will increase . The splitting of microservices splits a running program into more than a dozen, and it also depends on necessary components, such as registration center, configuration center, and gateway. Of course, each of them needs to consider high availability, so in terms of resource consumption, it will increase The consumption is more than doubled. In this way, the microservice transformation of the entire enterprise may require one more computer room to be transformed.
-
Just mentioned monitoring operation and maintenance, in fact, there are more problems at the operation and maintenance level . Hundreds of systems, nearly a thousand services, coupled with the distributed deployment method, there will be thousands of deployment and upgrade iterations of running programs, which must not be underestimated.
-
Every transformation, construction, or change will be asked a question of income, and a lot of manpower, material resources, and financial resources will be invested. What we want to see is the return, and the split in this way will only be invested .
The transformation of microservices, or the construction of microservices, definitely does not mean the splitting of microservices. The splitting of microservices is only for a certain system, or several systems, and is closely related to architects and R&D personnel. The construction of microservices is actually aimed at the management, operation and maintenance of the entire enterprise, and is related to the R&D and operation and maintenance teams of all microservice systems. Therefore, when enterprises are transforming into microservices, we should grasp the advantages of microservices, give full play to their strengths, and make up for their shortcomings.
Do not build microservices into batches of microservices. This is the first misunderstanding to pay attention to.
02 Misunderstandings of Microservice Construction
When it comes to this, it seems that we should say: "Don't build microservices for microservices", but in fact, it is not a problem to build microservices for microservices. Because the popularity of cloud native concepts and technologies is in full swing, it is imperative to be familiar with related technologies. Row.
Many companies have seen the prospect of microservices, and have begun to build some microservice governance platforms or microservice operation observation platforms in architecture, R&D and other departments, but there are usually many misunderstandings in such experimental projects.
Frequently asked questions: What problems are microservices used to solve, or what benefits can they bring? Therefore, enterprises look for points that can be optimized from various aspects, such as performance optimization, resource saving, operation and maintenance costs, and management difficulties, but after this circle, it is found that all the benefits are negative growth. Performance increases performance consumption due to the addition of detection probes; resources increase resource consumption due to the addition of many governance components; O&M and management increase exponentially. Therefore, some enterprises, after building the first phase of the microservice platform, think that microservices have no results when they move in or even do not move into a microservice system, and they have been interrupted since then.
In addition, when enterprises try microservices, they usually split a business system that is not very critical to test whether microservices are really as popular and useful as the Internet. However, after trying to microservice this very uncritical business system, enterprises will easily draw some " conclusions ":
The distribution of microservices seems to be nothing special, but brings various problems of distribution.
· The current limiting fuse of microservices is generally not used, and it may affect normal business if it is used.
The observation of microservices is useless. If there is no problem, usually no one is watching.
Not only the above two misunderstandings, we have also encountered many forward-looking customers when working on microservice projects, but the platform built according to the customer's requirements does not seem to be very practical. After waiting for two years, the customer found that it was still necessary to build micro-services, so he summed up the previous experience and felt that it still needed a large factory to build it, so he had to spend several times the money to find a large factory to do it, but in fact, it may be possible to build it again. Encountered the same problem before, but " wasted the people and hurt the money ". In fact, the main reason is that the fundamentals of microservices are not grasped.
The fundamental problem solved by microservices is actually a series of problems caused by quantitative changes in the operation of business systems. Quantitative changes cause qualitative changes, which are finally solved through the architecture of microservices. If the business traffic is not enough, the current limit and fuse will not be used; if there are not many application services, there is no need for unified management and operation observation; if the service changes are not frequent, then there is no need for continuous release and grayscale release. Wait.
The advantages of microservices are completely incapable of exerting their advantages in a single system with no business volume. On the contrary, the advantages of monolithic applications are more obvious. This is also the biggest misunderstanding in the construction of microservices.
03 Misunderstandings of Microservice Governance Platform
When we talk about microservices, many people's first impression is to split, one is split into multiple, this is microservices. Then microservice governance, or microservice operating platform, is used to solve the problems caused by the splitting of microservices into multiple ones.
Specific issues include communication mutual visits, traffic assurance, relational networks, running status, distributed transactions, performance observation, fault location, grayscale release, etc. Many solutions are provided by open source technologies, such as microservice frameworks and some open source components of APM.
So is a microservice governance platform a union of open source components? In microservice governance, open source components are:
-
Microservice framework (not actually a component): In terms of governance, it mainly provides communication and load balancing of microservices, such as SpringCloud and Dubbo;
-
Registration Center: Provides service registration discovery mechanism, such as Nacos, Consul, etc.
-
Service traffic limit: usually limited flow, circuit breaker, downgrade and other functions, such as the use of Hystrix components.
-
Configuration Center: Provides unified configuration management, especially the unified change of service configuration under distributed services, such as Apollo.
-
Service observation: It is mainly about API dimension and service dimension performance monitoring, relationship topology between services, link tracking, log tracking and other functions. Skywalking is currently the most used.
Of course, there are also components such as gateways, distributed task scheduling, and distributed transactions, which are all dependent on the operation of microservices.
Can the combination of these components achieve the governance of microservices? In fact, the microservice governance platform is mainly about management. The management of systems and applications from a business perspective is the greatest value of the governance platform . The registration center provides a full amount of service information, and the configuration center also has a full amount of service configuration, but they are all technically dependent tools, not management tools.
We just mentioned that the management difficulties caused by the quantitative change of microservices cannot be solved in all open source tools. Whether it is a service list, service configuration, or service topology, what we want is not functional realization from a technical perspective, but management observations from a business perspective . Open source tools are not governance. If a project is approved, don’t step on this pit.
To sum up, all the misunderstandings of microservice transformation are actually caused by insufficient understanding of microservices and unclear planning of microservices. So what aspects should the microservice construction start from to be the correct construction direction, in order to ensure continuous progress, and to avoid pitfalls and detours? We will share the correct construction ideas for microservice transformation in future articles, so stay tuned.