任何拥抱Docker或Kubernetes等容器技术的人都毫无疑问听说过相关的下一件大事：服务网格，它承诺将微服务之间的内部网络通信同质化，并提供可观察性和容错性等非功能性特点。但是，支持服务网格的底层代理技术也可以在系统边缘提供 - 特别是在API网关内。

尽管服务网格技术可能在一夜之间突然出现，但现实情况是，许多公司一直在使用我们现在才认定为服务网格的技术已经相当一段时间（包括Verizon，eBay和Facebook）。比如Lyft，这是一家年收入10亿美元的美国乘车分享服务公司。Lyft也恰好是开源Envoy代理的创造者，该代理为服务网格的许多开发提供动力，例如Kubernetes原生Istio控制平面和Ambassador API网关。

SOA网络状态

Envoy Proxy的创造者之一Matt Klein在在去年的一次演讲中，认为调试很困难或者几乎不可能，每个应用程序都有不同的统计信息和日志记录，无法跟踪整个请求/响应的服务调用路径。基础架构组件（如托管负载平衡器，缓存和网络拓扑）的可见性(可管理性)也很有限。

“这很痛苦，”他说。“我认为大多数公司和大多数组织都知道SOA（微服务）是未来，但调试是困难的。“

保持分布式网络应用程序的可靠性和高可用性是大型公司的核心挑战。具有挑战性的方案通常包括重试逻辑的实现、超时、速率限制和断路等。许多定制的或开源解决方案都使用了特定语言（甚至可能是特定于框架的）解决方案，这意味着工程师无意中将自己锁定在“基本上永远”的技术堆栈中(banq注，大概指的是Spring Cloud)。Klein和他在Lyft的团队认为必须有更好的方法。最终，Envoy代理项目被认为是更好的方式。(banq注：Istio/Envoy与Spring cloud是互补关系？)

在微容器外部工作：边缘代理的好处

虽然Envoy Proxy项目的开源版本使得Klein和Lyft工程团队在2016年9月看起来像是一夜之间取得成功，但现实情况是，这一过程在微服务和服务网络系统之间充满了挑战。在最近一次关于2017年微服务实践者虚拟峰会的演讲中，Klein谈到了从面向技术转向服务网状网络拓扑的商业价值和相关挑战。

Klein第一个珍贵建议是“从边缘代理开始”。基于微服务的Web应用程序需要边缘反向代理以避免内部业务服务接口的暴露（因为这会违反松耦合的原则），也避免通过独立的URI或RPC端点暴露每项服务的高运营开销。现有的云产品在这个边缘代理或网关领域“不太友好”，或者作为潜在令人困惑的不同产品呈现给工程师。相反，Klein建议在边缘开始实施现代代理技术，这会提供了改进的可观察性、负载平衡和动态路由的等业务价值。

边缘的演变：从代理到API网关

AppDirect是用于管理基于云的产品，并估计有5000万$年收入的端到端的电子商务平台，实现了类似Lyft方式，他们在最近的一篇博客强调，为了通过微服务的组合实现提供的业务功能，在暴露公共端点方面充满了挑战。

AppDirect工程团队采取了一系列措施来解决这些挑战：首先将配置的核心部分设置为静态（例如暴露的服务端口）并将负载平衡器放置在每个应用程序的前端。他们的第二次迭代使用HashiCorp的Consul分布式密钥/值存储和HAProxy反向代理来支持更多动态，该代理支持在运行时更改配置的“热重新加载”。然而，最终团队热衷于利用功能更加全面的API网关提供的更丰富的功能。

“我们使用API网关的目标是让暴露的公共API不可接触但是可访问，这样可通过”注入“逐个替换旧的组件，逐步发展壮大。” 。

在评估了一系列开源和商业产品之后，AppDirect团队部署了基于Envoy代理构建的Kubernetes的API网关：

“完全依赖于Kubernetes原生API - 我们了解并且喜欢 - Ambassador是轻量级，无状态的，并且不使用外部数据存储。Ambassador专门利用Kubernetes注释来驱动主动路由配置（即它是Envoy数据面板的控制面板），“该小组在博客文章中指出。

虽然AppDirect尚未完全实施内部通信的服务网格，但该公司已经了解Envoy代理等技术的好处，并且至关重要的是，如何在生产环境中处理这种部署。

让所有人都感觉到它

在云应用实施和迁移中采用服务网格技术才刚刚开始，但已经有可能确定该技术填补了当前技术与现代基于容器的应用程序平台（如Kubernetes）的差距。服务网格的所有优点（如速率限制，断路和可观察性）也可以在系统边缘获得并利用。如果你想探索和了解这项技术，从系统的边缘开始并努力工作可能是一种有效的策略。这也可以使该技术比试图彻底解决问题更早显示价值，例如提高可观察性和弹性。