平常一個B2B平臺交互時，就需要服務器集羣和分佈式處理
一.服務器集羣
如果一個Tomcat 可以處理500個併發請求（實際可以處理200~300的併發就不錯了），那麼10000個併發請求，就需要20臺服務器做Tomcat集羣,當tomcat集羣中節點數據增加，服務器能力先增加後下降。所以集羣中節點(服務器)數量不能太多，一般也就5個左右（節點如果多了就會使服務器性能呈拋物線形式發展），所以通過增加硬件來提高服務器性能是不可能了（就是因爲Session複製問題），那麼就需要軟件來解決這個問題 ；
當然中間就需要一臺負載均衡服務器（如：Nginx），然後將併發請求分佈在兩臺服務器上或者更多服務器上，比如在登錄tomcat1後，將登錄信息進行session共享給tomcat2,這樣才能保證好的體驗度，就是說平常在硬件能解決問題的情況下，絕對不用軟件，因爲軟件改起來比較麻煩，那就花錢唄，就是增加硬件服務器。
注：關注點
Tomcat分享/廣播登錄信息（Session複製導致集羣節點太多，纔會使性能呈拋物線）。
服務器集羣按照自己的理解就是一個工程運行在多個服務器上，自然做的事就是同一件事嘍，達到共享信息，複製的功能。
二.分佈式
1.個人理解：
需要按照功能點將系統進行拆分，拆分成獨立的功能。單獨爲某一個節點添加服務器，需要系統之間配合才能完成整個業務邏輯，叫做分佈式。
主要解決Session複製的問題，一般都是登錄使用Session複製。那採用分佈式的話，就可以考慮把登錄單獨的放在一個系統中進行維護
把一個項目拆分成幾個獨立的小工程，從圖中可以看出，用單點登錄系統來處理Session問題，如果前臺系統併發量高，那就給前臺系統加緩存。再如果後臺系統併發量沒那麼高，那就少配臺服務器，總之就是那塊壓力大就單獨給那塊加服務器，壓力小的就少加臺服務器，這樣就顯得比較靈活了，每一個功能點就是一個獨立的服務器。這樣一來，像以前的話，在一個大工程裏面，如果前臺系統想要調用訂單系統的某些東西，只需要注入進來就行了；但是現在每個功能點獨立之後，就不能這樣調了，因爲現在變成了服務器與服務器之間的通訊了，那麼就需要用到WebService或者Socket來支持了 。
注：分佈式也是多臺服務器，但是它們和集羣的羣別就是做的事都不一樣呀！不過分佈式單獨的服務器又各自能搞成集羣的類 型。比如：前臺系統需要搜索，那麼就需要搜索系統來配合；如果想要下訂單，那麼就需要與訂單系統來配合。反之依然，也就是說每個分佈式的節點都可以配置成服務器集羣。
2.總結：
分佈式架構：多個子系統相互協作才能完成業務流程，系統之間需要進行通信；
集 羣：同一個工程部署到多臺服務器上；
分佈式架構：
把系統按照模塊拆分成多個子系統。
優點：
1️⃣.把模塊進行拆分，使用接口通信，降低模塊之間的耦合度。
2️⃣.把項目拆分成若干個子項目，不同的團隊負責不同的子項目。
3️⃣.增加功能時只需要再增加一個子項目，調用其它系統的接口就可以
4️⃣.可以靈活的進行分佈式部署。
缺點：
1️⃣.系統之間交互需要使用遠程通信，接口開發增加工作量。
2️⃣.各個模塊之間有一些通用的業務邏輯無法共用。
三.SOA架構
SOA:Service Oriented Architecture 面向服務的架構。也就是把工程拆分成服務層，表現層兩個工程。服務層中間包含業務邏輯，只需要對外提供服務即可。表現層只需要處理和頁面的交互，業務邏輯都是調用服務層的服務來實現。
來圖示就可以看出，把系統拆分成了表現層和服務層兩層，這樣的好處就是啥？把上面的表現層所共需的業務邏輯放在了一起即服務層中，這種就可以共同互用了，提供了一定的便捷性。當然雖然架構層次是方便了互通共用，但是表現層的那些系統照樣是單個的子系統，即是單獨的war包，和服務層之間通訊聯繫時還是需要WebService和Socket的。