一、傳統開發模式
傳統的開發模式基本一般是重服務端的開發方式,大部分工作都在服務端執行,然后返回到客戶端(通常是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發表的文章: