从之前的容器到当前热门的Kubernetes、Serverless、微服务等，新技术的每一次出现，都是一场关于效率提升的革命，而效率通常包括了开发效率、运维效率和运营效率等。如果说Kubernetes专注提升容器集群的运维管理效率，那么Serverless则从根源上摆脱服务器的运维难题，使计算资源作为服务而不是服务器的概念出现，从而将开发人员的效率最大化。为了帮助企业更高效率部署业务，更快实现持续交付、灰度发布、应用编排等诉求，5月28日UCloud TIC（北京站）“云上效率提升”技术专场，来自 UCloud的四位资深技术专家围绕该主题进行了深入的技术探讨和实践案例分享。

基于Kubernetes构建容器云平台的实践

基于Kubernetes自动化部署、弹性伸缩和容器化等特性，UCloud针对内部研发人员和外部用户分别构建了容器云平台，UCloud实验室负责人叶理灯在会上分享了这两套容器云平台的技术实践原理。

 

UCloud内部容器云平台（简称KUN）的底层是基于Kubernetes搭建的，主要的实现方法之一是K8S+Docker，通过Docker提高运维部署效率和运维环境的一致性，通过K8S实现跨可用区容灾和AutoScaling能力，从而实现高可用、在线升级、自动扩缩、负载均衡、日志查看、资源监控等多种功能。

图：内部云平台的架构图

叶理灯提到，在构建内部容器云平台KUN的过程中要解决四个主要问题:1.多租户隔离的问题，保证业务之间互相不受干扰；2.IPv6的问题，如何保证跟IPv4网络兼容；3.如何用Operator来管理有状态的服务；4.监控问题。

对应的解决方案分别是：

1.基于RBAC来实现账号管理隔离，选择Token认证方式，通过服务账号SA（Service Account）模拟普通用户User，所有模拟账号的SA放置同⼀个NS，进行统⼀管理；定制权限组ClusterRole，通过授予模拟账号SA的不同权限组，来控制不同User在NS中的不同权限。抽象Project对象给User使用，Project与每个集群的NS⼀⼀对应，User在每个集群上都有对应模拟账号用于NS授权。

2.针对IPv6的问题，接入6to4 Tunnel和Bridge网桥，核心基础网络无需修改，采用underlay，实现Pod与集群外部互通。Service全网可访问，ClusterIP在K8S集群外部可以直接访问，分配一个Ipv4地址，在Kubernetes集群下的所有介入交换机上宣告，该IPv4地址对应的6to4地址作为该Kubernetes集群ServiceIP地址段。Pod返回的包，会先回给Service Gatevay，由于做了SNAT，基于连接追踪（conntrack），再返回给请求的客户端。

3.在KUN中使用Operator，为用户提供可视化 Web 操作页面，简化对各类自定义资源的管理操作。 用户不需要详细理解具体的 CRD 结构，就可以在Web 页面上快速创建⼀个 Redis 集群，并且可以看到集群⼀步步创建的过程。同时还可以对集群进行配置更新、删除等操作。

4.监控系统方案基于Prometheus构建，Prometheus部署于K8S集群中，使用HostPath存储数据、Metrics采集，使用Alert Manager 聚合报警，调用 Monitor Manager 提供的 Web Hook；自研 Monitor Manager：使用Grafana 实现 Web 可视化；

而UK8S是基于Kubernetes的对外部用户的容器管理服务，用户可以在UK8S上部署、管理、扩展容器化应用，而无需关心Kubernetes集群自身的搭建及维护等运维类工作。除此之外，UK8S还完全兼容原生的KubernetesAPI、以UCloud私有网络为基础，并整合了ULB、UDisk、EIP、VPC等云产品。

 

UK8S集群网络通过自研CNI插件与VPC网络深度集成、利用Secondary IP API实现IP管理、无overlay性能与云主机一致、Pod网络可与物理云托管云直接互通。

最后，叶理灯总结了UK8S管理服务的特点如下：

    A、完全的容器化和微服务化。

    B、所有管理服务全部运行在K8S上。

    C、基于K8S的API对服务模块进行动态管理。

    D、一个集群对应生成一个watcher，容易进行横向扩展。

    E、基于watcher+redis缓存的方式，保证用户在控制台获取集群信息的速度足够快。

利用StepFlow快速可视化的构建新业务

开发人员在构建应用服务的时候通常会写很多业务逻辑，还需要调用大量API或者服务接口，这个过程会出现很多问题，比如要写很多代码才能要调用这些API、某个功能开发完成后还需要后期维护。开发完成之后还要进行发布，除了本地去编写代码、调试，发布上线还要申请物理资源，中间可能还需要各个团队的协作，整个流程非常长。

 

UCloud技术总监蒙晓净说到：“以上这些问题其实都属于在研发过程中产生的隐性成本，那么有没有一种产品能够让我们解决上面的这些问题？用可视化的页面，比如画一个流程图把我的想法表达出来，把流程图转换后立刻实现所要的业务功能。”答案是StepFlow产品，它是一个通过可视化的方式去编排API和微服务的服务平台，应用开发的时候可以在不写代码的情况下完成新的功能的组装、新的服务接口的发布。

 

为帮助大家进一步了解StepFlow如何快速构建业务，蒙晓净介绍了四个应用场景：

1.  实现一个串行流程。这个场景的案例来自于爱普新媒体，在使用USQL进行数据分析之后，希望把这个分析结果导入到数据库里面进行二次保存，在导入完成后可以发一个短信给相关的人员通知任务完成或者失败。在这个过程中爱普新媒体用到了很多USQL、UFile、StepFlow、UDTS、短信包、数据库等产品，而StepFlow在这里相当于起到中枢的作用，把各个产品关联到一起。

2.  实现一个并行的流程，这里举一个UMedia媒体工厂的产品使用场景，它的功能是对视频做各种处理，通常需要在一个视频文件上传到UFile之后，对它做多个视频处理任务，例如多种格式转换、打水印、截图等等。在这个场景中StepFlow把UFile、UMedia关联到了一起，更关键的是它不仅局限于UCloud的产品，StepFlow还能够与用户自己的业务服务进行交互关联，调用第三方的Http，提供了极大的业务想象空间。

3.  实现调用子工作流，已创建的工作流能够变成子工作流，被其他工作流调用。类似于各种编程语言中标准库提供的公共函数，或是业务框架自行封装的函数；可以提前构造常用的公共流程，方便使用。

4.如何更新业务&快速发布？这里StepFlow是通过多版本管理的方式来解决这个问题。例如当前正式业务使用的是版本V1，如果要对V1进行修改，我们可以基于V1新增一个步骤NewStep并保存，只要是仅保存不发布，正常的流量是不会流入的。通过这样的方式也可以确保流程编辑不会影响正式的业务。然后通过指定版本的方式进行调试，最后确认无误后再进行发布。以这样的多版本功能还可以实现类似灰度控制的方案。

图：传统研发路径和StepFlow流程对比

大家可以看到，在以上四个场景实现的整个过程中我们并没有申请任何物理资源，甚至也不需要关心底下的物理资源使用情况怎么样，这充分表明了StepFlow本质上是一个Serverless的服务，这些事情都是StepFlow服务在后端进行动态的管理和调度的。同时，在这样的前提下，用户就可以集中更多精力在自己的业务上，优化自己的产品，从而获得更大的价值。

基于Serverless的数据湖分析引擎USQL实战

“我曾经作为一线的大数据开发工程师，经历过很多诸如组件版本冲突、维度膨胀、硬件故障、脏数据、集群更换、数据丢失等问题，经常半夜三四点爬起来加班进行数据排测的工作。为了解决这些困扰，我加入UCloud之后希望做出的大数据产品具备成本低、分析简单、无需运维三大特点。”UCloud产品总监张晓康说到。用户都希望数据创造的价值越大越好，而相关的成本投入能够趋于收敛，因此2018年10月份UCloud发布了一款基于Serverless的SQL分析计算引擎USQL(数据湖分析)，企业无需数据库管理员和运维人员即可完成面向海量数据的数据建模、SQL数据查询分析等工作。

举一个案例：爱普新媒体每天的数据日增量是300G、总量120T，每天运行50个Hive SQL实例， 大数据团队4-5个人，每年150万的人力投入。设备上的成本每年折旧下来大概是60万，托管费用大概每年30万，最终计算下来的结果是131.5元/SQL。针对这个场景，UCloud帮助用户利用对象存储UFile优化存储成本，再通过USQL节省计算成本。“我们将Kafka存储规模庞大的全量原始广告日志数据放到UFile，无需加载数据，直接通过SQL分析UFile数据再交给USQL，研发人力投入为0,大数据消费降低了92.85%，需求完成周期从原来的43.2小时降低到2小时。”爱普新媒体CTO牛德恒总结到。

在数据探索场景，普遍存在的问题有数据格式不固定、数据规模大、没有元数据、分析目标不明确等，USQL由于支持丰富的数据格式、计算与存储分离、元数据与数据分离、快速SQL分析等特性占据了绝对的优势。未来，UQSL产品将持续完善新的功能，例如支持JDBC的驱动、数据加密——协同UKMS（密钥管理服务）、CREATETABLE AS SELECT（CTAS）等。

云主机并发创建优化实例及用户价值

不同行业的客户可能对云主机并发创建都有需求，最常见的场景有电商大促、动画渲染、营销活动、教育培训等。在这些场景下，用户往往需要用尽可能短的时间创建上百台甚至上万台云主机来应对业务的高峰期。UCloud资深研发工程师齐良在现场分享了云主机并发创建的后台优化实践方案。

 

针对本地盘主机，虚拟机镜像从镜像仓库复制到宿主机再拷贝到虚拟机大概需要300秒，如果我们将镜像文件提前部署到宿主机上，那么从宿主机上拷贝镜像到虚拟机的时间就只需要30秒，这个方案在UCloud早期机房规模不是很大的时候还能适用。但到后期显然不行，因此UCloud开发了BlockStreaming技术，从而使单台云主机的创建时间小于10秒。

 

针对云盘主机的开机需要镜像完全复制、复制时间长、镜像仓库带宽瓶颈问题，UCloud研发了Koala镜像系统，实现了镜像分片存储、并发拷贝，有效的解决了由于复制导致开机时间长的问题，最终使得单台云主机创建时间小于15秒。如果要进行批量创建，我们采取的方案是镜像分片在UDisk内部进行P2P分发、同⼀个镜像只从Koala复制⼀次 、UDisk只缓存热门镜像，最后的效果是平均单台创建时间6s秒100台耗时10分钟。然而这个时间还是不能够满足很多用户的需求，于是我们进一步优化的手段是异步返回、并发申请资源、优化IP地址申请，最后100台耗时约5分钟；如果在批量创建100台云主机的代码中采用批量创建API接口可能耗时只需要2分钟，用户看到的可能只是改了API接口，但这只是背后复杂逻辑的冰山一角。

 

由于Koala镜像系统的限制是24台物理机、1000M网口、云主机拉取镜像20Mbps，我们经过计算这个系统最大只能支持150台并发创建。如果要实现同时创建1万台云主机，就需要提前预约资源、利用空闲资源加速创建 、突破Koala系统⽹网络瓶颈，基于这个想法我们又开发了镜像Cache系统。镜像Cache系统里面的空闲资源是成千上万的，可以假设这种带宽是没有限制的，基本就可以解决Koala镜像系统的带宽问题。

云主机并发创建优化实例及用户价值

不同行业的客户可能对云主机并发创建都有需求，最常见的场景有电商大促、动画渲染、营销活动、教育培训等。在这些场景下，用户往往需要用尽可能短的时间创建上百台甚至上万台云主机来应对业务的高峰期。UCloud资深研发工程师齐良在现场分享了云主机并发创建的后台优化实践方案。

 

针对本地盘主机，虚拟机镜像从镜像仓库复制到宿主机再拷贝到虚拟机大概需要300秒，如果我们将镜像文件提前部署到宿主机上，那么从宿主机上拷贝镜像到虚拟机的时间就只需要30秒，这个方案在UCloud早期机房规模不是很大的时候还能适用。但到后期显然不行，因此UCloud开发了BlockStreaming技术，从而使单台云主机的创建时间小于10秒。

 

针对云盘主机的开机需要镜像完全复制、复制时间长、镜像仓库带宽瓶颈问题，UCloud研发了Koala镜像系统，实现了镜像分片存储、并发拷贝，有效的解决了由于复制导致开机时间长的问题，最终使得单台云主机创建时间小于15秒。如果要进行批量创建，我们采取的方案是镜像分片在UDisk内部进行P2P分发、同⼀个镜像只从Koala复制⼀次 、UDisk只缓存热门镜像，最后的效果是平均单台创建时间6s秒100台耗时10分钟。然而这个时间还是不能够满足很多用户的需求，于是我们进一步优化的手段是异步返回、并发申请资源、优化IP地址申请，最后100台耗时约5分钟；如果在批量创建100台云主机的代码中采用批量创建API接口可能耗时只需要2分钟，用户看到的可能只是改了API接口，但这只是背后复杂逻辑的冰山一角。

 

由于Koala镜像系统的限制是24台物理机、1000M网口、云主机拉取镜像20Mbps，我们经过计算这个系统最大只能支持150台并发创建。如果要实现同时创建1万台云主机，就需要提前预约资源、利用空闲资源加速创建 、突破Koala系统⽹网络瓶颈，基于这个想法我们又开发了镜像Cache系统。镜像Cache系统里面的空闲资源是成千上万的，可以假设这种带宽是没有限制的，基本就可以解决Koala镜像系统的带宽问题。

齐良最后补充说：“后台做了这么多的优化之后，导致最终的系统也非常复杂，出问题的概率会比较大。为了保证系统的稳定性，我们需要对系统进行改造，要把这个系统做的足够简单，包括建造周期要短，调度和镜像拉取的逻辑也要更简单。最终体现在架构上就是关键路径要短、核心逻辑要简单、非核心服务可插拔以及兜底策略。”

 

关于本次技术专场的更多演讲内容，欢迎关注“UCloud技术”公众号回复“TIC”获取讲师PPT。