add doc

Author: 文亮

README.md

@@ -190,6 +190,10 @@
 - [14、平时除了使用外，有研究过Spring Cloud的底层架构原理么？](/docs/distributed-system/springCloud-study-theory.md)
 - [15、从底层实现原理的角度，对比一下Dubbo和Spring Cloud的优劣！](/docs/distributed-system/dubbo-vs-springCloud.md)
 - [16、作业：自己独立画出Spring Cloud的架构原理图，RPC框架架构设计图！](/docs/distributed-system/springCloud-and-rpc-framework.md)
+- [17、面试官：你们的服务注册中心进行过选型调研吗？对比一下各种服务注册中心！](/docs/distributed-system/registration-center-%20guide.md)
+- [18、画图阐述一下你们的服务注册中心部署架构，生产环境下怎么保证高可用？](/docs/distributed-system/register-high-availability.md)
+- [19、你们系统遇到过服务发现过慢的问题吗？怎么优化和解决的？](/docs/distributed-system/service-register-discovery.md)
+- [20、作业：说一下自己公司的服务注册中心怎么技术选型的？生产环境中应该怎么优化？](/docs/distributed-system/register-production-optimize.md)
 
 
 ### 第二季-高并发

docs/distributed-system/images/eureka-register.png

@@ -0,0 +1,34 @@
+
+#### 分布式系统架构的
+
+**服务注册中心，eureka、zk、consul，原理画图画清楚**
+
+**数据一致性，CP、AP**
+
+服务注册、故障 和发现的时效性是多长时间
+
+注册中心最大能支撑多少服务实例
+
+如何部署的，几台机器，每台机器的配置如何，会用比较高配置的机器来做，8核16G，16核32G的高配置机器来搞，基本上可以做到每台机器每秒钟的请求支撑几千绝对没问题
+
+可用性如何来保证
+
+**有没有做过一些优化，服务注册、故障以及发现的时效性，是否可以优化一下，用eureka的话，可以尝试一下，配合我们讲解的那些参数，优化一下时效性，服务上线、故障到发现是几秒钟的时效性**
+
+**zk，一旦服务挂掉，zk感知到以及通知其他服务的时效性，服务注册到zk之后通知到其他服务的时效性，leader挂掉之后可用性是否会出现短暂的问题，为了去换取一致性**
+
+
+**所以希望大家好好完成每天的作业，我布置的大量作业，就是为了帮你锻造出这种能力**
+
+**学习课程以及完成作业的过程中，大家一定会有很多的问题，可以到专栏的评论区去提问**
+
+**每天我都会和之前带出来的一批阿里、蚂蚁金服、滴滴的优秀同学给大家进行答疑，并且我们还有专门的付费用户的微信群，大家可以在微信群里跟我们一起进行技术交流**
+
+**如果你能坚持下来，学满6季，还可以获取私人定制的面试一条龙VIP服务**
+
+**如果是连续6季面试训练营都购买的同学，还可以获取面试一条龙VIP服务**
+
+**具体信息大家看“狸猫技术窝”公众号的知识店铺内的训练营详情即可**
+
+**具体可参见训练营目录下的《训练营专属服务》文档。简单来说，这个私人定制的面试VIP服务，会为你的跳槽面试全程保驾护航**
+

docs/distributed-system/images/zookeeper-register.png

@@ -0,0 +1,54 @@
+
+非常常见的一个技术面试题，但凡只要是聊到分布式这块，一定会问问你，**Dubbo，Spring Cloud，服务注册中心**，你们当时是怎么选型和调研的，你们最终是选择了哪块技术呢？你选择这块技术的原因和理由是什么呢？
+
+**Eureka、ZooKeeper**
+
+**Dubbo**作为服务框架的，一般注册中心会选择zk
+
+**Spring Cloud**作为服务框架的，**一般服务注册中心会选择Eureka**
+
+**Consul、Nacos，**普及型还没那么广泛，我会在面试训练营课程里增加对应的内容，给大家去进行补充
+
+#### (1)服务注册发现的原理
+
+集群模式
+![ZooKeeper](/docs/distributed-system/images/eureka-register.png)
+
+**Eureka，peer-to-pee**r，部署一个集群，**但是集群里每个机器的地位是对等的，各个服务可以向任何一个Eureka实例服务注册和服务发现，集群里任何一个Euerka实例接收到写请求之后，会自动同步给其他所有的Eureka实例**
+![ZooKeeper](/docs/distributed-system/images/zookeeper-register.png)
+
+**ZooKeeper，服务注册和发现的原理，Leader + Follower两种角色，只有Leader可以负责写也就是服务注册，他可以把数据同步给Follower，读的时候leader/follower都可以读**
+
+####  (2)一致性保障：CP or AP
+
+**CAP，C是一致性，A是可用性，P是分区容错性**
+
+**CP，AP**
+
+**ZooKeeper是有一个leader节点会接收数据， 然后同步写其他节点，一旦leader挂了，要重新选举leader，这个过程里为了保证C，就牺牲了A，不可用一段时间，但是一个leader选举好了，那么就可以继续写数据了，保证一致性**
+
+Eureka是peer模式，可能还没同步数据过去，结果自己就死了，此时还是可以继续从别的机器上拉取注册表，但是看到的就不是最新的数据了，但是保证了可用性，强一致，最终一致性
+
+（3）服务注册发现的时效性
+
+zk，时效性更好，注册或者是挂了，一般秒级就能感知到
+
+eureka，默认配置非常糟糕，服务发现感知要到几十秒，甚至分钟级别，上线一个新的服务实例，到其他人可以发现他，极端情况下，可能要1分钟的时间，ribbon去获取每个服务上缓存的eureka的注册表进行负载均衡
+
+服务故障，隔60秒才去检查心跳，发现这个服务上一次心跳是在60秒之前，隔60秒去检查心跳，超过90秒没有心跳，才会认为他死了，2分钟都过去
+
+30秒，才会更新缓存，30秒，其他服务才会来拉取最新的注册表
+
+三分钟都过去了，如果你的服务实例挂掉了，此时别人感知到，可能要两三分钟的时间，一两分钟的时间，很漫长
+
+#### (4)容量
+
+zk，不适合大规模的服务实例，因为服务上下线的时候，需要瞬间推送数据通知到所有的其他服务实例，所以一旦服务规模太大，到了几千个服务实例的时候，会导致网络带宽被大量占用
+
+eureka，也很难支撑大规模的服务实例，因为每个eureka实例都要接受所有的请求，实例多了压力太大，扛不住，也很难到几千服务实例
+
+之前dubbo技术体系都是用zk当注册中心，spring cloud技术体系都是用eureka当注册中心这两种是运用最广泛的，但是现在很多中小型公司以spring cloud居多，所以后面基于eureka说一下服务注册中心的生产优化
+
+（5）多机房、多数据中心、健康检查
+
+

docs/distributed-system/register-high-availability.md

@@ -0,0 +1,14 @@
+
+**zk，一般来说还好，服务注册和发现，都是很快的**
+
+**eureka，必须优化参数**
+
+**eureka.server.responseCacheUpdateIntervalMs = 3000**
+**eureka.client.registryFetchIntervalSeconds = 30000**
+
+**eureka.client.leaseRenewalIntervalInSeconds = 30**
+**eureka.server.evictionIntervalTimerInMs = 60000**
+**eureka.instance.leaseExpirationDurationInSeconds = 90**
+
+**服务发现的时效性变成秒级，几秒钟可以感知服务的上线和下线**
+