淺談開發模式及架構發展


一、傳統開發模式

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

    解析微服務架構(一)單塊架構系統以及其面臨的挑戰

    解析微服務架構(二)微服務架構綜述


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM