編輯:IT大咖說 閱讀字數:2265 html
現在微服務如日中天,優點和弊端也有各類描述,那麼咱們是否應該採用微服務架構?如何規避微服務的弊端,放大微服務優點?如何在先進性和實用性中做出平衡,順利落地?
前端
嘉賓演講視頻地址:t.cn/RKJFQLZdocker
微服務 ≈ 模塊化開發 + 分佈式計算數據庫
我認爲微服務架構帶來了兩個好處。第一個好處就是下降了系統的複雜度,第二個是提高了咱們的開發效率。後端
前一段時間咱們在決定來作微服務架構的過程當中作了不少的調研。安全
微服務自身的問題其實也很明顯。第一個是上手難度大,第二個問題就是部署包變多,以及多個小服務如何組裝成一個大系統,還有微服務之間的依賴關係錯綜複雜,該如何管理。架構
這些都是微服務是逃避不開的問題。我在論壇上看到過一句話,開發以爲微服務是個好架構,可是運維不這麼認爲。我認爲沒有一個很好的技術體系的支撐,就不要輕易地採用服務。運維
首先咱們要提供一個能力的支撐。所謂能力的支撐就是要把基礎組件所有提供給業務開發部門。分佈式
其次咱們要提供完善的運維支撐平臺和監控體系。模塊化
當平臺研發團隊對業務團隊進行支撐的時候,他們在使用微服務架構的過程中有任何問題,咱們都能爲他們提供一個良好的支撐。
一鍵發佈單個微服務。在一個項目當中可能有二三十個微服務,咱們要把每個微服務都可以一鍵發佈。
第二要是要一鍵發佈整個系統。由於有時須要重啓整個系統,這個時候就要能一鍵發佈整個系統。
我認爲第一規模要大,是指人員多,或是代碼函數多。
第二個就是複雜度高,是指業務複雜,好比金融系統。
第三須要長期演進。若是是單體的,能夠在演進過程當中打上層層補丁。咱們使用微服務把bug控制在一個小範圍以內。
這三種狀況能夠考慮使用微服務架構。
原來咱們在進行溝通的時候,幾乎都是以數據的形式。好比兩我的在開發一個系統裏面的兩個模塊,當我要調你的功能都是去看你的數據,通常狀況下不會直接調用API,而如今不能夠,由於咱們的庫和微服務都已經把它分離開了。因此如今的溝通方式產生了一個變化,當咱們須要一個功能或數據,都是去調別人的API。
管理模式會產生變化。由於原來單體的時候,研發作項目技術管理有兩種形態,第一種是老闆盯着員工幹活(氣死型),第二種是老闆拉着團隊幹活(累死型)。咱們是但願能夠造成一個自主執行的團隊,老闆給員工指明一條路,你們自發地去幹。
你們的職責劃分很是明確,咱們是一個自組織性的團隊。咱們是微服務的主人,要對微服務負百分之一百的責任,造成一種責任感。
對風險的控制。咱們不要作一個單體系統,單體系統會致使風險在整個系統的範圍內流竄,只要把這個系統把它拆小,把它簡單化了,就可以在某一些小的範圍裏面來控制這些風險。
知識的積累。咱們原來是用共享庫的形式,但弊端很明顯,它的版本升級、前端頁面、非功能需求都沒法實現。咱們如今能夠以完整的微服務形式來進行知識的積累。
亞馬遜創始人在2002年的時候就說,全部團隊的模塊都要以Service Interface的方式將數據和功能開放出來。不這麼作的人會被炒魷魚。
咱們在作的時候用了Jenkins的API來調用運維平臺,而後運維平臺裏會發命令來調用docker的API。
在開發環境上,咱們開發了一個程序包,開發人員作完測試之後,咱們須要去往測試環境上遷移。
咱們把開發環境上作出了一個鏡像,而後把它推向docker registry,在測試環境裏就能夠把它拉下來,測試人員直接測。
在這個過程中,最開始的時候是在開發環境上,開發人員測試完了之後就不再會用到Jenkins,這個時候都是以鏡像來進行遷移,後面到生產環境也是同樣,這叫不可變的遷移。
微服務不少都提供了API,這就要牽涉到API的安全。微服務開發出來的API通常狀況下會有兩個用途,一個是給本身內部的其餘業務模塊來調用,一種是對外提供服務,給咱們的合做夥伴調用。
Diamond主要用來是對數據庫指標和主機指標來進行採集。爲了後期維護和升級的方便,咱們選擇了Diamond。
第二個就是Flume。咱們主要用它來對日誌進行分析。
第三個是Metrics。主要是對JVM的指標進行檢查。
最後一個就是Cadvisor。是google的容器監控工具。
我我的以爲若是咱們選擇這些小小的監控組件,靈活性會更高。
假若有二十個微服務,一個訂單模塊要被商品模塊調用,那它要知道有哪些API以及API的參數是什麼,參數的含義是什麼。有兩種作法,第一種就是寫文檔,可是這種作法出現的問題是代碼和文檔不一致。因此咱們選擇了swagger。第一不用寫文檔,第二它用別人的API的時候變得方便了,由於swagger能夠自動生成一個API的頁面,很是好用。API測試用的是rest-assured。
這是指微服務之間的API調用。咱們選擇的是Eureka、Ribbon、RestTemplate和DCTrace,DCTtrace是咱們自主研發的調用鏈管理模塊。
API對內部來講,好比寫了20個微服務,那麼門戶或者移動端要來調動這些API,該怎麼調用呢?咱們寫了一個叫門戶後端的模塊,它根據路由的規則把請求轉發到路徑指定的微服務的API。
咱們在用戶管理和權限管理的基礎上加入了模塊管理,用戶看到的就是一個總體的系統。
我以爲微服務架構是技術升級,可是若是咱們的管理管理方法或者領導的管理、支持不跟上的話,微服務也是比較難作的。由於它的溝通方式、團隊的組織形式或是對團隊的要求都已經在產生變化,因此你們要作微服務架構首先要獲得領導的支持。
謝謝你們!