Welcome to Hexo! This is your very first post. Check documentation for more info. If you get any problems when using Hexo, you can find the answer in troubleshooting or you can ask me on GitHub.
1 | $ hexo new "My New Post" |
More info: Writing
1 | $ hexo server |
More info: Server
1 | $ hexo generate |
More info: Generating
1 | $ hexo deploy |
More info: Deployment
以centos为例，下载jar包，tar -zxvf xxx解压后，进入activemq解压文件夹，执行./bin/activemq console即可在shell前端启动，想后台运行的话执行./bin/activemq start即可。
官方文档在这里，很简单：http://activemq.apache.org/getting-started
报错信息如下：
1 | Caused by: java.lang.IllegalStateException: BeanFactory not initialized or already closed - call 'refresh' before accessing beans via the ApplicationContext |
1.确认计算机主机名名称没有下划线
2.如果是win7，停止ICS(运行–>services.msc找到Internet Connection Sharing (ICS)服务,改成手动启动或禁用)
修改conf/jetty.xml，注释掉host属性这行：
1 | |
重新启动activemq即可
spring cloud gateway（后续简称SCG）本身就是spring cloud体系的一员，在对于java技术栈的系统使用起来比较方便，此外，SCG扩展性比较好，适合作为业务网关的基础、根据自身需求进行二次开发。
灰度发布
请求限流
服务容错
监控
故障排查
mysql安装有多种方式：
具体详细参考官网 （https://dev.mysql.com/doc/refman/5.7/en/installing.html）
- mysql的安装方法有多种，如二进制安装、源码编译安装、yum安装;
- yum安装都是默认路径，不利于后期维护，安装相对简单；
- 源码安装编译的过程比较长，若没有对源码进行修改且要求使用mysql较高版本；
建议使用二进制安装，比较方便后期维护。本文就是采用这种方式启动多个实例。
本文在centos 7.5下进行操作。
下载mysql 压缩包，注意需要下载二进制包。下载地址
centos 下可以使用如下命令：
1 | wget https://cdn.mysql.com//Downloads/MySQL-5.7/mysql-5.7.32-el7-x86_64.tar.gz |
解压，移动到/usr/local/文件夹下：
1 | tar -zxvf mysql-5.7.32-el7-x86_64.tar.gz |
创建一个mysql用户组及用户，且这个用户是不可登录的 创建用户组：groupadd mysql 创建不可登录用户：useradd -g mysql -s /sbin/nologin -d /opt/mysql mysql 查看下创建后的用户信息：id msyql
1 | id mysql |
此处我选择使用在/data/mysql文件夹下保存数据、日志，因此按如下结构创建目录（我打算启动2个实例），命令略去：
1 | -data |
1 | chown -R mysql:mysql /data/mysql/ |
1 | echo 'export PATH=$PATH:/usr/local/mysql/bin' >> /etc/profile |
找一个mysql配置文件my.cnf，如果没有可以手工创建，位置放在：
1 | /etc/my_3307.cnf |
下面给出一个mysql配置文件参考，请按需修改：
1 | # my_3307.cnf |
1 | cd /usr/local/mysql/ |
1 | GRANT ALL PRIVILEGES ON *.* TO 'root'@'%' IDENTIFIED BY 'password' WITH GRANT OPTION; |
这样就能成功启动一个实例，接下来同样的操作，即可启动多个实例。
腾讯云标准型SA2
使用sysbench。
此处偷懒了，直接使用了sysbench默认的脚本创建数据库表，如果需要测试特定的表，需要修改/usr/share/sysbench下的脚本，基本只需要修改oltp_common.lua脚本即可，这个需要花时间细致的修改，这次就不在这方面多花时间了。本次主要目的是做基准测试、看看Mysql性能。
1 | sysbench --db-driver=mysql --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-password=1qaz@WSX --mysql-db=sbtest --table_size=1000000 --tables=10 --events=0 --time=300 --threads=20 oltp_read_write prepare |
执行命令：
1 | sysbench --db-driver=mysql --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-password=1qaz@WSX --mysql-db=sbtest --table_size=1000000 --tables=10 --events=0 --time=300 --threads=20 --percentile=95 --report-interval=10 oltp_read_write run |
参数说明：
注意此处没有预热，先观察下没有预热情况下的读写性能，得到如下执行结果：
1 | [root@VM_0_5_centos ~]# sysbench --db-driver=mysql --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-password=1qaz@WSX --mysql-db=sbtest --table_size=1000000 --tables=10 --events=0 --time=300 --threads=20 --percentile=95 --report-interval=10 oltp_read_write run |
在第一次执行完成后，再一次执行相同的压测命令：
1 | sysbench --db-driver=mysql --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-password=1qaz@WSX --mysql-db=sbtest --table_size=1000000 --tables=10 --events=0 --time=300 --threads=20 --percentile=95 --report-interval=10 oltp_read_write run |
也就是说，将第一次执行当做预热，然后得到了如下结果：
1 | [root@VM_0_5_centos ~]# sysbench --db-driver=mysql --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-password=1qaz@WSX --mysql-db=sbtest --table_size=1000000 --tables=10 --events=0 --time=300 --threads=20 --percentile=95 --report-interval=10 oltp_read_write run |
还是这条命令，再次执行看下：
1 | sysbench --db-driver=mysql --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-password=1qaz@WSX --mysql-db=sbtest --table_size=1000000 --tables=10 --events=0 --time=300 --threads=20 --percentile=95 --report-interval=10 oltp_read_write run |
最后执行结果如下：
1 | [root@VM_0_5_centos ~]# sysbench --db-driver=mysql --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-password=1qaz@WSX --mysql-db=sbtest --table_size=1000000 --tables=10 --events=0 --time=300 --threads=20 --percentile=95 --report-interval=10 oltp_read_write run |
使用如下命令清理数据
1 | sysbench --db-driver=mysql --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-password=1qaz@WSX --mysql-db=sbtest --table_size=1000000 --tables=10 --events=0 --time=300 --threads=20 --percentile=95 oltp_read_write cleanup |
使用
1 | sysbench --db-driver=mysql --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-password=1qaz@WSX --mysql-db=sbtest --table_size=1000000 --tables=10 --events=0 --time=300 --threads=20 oltp_read_write help |
可以看到oltp_read_write脚本所支持的参数，如下所示：
1 | [root@VM_0_5_centos ~]# sysbench --db-driver=mysql --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-password=1qaz@WSX --mysql-db=sbtest --table_size=1000000 --tables=10 --events=0 --time=300 --threads=20 oltp_read_write help |
此处我们指定下数据库存储引擎为myisam，执行：
1 | sysbench --db-driver=mysql --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-password=1qaz@WSX --mysql-db=sbtest --table_size=1000000 --tables=10 --events=0 --time=300 --threads=20 oltp_read_write --mysql_storage_engine=myisam prepare |
即可创建MyIsam的表。
执行命令
1 | sysbench --db-driver=mysql --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-password=1qaz@WSX --mysql-db=sbtest --table_size=1000000 --tables=10 --events=0 --time=300 --threads=20 --percentile=95 --report-interval=10 oltp_read_write --mysql_storage_engine=myisam run |
测试结果如下：
1 | ...... |
相同命令，再来一次：
1 | ...... |
1 | ······ |
1 | sysbench --db-driver=mysql --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-password=1qaz@WSX --mysql-db=sbtest --table_size=1000000 --tables=10 --events=0 --time=300 --threads=20 oltp_read_write cleanup |
| 压测指标 | InnoDB | MyISAM | |
|---|---|---|---|
| 第一次 | 读、写次数 | 读：527282 写：150652 其他：75326 事务：37663 总计：753260 | 读：722036 写：206294 其他：103150 总计：1031480 |
| 耗时 | 最小：7.13ms 平均：159.35ms 最大：873.88ms 95分位数：292.60ms | 最小：2.91ms 平均：116.36ms 最大：2703.01ms 95分位数：153.02ms | |
| 吞吐量 | 1883.1500 | 2578.7000 | |
| 第二次 | 读、写次数 | 读：574434 写：164124 其他：82062 事务：41031 总计：820620 | 读：697480 写：199279 其他：99641 总计：996400 |
| 耗时 | 最小：6.62ms 平均：146.24ms 最大：709.59ms 95分位数：262.64ms | 最小：2.86ms 平均：120.45ms 最大：3435.92ms 95分位数：176.73ms | |
| 吞吐量 | 2051.5500 | 2491.0000 | |
| 第三次 | 读、写次数 | 读：595840 写：170240 其他：85120 事务：42560 总计：851200 | 读：680372 写：194389 其他：97199 总计：971960 |
| 耗时 | 最小：6.18ms 平均：141.02ms 最大：687.11ms 95分位数：257.95ms | 最小：2.88ms 平均：123.52ms 最大：2916.81ms 95分位数：189.93ms | |
| 吞吐量 | 2128.0000 | 2429.9000 | |
经过预热之后，可以看到InnoDB的性能越来越好，每秒能处理2000多请求。不排除预热充分后能反超MyISAM的可能性，不过这个我就没继续多测试了。
MyISAM每秒能处理2500左右。
从目前做的测试来看，InnoDB在读写性能上还是不及MyISAM，不排除预热充分后能反超MyISAM的可能性，不过这个我就没继续多测试了。
可以将sysbench压测结果输出日志、然后绘制成图片，这样看着更高大上、更加直观。可以参考这篇文章：https://yq.aliyun.com/articles/498680
1 | sysbench --db-driver=mysql --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-password=1qaz@WSX --mysql-db=sbtest --table_size=1000000 --tables=10 --events=0 --time=300 --threads=20 --percentile=95 --report-interval=10 oltp_read_write prewarm |
但有报如下错误，时间有限，没仔细排查：
1 | [root@VM_0_5_centos ~]# sysbench --db-driver=mysql --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-password=1qaz@WSX --mysql-db=sbtest --table_size=1000000 --tables=10 --events=0 --time=300 --threads=20 --percentile=95 --report-interval=10 oltp_read_write prewarm |
示例：
1 | public class A { |
大概多数人都会遇到这么一个坑，如果使用spring的@Transactional给A类中的某个业务方法serviceA()加事务，在controller层直接调用serviceA()时，该方法的事务注解能正常生效；但如果在A类中的serviceB()调用serviceA()，并且servcieB没有加事务@Transactional，那么此时实际上serviceA()上的@Transactional并未生效。
想讲清这个问题就必须了解spring AOP的内部实现原理。
在spring中经常使用自定义注解或是spring已封装好的注解，通过AOP的方式复用代码、避免重复劳动。而spring实现AOP是通过动态代理来实现的，默认有接口的情况使用JDK的动态代理（也可以通过配置proxyTargetClass来指定使用CGLIB）、没有接口的情况使用CGLIB。
但无论是哪一种代理，都是在原有方法的外面包一层、在方法外的代理层来实现AOP的逻辑。以上面为例，在代理后会在serviceA()外层增加事务相关逻辑：
1 | //原始代码 |
但这个前提就是spring直接调用加了注解的方法才会调用代理方法，如果serviceA被同一个类内部其他方法调用，那servcieA()就只是一段普通代码、AOP相关的信息不会被spring看到，那自然就无法执行AOP的逻辑。
知道原理后，自然也就好解决了。
AOP的逻辑在代理后的方法中，那么我们就去执行spring生成的代理后的方法。获取方法如下：
这个有点取巧。还是以上面serviceB()为例，我们如果调用this.serviceA()，this指向对象本身、不会指向代理后的对象，因此肯定不可以，但我们可以让spring提供给我们代理后的对象：
1 | public class A{ |
获取ApplicationContext有多种方法：
1 | public class A { |
使用AopContext.currentProxy()注意必须在程序启动时开启EnableAspectJAutoProxy注解，设置代理暴露方式为true，如下面所示：
1 | /** |
通过spring生命周期，直接将ApplicationContext注入进来：
1 | public class A implements ApplicationContextAware { |
事情是这样子的：
我想自定义一个缓存注解，用来缓存方法返回值，并且支持自定义缓存超时时间，注解定义是这样：
1 | |
本来只想写一个expireTime，但想着大家肯定能偷懒尽量偷懒嘛，那最好还是支持 @MyCache(50) 这种写法、省去一步。于是也有了上面的写法，使用spring提供的@AliasFor，显式的定义两个属性互为别名，目的就是如果不在注解中指定属性，则默认就是将值给到超时时间expireTime。
这样写也是看了spring里@Transactional注解的定义，按道理，应该是我配置了 @MyCache(50) 后，我在Advice代码中取这个注解的expireTime属性值时，应该是拿到value的值，即50，但实际效果却不是这样，expireTime的值仍为默认的60。
而我取值的代码如下：
1 | @Around("myCache()") |
获取注解这一步有问题，@AliasFor是spring提供的注解，想要保证获取属性值能感知到，需要使用spring提供的工具方法获得注解，如下所示：
1 | ...... |
类似这样：
1 | @MyCache(expireTime = 40, value = 50) |
**程序直接无法启动！**会报如下异常：
1 | ...... |
在raft中，服务器节点共有3种状态（或者说角色）：
leader
follower
candidate
3种状态的流转参见此图：
Raft采用复制状态机(state machine replication)模型，通过复制日志来保证状态的一致性，详细内容参见wiki https://en.wikipedia.org/wiki/State_machine_replication 基本思想是：
复制状态机机制可以参考这张图：
先看 动画演示 http://thesecretlivesofdata.com/raft/
Raft中使用心跳机制来出发leader选举。当服务器启动的时候，服务器成为follower。只要follower从leader或者candidate收到有效的RPCs就会保持follower状态。如果follower在一段时间内（该段时间被称为election timeout）没有收到消息，则它会假设当前没有可用的leader，然后开启选举新leader的流程。
Raft算法将时间划分成为任意不同长度的任期（term），任期用连续的数字进行表示。每一个任期的开始都是一次选举（election），一个或多个候选人会试图成为领导人。如果一个候选人赢得了选举，它就会在该任期的剩余时间担任领导人。在某些情况下，选票会被瓜分，有可能没有选出领导人，那么，将会开始另一个任期，并且立刻开始下一次选举。Raft 算法保证在给定的一个任期最多只有一个领导人。
Raft 算法中服务器节点之间通信使用远程过程调用（RPCs），并且基本的一致性算法只需要两种类型的 RPCs，为了在服务器之间传输快照增加了第三种 RPC。
RPC有三种：
（1）follower增加当前的term，转变为candidate。 （2）candidate投票给自己，并发送RequestVote RPC给集群中的其他服务器。 （3）收到RequestVote的服务器，在同一term中只会按照先到先得投票给至多一个candidate。且只会投票给log至少和自身一样新的candidate。
一个节点node1发起选举后，会发生如下3种情况中的一种：
从follower状态成为candidate状态需要等待的时间。在这个时间内，节点必须等待，不能成为candidate状态。
该超时时长随机，在150ms-300ms之间，超时后，follower将成为candidate，启动一个新的election term，并投自己一票，并发送request vote 给其他节点。如果接收到的节点在当前term中还未投票（vote），就会将投票给这个candidate，并重置自己的election timeout。
心跳超时时间。candidate获得多数选票后将会变成leader，leader将开始发送append entries消息给它的follower，这是一个心跳消息，可能为空，也可能带有需要复制的日志数据，这类消息在heartbeat timeout时间间隔内发送；follower将会响应每个append entries。如果超过心跳超时时间内，follower没收到leader的消息，将会认为leader挂掉、会开始新的选举周期。
有关append entries的解析，可以参考这篇：Raft系列文章之三：Raft RPC详解
另一方面，这也说明，日志数据实际上都是跟着心跳消息发送给follower的，并不是说client发起一个修改、leader就立马开始同步数据。参见下文“日志复制”相关。
上述”3.选举流程”中的情况c.，最典型的就是split vote，当两个节点同时转变为candidate、发起选举时，就会出现该情况。
假设4个节点的情况，A B分别发起选举，两个节点在同一个term中启动election，并且这两个vote都在对方之前抵达一个单独的节点，此时A B分别拿到2个投票（包括自己投自己的那一票）、且在这个term中不会有更多votes，两个节点都没拿到多数选票。这些节点将会等待、在下个term中启动选举。由于选举超时时间(election timeout)是随机的，这两个candidate节点不可能每次election timeout时间都相同，也就可以保证这个选举过程最终会选出一个leader。
日志复制（Log Replication）主要作用是用于保证节点的一致性，这阶段所做的操作也是为了保证一致性与高可用性。
注意，在Raft中的日志，是指可能引起状态变化的操作，查看操作不引起状态变化、并不包含在下面讨论的日志范围内。
当leader选举出来后便开始负责客户端的请求，所有事务（更新操作）请求都必须先经过leader处理，日志复制（Log Replication）就是为了保证执行相同的操作序列所做的工作。
leader需要将所有数据变化复制给系统中所有节点。这需要用到在维持心跳中用到的append entries消息。
整体流程如下：
可以参考这篇Raft 日志复制 Log replication
Raft在面对网络分区问题时仍能保证一致性。 假设，由于网络分区，导致一个Raft集群分成了两部分，有2个leader
此时若有client去更新数据，如果分区内能够达到整个集群的多数，就能commit成功，但可能出现以给一个分区提交成功、另外一个分区的节点无感知。 如
故障恢复时，重新接入的分区会比较election term，比较高版本的leader的日志，使得自身的版本与新版本一致
这样整个集群将会恢复成一致的状态。
Raft算法的论文相比Paxos直观很多，更容易在工程上实现。
目前Raft算法实现已经很多，参见: https://raft.github.io/#implementations
典型的如etcd、nacos等。
etcd目标是构建一个高可用的分布式键值（key-value）数据库，基于 Go 语言实现。Etcd 主要用途是共享配置和服务发现，实现一致性使用了Raft算法。
etcd参见https://etcd.io/
本文主要参考、整理自 https://www.cnblogs.com/binyue/p/8647733.html 这篇文章还有一些内容不错，引用如下：
三、Raft和Paxos的工程应用
……
2.Zookeeper 中的 Paxos
Zookeeper 使用了一种修改后的 Paxos 协议。
在 Zookeeper 中，始终分为两种场景:
- Leader activation
在这个场景里，系统中缺乏 Leader(primary)，通过一个类似 paxos 协议的过程完成 Leader 选举。
- Active messaging 在 这个场景里，Leader 接收客户端发送的更新操作，以一种类似两阶段提交的过程在各个 follower (secondary)节点上进行更新操作。
在 Leader activation 场景中完成 leader 选举及数据同步后，系统转入 Active messaging 场景，在 active messaging 中 leader 异常后，系统转入 Leader activation 场景。
无论在那种场景，Zookeeper 依赖于一个全局版本号:zxid。zxid 由(epoch, count)两部分组成， 高位的 epoch 部分是选举编号，每次提议进行新的 leader 选举时 epoch 都会增加，低位的 count 部分 是 leader 为每个更新操作决定的序号。可以认为，一个 leader 对应一个唯一的 epoch，每个 leader 任期内产生的更新操作对应一个唯一的有序的 count，从而从全局的视野，一个 zxid 代表了一个更新操作的全局序号(版本号)。
Zookeeper 通过 zxid 将两个场景阶段较好的结合起来，且能保证全局的强一致性。由于同一时刻只有一个 zookeeper 节点能获得超过半数的 follower，所以同一时刻最多只存在唯一的 leader;每个 leader 利用 FIFO 以 zxid 顺序更新各个 follower，只有成功完成前一个更新操作的才会进行下一个更新操作，在同一个 leader 任期内，数据在全局满足 quorum 约束的强一致，即读超过半数的节点 一定可以读到最新已提交的数据;每个成功的更新操作都至少被超过半数的节点确认，使得新选举 的 leader 一定可以包括最新的已成功提交的数据。
3.如何解决split brain问题
分布式协议一个著名问题就是 split brain 问题。
简单说，就是比如当你的 cluster 里面有两个结点，它们都知道在这个 cluster 里需要选举出一个 master。那么当它们两之间的通信完全没有问题的时候，就会达成共识，选出其中一个作为 master。但是如果它们之间的通信出了问题，那么两个结点都会觉得现在没有 master，所以每个都把自己选举成 master。于是 cluster 里面就会有两个 master。
区块链的分叉其实类似分布式系统的split brain。
一般来说，Zookeeper会默认设置：
- zookeeper cluster的节点数目必须是奇数。
- zookeeper 集群中必须超过半数节点(Majority)可用，整个集群才能对外可用。
Majority 就是一种 Qunroms 的方式来支持Leader选举，可以防止 split brain出现。奇数个节点可以在相同容错能力的情况下节省资源。
四、从CAP的角度理解几种不同的算法
1.两阶段提交协议
两阶段提交系统具有完全的C，很糟糕的A，很糟糕的P。 首先，两阶段提交协议保证了副本间是完全一致的，这也是协议的设计目的。再者，协议在一个节点出现异常时，就无法更新数据，其服务可用性较低。最后，一旦协调者与参与者之间网络分化，无法提供服务。
2.Paxos和Raft算法
Paxos 协议和Raft算法都是强一致性协议。Paxos只有两种情况下服务不可用:一是超过半数的 Proposer 异常，二是出现活锁。前者可以通过增加 Proposer 的个数来 降低由于 Proposer 异常影响服务的概率，后者本身发生的概率就极低。最后，只要能与超过半数的 Proposer 通信就可以完成协议流程，协议本身具有较好的容忍网络分区的能力。
若无特别说明，本文所涉及的代码版本为spring boot/cloud 2.2.6。
需要注意的是，Eureka Server同时也是一个Eureka Client，在不禁止Eureka Server的客户端行为时，它会向它配置文件中的其他Eureka Server进行拉取注册表、服务注册和发送心跳等操作
eureka架构放一张图，镇楼
与eureka-client类似，eureka-server启动也是依赖spring factories机制初始化、并将对象加载到spring容器中。
以spring-cloud-netflix-eureka-server-2.2.2.REALEASE.jar为例，打开该包中的spring.factories，可以看到
1 | org.springframework.boot.autoconfigure.EnableAutoConfiguration=\ |
即启动时自动加载EurekaServerAutoConfiguration类，而该类的功能是向spring的bean工厂添加eureka-server相关功能的bean。
EurekaServerAutoConfiguration上有一个注解：@ConditionalOnBean(EurekaServerMarkerConfiguration.Marker.class)，意思是：只有在Spring容器里有Marker这个类的实例时，才会加载EurekaServerAutoConfiguration，这个就是控制是否开启Eureka Server的关键。
在使用eureka-server时，我们所加的@EnableEurekaServer注解，实现如下：
1 | @Target(ElementType.TYPE) |
此处利用spring提供的@Import注解，将EurekaServerMarkerConfiguration动态注入到spring 容器中，这也刚好提供了上面spring factories里EurekaServerAutoConfiguration实例化的前提：必须有EurekaServerMarkerConfiguration。
即启动时初始化顺序：
EnableEurekaServer注解后，通过@Import引入EurekaServerMarkerConfigurationEurekaServerAutoConfiguration在spring-cloud-netflix-eureka-server:2.2.2.RELEASE中，EurekaServerAutoConfiguration声明如下：
1 | @Configuration(proxyBeanMethods = false) |
其中，通过@Import引入的EurekaServerInitializerConfiguration类声明如下：
1 | @Configuration(proxyBeanMethods = false) |
SmartLifecycle的作用是：初始化完之后，执行public void start()方法。
而EurekaServerInitializerConfiguration中start()方法：
在这个start() 上下文初始化这一步，还会从相邻eureka节点注册表，方法调用路径如下：
1 | EurekaServerInitializerConfiguration#start() |
在EurekaServerAutoConfiguration中会实例化EurekaServerContext，代码如下：
1 | @Bean |
DefaultEurekaServerContext中初始化代码如下：
1 | @PostConstruct |
在spring-cloud-netflix-eureka-server中，PeerAwareInstanceRegistryImpl的继承/实现关系参见下图：
eureka server围绕注册表管理的，也就是上面的InstanceRegistry。
参考上图，依次说明如下：
InstanceRegistry
LeaseManager
LookupService
PeerAwareInstanceRegistryImpl
Eureka Client在发起服务注册时会将自身的服务实例元数据封装在InstanceInfo中，然后将InstanceInfo发送到Eureka Server。Eureka Server在接收到Eureka Client发送的InstanceInfo后将会尝试将其放到本地注册表中以供其他Eureka Client进行服务发现。
EurekaServerAutoConfiguration中定义了 public FilterRegistrationBean jerseyFilterRegistration ，表明eureka-server使用了Jersey实现 对外的RESTful接口。注册一个 Jersey 的 filter ，配置好相应的Filter 和 url映射。
在com.netflix.eureka.resources包下，是Eureka Server对于Eureka client的REST请求的定义。看ApplicationResource类（这是一类请求，应用类的请求），类似于应用@Controller注解：@Produces({“application/xml”, “application/json”})，接受xml和json。
例如ApplicationResource类中，有如下方法（添加实例接口）：
1 | @POST |
上面的registry.register方法，可以追溯到PeerAwareInstanceRegistryImpl的方法：public void register(final InstanceInfo info, final boolean isReplication) ，中有一句：super.register(info, leaseDuration, isReplication); 将会进入：com.netflix.eureka.registry.AbstractInstanceRegistry的 register方法
在register方法中，服务实例的InstanceInfo保存在Lease中，Lease在AbstractInstanceRegistry中统一通过ConcurrentHashMap保存在内存中。在服务注册过程中，会先获取一个读锁，防止其他线程对registry注册表进行数据操作，避免数据的不一致。然后从resgitry查询对应的InstanceInfo租约是否已经存在注册表中，根据appName划分服务集群，使用InstanceId唯一标记服务实例。
之后将进行一系列缓存操作并根据覆盖状态规则设置服务实例的状态，缓存操作包括将InstanceInfo加入用于统计Eureka Client增量式获取注册表信息的recentlyChangedQueue和失效responseCache中对应的缓存。最后设置服务实例租约的上线时间用于计算租约的有效时间，释放读锁并完成服务注册。
流程图如下：
在Eureka Client完成服务注册之后，它需要定时向Eureka Server发送心跳请求(默认30秒一次)，维持自己在Eureka Server中租约的有效性。
此代码实现在com.netflix.eureka.resources.InstanceResource中，参见此方法：
1 | @PUT |
registry类型为PeerAwareInstanceRegistry，追溯后会发现最终实现是在AbstractInstanceRegistry#renew方法。
renew方法是对Eureka Client位于注册表中的租约的续租操作，不像register方法需要服务实例信息，仅根据服务实例的服务名和服务实例id即可更新对应租约的有效时间。
1 | public boolean renew(String appName, String id, boolean isReplication) { |
此方法中不关注InstanceInfo，仅关注于租约本身以及租约的服务实例状态。如果根据服务实例的appName和instanceInfoId查询出服务实例的租约，并且根据#getOverriddenInstanceStatus方法得到的instanceStatus不为InstanceStatus.UNKNOWN，那么更新租约中的有效时间，即更新租约Lease中的lastUpdateTimestamp，达到续约的目的；如果租约不存在，那么返回续租失败的结果。
下图给出了eureka服务端接收心跳、租约更新流程。
如果Eureka Client在注册后，既没有续约，也没有下线(服务崩溃或者网络异常等原因)，那么服务的状态就处于不可知的状态，不能保证能够从该服务实例中获取到回馈，所以需要服务剔除此方法定时清理这些不稳定的服务，该方法会批量将注册表中所有过期租约剔除。
剔除是定时任务，默认60秒执行一次。延时60秒，间隔60秒 evictionTimer.schedule(evictionTaskRef.get(), serverConfig.getEvictionIntervalTimerInMs(), serverConfig.getEvictionIntervalTimerInMs()); 从上面eureka server启动来看，剔除的任务，是线程启动的，执行的是下面的方法。 com.netflix.eureka.registry.AbstractInstanceRegistry#evict
1 | |
1.自我保护期间不清除。 2.分批次清除。 3.服务是逐个随机剔除，剔除均匀分布在所有应用中，防止在同一时间内同一服务集群中的服务全部过期被剔除，造成在大量剔除服务时，并在进行自我保护时，促使程序崩溃。
剔除服务是个定时任务，用EvictionTask执行，默认60秒执行一次，延时60秒执行。定时剔除过期服务。
代码：
1 | EurekaServerInitializerConfiguration#start() |
服务剔除将会遍历registry注册表，找出其中所有的过期租约，然后根据配置文件中续租百分比阀值和当前注册表的租约总数量计算出最大允许的剔除租约的数量(当前注册表中租约总数量减去当前注册表租约阀值)，分批次剔除过期的服务实例租约。对过期的服务实例租约调用AbstractInstanceRegistry#internalCancel服务下线的方法将其从注册表中清除掉。
自我保护机制主要在Eureka Client和Eureka Server之间存在网络分区的情况下发挥保护作用，在服务器端和客户端都有对应实现。假设在某种特定的情况下(如网络故障)，Eureka Client和Eureka Server无法进行通信，此时Eureka Client无法向Eureka Server发起注册和续约请求，Eureka Server中就可能因注册表中的服务实例租约出现大量过期而面临被剔除的危险，然而此时的Eureka Client可能是处于健康状态的(可接受服务访问)，如果直接将注册表中大量过期的服务实例租约剔除显然是不合理的。
针对这种情况，Eureka设计了“自我保护机制”。在Eureka Server处，如果出现大量的服务实例过期被剔除的现象，那么该Server节点将进入自我保护模式，保护注册表中的信息不再被剔除，在通信稳定后再退出该模式；在Eureka Client处，如果向Eureka Server注册失败，将快速超时并尝试与其他的Eureka Server进行通信。“自我保护机制”的设计大大提高了Eureka的可用性。
有关自我保护机制的流程图：
Eureka Client在应用销毁时，会向Eureka Server发送服务下线请求，清除注册表中关于本应用的租约，避免无效的服务调用。在服务剔除的过程中，也是通过服务下线的逻辑完成对单个服务实例过期租约的清除工作。
对应代码：com.netflix.eureka.resources.InstanceResource 的
1 | @DELETE |
继续追踪：
1 | InstanceResource#cancelLease |
最终实现代码如下：
1 | protected boolean internalCancel(String appName, String id, boolean isReplication) { |
上述代码主要功能： 首先通过registry根据服务名和服务实例id查询关于服务实例的租约Lease是否存在，统计最近请求下线的服务实例用于Eureka Server主页展示。如果租约不存在，返回下线失败；如果租约存在，从registry注册表中移除，设置租约的下线时间，同时在最近租约变更记录队列中添加新的下线记录，以用于Eureka Client的增量式获取注册表信息。
如果Eureka Server是通过集群的方式进行部署，那么为了维护整个集群中Eureka Server注册表数据的一致性，势必需要一个机制同步Eureka Server集群中的注册表数据。
Eureka Server集群同步包含两个部分：
Eureka Server启动类中，EurekaServerAutoConfiguration通过@Import注解加载EurekaServerInitializerConfiguration
1 | EurekaServerInitializerConfiguration#start() |
代码实现：
1 | public int syncUp() { |
看循环：意思是，如果是i第一次进来，为0，不够等待的代码，直接执行下面的拉取服务实例。 将自己作为一个eureka client，拉取注册表。并通过register(instance, instance.getLeaseInfo().getDurationInSecs(), true)注册到自身的注册表中。
Eureka Server也是一个Eureka Client，在启动的时候也会进行DiscoveryClient的初始化，会从其对应的Eureka Server中拉取全量的注册表信息。在Eureka Server集群部署的情况下，Eureka Server从它的peer节点中拉取到注册表信息后，将遍历这个Applications，将所有的服务实例通过AbstractRegistry#register方法注册到自身注册表中。
EurekaServerBootstrap#initEurekaServerContext()中有如下代码：
1 | 。。。 |
当执行完上面的syncUp逻辑后，在下面的openForTraffic，开启此server接受别的client注册，拉取注册表等操作。而在它首次拉取其他peer节点时，是不允许client的通信请求的。
1 | public void openForTraffic(ApplicationInfoManager applicationInfoManager, int count) { |
为了保证Eureka Server集群运行时注册表信息的一致性，每个Eureka Server在对本地注册表进行管理操作时，会将相应的操作同步到所有peer节点中。
在外部调用server的restful方法时，在com.netflix.eureka.resources包下的ApplicationResource资源中，查看每个服务的操作。比如服务注册public Response addInstance(，此方法中有 registry.register(info, “true”.equals(isReplication));点进去实现类：replicateToPeers(Action.Register, info.getAppName(), info.getId(), info, null, isReplication);这是一种情况。
在PeerAwareInstanceRegistryImpl类中，其他操作，如cancel，renew等中都有replicateToPeers， 此方法中有个peerEurekaNodes，代表一个可同步数据的eureka Server的集合，如果注册表有变化，向此中的peer节点同步。
replicateToPeers方法，它将遍历Eureka Server中peer节点，向每个peer节点发送同步请求。
1 | private void replicateToPeers(Action action, String appName, String id, |
此replicateInstanceActionsToPeers方法中，类PeerEurekaNode的实例node的各种方法，cancel，register，等，用了batchingDispatcher.process(，作用是将同一时间段内，相同服务实例的相同操作将使用相同的任务编号，在进行同步复制的时候，将根据任务编号合并操作，减少同步操作的数量和网络消耗，但是同时也造成了同步复制的延时性，不满足CAP中的C（强一致性）。 所以Eureka，只满足AP。
1 | //示例：PeerEurekaNode |
通过Eureka Server在启动过程中初始化本地注册表信息和Eureka Server集群间的同步复制操作，最终达到了集群中Eureka Server注册表信息一致的目的。
Eureka Server中获取注册表的服务实例信息主要通过两个方法实现：
上面讲到从节点复制注册信息的时候，用方法public int syncUp() ，一行Applications apps = eurekaClient.getApplications();点进去实现类，有一行getApplicationsFromAllRemoteRegions(); 下面getApplicationsFromMultipleRegions，作用从多个地区中获取全量注册表信息，并封装成Applications返回，它首先会将本地注册表registry中的所有服务实例信息提取出来封装到Applications中，再根据是否需要拉取Region的注册信息，将远程拉取过来的Application放到上面的Applications中。最后得到一个全量的Applications。
在前面提到接受服务注册，接受心跳等方法中，都有recentlyChangedQueue.add(new RecentlyChangedItem(lease));作用是将新变动的服务放到最近变化的服务实例信息队列中，用于记录增量是注册表信息。getApplicationDeltasFromMultipleRegions，实现了从远处eureka server中获取增量式注册表信息的能力。
在EurekaServer对外restful中，在com.netflix.eureka.resources下， @GET public Response getApplication(@PathParam(“version”) String version, @HeaderParam(“Accept”) final String acceptHeader, @HeaderParam(EurekaAccept.HTTP_X_EUREKA_ACCEPT) String eurekaAccept) { 其中有一句：String payLoad = responseCache.get(cacheKey);在responseCache初始化的时候，它的构造方法ResponseCacheImpl(EurekaServerConfig serverConfig, ServerCodecs serverCodecs, AbstractInstanceRegistry registry) {中，Value value = generatePayload(key);点进去有一句：registry.getApplicationDeltasFromMultipleRegions(key.getRegions()));从远程获取delta增量注册信息。但是这个只是向client提供，不向server提供，因为server可以通过每次变更自动同步到peer。
获取增量式注册表信息将会从recentlyChangedQueue中获取最近变化的服务实例信息。recentlyChangedQueue中统计了近3分钟内进行注册、修改和剔除的服务实例信息，在服务注册AbstractInstanceRegistry#registry、接受心跳请求AbstractInstanceRegistry#renew和服务下线AbstractInstanceRegistry#internalCancel等方法中均可见到recentlyChangedQueue对这些服务实例进行登记，用于记录增量式注册表信息。#getApplicationsFromMultipleRegions方法同样提供了从远程Region的Eureka Server获取增量式注册表信息的能力。