ServiceMesh(2)

The previous article introduced “What problem does ServiceMesh Solve?” As microservices architecture becomes more and more complex, it is necessary to decouple “business services” and “infrastructure” to split a microservice process in two:

  • A process implements the business logic, BIZ, the white square in the image above

  • A process to realize the underlying technology system, proxy, namely the blue box above, load balancing, monitoring and alarm, service discovery and governance, call chain… And a lot of infrastructure are put into this layer

After this decoupling:

  • Biz only communicates locally with local proxies, whether invoking or providing a service

  • All cross-network communication is carried out between proxies

We can’t talk about ServiceMesh without mentioning Istio, which is currently the most popular practice for ServiceMesh. Today, let’s talk about what Istio does.

Voice-over: Don’t be behind The Times.

What is Istio?

Istio is a productization of ServiceMesh, and some of its key descriptions are:

  • It helps build connections between microservices, helps the r&d team better manage and monitor microservices, and makes the system architecture more secure

Voice-over:
Istio helps you to connect, secure, control, and observe microservices

  • Helps decouple microservices hierarchies so that the decoupled Proxy layer can be more focused on providing infrastructure capabilities, such as:

(1) Service discovery;

(2) Load balancing;

(3) Failure recovery;

(4) Service metrics;

(5) Service monitoring;

(6) A/B testing;

(7) Canary Rollouts;

(8) Rate limiting;

(9) Access Control

(10) End-to-end authentication;

Voice-over:
I admire you, but SM can also provide more basic service functions.

  • Enabling both the business engineering team and the infrastructure team to work more efficiently, each to focus on their own work, and to better empower each other

Voice-over:
We’re still talking about decoupling.

What does Istio website boast about itself?

Voice-over:
Another way to ask this question is “Why do people use Istio?”

Istio is awesome. If you want to implement ServiceMesh, you have to use Istio because:

  • By deploying a Sidecar Proxy on an existing server, the application can implement the N basic functions described above with little or no code changes

Voice-over:
Do you believe it?

  • You can control the background, simply change the configuration, click the button, you can manage and view the above N basic functions

  • Istio added the following features in this section:

(1) Load balancing supports multiple protocols, such as HTTP, gRPC, WebSocket and TCP;

(2) Fine-grained flow control of traffic through routing, retry and failover;

(3) Through the pluggable policy layer and configurable API, can support traffic access control, speed limit, quota management;

(4) Automatic measurement, log collection, call tracking;

(5) Service-to-service identity authentication;

What are the core features of Istio?

Istio highlights five key features it offers:

  • Flow control (traffic management)

Voice-over: Circuit breaker
(Circuit Breakers), timeout, retry, high availability, multiple routing rules, AB testing, gray publishing, traffic distribution by percentage, etc.

  • Safety (security)

Voice-over:
Encryption, identity authentication, service-to-service permission control, container-to-container permission control in K8S, etc.

  • Observed (observability)

Voice-over:
Tracking, monitoring, data collection, through the control background to fully understand the upstream and downstream traffic, service link, service operation, system performance, domestic micro-service architecture system, this part is relatively lacking.

  • Platform Support

Voice-over:
K8s, physical machines, and their own virtual machines are fine.

  • Integration and Customization

Voice-over:
You can customize the extended functions.

Istio’s boast and features are very attractive to many foreign companies that provide Intranet services through RESTful services, but may not achieve a good wooing effect compared to the domestic microservices architecture:

(1) The domestic RPC framework is basically TCP, so multi-protocol support is not necessarily necessary;

(2) In RPC framework, routing, retry, failover, load balancing and high availability are the most basic;

(3) Flow control, speed limit and quota management are the content of service governance, which is the icing on the cake in the initial stage of micro-service architecture;

(4) Automatic measurement, data collection at system entrance and exit, call tracking, observable and controllable background are indeed the most attractive;

(5) Service-to-service identity authentication. Microservices are basically Intranet access, which is just icing on the cake at the initial stage of the architecture.

Another lace, why is a proxy called a Sidecar proxy?

It is easy to understand from the picture above, biz and proxy go hand in hand, just like a motorcycle (motor) and a car (sidecar). In the future, sidecar and proxy will refer to the proxy process that provides the basic capabilities after the microservice process is decoupled into two processes.

Istio is awesome, but what about its core architecture?

Listen to the breakdown next time.

Voice-over: It’s too late to go to bed today.