32可擴(kuò)展架構(gòu)的基本思想和模式

1、極客時(shí)間32 | 可擴(kuò)展架構(gòu)的基本思想和模式2018-07-10 32 | 可擴(kuò)展架構(gòu)的基本思想和模式- 00:05 / 09:25系統(tǒng)與硬件和 系統(tǒng)最大的差異在于 是可擴(kuò)展的，一個(gè)硬件生產(chǎn)出來后就 再進(jìn)行改變、一個(gè) 完工后也 再改變其整體結(jié)構(gòu)。例如，一顆CPU生產(chǎn)出來后裝到一臺PC機(jī)上， 再返回工廠進(jìn)行 以增加新的功能；金字塔矗立千年歷經(jīng)風(fēng)吹雨打，但其現(xiàn)在的結(jié)構(gòu)和當(dāng)時(shí)建成完工時(shí)的結(jié)構(gòu)并無兩樣。相比之下， 系統(tǒng)就完全相反，如果一個(gè) 系統(tǒng)開發(fā)出來后，再也沒有任何更新和調(diào)整，反而說明了這套 系統(tǒng)沒有發(fā)展、沒有生命力。真正有生命力的 系統(tǒng)，都是在不斷迭代和發(fā)展的，典型的如Windows操作系統(tǒng)，從W

2、indows 3.0到Windows 95到Windows XP，直到現(xiàn)在的Windows 10，一直在跟著技術(shù)的發(fā)展而不斷地發(fā)展。我們進(jìn)入架構(gòu)可擴(kuò)展模式的學(xué)習(xí)，這部分內(nèi)容 分層架構(gòu)、SOA架構(gòu)、微服務(wù)和微內(nèi)核等，先來聊聊架構(gòu)的可擴(kuò)展模式。系統(tǒng)的這種天生和內(nèi)在的可擴(kuò)展的特性，既是魅力所在，又是難點(diǎn)所在。魅力體現(xiàn)在我們可以通過修改和擴(kuò)展，不斷地讓 系統(tǒng)具備 的功能和特性，滿足新的需求或者順應(yīng)技術(shù)發(fā)展的趨勢。而難點(diǎn)體現(xiàn)在如何以最小的代價(jià)去擴(kuò)展系統(tǒng)，因?yàn)楹芏嗲闆r下牽一發(fā)動全身，擴(kuò)展時(shí)可能出現(xiàn)到處都要改，到處都要推倒重來的情況。這樣做的風(fēng)險(xiǎn)不言而喻： 改動的地方越多，投入也越大，出錯(cuò)的可能性也越大。因

3、此，如何避免擴(kuò)展時(shí)改動范圍太大，是 架構(gòu)可擴(kuò)展性設(shè)計(jì)的主要思考點(diǎn)?？蓴U(kuò)展的基本思想幸運(yùn)的是，可擴(kuò)展性架構(gòu)的設(shè)計(jì) 很多，但萬變不離其宗，所有的可擴(kuò)展性架構(gòu)設(shè)計(jì)，背后的基本思想都可以總結(jié)為一個(gè)字：拆！拆，就是將原本 的系統(tǒng)拆分成多個(gè)規(guī)模小的部分，擴(kuò)展時(shí)只修改其中一部分即可，無須整個(gè)系統(tǒng)到處都改，通過這種方式來減少改動范圍，降低改動風(fēng)險(xiǎn)。說起來好像挺簡單，畢竟“拆”我們見得太多了。 情況下，我們要拆一個(gè)東西時(shí)，都是簡單 的。例如，用推土機(jī)拆房子、用剪刀拆快遞包裝、用手撕開包裝袋等，反正拆完了這些東西就扔了。但面對 系統(tǒng)，拆就沒那么簡單了，因?yàn)槲覀儾⒉皇且輾б粋€(gè) 系統(tǒng)，而是要通過拆讓 系統(tǒng)變得更 （

4、具備更 可擴(kuò)展性）。形象地說， 系統(tǒng)中的“拆”是建設(shè)性的，因此難度要 。按照不同的思路來拆分 系統(tǒng)，就會得到不同的架構(gòu)。常見的拆分思路有如下三種。面向流程拆分：將整個(gè)業(yè)務(wù)流程拆分為幾個(gè)階段，每個(gè)階段作為一部分。面向服務(wù)拆分：將系統(tǒng)提供的服務(wù)拆分，每個(gè)服務(wù)作為一部分。面向功能拆分：將系統(tǒng)提供的功能拆分，每個(gè)功能作為一部分。理解這三種思路的關(guān)鍵就在于如何理解“流程”“服務(wù)”“功能”三者的 和區(qū)別。從范圍上來看，從大到小依次為：流程>服務(wù)>功能，單純從概念解釋可能難以理解，但實(shí)際上看幾個(gè)案例就很清楚了。我以TCP/IP協(xié)議棧為例，來說明“流程”“服務(wù)”“功能”的區(qū)別和 。TCP/IP協(xié)議

5、棧和模型圖如下圖所示。流程對應(yīng)TCP/IP四層模型，因?yàn)門CP/IP網(wǎng)絡(luò)通信流程是：應(yīng)用層 傳輸層 網(wǎng)絡(luò)層 物理+數(shù)據(jù)鏈路層，不管最上層的應(yīng)用層是什么，這個(gè)流程都 變。hongfenghuoju/106882018/8/6 9:45:41服務(wù)對應(yīng)應(yīng)用層的HTTP、FTP、SMTP等服務(wù)，HTTP提供Web服務(wù)，F(xiàn)TP提供文件服務(wù)，SMTP提供郵件服務(wù)，以此類推。功能每個(gè)服務(wù)都會提供相應(yīng)的功能。例如，HTTP服務(wù)提供GET、POST功能，F(xiàn)TP提供上傳 功能，SMTP提供郵件發(fā)送和收取功能。我再以一個(gè)簡單的學(xué)生 為例（幾乎每個(gè)技術(shù) 讀書時(shí)都做過這樣一個(gè)系統(tǒng)），拆分方式是：1. 面向流程拆分展示層

6、 業(yè)務(wù)層 數(shù)據(jù)層 層，各層含義是：展示層：負(fù)責(zé)用戶頁面設(shè)計(jì)，不同業(yè)務(wù)有不同的頁面。例如，登錄頁面、 頁面、 管理頁面、安全設(shè)置頁面等。業(yè)務(wù)層：負(fù)責(zé)具體業(yè)務(wù)邏輯的處理。例如，登錄、 、 管理、修改 等業(yè)務(wù)。數(shù)據(jù)層：負(fù)責(zé)完成數(shù)據(jù) 。例如，增刪改查數(shù)據(jù)庫中的數(shù)據(jù)、 到日志文件等。層：負(fù)責(zé)數(shù)據(jù)的 。例如， 型數(shù)據(jù)庫MySQL、緩存系統(tǒng)Memcache等。最終的架構(gòu)如下：2. 面向服務(wù)拆分將系統(tǒng)拆分為 、登錄、 管理、安全設(shè)置等服務(wù)，最終架構(gòu)示意圖如下：3. 面向功能拆分每個(gè)服務(wù)都可以拆分為 細(xì)粒度的功能，例如：服務(wù)：提供多種方式進(jìn)行 ， 號 、 、學(xué)生郵箱 三個(gè)功能。登錄服務(wù)： 號登錄、 登錄、郵箱登

7、錄三個(gè)功能。管理服務(wù)： 基本 管理、課程 管理、成績 管理等功能。安全設(shè)置服務(wù)： 修改 、安全 、找回 等功能。最終架構(gòu)圖如下：通過學(xué)生 的案例可以發(fā)現(xiàn)，不同的拆分方式，架構(gòu)圖差異很大。但好像無論哪種方式，最終都是可以實(shí)現(xiàn)的。既然如此，我們何必費(fèi)盡心機(jī)去選擇呢，隨便挑選一個(gè)不就可以了？當(dāng)然不能隨便挑，否則架構(gòu)設(shè)計(jì)就沒有意義了，架構(gòu)師也就要丟掉飯碗了。 在于：不同的拆分方式，本質(zhì)上決定了系統(tǒng)的擴(kuò)展方式?？蓴U(kuò)展方式當(dāng)我們談可擴(kuò)展性時(shí)，很多同學(xué)都會有一個(gè)疑惑：就算是不拆 ，只要在設(shè)計(jì)和寫代碼時(shí)做好了，同樣 出現(xiàn)到處改的問題??？例如，在面向服務(wù)拆分的案例中，增加“學(xué)號注冊”，就算是不拆分為服務(wù)，也可以

8、 修改的范圍，那為何我們要大費(fèi)周章地去拆 呢？在一個(gè)理想的環(huán)境，你的團(tuán)隊(duì)都是高手，每個(gè)程序員都很厲害，對業(yè)務(wù)都很熟悉，新來的同事很快就知曉所有的細(xì)節(jié)那確實(shí)不拆分也沒有問題。但現(xiàn)實(shí)卻是：團(tuán)隊(duì)有菜鳥程序 員，到底是改A處實(shí)現(xiàn)功能還是改B處實(shí)現(xiàn)功能，完全取決于他覺得哪里容易改；有的程序員比較粗心；有的程序員某天精神狀態(tài)不太好；新來的同事不知道歷史上某行代碼為何那么“惡心”，而輕易地將其改漂亮了一些所有的這些問題都可能出現(xiàn)，這時(shí)候你就會發(fā)現(xiàn)，合理的拆分，能夠強(qiáng)制保證即使程序員出錯(cuò)，出錯(cuò)的范圍也 太廣，影響也 太大。下面是不同拆分方式應(yīng)對擴(kuò)展時(shí)的優(yōu)勢。1. 面向流程拆分?jǐn)U展時(shí)大部分情況只需要修改某一層，

9、少部分情況可能修改關(guān)聯(lián)的兩層， 出現(xiàn)所有層都同時(shí)要修改。例如學(xué)生 ，如果 層從MySQL擴(kuò)展為同時(shí)支持MySQL和Oracle，那么只需要擴(kuò)展 層和數(shù)據(jù)層即可，展示層和業(yè)務(wù)層無須變動。2. 面向服務(wù)拆分對某個(gè)服務(wù)擴(kuò)展，或者要增加新的服務(wù)時(shí)，只需要擴(kuò)展相關(guān)服務(wù)即可，無須修改所有的服務(wù)。同樣以學(xué)生 為例，如果我們需要在 服務(wù)中增加一種“學(xué)號 ”功能，則只需要修改“ 服務(wù)”和“登錄服務(wù)”即可，“ 管理服務(wù)”和“安全設(shè)置”服務(wù)無須修改。3. 面向功能拆分對某個(gè)功能擴(kuò)展，或者要增加新的功能時(shí)，只需要擴(kuò)展相關(guān)功能即可，無須修改所有的服務(wù)。同樣以學(xué)生 為例，如果我們增加“學(xué)號 ”功能，則只需要在系統(tǒng)中增加一

10、個(gè)新的功能模塊，同時(shí)修改“登錄功能”模塊即可，其他功能都不受影響。不同的拆分方式，將得到不同的系統(tǒng)架構(gòu)，典型的可擴(kuò)展系統(tǒng)架構(gòu)有： 面向流程拆分：分層架構(gòu)。面向服務(wù)拆分：SOA、微服務(wù)。面向功能拆分：微內(nèi)核架構(gòu)。當(dāng)然，這幾個(gè)系統(tǒng)架構(gòu)并不是非此即彼的，而是可以在系統(tǒng)架構(gòu)設(shè)計(jì)中進(jìn)行組合使用的。以學(xué)生 為例，我們最終可以這樣設(shè)計(jì)架構(gòu)：整體系統(tǒng)采用面向服務(wù)拆分中的“微服務(wù)”架構(gòu)，拆分為“ 服務(wù)”“登錄服務(wù)”“ 管理服務(wù)”“安全服務(wù)”，每個(gè)服務(wù)是一個(gè) 運(yùn)行的子系統(tǒng)。其中的“ 服務(wù)”子系統(tǒng)本身又是采用面向流程拆分的分層架構(gòu)?！暗卿浄?wù)”子系統(tǒng)采用的是面向功能拆分的“微內(nèi)核”架構(gòu)。專欄后面的內(nèi)容我將詳細(xì)闡述每

11、種可擴(kuò)展架構(gòu)。小結(jié)我為你講了可擴(kuò)展架構(gòu)的一些基本思想和方式，希望對你有所幫助。這就是 的全部內(nèi)容，留一道思考題給你吧，規(guī)則引擎是常用的一種支持可擴(kuò)展的方式，按照 的分析，它屬于哪一類？歡迎你把 寫到留言區(qū)，和我一起討論。相信經(jīng)過深度思考的回答，也會讓你對更加深刻。（編輯亂入：精彩的留言有機(jī)會獲得豐厚福利哦?。Z米豆發(fā)面向流程、面向服務(wù)、面向功能，這三個(gè) 名，面向服務(wù)和面向功能還可以，面向流程這個(gè)容易讓人誤解。 面向流程，大概指的是數(shù)據(jù)移動的流程，而不是業(yè)務(wù)流程。分層架構(gòu)的本質(zhì)，就是固定的內(nèi)核，移動的數(shù)據(jù)。 規(guī)則引擎的擴(kuò)展方式，可以用下排除法。首先，肯定不是分層架構(gòu)，即不是面向流程的，因?yàn)橐?guī)則引

12、擎主要作用在業(yè)務(wù)層。 其次，也不應(yīng)該是面向服務(wù)的，因?yàn)橐?guī)則引擎都是 多個(gè)服務(wù)的。規(guī)則引擎和插件式架構(gòu)，解決的都是功能擴(kuò)展的問題。微內(nèi)核架構(gòu)就是一種插件式架構(gòu)。 所以，規(guī)則引擎應(yīng)該是面向功能的擴(kuò)展方式。作者回復(fù)思路很清晰，贊，面向流程這個(gè)說法確實(shí)不那么容易理解，但你對照TCP/IP那個(gè)圖就很清晰了正是那朵玫瑰2018-07-102018-07-112018-07-10規(guī)則引擎是嵌入應(yīng)用程序的一種組件，我們也一直想引入來解決復(fù)雜多變的規(guī)則變化，而規(guī)則應(yīng)屬某項(xiàng)功能，比如我們在p2p行業(yè)，想篩選出 用戶，可能會有很多的條件限制，如投資額達(dá)到多少，投資的頻率等等，而這些條件又會經(jīng)常變化，于是用規(guī)則引擎

13、出來，從這個(gè)角度看規(guī)則引擎應(yīng)該是面向功能拆分（篩選 用戶是屬于一項(xiàng)功能）。不過我覺得規(guī)則引擎還可以編排流程，比 A，B，C，D四個(gè)流程，1、當(dāng)滿足條件1時(shí)走A->B->C->D2、滿足條件2時(shí)走A->B->D3、滿足條件2時(shí)走A->B->C從這個(gè)角度來說是不是也可以認(rèn)為是面向流程拆分，不知道理解是否正確？作者回復(fù)極客時(shí)間2018-07-11文章中的流程概念范圍要大很多，可以認(rèn)為流程和條件無關(guān)feifei2018-07-10規(guī)則引擎由推理引擎發(fā)展而來，是一種嵌入在應(yīng)用程序中的組件，實(shí)現(xiàn)了將業(yè)務(wù)決策從應(yīng)用程序代碼中分離出來，并使用預(yù)定義的語義模塊編寫業(yè)務(wù)決

14、策。接受數(shù)據(jù)輸入，解釋業(yè)務(wù)規(guī)則，并根 據(jù)業(yè)務(wù)規(guī)則做出業(yè)務(wù)決策。規(guī)則引擎是將業(yè)務(wù)決策與業(yè)務(wù)分離，它提供的還是決策功能，我覺得是面向功能，我沒使用規(guī)則引擎的經(jīng)驗(yàn)！不知道這樣理解是否 問題？hongfenghuoju/106882018/8/6 9:45:41作者回復(fù)理解正確滄海一粟2018-07-11面向服務(wù)的拆分成 的子系統(tǒng)，如文中所講的學(xué)生，拆分為 服務(wù)，登錄服務(wù)，請問 ，這些子系統(tǒng)是 鏈接數(shù)據(jù)庫的嗎？實(shí)際項(xiàng)目都是怎么做的？2018-07-10作者回復(fù)2018-07-11每個(gè)服務(wù)是 的子系統(tǒng)，有各自 的數(shù)據(jù)庫，緩存，服務(wù)器但莫規(guī)則引擎可能是面向流程和面向功能兩種拆分方式相結(jié)合。流程規(guī)劃每一層的

15、職責(zé)，并規(guī)劃好處理流程，在每一層可按功能模塊進(jìn)行拆分和管理，更容易添加新的規(guī)則。如果系統(tǒng)做的更大一些可能還會引入soa。把沒一層或每一層中的模塊拆分成單獨(dú)的服務(wù)。narry感覺規(guī)則引擎是面向流程的拆分，將規(guī)則的生命周期拆分成了:設(shè)計(jì)和執(zhí)行兩步作者回復(fù)2018-07-102018-07-102018-07-11規(guī)則引擎最終還是要完 能的呀，不是把規(guī)則拆分為設(shè)計(jì)和執(zhí)行Will面向流程是否可以這樣理解，比如電商 下單的流程。登陸、瀏覽商品、加入購物車、結(jié)算、下單、支付、收貨、評價(jià)等。拆完就是用戶服務(wù)、商品服務(wù)、訂單服務(wù)、評價(jià)服務(wù)等。 這么贊的所有章節(jié)！作者回復(fù)是的，這就是面向流程拆分，同樣是這個(gè)電商

16、案例，如果按照男裝，女裝，電器拆分，就是面向服務(wù)拆分云學(xué)可擴(kuò)展架構(gòu)的基本思想就是拆！Tom面向服務(wù)拆分的具體表現(xiàn)形式是每個(gè)服務(wù)部署為一個(gè)子系統(tǒng)，面向功能拆分的具體表現(xiàn)形式是怎樣的呢，新功能一個(gè)dll？作者回復(fù)微內(nèi)核，規(guī)則引擎2018-07-172018-07-172018-07-172018-07-162018-07-16規(guī)則引擎應(yīng)該是面向流程的架構(gòu)作者回復(fù)我理解是面向功能的LB2018-07-162018-07-16請問服務(wù)、微服務(wù)、功能從拆分邊界上如何區(qū)分呢？。2018-07-12作者回復(fù)其實(shí)沒有明顯的界限，微服務(wù)章節(jié)會講2018-07-13規(guī)則引擎應(yīng)該用面向服務(wù)的方式進(jìn)行拆分，因?yàn)榘岩?guī)則

17、作為服務(wù)的方式，一來可以復(fù)用，二來方便對規(guī)則進(jìn)行擴(kuò)展，不知道 回答對不？2018-07-12作者回復(fù)規(guī)則引擎是面向功能拆分，后面會講東2018-07-132018-07-11面向服務(wù)和面向功能，這兩個(gè)概念感覺十分難以區(qū)分，某個(gè)功能也可以做成一個(gè)微服務(wù)，某個(gè)微服務(wù)也可以認(rèn)為是一個(gè)功能，求教二者的差別?？梢岳斫夥?wù)是一組相似功能的集合，例如用戶登錄是服務(wù)，這個(gè)服務(wù)支持 號登錄， 登錄，QQ登錄3個(gè)登錄功能，當(dāng)然，如果你真的需要把 號登錄做成一個(gè) 的服務(wù)也是可以的，不 絕對的界限作者回復(fù)彡工鳥看人看法，站在系統(tǒng)的角度，規(guī)則引擎應(yīng)該屬于服務(wù)拆分。而規(guī)則引擎內(nèi)部屬于功能拆分。作者回復(fù)2018-07-11

18、2018-07-102018-07-11規(guī)則引擎不太會 為服務(wù)summer極客時(shí)間規(guī)則引擎是面向功能拆分空檔滑行2018-07-102018-07-10hongfenghuoju/106882018/8/6 9:45:41感覺像是按功能拆分，一個(gè)模塊可能之前只支持一兩個(gè)規(guī)則，在有新的功能要加進(jìn)來時(shí)可以只添加具體功能的實(shí)現(xiàn)，嵌入到原來的流程中。比如我們之前做的積 ，各種活動獲取積分時(shí)翻倍，新的活動規(guī)則都是用插件的方式添加的，不知道這個(gè)算不算。作者回復(fù)是的，功能拆分炫吉規(guī)則引擎的 是if（evalue） thenexecute這樣的流抽象，所以應(yīng)該屬于面向流程的架構(gòu)其中evalue和execute兩部分也可以繼續(xù)進(jìn)行架構(gòu)拆分作者回復(fù)面向流程的范圍要比if then要大的多，參考TCP/IP的案例炫吉規(guī)則引擎的 是if（evalue） thenexecut