在這個系統架構上面，通過一個固定IP的Linux機器，使用Tomcat服務器搭建了僅面向PC的Web服務。在這種單服務應用會存在的問題會存在的問題有：服務不穩定 由於每次代碼升級都需要重啓服務，會造成服務有小段時間的停服情況。服務器性能瓶頸 由於單個服務的併發能力有限（tomcat併發處理上線600tps就比較高），且業務和數據庫都部署在一個機器上面，隨着業務發展，對服務器性能的要求會越來越高。JVM不方便調優 業務邏輯處理、文件IO操作等都集中在一個應用中，對於JAVA應用來說，由於業務應用中部分邏輯是IO密集型的、部分是CPU密集型的、對內存的要求也是各種各樣。這種情況下不方便對JVM的參數進行調優，也不方便對線程池數量進行統一設置。如果手裏的資金足夠，可以多采購幾臺服務器，採用集羣式部署方式來是服務更加穩定，採用的架構如下：
在這個架構中，通過增加Nginx反向代理的方式，採用應用集羣的方式解決了服務穩定性問題、通過增加應用服務器數量的方式提高了服務併發處理量、通過將應用服務、數據庫、文件存儲分離，避免了應用服務和存儲相互競爭資源。但是當大量的訪問、修改請求提交的數據庫的時候，單機數據庫較高的瓶頸。對於此問題的解決方式，可以通過增加緩存的方式處理。
在這種架構下，存在由於Nginx通過ip_hash或session-stic解決會話維持對入口Nginx應用的壓力較大、部分業務的查詢不能做緩存且查詢需要耗費較多的數據庫資源、文件存儲管理比較混亂，可以進一步對架構調整如下。
在這個架構下，通過應用服務共享Session到緩存服務上面，解決nginx主主集羣部署下的會話維持。通過讀寫庫分離，解決數據庫單點的壓力問題。通過獨立的文件存儲服務，便於文件的管理。隨着業務發展，業務模塊的劃分的清晰。我們需要一種對支持對業務平臺化，核心業務、非核心業務隔離，對於不同業務產生的數據進行隔離，需要對應用系統和數據庫進行了垂直拆分，構建可靠、穩定的分佈式架構。 在分佈式架構下，對架構進行分層、服務化，內部簡單系統（非真實系統）架構如下：
最後，隨着技術能力的提升，可以對上述服務中的服務能力，可以提供向外的技術輸出（想象一下阿里雲）。比如底層服務中的緩存服務、MQ服務等基礎技術服務，通過隔離機制，提供給其他公司使用；領域服務中的比如互金行業中針對小額分散產品的ABS打包服務，可以作爲一種資產提供能力，提供給其他的金融機構。