tonyiscoding

咱们直接拉个分支, 单干了?

such an unfortunately infomation ! we want use python3; this maybe an solution for overload: https://python3-cookbook.readthedocs.io/zh_CN/latest/c09/p20_implement_multiple_dispatch_with_function_annotations.html

Niubility

### 背景 目前系统的负载均衡设计还没完成, 用默认的第一个节点代替了，需要设计一套负载均衡的抽象和实现示例来； ### 思路 - 负载均衡是需要基于注册中心的可用服务注册节点来的, 同一个 ServiceMeta下可能会得到多个 RegistryMeta，即一个服务可能有多个节点 -- 所以他的设计应该是高于传输层，依赖注册中心层 ### 拓展性 - 希望先抽象出一套API来, 这样能够后面基于这套API来进行拓展, 让用户自主选择负载均衡策略，甚至自定义 - 负载均衡的调度目前只考虑在 Connector维度, 暂时不考虑更细的 - 希望能够支持主流的lb算法, 所以设计的抽象度需要足够高 ### 风险与问题分析 - 并发问题,...

### 背景 目前系统有了 心跳机制、断线重连、空闲检测 但是这些功能的设计还不是很 完善，需要优化和完善点还很多 ### 思路 简单调整，参考市面上的主流设计方案, 优化 + 测试

### 背景说明 系统需要做一个流量控制, 针对一些使用场景下, 对服务的保护、对服务的限制 需要从外部流量入口着手 ### 思路 因为目前RPC的设计是应用级别提供服务的, 所以设计限流做到服务级别的限流即可 目前系统设计有 1. provider processor 层, 这一层基本上解析完成了消息, 可以在这里进行限流行为 2. 需要考虑后续 processor是会有自己的一套线程池的, 所以这里统计请求数量, 需要在多线程统计 3. 限流算法应该需要做到 多种限流的支持, 分布式限流这个目前倒是没有很大必要, 服务的自我保护做好即可，其他交给上层lb ### 拓展性 1....

### 背景 目前系统需要支持服务查找方案, 当请求到服务端后,对请求解析完成，需要高效的手段实现快速的方法查找和方法调用, 并把执行的结果响应 给到客户端 ### 设计思路 - 反射? -

hello, how was it going?