Service and found an article interpretation of micro-services architecture -Spring Cloud

First, why the need for service discovery

Briefly, the service of the core is applied according to the traditional stop a service split into a service, and on this basis of micro service to more fully decoupled (not share DB, KV, remove heavyweight ESB), and stressed the DevOps and fast evolution. This requires us to adopt and stop times, different technology stack pan-SOA era, and Spring Cloud is one of the best.

English Development and Operations DevOps is fit, he asked the development, testing, operation and maintenance of integrated cooperation, to make smaller, more frequent, more automated application release, application architecture and surrounding infrastructure to build infrastructure. This requires the full application of cohesion, but also facilitate operation and maintenance and management. This idea coincides with the micro-service concept.

Next we service architecture evolution from the perspective of Spring Cloud and see why more responsive to micro-services architecture.

1.1 Speaking from using nginx

The initial service solutions is to provide the same services to provide a unified domain name and service the caller sends an HTTP request, the request Nginx responsible for the distribution and jump to the domain name.

There are many problems with this architecture:

  • Nginx as an intermediate layer, is coupled in the configuration file of the service invocation logic, which impairs the integrity of the micro and services, but also makes Nginx into a heavyweight ESB some extent.
  • Information services scattered in various systems, can not be unified management and maintenance. Every service call is the first attempt, consumers do not know which service instances to provide them with services. This is not in line with the concept of DevOps.
  • We can not visually see the service providers and service consumers current health and communication frequencies. This is not in line with the concept of DevOps.
  • Consumers retransmission failure, load balancing and so there is no uniform policy, which increased the difficulty of development of each service, is not conducive to rapid evolution.

In order to solve the above problems, we need a ready-made central component of service integration, the summary information for each service, including the service component name, address and quantity. The caller services to provide this service to obtain information first instance (IP, port, etc.) when requested by a service center component, and then select a provider for the service via policy default or customized direct access. So, we introduced Dubbo.

1.2 Based on Dubbo achieve microService

Ali Dubbo is a open source SOA service management solutions, rich document, use of the country is very high.

Dubbo built using micro-services, it may have been a better solution to the problem mentioned above:

  • Call the middle layer becomes optional components, consumers can directly access the service provider.

  • Service information is concentrated in the Registry, formed a central component of service governance.

  • By Monitor monitoring system, you can visually display statistical information service call.

  • Consumer can perform load balancing, service degradation choice.

But for the micro-architecture in terms of service, Dubbo also not perfect:

  • Registry relies heavily on third-party components (zookeeper or redis), when these components there is a problem, a service call will soon be interrupted.

  • DUBBO only support RPC calls. Enables service providers and the caller had a strong reliance on the code, service providers need to continue to contain the common code out of the jar package packaged for consumer use. Once the packaging problem, it will result in a service call error.

  • Most importantly, DUBBO now has stopped maintenance, the demand for new technology development, the need to expand the upgrade by the developers themselves. Which for many small and medium software organizations that want to micro-service architecture, it is clearly not appropriate.

Currently on the Github community an upgraded version of a DUBBO, called DUBBOX, provides a more efficient way of serialize RPC and REST invocation. But the project also basically stopped maintained.

1.3 new options --Spring Cloud

As a new generation of service framework, Spring Cloud slogan put forward is to develop "cloud-oriented applications environment", which provides a more comprehensive technical support service for the micro-architecture. Combined with the demands of micro services we mentioned at the beginning, we have Spring Cloud and DUBBO be some comparison:

Micro services needed Dubbo Spring Cloud
Service registration and discovery Zookeeper Eureka
Service invocation RPC RESTful API
breaker Have Have
Load Balancing Have Have
Service routing and filtering Have Have
Distributed Configuration no Have
Distributed Lock no Plans to develop
Clusters main election no Have
Distributed Message no Have

Spring Cloud abandoned Dubbo RPC communication, using the REST HTTP-based manner. Strictly speaking, these two methods have advantages and disadvantages. Although to some extent, the performance of the latter at the expense of service calls, but also to avoid the problems mentioned above native RPC brings. RPC and REST compared to more flexible, service providers and rely solely dependent on the caller a paper contract, code-level strong dependence does not exist in this case emphasize the rapid evolution of micro-services environment, appear to be more appropriate.

Clearly, Spring Cloud is more powerful than DUBBO, wider coverage, but also as Spring fist project, it is also possible, Spring Boot, Spring Data, Spring Batch Spring and other items perfect integration with the Spring Framework, these services for micro It is crucial. As mentioned earlier, an important micro-services behind the concept is continuous integration, fast delivery, and the use of a unified internal services in the technical framework, with clearly more efficient than the technology portfolio to disperse. More importantly, compared to Dubbo, it is an ongoing maintenance, more fiery community open source project, which uses the system to ensure that it is built, can continue to be supported by the power of open source.

Two, Spring Cloud Netflix components

Netflix and Spring Cloud is what to do with it? Netflix is ​​a successful practice micro-architecture of the Internet service company, a few years ago, it took almost the entire Netflix micro-services stack frame contributed to the open source community. Pivotal Spring behind the 2015 launch of the Spring Cloud open source products, mainly to further open source Netflix package assembly, Spring easy for developers to build micro-services infrastructure framework. For micro-management services, the core is the registration and discovery services. So choose which components to a large extent depends on its service registration and discovery solutions for. In this area, a lot of open source architecture, the most common is Zookeeper, but this is not the best choice.

There is a well-known CAP theorem in the field of distributed systems: C-- data consistency, A-- service availability, P-- service network partition failure fault tolerance . These three characteristics can not be satisfied in any distributed system, up to meet two.

Zookeeper is a subproject of Hadoop famous, many scenes Zookeeper also found service as a Service solutions. Zookeeper ensured that the CP , i.e., any time access can be obtained Zookeeper request data consistent results, and the system fault tolerant network is divided, it can not guarantee the availability of each service request. From the analysis of the actual situation, when using Zookeeper get the list of services, if the election is the main zookeeper, or more than half Zookeeper cluster machine is not available, then the data will not be obtained. So, Zookeeper can not guarantee service availability.

Indeed, for most distributed environments, especially in scenes related to data storage, data consistency should first be guaranteed, and this is the reason zookeeper designed to CP. But for service discovery scenario, the situation is not the same: for the same service, even if the service providers saved in different nodes registry information are not the same, it does not cause catastrophic consequences. Because for service consumers, energy consumption is the most important - get the instance of the service may not be correct consumer information to try it, because they can not get better than examples of information rather than to spend. So, for service discovery, the availability of data consistency is more important than --AP than the CP . The Spring Cloud Netflix followed when designing Eureka is AP principle.

Eureka itself is open source Netflix offers a service registration and discovery products, and provides corresponding Java package. In its implementation, the mutual equality between the nodes, the nodes part of the registry will not have to hang impact cluster, even if a cluster node only survive, but also can normally provide discovery services. Even if all the nodes are linked to service registration, call service information will be cached on the Eureka Clients. This ensures that each call is robust enough between our micro-services.

In addition, Spring Cloud Netflix powerful forces behind open source, but also prompted us to choose the Spring Cloud Netflix:

  • Mentioned before, Spring Cloud community is very active, its application is very extensive in the industry (especially abroad), but also the entire framework withstood the test of Netflix harsh production environment.
  • In addition to service registration and discovery, other features Spring Cloud Netflix is ​​also very strong, including the Ribbon, hystrix, Feign, Zuul and other components joined together, let's call the service, routing also become very easy.
  • Spring Cloud Netflix as a heavyweight integrated Spring framework, using it also means that we get from Spring to great convenience. Other subprojects Spring Cloud, such as Spring Cloud Stream, Spring Cloud Config, etc., provides one-stop solutions for all the needs of micro-services.

Three, Spring Cloud service discovery

Core Spring Cloud Netflix is ​​Eureka for service registration and discovery, the next we are going to Eureka as a clue, introduced Eureka, Ribbon, Hystrix, Feign these Spring Cloud Netflix main components.

3.1 Service registration and discovery --Eureka

Eureka word comes from ancient Greek, meaning "I found I found!!" According to legend, Archimedes discovered the principle of buoyancy while taking a bath, happy time to put on pants, ran into the street shouting: "Eureka (I found)!."

Eureka by multiple instance (service instances), with examples of these services can be divided into two types: Eureka Server and Eureka Client. For ease of understanding, we will be subdivided into Eureka client Service Provider and Service Consumer. As shown below:

  • Eureka Server: registry services, maintains a list of services registered.
  • Service Provider: service provider, as a Eureka Client, to do Eureka Server service registration, renewal and off the assembly line and other operations, including major data registered service name, machine ip, port number, domain name, and so on.
  • Service Consumer: consumer services, as a Eureka Client, obtain registration information to the Service Provider Eureka Server, and communicate via remote call and Service Provider.

Service Provider Service Consumer is not strictly the concept and, Service Consumer can always register to Eureka Server, to make himself into a Service Provider. Spring Cloud for service registration and discovery, conducted a layer of abstraction and provides three implementations: Eureka, Consul, Zookeeper. It is currently the best supported Eureka, followed by the Consul, and finally Zookeeper.

3.1.1 Eureka Server

Eureka Server as a standalone deployment unit, in the form of REST API provides registration, management and query operations for the service instance. Meanwhile, Eureka Server also provides us with visual monitoring page, you can visually see each Eureka Server and the current operating status of all cases registered service.

3.1.1.1 Eureka Server High Availability Clusters

Eureka Server can run multiple instances to build a cluster, to solve the problem of a single point, but the process is different from the election of the leader ZooKeeper, Eureka Server uses a Peer to Peer to peer communication. This is a decentralized architecture, no master / slave distinction, each Peer are peers. In this architecture, the node registered with each other to increase the availability of each node needs to add one or more links to other nodes serviceUrl valid. Each node can be seen as copies of other nodes.

If a station Eureka Server downtime request Eureka Client will automatically switch to the new Eureka Server node, server downtime when restored, Eureka will again be incorporated into the server cluster management. When the node starts to accept client requests, all operations will be replicateToPeer (inter-node copy) operation, the request to all nodes other currently known in Eureka Server.

After a new Eureka Server node starts, it first tries to get all instances of the registry information from a neighboring node to complete initialization. Eureka Server Get all the nodes getEurekaServiceUrls () method, and will be updated through the renewal of the heartbeat regular basis. Default configuration, if Eureka Server does not receive the heartbeat of a service instance within a certain time, Eureka Server will log off the instance (default is 90 seconds, by eureka.instance.lease-expiration-duration-in-seconds configuration) . When Eureka Server node is lost too many heartbeats in a short time (such as a network partition failure), then the node goes into self-preservation mode. Chart below shows the official website of Eureka

What is a self-protection mode? Default configuration, if Eureka Server receives the number of heartbeats per minute is less than a threshold value renewal (the number of instance of * (60 / each instance heartbeat interval seconds) * self-protection factor), self-protection is triggered. In the self-protection mode, Eureka Server service will protect the information in the registry, no cancellation of any service instance. When it receives the heart rate restored to above the threshold, the Eureka Server node will automatically exit the self-protection mode. Its design philosophy mentioned earlier, it is rather reserved the wrong service registration information, do not blindly write off any possible health service instance. This mode may be disabled by eureka.server.enable-self-preservation = false, while eureka.instance.lease-renewal-interval-in-seconds can be used to change the heartbeat interval, eureka.server.renewal-percent-threshold can be used to modify the self-protection factor (default 0.85).

3.1.1.2 Eureka Server specific Region, Zone

Eureka's official documentation to Regin, Zone almost no mention, due to the abstract concept, the novice is difficult to understand. Therefore, we first look at the relationship between Region, Zone, Eureka clusters of three, as shown below:

region and zone (or Availability Zone) are the concept of AWS. In the non-AWS environment, we simply can first be understood as a Eureka cluster region, zone interpreted as the engine room. The figure can be understood as a Eureka cluster is deployed in the zone1 zone2 engine room and engine room.

3.1.2 Service Provider

3.1.2.1 Service Register

The Service Provider is essentially a Eureka Client. When it starts, it will call the service registration process to register their information to the Eureka Server. Eureka Server maintains a list of registered services, this list is a nested hash map:

  • The first layer, application name and the corresponding service instance.
  • The second layer, and the service instance corresponding to the registration information, including IP, port number.

When the instance status changes (such as time itself detected as Down), will update the status of their service to Eureka Server, while using replicateToPeers () do state synchronization to other Eureka Server nodes.

3.1.2.2 renewal and elimination

As mentioned earlier, the service instance starts, it will periodically send a heartbeat to the Eureka Server to renew their information, to avoid their registration information is removed. Renewal of registration services are basically the same way: First, update their status, and then synchronized to the other Peer.

If Eureka Server does not receive a heartbeat micro-services node over a period of time, Eureka Server will log off the micro-service node (except for self-protection mode).

3.1.3 Service Consumer

The Service Consumer essence is a Eureka Client (it will also register with the Eureka Server, but this registration information does not matter Bale). After it starts, it will get from the Eureka Server registration information for all instances, including IP addresses and ports, and cached locally. This information is updated every 30 seconds by default. I mentioned before, if interrupted Eureka Server communicates with, Service Consumer can still communicate with the Service Provider through a local cache.

Eureka actual development process, sometimes get to meet Service Consumer Information Server Provider's delay in Eureka Wiki has in so many words:

All operations from Eureka client may take some time to reflect in the Eureka servers and subsequently in other Eureka clients. This is because of the caching of the payload on the eureka server which is refreshed periodically to reflect new information. Eureka clients also fetch deltas periodically. Hence, it may take up to 2 mins for changes to propagate to all Eureka clients.

Mentioned in the last sentence, change the server may need two minutes to propagate to all clients, and for reasons not covered. This is because there are three Eureka cache and a delay caused.

  • Eureka Server to the list of registered cache, the default time is 30s.
  • Eureka Client for access to registration information is cached, the default time is 30s.
  • Ribbon from the above mentioned will get a list of services Eureka Client, the result of load balancing cache 30s.
  • If not using these components (Eureka, Ribbon) in Spring Cloud environment, the service will not start and immediately registered to Eureka, but registration will need to wait until the first time you send a heartbeat request. Heartbeat request transmission interval default 30s. Spring Cloud has done a modification, registration will start immediately after the service.

Based Service Consumer service instance to get information, we can call the service. The Spring Cloud also provides a wealth of tools for service calls Service Consumer:

  • Ribbon, load balancing client.
  • Hystrix, circuit breakers.
  • Feign, RESTful Web Service client, the integration of Ribbon and Hystrix.

Then we introduced one by one.

3.2 Service calls end load balancing --Ribbon

Ribbon is Netflix released an open source project, the main function is to achieve load balancing for the REST client. It mainly consists of six components:

  • ServerList, list server load balancing used. This list will be cached in the load balancer, and updated regularly. When used in conjunction with Ribbon and Eureka, ServerList implementation class is DiscoveryEnabledNIWSServerList, it will save the service instance table Eureka Server registered.
  • ServerListFilter, server list filters. This is an interface, mainly used for Service Consumer to get a list of server pre-filter, filter results also ServerList. Ribbon provided to achieve a variety of filters.
  • IPing, to detect whether the service instance survival strategy.
  • IRule, load balancing strategy, its implementation class policy statements include: polling, random, weighted in accordance with the response time and the like.

We can also define their own load balancing policies, such as our own implementation of the strategy on the use of, services to achieve a version control and direct-attached configuration. After realizing, the implementation class can be re-injected into the Ribbon.

  • ILoadBalancer, load balancer. It is also an interface, Ribbon provide a multiple implementations, such as ZoneAwareLoadBalancer. The upper code load balancing selection service call by calling its API. General ILoadBalancer implementation class references a IRule.
  • RestClient, service caller. As the name suggests, this is the load balancing, Ribbon tool REST request to initiate a Service Provider.

Ribbon will do four things at work:

  1. Preference in the same Zone and less loaded Eureka Server;
  2. Regular updates from Eureka and filtering service instance list;
  3. According to user-specified policy, select an address from Server instance to take the registration list of services;
  4. A service call by RestClient.

3.3 Service calls end blown --Hystrix

Netflix created a library called Hystrix achieve a pattern breaker. "Breaker" is a switching apparatus itself, when a service unit fails, the fault monitoring circuit breaker (similar to a blown fuse), and returns to the caller a line with expectations, the response may be processed alternatively (FallBack) instead of waiting for a long time or throw an exception caller can not handle, thus ensuring the caller to the service thread it will not be long, unnecessarily occupied, so as to avoid the spread of the fault in the distributed system, and even avalanche.

Of course, at lower frequencies the request fails, the failure MAMMALIA, or directly back to the client. Only when the number of failures reaches a threshold value (default failed five times within 20 seconds), the circuit breaker is opened and the subsequent communication is not performed, but directly returned alternative responses. Of course, the alternative responses Hystrix also can be customized by developers.

In addition to calling isolation dependent services, Hystrix also provides near real-time call monitoring ( Hystrix Dashboard ), Hystrix will continue to record execution information for all by Hystrix initiated the request, and presented to the user in the form of statistical reports and graphs, including how many successful execution of the request number, the number of failures per second and so on. Netflix realized the monitoring of these indicators by hystrix-metrics-event-stream projects. Spring Cloud also provides integrated Hystrix Dashboard, and monitoring content into visual interface, Hystrix Dashboard Wiki on a detailed description of the meaning of each indicator on the map.

3.4 Service Call-side code abstraction and encapsulation --Feign

Feign Web Service client is a declarative, its aim is to make Web Service calls easier. It integrates Ribbon and Hystrix, so that we no longer need to explicitly use these two components. Feign also provides a template for HTTP requests, through a simple interface to write and insert annotations, we can define the parameters of good information HTTP request, format, address and so on. Next, Feign completely Agent HTTP request, we just need to call the same method as the call it can complete a service request.

Feign has the following characteristics:

  • Pluggable annotation support, including Feign JAX-RS annotations and notes
  • HTTP support pluggable encoder and decoder
  • Support Hystrix and its Fallback
  • Support Ribbon load balancing
  • HTTP requests and responses supported compression

The following is a simple example of a Feign:

@SpringBootApplication
@EnableDiscoveryClient //启用Feign
@EnableFeignClients
public class Application
{
    public static void main(String[] args)
    {
        SpringApplication.run(Application.class, args);
    }
}

@FeignClient(name = "elements", fallback = ElementsFallback.class) //指定feign调用的服务和Hystrix Fallback(name即eureka的application name)
public interface Elements
{
    @RequestMapping(value = "/index")
    String index();
}

//Hystrix Fallback  
@Component
public class ElementsFallback implements Elements
{
    @Override
    public String index()
    {
        return "**************";
    }
}

//测试类
@Component  
public class TestController {
    @Autowired
    Elements elements;

    @RequestMapping(value = "/testEureka", method = RequestMethod.GET)
    public String testeureka()
    {
        return elements.index();
    }
}
复制代码

Original author: Qian Xiao Yi

Links: www.jianshu.com/p/5eac16e98...

Written in the last:

No. I welcome everyone's attention the public opening of the new [ calm as code ], mass Java-related articles, learning materials will be updated on the inside, finishing materials will be on the inside.

I feel good to write on a point of praise, plus followers chant! Point of attention, do not get lost, continuously updated! ! !

Guess you like

Origin juejin.im/post/5e69f1a5f265da574b792733