0
  • 聊天消息
  • 系統(tǒng)消息
  • 評(píng)論與回復(fù)
登錄后你可以
  • 下載海量資料
  • 學(xué)習(xí)在線(xiàn)課程
  • 觀看技術(shù)視頻
  • 寫(xiě)文章/發(fā)帖/加入社區(qū)
會(huì)員中心
創(chuàng)作中心

完善資料讓更多小伙伴認(rèn)識(shí)你,還能領(lǐng)取20積分哦,立即完善>

3天內(nèi)不再提示

分布式政企應(yīng)用如何快速實(shí)現(xiàn)云原生的微服務(wù)架構(gòu)改造

科技說(shuō)i ? 來(lái)源:科技說(shuō)i ? 作者:科技說(shuō)i ? 2023-04-12 11:04 ? 次閱讀

在以往的文章《云原生微服務(wù)治理技術(shù)朝無(wú)代理架構(gòu)的演進(jìn)之路》中,我們介紹了幾種微服務(wù)架構(gòu)模式,如下圖所示。

poYBAGQ1TiKAWdnYAADnwRA_DDQ310.png

今天主要是介紹,第一種SOA/ESB架構(gòu),在Java語(yǔ)言場(chǎng)景下,如何朝第三種 云原生ServiceMesh架構(gòu) 的演進(jìn)的問(wèn)題。

SOA/ESB架構(gòu)簡(jiǎn)介和問(wèn)題概覽

首先我們來(lái)看看 SOA/ESB 架構(gòu)模式 在目前公有云上的典型參考架構(gòu)。

如下圖所示,以華為云為例,以該模式部署應(yīng)用時(shí),其使用到的典型云服務(wù)為 彈性負(fù)載均衡 (ELB) + 彈性伸縮(AS,包含ECS)。在這種場(chǎng)景下:

·需要發(fā)起調(diào)用的客戶(hù)端程序,通過(guò)配置好的域名或地址,直接調(diào)用到ELB上,通過(guò)ELB去調(diào)用到后端的ECS服務(wù)器。

·ELB上需要配置后端服務(wù)器的多個(gè)IP地址。當(dāng)然,一般這類(lèi)操作可以簡(jiǎn)化為添加某類(lèi)彈性伸縮組。這樣,當(dāng)ECS發(fā)生彈性伸縮時(shí)管理員無(wú)需處理ELB配置,ELB即可自動(dòng)刷新ECS的IP列表的變化。

(配置操作可參見(jiàn):

poYBAGQ1TiOAPMjlAADj4zb7m68984.png

值得注意的是,以上的模式可能存在幾種變種。

·對(duì)于ELB,可能會(huì)采用API網(wǎng)關(guān)替代,或者用戶(hù)自建的KONG, APISIX,Envoy等,具體取決各個(gè)企業(yè)的自身業(yè)務(wù)場(chǎng)景。例如,某些互聯(lián)網(wǎng)公司傾向于采用企業(yè)自建的KONG,其主要原因是除了基本的服務(wù)發(fā)現(xiàn)和負(fù)載均衡能力以外,網(wǎng)關(guān)還需要處理面向內(nèi)部跨域調(diào)用的一些鑒權(quán)情況處理。

·對(duì)于彈性伸縮,可能也會(huì)直接采用Kubernetes的Deployment + HorizontalPodAutoscaler替代。這當(dāng)然取決于企業(yè)內(nèi)部的基礎(chǔ)架構(gòu)采用情況,看是更傾向于使用虛擬機(jī)架構(gòu)還是容器架構(gòu)。

以上架構(gòu)雖然在隔離性、安全性上存在一定優(yōu)點(diǎn),但是短板也非常明顯。

·性能和資源開(kāi)銷(xiāo)。這個(gè)比較好理解,相對(duì)微服務(wù)架構(gòu),SOA/ESB架構(gòu)上網(wǎng)絡(luò)增加了額外一跳,而且ELB的引入也會(huì)導(dǎo)致資源的額外消耗增多。

·運(yùn)維成本。畢竟額外引入了一個(gè)ELB的組件,因此在微服務(wù)之間調(diào)用時(shí),瓶頸在哪里,ELB是否需要擴(kuò)縮容,都是問(wèn)題。

pYYBAGQ1TiWAVyN-AADsd8IIA2M968.png

微服務(wù)和云原生架構(gòu)改造方法和問(wèn)題

對(duì)于如何改造 SOA/ESB 架構(gòu),朝微服務(wù)架構(gòu)或云原生架構(gòu)演進(jìn),業(yè)界也有很多方法。主要是以下兩類(lèi)。

poYBAGQ1TiaAdRwhAAErTIoDW9o713.png

通過(guò)修改代碼,將應(yīng)用改造為微服務(wù)架構(gòu)。例如直接在代碼中引入比如SpringCloud的服務(wù)注冊(cè)發(fā)現(xiàn)和負(fù)載均衡等組件。當(dāng)然,這種改造往往也并不簡(jiǎn)單,主要取決于現(xiàn)有應(yīng)用已采用的開(kāi)發(fā)框架等。比如應(yīng)用本身沒(méi)有采用spring來(lái)進(jìn)行開(kāi)發(fā),那么直接采用SpringCloud可能會(huì)為應(yīng)用帶來(lái)海量的改造成本。

·采用istio方案,通過(guò)有限改造應(yīng)用,將架構(gòu)升級(jí)為ServiceMesh架構(gòu)。之所以該方案說(shuō)是有限改造,而不是無(wú)改造,也是因?yàn)樵诜?wù)調(diào)用方式上,istio方案對(duì)應(yīng)用并不是完全無(wú)限制。其至少需要在客戶(hù)端將調(diào)用的http調(diào)用地址改造成為k8s原生的服務(wù)地址,調(diào)用的服務(wù)治理才能被envoy有效接管。當(dāng)然,改造完畢后,用戶(hù)在接下來(lái)在面向邊車(chē)的性能衰減,更復(fù)雜的調(diào)用運(yùn)維問(wèn)題上,恐怕一個(gè)也不會(huì)少。

綜上所述,兩種方案都存在比較明顯的短板。接下來(lái)分析下采用Sermant方式進(jìn)行架構(gòu)改造,如何彌補(bǔ)上述兩種方案的短板。

Sermant對(duì)SOA/ESB架構(gòu)升級(jí)的思路

采用Sermant (https://sermant.io/zh/) 對(duì)SOA/ESB架構(gòu)升級(jí),本質(zhì)上的最后的架構(gòu)終態(tài)是Service-Mesh。但是因?yàn)椴捎玫姆椒ㄉ杂胁煌瑥亩鴮?dǎo)致方案在性能和運(yùn)維問(wèn)題上都不存在短板。主要是以下兩點(diǎn):

·首先,Sermant采用Java Agent來(lái)動(dòng)態(tài)注入增強(qiáng)的服務(wù)邏輯治理,因此應(yīng)用側(cè)理論可以做到完全不用改代碼。

·其次,由于Sermant的核心邏輯是以AOP (面向切面編程) 方式,Java Agent和業(yè)務(wù)屬于同一進(jìn)程,因此在性能方面不存在sidecar形態(tài)的特別大的損耗。

Sermant方案架構(gòu)如下圖所示:

pYYBAGQ1TieAKy0gAAHPp4V9GQc132.png

在核心技術(shù)點(diǎn)上,Sermant改造方案的功能主要有以下幾個(gè)方面:

·內(nèi)置的服務(wù)注冊(cè)發(fā)現(xiàn)機(jī)制。(上圖中的第一點(diǎn)和第三點(diǎn))

-插件本身會(huì)帶服務(wù)注冊(cè)功能,在Provider應(yīng)用啟動(dòng)的時(shí)候自動(dòng)到注冊(cè)中心進(jìn)行服務(wù)注冊(cè)。

- 在Consumer應(yīng)用進(jìn)行URL服務(wù)調(diào)用的時(shí)候,通過(guò)微服務(wù)服務(wù)發(fā)現(xiàn)+負(fù)載均衡機(jī)制替代原先的服務(wù)直調(diào)。

·域名到服務(wù)名(有時(shí)也稱(chēng)應(yīng)用名)的轉(zhuǎn)換。(上圖中的第二點(diǎn))

- 服務(wù)發(fā)現(xiàn)時(shí),由于原先的調(diào)用采用URL直調(diào),并不包含應(yīng)用信息。這就需要一個(gè)調(diào)用關(guān)系到應(yīng)用名的映射。對(duì)于這塊內(nèi)容,未來(lái)我們計(jì)劃做成了一個(gè)動(dòng)態(tài)配置,存儲(chǔ)到配置中心里。這樣當(dāng)有應(yīng)用需要發(fā)起調(diào)用時(shí),Sermant直接將URL轉(zhuǎn)換成應(yīng)用名,就可以在注冊(cè)中心獲取響應(yīng)的應(yīng)用IP列表。

- 通過(guò)URL獲取Provider應(yīng)用名后,由于在改造過(guò)程中,不用Provider應(yīng)用并不是同批次發(fā)布攜帶Sermant Java Agent,因此還需要有個(gè)白名單機(jī)制,來(lái)配合灰度發(fā)布。

·增強(qiáng)的客戶(hù)端側(cè)負(fù)載均衡、重試、隔離、降級(jí)機(jī)制。(上圖中的第四點(diǎn))

- 通過(guò)URL獲取Provider應(yīng)用名后,由于在改造過(guò)程中,不用Provider應(yīng)用并不是同批次發(fā)布攜帶Sermant Java Agent,因此還需要有個(gè)白名單機(jī)制,來(lái)配合灰度發(fā)布。

- 此外,對(duì)于一些必要的東西向流量的治理能力,如服務(wù)間的3A認(rèn)證等,也需要進(jìn)一步在Sermant端補(bǔ)齊。

以上便是Sermant改造方案的主要功能點(diǎn)。另外,在實(shí)操中如何針對(duì)現(xiàn)有環(huán)境進(jìn)行升級(jí)還是需要一定方法,避免對(duì)現(xiàn)有環(huán)境進(jìn)行太大沖擊。以下詳細(xì)敘述。

采用Sermant對(duì)SOA/ESB架構(gòu)升級(jí)的方案實(shí)操

應(yīng)用改造在具體局點(diǎn)上不可能一蹴而就,因此在具體上實(shí)施上肯定是一個(gè)慢慢灰度的過(guò)程。以Kubernetes容器場(chǎng)景為例,介紹下在上百個(gè)微服務(wù)應(yīng)用上千實(shí)例的情況下,如何采用Sermant對(duì)SOA/ESB基于灰度進(jìn)行安全可控的云原生架構(gòu)升級(jí)。

以下為準(zhǔn)備工作:

準(zhǔn)備步驟一:

自身應(yīng)用是否支持。當(dāng)前Sermant支持的微服務(wù)升級(jí)的Java框架可以在該文檔中查詢(xún)。如未支持,可以考慮給社區(qū)提Issue解決。

準(zhǔn)備步驟二:

在Kubernetes中安裝Injector,方便以非侵入方式讓Java應(yīng)用自動(dòng)掛載Sermant Java Agent.

(本步驟可選。如跳過(guò),則需要手動(dòng)改變應(yīng)用部署腳本加載Sermant Java Agent。)

以下介紹詳細(xì)實(shí)施過(guò)程。假設(shè)初始架構(gòu)如下。一共三個(gè)App,其中App1通過(guò)ELB連接到App2和App3。為簡(jiǎn)化表述,圖中為應(yīng)用均為單實(shí)例,實(shí)際生產(chǎn)中的實(shí)例可能會(huì)有多個(gè)。

poYBAGQ1TieAKJWkAAAlNlOYL4E365.png

接下來(lái),在Kubernetes中對(duì)新版本的App1, App2進(jìn)行發(fā)布(圖中為V2版本),并在發(fā)布時(shí)攜帶Sermant Java Agent,以及激活SpringBoot注冊(cè)插件。但是此時(shí)可以先不配置Provider白名單規(guī)則,因此發(fā)布后,應(yīng)用流量應(yīng)該還是走ELB,未發(fā)生任何變化。

pYYBAGQ1TiiAPIO0AABTnHzHFTQ993.png

接著在配置中心,將App2加入到白名單中。此時(shí),對(duì)識(shí)別到App2的應(yīng)用,掛有Sermant Java Agent的App1實(shí)例 (圖中的V2實(shí)例) 會(huì)對(duì)App2的實(shí)例以負(fù)載均衡方式直接發(fā)起調(diào)用。與此同時(shí),App1訪(fǎng)問(wèn)App3的流量沒(méi)有變化。

poYBAGQ1TimALLlyAABUN-d2wb4862.png

驗(yàn)證成功后,刪除App1、 App2的V1版本,App1到App2的流量通過(guò)注冊(cè)中心的注冊(cè)發(fā)現(xiàn),完全實(shí)現(xiàn)直連。同時(shí),App1訪(fǎng)問(wèn)App3的流量維持不變。

pYYBAGQ1TiqAIbv1AAA3luCozmY828.png

此,使用Sermant對(duì)App1、App2的云原生架構(gòu)升級(jí)結(jié)束。后續(xù)其他App應(yīng)用,可以按照類(lèi)似方案,進(jìn)行灰度升級(jí),直至所有應(yīng)用全部掛載上Sermant,完成微服務(wù)直連改造。

結(jié)束語(yǔ)

Sermant 作為專(zhuān)注于服務(wù)治理領(lǐng)域的字節(jié)碼增強(qiáng)框架,致力于提供高性能、可擴(kuò)展、易接入、功能豐富的服務(wù)治理體驗(yàn),并會(huì)在每個(gè)版本中做好性能、功能、體驗(yàn)的看護(hù),廣泛歡迎大家的加入。

當(dāng)前Sermant已在華為云云服務(wù)CSE中被集成,用戶(hù)可以在華為云CSE云服務(wù)中使用相關(guān)功能。

審核編輯:湯梓紅

聲明:本文內(nèi)容及配圖由入駐作者撰寫(xiě)或者入駐合作網(wǎng)站授權(quán)轉(zhuǎn)載。文章觀點(diǎn)僅代表作者本人,不代表電子發(fā)燒友網(wǎng)立場(chǎng)。文章及其配圖僅供工程師學(xué)習(xí)之用,如有內(nèi)容侵權(quán)或者其他違規(guī)問(wèn)題,請(qǐng)聯(lián)系本站處理。 舉報(bào)投訴
  • 服務(wù)器
    +關(guān)注

    關(guān)注

    12

    文章

    8958

    瀏覽量

    85082
  • SOA
    SOA
    +關(guān)注

    關(guān)注

    1

    文章

    282

    瀏覽量

    27404
  • 微服務(wù)
    +關(guān)注

    關(guān)注

    0

    文章

    131

    瀏覽量

    7322
  • 華為云
    +關(guān)注

    關(guān)注

    3

    文章

    2391

    瀏覽量

    17244
  • 云原生
    +關(guān)注

    關(guān)注

    0

    文章

    240

    瀏覽量

    7932
收藏 人收藏

    評(píng)論

    相關(guān)推薦

    云原生技術(shù)概述 云原生火爆成為升職加薪核心必備

    云原生微服務(wù)可通過(guò)分布式部署,大幅提升團(tuán)隊(duì)和日常的工作效率,K8s+Docker+Ceph+Envoy+Istio+Prometheus架構(gòu),目前是各大主流互聯(lián)網(wǎng)首選的技術(shù)方向,掌握
    的頭像 發(fā)表于 07-27 10:23 ?1259次閱讀

    微服務(wù)架構(gòu)分布式事務(wù)解決方案 —— 阿里GTS

    一致性方案對(duì)應(yīng)用侵入性也很高,應(yīng)用需要進(jìn)行大量業(yè)務(wù)改造,成本較高。4 GTS--分布式事務(wù)解決方案GTS是一款分布式事務(wù)中間件,由阿里巴巴中間件部門(mén)研發(fā),可以為微服務(wù)
    發(fā)表于 03-16 11:14

    一行代碼,保障分布式事務(wù)一致性—GTS:微服務(wù)架構(gòu)分布式事務(wù)解決方案

    故障問(wèn)題。單體應(yīng)用拆分所導(dǎo)致的數(shù)據(jù)庫(kù)架構(gòu)的拆分。應(yīng)用更新多個(gè)業(yè)務(wù)記錄非常常見(jiàn),單體應(yīng)用實(shí)現(xiàn)也比較簡(jiǎn)單。然而在微服務(wù)架構(gòu)下,應(yīng)用不得不調(diào)用多個(gè)微服務(wù)
    發(fā)表于 06-05 19:14

    一文讀懂分布式架構(gòu)知識(shí)體系(內(nèi)含超全核心知識(shí)大圖)

    了解微服務(wù)分布式的本質(zhì),身臨其境的感受如何搭建全套微服務(wù)架構(gòu)的過(guò)程。關(guān)注“阿里巴巴云原生”公眾號(hào),回復(fù)“
    發(fā)表于 10-23 10:02

    性能提升1倍,成本直降50%!基于龍蜥指令加速的下一代云原生網(wǎng)關(guān)

    ;業(yè)務(wù)網(wǎng)關(guān)提供獨(dú)立業(yè)務(wù)域級(jí)別的、與后端業(yè)務(wù)緊耦合策略配置,隨著應(yīng)用架構(gòu)模式從單體演進(jìn)到現(xiàn)在的分布式微服務(wù),業(yè)務(wù)網(wǎng)關(guān)也有了新的叫法 - 微服務(wù)網(wǎng)關(guān)。(圖 6/傳統(tǒng)網(wǎng)關(guān))MSE 云原生網(wǎng)關(guān)
    發(fā)表于 08-31 10:46

    微服務(wù),容器和云原生架構(gòu)的中間件世界的現(xiàn)狀

    令人不可思議的速度快速向這些技術(shù)靠攏! 在2016年6月的今天,許多企業(yè)已經(jīng)采用容器和原生架構(gòu)或正在采用它們。 這個(gè)話(huà)題也越來(lái)越和中間件供應(yīng)商相關(guān)。 因此,我們需要做一個(gè)有關(guān)微服務(wù),
    發(fā)表于 10-10 11:25 ?0次下載
    <b class='flag-5'>微服務(wù)</b>,容器和<b class='flag-5'>云原生</b><b class='flag-5'>架構(gòu)</b>的中間件世界的現(xiàn)狀

    微服務(wù)分布式的區(qū)別

    本文全面概述了微服務(wù)分布式的區(qū)別。分布式微服架構(gòu)很相似,只是部署的方式不一樣而已。分布式
    的頭像 發(fā)表于 02-09 10:52 ?8.1w次閱讀
    <b class='flag-5'>微服務(wù)</b>和<b class='flag-5'>分布式</b>的區(qū)別

    云原生技術(shù)將是企業(yè)落地微服務(wù)的優(yōu)秀伴侶

    隨著技術(shù)的發(fā)展,我們?cè)仆泄軙r(shí)代逐步的向云原生演進(jìn)了。所謂云原生,就是將微服務(wù)、DevOps的架構(gòu)理念與云所提供的容器、Serverless無(wú)服務(wù)
    的頭像 發(fā)表于 10-08 14:37 ?1902次閱讀

    什么是微服務(wù)分布式 微服務(wù)分布式之間區(qū)別

    獨(dú)立的小團(tuán)隊(duì)開(kāi)發(fā),測(cè)試,部署,上線(xiàn),負(fù)責(zé)它的整個(gè)生命周期。 分布式又是啥? 分布式服務(wù)顧名思義服務(wù)是分散部署在不同的機(jī)器上的,一個(gè)服務(wù)可能負(fù)
    的頭像 發(fā)表于 07-30 18:21 ?3w次閱讀

    什么是分布式系統(tǒng) 分布式架構(gòu)有哪些

    什么是分布式系統(tǒng)? 1.分布式系統(tǒng)一定是由多個(gè)節(jié)點(diǎn)組成的系統(tǒng)。 2.這些連通的節(jié)點(diǎn)上部署了我們的節(jié)點(diǎn),并且相互的操作會(huì)有協(xié)同。 隨著應(yīng)用架構(gòu)演進(jìn), 分布式
    的頭像 發(fā)表于 07-31 09:54 ?7483次閱讀

    什么是分布式云原生

    體驗(yàn),讓客戶(hù)在使用云原生應(yīng)用時(shí),感受不到地域、跨云、流量的限制,把云原生的能力帶入到企業(yè)的每一個(gè)業(yè)務(wù)場(chǎng)景,加速千行百業(yè)擁抱云原生分布式云原生
    發(fā)表于 07-27 15:52 ?1542次閱讀

    華為云左少夫:面向分布式云原生構(gòu)筑無(wú)處不在的云原生基礎(chǔ)設(shè)施

    2022年全球分布式云大會(huì)近日于深圳南山舉辦,會(huì)上華為云云原生產(chǎn)品總監(jiān)做了題為“面向分布式云原生,構(gòu)筑無(wú)處不在的云原生基礎(chǔ)設(shè)施”的主題演講。
    的頭像 發(fā)表于 12-26 21:52 ?746次閱讀
    華為云左少夫:面向<b class='flag-5'>分布式</b><b class='flag-5'>云原生</b>構(gòu)筑無(wú)處不在的<b class='flag-5'>云原生</b>基礎(chǔ)設(shè)施

    分布式政企應(yīng)用如何快速實(shí)現(xiàn)云原生微服務(wù)架構(gòu)改造

    和集成復(fù)雜的應(yīng)用系統(tǒng)。然而,隨著云計(jì)算和微服務(wù)等新技術(shù)的出現(xiàn),SOA/ESB架構(gòu)也面臨著一些問(wèn)題和挑戰(zhàn)。本文將對(duì)SOA/ESB架構(gòu),在Java語(yǔ)言場(chǎng)景下,如何朝云原生ServiceMe
    的頭像 發(fā)表于 04-17 15:17 ?512次閱讀

    如何迅速將分布式政企應(yīng)用轉(zhuǎn)型為云原生微服務(wù)架構(gòu)

    )來(lái)構(gòu)建和集成復(fù)雜的應(yīng)用系統(tǒng)。然而,隨著云計(jì)算和微服務(wù)等新技術(shù)的出現(xiàn),SOA/ESB架構(gòu)也面臨著一些問(wèn)題和挑戰(zhàn)。本文將對(duì)SOA/ESB架構(gòu)進(jìn)行簡(jiǎn)要介紹,并探討將其轉(zhuǎn)換為微服務(wù)
    的頭像 發(fā)表于 04-17 15:18 ?491次閱讀

    技術(shù)速遞 | 分布式政企應(yīng)用如何快速實(shí)現(xiàn)云原生微服務(wù)架構(gòu)改造

    作者:楊奕? 華為云技術(shù)規(guī)劃專(zhuān)家 在以往的文章《云原生微服務(wù)治理技術(shù)朝無(wú)代理架構(gòu)的演進(jìn)之路》中,我們介紹了幾種微服務(wù)架構(gòu)模式,如下圖所示。
    的頭像 發(fā)表于 04-19 00:45 ?527次閱讀
    技術(shù)速遞 | <b class='flag-5'>分布式</b><b class='flag-5'>政企</b>應(yīng)用如何<b class='flag-5'>快速</b><b class='flag-5'>實(shí)現(xiàn)</b><b class='flag-5'>云原生</b>的<b class='flag-5'>微服務(wù)</b><b class='flag-5'>架構(gòu)</b><b class='flag-5'>改造</b>