背景
随着公司各个模块功工程的微服务化，而服务间的通信依赖服务注册于发现，也需要一个统一的服务治理。自然需要使用到注册中心。而关于微服务的注册中心选择，出现了很多：原本我司就有Zk存放资源组件配置的操作，ZooKeeper其实可以作为注册中心来使用，在Spring Cloud体系当中也有Spring Cloud Zookeeper，而除此之外还有官方 推荐的Netflix Eureka和 Consul。但就实践和工程解决的问题来看，我们需要的是一款普通的微服务治理，我们并不下海，所以能够满足注册和发现其实已经满足了我们的需求（我们没有那么多人自研/改造，且我们对数据强一致无硬需求，Zk保证的CP[强一致性和分区容错性]并没有硬需求，Erueka的原则AP[可用性和分区容错性]足以解决我们场景的问题），而对于Zk和Consul而言，本来就不是最优的选择加上Zk并没有过多的作为注册中心使用的经验的事例（出问题和构建没有足够的资料和容错[这里其实是我们压根没有相关的经验，所以Zk是很早就被Pass掉的一个选项]，Consul的定制化对于我们而言并没有需求并且着急需要一个服务治理的中间件），对应的答案就只有Erueka。
选择Erueka
虽然是官方亲儿子，Cloud力推，但至少要知道一些Erueka相关的优劣，这样在使用的时候对于出现问题能够快速解决。
当然要详细了解Erueka的底层，其实也算是深水区:微服务注册中心 Eureka 架构深入解读 我不多赘述，看了文章我觉得他说的挺细节的也挺到位的。
关键在于如何快速上线。因为契合Spring Cloud风格的配置和依赖，其实使得我们部分人并不是清楚其原理和细节就能够轻松搭建自己的注册中心：
SpringCloud之Eureka注册中心原理及其搭建
关于放弃Eureka
我们花了很短的时间将不少服务都推上了线，但是若是仅作为注册中心和服务治理而言其实Eureka已经帮助我们完成了所有事儿，但是在后来的容器化中我们遇到了一个问题（其实是因为领导阿里系出身，所以钟爱阿里系产品，加上比较讨厌某程的Apollo配置中心[这里有另外一个瓜...因为Apollo的热更新和Springboot热部署的开发插件配合的服务自动重启导致服务暴毙的事项...所以不怎么喜欢某程哈哈哈]）：对于Dubbo和K8s的支持，架总和领导推动下我们换上了崭新的Nacos。关于他们的优劣，我想着里应该不少人做了总结。比如这个：
主流微服务注册中心浅析和对比
最后
首先说下这期不是水文章，而是因为我写了一部分发现别人的经验和写的内容基本涵盖而且我也没有别人清晰...所以这个时候就只能贴链接了...不过有一说一，他们的活，整挺好