问题一：阿里云Serverless中我这里有个服务，后端是用函数计算搭的，这个是不是一个Bug？
"阿里云Serverless中我这里有个服务，后端是用函数计算搭的，每次请求函数计算服务时，第一个请求只能拉起函数计算实例，拉起后并没有执行对应请求，需要再发一次请求才能执行。这个是不是一个Bug？
"
参考回答：
第一次冷启动，超时了，你预留，或者预热都行。
关于本问题的更多回答可点击原文查看：
https://developer.aliyun.com/ask/575927
问题二：阿里云Serverless中nas是不是不能用，kod的模板，和dz的模板？
阿里云Serverless中nas是不是不能用，kod的模板，和dz的模板？
参考回答：
这两个模板依赖nas，现在3.0的工具还不支持nas操作，所以目前迁移不了。相关同学休假了，下周我们会排期搞这个。
关于本问题的更多回答可点击原文查看：
https://developer.aliyun.com/ask/575920
问题三：阿里云serverless 是有请求才运行吗？请求结束了，进程也结束了吗？
阿里云serverless 是有请求才运行吗？请求结束了，进程也结束了吗？
参考回答：
阿里云的Serverless是一种运行架构，在这种架构下，开发者只需要关心应用的开发构建和部署，无需阿里云的Serverless是一种运行架构，在这种架构下，开发者只需要关心应用的开发构建和部署，无需关心服务器相关操作与运维，且能够按照自己实际使用的资源量付费。该架构能够让开发者更专注于业务实现从而创造更大的业务价值。
在请求结束的情况下，Serverless并不会立即停止进程。相反，Serverless应用程序是基于事件驱动的，也就是说，它们会在有请求时启动并运行，一旦请求结束，除非有新的请求触发，否则进程并不会停止。例如，长时间执行的任务通常会采用异步提交任务并返回任务标识（ID），通过轮询或回调的方式来判断任务是否结束。
此外，需要注意的是，如果函数在处理请求过程中遇到了错误或者超时等情况，Serverless运行时会自动进行重试，以确保应用的稳定性和可靠性。同时，对于后端服务，也需要进行适当的清理连接、关闭进程、上报状态等操作。
总的来说，阿里云Serverless的运行机制能够有效地帮助开发者提高研发效率，降低运维成本，并且让开发者更专注于业务实现。
关于本问题的更多回答可点击原文查看：
https://developer.aliyun.com/ask/575919
问题四：如果把阿里云上ACK下掉，全部换成 Serverless 成本大吗？
如果把阿里云上ACK下掉，全部换成 Serverless 成本大吗？主要是业务系统访问人数没有什么并发，一天就几个人操作。我们系统只有白天在用，晚上没人用的。我们这套东西完全可以用Serveless，但我光靠我一个运维能搞定吗？我们这3个运维。一个是负责项目的不太懂技术。我们两个只有我来做这个活了。
参考回答：
阿里云的Serverless产品，原名ACK Serverless，其核心是将容器的运行时阿里云的Serverless产品，原名ACK Serverless，其核心是将容器的运行时和具体的节点运行环境解耦，使得用户无需管理K8s节点和服务器，能够直接部署应用。它的计价模式是按照调用次数、函数持续时间以及资源的使用情况（如CPU核数、内存、GPU等）来计算费用。
考虑到您的业务系统只有白天在用，晚上没有人使用，且访问人数没有并发，一天只有几个人操作，Serverless确实是一个很好的选择，因为它可以按需付费，只在有请求时才计费。此外，Serverless化应用的好处还包括简化部署、无需修改代码或重新编译、保持开发和线上环境一致等。
但是，从运维的角度来看，如果您的团队中只有三个运维人员，其中一个不太懂技术，那么切换到Serverless可能会面临一些挑战。首先，您需要确保团队中的运维人员对Serverless有足够的了解和技能。其次，由于Serverless的自动扩展和管理特性，运维人员的角色可能会发生变化，他们可能需要更多地关注监控、调试和故障排除。
关于本问题的更多回答可点击原文查看：
https://developer.aliyun.com/ask/575915
问题五：ack-kubernetes-elastic-workload，ECI这个能不能重新打个包支持下arm
ack-kubernetes-elastic-workload，ECI这个能不能重新打个包支持下arm
参考回答：
ACK-Kubernetes-Elastic-Workload 是阿里云容器服务 Kubernetes 版 (ACK) 提供的一个组件，用于实现弹性伸缩。而 ECI（Elastic Container Instance）是阿里云提供的无服务器容器实例服务。如果你希望ACK-Kubernetes-Elastic-Workload支持ARM架构的ECI实例，你可以考虑以下步骤：
- 评估需求：
- 首先确认你的业务场景是否确实需要在ARM架构上运行ACK-Kubernetes-Elastic-Workload。
- 了解当前的ACK-Kubernetes-Elastic-Workload组件是否有ARM版本的支持。
- 检查兼容性：
- 确认ACK-Kubernetes-Elastic-Workload中的所有依赖项和第三方库是否都支持ARM架构。
- 如果某些依赖不支持ARM，可能需要寻找替代方案或联系相关项目的开发者请求支持。
- 重新打包：
- 如果所有的依赖都已经支持ARM，那么可以尝试将ACK-Kubernetes-Elastic-Workload重新打包为ARM架构的镜像。
- 在Dockerfile中使用
FROM arm64v8/ubuntu:latest这样的基础镜像，并确保构建过程中的所有指令都是ARM兼容的。
- 测试和验证：
- 将新打包的ACK-Kubernetes-Elastic-Workload部署到ARM架构的ECI实例上进行测试。
- 验证功能是否正常，性能是否满足要求。
- 发布和支持：
- 如果一切顺利，你可以选择发布这个新的ARM版本，或者将其提交给ACK项目团队，以便他们能够提供官方支持。
关于本问题的更多回答可点击原文查看：
