“就近接入”名字服务的实现逻辑思考

目标

• 服务的实际响应者在全国各地都有部署，任意客户访问服务时，都期望访问较近的节点。

已有的方案

方案一：在名字服务服务端计算

• 客户端向名字服务发起请求
• 名字服务计算客户端所在区域信息
• 名字服务计算请求对应的服务的所有响应节点
• 名字服务从所有响应节点中选择靠近的节点返回给客户端

优点

• 瘦客户端。
• 地域信息不用透传给客户端。
• 非客户端地域相关节点，客户端不知道。

缺点

• 服务端计算速度慢,步骤多，依赖条件多
• 服务端需要频繁重复计算客户端的区域信息。

方案二: 在名字服务客户端计算

• 客户端向名字服务发起请求
• 名字服务返回对应服务的所有响应节点信息
• 客户端在自己程序内部对所有响应节点进行筛选，选中其中较近节点进行访问
  • 依据可以是设定的客户端自己所在区域，也可以是每次访问的耗时

优点

• 计算分布到客户端，服务端计算量少
• 如果需要修改请求筛选逻辑，只需要更新客户端，对整个系统的影响较少
  • 这个优点非常重要。如果没有这一点，会导致整个系统因为集中化而迭代速度非常缓慢
  • 现代化迭代开发更适合重客户端，轻服务端的模式，谨记

缺点

• 如果客户端没有更新能力，完全依赖服务端提供更新开发更新能力，那么这个方案会导致客户端的服务无法使用更新版本的能力

更进一步的关于组织架构和绩效的思考

• 框架部门可能会非常倾向于使用重服务端，轻客户端的做法
• 因为这个做法对于框架部门的绩效会非常好
• 同时这个做法会使服务端部门的大量员工失去开发工作，减少人员数量，同样也使服务端部门失去部分开发自主权
• 但是这也会导致服务端在未来的框架迭代中，没有人力也没有能力去采用新的框架，而必须依赖框架部门提供的框架能力。
• 而框架部门由于服务了太多的服务端部门，所以自我迭代速度反而不可能很快，反而会成为技术迭代的瓶颈。

总结

• 对于迭代速度极慢的整体框架，那么重服务端是合理的。
• 对于迭代速度快的整体框架，那么重客户端时合理的，反而重服务端是不合理的，服务端框架组部门的利益会凌驾于迭代获利之上