隨著Kubernetes和微服務的采用，邊緣已從簡單的硬件負載平衡器演變?yōu)榘ˋPI網(wǎng)關，內(nèi)容交付網(wǎng)絡和負載平衡器的完整的硬件和軟件代理堆棧。 理解這種轉變對于數(shù)據(jù)中心主管來說至關重要，因此他們可以做出正確的架構，策略和運營決策。 為了了解轉變，快速的歷史旅程會有所幫助。

早期的Internet和負載平衡器

在1990年代中期，Web應用程序體系結構還處于起步階段。 由數(shù)據(jù)庫層，應用程序層和表示層組成的經(jīng)典n層體系結構是此時的實際應用程序體系結構。 通過使用數(shù)據(jù)中心邊緣的第一個迭代：負載平衡器，將應用程序層或表示層的多個實例連接到Internet，可以對n層體系結構進行水平擴展。 在這個時代，負載平衡器負責在應用程序的不同實例之間路由流量，以確保高可用性和可伸縮性。 盡管2001年HAProxy的發(fā)布開始普及軟件負載平衡器的概念，但負載平衡器通常是一種硬件設備。

ADC和Web 2.0的興起

達西·迪尼奇（Darcy DiNucci）于1999年創(chuàng)造了Web 2.0一詞，指的是Internet從單向媒體向用戶可以與網(wǎng)站參與的雙向媒體的發(fā)展。 在此期間，AJAX（異步JavaScript和XML）開發(fā)技術變得無處不在。 通過將數(shù)據(jù)交換與演示脫鉤，AJAX為最終用戶創(chuàng)造了更加豐富的用戶體驗。 這種體系結構還創(chuàng)建了許多"客戶"客戶端，因為這些客戶端將不斷從Web應用程序發(fā)送和接收數(shù)據(jù)。 另外，這個時代的電子商務開始興起，信用卡信息的安全傳輸首次成為人們關注的主要問題。

網(wǎng)絡中的這些變化-加密的通信和更長壽命的連接上的許多請求-推動了邊緣從標準硬件/軟件負載平衡器到更專用的應用程序交付控制器（ADC）的演進。 ADC包含用于所謂的應用程序加速的各種功能，包括SSL卸載，緩存和壓縮。

達到網(wǎng)絡規(guī)模

在2010年代初期，許多云計算第一公司的用戶群經(jīng)歷了指數(shù)級增長。 這些公司背后的軟件最初是作為整體Web應用程序設計的。 隨著他們的用戶群激增到天文數(shù)字，這些公司發(fā)現(xiàn)網(wǎng)絡規(guī)模的問題確實是指示不同體系結構的另一類問題。 Twitter，F(xiàn)acebook和New Relic等公司開始將關鍵功能部件從整體中重構為獨立部署的服務。 通過將關鍵業(yè)務功能部署為服務，這些組織能夠獨立擴展和管理整個應用程序的不同方面。 這些獨立服務的流量通過整體路由。 路由的任何更改都意味著開發(fā)人員經(jīng)常不得不重新部署整個整體。 這成為改變速度的瓶頸，但至少解決了規(guī)模問題。

救援API網(wǎng)關

解決了規(guī)模問題的尖端組織現(xiàn)在面臨著解決整體應用程序問題的問題，這正拖慢了他們的應用程序開發(fā)速度。 從這些體系結構中獲得的經(jīng)驗之一是顯而易見的-對于重構服務，整體組件只是充當路由器。 這一發(fā)現(xiàn)引發(fā)了早期API網(wǎng)關的發(fā)展。 API網(wǎng)關執(zhí)行原始整體中的路由功能，從而為整個應用程序創(chuàng)建通用外觀。 API網(wǎng)關集中了跨領域的應用程序級功能，例如速率限制，身份驗證和路由。 這減少了每個單獨服務中所需的復制功能量。

云原生時代：微服務

整體已成為微型，但它仍然存在并減慢了應用程序的開發(fā)和部署。 微服務介入解決了這個問題。 每個微服務代表一個獨立的業(yè)務功能，并且獨立于應用程序的其他微服務而開發(fā)和發(fā)布。 通過解耦開發(fā)周期，微服務使組織能夠更有效地擴展云的軟件開發(fā)流程。 鑒于微服務可以部署在多種環(huán)境中：虛擬機，裸機，容器作為功能— API網(wǎng)關在將流量路由到正確的微服務中起著至關重要的作用。

現(xiàn)在到未來—轉向全周期開發(fā)和云原生工作流程

微服務不僅僅是應用程序體系結構的轉變。 微服務也是開發(fā)工作流程中的一種轉變。 團隊負責整個軟件開發(fā)生命周期-從設計到開發(fā)再到測試再到部署和發(fā)布。 一些組織將這些團隊作為呼叫輪換的一部分（"又名，就創(chuàng)建，就運行"）。 這種開發(fā)模型被Netflix稱為全周期開發(fā)，它是軟件開發(fā)和交付方式的一次轉變。

工作流程的這種轉變也對數(shù)據(jù)中心優(yōu)勢產(chǎn)生了影響。 API網(wǎng)關（以及邊緣堆棧的其他元素）不僅需要適應微服務架構，而且整個周期的開發(fā)團隊都需要訪問和管理整個邊緣。 此管理包括路由（服務的哪個版本應接收生產(chǎn)流量）以及更精細的控件，例如加權路由（金絲雀版本需要）和流量屏蔽（將流量的副本創(chuàng)建到服務的測試版本以進行測試） 目的）。 通過使開發(fā)團隊能夠管理發(fā)布和部署，組織可以擴展這些流程以支持甚至高度復雜的應用程序。

全周期開發(fā)團隊還經(jīng)常對其微服務負責運營。 取得成功的關鍵是實時了解其微服務的性能。 邊緣通過分析流入和流出微服務的所有流量，提供了對微服務行為的重要了解。 這使邊緣可以報告諸如延遲，吞吐量和錯誤率等指標，從而深入了解應用程序的運行狀況。

邊緣策略管理至關重要

考慮到邊緣在現(xiàn)代云原生工作流中的重要性，全周期開發(fā)團隊如何管理邊緣？ 不幸的是，傳統(tǒng)上邊緣堆棧的所有組件都由操作來管理，并且操作接口不適合全周期開發(fā)團隊中的應用程序開發(fā)人員使用。 此外，邊緣組件通常是隔離運行的，沒有內(nèi)聚的操作界面。 畢竟，全周期開發(fā)人員不是全職操作員； 他們只需要能夠滿足其特定需求的邊緣機器即可。

幸運的是，Kubernetes生態(tài)系統(tǒng)可以提供指導和啟發(fā)。 使用基于YAML的通用配置語言，開發(fā)人員可以管理自己的邊緣配置，而集中式運營團隊則可以執(zhí)行全局策略。 這是前沿團隊用來提供快速開發(fā)周期的最新的優(yōu)勢。

想了解更多？

這篇博客文章總結了大使團隊的首席執(zhí)行官Richard Li和產(chǎn)品架構師Daniel Bryant關于邊緣的未來的一些出色想法。 該主題在倫敦QCON上提出，值得一看。