編輯：IT大咖說 閱讀字數：2265
摘要
如今微服務如日中天，優勢和弊端也有各種描述，那麼我們是否應該採用微服務架構？如何規避微服務的弊端，放大微服務優勢？如何在先進性和實用性中作出平衡，順利落地？
嘉賓演講視訊地址：t.cn/RKJFQLZ
什麼是微服務架構？
微服務 ≈ 模組化開發 + 分散式計算
微服務架構帶來的好處
我認為微服務架構帶來了兩個好處。第一個好處就是降低了系統的複雜度，第二個是提升了我們的開發效率。
前一段時間我們在決定來做微服務架構的過程中做了很多的調研。
微服務看起來很好，有沒有給團隊帶來麻煩？
微服務自身的問題其實也很明顯。第一個是上手難度大，第二個問題就是部署包變多，以及多個小服務如何組裝成一個大系統，還有微服務之間的依賴關係錯綜複雜，該如何管理。
這些都是微服務是逃避不開的問題。我在論壇上看到過一句話，開發覺得微服務是個好架構，但是運維不這麼認為。我認為沒有一個很好的技術體系的支撐，就不要輕易地採用服務。
如何緩解微服務架構帶來的弊端
能力支撐
首先我們要提供一個能力的支撐。所謂能力的支撐就是要把基礎元件全部提供給業務開發部門。
其次我們要提供完善的運維支撐平臺和監控體系。
當平臺研發團隊對業務團隊進行支撐的時候，他們在使用微服務架構的過程當中有任何問題，我們都能為他們提供一個良好的支撐。
自動化
一鍵釋出單個微服務。在一個專案當中可能有二三十個微服務，我們要把每一個微服務都能夠一鍵釋出。
第二要是要一鍵釋出整個系統。因為有時需要重啟整個系統，這個時候就要能一鍵釋出整個系統。
什麼樣的系統需要採用微服務
我認為第一規模要大，是指人員多，或是程式碼函式多。
第二個就是複雜度高，是指業務複雜，比如金融系統。
第三需要長期演進。如果是單體的，可以在演進過程中打上層層補丁。我們使用微服務把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。
微服務整合
我們在使用者管理和許可權管理的基礎上加入了模組管理，使用者看到的就是一個整體的系統。
總結
我覺得微服務架構是技術升級，但是如果我們的管理管理方法或者領導的管理、支援不跟上的話，微服務也是比較難做的。因為它的溝通方式、團隊的組織形式或是對團隊的要求都已經在產生變化，所以大家要做微服務架構首先要得到領導的支援。
謝謝大家！