With all due respect, you may have misunderstood microservices

Liu Chao, chief architect of netease Cloud Computing, has more than 10 years of experience in cloud computing architecture and development, and has accumulated rich experience in micro-servitization and containerization of enterprise-level applications. Liu Chao will be the producer of the topic “Micro-service Practice” at QCon Guangzhou in May this year, and will plan several micro-service-related rich sharing sessions for everyone.

InfoQ recently caught up with Chao Liu to share some of the challenges and common misconceptions of microservices, as well as his assessment of the trend of microservices. Please follow the official account Netease_Cloud for more information on micro services.

Netease Cloud Micro service platform

• Service avalanche: when a service is down, all services on the invocation link are affected.

• A large number of requests are accumulated and fault recovery is slow. That is, a service is slow and stuck, and the entire invocation link times out a lot. It takes a long time for the slow service to recover.

At the infrastructure level, there are other issues:

• It is difficult to allocate server resources, and server models are fragmented. With more services, each team has to apply for servers, with different specifications and requirements, making management very difficult.

• Multiple processes on a server affect each other, and QoS is difficult to ensure. When VMS or physical servers are deployed, multiple processes are placed on the same server, causing serious impact during peak hours.

• The number of test environments increased, and it was difficult to manage and update the environment: each team deployed test environments repeatedly, and manual or scripted deployment was too complex.

To solve these problems, we implemented the following solutions at the application level:

• Through the circuit breaker mechanism, when a service is down, the affected service can be fused in time, and Fallback data is used to ensure that the process can still be carried out when non-critical services are unavailable.

• Asynchronization is implemented through thread pools and message queues, allowing services to fail quickly. When a service is blocked due to slow, the affected service can fail quickly after timeout without affecting the entire invocation link.

At the infrastructure level, we have implemented the following programmes:

• Unify infrastructure, embrace container standards, and address server fragmentation and isolation between services;

• Unified arrangement and flexible platform, embracing Kubernetes standard in 2015, solved the problems of difficult deployment and inconsistent environment;

• Build CI/CD service, abstract multi-level concepts such as product and environment, and realize automatic deployment from code to test to online.

As we supported more and more internal business, we ran into the following problems:

• The selection of micro-service framework is different, the technology cannot be accumulated, the business-oriented customization is serious, and the starting cost is high;

• Traditional monitoring services cannot meet the requirements due to the high complexity of removing obstacles that rely on application operation and maintenance.

• Failure drills vary, and hard coding is ubiquitous.

• API version management chaos, no unified monitoring, governance, no development standards;

• Distributed transactions are supported in different ways and are seriously bound to services.

To solve these problems, we implemented the following solutions:

• The microservice framework is unified with the open source technology stack, which separates the service governance logic, implements it in a non-invasive way, and supports the open source technology stack such as Spring Cloud and Dubbo.

• The link tracing service and log service are connected according to the ID to discover the context of the fault point.

• The fault injection service is introduced on the Agent to conduct unified fault drills.

• Service is exposed through API gateway, API management and testing platform is introduced, and Client SDK is generated automatically.

• Achieve TCC middleware, transaction message queue and other standard middleware.

1. The main work of microservices is service splitting, which mainly considers what granularity of service splitting and how to do it.

2. Microservices is a kind of movement process, you put people behind closed doors for a month, you can fix the architecture, and then we’ll be fine.

3. Microservices are just a technical issue that can be handled by development teams or operations teams.

Microservices is not just about service unbundling, as shown in the figure above, but just one of the twelve essentials of microservices implementation, because after unbundling a service, you face all the problems we encountered above, without the right tools and platform, and the more you break it down, the more disaster it becomes.

Microservice is by no means a moving process, but should be a gradual process. Once implemented, the business system is in a state of continuous update and iteration, as well as in the continuous separation and combination. Therefore, it is not recommended to dismantle it in a very detailed way at the beginning, or to do it all once and for all. Instead, the tools, team and staff required by the twelve key points will be gradually matched to the micro service state along with the gradual dismantling process of several, dozens, dozens and hundreds.

Microservices is not just a technical issue, but involves IT architecture, application architecture, and organizational architecture. Microservices are bound to increase the complexity of development, online, operation and maintenance. If the complexity of a single application is 10, the complexity after the implementation of microservices will be 100. After the corresponding tools and platforms are equipped, the complexity can be reduced to 50, but it is still much more complex than a single application.

So the implementation of micro service has a cost, and only encountered in business level is not no pain points, such as pain to affect income, pain to the competitors left behind, so the service is often a business drivers or executives driving, and the results of the implementation of micro service will inevitably affect the change of organization structure, such as blurred – enterprise operations and development, The establishment of specialized middleware and architect teams, the establishment of data center and business center group, and the independent decision-making of small teams.

Currently, most enterprises are aware of the importance of microservices, but the stages vary from place to place. I divide microservices into three stages:

1. Microservices 1.0, which only uses registered discovery and is developed based on SpringCloud or Dubbo. Most of the traditional enterprises that intend to implement microservices are at this stage, or are transiating from single application to this stage, at the stage of 0.5.

2. Microservices 2.0, which uses service governance strategies such as circuit breaker, traffic limiting and degradation, is equipped with complete micro-service tools and platforms. At present, most Internet enterprises are in this stage. The leader of traditional enterprises, in the process of Internet transformation, is transitioning to this stage, in the stage of 1.5;

3. In Microservices 3.0, Service Mesh takes Service governance as a general component and descends to the platform layer to realize it. The application layer only focuses on business logic, and the platform layer can automatically schedule and adjust parameters according to Service monitoring to realize AIOps and intelligent scheduling. At present a line Internet company is having this aspect attempt.

Later, due to the need of ability reuse and development speed, database and middleware have become the PaaS platform for the deployment of general components, and continuous release has also become the PaaS platform for the deployment of customers’ business, so these two parts are also platform-oriented.

As more and more businesses require service governance, the microservices framework, APM, has become part of the platform.

However, the unification of microservice framework involves multi-language problems and binding with application layer. Neither Spring Cloud nor Dubbo can be completely platformized. Therefore, Service Mesh is needed to isolate the control plane and data plane through sidecar. Traffic interception is implemented in a non-intrusive mode to achieve true governance platformization.

The second is AIOps and intelligent scheduling, which realizes automatic scheduling and parameter adjustment of services through monitoring data and service data collected from massive data centers.

This may seem like a long way off, but it’s not. If you’re interested, you can look it up online. In 2011, Google published surveillance data collected by its own data centers (github.com/google/clus…). And published the paper Machine Learning Applications for Data Center Optimization in 2014, using AI technology to optimize the efficiency of Data Center.

And the domestic first-line Internet companies also published the real data set of 4000 servers in 2018, and are doing similar things with Google.

We’ve observed that as data center machines break the 100,000 mark, efficiency gains become a huge cost savings, and that’s where the focus begins. To achieve this, it often relies on data-driven intelligent scheduling.

In order to support powerful scheduling functions, Google developed Borg and Twitter expanded Mesos, and realized automatic intelligent scheduling by combining these scheduling platforms with machine learning. First-tier Internet companies in China are also making active attempts.

With the microservitization and containerization, the number of services will be very large, thus greatly increasing the difficulty of operation and maintenance. In the past, only technical personnel who can operate and maintain physical machines and virtualization are not enough, but the personnel who can operate and maintain Kubernetes and Docker will be expensive, which greatly increases the labor cost.

Many organizations from the physical machine era, to the virtualization era, to the cloud era, and then to the container era, the size of the operation and maintenance team is getting bigger and bigger, and the salary of each person is getting higher and higher.

Therefore, a privatized container platform that only operates and maintains a small number of nodes in the future is not cost-effective in terms of cost. When a public cloud platform with credibility emerges, the use of public cloud becomes a rational choice to save costs.

Such as amazon, Google and other public cloud platform, there is no problem, the inside of the Google ops engineer is quite expensive, they have the most advanced technology is no problem, but they can through a variety of automation, intelligent technology, even managing global millions of machine, so stand down, it is not a high cost. If you just operate and maintain a container platform with dozens or at most hundreds of nodes, you also need to recruit some people who are so expensive, and ordinary enterprises can’t stand it. Therefore, in the future, either large-scale public cloud platforms or self-built cloud platforms such as those in the telecommunications and financial industry will have super-large-scale scenarios, which will be inevitable when AIOps and intelligent scheduling are used to save costs.

1. The first aspect is the scenario of large-scale micro-service practice based on Dubbo. Dubbo is a micro-service framework with a wide range of applications. Many enterprises are based on Dubbo, and the practice of Dubbo is an unavoidable link in the implementation of micro-services. This topic solves the problem that many technologists encounter when implementing a large number of Dubbo services.

2. The second aspect is the scene of large-scale micro-service practice based on Spring Cloud. Spring Cloud is an emerging micro-service framework in recent years. Many newly implemented micro-services will choose Spring Cloud, but although Spring Cloud has rich components and many options, However, it is also very complex and has a high learning curve. How to improve and adapt to a large number of scenarios is a frequent problem. This topic can provide technical personnel with reference when implementing Spring Cloud microservices.

3. The third aspect is the practice scenario of Service Mesh in high-concurrency scenarios. As mentioned above, Service Mesh is a trend that front-line Internet companies are trying, but this technology is too new and many holes are still being stepped on. This topic can bring the most cutting-edge micro-service technology to the technical personnel. For technical people who want to try Service Mesh.

4. The fourth aspect is the development and future trend of micro service framework in all directions, micro service involves a wide range, technology selection, many did not implement micro service technicians faces so many technical terms, disoriented, stable, will be out of date to be eliminated, choose advanced, be aggressive to qualify on accident, choose the wrong direction of technology, In case the open source does not maintain the big trouble, this topic will explain the development of micro service technology trends and the pros and cons of each direction, for the selection of difficult technical personnel to reference.

Click here to learn about netease Cloud Micro service platform and obtain the solution.

【 recommended 】 Enterprise project development — Cookie (1) 【 Recommended 】 Front-end template technology aspects (2)