0. ORM應用

就是所有的都寫在一起 ，這裏就不做解釋了吧，

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. 微服務架構例如dubbo/springcloud

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

微服務的主要特征如下：

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

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

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

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

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

系統應用架構演變（轉載）