René's URL Explorer Experiment

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