干货 | 携程Service Mesh可用性实践
作者简介
本文作者烧鱼、Shirley博，来自携程Cloud Container团队，目前主要从事Service Mesh在携程的落地，负责控制面的性能优化及可用性建设，以及推进各类基础设施服务的云原生化。
一、背景
近几年，国内各大公司大规模生产落地Kubernetes和Service Mesh，拉开了云原生革命的序幕。从2019年开始，团队开始在部分场景中落地Istio Gateway，积累Service Mesh经验；2020年中，我们开始与公司的框架部门合作着手Service Mesh在携程的落地，目前生产环境已有数百个应用接入，覆盖率还在持续的推进过程中。
Service Mesh作为一项新技术，相比传统的微服务框架有很多优势。但在生产环境落地的过程中，若无法保证可用性，出现大的故障，将会大大打击对新技术采用的信心，也会影响最终用户，造成对品牌的负面影响。显而易见，可用性是一切的基石。我们在落地Service Mesh的过程投入了大量的精力进行可用性的建设，避免出现单点故障，保证服务的高可用。Service Mesh在携程的落地并不是平地起高楼，公司内关于可用性已经有一套方法与模式，Service Mesh的可用性建设也必须考虑现有的高可用体系。
二、Service Mesh高可用
2.1 携程高可用架构简介
携程现有的高可用设计自上而下可以简化为：IDC级高可用、IDC内应用部署的高可用、IDC内基础设施的高可用。针对这三个层次的故障，分别有不同的设计，以下主要围绕IDC级及应用部署级可用性设计进行介绍。
2.1.1 IDC级灾备-同城双活
携程内部应用一般包含多个Group，Group是应用发布的最小单位，同时也是流量调度的单位。一个DR(容灾)组一般包含两个IDC，一个应用的多个Group会部署在DR组内的多个IDC，当某一个IDC出现故障时，迅速将流量切换到另一个IDC。其中核心应用多IDC部署，数据库跨IDC主备，流量调度层面也要支持跨IDC的管控。
2.1.2 IDC内高可用-应用多集群部署
随着容器化在携程内部大规模推进，绝大部分应用都跑在Kubernetes集群上。应用部署时，将同一个Group的实例，打散到多个Kubernetes集群上。然后，各个集群中的Operator与外部的注册中心交互，将本集群中的实例信息注册到对应的Group中。单个Kubernetes的控制面不可用，只会影响到当前集群实例的变更。
可见网站的高可用设计就是通过划分故障域，进行故障隔离，切断故障的传导，保证故障时能够切换或控制故障范围。数据中心之间故障隔离，保证数据中心级的高可用；数据中心内部Kubernetes集群之间故障隔离，进而保证Kubernetes之上的可用性。在Service Mesh的高可用设计上也要遵守这些故障隔离的原则。
2.2 Service Mesh高可用设计
思路上，我们先梳理故障场景，制定目标，然后设计方案，再结合故障场景进行可用性分析，上线之后再通过故障演练进行验证。
2.2.1 故障场景
1）Service Mesh数据面故障，可能会导致应用请求异常，从而影响服务质量，大规模的数据面故障可能会导致数据中心级别的故障。
2）Service Mesh控制面故障，无法给数据面下发最新的配置，数据面可以根据现在有配置提供服务。故障期间，实例IP的变化无法下发，路由信息也无法更新，部分服务可能会受影响。
3）目前Service Mesh控制面还是以Kubernetes为基础的，所以Kubernetes控制面的故障也会导致Service Mesh控制面的故障。
2.2.2 目标制定
1）数据中心级故障隔离。考虑极端的故障场景，数据面大规模故障，控制面长时间无法恢复等，设计上需要将故障控制在单个数据中心内部，防止故障传导到其他数据中心，从而保证有其他数据中心可以提供服务，可以进行数据中心切换。
2）支持应用多集群部署架构。从设计上考虑，Service Mesh的高可用不应该仅仅局限于现在的应用多集群部署的架构，而是与应用部署架构解耦，支持多种部署架构。
2.2.3 方案设计
多个数据中心之间隔离，每个数据中心有独立的控制面，将管理的资源收敛到每个数据中心内部。应用跨数据中心访问时需要走Gateway，通过ServiceEntry的方式导入其他集群的Gateway，由各个数据中心的Gateway收敛对外的服务入口，以数据中心为单位隔离故障。
在数据中心内部，控制面部署到独立的Kubernetes集群部署作为Primary Cluster，应用所在的Kubernetes集群作为Remote Cluster，Remote Cluster上的Sidecar共用同一个Service Mesh控制面。通过将Service Mesh控制面与应用部署的Kubernetes的集群拆分开的方式，可以灵活应对其他的应用多集群部署架构。
2.2.4 可用性分析
1）当某一个数据中心出现故障时，需要将流量切换到另一个数据中心，与现有架构保持一致。
2）当Service Mesh数据面出现故障时，应用可服务的实例数会减少。但是基于Envoy FailOver的能力，随着健康的实例数的减少，也会逐渐将流量转到其他数据中心的Gateway上，服务可用性不会有太大影响。
3）Primary Cluster出现故障时（包括Primary Kubernetes集群故障和Service Mesh控制面故障），无法通过控制面下发新的配置。如果此时该数据中心有服务异常不可用，数据面也会自动FailOver其他数据中心，短时间内没有太大影响。而数据面访问其他数据中心的服务时，因为其他数据中心的服务都是收敛到了Gateway上，所以并不感知具体的实例信息，即使其他数据中心服务实例信息变化，也不会因为配置无法下发，导致数据面的访问出现异常的问题。
4）在数据中心内部，Remote Cluster出现问题时，只会影响应用的HPA和发布，在Kubernetes的高可用层面解决，Service Mesh层面没有影响。
2.2.5 故障演练
1）确认是否按照设计预期的方式应对故障。将某一个数据中心内的服务，置成不可用状态，观察数据面是否按照预期执行了FailOver，以及数据面请求的成功率和延迟，是否在预期范围内。
2）分析演练的效果，挖掘是否存在隐藏的问题点。当某一个数据中心内，服务不可用时，数据面会FailOver到其他数据中心的Gateway上，此时需要重点检查是否存在环路，防止请求在多个数据中心的Gateway上循环。
三、Service Mesh自身的可用性提升
宏观层面的高可用的架构，通常是作为应对服务故障的兜底措施，可以应对不同级别的灾难,故障，但是数据中心级别的切换影响面较大，不能作为常规武器，服务自身也要加强可用性建设。Service Mesh可用性建设还要围绕使用场景，深度完善可观察性指标，从而迭代优化提升可用性。
3.1 场景/目标
1）控制面运行时，需要支撑大量客户端的数据面连接，同时需要快速的将配置推送到数据面。
2）故障恢复，由于Node故障或者服务自身异常，控制面需要快速启动提供服务。
3）发布场景，控制面和数据面的新版本发布，需要快速灰度和快速回滚的能力。
3.2 确定xDS推送指标
梳理配置下发的流程，apply到Kubernetes，到控制面处理该事件，并触发xDS的推送，最后数据面ack回来。主要是控制面内部的流程比较复杂，社区的版本中针对内部的各个阶段都有一些指标衡量，但是缺少一个描述整个下发流程耗时的指标。针对这个问题，内部已有相应的计划，初步验证了可行性。
以控制面接收到Event的时间做为起始时间，中间多个事件合并时取最小值，数据面的ack为结束时间。最终就可以得到控制面推送的耗时分布，从而进行针对性优化。
3.3 xDS推送的可靠性保证
举例说明，在应用的滚动发布过程中实例的IP都发生了变化，老的实例已经被删除，但最新的实例信息可能没有及时推送到数据面，可能导致数据面出现访问异常。根本问题在于实例删除的动作和配置下发是异步的，无法保证在实例删除之前，所有的数据面已经获取到了该实例的下线信息将流量摘除。在大规模动态扩缩，或者临界场景时，这种异步和非确定性的方式极易导致大面积的服务不可用。
因此我们需要一个保证实例变更流程可靠的机制。
1）在我们内部使用方式上，Pod会有一个对应的WorkloadEntry，然后通过ServiceEntry注册成为服务。内部kubelet扩展了finalizer机制，使得finalizer不权阻塞对象的删除，还会阻塞kubelet对Pod的Kill操作。Pod创建时，会被对应的Operator打上finalizer，所以删除Pod时，Pod会因为Finalizer的存在而继续存活，此时还可以提供服务。
2）由内部的Operator感知Pod变化，更新WorkloadEntry的label，使之被更新为不可用状态，不会被任何ServiceEntry选中。此时WorkloadEntry的generation会+1为X。
3）然后控制面watch到这个事件，会更新内部的ledger写入WorkloadEntry的NamespacedName以及generation，并将此时RootHash作为xDS的Nonce推送给数据面，当数据面ack时，控制面会记录该数据面最新的ack的Nonce。此时可以根据Nonce以及NamespacedName去ledger中查询已经推送下去的资源的generation。
4）再由Operator调用我们的聚合服务，去查询所有的控制面中数据面的WorkloadEntry的generation，与X对比，如果都大于等于X，则认为这个WorkloadEntry都下发成功了。如果是推送未完成，Operator也会进行重试，等待推送成功。
5）确认推送成功之后，Operator会去删掉WorkloadEntry，去除Pod finalizer，真正的删除Pod。
3.4 ServiceEntry/WorkloadEntry事件处理耗时优化
实践上，我们通过ServiceEntry和WorkloadEntry将部署到虚拟机和物理机上的服务导入到Mesh中，但是发现一个namespace下5千ServiceEntry和1万WorkloadEntry的场景下，事件处理的耗时都在分钟级，多个应用发布时，延迟可能会到小时级别，根本无法满足上线的需求。
深入研究发现istio 1.7，当一个ServiceEntry/WorkloadEntry发生变化时，会触发maybeRefreshIndexes这个方法，方法中会进行遍历所有的ServiceEntry和WorkloadEntry进行匹配，重新生成内存的Map，因此会执行5000*10000=5千万次workloadLabels.IsSupersetOf()。
func (s *ServiceEntryStore) maybeRefreshIndexes() {...wles, err := s.store.List(gvk.WorkloadEntry, model.NamespaceAll)// 10000for _, wcfg := range wles {...entries := seWithSelectorByNamespace[wcfg.Namespace]for _, se := range entries { // 5000workloadLabels := labels.Collection{wle.Labels}if !workloadLabels.IsSupersetOf(se.entry.WorkloadSelector.Labels) { // 5000 * 10000continue}}}}
解决问题的思路肯定是全量变增量，当WorkloadEntry发生变化时，只要遍历所在namespace的ServiceEntry，那么循环的次数就下降到了原来的万分之一，事件处理耗时也得到极大优化，下降到毫秒级。
具体实现上，处理事件的过程中需要更新多个Map，为了保证数据的准确性，还是沿用了原有的全局锁。所以目前也只是完成从全量到增量的优化，但是事件还是串行处理方式，在大规模变更的场景下延迟会被逐步放大，最后的变更推送下去需要很长的时间。目前也在尝试拓展一个新的CRD，实现上使用Sync.Map分段式锁，替换原有的全局锁，通过并发处理的方式来提升事件处理的效率。
熟悉Kubernetes和istio的同学也会发现，istio在处理event时是并没有用Kubernetes Controller Runtime的方式编程，以WorkloadEntry和ServiceEntry为例，当WorkLoadEntry变化时，应该去查找关联的ServiceEntry，然后触发ServiceEntry的Reconcile。目前内部也在尝试通过引入Controller Runtime来处理ServiceEntry，并且调大MaxConcurrentReconciles，让控制面支持并发的处理事件，进一步提升推送的时效。
3.5 控制面冷启动
在我们实践过程中也发现控制面ready之后，没有及时给连接上来的数据面推送最新的配置，导致数据面无法获取到最新的实例信息，从而影响了请求的转发。
深入分析发现，控制面ready时只等待Kubernetes的informer完成sync，但此时还有很多事件阻塞在内部队列中，导致控制面在ready之后的一段时间内，无法处理最新的事件，影响数据面下发最新的配置。在集群规模较大或者是istio资源较多的时候，尤为明显。对此我们增强了控制面启动流程，阻塞控制面ready，等待内部的队列被清空，从而保证可以尽快处理后续的事件。虽然增加了控制面的启动耗时，但相比于服务的可靠性的提升，这个代价还是值得的。
我们也在1.10中引入了DiscoveryNamespacesFilter，在控制面上忽略一些不需要关心的namespace，加快事件的处理。控制面冷启动的过程中，也发现使用DiscoveryNamespacesFilter存在潜在的风险，也向istio社区提交了PR https://github.com/istio/istio/pull/36628，目前已经合入。
func (c *Controller) SyncAll() error {c.beginSync.Store(true)var err *multierror.Error+ err = multierror.Append(err, c.syncDiscoveryNamespaces())err = multierror.Append(err, c.syncSystemNamespace())err = multierror.Append(err, c.syncNodes())err = multierror.Append(err, c.syncServices())return err}+func (c *Controller) syncDiscoveryNamespaces() error {+ var err error+ if c.nsLister != nil {+ err = c.opts.DiscoveryNamespacesFilter.SyncNamespaces()+ }+ return err+}
3.6 灰度发布
内部在不停的优化控制面和数据面，所以也需要经常发布。随着应用接入的规模变大，更多的核心的应用接入的，传统的滚动更新也无法满足需求，更细力度的灰度发布也变得尤为重要。虽然每次发布都会经过内部多个环境的验证，最终才上线生产，但是也存在不可控的因素，变更就会带来风险，所以需要做到可灰度可快速回滚。
Canary发布
1）在同一个集群中部署一组Canary的控制面。
2）然后调整Sidecar注入策略，将部分Sidecar接入Canary的控制面。
3）通过自动化的方式进行验证，需要提前梳理测试的场景。
Canary之后会再灰度发布
4）创建一组控制面实例，逐步扩容，逐步接入流量，开始观察。
5）此时回滚就是直接缩容新实例，数据面会快速重新连接到老版本控制面上，从而快速回滚。
6）观察稳定之后，逐步缩容老的服务。
四、未来展望
Service Mesh在流量管控领域具有重大的意义，不仅可拓展性强，还可以统一流量管理模型，统一多语言的异构系统。
未来我们还会持续投入，围绕可观察性，进一步提升服务可靠性，优化xDS的推送性能，支持内部大规模落地。同时增加与社区的沟通，期待与大家共同成长。
团队招聘信息
【推荐阅读】
“携程技术”公众号
分享，交流，成长