使用基於Http的訊息代替WebService的資料互動

標籤：基於http的訊息

系統間互動的工作，隨著資訊化建設的發展，以及業界對SOA的認識及其帶來的低TOC（總體擁有成本）等優勢，越來越受到資訊化水平較高的使用者的重視。

這裡先拋開SOA這樣的架構規劃，單純就系統間整合的協議進行討論。

系統間的互動或者成為整合（互聯互連），早在資訊化系統誕生的時候，就已經出現，只是並不明顯，或者由於早期開發平台、開發語言等的單一性，這種需求並沒有非常大的爆發出來。

隨著資訊化建設的發展，以及各種不同的開發語言的發展，跨語言的不同業務系統之間的互動，成為了擺在CIO們面前的一個大問題。

早期，為了保證資料或者訊息在不同的業務系統間傳遞的安全、有效、穩定，往往使用基於MQ的Message進行訊息傳遞。這期間IBM的MQ產品，成為跨業務系統資訊互動的重要媒介。但是，使用MQ的前提是，MQ已經提供了針對特定開發語言的API包，如MQ沒有提供，則無法使用。並且，MQ產品本身作為一個商業產品，其成本也是非常高的。由於MQ支援XA事務，因此，其資料傳遞的有效性還是能夠得到保障的。

後來，人們開始探討使用基於RDBMS的“前置機”方式。即需要互動的雙方，使用一個脫離於各自業務系統的“中間資料庫”，將需要讀寫的資料，讀寫入中間資料庫，再進行後續的操作。使用RDBMS的優點是，直接利用關係型資料庫這種支援事務的平台，並且關係型資料庫同樣支援XA事務，保證資料在不同資料庫之間傳遞的有效性。缺點是需要額外處理一套專門的中間表或者中間資料庫，並且有時並不能解決所有的問題。而且，當需要互動的系統超過3個時，每個系統都需要處理多於1個中間表體系，對系統廠商造成大量的工作。

WebService曾經認為是解決異構系統間整合的最佳解決方案，不依賴於第三方任何系統的支援（不需要額外部署專門的MQ或者RDBMS伺服器），大家只需要按照官方的規範，即可完成相互之間的資料互動。但是，webService存在的問題是，使用SOAP需要對訊息進行多層次的封裝，webservice之間進行資料互動的效率受到了嚴重的影響。雖然，webservice能夠互動的資料格式多種多樣，基本也不存在資料格式不支援的情況。但是，webservice的效率及其webservice的逾時等問題，還是困擾了系統廠商。

隨著httpclient的出現，以及JSON等資料格式的大範圍使用，基於http的訊息介面，逐漸被大家所青睞。一方面是因為，直接使用httpclient可以類比瀏覽器的資料操作與封裝；另一方面使用基於http的訊息，可以藉助於http的成熟、可靠、開源的web叢集解決方案來提升總體的效率。還有，就是基於http的訊息格式，幾乎不受任何限制，常規應用的各種訊息格式，基本都能直接使用基於http的訊息進行傳遞。目前，大部分PaaS平台，所提供的API介面，實際上就是使用基於Http的JSON訊息，來進行資料傳遞的。

針對基於http的訊息及WebService的效能問題，筆者曾經做過測試。

在一台配置較低的PC上，同時開啟服務端與用戶端，10000條資料，使用基於http的訊息逐條進行傳遞，從開始傳遞至全部接收並處理完畢，大概需要465秒的時間；而在同一台機器上，使用WebService進行互動，則需要1180秒。整體的效能大概查了接近60%。

因此，筆者大膽猜測，未來隨著基於http進行訊息傳遞的技術逐步完善，以及相關業界標準的進一步完善，一種新的基於http的訊息格式會逐步替代webservice，成為主流。

使用基於Http的訊息代替WebService的資料互動