相關(guān)閱讀：

BAT等大廠(chǎng)十年研發(fā)經(jīng)歷，總結(jié)了12開(kāi)發(fā)條經(jīng)驗(yàn)（墻裂推薦）

10種常見(jiàn)的軟件架構(gòu)模式

一、傳統(tǒng)開(kāi)發(fā)模式

    傳統(tǒng)的開(kāi)發(fā)模式基本一般是重服務(wù)端的開(kāi)發(fā)方式，大部分工作都在服務(wù)端執(zhí)行，然后返回到客戶(hù)端（通常是HTML）。以Asp.net MVC為例，如下圖：

    #1 根據(jù)請(qǐng)求的路由定位到對(duì)應(yīng)的Controller的對(duì)應(yīng)的Action。

    #2 執(zhí)行相關(guān)邏輯，得到結(jié)果Model（也可能沒(méi)有Model，如直接返回View）。

    #3 定位并加載對(duì)應(yīng)的View（也可能沒(méi)有View，如返回TextResult，JsonResult等）。

    #4 在服務(wù)端通過(guò)Razor引擎把Model和View綁定起來(lái)生成最終的返回結(jié)果（一般是HTML），返回到客戶(hù)端。

    缺點(diǎn)：

    #1 職責(zé)不明確，要求工程師對(duì)前后端技術(shù)都要了解一點(diǎn)，有的甚至是后端工程師同時(shí)兼顧前后端。

    #2 隨著不同終端(Pad/Mobile/PC)的興起，對(duì)前端的要求越來(lái)越高，同時(shí)兼顧前后端的工程師開(kāi)始感到乏力。

    #3 前端工程師必須使用后端工程師的IDE，如Visual Studio。不用的話(huà)，又會(huì)產(chǎn)生集成的工作量。

    #4 應(yīng)用開(kāi)發(fā)流程繁瑣，如下圖：

二、前后端分離 - 大前端時(shí)代

     隨著傳統(tǒng)的開(kāi)發(fā)模式的缺點(diǎn)日益明顯，以及前端技術(shù)與框架的發(fā)展，逐漸形成了前后端分離的開(kāi)發(fā)模式。加上Html5，Css3，混合式開(kāi)發(fā)技術(shù)的發(fā)展，更是把前端開(kāi)發(fā)推向了一個(gè)百花齊放的大前端時(shí)代。前后端分離的交互大概如下圖所示：

    #1 服務(wù)端響應(yīng)請(qǐng)求返回結(jié)果（一般是json或xml）。

    #2 客戶(hù)端接受到返回結(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年開(kāi)始嘗試前后端分離，但當(dāng)時(shí)上述提到的框架還沒(méi)被發(fā)掘出來(lái)，只有一個(gè)雙向綁定的框架knockoutjs。因此，我當(dāng)時(shí)做了兩種嘗試：

    #1 純前后端分離：Asp.Net MVC（僅返回json） + html + knockoutjs + requirejs + ajax。

    #2 偽前后端分離：Asp.Net MVC（返回json以及無(wú)對(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 前端工程師可以按自己的喜好來(lái)選擇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)用開(kāi)發(fā)流程更簡(jiǎn)潔高效（可并行），如下圖：

    挑戰(zhàn)：

    #1 對(duì)ajax的使用要求更高，目前很多前端工程師沒(méi)有關(guān)注到這一點(diǎn)，如promise機(jī)制。

    #2 基于ajax的通訊經(jīng)常要解決跨域問(wèn)題。

三、微服務(wù)架構(gòu)

    以上兩種開(kāi)發(fā)模式都是單體架構(gòu)，它們能夠很好地應(yīng)對(duì)簡(jiǎn)單的業(yè)務(wù)系統(tǒng)。但是隨著業(yè)務(wù)的擴(kuò)張，功能的不斷增加，單體架構(gòu)面臨著越來(lái)越多的挑戰(zhàn)：

    #1 維護(hù)成本增加

         a. 團(tuán)隊(duì)越來(lái)越大，相應(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)或方案來(lái)解決所有問(wèn)題。

    #5 可伸縮性差

         a. 無(wú)法按需伸縮。

         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)、互相配合，為用戶(hù)提供最終價(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)境、類(lèi)生產(chǎn)環(huán)境等。

    #4 另外，應(yīng)當(dāng)盡量避免統(tǒng)一的、集中式的服務(wù)管理機(jī)制，對(duì)具體的一個(gè)服務(wù)而言，應(yīng)更具業(yè)務(wù)上下文，選擇合適的語(yǔ)言、工具對(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. 使用合適的語(yǔ)言或者工具

         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ù)的依賴(lài)管理

         a. 版本管理

         b. 服務(wù)依賴(lài)

         c. 服務(wù)治理  

    展望：

    后續(xù)有機(jī)會(huì)的話(huà)，我會(huì)寫(xiě)一系列關(guān)于.Net Core如何與Srping Cloud集成的文章。

    說(shuō)明：

    本文部分內(nèi)容來(lái)自王磊的《微服務(wù)架構(gòu)與實(shí)踐》和infoq發(fā)表的文章：

    解析微服務(wù)架構(gòu)（一）單塊架構(gòu)系統(tǒng)以及其面臨的挑戰(zhàn)

    解析微服務(wù)架構(gòu)（二）微服務(wù)架構(gòu)綜述

原文地址:http://www.cnblogs.com/Erik_Xu/p/6241359.html

看完本文有收獲？請(qǐng)轉(zhuǎn)發(fā)分享給更多人