Service Mesh under MicroServices architecture will it be shiny tomorrow?

July 7, Speed Cloud Enterprise container PaaS Technology Salon 10th successfully held in Shanghai, Speed Cloud container architecture Director Wei Wei for everyone to explain in detail the service mesh representative practice, and take istio as an example in detail on the service mesh technology key points, including Istio control plane, istio data plane and so on. The following content is shared by Wei Wei, hoping to help you understand Service Mesh. Wei Wei: Good afternoon everyone, just a few lecturers talked about k8s storage, PAAs in the enterprise's landing practice, we are going to talk about the enterprise has a PaaS platform, and on the platform to deploy a variety of services, these services how to govern, service and service relationship, And how to maintain such issues, and the recent two years of the emergence of service Mesh, can be more convenient to manage these services. Service Mesh is a dedicated infrastructure layer designed to address inter-service communication and governance issues after system architecture microservices. Service Mesh has many scenarios in practice, but these scenarios have common features, such as the macro-architecture abstraction mentioned here, which is divided into Control Plane and Data Plane, the overall architecture design. Second, service Mesh is basically a set of lightweight services that are deployed with the application logic service, which uses proxies to implement routing, circuit breakers, service discovery, and so on, and these are transparent to application services, of course, on k8s. If it is not a service Mesh-based microservices architecture, can also be based on Springcloud micro-service architecture, but Springcloud has its own limitations, it is mainly used in Java-based areas. Istio, Conduit, and Nginmesh are all practice scenarios for comparing fire in Service Mesh. Istio is a collaborative open source project between Google and IBM Lyft, which is the most mainstream Service Mesh scenario, and Conduit has a very similar design concept to Istio, which uses Rust to rewrite sidecar and control polygons from Go Write Conduit Control Plane take over, Nginmesh does not own a full set of Service Mesh, but with Nginx instead of Istio Envoy. Istio in Istio, Conduit, Nginmesh These practical programs, istio the most influence, so IWe are going to explain istio today. The istio is logically divided into the control Plane and the data Plane (Plane). The control plane consists of Pilot, Mixer, Citadel, and each component of the control plane is responsible for some specific functions. The data plane consists of a set of intelligent agents (Envoy) that are deployed as Sidecar, which controls all network traffic between microservices. The Istio control plane Istio control plane consists of the following components: Pilot:pilot is responsible for Envoy configuration, full life cycle management. Provides service discovery for Envoy sidecar, enabling flexible routing for traffic management functions (such as A/B testing, Canary release) and resiliency (such as timeouts, retries, fuses, etc.), which can also translate high-level routing rules into Envoy specific configurations and propagate configurations at run time to The sidecar. Mixer:mixer is a platform-independent component that is responsible for the abstraction, docking, and policy configuration of back-end systems, and collects measurement data from Envoy agents and other services. abstractly, Mixer provides: Back-end abstraction: Mixer isolates the Istio components and services in the Mesh from the infrastructure details. Intermediate Media: Mixer enables OPS to control the interaction between all Mesh and infrastructure backend. Mixer to a certain extent the role of a bridge. Envoy provides request-level attribute data that is evaluated and processed by Mixer, and the various adapters (adapter) in Mixer are based on these attribute data for logging, monitoring Metrics collection display, quota management, ACL checking, and more. Citadel: Provides inter-service authentication and end-user authentication capabilities, built-in identity and certificate management, and provides service-level policy control beyond network policies. The Istio data plane envoy is the data plane of the istio. Envoy is a high performance lightweight agent that controls all inbound and outbound traffic for services in the service grid. Envoy provides many built-in features such as dynamic service discovery, load balancing, TLS session termination, http/2& GRPC traffic agents, fuses, health checks, and more. Envoy is deployed as a sidecar with the corresponding microservices deployed in a Kubernetes Pod. Each micro-service instance implements the sending and receiving requests through its own sidecar, and the microservices and microservices do not communicate directly, but instead communicate through sidecar proxy forwarding. The sidecar directly forms the calling network, just like a"Grid". You do not need to rebuild or rewrite the code using the sidecar proxy model code. 106 reads