摘要:小編一哥們和我吐槽自家的煩惱原本一個有錢有閑的證券行業經理一年前被老板派去支持創新業務探索因為新型業務在不斷加速鋪開當前的單體式應用復雜度越來越高業務上線過程繁瑣流程冗長資源分配耗時較多更新頻率越來越低人員也越來越顯得捉襟見肘這哥們于是開始
小編一哥們和我吐槽自家的煩惱
原本一個有錢有閑的證券行業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應用
這就實現了真正的低成本
當然
確定微服務技術平臺打造三類工具之后
在微服務化過程中還有很多的細節問題
比如服務調用失敗的處理
企業需要不斷學習業界先進的方法
這方面社區有很多最佳實踐可以參考
小結
實施微服務是為了提高效率降低成本
一切不能降本增效的微服務都是耍流氓
開源開放是當前業界的主流選擇
但基于開源、門檻低、無侵入、功能完善的平臺
才能讓企業真正實現低成本的微服務化
快速解決業務痛點
通過技術紅利促進企業的發展
這也是 網易云輕舟微服務平臺的設計理念
文章來源: 網易云社區
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://m.specialneedsforspecialkids.com/yun/25471.html
摘要:前端娛樂圈這些年前端有點熱鬧。刷量,撕,版本帝想要混前端,除了要有足夠強的學習力。領導說所有測試的都要先指派給前端,前端查清原因后再指給當事人。年,前端不再只是切圖仔。 ? 前端娛樂圈 這些年前端有點熱鬧。 github刷量,vue撕x,版本帝angularJs...... showImg(https://segmentfault.com/img/remote/146000001937...
摘要:為什么說怪呢,人多力量大,似乎才符合常理,但是往往在軟件項目開展的過程中會出現人多事少工作量大的情況,這跟我們以往的認知大相徑庭。 本文所要分享的是軟件開發過程中,親身經歷過的怪現象。為什么說怪呢,人多力量大,似乎才符合常理,但是往往在軟件項目開展的過程中會出現人多、事少、工作量大的情況,這跟我們以往的認知大相徑庭。 showImg(https://segmentfault.com/i...
摘要:以推出輕舟微服務平臺的網易云為代表,云計算公司正在微服務領域發力,促進企業數字化創新。以網易云輕舟微服務平臺為例,該平臺已經在物流工業和金融等領域得到了深度應用。 所謂數字化轉型升級,就是以數字技術優化傳統資源,企業需要謹慎地選擇合適的技術逐步完成自己的數字化戰略。以推出輕舟微服務平臺的網易云為代表,云計算公司正在微服務領域發力,促進企業數字化創新。那么,微服務對數字化轉型意味著什么?...
摘要:筆者對微服務系統的觀點是,我們從單體系統向微服務系統改造的過程中,需要認真思考什么階段使用微服務。此外,為了解決服務部署,我們可以考慮通過滾動發布來實現服務的無中斷。事實上,微服務保證其服務的整體可用性。 原文地址:梁桂釗的博客博客地址:http://blog.720ui.com 歡迎關注公眾號:「服務端思維」。一群同頻者,一起成長,一起精進,打破認知的局限性。 一、逃離單體系統,...
閱讀 1407·2021-11-08 13:14
閱讀 762·2021-09-23 11:31
閱讀 1052·2021-07-29 13:48
閱讀 2792·2019-08-29 12:29
閱讀 3387·2019-08-29 11:24
閱讀 1912·2019-08-26 12:02
閱讀 3709·2019-08-26 10:34
閱讀 3450·2019-08-23 17:07