2016年5月18日我提交了rpcx的第一段代码，那是一个基于标准rpc库的扩展，期望能够扩展rpc的功能，提供更多的服务治理的功能。
2016年初我的第一本技术书《Scala集合技术手册》出版了，这本书花费我太多的心血在编写和技术呈现上，但是我终于能腾出时间做点其它的事情。
正好，从Motorola出来后的创业公司被Comcast收购，Comcast的很多业务都是使用Go做开发的，虽然从03年到这个时候我还是使用Java开发，但是也在尝试使用Go做一些东西。一开始我对Go是有一定的误解的，首先对于它的非C风格的语法有些抵触，另外还认为它只能用来写一些小工具，根本没有意识到它的企业级应用的价值。随着慢慢地对它的熟悉，才渐渐感觉到它的强大，逐渐被它的简洁和并发编程所吸引，并且相信它是未来应用广阔的编程语言之一。
来到微博后就基本全时间的使用Go做开发，开发了服务发现和配置中心、消息队列、区块链、redis云服务等系统，越来越对Go语言有了更深的认识，也越来越喜欢上了这个简洁的开发语言。现在回过头来看2016年的一些探索，真是走对了方向。所以说， 2016年是rpcx的元年，5.18是它的诞生日。
1.0
最初的想法，是想创建一个项目，用来熟悉和学习Go语言。但是我不想纯粹写hello world的程序，而是想写一个有价值的项目，一个能长久活下去的项目，一个能给其它人带来价值的项目。
dubbo是Java生态圈非常有名的一个rpc服务治理的框架。虽然在阿里的内部竞争中不行败下阵来(这里面应该有一段错综复杂的故事),但是在其它一些电商却得到了广泛的应用，这是出乎我意料的。因为在我想象中，这些电商的技术能力应该是很强大的，应该使用自研的rpc服务治理的框架，不屑于dubbo这种不再活跃的开源项目，况且它的很多依赖包括spring框架都是非常老的了，如果使用它意味着公司的技术栈依赖的库都是要非常老的版本。我是一个现实主义者，相信存在即合理，相信大家使用dubbo框架是因为它的功能，它的优势。（当然现在dubbo框架又活跃起来了，还成为了apache的项目，依赖的库也得到了更新）
dubbo的很多概念都是很使用的，服务治理的功能也很强大，并且还可以扩展。我当时站在北京的香山之巅鬼见愁的悬崖上，抚剑环顾四周，白茫茫一片，还没有看到Go语言中有一个可以匹敌的框架。尽管优秀的web框架比如beego不断的涌现，但是rpc服务治理框架还没有踪影。这是一个空白!
很显然，rpc服务治理框架是互联网企业迈不过的一道技术门槛，Go语言要想在企业中后台中大规模的应用，必然需要一个rpc服务治理的框架。
虽然当时离grpc的初版发布了有一年了，thrift也开始支持Go语言，但是明显这些rpc的框架的方向是朝向跨语言的路数上走了，dubbo、motan走的是服务治理的一条路。即使是现在，我也不认为grpc是一个服务治理的框架，虽然现在也开始支持load balancing这样的功能，但是路由还是很简单，离整体的服务治理框架还有很大的差距。如果在企业中大规模的应用，肯定还有做很多的开发工作，这些工作的汇总在一起可能会诞生一个新的框架，貌似有些公司在做这样的一些工作，但是扩展起来还是很有难度的，因为grpc的扩展需要考虑到跨平台的能力，一旦涉及到很多的语言就有一个tradeoff的考虑。
Go标准库的rpc是一个非常赞的库，代码量不算太多，但是性能非常优异，远远大于很多的服务治理的框架。它的设计也很简单，服务器启动的时候注册服务，客户度通过tcp连接和服务器通讯，协议分为header和payload两部分，header很简单，包括服务名、方法和seq，payload包括序列化的数据。
最让人赞叹的是,标准库设计的非常的简洁。rpc的本质是什么，远程方法调用。即使是一个初学者，会写hello world,就会写rpc服务了，你只需要写一个带两个参数的方法就可以了。
部署和调用也很简单。服务器启动的时候注册一下，指定启动的地址和端口就可以了。客户端指定连接服务器的地址和端口，传入要调用的服务和方法就可以了。
非常的简单！你不要以为这是很平常的一件事，看看现在市面上的现有的rpc框架，你就知道这是一点多么了不起的事情了，也明白很多rpc服务治理框架有多渣渣。只是简单写一个一行的hello wolrd的例子，你可能创建很多的数据结构和方法，还要进行几十行甚至上百行的配置文件，而且服务器和客户端还要不同的配置文件。
对于复杂性这一点，grpc、thrift虽然也创建复杂的数据结构，但是对开发者来说，它是"隐藏"的，而且是自动生成的，这还是可以接受的，但是如果需要的你手工创建一些辅助的类型、方法、对象，这绝对是对开发者一种精神的折磨。
复杂的配置文件也是一种精神折磨。虽然需要定制一些额外的服务治理的功能，我们需要设置一些属性，但是如果将这些配置设计成非常复杂的结构，貌似很有条理，实际就是一坨。最简单的调用处理peer的ip和端口，以及调用的服务和方法，其它都是不需要配置的。需要配置的东西也是可以链式调用一行完成。
很遗憾目前我看到很多的rpc框架都是涉及的非常复杂，所以每次看到大师实现的标准rpc库都是由衷的敬佩，阅读起来代码就像听音乐一样让人愉悦。
rpc又提供了灵活性，本身它还提供了jsonrpc 1.0的功能，也有第三方库提供protobuf、msgpack的编解码器，还有jsonrpc 2.0的支持。
虽然rpc库的开发已经被冻结，但是如果你想在Go程序中实现点对点的rpc通讯，标准库还是首选，如果你想实现跨语言的点对点的rpc通讯，优先选择grpc，如果你想实现dubbo一样的服务治理的框架，2016年还没有选择。
所以我参考dubbo的功能，基于标准库的基础上逐步实现了服务治理的功能，包括zookeeper、etcd等注册中心、各种fail的处理、丰富的路由功能等等。
最初的设计就是包装标准库，在它的基础上提供插件的功能，各种服务治理的功能通过插件的方式去实现。
2.x
随着rpcx的功能不断完善，知名度也慢慢地扩大，越来越的开发者开始关注到这个项目，包括国外的一些开发者和使用者，大家提出了一些新的需求。在分析和实现这些需求的过程中，我发现依赖的标准库成了rpcx进一步开发的制约因素，很多功能可以通过简单的修改标准库来实现，但是因为无法修改标准库而无法实现这些需求，或者实现这些需求特别复杂。
所以在2.0版中，我把标准库复制出来，rpcx不再依赖Go的标准库，而是使用复制的rpc库，这样我就可以在复制的库中进行修改，这大大增加了rpcx的灵活性。
在这个版本中，rpcx的主要功能都已经成型，包括:
- 数据的传输方式，支持TCP、unix domain、HTTP、QUIC、KCP等
- 注册中心支持 点对点、点对多、zookeeper、etcd、consul等
- 多种编解码方式如protobuf、json、msgpack等
- 失败处理模式如FailFast、Failover、Failtry、Fork、Broadcast等
- 各种路由如轮询、随机、一致性哈希、权重、网络质量优先、地理位置优先等
- 元数据等
- 限流、别名、web管理工具等
并且，有网友反馈使用定制的rpcx服务替换原先的java服务，用在了游戏服务器的防御日志上，减少了一半的服务器，并且服务器的负载都很低，每个月能减少50万的费用，这是很令人鼓舞的事情。
3.x
3.0进行的重新，去掉了复制出来的标准库，完全自己重写。原因在于标准库的通讯协议过于简陋，相对rpcx做更复杂的功能不是太好扩展。
重新实现内存通讯协议的想法来源两个。一个是在微博实现包捕获和重放工具的时候，积累了协议涉及和实现的经验，第二个很重要的启发式微博张雷周晶他们正在做的新一代的Motan设计。微博内部广泛的使用Motan服务，为了应对微服务化的趋势，张雷他们对Motan进行了升级，既保持向下兼容，又重新设计了Motan协议。rpcx 3.0深受Motan协议的启发，结合标准rpc库的时候，rpcx实现了新一代的通讯协议。
新一代的rpcx协议包括header、变长信息(service名称、方法名、元数据)、payload三部分。header有固定的长度，采用二进制的方式压缩占用空间，也参考了TCP等协议栈的数据结构，变长信息采用LV的格式(长度+数值)，因为都是字符串类型，所以TLV协议中的T(type)可以省略。Payload是序列化后的byte slice。
协议采用尽量少的额外数据，又不失灵活性，保证协议的可扩展性和可升级。
同时，有用户反映rpcx引用的包太多，很多不需要使用的库都不得Registy不下载下来，比如使用etcd注册中心，zookeeper库也不得不下载下来。经过权衡，决定采用go tags的方式，通过tag将主要的可移除组件进行分来，可以有选择的进行下载，目前支持的tags包括：reuseport quic kcp zookeeper etcd consul ping utp。
这也给Go初学者带来的麻烦，不止一次的在QQ群中给新人介绍为什么EtcXXXXXX文件本地存在，而编辑器无法找到对应的struct。事实上目前的IDE如vscode、golang、vim-go等都支持设置tag。但是对于没有使用过tag不了解go tag的开发者来说，确实是一件让人困惑的事情。
当然也可以通过拆成子package的方式，就像各种数据库驱动实现的方式一样，可是这样子package太多了，而且每个子package中只有一两个文件，过于分散。
目前还是保留tag的方式，如果将来有更好的方式再做替换。
同时创建了丰富的示例，文档不足示例来补，基本上为rpcx的每一个特性都编写的可运行的示例，而且示例代码不足百行，很容易学习。
受grpc gateway的启发， 3.1中增加了 rpcx gateway的一个项目，可以部署一个gateway,支持各种编程语言的http调用，由gateway进行转换成rpcx协议进行转发，解决了跨语言的客户端调用问题。
更进一步，直接由rpcx服务器直接提供http调用，不用使用gateway转发。而且通过cmux库，实现一个监控可以同时支持纯的rpcx调用喝http调用。
同时增加了双向通讯的功能，这样服务器也可以给客户端推送消息。
增加了一个xgen工具，可以为指定的go代码生成服务器端的注册和服务启动功能，纯粹是一个辅助工具。
4.0
rpcx开发步入正轨，基本每一年发布一个大的版本。
4.0支持更多的可信赖的udp的实现。提供了OneClient对象，一个对象可以调用多个服务。完全实现了压缩的功能。增加了更多的监控的插件，优雅关机等功能。
小米的热心同学提供的rpcx-java， 可以使用Java实现服务器端和客户端的代码，而且保留和扩展了服务治理的功能，这样rpcx在Java生态圈也可以得到很好应用。
注册了 https://rpcx.io 域名，提供了rpcx的官网。
提供了中文文档。
5.0
今年年底发布rpcx 5.0版，增加了对opentracing和opencensus的支持，目前这两个项目已经合并，rpcx也会提供对合并后的规范的支持。
提供了JSONRPC 2.0的支持。
支持CROS跨域调用。
内置了client pool的支持。
目前为止，rpcx支持的主要功能包括：
- 数据的传输方式，支持TCP、unix domain、HTTP、QUIC、KCP等
- 注册中心支持 点对点、点对多、zookeeper、etcd、consul、mDNS等
- 多种编解码方式如protobuf、json、msgpack、thrift等
- 失败处理模式如FailFast、Failover、Failtry、Fork、Broadcast等
- 各种路由如轮询、随机、一致性哈希、权重、网络质量优先、地理位置优先等
- 元数据 身份认证
- 限流
- 别名
- metric监控
- 超时
- 心跳
- 分组
- 熔断器
- gateway
- http调用
- JSONRPC 2.0
- 双向通讯
- opentracing和opencensus
未来
rpcx越来越多的被一些创业公司和成长型的公司所使用。比如拍够购：
但也有网友提出了rpcx前景的一些问题。
1、现在大家都service mesh了，传统的rpc服务治理框架还有前景吗
两个方面，对于istio这种重度依赖kubernetes的service mesh,需要公司对k8s有很好的把控，开发和运维要求都很高，这限制了这种技术栈的被广泛的采用。另外一个是不使用k8s，那么需要你自研service mesh，自研的service mesh也可以方便的使用rpcx实现。
我不认为service mesh会是一统天下的微服务模式，传统的胖客户端的rpc模式也很有竞争力，如果加上容器化自动部署的功能，可能运维上的成本会小的很多。
2、rpcx没有大厂使用，连微博都不使用，是不是没前途
大厂很少采用开源的微服务框架实现它们主要服务的。大厂那么的开发人员，会有专门开发小组开发部门去实现自己的rpc框架，比如阿里巴巴、蚂蚁金服、微博、京东等等。比如微博，自创建开始就使用Motan自研的rpc框架，现在主要服务都使用Motan开发，不可能要求成千上万个服务都重写使用新的rpc框架。同时大厂也要保证自己的技术栈的掌控度。
但是对于创业公司和成长性的公司，主要的目标是技术要配合业务的快速发展，提供规模可扩展的技术栈以适应业务的变化和急速发展。采用的技术栈开发要简单(人少)、性能要强大(钱少要求多)、规模可扩展(业务急速发展)。我觉得rpcx在这些公司中的市场还是很大的，并且公司发展到大厂一样的规模后，rpcx依然还能保持它的灵活性和支撑业务的发展。
3、rpcx要支持多久
没有一个软件是永远能活下去的，但是rpcx会一直坚持下去，直到有一天一个能超越rpcx的框架出现，得到大家的认可，大家不再关注rpcx了，那个时候才是rpcx停下的时候。目前我还没看到这种机会出现。
引用IntellJ的一句话作为结束语:
Try it. Test it. If you feel it’s better, use it!