SM, the first

ServiceMesh has been very popular in the past two years. It is known as the next generation of micro-service architecture. In the next two months, I will systematically write about it, hoping to give you a preliminary understanding of the latest architecture technology.

_ Voiceover: _ My style of writing, “why” is often more important than “how”.

Internet companies often use microservices layered architecture.

Voice-over:Why servitization is necessary? See”What problems does servitization solve?__ “.

With the continuous increase of data volume, throughput and business complexity, the number of services will be more and more, and the layers will be more and more detailed. In addition to the data service layer, there will also be a business service layer, front-end and back-end separation and other hierarchical structures.

Voice-over:For details of layering, please refer toEvolution of the Layered Architecture of the Internet”.

The architecture naturally evolves as the main contradictions are constantly discovered, removed and resolved. What are the potential major contradictions of the microservice architecture?

The introduction of microservice architecture generally introduces an RPC framework to complete the whole RPC call process.

As shown in pink, RPC is divided into:

  • Rpc-client, which is embedded in the caller process

  • Rpc-server is the foundation of the service process

Voice-over:“Inseparable from the micro-service architecture, inseparable from the DETAILS of RPC”.

Not only microservices, MQ is a similar architecture:

MQ is divided into:

  • MQ-send-client

  • MQ-server

  • MQ-recv-client

Voice-over:“MQ, the Internet architecture decoupling wizard”.

The framework is just the first step, and more and more RPC and microservice-related features will be added.

** Example: ** Load balancing

If you want to extend multiple load balancing schemes, for example:

  • polling

  • random

  • modulus

  • Consistency hashing

The RPC-client needs to be upgraded.

** Example: ** Data collection

To collect RPC interface processing time for unified monitoring and alarm, you need to upgrade the RPC-client.

Voice-over, processing time is divided into:

  • Client perspective processing time

  • Server perspective processing time

If the latter is to be collected, the RPC-server also needs to modify and report.

** Also for example: ** service discovery

A new instance of the service notifies the configuration center. The configuration center notifies the registered RPC-Client to send traffic to the newly started service instance and quickly completes capacity expansion.

** for example: ** calls chain trace

To perform full-link call chain tracing, both rPC-client and RPC-server need to be upgraded.

The following features:

  • Load balancing

  • The data collection

  • Service discovery

  • Call chain trace

  • …

In fact, they are not business functions, so Internet companies generally have a technical department similar to the “architecture Department” to develop and upgrade related functions, while the technical department of the business line directly uses relevant frameworks, tools and platforms to enjoy the convenience brought by various “black technology”.

Perfect!!

Ideal is full, reality is very skinny, because:

  • Rpc-client, which is embedded in the caller process

  • Rpc-server is the foundation of the service process

The following problems are often encountered:

  • Business technology teams still need to take the time to learn and use the infrastructure and tools, rather than focus on the business and the product

  • M versions must be maintained for the client and N versions for the server. Compatibility tests must be performed for m x N versions

  • If you want to support different languages, you tend to develop c-client, Python-Client, Go-Client, java-Client multi-language versions

  • Every time the “black technology” upgrade, it needs to promote the upstream and downstream upgrade, this cycle is often quarterly, half a year, or even longer, the overall efficiency is very low

Brother, how long does it take for your company to promote a new technology product?

Is there a way around these coupling, these universal pain points?

One idea is to decouple the service into two processes.

  • A process implements the business logic (either the caller or the service provider), biz, the white square above

  • One process implements the underlying technology architecture, Proxy, the blue square above

_ Voiceover: _ Load balancing, alarm monitoring, service discovery and governance, call chain… And a lot of infrastructure are put into this layer.

  • Biz and Proxy are born and die together, and each other is deployed locally, as shown in the dotted box above

  • Local communication between BIZ and proxy is the black arrow in the figure above

  • All communications between BIZ are completed through proxies, and only remote connections exist between proxies, as shown in the red arrow in the figure above

In this way, “business to business, technology to technology” is realized and fully decoupled. If all nodes are decoupled, the whole architecture will evolve into:

  • Green for biz

  • Blue for the proxy

The entire Service cluster becomes a grid. This is where the Service Mesh comes from.

Architecture evolution, endless, many pain points, natural layer decoupling. I hope you have a good experience and we will talk about the design and architecture details of SM later.

The idea is more important than the conclusion.

The architect’s Path– Share technical ideas

Related articles:

What problems does servitization Solve?

Evolution of Layered Internet Architecture

“Inseparable microservice Architecture, Inseparable RPC Details”

MQ, The Decoupling Wizard for Internet Architecture

Research:

How long is the cycle for your company to promote a “underlying technology”? Will the business side cooperate with the upgrade?

This article uses the article synchronization assistant to synchronize