Spring Cloud Micro-service design and practice

Organize micro-service design and practice process, share to everyone.

Description of micro-service

The description of Microserivce by Martin Fowler :

• Classify service types according to business modules.
• Each service can be deployed independently and isolated from each other.
• Service is invoked through a lightweight API.
• The service needs to ensure good high availability.

Micro-service architecture is a design idea of complex business system building based on small functional modules focusing on single responsibility and communicating with each other through API.

Evolution process

Monolithic architecture (Monolithic), vertical architecture, SOA architecture, micro-service architecture

Pain points to be solved:

such as DAO and other similar operation code repetition, cache upgrade transformation, sub-Library table, database reuse and coupling, SQL not centralized management, DB coupling and other unrelated services caused by passive update problem;

Preparatory work

• Business Split

To rationally plan the boundaries between services;

• Service governance

Facilitate the realization of service discovery, governance, fuse, downgrade and other mechanisms;

• Automated testing

As far as possible to achieve more links to automate.

• Automatic operation and Maintenance

Easy deployment upgrades, efficient automation operations.

• Service Monitoring

Including hardware environment, service status, System health, interface call situation, abnormal real-time alarm and potential problems in advance warning and so on. A word: not ready to monitor, do not engage in micro-services.

Design principles

• AKF Split principle (AKF extended cube)

  • X horizontal replication, i.e. multi-instance cluster load
  • Y Split by Business services function
  • Z Data Partitioning

• Front-end separation

Optimize front and rear end frames, facilitate interface design development and maintenance

• Stateless service

Store data that needs to be shared by multiple services into the distributed cache, making the business service a "stateless compute node" that facilitates the dynamic expansion of nodes.

• Restful style

At present more are: ①restful②rpc (Thrift, Dubbo)

It is recommended to use a stateless HTTP protocol, which is highly extensible, and the JSON message business is mature and friendly.

principle of service splitting(important) Mandatory conditions

• Internal service should be stable
• The service should implement relevant methods and must follow the principle of common closure
• Different service rooms should be loosely coupled, service internal changes do not affect external services
• Service should be easy to test

Splitting a solution

• Split by Business (split horizontally)

such as user services, order services, product services, and so on, based on the existing system of the various business processes, the abstraction of each logic can be independent of the service, similar to split Code service interface;

• Basic service sinking

Split the public components into separate atomic services and sink to the bottom to form a relatively independent atomic service layer.

• Split based on domain model

https://www.zhihu.com/question/24013141

54691456

52496186

78848420

79173292

The standardized function, which provides the standard capability support for the product layer by the bottom service, has the strong function of individual business characteristic, which is realized by the product layer directly calling the lower capacity.

Attention issues

• Performance loss for remote service calls
• Strong consistency vs Final consistency (distributed transaction or CAP issues)
• More complex cross-service testing
• More complex operation and maintenance work
• More demanding finishing planning and design

Transactional consistency issues

Most businesses can be resolved through eventual consistency , with very few requiring strong consistency . The specific strategy is as follows:

Final consistency

Based on MQ and other message middleware implementations.

Strong consistency

Using the TCC framework, you need to embed a distributed transaction framework to support distributed transactions.

Domain-driven design has already clarified that a set of business concepts with strong consistency requirements, belonging to the same aggregation, is not recommended to be split into different services, thus avoiding the processing of distributed strong transactional consistency as much as possible. The service boundary that can be split is in the bounds context or the granularity of the aggregation. Such transactional consistency is ultimately consistent and can be handled with sophisticated tools or algorithms.

Combat Solutions Service Mesh

This section is detailed in https://www.sdnlab.com/20363.html

Defined

A service grid is a dedicated infrastructure layer for processing service-to-service communications. It is responsible for reliably delivering requests through a complex service topology. In fact, the service grid is typically implemented as a lightweight network proxy matrix that is deployed with application code, and it is not perceived by the application.

The Service Mesh can be summarized as:

1. Dedicated infrastructure layer: a separate operating unit.

2. Includes the data layer and the control layer: The data layer is responsible for delivering application requests, and the control layer controls how the service communicates.

3. Lightweight transparent proxy: the implementation form is lightweight network proxy.

4. Handling inter-service communication: The main purpose is to achieve inter-service communication in complex networks.

5. Reliably deliver service requests: Provides a network resiliency mechanism to ensure reliable delivery of requests.

6. Together with the service deployment, but the service does not need to be perceived: although it is deployed with the application, it is transparent to the application.

Role

Service mesh acts as a transparent proxy, it can run in any infrastructure environment, and is very close to the application, so what can service mesh do?

• Load Balancing

In the running environment, the microservices instances are usually in a dynamic state, and there is often a tendency for individual instances to fail to provide services, reduce processing power, and lag. However, because all requests are visible to Service Mesh, it is possible to provide advanced load balancing algorithms for smarter, more efficient traffic distribution, reduced latency, and increased reliability.

• Service discovery

Application changes that run in microservices mode are very frequent, and the problem with frequent increases in application instances is that it is more complex to pinpoint new instances and avoid sending requests to instances that are not already present. Service Mesh provides a variety of simple, unified, platform-independent services discovery mechanisms, such as a service discovery mechanism based on dns,k/v key-value-to-store.

• Fusing

Outage or unhealthy service instances in a dynamic environment can cause service outages to occur frequently, requiring applications or other tools to have rapid monitoring and removing the ability to provide service instances from a load-balanced pool. This capability is also called fusing, which allows applications to continually try without consuming more unnecessary resources, but to quickly fail or downgrade, or even to avoid potential association errors. Service Mesh makes it easy to implement a fusing mechanism based on request and connection levels.

• Dynamic routing

As service providers focus on delivering high stability, high availability, and high SLA services, in order to achieve the stated objectives, a variety of application deployment strategies are deployed as far as possible from a technical approach to non-service outages to avoid changes that result in reduced service disruptions and stability. For example: Blue/green deployment, canary deployment, but implementing these advanced deployment strategies is often difficult. For an application deployment strategy, refer to Etiennetremel's article for a detailed comparison of the various deployment strategies. And if the OPS can easily transfer application traffic from the staging environment to the production line environment, one version to another version, or from one data center to another data center for dynamic switching, even through a central control layer to control how much proportional traffic is switched. The dynamic routing mechanism provided by Service Mesh and the specific deployment strategy, such as the Blue/green deployment, make it easier to achieve these goals.

• Secure communications

Security is an important part of the entire company and business system, and it is very difficult to implement and control. In the micro-service environment, the communication between different service instances becomes more complex, so how to ensure the communication is very important in the situation of security and authorization. By implementing security mechanisms such as TLS plus decryption and authorization on Service Mesh, you can not only avoid repetitive implementations in different applications, but also easily update security at the entire infrastructure level without even needing to do anything about the application.

• Multi-lingual support

Because Service Mesh acts as a transparent proxy for standalone operation, it is easy to support multiple languages.

• Multi-protocol support

As with multi-lingual support, it is easy to implement multiprotocol support.

• Indicators and distributed tracking

The visibility of service Mesh across the infrastructure layer makes it possible to expose not only the operational metrics of a single service, but also the operational metrics of the entire cluster.

• Retry and Deadline

The retry capability of the service Mesh avoids embedding it into the business code, while the deadline allows the application to allow the maximum lifetime of a request, rather than endless retries.

Industrial Products

Currently, the industry mainly has the following related products:

Buoyant's linkerd, based on Twitter's Fingle, has long-term practical experience and validation of production lines, supports Kubernetes,dc/os container management platform, and CNCF one of the officially supported projects.

Lyft's envoy,7 layer agent and communication bus supports 7 layer HTTP routing, TLS, GRPC, service discovery and health monitoring, and is also one of the CNCF official support projects.

IBM, Google, Lyft supported Istio, an open source microservices connectivity, management platform, and security management for microservices, support Kubernetes, Mesos, and other container management tools, with the underlying dependency on Envoy.

Summarize

Service Mesh enables rapid turnaround to microservices or cloud-native applications, extending application load in a natural mechanism, solving the inevitable partial failures of distributed systems, capturing dynamic changes in distributed systems, decoupling them completely from applications, and more.

I believe that service Mesh is a must for microservices or cloud-native applications.

Spring Cloud

This everybody certainly is not unfamiliar, Spring family barrel certainly is everybody's commonly used tool, is very suitable for the small and medium sized enterprise which cannot devote a lot of energy to build the foundation component, is suitable for the rapid development and the business realization, the strong community support strength, has provided the very complete micro Service practice support, is my first choice to get started.

Here I choose Spring Cloud as a tool for microservices practices. But for the powerful creativity of Google and other giants I am quite looking forward to, and hope that the early emergence of more powerful products.

Introduced

The Spring Cloud website is described below:

Spring Cloud provides tools for developers to quickly build some of the common patterns in distributed systems (e.g. confi Guration Management, service discovery, circuit breakers, intelligent routing, micro-proxy, control bus, one-time tokens, Global locks, leadership election, distributed sessions, cluster State). Coordination of distributed systems leads to boiler plate patterns, and using Spring Cloud developers can quickly stand up Services and applications that implement those patterns. They would work well in any distributed environment, including the developer ' s own laptop, bare metal data centres, and mans Aged platforms such as Cloud Foundry.

Includes but is not limited to the following features:

• distributed/versioned Configuration
• Service Registration and Discovery
• Routing
• Service-to-service calls
• Load balancing
• Circuit breakers
• Global Locks
• Leadership election and cluster state
• Distributed messaging

Composition

The main components of the module:

• Spring Cloud Config
• Spring Cloud Netflix
• Spring Cloud Bus
• Spring Cloud Cluster
• Spring Cloud Consul
• Spring Cloud Security
• Spring Cloud Sleuth
• Spring Cloud CLI
• Spring Cloud Gateway
• Spring Cloud openfeign ....

Match up

• Spring Boot Actuator
• Spring Boot Admin

To meet the functionality needed for everyday business. I think Spring family barrels for enterprise Development support is very comprehensive, Internet enterprise development involves a lot of features are here for good support.

Spring Cloud Micro-service design and practice