ZeroC Ice 暫記

摘自： http://weibo.com/p/1001603869896789339575

原文地址： http://www.oschina.net/question/865233_242146

 

吳治輝，@ mycat，擁有超過 15 年的軟件研發經驗，精通 Java 編程，專一於電信軟件和雲計算方面的軟件研發，參與過衆多與分佈式、雲計算相關的大型項目的架構設計和編程，具有豐富的大型項目架構設計經驗，是業界少有的具有很強編程能力的S級資深架構師，目前就任於惠普。此外，他仍是 國內知名開源分佈式數據庫中間件  MyCat  的發起人。目前 MyCat 項目已經有超過 15 名活躍志願者在參與和推動，其社區 QQ 羣人數超過2000人，是當下熱門的移動互聯網和雲計算項目必備基礎中間件之一。

隨着移動互聯網的迅猛發展，HTTP REST 這種曾經風靡一時的低效的遠程通訊技術已再也不風光，而多語言支持的高性能 RPC 技術再次王者歸來。Facebook Thrift  一經開源即引發轟動，Hadoop 父兼 Apache 主席的 Doug Cutting 也耐不住誘惑，開放了他在 Hadoop 裏研發的創新性的 RPC 框架—— Avro。而做爲惟一平臺級的開源產品，這次話題的主角—— ZeroC Ice 正在低調地進軍互聯網領域。

精彩問答

@堅持住：ZeroC ICE 有什麼用？

@mycat：ZeroC ICE 手機端開發也很是有用，Android/IOS都支持，一個Ice服務，無論是 Java 開發也好，C開發也好，Web 端、Android/IOS 都同樣的調用方法，Ice是全棧工程師/架構師最好的搭檔。

@lxitgto：咱們4年前開始使用 Zeroc ICE，從 3.4 用到 3.5，期間也是掉過無數的坑。嚴重吐槽一下ICE的官方文檔，感受不是英文爲母語的人寫的。我很好奇國內還有哪些項目使用了 ICE？成功案例？

@mycat：Ice的官方文檔總共大概1000多頁，寫的是很詳細，但詳細不表明着容易理解，這是由於幾個緣由，首先，它是開源的，因此依賴服務盈利，公開的文檔要「閃爍其辭"，第二，Ice裏面有不少概念和術語，須要理解這些術語，才能很好的掌握Ice，而絕大多數使用者一上來就急於編碼寫Demo，沒有時間仔細學習和研究，致使後期發現不少」坑「，而Ice至今沒有一本詳細指導開發實踐的書籍，這更增長了掌握它的難度。

Ice在國內，最先有騰訊、以及一些電信軟件開發公司使用，後來有部分互聯網企業用，聽說有人人網等公司使用，接觸過一些電信軟件開發的相關人員，反饋是Ice很是穩定可靠，這與其經久考驗的代碼質量密切相關，其官網上，Skpye的案例不用說了，還列舉了寶鋼這個客戶。

@nullptr：最近學習ICE幾天了,有點疑惑,不知道問題是否是過低級了,可是如今確實卡在這裏了,若能回覆下,不勝感激:

1:在官方的demo中,ice 回調模式只有read/writer(proxy),可是proxy這個類貌似沒有寫入數據的地方,因此我像問下在callback模式中怎麼去設置發送的數據呢?

2:在官方demo中Glacier2模式的callback中,有個這個文件:config.glacier2.(就是除了server,client配置以前的另外一個配置文件,配置的)網上說啓動這個文件,可是不知道如何啓動(windows);

3:能不能推薦個這方面的網站,由於我除了官方的沒見過其餘的文檔和論壇,資料太少了..

@mycat：Ice回調模式有兩種，一種是傳統的回調模式，你傳遞一個接口實現類，它來調用你；另一個是你去探測異步調用是否完成，完成後獲取返回結果，這個在書裏貌似寫了的，兩種用法各自有其用武之地。  IceBox以及IceGrid是學習重點，也是Ice精華，建議先學這部分。

@Carvendy：性能測試 報告什麼能夠看看嗎？和其餘 工具性能差別，優點到底在哪裏呢？

@mycat：Ice最先是即時通信和在線遊戲項目中所用，追求性能和穩定性是其重要目標，Hadoop做者看不慣Thrift而開發的新的RPC框架Avro也很不錯，採用了Netty作通訊，聽說性能跟 Thrift有的一拼，但它只在Java裏用了Netty，其餘語言用HTTP通訊，請求應答消息相同的狀況下，HTTP方式的TPS是500左右，Netty模式是1.5萬左右，Ice則是2.5萬

@pj220：ICE 在嵌入式的windows CE系統下，目前僅支持ARM處理器，我想知道如何將ICE移植到MIPS處理器上？

@mycat：它的源碼是開放的，另外，查詢到一些資料，代表應該是能夠在MIPS上編譯和支持的：zeroc-ice (3.0.1-2) unstable; urgency=low  * Patch for MIPS support was incomplete (Closes: #357899).  * Added compilation fix for Alpha (Closes: #358488).

@leoxu：您好，請問開頭介紹中爲何說「HTTP REST 這種曾經風靡一時的低效的遠程通訊技術已再也不風光」，能夠給咱們你們分析分析嗎，謝謝

@mycat：關於HTML5在移動設備上的被Native方式的App所替代，這個現象應該你們都有所耳聞，最著名的是Facebook事件，而引起Rest VS RPC通訊的則是知名的印象筆記 這款APP，他們還寫過一個架構說明，爲何用RPC，總結下來，緣由有幾個：高性能，傳輸數據量大幅壓縮，安全，保持技術優點（RPC門檻高於REST），以及APP的安裝包縮減

@Gogo58：咱們公司如今都在用ice ，感受ice的分佈式的方式不是很難，咱們是用javaweb的項目，感受ice的.ice 文件配置不是很方便，端口號每次從svn下載要改好

@mycat：估計是沒有用IceGrid，若是用這個，就不存在改端口的問題，並且部署更方便了

@風--：簡單用過，最大的優點是支持多語言，很不錯！！

@mycat：最簡單的使用，只用Ice RPC，Java方面就一個Jar包，C方面就一個.so或dll運行庫，很容易嵌入程序，沒有複雜的第三方依賴。

@SimonYe：咱們正在用 dubbo，我想請教的是： Avro 與 dubbo 同爲 RPC 框架，有啥差異，應用場景有啥不一樣，謝謝。

@mycat：Avro目前算是一個API框架，dubbo算是一個PRC平臺了，但因爲只支持Java，以及是阿里內部一個項目，對比Ice，一個是公司級的，一個是世界級的，另外，dubbo被放棄了，而Ice 剛剛又推出了3.6版本，因此，選擇哪一個，就在本身了。

@chencliff：之前用過ice，後來發現複雜度實在是過高，項目組大部分紅員都停留在入門階段，很難轉化爲生產力。而且出錯後查找錯誤所在也是一個考驗。後來就轉到其餘技術上了。

@mycat：須要有一我的比較深刻的掌握Ice，搭建框架和測試環境，其餘人則不需太多瞭解，按照規範開發便可，能夠節省不少工做量。

Ice的日誌其實很詳細，但不少人都不知道日誌在哪裏放着，怎麼控制日誌級別

@hakuyo：只說一點基本通訊方面的理解吧，感受在基本通訊方面（不涉及穿防火牆等其餘高級的功能），ice=poco+protobuf，有印象ice好像要支持protobuf

@mycat：說的不錯，但Ice最強大的是IceGrid，動態伸縮，平滑擴容，方便部署和升級，目前的docker/Kubernate也借鑑了其思想

@Sub：ICE 如今又流行了？ 記得 05年的時候開始接觸使用了1~2年，雖然比 CORBA 之類的跨語言RPC通信好用不少，可是仍是感受繁瑣，後來就棄用了。

@mycat：由於要跨語言，因此須要有一箇中間接口，考慮到實際通訊中爲每一個語言開發一個客戶端的代價，所以這個步驟仍是能接受。若是你只用RPC通訊，而不用IceGrid的強大分佈式網格，你會以爲他比Rest等方式要繁瑣，有代價。它的精華在於，哪怕只有3我的的團隊，也能依賴IceGrid，作一個App，一個Web，一個強大的分佈式系統。

@wlyhqm2006：請問MyCat都使用了哪些ICE的技術

@mycat：Mycat自己是數據庫中間件，沒有用到Ice，但新的一個開源項目，Mycat開放電商架構平臺，則是Zeroc Ice+Mycat+Zookeeper+MQ+ES，組成一個強大先進的電商平臺。

@billow：騰訊MIG有個叫作 taf 的框架，貌似是基於ICE徹底從新開發的一套框架

以前也看過一點ICE的東西，感受在互聯網方面的應用很少啊，反卻是thrift或者基於pb的rpc方式更加流行暱，"ZeroC Ice 正在低調地進軍互聯網領域"這句話能展開說說麼？

@mycat：由於騰訊很早就用Ice的，因此模仿開發一個，是很正常的。RPC技術，特別是多語言，多平臺（服務端、移動設備）支持的RPC技術，正在互聯網應用中興起，這個是不爭的事實了，由於互聯網應用裏是最多遇到多語言開發，多平臺支持的需求領域。REST等HTTP技術性能低、傳輸數據量大、安全性低，門檻低，這是其根本問題。

Thrift 目前也只能算是一個RPC框架，但服務治理這部分還缺少，團隊須要額外的不少開發投入，才能達到ICE平臺的目前的功能。

@myw31415926：之前公司也用過一段時間的ACE，可是那個ACE太大了，調用比較複雜，入門感受頗有難度。請問ICE會有這樣的問題嗎，它與ACE比較，有哪些優點？對ICE的學習須要深刻到源碼級嗎，仍是隻須要熟悉接口調用就能夠了？謝謝您的回答！

@mycat：Ice RPC很簡單，無需深刻源碼，IceGrid很強大，只要理解了其 術語、原理、模型便可熟練使用，總體上Ice很輕量級，團隊有人搭建環境，其餘人遵循規範開發便可。https://github.com/MyCATApache/Mycat-openEP 這個開源項目裏作了一個IceGrid的Docker鏡像，10分鐘入門。

@test_30rl：請教一下如何使用 Ice 進行流式數據傳輸的支持哈，以前用protobuf的時候，發送二進制數據用的是 bytes 類型，可是不是基於流的，因此數據比較大的時候會有問題。

@mycat：TCP流式傳輸，都是把數據分紅自定義協議報文的方式傳輸的，100G文件發送也沒有問題，多看看RFC中TCP上的應用協議，就明白了。另外，Ice專門有文件傳輸的例子的，能夠直接拿來用

@李烈火：ZeroC Ice 到底是何方神聖？

@_zhanggx：分佈式系統的通訊，要麼是RPC，要麼是消息隊列機制，並且RPC方式的代碼一般要佔到一半以上。若是一個系統比較複雜，須要N個服務之間有調用關係，那麼這就是一個通用的技術問題，簡單地說，就是服務治理/服務總線平臺，涉及到服務註冊、負載均衡、故障處理、服務擴容、以及最後的RPC調用功能。

這些能力都具有的，並且是開源的，目前基本只有Zeroc Ice與 阿里放棄的Duboo，而Zeroc Ice則有超過10年的歷史，不斷更新，不只僅支持服務器端的RPC調用，也支持移動設備。

Ice的好處是，能夠用Java、C++、C#、Python等語言開發服務端，而後你們能夠相互通訊，最後這些服務組成一個系統，還能被7種語言寫的客戶端調用，包括PHP、Javascript，不只僅能被網頁程序調用，還能在移動設備上調用。對於互聯網/App開發來講，節省了80%的工做量。

這個是@mycat老師在其餘活動中回答的哈，鄙人摘抄了過來

@茶哥強大：http://www.infoq.com/cn/articles/netty-high-performance/這篇文章中netty優化到10w tps，zeroC ice能作到嗎，還有zeroC ice內部機制是否是nio，有沒有壓縮功能

@mycat：Netty並不表明着極限性能，Apahce Avro 是Hadoop之父的RPC開源新做，也是用了Netty，但我作過對比，一樣的接口方法，Avro 性能爲1.5萬每秒，遠遠高於HTTP的，但Ice則是2.5萬每秒。軟件設計中：通用性是以犧牲性能爲代價的。從這個方面也能解釋 Zeroc Ice的NIO高於Avro 的緣由。

@水母幹：想知道下要多大規模的項目纔會上ICE?以前一個項目一開始打算用ICE做爲RPC框架的,到後面考慮到用戶量並不會多到哪裏去,並且文檔實在是太難讀了,就換Thrift了

@mycat：若是有5個以上服務是分佈式的，並且有相互調用關係，而且會很快擴展增長新的服務或者擴容，那麼就建議Ice，由於分佈式系統中代價和工做量大的是擴容、負載均衡、容錯機制，用Thrift的話，這些都要本身去開發，用IceGrid，這都是現成的功能。

@zhaoy168：RPC開發門檻高，下降開發成本和業務快速迭代是互聯網最大的需求。

高高在上的RPC可能更適用於對性能細節要求很是高的場合，好比電信或銀行的內部調用。

在移動端，REST還會是主流。在方便的RPC工具出現前，RPC在移動互聯網的普及還有很長的路要走。

@mycat：RPC的門檻其實不高，特別對於調用者來講，比Rest方式還低的門檻，而服務開發方面，也只高了一點點，好處是更加面向服務接口，IDL/SLICE語言定義中立的服務接口，而不是隨意的定義服務和服務接口，致使最後系統混亂到沒法掌控，若是還認爲Rest是一點端主流，就去看看印象筆記的公開的架構說明吧。

@Gogo58：我想問一下ice 都是使用了哪幾種設計模式

@mycat：Proxy模式是RPC系統共用的最主要的設計模式之一，其餘如Factory模式也比較經常使用。不少「工具類」則使用了單例模式，其餘的模式則須要去代碼中發掘了。

@Gogo58：ice在作分佈式部署的實施的時候要注意什麼

@mycat：服務粒度的問題，過大太小都不合適。服務接口要具備前瞻性，即考慮到可能增長的參數，儘可能通用性服務之間的關聯問題，很是頻繁調用的服務，建議部署在一塊兒（一個IceBox裏）

@purely：icegrid -> node->server 和 icegrid -> node-> icebox 這2着有什麼區別嗎？

@mycat：這裏的一個Server就是一個IceBox進程，逐一區別於Ice Servant（Server中的一個Ice服務）

@purely：servant是做爲一個服務對象讓客戶端使用的，客戶端獲取一個servant（ice.object）的一個遠程代理來調用。

那麼servant的編寫上，是否要遵循無狀態或線程安全，纔可以保證調用的線程安全？

@mycat：是的，Servant的編寫須要遵循線程安全，無狀態服務也是好久以前你們達成的共識，容易負載均衡、故障恢復。

@每天順利：ZeroC Ice 相對於其餘RPC架構有哪些優化？同時，ZeroC Ice的性能測試的關鍵參數有哪些？

@mycat：NIO 和字節順序方面做了很精心的調整，其官方有關於Big-Endian與Little-Endian的討論，這個問題幾乎在其餘地方找不到，說明其深刻和細緻程度。性能方面，主要有線程池大小、超時時間、鏈接緩存、「本地服務」之間相互調用的優化問題等。

@Gogo58：使用ice作秒殺之類的高併發的系統的設計有沒有什麼要注意的

@mycat：Ice PRC只是一個通訊手段，秒殺之類的高併發的系統，須要好好利用和設計IceGrid，增長服務實例的數量和併發承受能力，而且確保每一個服務的相應時間儘可能縮短，才能抵抗高併發的請求壓力，比較好的一個模式是Ice收到請求之後，簡單處理後放入Redis/MQ等中間件，異步處理

@小M武毅：公司在使用Ice，對比過和thrift的性能，thrift在性能上有較高優點，但Ice在集羣管理方面有較完善的機制。在使用IceGrid基本都是一點點試出來的，是否有針對互聯網服務的詳細使用說明

@mycat：這本書裏有一個Android App 調用Ice服務的例子。客戶端不管是App仍是Web，調用起來都沒有區別，區別在於App的TCP鏈接相對速度更低，須要注意數據量的傳輸問題，好比避免文本傳輸，而用壓縮的二進制，另外，要快速返回結果，多用異步的交互模式。

@流沙河魚：目前dubbo和dubbox在各大互聯網公司使用的很廣泛了，如何說服這些人從dubbo轉移到ice上面來，可能還須要向這些技術人員說明ice的性能和可靠性以及其餘方面的優點，並這些人認識到ice框架的好處和優點，不少人多這個框架和技術是比較陌生的

@mycat：老項目老辦法，升級和新項目則遷移。架構師是起領頭做用的，若是架構師都不懂，那麼團隊裏推進就難了，無論怎樣，先學會使用，以便決策的時候多一個選擇，是比較靠譜的方法。

@楊延慶：以前在一個android的項目上用過的，用於android程序和java服務器之間進行通訊，可是對於大數據量的發送處理不是很好，我24小時的採集程序，傳給底層的ICE發送後，很容易形成阻塞，弄得我接收傳感器信息後不敢存臨時隊列，必須直接發送，對於這塊Java 的ICE調用，有沒有什麼好的建議呢

@mycat：RPC接收消息，若是涉及到複雜的消息處理，特別是耗時比較多，則能夠放入合適的消息隊列，消息隊列的選擇也影響很大，好比Kafka的性能一般是JMS消息隊列的好幾倍以上。 若是消息處理比較簡單，不會耗時，則直接處理消息是比較好的辦法。

@楊延慶：個人消息當時有普通的傳感器消息和警告消息，最初的想法是先把要發送的普通消息放到一個隊列裏，由ICE統一發送，若是有警告消息要發送時，能夠先中止普通消息的發送，放普通消息到消息隊列裏，先發警告消息，等警告消息發送完後再發，實際測試時發現ICE在發送消息隊列裏的數據時發的速度比我放的速度慢，有阻塞現象，致使消息隊列愈來愈大，從而app內存溢出，最後仍是收到傳感器消息就發ICE消息，不放隊列了，但...

你的意思是說android程序和server程序用jms交換消息，不用ICE麼？ 

@mycat：App客戶端直接Ice通訊把消息給服務端，服務端根據消息處理的狀況，考慮放入消息隊列或者直接處理。App端資源有限，放入消息隊列再發送，確定速度趕不上。

@楊延慶：主要是ICE的Java版不能像C++版能夠進行內存的手動分配和回收，因此只能像這樣作了，能不能使用ICE Box或者ICE Grid呢？

@mycat：在於Android客戶端的性能沒法跟PC比，無論是CPU能力仍是內存能力，因此要儘可能的避免複雜Java對象的建立銷燬等邏輯

@mycat：網上查到一個有趣的對比：zeromq 我在 mac lion 上試驗一把，官方的案例 hwclient.c/hwserver.c 把發的包改爲：包長度＋包內容（就是 Muti-part Message 方式），用 zmq_send/zmq_recv 和 zmq_msg_send/zmq_msg_recv，帶ZMQ_SNDMORE/ZMQ_REVMORE 都有問題，把 ZMQ_REVMORE 去掉就 OK，zeromq 還有不少要完善的，bug report我都找不到提交的地方，只要直接從 man 中找到的 email 地址發郵件給他們，樣例代碼和文檔都不太好用。我原來用 zeroc ice，這個開源系統這方面比 zeromq 作的好，至少咱們已經用 zero ice 作過一些項目