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

标签：cos   怎样   com   控制   ini   png   配置   流程   lazy   

最近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存储+强运维管控发布流程）

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

标签：cos   怎样   com   控制   ini   png   配置   流程   lazy   

原文地址：https://www.cnblogs.com/aarond/p/service-discovery-thinking.html