简介：2018年7月6日至7日，一年一度的科技圈盛会——全球建筑师峰会在深圳华侨城洲际酒店举行。 100多位国内外技术专家将齐聚深圳，分享各种技术架构的最佳实践。腾讯技术工程事业群架构平台部讲师分享了《基于弹性计算的实践》主题。以下为现场演讲内容。
据麦肯锡公司统计，全球服务器CPU利用率平均仅为6%至12%。阿里巴巴、腾讯等国内大型互联网公司的CPU平均利用率在10%左右。这主要是由于三个原因：
•单一业务难以均衡利用各种资源，99%的情况导致资源闲置
•在线服务的特点决定了30%的时间段是低负载的
•服务器传输过程可能会导致5%的时间空闲
最理想的情况是有一个这样的公司级borg资源调度平台。各业务建立在统一平台上，共享资源池混搭。但基于BG各自运营的历史现状，公司运营管理层共同打造弹性计算、各BG运营部门共同打造的共享算力平台，试图集合全公司闲置资源，从业务中挖掘金矿。现有网络，并以容器的形式满足计算需求。
经过一年的建设，已挖出约140万个核心，支持亿级视频转码、图像压缩以及腾讯围棋、王者荣耀、手机浏览器等游戏AI。但仍面临诸多挑战，例如作为：
例如，服务接入门槛高，业务需要了解和适应多样化、灵活的资源，长尾服务接入困难；另外，利用率不受控制，部分有状态服务的利用率不高，且不存在不能自动扩缩容的情况；小资源碎片，如剩余1核、1GB无法使用；最后，平台无法准确监控业务的运行状态和质量，比如请求延迟等。综上所述，造成当前困境的根本原因仍然是我们只是提供了资源级的服务，并没有很好地利用资源取决于很多业务层面的工作。回顾集群资源管理平台的历史，从最初使用物理机（-as-）到IaaS虚拟机服务，再到PaaS容器服务，其实每一步都在努力为业务做更多的事情而解放更多的生产力，提高利用效率，下一步，资源管理平台能否直接跳出资源服务层面，让业务只需要关联业务逻辑，按需付费？
答案是肯定的，它的名字并不意味着没有服务器，而是用户不需要关注服务器的存在。广义上讲，今天的SaaS、BaaS、FaaS、PaaS都可以称为。不同的是平台是自下而上控制的。威力越来越强，从左到右，平台通用性越来越好；但真正被广为人知是因为以AWS为代表的FaaS功能即服务的出现，所以目前狭义上一般指的是FaaS功能即服务。今天我们将用它来指代功能即服务。
这正是我们当前问题的答案。业务准入门槛高，用户无需担心资源问题，可以实现更快的业务上线；使用率不受控制，平台可以完全掌控资源的分配，使用率不再受制于人；碎片化 如果资源无法利用，可以使用函数级别，让业务将计算切分成更小粒度的函数。服务质量难以监控。我们需要感知业务的每一次调用和返回，了解延迟和返回结果。
所以我们在现有容器平台的基础上搭建了一个云功能平台，主要包括：
•构建功能管理模块，管理功能配置，包括元数据、代码、权限、触发方式等；
•构建函数调用模块，分发调用函数，解决负载均衡、故障恢复、扩容等问题；
•搭建多语言运行环境、代理函数网络监控请求、运行用户函数代码、监控函数运行进程、收集函数日志等；
•构建函数触发器等模块，实现事件触发自动调用云函数；
搭建一个新平台有很多考虑因素，比如如何让平台足够易用，让企业愿意尝试；如何使其足够稳定以保留业务；如何让它比容器平台更具成本效益，让企业能够看到。本文将分享真正的好处；如何实现更快、更安全、可持续发展等。
易用的关键在于让用户做更少的事情。在开发方面，云功能把业务逻辑以外的部分提炼出来，代为实现，比如网络报文收发、负载均衡、扩容缩容、故障恢复等。平台把龙画好了，只需要业务最后的润色就可以上线；在运维、托管代码包管理、服务器故障处理、服务质量监控和灾难恢复、负载均衡、扩缩容等配置方面；即使在应用程序中使用时，它也提供文件上传\删除、定时器、主题消息等事件触发的自动调用。虽然目前的一些微服务平台也在做类似的事情，但仍然以容器为维度。容器内部是平台。黑匣子；云函数参与容器内每个用户请求的调用和返回过程，可以获得更多的业务维度信息，使资源调度和质量控制更加精准。
与传统的分布式系统相比，云函数平台要想足够稳定，就需要解决函数调用流程的问题。最简单的调用流程就是从云端api进来，做分发，然后到计算节点执行。同步调用过程中，这在一劳永逸的场景下是没有问题的，因为同步调用失败时业务可以自行重试；但异步调用时不会将调用结果返回给用户，用户不会意识到请求丢失，所以需要持久化。方法保存所有异步调用，避免丢失；另外，异步调用业务无法自行重试。当平台自动重试仍然失败时，需要持久化，方便问题追踪；重试本身也需要精心设计，因为资源是调用请求到达时实时分配的。重试可能会导致后台资源加倍。在一些流式计算场景中，计算对时序要求比较严格，重试时需要阻塞整个流式计算。稳定性最常见的挑战就是热更新能力，而云功能平台天生就支持热更新，因为它可以知道业务的每一次请求和返回，并且可以控制业务请求的分发过程。热更新实际上只是被禁用。节点，等待请求结束，更新后重新启用该节点。
云功能平台比容器平台成本更低，要尽量避免闲置和无效的资源浪费。传统业务架构下，一个业务模块至少需要1个实例。如果需要容灾，至少需要2个；并且云功能平台设计为调用时实时分配资源，业务模块最多的小实例数量可以减少到0，无负载时不预留资源。当收到业务请求时实时分配资源。业务申请资源时，根据峰值指定CPU核数、内存大小、磁盘容量、网络带宽等一系列资源。参数，但大多数情况下是用不完的，所以云功能是扁平化的。平台一般只允许用户配置内存大小，因为内存是不可压缩的资源，没有内存程序就无法运行。 CPU、带宽等可压缩资源由平台根据内存大小和实际需求进行配置和动态调整。以避免业务过多申请资源造成浪费；另外，云瀚云的一个特点是支持事件触发执行，但触发器配置不当可能会导致无效循环，浪费资源。例如，上传配置文件时会执行某个函数，但函数内上传文件形成循环触发器，因此 会监控函数调用。流动，发现无效循环，避免资源浪费。
由于云函数的资源是在收到请求后实时分配和初始化的，而用户能够容忍的等待时间一般不超过3秒，所以第一次请求的冷启动时间必须足够快，并且初始化功能需要做很多工作。事情：首先申请资源，确定位置，下载镜像，下载函数代码，启动容器，执行函数之前初始化函数并返回结果。图片下载时间一般超过3秒，因此我们使用了大量的预处理、缓存和并行化方法来提高性能。比如镜像预先分发到服务器以避免实时下载，容器资源使用多级缓存来复用，小到使用指针而不是内存副本来传递参数等等。有一个小问题这里。一个用户函数使用的容器可以交给另一个用户使用吗？容器启动和代码下载过程是并行的，并且使用共享内存指针传输大函数参数。最终将冷启动时间控制在5ms，热启动时间控制在5ms以内，达到业界一流水平。
由于云功能平台的共享粒度更细，不可避免地要共享服务器核心，这将带来更大的安全挑战。因此，我们在隔离的基础上采取了一些额外的安全措施，比如将函数运行环境限制为仅限于/tmp目录。它是可写的，并通过内核功能限制敏感的系统调用，例如端口监控和端口扫描。不过，在保证安全的同时，我们也注重业务的兼容性。比如大家习惯性的使用root来运行程序。禁止root可能会给用户带来一些问题。额外的适配成本，所以我们使用 root 技术将容器内部的 root 映射到容器外部的普通用户来控制权限。此外，由于我们无法审计用户代码，因此从技术上讲，用户可以编写代码来执行任何操作，例如收集运行环境信息和窥探管理服务器的位置。为了安全起见，与开源平台相比，功能运行环境和管理环境是分离的。功能网络报文接收代理和日志收集都放在容器外部。容器内的函数运行时环境不知道任何管理节点的IP。 、端口信息和平台日志等信息。
由于业务除核心逻辑之外的所有非功能需求都是通过云功能实现的，因此必然会对云功能平台产生更多的需求。为了支持业务的可持续发展，跟上业务迭代的速度，我们也做了一些优化。例如，在过去的一年里，我们平台最常被问到的业务需求是支持各种编程语言、在运行时环境中安装各种库等，以加快迭代效率。我们细化了各种语言运行环境的公共部分，并用C语言实现，因为各种高级语言可以轻松实现对C库的直接调用，因此添加新的语言支持可以在1到2周内完成。在库更新方面，我们将所有运行时库部署到母机上，并通过目录挂载到容器中，这样库更新不需要更改运行时环境镜像。
总结一下刚才的关键设计，我们通过让用户少做事来提高易用性；精心设计异步调用和重试，提高稳定性；消除闲置和过多的应用程序以降低成本；使用缓存和并行性来提高启动速度；通过内核层技术以及管理环境和运行环境的隔离，提高安全性；通过细化公共函数并避免重新制作图像来提高迭代速度。实际效果如何？接下来，我想与大家分享一下我们目前的一些用户案例和经验教训。
目前云功能平台最大的内部用户是游戏AI的特征提取。游戏AI在整个行业还处于探索阶段。算法变化快，程序更新频繁，计算量巨大。例如，《王者荣耀》每天需要执行数亿次。视频文件的特征提取。如果基于云函数实现，AI工程师只需要编写两个函数即可。一个脚本将从视频文件中提取特征并生成 HDF5 文件。另一个函数会将HDF5文件打散并随机化，然后推送到训练平台进行训练和算法更新。这时候你只需提交一个新功能，就可以更加专注于算法研究，不再需要担心服务器管理、计算分布、扩缩容、故障恢复等问题。除了游戏AI之外，微信小程序的开发者工具也开始集成云功能，正在进行内测。欢迎大家来体验。
回顾一年多来的建设过程，主要有两个教训：
•不久前，腾讯云云功能出现安全漏洞。在云函数的上下文中，通过bash反射，可以通过尝试各种命令来获取k8s的访问地址。并且由于k8s没有配置认证，用户可以直接控制k8s来获取其他容器的内部内容。数据，造成安全风险。幸好公司安全团队发现及时，没有造成严重后果。出现这个问题的原因是我们对k8s的安全机制缺乏了解。给我们的教训是，每次引入一个开源组件，我们都需要在开放服务之前彻底了解它；
•由于云功能平台设计为24/7工作，每次升级计算节点时，都需要经过屏蔽、等待功能执行、升级、启用的过程。早年，还没有自动化。整个集群的升级花了近一周的时间。时间减缓了版本迭代过程；
同时我们认为好的体验主要有两点：
• 平台从设计之初就考虑到了平滑升级，因此一年来更换了50多个不同规模的版本，且业务从未关闭过；
•此外，我们非常重视平台公共功能的提取，比如多语言支持。 1到2周就可以开发出一种新的编程语言，这比其他平台要快得多；
在云功能平台的推广过程中，我们发现无状态微服务更容易服务于负载波动较大、对延迟不敏感的场景。但对于有状态服务，业务需要自己保存状态。负载业务无法利用按需资源获取的优势。对于延迟敏感的应用，由于多了一层中间函数的分布，延迟差不多5ms。对于这些场景，目前还不太适合。
但我们可以展望未来。已成为各大公有云的标配。对于公有云来说，它不仅是一种新的计算服务形态，而且是整个云平台的粘合剂，易于打包。推广其他云服务，将公有云从分散的云产品集合变成一个有机整体，成为用户的公有云后端；在开源社区，平台也在蓬勃发展，每隔一段时间就会出现值得关注和学习的新平台；虽然目前的主战场在数据中心，但随着物联网的发展，物联网边缘设备可能会成为更大的战场，因为边缘设备的计算资源管理和软件包发布更加复杂和具有挑战性，能够解决它们好的就像及时的帮助。
当武功修炼掌握了各种招数之后，就能达到无招必胜的境界。对于我们做集群资源调度的程序员来说，我们可以将资源调度做到极致，让业务根本察觉不到服务器的存在。 ，是我们的最高追求。