两年多来，我一直在帮助宣传服务网格和Envoy Proxy。看到社区是如何发展的，更重要的是组织如何开始使用它来解决困难的生产和运营问题，这真是令人惊喜。凭借我在Red Hat和现在的Solo.io的时间经历，我很幸运能够与各组织密切合作，共同开展服务网络采用之旅。
在这段实际，我开发了下面方法来成功地在生产中采用服务网格：
- 深入熟悉最终服务网格的数据平面技术
- 首先使用共享网关理想地使用较小部分的流量来操作数据平面
- 选择应用程序的子集以启用网状（基于边车）网络
- 慢慢启用提供最大价值的服务网格功能
- 冲洗并重复步骤2-4
我离开Red Hat加入Solo.io的一个重要原因是我们对服务网格的看法，包括这个简单的采用列表，非常好。本博客的其余部分是我们目前如何帮助客户使用网关和数据平面优先方法来采用服务网格。
了解Envoy代理
Envoy特使已成为许多服务网格技术的基础数据平面。像Istio，Consul Connect，AWS App Mesh，Grey Matter（以及其他来自现有API管理供应商的网站）的网格都基于Envoy。
它是一种极其强大，多功能，复杂的技术。过去在消息传递基础设施上工作的原理就是：将消息（或字节）从一个管道传递到另一个管道，表面上似乎很容易，但实际上它比你想象的要难得多。理解Envoy的工作方式非常重要，包括各种过滤器，收集的遥测技术以及配置API的工作原理。通过在您的环境中运维Envoy获得经验，才是获得理解它的最好方式。
(banq注：基于K8s的服务网格比消息系统其实更复杂，同步调用服务虽然方便请求响应模型，但是严重忽视分布式系统的网络不可靠性，为了防止网络不可靠，各种遥测技术都是事后诸葛亮。但是服务网格作为API网关还是值得期待的，可以替代将消息系统作为API网关的模式，但是内部服务之间调用还是有同步和异步之分)
理想情况下，您可以从单个Envoy部署（逻辑单一）开始，部署在您的应用程序前面。
使用基于Envoy的网关作为踏脚石
在采用服务网格时，使用Envoy作为共享网关是一个很好的起点。在我的书“ Istio in Action”中，我在本书的开头附近介绍了Istio Gateway资源及其相关配置，因为这是开始使用Istio的最佳方式。Gateway是在Envoy的基础上构建的，可以在不需要构建完整网格的情况下使用微服务（即，在所有应用程序旁边注入sidecars）。
使用网关来引导您的应用程序意味着您可以获得运行Envoy的运营体验以及获得“service-mesh lite”体验。当网关到位时，您可以获得一些强大的流量路由控制（包括基于百分比的路由，基于头/方法的路由，以及影子流量等），TLS终止/直通，TCP控制等。
像Istio Gateway这样的简单网关可能是一种很好的方式，可以在启动时为您的群集提供基本流量入口，但是基于Envoy构建的功能更全面的API网关可能会带来更多好处。
基于Envoy的更好的网关
现实情况是，当将集群/未来服务网格之外的客户端连接到集群/服务网格中运行的服务时，必须考虑到一个严峻的现实：现有组织已经知道流量如何流动并且应该受到保护。
例如，当通过网关将流量引入群集或新服务网格时，我们需要解决以下问题：
- 高速缓存
- 尖峰捕获/限速
- 最终用户/客户端oauth流
- HMAC /消息签名
- jwt验证（包括与现有JWT发行人或身份管理集成）
- Web应用程序防火墙（WAF）
- 消息转换
- API编排
还有很多其他，换句话说，这个入口点需要比基本的Envoy网关（即Istio的网关）更强大和更强大。它需要处理API网关中常见的熟悉的边缘功能。
Solo.io的Gloo是一个基于Envoy Proxy的API网关，它提供了两全其美的优势：
- 通过简化采用单个前端网关的体验以及服务网格的垫脚石
- 能够处理熟悉的API网关功能。
（省略Solo营销介绍....）
总结
如果您正在使用服务网格，请记住上述这种简单、经过验证的真实采用方法。特使Envoy是事实上的服务网格数据平面（Linkerd除外 - 至少在此时）并且围绕Envoy构建策略是重要的第一步。如果您正在探索不是基于Envoy构建的API管理或网关L7网络技术，您可能希望重新审视一下，特别是如果您正在寻找一个简单的服务网格入口通道时。