[Discussion] RPC layer design. #32
Description
RPC层次设计
1. 两层设计
分为接口层和实现层。
接口层为SOA框架的（契约+接口）层。
实现层为Ctrip的服务调用层（see https://github.com/reactivegroup/capa/issues/31） or AWS的服务调用层。
工作内容
首先需要在SOA SDK上做一些更改，将SOA的接口层和实现层做分割。
然后需要在SOA的接口层中，实现SPI动态加载的功能。
然后需要开发Ctrip的服务调用层和AWS的服务调用层。
问题
两层设计的一个问题是，需要针对具体中间件进行定制化开发。例如以上场景中，其实是针对SOA框架进行了定制化开发，如果换一个RPC中间件（dubbo、springcloud等），需要从头开始再重新开发一遍，核心逻辑是没办法复用的。
2. 三层设计
三层设计最大的特点是，把核心逻辑放到抽象层中（CAPA）。
再在抽象层（CAPA）之上，适配到不同的RPC中间件接口层中，以使调用方的代码保持无感。
工作内容
如果要保持对业务代码的无感，那么需要和 方案一 一样，在SOA SDK上做一些更改，将SOA的接口层和实现层做分割。
然后和 方案一 一样，方案一 是在接口层做了SPI功能，那么 方案二 需要在接口层做适配到CAPA的功能。
问题
需要抽象层的API和实现层的API，能够适配。像RPC/MQ这些领域，API的定义比较简单清晰，适配起来难度不大；但像DB/KV这些领域，各个中间件的API定义差别较大，适配起来会比较复杂（例如DB的transaction，redis的特殊数据结构...）
总结
从长期发展来看
三层设计中引入抽象层的好处，是可以做到与具体中间件无关。
假如不引入抽象层（CAPA等），那么必须要为每个具体中间件都开发一套SPI混合云的功能。
短期内是可行的，但从长期来看，这样做容易与社区割裂，相当于自己维护了一套混合云的中间件全家桶。
而对于三层设计，核心逻辑都在抽象层中，代码编写完成后，只需要对上适配不同的RPC中间件接口层；对下适配不同的RPC中间件实现层即可。
从代码维护角度
以及，两层设计是对原有的中间件SDK源码进行修改，需要在中间件SDK内部，找到对应的工厂类或者Provider类，在里面实现SPI这些功能。
如果自己拉一个分支，那么后续和主分支进行同步，也需要维护工作量。并且每个中间件都需要深入学习其源码，进行源码级修改。
而三层设计，是将SPI功能放到抽象层上，下面的实现层使用的是完整的中间件SDK，不需要对其内部进行更改，只需要适配到最外层的API上就可以。
如果用面向对象的角度来描述，那么两层设计就像继承，需要更改内部的逻辑；三层设计像组合，不需要更改内部逻辑，而是通过适配的方式。
没有银弹
综合考量，如果像RPC/MQ这种，业界已经有比较成熟的抽象层API设计的中间件领域，并且该领域的API比较简单清晰，那么引入抽象层我认为是合适的，我们可以与社区保持一致。
如果像DB/KV这样具有复杂API结构的中间件领域，可能短时间内开发一套抽象层并且适配到已有的中间件上还是有难度的，可以先采用第一种方案。