Shulou(Shulou.com)05/31 Report--

This article mainly explains "Rainbow built-in ServiceMesh microservice architecture method", the explanation content in the article is simple and clear, easy to learn and understand, please follow the idea of Xiaobian slowly in-depth, together to study and learn "Rainbow built-in ServiceMesh microservice architecture method"!

ServiceMesh

The general literal interpretation is "service grid," which is the dynamic linker of microservices, the most popular distributed system architecture nowadays, at the dedicated infrastructure layer of service-to-service communication, which provides lightweight and reliable delivery of communication between services independent of applications.

If it is simply described, it can be compared to TCP/IP between applications or microservices, responsible for network calls, current limiting, fusing and monitoring between services, and the same use of ServiceMesh does not require relationships between services. Things that were originally implemented through applications or other frameworks, such as Spring Cloud architecture, are now handed over to ServiceMesh.

The emergence of ServiceMesh is mainly due to the development of application virtualization technology, such as Kubernetes, Rainbond and other projects, which greatly reduces the complexity of application deployment and operation and maintenance.

Microservices Architecture Comparison

Why use ServiceMesh

ServiceMesh does not bring us new features, it is used to solve problems that have been solved by other tools, but this is an automated management of complex manual operations in the Cloud native environment.

Under the traditional MVC three-tier Web application architecture, the communication between services is not complicated and can be managed by themselves within the application. However, in the case of today's complex large-scale websites, single applications are decomposed into numerous microservices, and the dependencies and communication between services are very complicated."Fat client" libraries such as Finagle developed by Twitter, Hystrix developed by Netflix and Stubby developed by Google appear. These are the early ServiceMesh. However, they are all suitable for specific environments and specific development languages, and cannot be supported as platform-level ServiceMesh.

Under Cloud Native architecture, the use of containers gives more feasibility to heterogeneous applications. Kubernetes enhances the horizontal scaling ability of applications. Users can quickly arrange applications with complex environments and complex dependencies. At the same time, developers do not have to worry too much about application monitoring, scalability, service discovery, Load Balancer and distributed tracking. These cumbersome things focus on program development, giving developers more creativity. If you are in the following scenarios, it is recommended to choose the ServiceMesh architecture:

1. Transition from legacy systems to microservices architecture

2. Business systems are developed in multiple development languages

ServiceMesh has advantages over other microservice architectures Maximum transparency

ServiceMesh controls the invocation relationship between services and the governance policy of services through the global control layer. For the service itself, it is only necessary to consider the dependent communication of upstream services from the stand-alone dimension, using simple communication protocols such as HTTP, gRPC, etc. Mesh layer transparently detects upstream targets, retries/timeouts, monitors, tracks. Endow standalone services with distributed system capabilities.

Low learning costs

In the past, we had to design and build a complete microservice architecture, such as SpringCloud,Dubbo, etc., which inevitably required changing our traditional programming ideas and learning complex architecture frameworks, such as SpringCloud, which contains more than 10 components of various types, and basically has no direct relationship with the service business itself. This is a high bar for most business developers. But with the ServiceMesh architecture, developers have little to learn about business-independent framework techniques due to its maximum transparency. This greatly reduces the cost of learning.

Flexible architecture

For different team compositions, there may be members with different development languages, or there may be mature implemented business systems. If you move to a microservices architecture to support a larger number of users, if you use Spring Cloud architecture, you will inevitably have to refactor or even rewrite the system. Facing reality and the future, we need to gradually implement microservice architecture, using the right development language to develop the right service, and even integrating multiple lightweight architecture patterns, such as Dubbo,SpringBoot and LNMP architecture.

ServiceMesh Architecture Performance

It has been suggested that adding two layers of agents between services will have a greater impact on performance. For performance issues, we should look at the overall situation and analyze it from the following aspects:

The problem of increasing agent response performance exists in all microservices architectures.

The proxy layer of ServiceMesh is usually implemented by lightweight and efficient proxy, and its performance is usually superior.

ServiceMesh In order to provide better governance support, the communication model is generally at the application layer, such as processing protocols (http,grpc,mongo,mysql). If the performance requirements are relatively high, you can also directly use the 4-layer network model.

ServiceMesh is generally oriented to medium and large-scale distributed systems, distributed systems directly have their own communication costs, Mesh layer on the contrary can use more efficient communication protocols such as http/2 to optimize the service communication process through http/1.1 protocol communication.

Does ServiceMesh only govern the network?

The ServiceMesh Architecture Framework works at the network communication level to provide a range of service governance functions, including:

Service Discovery and Load Balancer

advanced routing

Communications monitoring and analysis

communication security

For Rainbond's architecture design, the following functions are added through plug-in extension:

log processing

data backup and recovery

Service operation and monitoring

Service Operation Environment Guarantee

Rainbond and ServiceMesh

Rainbond natively provides a full range of ServiceMesh governance functionality solutions, while providing plug-in extension strategies, users can customize plug-in implementations in addition to using the default solution. Rainbond and Istio implementations have something in common, but there are also natural differences.

The same point is that they all implement a global control layer based on the XDS specification, supporting envoy and istio-proxy.

The difference is that Istio needs to rely on Kubernetes and other platforms to work. The support of microservice architecture needs to be considered from the bottom layer storage and communication to the upper application layer configuration. Large-scale microservice architecture cannot be separated from the PaaS platform for automated management applications. Rainbond implements different control logic from hardware layer, communication layer and platform layer, which is compatible with existing microservice architecture and provides complete ServiceMesh microservice architecture practice. Inclusive architecture forms make existing application services available.

The experience provided by Rainbond to users is maximum transparency, that is, users have formed a microservice architecture by running services on Rainbond, without having to learn microservice architecture knowledge first, then consider how to transform their own services, and finally land.

As shown in the figure below, Rainbow's network governance plug-in dynamically starts third-party plug-in services, such as envoy services, in the same network namespace, storage space and environment variable space of the application by means of Sidecar, and completes data exchange from application space to platform space by communicating with Rainbow application runtime, so as to realize platform control over application communication.

Thank you for reading, the above is the content of "Rainbond built-in ServiceMesh microservice architecture method", after learning this article, I believe that everyone has a deeper understanding of Rainbond built-in ServiceMesh microservice architecture method, the specific use situation still needs to be verified by practice. Here is, Xiaobian will push more articles related to knowledge points for everyone, welcome to pay attention!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.