Grpc升级1.3.0后，服务路由该怎么做

摘要

Gprc Java最近1.3.0 Release了

1. 首先是Keepalived机制
   1）客户端的Keepalives设置可以work了
   2）设置Keepalives后，在整个网络连接建立完成之后，会不断的发送ping消息给服务端
   3）服务端根据Keppavlied的ping消息来自动识别哪些连接是断了的
2. 服务端可以设置连接的时效了
   1）当设置连接的最大时间到了，该连接将会中断掉
3. 增加了trace的一些传递
4. 对LoadBalancers进行了一些变化

重点说说LoadBalancer的一些变化

在1.1.0版本，整个Lb的工厂类是这样的

private static class RoundRobinLoadBalancer extends LoadBalancer { private RoundRobinLoadBalancer(TransportManager tm){ this.tm = tm; }

而TransportManager是建立trsnsport的管理通道，而真正做负载均衡是这样的

@Override public T pickTransport(Attributes affinity) { final RoundRobinServerList addressesCopy; synchronized (lock) { if (closed) { return tm.createFailingTransport(SHUTDOWN_STATUS); } if (addresses == null) { if (nameResolutionError != null) { return tm.createFailingTransport(nameResolutionError); } if (interimTransport == null) { interimTransport = tm.createInterimTransport(); } return interimTransport.transport(); } addressesCopy = addresses; } return addressesCopy.getTransportForNextServer(); }

而现在这些都没了，变成了一个叫做Subchannel来做这件事情了
针对Subchannel在他的注释里写了

/** * A logical connection to a server, or a group of equivalent servers represented by an {@link * EquivalentAddressGroup}. * *

It maintains at most one physical connection (aka transport) for sending new RPCs, while * also keeps track of previous transports that has been shut down but not terminated yet. * *

If there isn't an active transport yet, and an RPC is assigned to the Subchannel, it will * create a new transport. It won't actively create transports otherwise. {@link * #requestConnection requestConnection()} can be used to ask Subchannel to create a transport if * there isn't any. */

大概意思是一个逻辑连接而非真正的物理连接，里面有可能有一个或多个地址来
他维护了一个真正的物理连接去真正的建立Rpc的连接，而当连接状态还没有变成活动的时候，他将建立一个transport

所以这里比较有意思：
首先，grpc针对transport再进行了一次封装，把transport的建立提前了,在从nameresove拿到ip地址后，马上就会进行requestConnection

@Override public void requestConnection() { subchannel.obtainActiveTransport(); } @Nullable ClientTransport obtainActiveTransport() { ClientTransport savedTransport = activeTransport; if (savedTransport != null) { return savedTransport; } try { synchronized (lock) { savedTransport = activeTransport; // Check again, since it could have changed before acquiring the lock if (savedTransport != null) { return savedTransport; } if (state.getState() == IDLE) { gotoNonErrorState(CONNECTING); startNewTransport(); } } } finally { channelExecutor.drain(); } return null;

而真正实现负载均衡的是SubchannelPicker

/** * The main balancing logic. It must be thread-safe. Typically it should only * synchronize on its own state, and avoid synchronizing with the LoadBalancer's state. * *

Note: Implementations should override exactly one {@code pickSubchannel}. */ @ThreadSafe public abstract static class SubchannelPicker { /** * Make a balancing decision for a new RPC. * * @param args the pick arguments */ public abstract PickResult pickSubchannel(PickSubchannelArgs args); }

所以，在这里的整个负载均衡机制和原来1.1.0版本已经完全不同，如果想在负载均衡前面再加一次路由规则的限制的话，需要重新修改
我是这样修改的：
对SubchannelPicker进行扩展，当选择做负载均衡的时候，把某一些建立的Subchannel给踢掉

@Override public PickResult pickSubchannel(PickSubchannelArgs args) { Map affinity = args.getCallOptions().getOption(GrpcClientCall.CALLOPTIONS_CUSTOME_KEY); GrpcURL refUrl = (GrpcURL) affinity.get(GrpcClientCall.GRPC_REF_URL); if (size > 0) { Subchannel subchannel = nextSubchannel(refUrl); affinity.put(GrpcClientCall.GRPC_NAMERESOVER_ATTRIBUTES, nameResovleCache); return PickResult.withSubchannel(subchannel); } if (status != null) { return PickResult.withError(status); } return PickResult.withNoResult(); } private Subchannel nextSubchannel(GrpcURL refUrl) { if (size == 0) { throw new NoSuchElementException(); } synchronized (this) { Subchannel val = list.get(index); index++; if (index >= size) { index = 0; } //剔除不合规的Subchannel boolean discard = discard(refUrl, val); if (discard && index != 0) { nextSubchannel(refUrl); } return val; } }

但是这样有一个问题，剔除掉Subchannel，但是其实其Transport其实还在，还是浪费了整个客户端的资源，这个问题暂时也没有好的办法，如果把该Subchannel给shutdown掉，由于在接到了nameresovle的地址列表了，已经建立起了transpot了，如果shutdown了，将会触发nameresovle的refresh，重新获取地址，这样又是一个重复的循环，并不合算，所以只能是暂时浪费了一点内存来做服务路由了

扩展后代码如下：
https://github.com/linking12/saluki/blob/master/saluki-core/src/main/java/com/quancheng/saluki/core/grpc/GrpcRoutePicker.java

文章写的比较乱，主要是在升级Grpc后碰到的一些问题，然后想出的一些解决办法，希望看得懂
另外，吐槽一下，在选择很多人说自己写个rpc，他搞一下，他也弄一下，其实rpc不是那么简单的传输一个数据就拉倒这么简单，维护连接的状态，传输的数据这些都是要方方面面需要考虑的事情，现在业界有许多rpc的基础组件在了，如果用在生产上就不要自己造个轮子重新实现一套rpc
基于http2的有grpc、armeria都是一个比较靠谱的选型，而不是一来就我要自己造一个轮子实现以下rpc