いいえ公共バック、「返信しない学習を」、著者は高級ブティック秘密情報を入手します
ポスター、オーディションコース下のQRコードをスキャン：
読者の公共号の心からのこの記事では、魏呉に貢献します
1.レジストリは何ですか？
マイクロサービスのデータベースインスタンスおよびサービスのメタデータであるサービスレジストリ、。サービスレジストリに登録されたサービスの例としては、起動して、閉じたときにログオフします。
利用可能なサービスとルータクライアントの例には、サービスを見つけるためのサービスレジストリを照会します。サービスレジストリは、要求を処理できるかどうかを確認するために、ヘルスチェックサービスインスタンスのAPIと呼ばれるかもしれません。
2. CAPの設計原理、理論とBASEとは何ですか？
一貫性（C） ：同時に同じ値であれば、分散システム内のすべてのデータをバックアップします。（すべてのノードに相当のデータの最新のコピーの同じコピーにアクセス）
可用性（A） ：クラスタ内のノードのサブセットが失敗し、クラスタ全体のクライアントが読む場合の対応や要望を書き込むことができます。（高可用性データ更新）
パーティショントレランス（P） ：相互に正常な通信を維持することが保証されていないクラスタ・マシンで、その結果、ネットワーク障害のために、それをある場合、各マシンの競合の容量が含まれ、サービスの通常の使用を確保することができます
CAPは、AP、またはCP、またはACのいずれかの原則の本質であるが、CAPは存在しません。
唯一のユニークなデータは、一貫性のないデータは、発生しませんので、コピーせずに、分散システム内のデータは、その後、システムは、強い一貫性の条件を満たさなければならない場合は、CおよびPは、2つの要素を持っています
システムやネットワークのダウンタイムのゾーニングステータスは、必然的にいくつかのデータにつながる場合でも、アクセスすることはできません
此时可用性条件就不能被满足，即在此情况下获得了CP系统，但是CAP不可同时满足。必然导致某些数据不可以访问，此时可用性条件就不能被满足，即在此情况下获得了CP系统，但是CAP不可同时满足。
BASE 说的俗一点CA都退而求其次，这就是所谓的最终一致性。
3. 面对品种繁多的注册中心组件，又该如何进行技术选型呢?
基于上面的理论铺垫，我就拿目前工作中最常用的Eureka和ZooKeeper进行对比。
我直接放上两幅图：
上图是Eureka集群原理图，采用peer-to-peer的架构集群模式，部署一个集群，但是集群里每个机器的地位是对等的
各个服务可以向任何一个Eureka实例服务注册和服务发现，集群里任何一个Euerka实例接收到写请求之后，会自动同步给其他所有的Eureka实例
但是他就会有一个问题，可能还没同步数据过去，结果自己就死了
此时还是可以继续从别的机器上拉取注册表，但是看到的就不是最新的数据了，但是保证了可用性 ，此种状态就遵循了BASE理论，即最终一致性。
架构图如下所示：
ZooKeeper是有一个leader节点会接收数据， 然后同步写其他节点，一旦leader挂了，要重新选举leader
这个过程里为了保证C，就牺牲了A，不可用一段时间，但是一个leader选举好了，那么就可以继续写数据了，保证一致性
说到这里，笔者觉得现实场景适用真正意义上的AP几乎不存在，一个完全不要求数据统一的场景笔者确实没经历过，再说直白一点这不就是脑裂了吗。。。
接下来我继续从两个方面说说他俩的区别：
（1）服务注册发现的时效性
zk，时效性更好，注册或者是挂了，一般秒级就能感知到
eureka，默认配置非常糟糕，服务发现感知要到几十秒，甚至分钟级别
上线一个新的服务实例，到其他人可以发现他，极端情况下，可能要1分钟的时间，ribbon去获取每个服务上缓存的eureka的注册表进行负载均衡
服务故障，隔60秒才去检查心跳，发现这个服务上一次心跳是在60秒之前，隔60秒去检查心跳，超过90秒没有心跳，才会认为他死了，2分钟都过去
30秒，才会更新缓存，30秒，其他服务才会来拉取最新的注册表
三分钟都过去了，如果你的服务实例挂掉了，此时别人感知到，可能要两三分钟的时间，一两分钟的时间，很漫长
(2)容量
zk，不适合大规模的服务实例，因为服务上下线的时候，需要瞬间推送数据通知到所有的其他服务实例
所以一旦服务规模太大，到了几千个服务实例的时候，会导致网络带宽被大量占用
eureka，也很难支撑大规模的服务实例，因为每个eureka实例都要接受所有的请求，实例多了压力太大，扛不住，也很难到几千服务实例
之前dubbo技术体系都是用zk当注册中心，spring cloud技术体系都是用eureka当注册中心这两种是运用最广泛的
但是现在很多中小型公司以spring cloud居多，所以后面基于eureka说一下服务注册中心的生产优化
4. 如果要对注册中心进行自研又该注意哪些呢？
既然要自研注册中心了 那么肯定要开发其对应的客户端以及服务端 ， 两端都要考虑各自的东西
客户端：
服务拉取：每次肯定不是全量拉取，这个时候你就要思考服务端有可能提供一个最近的变更队列，供客户端拉取
并且一定要有一个用于校验拉取增量数据之后数据是否完整的指标数据，用于校验数据是否有异常，异常则做一次全量拉取。
心跳发送：告诉服务端自己是否存活进行服务的一个续约。
服务下线：进行服务下线，修改运行状态的标记位，当然这个标记位要保证其可见性。
服务端：
服务注册：要对java并发包的拥有着深刻的理解，在服务注册表一定一定要注意读写并发控制，既要保证线程安全，同时也要降低锁的争用，最大限度保证其性能。
保健サービスの登録を確認してください：サービスは、登録サービスを更新しなかった場合は、単位時間に、サービスをオフラインにしています。
クラスタ同期：実際のビジネスニーズに応じて、適切なデータ伝送方式、保証されたスループットの開発に、この文脈では、クラスタアーキテクチャの適切なプログラムを開発しています。
レジストリおよび技術的なフレームワークの互換性の主流は、考慮する必要があります。
終わり
収穫した場合、下に描画「をクリックしてください見て」、ありがとうございました！
世間の注目番の描画長押しへようこそヒューペルジンアーキテクチャノート
BATアーキテクチャの経験財布