提议分开 http 和 gRPC 的实现代码

[kids-return]

1. 可以在项目中 同时支持 http 和 gRPC 两种协议，配置里不再需要 'protocol' => Protocol::HTTP,
2. 对强类型更友好 例如

   
   现在的 Tcc callBranch
   public function callBranch($body, string $tryUrl, string $confirmUrl, string $cancelUrl)

之后 Http 文件的 TCC callBranch public function callBranch(array $body, string $tryUrl, string $confirmUrl, string $cancelUrl)

gRPC 文件的 TCC callBranch public function callBranch(\Google\Protobuf\Internal\Message $body, string $tryUrl, string $confirmUrl, string $cancelUrl)

3. 维护起来更方便，相关的实现之间不会有影响，也便于后续的协议扩展

[kids-return]

改动的可能有点大，官方的客户端也是分开的

[PandaLIU-1111]

这个可以改，但是会造成BC。还有一个，协议混用的场景多吗，我是认为提供过多可以调用的方法，对于使用者来说在协议切换的时候还得改代码，这块也不是很友好

[kids-return]

相对来说我认为切协议 修改代码是必要的，协议混用的场景我也无法确定多不多，但如果遇到混用的话将会很麻烦，即使切协议也要全部的服务都切，无法实现只切一部分，切部分协议就是混用的场景呀。

[kids-return]

如果只能使用一种协议，全切的成本也是巨大的，必须全部涉及到的服务协议修改完成才能切，还需要大量的测试。 目前 gRPC 我只跑通了一半的 TCC，现在的版本即使 BC 影响也不会很大，当前版本是0.2.x，在没到 1.0.0前 0.3的版本就能BC

[kids-return]

相对来说我认为切协议修改代码是必要的，协议混用的场景我也无法确定多不多，但如果遇到混用的话将会很麻烦，即使切协议也要全部的服务都切，无法实现只切一部分，切部分协议就是混用的场景呀。

如果切部分协议是混用的场景，越往后切协议的成本就约高，导致很难切最后基本不可能切，不如早早提供混用的场景便与后期可以过渡，代码层面也更友好

[huangzhhui]

把两个放一起是故意的设计，我不认为分开更好，会造成很多代码的浪费，PHP 本身可以接受多种参数类型，写成以下的方式即可

public function callBranch(\Google\Protobuf\Internal\Message|array $body, string $tryUrl, string $confirmUrl, string $cancelUrl)

[PandaLIU-1111]

把两个放一起是故意的设计，我不认为分开更好，会造成很多代码的浪费，PHP 本身可以接受多种参数类型，写成以下的方式即可

public function callBranch(\Google\Protobuf\Internal\Message|array $body, string $tryUrl, string $confirmUrl, string $cancelUrl)

这块我考虑另外一个问题，就是在协议切换的时候，比如我原本的服务用的是 http协议的，后面在切换GRPC协议，是否会有协议混用的场景，按照目前的做法应该是不支持协议混用的场景的

[huangzhhui]

协议混用理论上是可以支持的，就看要不要去做了，我是希望弱化用户对协议层的关注和理解，只通过一个配置值就能内部隐式完成切换