從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打包服務，可以作為一種資產提供能力，提供給其他的金融機構。