Normandy 博客

# re: 浅析远程过程调用 RPC[未登录]  回复  更多评论   

RPC的优势在哪里？

# re: 浅析远程过程调用 RPC  回复  更多评论   

@achilles
优点是可直接访问远程过程，避免烦琐的打包和解包过程，且不依赖于某种特定的协议

# re: 浅析远程过程调用 RPC[未登录]  回复  更多评论   

@Normandy
可是这些过程为什么非要放到不同的机器呢，与普通的网络通信相比RPC有什么优势？

# re: 浅析远程过程调用 RPC  回复  更多评论   

@achilles
优点是可直接访问远程过程，避免烦琐的打包和解包过程，且不依赖于某种特定的协议
===================
显然你就是看的皮毛
底层仍然通过打包解包实现
你没听说过marshall这个词？
这只不过是打包的另一种说法罢了。。。

# re: 浅析远程过程调用 RPC  回复  更多评论   

远程过程调用的使用领域太广泛了，以后要是能不联机就能定时生成或采集数据就更好了。

# re: 浅析远程过程调用 RPC  回复  更多评论   

@achilles
将一些过程放在远程是分布式程序的要求，如客户机/服务器模式。相比常规的网络通信程序而言，在用 RPC 时我们只需要关心程序本身的逻辑，就像建本地程序一样，因为 RPC 已经帮你做了网络通信的工作!

如果你还是不能理解， 请下载我上面的远程过程调用示例，将客户程序和服务程序放在两个不同的机器上运行看看。

如果你想了解更多的细节，请看一下 <<Linux 网络编程>> 第十二章，上面的内容更精彩!

# re: 浅析远程过程调用 RPC  回复  更多评论   

[荐]RPC is bad?
偶像 Steve Vinoski 在 maillist 的回帖中一不留神就泄漏了他为 ErlangeXchange 准备的 session ，我们可以先一睹为快。Steve 大拿是 CORBA 界的牛人，对 RPC 是 bad 很有发言权地。这篇文章也写得很漂亮，水分相当少，我就不干“损失味道”的事情了。
为方便阅读，将 mail 内容盗版如下：
Well, if you had time you could dig through my various IEEE Internet Computing columns from the past 6 years and find many reasons listed there. For example, “RPC Under Fire“(note that it’s PDF) from the Sep/Oct 2005 lists a number of problems:
Also, pretty much any of my columns that cover REST to any degree would also contain mentions of RPC’s shortcomings. All the columns can be found here:
But if you don’t have the time or energy, the fundamental problem is that RPC tries to make a distributed invocation look like a local one. This can’t work because the failure modes in distributed systems are
quite different from those in local systems, so you find yourself having to introduce more and more infrastructure that tries to hide all the hard details and problems that lurk beneath. That’s how we got
Apollo NCS and Sun RPC and DCE and CORBA and DSOM and DCOM and EJB and SOAP and JAX-RPC, to name a few off the top of my head, each better than what came before in some ways but worse in other ways, especially footprint and complexity. But it’s all for naught because no amount of infrastructure can ever hide those problems of distribution. Network partitions are real, timeouts are real, remote host and service
crashes are real, the need for piecemeal system upgrade and handling version differences between systems is real, etc. The distributed systems programmer *must* deal with these and other issues because
they affect different applications very differently; no amount of hiding or abstraction can make these problems disappear. As I said about such systems in a recent column:
“The layers of complexity required to maintain the resulting leaky illusion of local/remote transparency are reminiscent of the convoluted equations that pre-Copernican astronomers used to explain how the Sun and other planets revolved around the Earth.” (from “Serendipitous Reuse“)
RPC systems in C++, Java, etc. also tend to introduce higher degrees of coupling than one would like in a distributed system. Typically you have some sort of IDL that’s used to generate stubs/proxies/skeletons
–

# re: 浅析远程过程调用 RPC  回复  更多评论   

code that turns the local calls into remote ones, which nobody wants to write or maintain by hand. The IDL is often simple, but the generated code is usually not. That code is normally compiled into each app in the system. Change the IDL and you have to regenerate the code, recompile it, and then retest and redeploy your apps, and you typically have to do that atomically, either all apps or none, because versioning is not accounted for. In an already-deployed production system, it can be pretty hard to do atomic upgrades across the entire system. Overall, this approach makes for brittle, tightly-coupled systems.
Such systems also have problems with impedance mismatch between the IDL and whatever languages you’re translating it to. If the IDL is minimal so that it can be used with a wide variety of programming
languages, it means advanced features of well-stocked languages like Java and C++ can’t be used. OTOH if you make the IDL more powerful so that it’s closer to such languages, then translating it to C or other
more basic languages becomes quite difficult. On top of all that, no matter how you design the IDL type system, all the types won’t — indeed, can’t — map cleanly into every desired programming language. This turns into the need for non-idiomatic programming in one or more of the supported languages, and developers using those languages tend to complain about that. If you turn the whole process around by using a programming language like Java for your RPC IDL in an attempt to avoid the mismatch problems, you find it works only for that language, and that translating that language into other languages is quite difficult.
There’s also the need with these systems to have the same or similar infrastructure on both ends of the wire. Earlier posters to this thread complained about this, for example, when they mentioned having to have CORBA ORBs underneath all their participating applications. If you can’t get the exact same infrastructure under all endpoints, then you need to use interoperable infrastructure, which obviously relies on interoperability standards. These, unfortunately, are often problematic as well. CORBA interoperability, for example, eventually became pretty good, but it took about a decade. CORBA started out with
no interoperability protocol at all (in fact, it originally specified no network protocol at all), and then we suffered with interop problems for a few years once IIOP came along and both the protocol itself and implementations of it matured.
Ultimately, RPC is a leaky abstraction. It can’t hide what it tries to hide, and because of that, it can easily make the overall problem more difficult to deal with by adding a lot of accidental complexity.
In my previous message I specifically mentioned Erlang as having gotten it right. I believe that to be true not only because the handling of distribution is effectively built in and dealt with directly, but also because Erlang makes no attempt to hide those hard problems from the developer. Rather, it makes them known to the
developer by providing facilities for dealing with timeouts, failures, versioning, etc. I think what Erlang gives us goes a very long way and is well beyond anything I’ve experienced before. Erlang really doesn’t provide RPC according to the strict definition of the term, BTW, because remote calls don’t actually look like local ones.
(BTW, this is the kind of stuff I’ll be talking about at Erlang eXchange next month.)

# re: 浅析远程过程调用 RPC  回复  更多评论   

可不可以这样理解：
通常的C/S程序，Server端的程序必须已经在运行，Client端的程序才能和它通讯。

而使用RPC，Client可以远程启动Server端的程序。

# re: 浅析远程过程调用 RPC  回复  更多评论   

你讲得非常棒，看了你的文章，让我知道了什么RPC。

# re: 浅析远程过程调用 RPC  回复  更多评论   

虽然RPC有好有不好，不过很赞你的文章看了就懂，而且跟着做就可以简单理解一下rpc的例子。

RPC虽然对网络依赖，但是对于中间件技术来说还是蛮赞的技术。

# re: 浅析远程过程调用 RPC  回复  更多评论   

你将得非常的好.谢谢你