建站
咨詢
售后
建站咨詢
新聞中心
之前的一篇文章給大家介紹過(guò)了何為微服務(wù)：圖文詳解：如何給女朋友解釋什么是微服務(wù)?但是身為一名積極好學(xué)的前端女朋友還是會(huì)經(jīng)常問(wèn)我，微服務(wù)那么多理念，你跟我講完，我就忘了，可以再給我講講它的思想到底是啷個(gè)回事嘛～看在她這么刻苦奮進(jìn)的情況下，加之我們公司也做了許多微服務(wù)的項(xiàng)目，對(duì)此還算有所研究。今天就繼續(xù)為大家?guī)?lái)深層次的關(guān)于微服務(wù)架構(gòu)的講解：
成都創(chuàng)新互聯(lián)公司專注于龍州企業(yè)網(wǎng)站建設(shè),自適應(yīng)網(wǎng)站建設(shè),成都商城網(wǎng)站開(kāi)發(fā)。龍州網(wǎng)站建設(shè)公司,為龍州等地區(qū)提供建站服務(wù)。全流程按需定制開(kāi)發(fā)，專業(yè)設(shè)計(jì)，全程項(xiàng)目跟蹤，成都創(chuàng)新互聯(lián)公司專業(yè)和態(tài)度為您提供的服務(wù)
在學(xué)習(xí)微服務(wù)之前，我們先來(lái)回顧下單體架構(gòu)的模式。
單體架構(gòu)
概念
單體架構(gòu)也稱之為單體系統(tǒng)或者是單體應(yīng)用。就是一種把系統(tǒng)中所有的功能、模塊耦合在一個(gè)應(yīng)用中的架構(gòu)方式。
特點(diǎn)
單體架構(gòu)的特點(diǎn)主要有：
1. 打包成一個(gè)獨(dú)立的單元(導(dǎo)成一個(gè)唯一的jar包或者是war包)
2. 以一個(gè)進(jìn)程的方式來(lái)運(yùn)行
單體架構(gòu)
優(yōu)點(diǎn)
- 易于開(kāi)發(fā)： 開(kāi)發(fā)方式簡(jiǎn)單，IDE 支持好，方便運(yùn)行和調(diào)試。
- 易于測(cè)試： 所有功能運(yùn)行在一個(gè)進(jìn)程中，一旦進(jìn)程啟動(dòng)，便可以進(jìn)行系統(tǒng)測(cè)試。
- 易于部署： 只需要將打好的一個(gè)軟件包發(fā)布到服務(wù)器即可。
- 易于水平伸縮： 只需要?jiǎng)?chuàng)建一個(gè)服務(wù)器節(jié)點(diǎn)，配置好運(yùn)行時(shí)環(huán)境，再將軟件包發(fā)布到新服務(wù)器節(jié)點(diǎn)即可運(yùn)行程序(當(dāng)然也需要采取分發(fā)策略保證請(qǐng)求能有效地分發(fā)到新節(jié)點(diǎn))。
缺點(diǎn)
維護(hù)成本大： 當(dāng)應(yīng)用程序的功能越來(lái)越多、團(tuán)隊(duì)越來(lái)越大時(shí)，溝通成本、管理成本顯著增加;當(dāng)出現(xiàn) bug 時(shí)，可能引起 bug 的原因組合越來(lái)越多，導(dǎo)致分析、定位和修復(fù)的成本增加;并且在對(duì)全局功能缺乏深度理解的情況下，容易在修復(fù) bug 時(shí)引入新的 bug。
- 持續(xù)交付周期長(zhǎng)： 構(gòu)建和部署時(shí)間會(huì)隨著功能的增多而增加，任何細(xì)微的修改都會(huì)觸發(fā)部署流水線。
- 新人培養(yǎng)周期長(zhǎng)： 新成員了解背景、熟悉業(yè)務(wù)和配置環(huán)境的時(shí)間越來(lái)越長(zhǎng)。
- 技術(shù)選型成本高： 單塊架構(gòu)傾向于采用統(tǒng)一的技術(shù)平臺(tái)或方案來(lái)解決所有問(wèn)題，如果后續(xù)想引入新的技術(shù)或框架，成本和風(fēng)險(xiǎn)都很大。
- 可擴(kuò)展性差： 隨著功能的增加，垂直擴(kuò)展的成本將會(huì)越來(lái)越大;而對(duì)于水平擴(kuò)展而言，因?yàn)樗写a都運(yùn)行在同一個(gè)進(jìn)程，沒(méi)辦法做到針對(duì)應(yīng)用程序的部分功能做獨(dú)立的擴(kuò)展
采用過(guò)時(shí)的單體架構(gòu)的話，就會(huì)使得公司雇傭有潛力的開(kāi)發(fā)者很困難，應(yīng)用無(wú)法擴(kuò)展，可靠性很低，那么我們?cè)賮?lái)看看微服務(wù)架構(gòu)是怎樣的呢?
微服務(wù)架構(gòu)
概念
微服務(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)核心
核心部分
- 網(wǎng)關(guān)集群：數(shù)據(jù)的聚合、實(shí)現(xiàn)對(duì)接入客戶端的身份認(rèn)證、防報(bào)文重放與防數(shù)據(jù)篡改、功能調(diào)用的業(yè)務(wù)鑒權(quán)、響應(yīng)數(shù)據(jù)的脫敏、流量與并發(fā)控制等。
- 業(yè)務(wù)集群：一般情況下移動(dòng)端訪問(wèn)和瀏覽器訪問(wèn)的網(wǎng)關(guān)需要隔離，防止業(yè)務(wù)耦合。
- Local Cache：由于客戶端訪問(wèn)業(yè)務(wù)可能需要調(diào)用多個(gè)服務(wù)聚合，所以本地緩存有效的降低了服務(wù)調(diào)用的頻次，同時(shí)也提示了訪問(wèn)速度。本地緩存一般使用自動(dòng)過(guò)期方式，業(yè)務(wù)場(chǎng)景中允許有一定的數(shù)據(jù)延時(shí)。
- 服務(wù)層：原子服務(wù)層，實(shí)現(xiàn)基礎(chǔ)的增刪改查功能，如果需要依賴其他服務(wù)需要在 Service 層主動(dòng)調(diào)用。
- Remote Cache：訪問(wèn) DB 前置一層分布式緩存，減少 DB 交互次數(shù)，提升系統(tǒng)的TPS。
- DAL：數(shù)據(jù)訪問(wèn)層，如果單表數(shù)據(jù)量過(guò)大則需要通過(guò) DAL 層做數(shù)據(jù)的分庫(kù)分表處理。
- MQ：消息隊(duì)列用來(lái)解耦服務(wù)之間的依賴，異步調(diào)用可以通過(guò) MQ 的方式來(lái)執(zhí)行。
- 數(shù)據(jù)庫(kù)主從：服務(wù)化過(guò)程中必經(jīng)的階段，用來(lái)提升系統(tǒng)的 TPS
架構(gòu)
常見(jiàn)的架構(gòu)有：
1. 客戶端與服務(wù)端的
2. 基于組件模型的架構(gòu)(EJB)
3. 分層架構(gòu)(MVC)
4. 面向服務(wù)架構(gòu)(SOA)
特點(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è)功能。
優(yōu)點(diǎn)
- 邊界清晰：比如說(shuō)一個(gè)電商平臺(tái)，我們以前是部署在一臺(tái)服務(wù)器上，所有的代碼打成一個(gè)war包?，F(xiàn)在，我們可以給它拆分開(kāi)：用戶服務(wù)，積分服務(wù)，支付服務(wù)，倉(cāng)儲(chǔ)服務(wù)，信息服務(wù)，地圖服務(wù)等等，每一個(gè)微服務(wù)只關(guān)注一個(gè)特定的業(yè)務(wù)功能，這樣的話開(kāi)發(fā)和維護(hù)單個(gè)服務(wù)都比較簡(jiǎn)單，因?yàn)樗倪吔缱銐蚯逦?，業(yè)務(wù)也足夠清晰，用戶服務(wù)，只做好用戶的事情就好了，相較于之前的大而全的單體服而言，每個(gè)微服務(wù)的代碼量也比較少。
- 效率高：?jiǎn)误w服務(wù)隨著代碼量變得越來(lái)越多，比如說(shuō)百萬(wàn)行級(jí)別的代碼，僅僅編譯一次應(yīng)用可能就需要花費(fèi)很久，但是現(xiàn)在，如果一個(gè)地方有問(wèn)題，比如說(shuō)支付模塊有問(wèn)題，只需要單獨(dú)修改支付模塊，修改完支付模塊之后，單獨(dú)測(cè)試支付功能，單獨(dú)部署支付模塊就可以了，而不會(huì)影響整體的部署速度。
- 技術(shù)棧不受限制：每一個(gè)服務(wù)可以使用不同的技術(shù)棧來(lái)實(shí)現(xiàn)，由于不同的服務(wù)之間是通過(guò)restful API來(lái)通信的，所以每個(gè)服務(wù)可以使用不同的技術(shù)框架，使用不同的存儲(chǔ)庫(kù)來(lái)實(shí)現(xiàn);
- 拓展性更強(qiáng)：隨著業(yè)務(wù)的發(fā)展，用戶量變得越來(lái)越多，或者說(shuō)訂單量猛增，這時(shí)我們可以專門去優(yōu)化這個(gè)訂單服務(wù)，給這個(gè)訂單服務(wù)提供更高配置的機(jī)器，而其他并沒(méi)有遇到瓶頸的業(yè)務(wù)，比如說(shuō)短信服務(wù)，我們可以暫時(shí)不用動(dòng)。
缺點(diǎn)
- 運(yùn)維成本過(guò)高：以前只需要打個(gè) war 包扔在 tomcat 下面就可以了，但現(xiàn)在，我們可能需要部署幾個(gè)甚至幾十個(gè)微服務(wù)，這樣的話，如何保證這幾十甚至上百個(gè)微服務(wù)正常的運(yùn)行和互相通信協(xié)作，這給運(yùn)維帶來(lái)了很大的挑戰(zhàn);
- 分布式系統(tǒng)復(fù)雜：使用微服務(wù)這種架構(gòu)，構(gòu)建的是一個(gè)分布式的系統(tǒng)，在分布式系統(tǒng)當(dāng)中會(huì)引入很多問(wèn)題，比如說(shuō)分布式鎖，分布式事務(wù)等等，這個(gè)時(shí)候我們需要對(duì)這個(gè)系統(tǒng)的，事務(wù)，冪等，網(wǎng)絡(luò)延遲，分區(qū)，熔斷，降級(jí)等問(wèn)題都要有一個(gè)妥善的處理和應(yīng)對(duì)方案;
- 通信成本高：由于之前的接口調(diào)用都在同一個(gè)進(jìn)程內(nèi)，我需要支付調(diào)用支付方法，需要積分直接調(diào)用添加積分的方法，但現(xiàn)在，由于積分模塊或者支付模塊都被拆成了單獨(dú)的服務(wù)，這個(gè)時(shí)候如果再想去調(diào)用的話，就是通過(guò)http方式的請(qǐng)求去調(diào)用，這種頻繁的跨服務(wù)通信是有很高的成本的，選擇一個(gè)適合自己業(yè)務(wù)的輕量級(jí)低成本的通信方式，也很關(guān)鍵。
- 服務(wù)拆分難：如何做好微服務(wù)的拆分?這個(gè)是需要我們不斷摸索的，從單體服務(wù)向微服務(wù)架構(gòu)的演進(jìn)，它是一個(gè)循序漸進(jìn)的過(guò)程，在演進(jìn)的過(guò)程中常常會(huì)根據(jù)業(yè)務(wù)變化來(lái)對(duì)微服務(wù)進(jìn)行重構(gòu)，甚至是重新劃分，從而讓這個(gè)架構(gòu)更加合理。
架構(gòu)區(qū)別
MVC架構(gòu)
MVC 架構(gòu)就是一個(gè)單體架構(gòu)。我們常使用的技術(shù)：Struts2、SpringMVC、Spring、Mybatis等等。
RPC 架構(gòu)
RPC(RemoteProcedureCall)：遠(yuǎn)程過(guò)程調(diào)用。他一種通過(guò)網(wǎng)絡(luò)從遠(yuǎn)程計(jì)算機(jī)程序上請(qǐng)求服務(wù)，而不需要了解底層網(wǎng)絡(luò)技術(shù)的協(xié)議。我們常使用的技術(shù)：Thrift、Hessian等等
實(shí)現(xiàn)原理：首先需要有處理網(wǎng)絡(luò)連接通訊的模塊，負(fù)責(zé)連接建立、管理和消息的傳輸。其次需要有編解碼的模塊，因?yàn)榫W(wǎng)絡(luò)通訊都是傳輸?shù)淖止?jié)碼，需要將我們使用的對(duì)象序列化和反序列化。剩下的就是客戶端和服務(wù)器端的部分，服務(wù)器端暴露要開(kāi)放的服務(wù)接口，客戶調(diào)用服務(wù)接口的一個(gè)代理實(shí)現(xiàn)，這個(gè)代理實(shí)現(xiàn)負(fù)責(zé)收集數(shù)據(jù)、編碼并傳輸給服務(wù)器然后等待結(jié)果返回。
SOA 架構(gòu)
SOA(ServiceorientedArchitecture):面向服務(wù)架構(gòu)
ESB(EnterpariseServceBus):企業(yè)服務(wù)總線，服務(wù)中介。主要是提供了一個(gè)服務(wù)于服務(wù)之間的交互。ESB 包含的功能如：負(fù)載均衡，流量控制，加密處理，服務(wù)的監(jiān)控，異常處理，監(jiān)控告急等等。我們常使用的技術(shù)：Mule、WSO2
微服務(wù)架構(gòu)
微服務(wù)就是一個(gè)輕量級(jí)的服務(wù)治理方案。我們常使用的技術(shù)：SpringCloud、dubbo等等。
架構(gòu)區(qū)別
微服務(wù)原則
AKF拆分原則
業(yè)界對(duì)于可擴(kuò)展的系統(tǒng)架構(gòu)設(shè)計(jì)有一個(gè)樸素的理念,就是：通過(guò)加機(jī)器就可以解決容量和可用性問(wèn)題。
這一理念在“云計(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ù)》一書提出了一個(gè)更加系統(tǒng)的可擴(kuò)展模型——AKF 可擴(kuò)展立方(ScalabilityCube)。這個(gè)立方體中沿著三個(gè)坐標(biāo)軸設(shè)置分別為：X、Y、Z。
Y 軸(功能)——關(guān)注應(yīng)用中功能劃分，基于不同的業(yè)務(wù)拆分
Y 軸擴(kuò)展會(huì)將龐大的整體應(yīng)用拆分為多個(gè)服務(wù)。每個(gè)服務(wù)實(shí)現(xiàn)一組相關(guān)的功能，如訂單管理、客戶管理等。在工程上常見(jiàn)的方案是服務(wù)化架構(gòu)(SOA)。比如對(duì)于一個(gè)電子商務(wù)平臺(tái)，我們可以拆分成不同的服務(wù)，組成下面這樣的架構(gòu)：
服務(wù)化架構(gòu) SOA
但通過(guò)觀察上圖容易發(fā)現(xiàn)，當(dāng)服務(wù)數(shù)量增多時(shí)，服務(wù)調(diào)用關(guān)系變得復(fù)雜。為系統(tǒng)添加一個(gè)新功能，要調(diào)用的服務(wù)數(shù)也變得不可控，由此引發(fā)了服務(wù)管理上的混亂。所以，一般情況下，需要采用服務(wù)注冊(cè)的機(jī)制形成服務(wù)網(wǎng)關(guān)來(lái)進(jìn)行服務(wù)治理。系統(tǒng)的架構(gòu)將變成下圖所示：
服務(wù)網(wǎng)關(guān)治理
X 軸(水平擴(kuò)展)——關(guān)注水平擴(kuò)展，也就是”加機(jī)器解決問(wèn)題”
X 軸擴(kuò)展與我們前面樸素理念是一致的，通過(guò)絕對(duì)平等地復(fù)制服務(wù)與數(shù)據(jù)，以解決容量和可用性的問(wèn)題。其實(shí)就是將微服務(wù)運(yùn)行多個(gè)實(shí)例，做集群加負(fù)載均衡的模式。為了提升單個(gè)服務(wù)的可用性和容量，對(duì)每一個(gè)服務(wù)進(jìn)行X軸擴(kuò)展劃分。
X 軸(水平擴(kuò)展)
Z 軸(數(shù)據(jù)分區(qū))——關(guān)注服務(wù)和數(shù)據(jù)的優(yōu)先級(jí)劃分，如按地域劃分
Z 軸擴(kuò)展通常是指基于請(qǐng)求者或用戶獨(dú)特的需求，進(jìn)行系統(tǒng)劃分，并使得劃分出來(lái)的子系統(tǒng)是相互隔離但又是完整的。工程領(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è)單元自成一體。如下圖：
PC 用戶
移動(dòng)端用戶
數(shù)據(jù)分區(qū)：為了性能數(shù)據(jù)安全上的考慮，我們將一個(gè)完整的數(shù)據(jù)集按一定的維度劃分出不同的子集。一個(gè)分區(qū)(Shard)，就是是整體數(shù)據(jù)集的一個(gè)子集。比如用尾號(hào)來(lái)劃分用戶，那同樣尾號(hào)的那部分用戶就可以認(rèn)為是一個(gè)分區(qū)。數(shù)據(jù)分區(qū)為一般包括以下幾種數(shù)據(jù)劃分的方式：
- 數(shù)據(jù)類型 如：業(yè)務(wù)類型
- 數(shù)據(jù)范圍 如：時(shí)間段，用戶ID
- 數(shù)據(jù)熱度 如：用戶活躍度，商品熱度
- 按讀寫分 如：商品描述，商品庫(kù)存
前后端分離原則
何為前后端分離?前后端本來(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è)好處：
1. 前后端技術(shù)分離，可以由各自的專家來(lái)對(duì)各自的領(lǐng)域進(jìn)行優(yōu)化，這樣前端的用戶體驗(yàn)優(yōu)化效果更好。
2. 分離模式下，前后端交互界面更清晰，就剩下了接口模型，后端的接口簡(jiǎn)潔明了，更容易維護(hù)。
3. 前端多渠道集成場(chǎng)景更容易實(shí)現(xiàn)，后端服務(wù)無(wú)需變更，采用統(tǒng)一的數(shù)據(jù)和模型，可以支持多個(gè)前端：例如：微信 h5 前端、PC 前端、安卓前端、IOS 前端
無(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ù)。
無(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)題。
RestFul 的通訊風(fēng)格
原則來(lái)講本來(lái)應(yīng)該是個(gè)“無(wú)狀態(tài)通信原則”
無(wú)狀態(tài)通信
在這里我們直接推薦一個(gè)實(shí)踐優(yōu)選的 Restful 通信風(fēng)格，因?yàn)樗泻芏嗪锰帲?/p>
1. 無(wú)狀態(tài)協(xié)議 HTTP，具備先天優(yōu)勢(shì)，擴(kuò)展能力很強(qiáng)。例如需要安全加密，有現(xiàn)成的成熟方案HTTPS即可。
2. JSON 報(bào)文序列化，輕量簡(jiǎn)單，人與機(jī)器均可讀，學(xué)習(xí)成本低，搜索引擎友好。
3. 語(yǔ)言無(wú)關(guān)，各大熱門語(yǔ)言都提供成熟的 RestfulAPI 框架，相對(duì)其他的一些 RPC 框架生態(tài)更完善。
通信
服務(wù)通信
WebService、WCF、WebAPI，以及 ASHX,ASPX。
- 主動(dòng)觸發(fā)
- 數(shù)據(jù)序列化傳遞
- 跨平臺(tái)。
- 跨語(yǔ)言
- Http 穿透防火墻。
進(jìn)程通信
- Net Remoting：Net 平臺(tái)督郵的，不支持跨平臺(tái)。
- gRPC：高性能、開(kāi)源和通用 RPC框架，面向服務(wù)端和移動(dòng)端，基于 HTTP/2 設(shè)計(jì)，推薦使用。
WebService
注冊(cè)中心 Eureka
注冊(cè)中心主要提供三個(gè)核心功能：
1. 服務(wù)注冊(cè)
服務(wù)提供者啟動(dòng)時(shí)，會(huì)通過(guò) Eureka Client 向 Eureka Server 注冊(cè)信息，Eureka Server 會(huì)存儲(chǔ)該服務(wù)的信息，Eureka Server 內(nèi)部有二層緩存機(jī)制來(lái)維護(hù)整個(gè)注冊(cè)表
2. 提供注冊(cè)表
服務(wù)消費(fèi)者在調(diào)用服務(wù)時(shí)，如果 Eureka Client 沒(méi)有緩存注冊(cè)表的話，會(huì)從 Eureka Server 獲取最新的注冊(cè)表
3. 同步狀態(tài)
Eureka Client 通過(guò)注冊(cè)、心跳機(jī)制和 Eureka Server 同步當(dāng)前客戶端的狀態(tài)。
Eureka 流程
網(wǎng)關(guān) Zuul
API 網(wǎng)關(guān)是一個(gè)更為智能的應(yīng)用服務(wù)器，它的存在就像是整個(gè)微服務(wù)架構(gòu)系統(tǒng)的門面，所有的外部客戶端訪問(wèn)都需要經(jīng)過(guò)它來(lái)進(jìn)行調(diào)度和過(guò)濾。除了需要實(shí)現(xiàn)請(qǐng)求路由，負(fù)載均衡及校驗(yàn)過(guò)濾等功能外還需要與服務(wù)治理框架的結(jié)合，請(qǐng)求轉(zhuǎn)發(fā)時(shí)的熔斷機(jī)制，服務(wù)的聚合等一系列高級(jí)功能。主要核心功能：
- 服務(wù)路由轉(zhuǎn)發(fā)
- 鑒權(quán)校驗(yàn)過(guò)濾
- 熔斷限制保護(hù)
網(wǎng)關(guān)
認(rèn)證&授權(quán)
現(xiàn)在的應(yīng)用開(kāi)發(fā)層出不窮，基于瀏覽器的網(wǎng)頁(yè)應(yīng)用，基于微信的公眾號(hào)、小程序，基于 IOS、Android 的 App，基于 Windows 系統(tǒng)的桌面應(yīng)用和 UWP 應(yīng)用等等，這么多種類的應(yīng)用，就給應(yīng)用的開(kāi)發(fā)帶來(lái)的挑戰(zhàn)，我們除了分別實(shí)現(xiàn)各個(gè)應(yīng)用外，我們還要考慮各個(gè)應(yīng)用之間的交互，通用模塊的提煉，其中身份的認(rèn)證和授權(quán)就是每個(gè)應(yīng)用必不可少的的一部分。而現(xiàn)在的互聯(lián)網(wǎng)，對(duì)于信息安全要求又十分苛刻，所以一套統(tǒng)一的身份認(rèn)證和授權(quán)就至關(guān)重要。
IdentityServer4 就是這樣一個(gè)框架，IdentityServer4 是為 ASP.NET CORE 量身定制的實(shí)現(xiàn)了 OpenId Connect 和 OAuth2.0 協(xié)議的認(rèn)證授權(quán)中間件。
IdentityServer4
分布式日志
一般我們需要進(jìn)行日志分析場(chǎng)景：直接在日志文件中 grep、awk 就可以獲得自己想要的信息。但在規(guī)模較大也就是日志量多而復(fù)雜的場(chǎng)景中，此方法效率低下，面臨問(wèn)題包括日志量太大如何歸檔、文本搜索太慢怎么辦、如何多維度查詢。需要集中化的日志管理，所有服務(wù)器上的日志收集匯總。常見(jiàn)解決思路是建立集中式日志收集系統(tǒng)，將所有節(jié)點(diǎn)上的日志統(tǒng)一收集，管理，訪問(wèn)。
大型系統(tǒng)通常都是一個(gè)分布式部署的架構(gòu)，不同的服務(wù)模塊部署在不同的服務(wù)器上，問(wèn)題出現(xiàn)時(shí)，大部分情況需要根據(jù)問(wèn)題暴露的關(guān)鍵信息，定位到具體的服務(wù)器和服務(wù)模塊，構(gòu)建一套集中式日志系統(tǒng)，可以提高定位問(wèn)題的效率。
Exceptionless 是一個(gè)開(kāi)源的實(shí)時(shí)的日志收集框架，它可以應(yīng)用在基于 ASP.NET，ASP.NET Core，Web Api，Web Forms，WPF，Console，MVC 等技術(shù)棧的應(yīng)用程序中，并且提供了 Rest 接口可以應(yīng)用在 Javascript，Node.js 中。它將日志收集變得簡(jiǎn)單易用并且不需要了解太多的相關(guān)技術(shù)細(xì)節(jié)及配置。在以前，我們做日志收集大多使用 Log4net，Nlog 等框架，在應(yīng)用程序變得復(fù)雜并且集群的時(shí)候，可能傳統(tǒng)的方式已經(jīng)不是很好的適用了，因?yàn)槭占鱾€(gè)日志并且分析他們將變得麻煩而且浪費(fèi)時(shí)間。
現(xiàn)在 Exceptionless 團(tuán)隊(duì)給我們提供了一個(gè)更好的框架來(lái)做這件事情，我認(rèn)為這是非常偉大并且有意義的，感謝他們。
ELK是三個(gè)開(kāi)源軟件的縮寫，分別為：Elasticsearch 、 Logstash 以及 Kibana , 它們都是開(kāi)源軟件。不過(guò)現(xiàn)在還新增了一個(gè) Beats，它是一個(gè)輕量級(jí)的日志收集處理工具(Agent)，Beats 占用資源少，適合于在各個(gè)服務(wù)器上搜集日志后傳輸給 Logstash，官方也推薦此工具，目前由于原本的 ELK Stack 成員中加入了 Beats 工具所以已改名為 Elastic Stack，推薦使用。
ELK
配置中心 ConfigSpring
Config 首推基于 git 的管理方式，提供了兩個(gè)管理維度，一個(gè)是 label(即 branch)，一個(gè)是 profile。主要核心功能：
- 業(yè)務(wù)配置
- 功能開(kāi)關(guān)
- 服務(wù)配置
Spring Config
異步隊(duì)列 MQMQ
大家都熟悉，現(xiàn)在主流的MQ有rabbitMQ，rocketMQ，kafka。想要了解更多關(guān)于 rabbitMQ 和 kafka 的知識(shí)可以在這兩篇文章里查看：
圖文詳解：阿里寵兒【小兔】RabbitMQ的養(yǎng)成攻略
圖文詳解：Kafka到底有哪些秘密讓我對(duì)它情有獨(dú)鐘呢?
核心功能：削峰填谷
流量削峰
容錯(cuò)限流 Hystrix
它設(shè)計(jì)用來(lái)當(dāng)分布式系統(tǒng)發(fā)生不可避免的異常的時(shí)候去隔離當(dāng)前服務(wù)和遠(yuǎn)程服務(wù)、系統(tǒng)、三方包的聯(lián)系，防止出現(xiàn)級(jí)聯(lián)失敗的情況，從而導(dǎo)致整個(gè)系統(tǒng)雪崩。主要核心功能：
- 失敗轉(zhuǎn)移和優(yōu)雅降級(jí)
- 實(shí)時(shí)監(jiān)控更改相關(guān)配置
- 基于線程和信號(hào)量的斷路器隔離
容錯(cuò)限流
負(fù)載均衡、服務(wù)調(diào)用
ribbon是一個(gè)負(fù)載均衡客戶端，可以很好的控制htt和tcp的一些行為。
Feign默認(rèn)集成了ribbon。ribbon主要功能是提供客戶端的軟件負(fù)載均衡算法。Ribbon就屬于進(jìn)程內(nèi)負(fù)載均衡，它只是一個(gè)類庫(kù)，集成于消費(fèi)方進(jìn)程，消費(fèi)方通過(guò)它來(lái)獲取到服務(wù)提供方的地址。主要核心功能：負(fù)載均衡
負(fù)載均衡
持續(xù)集成 Jenkins
在項(xiàng)目多的時(shí)候，重復(fù)操作極大的浪費(fèi)時(shí)間。如果遇到同一時(shí)間不同項(xiàng)目組打包項(xiàng)目，打包和部署服務(wù)器就要排隊(duì)使用，測(cè)試人員只能在等待中浪費(fèi)時(shí)間。為了解決這些問(wèn)題，選擇尋找合適的持續(xù)集成方案。來(lái)自動(dòng)化完成重復(fù)的步驟。jenkins 還包含了很多插件，比如代碼校驗(yàn)等等。是 CI/CD 的基本技術(shù)。核心功能：
- 拉取代碼
- 打包構(gòu)建
- 將資源送往目標(biāo)服務(wù)器
持續(xù)集成
分布式緩存 RedisRedis
是一款基于 ANSI C 語(yǔ)言編寫的，BSD 許可的，日志型 key-value 存儲(chǔ)組件，它的所有數(shù)據(jù)結(jié)構(gòu)都存在內(nèi)存中，可以用作緩存、數(shù)據(jù)庫(kù)和消息中間件。核心功能：
- 內(nèi)存數(shù)據(jù)庫(kù)
- 基于內(nèi)存數(shù)據(jù)庫(kù)的各種擴(kuò)展功能
分布式緩存 Redis
分布式事務(wù)
分布式事務(wù)的實(shí)現(xiàn)方式主要有：
- 2PC(two-phase commit protocol，強(qiáng)一致性，沒(méi)有可用性)
- 3PC
- TCC(Try-Confirm-Cancel)
- 本地消息表，推薦 RabbitMQ。
- Saga 模式
本地消息表：MQ分布式事務(wù)—本地消息表—基于消息的一致性。
- 上有投遞消息
- 下游獲取消息
- 上游投遞穩(wěn)定性
- 下游接受穩(wěn)定性
消息隊(duì)列異步
分庫(kù)分表 sharding jdbc
Sharding-JDBC定位為輕量級(jí) Java 框架，在 Java 的 JDBC 層提供額外的服務(wù)，以 jar 包形式提供服務(wù)，無(wú)需額外部署和依賴，可以理解為增強(qiáng)版的 JDBC 驅(qū)動(dòng)，完全兼容 JDBC 和各種 ORM 框架。核心功能：
- 數(shù)據(jù)分片
- 讀寫分離
- 透明的使用jdbc訪問(wèn)各個(gè)數(shù)據(jù)庫(kù)
Sharding-JDBC
SpringCloud
SpringCloud，從命名我們就可以知道，Spring Cloud 是大名鼎鼎的 Spring家族的產(chǎn)品， 專注于企業(yè)級(jí)開(kāi)源框架的研發(fā)。
Spring Cloud 自從發(fā)布到現(xiàn)在，仍然在不斷的高速發(fā)展，幾乎考慮了服務(wù)治理的方方面面，開(kāi)發(fā)起來(lái)非常的便利和簡(jiǎn)單。
Spring Cloud 架構(gòu)
- Service Provider： 暴露服務(wù)的提供方。
- Service Consumer： 調(diào)用遠(yuǎn)程服務(wù)的服務(wù)消費(fèi)方。
- EureKa Server： 服務(wù)注冊(cè)中心和服務(wù)發(fā)現(xiàn)中心。
Spring Cloud 架構(gòu)
支持協(xié)議
Spring Cloud 使用 HTTP 協(xié)議的 REST API。
Spring Cloud 組件運(yùn)行
所有請(qǐng)求都統(tǒng)一通過(guò) API 網(wǎng)關(guān)(Zuul)來(lái)訪問(wèn)內(nèi)部服務(wù)。
網(wǎng)關(guān)接收到請(qǐng)求后，從注冊(cè)中心(Eureka)獲取可用服務(wù)。
由 Ribbon 進(jìn)行均衡負(fù)載后，分發(fā)到后端的具體實(shí)例。
微服務(wù)之間通過(guò) Feign 進(jìn)行通信處理業(yè)務(wù)。
Spring Cloud 組件運(yùn)行
Dubbo
Dubbo 出生于阿里系，是阿里巴巴服務(wù)化治理的核心框架，并被廣泛應(yīng)用于中國(guó)各互聯(lián)網(wǎng)公司;只需要通過(guò) Spring 配置的方式即可完成服務(wù)化，對(duì)于應(yīng)用無(wú)入侵，設(shè)計(jì)的目的還是服務(wù)于自身的業(yè)務(wù)為主。
雖然阿里內(nèi)部原因 Dubbo 曾經(jīng)一度暫停維護(hù)版本，但是框架本身的成熟度以及文檔的完善程度，完全能滿足各大互聯(lián)網(wǎng)公司的業(yè)務(wù)需求。
Dubbo 架構(gòu)
- Provider：暴露服務(wù)的提供方，可以通過(guò) jar 或者容器的方式啟動(dòng)服務(wù)。
- Consumer：調(diào)用遠(yuǎn)程服務(wù)的服務(wù)消費(fèi)方。
- Registry：服務(wù)注冊(cè)中心和發(fā)現(xiàn)中心。
- Monitor：統(tǒng)計(jì)服務(wù)和調(diào)用次數(shù)，調(diào)用時(shí)間監(jiān)控中心。(Dubbo 的控制臺(tái)頁(yè)面中可以顯示，目前只有一個(gè)簡(jiǎn)單版本。)
- Container：服務(wù)運(yùn)行的容器。
Dubbo 架構(gòu)
支持協(xié)議
Dubbo 使用 RPC 通訊協(xié)議，提供序列化方式如下：
Dubbo：Dubbo 缺省協(xié)議采用單一長(zhǎng)連接和 NIO 異步通訊，適合于小數(shù)據(jù)量大并發(fā)的服務(wù)調(diào)用，以及服務(wù)消費(fèi)者機(jī)器數(shù)遠(yuǎn)大于服務(wù)提供者機(jī)器數(shù)的情況。
RMI：RMI 協(xié)議采用 JDK 標(biāo)準(zhǔn)的 java.rmi.* 實(shí)現(xiàn)，采用阻塞式短連接和 JDK 標(biāo)準(zhǔn)序列化方式。
Hessian：Hessian 協(xié)議用于集成 Hessian 的服務(wù)，Hessian 底層采用 HTTP 通訊，采用 Servlet 暴露服務(wù)，Dubbo 缺省內(nèi)嵌 Jetty 作為服務(wù)器實(shí)現(xiàn)。
HTTP：采用 Spring 的 Http Invoker 實(shí)現(xiàn)。
Webservice：基于 CXF 的 frontend-simple 和 transports-http 實(shí)現(xiàn)。
Dubbo 組件運(yùn)行
每個(gè)組件都是需要部署在單獨(dú)的服務(wù)器上，Gateway 用來(lái)接受前端請(qǐng)求、聚合服務(wù)，并批量調(diào)用后臺(tái)原子服務(wù)。每個(gè) Service 層和單獨(dú)的 DB 交互。
Dubbo 組件運(yùn)行儲(chǔ)
Gateway：前置網(wǎng)關(guān)，具體業(yè)務(wù)操作，Gateway 通過(guò) Dubbo 提供的負(fù)載均衡機(jī)制自動(dòng)完成。
Service：原子服務(wù)，只提供該業(yè)務(wù)相關(guān)的原子服務(wù)。
Zookeeper：原子服務(wù)注冊(cè)到 ZK 上。
最后
以上就是關(guān)于微服務(wù)的一些核心知識(shí)點(diǎn)了，暫時(shí)就寫到這里了，也是為自己做一下相關(guān)技術(shù)棧的記錄，后續(xù)有時(shí)間會(huì)針對(duì)每一項(xiàng)技術(shù)進(jìn)行仔細(xì)研究，或者通過(guò)實(shí)際項(xiàng)目來(lái)展示，盡量通過(guò)一個(gè)完整的項(xiàng)目來(lái)幫助大家更好的了解這些技術(shù)的落地應(yīng)用。
網(wǎng)站名稱：如何更深入的給女朋友解釋什么是微服務(wù)？
本文URL：http://www.dlmjj.cn/article/djciigc.html
