运维体系 实时计算平台 从架构到组件，深挖istio如何连接、管理和保护微服务2.0？(6)

A1：先回答第一个问题，我们可以看到不管是数据面板还是控制面板都会有很多个，但是控制面板，谷歌和IBM，刚才所说的是由三个公司来开发的，谷歌、IBM，还有Lyft，那个公司类似于滴滴那种业务的公司，它们负责Envoy的开发，数据面板是它们公司来负责。我们可以看出来它们是有点分离的感觉，对于谷歌或者IBM来说它们更关注的是控制面板，并且在控制面板和数据面板之间的接口设计的非常好，设计了一套通用的接口。它们最终是分为两个方向发展，但是都可以通过同一套标准集成起来。

第二个问题，首先公司内部都在采用微服务，对于Istio至少要到1.0之后才会在内部环境使用，如果没问题才会逐渐往真正的对外业务使用它，包含通讯里面都可能会用它。但是对于CT领域来说的话，用这个可能代价就需要好好地评估一下了。因为性能上的问题，它毕竟还是多了一跳。如果两个服务之间的交互就相当于多了两跳，对于通信这种实时性要求非常高的领域可能会存在问题。我们也会开发自己的一套侵入式框架，可以参考Envoy的实现。

Q2：我们现在游戏项目里面刚好也用到它。但是它有个问题，用的感觉有点大材小用，我们用它做调用链关系分析，因为我们集群开发很多游戏，每个游戏有个pilot，但是如果出了问题我不知道，那它里面的一个插片自动生成，它只能识别K8集群里面pod。如果我们想用它把K8S的集群和非K8S的集群调用，并且全部进行连接起来的话，它是否支持？

A2：我觉得它现在由于所处在初级阶段所以暂时不支持是正常的，但它后续的发展肯定会支持，因为它们整个设计的目标就是为了达到这种服务粒度，而不仅限于K8S pod这种管理粒度。

Q3：我有一个关于sidecar的问题，如果作为一个客户端去请求的时候应该要引流引到sidecar上面，它引流是怎么引的？如果直接转过去的话又怎么去识别目标的服务到底是什么样的？它调用的是什么服务，后端可以路由到几个上？

A3：这个信息都是由刚才所说的pilot来负责收集，它会把这些信息下发到Envoy上，所以它在做路由算法的时候会访问，来获取它可以访问到哪些服务，它会把服务的信息找到，包括它能访问的服务池包含哪些内容，然后再通过策略进行控制。

它是会反向再去K8S里面找到的，并不是完全Envoy自己来负责，这些信息都是由pilot来给它，拿到这些信息再做处理，最终还是会和平台结合到一起。它有一个假设，所有的平台都会实现这种服务发现的接口，并且会从服务发现的接口拿到一些必要的信息，包含你刚才说的，会转成相应的IP。

从架构到组件，深挖istio如何连接、管理和保护微服务2.0？

标签：开放平台服务治理调用链

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/jisuanjixue/article-66285-6.html