微服務(wù)有什么作用？

微服務(wù)有什么作用？

維基上對(duì)微服務(wù)的定義為：一種軟件開(kāi)發(fā)技術(shù)- 面向服務(wù)的體系結(jié)構(gòu)（SOA）架構(gòu)樣式的一種變體，它提倡將單一應(yīng)用程序劃分成一組小的服務(wù)，服務(wù)之間互相協(xié)調(diào)、互相配合，為用戶提供最終價(jià)值。微服務(wù)的最重要的單一特征可能是，由于服務(wù)較小且可獨(dú)立部署，因此不再需要繁瑣的行動(dòng)才能更改應(yīng)用程序中的一行文字。

在微服務(wù)模型中，組件是獨(dú)立部署的，并通過(guò)REST，事件流和消息**的某種組合進(jìn)行通信-因此，可以針對(duì)該服務(wù)優(yōu)化每個(gè)單獨(dú)服務(wù)的堆棧。

技術(shù)一直在變化，由多個(gè)較小的服務(wù)組成的應(yīng)用程序隨著更理想的技術(shù)的發(fā)展而變得更容易且成本更低。使用微服務(wù)，可以單獨(dú)部署單個(gè)服務(wù)，但是也可以單獨(dú)擴(kuò)展它們。由此帶來(lái)的好處是顯而易見(jiàn)的：如果正確完成，微服務(wù)比單片應(yīng)用程序所需的基礎(chǔ)結(jié)構(gòu)要少，因?yàn)槲⒎?wù)僅支持對(duì)需要它的組件進(jìn)行**縮放，而對(duì)于單片應(yīng)用程序則不需要整個(gè)應(yīng)用程序。比如像HC服務(wù)網(wǎng)格是基于Istio及容器技術(shù)的微服務(wù)治理平臺(tái)，以無(wú)侵入方式為多語(yǔ)言、不同部署形態(tài)的異構(gòu)應(yīng)用提供服務(wù)治理、服務(wù)監(jiān)控和安全控制等微服務(wù)管理能力。

能夠?qū)⒎?wù)通信、觀測(cè)與安全能力下沉到基礎(chǔ)設(shè)施層，降低分布式應(yīng)用開(kāi)發(fā)復(fù)雜度，為應(yīng)用運(yùn)維減負(fù)，推動(dòng)企業(yè)應(yīng)用整體向服務(wù)治理平臺(tái)遷移，提升IT系統(tǒng)的整體承載能力、高可用能力。

什么樣的項(xiàng)目需要微服務(wù)

業(yè)務(wù)復(fù)雜度大，并發(fā)量高的項(xiàng)目需要微服務(wù)。根據(jù)查詢相關(guān)信息顯示，在業(yè)務(wù)復(fù)雜度較小時(shí)采用單體應(yīng)用（Monolith）的生產(chǎn)率更高，當(dāng)業(yè)務(wù)復(fù)雜度到了一定規(guī)模時(shí)，單體應(yīng)用的生產(chǎn)率開(kāi)始急劇下降，這時(shí)對(duì)其進(jìn)行微服務(wù)化（Microservice）的拆分才是合理的，當(dāng)并發(fā)量比較小的時(shí)候，使用微服務(wù)并不能體現(xiàn)它的優(yōu)勢(shì)，這時(shí)用單體結(jié)構(gòu)就可以滿足系統(tǒng)的性能要求，當(dāng)并發(fā)量較大時(shí)，尤其集中在一個(gè)或者少量幾個(gè)業(yè)務(wù)場(chǎng)景下，使用微服務(wù)便可有效的節(jié)省資源，綜上所述，當(dāng)系統(tǒng)的業(yè)務(wù)復(fù)雜度小，并發(fā)量不高時(shí)，使用單體架構(gòu)較為劃算，當(dāng)業(yè)務(wù)復(fù)雜度大，并發(fā)量高時(shí)則使用微服務(wù)架構(gòu)。

微服務(wù)的好處（優(yōu)點(diǎn)）有哪些？

顯然，隨著系統(tǒng)復(fù)雜度的提升，以及對(duì)系統(tǒng)擴(kuò)展性的要求越來(lái)越高，微服務(wù)化是一個(gè)很好的方向，但除此之外，微服務(wù)還會(huì)給我們帶來(lái)哪些好處？ 獨(dú)立，獨(dú)立，還是獨(dú)立 我們說(shuō)微服務(wù)打響的是各自的獨(dú)立戰(zhàn)爭(zhēng)，所以，每一個(gè)微服務(wù)都是一個(gè)小王國(guó)，這些微服務(wù)跳出了“大一統(tǒng)”（Monolith）王國(guó)的統(tǒng)治，開(kāi)始從各個(gè)層面打造自己的獨(dú)立能力，從而保障自己的小王國(guó)可以持續(xù)穩(wěn)固的運(yùn)轉(zhuǎn)。 首先，在開(kāi)發(fā)層面，每個(gè)微服務(wù)基本上都是各自獨(dú)立的項(xiàng)目（project），而對(duì)應(yīng)各自獨(dú)立項(xiàng)目的研發(fā)團(tuán)隊(duì)基本上也是獨(dú)立對(duì)應(yīng)，這樣的結(jié)構(gòu)保證了微服務(wù)的并行研發(fā)，并且各自快速迭代，不會(huì)因?yàn)樗醒邪l(fā)都投入一個(gè)近乎單點(diǎn)的項(xiàng)目，從而造成開(kāi)發(fā)階段的瓶頸。

開(kāi)發(fā)階段的獨(dú)立，保證了微服務(wù)的研發(fā)可以高效進(jìn)行。

服務(wù)開(kāi)發(fā)期間的形態(tài)，跟服務(wù)交付期間的形態(tài)原則上是不需要完全高度統(tǒng)一的，即使我們?cè)陂_(kāi)發(fā)的時(shí)候都是各自進(jìn)行，但交付的時(shí)候還是可以一起交付，不過(guò)這不是微服務(wù)的做法。 在微服務(wù)治理體系下，各個(gè)微服務(wù)交付期間也是各自獨(dú)立交付的，從而使得每個(gè)微服務(wù)從開(kāi)發(fā)到交付整條鏈路上都是獨(dú)立進(jìn)行，這大大加快了微服務(wù)的迭代和交付效率。 服務(wù)交付之后需要部署運(yùn)行，對(duì)微服務(wù)來(lái)說(shuō)，它們運(yùn)行期間也是各自獨(dú)立的。 微服務(wù)獨(dú)立運(yùn)行可以帶來(lái)兩個(gè)比較明顯的好處，**個(gè)就是可擴(kuò)展性。

我們可以快速地添加服務(wù)集群的實(shí)例，提升整個(gè)微服務(wù)集群的服務(wù)能力，而在傳統(tǒng) Monolith 模式下，為了能夠提升服務(wù)能力，很多時(shí)候必須強(qiáng)化和擴(kuò)展單一結(jié)點(diǎn)的服務(wù)能力來(lái)達(dá)成。如果單結(jié)點(diǎn)服務(wù)能力已經(jīng)擴(kuò)展到了極限，再尋求擴(kuò)展的話，就得從軟件到硬件整體進(jìn)行重構(gòu)。 軟件行業(yè)有句話：“Threads don\’t scale，Processes do！”，很明確地道出了原來(lái) Monolith 服務(wù)與微服務(wù)在擴(kuò)展（Scale）層面的差異。

對(duì)于Java開(kāi)發(fā)者來(lái)說(shuō)，早些年（當(dāng)然現(xiàn)在也依然存在），我們遵循 Java EE 規(guī)范開(kāi)發(fā)的 Web 應(yīng)用，都需要以 WAR 包的形式部署到 TOMCAT、Jetty、RESIN 等 Web 容器中運(yùn)行，即使每個(gè) WAR 包提供的都是獨(dú)立的微服務(wù)，但因?yàn)樗鼈兌际墙y(tǒng)一部署運(yùn)行在一個(gè) Web 容器中，所以擴(kuò)展能力受限于 Web 容器作為一個(gè)進(jìn)程（process）的現(xiàn)狀。 無(wú)論如何調(diào)整 Web 容器內(nèi)部實(shí)現(xiàn)的線程（thread）設(shè)置，還是會(huì)受限于 Web 容器整體的擴(kuò)展能力。所以，現(xiàn)在很多情況下，大家都是一個(gè) TOMCAT 只部署一個(gè) WAR，然后通過(guò)**和擴(kuò)展多個(gè) TOMCAT 實(shí)例來(lái)擴(kuò)展整個(gè)應(yīng)用服務(wù)集群。

當(dāng)然，說(shuō)到在 TOMCAT 實(shí)例中只部署一個(gè) WAR 包這樣的做法，實(shí)際上不單單只是因?yàn)閿U(kuò)展的因素，還涉及微服務(wù)運(yùn)行期間給我們帶來(lái)的第二個(gè)好處，即隔離性。 隔離性實(shí)際上是可擴(kuò)展性的基礎(chǔ)，當(dāng)我們將每個(gè)微服務(wù)都隔離為獨(dú)立的運(yùn)行單元之后，任何一個(gè)或者多個(gè)微服務(wù)的失敗都將只影響自己或者少量其他微服務(wù)，而不會(huì)大面積地波及整個(gè)服務(wù)運(yùn)行體系。 在架構(gòu)設(shè)計(jì)上有一種實(shí)踐模式，即隔板模式（Bulkhead Pattern），這種架構(gòu)設(shè)計(jì)模式的首要目的就是為了隔離系統(tǒng)中的各個(gè)功能單元和實(shí)體，使得系統(tǒng)不會(huì)因?yàn)橐粋€(gè)單元或者服務(wù)的失敗而導(dǎo)致整體失敗。

這種思路在造船行業(yè)、兵工行業(yè)都有類似的應(yīng)用場(chǎng)景?，F(xiàn)在任何大型船舶在設(shè)計(jì)上都會(huì)有隔艙，目的就是即使有少量進(jìn)水，也可以只將進(jìn)水部位隔離在小范圍，不會(huì)擴(kuò)散而導(dǎo)致船舶大面積進(jìn)水，從而沉沒(méi)。當(dāng)年泰坦尼克號(hào)雖然沉了，但不意味著他們沒(méi)有做隔艙設(shè)計(jì)，只能說(shuō)，傷害度已經(jīng)遠(yuǎn)遠(yuǎn)超出隔艙可以提供的基礎(chǔ)保障范圍。 在坦克的設(shè)計(jì)上，現(xiàn)在一般也會(huì)將彈*艙和乘員艙隔離，從而可以保障當(dāng)坦克受創(chuàng)之后，將傷害盡量限定在指定區(qū)域，盡量減少對(duì)車乘成員的傷害。

前面我們提到，現(xiàn)在大家基本上弱化了 Java EE 的 Web 容器早期采用的“一個(gè) Web 容器部署多個(gè) WAR 包”的做法，轉(zhuǎn)而使用“一個(gè) Web 容器只部署一個(gè) WAR 包”的做法，這實(shí)際上正是綜合考慮了 Web 容器的設(shè)計(jì)和實(shí)現(xiàn)現(xiàn)狀與真實(shí)需求之后做出的合理實(shí)踐選擇。 這些 Web 容器內(nèi)部大多通過(guò)類加載器（Classloader）以及線程來(lái)實(shí)現(xiàn)一定程度上的依賴和功能隔離，但這些機(jī)制從基因上決定了這些做法不是**的隔離手段。而進(jìn)程（Process）擁有天然的隔離特性，所以，一個(gè) WAR 包只部署運(yùn)行在一個(gè) Web 容器進(jìn)程中才是**的隔離方式。 現(xiàn)在回想一下，好像自從各個(gè)微服務(wù)打響?yīng)毩?zhàn)爭(zhēng)并且獨(dú)立之后，無(wú)論從哪個(gè)層面來(lái)看，各自“活”得都挺好。

多語(yǔ)言生態(tài) 微服務(wù)獨(dú)立之后，給了對(duì)應(yīng)的團(tuán)隊(duì)和組織快速迭代和交付的能力，同時(shí)，也給團(tuán)隊(duì)和組織帶來(lái)了更多的靈活性，實(shí)際上，對(duì)應(yīng)交付不同微服務(wù)的團(tuán)隊(duì)或者組織來(lái)說(shuō)，現(xiàn)在可以基于不同的計(jì)算機(jī)語(yǔ)言生態(tài)構(gòu)建這些微服務(wù)，如圖 1 所示。 微服務(wù)的提供者既可以使用 Java 或者 Go 等靜態(tài)語(yǔ)言完成微服務(wù)的開(kāi)發(fā)和交付，也可以使用Python或者 Ruby 等動(dòng)態(tài)語(yǔ)言完成微服務(wù)的開(kāi)發(fā)和交付，對(duì)于團(tuán)隊(duì)內(nèi)部擁有繁榮且有差異的語(yǔ)言文化來(lái)說(shuō)，多語(yǔ)言生態(tài)下的微服務(wù)開(kāi)發(fā)和交付將可以**化的發(fā)揮團(tuán)隊(duì)和組織內(nèi)部各成員的百科優(yōu)勢(shì)。 當(dāng)然，對(duì)于多語(yǔ)言生態(tài)下的微服務(wù)研發(fā)來(lái)說(shuō)，有一點(diǎn)需要注意：為了讓服務(wù)的訪問(wèn)者可以用統(tǒng)一的接口訪問(wèn)所有這些用不同語(yǔ)言開(kāi)發(fā)和交互的微服務(wù)，應(yīng)該盡量統(tǒng)一微服務(wù)的服務(wù)接口和協(xié)議。 在微服務(wù)的生態(tài)下，互通性應(yīng)該是需要重點(diǎn)關(guān)注的因素，沒(méi)有互通，不但服務(wù)的訪問(wèn)者和用戶無(wú)法很好地使用這些微服務(wù)，微服務(wù)和微服務(wù)之間也無(wú)法相互信賴和互助，這將大大損耗微服務(wù)研發(fā)體系帶來(lái)的諸多好處，而多語(yǔ)言生態(tài)也會(huì)變成一種障礙和負(fù)累，而不是益處。

記得時(shí)任黑貓宅急便社長(zhǎng)的小倉(cāng)昌男在其所著的《黑貓宅急便的經(jīng)營(yíng)學(xué)》中提到一個(gè)故事，日本國(guó)鐵曾經(jīng)采用不同于國(guó)際標(biāo)準(zhǔn)的集裝箱和鐵路規(guī)格，然后發(fā)現(xiàn)貨物的運(yùn)輸效率很低，經(jīng)過(guò)考察發(fā)現(xiàn)，原來(lái)是貨物從國(guó)際標(biāo)準(zhǔn)集裝箱卸載之后，在通過(guò)日本國(guó)鐵運(yùn)輸之前，需要先拆箱，重新裝入日本國(guó)鐵規(guī)格的集裝箱，然后裝載到日本國(guó)鐵上進(jìn)行運(yùn)輸。 但是，如果日本國(guó)鐵采用國(guó)際標(biāo)準(zhǔn)的集裝箱規(guī)格，那么貨物集裝箱從遠(yuǎn)洋輪船上卸載之后就可以直接裝上國(guó)鐵，這將大大加快運(yùn)輸效率（日本，國(guó)鐵改革后也證明確實(shí)如此）。日本國(guó)鐵在前期采用私有方案時(shí)，只關(guān)注了自己的利益和效率，舍棄了互通，也帶來(lái)了效率的低下。

所以，在開(kāi)發(fā)和交付微服務(wù)的時(shí)候，尤其是在多語(yǔ)言生態(tài)下開(kāi)發(fā)和交付微服務(wù)，我們從一開(kāi)始就要將互通性作為首要考慮因素，從而不會(huì)因?yàn)閳?zhí)迷于某些服務(wù)或者系統(tǒng)的單點(diǎn)效率而失去了整個(gè)微服務(wù)體系的整體效率。

微服務(wù)優(yōu)點(diǎn)

微服務(wù)是一種軟件架構(gòu)風(fēng)格，它是以專注于單一責(zé)任與功能的小型功能區(qū)塊為基礎(chǔ)，利用模組化的方式組合出復(fù)雜的大型應(yīng)用程序，各功能區(qū)塊使用與語(yǔ)言無(wú)關(guān)的 API（例如 REST）集相互通訊，且每個(gè)服務(wù)可以被單獨(dú)部署，在微服務(wù)軟件架構(gòu)風(fēng)格概念被提出來(lái)的初期，它具備以下三個(gè)核心特點(diǎn)：1. 微服務(wù)為大型系統(tǒng)而生。 通常我們?cè)谙到y(tǒng)架構(gòu)設(shè)計(jì)上面臨的問(wèn)題都與系統(tǒng)的大小相關(guān)，隨著業(yè)務(wù)的快速增長(zhǎng)，會(huì)帶來(lái)系統(tǒng)流量壓力和復(fù)雜度的上升，系統(tǒng)的可維護(hù)性和可擴(kuò)展性成為架構(gòu)設(shè)計(jì)的主要考慮因素，微服務(wù)架構(gòu)設(shè)計(jì)理念通過(guò)小而美的業(yè)務(wù)拆分，通過(guò)分而自治來(lái)實(shí)現(xiàn)復(fù)雜系統(tǒng)的優(yōu)雅設(shè)計(jì)實(shí)現(xiàn)。

2. 微服務(wù)架構(gòu)是面向結(jié)果的。

微服務(wù)架構(gòu)設(shè)計(jì)風(fēng)格的產(chǎn)生并非是出于學(xué)術(shù)或?yàn)闃?biāo)準(zhǔn)而標(biāo)準(zhǔn)的設(shè)計(jì)，而是在軟件架構(gòu)設(shè)計(jì)領(lǐng)域不斷演進(jìn)過(guò)程中，面對(duì)實(shí)際工業(yè)界所遇到問(wèn)題，而出現(xiàn)的面向解決實(shí)際問(wèn)題的架構(gòu)設(shè)計(jì)風(fēng)格。3. 專注于服務(wù)的可替代性來(lái)設(shè)計(jì)。 微服務(wù)架構(gòu)設(shè)計(jì)風(fēng)格核心要解決的問(wèn)題之一便是如何便利地在大型系統(tǒng)中進(jìn)行系統(tǒng)組件的維護(hù)和替換，且不影響整體系統(tǒng)穩(wěn)定性。微服務(wù)帶來(lái)的好處獨(dú)立的可擴(kuò)展性，每個(gè)微服務(wù)都可以獨(dú)立進(jìn)行橫向或縱向擴(kuò)展，根據(jù)業(yè)務(wù)實(shí)際增長(zhǎng)情況來(lái)進(jìn)行快速擴(kuò)展;獨(dú)立的可升級(jí)性，每個(gè)微服務(wù)都可以獨(dú)立進(jìn)行服務(wù)升級(jí)、更新，不用依賴于其它服務(wù)，結(jié)合持續(xù)集成工具可以進(jìn)行持續(xù)發(fā)布，開(kāi)發(fā)人員就可以獨(dú)立快速完成服務(wù)升級(jí)發(fā)布流程;易維護(hù)性，每個(gè)微服務(wù)的代碼均只專注于完成該單個(gè)業(yè)務(wù)范疇的事情，因此微服務(wù)項(xiàng)目代碼數(shù)量將減少至IDE可以快速加載的大小，這樣可以提高了代碼的可讀性，進(jìn)而可以提高研發(fā)人員的生產(chǎn)效率;語(yǔ)言無(wú)關(guān)性，研發(fā)人員可以選用自己最為熟悉的語(yǔ)言和框架來(lái)完成他們的微服務(wù)項(xiàng)目（當(dāng)然，一般根據(jù)每個(gè)公司的實(shí)際技術(shù)棧需要來(lái)了），這樣在面對(duì)新技術(shù)或新框架的選用時(shí)，微服務(wù)能夠更好地進(jìn)行快速響應(yīng);故障和資源的隔離性，在系統(tǒng)中出現(xiàn)不好的資源操作行為時(shí)，例如內(nèi)存泄露、數(shù)據(jù)庫(kù)連接未關(guān)閉等情況，將僅僅只會(huì)影響單個(gè)微服務(wù);優(yōu)化跨團(tuán)隊(duì)溝通，如果要完全實(shí)踐微服務(wù)架構(gòu)設(shè)計(jì)風(fēng)格，研發(fā)團(tuán)隊(duì)勢(shì)必會(huì)按照新的原則來(lái)進(jìn)行劃分，由之前的按照技能、職能劃分的方式變?yōu)榘凑諛I(yè)務(wù)（單個(gè)微服務(wù)）來(lái)進(jìn)行劃分，如此這般團(tuán)隊(duì)里將有各個(gè)方向技能的研發(fā)人員，溝通效率上來(lái)說(shuō)要優(yōu)于之前按照技能進(jìn)行劃分的組織架構(gòu);原生基于“云”的系統(tǒng)架構(gòu)設(shè)計(jì)，基于微服務(wù)架構(gòu)設(shè)計(jì)風(fēng)格，我們能構(gòu)建出來(lái)原生對(duì)于“云”具備超高友好度的系統(tǒng)，與常用容器工具如Docker能夠很方便地結(jié)合，構(gòu)建持續(xù)發(fā)布系統(tǒng)與IaaS、PaaS平臺(tái)對(duì)接，使其能夠方便的部署于各類“云”上，如公用云、私有云以及混合云。

談?wù)勎⒎?wù)架構(gòu)是一個(gè)怎樣的存在？

微服務(wù)是近些年被廣泛提及的一個(gè)概念， 微服務(wù)架構(gòu)可以理解為一個(gè)輕量級(jí)的服務(wù)治理方案， 也就是將系統(tǒng)的功能，通過(guò)服務(wù)的形式發(fā)布到服務(wù)器上，對(duì)服務(wù)進(jìn)行組合調(diào)用，實(shí)現(xiàn)具體的功能，解決實(shí)際業(yè)務(wù)問(wèn)題的架構(gòu)風(fēng)格。 微服務(wù)產(chǎn)生于單體應(yīng)用的擴(kuò)大化，隨著信息化不斷發(fā)展，企業(yè)對(duì)軟件功能的要求越來(lái)越具體，也愈發(fā)的細(xì)致，如果通過(guò)應(yīng)用程序來(lái)實(shí)現(xiàn)，必然是一個(gè)極其復(fù)雜而又痛苦的過(guò)程，由此誕生了微服務(wù)的概念。

就是 將功能發(fā)布成服務(wù)，應(yīng)用程序通過(guò)調(diào)用不同的服務(wù)來(lái)實(shí)現(xiàn)業(yè)務(wù)， 這種設(shè)計(jì)架構(gòu)稱之為微服務(wù)。

微服務(wù)架構(gòu)的優(yōu)點(diǎn)在于每個(gè)服務(wù)可以有獨(dú)立的團(tuán)隊(duì)開(kāi)發(fā)，服務(wù)之間互不干涉，保障了系統(tǒng)的穩(wěn)定性。由于功能被拆分到更細(xì)的粒度，有效的降低了程序的復(fù)雜程度，對(duì)硬件的需求也隨之降低，但是微服務(wù)也有一些不足，比如服務(wù)調(diào)用帶來(lái)的系統(tǒng)復(fù)雜性，服務(wù)間的依賴關(guān)系也是難以管理的，如何構(gòu)建合理的服務(wù)依賴是考驗(yàn)架構(gòu)師能力的重要依據(jù);**，微服務(wù)架構(gòu)的部署以及跟蹤也是很難的?？傊?， 微服務(wù)架構(gòu)有著自身的應(yīng)用場(chǎng)景以及特點(diǎn)，了解哪些場(chǎng)景適合微服務(wù)比掌握微服務(wù)的具體技術(shù)更為重要， 適當(dāng)?shù)募夹g(shù)用在適當(dāng)?shù)膱?chǎng)景，才能發(fā)揮合適的價(jià)值。 微服務(wù)架構(gòu)是當(dāng)前***的技術(shù)架構(gòu)，主要組件有注冊(cè)中心、**、配置中心和各種微服務(wù)模塊。

架構(gòu)靈活、易擴(kuò)展、可動(dòng)態(tài)擴(kuò)容。 在微服務(wù)之前，系統(tǒng)架構(gòu)經(jīng)歷很長(zhǎng)時(shí)間的演變，簡(jiǎn)述如下： 1.無(wú)架構(gòu) 頁(yè)面邏輯和業(yè)務(wù)邏輯混在一起，甚至頁(yè)面直接訪問(wèn)數(shù)據(jù)庫(kù)。 優(yōu)點(diǎn)：因?yàn)闆](méi)有太多的訪問(wèn)路徑轉(zhuǎn)換，效率是**的; 缺點(diǎn)：沒(méi)有分層，邏輯混亂，維護(hù)難，擴(kuò)展難。

2.MVC 架構(gòu) 單系統(tǒng)，表現(xiàn)層、邏輯層、業(yè)務(wù)層分開(kāi)，各層分工協(xié)作。 優(yōu)點(diǎn)：邏輯清晰、分工明確、易維護(hù)。 缺點(diǎn)：系統(tǒng)集中部署，屬于強(qiáng)耦合，某些業(yè)務(wù)模塊出現(xiàn)異常時(shí)，會(huì)導(dǎo)致整個(gè)系統(tǒng)無(wú)法訪問(wèn)。

3.SOA架構(gòu) 面向服務(wù)的架構(gòu)，多個(gè)系統(tǒng)分布式部署，通過(guò)消息總線進(jìn)行通訊。 優(yōu)點(diǎn)：各個(gè)系統(tǒng)的業(yè)務(wù)相對(duì)獨(dú)立，耦合低; 缺點(diǎn)：消息總線負(fù)擔(dān)太重，中心化太重，接口缺乏規(guī)范。 4.微服務(wù)架構(gòu) 一個(gè)系統(tǒng)，按照粒度規(guī)劃，劃分為很多的微服務(wù)，而每個(gè)微服務(wù)，對(duì)應(yīng)一個(gè)具體的業(yè)務(wù)實(shí)現(xiàn)，并可擁有自己獨(dú)立的數(shù)據(jù)庫(kù)，整個(gè)就是微服務(wù)架構(gòu)。

優(yōu)點(diǎn)：如上，架構(gòu)靈活、易擴(kuò)展，在實(shí)際運(yùn)營(yíng)時(shí)，按需擴(kuò)容，集群部署。各個(gè)微服務(wù)業(yè)務(wù)互不影響，耦合性低; 缺點(diǎn)：開(kāi)發(fā)成本高，對(duì)部署有一定的專業(yè)性要求。 從技術(shù)而言，微服務(wù)已經(jīng)是一個(gè)設(shè)計(jì)理念很成熟的架構(gòu)，可滿足不同層次，不同業(yè)務(wù)場(chǎng)景的需要，而且經(jīng)過(guò)多個(gè)版本的迭代，該踩的坑也基本踩完，生態(tài)系統(tǒng)完整，開(kāi)源組件選擇多多，很有一統(tǒng)天下的趨勢(shì)，值得嘗試。 但，不要為了微服務(wù)而微服務(wù)，要根據(jù)自己實(shí)際的要求去做抉擇和取舍。

比較，適合自己的，才是**的！ 微服務(wù)是近幾年技術(shù)社群討論很多的一種軟件架構(gòu)方式，可以說(shuō)是SOA的現(xiàn)代版本、 時(shí)尚 版本。不過(guò)這次浪潮不是由大公司倡導(dǎo)的，而是由工程師們引領(lǐng)的。比如，它采用工程師們熟悉的RESTful接口，而不是笨重的WebService，也不需要一大堆昂貴的中間件。 那微服務(wù)為什么流行起來(lái)？按理說(shuō)它們都是讓軟件更加模塊化，使相互之間保持松耦合，從而優(yōu)化系統(tǒng)架構(gòu)。

國(guó)內(nèi)流行起來(lái)的微服務(wù)架構(gòu)——RestCloud RestCloud 為了保證服務(wù)不注冊(cè)中心癿高可用性，服務(wù)不注冊(cè)中心通過(guò)水平擴(kuò)展癿能 力允許對(duì)服務(wù)不注冊(cè)中心迚行集群配置，開(kāi)在**層做了服務(wù)癿注冊(cè)癿數(shù)據(jù)緩存。 Spring Cloud Eureka 是 Spring Cloud Netflix 微服務(wù)套件中癿一部分，它基于 Netflix Eureka做了二次封裝。主要負(fù)責(zé)完成微服務(wù)架極中的服務(wù)治理功能。 易用性 如果你目前使用SpringBoot開(kāi)發(fā)API服務(wù)則無(wú)需修改任何代碼，只需引入RestCloud配置中心的jar包即可由配置中心接管所有配置，對(duì)開(kāi)發(fā)人員無(wú)任何感知，如果你使用RestBoot開(kāi)發(fā)平臺(tái)開(kāi)發(fā)API則已經(jīng)是天然集成了配置中心的客戶端Jar包無(wú)需任何依賴。

如果你使用php,c#開(kāi)發(fā)目前RestCloud并沒(méi)有提供現(xiàn)成的解決方案，你需要通過(guò)Rest API來(lái)接入RestCloud配置中心并自已在本地實(shí)現(xiàn)配置緩存管理。 穩(wěn)定性 RestCloud采取全新的本地配置持久化技術(shù)，保證配置中心不會(huì)形成單點(diǎn)故障，因?yàn)樗械呐渲脭?shù)據(jù)在應(yīng)用則具有本地緩存和持久化技術(shù)，假定RestCloud配置中心出現(xiàn)故障且長(zhǎng)時(shí)間未能恢復(fù)的情況下，應(yīng)用則的程序會(huì)自動(dòng)讀取本地緩存配置數(shù)據(jù). 進(jìn)一步假定這時(shí)應(yīng)用也剛好出現(xiàn)故障需要重啟，則本地緩存在重啟后將會(huì)消失,這時(shí)應(yīng)用將自動(dòng)從持久層再次讀取配置數(shù)據(jù)到緩存中從而恢復(fù)運(yùn)行，所以RestCloud配置中心不會(huì)出現(xiàn)故障后影響應(yīng)用的運(yùn)行,RestCloud配置中心優(yōu)于目前開(kāi)源的大多數(shù)配置中心解決方案。 易用性 如果你目前使用SpringBoot開(kāi)發(fā)API服務(wù)則無(wú)需修改任何代碼，只需引入RestCloud配置中心的jar包即可由配置中心接管所有配置，對(duì)開(kāi)發(fā)人員無(wú)任何感知，如果你使用RestBoot開(kāi)發(fā)平臺(tái)開(kāi)發(fā)API則已經(jīng)是天然集成了配置中心的客戶端Jar包無(wú)需任何依賴。

如果你使用php,c#開(kāi)發(fā)目前RestCloud并沒(méi)有提供現(xiàn)成的解決方案，你需要通過(guò)Rest API來(lái)接入RestCloud配置中心并自已在本地實(shí)現(xiàn)配置緩存管理。 穩(wěn)定性 RestCloud采取全新的本地配置持久化技術(shù)，保證配置中心不會(huì)形成單點(diǎn)故障，因?yàn)樗械呐渲脭?shù)據(jù)在應(yīng)用則具有本地緩存和持久化技術(shù)，假定RestCloud配置中心出現(xiàn)故障且長(zhǎng)時(shí)間未能恢復(fù)的情況下，應(yīng)用則的程序會(huì)自動(dòng)讀取本地緩存配置數(shù)據(jù). 進(jìn)一步假定這時(shí)應(yīng)用也剛好出現(xiàn)故障需要重啟，則本地緩存在重啟后將會(huì)消失,這時(shí)應(yīng)用將自動(dòng)從持久層再次讀取配置數(shù)據(jù)到緩存中從而恢復(fù)運(yùn)行，所以RestCloud配置中心不會(huì)出現(xiàn)故障后影響應(yīng)用的運(yùn)行,RestCloud配置中心優(yōu)于目前開(kāi)源的大多數(shù)配置中心解決方案。

什么是 微服務(wù)

微服務(wù)架構(gòu)是一種方法，其中單個(gè)應(yīng)用程序由許多松散耦合且可獨(dú)立部署的較小服務(wù)組成。 微服務(wù)（或微服務(wù)架構(gòu)）是一種云原生架構(gòu)方法，其中單個(gè)應(yīng)用程序由許多松散耦合且可獨(dú)立部署的較小組件或服務(wù)組成。

這些服務(wù)通常 雖然關(guān)于微服務(wù)的大部分討論都圍繞架構(gòu)定義和特征展開(kāi)，但它們的價(jià)值可以通過(guò)相當(dāng)簡(jiǎn)單的業(yè)務(wù)和組織優(yōu)勢(shì)來(lái)更普遍地理解： 微服務(wù)也可以通過(guò)它們 不是 什么來(lái)理解。

與微服務(wù)架構(gòu)最常進(jìn)行的兩個(gè)比較是單體架構(gòu)和面向服務(wù)的架構(gòu) (SOA)。 微服務(wù)和單體架構(gòu)之間的區(qū)別在于，微服務(wù)由許多較小的、松散耦合的服務(wù)組成一個(gè)應(yīng)用程序，而不是大型、緊密耦合的應(yīng)用程序的單體方法 微服務(wù)和 SOA 之間的區(qū)別可能不太清楚。 雖然可以在微服務(wù)和 SOA 之間進(jìn)行技術(shù)對(duì)比，尤其是圍繞 企業(yè)服務(wù)總線 (ESB) 的角色，但更容易將差異視為 范圍之一 。 SOA 是企業(yè)范圍內(nèi)的一項(xiàng)努力，旨在標(biāo)準(zhǔn)化 組織中 所有 Web 服務(wù)相互通信和集成的方式，而微服務(wù)架構(gòu)是特定于應(yīng)用程序的。

微服務(wù)可能至少與開(kāi)發(fā)人員一樣受高管和項(xiàng)目負(fù)責(zé)人的歡迎。 這是微服務(wù)更不尋常的特征之一，因?yàn)榧軜?gòu)熱情通常是為軟件開(kāi)發(fā)團(tuán)隊(duì)保留的。 原因是微服務(wù)更好地反映了許多業(yè)務(wù)***希望構(gòu)建和運(yùn)行他們的團(tuán)隊(duì)和開(kāi)發(fā)流程的方式。

換句話說(shuō)，微服務(wù)是一種架構(gòu)模型，可以更好地促進(jìn)所需的操作模型。 在IBM 最近對(duì) 1,200 多名開(kāi)發(fā)人員和 IT 主管進(jìn)行的一項(xiàng)調(diào)查中，87% 的微服務(wù)用戶同意微服務(wù)的采用是值得的。 也許微服務(wù)最重要的一個(gè)特點(diǎn)是，由于服務(wù)更小并且可以獨(dú)立部署，它不再需要國(guó)會(huì)的法案來(lái)更改一行代碼或在應(yīng)用程序中添加新功能。

微服務(wù)向組織承諾提供一種解毒劑，以解決與需要大量時(shí)間的小改動(dòng)相關(guān)的內(nèi)心挫敗感。 它不需要博士學(xué)位。 在計(jì)算機(jī)科學(xué)中看到或理解一種更好地促進(jìn)速度和敏捷性的方法的價(jià)值。

但速度并不是以這種方式設(shè)計(jì)服務(wù)的**價(jià)值。 一種常見(jiàn)的新興組織模型是圍繞業(yè)務(wù)問(wèn)題、服務(wù)或產(chǎn)品將跨職能團(tuán)隊(duì)聚集在一起。 微服務(wù)模型完全符合這一趨勢(shì)，因?yàn)樗菇M織能夠圍繞一個(gè)服務(wù)或一組服務(wù)創(chuàng)建小型、跨職能的團(tuán)隊(duì)，并讓他們以敏捷的方式運(yùn)行。 微服務(wù)的松散耦合還為應(yīng)用程序建立了一定程度的故障隔離和更好的彈性。

服務(wù)的小規(guī)模，加上清晰的邊界和溝通模式，使新團(tuán)隊(duì)成員更容易理解代碼庫(kù)并快速為其做出貢獻(xiàn)——在速度和員工士氣方面都有明顯的好處。 在傳統(tǒng)的 n 層架構(gòu)模式中，應(yīng)用程序通常共享一個(gè)公共堆棧，其中一個(gè)大型關(guān)系數(shù)據(jù)庫(kù)支持整個(gè)應(yīng)用程序。 這種方法有幾個(gè)明顯的缺點(diǎn)——其中最重要的是應(yīng)用程序的每個(gè)組件都必須共享一個(gè)公共堆棧、數(shù)據(jù)模型和數(shù)據(jù)庫(kù)，即使對(duì)于某些元素的工作有一個(gè)清晰、更好的工具。 它造成了糟糕的架構(gòu)，并且對(duì)于那些不斷意識(shí)到構(gòu)建這些組件的更好、更有效的方法是可用的開(kāi)發(fā)人員來(lái)說(shuō)是令人沮喪的。

相比之下，在微服務(wù)模型中，組件是獨(dú)立部署的，并通過(guò) REST、事件流和消息**的某種組合進(jìn)行通信——因此每個(gè)單獨(dú)服務(wù)的堆棧都可以針對(duì)該服務(wù)進(jìn)行優(yōu)化。 技術(shù)一直在變化，由多個(gè)較小的服務(wù)組成的應(yīng)用程序更容易和更便宜地隨著更理想的技術(shù)發(fā)展而變得可用。 使用微服務(wù)，可以單獨(dú)部署單個(gè)服務(wù)，但也可以單獨(dú)擴(kuò)展它們。由此產(chǎn)生的好處是顯而易見(jiàn)的：如果做得正確，微服務(wù)比單體應(yīng)用程序需要更少的基礎(chǔ)設(shè)施，因?yàn)樗鼈冎恢С謱?duì)需要它的組件進(jìn)行**擴(kuò)展，而不是在單體應(yīng)用程序的情況下對(duì)整個(gè)應(yīng)用程序進(jìn)行擴(kuò)展。

微服務(wù)的顯著優(yōu)勢(shì)伴隨著重大挑戰(zhàn)。 從單體架構(gòu)到微服務(wù)意味著更多的管理復(fù)雜性——更多的服務(wù)，由更多的團(tuán)隊(duì)創(chuàng)建，部署在更多的地方。 一項(xiàng)服務(wù)中的問(wèn)題可能會(huì)導(dǎo)致或由其他服務(wù)中的問(wèn)題引起。

日志數(shù)據(jù)（用于監(jiān)控和解決問(wèn)題）更加龐大，并且在服務(wù)之間可能不一致。 新版本可能會(huì)導(dǎo)致向后兼容性問(wèn)題。 應(yīng)用程序涉及更多的**連接，這意味著出現(xiàn)延遲和連接問(wèn)題的機(jī)會(huì)更多。

DevOps 方法可以解決其中的許多問(wèn)題，但 DevOps 的采用也有其自身的挑戰(zhàn)。 然而，這些挑戰(zhàn)并沒(méi)有阻止非采用者采用微服務(wù)——或者采用者深化他們的微服務(wù)承諾。 新的 IBM 調(diào)查數(shù)據(jù) 顯示，56% 的當(dāng)前非用戶可能或非?？赡茉谖磥?lái)兩年內(nèi)采用微服務(wù)，78% 的當(dāng)前微服務(wù)用戶可能會(huì)增加他們?cè)谖⒎?wù)上投入的時(shí)間、金錢和精力 微服務(wù)架構(gòu)通常被描述為針對(duì) DevOps 和持續(xù)集成/持續(xù)交付 (CI/CD) 進(jìn)行了優(yōu)化，在可以頻繁部署的小型服務(wù)的上下文中，原因很容易理解。 但另一種看待微服務(wù)和 DevOps 之間關(guān)系的方式是，微服務(wù)架構(gòu)實(shí)際上 需要 DevOps 才能成功。

雖然單體應(yīng)用程序具有本文前面討論過(guò)的一系列缺點(diǎn)，但它們的好處是它不是一個(gè)具有多個(gè)移動(dòng)部件和獨(dú)立技術(shù)堆棧的復(fù)雜分布式系統(tǒng)。 相比之下，鑒于微服務(wù)帶來(lái)的復(fù)雜性、移動(dòng)部件和依賴項(xiàng)的大量增加，在部署、監(jiān)控和生命周期自動(dòng)化方面沒(méi)有大量投資的情況下使用微服務(wù)是不明智的。 雖然幾乎任何現(xiàn)代工具或語(yǔ)言都可以在微服務(wù)架構(gòu)中使用，但有一些核心工具已成為微服務(wù)必不可少的邊界定義： 微服務(wù)的關(guān)鍵要素之一是它通常非常小。

（沒(méi)有任意數(shù)量的代碼可以確定某物是否是微服務(wù)，但名稱中的“微”就在那里。） 當(dāng)Docker在 2013 年迎來(lái)現(xiàn)代容器時(shí)代時(shí)，它還引入了與微服務(wù)最密切相關(guān)的計(jì)算模型。 由于單個(gè)容器沒(méi)有自己的操作系統(tǒng)的開(kāi)銷，它們比傳統(tǒng)的虛擬機(jī)更小更輕，并且可以更快地啟動(dòng)和關(guān)閉，使其成為微服務(wù)架構(gòu)中更小、更輕的服務(wù)的完美匹配. 隨著服務(wù)和容器的激增，編排和管理大量容器很快成為關(guān)鍵挑戰(zhàn)之一。 Kubernetes是一個(gè)開(kāi)源容器編排平臺(tái)，已成為****的編排解決方案之一，因?yàn)樗龅梅浅：谩?/p>

微服務(wù)通常通過(guò) API 進(jìn)行通信，尤其是在首次建立狀態(tài)時(shí)。 雖然客戶端和服務(wù)確實(shí)可以直接相互通信，但 API **通常是一個(gè)有用的中間層，尤其是當(dāng)應(yīng)用程序中的服務(wù)數(shù)量隨著時(shí)間的推移而增長(zhǎng)時(shí)。 API **通過(guò)路由請(qǐng)求、跨多個(gè)服務(wù)扇出請(qǐng)求以及提供額外的安全性和身份驗(yàn)證來(lái)充當(dāng)客戶端的反向**。

有多種技術(shù)可用于實(shí)現(xiàn) API **，包括 API 管理平臺(tái)，但如果使用容器和 Kubernetes 實(shí)現(xiàn)微服務(wù)架構(gòu)，則**通常使用 Ingress 或最近的Istio 來(lái)實(shí)現(xiàn)。 雖然**實(shí)踐可能是設(shè)計(jì)無(wú)狀態(tài)服務(wù)，但狀態(tài)仍然存在，服務(wù)需要了解它。 雖然 API 調(diào)用通常是為給定服務(wù)初始建立狀態(tài)的有效方式，但它并。