ZEROC究竟是何方神聖？

原文出自：http://www.roncoo.com/article/detail/124802

1、RPC又是炒冷飯？？

Leader-us：

RPC的確是炒冷飯，但彼一時，此一時。 現在這個江湖早已不是過去那個江湖了。移動設備早已吞噬PC市場，原先為應付移動設備兼容而開發的網頁模式的應用逐漸下架，App要界面好看，速度要快，要安全，要省流量，所以，RPC又重新引起大家的重視，現在90%的人都認為Rest沒有技術含量，淪為大路貨了，但90%的人都覺得Thrift是高大上的技術，在市場驅動下，RPC這個炒冷飯的技術，還真是一盤大餐！

2、Ice到底是個什麼東東呢？有什麼用處？

Leader-us：

分散式系統的通信，要麼RPC，要麼消息隊列機制，而且RPC方式的代碼通常要佔到一半以上。 如果一個系統比較複雜，需要N個服務之間有調用關係，那麼這就是一個通用的技術問題，簡單的說，就是服務治理/服務匯流排平台，涉及到服務註冊、負載均衡、故障處理、服務擴容、以及最後的RPC調用功能，這些能力都具備的，而且是開源的，目前基本只有Zeroc Ice與 阿里放棄的Duboo，而Zeroc Ice則有超過10年的歷史，不斷更新，不僅僅支持伺服器端的RPC調用，也支持移動設備。 Ice的好處，可以用Java，C++，C#，Python等語言開發服務端，然後大家可以相互通信，最後這些服務組成一個系統，還能被7種語言寫的客戶端調用，包括PHP，Javascript，不僅僅是網頁程序調用，還能移動設備上調用。對於互聯網/App開發，節省了80%的工作量.

3、這個Zeroc Ice 與 Thrift 還有 Avro 相比 有什麼優缺點?同時Thrift 還有 Avro 在大數據及互聯網應用廣泛且都有成熟案例，Zeroc Ice如何進入這個圈子？

Leader-us：

我們要看看究竟是誰進誰的圈子，這個問題需要弄明白。 RPC技術最早是由SUN引領並成為標準規範的，後來就產生了一個問題，不同廠家的硬體、軟體、不同的開發語言之間如何能進行「標準化」的通信？ 當時微軟有自己的DCOM技術，SUN 有自己的J2EE/RMI技術，這些都局限於一個小圈子裡，於是COBRA成為第一個吃螃蟹的，一大群專家坐在一起，制定了一個跨語言、跨操作系統、跨硬體平台的「宏偉」目標。 但可惜最終這個宏大目標沒能實現，由於規範過於龐大、開發中間件的廠商沒有人能100%準確理解和遵循規範，導致各種兼容性問題，最終COBRA走向沒落。 COBRA沒落之時，出現兩個分支，其中一個是COBRA領域的資深專家們，這裡主要是技術派專家，而非吹水派專家，看到了COBRA失敗的本質原因，也很痛心這個偉大嘗試的失敗，於是他們抱團，成立了 Zeroc公司，開始了破冰之旅，從而誕生了Ice這個跨平台、跨語言、高性能的RPC平台——他們稱之為反叛之冰。 這裡順便說下COBRA的沒落的一個重要原因：對於中間件和平台這樣的技術，產品本身的質量和功能遠遠超過一紙規範，沒有意識到這個問題而導致失敗的例子很多，網景公司的JavaScript最終不低微軟的JS，SUN的 J2ME最終也讓位於谷歌的Android。 Zeroc公司就吸取了這個教訓，他們自己實現ICE平台的各個語言的Runtime，包括Java版本的、C版本的、Python、PHP，而且十幾年來一直不斷完善，移動設備上，Android，IOS都提供Runtime包，因此，連SUN、Borland都倒下了，Zeroc公司僅靠Ice一個產品，屹立至今，試問IT界里，這樣的技術型公司還有幾個？ COBRA沒落的同時，IBM主推的Webservice/SOA這條線發展下去了，他們也借鑒了COBRA的精華，比如WSDL其實就是IDL，但這個路也沒能光大下去，很快被Rest/JSON替代，然後這裡就沒有平台的說法，都變成了API。 由於Zeroc Ice的存在，所以在多語言、高性能的RPC領域，一直沒有什麼其他產品和開源項目，直到最近，由於移動設備對遠程通信性能和流量的要求提升，同時互聯網開發中多語言協作的增多，於是RPC技術重新被大家重視，谷歌釋放出開源的Protocol Buffers表明其RPC方面的領先性，Facebook則更開放的把Thrift這個框架開源出來，而Avro則是因為Hadoop之父（Avro是Hadoop里的一個組件演化而來的） 看不慣Thrift的思想而打造的一個框架，此框架目前仍然是「半成品」。 與Zeroc Ice相比，Thrift其實只能算作一個FrameWork，而Ice則是一個Platform，另外從成熟度、穩定性等方面來對比，都不是在一個層面上的，目前開源的唯一一個工業級的RPC平台，只有Ice， Ice的性能不用說，其穩定性更是有目共睹，因為最早很多電信級別的客戶使用它。大名鼎鼎的Skype也是用它，國內也不少公司默默的使用。 以下是我對Avro的一個測試研究： ?Apahce Avro框架簡單，非介面編譯的模式靈活度很高，用Json定義的RPC消息結構和方法簡單並容易理解 ?Http協議的編碼和傳輸機制效率遠遠低於長連接的Socket模式，本機對比了Avro的Http協議與Netty實現的Socket協議，請求應答消息相同的情況下，HTTP的TPS是500左右，而Netty Socket模式則是1.5萬左右，相差很懸殊，同樣的介面，ICE的TPS則達到2.5萬TPS！ ?多語言客戶端支持並不是那麼容易的事情，Avro的Phyton客戶端目前只實現了基本的Http協議，（Java的同時實現了Neety客戶端協議），這種情況下，服務端只能也採用Http協議，從而導致並發性能問題.

4、有沒有比較形象一點的比較呢，比如說在實際使用過程中會體現的一些優點，能有幾個粗略的數據對比會更加清晰一些啊

Leader-us：

直觀的幾個好處舉例如下： 以使用最多的語言Jar為例，Ice核心Jar包就一個，100多個類，總共幾百K，不依賴任何其他第三方包，不容易引發包衝突，因為包很小，所以手機上的APP就能打包很小，快速下載，這很重要。 如果系統比較簡單，只是幾個服務的遠程調用，除了業務代碼，Ice相關的編碼也就幾十行，容易上手，不用註冊中心的方式，比Java RMI還簡單 常見的互聯網應用，涉及到PHP、Java、C (ios)，一個Java開發的Ice服務，互聯網Web，Android，蘋果手機，都搞定了，成本和代價很小 如果涉及到安全問題，客戶端從TCP改為SSL，則只要改Ice配置即可，不用改程序，而且一個Ice服務可以同時提供TCP和SSL兩種訪問埠，也只是配置就解決了。 最後，如果系統比較複雜，幾十個上百個服務，涉及到複雜的服務調用，負載均衡問題，那麼升級為IceGrid，定義一個XML文件，秒殺了服務的部署拓撲，只要用控制台命令發布即可， 不像Jboss這種系統，需要手工到每個Jboss下 起停等繁瑣工作。 總之，可以很簡單的使用，也開業很高大上的使用，這就是Zeroc Ice。網上有一個有趣的帖子，有個人說 他認為每個軟體都有自己的缺陷，但是Ice，他一直沒找到缺陷。

5、在介面調用方面，我用過webserivce SAP的RFC，效率和可移植性均不強。現在的平台太多了，而流量和效率是最需要考慮的方面，

1.RPC的效率應該是沒的說，

2.有個問題，Ice的底層是不是也是對OS的API socket的封裝？

Leader-us：

Ice 底層也是Socket通信，使用了NIO最佳模式，比Netty實現的Avro （Apache主席，Hadoop之父的新作） 高出近一倍，相同的介面，Http 介面實現的Avro RPC是 500 TPS，Netty 版的Avro 是1.5萬TPS，Ice則高達2.5萬。有人根據Ice權威指南里的例子，對比了Duboo，發現Ice比Duboo性能高4倍左右。 Ice對外宣傳的是，高性能，多語言，跨平台，非常穩定。排在第一的是高性能，這是其十年來不斷完善與進化的結果，如果你能10年磨一劍，那也是倚天劍了。

6、請問ACE和ICE有什麼區別？從架構層面和設計方面，而不是代碼（ACE的代碼公認的爛，為設計模式而模式）

Leader-us：

ace是對c++基礎開發介面和功能的封裝，提高了程序的可移植性，並且提供了很好網路類； ice是分散式框架，提供了消息分發、對象定位、遠程調用等功能的實現。 ACE 可以理解為是一個API，而且是面向C++ 的ICE可以理解為一個Platform，是多語言的RPC平台兩者不是一個層面的東西另外，Ice又稱之為反叛之冰，是當初參與COBRA的一幫資深大牛另起爐灶的產品，團隊的實力和影響力都是只能仰望的高人，用流行的一個句話來比較，Ice完美秒殺ace。