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