作者 | 朱鹏，阿里云 Serverless 技能专家
根据 ECS 的 FaaS
在阿里云传统架构，用户经过互联网进入到负载均衡体系中，再经过负载均衡把体系的恳求调度到不同的机器上去。这种传统的架构带来的问题比较多，一方面是多运用配比比例容易失衡，造成资源浪费；另一方面是镜像升级比较繁琐，整个过程的开机速度在分钟级，扩容速度也相对较慢。
架构规划
根据 ECS 的 FaaS 架构规划同样也是经过互联网进入，落到 SLB 负载均衡上。SLB 负载均衡这个体系是布置在阿里云内部的，首要用于抵挡 DDoS 进犯及恳求均衡到多台 api server 上。api server 再发起函数的 CRUD 操作，并向 Scheduler 申请容器。Scheduler 办理容器在 worker 的放置，恳求落在容器上的调度分发。用户地点 worker 便是咱们称之为的核算节点，假如需求拜访用户的 VPC 环境则在核算节点上经过 ENI 网卡打通到用户 VPC 环境。
多租户多运用布置的支撑
namespace 是 linux 前几年推出的一个资源阻隔计划，能够在内核层面做一些设置指定一部分进程固定。而且能够在 cgroup 的这一套设置计划里设置，操控资源的拜访。在 namespace、cgroup 整套计划下，衍生出了 container，社区中常用的的 Docker 计划把镜像操作体系中的很多细节包装成一个计划，用户看到了一个相对比较完好的操作体系，把用户当成一个单个用户放置在虚拟机傍边。这便是一个 vm，相当于说一台 ECS，这儿便是操作体系层面，把整个 cpu、memory、包含设备全部给屏蔽掉，在上面用 cgroup 封一层，对应的便是 Docker 容器。
运用放置策略包含用户独占虚拟机、同 VPC 独占虚拟机、资源拜访权限共同的 APP 混部在同机器。把两个不同的用户混在一个 vm 下，也便是 ECS 上面，关于用户之间来说是存在危险的。为了屏蔽掉共用 kernel 带来的危险，ECS 上的完结，咱们单个 ECS 只要一个租户，这样处理也存在一些问题，最杰出的便是关于低频调用函数资源运用率低。
快速水平弹性扩容
怎么做到水平弹性扩容？
1、经过运用容器布置，能够定制一些特别的言语、Runtime 容器、通用 LIB/SDK，并坚持社区生态共同，这样就不需求别的去下载，用户用起来也比较便利，发动速度也十分快。
2、经过设置公共容器镜像、容器镜像写入 ECS 镜像、ECS 镜像发动机器、快速弥补机器池等操控机器资源池，然后能够兼顾功能与本钱。
3、在池化的机器中池化容器创立、代码目录推迟挂载、提前发动 runtime、提前 health check，用户恳求降临的时候需求发动的时刻会变得更短。
4、经过约束用户运用大小、鼓励拆分业务逻辑、内置 SDK/Lib 来操控运用大小。
5、经过 P2P 镜像分发、避免对下载服务造成冲击、按需加载、下降下载推迟、提高发动速度等完结 P2P 镜像下载加快。
怎么提高资源运用率？
在实践研制过程中发现，相同 QPS 下单位时刻片内调度对资源量的影响十分大，咱们能够经过调度提高资源运用率。例如在下图中，咱们看到微观状态下的全体 TPS 是十分安稳的，然而事实上，咱们放大到毫秒等级会发现，其实十分不均匀！那么这种不均匀到底会给咱们带来什么影响？
假设咱们每个容器被设置的最大并发度为 1，即任意时刻一个容器只处理一个任务。下图展现了 a,b,c,d,e,f 多个恳求在不同时刻点被调度时对容器数目的影响。
能够看到场景一时，每个恳求均匀打入时，任意时刻只需求一个容器就够了，这种情况便是咱们抱负中希望能到达的；
而在场景二下，假如调度发生了滞后，或许导致前置的恳求和后来的恳求混到了一个时刻点，导致容器数目翻倍，在中心的空白处，这些容器又没有被充分利用造成了资源的浪费；
在场景三下，假如容器发动耗时较长，或者调用耗时变长，原来的 b 恳求会和 a 恳求呈现时刻上的叠加，导致又需求创立新的容器，而新的容器假如需求较长时刻的冷发动， 又会导致和 c 恳求呈现时刻上的叠加。假如调度体系完结得不够好，这样一来就或许产生雪崩效应，导致资源运用量暴涨，而实践运用率却极其低下。
经过上面几个场景，咱们能够大致为资源运用率的开支上总结一个优化方向：
- 尽或许让调度更均匀、更合理，避免扎堆唤起容器
- 尽或许下降冷发动时长，避免短期很多容器都处于创立傍边，避免无意义的体系调度开支
- 除了上述外，咱们还能够考虑高密布置，将单机的资源运用率提高上去
怎么容灾、避免雪崩？
在实践操作中发生反常的时候，用户恳求会犯错，犯错后会重启或调集新资源创立新的容器，但这样会导致整个推迟增大。用户有又会重复测验，重复测验则会导致负载升高，然后又引起反常，如此恶性循环。能够经过优化发动速度、多 Partition 容灾布置、指数退避重试、Breaker 阻断反常恳求、多可用区备灾、SLB 阻断 DDoS 进犯来避免雪崩。
根据神龙高密布置的 FaaS
为什么需求做高密布置？
一是因为弹性发动速度要求高，希望做到每秒1万个容器实例的发动、发动推迟操控在300毫秒以内、容器的存活时刻在分钟等级、资源粒度128MB；
二是本钱更低，ECS 架构因安全阻隔问题资源碎片多，突发调用推迟高，影响资源数目；
三是功能，ECS 单机缓存少、恳求毛刺率较高、恳求最大推迟高；
四是安稳性，高并发对体系冲击、频繁的创立删除资源、ECS 管控压力，爆炸半径难以操控。
高密布置架构带来的技能难题
整个高密布置架构带来的一些技能难题：
首先要面临的是怎么处理单机多租户阻隔安全危险，假如不处理这个问题那么就无法做到单机多租户的安全高密布置，这样资源运用率密度无法有用提高；
其次是怎么处理高并发下发动速度问题，假如无法做到这点，如咱们前面所提到的，冷发动时刻较长会严重加剧资源的开支，同时严重影响用户推迟体会；
再便是怎么处理单机多租户 VPC 网络打通及安全问题，这一点其实十分重要，咱们在 ECS 上建立 VPC 网络连接的速度十分慢，这也严重影响了用户冷发动及资源的运用；
别的咱们还需求考虑怎么规划高密布置下的技能容灾计划，因为任何一个核算节点的反常会带来很多用户的服务反常。
根据安全容器模板技能的优化
咱们是怎么做到根据安全容器模板技能的优化的？每个容器独占一个虚拟机沙箱，这个沙箱相当所以一个独立的虚拟机，有自己独立的 linux 内核，这样一来每个容器都是经过独立的 kernel 来做安全阻隔。神龙发动时模板化很多虚拟机用于提高发动速度，经过 virtiofs 推迟挂载用户代码目录，经过虚拟机微内核阻隔用户，能够做到单台机上每个微内核 20M 左右的内存，单机至少 2000 个容器，操控它的冷发动时刻是在 250 毫秒左右。经过调度算法，咱们能够合理地运用资源，承诺用户的资源 quota。
代码按需加载
代码按需加载是经过以下几个方面做到的：用户容器会重复运用同一份代码，单台神龙只需下载一次；脚本言语包含了很多用不到的代码；运用运用 FUSE（用户空间文件体系）来做中心层文件的实在读取；底层运用 NAS 做低推迟的数据下载；OSS（阿里云对象存储）做高带宽支撑的数据下载。注意到，咱们这儿混用了 NAS 及 OSS 一同来做代码的加载，需求注意的是，NAS 的拜访推迟相对而言更低，关于小文件的加载更快。咱们在加载初始阶段开始全量异步从 OSS 下载代码。而关于需求当即拜访的数据，咱们则从 NAS 上读取。因为咱们将整个用户代码目录做成了两个文件：一个为目录文件索引数据，另一个为文件内容数据。因为 NAS 拜访推迟低，咱们能够经过类似 GetRange 的方式去数据文件上获取小文件内容。这样就能够用最快的速度即时加载用户代码来到达快速冷发动了。
VPC 网络优化
根据网络服务网格的 VPC 网关代理是经过用户VPC网络安全阻隔。咱们曩昔在 ECS 计划上插拔 ENI 网卡十分耗时，至少需求 2~3s，P99 乃至到达 6～8s。在高密布置的神龙计划上，咱们没有必要为每个安全容器做多次网卡插拔，只需求在神龙机器上统一打通到网关代理，而用户 ENI 网卡常驻在网关集群上，这样整个网卡的加载速度会变得很快。这样关于用户体会和资源开支都会是一个巨大的优化。
资源分配率
经过混合布置多租户各类业务提高布置密度，合理配比不同资源需求的容器到一台物理神龙，然后提高资源分配率。
视频解析* *
点击此处，查看直播视频回放！
