日本一级特黄大片本道,亚洲精品免费视频99,一级欧美一级日韩片段,国产成人自拍在线观看,国产这里只有精品,免费无码做爱视频,欧美成人性爱影院,毛片一区二区

什么是微服務(wù)架構(gòu)？

通常而言，微服務(wù)架構(gòu)是一種架構(gòu)模式或者說(shuō)是一種架構(gòu)風(fēng)格。

它提倡將單一應(yīng)用程序劃分成一組小的服務(wù)，每個(gè)服務(wù)運(yùn)行獨(dú)立的自己的進(jìn)程中，服務(wù)之間互相協(xié)調(diào)、互相配合，為用戶(hù)提供最終價(jià)值。

服務(wù)之間采用輕量級(jí)的通信機(jī)制互相溝通（通常是基于HTTP的RESTful API）。每個(gè)服務(wù)都圍繞著具體業(yè)務(wù)進(jìn)行構(gòu)建，并且能夠被獨(dú)立地部署到生產(chǎn)環(huán)境、類(lèi)生產(chǎn)環(huán)境等。

微服務(wù)架構(gòu)和單體架構(gòu)的區(qū)別

單體架構(gòu)

通俗地講，“單體應(yīng)用（monolith application）”就是將應(yīng)用程序的所有功能都打包成一個(gè)獨(dú)立的單元，可以是JAR、EXE、BIN或其它歸檔格式。

單體應(yīng)用有如下優(yōu)點(diǎn)：

開(kāi)發(fā)簡(jiǎn)單直接，集中式管理, 基本不會(huì)重復(fù)開(kāi)發(fā)
功能都在本地，沒(méi)有分布式的管理開(kāi)銷(xiāo)和調(diào)用開(kāi)銷(xiāo)

它的缺點(diǎn)也非常明顯，特別對(duì)于互聯(lián)網(wǎng)公司來(lái)說(shuō)：

開(kāi)發(fā)效率低：所有的開(kāi)發(fā)在一個(gè)項(xiàng)目改代碼，遞交代碼相互等待，代碼沖突不斷
代碼維護(hù)難：代碼功能耦合在一起，新人不知道何從下手
部署不靈活：構(gòu)建時(shí)間長(zhǎng)，任何小修改必須重新構(gòu)建整個(gè)項(xiàng)目，這個(gè)過(guò)程往往很長(zhǎng)
穩(wěn)定性不高：一個(gè)微不足道的小問(wèn)題，可以導(dǎo)致整個(gè)應(yīng)用掛掉
擴(kuò)展性不夠：無(wú)法滿(mǎn)足高并發(fā)情況下的業(yè)務(wù)需求

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

隨著業(yè)務(wù)需求的快速發(fā)展變化，敏捷性、靈活性和可擴(kuò)展性需求不斷增長(zhǎng)，迫切需要一種更加快速高效的軟件交付方式。微服務(wù)就是一種可以滿(mǎn)足這種需求的軟件架構(gòu)風(fēng)格。單體應(yīng)用被分解成多個(gè)更小的服務(wù)，每個(gè)服務(wù)有自己的歸檔文件，單獨(dú)部署，然后共同組成一個(gè)應(yīng)用程序。這里的“微”不是針對(duì)代碼行數(shù)而言，而是說(shuō)服務(wù)的范圍限定到單個(gè)功能。

微服務(wù)有如下優(yōu)點(diǎn)：

微服務(wù)是松藕合的，無(wú)論是在開(kāi)發(fā)階段或部署階段都是獨(dú)立的。
能夠快速響應(yīng), 局部修改容易, 一個(gè)服務(wù)出現(xiàn)問(wèn)題不會(huì)影響整個(gè)應(yīng)用。
易于和第三方應(yīng)用系統(tǒng)集成, 支持使用不同的語(yǔ)言開(kāi)發(fā), 允許你利用融合最新技術(shù)。
每個(gè)微服務(wù)都很小，足夠內(nèi)聚，足夠小，代碼容易理解。團(tuán)隊(duì)能夠更關(guān)注自己的工作成果, 聚焦指定的業(yè)務(wù)功能或業(yè)務(wù)需求。
開(kāi)發(fā)簡(jiǎn)單、開(kāi)發(fā)效率提高，一個(gè)服務(wù)可能就是專(zhuān)一的只干一件事, 能夠被小團(tuán)隊(duì)單獨(dú)開(kāi)發(fā)，這個(gè)小團(tuán)隊(duì)可以是 2 到 5 人的開(kāi)發(fā)人員組成。

同樣的, 也存在如下缺點(diǎn):

微服務(wù)架構(gòu)帶來(lái)過(guò)多的運(yùn)維操作, 可能需要團(tuán)隊(duì)具備一定的DevOps技巧。
分布式系統(tǒng)可能復(fù)雜難以管理。因?yàn)榉植疾渴鸶檰?wèn)題難。當(dāng)服務(wù)數(shù)量增加，管理復(fù)雜性增加。

微服務(wù)架構(gòu)的主要特點(diǎn)

微服務(wù)架構(gòu)是一種松耦合的、有一定的有界上下文的面向服務(wù)架構(gòu)。也就是說(shuō)，如果遇到一個(gè)功能變更, 但其要求每個(gè)服務(wù)都要同時(shí)修改，那么它們就不能稱(chēng)之為微服務(wù)，因?yàn)樗鼈兙o耦合在一起；如果你需要掌握一個(gè)服務(wù)的上下文場(chǎng)景使用條件，那么它就是一個(gè)有上下文邊界的服務(wù)，這個(gè)定義一般來(lái)自DDD（領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)）。

它的主要特點(diǎn)是組件化、松耦合、自治、去中心化，體現(xiàn)在以下幾個(gè)方面：

細(xì)粒度的服務(wù)分解，服務(wù)粒度要小，而每個(gè)服務(wù)是針對(duì)一個(gè)單一職責(zé)的業(yè)務(wù)能力的封裝，專(zhuān)注做好一件事情。
獨(dú)立部署運(yùn)行和擴(kuò)展，每個(gè)服務(wù)能夠獨(dú)立被部署并運(yùn)行在一個(gè)進(jìn)程內(nèi)。這種運(yùn)行和部署方式能夠賦予系統(tǒng)靈活的代碼組織方式和發(fā)布節(jié)奏，使得快速交付和應(yīng)對(duì)變化成為可能。
獨(dú)立開(kāi)發(fā)和演化，技術(shù)選型靈活，不受遺留系統(tǒng)技術(shù)約束。合適的業(yè)務(wù)問(wèn)題選擇合適的技術(shù)可以獨(dú)立演化。服務(wù)與服務(wù)之間采取與語(yǔ)言無(wú)關(guān)的API進(jìn)行集成。相對(duì)單體架構(gòu)，微服務(wù)架構(gòu)是更面向業(yè)務(wù)創(chuàng)新的一種架構(gòu)模式。
獨(dú)立團(tuán)隊(duì)和自治，團(tuán)隊(duì)對(duì)服務(wù)的整個(gè)生命周期負(fù)責(zé)，工作在獨(dú)立的上下文中，自己決策自己治理，而不需要統(tǒng)一的指揮中心。團(tuán)隊(duì)和團(tuán)隊(duì)之間通過(guò)松散的社區(qū)部落進(jìn)行銜接。

通過(guò)解耦我們所做的事情，分而治之以減少不必要的損耗，使得整個(gè)復(fù)雜的系統(tǒng)和組織能夠快速的應(yīng)對(duì)變化。

需要考慮的問(wèn)題

單個(gè)微服務(wù)代碼量小，易修改和維護(hù)。但是，系統(tǒng)復(fù)雜度的總量是不變的，每個(gè)服務(wù)代碼少了，但服務(wù)的個(gè)數(shù)肯定就多了。就跟拼圖游戲一樣，切的越碎，越難拼出整幅圖。一個(gè)系統(tǒng)被拆分成零碎的微服務(wù)，最后要集成為一個(gè)完整的系統(tǒng)，其復(fù)雜度肯定比大塊的功能集成要高很多。

單個(gè)微服務(wù)數(shù)據(jù)獨(dú)立，可獨(dú)立部署和運(yùn)行。雖然微服務(wù)本身是可以獨(dú)立部署和運(yùn)行的，但仍然避免不了業(yè)務(wù)上的你來(lái)我往，這就涉及到要對(duì)外通信，當(dāng)微服務(wù)的數(shù)量達(dá)到一定量級(jí)的時(shí)候，如何提供一個(gè)高效的集群通信機(jī)制成為一個(gè)問(wèn)題。

單個(gè)微服務(wù)擁有自己的進(jìn)程，進(jìn)程本身就可以動(dòng)態(tài)的啟停，為無(wú)縫升級(jí)打好了基礎(chǔ)，但誰(shuí)來(lái)啟動(dòng)和停止進(jìn)程，什么時(shí)機(jī)，選擇在哪臺(tái)設(shè)備上做這件事情才是無(wú)縫升級(jí)的關(guān)鍵。這個(gè)能力并不是微服務(wù)本身提供的，而是需要背后強(qiáng)大的版本管理和部署能力。

多個(gè)相同的微服務(wù)可以做負(fù)載均衡，提高性能和可靠性。正是因?yàn)橄嗤⒎?wù)可以有多個(gè)不同實(shí)例，讓服務(wù)按需動(dòng)態(tài)伸縮成為可能，在高峰期可以啟動(dòng)更多的相同的微服務(wù)實(shí)例為更多用戶(hù)服務(wù)，以此提高響應(yīng)速度。同時(shí)這種機(jī)制也提供了高可靠性，在某個(gè)微服務(wù)故障后，其他相同的微服務(wù)可以接替其工作，對(duì)外表現(xiàn)為某個(gè)設(shè)備故障后業(yè)務(wù)不中斷。同樣的道理，微服務(wù)本身是不會(huì)去關(guān)心系統(tǒng)負(fù)載的，那么什么時(shí)候應(yīng)該啟動(dòng)更多的微服務(wù)，多個(gè)微服務(wù)的流量應(yīng)該如何調(diào)度和分發(fā)，這背后也有一套復(fù)雜的負(fù)載監(jiān)控和均衡的系統(tǒng)在起作用。

微服務(wù)可以獨(dú)立部署和對(duì)外提供服務(wù)，微服務(wù)的業(yè)務(wù)上線(xiàn)和下線(xiàn)是動(dòng)態(tài)的，當(dāng)一個(gè)新的微服務(wù)上線(xiàn)時(shí)，用戶(hù)是如何訪(fǎng)問(wèn)到這種新的服務(wù)？這就需要有一個(gè)統(tǒng)一的入口，新的服務(wù)可以動(dòng)態(tài)的注冊(cè)到這個(gè)入口上，用戶(hù)每次訪(fǎng)問(wèn)時(shí)可以從這個(gè)入口拿到系統(tǒng)所有服務(wù)的訪(fǎng)問(wèn)地址。這個(gè)統(tǒng)一的系統(tǒng)入口并不是微服務(wù)本身的一部分，所以這種能力需要系統(tǒng)單獨(dú)提供。

還有一些企業(yè)級(jí)關(guān)注的系統(tǒng)問(wèn)題，比如，安全策略如何集中管理？系統(tǒng)故障如何快速審計(jì)和跟蹤到具體服務(wù)？整個(gè)系統(tǒng)狀態(tài)如何監(jiān)控？服務(wù)之間的依賴(lài)關(guān)系如何管理？等等這些問(wèn)題都不是單個(gè)微服務(wù)考慮的范疇，而需要有一個(gè)系統(tǒng)性的考慮和設(shè)計(jì)，讓每個(gè)微服務(wù)都能夠按照系統(tǒng)性的要求和約束提供對(duì)應(yīng)的安全性，可靠性，可維護(hù)性的能力。

選擇微服務(wù)框架的關(guān)注點(diǎn)

服務(wù)注冊(cè)、發(fā)現(xiàn)、負(fù)載均衡和健康檢查，假定采用進(jìn)程內(nèi)LB方案，那么服務(wù)自注冊(cè)一般統(tǒng)一做在服務(wù)器端框架中，健康檢查邏輯由具體業(yè)務(wù)服務(wù)定制，框架層提供調(diào)用健康檢查邏輯的機(jī)制，服務(wù)發(fā)現(xiàn)和負(fù)載均衡則集成在服務(wù)客戶(hù)端框架中。

監(jiān)控日志，框架一方面要記錄重要的框架層日志、Metrics和調(diào)用鏈數(shù)據(jù)，還要將日志、Metrics等接口暴露出來(lái)，讓業(yè)務(wù)層能根據(jù)需要記錄業(yè)務(wù)日志數(shù)據(jù)。在運(yùn)行環(huán)境中，所有日志數(shù)據(jù)一般集中落地到企業(yè)后臺(tái)日志系統(tǒng)，做進(jìn)一步分析和處理。

REST/RPC和序列化，框架層要支持將業(yè)務(wù)邏輯以HTTP/REST或者RPC方式暴露出來(lái)，HTTP/REST是當(dāng)前主流API暴露方式，在性能要求高的場(chǎng)合則可采用Binary/RPC方式。針對(duì)當(dāng)前多樣化的設(shè)備類(lèi)型(瀏覽器、普通PC、無(wú)線(xiàn)設(shè)備等)，框架層要支持可定制的序列化機(jī)制，例如，對(duì)瀏覽器，框架支持輸出Ajax友好的JSON消息格式，而對(duì)內(nèi)部服務(wù)及應(yīng)用程序，框架支持輸出性能高的Binary消息格式。

配置，除了支持普通配置文件方式的配置，框架層還可集成動(dòng)態(tài)運(yùn)行時(shí)配置，能夠在運(yùn)行時(shí)針對(duì)不同環(huán)境動(dòng)態(tài)調(diào)整服務(wù)的參數(shù)和配置。

限流和容錯(cuò)，框架集成限流容錯(cuò)組件，能夠在運(yùn)行時(shí)自動(dòng)限流和容錯(cuò)，保護(hù)服務(wù)，如果進(jìn)一步和動(dòng)態(tài)配置相結(jié)合，還可以實(shí)現(xiàn)動(dòng)態(tài)限流和熔斷。

管理接口，框架集成管理接口，一方面可以在線(xiàn)查看框架和服務(wù)內(nèi)部狀態(tài)，同時(shí)還可以動(dòng)態(tài)調(diào)整內(nèi)部狀態(tài)，對(duì)調(diào)試、監(jiān)控和管理能提供快速反饋。Spring Boot微框架的Actuator模塊就是一個(gè)強(qiáng)大的管理接口。

統(tǒng)一錯(cuò)誤處理，對(duì)于框架層和服務(wù)的內(nèi)部異常，如果框架層能夠統(tǒng)一處理并記錄日志，對(duì)服務(wù)監(jiān)控和快速問(wèn)題定位有很大幫助。

安全，安全和訪(fǎng)問(wèn)控制邏輯可以在框架層統(tǒng)一進(jìn)行封裝，可做成插件形式，具體業(yè)務(wù)服務(wù)根據(jù)需要加載相關(guān)安全插件。

文檔自動(dòng)生成，文檔的書(shū)寫(xiě)和同步一直是一個(gè)痛點(diǎn)，框架層如果能支持文檔的自動(dòng)生成和同步，會(huì)給使用API的開(kāi)發(fā)和測(cè)試人員帶來(lái)極大便利。Swagger是一種流行Restful API的文檔方案。

一個(gè)完整的微服務(wù)系統(tǒng)，它最少要包含以下功能：

日志和審計(jì)，主要是日志的匯總，分類(lèi)和查詢(xún)
監(jiān)控和告警，主要是監(jiān)控每個(gè)服務(wù)的狀態(tài)，必要時(shí)產(chǎn)生告警
消息總線(xiàn)，輕量級(jí)的MQ或HTTP
注冊(cè)發(fā)現(xiàn)
負(fù)載均衡
部署和升級(jí)
事件調(diào)度機(jī)制

以下功能不是最小集的一部分，但也應(yīng)該在選擇時(shí)進(jìn)行考慮：

認(rèn)證和鑒權(quán)
多語(yǔ)言支持, 是否支持多種編程語(yǔ)言
統(tǒng)一服務(wù)構(gòu)建和打包
統(tǒng)一服務(wù)測(cè)試
統(tǒng)一配置文件管理
服務(wù)依賴(lài)關(guān)系管理
問(wèn)題跟蹤調(diào)試框架
灰度發(fā)布
藍(lán)綠部署
資源管理，如：底層的容器, 虛擬機(jī), 物理機(jī)和網(wǎng)絡(luò)管理

開(kāi)發(fā)方式影響

隨著持續(xù)交付概念推廣以及容器概念的普及，微服務(wù)將這兩種理念和技術(shù)結(jié)合起來(lái)，形成新的微服務(wù)+API+容器平臺(tái)的開(kāi)發(fā)模式，提出了容器化微服務(wù)的持續(xù)交付概念。

下圖為傳統(tǒng)單體應(yīng)用的DevOps開(kāi)發(fā)隊(duì)伍方式：

這種整體型架構(gòu)要求產(chǎn)品隊(duì)伍橫跨產(chǎn)品管理 Dev開(kāi)發(fā) QA DBA 以及系統(tǒng)運(yùn)營(yíng)管理，而微服務(wù)架構(gòu)引入以后，如下圖：

微服務(wù)促進(jìn)了DevOps方式的重組，將一個(gè)大臃腫的整體產(chǎn)品開(kāi)發(fā)隊(duì)伍切分為根據(jù)不同微服務(wù)的劃分的產(chǎn)品隊(duì)伍，以及一個(gè)大的整體的平臺(tái)隊(duì)伍負(fù)責(zé)運(yùn)營(yíng)管理，兩者之間通過(guò)API交互，做到了松耦合隔絕。

微服務(wù)的實(shí)施是有一定的先決條件：基礎(chǔ)的運(yùn)維能力（如監(jiān)控、快速配置、快速部署）需提前構(gòu)建，否則就會(huì)陷入較被動(dòng)的局面。推薦采用CI/CI改進(jìn)基礎(chǔ)設(shè)施及運(yùn)維的實(shí)踐，通過(guò)自動(dòng)化運(yùn)維使得可以快速安全的響應(yīng)和處理微服務(wù)對(duì)服務(wù)部署的要求，通過(guò)容器技術(shù)保證服務(wù)環(huán)境之間擁有更高的一致性，降低“在我的環(huán)境工作，而你的環(huán)境不工作”的可能，也是為后續(xù)的發(fā)布策略和運(yùn)維提供更好的支撐。

想要更好的實(shí)施微服務(wù), 首先需要考慮構(gòu)建團(tuán)隊(duì)DevOps能力，這是保證微服務(wù)架構(gòu)在持續(xù)交付和應(yīng)對(duì)復(fù)雜運(yùn)維問(wèn)題的動(dòng)力之源。

其次保持服務(wù)持續(xù)演進(jìn)，使之能夠快速、低成本地被拆分和合并，以快速響應(yīng)業(yè)務(wù)的變化；同時(shí)要保持團(tuán)隊(duì)和架構(gòu)對(duì)齊。微服務(wù)看似是技術(shù)層面的變革，但它對(duì)團(tuán)隊(duì)結(jié)構(gòu)和組織文化有很強(qiáng)的要求和影響。識(shí)別和構(gòu)建匹配架構(gòu)的團(tuán)隊(duì)是解決問(wèn)題的另一大支柱。

最后，打造持續(xù)改進(jìn)的組織文化是實(shí)施微服務(wù)的關(guān)鍵基石。只有持續(xù)改進(jìn)，持續(xù)學(xué)習(xí)和反饋，持續(xù)打造這樣一個(gè)文化氛圍和團(tuán)隊(duì)，微服務(wù)架構(gòu)才能持續(xù)發(fā)展下去，保持新鮮的生命力，從而實(shí)現(xiàn)我們的初衷。

原文鏈接：https://blog.csdn.net/kunyus/article/details/90670710

—————END—————

微服務(wù)的概念及優(yōu)缺點(diǎn)