eBay 采用多活数据中心的网络拓扑，因此任何生产应用都需要完成跨三个数据中心的部署。

为满足单集群的高可用，针对每个数据中心，任何应用都需进行多副本部署，并配置负载均衡。

以实现全站微服务化，但为保证高可用，服务之间的调用仍以南北流量为主。

针对核心应用，除集群本地负载均衡配置以外，还需配置跨数据中心负载均衡，并通过权重控制将 99% 的请求转入本地数据中心，将 1% 的流量转向跨地域的数据中心。该配置的主要目的是当某应用的所有本地服务实例失效时，运维可快速将跨数据中心负载均衡器上指向本地的 99% 流量的成员禁止掉，流量可在秒级转向其他数据中心从而保护业务不受影响。业务版本发布、硬件故障、防火墙、路由器等网络设备变更都有可能导致本地服务实例失效。

虚拟 IP 地址分配，当用户创建 Service 对象以后，Service Controller 需要从预先配置的公网 IP 中选择一个可用的虚拟 IP 地址分配给该服务。

配置 IPVS 接口，完成负载均衡规则的配置。

路由宣告，虚拟 IP 地址与物理设备的 IP 不一样，它没有绑定在任何物理设备上，但基于 BGP 协议和 ECMP，它能让多个设备配置同一个 IP 地址的路由信息。当 Service Controller 为 Service 分配虚拟 IP 地址并配置好 IPVS 规则以后，Controller 还需要将该虚拟 IP 地址从配置好的节点中宣告出去。基于 BGP 协议，数据中心中的其他路由器即可获知如何将虚拟 IP 地址转发至该网关节点。有了 ECMP 的支持，多个四层负载均衡组件行为一致，也就是他们配置一样的规则，宣告一样的 IP，每个实例都会承载该虚拟 IP 地址的流量。相比主备模式的硬件负载均衡器，此方案的所有负载均衡节点都是 Active 模式，没有 Standby 设备的额外硬件开销。

N 元组哈希，基于源 IP，源端口，目标 IP，目标端口，以及协议的 N 元组哈希，保证针对同一个连接，总是选择同一个上游实例。路由器的 ECMP 哈希算法与设备相关，同样的 N 元组有可能会被转发至多个目标，在本场景中是四层负载均衡。只要在 IPVS 主机上按照 N 元组重新做哈希，那么无论请求被转发至哪个 IPVS 实例，都会被转发至相同的上游服务器。所有实例计算的的哈希结果都一致，这样多个 IPVS 实例之间不用同步状态。当一个节点出现故障时，其他节点可将请求转发至同一个上游。

一致性哈希，基于 N 元组的哈希算法，会尽量将请求平分到多个上游服务器，在 Kubernetes 世界里，上游服务器以 Pod 的形式存在，扩缩容，Failover 是常见场景。在普通哈希算法中，目标的变动意味着大量的 rehash，采用一致性哈希算法后，只需要将变动的部分重新哈希即可，减少了大量哈希计算的 CPU 开销。

Connection Tracking，Connection Tracking 表用来记录最近连接的后端选择结果，当 IPVS 模块处理数据进行负载均衡操作时，首先查询该连接表，如果发现对应的 N 元组已经有了对应的目标实例且该实例依然健康，那么直接复用此结果。如果不存在或者对应的实例状态不正常则需要基于一致性哈希重新计算，计算结果会被保存在该连接表中供后面的请求数据复用。

数据包封包，选择好对应的上游服务器以后，IPVS 模块开始处理数据包。按照第五章的内容，内核协议栈在处理数据包是，可以基于 NAT 或者 Tunnel 两种模式，NAT 的问题是用户原始 IP 会丢失，这里选取更优的 Tunnel 模式，IPVS 模块会保持原始数据包不变，在原始数据包外面封装一层 IP 包头，数据包的内层包头源是客户端 IP，目标是服务虚拟 IP 地址，外层包头源是 IPVS PodIP，目标是上游服务器 PodIP，然后基于 IP over IP 协议发送数据给上游。

健康检查，健康检查是负载均衡的基本功能，在我们打造的软件负载均衡中也需要。Seasaw 库有 API 支持多种健康检查模式，只需在控制器中调用接口对所有上游目标做健康检查，如果某个上游服务器检查失败，需要将 IPVS 中对应的转发规则删除掉。

针对数十个可用区，上百个 Kubernetes 集群，让用户面向每个集群做配置不现实。这样做的结果是管理混乱，客户需要关心太多基础架构细节，计算资源调控难度大，配置不统一，变更造成的故障可能性高。

Istio 对象无状态属性，很难直观获取配置是否正确、是否已推送完成等信息。

多路径软件接入网关的健康检查机制。

PlacementPolicy 控制，用户可以选择目标集群来完成流量配置，甚至可以选择关联的 FederatedDeployment 对象，使得 AccessPoint 自动发现目标集群并完成配置。

完成了状态上报，包括网关虚拟 IP 地址，网关 FQDN，证书安装状态以及版本信息，路由策略是否配置完成等。这补齐了 Istio 自身的短板，使得任何部署在 Istio 的应用的网络配置状态一目了然。

发布策略控制，针对多集群的配置，可实现单集群的灰度发布，并且能够自动暂停发布，管理员验证单个集群的变更正确以后，再继续发布。通过此机制，避免因为全局流量变更产生的故障。

不同域名的 AccessPoint 可拥有不同的四层网关虚拟 IP 地址，以实现基于 IP 地址的四层网络隔离。

基于跨地域的流量管控，Istio 实现了基于 workload locality 的故障转移策略和权重策略管理，基于这些策略可实现跨地域的高可用流量管理。

可移植性，不仅支持 Kubernetes，也支持虚拟平台 Openstack 以及 Consul。

跨语种的服务网格平台，统一 Java，Scala，Nodejs 等诸多语言。

Istio 将南北和东西流量统一管理，统一服务网格和 API 网关用户体验，降低运营成本。

天然安全，自动化证书管理，认证授权的集成。

充分的功能支持，能看到的 API 网关的所有功能都有支持。

背后有强大的社区支持，谷歌将 Istio 作为下一代微服务治理平台，IBM，微软，华为，阿里等云计算巨头都积极参与 Istio 项目的推进和生产化。

规模和效率。Kubernetes 支持的集群规模越来越大，几千个计算节点，数十万 Pod，数千上万 Service 的生产集群越来越常见。Istio 在支持大规模集群场景还有很多挑战，代码需要做诸多优化。Istio 的多集群部署甚至还会让量级翻数倍，如何支持超大规模集群，是 Istio 面临的最大挑战之一。

复杂性，无论从控制平面复杂性还是模型抽象看，Istio 都是一个复杂系统，更多的功能模块意味着运维的复杂度更高。

与企业已存服务的整合，Istio 生产化需要与企业现有服务的整合，比如与企业 CA 的整合，与企业 Tracing 系统的整合，与企业监控平台的整合等等。

存量业务的迁移，很多企业已经有基于 Spring Cloud 等开源框架的微服务系统，此系统已经支持了诸多熔断限流，API 网关等功能，与 Istio 提供的功能重复。是否要将这些存量业务迁移到 Istio，如何迁移都是巨大挑战。