摘要：集群能帶來什么提高服務的性能，并發能力，以及高可用性首先，一臺機子一個，如果你用單機部署多的話，他們會共享網卡內存磁盤等，其性能依舊不行，且一臺機子的線程池是有限的，多機的話可以對應處理并發，對于高可用性，下掛載多臺，當一臺宕機時，可以直接

1、提高服務的性能，并發能力，以及高可用性；

（首先，一臺機子一個Tomcat，如果你用單機部署多Tomcat的話，他們會共享網卡、內存、磁盤IO等，其性能依舊不行，且一臺機子的HTTP線程池是有限的，多機的話可以對應處理并發，對于高可用性，Nginx下掛載多臺Tomcat，當一臺宕機時，可以直接將該節點取消，轉接到可用節點）

2、提供項目架構的橫向擴展能力；

（類似天貓雙11，通過動態添加Tomcat，Nginx熱部署完成橫向擴展功能）

（一步登天）通過Nginx負載均衡進行請求轉發

單機或常用框架

一個很合理的架構思路，小白也需要了解一下，一眼就能讀懂。

轉為集群后的“理想”架構

1、由上圖，有經驗的朋友一眼已經看出了Session問題，Session登錄信息存儲及讀取的問題
2、服務器定時任務并發的問題（類似電商類的訂單定時關閉任務，可能存在并發問題）

當然，也是有一些解決方案：
類似：采用nginx ip hash policy

優點：可以不改變現有技術架構，直接實現橫向擴展（省事）
缺點：
    1、導致服務器請求（負載）不平均（完全依賴ip hash的結果）
    2、在Ip變化的環境下無法服務
    

那么我們理應采用第二種，第一種在正常的公司與團隊都很少采用，而也由此演變了比較合理的集群架構

通過Session Server解決單個服務器對應單個Session的問題，后期還要編碼處理單點登錄，且Redis還要處理分布式鎖（防止多機同時啟動定時任務，并發問題等）

這里要注意的是，架構的演進是和項目的功能、業務與問題相關的，而不是理所當然的照搬。

如果本文對你有所幫助，歡迎關注個人技術公眾號，或者點贊，謝謝。