內容來源：2017年4月22日，練海榮在“【滬江技術沙龍】 -- 漫談微服務架構實踐”進行《如何支撐微服務架構落地》演講分享。IT大咖說（id：itdakashuo）作為獨家視頻合作方，經(jīng)主辦方和講者審閱授權發(fā)布。

編輯：IT大咖說?

閱讀字數(shù)：2265?

摘要

如今微服務如日中天，優(yōu)勢和弊端也有各種描述，那么我們是否應該采用微服務架構？如何規(guī)避微服務的弊端，放大微服務優(yōu)勢？如何在先進性和實用性中作出平衡，順利落地？

嘉賓演講視頻回顧及PPT：http://suo.im/5axdNN

什么是微服務架構？

微服務 ≈ 模塊化開發(fā) + 分布式計算

微服務架構帶來的好處

我認為微服務架構帶來了兩個好處。第一個好處就是降低了系統(tǒng)的復雜度，第二個是提升了我們的開發(fā)效率。

前一段時間我們在決定來做微服務架構的過程中做了很多的調研。

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

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

這些都是微服務是逃避不開的問題。我在論壇上看到過一句話，開發(fā)覺得微服務是個好架構，但是運維不這么認為。我認為沒有一個很好的技術體系的支撐，就不要輕易地采用服務。

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

能力支撐

首先我們要提供一個能力的支撐。所謂能力的支撐就是要把基礎組件全部提供給業(yè)務開發(fā)部門。

其次我們要提供完善的運維支撐平臺和監(jiān)控體系。

當平臺研發(fā)團隊對業(yè)務團隊進行支撐的時候，他們在使用微服務架構的過程當中有任何問題，我們都能為他們提供一個良好的支撐。

自動化

一鍵發(fā)布單個微服務。在一個項目當中可能有二三十個微服務，我們要把每一個微服務都能夠一鍵發(fā)布。

第二要是要一鍵發(fā)布整個系統(tǒng)。因為有時需要重啟整個系統(tǒng)，這個時候就要能一鍵發(fā)布整個系統(tǒng)。

什么樣的系統(tǒng)需要采用微服務

我認為第一規(guī)模要大，是指人員多，或是代碼函數(shù)多。

第二個就是復雜度高，是指業(yè)務復雜，比如金融系統(tǒng)。

第三需要長期演進。如果是單體的，可以在演進過程中打上層層補丁。我們使用微服務把bug控制在一個小范圍之內。

這三種情況可以考慮使用微服務架構。

采用微服務架構后，如何正確的姿勢做技術管理

原來我們在進行溝通的時候，幾乎都是以數(shù)據(jù)的形式。比如兩個人在開發(fā)一個系統(tǒng)里面的兩個模塊，當我要調你的功能都是去看你的數(shù)據(jù)，一般情況下不會直接調用API，而現(xiàn)在不可以，因為我們的庫和微服務都已經(jīng)把它分離開了。所以現(xiàn)在的溝通方式產(chǎn)生了一個變化，當我們需要一個功能或數(shù)據(jù)，都是去調別人的API。

管理模式會產(chǎn)生變化。因為原來單體的時候，研發(fā)做項目技術管理有兩種形態(tài)，第一種是老板盯著員工干活（氣死型），第二種是老板拉著團隊干活（累死型）。我們是希望可以形成一個自主執(zhí)行的團隊，老板給員工指明一條路，大家自發(fā)地去干。

大家的職責劃分非常明確，我們是一個自組織性的團隊。我們是微服務的主人，要對微服務負百分之一百的責任，形成一種責任感。

對風險的控制。我們不要做一個單體系統(tǒng)，單體系統(tǒng)會導致風險在整個系統(tǒng)的范圍內流竄，只要把這個系統(tǒng)把它拆小，把它簡單化了，就能夠在某一些小的范圍里面來控制這些風險。

知識的積累。我們原來是用共享庫的形式，但弊端很明顯，它的版本升級、前端頁面、非功能需求都無法實現(xiàn)。我們現(xiàn)在可以以完整的微服務形式來進行知識的積累。

亞馬遜創(chuàng)始人在2002年的時候就說，所有團隊的模塊都要以Service Interface的方式將數(shù)據(jù)和功能開放出來。不這么做的人會被炒魷魚。

我們采用的微服務架構技術

持續(xù)部署

我們在做的時候用了Jenkins的API來調用運維平臺，然后運維平臺里會發(fā)命令來調用docker的API。

環(huán)境遷移

在開發(fā)環(huán)境上，我們開發(fā)了一個程序包，開發(fā)人員做完測試以后，我們需要去往測試環(huán)境上遷移。

我們把開發(fā)環(huán)境上做出了一個鏡像，然后把它推向docker registry，在測試環(huán)境里就可以把它拉下來，測試人員直接測。

在這個過程當中，最開始的時候是在開發(fā)環(huán)境上，開發(fā)人員測試完了以后就再也不會用到Jenkins，這個時候都是以鏡像來進行遷移，后面到生產(chǎn)環(huán)境也是一樣，這叫不可變的遷移。

API

微服務很多都提供了API，這就要牽涉到API的安全。微服務開發(fā)出來的API一般情況下會有兩個用途，一個是給自己內部的其他業(yè)務模塊來調用，一種是對外提供服務，給我們的合作伙伴調用。

微服務監(jiān)控

Diamond主要用來是對數(shù)據(jù)庫指標和主機指標來進行采集。為了后期維護和升級的方便，我們選擇了Diamond。

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

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

最后一個就是Cadvisor。是google的容器監(jiān)控工具。

我個人覺得如果我們選擇這些小小的監(jiān)控組件，靈活性會更高。

API的管理及測試

假如有二十個微服務，一個訂單模塊要被商品模塊調用，那它要知道有哪些API以及API的參數(shù)是什么，參數(shù)的含義是什么。有兩種做法，第一種就是寫文檔，但是這種做法出現(xiàn)的問題是代碼和文檔不一致。所以我們選擇了swagger。第一不用寫文檔，第二它用別人的API的時候變得方便了，因為swagger可以自動生成一個API的頁面，非常好用。API測試用的是rest-assured。

API調用

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

API安全

API對內部來說，比如寫了20個微服務，那么門戶或者移動端要來調動這些API，該怎么調用呢？我們寫了一個叫門戶后端的模塊，它根據(jù)路由的規(guī)則把請求轉發(fā)到路徑指定的微服務的API。

微服務整合

我們在用戶管理和權限管理的基礎上加入了模塊管理，用戶看到的就是一個整體的系統(tǒng)。

總結

我覺得微服務架構是技術升級，但是如果我們的管理管理方法或者領導的管理、支持不跟上的話，微服務也是比較難做的。因為它的溝通方式、團隊的組織形式或是對團隊的要求都已經(jīng)在產(chǎn)生變化，所以大家要做微服務架構首先要得到領導的支持。謝謝大家！