單體架構(gòu)

單體架構(gòu)也稱之為單體系統(tǒng)或者是單體應(yīng)用茧跋。就是一種把系統(tǒng)中所有的功能瘾杭、模塊耦合在一個(gè)應(yīng)用中的架構(gòu)方式

單體架構(gòu)特點(diǎn)

1、打包成一個(gè)獨(dú)立的單元(導(dǎo)成一個(gè)唯一的 jar 包或者是 war 包)

MVC架構(gòu)银萍，就是典型的單體架構(gòu)

單體架構(gòu)的優(yōu)點(diǎn)、缺點(diǎn)

優(yōu)點(diǎn)

1飞袋、項(xiàng)目易于管理
2巧鸭、部署簡(jiǎn)單

缺點(diǎn)

1纲仍、測(cè)試成本高
2贸毕、可伸縮性差
3明棍、可靠性差
4、迭代困難
5沸版、跨語(yǔ)言程度差
6视粮、團(tuán)隊(duì)協(xié)作難

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

什么是微服務(wù)

微服務(wù)是一種架構(gòu)風(fēng)格橙凳。一個(gè)大型的復(fù)雜軟件應(yīng)用区宇，由一個(gè)或多個(gè)微服務(wù)組成议谷。系統(tǒng)中的各個(gè)微服務(wù)可被獨(dú)立部署堕虹，各個(gè)微服務(wù)之間是松耦合的。每個(gè)微服務(wù)僅關(guān)注于完成一件任務(wù)并很好的完成該任務(wù)

架構(gòu)風(fēng)格

項(xiàng)目的一種設(shè)計(jì)模式郁稍。

常見(jiàn)的架構(gòu)風(fēng)格

1耀怜、客戶端與服務(wù)端的
2财破、基于組件模型的架構(gòu)（EJB）
3左痢、分層架構(gòu)(MVC)
4俊性、面向服務(wù)架構(gòu)(SOA)

微服務(wù)特點(diǎn)：

1定页、系統(tǒng)是由多個(gè)服務(wù)構(gòu)成
2拯勉、每個(gè)服務(wù)可以單獨(dú)獨(dú)立部署
3宫峦、每個(gè)服務(wù)之間是松耦合的导绷。服務(wù)內(nèi)部是高內(nèi)聚的妥曲，外部是低耦合的檐盟。高內(nèi)聚就是每個(gè)服務(wù)只關(guān)注完成一個(gè)功能押桃。

微服務(wù)的優(yōu)點(diǎn)羡忘、缺點(diǎn)

優(yōu)點(diǎn)

1卷雕、測(cè)試容易
2漫雕、可伸縮性強(qiáng)
3九孩、可靠性強(qiáng)
4、跨語(yǔ)言程度會(huì)更加靈活
5梅惯、團(tuán)隊(duì)協(xié)作容易
6铣减、系統(tǒng)迭代容易

缺點(diǎn)

1葫哗、運(yùn)維成本過(guò)高，部署數(shù)量較多
2亿扁、接口兼容多版本
3从祝、分布式系統(tǒng)的復(fù)雜性
4擎浴、分布式事務(wù)

MVC毒涧、RPC、SOA萌狂、微服務(wù)架構(gòu)之間的區(qū)別

1 MVC 架構(gòu)

其實(shí) MVC 架構(gòu)就是一個(gè)單體架構(gòu)档玻。
代表技術(shù)：Struts2、SpringMVC茫藏、Spring误趴、Mybatis 等等。

2 RPC 架構(gòu)

RPC(Remote Procedure Call)：遠(yuǎn)程過(guò)程調(diào)用务傲。他一種通過(guò)網(wǎng)絡(luò)從遠(yuǎn)程計(jì)算機(jī)程序上請(qǐng)求服務(wù)凉当，而不需要了解底層網(wǎng)絡(luò)技術(shù)的協(xié)議。
代表技術(shù)：Thrift售葡、Hessian 等等

3 SOA 架構(gòu)

SOA(Service oriented Architecture):面向服務(wù)架構(gòu)
ESB(Enterparise Servce Bus):企業(yè)服務(wù)總線看杭，服務(wù)中介。主要是提供了一個(gè)服務(wù)于服務(wù)之間的交互。
ESB 包含的功能如：負(fù)載均衡谴供，流量控制永淌，加密處理答恶，服務(wù)的監(jiān)控，異常處理燕酷，監(jiān)控告急等等酱讶。
代表技術(shù)：Mule、WSO2

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

微服務(wù)就是一個(gè)輕量級(jí)的服務(wù)治理方案。
代表技術(shù)：SpringCloud、dubbo 等等

如何設(shè)計(jì)微服務(wù)以及設(shè)計(jì)原則

1. AKF 拆分原則
   業(yè)界對(duì)于可擴(kuò)展的系統(tǒng)架構(gòu)設(shè)計(jì)有一個(gè)樸素的理念,就是：
   通過(guò)加機(jī)器就可以解決容量和可用性問(wèn)題。(如果一臺(tái)不行那就兩臺(tái))沛简。
   

   這一理念在“云計(jì)算”概念瘋狂流行的今天牡肉，得到了廣泛的認(rèn)可！對(duì)于一個(gè)規(guī)模迅速增長(zhǎng)的系統(tǒng)而言煌寇，容量和性能問(wèn)題當(dāng)然是首當(dāng)其沖的。但是隨著時(shí)間的向前击纬，系統(tǒng)規(guī)模的增長(zhǎng)殃饿，除了面對(duì)性能與容量的問(wèn)題外，還需要面對(duì)功能與模塊數(shù)量上的增長(zhǎng)帶來(lái)的系統(tǒng)復(fù)雜性問(wèn)題以及業(yè)務(wù)的變化帶來(lái)的提供差異化服務(wù)問(wèn)題肴甸。而許多系統(tǒng)庶柿，在架構(gòu)設(shè)計(jì)時(shí)并未充分考慮到這些問(wèn)題审残，導(dǎo)致系統(tǒng)的重構(gòu)成為常態(tài)介时，從而影響業(yè)務(wù)交付能力，還浪費(fèi)人力財(cái)力迁酸！對(duì)此串远，《可擴(kuò)展的藝術(shù)》一書(shū)提出了一個(gè)更加系統(tǒng)的可擴(kuò)展模型—— AKF 可擴(kuò)展立方 （Scalability Cube）更胖。這個(gè)立方體中沿著三個(gè)坐標(biāo)軸設(shè)置分別為：X、Y哺窄、Z。
   AKF

服務(wù)化架構(gòu)(SOA)

Z 軸擴(kuò)展通常是指基于請(qǐng)求者或用戶獨(dú)特的需求，進(jìn)行系統(tǒng)劃分钳吟，并使得劃分出來(lái)的子系統(tǒng)是相互隔離但又是完整的廷粒。以生產(chǎn)汽車的工廠來(lái)舉例：福特公司為了發(fā)展在中國(guó)的業(yè)務(wù)，或者利用中國(guó)的廉價(jià)勞動(dòng)力，在中國(guó)建立一個(gè)完整的子工廠坝茎，與美國(guó)工廠一樣涤姊，負(fù)責(zé)完整的汽車生產(chǎn)。這就是一種 Z 軸擴(kuò)展嗤放。
工程領(lǐng)域常見(jiàn)的 Z 軸擴(kuò)展有以下兩種方案：

單元化架構(gòu)在分布式服務(wù)設(shè)計(jì)領(lǐng)域思喊，一個(gè)單元（Cell）就是滿足某個(gè)分區(qū)所有業(yè)務(wù)操作的自包含閉環(huán)。如上面我們說(shuō)到的 Y 軸擴(kuò)展的 SOA 架構(gòu)次酌，客戶端對(duì)服務(wù)端節(jié)點(diǎn)的選擇一般是隨機(jī)的恨课，但是，如果在此加上 Z 軸擴(kuò)展和措，那服務(wù)節(jié)點(diǎn)的選擇將不再是隨機(jī)的了庄呈，而是每個(gè)單元自成一體。如下

2. 前后端分離原則
   何為前后端分離橘原？前后端本來(lái)不就分離么籍铁？這要從尷尬的 jsp 講起。分工精細(xì)化從來(lái)都是蛋糕做大的原則趾断，多個(gè)領(lǐng)域工程師最好在不需要接觸其他領(lǐng)域知識(shí)的情況下合作拒名，才可能使效率越來(lái)越高，維護(hù)也會(huì)變得簡(jiǎn)單芋酌。jsp 的模板技術(shù)融合了 html 和 java 代碼增显，使得傳統(tǒng)MVC 開(kāi)發(fā)中的前后端在這里如膠似漆，前端做好頁(yè)面脐帝，后端轉(zhuǎn)成模板同云，發(fā)現(xiàn)問(wèn)題再找前端，前端又看不懂 java 代碼......前后端分離的目的就是將這尷尬局面打破堵腹。
   

   前后端分離原則炸站，簡(jiǎn)單來(lái)講就是前端和后端的代碼分離，我們推薦的模式是最好采用物理分離的方式部署疚顷，進(jìn)一步促使更徹底的分離旱易。如果繼續(xù)直接使用服務(wù)端模板技術(shù)，如：jsp，把 java咒唆、js、html释液、css 都堆到一個(gè)頁(yè)面里全释，稍微復(fù)雜一點(diǎn)的頁(yè)面就無(wú)法維護(hù)了。
   
   這種分離方式有幾個(gè)好處：
   2.1) 前后端技術(shù)分離误债，可以由各自的專家來(lái)對(duì)各自的領(lǐng)域進(jìn)行優(yōu)化浸船，這樣前段的用戶體驗(yàn)優(yōu)化效果更好。
   

   2.2) 分離模式下寝蹈，前后端交互界面更清晰李命，就剩下了接口模型，后端的接口簡(jiǎn)潔明了箫老，更容易維護(hù)封字。
   2.3) 前端多渠道集成場(chǎng)景更容易實(shí)現(xiàn)，后端服務(wù)無(wú)需變更耍鬓，采用統(tǒng)一的數(shù)據(jù)和模型阔籽，可以支持多個(gè)前端：例如：微信 h5 前端、PC 前端牲蜀、安卓前端笆制、IOS 前端。

3. 無(wú)狀態(tài)服務(wù)
   對(duì)于無(wú)狀態(tài)服務(wù)涣达，首先說(shuō)一下什么是狀態(tài)：如果一個(gè)數(shù)據(jù)需要被多個(gè)服務(wù)共享在辆，才能完成一筆交易，那么這個(gè)數(shù)據(jù)被稱為狀態(tài)度苔。進(jìn)而依賴這個(gè)“狀態(tài)”數(shù)據(jù)的服務(wù)被稱為有狀態(tài)服務(wù)匆篓，反之稱為無(wú)狀態(tài)服務(wù)。
   那么這個(gè)無(wú)狀態(tài)服務(wù)原則并不是說(shuō)在微服務(wù)架構(gòu)里就不允許存在狀態(tài)林螃，表達(dá)的真實(shí)意思是要把有狀態(tài)的業(yè)務(wù)服務(wù)改變?yōu)闊o(wú)狀態(tài)的計(jì)算類服務(wù)奕删，那么狀態(tài)數(shù)據(jù)也就相應(yīng)的遷移到對(duì)應(yīng)的“有狀態(tài)數(shù)據(jù)服務(wù)”中。
   

   場(chǎng)景說(shuō)明：例如我們以前在本地內(nèi)存中建立的數(shù)據(jù)緩存疗认、Session 緩存完残，到現(xiàn)在的微服務(wù)架構(gòu)中就應(yīng)該把這些數(shù)據(jù)遷移到分布式緩存中存儲(chǔ)，讓業(yè)務(wù)服務(wù)變成一個(gè)無(wú)狀態(tài)的計(jì)算節(jié)點(diǎn)横漏。遷移后谨设，就可以做到按需動(dòng)態(tài)伸縮，微服務(wù)應(yīng)用在運(yùn)行時(shí)動(dòng)態(tài)增刪節(jié)點(diǎn)缎浇，就不再需要考慮緩存數(shù)據(jù)如何同步的問(wèn)題

4. RestFul 的通信
   作為一個(gè)原則來(lái)講本來(lái)應(yīng)該是個(gè)“無(wú)狀態(tài)通信原則”扎拣，在這里我們直接推薦一個(gè)實(shí)踐優(yōu)選的 Restful 通信風(fēng)格 ，因?yàn)樗泻芏嗪锰帲?br> 4.1 無(wú)狀態(tài)協(xié)議 HTTP，具備先天優(yōu)勢(shì)二蓝，擴(kuò)展能力很強(qiáng)誉券。例如需要安全加密，有現(xiàn)成的成熟方案 HTTPS 即可刊愚。
   4.2 JSON 報(bào)文序列化踊跟，輕量簡(jiǎn)單，人與機(jī)器均可讀鸥诽，學(xué)習(xí)成本低商玫，搜索引擎友好
   

   4.3 語(yǔ)言無(wú)關(guān)，各大熱門語(yǔ)言都提供成熟的 Restful API 框架牡借，相對(duì)其他的一些RPC 框架生態(tài)更完