envoy proxy_envoy proxy配置静态资源

envoy proxy_envoy proxy配置静态资源

       大家好，今天我来为大家详细地介绍一下关于envoy proxy的问题。以下是我对这个问题的总结和归纳，希望能对大家有所帮助。

1.ServiceMesh & Istio

ServiceMesh & Istio

        服务网格（ServiceMesh）号称是下一代微服务架构。

        互联网公司，经常使用的是微服务分层架构。

        画外音：

        为什么要服务化，详见 服务化解决了什么问题？

        随着数据量不断增大，吞吐量不断增加，业务越来越复杂，服务的个数会越来越多，分层会越来越细，除了数据服务层，还会衍生出业务服务层，前后端分离等各种层次结构。

        画外音：

        分层的细节，详见《 互联网分层架构演进 》。

        不断发现主要矛盾，抽离主要矛盾，解决主要矛盾，架构自然演进了，微服务架构，潜在的主要矛盾会是什么呢？

        引入微服务架构，一般会引入一个RPC框架，来完成整个RPC的调用过程。

        如上图粉色部分所示，RPC分为：

        画外音：

        《 离不开的微服务架构，脱不开的RPC细节 》。

        不只是微服务，MQ也是类似的架构：

        如上图粉色部分所示，MQ分为：

        画外音：

        《 MQ，互联网架构解耦神器 》。

        框架只是第一步，越来越多和RPC，和微服务相关的功能，会被加入进来。

        例如：负载均衡

        如果要扩展多种负载均衡方案，例如：

        RPC-client需要进行升级。

        例如：数据收集

        如果要对RPC接口处理时间进行收集，来实施统一监控与告警，也需要对RPC-client进行升级。

        画外音，处理时间分为：

        客户端视角处理时间

        服务端视角处理时间

        如果要收集后者，RPC-server也要修改与上报。

        又例如：服务发现

        服务新增一个实例，通知配置中心，配置中心通知已注册的RPC-client，将流量打到新启动的服务实例上去，迅猛完成扩容。

        再例如：调用链跟踪

        如果要做全链路调用链跟踪，RPC-client和RPC-server都需要进行升级。 下面这些功能：负载均衡数据收集服务发现调用链跟踪…其实都不是业务功能，所以互联网公司一般会有一个类似于“架构部”的技术部门去研发和升级相关功能，而业务线的技术部门直接使用相关框架、工具与平台，享受各种“黑科技”带来的便利。

        完美！！！ 理想很丰满，现实却很骨感，由于：

        往往会面临以下一些问题：

        画外音：

        兄弟，贵司推广一个技术新产品，周期要多长？

        这些耦合，这些通用的痛点，有没有办法解决呢？

        一个思路是，将服务拆分成两个进程，解耦。

        画外音：

        负载均衡、监控告警、服务发现与治理、调用链…等诸多基础设施，都放到这一层实现。

        这样就实现了“业务的归业务，技术的归技术”，实现了充分解耦，如果所有节点都实现了解耦，整个架构会演变为：

        整个服务集群变成了网格状，这就是Service Mesh服务网格的由来。

        要聊ServiceMesh，就不得不提Istio，它是ServiceMesh目前最流行的实践，今天说说Istio是干啥的。

        画外音：不能落伍。

        什么是Istio？

        Istio是ServiceMesh的产品化落地，它的一些关键性描述是：

        画外音：

        Istio helps you to connect, secure, control, and observe microservices

        画外音：

        佩服，硬是凑齐了十条，其实SM还能提供更多基础服务功能。

        画外音：

        说的还是解耦。

        Istio官网是怎么吹嘘自己的？

        画外音：

        这个问题的另一个问法是“为什么大家要来用Istio”。

        Istio非常牛逼，如果要实施ServiceMesh，必须用Istio，因为：

        画外音：

        你信了么？

        Istio的核心特性是什么？

        Istio强调了它提供的五项关键特性：

        画外音：

        断路器(circuit breakers)、超时、重试、高可用、多路由规则、AB测试、灰度发布、按照百分比分配流量等。

        Istio的吹嘘与特性，对于国外很多通过RESTful提供内网服务的公司，很有吸引力，但相对于国内微服务架构，未必达到了很好的拉拢效果：

        （1）国内基本都是TCP的RPC框架，多协议支持未必是必须的；

        （2）RPC框架里，路由、重试、故障转移、负载均衡、高可用都是最基础的；

        （3）流控、限速、配额管理，是服务治理的内容，在微服务架构初期是锦上添花；

        （4）自动度量，系统入口出口数据收集，调用跟踪，可观察和可操控的后台确实是最吸引人的；

        （5）服务到服务的身份认证，微服务基本是内网访问，在架构初期也只是锦上添花；

        另外一个花边，为什么代理会叫sidecar proxy？

        Istio这么牛逼，它的核心架构如何呢？

        关于Istio的架构设计，官网用了这样一句话：

        逻辑上，Istio分为：

        这两个词，是Istio架构核心，但又是大家被误导最多的地方。

        数据平面和控制平面，不是ServiceMesh和Istio第一次提出，它是计算机网络，报文路由转发里很成熟的概念：

        画外音：上两图为路由器架构。

        它的设计原则是：

        画外音：

        Istio的架构核心与路由器非常类似：

        （1）高效转发；

        （2）接收和实施来自mixer的策略；

        （1）管理和配置边车代理；

        （2）通过mixer实施策略与收集来自边车代理的数据；

        画外音：

        （1）sidecar proxy，原文使用的是envoy，后文envoy表示代理；

        （2）mixer，不确定要怎么翻译了，有些文章叫“混音器”，后文直接叫mixer；

        （3）pilot，galley，citadel，不敢翻译为飞行员，厨房，堡垒，后文直接用英文；

        如架构图所示，该两层架构中，有五个核心组件。

        Envoy的核心职责是高效转发，更具体的，它具备这样一些能力：

        （1）服务发现

        （2）负载均衡

        （3）安全传输

        （4）多协议支持，例如HTTP/2，gRPC

        （5）断路器(Circuit breakers)

        （6）健康检查

        （7）百分比分流路由

        （8）故障注入(Fault injection)

        （9）系统度量

        大部分能力是RPC框架都具备，或者比较好理解的，这里面重点介绍下断路器和故障注入。

        它是软件架构设计中，一个服务自我保护，或者说降级的设计思路。

        举个例子：当系统检测出某个接口有大量超时时，断路器策略可以终止对这个接口的调用（断路器打开），经过一段时间后，再次尝试调用，如果接口不再超时，则慢慢恢复调用（断路器关闭）。

        它是软件架构设计中，一种故意引入故障，以扩大测试覆盖范围，保障系统健壮性的方法，主要用于测试。

        国内大部分互联网公司，架构设计中不太会考虑故障注入，在操作系统内核开发与调试，路由器开发与调试中经常使用，可以用来模拟内存分配失败、磁盘IO错误等一些非常难出现的异常，以确保测试覆盖度。

        Mixer的一些核心能力是：

        （1）跨平台，作为其他组件的adapter，实现Istio跨平台的能力；

        （2）和Envoy通讯，实时各种策略

        （3）和Envoy通讯，收集各种数据

        Mixer的设计核心在于“插件化”，这种模型使得Istio能够适配各种复杂的主机环境，以及后端基础设施。

        Pilot作为非常重要的控制平面组件，其核心能力是：

        （1）为Envoy提供服务发现能力；

        （2）为Envoy提供各种智能路由管理能力，例如A/B测试，灰度发布；

        （3）为Envoy提供各种弹性管理能力，例如超时，重试，断路策略；

        Pilot的设计核心在于“标准化”，它会将各种流控的控制命令转化为Envoy能够识别的配置，并在运行时，将这些指令扩散到所有的Envoy。Pilot将这些能力抽象成通用配置的好处是，所有符合这种标准的Envoy都能够接入到Pilot来。

        潜台词是，任何第三方可以实现自己的proxy，只要符合相关的API标准，都可以和Pilot集成。

        Citadel组件，它提供终端用户身份认证，以及服务到服务的访问控制。总之，这是一个和安全相关的组件。

        Gally组件，它是一个配置获取、校验、处理、分发的组件，它的设计核心在于“解耦”，它将“从底层平台（例如：K8S）获取用户配置”与Istio解耦开来。

        Istio采用二层架构，五大模块，进行微服务ServiceMesh解耦：

        数据平面，主要负责高效转发

        （1）envoy模块：即proxy；

        （2）mixer模块：支持跨平台，标准化API的adapter；

        （3）pilot模块：控制与配置envoy的大部分策略；

        （4）citadel模块：安全相关；

        （5）galley模块：与底层平台（例如：K8S）配置解耦；

        实施与控制分离，经典的架构设计方法，GOT？

        思路比结论重要。

       好了，今天关于“envoy proxy”的话题就到这里了。希望大家能够通过我的讲解对“envoy proxy”有更全面、深入的了解，并且能够在今后的生活中更好地运用所学知识。