如今微服務如日中天，優勢和弊端也有各種描述，那麼我們是否應該採用微服務架構？如何規避微服務的弊端，放大微服務優勢？如何在先進性和實用性中作出平衡，順利落地？
t.cn/rkjfqlz
微服務 ≈ 模組化開發 + 分布式計算
我認為微服務架構帶來了兩個好處。第乙個好處就是降低了系統的複雜度，第二個是提公升了我們的開發效率。
前一段時間我們在決定來做微服務架構的過程中做了很多的調研。
微服務自身的問題其實也很明顯。第乙個是上手難度大，第二個問題就是部署包變多，以及多個小服務如何組裝成乙個大系統，還有微服務之間的依賴關係錯綜複雜，該如何管理。
這些都是微服務是逃避不開的問題。我在論壇上看到過一句話，開發覺得微服務是個好架構，但是運維不這麼認為。我認為沒有乙個很好的技術體系的支撐，就不要輕易地採用服務。
首先我們要提供乙個能力的支撐。所謂能力的支撐就是要把基礎元件全部提供給業務開發部門。
其次我們要提供完善的運維支撐平台和監控體系。
當平台研發團隊對業務團隊進行支撐的時候，他們在使用微服務架構的過程當中有任何問題，我們都能為他們提供乙個良好的支撐。
一鍵發布單個微服務。在乙個專案當中可能有二三十個微服務，我們要把每乙個微服務都能夠一鍵發布。
第二要是要一鍵發布整個系統。因為有時需要重啟整個系統，這個時候就要能一鍵發布整個系統。
我認為第一規模要大，是指人員多，或是**函式多。
第二個就是複雜度高，是指業務複雜，比如金融系統。
第三需要長期演進。如果是單體的，可以在演進過程中打上層層補丁。我們使用微服務把bug控制在乙個小範圍之內。
這三種情況可以考慮使用微服務架構。
原來我們在進行溝通的時候，幾乎都是以資料的形式。比如兩個人在開發乙個系統裡面的兩個模組，當我要調你的功能都是去看你的資料，一般情況下不會直接呼叫api，而現在不可以，因為我們的庫和微服務都已經把它分離開了。所以現在的溝通方式產生了乙個變化，當我們需要乙個功能或資料，都是去調別人的api。
管理模式會產生變化。因為原來單體的時候，研發做專案技術管理有兩種形態，第一種是老闆盯著員工幹活（氣死型），第二種是老闆拉著團隊幹活（累死型）。我們是希望可以形成乙個自主執行的團隊，老闆給員工指明一條路，大家自發地去幹。
大家的職責劃分非常明確，我們是乙個自組織性的團隊。我們是微服務的主人，要對微服務負百分之一百的責任，形成一種責任感。
對風險的控制。我們不要做乙個單體系統，單體系統會導致風險在整個系統的範圍內流竄，只要把這個系統把它拆小，把它簡單化了，就能夠在某一些小的範圍裡面來控制這些風險。
知識的積累。我們原來是用共享庫的形式，但弊端很明顯，它的版本公升級、前端頁面、非功能需求都無法實現。我們現在可以以完整的微服務形式來進行知識的積累。
亞馬遜創始人在2023年的時候就說，所有團隊的模組都要以service inte***ce的方式將資料和功能開放出來。不這麼做的人會被炒魷魚。
我們在做的時候用了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。
我們在使用者管理和許可權管理的基礎上加入了模組管理，使用者看到的就是乙個整體的系統。
我覺得微服務架構是技術公升級，但是如果我們的管理管理方法或者領導的管理、支援不跟上的話，微服務也是比較難做的。因為它的溝通方式、團隊的組織形式或是對團隊的要求都已經在產生變化，所以大家要做微服務架構首先要得到領導的支援。
謝謝大家！
微服務架構的中國式落地
服務註冊發現eureka ribbon 服務配置中心apollo 認證授權中心spring security oauth2 服務框架spring mvc boot 日誌監控elk 呼叫鏈監控cat metrics監控kairosdb 健康檢查和告警zmon 限流熔斷和流聚合hystrix turbi...
買單俠以微服務架構支撐企業成長
現如今，企業架構微服務已然成為一種趨勢。儘管面臨缺少微服務相關的技術人才和程式設計客棧足夠的認識的問題，還是投入大量人力物力企圖實現系統微服務化，不過在這種沒有規劃的投入下，建設的新系統往往不但沒有實現微服務設計反而失去了原本的優勢。儘管失敗的案例很多，但是還是有很多新生企業努力向微服務架構前進。從...
如何實現微服務架構
一 技術選型 相對單體應用的交付，微服務應用交付要複雜得多，不僅需要開發框架支援，還需要一些自動化部署的工具，以及iaas paas或caas的支援。下面從開發和執行平台兩個維度考慮挑選技術選型 1 開發框架的選擇 可使用spring cloud作為微服務開發框架。首先，spring cloud具備...