1、SpringBoot 微服務的誕生

一直想寫點關於 SpringBoot 的文章,奈何水平有限不敢輕易下筆,只能對一些淺顯的問題進行總結。今天無意中發現一本好書《SpringBoot 快速構建微服務體系》,王福強老師的著作。裏面對 SpringBoot 進行了更爲深層的解釋,內容非常不錯。

接下來我會借這本書寫寫關於 SpringBoot 的內容。也推薦大家去看原著,支持下王福強老師,畢竟寫書這件事真是不容易!!

0、微服務(Micro Service)的盛行

最近幾年微服務(Micro Service)的概念很流行,其中Java中最耀眼的當屬 SpringBoot 。背靠 Spring 框架衍生出來的整個生態體系,無論從“出身”,還是社區的支撐上, SpringBoot 都是微服務框架選型的不二之選。

王福強老師認爲 SpringBoot 並非單一 一個微服務框架的概念就可以將其概括,應當將其看作是一種最佳實踐更爲貼切:一種 Spring 框架及其社區對“約定大於配置”理念的最佳實踐。

1、什麼是微服務(Micro Service)

微服務(Micro Service) 流行於近幾年,但是實際上好多大的企業已經在使用和實施微服務了。各個大企業在微服務化的道路上走得時間長了,踩坑多了,整個軟件交付鏈路上各個環節的基礎設施逐漸成熟,進而微服務就誕生了。

之所以稱爲微服務,是和之前的服務化思路和實踐相比較而來的。因爲早些年的服務實現和實施思路是瀑布式的,也就是將很多功能從開發到交付都打成一個很大的服務單元,而微服務實現和實施的思路則更強調功能趨於單一,服務單元小型化和微型化。

所以,從思路和理念上來講,微服務就是倡導對功能進行拆分,將服務粒度做小,使之可以獨立承擔對外服務的職責,沿着這個思路開發和交付的軟件服務實體就叫做“微服務”,而圍繞着這個思路和理念構建的一系列基礎設施和指導思想,王福強老師稱爲“微服務體系”。

2、微服務(Micro Service) 因何而生

對於原來瀑布模式下開發的服務來說,如果團隊不大,如軟件複雜度不大,那麼使用原來的模式進行服務化治理是比較合理的,而且這種方式對運維和各種基礎設施的要求也不高。

但是隨着互聯網的蓬勃發展,軟件的複雜化飆升,軟件交付的效率要求更高,隨之投入的資源越來越多,傳統的服務之路“捉襟見肘”。

首先開發階段,將多個功能統一到一個項目下,但隨着功能的膨脹,這些功能會有不同的研發人員開發,造成後果就是,大家提交代碼時候頻繁衝突,併爲解決衝突付出精力,使得單一的開發項目成爲了開發期間所有人的工作瓶頸。

這個時候可以按照微服務的理念對要開發的功能模塊進行拆分,從而負責不同功能的研發人員就可以在自己的項目進行代碼管理。

到了軟件交付階段,如果是以前的瀑布式開發,所有開發完成的項目會集中交付,只能等待所有的功能測試完成後,才能完成整個項目的交付。如果有其中一環掉鏈子,可怕程度難以想象。

但是按照微服務理念,我們前期按照功能將服務單元進行了拆分,各自獨立,研發人員開發完成後可以將其作爲獨立的單元進行交付,從而使得所有研發人員能夠並行,各自演化不受影響。

總體來說,微服務可以應對飆升的複雜度;也可以對相應的組織架構進行擴展。

3、微服務帶來的好處

首先每個微服務都是獨立的項目,而且相對於整個項目也是相對獨立的,進而在開發階段保證了其快速迭代,高效進行開發。

其次雖然微服務是獨立開發的,但是交付的時候還是可以一起交付的(但是這不是微服務的做法)。微服務體系下,各個服務交付時間獨立,從而使得每個微服務從開發到交付整條鏈路都是獨立進行的,加快了微服務的迭代和交付效率。

微服務獨立運行可以帶來明顯的好處:

①可擴展性:可以快速添加服務集羣的實例,提升整個微服務集羣的服務能力,傳統模式下,爲了提高服務能力,很多是必須強化和擴展單一節點的服務能力來達成,如果單節點服務能力已達極限,就得從軟件到硬件整體進行重構。

早些年開發者遵循JavaEE開發規範開發的Web應用,都需要以 War 包的形式部署到 tomcat、jetty等web容器中運行,即使每個war包提供的都是獨立的微服務,但是它們都是統一部署到一個web容器中的,所以擴展能力受限於web容器整體。所以大多數情況下,都是一個tomcat只部署一個war包,然後擴展和複製多個tomcat實例來擴展整個應用服務集羣。

②隔離性:實際上是可擴展性的基礎,當將每個微服務都隔離爲獨立的運行單元后,任何一個或者多個微服務的失敗都將隻影響自己或者少量的其他微服務,而不會大面積波及整個服務運行體系。

③多語言生態:微服務獨立後,給了對應的團隊何組織快速迭代和交付的能力。同事也帶來了更多的靈活性,實際上不同的交付團隊可以基於不同的計算機語言構建這些微服務。比如說可以使用 Java 、Go、python等進行開發何交付,但是應該儘量統一微服務的服務接口和協議。

4、微服務帶來的挑戰

服務的數量明顯增多。雖然微服務化後可以快速迭代開發交付,擴展性上也沒有問題。但是在快速迭代中,對開發人員的要求更高,要對自己的開發的程序要更加熟悉,因爲往往一個服務只有一個開發人員,好的情況外加一個備份人員,但往往是備份人員是另外一個微服務的主開發人員(小編的項目組就是這樣子的)。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章