[Cloud][Project] 遗留中间件SDK无感迁移到Capa. #18
Description
Goal
使遗留的中间件SDK能够支持capa的API编程模型，即将API编程模式适配到SDK上。
Claim
尽可能不更改遗留SDK的使用方式，尽量采用增强的方式，最好是对原有代码无任何改动。
Proposal
首先，我们按照云原生运行时API的划分，将常用的中间件划分为以下几个领域，然后从C-Stack中挑选对应的中间件，来查看它们的SDK目前的特性和能力：
| Domain | Middleware | SDK实例获取方式 | SDK方法调用方式 |
|---|---|---|---|
| RPC | C-RPC | static方法获取 | 异构实现类的实例方法 |
| Pub/Sub | C-MQ | new对象获取 | 接口实现类的实例方法 |
| State | C-DB | new对象获取 | 异构实现类的实例方法 |
| Config | C-CONFIG | 无需实例 | 直接静态调用 |
| Metrics | C-METRICS | 无需实例 | 直接静态调用 |
第一种思路：动态代理
实例获取方式中有以下几个挑战：
- static的实例获取方式，导致难以进行动态代理
- new对象的实例获取方式，除非改变编程方式(例如采用注入方式)，否则直接进行new，难以进行动态代理
方法调用方式中有以下几个挑战：
- 异构实现类的实例方法，没有接口定义，无法基于接口生成代理类，只能通过继承的方式
- 直接静态调用，难以进行继承的代理方式
综上，采用生成代理类的方式，很难改变已有的static静态调用的行为。
看起来，如果走动态代理的思路：
C-MQ适合采用 实例注入+动态代理 的实现方式。
C-DB适合采用 注解AOP+动态代理 的实现方式。
其他中间件不适合该思路。（主要因为有static的方法）
待解决问题
通过AOP来更改static静态方法可行吗？我不太清楚
相关资料：https://stackoverflow.com/questions/13744677/set-an-aspectj-advise-for-static-method
第二种思路：字节码更改
我们的目的是什么？是修改SDK调用时的行为，将其重定向到Capa的实现中。
所以，大不了直接把源码改掉就好了。
我们可以用字节码增强技术，拦截对应的中间件SDK的Class，然后直接重写它的所有方法，改为capa调用方式。
| Domain | Middleware | 重写范围 |
|---|---|---|
| RPC | C-RPC | 获取实例的static方法+异构实现类的所有实例方法 |
| Pub/Sub | C-MQ | new对象获取的构造函数+接口实现类的所有实例方法 |
| State | C-DB | new对象获取的构造函数+异构实现类的所有实例方法 |
| Config | C-CONFIG | 所有的public的static调用 |
| Metrics | C-METRICS | 所有的public的static调用 |
缺点：难以debug，而且要求SDK的结构不做大的变更。