作者:彥林
本文整理自阿里云智能高級技術專家彥林的線上直播分享《云原生微服務最佳實踐》,視頻回放地址:https://yqh.aliyun.com/live/detail/28454
隨著云原生的演進,微服務作為主流應用架構被廣泛使用,其落地的難題逐步從如何建好延伸到如何用好,今天跟各位小伙伴分享一下我在微服務領域 10 余年的實踐經驗,如何以更高效的姿勢把微服務這件事做扎實,
阿里微服務發展歷程
微服務 1.0 (1w 實體/微服務拆分/同城容災)
2008 年隨著阿里業務規模不斷增大,單體胖應用+硬負載的架構逐漸暴露性能瓶頸;隨著研發人員逐步增多,協調效率也逐步下降,不能滿足日益復雜的業務挑戰,因此急需技術升級解決這些問題,

在當時 SOA 架構非常流行,也就成為我們技術演進的主要方向,當時有兩種解決方案,一個是 Server Based 的解決方案,這種模式侵入小、方便集中管控,但是這種中心化方案會帶來成本高、穩定性風險高、擴展性差;一個是 Client Based 的解決方案,這種模式去中心化,擴展性強,成本低,但是會帶來一定侵入性,比較難以管理;當然很多人會問為什么不直接用 DNS 呢?主要是 DNS 不能滿足 IDC 內部服務發現實時性,服務串列更新不能及時通知下有業務會導致業務流量損失,

在評估兩種方案利弊之后,我們在網關這種需要集中管理安全和簡單路由場景采用了 Server Based 的方案,基于 Nginx 演進出了阿里 Tengine 網關技術體系,從入口處解決安全、高可用、簡單路由能力;在 IDC 內部采用了 Client Base 模式,范訓出 HSF/Dubbo+Nacos 技術體系,支撐了業務微服務拆分,

隨著第一代微服務架構落地,由于引入注冊中心帶來了穩定性風險,注冊中心掛會導致呼叫鏈路全部中斷;業務集中發布的時候注冊中心壓力會比較大,

針對可用性問題我們提供了推空保護能力,即使注冊中心掛也不會影響業務正常運行;為了提供更好性能我們提供了全異步架構;為了支持同城容災我們提供了 AP 一致性協議,具體協議可以參考《Nacos 架構與原理》電子書,

隨著阿里微服務 1.0 架構落地,幫助業務完成微服務拆分,解決了擴展性和協同效率問題,同時支撐了阿里同城容災能力,對于正在做微服務的小伙伴可能問阿里如何做微服務架構演進的:
前后端分離是第一步,因為前端變化多,變化快,后端相對變化小,演進慢,因此需要解耦發展,讓前端更快的適應市場變化,以便在競爭中保持先機;
后端無狀態改造是第二步,把記憶體狀態外置到 Redis,把持久化狀態外置到 Mysql,這樣業務就可以隨意進行切分;
第三步是模塊化拆分,這塊是最考驗架構師的,因為拆分一個是按照業務屬性拆分,一個是按照應用復雜度進行拆分,這個是一個相對動態程序,建議拆分模塊后 2-3 人負責一個模塊,拆到太細會有比較高的運維成本,拆的太粗又會帶來研發協同問題,阿里內部也經歷過合久必分,分久必合的幾波震蕩,最終走到相對穩態,這里值得一提就是 HSF/Dubbo 的一個優勢,因為早期采用 SOA 架構思想設計,一個介面就是一個服務,這樣其實非常方便服務的拆分和合并,當然同時帶來一個問題是對注冊中心性能壓力比較大,這是一個架構選擇和平衡問題,

微服務 2.0(10w 實體/業務中臺/異地多活)
微服務 1.0 架構幫助阿里極大緩解性能和效率問題,但是由于阿里雙十一的成功,技術上面臨一個洪峰的技術挑戰,我們必須在用戶體驗、資源成本、高可用之間做一個平衡,這個階段我們最大的挑戰是擴展性和穩定性,擴展性是要支撐業務 10w+實體擴容,但是單地資源有限,雙十一商家投入的資金越來越大,導致我們雙十一當天也不能出嚴重問題,不然損失非常大,因此對業務穩定性提出非常高的要求,

因此阿里演進到微服務 2.0 支撐了異地多活的高可用體系,讓阿里業務可以按照 IDC 級別水平擴展,新的機房,新的技術體系都可以在單元中進行驗證,也加速了阿里技術體系演進速度,

在此期間 Nacos Server 間水平通知壓力巨大,業務發布視窗容易把網卡打滿,頻繁推送會消耗業務大量記憶體和 CPU,進而影響業務的穩定性,

針對上述問題,我們在 Nacos Server 間做了聚合推送,將一定時間窗的變更合并聚合推送,推送程序中做了壓縮推送,從而解決了上述問題,

在微服務解決擴展性和高可用的同時,業務系統變多,重復建設,業務孤島也越來越多,協同效率也越來越低,因此阿里業務在這個時候推出了業務中臺能力,將扁平的微服務抽象分層,將基礎服務抽象為中臺服務解決上述問題,業務分層后支撐了阿里業務高速增長,也加速了技術架構統一,

微服務 3.0(100w 實體/業務域拆分/云原生)
微服務 2.0 架構支撐了阿里雙十一的技術奇跡,阿里也陸續開啟業務擴張,構建更完整的互聯網版圖,在這個階段阿里收購了比較多的公司,技術體系不統一如何形成合力;從線上走到線下后,線下系統對系統穩定性要求更高;云計算發展,如何利用好云的彈性做雙十一,這個階段我們也推出了微服務的云產品,期望通過云產品支撐阿里雙十一,

業務域切分比較容易,切完之后如何更好的互聯互通是一個關鍵,因此我們內部推出了 Nacos-sync 和云原生網關兩個產品,Nacos-sync 適合業務流量超大,協議一致場景,云原生網關適合網路不通,協議不同,跨 Region 等場景,

即使從頂層做了業務域拆分,但是最大的電商集群往百萬實體演程序序中對注冊中心的壓力越來越大,我們把聚合視窗時間不斷拉長,推送慢了會導致業務發布時間變長,推送快了會對業務消耗較大,因此陷入了兩難境地,

這個階段我們進行問題的分解,首先根據服務串列大小做了一個切分,服務串列多的可以推送慢一些問題也不大,服務串列小的需要及時推送,因此我們優化了聚合推送邏輯,根據服務串列大小做了分級推送,還有一個優化思路是變更只有幾個串列變化,因此我們提供了增量推送能力,大幅降低服務變更推送資料量,

通過微服務 3.0 架構演進很好的解決了跨域互通和平滑上云的問題,新業務可以先上云,或者部分業務上云,通過網關做云上云下互通等問題,同時支撐了百萬實體微服務架構演進,

期望通過我分享阿里微服務發展歷程給大家做微服務架構演進提供一些思路和啟發,
云原生微服務趨勢
隨著云原生技術演進,容器以不可變基礎設施為理念,解決運維標準和資源利用率問題;微服務以可變運行時為理念,解決研發效率問題,提升系統整體擴展性和高可用,經常有人問我,為什么有了容器的服務發現機制,還需要微服務的注冊中心呢?從架構上首先是分層的,小的時候確實也看不到明顯區別,大一些就會發現問題,如阿里中心最大微服務集群,底層是多個 Kubernetes 集群,防止一個 Kubernetes 出問題影響全域,底層 Kubernetes 也可以水平擴展,如果依賴了 Kubernetes 的服務發現機制,跨 Kubernetes 服務發現就成了第一個問題,當然底層是一個 Kubernetes 上面也可以是多個微服務環境,微服務可以按照業務域切分,兩層可以做解耦,自由環境組合,還有就是阿里微服務體系積累了推空保護、服務治理完整體系,而 Kubernetes 的 CoreDNS 將服務發現強制拉到業務呼叫鏈路,每次呼叫都會做域名決議,因此 CoreDNS 掛的時候業務全部中斷,
對于阿里整體正在從百萬實體往千萬實體的規模演進,這部分也是阿里微服務 4.0 的內容,這部分給大部分公司的借鑒意義有限,因此不做展開,

微服務最佳實踐
阿里微服務體系經過 10 余年的發展,目前已經通過開源被廣泛使用,通過阿里云支撐了成千上萬家企業做數字化升級,借此機會把我們的最佳實踐總結分享給大家,期望都對大家用好微服務有所幫助,
阿里微服務體系簡介
通過 MSE + ACK 能夠完成第一步云原生技術升級,釋放云彈性紅利,釋放研發效率紅利,可以通過可觀測和高可用進一步用好微服務體系,

微服務最佳實踐
通過注冊&配置中心完成微服務拆分;通過網關統一入口,從入口處解決安全和高可用問題;最后通過服務治理提升用戶微服務的問題,

網關最佳實踐
云原生網關作為下一代網關,提供高集成、高可用、高性能、安全的一站式網關解決方案,
? 統一接入:將流量網關、 微服務網關、 WAF 三合一大幅降低資源和運維成本,需要強調的是云原生網關集成 WAF 的方案有非常好的性能優勢,WAF 做為控制面下發防護規則到云原生網關,流量直接在云原生網關清洗完畢直接路由到后端機器,RT 短,運維成本低,
? 統一入口安全防線:自動更新證書防過期,支持 JWT/OAuth2/OIDC/IDaaS 認證機制,支持黑白名單機制,
? 統一東西南北流量:統一解決跨域互通問題,包括跨網路域,跨業務域,跨地域,跨安全域等,
? 統一服務發現機制:支持 Nacos/Kubernetes/DNS/ 固定 IP 多種服務發現方式,
? 統一觀測平臺:從入口做好 tracing 埋點全鏈路診斷,豐富業務大盤和告警模板大幅降低網關運維成本,
? 統一服務治理:從入口做限流、降級、熔斷等高可用能力,提供全鏈路灰度方案控制變更風險,統一性能優化:采用硬體加速性能提升 80%,Ingress 場景比 Nginx 性能高 90%,引數調優+模塊優化提升 40%,

云原生網關支持 WASM 擴展網關自定義功能,并且通過插件市場提供豐富的插件能力,

服務治理最佳實踐
提供零業務侵入,開發,測驗,運維全覆寫服務治理能力,提升系統高可用,如發布階段即使注冊中心是毫秒級推送也會有延遲,這個期間就會導致流量損失,因此我們提供了無損上下線能力解決這個痛點,本月我們將服務治理能力通過 OpenSergo 開源,歡迎各位小伙伴參與共建!

日常環境隔離最佳實踐
共享一套環境聯調開發相互影響,所有環境都獨立聯調機器成本太高,這個是一個矛盾,我們通過全鏈路打標能力將流量隔離,讓大家可以在一套環境隔離多個邏輯聯調環境,巧妙的解決這個問題,

配置管理最佳實踐
隨著應用規模變大,到每個機器去修改配置運維成本太高,因此需要配置中心統一維護應用配置,將靜態業務動態化,動態修改業務運行時行為,提升應用運行時靈活性,

服務網格最佳實踐
對于多語言開發有訴求和對服務網關感興趣的小伙伴可以通過 MSE+ASM 快速構建服務網格解決方案,完成服務互通,快速體驗新的技術,

微服務高可用最佳實踐
隨著業務復雜度變高,業務峰值不可測,面對失敗的設計和微服務高可用工具使用就非常重要,可以通過 Sentinel 完成限流、降級、熔斷的保護,可以通過 PTS 完成壓測,可以通過混沌工程完成破壞性測驗,從體整體提升系統高可用,

注冊中心平滑遷移實踐
目前大規模場景推薦雙注冊,如 1w 實體以上,這樣發布周期長,穩定性更高一些,如果不到 1w 實體可以通過 Nacos-sync 同步完成注冊中心平滑前一,這樣通用型強一些,

網關平衡遷移實踐
由于前面云原生網關三合一和性能優勢,大家可以通過入口 DNS 灰度切換到云原生網關,

微服務標桿客戶
用戶上云中有兩類典型客戶,一類是傳統的單體胖應用客戶,一類是已經采用了微服務需要用好微服務的用戶,我們通過兩個標桿客戶分享一下,
斯凱奇微服務+業務中臺實踐
斯凱奇 2021 年找到我們做數字化升級時間非常緊急,需要雙十一前 3 個月左右要完成數字化升級,采用 MSE 微服務+中臺解決方案,斯凱奇借助云原生網關完成了東西南北流量的統一控制,借助南北向云原生網關完成安全認證和入口限流,從入口做好流量防護;借助東西向網關完成了多個業務域的互通,新老系統的互通,1 個月左右完成了整個系統的搭建,1 個月左右完成了整個系統壓測和高可用驗證,并且最終大促業務非常成功,助力斯凱奇雙十一 12 億營收規模,

來電微服務全鏈路灰度最佳實踐
來電的技術挑戰
來電科技的業務場景豐富且系統眾多,在技術架構上已完成容器化以及微服務化改造,微服務框架使用的是 Spring Cloud 與 Dubbo,隨著近年來的高速發展,充電寶設備節點以及業務量都在快速增加,系統的穩定性面臨幾點挑戰:
1.在系統服務的發布程序中如何避免業務流量的損失;
2.系統缺少簡單有效的灰度能力,每次系統發布都存在一定的穩定性風險,MSE 微服務治理提供了開箱即用且無侵入的線上發布穩定性解決方案以及全鏈路灰度解決方案,幫助來電科技消除發布風險、提升線上穩定性,
來電全鏈路灰度最佳實踐
1.來電科技選用 MSE 微服務治理專業版來實作無侵入微服務治理能力,無縫支持市面上近 5 年所有的 Spring Cloud 和 Dubbo 的版本,不用改一行代碼,不需要改變業務的現有架構就可以使用,沒有系結,
2.MSE 微服務治理專業版提供了全鏈路灰度解決方案幫助來電科技快速落地可灰度、可觀測、可回滾的安全生產三板斧能力,滿足業務高速發展情況下快速迭代和小心驗證的訴求;
3.MSE 微服務治理的無損上下線能力,對系統服務的全流程進行防護,通過服務預熱、無損下線、與 Kubernetes 微服務生命周期對齊、延遲發布等一系列能力,保證在服務冷啟動或銷毀程序中,業務連續無損,
4.MSE 微服務治理的離群實體摘除能力,可以做到讓服務消費者自動檢測其所呼叫提供者實體的可用性并進行實時的權重動態調整,以保證服務呼叫的成功率,從而提升業務穩定性和服務質量,

阿里云微服務生態與規劃
阿里開源微服務會貼著服務治理幫助開發者用戶微服務,云產品做好產品集成提升大家的使用體驗,
ACK+MSE = 云原生架構升級解決方案
ASM+MSE = 服務網格解決方案
AHAS + MSE = 微服務高可用解決方案
ARMS + MSE = 微服務可觀測解決方案
EDAS + MSE = APaaS解決方案
SAE + MSE = 微服務 Serverless 解決方案
WAF + 云盾 + IDaaS + MSE = 微服務安全解決方案

運營活動
限時折扣(4.21-4.30)

微服務全家桶,省、省、省~

下期預告 - Kubernetes Ingress 最佳實踐
隨著 Kubernetes 普及,Ingress 成為云原生架構的流量入口,云原生網關作為 Ingress
的最佳實踐如何助力業務降本提效,如何從入口處建立安全、高可用的防線,如何從 Nginx Ingress 實作平滑切到云原生網關,4.28 將為大家揭曉!

阿里云 MSE 搶購入口:
https://www.aliyun.com/product/aliware/mse
MSE 國際站購買入口:
https://www.alibabacloud.com/product/microservices-engine
點擊此處即可觀看微服務最佳實踐相關視頻~
發布云原生技術最新資訊、匯集云原生技術最全內容,定期舉辦云原生活動、直播,阿里產品及用戶最佳實踐發布,與你并肩探索云原生技術點滴,分享你需要的云原生內容,
關注【阿里巴巴云原生】公眾號,獲取更多云原生實時資訊!
轉載請註明出處,本文鏈接:https://www.uj5u.com/qita/460843.html
標籤:其他
上一篇:k8s入門之Service(六)
下一篇:關于掛科我想說幾句
