講一下創業公司的技術架構演進

 

 

　　從2015年6月百度離職後，加入創業公司到如今已經將近兩年了。新系統的架構隨着時間的推移作了很是多的變化以及調整，在這裏對本身系統的架構的演進歷程以及爲何作這種優化處理作一些總結，並講述一下各個過程遇到的問題與解決方式。

在創業初期，爲了遇上線進度一開始的時候，一切以功能爲主，且創業初期資金有限，沒有采購太多的服務器資源，所以系統在技術架構層面沒有作太多的設計，系統的全部資源都放在一個服務器上，此時系統的架構能夠以下：

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

1. 服務不穩定

　　因爲每次代碼升級都須要重啓服務，會形成服務有小段時間的停服狀況。

1. 服務器性能瓶頸

　　因爲單個服務的併發能力有限（tomcat併發處理上線600tps就比較高），且業務和數據庫都部署在一個機器上面，隨着業務發展，對服務器性能的要求會愈來愈高。

1. JVM不方便調優

　　業務邏輯處理、文件IO操做等都集中在一個應用中，對於JAVA應用來講，因爲業務應用中部分邏輯是IO密集型的、部分是CPU密集型的、對內存的要求也是各類各樣。這種狀況下不方便對JVM的參數進行調優，也不方便對線程池數量進行統一設置。

若是手裏的資金足夠，能夠多采購幾臺服務器，採用集羣式部署方式來是服務更加穩定，採用的架構以下：

　　在這個架構中，經過增長Nginx反向代理的方式，採用應用集羣的方式解決了服務穩定性問題、經過增長應用服務器數量的方式提升了服務併發處理量、經過將應用服務、數據庫、文件存儲分離，避免了應用服務和存儲相互競爭資源。可是當大量的訪問、修改請求提交的數據庫的時候，單機數據庫較高的瓶頸。對於此問題的解決方式，能夠經過增長緩存的方式處理。

 

 

　　在這種架構下，存在因爲Nginx經過ip_hash或session-sticky解決會話維持對入口Nginx應用的壓力較大、部分業務的查詢不能作緩存且查詢須要耗費較多的數據庫資源、文件存儲管理比較混亂，能夠進一步對架構調整以下。

　　在這個架構下，經過應用服務共享Session到緩存服務上面，解決nginx主主集羣部署下的會話維持。經過讀寫庫分離，解決數據庫單點的壓力問題。經過獨立的文件存儲服務，便於文件的管理。隨着業務發展，業務模塊的劃分的清晰。咱們須要一種對支持對業務平臺化，核心業務、非核心業務隔離，對於不一樣業務產生的數據進行隔離，須要對應用系統和數據庫進行了垂直拆分，構建可靠、穩定的分佈式架構。

 

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

　　最後，隨着技術能力的提高，能夠對上述服務中的服務能力，能夠提供向外的技術輸出（想象一下阿里雲）。好比底層服務中的緩存服務、MQ服務等基礎技術服務，經過隔離機制，提供給其餘公司使用；領域服務中的好比互金行業中針對小額分散產品的ABS打包服務，能夠做爲一種資產提供能力，提供給其餘的金融機構。