（轉）ASP.NET Core 企業開發架構概述
目錄
一、 垂直方向架構
1. 多層架構
分層架構通過程序包或者程序的隔離構建鬆耦合的應用。我們以最近流行的洋蔥架構模型進行分析，如圖
1.1 領域模型
包括領域實體/存儲接口/服務接口，是整個程序的核心。
- 貧血模型
如果把大量的業務邏輯委託給服務接口實現者，領域模型顯得很瘦小，就可以稱之爲貧血模型。這種模型下的領域對象僅僅表示「狀態」。「行爲」（也稱爲邏輯、過程）放在了N層結構的Logic/Service/Manager層中。優點是易於理解和實現，缺點是隨着業務發展模型會難以表達業務領域。目前不少業內軟件架構是這種模式。
貧血模型的簡單圖示：
- 充血模型
如果在領域模型中實現主要的業務邏輯，把不方便實現的業務（比如匯率結算，地理座標解析等）委託給服務接口實現者，此時領域模型顯得粗壯，就可以稱之爲充血模型。這種模型下的領域對象既表示「狀態」又有」行爲「，領域對象之間還通過聚合在一個根（聚合根），然後由根對象保證狀態的一致性（類似於數據庫表之間的約束一致性）。優點是模型易於跟進業務發展，容易通過重構表達最新的業務領域；缺點是不易掌握。
充血模型的簡單圖示：
1.2 存儲倉庫
領域模型中的對象自從被創建出來後不會一直留在內存中活動，當它不活動時會被持久化到數據庫中，然後當需要的時候就會重建該對象；重建對象就是根據數據庫中已存儲的對象的狀態重新創建對象的過程。可見持久化和重建對象是一個和數據庫打交道的過程。從更廣義的角度來理解，程序會像集合一樣從某個類似集合的地方根據某個條件獲取一個或一些對象，往集合中添加對象或移除對象。也就是說，這就需要提供一種機制，可以提供類似集合的接口來幫助程序管理對象。倉儲就是基於這樣的思想被設計出來的。
貧血模型下的存儲倉庫：實現實體對象的CRUD.
充血模型下的存儲倉庫：創建聚合根對象,實體對象的創建/更新/刪除的行爲由聚合根完成。
1.3 服務
一般有三種服務：應用服務、領域服務、基礎服務。
-
應用服務
調用領域服務，形成工作流程，提供事物上下文。應用服務可以直接爲UI提供服務或者直接作爲API暴露出去。
-
領域服務
在具體一個業務上下文中提供服務。比如訂單生成服務提供訂單的生成功能，訂單的跟蹤服務提供訂單的執行信息。
-
基礎服務
基礎服務提供的是和業務無直接關係的工具輔助服務。比如日誌，安全，通信，事件總線等等。
1.4 UI
提供應用程序界面，支持用戶輸入。高效的UI開發往往會依賴UI框架，比如MVC框架。
UI框架比較多，比如MFC,WinForm,Asp.net WebForm,Asp.net MVC,Structs等等。
綜上：洋蔥模型的各層由外到內的單向依賴，簡單直接的降低了代碼之間的耦合度。
2. 典型框架
2.1 數據存儲框架
2.1.1 數據訪問輔助
這類框架往往提供了一套操作連接/命令/結果集的接口。用戶先發起連接，發生sql命令，然後得到結果集以按行（又叫記錄）方式進行遍歷。不同的數據庫需要相應的數據庫驅動和實現，但對於用戶來說操作數據的方式都是一樣的。
優點：
- 編寫原始sql，執行效率高。
- 握有連接對象，可以自定義事物的發起，提交或者回滾。
- 可以針對不同數據存儲方式定義數據訪問庫。
- 一般比較輕量，依賴少。
缺點:
- 編寫sql容易出錯，隨着數據庫的演變，sql的潛在錯誤必須依賴充分的單元測試才能消除。
- 數據庫的演變，sql重構難度會逐漸增大。
| 框架 | 特點 | 開發語言 |
|---|---|---|
| JDBC | 簡單易學,上手快,非常靈活構建SQL，效率高 | Java |
| ADO.NET | 接口清晰，支持離線遍歷數據集，支持數據庫和非數據庫數據源 | C# |
2.1.2 對象-關係映射
對象-關係映射（Object-Relational Mapping，簡稱ORM），以面向對象的開發方法實現數據的增刪改查。
優點：
- 提高開發效率，降低開發成本
- 使開發更加對象化
- 可移植
- 可以很方便地引入數據緩存之類的附加功能
缺點：
- 自動化進行關係數據庫的映射需要消耗系統性能。其實這裏的性能消耗還不大，一般來說都可以忽略之（除非在性能特別關鍵應用）。
- 在處理多表聯查、where條件複雜之類的查詢時，ORM的語法會變得複雜。
典型框架：
| 框架 | 特點 | 開發語言 |
|---|---|---|
| Dapper | 半自動；輕量級；自己寫sql語句,可操作性強,小巧 | C# |
| Entity Framework | 全自動；較重量級；支持寫linq和原生sql，功能強大 | C# |
| Hibernate | Hibernate功能強大，數據庫無關性好，O/R映射能力強,需要學習HQL,精通的難度高 | Java |
| iBATIS | 更名爲MyBatis，入門簡單，即學即用;功能比較簡陋，需要受寫sql語句 | Java / NET |
2.2 MVC 框架
- Model
負責提供界面綁定的數據，以及業務邏輯處理。
- View
負責提供用戶和應用之間的交互界面。不同類型的應用交互界面不同，可以是桌面程序窗口和web頁面。
- Controller
負責收集用戶輸入事件，並分配事件給對該事件感興趣的模型處理。對MVC的理解難點在於控制器的解讀，在下面我們會用經典MVC模式和後端MVC模式分析。
2.2.1 經典MVC模式
這種模式大量用在複雜交互界面的桌面應用程序，比如MFC框架；以及web富應用框架中，比如AngularJS 1（儘管有人稱之爲爲MVVM框架）。
控制器把輸入事件通知給對該事件感興趣的模型（步驟3），模型更新自己的狀態並引起視圖更新（步驟4），然後將更新事件通知控制器（步驟5），此時如果有對該更新事件感興趣的模型會進一步進行處理（步驟6）。事實上控制器和模型之間構成了訂閱/發佈關係。
MVVM框架：把Controller變成了ViewModel，它與View進行雙向綁定：View的變動，自動反映在 ViewModel，反之亦然。
2.2.2 後端MVC模式
自web應用普及開來，涌現了不少後端MVC模式，比如JAVA的Structs,.NET的Asp.net MVC等。由於頁面在瀏覽器中顯示，用戶輸入通過http到達後端，在後端看來MVC模式默認如下圖所示：
與經典MVC模式不同，控制器直接獲得輸入事件（http請求），調用對應的模型，模型處理完後傳遞視圖對象（VO）給控制器，控制器找到合適的視圖並傳遞VO給視圖，視圖產生html/json/文件流等資源，應用程序根據資源類型Response結果。通常後端MVC的控制負責的處理比較簡單；而複雜的用戶輸入可以用前端MVC框架實現（類似經典MVC模式）。
2.2.3 典型框架
| 框架 | 特點 | 開發語言 | 前後(端) |
|---|---|---|---|
| Asp.net MVC | 支持WebForm和Razor | C# | 後 |
| Nancy | 輕量，支持WebForm和Razor，路由更靈活 | C# | 後 |
| Struts2 | JSP上的MVC先驅，但比較重量，封裝簡陋 | java | 後 |
| SpringMVC | 開發效率和性能高於Struts2,100%零配置 | java | 後 |
| AngularJS | 功能完整，支持雙向綁定，開發效率高，運行效率一般，v2版本推翻v1,性能上提高，開發更組件化 | js | 前 |
| React | 思路新穎，運用Virtual Dom技術，性能高；但目標是UI組件，需配合其他庫搭建完整MVC框架 | js | 前 |
| Vue | 非常小巧，核心庫專注視圖層。需要搭建其他組件實現完整MVC框架 | js | 前 |
2.2.4 MVC模式總結
模型負責提供視圖數據和業務邏輯處理，視圖負責提供用戶交互界面，控制器將輸入事件分配到對該事件感興趣的模型。控制器居於中心位置，類似於功能膠水，但功能僅限於膠水是它不錯的定位；避免寫入過多業務邏輯代碼使控制器變得複雜，難以維護。
MVC模式的價值在於更好的處理洋蔥架構的UI層。
2.3 IOC框架
2.3.1 概念
用現實生活中例子引入：由於汽車依賴輪胎，如果按照正向依賴，則汽車廠商需要根據輪胎供應商能提供的輪胎來定義自己的接口（螺絲，大小等）。但如果依賴倒置一下（讓輪胎廠商依賴汽車廠商），則汽車廠商只需要定義自己的接口（螺絲，大小等）由輪胎廠商去按照這個規格規範生產，就成爲現在汽車行業的例子。這種依賴倒置是一個思想概念，需要一個容器來實現，這就是IOC框架。
- 依賴倒置(Dependency Inversion Principle, 英文縮寫爲DIP)
從依賴具體類變換爲依賴抽象就叫依賴倒置，這是一種設計原則。
- 控制反轉（Inversion of Control，英文縮寫爲IoC）
依賴倒置的一種實現方式，通常用於構建框架，比如WinForm，WebForm程序中你可以自定義具體的窗口類，然後在窗口初始化和虛函數裏面寫代碼，框架會按照自己的一套流程運行：啓動具體窗口，調用初始化方法，在不同的運行節點調用對應的虛函數。運行控制權始終在框架手中而不是我們寫的代碼。
- 依賴注入(Dependency Injection，英文縮寫爲DI)
依賴注入也是依賴倒置的一種具體實現，是類庫設計的一種常用模式。類庫基於依賴模式設計：調用者依賴於接口，而不是具體的實現，調用者在運行時被注入所依賴接口的具體實現。注入方法不在此處贅述。
- IOC框架
IOC框架包括了控制反轉和依賴注入功能。以下通過QA的方式來讀懂IOC框架：
Q: IOC的控制是對什麼的控制？
A: 是對應用程序中對象的創建和生命週期的控制。
Q: 正向控制是什麼樣子？
A: 由應用程序new對象，並在合適的時候釋放對象。
Q: 反轉控制是什麼樣子？
A: 對象的創建和生命週期管理由IOC框架控制，而不是應用程序控制，這種情形與正向控制相反就叫做反轉控制。
Q: 控制反轉帶來了什麼好處？
A: 控制反轉不僅減輕了應用程序的代碼複雜性，更給IOC框架的擴展性帶來好處，比如IOC框架可以實現對象單例模式，多例模式，引入事物管理，日誌管理，安全管理等等功能，比如Spring產品家族。
Q: 依賴是什麼？
A: 依賴包括：臨時使用，關聯，聚合，組合，依賴關係從左到右增強。可以參考UML相關概念描述。
Q: 注入的目的是什麼？
A: 使得對象可以依賴抽象，而不是具體實現類。主要好處是讓應用程對象之間鬆耦合。
2.3.2 典型注入框架
| 框架 | 特點 | 開發語言 |
|---|---|---|
| Unity | 包含於微軟企業庫中，性能穩定 | C# |
| Autofac | 輕量，性能很高 | C# |
| Spring | 重量，功能強大 | java |
二、 水平方向架構
多層架構適合整體式程序，即一個程序實現了系統全部功能。隨着企業規模越來越大，會面對不斷的新需求和需求改動，在一個程序中進行擴展變得越來越難以進行。同時面對大併發的業務請求，程序在一個進程或者多個進程中運行都難以克服一個低效運行的功能代碼造成的性能瓶頸。
人們找到了解決辦法：將程序功能分割成服務程序，各服務程序在水平方向上並行開發和部署，由API連接各服務，這種方式使降低服務之間的耦合，部署更加靈活，性能調優可以針對獨立的服務。
1. SOA架構
面向服務的體系結構（英語：service-oriented architecture）是構造分佈式計算的應用程序的一種方法。它將應用程序功能作爲服務提供給最終用戶或者其他服務使用。
它採用開放標準、與軟件資源進行交互並採用表示的標準方式。
1.1 簡潔版架構
1.2 服務的基本要素
- Policy(策略)
服務提供者有時候會要求服務消費者與某種策略通信。比如要求消費者提供安全標識，才能獲取某項服務。
- Endpoint(終結點)
終結點是一個描述提供或者接受服務的方式，包括網絡協議，域名或者IP,端口信息。
- Contracts(合約)
服務合約是服務提供者（通常是遠程的）和使用者（客戶）之間使用合約語言（XML、JSON、Java Object等）約定數據輸入和數據輸出的一份協議。
- Messages(消息)
服務提供的消息，應滿足服務的合約。
1.3 服務治理
服務治理SOA最大的話題，涵蓋了以下內容：
- 服務定義（服務的範圍、接口和邊界）
- 服務部署生命週期（各個生命週期階段）
- 服務版本治理（包括兼容性）
- 服務遷移（啓用和退役）
- 服務註冊中心（依賴關係）
- 服務消息模型（規範數據模型）
- 服務監視（進行問題確定）
- 服務所有權（企業組織）
- 服務測試（重複測試）
- 服務安全（包括可接受的保護範圍）
爲了解決以上問題，最爲流行的做法在SOA架構中增加ESB（Enterprise Service Bus，即企業服務總線）集成。
2. 微服務架構
微服務是SOA的進化版本，把服務做到微型化。
2.1 簡潔版架構
2.2 服務的基本要素
微服務架構下通過REST API提供提服務，所以不強調策略和合約，只要服務提供方暴露終結點和提供消息就足夠了。
2.3 服務治理
SOA會遇到的治理問題，在微服務中一樣會暴露出來。由於微服務系統中服務數量更多，生產環境中出現的各種問題更加突出。一部分人覺得微服務架構應該是去中心化，不需要ESB的中介作用，事實上爲微服務的網關可以具備ESB的一些功能，比如安全檢查/事物管理/複雜的工作流程等功能。
3. 整體式 vs SOA架構 vs 微服務架構
| 框架 | 前期開發效率 | 迭代開發效率 | 擴展能力 | 維護性 |
|---|---|---|---|---|
| 整體式 | 高 | 中，通常越來越低 | 低 | 高 |
| SOA架構 | 中 | 中，趨勢比較平穩 | 中 | 中 |
| 微服務架構 | 低 | 高，趨勢比較平穩 | 高 | 低 |
如果是小團隊，中小項目用整體式開發更好；如果有大量或者難以重構的遺留代碼建議採用SOA架構；比如是全新的項目且預計將來會快速迭代成大項目則建議用微服務架構。
4. SOA典型框架
| 框架 | 特點 | 是否開源 |
|---|---|---|
| WCF | 微軟出品，目前僅在windows下運行。它支持HTTP、TCP、命名管道之間的單向和雙向消息通信，此外，在第三方擴展的幫助下，還支持任何基於消息的傳輸格式。 | 客戶端開源 |
| Spring Integration | 基於Spring的輕量級開源框架，是一個乾淨、簡練的EAI手段，也是很好的ESB產品替代者。現在的ESB方案沉重且很難引入到一些環境中。Spring Integration則是一個功能強大、低摩擦的替代方案，它能溫和地解決一些最複雜的集成問題。 | 是 |
| Mule ESB | 它不是僅僅一個集成框架，而是一個包括一些額外功能的完整ESB ，Mule的Studio提供了一個很好的和直觀的可視化設計。比Spring集成它更像是一個DSL。這一點很重要，如果集成邏輯比較複雜。 | 是 |
| Apache Camel | Apache Camel幾乎和Mule ESB相同。你能想到的幾乎每一個技術，提供很多很多的組件（比Mule ESB甚至更多）。如果沒有可用的組件，你可以很容易地創建自己的組件 | 是 |
5. 微服務典型框架
| Dubbo | Spring Cloud | Surging | |
|---|---|---|---|
| 開發語言 | Java | Java | C# |
| 開發方 | 阿里 | Spring社區 | 個人 |
| 維護狀態 | 不再繼續維護 | 活躍 | 一般 |
| 互聯網應用案例 | 阿里、京東、噹噹等 | 聯通 華爲 東軟 | 暫無 |
| 基於協議 | 可選，默認dobbo | http | IPC |
| 可用的語言 | Java | 所有語言 | C# |
| 分佈式事物 | 否 | 否 | 否 |
| 無狀態部署 | 是 | 是 | 是 |
| 服務器治理 | 服務發現、服務路由、服務負載均衡、服務列表、服務分組、服務依賴管理、服務權重、服務授權、服務直連、上下文隱式傳參、分組聚合、結果緩存 | 除dubbo有的外：服務網關、斷路器、服務跟蹤、消息總線、批量任務 | 提供高性能RPC遠程服務調用，採用Zookeeper、Consul作爲surging服務的註冊中心，集成了哈希，隨機，輪詢作爲負載均衡的算法，RPC集成採用的是netty框架，採用異步傳輸 |
| 分佈式配置 | 第三方 | 有 | 有 |
| 單元測試 | 支持 | 支持 | 未知 |
微服務思想重點在服務的微（自治，減少依賴）和治理（一個可靠安全的網關），它鼓勵混合應用順手的編程語言、開發框架，以減少高效開發與部署系統和軟硬件環境之間的摩擦，比如企業內有java和.net開發團隊則可以在Spring Cloud下用Asp.net core做平臺開發微服務程序。
三、 總結
對於整體式程序或者一個服務作爲整體式程序開發 ，可以採用洋蔥模型架構。在處理數據時採用數據存取框架，對於UI可以採用服務器端MVC和客戶端MVC框架。對於具有遺留程序的系統可以採用SOA架構來整合系統功能；如果系統越來越複雜，負載壓力在不同程序功能上不平衡可以採用微服務架構。在全新的即將成爲大型應用的系統採用微服務架構也是不錯的選擇。
參考文章：
http://blog.csdn.net/sinat_34093604/article/details/53082000
http://www.jdon.com/soa/integration-framework-comparison-spring.html
http://blog.csdn.net/qiumuxia0921/article/details/52713791
http://openwares.net/java/dip_ioc_di.html
http://www.cnblogs.com/summer7310/p/6394379.html
http://www.cnblogs.com/wangpenghui522/p/5430292.html
http://blog.csdn.net/zhengzhb/article/details/7190158
http://www.cnblogs.com/fanliang11/p/7191030.html
http://blog.csdn.net/orichisonic/article/details/48546061
以上內容有任何錯誤或不準確的地方請大家指正，不喜勿噴！ 本文版權歸作者和博客園共有，歡迎轉載，但未經作者同意必須保留此段聲明，且在文章頁面明顯位置給出原文連接，否則保留追究法律責任的權利。如果覺得還有幫助的話，可以點一下右下角的【推薦】，希望能夠持續的爲大家帶來好的技術文章！想跟我一起進步麼？那就【關注】我吧。