1.      傳統的垂直應用的架構：

就是我們現在企業中最常用的MVC架構，它有一個主要的特點就是技術單一，開發上手快，測試，部署都是比較簡單的

MVC的三層結構：

a．  最前端的是V(view),主要是用於前端頁面展示，使用jsp,js,html+css等

b．  中間為排程控制層（Control）,主要是用於前端web請求的分發，然後排程後臺的邏輯執行，可以通過struts2或者spring mvc來實現

c．  第三層為應用模型層（Model），模型是應用程式上的字型部分，模型代表了業務邏輯和業務資料

標準的MVC模式並不包含資料訪問層，在開發中我們有一些架構可以解決這個問題，比如使用了我們的ORM(物件關係對映框架)來實現與資料庫的訪問，可以使用mybatis和hebernate,這倆個框架都不同程度的封裝了JDBC

這種垂直架構面臨的挑戰：

1.      複雜應用開發的維護成本很高，部署效率低

2.      團隊合作弱，多個專案的或者同一個專案的公共模組重複開發，增加了程式碼量的冗餘

3.      系統可靠性降低，隨業務的不斷增加，訪問量增大，網路流量增大，資料庫連線增多，這都是將要面臨的問題

4.      維護困難：業務程式碼不斷加大，功能不斷加多，在這種垂直的架構中無法對已有的服務拆分，改一個地方，其它地方會有影響

2.      RPC架構

RPC架構可以讓遠端過程（服務）呼叫更加簡單、透明，RPC框架負責遮蔽底層的傳輸方式（TCP或者是UDP）、序列化方式（XML、JSON、二進位制）和一些通訊的細節，開發者不需要關心具體的通訊細節和呼叫過程

RPC架構的核心技術：

1.      遠端服務提供者需要以某種形式提供服務呼叫相關的資訊，包括但不侷限於服務介面定義、資料結構，或者中間態的服務定義檔案，服務呼叫者需要通過一定的途徑獲取遠端服務呼叫相關資訊。

2.      遠端代理物件：服務呼叫者呼叫的服務實際是遠端服務的本地代理，對於我們的java來說其實就是jdk的動態代理，通過動態代理的攔截機制，將本地呼叫封裝成遠端服務呼叫

3.      通訊：RPC框架與具體的協議無關

4.      序列化

RPC架構面臨的挑戰：

隨著服務越來越多的時候，服務間依賴關係變得錯綜複雜，服務的呼叫量越來越大，服務的容量問題就會暴露出來了，某個服務在那個機器上，什麼時候該增加節點，這都是問題

將業務服務化後，隨之而來的就是服務治理的問題，目前業界開源的RPC框架的服務治理能力都不是很健全，當應用大規模服務化後會面臨許多服務治理方面的挑戰，需要解決這些問題，必須通過服務框架+服務治理來完成，但憑RPC框架就比較吃力了

3.      SOA服務化架構

SOA是一種粗粒度，鬆耦合的以服務為中心的架構，介面間通過定義明確的協議和介面進行通訊。它可以更加從容地應對複雜企業系統整合和需求的快速變化

SOA面向服務的一般原則總結如下

1.      服務和複用

2.      服務共享一個標準的契約：比如說一個介面

3.      服務間是鬆耦合的

4.      服務是底層邏輯的抽象：只有經服務契約所暴露的服務對外部可見，契約外的底層邏輯實現是不可見的

5.      服務是可以組合的：多個服務可以被編排組合成一個新的服務

6.      服務是自治的不依賴其它服務

7.      服務是可以被自動發現的:服務釋出上線後，允許被其它消費者自動發現

SOA架構面臨的挑戰：

SOA架構解決了應用服務化的問題，隨著服務化實踐的不斷深入，服務規模越來越大，服務治理面臨的挑戰也是越來越多

4.      微服務架構

微服務架構是一種服務化架構風格，通過將功能分散到各個離散的服務中以實現對解決方案的解耦

微服務的主要特徵如下：

1.      原子服務，專注於做一件事情，與面向物件中的“單一職責原則”類似，實現高內聚，低耦合

2.      高密度部署：重要的服務可以獨立程序部署，非核心服務可以獨立打包，合設到統一程序中去，服務被高密度部署

3.      敏捷交付：服務由小研發團隊負責設計、開發、測試、部署、線上治理運維整個服務的生命週期

4.      微治理：服務足夠小，功能單一，可以獨立打包、部署、升級。不依賴其它的服務，實現了局部自治

這就是我們應用架構的演進，從耦合到微服務，便於管理和服務的治理