The concept of microservice has been practiced in major companies. Spring Boot, represented by Java, has become the representative of microservice, and K8S+Docker has become the best environment for microservice operation. The concept of microservice is not so far away from us.

Of course, microservices are complex and require a lot of code modification in addition to many components to take advantage of them, so is there a way to use them flexibly in many different development languages without requiring a lot of code modification?

Istio was born based on the service grid. Today we are going to learn about microservices and Istio.

Attach:

A meow blog :w-blog.cn

Istio official address :preliminary.istio. IO /zh

Istio Chinese document: preliminary. Istio. IO/useful/docs /

PS: Here is a demo based on the latest ISTIO version 1.0.3. The details will be slightly different for different versions.

I. Micro services

Before we begin with Istio, we need to understand the concept of microservices and the list of components commonly used in microservice management:

  • Service registration: The service provider registers its calling address with the service registry so that the service caller can easily find it.
  • Service discovery: The service caller finds the address of the service he needs to invoke from the service registry.
  • Load balancing: Service providers typically provide services in the form of multiple instances. Load balancing enables service callers to connect to appropriate service nodes. Moreover, the work chosen by the node is transparent to the service caller.
  • Service gateway: The service gateway is the unique entrance to service invocation. It can realize user authentication, dynamic routing, gray scale publishing, A/B testing, load limiting and other functions in this component.
  • Configuration center: register localized configuration information (properties, XML, YAML, etc.) in the configuration center to achieve no difference in the development, test, and production environments, and facilitate package migration.
  • API management: Write and update API documentation in a convenient form for callers to view and test.
  • Integration framework: All microservice components provide services externally with a single program package. The integration framework integrates all microservice components (especially management components) into a unified interface framework in the form of configuration, so that users can use the system in a unified interface.
  • Distributed transactions: For important businesses, data consistency is guaranteed through distributed transaction technologies (TCC, high availability messaging service, best effort notification).
  • Call chain: Records the microservices invoked to complete a business logic and shows the serial or parallel invocation relationship. When the system goes wrong, you can easily find the error point.
  • Support platform: After the system is microservitized, the system becomes more fragmented, and the deployment, operation and maintenance, and monitoring of the system are more complex than the single architecture. Therefore, most of the work needs to be automated. Tools such as Docker can now be used to counteract the drawbacks of these microservices architectures. Examples include continuous integration, blue-green publishing, health check, performance health, and more. Seriously, in our two years of experience, we can say that if you don’t have the right supporting platform or tools, don’t use microservices architecture.

Advantages of microservices architecture:

  • Reduce system complexity: Each service is simpler and focuses on a single business function.
  • Loose coupling: The microservice architecture approach is loosely coupled and each microservice can be developed independently by different teams without affecting each other.
  • Cross-language: Developers are free to choose their development technology as long as it complies with the service API contract. This means that developers can write or refactor services using new technologies, and since the services are relatively small, it doesn’t have much impact on the overall application.
  • Standalone deployment: The microservice architecture enables each microservice to be deployed independently. Developers do not have to coordinate the deployment of service upgrades or changes. These changes can be deployed as soon as the tests pass. So the microservices architecture also makes CI/CD possible.
  • Docker containers: Better combined with Docker containers.
  • DDD domain-driven design: it fits the concept of DDD and is better combined with development.

Disadvantages of microservices architecture:

  • Microservices emphasize service size, but there is no universal standard: the rules by which business logic should be divided into microservices are an empirical project in itself. Some developers argue that 10-100 lines of code should be used to build a microservice. While building small services is what microservices architecture is all about, remember that microservices are a means to an end, not an end. The goal of microservices is to decompose applications sufficiently to facilitate agile development and continuous integration deployment.
  • The distributed nature of microservices brings complexity: developers need to implement the invocation and communication between microservices based on RPC or messaging, which makes the discovery between services, the tracing of service invocation chains, and the quality problems quite tricky.
  • Partitioned database systems and distributed transactions: Business transactions updating multiple business entities are quite common, and different services may have different databases. The constraints of the CAP principle force us to abandon traditional strong consistency in favor of final consistency, which is a challenge for developers.
  • Testing challenges: Traditional monolithic WEB applications only need to test a single REST API, whereas testing a microservice requires launching all the other services it depends on. The complexity should not be underestimated.
  • Change across multiple services: For example, in A traditional single application, if three services A, B, and C need to be changed, A depends on B, and B depends on C. We just need to change the corresponding module and deploy once and for all. But in the microservices architecture, we need to carefully plan and coordinate the deployment of changes for each service. We need to update C first, then B, and finally A.
  • Complex deployment: Microservices are made up of a large number of different services. Each service may have its own configuration, number of application instances, and underlying service addresses. This is where different configuration, deployment, extension, and monitoring components are required. In addition, we need a service discovery mechanism so that a service can discover the addresses of other services it communicates with. Therefore, successful deployment of microservice applications requires better deployment strategies and a high level of automation by developers.

In summary (issues and challenges) : API Gateway, inter-service invocation, service discovery, service fault tolerance, service deployment, data invocation, and testing.

Second, service grid

The second point is we need to know the Service grid, Istio provides a complete solution, for the whole Service grid provides insight and operation control to meet the diverse needs of the micro Service applications, Service Mesh this term usually used to describe the applications of the interaction between the Service network and application.

As service grids grow in size and complexity, they become increasingly difficult to understand and manage. Its requirements include service discovery, load balancing, failure recovery, metrics collection and monitoring, and often more complex operational requirements such as A/B testing, Canary publishing, traffic limiting, access control, and end-to-end authentication.

At the end of 2017, non-invasive Service Mesh technology went from infancy to maturity. In one sentence, a Service Mesh can be likened to TCP/IP between applications or microservices, responsible for network calls, traffic limiting, fuses, and monitoring between services. The TCP/IP layer is generally not a concern for writing applications (e.g., RESTful applications over HTTP), and the use of Service Mesh eliminates the need for relationships between services that are previously implemented by applications or other frameworks. Spring Cloud, OSS, for example, now just hand it over to Service Mesh.

The ins and outs of the Service Mesh

  • From the most original mainframe directly connected with the use of network cables
  • The emergence of the network layer
  • The flow of control integrated into the application
  • Decomposition to control flow outside the application
  • Integrated service discovery and circuit breakers in the application
  • There are software packages/libraries dedicated to service discovery and circuit breakers, such as Twitter’s Finagle and Facebook’s Proxygen, that are still integrated inside applications
  • Open source software for service discovery and circuit breakers, such as Netflix OSS and Airbnb’s Synapse and Nerve, has emerged
  • Finally, Service Mesh emerges as the middle layer of microservices

Service Mesh has the following characteristics:

  • An intermediate layer of communication between applications
  • Lightweight Web proxy
  • The application is not aware
  • Decouple application retry/timeout, monitoring, tracing, and service discovery

Service Mesh architecture diagram:

My understanding of the difference between microservices and service grid is that microservices are more like an ecosystem between services, focusing on things like service governance, while service grid is more focused on communication between services and better integration with DevOps.

3. Istio

Istio was launched on May 24, 2017. Istio was developed by Google, IBM, and Lyft, and released in August 2018 with version 1.0. In a nutshell, Istio allows you to connect, protect, control, and observe services.

The connection

  • Intelligently controls traffic and API calls between services, runs a series of tests, and escalates through red/black deployment.

To protect the

  • Automatically secure your services by hosting authentication, authorization, and encryption of communication between services.

control

  • Apply policies and ensure that they are enforced so that resources are fairly distributed among consumers.

observation

  • Understand what is happening with rich automatic tracking, monitoring, and recording of all services.

PS: The following content is from the official website documentation

The Istio service grid is logically divided into a data plane and a control plane.

The data plane consists of a set of intelligent agents deployed as Sidecars (envoys). These agents can regulate and control all network communications between microservices and mixers. The control plane manages and configures proxy traffic. In addition, the control plane is configured with Mixer to implement policy and collect telemetry data.

The following figure shows the different components that make up each panel:

Envoy

Istio uses an extended version of Envoy agent, a high-performance agent developed in C++ that mediates all inbound and outbound traffic for all services in the service grid. Many of The Envoy’s built-in features are carried over by IStio, such as:

  • Dynamic service discovery
  • Load balancing
  • The TLS to terminate
  • HTTP/2 & gRPC proxy
  • fuse
  • Health check, grayscale publishing based on percentage traffic splitting
  • Fault injection
  • Rich metrics

Envoy deployed as Sidecar, in the same Kubernetes pod as the corresponding service. This allows Istio to extract a large number of signals about traffic behavior as properties, which in turn can be used in Mixer to execute policy decisions and sent to the monitoring system to provide information on the behavior of the entire grid.

The Sidecar agent model can also add Istio capabilities to existing deployments without having to rebuild or rewrite code. Read more about why we chose this approach to our design goals.

Mixer

Mixer is a platform-independent component that performs access control and usage policies on the service grid and collects telemetry data from Envoy agents and other services. The broker extracts request-level attributes and sends them to Mixer for evaluation. For more information on attribute extraction and policy evaluation, see Mixer Configuration.

Mixer includes a flexible plug-in model that enables it to plug into a variety of host environments and infrastructure backends, abstracting Envoy proxies and ISTIO-managed services from these details.

Pilot

Pilot provides service discovery capabilities for Envoy Sidecar, traffic management capabilities for intelligent routing (e.g., A/B tests, Canary deployments, etc.) and resiliency (timeouts, retries, fuses, etc.). It translates the high-level routing rules that control traffic behavior into Envoy specific configurations and propagates them to the Sidecar at run time.

Pilot abstracts platform-specific service discovery mechanisms and synthesizes them into a standard format that can be used by any Sidecar that conforms to the Envoy data plane API. This loose coupling enables Istio to operate in a variety of environments (e.g., Kubernetes, Consul, Nomad) while maintaining the same operational interface for traffic management.

Citadel

Citadel provides powerful inter-service and end-user authentication with built-in identity and credential management. It can be used to upgrade unencrypted traffic in the service grid and provide operations personnel with the ability to enforce policies based on service identification rather than network control. Starting with version 0.5, Istio supports role-based access control to control who can access your services.

Service monitoring Link monitoring

Istio combines link monitoring and service monitoring, and K8S status monitoring is also a natural part of it

Zipkin + Jaeger for a more user-friendly presentation of Zipkin data

.

PS: Link monitoring needs to be implemented in the code to make basic adaptation

Prometheus + Grafana to display, monitor and alarm the data obtained by Prometheus