微服務相信大家都不會陌生,我們到處都可以看到這樣的名詞,那微服務是什么呢,解決了什么樣的問題

這是一個電影操作系統的服務,我們把整個系統分成了電影模塊,訂單模塊和用戶模塊,最終我們把它打包成一個war包,部署到TOMCAT里面去,這種架構風格,我們稱之為單體架構,我相信一開始大部分的項目,都是以這種架構方式進行架構的,而且項目初期的話,這個項目會跑的很好的,但是隨著業務的發展,整個項目越來越復雜,模塊越來越多,這個時候我們可能就會面臨著各種各樣的問題

它是一個單體項目,他大致也分了一些模塊,這些模塊的邊界非常的模糊,同時代碼的質量不是很好,業務和需求的變更,也是比較的頻繁,這個導致了項目的復雜性非常的高,第二個技術債務逐漸上升,這種思想在單體架構里是非常嚴重的,我們知道人員它是流動的,可能會有人離職,而這個人員往往會埋坑,每個人員他的水平也不一樣,隨著人員的進進出出,因為你埋的坑沒人解決,第三個部署速度逐漸變慢,因為隨著業務的發展,各個模塊可能會越來越多,而且模塊的代碼也會越來越多,那他的啟動當然也會越來越慢,我之前的項目啟動可能要15分鐘,非常的恐怖,第四個是阻礙創新,阻礙技術創新,這指的是這樣的,因為技術是在不斷地發展,而我們這個項目呢,假設他是5年之前創立的一個項目,他一開始用的是Struts,而我們現在往往喜歡用SpringMVC了,假設我們要進行修改,更換,這其實是非常困難的,首先我又大量代碼需要重新寫,各種各樣的UI啦,都得改,第二個他的風險也非常高,那怎么辦呢,往往繼續使用Struts呢,這其實是不利于技術的發展的,最后是無法按需伸縮,假設電影模塊是CPU密集型的服務,而定的模塊是IO密集型的服務,訂單模塊發生的場景,更好的內存,更好的硬盤,但是我們應用是放在一起打包的,那我們是不是要考慮他的CPU是不是不能太差,這個時候我們就要做一些妥協,這是單體架構存在的缺點,那我們怎么樣去解決這個缺點呢,那現在有一定規模的項目,我們知道架構是為了解決問題的

單點架構存在這樣的問題,所以我們要想辦法去解決這樣的問題,現在又出現了微服務,關于微服務的缺點呢,我們可以看一下這篇博客http://www.zhihu.com/question/37808426下面我們來了解一下什么是微服務,業界沒有一個非常明確的一個定義,我這里引入了Martin Fowler對于微服務的一個描述,他說,簡而言之,微服務架構風格這種開發方法,是以開發小型服務的方式,開發一個獨立應用的,每個小型服務都運行在自己的進程中http://www.martinfowler.com/articles/microservices.html我們看微服務大概具備幾個條件

一系列獨立運行的微服務共同構建起了整個系統,很顯然,每個服務獨立的開發,圍繞業務功能進行構建,第四個微服務之間通過一些輕量級的通信機制進行通信,通過REST API和RPC方式進行調用,我們可以對比一下單體架構和微服務架構

共享DB,共享資源,而微服務建議的是,每個服務單獨運行,因為他有可能有自己的數據庫,訂單服務是IO密集型的,而數據庫定義是關系型的,不可能使用Redis,他們可能通過調用機制去調用,第一是易于開發和維護

針對單個微服務來講的話,因為他只關注某一項業務,訂單微服務他只關注訂單,相對來講它是比較小的,因為他關注的點非常的有限,他的業務難度也會小很多,這樣啟動比較快,因為他關注的點比較小,所以war包也比較小,所以啟動會比較快,像訂單服務里面我們做了小小的改動,電影模塊并沒有改動,那我們這個時候只要修改這個微服務就可以了,第四個是技術棧受限,像這個模塊可能用的是JAVA寫的,這個模塊我們一開始也是用JAVA寫的,我們發現這個用JAVA并不是很適合,或者開發成本比較高,而且不方便,我們后來想使用Node,我們對他進行重構或者怎么樣,這種成本會比較小,因為關注點比較小,第五個是按需伸縮,這更好理解了,比如它是CPU的,CPU密集型的,只要采購更好的CPU,DevOps,以前我們是一個war包,就可以了,現在我們需要維護多個微服務,微服務還要進行相互的協同,才能完整的構建一個服務,那假設手動的進行構建,進行打包的話,壓力可見而知,所以需要一些自動化的工具,輔助我們開發和運維

任何一個東西,他不是完美的,他具備優點的同時,也帶來了相應的挑戰,運維要求比較高,剛剛其實我們已經知道了,他只要維護一個東西就OK了,他可能需要維護多個微服務,哪個服務出問題了,就會導致那一塊應用不正常了,運維要求會比較高,第二個是分布式的復雜性,任何一個分布式系統,大家都了解,不細講了,接口調整成本比較高,像訂單用戶服務,它會被電影微服務所調用,假設我們用戶的模型發生了變化,甚至用戶的業務發生了變化,那很多時候電影微服務要調用他,電影微服務要調用用戶微服務,那這時候,用戶微服務就發生變化了,電影微服務也要跟著調,有很多產品避免不了,有很多產品也能避免,最后一個是重復勞動,像我們在這種架構模式下的,往往會成立一個公共組件,這種方式的話可能會有一點難度,工作量是重復的,如果我們都是用的JAVA技術的,一些Maven,去單獨的寫公共組件,寫好了之后打成一個jar包,大家都引用這個依賴,因為微服務是不綁定技術棧的

在我們設計表的時候,我們也有設計原則,這里我們也總結了一些比較簡單的設計原則,第一個是單一職責原則,這指的是,訂單微服務關注的是單一的,他只關注訂單,他的職責很單一,單例的原則,我們要打造一個高內聚,低耦合的項目,所以每一個微服務他關注的,應該是單一的,第二個是服務治理原則,這個是這樣的,舉個例子,他應該有自己的開發,運維,部署,可以把它當做一個項目去運作,第三個是輕量級的通信原則,輕量級有兩個特性,第一個通信的協議,他這個協議是跨平臺,跨語言的,為什么要跨平臺跨語言的,第四個接口明確原則,這個是這樣的

我們知道這種架構模式的話,SOA用ESB,WEBService之類的,微服務同樣也是,首先SpringCloud,這個是我們課程的一個主要話題,第二個是dubbo,因為微服務它是一個分布式的系統,我們往往會有一些通用的模式,降低微服務的開發難度,或者讓微服務更加的可維護,這個時候我們可能需要用一些各種各樣的組件,去進行配合

?

總結

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

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