关于微服务注册中心的考量

最近k8s实在流行，好多服务都上了k8s，用着阿里巴巴的nacos，很爽。

直到，曾经有人提出了疑问：既然k8s有了服务注册中心，为啥还要nacos？

然后啊，就hang住了，百思不得其解。直到思考出了下图：

其实就是看现有团队实际情况，

正向考虑的话是：各种够不够强大：

1. 运维团队够不够强大搞istio？
2. 架构团队够不够强大激进，搞dapr？
3. 开发人员够不够强大，为了接入k8s环境做本机工具的搭建，主要是流量转发、搭建minikube等
4. 管理上的控制粒度（nacos有利于小团队、prd上的配置变更、流程上的便利性等；k8s的configmap更偏向于git存储+强运维管控发布流程）

逆向考虑的话是：

1. 我想要用哪种注册中心，最优的? 实用就好的？
2. 需要买入啥设备？
3. 需要招聘怎样的团队？对应的JD描述、等级等等
4. 管理上的控制粒度（nacos有利于小团队、prd上的配置变更、流程上的便利性等；k8s的configmap更偏向于git存储+强运维管控发布流程）

出处：https://www.cnblogs.com/aarond/p/service-discovery-thinking.html