又讓馬兒跑又不讓吃草，微服務化如何完成低成本改造？

小編一哥們和我吐槽自家的煩惱
本來一個有錢有閒的證券行業IT經理
一年前被老闆派去支持創新業務探索
由於新型業務在不斷加速鋪開
當前的單體式應用複雜度愈來愈高
業務上線過程繁瑣、流程冗長
資源分配耗時較多
更新頻率愈來愈低
人員也愈來愈顯得捉襟見肘

這哥們因而開始了加班第1、女票第二的人生
把本身都當成牲口使喚
仍是免不了遭到Boss痛批：
業務需求響應速度像烏龜同樣
一個小問題也會影響整個大項目
嚴重拖了公司業務創新的後腿

Boss參考同行後給他佈置了一項新任務——
在低成本、不影響業務的前提下試水微服務化

抱怨Boss既讓馬兒跑又不讓馬兒吃草的同時
哥們第一時間就想到了主流開源方案
因而整天啃Spring Clouod甚至到了不問女票的程度
小編不能眼看哥們在注孤生的道路上越走越遠
決心挽救他
身後站着網易雲輕舟微服務的衆多大神
就是這麼自信
其實
這也不是個別問題
當微服務成爲數字化轉型升級的鑰匙
不少企業都想微服務化以爭取（或是保持）行業領先地位
如何實現前沿技術與企業業務的融合
就成了每一位微服務項目負責人的煩惱
解決這個難題固然要從企業的困惑提及

企業微服務化的困惑

企業對於微服務化較爲廣泛的困惑 
第一是 微服務技術複雜 
 
且不說包括容器化、DevOps、微服務監控的全家桶 
單看核心的服務治理 
昨天Dubbo今天Spring Cloud明天Service Mesh 
組件衆多且學習曲線陡峭 
對於傳統企業IT團隊來講實在強人所難 
不知道從何處下手 
何況企業承擔人力成本是爲了業務而非學習 
第二是 微服務收益難以預估 
 

  
微服務技術來自互聯網領域 
誘惑是規避單體應用的笨拙 
經過分而治之來提升市場響應效率 
單個服務的開發運維成本大幅下降 
甚至新人也能夠快速上手項目 
但傳統企業狀況不一樣 
微服務如此複雜的體系 
若實施不力設計不合理 
總體複雜度的增長是妥妥的 
會出現畫虎不成反類犬的尷尬 
再吸取經驗從新調整 
所耗費的時間和人力也是難以預估的 
第三是 預算有限 
 
IT預算總體縮減的背景下 
收益不肯定的項目的預算就更不用說 
容易缺少長遠的規劃 
因此，企業對微服務的要求是 
好用+易上手+低成本 
好用是能知足各類功能和非功能性需求 
易上手是指不須要團隊太多的額外學習 
低成本不只僅指引入平臺的採購成本 
也包括使用和維護成本 
Java比較6的哥們，半個月都搞不定Spring Cloud 
其實就算搞懂了Spring Cloud社區版本 
項目也是須要從新修改業務代碼的 
這就是所謂的「侵入式框架」 
也是高昂的成本 
 

引領微服務化的策略

小編和網易雲輕舟微服務大神們聊事後 
總結了企業實施微服務化的通用策略 
首先是 戰略層面 
如同10年前將信息化做爲一把手工程 
明確應用架構非微服務不可的前提下 
企業必須讓管理層掛帥推進微服務化 

  
 

  
由於微服務做爲實現DevOps、雲原生的方法 
不只僅是一個技術問題 
牽扯到IT架構、應用架構和組織架構 
單靠開發團隊或者運維團隊是沒法完成的 
須要打通組織、流程 
 
戰略目標及相關預算的制定 
最好邀請了解行業、精通技術的專家參與 
同時 要明確微服務化是一個漸進的過程 
不可能一蹴而就 
 
事實上 
網易業務也是處在不斷拆分和組合中 
 
其次是 戰術層面 
要牢抓 「一個核心、兩個關鍵、三類工具」 
一個核心是指實現DevOps爲業務提速 
DevOps是微服務化的核心目標和重要保證 
若是不考慮DevOps 
就沒法解決哥們遇到的那些問題 
微服務化對業務仍是沒有實際意義 
若是沒有持續集成/持續交付（CI/CD）、自動化測試 
若是開發團隊不承擔環境配置之類的運維工做 
微服務化就會由於引入複雜性而失敗 
圍繞這個核心 
須要明確微服務架構設計工做的全貌 
有了全局的觀念 
才能正確規劃微服務化的步驟 
根據網易雲首席架構師劉超的分享 
微服務的實施須要解決以下12個具體問題 

兩個關鍵之一：業務拆分 
高內聚低耦合的拆分原則 
本質是單一職責和職責分離 
首先必須定義好服務邊界 
全新設計的系統的重點 
是業務邊界肯定和服務間的通訊方式 
對於邊界不直觀的業務 
宜合不宜拆，宜緩不宜急 
而現有系統的服務化改造 
要重點關注系統架構的平滑過渡 
也就是實現「開着飛機換引擎」 
平滑過渡須要逐步改造 
 
兩個關鍵之二：服務治理 
大量小服務有序、穩定地合做 
背後必須有過硬的服務治理能力 
要認清微服務化的3個階段： 
以服務註冊/發現爲標誌的1.0階段 
以熔斷/限流/降級爲標誌的2.0階段 
以Service Mesh（服務網格）爲標誌的3.0階段 
目前有意實施微服務的傳統企業 
基本都是在向1.0階段過渡 
傳統行業領頭羊則在向2.0階段過渡 
企業通常須要按部就班 
好比說 
Spring Cloud只支持Java編程語言 
Service Mesh支持多語言且對業務侵入性最小 
直接上Service Mesh不是更好嗎？ 
其實Service Mesh主流平臺Istio的設計 
是彌補Kubernetes容器平臺的微服務管理短板 
 
若是業務沒有完成容器化就上Service Mesh 
運維會工做那是至關的麻煩 
固然1.0以前也建議儘可能先無狀態化、容器化 
這樣能夠減小運維和持續集成的不少工做 
因此 
網易雲輕舟微服務平臺的設計 
治理框架同時支持Dubbo、Spring Cloud和Service Mesh 
基礎設施同時支持容器、虛擬機和裸機平臺 
大神們認爲這是「好用」的基礎之一 
三類工具包括治理&監控、容器雲和DevOps 
一個好用的微服務工具平臺 
應當知足微服務的核心和關鍵需求 
最終要可以一站式hold住12個要點 
隨着微服務的拆分 
只有 服務治理還不夠 
須要 全鏈路監控協助發現瓶頸、定位故障 
其將來是 AIOps（智能化運維） 

DevOps不只須要 CI/CD、自動化測試 
也須要 容器雲平臺的支撐 
易用的微服務平臺 
應當是背靠專業服務的成熟產品 
經過單一圖形化解決完成應用的管控 
儘可能消除微服務帶來的複雜性 
讓企業可以專一於業務 
低成本的微服務平臺 
應當實現微服務治理框架和用戶業務的鬆耦合 
好比網易雲輕舟微服務平臺 
針對2.0階段的服務治理框架 
基於Spring Cloud打造 
經過Java Agent動態字節碼加強黑科技 
實現了代碼無侵入式的部署升級方案 
 
也就是說 
無需二次修改就能把老應用改形成新的微服務 
而且兼容Dubbo應用 
這就實現了真正的低成本 
固然 
肯定微服務技術平臺打造三類工具以後 
在微服務化過程當中還有不少的細節問題 
好比服務調用失敗的處理 
企業須要不斷學習業界先進的方法 
這方面社區有不少最佳實踐能夠參考 

小結

實施微服務是爲了提升效率下降成本 
一切不能降本增效的微服務都是耍流氓 
開源開放是當前業界的主流選擇 
但基於開源、門檻低、無侵入、功能完善的平臺 
才能讓企業真正實現低成本的微服務化 
快速解決業務痛點 
經過技術紅利促進企業的發展 
這也是 網易雲輕舟微服務平臺的設計理念

相關文章：
【推薦】 OpenResty 最佳實踐 （2）
【推薦】 pdfjs viewer 開發小結
【推薦】 jQuery到Vue的遷移之路