使用 PHPRPC 如何解决在通常构建 SOA 系统时所遇到的问题

[quote="fjlyxx"]
个人觉得SOA中碰见的问题大多是因为以下几点引起的

第一 压力
第二 千变万化的服务提供方式
第三 分布式
第四 不确定因素 比如网络阻塞 服务非正常停止
第五 规范化 原来应用的发展历史对SOA平台是有影响的

但是以上这些技术难道 并不是没有办法解决的 已经有很多成功的解决案例 但是不得不承认现在很多公司打着SOA的旗号在忽悠客户 做一个SOA平台需要比较大的投入

SOA涉及的技术领域比较广泛,我觉得单靠PHPRPC 是不能满足需求的.
[/quote]

下面我就来帮你解决上面你遇到的这五个问题：

[quote][b]第一 压力[/b][/quote]

你说的这个压力我理解没错的话，应该是指服务器本身的负载能力吧（应该不是项目进度给你的工作压力吧）。这个实际上是个系统构架问题，既然你做的是 SOA，那么必然是分布式的，既然是分布式的，那么你就不应该把所有的负载都压倒一台服务器上，你只要合理的部署你的服务，压力这个问题就是不问题。假设以前你用 Web Service，那么 Web Service 的低效是众所周知的，现在你换上一个高效的 PHPRPC，只会让你在拥有同样多数量服务器的情况下，大大的减轻压力，而不是增加压力。难道这还不够解决问题的吗？难道，你有了 ESB，就可以用更少的服务器解决更大的压力问题吗？显然不能。在那种情况下，你只有用更多的服务器才能解决这个问题。那么你可能会问，没有 ESB，我如何来实现负载均衡啊？那么我告诉你，最简单且最有效的方法就是，直接在 DNS 服务器上做负载均衡设置。在这种情况下，对调用者仍然是透明的，但是对服务的质量却比 ESB 的路由方式要提高几十到几百倍的能力。如果你是新手，还不懂 DNS 是做什么的，建议你好好补充一下基础知识。

[quote][b]第二 千变万化的服务提供方式[/b][/quote]

解决这个问题有两种方式：

一种方式是提供一种大而全的集中式服务协议转换器，ESB 的一个主要工作就是做这个。

另一种是，将所有服务方式统一为一种，PHPRPC 的目标就是如此。

前一种方式的弊端大家都很清楚，那就是将本来就低效的服务变的更加低效，如果有人这么认为协议转换是没有成本的，或者成本很低，那他肯定是个外行。协议转换本身就非常消耗资源，而如果又把它作为核心总线的一部分的话，那它势必会成为整个系统最大的瓶颈之一。而且需要转换的协议越多，这个效率下降就越明显。

而将服务方式统一为一种，那么这个问题就很自然的消失了，既不会对效率产生影响（如果有影响也是好的，那就是大大的提高了效率），又降低了系统的复杂性。

那么你可能会说，要统一很难的，如果统一那么简单，为什么以前不用这种方式，还要加一个 ESB 来做协议转换这种事呢？

OK，这个问题的答案很简单，那是因为以前的技术做不到一个服务可以让所有语言都可以无差别调用，所以协议转换就成了必须的。例如，Web Service 你可以认为它已经在很多语言中被发布和被调用了是吧，但是你能够在所有的浏览器中通过 JavaScript 调用它吗？（如果你属于喜欢抬杠的人，那么你可能会说你不知道在 .NET Web Service 刚推出时 IE 5.5 就已经有一个 webservice.htc 可以调用 Web Service 了吗？还有后来的 Mozilla 也内置了对 Web Service 的支持，不是吗？那么我现在就可以回答你，你真的有看到过有人在实际项目中这么用吗？你真的用那个 htc 调用成功过其它语言发布的 Web Service 吗？在这两个浏览器中你可以用相同的方式来使用 Web Service 吗？另外，除了这两个浏览器，那 Opera、Safari，更多其它浏览器、手机浏览器也都能支持吗？它可以跨域调用服务吗？好了，这个问题暂时告一段落）如果可以并且好用的话，就不会有 DWR 这样的东西出现了，而 DWR 有只能用于 JavaScript 和 Java 通讯，根本没有能力代替 Web Service，所以 ESB 才会考虑将这两个整合到一起。看到了吗？这都是不得已的办法。

如果以前就有一个可以在任何环境、任何语言、任何平台都可以方便进行调用的协议和实现的话，ESB 就不会把协议转换作为一个重要的功能来做了。

[quote][b]第三 分布式[/b][/quote]

SOA 是分布式的，PHPRPC 是提供构建分布式系统能力的一个工具，问题解决了。

[quote][b]第四 不确定因素 比如网络阻塞 服务非正常停止[/b][/quote]

这个问题在任何分布式系统中都会遇到，但是如果在构建分布式系统时，你能够清楚的认识到这一点，那么它就不是问题。有人（甚至是专家）会说 RPC 方式隐藏了网络通讯的细节，以至于让人们忽略了网络调用和本地调用之间的区别，我觉得这个说法是错的。如果说隐藏网络通讯细节的话，这个问题应该归咎到分布式对象模型的头上，而不是 RPC 的头上，只有在分布式对象模型中，程序员才无法分清一个操作是否要跨网络（如果你不明白，建议补充一下对分布式对象模型的一些知识，最好是学一些关于分布式对象模型的一些具体技术，在对这些具体技术有所实践后，你应该明白我说的是什么）而在 RPC 中，任何一个远程调用都是跨网络的，这一点是可以很清楚的知道的。

另外一点，就是 RPC 调用只有两个结果，要么成功，要么不成功。当然你还可以分得更细，可以分三种，一种是是调用成功后，客户端得到了结果；第二种是调用成功后，客户端还没有得到结果，但网络中断了，客户端认为没有成功，而实际上服务器端已经成功执行了调用；第三种是调用开始后，客户端请求还未完全到达服务器，网络中断了，这时服务器没有执行调用，也就是不成功，客户端也自然收到没有调用成功的消息。在 PHPRPC 调用中（其它的 RPC 协议我不能保证）不存在这种情况，那就是客户请求一边发送，服务器就一边执行，所以，你不用担心服务器会在执行一部分调用后失败的情况，这种情况在 PHPRPC 中是不存在的。所以，现在问题简单了，你只要遵循下面一套指导原则，对于网络的不确定因素就能很好的面对和处理了。

指导原则很简单，那就是把服务分为两类，一类是幂等性操作，一类是非幂等性操作。当执行幂等性远程过程调用操作时，网络发生故障中断并再次恢复后，只需重发调用即可。对于非幂等性操作，你可以为它配一个查询执行是否成功的幂等性操作，在正常情况下，我们不需要使用这个查询执行是否成功的幂等性操作，但是当执行非幂等性远程过程调用操作时，网络故障中断并再次恢复后，我们首先要执行这个查询执行是否成功的幂等性操作，然后根据它的返回的状态来决定是否重发非幂等性远程过程调用操作。这样就可以保证幂等性操作至少执行一次，非幂等性操作仅执行一次的要求了。

这个指导原则不仅适用于用 PHPRPC 构建的系统，同样适用于其它可以将执行调用结果分为以上三类的 RPC 服务，例如 Web Service。但是不适用于基于分布式对象模型构建的系统，因为在这样的系统中，你无法弄清到底哪个调用触发了网络通讯。

[quote][b]第五 规范化 原来应用的发展历史对SOA平台是有影响的[/b][/quote]

这就是一个过渡问题，如果要让一个原有系统过渡到一个利用新技术构建的系统要花费很大的代价的话，自然会成为一个很大的问题。而 PHPRPC 充分的考虑了这点，因此，当你将一个原有系统用 PHPRPC 重新构建时，你会发现你几乎不需要对你的原有系统做什么更改，你原有的业务逻辑层可以直接使用 PHPRPC 来发布成服务。而且不仅适用于 Java，同样适用于其它语言构建的系统，例如 PHP、.NET、Ruby、Python 甚至 ASP 等。对其它技术来说（包括 Web Service），这点确实很难做到。这也是 PHPRPC 的最大亮点之一。

综上所述，PHPRPC 解决了 SOA 领域对于以前大多数技术可能会遇到的问题。因此，利用 PHPRPC 构架 SOA 系统是非常合适的选择。