松耦合和緊耦合的架構設計、性能對比

　　在最近的一次大數據技術討論會上，有一家公司的技術高管談到松耦合和緊耦合的性能表現的話題。正好Laxcus大數據管理系統的設計，從0.x、1.x到2.x版本，也經歷了從緊耦合到松耦合的發展過程。做為親歷者，對這兩種架構的設計和運行效果，我們有清楚的瞭解和認識。下麵就說一說這件事。寫此博文，也希望給做系統設計的兄弟們，尤其是做高併發、複雜數據計算的同行提供一點參考。

　　先說緊耦合，這種架構是我們在Laxcus 0.x、1.x中採用的。如下圖所示，緊耦合架構本質是一個Client/Server模型。客戶機發起請求給伺服器，伺服器收到，根據請求做出應答，然後反饋給客戶機。這種架構最典型的應用就是我們每天都用到的WEB服務。優點嘛，就是簡單。架構簡單、設計簡單、開發周期短、能夠快速投入部署和應用。在Laxcus集群的早期運行中，這些特點都得到有力的驗證。

緊耦合架構

　　但是到了後期，隨著Laxcus集群規模的不斷擴大，訪問量的不斷增加，尤其是數據計算量、計算時間成倍數的增長後，緊耦合架構漸漸不堪重負，缺點開始不斷暴露出來，主要有以下幾個方面：

　　1. 無法支持大規模的計算業務。因為大數據業務對電腦資源占比普遍很大，導致多任務並行能力有限。舉個例子，我們曾在一臺Pentium IV 2.G + 2G的機器上測試一項小規模的數據處理業務。當並行任務量達到100多個的時候，電腦已經發生超載現象。

　　2. 電腦載荷無法控制。換句話說，就是電腦不能控制超載現象，而超載對硬體傷害非常大，這會嚴重降低電腦穩定運行能力和使用壽命。

　　3. 任務執行過程中管理難度大。任務在執行過程中不受管控。

　　4. 對網路資源消耗大。同步操作在數據發送和數據返回之間，有很大一段是空閑的，這種空閑占用是對網路資源的極大浪費。

　　5. 安全控制力度差。因為伺服器直接暴露給客戶機，容易引髮網絡攻擊行為。

　　6. 程式代碼之間關聯度過高，不利於模塊化處理。

　　7. 以上現象最終導致系統穩定性變差。

　　這些問題出現後，我們開始考慮修改系統設計。經過多番考量、比較、權衡之後，我們決定改用松耦合架構重新規劃系統設計。新框架是在原來Client/Server模型之上的改進，即在Client/Server模型之間加入一個代理（Agent），把CS模型變成CAS模型。在新的架構下，客戶機的角色不變，代理伺服器承擔起與客戶機通信，和對客戶機的識別判斷工作，伺服器位於代理伺服器後面，對客戶機來說不可見，它只負責數據處理工作。另外我們也把CS模型的同步操作改為CAS的代理處理。

　　在設計新架構的同時，我們還發現，如果要適應松耦合架構，原來在緊耦合架構下運行的程式代碼，因為現在的工作方式發生了發生了變化，它們幾乎都要重寫。這可是一個龐大的工程，需要消耗大量的人力、時間去修改和調試。所以我們在松耦合架構之上，結合代理伺服器，又設計了一套Invoke/Produce機制。這是另一種代理方案，是針對數據處理進行抽象化處理和分組分級管理。原來的數據處理和業務邏輯套用這套機制後，程式代碼基本不用修改，轉移到CAS模型上運行就可以了。 

松耦合架構

　　新架構設計和代碼修改完成後，我們在原來的集群上，和緊耦合架構做了各種對比測試。結果表現是出其的好，不僅解決了緊耦合架構上存在的所有問題，而且其中很多技術指標還超出了我們的預估，主要表現以下一些方面：

　　1. 多任務並行處理能力獲得極大提升。同樣是上述那個數據處理，緊耦合架構只能支持最大約100多個並行，而轉到松耦合架構上，達到了8700多個。這還只是在Pentium IV 2.0晶元上的表現，放到Core 2平臺，並行處理任務很輕鬆地超過10000個。

　　2. 實現負載自適應機制。（根據當時運行環境，松耦合架構分配並行工作任務，避免超載現象）。

　　3. 實現了運行任務的隨機控制。 （松耦合架構對運行中的工作任務進行隨機調整和控制，進一步避免了持續超載現象）。

　　4. 基本杜絕了網路攻擊行為。由於代理伺服器的隔絕和篩查作用，同時結合其它安全管理手段，外部攻擊在代理伺服器處就被識別和過濾掉了，這樣就保護了後面的伺服器不受影響。

　　5. Invoke/Produce機制改善了程式結構的模塊化，有利於實現複雜的數據業務處理。

　　6. 非同步操作減少了網路資源消耗和操作關聯。

　　7. 綜合以上措施，它們共同增強了系統穩定性。

　　最後用一張表格對兩種架構做個對比，做為兩種架構性能特點的總結。有關Laxcus詳細介紹，請見《Laxcus大數據管理系統》一文。