美图 IT 老兵：关于大规模图片处理和全球云端处理架构思考

5 月 25 日，全球最具影响力的高端技术人学习成长社交平台——TGO 鲲鹏会邀请了不同领域的技术管理者，从案例和实践出发，一起分享讨论自己在架构设计方面的想法和宝贵经验，深入解读可扩展、高可用架构。在活动现场，美图公司技术总监王静波结合美图公司现状为大家分享了在大规模的场景及其需要支撑全球用户的场景下，美图如何运用面向未来的云端流程处理系统，从根本上解决处理时长、可用性和成本等问题。

6 月 14—15 日，由 TGO 鲲鹏会主办的 GTLC 全球技术领导力峰会总站将在上海举行。
口述 | 王静波整理 | Rainie Liu云端图片美化技术架构

美图绘画机器人“Andy”的成果

上面是美图绘画机器人“Andy”根据照片绘制的图片，Andy 是美图云端图像处理的核心技术之一。

本地图片处理的局限

一部分图片处理从本地迁移到云端是必然的路径。以往美图秀秀的图片处理功能大多在设备端，但随着时间推移遇到很多问题：

1、研发链条长。算法研发出来后需要为设备适配、测试、更新版本，速度较慢。

2、客户端体积膨胀。每加一项算法客户端体积都要增加，久而久之客户端膨胀很厉害，在海外市场用户对包体积比较敏感，这一点影响很大。

3、客户端性能不足。一些低端设备难以提供很好的用户体验。

4、AI 训练数据不足。本地处理的图片很难为云端提供数据训练。

此外，4G 网络的发展、带宽和延迟的改进等客观环境改善，加上图片美化流行潮流迭代加快等因素，促使美图开始研发云端图片美化架构。

云端图片美化架构

云端处理图片有三大基础要求：速度快、成功率高、质量全面监控。

基于三大要求，美图设计了如下架构：

上图是一个简化的方案：客户端先上传到存储服务，再调用 API 服务进行处理，API 服务到客户端服务是同步的，超时的话会有一个轮询机制。

为了解决隐私顾虑，用户上传到云端的图片后，6 个月后会全部删除，在此期间进行人工智能的训练。

为了保证速度和成功率，美图做了一些优化措施。

1、客户端：效果列表的预加载；上传服务采用 token 预获取；调节参数减少图片体积。

2、上传图片时会有两个源站服务，如果上传我们自身的源站有问题，则自动切换到公有云上面，两个服务会产生同步；图片、视频会切片上传减小压力。

3、API 服务和处理服务保持长连接，对于处理服务会进行弹性调度。它根据现在 CPU 使用率来自动弹性调度，自动扩缩容，从而提升处理速度，降低成本。

美图全球部署的问题

美图秀秀、美颜相机、B+ 等产品在国外用户量非常大，所以云美化不仅要考虑国内，也要考虑国外市场。

因为美图的存储服务和处理服务是两个不同的域名，可能会出现存储服务是在中国的 region，但处理服务的 DNS 解析到新加坡去了，导致图片处理失败。

目前美图采用的解决方案是，在存储服务和 API 服务方面有一个特定的字段定位 region，这样在上传一个图片到存储服务时就会知道下一次图片处理应该到哪个 region。这个方案还会显著提升容灾切换能力，通过业务端切换备份机房速度更快。

全面质量监控

1、美图有一个专门的文件上传 SDK；产品有一个通道上报一些指标数据，包括用户处理的效果 ID、上传时间、处理时间、下载时间、失败环节等等。

2、文件上传的 SDK 也有监控，包括上传时间，失败率，速度等等

3、API 服务的监控。监控请求 API 服务之后，处理服务花了多长时间。API 服务监控能单独看到处理服务器的情况，给出最后的报表。

美图根据详细的监控数据可以做针对性优化，根据地区维度和效果维度监控反馈数据。

边缘计算

运煤化准备演进的方向是边缘计算。

边缘计算的目标：数据上传的时候上传到 CDN 的边缘节点，处理也是在边缘节点处理，处理完成后，异步上传到源站，减少相关步骤，节省时间，提升用户体验。

大规模视频处理架构

图片视频处理需求传统上有几点：打水印、给视频截帧、转码服务、为内容加入特效。

传统处理方式下，给视频要打一个水印，打一个水印就调一段脚本，相当于是业务方是命令的决策者；处理服务则是一个命令的提供者。

问题

这样会存在一个问题，当业务方数量增多后，逻辑会非常混乱。假设，把水印的代码稍微改一改，10 个业务方就都要按照这个参数来改，这样改一个流程大概要半个月。

还有一些问题，首先决策方的业务代码全是业务方决定，很难把控；其次这套服务没有流程化；第三在于资源没有办法弹性调度。

解决方案

第一，业务方只要提交需求，比如需要对这个视频进行处理，处理的决策过程放到处理服务，把决策下移到处理服务来。

第二，原来有很多的命令，里面都是一个 shell 脚本或者是一个开源代码。以前每次上线都是先把这一类命令放到物理机的某一个目录上去统一放好，上线就把它配置上去。但是，当命令没有放到那个文件夹里面，调不到就会失败。假设每次都要重复写这样一套流程，那么新加一个业务写一套流程，因此我们希望处理命令方能够通过配置来做，处理命令写好一次放在这个地方就 OK，当别人想要用服务的时候，就可以把这套东西配置起来，把钟点工式的服务变成管家式的服务，把命令配置好。poseidon 是一段代码，第一步先接收消息，第二步下载图片，第三步是处理，处理结束后就回调业务方，只有处理这个步骤需要变化，其他步骤都是固定的，因此采用模板方法的设计模式来做。

第三，处理的逻辑用 trident 来补充。工程师会写上这个函数，把这个函数到底怎么样配置、参数是什么样子等全部列下来，后面增加任何服务的时候只要写一个 shell 脚本就行，中间接收消息、下载、回调、处理的过程等已经全部模板化，通过组装的方式在界面上就能组装出来。

处理原来是在物理机上，我们改造后放到 K8s 上进行，可以做弹性调度。最下面一层是云存储。

业务和处理

例如美拍的一个视频处理规则要求视频短边小于 540 时做一些事，这是一个规则引擎以及一个工作引擎负责下一步的处理，处理完之后要回调也无妨，告诉它回调业务方哪一个接口、什么格式，回调之后整个流程结束。那么我们只要通过配置的方式，就可以完成业务规则的定义。

poseidon 和 trident 的工作核心定义是，写好了一个函数是一个 python 脚本，调用一下它才能处理这个视频。这里提供三种方式调用，第一个是 HTTP 的同步调用；第二个是队列的方式；第三个是跟 kafka 类似的 kaproyx。

代码写好之后首先要提供该配置数据，或者从 kafka 读消息。读完消息之后把图片或者视频下载下来，拿这个函数处理。处理完之后上传到存储服务，上传完之后再回调到规则引擎。

把这个函数写好之后，trident 能够把函数配置和写好的模板方法（poseidon 的方法）打包成一个 docker-image，放到 docker 里面服务就 OK 了。

美图的大规模图片视频处理架构主要由 3 大特性，第一是通过决策下移，从业务方下移到处理服务提升控制力；第二是处理流程化；第三是通过 K8s 等能够做到大幅度的弹性调度。

Q&A 提问：APM 的部分，监控获取信息是用一些商业的方案，还是用开源的方案？有没有考虑到 APM 对自己本身业务性能的评审？

王静波：APM 是一个通道，是一个被动旁路的行为。业务方主动把这些信息收集好之后发给它，它只是通过一个 HTTP 的接口把数据上传。我们通过 IP 服务判断用户是在美国，或者是在中国福建厦门；是用的电信、联通，还是长城宽带？

我们还有一个比较强悍的武器是哈勃。比如我们的秀秀加一个哈勃的 SDK 之后，秀秀所有的 HTTP 请求，只要在白名单里面的都会上报 TCP 时间、DNS 时间、成功还是失败、整个处理时间……大概有几十个指标全部会上报。这个过程相当于做了一个代理一样，所有的行为发到哈勃的 SDK，SDK 再代理出去，效果非常好。

因为哈勃能够知道完整的所有指标，所以哈勃系统能帮助我们进行优化，包括我们做了 DNS 的 SDK，通过哈勃系统数据发现，有一些用户的 DNS 的时间非常长，那么我们可以根据用户需求做一个 DNS 的缓存 SDK- FastDNS。

这个问题讲的非常到位，管理学上有一句话，如果你不能度量它就不能管理它。我们很多时候不知道它的性能怎么样的时候，是没有办法去优化的。所以我们 APM 也好，我们哈勃系统也好，都是这样做的。

原文链接

https://mp.weixin.qq.com/s?__biz=MzA4NTU2MTg3MQ%3D%3D&mid=2655168641&idx=1&sn=53542b3dcbe2f82bda2af6a7c0cd57b4&chksm=84600fe1b31786f7bc9b3c1ffdd93456286fff7b9870cf17d8daea2dfba1a64d0937565876f0&mpshare=1&scene=23&srcid=%23rd

服务推荐

蜻蜓代理
代理ip
微信域名拦截检测
微信域名检测api