Envoy：路由转发和反向代理功能。一般作为网关或者反向代理。代理转发功能类似的有：nginx、kong、envoy。从某种程度上讲，服务网格是解决服务之间的通信和服务治理问题。
dubbo就是一个带有服务治理功能的RPC框架。它是一套完整的解决方案。dubbo提供了一套较为完整的服务治理方案，所以企业如果要实现服务化的话，dubbo 是很好的一个选择。目前实现微服务治理主要有两种方式，第一种以SDK的方式侵入业务代码中，第二种以进程外方式(sidercar)代理。其中第一种方式已有很多成熟方案，如Dubbo；而第二种即为当前火爆的Service Mesh，如Istio。
微服务带来很多好处的同时也引入了很多问题。在云原生模型里，一个应用可以由数百个服务组成，每个服务可能有数千个实例，每个实例的状态可能持续的发生变化，此时，服务间的通信不仅异常复杂，而且都是运行时的行为，管理好服务间通信对于保证端到端的性能与可靠性来说无疑成为重中之重。在Service Mesh没有出现之前，微服务框架之间的通讯大多采用SDK方案，但该方式短板也非常明显，例如对业务有侵入性、无法做到SDK升级对业务透明等。
在传统模式下，如果微服务之间要进行通信，那么程序需要自己处理各种通信的细节，这就包括服务发现、熔断机制、超时重试和 tracing 等功能。这些功能通常实现为与某种编程语言相关的 library，这也导致了这样的 library 无法在不同的编程语言之间共享。
如果我们可以将这部分功能抽取出来，形成一个独立的进程，这样的进程称为 Sidecar。通常来说，我们会将应用程序和 Sidecar 部署在一起，那么程序的入口流量和出口流量都会由这个 Sidecar 去代理，这样就可以通过 Sidecar 去实现服务发现、熔断机制、超时重试等功能了。
基于以上种种复杂原因催生了服务间通讯层的出现，这个层即不应该与应用程序的代码耦合，又能捕获到底层环境的动态变化并作出适当的调整，避免业务出现单点故障；同时也可以让开发者只关注自身业务，将应用云化后带来的诸多问题以不侵入业务代码的方式提供给开发者。
上述所说的这个服务间通讯层就是Service Mesh（国内通常翻译为服务网格），它可以提供安全、快速、可靠的服务间通讯。如果用一句话来解释什么是Service Mesh，可以将其比作微服务间的TCP/IP层，负责服务之间的调用、限流、熔断和监控等。
很多场合中会听到Envoy支持Polygoat,好像用了Envoy就不用SDK了。这种说法显然是错觉。SDK是一定要的，为了支持Polygoat，就要选多语言支持的SDK。因为调用另一个服务的代码还是发生在自己的程序中，这不是Envoy可以替代的。Envoy所说的省却SDK开发，是指所谓的“胖SDK”， 就是包括了服务发现和路由功能的SDK，类似大家现在用的Dubbo，那的确是会让SDK瘦身的。但是如果用了RSocket的Broker，这些SDK同样也不用再“胖”了，而且RSocket协议也有不同语言的SDK。
从部署架构角度看Envoy
完整Sidecar模型部署，这是Envoy最大的部署特征，services之间的通信完全转化为Envoy代理之间的通信，从而实现将诸多非业务功能从服务代码中移出到外部代理组件，Envoy负责网络通信控制与流量的可观测。也可以部署为简化的sidecar，其仅充当service入站方向的代理，无需额外的流量操纵，这个结构在我对外阐述的基于NGINX实现业务可观测性中所使用。
Hub型，这与NGINX的MRA中的Router-mesh型理念相同，所有服务使用一个集中的Envoy进行通信，这种部署结构一般适用于中小型服务，可通过与服务注册的适配将服务流量导向到Envoy。
Envoy也可以作为Ingress edge网关或Egress 网关，在这种场景下一般Envoy多用于Ingress controller或API 网关，可以看到很多的此类实现喜欢使用Envoy作为底层，例如Gloo, Ambassador等。
下面这个部署结构应该是大家比较熟悉的，Envoy作为一个Edge 网关，并同时部署额外一层微服务网关（或代理平台层）。充当反向代理的 Envoy，通常也可以称为 Edge Envoy。
最后，这是将所有形态的Envoy部署集中到了一起，这种架构可能会在服务从传统架构向微服务架构迁移过程的中间形态。
总结来看，由于Envoy的跨平台性，使其具有和NGINX一样的灵活部署结构，但是实际上部署结构往往与最终的配置实现机制有着强关系，软件的能力能否适应在此结构下的灵活与简单的配置实现是最终考验。客观的讲，在这方面Envoy更具有优势。
深入理解Envoy
要深入理解Envoy，首先需要先了解一下Envoy中的一些术语。
Host：能够进行网络通信的实体（如服务器上的应用程序）。
Downstream：下游主机连接到Envoy，发送请求并接收响应。
Upstream：上游主机接收来自Envoy连接和请求并返回响应。
Listener：可以被下游客户端连接的命名网络（如端口、unix套接字）。
Cluster：Envoy连接到的一组逻辑上相似的上游主机。
Mesh：以提供一致的网络拓扑的一组主机。
Runtime configuration：与Envoy一起部署的外置实时配置系统。
Istio Service Mesh
Envoy的启动配置文件分为两种方式：静态配置和动态配置。
静态配置是将所有信息都放在配置文件中，启动的时候直接加载。
动态配置需要提供一个Envoy的服务端，用于动态生成Envoy需要的服务发现接口，这里叫XDS，通过发现服务来动态的调整配置信息，Istio就是实现了v2的API。
最后两行是精华
Envoy与K8S
可以作为K8S网关，可以作为反向代理，可以作为服务网格的边车。
K8S核心功能：
容器编排：容器编排将部署、管理、弹性伸缩、容器网络管理都自动化处理。需要管理成百上千 Linux® containers 和主机的企业将从容器编排中获得极大优势。有很多用于容器生命周期管理的容器编排工具，比如常见的Kubernetes, Docker Swarm, Apache Mesos。--将N台机器（集群）对外像是一台机器一样。简单demo
自愈: 重新启动失败的容器，在节点不可用时，替换和重新调度节点上的容器，对用户定义的健康检查不响应的容器会被中止，并且在容器准备好服务之前不会把其向客户端广播。
弹性伸缩: 通过监控容器的cpu的负载值,如果这个平均高于80%,增加容器的数量,如果这个平均低于10%,减少容器的数量
服务的自动发现和负载均衡: 不需要修改您的应用程序来使用不熟悉的服务发现机制，Kubernetes 为容器提供了自己的 IP 地址和一组容器的单个 DNS 名称，并可以在它们之间进行负载均衡。
滚动升级和一键回滚: Kubernetes 逐渐部署对应用程序或其配置的更改，同时监视应用程序运行状况，以确保它不会同时终止所有实例。 如果出现问题，Kubernetes会为您恢复更改，利用日益增长的部署解决方案的生态系统。
Envoy 和 Nginx 对比
Nginx的关键词是Web服务器和反向代理，Envoy是透明接管流量，更加体现对流量的控制和掌控力。另外，从使用方式上看，微服务对Nginx是显式调用，通过Nginx完成负载均衡等相关功能，对Envoy是隐式调用，业务微服务不需要感知Envoy的存在，和使用Envoy使用相同的方式进行通信，只不过不再需要关注通信和链路治理的细节。
网友评论