如何支撐微服務架構落地

時間 2019-12-01

標籤如何支撐微服架構落地欄目系統架構简体版

原文原文鏈接

內容來源：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。