從2015年6月百度離職後，加入創業公司到現在已經將近兩年了。新系統的架構隨著時間的推移做了非常多的變化以及調整，在這裡對自己系統的架構的演進歷程以及為什麼做這種優化處理做一些總結，並講述一下各個過程遇到的問題與解決方式。

在創業初期，為了趕上線進度一開始的時候，一切以功能為主，且創業初期資金有限，沒有采購太多的伺服器資源，因此係統在技術架構層面沒有做太多的設計，系統的所有資源都放在一個伺服器上，此時系統的架構可以如下：

在這個系統架構上面，通過一個固定IP的Linux機器，使用Tomcat伺服器搭建了僅面向PC的Web服務。在這種單服務應用會存在的問題會存在的問題有：

• 服務不穩定

由於每次程式碼升級都需要重啟服務，會造成服務有小段時間的停服情況。

• 伺服器效能瓶頸

由於單個服務的併發能力有限（tomcat併發處理上線600tps就比較高），且業務和資料庫都部署在一個機器上面，隨著業務發展，對伺服器效能的要求會越來越高。

• JVM不方便調優

業務邏輯處理、檔案IO操作等都集中在一個應用中，對於JAVA應用來說，由於業務應用中部分邏輯是IO密集型的、部分是CPU密集型的、對記憶體的要求也是各種各樣。這種情況下不方便對JVM的引數進行調優，也不方便對執行緒池數量進行統一設定。

如果手裡的資金足夠，可以多采購幾臺伺服器，採用叢集式部署方式來是服務更加穩定，採用的架構如下：

在這個架構中，通過增加Nginx反向代理的方式，採用應用叢集的方式解決了服務穩定性問題、通過增加應用伺服器數量的方式提高了服務併發處理量、通過將應用服務、資料庫、檔案儲存分離，避免了應用服務和儲存相互競爭資源。但是當大量的訪問、修改請求提交的資料庫的時候，單機資料庫較高的瓶頸。對於此問題的解決方式，可以通過增加快取的方式處理。

在這種架構下，存在由於Nginx通過ip_hash或session-sticky解決會話維持對入口Nginx應用的壓力較大、部分業務的查詢不能做快取且查詢需要耗費較多的資料庫資源、檔案儲存管理比較混亂，可以進一步對架構調整如下。

在這個架構下，通過應用服務共享Session到快取服務上面，解決nginx主主叢集部署下的會話維持。通過讀寫庫分離，解決資料庫單點的壓力問題。通過獨立的檔案儲存服務，便於檔案的管理。隨著業務發展，業務模組的劃分的清晰。我們需要一種對支援對業務平臺化，核心業務、非核心業務隔離，對於不同業務產生的資料進行隔離，需要對應用系統和資料庫進行了垂直拆分，構建可靠、穩定的分散式架構。

在分散式架構下，對架構進行分層、服務化，內部簡單系統（非真實系統）架構如下：

最後，隨著技術能力的提升，可以對上述服務中的服務能力，可以提供向外的技術輸出（想象一下阿里雲）。比如底層服務中的快取服務、MQ服務等基礎技術服務，通過隔離機制，提供給其他公司使用；領域服務中的比如互金行業中針對小額分散產品的ABS打包服務，可以作為一種資產提供能力，提供給其他的金融機構。

出處：http://www.cnblogs.com/loveyou/p/6931136.html

版權申明：內容來源網路，版權歸原創者所有。除非無法確認，我們都會標明作者及出處，如有侵權煩請告知，我們會立即刪除並表示歉意。謝謝。

-END-