K8S下挖空Dubbo的一些思路--可行性

在kubernetes环境下，dubbo显得有些臃肿。我们从用户接口、协议、注册中心三部分来看一下

• 用户接口：正常情况下开发只会使用三个@Reference、@Sevice、RpcContext；足够简洁、没问题
• 协议：默认是单一长连接；首先http2是大势所趋、而且两者实现类似，其次Istio对原始tcp的支持不是很理想
• 注册中心：无论是Zookeeper和Nacos都是一个独立的大组件，属于需要单独维护的那种。而且目前的Nacos我没有使用的欲望

那么明确下目的：在保持用户接口的情况下，替换掉dubbo协议和注册中心

协议

目标是http2，我们只需要一个支持http2的框架即可

1. Spring是可以支持的，但是Spring的路由相当复杂，在普通的web项目中动态添加路由相当麻烦
2. 但是Spring也是必不可少的，之前的代码都是在Spring基础上开发的，如果用新框架必须能调用Spring的bean

嵌入式的web框架，方便动态添加路由、性能强又稳定的，满足这些的貌似只有Vertx了

协议方面使用Vertx的http2或者h2c都可以，h2c不需要证书会更方便点

序列化方面，因为http2使用二进制传输数据，所以任何一种序列化框架都可以完美支持。这里依然可以使用Kryo

用户接口

用户接口主要就是上面说的三个，要求是在不改变的情况下实现它们应该有的功能

• @Reference：引用实现类是不存在的，需要生成一个代理类，代理类里进行http调用
• @Sevice：服务类负责把接口导出，需要按一定规则生成并注册路由到Vertx
• RpcContext：这个最简单，在http请求时把数据放入head即可

这里最重要的是保持不变，不影响旧代码的情况下实现功能，否则大量改造就没有意义了

注册中心

这个的方案很多，各有优劣。下面说一种需要平台支持的方案

1. 首先每个服务定义一个svc，可以分组，这样rpc就可以简单的变为对svc进行http请求
2. 平台去收集每个分组和服务对应的svc。可以放在资源注入的时候做
3. 服务启动时，使用接口名去平台查询svc。因为本身就有文档上报，这个并不麻烦
4. 将查询到svc放入缓存，在上面的代理类里需要使用

这个方案将lb完全交给了svc，平台只承担了一部分注册中心的责任。如果想代码里自定义lb，可以进行如下几种方案的改造

1. 在服务上通过kubernetes提供的接口监听svc对应的ep，ep对应的节点就是所有可用的节点
2. 使用headless svc，这样就可以直接dns直接查询到后端pod对应的ip了，这些ip就是所有可用的节点
3. 服务通过轮询或者长轮询等手段，向平台上报自己ip，同时从平台获取svc对应的ip

将lb完全交给了svc的方案可以进一步的将svc暴露成ingress，实现本地访问；但是自定义lb的方案都是直接通过ip，想在本地访问还需要另外设计方案

总结

标题的挖空很合适，如果替换协议不如就不使用整个dubbo了，将其替换成更轻量的vertx。下面我们从保持用户接口的方案开始聊聊整个过程中会用到的各种组件和技术

K8S下挖空Dubbo的一些思路--@Reference
K8S下挖空Dubbo的一些思路--@Sevice