Java系统和PHP系统相互调用

1、HTTP JSON方式的缺点

1. JSON序列化效率低
2. 多语言服务治理功能低

2、关于RPC框架

RPC 框架大体分为两类，一种是偏重服务治理，另外一种侧重跨语言调用

2.1 服务治理型

特色

功能丰富，提供高性能的远程调用、服务发现及服务治理能力，适用于大型服务的服务解耦及服务治理，对于特定语言(Java)的项目能够实现透明化接入。缺点是语言耦合度较高，跨语言支持难度较大。

经常使用框架

• Dubbo
• Motan

2.2 跨语言调用型

特色

侧重于服务的跨语言调用，可以支持大部分的语言进行语言无关的调用，很是适合多语言调用场景。但这类框架没有服务发现相关机制，实际使用时须要代理层进行请求转发和负载均衡策略控制。

经常使用框架

• Thrift
• gRPC

3、如何提供服务给PHP系统

Dubbo(阿里开源)

3.1 Dubbo + dubbo-php-framework

特色

能够实现php调用php，php调用java(dubbo)，java(dubbo)调用php，Java调Java，真正的跨语言

缺点

开发活跃程度极低，社区小，资料少，没有release版本

3.2 Dubbo Restful（合并自Dubbox）

特色

显著简化企业内部的异构系统之间的（跨语言）调用。
服务消费场景：

1. 非dubbo的消费端调用dubbo的REST服务（non-dubbo --> dubbo）
2. dubbo消费端调用dubbo的REST服务 （dubbo --> dubbo）
3. dubbo的消费端调用非dubbo的REST服务 （dubbo --> non-dubbo）

问题

1. Dubbo REST的服务能和Dubbo注册中心、监控中心集成吗？

   能够的，并且是自动集成的，也就是你在dubbo中开发的全部REST服务都会自动注册到服务册中心和监控中心，能够经过它们作管理。
   可是，只有当REST的消费端也是基于dubbo的时候，注册中心中的许多服务治理操做才能彻底起做用。而若是消费端是非dubbo的，天然不受注册中心管理，因此其中不少操做是不会对消费端起做用的。

2. Dubbo REST中如何实现负载均衡和容错（failover）？

   若是dubbo REST的消费端也是dubbo的，则Dubbo REST和其余dubbo远程调用协议基本彻底同样，由dubbo框架透明的在消费端作load balance、failover等等。
   若是dubbo REST的消费端是非dubbo的，甚至是非java的，则最好配置服务提供端的软负载均衡机制，目前可考虑用LVS、HAProxy、 Nginx等等对HTTP请求作负载均衡。

montan（微博开源）

3.3 motan + motan-php

Java系统使用motan提供服务，php系统使用Motan-PHP（PHP client）调用服务。

特色

motan暂不支持以服务注入方式引用yar 服务（使用motan做为yar client）。
目前yar协议主要解决java与php互通的问题，当java做为服务端，php做为client端，php能够在不作任何修改的状况下经过yar 协议使用java的服务。
而使用php作server、java作client的场景下（通常这种场景比较少），php的yar server不支持注册服务等功能，因此java做为client 时也没有必要经过motan调用服务。yarclient是个单独的小模块，是个相似httpclient这样的简易客户端，只能经过域名或ip访问yar服务。

缺点

只支持PHP系统调用Java系统，没有stable release版本，文档不多，社区小，开发活跃程度低。总体不如Dubbo+dubbo-php-framework方式

3.4 motan Restful

模仿Dubbo Restful，很相似，从文档上对比，不如Dubbo Restful

3.5 Client + Agent(还未彻底开源)

大概是使用motan + motan-go(agent)等实现。朝着weibo mesh的服务化方向，将 Motan Agent定位为统一服务管理的执行节点。

实现方式

为不一样语言提供很是轻量的 Client，只实现与 Agent 的交互和必要的请求序列化能力；提供一个 local 的 Agent 代理，可以提供不一样 RPC 协议交互能力，以及统一的服务治理能力与标准，服务治理的绝大部分功能都在语言无关的 Agent 中实现。经过使用 Agent，能够为相似 PHP 这样的解释型语言提供长连接复用能力，提升请求性能。

4、跨语言服务化

阿里Dubbo和微博motan都称本身框架有多语言服务化功能，都在开发中，都还不够成熟

4.1 挑战

HTTP RESTful API

HTTP 自己就是语言无关的协议，通常由服务提供方与使用方经过文档来进行服务约定。这也是目前使用很是普遍的跨语言交互方式，HTTP服务的服务治理能力通常依赖于代理层和服务调用方本身实现，通常代理服务须要单独部署，全部请求流量经由代理服务进行转发。例如使用 nginx 提供基础的负载均衡与流量控制等治理能力就是最简单的跨语言服务治理方案。

HTTP的跨语言服务化，有些方案选择了为特定语言实现强大服务治理能力，对其余语言提供兼容能力，例如Spring Cloud为Java 服务提供完整的服务治理能力，包括服务发现、路由器、过滤器、配置管理、熔断器等等。但很难为不一样语言提供统一的服务治理能力，特别是在 Client 侧的一些服务治理能力，不一样语言都须要作相同功能的开发。

还有一些方案使用本机代理的方式，例如envoy、linkerd等能够部署到单机的 HTTP 代理服务，在代理服务中集成统一服务发现与治理能力。这种方案可以作到不一样语言的Client和 Server 都提供相同的服务治理能力，但服务治理的功能很难作到前一种方案那么强大。

RPC

使用 RPC 做为服务调用方式时，跨语言与服务治理也很难同时知足，对于跨语言型的 RPC 协议，例如 gRPC 等，都可以提供不一样语言交互的能力，可是相关的服务治理功能尚未那么完善，作到了’交互’，但还没法作到’治理’。使用跨语言型 RPC 框架时通常会选择使用 HTTP（HTTP2）做为通讯协议，这样能够直接应用 HTTP 方式的服务治理功能；

对于服务治理型RPC，因为选择了在 Client 端进行服务发现与治理，若是要实现不一样语言统一的服务治理能力，须要在不一样语言的一侧都实现相同的功能。实现起来也至关的困难。所以大部分服务治理型 RPC 专一与为特定语言提供完善的治理能力。

4.2 方式

1. 兼容HTTP协议，增长HTTP RESTful协议

例如Dubbo Restful和motan Restful。这种方案将 Java 语言的 RPC 调用方式与其余语言独立开来，只针对 Java Server 端提供，没有为其余语言提供服务治理能力。因为只须要作 Java 协议的开发，这种方案研发和维护成本很低，不过可以提供的统一服务治理能力就很低了。

2. 为不一样语言提供RPC模块

例如Dubbo + dubbo-php-framework方式。这种方案能作到最贴近不一样语言的使用习惯，能够为不一样语言提供彻底一致的服务治理能力，不管是做为 Server 端仍是 Client 端。但这种方式也是成本最高的，包括开发不一样语言的版本，以及后续的功能升级与版本维护代价都很是高。

3. 开发一个 Agent 模块，实现绝大部分的服务治理能力

例如motan Client + Agent方式。Agent在不一样服务的Server或Client侧运行。而后为不一样语言开发一个很轻量的 Client 与 Agent 进行交互，因为 Client 只实现必要的交互功能，下降了不一样语言版本的开发量与维护的成本。

5、可考虑的方案

1. （若是是JSON效率低）考虑使用Google Protocol Buffers, thrift, Hessian等更高效序列化方式。
2. （若是是服务治理功能低）保持原来HTTP+JSON方式不变，优化服务治理功能
3. 本身基于已有开源框架二次开发(参考motan Client + Agent思路)
4. 使用Dubbo Restful

6、参考资料

1. 微博轻量级RPC框架Motan正式开源：支撑千亿调用
2. 微博开源的Motan RPC最新进展：新增跨语言及服务治理支持
3. 跨语言统一治理、Golang，谈谈另辟蹊径的开源RPC框架Motan
4. 在Dubbo中开发REST风格的远程调用（RESTful Remoting）
5. https://github.com/weibocom/motan/issues/186#issuecomment-243055131
6. 跨语言统一治理、Golang，谈谈另辟蹊径的开源RPC框架Motan

7、其余相关资料

1. 贝聊系统架构服务化之路
2. 逆天：蘑菇街下单平台演进，从PHP到Java
3. 服务化框架技术选型实践
4. 饿了么分布式服务治理及优化经验
5. 微博平台的RPC服务化实践
6. 多语言支持