一个概念如果不能用一句话说明，则有可能是没有理解。
想起吴军在智能时代中所有，2%才有可能是不落后。
Istio 现在是 Service Mesh 中最火热的项目了，它主要负责对服务网格中的流量进行管理，包括动态服务发现、服务路由、弹性功能等。它作为 Service Mesh 的控制平面，配合 Envoy 作为数据平面，构成了 Service Mesh 中流量管理体系。
Istio 体系中流量管理配置以及相关机制比较冗杂，本文会尽量从整体上进行描述，不抠细节，以求有一个宏观的理解。
我们首先要明白为什么会催生出 service mesh 这样的架构，而要理解这一点，我们需要对比 2 种东西，即传统微服务架构以及原生 k8s 架构。
我们知道现有的微服务架构已经比较成熟了，拥有完善的服务注册发现与服务治理功能(包括限流熔断、负载均衡、流量路由等)，那么仍然困扰我们的是什么呢？
现有的微服务框架几乎都是集成于客户端 sdk 的，开发者在自己的应用中集成微服务框架 sdk，从而具有服务治理相关功能，那么这会带来 2 个几乎无法避免的问题:应用需要不断更新代码从而更新客户端 sdk，而这中间可能出现各种依赖冲突；应用集成并使用客户端 sdk 依赖于开发者的素质，常常导致效率低下。
这种情况下，我们自然而然地会想到使用 sidecar，将原先在 sdk 中的逻辑搬到 sidecar 上，在运维的时候与应用服务集成在一起，形成一种较 sdk 集成更先进的边车模式。这种方式对应用代码几乎没有侵入，并且也不受开发者的水平限制，完全做到了控制与逻辑的分离。当然作为易用性的代价，我们会失去一些性能。
sidecar 模式是 service mesh 相较微服务架构最主要的优点之一，而这在 service mesh 架构中也称为”数据平面”。
这里我们思考的是在 k8s 之上，我们还有什么不满足？k8s 使用 kube-dns 以及 kube-proxy 配合 service 的概念支持了服务的注册与发现，意味着我们有了可以在 k8s 上构建微服务的基础。但在实际生产中，我们往往需要对流量更精细的管控，我们希望对单个 pod 或者一组 pod 的流量进行管理，而不仅仅是 service 的维度。例如一个需求是我们需要将 endpoints 下的一部分 pod 作为 v1 版本，其余作为 v2 版本，而/v1 前缀的请求都将调度到 v1 版本，/v2 前缀的请求调度到 v2 版本。
sidecar 作为数据平面与每一个应用部署在同一 pod 中，这意味着我们可以做到对 pod 级别的流量做管理了，而具体实现这一逻辑的就是 service mesh 中的另一层:”控制平面”了。
Istio 是目前 Service Mesh 领域最火热的架构，我们来看看 Istio 的整体架构。
Istio 分为数据平面以及控制平面，数据平面以 sidecar 的形式与应用部署在一起，承载其流量的发送与接收，而控制平面则是通过配置和控制消息来组织编排网络的逻辑，并下发给数据平面。
我们简单讲一下其中的组件：
流量管理是 Istio 中最基础和最重要的功能了。我们之前说到我们的真实诉求往往是希望指定某个 pod 或者一组特定的 pod 接收流量，最基础的方式是通过人肉运维搞定，但更优雅地是将其委托给 Istio 本身，Istio 会通过 Pilot 与 Envoy 代理搞定这一切。
怎么搞定这一切呢，既然 kubernetes 中 service 的抽象概念满足不了我们的需求，很自然地我们尝试去抽象一些更上层的概念来解决问题。Istio 也是如此，我们来讲一下其中主要的一些基本概念(至于具体的配置，由于篇幅限制跳过)：
在 Istio 的控制平面中，Pilot 是负责流量管理的组件，也是本文的主角。Pilot 整体架构如下(来自old_pilot_repo，不过整体出入不大)：
我们看到 pilot 主要包含 2 个组件，即 Discovery services 和 Agent。
pilot agent 它不是本文的主角，我们简单介绍一下。它主要的工作包括：
pilot-discovery 是 pilot 中的关键组件，我们进行较为详细的描述。
pilot-discovery 的整体模型如下所示：
pilot-discovery 有两部分输入信息：
为了支持对不同服务注册中心的支持，所以需要有一个统一的数据存储模型，即 Abstract Model，和一个转换器 Platform Adapter 来实现各服务注册中心数据到 Abstract Model 的数据转换。当然除了注册中心数据外，Platform Adapter 还需将 VirtualService、DestinationRule 等 CRD 资源信息转换成 Abstract Model。
基于统一数据存储模型 Abstract Model，pilot-discovery 为数据面提供了控制信息服务，也就是所谓的 xds api 服务，从而得以将控制信息下发到数据面 envoy。
接下来我们讲讲 pilot-discovery 的一个整体流程。
pilot-discovery 首先干的事儿是进行一些初始化，初始化的工作内容包括：
我们之前讲 Istio 中流量策略等相关规则都是以 kubernetes CRD 的形式保存在 kubernetes api server 背后的 Etcd 中的，包括 VirtualService、DestinationRule。这些 CRD 资源当完成注册后，还创建了 config controller 来处理 CRD 的事件。
config controller 主要内容包括对每个 CRD 资源实现一个 list/watch，然后为其 Add、Update、Delete 等事件创建一个统一的流程框架，即将 CRD 对象事件封装成一个 Task 并 push 到一个 queue 里。随后启动协程依次处理 CRD 资源事件，即从 queue 中取出 Task 对象，并调用其 ChainHandler。
服务注册信息指的默认为 kubernetes 服务注册信息(当然也支持其他注册中心，但比较小众)，即 pod、service、endpoints、node 等资源。我们之前讲 Pilot 创建了一个 service controller 来实现对 kubernetes 资源的监控和处理。
service controller 的逻辑和 config controller 基本一致。为每种 kubernetes 资源都实现了一个 list/watch，然后将其 Add、Update、Delete 事件封装成 Task 对象 push 到 queue 中，随后启动协程从 queue 中取出并调用 CHainHandler。
我们知道，Envoy 是通过与 Pilot 暴露的信息服务交互从而得到服务发现/路由策略等相关信息的。pilot-discovery 创建了 gRPC 协议的 discovery 服务，通过 xDS api 与 Envoy 交互，包括 eds、cds、rds、lds 等。具体细节我们之后描述。
数据平面是 sidecar 方式部署的智能代理，在 Istio 体系中，数据面往往是由 Envoy 担任。Envoy 可以调整控制服务网格之间的网络通信，是控制面流量管理的实际执行者。
Envoy xDS 是为 Istio 控制平面与数据平面通信设计的一套 api 协议，也就是下发流量管理配置的关键。
首先在了解 xDS 之前，我们需要了解 Envoy 中的一些基本概念：
Envoy 整体架构如下所示：
Envoy 的工作流程为下游主机(Host A)发送请求至上游主机(Host B/C/D)，Envoy 拦截请求(代理注入及流量劫持我们不详细描述)，Listener 监听到下游主机请求后将请求内容抽象为 Filter Chains，并根据流量策略相关的配置信息路由至相应的上游主机集群(Cluster)，从而完成路由转发、负载均衡、流量策略等能力。
上述的流量策略相关的配置信息主要以动态配置的方式由 xDS api 实现，也是我们关注的重点。此外，Envoy 作为流量代理还可以将部分配置以静态配置的方式写入文件中，启动时候直接加载。
所谓 xDS，这里的 x 是一个代词，在 Istio 中，主要包括 cds(cluster discovery service)、eds(endpoint discovery service)、rds(route discovery service)、lds(listener discovery service)，ads(aggregated discovery service)则是对这些 api 的一个封装。
在以上 api 引入的概念中，endpoint 表示一个具体的应用实例，对应 ip 和端口，类似 kubernetes 中的一个 pod。cluster 是一个应用集群，对应一个或多个 endpoint，类似 kubernetes 中 service 的概念(实际上应该更小一些)。route 即当我们做类似灰发、金丝雀发布时，同一个服务会运行多个版本，每个版本对应一个 cluster，这时就需要通过 route 规则规定请求如何路由到某个版本的 cluster 上。
在实际请求过程中，xDS 接口采用的顺序如下：
不过目前这个流程都已整合在 ADS 中，即聚合的服务发现，ADS 通过一个 gRPC 流以保证各个 xDS 接口的调用顺序。
我们之前讲过 pilot-discovery 的工作包括会创建一个 discovery 服务。现在它会与每一个 Envoy 建立一个双向 streaming 的 gRPC 连接，Envoy proxy 则会通过 ADS 接口按照上述的调用逻辑发起请求，并将 Pilot 的流量管理关键概念 VirtualService、DestinationRule 等组装成 cluster、endpoint、router、listener 等 envoy 配置。最终这些动态配置会作用在每一个 Envoy Proxy 上，当 Envoy listener 监听到下游主机请求时，就可以根据这些配置完成实际的动态服务发现、流量管理等功能。
描述： 下午快下班的时候公司供应链部门的同事跑过来问我能不能以程序的方法帮他解决一些excel表格每周都需要手工重复做的事情，Excel 是数据处理最常用的办公工具对于市场、运营都应该很熟练。哈哈，然而程序员是不怎么会用excel的。下面给大家介绍一下pandas, Pandas是一个强大的分析结构化数据的工具集；它的使用基础是Numpy（提供高性能的矩阵运算）；用于数据挖掘和数据分析，同时也提供数据清洗功能。
具体需求：
找出相同的数字，把与数字对应的英文字母合并在一起。
期望最终生成值：
TAOCGQ I 1
TAOCGQ WY 2
TAOCGQ BHLPQGRN 3
TAOCGQ VUE 4
TAOCGQ Z 5
代码实现：
import pandas as pd
df = pd.read_excel(r'E:\代码\tables_results\价格表.xlsx')
pd_result = df.to_dict(orient='split')
'''舱位信息列表['航线', 'W', 'I', 'Y', 'B', 'H', 'L', 'P', 'Q', 'G', 'V', 'U', 'Z', 'R', 'N', 'E', 'K']'''
cabin_list = pd_result['columns']
'''航线信息及价格列表 [['LHW-ZUH', 2.0, 0.0, 2.0, 2.0, 2.0, 3.0, 3.0, 3.0, 3.0, 3.0, 3.0, 3.0, 2.0, 2.0, 2.0, 0] ]'''
data_lists = pd_result['data']
for data in data_lists:
for number in range(0,20):
''' 循环航线信息取出列表的索引id'''
idxs = [i for i, x in enumerate(data) if x == number]
if idxs: #索引列表
news_data_list = []
for idx in idxs: #循环索引列表
news_data_list.append(cabin_list[idx])
cabin_merge = ''.join(news_data_list) # 将多个舱位合并
aviation_rebate = idxs[0] # 取出返点价格，因为有多个索引，只取第一个就行
air_route = str(data[0]).split('-') #航线 LHW-ZUH
dpt = air_route[0] # 出发城市
arr = air_route[1] # 到达城市
result = dpt + arr + ',' + cabin_merge + ',' + str(int(data[aviation_rebate]))
'''
最终结果：
['LHWZUH', 'IK', '0']
['LHWZUH', 'WYBHRNE', '2']
['LHWZUH', 'LPQGVUZ', '3']
['ZUHLHW', 'IK', '0']
'''
print(result.split(','))
程序执行结果：
['TAOCGQ', 'I', '1'] ['TAOCGQ', 'WY', '2'] ['TAOCGQ', 'BHLPQGRN', '3'] ['TAOCGQ', 'VUE', '4'] ['TAOCGQ', 'Z', '5']