1 introduction
The previous chapter introduced Istio’s past life, the evolution of the microservices architecture model, and the problems and embarrassments that microservices face today. Here we review.
Problems encountered in microservice governance at present:
Different service governance modes: Different service governance modes 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.
Duplicate wheels: Microservices 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 services, service security, service monitoring, fuses/downgrades/current limiting, which is a waste of cost.
Lack of standardization of service governance: Due to the lack of standardization of service governance, the quality of micro-service governance completely depends on the ability, experience and level of technical personnel, which is a bit like the era of manual workshop, the high quality of utensils completely depends on craftsmen. But the absence of standardization is obviously inconsistent with the trajectory of technological development.
In order to solve the pain points in the microservice governance mentioned above, the common appeal is whether there can be such a platform, which can be inserted into the existing distributed microservice architecture without invasion, transparency and user perception. At the same time, it can solve some common problems that communication must consider (service discovery, load balancing, timeout retry, fusing/limiting, monitoring, access control, authentication and authorization, etc.), and unify the solution of these problems to the platform layer. And no longer rely on the introduction of third-party middleware (Zookeeper, Nginx, Sentinal, Hystrix, Pinpoint/Zipkin, Spring Security), and all the maintenance methods unified and standardized.
So the service grid came into being, Istio came into being, and it all came naturally.
The Old Testament — Genesis:
In the beginning, God created heaven and earth. The earth was without form and void, and darkness was over the face of the deep, and the Spirit of God was moving upon the waters. And God said, let there be light. So, there is light. God separated light from darkness, and he called the light day and the darkness night. Night passed, and morning came, the first day.
And God said, Let there be a firmament between the waters, and let it divide the waters from the waters. And he made the firmament to divide the waters from the waters. He called the firmament the sky. Night passed, and morning came, the next day.
.
So what is a service grid? What is Istio?
2 What Is Service Mesh?
Here’s how Istio describes the service grid:
The term service mesh is used to describe the network of microservices that make up such applications and the interactions between them. As a service mesh grows in size and complexity, it can become harder to understand and manage. Its requirements can include discovery, load balancing, failure recovery, metrics, and monitoring. A service mesh also often has more complex operational requirements, like A/B testing, canary rollouts, rate limiting, access control, and end-to-end authentication.
Personal translation:
A service grid is a specification that governs a network of microservices that can communicate with each other. As microservices grow, service grids become more complex and difficult to understand. In addition to service discovery, load balancing, failure recovery, metrics collection, and monitoring, service grid governance should have more complex operational requirements, such as A/B testing, Canary publishing, traffic limiting, access control, and end-to-end authentication.
3 what is Istio
The service grid was introduced above, and Istio is introduced again, again using Istio’s definition:
Cloud platforms provide a wealth of benefits for the organizations that use them. However, there’s no denying that adopting the cloud can put strains on DevOps teams. Developers must use microservices to architect for portability, meanwhile operators are managing extremely large hybrid and multi-cloud deployments. Istio lets you connect, secure, control, and observe services.
At a high level, Istio helps reduce the complexity of these deployments, and eases the strain on your development teams. It is a completely open source service mesh that layers transparently onto existing distributed applications. It is also a platform, including APIs that let it integrate into any logging platform, or telemetry or policy system. Istio’s diverse feature set lets you successfully, and efficiently, run a distributed microservice architecture, and provides a uniform way to secure, connect, and monitor microservices.
Personally feel the introduction is very wordy, I suggest you also don’t look, I give you a simple list of key points can:
Istio is a concrete solution to Service Mesh. She is like a beautiful creature, who can not only meet all the harsh requirements of the service grid, but also thoughtfully prepare a set of standardized and normalized luxurious international services for you, waiting for your arrival. More praiseworthy is, with so many excellent qualities of her, or even free! Great not great!
4 Why Istio
Here are some of your reasons for choosing Istio:
1 Automatic load balancer for HTTP, gRPC, WebSocket, and TCP network traffic
2 Fine-grained control of traffic behavior is implemented through various routing rules, retry, failover, and fault injection mechanisms
3 Use the pluggable policy layer (associated with filters) and apis to control access, traffic, and resource quotas
4 Track, record, and measure all network traffic at the cluster entrance, within the cluster, and at the cluster egress
5 Ensure the security of communication between services
5 IsTIO core features
Istio’s officially touted features are traffic Management, Secure, polices, and observability. Personally, this statement sounds awkward and not colloquial.
5.1 traffic management
This is easy to understand, the essence is the management of network traffic. Such as the morning and evening peak traffic restrictions, and traffic police in traffic accidents to divert new roads, these are doing flow control and routing.
In fact, traffic management is not just the emergence of service grid. Traffic control, such as load balancing, circuit breaking, flow limiting, degradation, etc. was already existed in the early micro-service era. However, the implementation of these functions depended on middleware (such as Nginx and Hystrix) in the early service grid era. These functions are all rolled out to the base platform Istio.
Flow control for Istio is implemented mainly through the Envoy component. As for the technical details, I will tell you specifically later.
5.2 secure
When it comes to Istio’s secure, there is a scope. Secure here is not borderless, it mainly refers to the communication between microservices, namely pod to POD, service to service level communication Secure. Istio is known to be the product of a threesome between Google, IBM, and Lyft. Istio’s Secure is based on Google’s ALTS (Application Layer Transport Security) technology, which validates communication between Google services and ensures the security of data in transit, namely, application-layer service-to-service communication. These functions were benchmarked earlier in the microservices era by technical specifications such as JWT and OAUTH2.
Istio Secure features ACLS (access control), authentication (verification of who you are), and authorization (authorization of what you are allowed to do).
Istio Secure is implemented through the Citadel component. As for the technical details, I will tell you specifically later.
5.3 policies
Istio Policies has the following responsibilities:
- Dynamically limits the network rate of service communication
- Restrict access to services and set black and white lists
- Rewriting or redirecting network header information
In addition, Istio allows you to add custom policies, which are integrated with Istio through the policy Adapter provided by Istio.
Don’t confuse policies with Secure. Policies are more about human intervention, and secure is about security.
Istio Policies functionality is implemented through mixer components. As for the technical details, I will tell you specifically later.
5.4 observability
Observability is a feature that provides you with multiple tools to monitor, track, and measure traffic at cluster entrances, within clusters, and at cluster exits. The monitoring method in the early era of micro services is Agent or middleware, such as Zabbix, Pinpoint, Zipkin and so on.
The Istio Observability function is realized through the Mixer component. As usual, I’ll fill you in on the technical details later.
6 Multi-platform support
Istio supports multiple platforms, such as K8S, Consul, Mesos, and standalone virtual machines.
I’ll actually show you later that all you have to do is wait and scream.
Since then, the author will take you through the introduction of Istio easily. Please look forward to more exciting things in the future.