Normandy 博客

# re: 淺析遠(yuǎn)程過程調(diào)用 RPC[未登錄]  回復(fù)  更多評論   

RPC的優(yōu)勢在哪里？

# re: 淺析遠(yuǎn)程過程調(diào)用 RPC  回復(fù)  更多評論   

@achilles
優(yōu)點(diǎn)是可直接訪問遠(yuǎn)程過程，避免煩瑣的打包和解包過程，且不依賴于某種特定的協(xié)議

# re: 淺析遠(yuǎn)程過程調(diào)用 RPC[未登錄]  回復(fù)  更多評論   

@Normandy
可是這些過程為什么非要放到不同的機(jī)器呢，與普通的網(wǎng)絡(luò)通信相比RPC有什么優(yōu)勢？

# re: 淺析遠(yuǎn)程過程調(diào)用 RPC  回復(fù)  更多評論   

@achilles
優(yōu)點(diǎn)是可直接訪問遠(yuǎn)程過程，避免煩瑣的打包和解包過程，且不依賴于某種特定的協(xié)議
===================
顯然你就是看的皮毛
底層仍然通過打包解包實(shí)現(xiàn)
你沒聽說過marshall這個(gè)詞？
這只不過是打包的另一種說法罷了。。。

# re: 淺析遠(yuǎn)程過程調(diào)用 RPC  回復(fù)  更多評論   

遠(yuǎn)程過程調(diào)用的使用領(lǐng)域太廣泛了，以后要是能不聯(lián)機(jī)就能定時(shí)生成或采集數(shù)據(jù)就更好了。

# re: 淺析遠(yuǎn)程過程調(diào)用 RPC  回復(fù)  更多評論   

@achilles
將一些過程放在遠(yuǎn)程是分布式程序的要求，如客戶機(jī)/服務(wù)器模式。相比常規(guī)的網(wǎng)絡(luò)通信程序而言，在用 RPC 時(shí)我們只需要關(guān)心程序本身的邏輯，就像建本地程序一樣，因?yàn)?RPC 已經(jīng)幫你做了網(wǎng)絡(luò)通信的工作!

如果你還是不能理解， 請下載我上面的遠(yuǎn)程過程調(diào)用示例，將客戶程序和服務(wù)程序放在兩個(gè)不同的機(jī)器上運(yùn)行看看。

如果你想了解更多的細(xì)節(jié)，請看一下 <<Linux 網(wǎng)絡(luò)編程>> 第十二章，上面的內(nèi)容更精彩!

# re: 淺析遠(yuǎn)程過程調(diào)用 RPC  回復(fù)  更多評論   

[薦]RPC is bad?
偶像 Steve Vinoski 在 maillist 的回帖中一不留神就泄漏了他為 ErlangeXchange 準(zhǔn)備的 session ，我們可以先一睹為快。Steve 大拿是 CORBA 界的牛人，對 RPC 是 bad 很有發(fā)言權(quán)地。這篇文章也寫得很漂亮，水分相當(dāng)少，我就不干“損失味道”的事情了。
為方便閱讀，將 mail 內(nèi)容盜版如下：
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: 淺析遠(yuǎn)程過程調(diào)用 RPC  回復(fù)  更多評論   

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: 淺析遠(yuǎn)程過程調(diào)用 RPC  回復(fù)  更多評論   

可不可以這樣理解：
通常的C/S程序，Server端的程序必須已經(jīng)在運(yùn)行，Client端的程序才能和它通訊。

而使用RPC，Client可以遠(yuǎn)程啟動Server端的程序。

# re: 淺析遠(yuǎn)程過程調(diào)用 RPC  回復(fù)  更多評論   

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

# re: 淺析遠(yuǎn)程過程調(diào)用 RPC  回復(fù)  更多評論   

雖然RPC有好有不好，不過很贊你的文章看了就懂，而且跟著做就可以簡單理解一下rpc的例子。

RPC雖然對網(wǎng)絡(luò)依賴，但是對于中間件技術(shù)來說還是蠻贊的技術(shù)。

# re: 淺析遠(yuǎn)程過程調(diào)用 RPC  回復(fù)  更多評論   

你將得非常的好.謝謝你