TCP/IP、HTTP、WEBSERVICE、SOAP、ICE都使用后才有感慨

TCP是TCP/IP的第三層傳輸層，對(duì)應(yīng)OSI的第四層傳輸層；
IP是TCP/IP的第二層互聯(lián)層，對(duì)應(yīng)OSI的第三層網(wǎng)絡(luò)層。

ICE(Internet Communications Engine)是ZeroC提供的一款高性能的中間件，基于ICE可以實(shí)現(xiàn)電信級(jí)的解決方案。前面我們提到過(guò)在設(shè)計(jì)網(wǎng)站架構(gòu)的時(shí)候可以使用ICE實(shí)現(xiàn)對(duì)網(wǎng)站應(yīng)用的基礎(chǔ)對(duì)象操作，將基礎(chǔ)對(duì)象操作和數(shù)據(jù)庫(kù)操作封裝在這一層，在業(yè)務(wù)邏輯層以及表現(xiàn)層(java,php,.net,python)進(jìn)行更豐富的表現(xiàn)與操作，從而實(shí)現(xiàn)比較好的架構(gòu)?；贗CE的數(shù)據(jù)層可以在未來(lái)方便的進(jìn)行擴(kuò)展。ICE支持分布式的部署管理，消息中間件，以及網(wǎng)格計(jì)算等等。 

大道理講完，言歸正傳，最近育兒網(wǎng)新增了不少新服務(wù)，服務(wù)間經(jīng)常會(huì)需要相互調(diào)用數(shù)據(jù)，例如用戶(hù)中心要取博客系統(tǒng)里的文章啊，論壇里發(fā)文后要在積分系統(tǒng)里增加用戶(hù)積分啊。由于設(shè)計(jì)時(shí)這些服務(wù)僅僅基于統(tǒng)一的用戶(hù)中心，服務(wù)間基本是獨(dú)立的，所以要實(shí)現(xiàn)這些調(diào)用只能在每個(gè)服務(wù)上新增為其它服務(wù)提供服務(wù)的服務(wù)-_-!。這個(gè)時(shí)候有幾個(gè)可選方案，我們開(kāi)始選擇了xml-rpc，基于http和xml的選程調(diào)用，用了一段時(shí)間，發(fā)現(xiàn)維護(hù)成本和訪(fǎng)問(wèn)性能都存在問(wèn)題。 

由于這些中間服務(wù)部署的時(shí)候是和各自所屬的服務(wù)部署在一起的，對(duì)這些服務(wù)做整體的改動(dòng)就非常困難，要維護(hù)起來(lái)就比較麻煩。另外由于是什么http和xml作為通信協(xié)議，由php實(shí)現(xiàn)業(yè)務(wù)邏輯，性能問(wèn)題也很明顯，而且這些http請(qǐng)求都會(huì)在http日志留下足跡，導(dǎo)致我們的日志分析很不精確。這個(gè)問(wèn)題不是太大，但很郁悶，所以我們考慮使用ICE來(lái)解決這個(gè)問(wèn)題，至于SOAP什么的就不考慮了，同樣效率低下。 

實(shí)現(xiàn)的過(guò)程還是比較順利，花了三天的時(shí)間用c++實(shí)現(xiàn)了大部分常用的接口，服務(wù)端采用deamon的方式運(yùn)行，錯(cuò)誤日志記在syslog里(/var/log/messages)，客戶(hù)端PHP，編譯進(jìn)去了IcePHP，調(diào)用的方法很簡(jiǎn)單?，F(xiàn)在還存在一些問(wèn)題，運(yùn)行的時(shí)候會(huì)異常退出，還需要一段時(shí)間來(lái)解決，暫時(shí)加了只狗看著，一旦進(jìn)程里沒(méi)了就重新啟動(dòng)。 

既然要跨平臺(tái)通訊，就涉及對(duì)象描述，ICE使用Slice來(lái)對(duì)結(jié)構(gòu)，類(lèi)，方法等進(jìn)行定義。完了以后服務(wù)器端，客戶(hù)端都按這個(gè)來(lái)調(diào)用和實(shí)現(xiàn)。ICE內(nèi)置的Linux 下后臺(tái)Deamon實(shí)現(xiàn)方案非常簡(jiǎn)單，只需要從Ice::Service里派生出一個(gè)類(lèi)來(lái)，實(shí)現(xiàn)run方法，在這個(gè)方法里創(chuàng)建adapter對(duì)象，并在adapter對(duì)象里添加Servants，然后激活這個(gè)adapter就可以了，網(wǎng)絡(luò)層的通信都由ICE接管了。由于是基于tcp/ip的直接通信，比更高層的http通信效率要高很多。 

在客戶(hù)端實(shí)現(xiàn)時(shí)，我們也碰到了一些小麻煩。一個(gè)是內(nèi)置的$ICE對(duì)象用的時(shí)候有時(shí)需要用global聲明，否則可能會(huì)出錯(cuò)，另外由于默認(rèn)情況下Slice中struct對(duì)應(yīng)到php的類(lèi)型是一個(gè)類(lèi)的實(shí)例，而不是一個(gè)數(shù)組，所以在賦值給頁(yè)面的時(shí)候，smarttemplate以及其它模板系統(tǒng)中可能都會(huì)存在問(wèn)題，可以通過(guò)修改模板系統(tǒng)的數(shù)據(jù)賦值顯示代碼解決。 

我們做了一些性能的測(cè)試，同樣運(yùn)行1千次請(qǐng)求，使用xml-rpc實(shí)現(xiàn)需要28秒左右，使用ICE實(shí)現(xiàn)，只需要3秒多，性能的差距還是很大的，同時(shí)在這個(gè)過(guò)程中沒(méi)發(fā)現(xiàn)有內(nèi)存泄露的情況，效果還比較理想。 
//////////////////

WEBSERVICE   所遵循的SOAP協(xié)議 是建立在HTTP協(xié)議之上的協(xié)議 

簡(jiǎn)單對(duì)象訪(fǎng)問(wèn)協(xié)議（SOAP）是W3C組織的一個(gè)Note, 它描述了一種在分散的或分布式的環(huán)境中如何交換信息的輕量級(jí)協(xié)議。SOAP是一個(gè)基于XML的協(xié)議，它包括三個(gè)部分：SOAP封裝(Envelop)，封裝定義了一個(gè)描述消息中的內(nèi)容是什么，是誰(shuí)發(fā)送的，誰(shuí)應(yīng)當(dāng)接受并處理它以及如何處理它們的框架；SOAP編碼規(guī)則（Encoding Rules），用于表示應(yīng)用程序需要使用的數(shù)據(jù)類(lèi)型的實(shí)例；SOAP RPC表示(RPC Representation)，表示遠(yuǎn)程過(guò)程調(diào)用和應(yīng)答的協(xié)定；SOAP可以和多種傳輸協(xié)議綁定（Binding），使用底層協(xié)議交換信息。在這個(gè)文檔中，目前只定義了SOAP如何和HTTP以及HTTP擴(kuò)展進(jìn)行綁定的框架。

SOAP是個(gè)通信協(xié)議， SOAP在HTTP協(xié)議的基礎(chǔ)上，把編寫(xiě)成XML的REQUEST參數(shù), 放在HTTP BODY上提交個(gè)WEB SERVICE服務(wù)器(SERVLET，ASP什么的) 處理完成后，結(jié)果也寫(xiě)成XML作為RESPONSE送回用戶(hù)端， 為了使用戶(hù)端和WEB SERVICE可以相互對(duì)應(yīng)，可以使用WSDL作為這種通信方式的描述文件，利用WSDL工具可以自動(dòng)生成WS和用戶(hù)端的框架文件，SOAP具備把復(fù)雜對(duì)象序列化捆綁到XML里去的能力。

SOAP的前身是RPC, 就是遠(yuǎn)程呼叫處理的協(xié)議，這個(gè)協(xié)議安全性不是很好，多數(shù)防火墻都會(huì)阻擋RPC的通信包，而SOAP則使用HTTP協(xié)議作為基本的協(xié)議，使用端口80使得SOAP可以透過(guò)防火墻，完成RPC的功能。

SOAP協(xié)議和HTTP協(xié)議一樣，都是底層的通信協(xié)議，只是請(qǐng)求包的格式不同而已，SOAP包是XML格式的，現(xiàn)在我們編寫(xiě)WEB SERVICE不需要深入理解SOAP也沒(méi)關(guān)系。如果SERVICE和CLIENT在同樣的環(huán)境下使用SOAP，由于一般情況下都有自動(dòng)生成SOAP程序框架的工具，因此不知道細(xì)節(jié)也沒(méi)關(guān)系. 可是, 如果CLIENT和SERVICE的環(huán)境不同，比如說(shuō)JAVA的Client和.NET的SERVICE進(jìn)行通信，或者是VB CLIENT和TOMCAT下的JAVA SERVICE通信，還是要知道一點(diǎn)細(xì)節(jié)為好. 特別是, WSDL或者UDDI都不是標(biāo)準(zhǔn)，如果不讓用就只好手工配制SOAP MESSAGE啦。