2014年第一分钟，新浪微博的发布量以808298条再次刷新记录，第一秒微博发布量相较去年提升55%。（数据来源：新浪科技 ）这是微博平台 RPC 框架 “Motan” 上线后第一次抗峰值，整体表现平稳，基本达到最初的“应用方无感知”的目标。
在RPC服务化这个事情上，微博平台不是第一个吃螃蟹的：早的有亚马逊和eBay等国外先驱，近的有Twitter的finagle，淘宝的dubbo等等，网上各种公开的资料铺天盖地。另一方面，单纯的RPC调用功能实现，从技术上看其实并不复杂：client 发起调用，框架拦截调用信息，序列化，传输，server端收到调用信息，反序列化，根据调用信息发起实际调用获取结果，再原路返回。实现这些功能可能也就三五天的事情，但在一个复杂的业务环境下，稳定可靠的应用它，才是最大的挑战。
微博平台的 RPC 服务化拆分历程始于2013年7月。在此之前，我们花了很长的时间讨论服务化的目标，主要是项目的范围：哪些问题不属于服务化项目需要解决的问题。 实际的框架代码开发花了三个工程师（王喆@wangzhe_asdf9 陈波@fishermen 麦俊生@麦俊生）大约一个月时间，然后花了将近两个月的时间推动在第一个业务上线：调整工程师的开发模式，调整测试流程，修改上线系统，添加监控和报警，小流量测试，灰度发布，最后才是全量上线。然后又花了一个月，在微博平台主要业务中全部上线。
微博RPC的一些基本的数据指标：
Motan 框架：2w+ 行 Java 代码，1w 行 test 代码，UT行覆盖率超过 70%（当前 Motan 实现中，与微博平台内部多个系统都有功能绑定，还不具备开源条件，但开源是我们从一开始就设立好的目标之一）
支持 2 种调用方式：inJVM 和 TCP远程调用。inJVM 方式类似 loopback 网卡：数据经过了协议栈流程处理，但没有流经真正的网络设备。inJVM方式主要用来支持开发调试和测试，以及在RPC服务上线初期作为Fail-Back降级使用
典型业务场景下单实例 tps 极限 20k，微博平台一般采用单机双实例，即单机极限 40k
典型业务场景下平均响应时间 <3 ms，框架层额外消耗 < 0.01 ms
最大的单个核心业务日调用量超过 800亿次
RPC服务化的目的大约有两种：将一个大一统的应用拆分成多个小的RPC服务，那么目的就是为了解耦和，提升开发效率；如果是将传统的Http或其它方式远程调用改造成高效的RPC调用，那么就是为了提升运行效率。不幸的是，微博平台的RPC框架，需要同时达到这两个目的：既要在平台内部将一个大一统的应用拆分，又要考虑到后续向开放平台的大客户们提供RPC接入的可能。因此，微博平台在技术选型和方案设计上做了很多的权衡和妥协：
首先，是选择已有开源方案，还是自己开发一个新方案？选择的依据按重要程度排序：是否满足自己的核心需求，方案成熟度，认知成本（即二次开发难度）。由于是拆分一个已有的复杂应用，微博平台的一个核心需求是：应用开发方希望尽可能的平滑迁移，最好能做到应用方无感知。我们评估的多个开源方案没有一个能满足，所以只能自己做一个了
灵活性与误用的可能性：框架开发方总是有一个偏见，觉得我这个框架越灵活越好，最好每个步骤每个环节都是可以由使用方自己配置或定义。但对于一个内部强制使用的框架来说，使用方式的统一性也同样重要，换句话说，对于大部分的环节步骤，都需要保证团队内部各使用方都按同样的方式进行配置，防止误用，并降低学习和沟通成本。我们的经验是，框架开发完成后，还需要有“框架使用方”角色，将所有的灵活性限制在框架使用方的层面，避免直接暴露所有细节到最终的业务开发方
序列化方式选择：微博平台从2011年引入了 PB 序列化方式，以替代 cache 和 db 中的 json 文本。但在 RPC 框架上线过程中，我们选择了对 Java 对象更为友好的 Hessian2 。因为之前的 PB 序列化需要定义 proto 文件和生成代码，平台只对必要的 model 类做了支持，而 rpc 可能涉及到更多的 wrap 类，业务逻辑类等，为所有的类提供 pb 支持的工作量太大，而且后期维护困难。当然了，Motan 框架支持各种不同的序列化方式配置。
通讯协议选择：在评估了几个开源RPC框架的协议设计后，我们最终选择了在 TCP 链接基础上设计自己的 RPC 通讯协议，一个简单的二进制协议：定长 header 中包含一个 length 字段，然后就是二进制的 body payload，即序列化之后的 rpc request 或 response 。
集群管理：微博平台Motan框架当前依赖于内部开发的Config Service（Code name Vintage，based on ZooKeeper）来进行服务注册，服务发现和变更通知。
Trace系统：微博平台Motan框架当前依赖于内部开发的类似Twitter Zipkin的Trace系统（Code name Watchman）来对RPC请求做抽样及全量trace。
Motan 架构图（RPC调用数据流图）