1. 程式人生 > >用普通話說微服務系列(一) 單體應用到微服務的進化

用普通話說微服務系列(一) 單體應用到微服務的進化

從工作體驗切入

開始部署應用             

      在很久很久以前,開發與部署web應用時,一開始都是很開心地寫完‘整個’應用,以包或者資料夾等方式部署到伺服器上。在java中,用war包部署到tomcat伺服器;在.net中,在IIS管理器中指定資料夾。應用就這樣愉快地執行著。

噩夢開始前兆           
 

      突然,開發的應用是一個有市場潛力的應用,或者客戶想開發2期,3期...... 這樣,應用越變越大、專案上線了、修改bug變得越來越吃力、以前開發此功能的同事走了,修改bug用新增程式碼的方式修改、專案啟動越來越慢。

      就這樣,專案支撐了幾年...

噩夢開始前的準備    

      技術負責人突然發現,專案支撐不了多長時間了。並且有其它專案可用到我們開發的功能元件,例如圖片處理功能。

      技術負責人很負責地把應用拆分。分成不同的服務開發的形式。例如我們開發的是一個商城平臺。技術負責人把商城平臺拆分成:圖片處理服務、交易服務、使用者管理服務、商城資料服務(包括商品、類別等)。這時候,系統開發者們很驕傲地看到此應用拆分成的服務可以跑很多年。

架構的追求               

      商城拆分的服務跑得很完美,但是隨著服務的新增與拆分,架構師看到了重複的工作與服務存在不合理的架構。

      什麼樣的重複工作呢?當新增一個服務時,手動新增VM來部署、前端又要新增請求新域名IP的服務。

      並且不合理的架構:1)多個服務使用同一個資料庫,可能導致資料庫壓力過大。2)服務的粒度區分不明顯,有大有小。3)服務沒有同一的認證中心。4)服務動態修改例項數很麻煩。

      針對上面所有的問題,微服務設計思想,就提出了。

 

微服務開播啦!

      什麼是微服務?微服務是一種架構設計,集合了多個概念而成。因為微服務要執行在分散式環境,提倡自動化,所以微服務有很多專業的實現名詞。包括服務發現、熔斷限流、服務網格、API閘道器等。這些個名詞,都會用普通話來開篇敘說。

      微服務可以單獨跑在一個VM或者Docker上。並且有自己的專門資料庫。這個很好理解,微服務提倡解耦。每個微服務可以連線自己的資料庫,並且此資料庫是獨立存在於其它微服務。其它微服務想要訪問資料的時候,可以訪問我微服務的API即可。

微服務-服務與資料庫獨立

 

微服務可以編寫自己的程式語言。甚至於,在同‘一堆’微服務裡,商品微服務用C#、使用者微服務用Java、購物車微服務用PHP。多麼的‘解耦’啊!

微服務-服務與開發語言獨立

 

      微服務的粒度提倡不要太少。有人說,微服務的粒度控制在10個類以內,每個類100行程式碼以內。我的天!這個按程式碼區分的微服務粒度也太低了!反而引起服務的過度呼叫。如果平時你要下單購買一個商品時的流程,只需要訪問訂單、商品、支付微服務。但是你區分的太少,可能訪問的微服務變成了十幾個,甚至上百。這樣想一下效能也太低了吧!因為每個微服務執行在單獨的程序裡。

告誡                  

      在選擇使用微服務前,需要考慮團隊是否有相應的技術。開發微服務需要的技術人員技術相應較高,並且需要理解微服務的一些基本原理,除非公司已經有了一套完整的微服務框架,開發人員只需要在上面像單體應用地開發。

      微服務開發前期需要的週期會相應的增加,甚至是增加幾倍。

      微服務需要有相應程式的運維團隊去運維你的微服務。如果公司有自己的運維一體化工具,則省去了這個建隊需求。

      所以,在使用微服務前,考慮周到,不要盲目地追求使用。最後你可能專案延期、效能比單體應用還慢!

期待                    

      微服務,還有一段很長的路要走。就在今年2018,微服務提出了2.0版本,服務網格。期待微服務整個體系慢慢完善統一起來。

 

微服務的好處

1)資料來源隔離,達到解耦的目的。每個微服務有自己的資料來源,如果需要遷移微服務、加大微服務例項數都非常簡單,不用再考慮資料切分的事情了。

2)統一的認證中心、服務發現、服務閘道器。統一了分散式開發的工具、設計思想。

3)系統越大,相應地開發週期不會線性的增長。

微服務的劣處

1)微服務是分散式開發,所以開發變得異常複雜。分散式系統存在著兩大難題,一個是分散式事務,另外一個是分散式鎖。

2)微服務粒度越細,效能越低。

3)如果沒有自動化部署工具,微服務部署變得一場複雜。

 

可以關注本人的公眾號,多年經驗的原創文章共享給大家。