这些基本的应用程序网络问题并非特定于某个应用程序、语言或框架。例如，重试、超时、客户端负载均衡，或者熔断等，这些问题与应用程序功能本身相互独立。作为整个服务的一部分，它们是关键问题，但是为使用的每种语言或者框架投入大量时间和资源，以便在特定于语言或框架中实现类似的功能，这不应该是最佳的解决方法。我们真正想要的是以一种技术无关的方式来解决这些问题，并减轻特定于应用程序本身来实现。
Linux容器简化了应用程序的打包部署，容器是云原生应用的基石，通过应用容器化，不仅使得开发部署更加敏捷、迁移更加灵活，并且可将这些实现标准化。而容器编排则是更近一步，负责解决如何高效地编排和利用好这些资源。Kubernetes编排容器服务已经成为一种事实标准；同时微服务与容器在轻量、快速部署、运维等特征方面已实现了匹配，微服务运行在容器中也正成为一种标准实践。不论使用什么具体的语言与编程框架，针对应用程序的构造、部署、服务暴露、服务关联/反关联、健康检查以及扩展等，通过使用Kubernetes即可将其提升到新的水平。实际上，Kubernetes也有一个简单的负载均衡和服务发现机制。在Kubernetes中，我们可以使用单个虚拟IP与后端pod进行通信。Kubernetes将以轮询或随机方式自动将流量发送到pod。Kubernetes根据其健康状态以及它们是否与标签和选择器匹配来进行处理。然后，服务可以使用DNS进行服务发现和负载均衡，而不管其实现如何，也就是说无需特殊的语言特定库或注册客户端。在这种技术架构下，Kubernetes将简单的网络问题从应用程序转移到基础架构中。
Kubernetes是一个出色的容器部署和管理平台，它为创建通用的分布式系统管理并将其公开为基础架构服务树立了榜样。但是，Kubernetes是一个容器部署平台，它不会演变或应用网络的其他诸多方面，它旨在通过API以非常自然的方式进行扩展，并期望将任何更高阶的应用程序服务构建为插件。而类似于Istio的这些服务网格技术在微服务治理上很好地补齐了Kubernetes的功能，同时又与Kubernetes有着完美的集成，不同于现有的微服务架构，如SpringCloud、Dubbo、Netf lix OSS等。
将这些问题转移到基础架构中的另外一种方法是使用代理。代理是一个中间基础架构组件，可以处理连接并将它们重定向到适当的后端。我们可以使用代理来处理网络流量，强制执行安全策略以及对后端服务器进行负载均衡等工作。例如，HAProxy是一种简单但功能强大的反向代理，用于在多个后端服务器之间分配连接；mod_proxy是Apache HTTP服务器的一个模块，它也可以充当反向代理。在我们的企业IT系统中，通常所有传出的互联网流量都通过转发代理进行路由，这些代理监视流量并阻止某些类型的活动。
当然，我们需要一个七层代理。这个服务代理将需要理解应用程序架构，能够支持诸如重试、超时、熔断、客户端负载均衡、服务发现、安全性和指标收集等功能，并且不局限于任何特定的语言或框架依赖。