浅谈开发模式及架构发展
一、傳統開發模式
? ? 傳統的開發模式基本一般是重服務端的開發方式，大部分工作都在服務端執行，然后返回到客戶端（通常是HTML）。以Asp.net MVC為例，如下圖：
? ??
?
? ? #1 根據請求的路由定位到對應的Controller的對應的Action。
? ? #2 執行相關邏輯，得到結果Model（也可能沒有Model，如直接返回View）。
? ? #3 定位并加載對應的View（也可能沒有View，如返回TextResult，JsonResult等）。
? ? #4 在服務端通過Razor引擎把Model和View綁定起來生成最終的返回結果（一般是HTML），返回到客戶端。
?
? ? 缺點：
? ? #1 職責不明確，要求工程師對前后端技術都要了解一點，有的甚至是后端工程師同時兼顧前后端。
? ? #2 隨著不同終端(Pad/Mobile/PC)的興起，對前端的要求越來越高，同時兼顧前后端的工程師開始感到乏力。
? ? #3 前端工程師必須使用后端工程師的IDE，如Visual Studio。不用的話，又會產生集成的工作量。
? ? #4 應用開發流程繁瑣，如下圖：
? ??
?
二、前后端分離 - 大前端時代
? ? ?隨著傳統的開發模式的缺點日益明顯，以及前端技術與框架的發展，逐漸形成了前后端分離的開發模式。加上Html5，Css3，混合式開發技術的發展，更是把前端開發推向了一個百花齊放的大前端時代。前后端分離的交互大概如下圖所示：
? ??
?
? ? #1 服務端響應請求返回結果（一般是json或xml）。
? ? #2 客戶端接受到返回結果，反序列化成JS Object，和Html Template進行雙向綁定。
? ? #3 Object的變化會引起View的變化，View的操作可以改變Object。
? ? #4 Controller托管著Object，View可以調用Controller的Event，然后給服務端發送請求。
?
? ? 實現前后端分離的前端框架（如Angular/Angular2，Vue/Vue2，Durandal，Webix-Jet等）一般都會包含三個重要組合部分：路由、模版、綁定。
? ? 我大概在2011年開始嘗試前后端分離，但當時上述提到的框架還沒被發掘出來，只有一個雙向綁定的框架knockoutjs。因此，我當時做了兩種嘗試：
? ? #1 純前后端分離：Asp.Net MVC（僅返回json） + html + knockoutjs + requirejs + ajax。
? ? #2 偽前后端分離：Asp.Net MVC（返回json以及無對象綁定的view） + knockoutjs + requirejs + ajax。
? ? 之所以會有第二種方案是因為我想使用MVC的路由以及它的母板（Master Page）機制，目前的框架基本都提供了母板機制。
?
? ? 前后端分離的通訊一般都使用ajax，少部分使用form表單，服務端接口建議使用RESTful的風格：
? ??
? ? API表示資源或領域，Method表示行為。
?
? ? 優點：
? ? #1 前后端工程師職責分明，后端可以更加關注后端技術，前端可以更關注前端技術。
? ? #2 前端工程師可以按自己的喜好來選擇IDE（WebStrom，HBuilder， Sublime等），而不需要了解后端工程師使用的IDE。
? ? #3 服務端的職責只負責數據處理（接收請求返回json），技術選型多樣化，可以是.net， jsp， php，nodejs等。
? ? #4 服務端作為一個數據中心的角色，可以服務多種應用，如桌面程序，web，手機app等。
? ? #5 可以更好的使用瀏覽器緩存，靜態的html和js加載一次后會存在瀏覽器緩存中。
? ? #6?應用開發流程更簡潔高效（可并行），如下圖：
? ??
?
? ? 挑戰：
? ? #1 對ajax的使用要求更高，目前很多前端工程師沒有關注到這一點，如promise機制。
? ? #2 基于ajax的通訊經常要解決跨域問題。
?
三、微服務架構
? ? 以上兩種開發模式都是單體架構，它們能夠很好地應對簡單的業務系統。但是隨著業務的擴張，功能的不斷增加，單體架構面臨著越來越多的挑戰：
? ??
?
? ? #1 維護成本增加
? ? ? ? ?a. 團隊越來越大，相應的溝通成本、管理成本、人員協調成本顯著增加。
? ? ? ? ?b. 引起缺陷的原因組合多，導致分析、定位、修復缺陷的成本響應增高。
? ? ? ? ?c. 在自動化測試機制不完善的情況下，易導致“修復越多，缺陷越多”的惡性循環。
? ? #2 交付周期長
? ? ? ? ?代碼編譯、檢查，運行測試、構建、更能驗證等，反饋周期變長。
? ? #3 新人培訓周期長
? ? ? ? ?對于新加入團隊的成員，需要花更多的時間了解熟悉業務、配置環境、熟悉代碼。
? ? #4 技術選型成本高
? ? ? ? ?單體架構傾向于采用統一的技術平臺或方案來解決所有問題。
? ? #5 可伸縮性差
? ? ? ? ?a. 無法按需伸縮。
? ? ? ? ?b. 資源有效利用率低。
? ? #6 構建全功能團隊難
? ? ? ? ?應用程序的復雜結構也會逐漸映射到研發團隊的結構上。
?
? ? 微服務架構（Microservice Architect）：
? ? #1?微服務架構是一種架構模式，它提倡將單塊架構的應用劃分成一組小的服務，服務之間互相協調、互相配合，為用戶提供最終價值。
? ? #2?每個服務運行在其獨立的進程中，服務與服務間采用輕量級的通信機制互相溝通。
? ? #3?每個服務都圍繞著具體業務進行構建，并且能夠被獨立的部署到生產環境、類生產環境等。
? ? #4 另外，應當盡量避免統一的、集中式的服務管理機制，對具體的一個服務而言，應更具業務上下文，選擇合適的語言、工具對其進行構建。
? ??
?
? ? 本質特征：
? ? #1 服務作為組件
? ? #2 圍繞業務組織團隊
? ? #3 關注產品而非項目
? ? #4 技術多樣性
? ? #5 業務數據獨立
? ? #6 基礎設施自動化
? ? #7 演進式架構
?
? ? 優勢：
? ? #1 邊界性
? ? ? ? ?a. 業務獨立
? ? ? ? ?b. 功能耦合度低
? ? #2 獨立性
? ? ? ? ?a. 獨立部署
? ? ? ? ?b. 按需伸縮
? ? #3 技術多樣性
? ? ? ? ?a. 使用合適的語言或者工具
? ? ? ? ?b. 使用合適的數據存儲
?
? ? 挑戰：
? ? #1 分布式系統的復雜度
? ? ? ? ?a. 網絡因素（帶寬、超時）
? ? ? ? ?b. 數據一致
? ? ? ? ?c. 可用性
? ? #2 微服務測試
? ? ? ? ?a. 測試策略
? ? ? ? ?b. 自動化測試
? ? #3 運維成本高
? ? ? ? ?a. 環境配置
? ? ? ? ?b. 部署
? ? ? ? ?c. 監控
? ? #4 微服務的依賴管理
? ? ? ? ?a. 版本管理
? ? ? ? ?b. 服務依賴
? ? ? ? ?c. 服務治理?
?
? ? 展望：
? ? 后續有機會的話，我會寫一系列關于.Net Core如何與Srping Cloud集成的文章。
?
? ??說明：
? ? 本文部分內容來自王磊的《微服務架構與實踐》和infoq發表的文章：
? ??解析微服務架構（一）單塊架構系統以及其面臨的挑戰
? ??解析微服務架構（二）微服務架構綜述
原文地址:http://www.cnblogs.com/Erik_Xu/p/6241359.html
.NET社區新聞，深度好文，歡迎訪問公眾號文章匯總 http://www.csharpkit.com
總結
以上是生活随笔為你收集整理的浅谈开发模式及架构发展的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： ASP.NET Core Web API
- 下一篇： Actor-ES框架：Ray-Handl