了解数据中心边缘的转变

随着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上提出，值得一看。