Explaining micro service and service grid with istio


Author: sudip sengupta


Proofread by:bot(talent cloud)Wenzi under the stars(Caiyun)

MicroserviceThe application is broken down into smaller service components. Compared with the traditional monolithic architecture,Microservice architecture regards each microservice as an independent entity and module, which fundamentally helps to simplify the maintenance of code and related infrastructure. Each microservice of an application can be written in a different technology stack, and can be further deployed, optimized, and managed independently.

In theory, microservice architecture is especially beneficial to the construction of complex large-scale applications, but in fact, it is also widely used in the construction of small-scale applications.

Benefits of microservice architecture

  • Different technology stacks can be used to develop and deploy various micro services in the application.
  • Each microservice can be optimized, deployed or expanded independently.
  • Better fault handling and error detection.


Components of microservice architecture

Modern cloud native applications running on the microservice architecture rely on the following key components:

  • Containerization(through a platform similar to docker): services are managed and deployed by dividing them into multiple processes.
  • layout(through a platform similar to kubernetes): configure, allocate, and manage system resources for services.
  • Service Grid(through the platform similar to istio): through the service proxy grid for inter service communication, to connect, manage and protect micro services.

The above three components are the most important components in the microservice architecture. These components allow applications in the cloud native stack to expand under load and even execute during partial failures in the cloud environment.


Complexity of microservice architecture

When a large-scale application is decomposed into multiple microservices, each microservice uses a different technology stack (development language, database, etc.), so we need to organize these environments into a complex architecture for management. Although each microservice has been divided into multiple processes running in a separate docker container to help manage and deploy a single microservice, theBecause we have to deal with the overall system health, fault tolerance and fault points, the communication between services is still very complex.

We can learn more about it through the example of shopping cart working on micro service architecture. Here, microservice will be related to inventory database, payment gateway service, product recommendation algorithm based on customer access history, etc. Although these services are still independent micro modules in theory, they do need to interact with each other.


Why do we need service grid?

Service to service communication is very important in microservice architecture, so it is obvious that communication channels need to ensure fault-free, security, high availability and robustness. These areService grid is the place where infrastructure components appear. It ensures service to service communication by implementing multiple service agents.Service grid is not responsible for adding new functions, but can fine tune the communication between different services.

In the service grid, agents deployed with a single service can realize the communication between services, which is widely known asSidecar mode。 Side car mode has important functions to deal with inter service communication, such as load balancing, open circuit, service discovery and so on.

Through service grid, we can:

  • Maintain, configure, and protect communication between all or selected microservices in the application.
  • Configure and perform network functions in micro services, such as network resilience, load balancing, network interruption, service discovery, etc.
  • Network function and business logic are separated as separate entities, so developers can focus on the business logic of applications, and most of the work related to network communication is handled by service grid.
  • Since the proxy communication from microservice to service always uses standard protocols such as HTTP 1. X / 2. X and grpc, developers can use any technology to develop a single service.


Components of service grid architecture

Business logic

Business logic includes the core application logic, basic code, application calculation and service to service integration logic of microservice. The advantage of microservice architecture is that business logic can be written on any platform, and the business logic is completely independent of other services.

Basic network functions

The basic network functions include initiating network request and connecting service grid agent. Although the main network functions of micro service are handled by service grid, a given service must contain basic network functions to connect with sidecar agent.

Application network function

Different from basic network functions, this component maintains and manages key network functions through service agents, including network interruption, load balancing, service discovery, etc.

Service grid control plane

All service grid agents are centrally managed and controlled by the control plane. Through the control plane, we can specify authentication policies, generate metrics, and configure service agents throughout the grid.


Implementing service grid with istio

Although there are other service grids, istio is the most popular. Let’s take a look at how to apply istio to the service grid architecture of cloud native applications.

As mentioned above, in the microservice architecture,Istio will connect, protect and control the communication between distributed services by forming an infrastructure layer.Istio will deploy one next to each service  Istio proxy (called istio sidecar)However, the code of the service itself rarely changes. All inter service traffic is directed to the istio agent, which uses policies to control inter service communication, and implements the basic policies of deployment, fault injection and circuit breaker.

Istio’s core competence

  • The communication between services is protected by authentication and authorization.
  • Policy layer supporting access control, quota and resource allocation.
  • It supports automatic load balancing of HTTP, grpc, websocket and TCP communication.
  • Automatic index, log and trace of all traffic in the cluster, including the entrance and exit of the cluster.
  • The inter service communication is configured and controlled by fault transfer, fault injection and routing rules.

Istio does not rely on any platform, which means it can run in a variety of environments, including cloud, local, kubernetes, etc. Istio currently supports:

  • Service deployment on kubernetes
  • Services registered with Consul
  • Services running on a single virtual machine

Core istio components

Explaining micro service and service grid with istio

Image source: istio.io

Istio service grid consists ofData planeandControl planeform.

  • stayData planeIt is composed of multiple service agents (through envoy), while sidecar communication between microservices is realized through policy and telemetry collection (through mixer).
  • stayControl planeThe communication between sidecar agents is managed and configured through pilot, Citadel and galley.CitadelUsed for key and certificate management.PilotThe authorization policy and security naming information are distributed to agents, which are mainly used for service discovery and service configuration (service access rule maintenance). The adapter mechanism in pilot can adapt to various service discovery components (Eureka, consult, kubenetes), the best of which is kubernetes. Galley validation rules (rules configured by pilot, mixer and citadel).

The control plane manages and maintains the data plane components, which forms the most important layer of istio service mesh.

Original address:https://mp.weixin.qq.com/s/xPyXBvp_-e-1ODAapDgWHw

Recommended Today

Modul of fastems

Each module of fastems is implemented from the abstract class Fastems.Mms.Client.Infrastructure.UiModuleBase; public class DataManagerModule : UiModuleBase { public override void Initialize() { AddResourceDictionary(“/Resources/DataManagerResources.xaml”, typeof(DataManagerModule)); RegisterViewWithRegion(“DialogRegion”, typeof(DialogView)); RegisterViewWithRegion(“BusyIndicatorRegion”, typeof(BusyIndicatorView)); } } And Fastems.Mms.Client.Infrastructure.UiModuleBase inherits from Fastems.Mms.Client.Infrastructure.ModuleBase public abstract class UiModuleBase : ModuleBase { [Import] public IRegionManager RegionManager { get; set; } [Import] public IMergedDictionaryRegistry MergedDictionaryRegistry { […]