隨著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的通用配置語言，開發人員可以管理自己的邊緣配置，而集中式運營團隊則可以執行全局策略。 這是前沿團隊用來提供快速開發周期的最新的優勢。

想了解更多？

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