摘要：小編一哥們和我吐槽自家的煩惱原本一個(gè)有錢有閑的證券行業(yè)經(jīng)理一年前被老板派去支持創(chuàng)新業(yè)務(wù)探索因?yàn)樾滦蜆I(yè)務(wù)在不斷加速鋪開當(dāng)前的單體式應(yīng)用復(fù)雜度越來越高業(yè)務(wù)上線過程繁瑣流程冗長(zhǎng)資源分配耗時(shí)較多更新頻率越來越低人員也越來越顯得捉襟見肘這哥們于是開始

小編一哥們和我吐槽自家的煩惱
原本一個(gè)有錢有閑的證券行業(yè)IT經(jīng)理
一年前被老板派去支持創(chuàng)新業(yè)務(wù)探索
因?yàn)樾滦蜆I(yè)務(wù)在不斷加速鋪開
當(dāng)前的單體式應(yīng)用復(fù)雜度越來越高
業(yè)務(wù)上線過程繁瑣、流程冗長(zhǎng)
資源分配耗時(shí)較多
更新頻率越來越低
人員也越來越顯得捉襟見肘

這哥們于是開始了加班第一、女票第二的人生
把自己都當(dāng)成牲口使喚
還是免不了遭到Boss痛批：
業(yè)務(wù)需求響應(yīng)速度像烏龜一樣
一個(gè)小問題也會(huì)影響整個(gè)大項(xiàng)目
嚴(yán)重拖了公司業(yè)務(wù)創(chuàng)新的后腿

Boss參考同行后給他布置了一項(xiàng)新任務(wù)——
在低成本、不影響業(yè)務(wù)的前提下試水微服務(wù)化

抱怨Boss既讓馬兒跑又不讓馬兒吃草的同時(shí)
哥們第一時(shí)間就想到了主流開源方案
于是成天啃Spring Clouod甚至到了不問女票的程度
小編不能眼看哥們?cè)谧⒐律牡缆飞显阶咴竭h(yuǎn)
決心挽救他
身后站著網(wǎng)易云輕舟微服務(wù)的眾多大神
就是這么自信
其實(shí)
這也不是個(gè)別問題
當(dāng)微服務(wù)成為數(shù)字化轉(zhuǎn)型升級(jí)的鑰匙
很多企業(yè)都想微服務(wù)化以爭(zhēng)?。ɑ蚴潜３郑┬袠I(yè)領(lǐng)先地位
如何實(shí)現(xiàn)前沿技術(shù)與企業(yè)業(yè)務(wù)的融合
就成了每一位微服務(wù)項(xiàng)目負(fù)責(zé)人的煩惱
解決這個(gè)難題當(dāng)然要從企業(yè)的困惑說起

企業(yè)微服務(wù)化的困惑
企業(yè)對(duì)于微服務(wù)化較為普遍的困惑
第一是 微服務(wù)技術(shù)復(fù)雜

且不說包括容器化、DevOps、微服務(wù)監(jiān)控的全家桶
單看核心的服務(wù)治理
昨天Dubbo今天Spring Cloud明天Service Mesh
組件眾多且學(xué)習(xí)曲線陡峭
對(duì)于傳統(tǒng)企業(yè)IT團(tuán)隊(duì)來說實(shí)在強(qiáng)人所難
不知道從何處下手
況且企業(yè)承擔(dān)人力成本是為了業(yè)務(wù)而非學(xué)習(xí)
第二是 微服務(wù)收益難以預(yù)估

微服務(wù)技術(shù)來自互聯(lián)網(wǎng)領(lǐng)域
誘惑是規(guī)避單體應(yīng)用的笨拙
通過分而治之來提高市場(chǎng)響應(yīng)效率
單個(gè)服務(wù)的開發(fā)運(yùn)維成本大幅降低
甚至新人也可以快速上手項(xiàng)目
但傳統(tǒng)企業(yè)情況不同
微服務(wù)如此復(fù)雜的體系
若實(shí)施不力設(shè)計(jì)不合理
整體復(fù)雜度的增加是妥妥的
會(huì)出現(xiàn)畫虎不成反類犬的尷尬
再吸收經(jīng)驗(yàn)重新調(diào)整
所耗費(fèi)的時(shí)間和人力也是難以預(yù)估的
第三是 預(yù)算有限

IT預(yù)算整體縮減的背景下
收益不確定的項(xiàng)目的預(yù)算就更不用說
容易缺乏長(zhǎng)遠(yuǎn)的規(guī)劃
所以，企業(yè)對(duì)微服務(wù)的要求是
好用+易上手+低成本
好用是能滿足各種功能和非功能性需求
易上手是指不需要團(tuán)隊(duì)太多的額外學(xué)習(xí)
低成本不僅僅指引入平臺(tái)的采購(gòu)成本
也包括使用和維護(hù)成本
Java比較6的哥們，半個(gè)月都搞不定Spring Cloud
其實(shí)就算搞懂了Spring Cloud社區(qū)版本
項(xiàng)目也是需要重新修改業(yè)務(wù)代碼的
這就是所謂的“侵入式框架”
也是高昂的成本

引領(lǐng)微服務(wù)化的策略
小編和網(wǎng)易云輕舟微服務(wù)大神們聊過后
總結(jié)了企業(yè)實(shí)施微服務(wù)化的通用策略
首先是 戰(zhàn)略層面
如同10年前將信息化作為一把手工程
明確應(yīng)用架構(gòu)非微服務(wù)不可的前提下
企業(yè)必須讓管理層掛帥推動(dòng)微服務(wù)化

因?yàn)槲⒎?wù)作為實(shí)現(xiàn)DevOps、云原生的方法
不僅僅是一個(gè)技術(shù)問題
牽扯到IT架構(gòu)、應(yīng)用架構(gòu)和組織架構(gòu)
單靠開發(fā)團(tuán)隊(duì)或者運(yùn)維團(tuán)隊(duì)是無法完成的
需要打通組織、流程

戰(zhàn)略目標(biāo)及相關(guān)預(yù)算的制定
最好邀請(qǐng)了解行業(yè)、精通技術(shù)的專家參與
同時(shí) 要明確微服務(wù)化是一個(gè)漸進(jìn)的過程
不可能一蹴而就

事實(shí)上
網(wǎng)易業(yè)務(wù)也是處在不斷拆分和組合中

其次是 戰(zhàn)術(shù)層面
要牢抓 “一個(gè)核心、兩個(gè)關(guān)鍵、三類工具”
一個(gè)核心是指實(shí)現(xiàn)DevOps為業(yè)務(wù)提速
DevOps是微服務(wù)化的核心目標(biāo)和重要保證
如果不考慮DevOps
就無法解決哥們遇到的那些問題
微服務(wù)化對(duì)業(yè)務(wù)還是沒有實(shí)際意義
如果沒有持續(xù)集成/持續(xù)交付（CI/CD）、自動(dòng)化測(cè)試
如果開發(fā)團(tuán)隊(duì)不承擔(dān)環(huán)境配置之類的運(yùn)維工作
微服務(wù)化就會(huì)因?yàn)橐霃?fù)雜性而失敗
圍繞這個(gè)核心
需要明確微服務(wù)架構(gòu)設(shè)計(jì)工作的全貌
有了全局的觀念
才能正確規(guī)劃微服務(wù)化的步驟
根據(jù)網(wǎng)易云首席架構(gòu)師劉超的分享
微服務(wù)的實(shí)施需要解決如下12個(gè)具體問題

兩個(gè)關(guān)鍵之一：業(yè)務(wù)拆分
高內(nèi)聚低耦合的拆分原則
本質(zhì)是單一職責(zé)和職責(zé)分離
首先必須定義好服務(wù)邊界
全新設(shè)計(jì)的系統(tǒng)的重點(diǎn)
是業(yè)務(wù)邊界確定和服務(wù)間的通信方式
對(duì)于邊界不直觀的業(yè)務(wù)
宜合不宜拆，宜緩不宜急
而現(xiàn)有系統(tǒng)的服務(wù)化改造
要重點(diǎn)關(guān)注系統(tǒng)架構(gòu)的平滑過渡
也就是實(shí)現(xiàn)“開著飛機(jī)換引擎”
平滑過渡需要逐步改造

兩個(gè)關(guān)鍵之二：服務(wù)治理
大量小服務(wù)有序、穩(wěn)定地合作
背后必須有過硬的服務(wù)治理能力
要認(rèn)清微服務(wù)化的3個(gè)階段：
以服務(wù)注冊(cè)/發(fā)現(xiàn)為標(biāo)志的1.0階段
以熔斷/限流/降級(jí)為標(biāo)志的2.0階段
以Service Mesh（服務(wù)網(wǎng)格）為標(biāo)志的3.0階段
目前有意實(shí)施微服務(wù)的傳統(tǒng)企業(yè)
基本都是在向1.0階段過渡
傳統(tǒng)行業(yè)領(lǐng)頭羊則在向2.0階段過渡
企業(yè)一般需要循序漸進(jìn)
比如說
Spring Cloud只支持Java編程語(yǔ)言
Service Mesh支持多語(yǔ)言且對(duì)業(yè)務(wù)侵入性最小
直接上Service Mesh不是更好嗎？
其實(shí)Service Mesh主流平臺(tái)Istio的設(shè)計(jì)
是彌補(bǔ)Kubernetes容器平臺(tái)的微服務(wù)管理短板

如果業(yè)務(wù)沒有完成容器化就上Service Mesh
運(yùn)維會(huì)工作那是相當(dāng)?shù)穆闊?
當(dāng)然1.0之前也建議盡量先無狀態(tài)化、容器化
這樣可以減少運(yùn)維和持續(xù)集成的很多工作
所以
網(wǎng)易云輕舟微服務(wù)平臺(tái)的設(shè)計(jì)
治理框架同時(shí)支持Dubbo、Spring Cloud和Service Mesh
基礎(chǔ)設(shè)施同時(shí)支持容器、虛擬機(jī)和裸機(jī)平臺(tái)
大神們認(rèn)為這是“好用”的基礎(chǔ)之一
三類工具包括治理&監(jiān)控、容器云和DevOps
一個(gè)好用的微服務(wù)工具平臺(tái)
應(yīng)當(dāng)滿足微服務(wù)的核心和關(guān)鍵需求
最終要能夠一站式hold住12個(gè)要點(diǎn)
隨著微服務(wù)的拆分
只有 服務(wù)治理還不夠
需要 全鏈路監(jiān)控協(xié)助發(fā)現(xiàn)瓶頸、定位故障
其未來是 AIOps（智能化運(yùn)維）

DevOps不僅需要 CI/CD、自動(dòng)化測(cè)試
也需要 容器云平臺(tái)的支撐
易用的微服務(wù)平臺(tái)
應(yīng)當(dāng)是背靠專業(yè)服務(wù)的成熟產(chǎn)品
通過單一圖形化解決完成應(yīng)用的管控
盡量消除微服務(wù)帶來的復(fù)雜性
讓企業(yè)能夠?qū)Ｗ⒂跇I(yè)務(wù)
低成本的微服務(wù)平臺(tái)
應(yīng)當(dāng)實(shí)現(xiàn)微服務(wù)治理框架和用戶業(yè)務(wù)的松耦合
比如網(wǎng)易云輕舟微服務(wù)平臺(tái)
針對(duì)2.0階段的服務(wù)治理框架
基于Spring Cloud打造
通過Java Agent動(dòng)態(tài)字節(jié)碼增強(qiáng)黑科技
實(shí)現(xiàn)了代碼無侵入式的部署升級(jí)方案

也就是說
無需二次修改就能把老應(yīng)用改造成新的微服務(wù)
并且兼容Dubbo應(yīng)用
這就實(shí)現(xiàn)了真正的低成本
當(dāng)然
確定微服務(wù)技術(shù)平臺(tái)打造三類工具之后
在微服務(wù)化過程中還有很多的細(xì)節(jié)問題
比如服務(wù)調(diào)用失敗的處理
企業(yè)需要不斷學(xué)習(xí)業(yè)界先進(jìn)的方法
這方面社區(qū)有很多最佳實(shí)踐可以參考

小結(jié)
實(shí)施微服務(wù)是為了提高效率降低成本
一切不能降本增效的微服務(wù)都是耍流氓
開源開放是當(dāng)前業(yè)界的主流選擇
但基于開源、門檻低、無侵入、功能完善的平臺(tái)
才能讓企業(yè)真正實(shí)現(xiàn)低成本的微服務(wù)化
快速解決業(yè)務(wù)痛點(diǎn)
通過技術(shù)紅利促進(jìn)企業(yè)的發(fā)展
這也是 網(wǎng)易云輕舟微服務(wù)平臺(tái)的設(shè)計(jì)理念

文章來源： 網(wǎng)易云社區(qū)