既然云开发是后端服务，那么不可或缺的一定是计算能力，因为计算能力是后端服务的核心。而云函数作为函数形态的容器计算服务，在云开发后端生态中发挥着不可代替的作用。
不过，当应用功能越来越强大，模块分层日渐明显时，云函数不持久服务的特性也越发明显，这一特性会限制应用的发展。而我们需要做出相应的改变，这里就要提云开发的另一个计算能力——云应用（现称云托管）。
云托管支持任意语言和框架编写的容器化应用。说白了就是把整装的后端服务打包，放置在云托管中运行，提供服务。
为了让你更好地领悟和使用云托管进行应用开发，这一讲我会通过引入生产者&消费者模型，来讲解云托管在其中发挥的作用 。
生产&消费者
目前大部分的应用开发（包括 WEB 应用）用的都是前后端分离的架构体系，也就是客户端与服务端分离，二者通过网络请求进行交互。好处是：客户端能作为一个整体，独立运行在用户的计算环境中，与用户打交道，专注于交互体验而服务端没有了构造交互页面的琐事，专心处理服务数据，更加高效。
这就好比在餐厅中，在没有前后端分离时，一个人既是服务员，也是厨师。分离之后，服务员是一个人，厨师也是一个人，服务员专注于服务客人，厨师专注于处理菜品，整体协作就靠二人的对话。
但这样一来，也就出现了服务速度的不平均。假设餐厅服务前后一体时，一个人一小时能够承担 10 位客户；在前后服务分开时，服务内容也需要分开，服务客人和处理菜品的时间会不一致，假设后端服务处理菜品速度为一小时 20 位客户，而前端服务的速度为一小时 40 位客户。这就导致每一个小时都会有 20 位客户的菜品不能得到处理，需要等待。这种情况下，需求的产生者（也就是前端服务）是生产者，处理需求的后端服务就是消费者，待处理的需求就会称为消息队列。
餐厅如果想要保持后端能够及时处理前端产生的需求，就需要增加后端的人手，使消费速度和生产速度达到平衡。如果来的人越来越多，前端服务处理不过来，客户的等待时间仍会加长，这时就要相应增加前端和后端服务的人手。
以上面对的是 WEB 网站类型的应用，但我们可能面对小程序、App、PC 端的应用。而这些应用的客户端程序被各种方式（如下载安装包，通过官方平台分发）直接存储在用户的本机中，不用前端服务进行客户端分发。
由于不用前端服务进行客户端分发，所以在描述小程序、App、PC 端这些应用时，之前的餐厅例子中服务员就不用存在了，整个例子会变为外卖餐厅，用户在使用客户端的过程中，就会向服务端发送请求。这就好比外卖餐厅持续不断地收到订单，要处理订单上的菜品就需要有多个厨师（也就是后端服务）支持。最终保持后端服务的处理速度与订单的产生速度达到平衡。如果你是老板，那就要根据外卖订单或者到店客人的数量来动态地招聘或者解聘员工，以达到最大的效益平衡。
同理，作为开发者，你也要根据访问应用用户的多少，来实时控制服务的资源，以实现最大的效益平衡。如果你不能做这些动态管控，就出现两种后果。
- 你的服务配置太小：这种情况下，服务会始终满载处理，但是除了处理中的用户之外，你不会再收到任何新增的客户。
- 你的服务配置太大：这种情况下，服务会产生太多空闲，成本会增大，一旦用户突然变少，自己的收入低于付出的成本，就会赔钱。
不管是什么情况，都是我们不想看到的。我们希望服务刚好满足处理需求，但是我们自己实现这个动态管控的系统所花费的成本很高，这时，你需要一个能帮助你的做动态管控的帮手，也就是云应用（云托管）。
云托管如何运行？
云托管内以服务进行区分，每一个服务都是一个后端处理角色（比如餐厅例子中各种类型的厨师岗位），开发者需要通过编码定义这些角色怎么工作。下面我来介绍一下服务从 0 到开始工作的具体流程，利于你之后的学习和理解。
- 开发者首先根据需求，将这一后端处理角色所需要处理的流程以及工作状态进行编码，形成一个代码包（你可以用任何主流的语言和框架来完成编码的过程）。
- 编码完成后，开发者需要定义代码包如何被启动做正确的运行，以及运行时需要的条件，将这一系列的操作步骤和需求写到清单中。
- 开发者在云托管创建一个服务，并在服务中创建一个版本，将上述代码包含清单一块打包上传。云托管会自动根据清单内容执行，并打包开发者的代码和相关资源，将其变成一个成型的包，并将这个包存到服务的仓库中。
- 云托管在第三步的服务版本中运行一个容器实例，并将仓库中打好的包放进去，启动运行，云托管服务就启动成功了。
简单概括一下这四个步骤：
- 编码开发程序；
- 构建 DockerFile 文件或者配置 cloudbase framework；
- 云托管构建镜像；
- 创建实例运行。
当服务下只有一个版本时，该版本下的实例就承担了全部服务请求。在初始状态下，版本中会有一个实例存在（作为值班实例）。如果请求数量越来越多，初始的实例无法支撑时，云托管会创建一个新的实例出来，保证请求的消费均衡。
这种情况就类似于前面的外卖餐厅，云托管的服务就是厨师角色，实例就是厨师的人数。如果此时你有新的业务变更升级，服务处理时流程也随之发生了变化，那你需要再次重复以上步骤，在统一服务下创建新的版本，此时的情况如下：
云托管对于同一服务的不同版本有一个流量分配控制，开发者可以通过变更流量分配情况，来改变版本后实例的增减。如果你需要灰度上线更新，可以设置一部分流量到版本 2 服务中，情况也随之发生变化：
此时，流量的一部分被版本 2 下面的实例消费了（上图所示为40%）。假设一个实例可以同时处理 10 个请求。那么有100个请求过来时，按照流量分配，版本 2 下应该有4个实例，版本 1 下应该有6个实例。如果用户访问增长，流量增大，那么两个版本会根据各自消费的需要，扩充相应的实例出来。
作为使用者，实例的自动扩缩全部由云托管控制，我们只需要分配流量就可以。很多情况下服务的请求是突然增长的，短时间可能来不及扩展并投入实例，那么你可以预先设置一个比例，告诉云托管，当一个实例资源占用到一定比例时，就开始扩容；如果资源使用小于这个比例，就自动缩容。如此一来，就做到了未雨绸缪，先行扩容保稳定。
当然，你也可以设置规格更强大的实例来维持大规模的服务请求，减少扩缩容的次数，提升效率。
当然，由于编码不同，使用的语言以及框架不一致，就会导致应用代码的启动速度不一样。有的应用启动速度小于 1s，有的应用启动速度在 1 分钟左右。开发者可以通过设置 initialDelaySecond 来告诉云托管的预计初始化时长。那么云托管在扩充实例时，会等待设置的这个时长之后才接入请求。从建立容器到接入请求，这个时长就被称为等待时长，云托管会不断检测请求的增常情况以及预测资源量，在加入考虑等待时长后，控制在一个时间点扩充实例容器，保证在容器准备就绪后能够正好接入超出的请求处理。
云托管有什么优势？
云托管相比于服务器来讲，最重要的就是免服务器运维。云托管不用开发者控制实例资源，减少了运维的成本，规避了运维出现的各种风险，在很大程度上节约了成本。
开发者只调配请求流量分配，就可以轻松控制实例的配置，实例数量可根据流量自动伸缩，可缩减到 0 也可实现服务常驻，不用时刻关注运行状况而手动扩缩容。
另外，云托管兼容 Knative + Kubernetes 生态标准，有良好的社区基础和完备的社区生态。可在各云厂商之间服务无缝迁移，不用担心技术锁定，进入“云原生”时代。跨平台部署和迁移的难度几乎不存在。
在计费当中，由于弹性扩缩资源，云托管保证开发者只需为实际使用的资源量买单，最小粒度可到 0.25C、0.5GiB，避免资源闲置，也不用为业务高峰提前准备过量资源。
有不少开发者目前已经使用一些容器平台（比如腾讯云 EKS、AWS-EKS），云托管虽然也是容器托管，但本身优势仍然明显。
首先，云托管相比于其他容器平台，上手难度更低，开发者不用学习相应的知识技能，也不用创建和运维集群、编写复杂的 YAML 配置文件，只需专注业务逻辑开发。
再者，除传统的上传镜像部署方式外，云托管支持直接上传代码或拉取代码库的部署，云托管提供构建服务，闭环全部操作，不用用户单独自行构建镜像。如果配合使用 CloudBase Framework 可进一步将 Dockerfile 的编写也交给系统。
对于云函数形式的后端服务有迁移成本的开发者也不用忧虑了，云托管保证了更小的迁移成本从传统服务到云开发的迁移，将运维的工作交给云开发，集中精力做业务。
结语
总的来说，开发者可以按照应用模块区分，在云托管中创建多个服务，在不同业务条件下，模块的请求量会有相应的变化，而云托管中服务的实例也会进行动态的扩缩。
在这种形态下，开发者对一个模块服务的升级改造并不会影响其他模块服务，而升级可以通过控制服务的流量分配来完成灰度过程。在过程中，服务下的每个版本根据请求量和分配比例对实例进行动态扩缩。
当服务的一个版本无请求分配时，版本下的实例自动销毁，不产生费用。这就是云托管，开发者可以调配的均是业务相关的，运维相关的一概由云开发来处理。所以云托管降低了使用者的技术门槛，不用过高的技术积累就可以轻松使用。今天这一讲，我想强调三个重点内容：
- 云托管以服务进行划分，针对每个服务可以存在多个版本，每个版本下会有动态伸缩的运行实例；
- 你只需要规定服务每个版本的流量分配，云托管将会自动根据请求量部署够用的实例，不用人工干预；
- 你可以通过上传镜像，上传本地代码，仓库拉取等多种方式部署你的应用程序，也可以通过framework来灵活部署。
我希望你能通过今天的内容理解云托管的形态和使用方法，以及其便捷的操作和配置过程。我给你留的作业是：在云开发控制台中开通云托管，并使用官方 DEMO 体验部署操作流程。
