小編一哥們和我吐槽自家的煩惱
原本一個有錢有閑的證券行業IT經理
一年前被老闆派去支援創新業務探索
因為新型業務在不斷加速鋪開
目前的單體式應用複雜度越來越高
業務上線過程繁瑣、流程冗長
資源配置設定耗時較多
更新頻率越來越低
人員也越來越顯得捉襟見肘
這哥們于是開始了加班第一、女票第二的人生
把自己都當成牲口使喚
還是免不了遭到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的遷移之路