微服务注册中心如何选型？这几个维度告诉你！( 六 ) _微服务

自愈能力：当容器失败时，会对容器进行重启；当所部署的Node节点有问题时，会对容器进行重新部署和重新调度；当容器未通过监控检查时，会关闭此容器；直到容器正常运行时，才会对外提供服务。

水平扩容：通过简单的命令、用户界面或基于CPU的使用情况，能够对应用进行扩容和缩容。

服务发现和负载均衡：开发者不需要使用额外的服务发现机制，就能够基于Kubernetes进行服务发现和负载均衡。

自动发布和回滚：Kubernetes能够程序化的发布应用和相关的配置。如果发布有问题，Kubernetes将能够回归发生的变更。

保密和配置管理：在不需要重新构建镜像的情况下，可以部署和更新保密和应用配置。

存储编排：自动挂接存储系统，这些存储系统可以来自于本地、公共云提供商（例如：GCP和AWS）、网络存储(例如：NFS、iSCSI、Gluster、Ceph、Cinder和Floker等) 。

文章插图
Kubernetes属于主从分布式架构，主要由Master Node和Worker Node组成，以及包括客户端命令行工具Kubectl和其它附加项。
Master Node：作为控制节点，对集群进行调度管理，Master主要由三部分构成:

Api Server相当于 K8S 的网关，所有的指令请求都必须经过 Api Server;
Kubernetes调度器，使用调度算法，把请求资源调度到某个 Node 节点;
Controller控制器，维护 K8S 资源对象（CRUD：添加、删除、更新、修改）;
ETCD存储资源对象（可以服务注册、发现等等）;

文章插图
Worker Node：作为真正的工作节点，运行业务应用的容器；Worker Node主要包含五部分:

Docker是运行容器的基础环境，容器引擎;
Kuberlet 执行在 Node 节点上的资源操作，Scheduler 把请求交给Api ，然后 Api Sever 再把信息指令数据存储在 ETCD 里，于是 Kuberlet 会扫描 ETCD 并获取指令请求，然后去执行;
Kube-proxy是代理服务，起到负载均衡作用；
Fluentd采集日志;
Pod：Kubernetes 管理的基本单元（最小单元)，Pod 内部是容器。Kubernetes 不直接管理容器，而是管理 Pod;

6、总结1、高可用这几款开源产品都已经考虑如何搭建高可用集群，这个地方有些差别而已；
2、关于CP还是AP的选择对于服务发现来说，针对同一个服务，即使注册中心的不同节点保存的服务提供者信息不尽相同，也并不会造成灾难性的后果。
但是对于服务消费者来说，如果因为注册中心的异常导致消费不能正常进行，对于系统来说是灾难性，因此我觉得对于注册中心选型应该关注可用性，而非一致性，所以我选择AP 。
3、技术体系对于语言来说我们都是Java技术栈，从这点来说我们更倾向于Eureka、Nacos;
如果公司内部有专门的中间件或者运维团队的可以Consul、Kubernetes，毕竟Kubernetes才是未来，我们追求的就是框架内解决这些问题，不要涉及到应用内的业务开发，我们其实后者是有的，只是可能不能达到能自主研发程度，这样只能要求自己走的远一些。
应用内的解决方案一般适用于服务提供者和服务消费者同属于一个技术体系；应用外的解决方案一般适合服务提供者和服务消费者采用了不同技术体系的业务场景。
关于Eureka、Nacos如何选择，这个选择就比较容易做了，那个让我做的事少，我就选择那个，显然Nacos帮我们做了更多的事。

【微服务注册中心如何选型？这几个维度告诉你！】