微服务和其他常见架构
生活随笔
收集整理的這篇文章主要介紹了
微服务和其他常见架构
小編覺(jué)得挺不錯(cuò)的,現(xiàn)在分享給大家,幫大家做個(gè)參考.
我們看一下這個(gè)定義是怎么來(lái)的,微服務(wù)是由James和Martin兩個(gè)人提出來(lái)的,他們?cè)?4年的3月份,寫(xiě)過(guò)一篇文章,就叫MicroService,就是微服務(wù),有興趣的可以去看一下原文,這里大家可以看一下時(shí)間https://martinfowler.com/articles/micorservices.htmlhttps://martinfowler.com/他們?cè)?4年的時(shí)候就提出來(lái)了,那么國(guó)內(nèi)是在16年和17年的時(shí)候才慢慢流行出來(lái),大多數(shù)公司用的已經(jīng)比較多了,大家可以看到一個(gè)新事物從提出來(lái),到讓大家所能接受,再到實(shí)踐,最后生產(chǎn)上使用,這是一個(gè)漫長(zhǎng)的過(guò)程,所以大家現(xiàn)在看到一個(gè)新事務(wù)的提出呢,也不用太興奮,畢竟里生產(chǎn)上真正使用,還得有待觀察,在這里我要特別強(qiáng)調(diào)的一點(diǎn)是,微服務(wù)它是一種架構(gòu)風(fēng)格,千萬(wàn)不要認(rèn)為微服務(wù)就是某種組件,就是某些框架,比如我們比較屬性的RestFul,也是一種架構(gòu)風(fēng)格,既然是架構(gòu)風(fēng)格,說(shuō)明他沒(méi)有強(qiáng)制性,沒(méi)有絕對(duì)標(biāo)準(zhǔn)的答案,細(xì)節(jié)上可能有很多不同的理解,因?yàn)橛泻芏喾N理解,首先我們先來(lái)看看martin對(duì)微服務(wù)的理解
開(kāi)始看到英文中有標(biāo)粗的幾個(gè)部分,那幾個(gè)部分就是微服務(wù)該有的幾個(gè)特點(diǎn),它是由一系列微小的服務(wù)共同組成,微服務(wù)自然是微小的服務(wù),這里還寫(xiě)道,一系列,尤其是傳統(tǒng)的單體應(yīng)用,單體應(yīng)用往往是一個(gè)服務(wù),而這是一系列,很多個(gè)服務(wù)共同組成,第二個(gè)是跑在自己的進(jìn)程里,就是說(shuō)任何一個(gè)微服務(wù),都有自己的獨(dú)立的進(jìn)程,互補(bǔ)干擾,第三點(diǎn)是要為獨(dú)立的業(yè)務(wù)開(kāi)發(fā),微服務(wù)要圍繞業(yè)務(wù),我要引用模型去建造,這一點(diǎn)在我們服務(wù)拆分會(huì)有體現(xiàn),第四點(diǎn)是獨(dú)立部署,第五點(diǎn)你可以直接翻譯過(guò)來(lái),就是分布式的管理,相對(duì)以前就是集中式的管理,而現(xiàn)在微服務(wù)是分布式的管理,一個(gè)新事物的出現(xiàn),必然有他的原因,黑格爾曾經(jīng)說(shuō)過(guò),存在即合理,想要知道為什么要提出微服務(wù),我們還得看一下應(yīng)用架構(gòu)的歷史
這個(gè)圖講的是系統(tǒng)的演進(jìn),他本身也是Dubbo的一幅圖,在微服務(wù)之前呢,其實(shí)很經(jīng)典的架構(gòu)呢,也是不少的,就像這幅里畫(huà)的,最開(kāi)始是單一應(yīng)用,然后到垂直應(yīng)用,再到分布式架構(gòu),最后到流動(dòng)時(shí)架構(gòu),這些架構(gòu)具體有什么特點(diǎn)呢,我這里就不一一贅述了,有興趣的可以翻閱一下相關(guān)的資料
來(lái)講一下他涉及的架構(gòu)形態(tài),主要涉及以下方面,首先單體架構(gòu),一個(gè)工程構(gòu)建之后是一個(gè)jar包,其實(shí)還是基于前后端分離的一種架構(gòu),這也算是一種架構(gòu)形態(tài),還有什么呢,它是分布式的架構(gòu),我們當(dāng)時(shí)介紹了水平擴(kuò)展,在這里大家要避免進(jìn)入一個(gè)誤區(qū),以為單體架構(gòu)就不是分布式的,其實(shí)不對(duì),他既可以是單體,也可以是分布式的,下面我們就來(lái)挨個(gè)分析一下,從前面的演示中我們也看到了,點(diǎn)餐系統(tǒng)包含了買(mǎi)家端和賣(mài)家端,我們先拋開(kāi)買(mǎi)家端不說(shuō),我們現(xiàn)在只看賣(mài)家端,其實(shí)就是一個(gè)傳統(tǒng)的CMS后臺(tái)系統(tǒng),里面包含了,商品,訂單,類目這些服務(wù),這三個(gè)服務(wù)其實(shí)對(duì)應(yīng)的業(yè)務(wù)邏輯代碼,我們可以把它看成整體是一個(gè)單體架構(gòu)的應(yīng)用,來(lái)看看單體架構(gòu)的應(yīng)用都有什么特點(diǎn),首先他所有的功能都是打包在一個(gè)war包里的,我們也展示了訂單商品類目,雖然這些都有各自的邏輯,但是最終打包的時(shí)候都是打到一個(gè)war包里,基本上沒(méi)有外部依賴,外部依賴怎么理解呢,他并不是在你pom文件里面,寫(xiě)的dependency,不是那個(gè)意思,將來(lái)我們把服務(wù)給拆分開(kāi)來(lái)之后,商品服務(wù)他可能會(huì)依賴訂單服務(wù),這樣子他形成一個(gè)依賴,那么目前單體架構(gòu)直接打成一個(gè)war包,商品和訂單之間它是沒(méi)有外部依賴的,因?yàn)樗麄兌荚谝粋€(gè)整體里,都在一個(gè)war包里面,他還有一個(gè)特點(diǎn),部署在一個(gè)WEB容器里,比如TOMCAT,包含了DAO,Service,包括UI,所有邏輯,其實(shí)說(shuō)到底,他還是一個(gè)整體,他把所有的東西都打成一個(gè)war包,當(dāng)然他這個(gè)容器不一定是TOMCAT,我們使用Springboot內(nèi)置的TOMCAT呢,你也可以改成Jetty等其他的WEB容器,最后這些服務(wù)都是公用一個(gè)DB,公用一個(gè)數(shù)據(jù)庫(kù),我們列舉了一個(gè)單體架構(gòu),那么由這些特點(diǎn)可以看得出來(lái),他有哪些優(yōu)缺點(diǎn),單體架構(gòu)的優(yōu)點(diǎn)在于什么呢,第一點(diǎn)是容易測(cè)試
單體架構(gòu)的優(yōu)點(diǎn),第一點(diǎn)是容易測(cè)試,在本地就可以啟動(dòng)完整的系統(tǒng),他不需要外部依賴,第二點(diǎn)他容易部署,你直接把他打成一個(gè)war包,放到TOMCAT容器下邊,可以運(yùn)行
他的缺點(diǎn)就很多了,第一點(diǎn)是開(kāi)發(fā)效率低,所有的開(kāi)發(fā)人員在一個(gè)項(xiàng)目里改代碼,可能提交代碼的時(shí)候等待,造成一些代碼沖突,其實(shí)代碼維護(hù)會(huì)變得很困難,尤其是新人來(lái)的時(shí)候,你這么多業(yè)務(wù)代碼,全部寫(xiě)在一塊,新人一來(lái)不知如何下手,第三點(diǎn)部署不夠靈活,這個(gè)跟我們剛剛說(shuō)的容易部署,是兩個(gè)概念,部署不夠靈活,指的是構(gòu)建時(shí)間特別長(zhǎng),有任何的代碼的小修改,必須重新構(gòu)建整個(gè)項(xiàng)目,我曾經(jīng)構(gòu)建一個(gè)項(xiàng)目,需要幾個(gè)小時(shí),另一個(gè)缺點(diǎn)是穩(wěn)定性不高,一個(gè)微不足道的小問(wèn)題,可能讓你整個(gè)系統(tǒng)全部掛掉,就是由于全部代碼寫(xiě)到一起,牽一發(fā)動(dòng)全身,最后一個(gè)缺點(diǎn)是擴(kuò)展性不夠,無(wú)法滿足高并發(fā)的需求,舉個(gè)例子,這個(gè)應(yīng)用里面不是有商品服務(wù)和訂單服務(wù)嗎,那么現(xiàn)在有這么一個(gè)情況,我們希望商品服務(wù)的流量要大一些,因?yàn)楹芏嗳酥豢床毁I(mǎi),訂單服務(wù)要少一些,如果你是單體架構(gòu)的話,那你是很難做到這一點(diǎn)的,因?yàn)榇a寫(xiě)到一起,運(yùn)行也是子啊一個(gè)war包里面運(yùn)行,微服務(wù)架構(gòu)就不一樣了,你把商品服務(wù)和訂單服務(wù)完全獨(dú)立出來(lái),獨(dú)立部署,我完全可以將商品服務(wù)部署10臺(tái)服務(wù)器,訂單服務(wù)部署5臺(tái)服務(wù)器,非常容易的做到這一點(diǎn),這是我們對(duì)賣(mài)家端做的一些分析
買(mǎi)家端是一個(gè)基于前后端分離的架構(gòu),這張圖可能看到過(guò),WEB演變的一張圖,WEB研發(fā)模式的演變,就能搜到,前端APP是由vue.js來(lái)開(kāi)發(fā)的,我們的前端每當(dāng)你改完代碼,并不是直接就可以看得到效果,如果要發(fā)布上去的話呢,必須使用Node.js構(gòu)建一次
這個(gè)手機(jī)訪問(wèn)并不是直接訪問(wèn)后端,他經(jīng)過(guò)vue.js的APP,SpringBoot后端服務(wù)我畫(huà)了多個(gè),這是因?yàn)槲覀儺?dāng)時(shí)利用了Redis,做到了Session的共享,讓SpringBoot的后端服務(wù)呢,支持水平擴(kuò)展,介紹完前后端分離這種架構(gòu)模式呢,我們?cè)賮?lái)看一下分布式架構(gòu)
什么叫分布式呢,旨在支持應(yīng)用和服務(wù)的開(kāi)發(fā),可以利用物理架構(gòu),由多個(gè)自治的處理元素,不共享主內(nèi)存,但通過(guò)網(wǎng)絡(luò)發(fā)送消息合作,這個(gè)定義呢體現(xiàn)分布式系統(tǒng),三個(gè)突出特點(diǎn),同時(shí)也對(duì)應(yīng)這三個(gè)很容易混淆的概念,首先因?yàn)槲⒎?wù)的話,必然是分布式的,所以有必要對(duì)分布式的概念進(jìn)行同步一下,我們來(lái)看一下他的第一個(gè)特點(diǎn),多個(gè)自治的處理元素,其實(shí)我們可以簡(jiǎn)單地理解為多節(jié)點(diǎn),分布式系統(tǒng)是多節(jié)點(diǎn)的,集群肯定也是多節(jié)點(diǎn)的,分布式系統(tǒng)和集群在這一點(diǎn)上,有什么區(qū)別呢,如果廚房里面有兩個(gè)廚師,一個(gè)洗菜,一個(gè)炒菜,他們做的事情互不干擾,那這種叫做分布式,那如果兩個(gè)都是炒菜呢,那就是集群,不共享主內(nèi)存,但通過(guò)網(wǎng)絡(luò)發(fā)送消息合作,這強(qiáng)調(diào)分布式系統(tǒng)中,各個(gè)節(jié)點(diǎn)是通過(guò)發(fā)送消息來(lái)通信的,比如HTTP REST接口,比如RPC,這個(gè)在微服務(wù)中同樣適用
?
總結(jié)
以上是生活随笔為你收集整理的微服务和其他常见架构的全部?jī)?nèi)容,希望文章能夠幫你解決所遇到的問(wèn)題。
- 上一篇: 点餐项目演示说明
- 下一篇: 从一个极简的微服务架构开始