Rpc网关

背景

用户下单后，商家的ERP系统想实时获取订单数据，以提供更好的服务。一个解决方案是，商家在公有云环境订购一个RDS，用户下单后，平台实时的将订单数据推送到此RDS中。但是，此方法碰到一个网络问题 此前通过一个对公网开放的OpenAPI网关解决网络不通问题，但是此方案需要走公网带宽，极大的提高了服务成本，同时第三方提供OpenAPI开发效率低下。所以，引入了代理网段“打通“公有云跟生产网 代理网段是一个特殊的网段，在这个网段的每台服务器可以申请一个各自的VIP1，然后云环境就可以VIP1访问此服务器。还可以申请一个VIP2，这样生产网就可以通过VIP2访问此服务器，但显然此服务器是无法主动访问生产网的。 通过引入代理网段，就有了以下方案 在代理网段构建一个rpcProxy集群。这样云环境只需要提供一个rpc服务，生产进行服务调用即可。在开发过程中，如同Dubbo一样简单方便，极大的提高了开发效率，同时不需要消耗公网带宽，大大的减少了服务成本

---

架构设计

传统的RPC框架Provider会开启监听端口，等待Consumer请求。但是，在此网络环境下，Proxy无法主动访问Provider，所以需要Provider主动访问Proxy，即在CS架构下，Provider也是Client一方. 这也决定了无法直接在Dubbo等开源框架上进行扩展，所以我们决定重头开发一个简易RPC框架+代理网关。本着简单的原则，设计了如下架构：

这个架构非常简单，配上监控降级等Ops系统，很好的解决了我们的需求。
但是，这个架构有个明显的缺陷，那就是每一台ProxyServer都需要跟所有的Provider跟Consumer维持长连接，即缺乏扩展性，无法接入更多的业务系统，无法平台化

平台化

我们的环境Consumer跟Provider总共就300来台服务器，所以为了快速开发，一开始我们就采用上面的专用化方案，总共架设了50来台ProxyServer搞定了这个需求. 需求发布后，没多久我们收到了个别业务方表示也有这方面的需求，这让我们有了平台化的诉求。但是平台化是个复杂的工程，本着学习的态度我们进行了一些尝试。

上面的架构主要问题是每台ProxyServer都需要维持所有连接，那我们就让Provider只连接部分ProxyServer。这显然是带状态的设计，这让我们想到了一致性Hash，同时为了简化Proxy的逻辑，我们将状态交给Provider维护

1. Proivder根据{provider_name}做一致性hash，筛选出一批ProxyServer进行服务注册（上面架构图步骤1）
2. 经过一致性has后，从大的层面看，我们发现无需多大改动，系统就支持了这种按Provider切分。但是，从细节处，优雅上下线，连接管理变的复杂的多，有很多细节是需要优化的
3. 此外，平台化后，还需要有接入平台，更加专业的监控，管理等Ops系统支持.