<rt id="bn8ez"></rt>
<label id="bn8ez"></label>

  • <span id="bn8ez"></span>

    <label id="bn8ez"><meter id="bn8ez"></meter></label>

    隨筆-11  評論-10  文章-8  trackbacks-0
    多謝 erlang-china 的提醒,今天從 mailing list 中翻出了關于RPC的討論,深有感觸 -- 牛人就是牛人!!!

    關于 RPC is bad 的主要論點如下:
    The fundamental problem of RPC, which is trying to make remote calls look local, is based on essentially trying to ignore the problems covered by the fallacies or trying to pretend they don't even exist

    嚴重同意,理由如下:

    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.


    這一點非常贊同,也深有同感。在做FileServer的時候所有的節點都是通過RMI進行通訊,最初使用RMI的目的就是
    簡化網絡部分的開發,對于一般的開發人員無須理解RMI,動態代理,只需要像使用本地方法一樣就可以訪問遠程
    節點。這種方案確實很好的隱藏了網絡細節,使網絡對開發人員完全透明,但有個問題始終無法很好的處理:異常。
    網絡錯誤是隨時都有可能發生的,對于不同的錯誤需要根據環境和需要做具體的處理,比如,多試幾次,嘗試下一個
    節點,對于無法處理的還可以直接拋出。而這種策略的選擇和使用必須由應用邏輯層完成,可是應用層假設是不知道
    網絡存在的,它甚至無法知道自己調用的方法中哪個是遠程調用,哪個是本地調用。這種矛盾從根本上說明了網絡的
    復雜性和多樣性是開發分布式應用的程序員必須面對的,是逃不掉的,要直面這慘淡的人生T_T

    下面闡述了使用類型系統的缺陷:
    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.

    類型系統一直都在進化,從弱到強到動態,你相信會有一種類型系統可以和所有
    的其他語言進行完美的映射嗎?如果真存在,類型系統的進化就毫無意義了。定義
    一個新的語言,然后映射到其他語言,最后號稱“我是跨語言跨平臺的!”,這種
    解決問題的方式根本就是有問題的。WSDL使用XML描述,有著更好的可擴展性,只是
    酒瓶換新酒,根爛了,再換也沒用。

    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.

    下面對為什么 message queuing system 適合分布式系統做了很好的總結:
    Message queuing systems work well because (in no particular
    order):

    * they don't pretend to be programming language procedure or method
    calls, so they avoid the associated impedance mismatch problems
    * they don't try to hide distributed systems issues
    * coupling is low -- drop a message into a queue here, pick up a
    message from a queue there
    * queues can be persistent, or more generally, delivery guarantees can
    be varied as needed
    * asynchrony
    * payloads need not conform to some made-up IDL type system
    * getting two different messaging systems to interoperate is easier
    than getting two different RPC or distributed object systems to
    interoperate
    這和我在自己的碩士論文中的觀點有些相似:完全使用消息機制進行構件間的通訊。構件可以
    是分布式的或在容器中的,基于消息的通訊都是完全適用的。對于網絡應用同樣如此。對于流行
    的網絡協議,HTTP,FTP,LDAP 等等都是消息式的,完全經歷了時間的考驗。

    posted on 2008-05-28 00:32 JBahamut 閱讀(474) 評論(1)  編輯  收藏

    評論:
    # re: 讀 Erlang mailing list 有感 2008-06-24 01:55 | mier
    你java好強大  回復  更多評論
      

    只有注冊用戶登錄后才能發表評論。


    網站導航:
     
    主站蜘蛛池模板: 亚洲精品美女久久久久99| 久久最新免费视频| 日韩亚洲AV无码一区二区不卡 | 国产亚洲av片在线观看18女人 | 亚洲1区1区3区4区产品乱码芒果 | 最近中文字幕大全免费版在线 | 亚洲人成无码网站久久99热国产| 色婷婷7777免费视频在线观看| 在线涩涩免费观看国产精品| 一边摸一边桶一边脱免费视频 | 成人免费午夜无码视频| 久久一本岛在免费线观看2020| 久久不见久久见免费影院www日本| 亚洲第一街区偷拍街拍| 亚洲人成7777| 久久精品九九亚洲精品| 国产亚洲A∨片在线观看| 亚洲午夜日韩高清一区| 国产高清免费观看| 四虎国产精品免费久久| 7723日本高清完整版免费| 99国产精品免费观看视频| 久久免费区一区二区三波多野| 黄床大片免费30分钟国产精品| 日韩a毛片免费观看| 成人免费视频一区二区| 日日躁狠狠躁狠狠爱免费视频| 国产亚洲女在线线精品| 色窝窝亚洲AV网在线观看| 亚洲aⅴ天堂av天堂无码麻豆| 一本色道久久88—综合亚洲精品| 亚洲av午夜精品无码专区| 亚洲国产精品白丝在线观看 | 无人在线观看免费高清视频| 91精品视频免费| 中文字幕影片免费在线观看 | 亚洲1区2区3区精华液| 国产成人亚洲综合在线| 色屁屁在线观看视频免费| 污污免费在线观看| caoporm碰最新免费公开视频|