雲栖号資訊:【 點選檢視更多行業資訊】
在這裡您可以找到不同行業的第一手的上雲資訊,還在等什麼,快來!
随着Kubernetes和微服務的采用,邊緣已從簡單的硬體負載平衡器演變為包括API網關,内容傳遞網絡和負載平衡器的完整的硬體和軟體代理堆棧。 了解這種轉變對于資料中心主管來說至關重要,是以他們可以做出正确的架構,政策和營運決策。 為了了解轉變,快速的曆史旅程會有所幫助。
早期的Internet和負載平衡器
在1990年代中期,Web應用程式體系結構還處于起步階段。 由資料庫層,應用程式層和表示層組成的經典n層體系結構是此時的實際應用程式體系結構。 通過使用資料中心邊緣的第一個疊代:負載平衡器,将應用程式層或表示層的多個執行個體連接配接到Internet,可以對n層體系結構進行水準擴充。 在這個時代,負載平衡器負責在應用程式的不同執行個體之間路由流量,以確定高可用性和可伸縮性。 盡管2001年HAProxy的釋出開始普及軟體負載平衡器的概念,但負載平衡器通常是一種硬體裝置。

ADC和Web 2.0的興起
達西·迪尼奇(Darcy DiNucci)于1999年創造了Web 2.0一詞,指的是Internet從單向媒體向使用者可以與網站參與的雙向媒體的發展。 在此期間,AJAX(異步JavaScript和XML)開發技術變得無處不在。 通過将資料交換與示範脫鈎,AJAX為最終使用者創造了更加豐富的使用者體驗。 這種體系結構還建立了許多"客戶"用戶端,因為這些用戶端将不斷從Web應用程式發送和接收資料。 另外,這個時代的電子商務開始興起,信用卡資訊的安全傳輸首次成為人們關注的主要問題。
網絡中的這些變化-加密的通信和更長壽命的連接配接上的許多請求-推動了邊緣從标準硬體/軟體負載平衡器到更專用的應用程式傳遞控制器(ADC)的演進。 ADC包含用于所謂的應用程式加速的各種功能,包括SSL解除安裝,緩存和壓縮。
達到網絡規模
在2010年代初期,許多雲計算第一公司的使用者群經曆了指數級增長。 這些公司背後的軟體最初是作為整體Web應用程式設計的。 随着他們的使用者群激增到天文數字,這些公司發現網絡規模的問題确實是訓示不同體系結構的另一類問題。 Twitter,Facebook和New Relic等公司開始将關鍵功能部件從整體中重構為獨立部署的服務。 通過将關鍵業務功能部署為服務,這些組織能夠獨立擴充和管理整個應用程式的不同方面。 這些獨立服務的流量通過整體路由。 路由的任何更改都意味着開發人員經常不得不重新部署整個整體。 這成為改變速度的瓶頸,但至少解決了規模問題。
救援API網關
解決了規模問題的尖端組織現在面臨着解決整體應用程式問題的問題,這正拖慢了他們的應用程式開發速度。 從這些體系結構中獲得的經驗之一是顯而易見的-對于重構服務,整體元件隻是充當路由器。 這一發現引發了早期API網關的發展。 API網關執行原始整體中的路由功能,進而為整個應用程式建立通用外觀。 API網關集中了跨領域的應用程式級功能,例如速率限制,身份驗證和路由。 這減少了每個單獨服務中所需的複制功能量。
雲原生時代:微服務
整體已成為微型,但它仍然存在并減慢了應用程式的開發和部署。 微服務介入解決了這個問題。 每個微服務代表一個獨立的業務功能,并且獨立于應用程式的其他微服務而開發和釋出。 通過解耦開發周期,微服務使組織能夠更有效地擴充雲的軟體開發流程。 鑒于微服務可以部署在多種環境中:虛拟機,裸機,容器作為功能— API網關在将流量路由到正确的微服務中起着至關重要的作用。
現在到未來—轉向全周期開發和雲原生工作流程
微服務不僅僅是應用程式體系結構的轉變。 微服務也是開發工作流程中的一種轉變。 團隊負責整個軟體開發生命周期-從設計到開發再到測試再到部署和釋出。 一些組織将這些團隊作為呼叫輪換的一部分("又名,就建立,就運作")。 這種開發模型被Netflix稱為全周期開發,它是軟體開發和傳遞方式的一次轉變。
工作流程的這種轉變也對資料中心優勢産生了影響。 API網關(以及邊緣堆棧的其他元素)不僅需要适應微服務架構,而且整個周期的開發團隊都需要通路和管理整個邊緣。 此管理包括路由(服務的哪個版本應接收生産流量)以及更精細的控件,例如權重路由(金絲雀版本需要)和流量屏蔽(将流量的副本建立到服務的測試版本以進行測試) 目的)。 通過使開發團隊能夠管理釋出和部署,組織可以擴充這些流程以支援甚至高度複雜的應用程式。
全周期開發團隊還經常對其微服務負責營運。 取得成功的關鍵是實時了解其微服務的性能。 邊緣通過分析流入和流出微服務的所有流量,提供了對微服務行為的重要了解。 這使邊緣可以報告諸如延遲,吞吐量和錯誤率等名額,進而深入了解應用程式的運作狀況。
邊緣政策管理至關重要
考慮到邊緣在現代雲原生工作流中的重要性,全周期開發團隊如何管理邊緣? 不幸的是,傳統上邊緣堆棧的所有元件都由操作來管理,并且操作接口不适合全周期開發團隊中的應用程式開發人員使用。 此外,邊緣元件通常是隔離運作的,沒有内聚的操作界面。 畢竟,全周期開發人員不是全職操作員; 他們隻需要能夠滿足其特定需求的邊緣機器即可。
幸運的是,Kubernetes生态系統可以提供指導和啟發。 使用基于YAML的通用配置語言,開發人員可以管理自己的邊緣配置,而集中式營運團隊則可以執行全局政策。 這是前沿團隊用來提供快速開發周期的最新的優勢。
【雲栖号線上課堂】每天都有産品技術專家分享!
課程位址:
https://yqh.aliyun.com/live立即加入社群,與專家面對面,及時了解課程最新動态!
【雲栖号線上課堂 社群】
https://c.tb.cn/F3.Z8gvnK
原文釋出時間:2020-04-15
本文作者:聞數起舞
本文來自:“
51CTO”,了解相關資訊可以關注“
”