Eureka在相互注册形成高可用时DS Replicas为空

Eureka在相互注册形成高可用时DS Replicas为空›

原本在同一台服务器上，以不同的端口来搭建集群，ip 或者 主机名相同时，无法形成副本。所以将其中一台迁移到了另外的服务器上了

使用Eureka做服务发现

Zookeeper做注册中心的缺陷

Peter Kelley(个性化教育初创公司Knewton的一名软件工程师)发表了一篇文章说明为什么ZooKeeper用于服务发现是一个错误的做法，他主要提出了三个缺点[1]：

ZooKeeper无法很好的处理网络分区问题，当网络分区中的客户端节点无法到达Quorum时，会与ZooKeeper失去联系，从而也就无法使用其服务发现机制。

服务发现系统应该是一个AP系统，设计上针对可用性；而ZooKeeper是一个CP系统。

ZooKeeper的设置和维护非常困难，实际操作的时候也容易出错，比如在客户端重建Watcher，处理Session和异常的时候。

当然，Peter Kelley提出的这几个问题并不是不能克服的，并不能说明基于ZooKeeper就不能做好一个服务发现系统，但是我们可能有更简洁的方案来实现。

Eureka介绍

什么是Eureka

官方的介绍在这里Eureka wiki。Eureka是Netflix开源的一个RESTful服务，主要用于服务的注册发现。Eureka由两个组件组成：Eureka服务器和Eureka客户端。Eureka服务器用作服务注册服务器。Eureka客户端是一个java客户端，用来简化与服务器的交互、作为轮询负载均衡器，并提供服务的故障切换支持。Netflix在其生产环境中使用的是另外的客户端，它提供基于流量、资源利用率以及出错状态的加权负载均衡。

在我看来，Eureka的吸引力来源于以下几点：

开源：大家可以对实现一探究竟，甚至修改源码。

可靠：经过Netflix多年的生产环境考验，使用应该比较靠谱省心

功能齐全：不但提供了完整的注册发现服务，还有Ribbon等可以配合使用的服务。

基于Java：对于Java程序员来说，使用起来，心里比较有底。

spring cloud可以使用Spring Cloud, 与Eureka进行了很好的集成，使用起来非常方便。

Eureka架构

Netflix主要是在AWS中使用Eureka的，虽然同时也支持本地环境，但是了解AWS的一些基础概念对于理解Eureka的设计非常有帮助。

按Alt + 回车键，将会生成eureka-serverzip，解压缩后得到一个maven 项目，将该项目录入IDE。

我们首先来看一下pom文件，可以看出项目中引用了spring-cloud-starter-netflix-eureka-server, 并且springboot 的版本号为：212RELEASE, Spring Cloud的版本号为：GreenwichRC2RC2 表示还没有正式发布，只是第二个Release Candidate。

接下来我们只需要两个步骤，

a、修改EurekaServerApplication, 在@SpringBootApplication的注解上面，加入一个新的注解：@EnableEurekaServer

b、在resources 目录中加入applicationyml 文件， 并配置以下信息：

一个简单的Eureka 注册中心就已经可以使用了，我们运行一下这个spring boot 应用，找开浏览器：localhost:8761，即可看到我们的注册中心就已经运行启来了。并且EUREKA-SERVER也注册到自己的注册中心了。

单节点的注册中心已经搭建完毕，但单节点的注册中心存在单点故障的可能，不能用于生产环境。生产环境的Eureka一般采用集群方式进行部署。

通过clientserviceUrldefaultZone配置多个peer节点，因为是在单机上测试，所以修改了host文件，并且使用不同的端口号来启动注册中心。正式的生产环境请根据自己的实际情况进行配置，比如：第一台Eureka的IP地址为：1921680100，则defaultZone配置其他三台注册中心http://1921680101:8761/eureka/,http://1921680102:8761/eureka/,http://1921680103:8761/eureka/

依次启动4台注册中心，打开网页:http://localhost:8764

可以看到其它三台注册中心已经出现在已注册的replicas和可用的replicas列表里边。

如上图所示，4台注册中心，每台注册中心需要配置其他三台服务器，以Eureka 1为例，其配置如下：

注册中心是本应该是无状态的，可以横向扩展。但由于每台注册中心的配置都不一样，所以扩展起来比较麻烦，需要修改配置文件，这样就无法做到快速的扩容。

微服务客户端需要配置注册中心的地址，使用的是如下的配置：

由于配置的是固定的IP地址，如果我们要扩容注册中心，增加新的注册中心节点，那我们就需要修改微服务客户端的配置文件，将新的注册中心节点进入的服务器列表中。试想一下，如果有几十个微服务，每个微服务有4个节点，那将会要修改上百个配置文件。很显然这种方式不太可取，从软件设计角度来说，违反了开闭原则。

其实Eureka 注册中心还有另一种高可用配置方式，基于DNS。Eureka天生就可以部署在像AWS这样的公有云上，并且可以跨Region，跨Available Zone部署。虽然我们不用部署在云端，依然可以利用这一特性，我们可以把Region看作我们数据中心的机房，Avaiable Zone 看作是机房中的网络区域，结合内部DNS服务来实现高可用的注册中心。

画重点：

a region: default，配置地区

b useDnsForFetchingServiceUrls，表示基于DNS获取服务信息

c eurekaServerDNSName: eurekatxzqcomcn，配置域名服务器名称

键：txtdefaulteurekatxzqcomcn 值：shenzheneurekatxzqcomcn

键：txtshenzheneurekatxzqcomcn 值：17218101 17218102 17218103 17218104

第一条记录表示，default 区域，包含了哪些可用区，我们用shenzhen表示是深圳机房，txt记录的值就设置为：shenzheneurekatxzqcomcn

第二第记录表示 , shenzhen机房有哪些服务器，多台服务器使用空格格开。

如果在本地测试，需要搭建一台自己的DNS服务器，可以参考我的另一篇文章： 基于Docker快速搭建DNS Server

Client View是指DNS服务应用到哪一个网段，比如：17218100/24网段的IP连接到BIND服务器，才会解析指定的域名。

在添加域名的时候，需要指定Client View，这里我们选择我们刚刚创建的View_17218100，指的是只有在这个网段的IP访问这台DNS服务器，才能解析。

添加完一级域名后我们刷一下这个ZONE，然后设置一下本地DNS服务器

DNS域名服务器验证通过后，我们接下来就可以在为这个域名添加我们所需要的txt 记录了。

到这里我们的准备工作就已经基本完成了。使用Maven将注册中心编译成，输出jar包。新建一个Eureka的docker镜像，并启动4个容器。基于DNS的注册中心就搭建完毕了。

你只需要对DNS记录进行变更，就可以实现动态的、快速扩容/缩容了。

关于如何将Eureka部署到Docker，请参考另一篇文章：

一、服务注册中心的由来

假如没有服务注册中心，我们会干些什么事情呢？

在传统行业的项目架构中以下的方案最为常见了：

这种架构开发、部署都是最简单的，一般适用于中小企业访问量并不是太多的情况下，各个系统服务一台机器就搞定了。系统之间的调用也是拿到对方的IP+PORT直接连接。

接下来可能因为应用B开始访问量大了，单台机器已经不能满足我们的需求，于是一些反向代理工具应运而出，其中比较常见的有Apache、Nigix，架构演变为：

相比之前的应用B的单台机器访问，这种nginx代理的方式减轻了服务器的压力，但是可能会出现Nginx挂了，那么整个服务也不可用，于是又来了这么一套架构：

这样看方案算是完美了吧。然后事情并不是想象的那么一帆风顺，这还只是应用A调用一个应用B，如果应用A调用的可能是应用B、C、D、E，这种完全就不知道他后面到底还想干嘛，这种架构看似可以，但是绝对会累死运维的（nginx的配置将会非常混乱，直接导致运维不干了）。

服务注册中心干些什么事情呢？

上面提到的那种靠人力（主要是运维干的事情）比较繁琐，还不好维护，有这么几点不方便：应用服务的地址变了、双十一搞活动服务器新增等等。那么我们可以有这么的一种架构：

    服务注册中心主要是维护各个应用服务的ip+port列表，并保持与各应用服务的通讯，在一定时间间隔内进行心跳检测，如果心跳不能到达则对服务IP列表进行剔除，并同时通知给其它应用服务进行更新。同样要是有新增的服务进来，应用服务会向注册中心进行注册，服务注册中心将通知给其它应用进行更新。每个应用都有需要调用对应应用服务的地址列表，这样在进行调用时只要处理客户负载杂均衡即可。

二、微服务注册中心

1Zookeeper

ZooKeeper是一个分布式的，开放源码的分布式应用程序协调服务，是Google的Chubby一个开源的实现，是Hadoop和Hbase的重要组件。它是一个为分布式应用提供一致性服务的软件，提供的功能包括：配置维护、域名服务、分布式同步、组服务等。

上面的话直接摘抄的内容，国内很多公司做分布式开发最初的选型大部分都是采用dubbo框架。dubbo框架注册中心主要使用zookeeper。zookeeper服务端与客户端的底层通讯为netty。zookeeper采用CAP理论中的CP，一般集群部署最少需要3台机器。

2Euraka

先来看一下euraka的架构图：

Register：服务注册

当Eureka客户端向Eureka Server注册时，它提供自身的元数据，比如IP地址、端口，运行状况指示符URL，主页等。

Renew：服务续约

Eureka客户会每隔30秒发送一次心跳来续约。 通过续约来告知Eureka Server该Eureka客户仍然存在，没有出现问题。 正常情况下，如果Eureka Server在90秒没有收到Eureka客户的续约，它会将实例从其注册表中删除。 建议不要更改续约间隔。

Fetch Registries：获取注册列表信息

Eureka客户端从服务器获取注册表信息，并将其缓存在本地。客户端会使用该信息查找其他服务，从而进行远程调用。该注册列表信息定期（每30秒钟）更新一次。每次返回注册列表信息可能与Eureka客户端的缓存信息不同， Eureka客户端自动处理。如果由于某种原因导致注册列表信息不能及时匹配，Eureka客户端则会重新获取整个注册表信息。 Eureka服务器缓存注册列表信息，整个注册表以及每个应用程序的信息进行了压缩，压缩内容和没有压缩的内容完全相同。Eureka客户端和Eureka 服务器可以使用JSON / XML格式进行通讯。在默认的情况下Eureka客户端使用压缩JSON格式来获取注册列表的信息。

Cancel：服务下线

Eureka客户端在程序关闭时向Eureka服务器发送取消请求。 发送请求后，该客户端实例信息将从服务器的实例注册表中删除。该下线请求不会自动完成，它需要调用以下内容：

DiscoveryManagergetInstance()shutdownComponent()；

Eviction 服务剔除

在默认的情况下，当Eureka客户端连续90秒没有向Eureka服务器发送服务续约，即心跳，Eureka服务器会将该服务实例从服务注册列表删除，即服务剔除。

自我保护机制：

既然Eureka Server会定时剔除超时没有续约的服务，那就有可能出现一种场景，网络一段时间内发生了 异常，所有的服务都没能够进行续约，Eureka Server就把所有的服务都剔除了，这样显然不太合理。所以，就有了 自我保护机制，当短时间内，统计续约失败的比例，如果达到一定阈值，则会触发自我保护的机制，在该机制下， Eureka Server不会剔除任何的微服务，等到正常后，再退出自我保护机制。自我保护开关(eurekaserverenableself-preservation: false)

3Consul

consul推荐的架构图：

Consul不像Euraka的部署那么简单，他是go语言开发的，需要运维单独部署，有提供java的客户端连接，采用的是CAP的CP。

4Nacos

    Euraka是Spring Cloud Netflix早期版本中推荐使用的，后来euraka10版本不再维护，euraka20已经闭源，导致很多新项目基于Spring Cloud Netflix 开发的选型变迁为Consul

Nacos是阿里开源的服务注册中心，它可以与spring cloud aliaba集成使用。

Nacos的官方介绍：

    Nacos 致力于帮助您发现、配置和管理微服务。Nacos 提供了一组简单易用的特性集，帮助您实现动态服务发现、服务配置管理、服务及流量管理。

    Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。 Nacos 是构建以“服务”为中心的现代应用架构(例如微服务范式、云原生范式)的服务基础设施。

Nacos 地图

Nacos 生态图

如 Nacos 全景图所示，Nacos 无缝支持一些主流的开源生态，例如

Spring Cloud

Apache Dubbo and Dubbo Mesh TODO

Kubernetes and CNCF TODO

三、服务注册与发现技术选型

以下是来自网上的一个分享：

除了上述的几种以外，笔者更推荐使用Nacos作为服务注册中心。

推荐理由：

Nacos服务注册表结构Map<namespace, Map<group::serviceName, Service>>采用多层次Map结构，控制的颗粒度更细，支持金丝雀模式发布，心跳同步机制也更快速，服务更新更及时。

1 Linux 服务器安装宝塔面板

2使用ssh root@ip 的方式远程连接

3安装Docker ,参考: http://wwwxiefengorg/id=3 中的Docker安装

1项目中 eureka 配置需加上: prefer-ip-address: true 具体配置列如:

2其余微服务的yml文件中也需配置:prefer-ip-address: true 具体配置列如:

3微服务的pomxml文件,配置打包插件,具体配置列如:

4编译项目并打包 ,使用idea自带的打包方式 : 右侧Maven按钮 -> 项目[root]->双击package ->打包成功,获取jar包;

1在服务器非系统盘符中(如果有)创建对应文件夹,以项目为例如下:

1)  mhxs-eureka-server (eureka注册与发现)

2)  mhxs-web-comment-api (客户端)

3)  mhxs-web-novel-api (客户端)

4)  mhxs-web-user-api (客户端)

5)  mhxs-gateway (网关zuul,集成了swagger2)

2上传对应的jar文件到对应对应的文件夹中

3在对应文件夹中的分别创建Dockerfile文件,并编辑内容例如:

注1:其中微服务jar包修改了版本(如:xx-1jar,xxx-2jar,xxx-3jar,),对应文件夹下的同理修改,目的是为了方便后期版本回退

注2:注意修改对应的jar名称和端口

4编写创建镜像的脚本文件 : build_imagessh 和 相应jar文件夹一级,具体内容列如:

注:其中modules中的为对应的 jar文件夹名称

5使用ssh连接到linux服务器,进入到build_imagesh 文件夹下,创建Docker镜像,操作如下:

6查看镜像

7在jar包文件夹同一层中创建启动镜像脚本:start_servicessh具体内容例如:

注1: 其中CODE用于检测对应服务是否已经启动成功,需根据具体项目修改

注2: 启动方式分为全顺序启动和非全顺序启动

8: 查看镜像容器:

9:更新jar:

10查看日志，有两种方法

1）直接通过宝塔面板可以找到对应日志位置：

2） 使用命令查看

一、并发是一种需求，以下先介绍一下javaweb对于高并发的处理思路：

1、synchronized 关键字

可用来给对象和方法或者代码块加锁，当它锁定一个方法或者一个代码块的时候，同一时刻最多只有一个线程执行这段代码。可能锁对象包括： this， 临界资源对象，Class 类对象

2、同步方法

同步方法锁定的是当前对象。当多线程通过同一个对象引用多次调用当前同步方法时， 需同步执行。

3、同步代码块

同步代码块的同步粒度更加细致，是商业开发中推荐的编程方式。可以定位到具体的同步位置，而不是简单的将方法整体实现同步逻辑。在效率上，相对更高。

A）锁定临界对象

同步代码块在执行时，是锁定 object 对象。当多个线程调用同一个方法时，锁定对象不变的情况下，需同步执行。

B）锁定当前对象

4、锁的底层实现

Java 虚拟机中的同步(Synchronization)基于进入和退出管程(Monitor)对象实现。同步方法 并不是由 monitor enter 和 monitor exit 指令来实现同步的，而是由方法调用指令读取运行时常量池中方法的 ACC_SYNCHRONIZED 标志来隐式实现的。

5、锁的种类

Java 中锁的种类大致分为偏向锁，自旋锁，轻量级锁，重量级锁。

锁的使用方式为：先提供偏向锁，如果不满足的时候，升级为轻量级锁，再不满足，升级为重量级锁。自旋锁是一个过渡的锁状态，不是一种实际的锁类型。

锁只能升级，不能降级。

6、volatile 关键字

变量的线程可见性。在 CPU 计算过程中，会将计算过程需要的数据加载到 CPU 计算缓存中，当 CPU 计算中断时，有可能刷新缓存，重新读取内存中的数据。在线程运行的过程中，如果某变量被其他线程修改，可能造成数据不一致的情况，从而导致结果错误。而 volatile 修饰的变量是线程可见的，当 JVM 解释 volatile 修饰的变量时，会通知 CPU，在计算过程中， 每次使用变量参与计算时，都会检查内存中的数据是否发生变化，而不是一直使用 CPU 缓存中的数据，可以保证计算结果的正确。

更多、此外还有很多细节需要通过学习去了解和完善，此处就不一一列举了。

二、并发框架

并发框架很多，如ExecutorService、RxJava、Disruptor、Akka等，具体选择哪个（或者都不选择）是根据项目需求选择的，框架本身的差异并不大，基本都是如下模式