这一次说一下云原生中的代理网关envoy。在具体讲解它的作用前，需要先简单介绍下云原生架构中两个重要的概念，分别是
- • Service Mesh (服务网格)
- • Sidecar Service (边车服务)
只有对云原生架构中的这两个概念清楚后，才能理解envoy的作用。
服务网格
要理解服务网格，就得从云原生架构的特征说起。
云原生架构的一个重要的特点就是，服务是微小，繁多且是分布式的，服务相互之间的调用非常频繁。还有可能会有不同云混合部署，调用函数式服务等各种情况存在。
但无论是哪种情况而言，这些不同的服务之间的调用一定存在一个问题需要解决，那就是：
服务之间的网络是不可靠的
所以对于云原生架构来说，解决服务网络的可靠性就是一个非常重要的点。解决网络的可靠性无非是以下一些方式或措施，重试，超时，熔断，负载等。问题在于如何去实现这些策略，
- • 你可以为每个服务编码去实现类似的网络机制？虽然这样并不是不可以，但它显然加大了编码的复杂度，服务得关注与自己无关的一些特性。
- • 可以在团队或项目范围内提供模板服务，这些模板就提供了类似的机制，这也不失为一种方式。但它本质上仍然是每个服务需要关注这样的概念。
- • 在架构层面，提供独立于服务之外的架构能力，支撑调用服务的重试，限流，超时，负载等。这是不是一个更好的方式？
是的，这就是服务网格要解决的问题。
在云原生架构中，服务网络就是给架构提供了一个独立于服务之外的基础平台能力，它独立于应用之外，支撑调用服务的网络重试，超时，负载等；甚至进一步的提供统一的网络信息数据收集与分析，链接追踪等能力。这都是服务网格的能力。
服务网格通常由两部分组成，一个是control plane，另一个是data plane。其中control plane相当于控制平台，而data plane则是绑定每一个需要网格能力的服务并实现类似重试，限流，超时，熔断等能力。
对于云原生架构来说，服务网格当前有两个流行的选择，一个是istio envoy，另一个Linkerd。
今天要说的envoy，其实就是服务网格中承担data plane角色的技术实现。
边车服务
在Dcoker中，部署的最小基本单位提Continer，而在K8S中，部署的基本最小单位是Pod。
Pod是由一个或多个Continer组成的，大多数情况下，你可以把一个容器部署成为一个Pod。当然，也可以在一个Pod中部署多个容器。
多个服务在一个Pod中有几种不同的情况存在，其中一个就是一个是主服务，另一个是提供一些附加能力的服务。比如代理，日志收集，链路追踪等。
这种部署模式，或者这种额外能力的组件，我们就称它为sidecar（边车服务）
我画了一个图来示意边车服务是什么，图中包含了一个普通的Pod，以及一个带边车服务的Pod
边车服务
现在你应该很清楚了，所谓sidecar（边车服务）通常指的是在Pod中，给主服务提供附加功能的服务。这个概念只在K8S中存在，类似Docker则做不到这样，因为K8S是以Pod为最小部署单位，而一个Pod允许有一个或多个容器。
Envoy
好了，如果你能理解云原生K8S中的服务网格以及边车服务两个比较重要的概念。那再来解释Envoy就比较简单了。
Envoy就是做代理的。类似的技术有Nginx代理，Kong代理等。
那你可能会很好奇，为什么不用nginx或kong做代理？因为Envoy是专门为云原生，K8S这样的容器编排而设计与实现的，当然在云原生架构中更优的选择。
Envoy其实可以做边车服务，也可以像kong一样，做普通的代理网关服务。但在云原生架构中，通常是将它与istio结合起来使用，实现服务网格的能力。而针对这两者，istio通常是承担control plane的职责与角色，而Envoy则是承担data plane的角色。
Envoy能做什么？使用Envoy来做代理，可以做到请求重试，超时控制，熔断，限流以及负载等能力。调用一个服务，其实是调用这个服务对应的Envoy边车服务，由Envoy再来根据策略配置进行处理，比如请求多次，超过多久就失败不再请求等。
在云原生架构中，使用Envoy的优点主要表现在：
Envoy是服务进程之外的架构能力
这是它最大的优点，也就是你不需要在代码层级去考虑代理的各种功能要如何实现，直接基于云原生的这种进程外的架构能力，就能实现服务的各种网络代理上的能力。让你的服务更专注于业务，技术方面的能力不需要去关心与实现。
这简化了服务的技术方面的复杂度
Envoy支持各种协议
Envoy是网络层L3/L4层的架构，这意味着它支持TCP proxy,UDP proxy, Http proxy等各种不同的网络协议。适应度非常广
同时支持HTTP/1.1 and HTTP/2
支持HTTP/2,这意味着它支持gRPC。对于云原生架构中，gRPC是一个非常重要的技术，相比HTTP，优势非常明显。
与语言技术无关
Envoy是独立于服务之外的代理能力，这意味着在一个云原生架构中，无论是你Java或是Go还是其它任何一种语言实现，都能够和Envoy搭配使用。
这使得它非常适合异构技术的云原生架构。
Linkerd
最后，说起Envoy时，不得不说起另一个云原生技术，那就是Linkerd了，它同样是一种服务网格的实现。
一个简单足以概述它们关系的公式是：Linkerd = Istio Envoy
而Envoy与Linkerd都是CNCF的项目，但Istio却不是的。但从使用率上来看， istio envoy占多数。
后面会聊到Linkerd的，再进一步谈一谈它们的区别。
关于Envoy，你最需要知道的就是，它是云原生架构中的代理边车服务能力。在云原生架构中，服务网格是必需的一种能力。因此对于Envoy，它可能是你需要掌握与学习的云原生技术之一了。
