代理的力量： 弥合开发与生产之间的差距

应用开发人员和网络架构师的世界除了他们各自看待对方领域的方式不同之外，可能有很大差异。

应用部署的典型网络视角通常是这样的：

而在“墙”的另一边，开发人员对同一应用部署的看法通常是这样的：

毫无疑问，两者在各自的领域都是准确的，但对于对方的实际架构却极为漠不关心。 这说明了为什么应用投入生产时会出现许多问题。 他们确实站起来了。 研究指出，2013 年“90% 的开发人员表示，他们利用周末、节假日和假期来解决生产阶段的应用程序紧急情况[1]”。 虽然其中许多问题肯定与软件缺陷和错误有关，但其他许多问题无疑是由环境的诸多差异引起的。 生产不是开发，反之亦然。

当今的应用利用生产环境中存在的各种服务，但在开发或测试环境中很少使用：用于可扩展性的负载均衡器、用于提高性能的缓存以及用于安全性的 Web 应用程序防火墙。 这些服务不仅会在用户和应用程序（或者应用程序和 API，如果你愿意的话）之间的网络中触及每一个请求和响应，而且在某些情况下，它们还会修改请求和/或响应。 一个很好的例子就是用户的 IP 地址。 该值存在于每个请求的 HTTP 标头中，但当它通过负载均衡代理时，它将成为代理的 IP 地址，而不是客户端的 IP 地址。

对于毫无戒心的开发人员来说，这可能会导致应用“崩溃”，并导致数小时的故障排除，以及修改应用程序所需的时间。这些由环境差异引起的问题无疑是 28% 的开发人员在调查中表示[2] 在 2015 年中表示“通过正确的测试环境，可以发现并修复 50% 以上的生产问题。” 超过一半（52%）的受访者表示“25%至50%的生产问题将得到解决”。

生产中出现的许多问题直接归因于应用的差异，特别是使用敏捷方法开发的应用程序的差异。 由于代码变化的频率，敏捷方法会增加生产中出现此类冲突的可能性。

越来越多的（但绝不是全部）这些挑战可以通过使用可编程代理来解决，因为这样做无需更改已在生产中的代码，也无需进一步延迟将应用交付到市场。 前面提到的“IP 地址”问题通常通过指示代理插入包含实际 IP 地址的新HTTP 标头来解决，以便开发人员仍然可以访问该信息，并且第 7 层负载均衡代理擅长根据各种数据（包括版本控制和 API 签名）路由应用和 API 请求。

值得注意的是，软件和网络工程图中经常提到的一个组件是负载均衡器。 尽管此代理传统上是由网络团队部署和管理的，但它对应用架构来说至关重要，因此它几乎总是作为应用的一部分包含在内。 同样，开发人员认识到当今负载均衡对于扩展应用的重要性，并通常将其包含在他们的图表中。

这也反映了越来越多的情况，开发人员和操作人员已承担起可扩展性的责任，从而控制了其应用的负载均衡。  这是一件好事，因为这意味着开发和运营可以（并且希望）在 CI/CD 管道中包含负载均衡（及其所有第 7 层优点），特别是在测试期间，以确保在投入生产之前可以快速发现并解决任何潜在问题。 将负载均衡转移到 CI/CD 管道中还可以实现更全面的持续交付方法，其中整个应用包（架构）作为代码进行管理，并可同时更新。 这使得网络基础设施（因为在描述负载均衡时，传统上就属于这一类）能够支持不可变的架构，在该架构中，应用（或者如果采用这种方式，则是微服务）可以完全使用新配置重新部署，而不是简单地进行更新，从而避免可能带来挑战和技术债务的自然软件熵。

代理在很多方面都是连接“网络”和“应用”的桥梁，跨越了软件和网络工程师与架构师之间的象征性鸿沟（如果我们诚实的话，更像是一堵墙）。 如果组织要扩展以应对现代架构的挑战，这是 DevOps 需要弥补的差距之一。

[1] http://solutions-review.com/mobile-应用-development/5000-developer-survey-mobile-app-development-insights-revealed/

[2] https://www.ravellosystems.com/blog/software-is-not-quite-ready-to-eat-the-world-state-of-devtest-infrastruct-survey-results/