我們看一下這個定義是怎么來的,微服務是由James和Martin兩個人提出來的,他們在14年的3月份,寫過一篇文章,就叫MicroService,就是微服務,有興趣的可以去看一下原文,這里大家可以看一下時間https://martinfowler.com/articles/micorservices.htmlhttps://martinfowler.com/他們在14年的時候就提出來了,那么國內是在16年和17年的時候才慢慢流行出來,大多數公司用的已經比較多了,大家可以看到一個新事物從提出來,到讓大家所能接受,再到實踐,最后生產上使用,這是一個漫長的過程,所以大家現在看到一個新事務的提出呢,也不用太興奮,畢竟里生產上真正使用,還得有待觀察,在這里我要特別強調的一點是,微服務它是一種架構風格,千萬不要認為微服務就是某種組件,就是某些框架,比如我們比較屬性的RestFul,也是一種架構風格,既然是架構風格,說明他沒有強制性,沒有絕對標準的答案,細節上可能有很多不同的理解,因為有很多種理解,首先我們先來看看martin對微服務的理解

開始看到英文中有標粗的幾個部分,那幾個部分就是微服務該有的幾個特點,它是由一系列微小的服務共同組成,微服務自然是微小的服務,這里還寫道,一系列,尤其是傳統的單體應用,單體應用往往是一個服務,而這是一系列,很多個服務共同組成,第二個是跑在自己的進程里,就是說任何一個微服務,都有自己的獨立的進程,互補干擾,第三點是要為獨立的業務開發,微服務要圍繞業務,我要引用模型去建造,這一點在我們服務拆分會有體現,第四點是獨立部署,第五點你可以直接翻譯過來,就是分布式的管理,相對以前就是集中式的管理,而現在微服務是分布式的管理,一個新事物的出現,必然有他的原因,黑格爾曾經說過,存在即合理,想要知道為什么要提出微服務,我們還得看一下應用架構的歷史

這個圖講的是系統的演進,他本身也是Dubbo的一幅圖,在微服務之前呢,其實很經典的架構呢,也是不少的,就像這幅里畫的,最開始是單一應用,然后到垂直應用,再到分布式架構,最后到流動時架構,這些架構具體有什么特點呢,我這里就不一一贅述了,有興趣的可以翻閱一下相關的資料

來講一下他涉及的架構形態,主要涉及以下方面,首先單體架構,一個工程構建之后是一個jar包,其實還是基于前后端分離的一種架構,這也算是一種架構形態,還有什么呢,它是分布式的架構,我們當時介紹了水平擴展,在這里大家要避免進入一個誤區,以為單體架構就不是分布式的,其實不對,他既可以是單體,也可以是分布式的,下面我們就來挨個分析一下,從前面的演示中我們也看到了,點餐系統包含了買家端和賣家端,我們先拋開買家端不說,我們現在只看賣家端,其實就是一個傳統的CMS后臺系統,里面包含了,商品,訂單,類目這些服務,這三個服務其實對應的業務邏輯代碼,我們可以把它看成整體是一個單體架構的應用,來看看單體架構的應用都有什么特點,首先他所有的功能都是打包在一個war包里的,我們也展示了訂單商品類目,雖然這些都有各自的邏輯,但是最終打包的時候都是打到一個war包里,基本上沒有外部依賴,外部依賴怎么理解呢,他并不是在你pom文件里面,寫的dependency,不是那個意思,將來我們把服務給拆分開來之后,商品服務他可能會依賴訂單服務,這樣子他形成一個依賴,那么目前單體架構直接打成一個war包,商品和訂單之間它是沒有外部依賴的,因為他們都在一個整體里,都在一個war包里面,他還有一個特點,部署在一個WEB容器里,比如TOMCAT,包含了DAO,Service,包括UI,所有邏輯,其實說到底,他還是一個整體,他把所有的東西都打成一個war包,當然他這個容器不一定是TOMCAT,我們使用Springboot內置的TOMCAT呢,你也可以改成Jetty等其他的WEB容器,最后這些服務都是公用一個DB,公用一個數據庫,我們列舉了一個單體架構,那么由這些特點可以看得出來,他有哪些優缺點,單體架構的優點在于什么呢,第一點是容易測試

單體架構的優點,第一點是容易測試,在本地就可以啟動完整的系統,他不需要外部依賴,第二點他容易部署,你直接把他打成一個war包,放到TOMCAT容器下邊,可以運行

他的缺點就很多了,第一點是開發效率低,所有的開發人員在一個項目里改代碼,可能提交代碼的時候等待,造成一些代碼沖突,其實代碼維護會變得很困難,尤其是新人來的時候,你這么多業務代碼,全部寫在一塊,新人一來不知如何下手,第三點部署不夠靈活,這個跟我們剛剛說的容易部署,是兩個概念,部署不夠靈活,指的是構建時間特別長,有任何的代碼的小修改,必須重新構建整個項目,我曾經構建一個項目,需要幾個小時,另一個缺點是穩定性不高,一個微不足道的小問題,可能讓你整個系統全部掛掉,就是由于全部代碼寫到一起,牽一發動全身,最后一個缺點是擴展性不夠,無法滿足高并發的需求,舉個例子,這個應用里面不是有商品服務和訂單服務嗎,那么現在有這么一個情況,我們希望商品服務的流量要大一些,因為很多人只看不買,訂單服務要少一些,如果你是單體架構的話,那你是很難做到這一點的,因為代碼寫到一起,運行也是子啊一個war包里面運行,微服務架構就不一樣了,你把商品服務和訂單服務完全獨立出來,獨立部署,我完全可以將商品服務部署10臺服務器,訂單服務部署5臺服務器,非常容易的做到這一點,這是我們對賣家端做的一些分析

買家端是一個基于前后端分離的架構,這張圖可能看到過,WEB演變的一張圖,WEB研發模式的演變,就能搜到,前端APP是由vue.js來開發的,我們的前端每當你改完代碼,并不是直接就可以看得到效果,如果要發布上去的話呢,必須使用Node.js構建一次

這個手機訪問并不是直接訪問后端,他經過vue.js的APP,SpringBoot后端服務我畫了多個,這是因為我們當時利用了Redis,做到了Session的共享,讓SpringBoot的后端服務呢,支持水平擴展,介紹完前后端分離這種架構模式呢,我們再來看一下分布式架構

什么叫分布式呢,旨在支持應用和服務的開發,可以利用物理架構,由多個自治的處理元素,不共享主內存,但通過網絡發送消息合作,這個定義呢體現分布式系統,三個突出特點,同時也對應這三個很容易混淆的概念,首先因為微服務的話,必然是分布式的,所以有必要對分布式的概念進行同步一下,我們來看一下他的第一個特點,多個自治的處理元素,其實我們可以簡單地理解為多節點,分布式系統是多節點的,集群肯定也是多節點的,分布式系統和集群在這一點上,有什么區別呢,如果廚房里面有兩個廚師,一個洗菜,一個炒菜,他們做的事情互不干擾,那這種叫做分布式,那如果兩個都是炒菜呢,那就是集群,不共享主內存,但通過網絡發送消息合作,這強調分布式系統中,各個節點是通過發送消息來通信的,比如HTTP REST接口,比如RPC,這個在微服務中同樣適用

?

總結

以上是生活随笔為你收集整理的微服务和其他常见架构的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。