.net core高并发_高可用可拓展的RPC框架 koalas-RPC

企业生产级百亿日PV高可用可拓展的RPC框架。理论上并发数量接近服务器带宽，客户端采用thrift协议，服务端支持netty和thrift的TThreadedSelectorServer半同步半异步线程模型，支持动态扩容，服务上下线，权重动态，可用性配置，泛化调用，页面流量统计，泛化调用等，支持trace跟踪等，天然接入cat支持数据大盘展示等

1：为什么要写这个RPC

市面上常见的RPC框架很多，grpc，motan，dubbo等，但是随着越来越多的元素加入，复杂的架构设计等因素似使得这些框架和spring一样，虽然号称是轻量级，但是用起来却是让我们很蹩脚，大量的配置，繁杂的API设计，其实，我们根本用不上这些东西！！！ 我也算得上是在很多个互联网企业厮杀过，见过很多很多的内部RPC框架，有些优秀的设计让我非常赞赏，有一天我突然想着，为什么不对这些设计原型进行聚合归类，自己搞一套【轻量级】RPC框架呢，碍于工作原因，一直没有时间倒腾出空，十一期间工作闲暇，说搞就搞吧，落地不易，很多细节性问题，比如tcp中怎么解决大量的wait-time,如何做到thrift和netty的兼容等等大量细节的优化，希望源码对大家对认识RPC框架起到推进的作用。东西越写越多，有各种问题欢迎随时拍砖

2：为什么叫koalas

树袋熊英文翻译，希望考拉RPC给那些不太喜欢动手自己去造轮子的人提供可靠的RPC使用环境

3：技术栈

• thrift 0.8.0
• spring-core-4.2.5，spring-context-4.2.5，spring-beans-4.2.5
• log4j，slf4j
• org.apache.commons(v2.0+)
• io.netty4
• fastJson
• zookeeper
• 点评cat(V3.0.0+ 做数据大盘统计上报等使用，可不配置)
• AOP，反射代理等

4：关于技术选型

1. 序列化篇 考察了很多个序列化组件，其中包括jdk原生，kryo、hessian、protoStuff,thrift，json等，最终选择了Thrift，原因如下 原生JDK序列化反序列化效率堪忧，其序列化内容太过全面kryo和hessian，json相对来说比原生JDK强一些，但是对跨语言支持一般，所以舍弃了，最终想在protoBuf和Thrift协议里面选择一套框架，这俩框架很相通，支持跨语言，需要静态编译等等。但是protoBuf不带RPC服务，本着提供多套服务端模式(thrift rpc，netty)的情况下，最终选择了Thrift协议。
2. IO线程模型篇 原生socket可以模拟出简单的RPC框架，但是对于大规模并发，要求吞吐量的系统来说，也就算得上是一个demo级别的，所以BIO肯定是不考虑了，NIO的模型在序列化技术选型的时候已经说了，Thrift本身支持很多个io线程模型，同步，异步，半同步异步等(SimpleServer，TNonblockingServer，THsHaServer，TThreadedSelectorServer，TThreadPoolServer)，其中吞吐量最高的肯定是半同步半异步的IO模TThreadedSelectorServer了，具体原因大家可自行google，这次不做多的阐述，选择好了模型之后，发现thrift简直就是神器一样的存在，再一想，对于服