1 introduction
Before introducing Istio, let’s talk about microservices, because Istio is developed on microservices technology architecture. Once you have a grasp of the microservices technology architecture, step back and understand Istio, and you will feel that the technology has evolved along the way.
History goes back and forth, but technology moves forward.
A lot of the content of this article is from the PPT screenshots I shared with many companies. If you are interested, please ask me for them.
2. Evolution of architecture
2.1 Single Architecture
Features:
All functions are integrated in one project
All functions are packaged in a Web package and deployed to the server
3 Deploy applications and databases separately
4 Deploy application clusters and database clusters to improve system performance
Advantages:
Simple architecture, low cost of early development, short cycle. Preferred for small projects.
Disadvantages:
1 All functions are integrated in a project, which is difficult to develop, expand and maintain for large projects
2 System performance Expansion can only be performed by expanding clusters, which is costly
3 Limited technology stack
2.2 Vertical Architecture
Features:
When the number of visits gradually increases, the cost performance of a single application added to the machine becomes less and less, so the application is divided into several unrelated applications to improve efficiency.
Advantages:
1. Simple related structure, low early development cost, short cycle, the first choice for small projects
By vertical splitting, the original monomer does not expand indefinitely
3 Different projects can use different technology stacks
Disadvantages:
1 Integrated with business domain functions in a project, it is difficult to develop, expand, and maintain large projects
2 System performance Expansion can only be performed by expanding clusters, which is costly and has bottlenecks
3 If function calls between monomers are excessive to RPC or HTTP calls between systems, an independent mechanism is required to ensure service discovery
2.3 Microservice architecture
Features:
1. Completely separate the system service layer and extract the service layer into micro-services
2 Microservices follow a single principle
3 RESTful lightweight protocol is used to transmit data between microservices
Advantages:
1 Finer granularity of service separation facilitates resource reuse and improves development efficiency
2. The optimization scheme of each service can be more accurately specified to improve the maintainability of the system
3 Microservice architecture is decentralized and uses lightweight protocols such as RESTful to communicate between services, which is lighter than ESB
4 Suitable for Internet products, faster and more convenient product iteration
Disadvantages:
1 Too many micro-services lead to high service management costs, which is not conducive to system maintenance
2. The technical cost of distributed system development is high (fault tolerance, distributed transaction, etc.), which poses great technical challenge to the team
3. Evolution history of microservice architecture model
The microservice architecture model is also an evolution from simple to complex.
3.1 Framework and Communication
In the early days of microservices architecture, the main technical demands were to find simpler and lighter development frameworks, and different development frameworks meant different communication protocols.
3.2 Runtime support services
With the authoring and communication of the services resolved, it’s time to consider some run-time supporting services. These services are decoupled from the business and belong to the underlying support services, such as gateways, load balancers, service registration and discovery, configuration centers, and so on.
3.3 Service Security
With the communication and infrastructure of the service resolved, the business is basically ready to go. However, such naked services have great security risks. Many sensitive information can be easily obtained without authentication and authorization. Therefore, service security has been added to the model system of micro-services. There are two main types of service security, namely JWT and OAuth2.
3.4 Service Monitoring and Alarm
With communication, support, and security sorted out, the service is happy to work. But just as determining health requires a physical exam, determining the health of an online service requires monitoring, telemetry, and human intervention with an alarm when workload exceeds a threshold. Service monitoring has many dimensions, including system indicator monitoring, service indicator monitoring, service health check, call chain monitoring, log monitoring and so on.
3.5 Service Deployment
The containerization era brings a new idea of operation and maintenance. The original heavy operation and maintenance based on virtual machines and physical machines begins to change to light operation and maintenance based on containers and container choreography, which also brings a change in service deployment mode. Faster, better, and more efficient deployment is a new challenge for the microservices architecture model.
Service deployment requires the introduction of publishing mechanism, mirror governance, container governance, volume management, CI/CD, and so on.
3.6 Underlying Services
When the business scope is more and more wide, no matter how big the company is, it is impossible to solve any technical problems. At this time, it is necessary to introduce some excellent third-party services in the industry as the underlying services to solve specific problems. Sometimes these third-party services may not be a perfect fit for their own architecture, so tailoring is needed. However, these third-party services also form an integral part of the overall microservices architecture model. The common third-party underlying services include distributed message middleware, distributed data access, distributed task scheduling and distributed cache. Underlying services differ from underlying support services in that the former are more in the business problem domain, while the latter are primarily in the general problem domain.
3.7 Service Protection
Just as the most voracious person can’t eat an elephant in one sitting, the most well-written service can’t support unlimited requests. When technical personnel deal with the technical solution of infinite and untimely technical scenarios, they often adopt the strategy of constant response to constant change: set the peak value according to the current service load, and take measures such as fusing and limiting the flow when the peak value exceeds the peak value.
Fusing is shown in the figure below:
The downgrade is shown below:
Current limiting is shown in the figure below:
3.8 Full-link pressure test
In the introduction above, we introduced the dimensions of the microservices architecture model. It could have ended there, but it didn’t feel right, because we were missing a crucial piece, which was testing.
Full-link manometry is one of the tasks that larger technology companies must do. It is essential that the system be able to anticipate flooding when business growth exceeds expectations. After all, it’s better to be proactive than too late. Full-link pressure measurement is a big topic, because what is introduced here is Istio, so it is briefly mentioned here. I will not repeat the PPT details in detail. If you are interested in it, you can ask me for them.
4 Overview of microservice architecture model
The following diagram shows the entire microservices architecture model:
5. Problems brought about by
The introduction of microservices architecture brings many benefits, but also many problems of service governance. The core issues are as follows:
5.1 Service Management Modes Are Inconsistent
Different service governance approaches introduce different middleware with different technical and maintenance standards. Therefore, operations or architects must master the use of each type of middleware, which is often not practical for a technology company with limited human resources.
5.2 Repeat the wheel
Microservice architecture allows multi-language stack and multi-technology stack, but different technology stacks need their own solutions to common technical problems such as communication, support service, service security, service monitoring, fuse/downgrade/current limiting, which is really a waste of cost.
5.3 Lack of standardization in service governance
Because service management lacks standardization, the stand or fall that because this micro service manages relies on the ability of technical personnel individual completely, experience and level, this resembles manual workshop era a bit, implement high grade relies on craftsman entirely. But the absence of standardization is obviously inconsistent with the trajectory of technological development.
6 summarizes
At present, the development of micro-service has become stable and become the mainstream of technology, but at the same time, its situation is becoming more and more awkward, and the problems exposed are becoming more and more acute. Fortunately, the age of the service grid has arrived, and Istio, the leader of the service grid, is steadily entering the history stage and becoming more and more popular. I will continue to take you through Istio with ease.