函数管理一般开源引擎都会自带部分的函数管理能力，比如通过 CLI 的方式来对函数进行 CRUD，也有一些引擎框架也集成了部分的 Console 操作能力。但不管是可视化界面还是 CLI 的操作性，都达不到一个生产级别的要求。从函数自身管理角度看，需要集成函数的创建、配置、部署发布、测试、删除、上下线功能，并且支持底层资源规格的选取。从函数代码开发角度看，需要提供多种函数语言的开发（如 Java、Python、Node.js、Golang 等），区别于函数计算引擎自带的模板和函数语言支持，平台更需要易用性，比如代码包的上传部署、持久化存储以及常用触发器的适配集成等等。除此之外，还有最容易忽视的一点，那就是由于企业操作系统的不同，我们在制作函数计算基础镜像的时候，也得考虑不同操作系统版本不一致的问题。平台管控这部分的功能包括了用户的隔离、鉴权验证、用户角色、权限管理。这几大功能都是跟安全分不开的。我们一个一个来说。用户隔离：不仅包括了函数实体管控上的命名空间、并发度设置和持久化存储的隔离，还包括运行容器的隔离；而容器方面，你需要考虑追加一层安全容器或者基于 Node 节点来分配，这两种模式，我在扩缩容这节课对比过，可以复习一下，加深记忆。鉴权验证：通常和企业的公共 IAM 系统对接，但如果从高可用角度出发，你可以设计两套系统，一套企业 IAM 系统正常访问模式，一套是本地系统的 IAM 应急模式。用户角色和权限管理：目前主流的权限管理系统的设计大都基于 RBAC 模型或者是 RBAC 的变形，可以复用你之前设计微服务系统的经验。资源控制这个功能也可以放到平台管控里面，单独讨论是为了强调平台的另一个重要特性：计量计费。针对公有云和私有云，不同的特点在于公有云面向的是外部的众多客户，云厂商以营收为主，不仅计量还需要计费，那作为 Serverless 平台就需要对接企业的计费系统。而对于私有云来说，更多的是企业内部使用，计量的重要性更多一些，计费并不是一个非常急迫的功能。第二个特性在于对资源的使用限制。比如对实例的内存、CPU、GPU 的使用，在单个地域的最大使用量，都是平台需要考虑的点。开发工具链一套好的开发工具，不仅可以使得开发调试部署更加方便，而且还更有利于老的服务迁移到新的技术平台中来，这才是设计新平台的初衷。那么除了 Serverless 引擎自带的 CLI 命令之外，我们还应该开发一套满足自身企业的 CLI 命令工具应对通用的开发，WebIDE 工具应对在线快速开发，IDE 集成插件应对习惯于类似 VSCode 的开发人员。高可用企业一般会在服务器宕机、流量异常、同步 / 异步失败、冷启动、扩缩容等方面提出要求。我们发现，除了冷启动和扩缩容属于 Serverless 的特有特征之外，其他的方面和我们在微服务治理中的知识点是一样的。总的来说，我们可以通过多 AZ 的部署、异地备份等方式来解决。通过引入服务治理中间件（如断路器、注册中心等）来解决流量的异常调度、同步请求失败等问题，但异步调用失败需要结合中间件来处理。回想一下，我们之前提到的异步调用，平台就需要延迟加载重试等策略方式来保证用户的请求可靠。至于冷启动和扩缩容，可以再回过头复习一下，相信你就有答案了。到这里，一个 Serverless 平台的主干功能其实就差不多了。但如果要用的“爽”，你还得具备可观测、编排、异步调用、层、模板、单实例多并发、预留实例的能力，这个核心能力的实现和使用，是不是都可以从前面的课程中找到答案呢？
标签：Serverless,异步,函数,平台,扩缩容,建设,CLI From： https://www.cnblogs.com/muzinan110/p/17057463.html