微服务学习,源码探究[1] 服务的注册与发现

 

        许久没有做过学习笔记了,之前挖的坑也要因为手头的事情暂告一段落。

        由于技术上的需求,最近一段时间对微服务的架构学习了许多。粗略的学习过后决定一探其中源码,究其本质在于探索一些spirng springboot springcloud中的注解以及这些注解在配置项中起到的作用。偶尔也会涉及比如hystrix的设计模式的探讨与启发。

        该博客不是科普微服务的博客,所以认为读者已经对微服务的基本架构和用法有所了解,这里只是对源码有一些自己的拙见。

 

        众所周知,spring cloud以eureka组件作为其服务的注册中心。服务注册中心起到了注册服务,分发服务的作用。提供方和消费方都不知道其中的细节。这个组件的工作方式是怎么样的呢,让我们来窥视一下源代码:

        我们从服务的客户端开始探究这个问题,道理很简单,从提供方注册服务、消费方获取服务的这个过程对我们来说比较直观。

 

/**
 * Convenience annotation for clients to enable Eureka discovery configuration
 * (specifically). Use this (optionally) in case you want discovery and know for sure that
 * it is Eureka you want. All it does is turn on discovery and let the autoconfiguration
 * find the eureka classes if they are available (i.e. you need Eureka on the classpath as
 * well).
 *
 * @author Dave Syer
 * @author Spencer Gibb
 */
@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Inherited
@EnableDiscoveryClient
public @interface EnableEurekaClient {

}

这是@EnableEurekaClient注解的源代码 。

[充电站]@Inherited注解:使子类可以继承父类的注解。

在这个注释中没有实际的代码,但是通过阅读作者留下的说明,我们大概了解到了有了这个注解,就会去加载eureka客户端的配置并且尝试发现eureka服务。

[充电站]@EnalbeDiscoveryClient注解:允许应用发现服务,这个注解和@EnableEurekaClient的区别就在于,除了Eureka还有很多的注册中心可以使用,例如大名鼎鼎的zk(zookeeper)。

我们通过DiscoveryClient类去深入了解其中的机制:

/**
 * The class that is instrumental for interactions with Eureka Server.
 *
 * 

* Eureka Client is responsible for a) Registering the * instance with Eureka Server b) Renewalof the lease with * Eureka Server c) Cancellation of the lease from * Eureka Server during shutdown *

* d) Querying the list of services/instances registered with * Eureka Server *

* *

* Eureka Client needs a configured list of Eureka Server * {@link java.net.URL}s to talk to.These {@link java.net.URL}s are typically amazon elastic eips * which do not change. All of the functions defined above fail-over to other * {@link java.net.URL}s specified in the list in the case of failure. *

* * @author Karthik Ranganathan, Greg Kim * @author Spencer Gibb * */

秉承一贯的特点,我们先看作者留下的说明文档:这个类是为了与eureka服务端做交互的。这个类起如下的作用:向服务中心注册实例、与服务中心续约、服务崩溃时解除与服务中心的注册关系、查询在服务中心已注册的可用服务清单。客户端会从配置文件中找到服务中心的地址,当且仅当所有的服务请求都失败了,才会认为这一次的请求是失败的。

从说明文档里已经很明白的了解到了类起到的作用。

接下来我们要去了解更为细节的东西,首先是获取配置的方式,至于配置的设计,在这里先不多说。(有部分方法已经被标注为过时方法,可以通过@link寻找到EndpointUtils类的相同方法)

public static List getServiceUrlsFromConfig(EurekaClientConfig clientConfig, String instanceZone, boolean preferSameZone) {
        List orderedUrls = new ArrayList();
        
        String region = getRegion(clientConfig);

        String[] availZones = clientConfig.
                getAvailabilityZones(clientConfig.getRegion());
        
        if (availZones == null || availZones.length == 0) {
            availZones = new String[1];
            availZones[0] = DEFAULT_ZONE;
        }

        int myZoneOffset = getZoneOffset(instanceZone, preferSameZone, availZones);

        List serviceUrls = clientConfig.
                getEurekaServerServiceUrls(availZones[myZoneOffset]);
        if (serviceUrls != null) {
            orderedUrls.addAll(serviceUrls);
        }

        int currentOffset = myZoneOffset == 
                (availZones.length - 1) ? 0 : (myZoneOffset + 1);

        while (currentOffset != myZoneOffset) {
            serviceUrls = clientConfig.
                getEurekaServerServiceUrls(availZones[currentOffset]);
            if (serviceUrls != null) {
                orderedUrls.addAll(serviceUrls);
            }
            if (currentOffset == (availZones.length - 1)) {
                currentOffset = 0;
            } else {
                currentOffset++;
            }
        }

        if (orderedUrls.size() < 1) {
            throw new IllegalArgumentException("DiscoveryClient: invalid serviceUrl             
                specified!");
        }
        return orderedUrls;
    }

一上来就有一个region的概念,从config对象中获取了region的信息,如果没有设置region,将会采用默认的region,也就是defaultRegion,从方法的返回值可以知道,region应该只能配置一个。

接下来就是一个zone的概念,从方法的返回值也可以知道zone是可以有多个的,并且是在这个region下的若干zone,如果没有配置,将会采用默认值也就是defaultZone。注意这里,如果设置了prefersamezone,将会有限寻找到相同的zone的偏移量,并且返回的有序列表中,该zone下的url将会在列表前段。

之后的事情就比较简单,遍历所有的zone,并且获得url,将其放到有序列表中。

看这个方法:

 public List getEurekaServerServiceUrls(String myZone) {
        String serviceUrls = configInstance.getStringProperty(
                namespace + CONFIG_EUREKA_SERVER_SERVICE_URL_PREFIX + "." + myZone,             
                null).get();
        if (serviceUrls == null || serviceUrls.isEmpty()) {
            serviceUrls = configInstance.getStringProperty(
                    namespace + CONFIG_EUREKA_SERVER_SERVICE_URL_PREFIX + ".default", 
                    null).get();

        }
        if (serviceUrls != null) {
            return Arrays.asList(serviceUrls.split(","));
        }

        return new ArrayList();
 }

配置文件中的配置,本质上由来于它解析的方式,eureka.client.serviceUrls.defaultZone就是这样的。

因此我们也可以配置自己的region、zone以及相应的url:

eureka:
  client:
    register-with-eureka: true
    fetch-registry: true
    prefer-same-zone-eureka: true
    region: beijing
    availability-zones:
      beijing: zone-1,zone-2
    service-url:
      zone-1: http://localhost:30000/eureka/
      zone-2: http://localhost:30001/eureka/

在我们使用Ribbon实现服务调用时,对于zone的设置可以在负载均衡时实现区域亲和:Ribbon的默认策略会优先访问和客户端在同一个zone里的服务端实例,只有当同一个zone里没有可用服务实例才会去访问其他zone。在这点上,我们可以设计出对区域性故障的容灾集群。

 

再来看看服务的注册:

private void initScheduledTasks() {
        if (clientConfig.shouldFetchRegistry()) {
            // registry cache refresh timer
            int registryFetchIntervalSeconds = clientConfig.getRegistryFetchIntervalSeconds();
            int expBackOffBound = clientConfig.getCacheRefreshExecutorExponentialBackOffBound();
            scheduler.schedule(
                    new TimedSupervisorTask(
                            "cacheRefresh",
                            scheduler,
                            cacheRefreshExecutor,
                            registryFetchIntervalSeconds,
                            TimeUnit.SECONDS,
                            expBackOffBound,
                            new CacheRefreshThread()
                    ),
                    registryFetchIntervalSeconds, TimeUnit.SECONDS);
        }

        if (clientConfig.shouldRegisterWithEureka()) {
            int renewalIntervalInSecs = instanceInfo.getLeaseInfo().getRenewalIntervalInSecs();
            int expBackOffBound = clientConfig.getHeartbeatExecutorExponentialBackOffBound();
            logger.info("Starting heartbeat executor: " + "renew interval is: " + renewalIntervalInSecs);

            // Heartbeat timer
            scheduler.schedule(
                    new TimedSupervisorTask(
                            "heartbeat",
                            scheduler,
                            heartbeatExecutor,
                            renewalIntervalInSecs,
                            TimeUnit.SECONDS,
                            expBackOffBound,
                            new HeartbeatThread()
                    ),
                    renewalIntervalInSecs, TimeUnit.SECONDS);

            // InstanceInfo replicator
            instanceInfoReplicator = new InstanceInfoReplicator(
                    this,
                    instanceInfo,
                    clientConfig.getInstanceInfoReplicationIntervalSeconds(),
                    2); // burstSize

            statusChangeListener = new ApplicationInfoManager.StatusChangeListener() {
                @Override
                public String getId() {
                    return "statusChangeListener";
                }

                @Override
                public void notify(StatusChangeEvent statusChangeEvent) {
                    if (InstanceStatus.DOWN == statusChangeEvent.getStatus() ||
                            InstanceStatus.DOWN == statusChangeEvent.getPreviousStatus()) {
                        // log at warn level if DOWN was involved
                        logger.warn("Saw local status change event {}", statusChangeEvent);
                    } else {
                        logger.info("Saw local status change event {}", statusChangeEvent);
                    }
                    instanceInfoReplicator.onDemandUpdate();
                }
            };

            if (clientConfig.shouldOnDemandUpdateStatusChange()) {
                applicationInfoManager.registerStatusChangeListener(statusChangeListener);
            }

            instanceInfoReplicator.start(clientConfig.getInitialInstanceInfoReplicationIntervalSeconds());
        } else {
            logger.info("Not registering with Eureka server per configuration");
        }
    }

分析第一段:clientConfig.shouldFetchRegistry()条件告诉我们,只有我们设置了registry-with-eureka=true才会触发这一段内容,其中涉及了两个参数值:registryFetchIntervalSeconds是从eureka服务端获取注册信息的时间间隔,默认30s。

                         cacheRefreshExecutorExponentialBackOffBound是缓存刷新重试延迟时间的最大乘数,不是特别重要。

那么这个计划将会在每30秒去做一次服务的注册,有注册就会有续约和获取,我们先看续约:

 boolean renew() {
        EurekaHttpResponse httpResponse;
        try {
            httpResponse = eurekaTransport.registrationClient.sendHeartBeat(instanceInfo.getAppName(), instanceInfo.getId(), instanceInfo, null);
            logger.debug("{} - Heartbeat status: {}", PREFIX + appPathIdentifier, httpResponse.getStatusCode());
            if (httpResponse.getStatusCode() == 404) {
                REREGISTER_COUNTER.increment();
                logger.info("{} - Re-registering apps/{}", PREFIX + appPathIdentifier, instanceInfo.getAppName());
                return register();
            }
            return httpResponse.getStatusCode() == 200;
        } catch (Throwable e) {
            logger.error("{} - was unable to send heartbeat!", PREFIX + appPathIdentifier, e);
            return false;
        }
    }

可以发现,本质上是一个http请求,像中心发送请求,其实服务的获取、注册等操作也是以rest请求做成的。

 

本章分析完后,将会自己制作一个简单的类eureka服务注册机制,以进一步体会其中的设计和参数必要性。

 

你可能感兴趣的:(读书笔记)