如何支撐微服務架構落地


內容來源:2017年4月22日,練海榮在「【滬江技術沙龍】 -- 漫談微服務架構實踐」進行《如何支撐微服務架構落地》演講分享。IT大咖說做爲獨家視頻合做方,經主辦方和講者審閱受權發佈。

編輯:IT大咖說   閱讀字數:2265 html


摘要

現在微服務如日中天,優點和弊端也有各類描述,那麼咱們是否應該採用微服務架構?如何規避微服務的弊端,放大微服務優點?如何在先進性和實用性中做出平衡,順利落地?
前端

嘉賓演講視頻地址:t.cn/RKJFQLZdocker

什麼是微服務架構?

微服務 ≈ 模塊化開發 + 分佈式計算數據庫

微服務架構帶來的好處

我認爲微服務架構帶來了兩個好處。第一個好處就是下降了系統的複雜度,第二個是提高了咱們的開發效率。後端

前一段時間咱們在決定來作微服務架構的過程當中作了不少的調研。安全

微服務看起來很好,有沒有給團隊帶來麻煩?

微服務自身的問題其實也很明顯。第一個是上手難度大,第二個問題就是部署包變多,以及多個小服務如何組裝成一個大系統,還有微服務之間的依賴關係錯綜複雜,該如何管理。架構

這些都是微服務是逃避不開的問題。我在論壇上看到過一句話,開發以爲微服務是個好架構,可是運維不這麼認爲。我認爲沒有一個很好的技術體系的支撐,就不要輕易地採用服務。運維

如何緩解微服務架構帶來的弊端

能力支撐

首先咱們要提供一個能力的支撐。所謂能力的支撐就是要把基礎組件所有提供給業務開發部門。分佈式

其次咱們要提供完善的運維支撐平臺和監控體系。模塊化

當平臺研發團隊對業務團隊進行支撐的時候,他們在使用微服務架構的過程中有任何問題,咱們都能爲他們提供一個良好的支撐。

自動化

一鍵發佈單個微服務。在一個項目當中可能有二三十個微服務,咱們要把每個微服務都可以一鍵發佈。

第二要是要一鍵發佈整個系統。由於有時須要重啓整個系統,這個時候就要能一鍵發佈整個系統。

什麼樣的系統須要採用微服務

我認爲第一規模要大,是指人員多,或是代碼函數多。

第二個就是複雜度高,是指業務複雜,好比金融系統。

第三須要長期演進。若是是單體的,能夠在演進過程當中打上層層補丁。咱們使用微服務把bug控制在一個小範圍以內。

這三種狀況能夠考慮使用微服務架構。

採用微服務架構後,如何正確的姿式作技術管理

原來咱們在進行溝通的時候,幾乎都是以數據的形式。好比兩我的在開發一個系統裏面的兩個模塊,當我要調你的功能都是去看你的數據,通常狀況下不會直接調用API,而如今不能夠,由於咱們的庫和微服務都已經把它分離開了。因此如今的溝通方式產生了一個變化,當咱們須要一個功能或數據,都是去調別人的API。

管理模式會產生變化。由於原來單體的時候,研發作項目技術管理有兩種形態,第一種是老闆盯着員工幹活(氣死型),第二種是老闆拉着團隊幹活(累死型)。咱們是但願能夠造成一個自主執行的團隊,老闆給員工指明一條路,你們自發地去幹。

你們的職責劃分很是明確,咱們是一個自組織性的團隊。咱們是微服務的主人,要對微服務負百分之一百的責任,造成一種責任感。

對風險的控制。咱們不要作一個單體系統,單體系統會致使風險在整個系統的範圍內流竄,只要把這個系統把它拆小,把它簡單化了,就可以在某一些小的範圍裏面來控制這些風險。

知識的積累。咱們原來是用共享庫的形式,但弊端很明顯,它的版本升級、前端頁面、非功能需求都沒法實現。咱們如今能夠以完整的微服務形式來進行知識的積累。

亞馬遜創始人在2002年的時候就說,全部團隊的模塊都要以Service Interface的方式將數據和功能開放出來。不這麼作的人會被炒魷魚。

咱們採用的微服務架構技術

持續部署

咱們在作的時候用了Jenkins的API來調用運維平臺,而後運維平臺裏會發命令來調用docker的API。

環境遷移

在開發環境上,咱們開發了一個程序包,開發人員作完測試之後,咱們須要去往測試環境上遷移。

咱們把開發環境上作出了一個鏡像,而後把它推向docker registry,在測試環境裏就能夠把它拉下來,測試人員直接測。

在這個過程中,最開始的時候是在開發環境上,開發人員測試完了之後就不再會用到Jenkins,這個時候都是以鏡像來進行遷移,後面到生產環境也是同樣,這叫不可變的遷移。


API

微服務不少都提供了API,這就要牽涉到API的安全。微服務開發出來的API通常狀況下會有兩個用途,一個是給本身內部的其餘業務模塊來調用,一種是對外提供服務,給咱們的合做夥伴調用。


微服務監控

Diamond主要用來是對數據庫指標和主機指標來進行採集。爲了後期維護和升級的方便,咱們選擇了Diamond。

第二個就是Flume。咱們主要用它來對日誌進行分析。

第三個是Metrics。主要是對JVM的指標進行檢查。

最後一個就是Cadvisor。是google的容器監控工具。


我我的以爲若是咱們選擇這些小小的監控組件,靈活性會更高。

API的管理及測試

假若有二十個微服務,一個訂單模塊要被商品模塊調用,那它要知道有哪些API以及API的參數是什麼,參數的含義是什麼。有兩種作法,第一種就是寫文檔,可是這種作法出現的問題是代碼和文檔不一致。因此咱們選擇了swagger。第一不用寫文檔,第二它用別人的API的時候變得方便了,由於swagger能夠自動生成一個API的頁面,很是好用。API測試用的是rest-assured。

API調用

這是指微服務之間的API調用。咱們選擇的是Eureka、Ribbon、RestTemplate和DCTrace,DCTtrace是咱們自主研發的調用鏈管理模塊。

API安全

API對內部來講,好比寫了20個微服務,那麼門戶或者移動端要來調動這些API,該怎麼調用呢?咱們寫了一個叫門戶後端的模塊,它根據路由的規則把請求轉發到路徑指定的微服務的API。


微服務整合

咱們在用戶管理和權限管理的基礎上加入了模塊管理,用戶看到的就是一個總體的系統。

總結

我以爲微服務架構是技術升級,可是若是咱們的管理管理方法或者領導的管理、支持不跟上的話,微服務也是比較難作的。由於它的溝通方式、團隊的組織形式或是對團隊的要求都已經在產生變化,因此你們要作微服務架構首先要獲得領導的支持。

謝謝你們!

相關文章
相關標籤/搜索