This article will take you through a systematic understanding of the key concepts and selection guidelines for enterprise-level microservice governance and development, hoping to provide inspiration for your enterprise-level modern application construction.
Microservices are an inevitable choice under the trend of application modernization
With the continuous development of the digital economy, enterprises are faced with more diverse and agile IT requirements in the new era.
· Changes in user behavior: user access to business applications is unpredictable, sudden access increases, and there are uncontrollable business peak periods such as temporary hot events or promotional periods.
· Changes in business models: All business access is through Internet channels, including the Web, mobile apps, WeChat applets, etc.
· Changes in business system development: Applications are no longer planned for half a year or a year in the past. Demand changes at any time, and iterations every two weeks have become the norm. Business applications have short lead times and high quality requirements.
· Changes in the operation and maintenance model: 24/7 on-duty, online upgrade and quick response are required. Different teams, especially outsourcing teams, use different technology stacks, which cannot be managed and controlled uniformly.
Therefore, evaluating whether an enterprise needs to adopt a microservice architecture often examines these five key conditions: data volume and business complexity, team size, response to changes in business traffic, whether sufficient fault tolerance is required, and functional repetition and error costs.
Under the increasingly fierce digital competition, enterprises must embrace market changes faster, respond to new user needs at any time, and launch products to the market faster than competitors.
Microservices, as an important starting point for accelerating enterprises to improve their agile innovation capabilities, can help enterprises quickly implement independent update and deployment of applications, and quickly respond to market changes. It has gradually become an inevitable choice for enterprises to accelerate application modernization.
How to choose a microservice architecture?
· Dubbo
Dubbo is a relatively early microservice architecture, which enables applications to realize the output and input functions of services through high-performance RPC, and seamlessly integrates with the Spring framework.
The advantage is that RPC long connection + NIO has higher performance; but the limitations of the protocol will limit the ecological development and compatibility.
· Spring Cloud
Spring Cloud is a set of frameworks for implementing microservices based on Spring Boot. It provides components such as configuration management, service discovery, circuit breakers, intelligent routing, micro-agents, and control buses required for microservice development. Spring Cloud contains a lot of sub-frameworks. Among them, Spring Cloud Netflix is one of the frameworks. It was developed by Netflix and later merged into the Spring Cloud family. The main modules it provides include: service discovery, circuit breaker and monitoring, intelligent routing , client load balancing, etc.
Spring Cloud has a more mature Spring community ecology and more mature enterprise application cases; but there are also certain deficiencies, such as cross-language platform issues, and microservice governance is more intrusive to code.
· To that
Istio is a relatively popular implementation solution in the current Service Mesh form. It can be deeply integrated with K8s to realize service governance faster and more conveniently. Istio provides an easy way to create a network of services that provides load balancing, authentication between services, monitoring, etc., without requiring any changes to the service code. By deploying a dedicated sidecar proxy service in the entire environment, all network communications between microservices are intercepted. The entire configuration and management are done through the Istio control panel.
As a new generation of microservice architecture, its microservice governance and development are more thoroughly decoupled and adapt to a wider range of scenarios. Many enterprises are gradually transitioning from Spring Cloud to Service Mesh; but it is precisely because the technology is relatively new that enterprises develop their own A certain learning cost is required, breaking the barriers of traditional IT operation and maintenance/development, and considering the introduction of professional technology vendors can perfectly solve this problem.
The above figure shows the basic operating principle of Istio:
1. When the user submits a new configuration to Kubernetes, the webhook registered in kubernetes by Galley will be triggered first, and the webhook will check whether the configuration is legal, as shown in step 1 in the figure.
2. If the configuration fails to pass the verification, kubernetes will reject the configuration submitted by the user and give a corresponding error message. Step 2 as shown in the figure.
3. When the configuration passes the verification, galley gets the configuration change information through the notification mechanism of kubernetes
4. Galley converts the changed configuration/service information into MCP format and pushes it to the pilot through the MCP protocol, as shown in step 4.
5. In the last step, the pilot pushes the changed configuration to the data plane through the xDS protocol.
The above is the current common microservice architecture, so what should the enterprise do when it is actually transformed? we suggest:
· Different types of applications can evolve to modern applications through microservice capabilities.
Need to provide a stable transformation path for traditional applications
Need to provide a cloud-native transformation path for Spring Cloud applications that does not require large-scale adaptation.
How to design microservice architecture?
First of all, from the definition of microservices, microservices are independent small service units that cooperate together , which can be called synchronously and asynchronously, or independently split, independently deployed, and independently upgraded. Back-end middleware, storage resources, databases, etc. are also independent , the best practice is that each microservice has its own database, which truly realizes the decoupling of microservice applications.
Next, let’s look at Conway’s law , which is a necessary basic theory of microservices and a major principle that enterprises need to follow in microservices :
Organizational form is equivalent to system design. Organizations that design systems produce designs that equate to communication structures within and between organizations.
The first law: Communication dictates design (organizational communication will be expressed through system design).
Communication between people is very complicated, and one person's communication energy is limited, so when the problem is too complicated and needs to be solved by many people, we need to split the organization to achieve communication efficiency management. Have frequent, fine-grained communication within the team. For the outside of the team, define interfaces and contracts, and only conduct coarse-grained communication. This can reduce communication costs, and also conform to the principle of high cohesion and low coupling.
The second law: There is never enough time to do something right, but there is always enough time to do it over (no matter how much time you have, one thing cannot be done perfectly, but there is always time to finish one thing).
Complex systems need to be continuously optimized in a fault-tolerant and flexible manner. Don't expect a large and comprehensive design or architecture. Good architectures and designs are iterated slowly. Therefore, enterprises need to embrace change, solve the current situation, and complete small goals first.
The third law: There is a homomorphism from the linear graph of a system to the linear graph of its design organization (there is a potential heterogeneity and homomorphism between the linear system and the linear organizational structure).
What kind of system you want, what kind of team you build, and vice versa.
The fourth law: The structures of large systems tend to disintegrate during development, qualitatively more so than with small systems (large system organizations are always more inclined to disintegrate than small systems).
A large organization will always be split into small teams (2 pizza teams) due to communication costs/management issues.
Specifically, enterprises can follow the following standards when transforming the microservice architecture:
· A system composed of distributed services.
• Divide the organization by business rather than technology.
· Make a living product rather than a project.
· Decentralization.
Automated operation and maintenance (DevOps).
· Fault tolerance.
• Rapid evolution.
At the same time, according to the company's own organizational structure and business conditions, targeted planning and design are carried out.
If you have requirements for enterprise-level microservice transformation, please contact us to explore the best practices of application modernization together.