根据Flexera 云状态报告在2021年有92%的企业采用多云战略，45%的企业使用了多云，到2024年报告表明有89%的企业使用了多云，使用多云是趋势。趣丸在21年开始引入多云，到现在经历了2年多的时间。引入多云的好处我这里总结了四点（成本、资源、稳定性、发展）：

从业务方面出发，现在都业务出海或业务全球化，多云可以让我们灵活地选择部署区域，不受限于某个云厂商的服务能力，部署不会受限于某个区域。

首先对趣丸多云架构现状做一下介绍：在线业务部署在两个云，业务流量通过智能DNS调度到两个云，业务层使用 istio 进行流量管理和故障转移，部分业务改造完成实现数据层跨云容灾。

多云带来优势的同时也必然带来一些挑战，这里我总结了四点：

这里我只针对前面3点给出一些实践经验，对于数据层的跨云容灾我们也在探索。

前面部分简单介绍了架构现状，第二部分通过3个章节介绍解决多云架构三类问题的实践经验。

多云架构的基础：多云互联互通骨干网络构建。多云架构对跨云网络联通稳定性要求非常高，从图上来看整个解决方案和传统IDC的网络互联架构没有区别。但是这套架构在云构建时会非常复杂。这里总结了3点：

这里建议与云商共建，充分利用云商的特点构建骨干网络。这套网络架构，满足趣丸网络架构原则- 全球一张网，也保障了多云互联网络联通的稳定性。由于受限于云商的产品能力，目前针对流量的 QOS 当前尚不完善。

另外需要考虑的一个点是 VPN 的带宽，当有多条专线时（SLA 无限接近于100%） VPN 作为逃生通道无需承载全部流量（也很难做到），只需要考虑专线全部中断时，作为管理流量的逃生通道。

说到云原生一般都会想到云原生15 要素 和 云原生的特点：微服务、容器化、不可变基础设施、服务网格、声明式API等。趣丸通过这些原则和实践，从18年开始对业务进行了大量的改造，比如通信协议、服务发现等等，实现了应用的快速迭代、灵活部署和高可用性，推动了业务的持续创新和稳定发展。

下面我主要在流量调度层面介绍一些落地实践。

1）部署方案和东西流量管理

Kubernetes 集群部署相互独立，业务通过一套CICD进行多集群部署，没有采用多集群管理的方式。

我们出于以下3点考虑：

通过 Istio 的多集群流量调度实现业务东西流量调度。istio 集群的部署模型我们采用的是单一网格的多主架构模式，这个模式业界采用较多的方案。主要有两个好处：

多主架构模式的特点是：多个集群一个网格，每个控制面的 istiod 都能发现其他所有集群的 svc 和 endpoint，并通过 xDS 下发给本集群的 istio-proxy，实现工作负载可以直接互相访问（跨k8s集群workload的互相访问）。这个架构有一个前提条件是所有云商的网络是打平的。

这个架构也存在三个问题：

2）多云流量调度

针对目前架构存在的问题2和问题3这里给出一些解决方案。

防止非必要的跨云流量，需要制定一个流量管理策略：本地优先，在本云内闭环，本地失效时流量调度到其他区域。

通过istio 的负载均衡规则的 failoverPriority（故障转移策略）来实现需要的流量管理策略：

loadBalancer:      localityLbSetting:        enabled: true        failoverPriority:        - topology.istio.io/network        - topology.kubernetes.io/region        - topology.kubernetes.io/zone

这个策略可以保障：

需要注意的是让pod均衡的分布到多个可用区（建议使用k8s 的Pod 拓扑分布约束：topologySpreadConstraints ）。

解决了zone和region级别的容灾能力，经常遇到一个应用的部分pod也出现问题。例如：

通过 istio 的离群检测（故障转移）outlierDetection 能力来缓解或解决上述问题。

3）金丝雀发布和访问控制

业务常见的发布方式是金丝雀，通过精确的流量分割和控制，逐步将用户流量从旧版本转移到新版本，可以很好的控制更新过程中可能出现的故障影响范围。通过精确的流量分割和控制，逐步将用户流量从旧版本转移到新版本，可以很好的控制更新过程中可能出现的故障影响范围。

金丝雀发布与多云关系不大，这里拿出来讲的原因是 istio 提供的金丝雀能力非常强大，可以非常方便的的解决全链路金丝雀流量调度的问题。istio流量染色可以根据业务标记（最常见的是 http 头）将流量调度到集群金丝雀版本中，并且可以精确的控制流量百分比。

通过 mesh 打通，可以方便的跨集群访问，在带来方便的同时也存在未授权访问的安全风险。Istio本身提供了非常好的无入侵的安全防护能力，主要体现在2个方面：

基于授权策略的安全防护能力提供了非常丰富的访问控制能力，可以基于SA，请求接口（path），namespace 等属性进行访问控制。实现应用级别的安全访问边界（零信任）。

遥测是云原生的一个新要素，是质量保障的关键环节，趣丸通过集成不同云平台的监控工具和日志系统，实现统一的数据收集和分析，在上层屏蔽云商差异从而优化运维效率和提升决策质量。

1）基于Prometheus的多云异构可观测方案

可观察包含三个方面：监控、日志、追踪链。并且可观测的数据有个特点，写入量大，实际使用少。大部分情况是业务出现问题时才使用，尤其是日志数据。所以大量的写流量都走专线不合适。整体方案是就近存储，本地计算，跨专线聚合查询。监控指标数据我们是通过 Prometheus 自建的，实现就近存储，跨专选聚合查询。日志和追踪链使用的云产品，无法做到就近存储，所以对专线带宽有很高的依赖。

解决多云产品异构的问题，思路也很简单，就是开发一套 exporter ，每种产品通过统一的标签存储到  Prometheus 中，屏蔽底层差异，作为可观测平台的数据基础。这样做也带来了问题，云产品是非常多的，不同云之间的差异也非常大，导致新云接入时可观测能力的支持需要投入大量的人力。

我在想CNCF可以制定一个标准来约束云商对于产品指标暴露的一个规范，降低企业使用多云的投入。

2）以应用为中心的观测能力

有了数据的支持，结合以应用为中心的理念，将应用与人、资源、告警、指标、调用链、日志进行关联，构建一个以应用为中心的的可观测平台。将质量相关的数据信息汇总到一起，排查问题时就不需要登陆到各个平台去收集信息，形成一站式的可观测平台。

我们的可观测平台实现了宏观层面-业务场景层面和微观层面-具体服务/接口 两个层面的质量展示，可以更直观的发现问题。

多云架构还有很多挑战，针对业务的需求，再结合云原生技术的发展方向我总结了4点：