迈向多云时代：TT 多云架构演进与实践

随着云计算产业的发展，云计算概念的普及和人们对云计算技术认知的加深，企业开始对云计算服务有了更多的要求，上云也就成为现在很多企业的刚需，致使越来越多的企业开始架构转型。对于企业来说，业务呈现多元化、多地域、全球化的发展趋势，多云管理能很好地利用单个云的优势、某个云特有的云服务，也能很好地避免服务商锁定，企业还能根据业务、技术及性能等需求动态调整多云部署的策略，因而多云就成为了很多企业的首选解决方案。

但是企业在实现多云架构的过程中依然面临很多挑战：如何解决多云厂商带来的管理复杂性问题；如何实现多云互联互通的网络方案；企业应用部署策略与多云容灾；多云可观测与安全问题等。

本文整理自趣丸科技（TT 语音）资深架构师黄金在QCon广州大会演讲分享，主题为“迈向多云时代——TT 多云架构演进与实践”。

本次分享主要分为四个部分展开：第一部分介绍 TT 上云的发展历程，第二部分讲多云的优势与挑战，第三部分分享 TT 多云解决方案，第四部分是未来展望。

以下是分享实录。

TT 上云的发展历程

TT 的云端架构的发展粗略分为三个阶段，第一阶段，我们叫单云时代。第二阶段多云 1.0。第三阶段多云 2.0，但是这三个阶段不是相互割裂的，会有一定叠加。举个简单的例子，到目前为止我们还有一些服务处在单云时代，但同时还有很多服务已经处在多云 2.0 阶段，每个阶段都有它自己的一些特点。

单云时代的架构

单云时代是企业发展的初期，主要追求的是能够快速部署，快速实现，方便管理。它的特点也比较明显，所有的基础设施都在一个云里边，然而缺陷也比较明显，业务的稳定性很容易受到单个云服务商的稳定性影响。我们至少经历过 4 次由于云服务商升级底层网络，或者底层基础设施人为操作故障，导致整个业务的大规模受损。随着业务的发展，我们开始对云服务商的产品特性、功能以及成本有了更多的要求，引入了其他云服务商，就发展到了多云 1.0 时代。

迈向多云时代

多云 1.0 时代相比单云时代也有一些特点。它在业务层上实现了一个多云容灾。我们把业务拆分后部署在多个云上，这样单个云的故障对业务层的影响就会减弱，但这时候状态层没有做分离。做过多云、多活的都知道，状态层的分离是比较复杂的，也会给后期的维护带来困难，所以我们当时并没有在状态层去做分离。流量入口是通过固定比例去调配的，一般方式就通过 DNS 轮训，或者是按云服务接入商的固定比例分配。这样业务层上的失败只会影响固定比例的流量，但是状态层失败，依然会导致全部失败。随着企业不断发展壮大，我们对区域、容灾、稳定性有了更强的需求，就在多云 1.0 的基础上对业务架构进行了改造，从而产生了多云 2.0。

相比多云 1.0，多云 2.0 的主要的特点是在入口上做了智能调度。流量不再按照之前的方式，通过固定比例分发到某一个云。现在是通过智能调度去做健康检查，动态地剔除故障节点，保证流量始终到达健康的节点上。同时我们在状态层也做了分离，对一些稳定性要求比较高的业务来说，状态层不分离始终是个故障点。我们通过现在比较流行的云原生数据库对状态层做了分离，比如TiDB、OceanBase等为状态层分离带来了极大的简化，这些数据库支持跨机房的数据同步，实现起来很方便。

多云的优势与挑战

多云架构的优势

多云的优势总结为四个方面，稳定性，成本，创新和发展。从稳定性上说，多云能够很好地分散风险。我们能够做到多云、多活，单个云故障基本不会影响到业务。从成本上说，每个云厂商都有自己的一套定价模型，他们的产品可能相同，但价格不一样。多云可以让我们避免被云厂商锁定，可以在成本上有更加灵活的选择。一般情况下，性能一致肯定选成本最低的。成本一样肯定会选择性能最好的。从创新上说，每个云厂商都有自己的一些特色功能，或者是一些创新特性，多云可以让我们在多个云厂商之间取长补短，将这些创新点、特性应用在自己的产品上，提升产品在市场上竞争力，实现优势叠加。最后从发展上看，现在应用出海全球化已经形成趋势，大家都在做全球化，多云可以让我们灵活地选择部署区域，不受限于某个云厂商的服务能力，部署不会受限于某个区域，从而为全球化提供了助力。

多云环境以及异构的基础设施带来的挑战

1. 跨云互联互通。首当其冲的跨云问题就是的互联互通。在单个云的时候，联通性问题一般云厂商会帮我们去解决，而一旦跨云后就需要我们协调各供应商，共同去解决联通性问题。

2.跨云应用管理问题与流量控制。第二个问题是跨云应用管理与流量控制问题，我们有多个云了，应用在多个云之间怎么去部署，流量在多个云之间怎么去做调度？

3.异构基础设施带来的监控、管理问题。每个云厂商的产品都不尽相同，即使是相同的产品线，默认参数、配置也不尽相同，这都提高了后期问题排查的复杂度。

举一个比较简单的例子，我们Kubernetes集群用得比较多。有一次我想统一公司内部所有的 Kubernetes 版本，把它统一到某个具体的版本上，但我发现根本就做不到。因为国内的云厂商有的是单版本发布的，比如 1.19，1.21 发版；有的是双版本发布的，比如 1.20，1.22 发版，这就导致永远没办法去做统一。

4.多身份识别问题。每个云厂商都有自己的一套账号体系，账号体系完全没有相同性可言，而且有些产品没办法通过自己的平台管理，只能登到云厂商的平台上去管理。这时候就带来一个问题，有时候我们为了排查一个问题需要登录三个云厂商的平台，执行三种完全不同的操作，才能找到问题所在。

举个例子，我们 LB 用得比较多，很多云厂商 LB 的日志是不能被用户采集的，但业务又要我们排查问题，这就只能是登陆每个云厂商平台，去看他们 LB 的日志，排查出问题，业务也觉得这个地方很烦琐。同时，管理三个云厂商账号，在人员离职、入职时也非常麻烦。还有像安全问题，我这里就不一一列举了，毕竟今天主题是多云，不是多云劝退指南。

多云有优势也有挑战，我们应不应该选择多云？还是应该只用单云？单云的话如何解决容灾问题……归根到底还是那句话，“没有银弹。”在追求极端可用性的路上一定会带来极端的复杂度，企业要根据自己的实际发展阶段，选择适合自己的模式，不要一概而论。

TT 多云解决方案

面对上述这些挑战，结合自己的思考，我们给出了一些解决方案。主要分为三个小节，第一个是多云互联互通的问题，第二个是应用管理流量控制，第三个是在跨云可观测性上的一些实践。

多云互联互通的基础网络方案

应对多云互联互通问题，这里分享两个方案。第一个是基于多云骨干网络建设的方案。第二个是南北向流量和高可用方案。

基于多云的骨干网络建设

骨干网络建设，传统的基于静态路由表的方式有什么问题呢？假设有三朵云 ABC，每一朵云都有一个网段，为了实现这三朵云的互联互通，一般来说需要在每个云的接入点上配置每个网段的下一跳，通过静态路由表方式配置。假设 A 到 B 之间的物理专线断开了，那么 A 到 B 还能不能通呢？从图上看是可以通的，可以从 A 绕到 C 再到 B。但实际上是不通，因为静态路由已经配置好了，178 的下一跳就是 B。怎么才能让它再连通起来呢？只能去改路由表，把 B 的下一跳改为 C，从 C 绕到 B。这种需要人为操作才能恢复的故障，极大增加了故障发生时的恢复时间。

我们的解决方案是，把整套骨干网络基于动态路由表的方式实现。它的特点就是动态发布，动态学习。我们在每个区域上都做了一个自制体，就是 AS，每个 AS 都有一个不同的 AS 号，每个 AS 都有一个BGP Speaker，接入到骨干网络的 BGP 平面，每个 BGP Speaker 负责自治体内的所有 VPC 网段发布到平面上，其他的 BGP Speaker 就可以动态学习到这个 VPC 的路由。

这样做得好处是，虽然路由表和刚才一样，但是它的性质已经完全变了，它是动态的，不需要手动配置了。静态路由表的特点就是，静态配置的路由的优先级最高，断开之后它没办法学习到新的路由。而现在动态路由就可以了，通过BFD去做检查，可以在 10 秒内发现专线断开，然后就可以更新路由表，学习到新的路由。我们用的是 EBGP，他特点是每一个 BGP Speaker 都会将自己学习到的所有路由广播出去。当 B 断开的时候，A 就能从 C 学习到 B 的路由，通过多边专线绕行，从而保障业务的高可靠。这个方案除了能够实现多边专线绕行，还方便我们管理。

举个例子，在多云的情况下，经常会出现一种调整策略，比如说在一个云部署得多，在另一个云部署得少。比如在 A 云增加了一个网段，之前的方式就需要在每个接入点手工配置，而现在只需要加进去，让 BGP 去管理新的网段，最后把路由发布到 BGP 平面上，其他的 BGP Speaker 就可以学习到这个路由，从而实现了互通。整个的 VPC 的初始化可以缩短到几分钟以内。

接下来看一下实际骨干网络建设，看起来比刚才的那张图要稍微复杂一点。因为有了动态路由，我们主要围绕两个方面去做。第一个就是全球一张网的目标，能够实现多云能力的公用，让我们灵活选择部署区域。

第二个就是我们做了多级链路冗余，动态路由能实现多级备份。我们在整个骨干网络平面上又做了一套 VPN 的数据面，如果整个物理专线全部断开，重要的流量依然可以走 VPN 链路，保证重要的业务不会中断。有人可能问，已经做了三角专线了，而且可以实现动态绕行，为什么还需要做 VPN 数据面呢？这是个惨痛的教训。国内某云厂商在配置我们的 BGP 平面的时候做了一个操作，输入了一个 S。这个 S 命令相当于 shutdown，导致整个网段全部中断。虽然 BGP 可以简化配置，但 BGP 配置却成为了瓶颈，一旦有人配置错将引发很大的灾难，而且恢复时间比较久。所以我们就在物理专线上又做了个 VPN 数据面，通过这种明细路由加聚合路由的方式，对路由做优先级，优先走专线路由，当专线路由消失的时候，就走 VPN 路由。在物理专线全断的情况下，保障重要流量依然能够走 VPN 的专线。

南北流量高可用方案

我们做了多云、多入口，也做了多活，那么用户的流量怎么到达服务呢？这就是南北向流量高可用的问题了。怎么找到入口？常见的方式比较简单，就是 DNS。DNS 的目前的做法有三种，主备域名、HTTP  DNS，以及智能 DNS，智能 DNS 现在比较流行。我们基于自己的业务情况选择了后面两种。考虑的主要是两方面，一方面是灵活度高，HTTP  DNS 它可以绕过 Local  DNS，对于那些要求很高的，比如说账户系统就要接入 HTTP  DNS。其他的业务接入智能 DNS。相比 HTTP  DNS，智能 DNS 的好处是，它的改造对业务是无感知的，可以在业务完全不需要任何改造的情况下，接入智能 DNS，实现故障节点剔除以及主备切换。

接下来看一下具体情况。刚开始 DNS 的整个入口是通过智能 DNS 解决互联网层、接入层多活以及主备切换的问题。智能 DNS 它可以做多种形式的健康检查，比如说 7 层的、4 层的，通过健康检查，我们可以实现故障节点的自动剔除。除了这个方案，我们还有一套方案就是 HTTP  DNS，对于一些可用性要求高的，或者是一些重要的业务，都会要求他接入 HTTP  DNS。HTTP  DNS 也是业界比较成熟的方案，SDK 也比较多，安卓跟 iOS 都有相应的 SDK，接入 SDK 就可以实现绕过运营商的 Local  DNS，防止域名劫持和封堵问题。

业务通过 DNS 之后是直接到达服务吗？肯定不是，因为还会有攻击的风险，所以下面还需要有一套高防。说到高防，我们采用本地原生高防加异地大流量高防的一套组合方案，我们叫高防的阶梯调度实现的，为什么需要这样去做？因为本地高防的特点是，它的流量比较小，比较便宜，云厂商都自带了，但它可能只能扛 10~20G 的流量，而异地大流量高防的流量一般比较大，一般都是 TB 级别的，但本地高防是走内网到达服务的，没有公网带宽的消耗，同时它时延也比较低。我们是的做法是优先本地高防，低延时和低成本。在受到攻击时，通过智能 DNS 的调度能力把流量调度到异地高防，通过异地高防清洗后再到达业务，实现业务的高可靠性。

 我们具体来看这套高防的调度方案。流量有两条路径，默认是正常的用户访问和日常的小流量攻击，智能 DNS 都会把它调度到默认的原生高防上，原生高防负责防护，最终流量会到达业务服务。当遭受海量攻击时，智能 DNS 检测到这个本地原生高防 IP 被封堵后，就会通过改 CName 的方式，将攻击流量引向异地的大容量高防，通过大流量高防进行清洗，最终业务流量到达服务的时候是没有什么风险的，可以保证遭受大量攻击的时候依然满足业务的高可靠性。这是将低成本、低时延和业务可靠性的多重结合。

基于 Kubernetes 和 lstio 多云流量调度与容灾方案

Kubernetes 多集群管理方案

接下来介绍下多云应用的管理与流量控制。我们的整套方案就是基于 Kubernetes 和 Istio 实现的多云的流量调度与容灾方案。我这里分享两个方案。第一个是 Kubernetes 多集群的管理方案。第二个是基于 Istio 做的跨 Region，跨 Zone 的东西向流量调度的方案。

第一个方案，Kubernetes 的多集群管理。我们的 Kubernetes 是单云的，要求是做跨 Zone 部署，但国内可能和海外不太一样，海外的先不提。我们的应用是通过 CI/CD 直接发布到多个 Kubernetes 集群的，每个 Kubernetes 集群是完全独立的。这里可能和一些企业不太一样。有些企业可能是每个 Kubernetes 是单个 Zone 的。我们这样做是因为，如果一个 Kubernetes 一个 Zone，那么所有有 Zone 容灾需求的业务就要部署到多个 Kubernetes 集群，中间可能还涉及业务改造，这就增加了管理的复杂度。

第一个方案，Kubernetes 的多集群管理。我们的 Kubernetes 是单云的，要求是做跨 Zone 部署，但国内可能和海外不太一样，海外的先不提。我们的应用是通过 CI/CD 直接发布到多个 Kubernetes 集群的，每个 Kubernetes 集群是完全独立的。这里可能和一些企业不太一样。有些企业可能是每个 Kubernetes 是单个 Zone 的。我们这样做是因为，如果一个 Kubernetes 一个 Zone，那么所有有 Zone 容灾需求的业务就要部署到多个 Kubernetes 集群，中间可能还涉及业务改造，这就增加了管理的复杂度。

第一个方案，Kubernetes 的多集群管理。我们的 Kubernetes 是单云的，要求是做跨 Zone 部署，但国内可能和海外不太一样，海外的先不提。我们的应用是通过 CI/CD 直接发布到多个 Kubernetes 集群的，每个 Kubernetes 集群是完全独立的。这里可能和一些企业不太一样。有些企业可能是每个 Kubernetes 是单个 Zone 的。我们这样做是因为，如果一个 Kubernetes 一个 Zone，那么所有有 Zone 容灾需求的业务就要部署到多个 Kubernetes 集群，中间可能还涉及业务改造，这就增加了管理的复杂度。

同时我们还有些不好的回忆。由于我们大量使用了集群伸缩的能力，每天晚上可能一下弹出 40~50 台机器，是比较正常的。这中间有个问题经常出现，就是某个云厂商的单个可用区没有机型了，弹不出来，会导致业务因为负载问题受损。我之前也做过单云单 Zone 的方案，但是我现在更偏向于采用单个 Kubernetes 集群，多个可用区的方案。我们一般的要求是单个 Kubernetes 集群至少有 3 个可用区。

Kubernetes 集群相互独立了，怎么做部署在多个 Kubernetes 集群上的应用管理呢？不可能每 Kubernetes 都去看，普遍的解决方案是采用多云管理平台。业务通过多云管理平台就可以实现跨集群部署应用的统一管理。

为什么我们没有用跨集群的管理工具呢？因为我用 Kubernetes 的时间也比较久了，大概从 16 年就开始接触，当时 Kubernetes 的版本是 1.9。多集群的跨集群管理工具其实比较多，我们之所以没用主要是基于三个方面的考虑。第一方面是，我们没有跨集群调度的强需求。我之前做过一个方案，就是一个 Kubernetes 集群全部倒了，把业务都调度到另一个集群里面，中间遇到的问题比较多，特别是一些状态层的依赖等。解决这个问题，可以采用多集群部署。这个对我们来说并不是一个很强烈的需求，因为现在弹性能力都比较强了。我可以部署一个副本，当流量切过来时，可以通过大量扩缩容增加副本数，让业务能经受起突然到来的流量。

第二个问题就是满足一定的隔离性。我做了 Kubernetes 和 Istio 好几年了，目前没有经历过升级后整个集群全部搞挂的情况，但是云厂商会这样干的。我们在某个云厂商升级过一个集群，他告诉我，你点击一下就可以升级了。我点了一下，整个集群全挂了，所有的业务都无法访问。最后他们告诉我有 Bug，这样老板肯定就不乐意了，肯定要来批评我。所以我觉得一定的隔离性还是需要的，尤其是在日常维护集群的时候，隔离性是“保命”的必备的技能。

第三个问题是，虽然 Kubernetes 集群推出好久了，但是多集群管理还没有一个实际的标准。比如说 Kubernetes 社区有 Fedora，V1、V2 也出了。我之前用 V1，我当时觉得挺好使的，用着用着，社区说 V1 不要了，要搞 V2。可能各个方面的诉求不一样，导致 Kubernetes 社区，第三方社区有很多方案。我建议将来如果有了统一的实际标准后，再迁移到多云管理上。

基于 Istio 的跨 Region Zone 的东西向流量调度

下面要讨论的问题是多集群的流量管理。我们基于Istio做了一套东西向流量管理方案，Istio 集群的组建方案也比较多，我们选择的方案是在同一网络下的多主架构，这个架构也是我用的最多的一个方案。每个Istio都能发现其他所有集群的Service endpoint，通过 xDS 把其他集群的 Service  endpoint 下发给本集群内的 Sidecar，让应用可以跨集群访问其他集群的服务。

流量遵循的调度原则是什么呢？原则就是本地优先，这样的好处是时延最低，同时能满足一定的容灾性需求。做法是优先本 Region 本 Zone，本 Zone 失效之后再去访问其他 Region 的其他 Zone。所有的本 Region 失效后，才会去访问其他的 Region。这就是我们整个的流量调度方案。

跨云可观测性实践

有了基础网络，以及应用层流量的高可用的方案，就可以认为这套方案是高可用了吗？业务提出了一些疑问，为什么这个 IP 到另外一个 IP 不通呢？怎么解决？这就需要一个可观测平台去解决，能够提前的去感知问题，发现问题。我们在可观测平台上踩过一些坑，这里主要分享两个方面。第一个是我们在跨云基础网络质量与可靠性检测上的一些方案，另一个是多云可观测平台的搭建思路。

跨云基础网络的质量与可靠性检测

为什么要做跨云基础网络质量与可靠性检测？一旦跨云，云厂商的很多设备对我们来说都是黑盒，没办法去做深入监控。但是我们需要解决两个问题，第一个问题是通不通，业务问我这个网段到另一个网段为什么不通？第二个是质量问题，有没有时延、丢包、重传等。

1.通不通。这个问题有可能是天生的，比如网络域隔离，生产和测试要隔离。不能说要通它就会通。还有 ACL 的一些配置，BGP 还有一个比较复杂的问题是缺路由，而且排查起来比较复杂。

2.质量问题。我们遇到的问题主要是 MTU 配置错误，某云厂商把 MTU 配置错了，结果大包一直发不出去，还有一些网络配置和一些专线容量问题。我们告诉业务，我们做了一套高可用的方案，怎么证明它高可用？业务出现了故障了，能不能先于业务之前去发现？我觉得一个很核心的问题就是在业务发现故障前，提前去感知问题。

我们做了一个基于拨测的可观测平台。这是在经历过几次云厂商硬件故障，而我们又没法感知的情况下做出来的一套方案。整个拨测通过中央 Servier 集群，向部署在各个 VPC、各个 Region、各个 Zone 的 Agent 下发 Target 配置，Agent 会根据 Target 配置 Ping。Ping 不是简单的 Ping 协议，还做了一些 TCP 层面的检测，之后把这些检测数据上报到 Prometheus，从而实现任意 VPC 之间的连通性与质量拨测。它的缺点也比较明显，它只能实现端到端的拨测，并没有办法完全做到任意两个 IP 之间的网络质量监测。这套方案是不是很像 PingMesh？PingMesh 是我后来才知道的一个概念，我之前不太了解。我们现在也在向 PingMesh 的方向上去演进，通过 PingMesh 去检测多云之间的网络质量。

多云应用可观测平台搭建思路

关于多云可观测平台搭建的思路，说起来都比较简单，这里主要分析我们踩过的坑。在多云环境下可观测平台跟单云有什么不一样？主要问题是多云会涉及跨专线传输，而专线比较昂贵，成本很高；还有不同网络区域的稳定性问题，一旦跨专线了，时延就没办法很好保证。可观测平台的数据有个特点，写入量很大，实际查询量却很少。可能 90%的数据根本就不会查，业务出问题了才会上去察看一下，所以大量的写流量都走专线不合适。我们的思路是就近存储，跨专线查询。

如图所示，我们通过 Agent 收集本集群内的 Pod 日志，存储到本云上。通过查询调度器再去根据比如说分集群、分区域查询日志，让查询走专线。这个里面我们也遇到了问题。最开始时日志采集是集中的，所有的日志都是跨专线的，我们的物理专线大概有 10G，平时日志占了大概 3G，当时我也觉得没什么问题，毕竟剩余还有 7G，够用了，但还是出问题了。我们之前做了一个 VPN 备份物理专线的方案，中间做了个演练，就是把整个物理专线全部断掉，重要的流量都走 VPN，但是日志不算重要，所以没走。切过去的时候没有问题，但切回来的时候就出现问题了，这个日志积累了大概半个小时的数据量，疯狂地去抢占物理专线，由于物理专线完全没有流量控制能力，从而导致业务流量受损。

最后看一下整体架构。最上层通过智能 DNS 做多入口的多活以及主备的切换，同时通过健康检查实现对故障节点的自动剔除。接下来就是高防层，通过 DNS 的智能调度能力，结合本地高防加云原生高防，实现了一套阶梯调度的方案，能够满足低成本、低时延的要求，同时又能保障业务的稳定性。经过高防的清洗后，流量就会到达企业内部，企业内部采用多 Kubernetes 集群，通过 Istio 连成一个 Mesh，所有的 istiod 都能发现其他集群的 Service endpoint，通过 xDS 下发给自己集群内部的 Sidecar，Sidecar 实现跨集群的流量调度以及容灾。

最下面一层就是状态层的同步，做了跨数据中心、跨云厂商的 DB 的同步，采用了 TiDB 等比较常用的方案。这套集群走到了今天，还在持续演进，没有一个方案能一劳永逸，贯穿企业发展的所有阶段。比如 Istio 面对这种大规模集群的时候，有很多性能问题需要去解决。

未来展望

多云的问题比较多，有些问题我们没有完全解决。对未来的发展，再结合社区的方向，包括现在多云的安全问题和资源管理问题，我们做了以下两个方向的探索，第一个方向是基础设施即代码；第二个方向就是零信任网络。

基础设施即代码

差异化的云服务产品对基础设施管理的冲击云原生时代的基础设施管理

基础设施即代码，我这里面说到就是Terraform。Terraform 目前已经非常流行，经过我们的调研，各大云厂商都已经开始支持Terraform了。当前在多云的环境，云服务产品的差异性对我们的基础设施管理也带来了比较大的冲击。同一个产品在每个云厂商的管理流程不一样，生命周期也可能不一样。有时候为了统一生命周期管理，会选择自己对接云厂商的 API，实现生命周期的统一管理。但云厂商 API 完全不同，需要一个个对接，引入一个云厂商就需要对接一次。有时即使功能相同，特性也不同，像 LB 的很多参数都不完全一致，术语也不一致，有的叫弹性，有的叫独占。

但 Terraform 带来了角色的转化，之前是我们需要自己对接云厂商的 API，屏蔽云厂商的 API 差异，为业务提供资源管理平台或稳定的服务。Terraform 可以让云厂商自己去接入，我们实现一个 Provider，再去通过 Terraform 调各个云厂商 API，屏蔽之间的差。下面具体看下它帮我们解决了哪些问题。

• 云无关。我们引入的云厂商比较多，最苦恼的就是这么多云怎么管？各个云厂商的 API 都不一样，OS 也不一样。我们通过代码将基础设施定义好，比如环境定义，之后通过 Terraform 做到灵活迁移。

• 统一的资源生命周期管理。每个云厂商都有各自的管理方式，用 Terraform 之后我们可以在自己内部形成统一的资源生命周期管理。

• 快捷的环境复制与迁移。我们在多云上经常还会用到灵活调整部署策略，它为我们解决了很多问题。

• 标准化，自动化，可视化。Terraform 的这些特性为我们带来了非常可观的收益。我们定义好资源、代码，通过 Git 去管理，用 Terraform 的 API 自动对接内部流程，自动化管理资源的生命周期，每一次变更都通过 Git 去可视化，这些地方是我们觉得是比较利好的。

零信任网络

我们先看一下传统的基于安全边界的网络有什么问题。首先，基于边界的假设是不够合理的，因为一旦边界被打破，那么内网的流量就都是不可信的。其次，传统的基于安全边界的网络只在边界做认证。第三，边界上的认证往往也都比较简单，比如基于 IP、或者基于 Mac 地址，基于网段认证。

多云对传统网络安全的挑战

在多云环境下，安全问题就更加凸现了，主要有以下几个点。1. 云厂商的安全能力不相同，企业的整个安全能力就取决于最弱的那个云厂商。2. 云厂商也不可信，从而引出下一个问题。3. 所有核心数据都在云上，云上没有人是可信的。4. 在全球化的背景下，我们的边界、分布比之前更广了，数据分布在全球，攻击面就会更大。5. 在云服务商提供的便利服务下，业务可以很容易地获得公网 IP，通过暴露公网 LB，就可以轻松拿到公网 IP，这样是没有什么安全性可言的。

零信任网络的搭建思路主要是两个核心点：微边界和永远验证。大边界有问题，一旦突破之后里面的问题比较多，我们就要把边界细分，主要涉及三方面。

• 第一个是把 Network 重新划分，我们做了很多 VPC 治理工作，把网段分得更细了，这样就可以提高攻击者突破边界之后获取更大利益的困难程度。

• 第二个就是流量加密。我们把所有的流量都通过 TLS 加密，公网流量通过 ATBS 加密。有人说，这基本不可行，所有内网流量加密怎么可行呢？实际上很容易，因为有了 Istio，Istio 本身有 mTLS，只需要开启它就可以实现对所有的内网流量的加密，但前提是需要全部接入进去。

• 第三个是威胁防护，我们现在只是基于 IP 或 Mac 地址的防护，以后会做基于多种策略的防护，比如借助 AIOps 的一些防护能力。

这就是以上分享的全部内容。

讲师简介：

黄金，目前任职于广州趣丸网络科技有限公司，担任资深架构师，负责趣丸基础架构组。七年工作经验，五年以上基础架构与容器相关平台经验，参与过企业级容器平台从零搭建过程。目前主要工作是基于多云环境，建设企业级高可用多云基础设施。