摘自： http://weibo.com/p/1001603869896789339575
原文地址： http://www.oschina.net/question/865233_242146
隨着移動互聯網的迅猛發展，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 做過一些項目