Original: Taste of Little Sister (wechat official ID: XjjDog), welcome to share, please reserve the source.

Taking the pulse of the latest technology and popularizing cutting-edge technology with words has always been, and is now, a duty and habit at XJJDog. To grasp the essence of technology from the flowery rhetoric flying all over the place is to avoid being overwhelmed and fooled.

Infrastructure. Each wave is reinventing itself. ServiceMesh is at the forefront of a revolution in the cloud native era, where Istio, with its lofty status and superior performance, is poised to become the standard.

Let’s take a look at what Istio is all about.

1. The middle tier is a masterstroke of infrastructure

In introducing what istio is, let’s begin by describing a problem.

If your company is going to fully embrace SpringCloud microservices, you’ll want to use the Java language. And then some of the older projects, they all go up.

But there are always stubborn projects that cannot be refactored in Java. For example, if you have a project written in C++, the cost of refactoring is very high. So what to do?

1.1 sidecars

It’s an immutable truth in the software industry: If you want to solve a problem between two components quickly and efficiently, add an intermediate layer.

Whether it’s conceptual “mid-stage”, technical “proxy”, or even verbose DDD layering, it can be played this way!

For network requests, Proxy can take over all the traffic, and then transform, analyze and schedule these traffic, so that an ugly service can be covered with a layer of skin, into a beautiful service.

To solve the above problems, we just need to use SpringCloud compatible technology to develop the Proxy, and then do a layer of transformation to convert the request into C++ calls, and we can do a good job. The request to invoke this Proxy will not be followed by C++.

In general, we need to deploy Proxy and C++ services on a single machine, and they will perform better; Of course, now that the container is up and running, it can run on two different Docker instances; Later, k8s came, a Pod can be directly placed in Proxy and C++ container instances, they can communicate with each other through localhost, become a whole.

That’s the concept of sidecar. For those of you who aren’t familiar with this section, check out the previous article, “The Key to ServiceMesh: Sidecar; Driving again.”

Why do we have to talk about agents? Because isTIO’s core component is, in essence, a Proxy in the form of a Sidecar. To request services from the back end, you must go through ISTIO. It takes over all the traffic and divides it according to its properties.

1.2 Proxy Functions

The idea is that simple. But things get complicated when istio is left to do all the messy functions in microservices.

As we all know, microservices introduce more problems than they solve. A microservice is a true microservice when it comes to supporting facilities.

Let’s look at what happens when a request enters the microservice from the periphery.

  • In order for microservers to be found, there needs to be a unified registry, which is essentially a configuration center
  • To track the performance of a request on different running instances, a centralized Tracing system is required
  • The request calls the service on the back end through RPC, first through load balancing, fusing, limiting, retry, failover, etc. Of course, everything is based on the premise of safety
  • A request has more attributes, such as authentication, encryption, authentication, gray scale, etc. If you do every function again, it will be complicated and boring.
  • Supporting CI/CD, etc., speed up the research and development process

The point is, none of these features are useful to business development students. Business students only need to pay attention to their business logic, but at present we mentioned a variety of technical terms and functional components, the current stage of business development can not be avoided at all.

To make matters worse, no matter which of the above components I upgraded, the business would have to reintroduce a new VERSION of the SDK and then scroll through the upgrade. Because they’re called infrastructure because they’re connected.

So we need to make some changes to our deployment model. If all of our applications, instead of providing services directly to the outside world, all forward requests through proxies, it would look like this.

Envoy Proxy is our Proxy Sidecar, and Service A and Service B represent our real micro services. The number of service instances and agents is 1:1.

So all of the traffic we mentioned above can be taken over by an Envoy — just like you could call the Service directly behind it, but since it’s a Proxy, you can just layer on something like Aop and do just about anything!

All magical things can happen in the agency!

1.3 Data Plane and Control Plane

If you’ve ever worked with ServiceMesh before, you’ve probably heard of these two words.

The data plane actually refers to our Proxy collection. It’s a network, but if we unify the concept, it’s called a plane.

So the control plane, is the supporting control management console, as well as the instruction of the management background.

That is, for the most part, the service will run on just the data plane. But to see the framework is not strong, but also to see the control plane is easy to use.

The top half of the diagram is the fabled data plane. After our introduction above, you should be very familiar with it. Istio complicates it by adding a certificate system to control authentication and authorization.

But if you’re a ServiceMesh developer, the job is a lot easier. Your workload is focused entirely on proxy development.

The control plane, if not according to ISTIO rules, is actually dispensable. For example, your log collection can be connected directly through Pod to your ELKB platform telemetry loop, using your company’s original technology architecture.

So said.

If your company is relatively new and you don’t have a complete infrastructure, going directly to ISTIO is great because it does most of the infrastructure components for you.

But if your company’s infrastructure has been developed for years, switching to ISTIO infrastructure is idle! Your best bet is to develop such an agent and funnel traffic to your base components.

Developing such components in C++ or Go, rather than Java, is the best option. Java development Agents tend to consume a lot of memory. Of course, if memory isn’t valuable to you, forget it.

2. Unification is the primary goal of infrastructure

Because the scope of the infrastructure is so large, there are multiple solutions for each technology. MQ, for example, is popular Kafka, RabbitMQ, Pulsar, etc.

For communities, competition and differentiation are principles that promote innovation. But for a company, unifying the infrastructure is the primary goal (those giants say otherwise).

So whether it’s scheduling or traffic blocking, the agent’s responsibilities are only going to get bigger. If the technology is not uniform, the functionality becomes a Cartesian explosion. Istio takes a more mainstream approach, with proxies implemented as envoys, while the network protocols in the middle support mainstream communication protocols such as HTTP/1.1, HTTP/2, gRPC or TCP.

Unity is the value it embodies here.

Pod’s natural ability to tie agents and services together makes K8S the preferred scheduling platform. Of course you have to make a machine agent like NodePort, but there is no essential difference.

Eventually, through the integration (or monopoly) of communities, ISTIO became the framework for accomplishing the whole goal of unification. It took on more and more responsibilities, gradually evolving into the image above.

The top half is still the data plane, but ISTIO has expanded on the control plane.

The control center is further subdivided into Pilot, Mixer, and Citadel, whose respective functions are as follows:

  • Mixer: Performs access control and policy management (limiting traffic, quotas, etc.) for the entire cluster and collects statistics on traffic between services observed by the agent, i.e., telemetry (monitoring, APM, etc.) data.

  • Pilot: Service discovery, traffic management and intelligent routing (AB tests, canary publishing, etc.), and error handling (timeout, retry, fuse) capabilities for Envoy.

  • Citadel: provides authentication and certificate management between services and enables services to be automatically upgraded to TLS.

  • Galley: This component does not directly provide business capabilities to the data plane, but acts as a coordination component to other control planes, which is more thoroughly decoupled and has more and more core functions.

End

We can see that a normal request, after joining ISTIO, all becomes proxy to proxy communication. The proxy proxies both incoming and outgoing traffic, and all traffic passes through it, so it can intercept and analyze any data. With the help of K8S, the service and proxy can communicate with each other via localhost.

For microservices architectures, a request is spread across multiple machines, time, error logs, and so on, and troubleshooting has to rely on components such as APM. Istio is more thorough, you don’t know exactly where the service nodes are scheduled, and the traditional human operation and maintenance approach is broken, relying more on upstream tools.

There are a lot of things you need to know before using IStio, such as virtualization and K8S. It is even better for new companies to skip both and embrace IStio. But if your company already has a very good basic setup tool, and is not compatible with the community, then I’m afraid you have to borrow the concept of proxy.

Xjjdog is a public account that doesn’t allow programmers to get sidetracked. Focus on infrastructure and Linux. Ten years architecture, ten billion daily flow, and you discuss the world of high concurrency, give you a different taste. My personal wechat xjjdog0, welcome to add friends, further communication.