1, the preface

Considering the cost of server resources, the company is still transforming and migrating the containerized services and some middleware (MQ, DB, ES, Redis, etc.) to other computer rooms.

Then why don’t you use Ali cloud ah, Tencent cloud ah, but also use their own computer room?

Indeed, the company still has a dedicated operation and maintenance team. Due to historical reasons, the business was developing rapidly at that time. Considering data security, the company also built its own computer room. For small and medium-sized companies to do so, obviously the cost is too high, so ali Cloud is generally used. For medium and large enterprises or companies with high requirements on data security, self-built machine room maintenance is no longer a minority.

For middleware, such as Redis cache, some business also is because of historical reasons, after online is a separate application at the time, and the deployment of a cluster, but the amount is not large, so similar to this kind of circumstance, can consider to use cluster with other projects into one, this can save a part of the server resources.

Now most enterprises are microservified and containerized.

Therefore, the non-containerized business requirements are migrated to the container, the container here basically refers to the Kubernetes platform, through the container issued scheduling services, for operation and maintenance, maintenance becomes more convenient and efficient.

For R & D, the business needs to deploy services, no longer need to re-submit THE JIRA work order, go through a series of review processes, and finally you may be given a virtual machine, dependent software installation and deployment separately. The container is used, as long as the required software environment is installed in the container in advance, and the image is set up in accordance with the release specification. The process of releasing the service is dot dot dot… .

2. Online business scenario introduction

Let’s move on to today’s theme.

There is a project based on the SpringCloud architecture that uses the gateway Zuul and also uses Eureka as the registry.

Because the project has been moved to the container environment of Beijing machine room node deployment in advance, our final goal is to move to another machine room (such as Tianjin machine room).

There are two machine rooms in Beijing: MACHINE Room A and machine room B. Since they are both in Beijing, the network delay between the two machine rooms is acceptable.

Microservices are also deployed between the two rooms.

At this point, if the microservice is only deployed to the Tianjin machine room, the relationship will be as shown in the following figure:

The problem is obvious, that is, the gateway service is only in Beijing, while the micro-service is added in Tianjin machine room, which will lead to cross-room invocation, that is, the Beijing gateway calls the Micro-service in Tianjin.

Although the latency difference between ping from Beijing to Tianjin is only 3 milliseconds, the call between services is much longer.

Including the establishment of TCP connections between servers, the network overhead of data transmission, if the packet is too large, cross-room access time will be obvious.

Therefore, try to avoid cross-room access, of course, the gateway should also be migrated to tianjin machine room.

However, if you look at the bold pink lines, there are still cross-room calls from Tianjin gateway to Beijing micro service.

The interface response time may be longer if the number of concurrent visits is a little larger, the interface response body is large, or the network jitter and other scenarios.

How to solve it?

Since most services are deployed in Tianjin, the service weight of the equipment room in Tianjin can be increased

SLB configuration (nginx-like) :

Upstream {server upstream 20; Server Tianjin machine Room gateway IP 80; }Copy the code

Gateway and microservices are communicated through Eureka registry media, namely registration service pull service.

It is not enough to configure the weight at the gateway layer. At this time, there will also be a route from the Tianjin gateway to the Beijing micro service.

Eureka implements load balancing based on the Ribbon. It implements load balancing by weight. Eureka makes some modifications and supports weight modification on the interface.

Here is a screenshot of some examples:

The value next to IP is the weight value. You can enter the weight value on the page to adjust the value.

We can lower the weight of Microservices in Beijing and increase the weight of microservices in Tianjin.

The load-balancing algorithm based on weights is used to minimize cross-room calls on both sides of the gateway and microservice, but it is impossible to avoid cross-room calls.

Partitioning improvements using Eureka

The scheme described above still exists cross-machine room access for 20% of the traffic. Can we access the services of the same machine room first, and then access those of other machines if the services of the same machine room are unavailable?

The answer is yes.

We can do this with the help of the concept of regions and zones provided in the Eureka registry.

Region and zone concepts are derived from Amazon’s AWS:

Region: simply defined as a geographical region, such as Asia or North China, with no specific size limitation. Divide regions based on project requirements.

Zone: refers to an equipment room in a region. For example, if a zone is divided into Beijing and Tianjin, and Beijing has two equipment rooms, a region can be divided into three zones. Beijing can be divided into Zone1 and Zone2, and Tianjin into Zone3.

Based on the previous example, assume that only one region is set as Beijing and Tianjin.

Then we label the gateway service and micro-service in this area as zone machine room. In system operation and maintenance, the machine room is also called IDC data center.

Label the gateway service zone:

Tagged with zone for microservices:

This function is implemented on the Eureka registry. Before configuring the zone for the service, the call path is as follows:

After configuring the zone for the service, the invocation path of the routing mechanism inside the framework is as follows:

The current Eureka is deployed in Beijing. If you want the service to be accessible to the nearest machine room during registration, renewal, and pull actions, the deployment architecture will look like this:

It is assumed that the network delay is small, so two computer rooms in Beijing can use the same Eureka cluster. Tianjin can independently deploy another Eureka cluster, so that preferential routing to the same machine room access can be realized.

Key configuration for service registration

Eureka uses region and zone configurations.

spring: application: name: mananger server: port: ${EUREKA_SERVER_PORT:8011} eureka: instance: Instance-id :${EUREKA_SERVER_IP:127.0.0.1}:${server.port} # [ha-p configuration]- Zone of the current service instance Zone: ${EUREKA_SERVER_ZONE:tz-1} profiles: ${spring.profiles. Active} # enable IP, default false = "hostname prefer-ip-address: true ip-address: ${EUREKA_SERVER_IP:127.0.0.1} # [HA -p configuration]- Region client: region: ${EUREKA_SERVER_REGION:cn-bj} # [ha-p config]- enable the current service instance to preferentially discover registries in the same zone. Default is true prefer-same-zone-eureka: True # [service renewal]- allows the current service instance to fetch the registration information, default is true register-with-eureka: true # True # [ha-p config] -Zone set Availability-zones: cn-zones: true # [ha-p config] -Zone set Availability-zones: ${eureka.instance.metadata-map.zone}, zone-tj service-url: # [HA -p config] http://BJIP1:8011/eureka,http://BJIP2:8012/eureka zone-tj: http://TJIP1:8013/eureka,http://TJIP2:8014/eurekaCopy the code

prefer-same-zone-eureka :

The default value is true. The first zone in availability-Zones is found by region, and the service-URL pair is found by zone in the server registry address list. And initiate registration and heartbeat to the first URL address in the list, do not initiate operations to other URL addresses. If the first URL fails to be registered, the system sends operations to other urls in sequence. If the failure persists after a certain number of retries, the system tries again at a heartbeat interval.

eureka.instance.metadata-map.zone:

Both the service provider and consumer need to set this parameter to indicate which equipment room they belong to. Gateway services are also consumers. After being pulled from the registry to the registry, gateway services are filtered based on the zone specified in this parameter. After filtering, there are multiple instances of services in the same zone. If all services in the same zone are unavailable, services in other zones are invoked.

Also note the availability – zones under the region configuration is ${eureka. The instance. The metadata – map. Zone},… The advantage of this configuration is that once you specify eureka.instance.metadata-map.zone, this parameter will be placed in the availability zone as the first zone to access.

Zuul gateway routing partition source code analysis

Zuul, which is used by the gateway, uses the combination of the Ribbon and Eureka to make calls between services. Because the gateway is actually a service consumer, it registers with Eureka. The services in the registry pulled by the gateway, as service providers, also register with Eureka.

The outline of the request is controlled by a diagram:

Part of the core source code in the above illustration is as follows:

Pollserverlistupdate #start(Final UpdateAction Action) will pull the registry information from the Eureka registry every 30 seconds (default) to update the locally cached data structure.

Calls to the DyamicServerListLoadBalancer anonymous implementation class.

Through DyamicServerListLoadBalancer class callsupdateListOfServer()The realization of the method to update the service list, serverListImpl is DiscoveryEnabledNIWSServerList class

Inside the DiscoveryEnabledNIWSServerList class invokes obtainServersViaDiscovery () method, by means of its internal EurekaClient from Eureka registry pull service list.

Inside the filter to obtain a list of the same room (zone) services, successively is called ZonePreferenceServerListFilter and ZoneAffinityServerListFilter two filter realize zone.

Started to get the Servers there are a total of 4 records, according to debug the code, we are to get the service zone for 2, so the result is a, namely zone = “2”, that finding the same zone.

Is called after requesting the interfaceLoadBalancerContext#getServerFromLoadBalancer(...)Is called internallyILoadBalanceractualizedchooseServer()Method, and you’ll get it eventuallyzone="2"A Server in.

So how is the Server selected here?

When debugging locally, only the zones that are already available are configured, so the super.chooseserver (key) method is called directly:

BaseLoadBalancer#chooseServer(…) The parent class selects the Server method, which internally calls the specific load balancer implementation via IRule#choose(key) :

In the screenshot above, you can see MetadataWeightedRule, a class we implemented ourselves based on weight load balancing.

This implementation class inherits the ZoneAviodanceRule to make use of the zone concept. The Choose (Object key) method is overwritten and calls this.getpredicate ().geteligibleservers (…). The system uses the same filtering rules to obtain all service lists in the same equipment room (zone), and filters a Server based on the weight of each service configuration.

After obtaining the Server, the URI request address of the interface is http://IP:PORT/api/… / XXX. Json, through the underlying OkHttp implementation to complete the Http interface call process.

The Ribbon component pulls a list of services from the Eureka registry from the gateway and provides zone-based access to multiple data centers.

For service registration, ensure that services can be registered with registries in the same zone. If services are registered across zones, network delays are large, such as registry pulling and heartbeat timeout.

For service invocation, ensure that services in the same zone are invoked first. When the same zone cannot be found or services in the same zone are unavailable, services in other zones are invoked.

This paper only mentions the invocation between gateway and micro-service. In actual projects, micro-service will also call other third-party services. The problem of cross-machine room invocation should also be taken into account, so that all services can be invoked in the same machine room as far as possible to reduce network delay and improve service stability.

Welcome to pay attention to my public number, scan the TWO-DIMENSIONAL code to pay attention to unlock more wonderful articles, grow up with you ~