了解数据中心边缘的转变

了解数据中心边缘的转变

早期的Internet和负载平衡器

在1990年代中期，Web应用程序体系结构还处于起步阶段。 由数据库层，应用程序层和表示层组成的经典n层体系结构是此时的实际应用程序体系结构。 通过使用数据中心边缘的第一个迭代：负载平衡器，将应用程序层或表示层的多个实例连接到Internet，可以对n层体系结构进行水平扩展。 在这个时代，负载平衡器负责在应用程序的不同实例之间路由流量，以确保高可用性和可伸缩性。 尽管2001年HAProxy的发布开始普及软件负载平衡器的概念，但负载平衡器通常是一种硬件设备。

达到网络规模

在2010年代初期，许多云计算第一公司的用户群经历了指数级增长。 这些公司背后的软件最初是作为整体Web应用程序设计的。 随着他们的用户群激增到天文数字，这些公司发现网络规模的问题确实是指示不同体系结构的另一类问题。 Twitter，Facebook和New Relic等公司开始将关键功能部件从整体中重构为独立部署的服务。 通过将关键业务功能部署为服务，这些组织能够独立扩展和管理整个应用程序的不同方面。 这些独立服务的流量通过整体路由。 路由的任何更改都意味着开发人员经常不得不重新部署整个整体。 这成为改变速度的瓶颈，但至少解决了规模问题。

救援API网关

解决了规模问题的尖端组织现在面临着解决整体应用程序问题的问题，这正拖慢了他们的应用程序开发速度。 从这些体系结构中获得的经验之一是显而易见的-对于重构服务，整体组件只是充当路由器。 这一发现引发了早期API网关的发展。 API网关执行原始整体中的路由功能，从而为整个应用程序创建通用外观。 API网关集中了跨领域的应用程序级功能，例如速率限制，身份验证和路由。 这减少了每个单独服务中所需的复制功能量。

云原生时代：微服务

整体已成为微型，但它仍然存在并减慢了应用程序的开发和部署。 微服务介入解决了这个问题。 每个微服务代表一个独立的业务功能，并且独立于应用程序的其他微服务而开发和发布。 通过解耦开发周期，微服务使组织能够更有效地扩展云的软件开发流程。 鉴于微服务可以部署在多种环境中：虚拟机，裸机，容器作为功能— API网关在将流量路由到正确的微服务中起着至关重要的作用。

现在到未来—转向全周期开发和云原生工作流程

微服务不仅仅是应用程序体系结构的转变。 微服务也是开发工作流程中的一种转变。 团队负责整个软件开发生命周期-从设计到开发再到测试再到部署和发布。 一些组织将这些团队作为呼叫轮换的一部分（"又名，就创建，就运行"）。 这种开发模型被Netflix称为全周期开发，它是软件开发和交付方式的一次转变。

工作流程的这种转变也对数据中心优势产生了影响。 API网关（以及边缘堆栈的其他元素）不仅需要适应微服务架构，而且整个周期的开发团队都需要访问和管理整个边缘。 此管理包括路由（服务的哪个版本应接收生产流量）以及更精细的控件，例如加权路由（金丝雀版本需要）和流量屏蔽（将流量的副本创建到服务的测试版本以进行测试） 目的）。 通过使开发团队能够管理发布和部署，组织可以扩展这些流程以支持甚至高度复杂的应用程序。

全周期开发团队还经常对其微服务负责运营。 取得成功的关键是实时了解其微服务的性能。 边缘通过分析流入和流出微服务的所有流量，提供了对微服务行为的重要了解。 这使边缘可以报告诸如延迟，吞吐量和错误率等指标，从而深入了解应用程序的运行状况。

边缘策略管理至关重要

考虑到边缘在现代云原生工作流中的重要性，全周期开发团队如何管理边缘？ 不幸的是，传统上边缘堆栈的所有组件都由操作来管理，并且操作接口不适合全周期开发团队中的应用程序开发人员使用。 此外，边缘组件通常是隔离运行的，没有内聚的操作界面。 毕竟，全周期开发人员不是全职操作员； 他们只需要能够满足其特定需求的边缘机器即可。

想了解更多？

这篇博客文章总结了大使团队的首席执行官Richard Li和产品架构师Daniel Bryant关于边缘的未来的一些出色想法。 该主题在伦敦QCON上提出，值得一看。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。