"Reprint" How to build a self-healing distributed system using Spring cloud

Http://zhidao.baidu.com/link?url= Tskwdn3wr8kuxwmtehmnefty0konzbmk9xy-rimsdisa4h2neaecghqggbipz2w6nxrvd3mmcpbip5q6ketfpz03gdlzroh86p_eva8brpe

Leveraging the components of Netflix and all the familiar tools, we can handle the technical challenges posed by microservices and distributed computing.

Over the past year, microservices have become a hot term in the Software architecture field, and we can easily cite many of the comparative advantages it brings. However, we must be aware that once we start to follow the micro-service approach and split the existing architecture system, it means that we will inevitably enter the field of distributed systems. In the previous article we explored the eight misunderstandings of distributed computing *, so the system itself is fraught with risks, and once we commit any of these eight kinds of mistakes, we will all face disastrous consequences.

In my personal opinion, if you want to summarize these myths into one point, it is: for a distributed system, any expression of consistency or reliability is not guaranteed. We need to assume that the various behaviors in the system and the location of the components are always in a state of flux. There are two main consequences: components can sometimes lead to poor service quality or even direct offline service, we can only refer to it as "failure", and it is difficult to specify exactly where the problem is. Failure to properly dispose of such failures will lead to disruption and downtime, which means that the system will not be able to provide services to users in accordance with established design scenarios.

In view of this, in order to enjoy the many advantages of microservices (including loose coupling, autonomous services, decentralized governance, and ease of continuous delivery, etc.), we must avoid the horrors of a single failure progression that ultimately leads to system crashes. In this regard, the father of Erlang, Joe Armstrong, once made a thorough statement in the article titled "How to Build a system that is always running, self-repairing, and extensible." In his view, such systems appear to be very similar to what we call microservices architectures, but they emphasize their fault tolerance as a self-healing system. So how can we build a solid and reliable system solution for us?

Netflix has been a pioneer in the implementation and promotion of micro-service architectures. As part of its principled approach to business building, Netflix believes that system solutions must be able to withstand the sudden failure of any component, while the overall system continues to function (which means we can still watch movies on the platform, and Netflix can continue to record the user's viewing preferences). When trying to build such a system, we encounter the following common technical challenges:

Because of the need to split the system into multiple distributed processes, how do we distribute these configurations to these processes with consistency and reliability?
When these configuration scenarios need to be modified, how do we update the configuration content without having to redeploy all the processes?
In such a system, especially for systems deployed in a cloud environment, each process is not only constantly changing, but also changing its location (especially in the case of failover). How do we accurately determine the exact location of the processes that need to be coordinated?
Once we have detected several possible locations for the current process affinity, how do we choose which process instance to communicate next?
How do we prevent cascading failures caused by the failure of this instance in the process of selecting a process instance and communicating with that instance?
How can we maintain a visual monitoring of the state of the system in order to make targeted and accurate adjustments in situations where the integrated operational behavior of the systems continues to bring an evolutionary topology to the autonomous service?
In fact, you can deploy a variety of template models and open source tools to address these technical challenges. Netflix built a variety of components, open source, and conducted a series of tests in a production environment. From a theoretical standpoint, we can use these tools to build systems that are capable of "forever running, self-repairing, and scale-out." For those of you who have just embarked on a distributed system, our first priority is to understand these implementation patterns, master the Netflix components and apply them, and then deploy, manage, and integrate these components into our systems. Since any new technology dependency will bring the complexity elements that are not seen before in the software engineering scenario, we recommend that you use the Netflix stack directly to minimize such potential friction.

Since its inception, the spring engineering team has been working hard to create powerful weapons that deal with Java complexity. Our early focus is on eliminating the productivity impact of Java EE for enterprise application developers. In the recent past, our main focus has shifted to the implementation of cloud-on-premises application building, and much of this work has been incorporated or revolved around the spring Cloud project.

The goal of the spring Cloud Project is to provide spring developers with a set of easy-to-use toolsets that make it easy to build the distributed system scenarios they need. To achieve this goal, Spring Cloud consolidates and packages a large number of implementation stacks on the basis of the Netflix OSS stack. These stacks can then be delivered through a variety of familiar annotation-based configuration tools, Java configuration Tools, and template-based programming tools. Let's take a look at some of the common components in spring cloud.

Spring Cloud Config Server
Spring Cloud Config Server can provide a centralized configuration service with scale-out capabilities. The data it uses is stored in a single pluggable library layer, which currently supports local storage, git, and subversion. By leveraging a set of versioning systems as a Configuration storage solution, developers can easily adjust the content of versions and audit configurations.

How to build a self-healing distributed system using Spring cloud

Configuration content is represented in the form of a Java attribute or a Yaml file. The config server merges these files into an environment object that contains an easy-to-understand spring property model and a configuration file that exists as a rest API. Any application can invoke the configuration data contained in the rest API directly, but we can also add the smart client binding scheme to the Spring boot application, which automatically assigns the configuration information received from config server to any local configuration.

Spring Cloud Bus
Spring Cloud config server is a powerful set of configuration distribution mechanisms that can distribute configuration content to multiple application instances with consistency assurance. However, based on the limitations of its design approach, we can only update its configuration at the moment of application startup. When sending a new value to a property in git, we need to manually restart each application process to ensure that the value is effectively incorporated into the application. Obviously, you need to be able to complete the update of the application configuration content without restarting.

How to build a self-healing distributed system using Spring cloud

The task of Spring Cloud Bus is to add a set of management backplanes for the application instance. It currently relies on a set of clients to bind to a set of AMQP interchanges and queues, but this backend is also designed to implement pluggable features. Spring Cloud Bus brings more management endpoints to our applications. In Figure two, we can see that a value oriented to the Greeting property is sent to Git, and then a request is sent to the/bus/refresh endpoint in app a. The request triggers the following three events:

Application A requests from Config server for the latest version of the configuration content. Any spring beans that are annotated with @refreshscope will be reinitialized and loaded with new configuration content.
Application A sends a message to the AMQP switch system indicating that it has received an update indication.
Application B and App C, which are incorporated into cloud bus by listening to the AMQP queue, get to the above message and implement the configuration update in the same manner as application A.
Now we have the ability to update the application configuration without rebooting.

"Reprint" How to build a self-healing distributed system using Spring cloud