淘宝开放云研发PaaS新探索——聚石塔云托管技术
淘宝开放平台是淘宝天猫与外部生态互联互通的重要开放途径，通过开放的产品技术把阿里经济体一系列基础服务，像水、电、煤一样输送给我们的商家、开发者、社区媒体以及其他合作伙伴，推动行业的定制、创新、进化, 并最终促成新商业文明生态圈。
本文为此系列第三篇文章，前两篇见——
第一篇：开放网关架构演进
第二篇：元数据驱动架构的官方数据空间设计
问题由来
聚石塔在淘宝天猫算是一个“古董级”技术平台，从诞生之初就承载了支持淘宝开放生态的使命。历经几代技术变革走到现在。
在2019年我们做了对三方开发生态的“云原生化”之后，基本上大部分电商生态ISV的主要业务系统都完成了云原生化，每个isv会自己保有若干个ACK集群，聚石塔的职责是帮助ISV来运维集群，并且基于k8s的能力搭建了一套应用运维PaaS，解决应用的CICD，监控运维，安全管控等问题。这套模式在电商场景下得到了比较好的验证，借助云原生标准化以及繁荣的云原生生态，帮助电商ISV完成了技术架构升级，平台侧则借此机会完成了应用架构标准化以及稳定性保障能力的提升。目前聚石塔容器集群的日常总规模已经达到万核的规模。
也是从19年开始，淘宝小程序生态开始蓬勃发展，越来越多的三方开发者涌入到开放平台，为千牛和手淘的商家以及消费者服务。这些生态的系统也都统一落在了聚石塔的容器PaaS上，随之而来也诞生了新的问题。
▐ 中小型开发者的第一座山
相比于传统电商类ISV，小程序ISV的体量要小很多，应用架构也要简单很多。通常1-2个应用就能完成一个小程序所需的所有功能。「容器集群+应用」的模式对于此类小型应用的开发者显得过于复杂，学习成本也太高，同时还会带来资源浪费的问题。对那些没有聚石塔基础以及云基础的开发者而言尤其严重，就好像打开淘宝开放平台大门之后看到了一座高山，还需要学习相关技术，付出精力勇攀高峰。
应用&集群创建的复杂度
一个云应用入驻小程序，通常的初始化路径：
申请开放平台应用 --> 聚石塔购买ECS资源 --> 聚石塔创建集群&初始化 --> 聚石塔创建并部署应用 --> 聚石塔购买SLB --> 应用关联至小程序云网关
对一个熟练的开发者，整个过程的时间统计如下：
购买ECS |
集群创建&初始化 |
创建并部署应用 |
购买配置SLB |
应用关联云网关 |
总时长 |
分钟级 |
小时级 |
小时级 |
分钟级 |
小时级 |
65min |
对于不熟悉平台的开发者，时间会更长，学习云基础设施、熟悉整个运维框架需要大概3-7天时间。
额外的成本付出
在小程序业务场景中，大部分的k8s集群都属于规模小于50核的小集群。
对于50核的集群（6个8核16G的ECS）而言，会被集群管控组件占用掉3.5核10G的资源；对于20核的集群（5台4核8G的ECS），会被集群组件占用掉3核8.5G的资源；集群估摸越小，用户实际可用资源越少，业务成本越高。
据统计，大部分小程序开发者集群规模都比较小，需要付出相当比例（1/10~1/5）的成本用于集群系统组件开销。
同时，开发者还面临大促运维困难（需要提前扩容，准备多可用区资源），日常集群组件运维复杂等问题。
▐ 平台开放的桎梏
在传统电商场景中，聚石塔已经定义了一套非常完整的开放标准方案。既让传统电商开发者“入塔”：服务商可以通过“入塔”把服务部署在聚石塔的IaaS或应用PaaS上，以获得更好的业务系统稳定性和业务数据安全保障，进而更好的服务淘宝的商家和消费者。
但是小程序生态场景则更加丰富，有更多垂直业务场景，比如涉及敏感数据的聊天语料场景，以及基本不涉及敏感数据的小游戏场景。更细分的业务场景，如果都统一使用老一套的管控标准明显是不合适的。那么如何面向不同的垂直业务场景，不同规模的三方应用，开放不同粒度的管控方案，也是聚石塔接下来需要解决的重要命题。
解决垂直业务场景平台业务开放标准的问题，解开平台业务开放的桎梏。
▐ 不能让入驻聚石塔成为业务的卡点
在我们的各种竞对越来越多的平台玩儿法出现的时候，聚石塔不能成为淘宝开放业务下三方开发者入驻的卡点。那如何解决上述的几个问题？在小程序这个大业务场景下，“云托管”方案是聚石塔给出的答案。
云托管是指将用户的计算资源（容器）、数据库资源、网络资源完全托管化，用户不再需要关注底层基础设施的运维，只需要将精力集中在业务代码研发的“应用云原生化”方案。通过这种方式，用户打开开放平台大门之后，面向的不再是一座山，而是一辆车，按照用户熟悉的代码开发方式就能将业务跑起来。本质上云托管其实是Serverless的形态之一。
通过平台集中托管计算网络架构，屏蔽业务流量链路的复杂度（比如用户不再需要自己购买和管理用于小程序云业务流量的SLB），集中化管理IaaS资源准备，降低用户对集群运维和组件运维的感知度，从而降低用户的学习使用成本，运维成本和资源成本。
同时借助k8s云原生天然的松耦合网络插件能力，为不同业务场景，定制不同的网络管控方案，解决平台面向多业务场景下更细粒度的网络管控需求。
技术实现
总的来看，云托管将资源的托管分为两个大类：
计算资源托管，即计算容器的托管；使用ASI（k8s）集群运维管理资源；
应用依赖的云资源（数据库、中间件）的托管；由平台管理各资源的购买，使用，以及运维。
通过两大类托管的资源以及管控链路模型，我们把整体网络切分为4个区域：
ASI集群VPC：实际是公有云的云上VPC。内部包含开发者部署的应用，业务组件Addon应用，以及集群中的管控组件和集群运行必备组件；
租户托管VPC：平台为开发者单独分配的VPC，开发者对此VPC无感知。该VPC的主要作用是用户资源的隔离，以及用户云资源归属托管。
阿里集团内网：集团内网内部署平台的管控应用以及对用户透出的控制台应用，通过网络打通的方式下发指令到ASI集群中。
小程序云网关：云网关用于连接手淘端流量，并通过跨网技术将流量下发到托管集群的用户应用pod中。
通过上面的基本路径，用户可以在聚石塔内实现Serverless的应用研发，同时无需感知“云”的复杂概念，以“资源云原生化”的方式来使用平台托管的云产品，由平台对底层云资源做包装和集成。
在上述的方案中，需要解决以下几个方面的主要问题：
如何在集群中隔离多租户的应用和容器；
如何在隔离的同时实现单租户的应用与资源网络通信，实现平台面向不同业务场景的网络管控；
Serverless场景下的应用自动弹性伸缩方案；
▐ 多租计算隔离模型
我们在初期选择底层容器技术方案的时候，考虑了多种不同的容器集群托管方案，包括ACK，自建，以及阿里云ASI。后面考虑到面向二方业务的能力完备性，选择了ASI作为底层k8s托管方案。
而聚石塔并没有直接使用ASI的多租集群方案，而是使用ASI的单租集群，由聚石塔作为统一租户对集群进行整体管理，以及不同开发者（租户）在集群内的资源分割。
为了解决runc容器无法彻底做到内核级别隔离的问题，聚石塔底层的容器选择了袋鼠RunD容器作为安全容器解决方案。
RunD容器构建在神龙裸金属服务器之上，租户容器的分配其实是和交换机挂钩的，在后面网络通信与管控的部分会详细介绍租户容器网络的分配规则。
▐ 网络通信与管控
网络通信与管控，主要需要解决两个方面的需求：
为pod分配网络，实现应用网络通信；
面向多业务场景，实现分级的网络管控；
通过Pod挂载多ENI分割业务管控流量和用户流量
从应用视角来看，我们可以把流量分为两种类型：
平台业务管控流量，比如从前台云网关导入的业务流量（南北流量）
用户应用内部流量，比如同租户应用间的流量访问，或应用与rds之前的访问流量（东西流量）
结合跨VPC双向通信的需求，我们选择了pod挂载多ENI网卡的方案。利用ENI网卡的跨租户挂载实现不同租户VPC的互通，利用ENI的边缘交换机来管理网络的通达。
在聚石塔的场景中，容器默认的eni网卡（eth0）用于南北业务管控流量通信；容器通过角色扮演挂载的用户eni网卡（eth1）用于用户应用间以及与云资源的通信。这样两个网卡对应的交换机和安全组也可以做拆分管理。
租户间网络隔离
上面提到了每个pod都会挂两个eni网卡，一个是管控网卡，用于平台业务流量导入；一个是用户网卡，用于与用户独占的托管vpc通信。那如何解决多租户应用间的管控网卡隔离问题？（不需要考虑用户网卡的隔离，因为天然就是通过vpc隔离的）
有两套方案：
独立交换机+安全组方案
为租户分配独立的交换机和安全组，同租户的pod都生产自同一组交换机，通过在独占的安全组内配置交换机网段互通规则来保障应用只能局限在同租户内。
这个方案简单，且比较容易实现同租户应用间的k8s service通信。但是有个致命问题，由于vpc有交换机数量上限（120个），导致每个vpc内可容纳的租户最多只有40个（还要考虑多可用区容灾的问题），不符合平台所需要接入的isv的规模。
共享交换机+安全组
共享交换机+安全组的方案，是多个租户共享一个交换机分配pod ip；这时候为了避免不同租户间的pod互访，需要将所有pod加入到一个统一的企业安全组内，利用企业安全组内成员默认不能互访的能力，隔离pod间互访。
实际上，这个方式是隔离了所有集群内的pod互访，包括同租户的pod互访；同租户的pod互访需要通过用户eni网卡来实现。
而由于kcm，kube-proxy的默认规则，k8s service选择ip的时候会默认选择eth0网卡ip，导致k8s service无法使用。想要突破该限制的方案会相对复杂，需要自己定制k8s的endpointController来实现service的realServer动态挂载，同时通过宿主机的路由和iptables定制实现网络包从正确的网络出口出去。
面向多业务场景的网络管控方案
文章开始提到，聚石塔需要解决面向不同开放场景的网络规则细粒度控制的问题。我们把业务场景总结为3种类型：
场景 |
数据级别 |
公网访问方式 |
封闭环境 |
高 |
默认情况下不允许访问公网，如有特殊情况，需要走外链调用（请求会经过审计） |
受控环境 |
中 |
仅可以访问经过审批的公网ip地址，有部分加密敏感数据场景 |
开放环境 |
低 |
可以自由配置公网访问，无数据风险场景 |
针对3种典型场景，我们设计了不同的网络管控方案。
由于有双网卡的便利性，我们可以将用户自己的流量封闭在用户eni网卡内，进而通过控制用户eni所在vpc的交换机和安全组来控制网络流量。
比如在封闭环境中，我们在用户eni网卡的安全组规则定制了禁止所有公网出入的规则，直接可以封闭用户应用的公网出入访问；而在开放环境中，我们并不会针对网络做特殊的管控和定制，用户甚至可以将自己的应用挂载slb对外提供服务。
▐ 应用稳定性银弹 —— 自动弹缩
提到Serverless方案，那不得不提的就是自动弹缩。应用自动弹缩是平衡应用稳定性与应用成本的利器。同样的，在聚石塔云托管环境中，云托管支持基于容器指标的自动弹性伸缩，比如CPU、内存水位；同时我们也支持基于业务水位的弹性伸缩，比如基于小程序云网关流量的弹性。
其中基于CPU内存水位使用了k8s原生的metric server作为数据源，提供给标准的HPA服务根据相应的算法计算做种做出弹性的决策；
官方的数据源和HPA都无法很好支持类似自定义业务指标类型的弹性，所以我们引入了KEDA作为弹性伸缩的前置决策工具，通过 KEDA 我们可以根据需要处理的事件数量来驱动 Kubernetes 中任何容器的扩展；同时我们定义了专用的数据采集器jst-externalscaler用于自定义业务指标数据的采集。
通过官方HPA+KEDA的扩展组合，最终实现了云托管的应用pod自动弹性基础设施。
向前看
云托管在聚石塔的产品矩阵中，更像是一个“自治区”。以“先富带动后富”的形式，从轻量化的淘宝小程序场景出发，探索对淘系服务商，对商家更友好的基础设施能力，重新定义“入塔”标准，最终带动整体聚石塔上的三方业务整体向更简单，更敏捷的方向演进。聚石塔是连接生态开放与云的重要且唯一的通道。所以聚石塔决定了数据安全，决定了开发者体验，也决定了业务交付效率。如何解决“入塔”问题是一个重要的命题和考验。未来聚石塔会继续在应用开发者生态中深耕，结合低代码，函数计算，云托管等多种手段，打造面向业务的“应用云原生化”PaaS平台，欢迎大家一起探讨~
团队介绍
大淘宝技术开放平台，是阿里与外部生态互联互通的重要开放途径，通过开放的产品技术把阿里经济体一系列基础服务，像水、电、煤一样输送给我们的商家、开发者、社区媒体以及其他合作伙伴，推动行业的定制、创新、进化, 并最终促成新商业文明生态圈。
我们是一支技术能力雄厚，有着光荣历史传统的技术团队。在历年双十一战场上，团队都表现着优异的成绩。这里承载着每秒百万级的业务处理，90%的订单通过订单推送服务实时地推送到商家的ERP系统完成电商作业，通过奇门开放的ERP-WMS场景已经成为仓储行业标准。随着新零售业务的持续探索与快速发展，我们渴求各路高手加入，参与核心系统架构设计、性能调优，开放模式创新等富有技术挑战的工作。
¤ 拓展阅读 ¤
3DXR技术 | 终端技术 | 音视频技术
服务端技术 | 技术质量 | 数据算法