spider RPC需求来源
spider RPC的需求源于作者所在公司布局证券金融服务行业某细分领域2B saas服务平台的需要，以尽可能达到高可靠性、最小化单点影响、单点失败时最小化影响客户数的目标、随时按需动态增加或收缩服务器实例，以满足互联网金融业务量随时剧烈波动的现实场景。
修复某证券期货大金融软件服务公司某java中间件通信框架下列潜在缺陷：
- cpu利用率在90%以上运行超过几十分钟后有可能jvm进程hang的问题；
- TPS无法随着服务器配置的增加线性扩展；
spider RPC公开版支持以下特性：
注：部分特性处于特殊场景考虑，公开版不开放。
- 能够根据请求包里面的功能号、子系统号进行静态路由；
- saas化。能够根据请求包里面的机构号、产品（系统）号、版本号进行动态路由。
saas架构的理想模式就是所有的业务实现均原生支持多租户。
如果做不到原生支持多租户，按照一个租户一个runtime，也需要动态能够设置某个runtime提供对哪个客户的支持，这肯定不能让运维动态更改配置文件，他只需要中心化指定即可。
即使能做到，也需要支持动态能够设置某个app提供对哪个客户的支持，因为一个app仅能够提供对有限个客户的支持，且mysql也不可能做到一个库支持所有。
反之，如果做不到原生支持多租户，则app必须支持多数据源切换以及动态管理，因为通常一个客户通常难以大到需要一个app去支持的程度。 - 支持服务器集群中的各节点负载均衡（根据模式）；
- 支持基于中心化管理的大型部署和独立管理的中小型部署；
- 支持自动重连到断开的服务器节点；
- 支持中心化剔除已删除的服务器节点；
- 支持中心化增加服务器节点；
- 支持中心化删除服务器集群；
- 支持中心化增加服务器集群；
- 一个可执行组件，支持任何时候节点（Work Node，WN）作为路由服务器（Node Broker，NB）或处理服务器（Node Processor，NP）；
- 基于TCP/IP协议，支持客户端语言无关；
- 节点间技术上对等，即允许同时满足A是B的客户端，B是A的客户端，只要保证路由不形成死循环即可；
- 支持报文加密；
- 能够自动校验报文是否被篡改；
- 支持客户端认证功能；
- 支持报文压缩；
- 支持是否启用服务端功能；
- 能够中心化监控所有中间件的运行状况；
- 支持基于java Spring IOC注解方式的Java原生式远程服务调用；
- 最小化节点本地（集中化）配置；
- 支持List泛型；
- 灵活的路由，任何服务都可以发送到任何集群（暂不支持到具体的节点）。