[Discussion] RPC in Ctrip. #31
Description
Ctrip实现层方案选型
在Ctrip的RPC实现层选型上，主要考虑SOA SDK和Service Mesh两种模式。
1. SOA SDK
首先，需要将SOA SDK中的接口层和调用实现层做一个分割。
这样可以通过SPI机制，选择加载SOA调用实现层 or AWS调用实现层。
并且业务代码只引入接口层（契约+服务调用接口）。
其次，SOA SDK目前只支持引入具体服务的client-sdk，然后才能调用该服务。
需要引入调用目标服务的SOA实现层的client-sdk；或者SOA需要开发动态调用的能力。
直接使用SOA SDK进行RPC调用的好处是：不需要关注反序列化等步骤。
而缺点是：需要对目前的SOA SDK有较大的改动（接口层实现层分割等）
2. Service Mesh
选择servicemesh的原因是，不需要依赖SOA SDK的更改，可以快速实现MVP的RPC功能。
Servicemesh的一个好处是，支持动态的服务调用。可以通过appId、method等参数，即可发起一次服务调用，而无需提前引入对应服务的client-sdk。
例如在capa-proxy场景，不可能预先知道要调哪些服务，引入全量的client-sdk是不现实的，所以需要动态化调用能力。
但是sidecar返回给业务进程的数据，本身透传了服务端的数据序列化格式，如果不是标准json格式，那么需要客户端针对性的做反序列化工作。
需要针对SOA服务端返回的bjjson序列化格式，做反序列化操作。
但该部分工作是不可避免的，因为存在AWS调用Ctrip的场景，如果AWS端不对Ctrip的数据序列化格式进行兼容，那么就会存在问题。所以从工作量的角度来看，反序列化操作是必须要做的，并且应该放到抽象层，供ctrip、aws一起使用。
总结
综上，如果需要快速实现MVP模式，ServiceMesh方案可以快速实现（因为不依赖于SOA的改造）。
如果采用SOA方案，也是OK的，等待SOA SDK改造完成，实现层也可以从ServiceMesh方案切换到SOA方案。
（ServiceMesh方案主要开发量在反序列化上，但这部分工作本身就会用在AWS端，所以本身是必需的工作量）
最后，如果本身采用的是三层设计 (#32) ，只要API确定好，实现层是可以随时更改的，对上层是无感的；但如果采用两层设计，可能需要更改代码进行适配。