高可用注册中心架构图
看下图，我们先对注册中心高可用架构有一个直观的认识：
注册中心高可用改造
废话不多说，我们直接开干！
步骤：
- 修改host配置文件
- 启动双注册中心
- 单节点注册+同步机制
- 客户端配置双节点
1.修改host配置文件
我这里用的是mac的系统，需要进入到etc目录下，如果是windows的小伙伴可以去网上查一下相关资料找到hosts这个文件。
添加如下内容：
2.创建并配置双注册中心
2.1创建eureka-server-peer模块
2.2创建启动类
2.3创建配置文件
spring:
application:
name: eureka-server-peer1
server:
port: 20001
eureka:
instance:
hostname: peer1
client:
service-url:
#注册中心注册
defaultZone: http://peer2:20000/eureka2.4同样的方式创建peer2模块
peer2配置文件：
spring:
application:
name: eureka-server-peer2
server:
port: 20000
eureka:
instance:
hostname: peer2
client:
service-url:
#注册中心注册
defaultZone: http://peer1:20001/eureka最后我们把这两个注册中心节点启动起来：
我们先访问一下peer2：
可以看到在peer2的页面里DS Replicas可以看到peer1了。
然后我们再访问peer1：
也可以在peer1里看到peer2。
这就说明我们的peer1与peer2之间数据同步的通道我们已经打通了。
3.客户端配置双节点
首先我们先启动EurekaClient：
再打开一下浏览器，访问一下peer1和peer2：
可以看到eureka-client都已经注册到我们的peer1和peer2里面了。下面我们来看一下另外一种玩法
我们先修改一下eureka-client的配置文件：
最后我们刷新一下页面：
可以看到也是没有问题的。接下来，我们尝试把某一注册中心下线掉，看看client还能不能注册进来
先分别把eureka-client和peer2下线：
我们再启动eureka-client
启动成功后我们再次访问：
可以看到peer2已经无法访问了，我们这里就是相当于模拟了一个宕机的状态。我们再访问peer1：
可以看到，eureka-client仍然是可以注册到peer1的。
其实它这里是采用了轮训的机制，在delaultZone里拿到了一个可用的注册中心的url来进行注册，如果第一个是不可用的注册不成功，那么它就会继续往后轮训，直到找到一个可用的注册中心为止。
总结
到这里，我们的注册中心高可用改造已经完成了。
其实业界所谓的高可用的思路都是差不多的，我们在学习技术的过程当中一定要学会举一反三，多多总结。
还有几个点，要和大家分享一下：
第一点就是说我们千万不要害怕犯错，其实从错误当中汲取经验是印象最深刻的，才能学到东西，但是一个错误一定不要犯两次。
第二点就是要“警惕挖掘机”，之前我听说过某互联网公司，挖掘机把他们网线挖断了。
我们为什么说在架构设计的阶段一定要异地双活或者异地多活？
比如说阿里在应用部署的时候，至少要求你要有两个机房，他们的距离至少要超过1000千米，它其实就是为了警惕像自然灾害这样的情况，打个比方，如果你的机房部署的沿海，比如极端天气，像海啸、台风就有可能影响到你两个机房，你的两个机房都挂了，我们说这个概率虽然非常小，但是还是有可能会发生的。
墨菲定律中说过，如果有个事情它有这种变坏的方向，不管它概率多小，它总会发生。
所以我们在做高可用架构的时候一定要有一个追求，就是考虑所有异常存在的情况，确保万无一失。
第三点就是“延时”：
像大型的应用都不可能会做到全链路强一致性。如果我们做架构设计的时候，要对这种延迟有一个余量，也就是说确保核心主链路中不会因为这种最终一致性方案导致异常的情况。
最后一点想和大家分享的是“勇敢”：
打破保守，跳出舒适圈。
不要只盯着自己熟悉的架构方案。
如果十年前你用Struts，到了今天你仍然用Struts，这样你的思维就会固化。
因为我们人更偏向与在舒适圈里待着的，我们的大脑都会去依赖于这种不费力的选择，所以平时工作中一定要多像年轻的同事学习，你的年龄并不是你在这个架构领域或者权威领域的话语权，比如你在那种养老公司待个十年，做那种没有挑战的工作，你的架构能力不一定比得过在互联网公司捶打一两年的年轻人。
