英语网站开发的背景,台州网站平面设计,企业网络贷款平台,网站推广策划方案书简介#xff1a; 函数计算可观测性经历了 1.0 - 2.0 的发展#xff0c;从闭门造车的可观测发展成开源的可观测#xff0c;从平台的可观测发展为开发者的可观测#xff0c;从FaaS Only 的可观测演进成了云原生的可观测。 作者#xff1a;夏莞 背景 Serverless 将成为…简介 函数计算可观测性经历了 1.0 - 2.0 的发展从闭门造车的可观测发展成开源的可观测从平台的可观测发展为开发者的可观测从FaaS Only 的可观测演进成了云原生的可观测。 作者夏莞 背景 Serverless 将成为下一个十年云的默认编程范式 随着 Serverless 概念的进一步普及开发者逐渐从观望状态进入尝试阶段越来越多的企业用户开始将业务迁移到 Serverless 平台。在阿里集团内部淘宝、飞猪、闲鱼、高德、语雀等核心功能稳步落地在阿里集团外部新浪微博、世纪联华、石墨文档、TPLink、蓝墨云班课等各行各业的企业也纷纷解锁 Serverless 使用的不同场景。Serverless 正在成为成为下一个十年云的默认编程范式。 更多案例请参考 函数计算用户案例 Serverless 降本增效免运维的特性为开发者带来了实打实的好处基于函数计算的 Serverless 方案为蓝墨节省了 60% 左右的 IT 成本为石墨文档节约了 58% 的服务器成本提升码隆科技的开发效率实现两周内功能上线平稳支撑负载的波峰波谷相差 5 倍以上的新浪微博每天轻松处理数十亿请求。 广告时间欢迎加入云原生Serverless 团队函数计算Serverless工作流Serverless应用引擎以公共云、集团、开源社区三位一体的方式打造业界领先的Serverless 产品体系。职位需求见 JD招聘长期有效有兴趣的同学可以联系本文作者或 Chang, Shuai(shuai.chang)。 可观测性成为 Serverless 发展的绊脚石 随着 Serverless 的深入使用开发者逐渐发现 Serverless 架构下的问题定位比传统应用更加困难主要原因如下 组件分布化Serverless 架构的应用往往粘合多个云服务请求需要流经多款云产品一旦端到端延时变长或表现不符合预期问题定位十分复杂需要依次去各个产品侧逐步排查。调度黑盒化Serverless 平台承担着请求调度、资源分配的责任实时弹性扩容会带来不可避免的冷启动Serverless 的资源伸缩是无需开发者参与也不受开发者控制的。冷启动会影响端对端延时这次请求有没有遇到冷启动冷启动的时间都消耗在哪些步骤有没有可优化的空间都是开发者急于知道的问题。执行环境黑盒化开发者习惯于在自己的机器上执行自己的代码出了问题登录机器查看异常现场查看执行环境的 CPU/内存/IO 情况。面对 Serverless 应用机器不是自己的登也登不上看也看不了开发者眼前一片漆黑。产品非标化在 Serverless 场景下开发者无法控制执行环境无法安装探针无法使用开源的三方监控平台调查问题的方式不得不发生改变传统的调查问题经验无法施展非常不顺手。函数计算是阿里云的 Serverless 产品在过去的一年函数计算团队为了更好地回答以上问题做了很多努力。 本文主要介绍函数计算在可观测性上的尝试与函数计算可观测性现状。 Serverless 下可观测性 可观测性是通过外部表现判断系统内部状态的衡量方式。 --维基百科 在应用开发中可观测性帮助我们判断系统内部的健康状况。在系统平稳运行时帮助我们评估风险预测可能出现的问题。当系统出现问题时帮助我们快速定位问题及时止损。 一个好的可观测性系统要帮助用户尽可能快地发现问题、定位问题并且端到端地解决问题。 在 Serverless 这种免运维的平台体系中可观测性是开发者的眼睛没有可观测何谈高可用 可观测性 1.0 图1可观测性基础 可观测性主要包含三个部分日志、指标、链路追踪。 和几乎所有 FaaS 产品一样函数计算FC在商业化之初就支持了函数日志和指标的查看。 函数日志 用户在 FC 配置 SLS 的 Project 和 LogstoreFC将函数打到 stdout 的日志转存到用户的 Logstore中。用户可以通过 SLS 控制台查看函数日志并借助 SLS 的能力对日志进行分析和聚合。 基本指标 FC 将指标日志推送到云监控通过云监控提供函数调用数/错误数/函数延时/函数内存等基本指标。 函数日志和基本指标是应用的听诊器虽然朴素简陋却也能帮助用户发现问题定位问题。 即使出现开发者无法排查的问题在用户量不那么大的年代开发同学可以为用户提供贴身服务结合后台日志帮用户定位问题。 函数日志和指标使用详细信息请参考 配置并查看函数日志监控指标。 可观测性 2.0 -- 云原生的可观测 随着 Serverless 的发展越来越多的场景在 Serverless 落地使用规模越来越大产品架构越来越复杂应用听诊器的可观测性 1.0 已经不能满足各行各业开发者的监控诉求。这种近乎黑盒的执行环境给开发者带来了强烈的距离感与不信任感。 开发者需要掌控自己的应用想要知道每一个请求在函数计算经历了怎样的历程想要看看端到端的延时长是不是因为冷启动想要查看函数实例的执行环境想要在请求出现异常时第一时间定位问题想要复用熟悉的开源观测平台。 在面对这些需求时团队内部也经过了长时间的激烈讨论一部分同学认为我们应该支持这些需求另一部分同学则认为这些需求某种程度上与 Serverless 本质相违背Serverless 就是要屏蔽底层的计算资源用户不需要关心底层计算资源的情况。另一方面我们暴露了这些指标有什么用呢用户就算看到了有冷启动看到了系统时间消耗看到了底层实例的 CPU用户又不能有任何实质操作这些指标真的意义吗这两种观点争论不休而我是坚定的反对者。 后来团队搬到了 EFC每天都要等待着那不知什么时候会来的电梯输入你要去的楼层去对应的电梯安静地等待看不到电梯目前所在楼层。电梯告诉我们你就在这里等哦我肯定会来的但是我现在到了哪层我什么时候下来你大可不必知道你知道了也没用我的这个调度肯定是最优的你要相信专业电梯的调度算法。可是我怎么能相信你呢 于开发者而言函数计算也是那不知什么时候会来的电梯吧我们和开发者说您的请求我们一定会稳定执行的您的执行环境一定很健康请求过多我们会自动扩容的但是当前实例的监控指标我什么时候扩容您大可不必知道我们的调度肯定是最优的您要相信专业研发团队的调度算法。同样的开发者又怎么相信我们呢 Serverless 的可观测性不单单要帮助开发者排查问题也要逐步揭开 Serverless 那层神秘的面纱赢取开发者对 Serverless 的信任。 于是有了函数计算可观测性 2.0我们希望可观测性 2.0 可以成为应用的心电图。 图2函数计算可观测性现状 为了回答请求在函数计算的生命历程串联分布式系统的上下游服务拥抱开源可观测能力我们集成了 OpenTracing支持链路追踪。为了暴露系统状态提供应用级别监控我们集成了 ARMS(Java)内置了 APM 能力。为了加快端到端定位问题的速度我们支持了请求级别指标FC Insights发布了监控中心问题发现/调查一站式解决。为了兼容开发者已有的用户体验我们拥抱开源集成 OpenTracing支持 Grafana Dashboard我们支持三方监控平台实现代码几乎零改造接入APM 监控系统。为了兼容传统开发者的可观测体验支持探针安装我们拓展了编程模型支持函数LifeCycle为集成三方监控提供可能。图3函数计算兼容开源可观测能力 相比于自己发明创造 FaaS 可观测性新体验函数计算兼容开源可观测能力集成 Jaeger支持 Grafana 大盘也支持以非常小的改动接入 New Relic 等优秀三方监控平台。函数计算是首家兼容开源、拥抱容器生态和云原生开发者的 FaaS 提供商可观测体验的平滑迁移支撑应用在容器和 Serverless 平台的平滑迁移。 集成OpenTracing支持链路追踪 FC 与链路追踪服务集成为开发者提供了完整的调用链路还原、调用量统计、链路拓扑分析、冷启动定位等工具。帮助开发者快速分析和诊断分布式架构下的性能瓶颈。 FC 链路追踪具有以下特点 • 拥抱开源完全兼容OpenTracing 协议没有附加学习成本 • 主动记录上报请求在函数计算中消耗的端对端时间 • 调度透明暴露代码准备时间与实例启动时间是首个暴露冷启动延时与具体时间消耗的 FaaS 产品 • 承上启下串起上下游应用既可以通过span context 与上游应用连接又将 span context 传入函数连接下游服务。 图4链路追踪链路示例 图5链路追踪综合能力详情 集成 ARMS内置 APM 能力 FC 无缝对接 ARMS 应用监控开发者只需为函数新增一个环境变量即可开启 APM 应用监控功能ARMS 探针以对代码无入侵的方式监测应用性能提供应用级别的可观测性包括函数实例的 CPU、内存指标、Java 虚拟机指标、代码 Profiling 信息、SQL 查询等函数实例的指标。 图6ARMS 示例 发布监控中心(Insights)问题发现调查一站式解决 FC 支持请求级别指标通过为用户每个请求多打一条指标日志的方式为请求装上摄像头。通过请求级别指标用户可以清楚地看到请求的执行时间、使用内存是否异常、错误类型、冷启动情况traceID 等信息。也可以基于请求级别指标串联起所有的可观测性能力。 监控中心则是 FC 可观测性能力的集大成者监控中心集成了 Metrics、Logs、Tracing的能力可以在一个站点完成预览指标、查看日志、分析链路的能力争取做到问题发现调查一站式解决。 监控中心具有如下特点 多维度支持 Region、Service、Function、Qualifier、Request 多维度的指标展示各个维度下的调用数和错误分布多层次集成 Metrics、Logs、Tracing 的能力全方位多层次对应用进行监控全链路结合指标、日志、链路等信息层层递进抽丝剥茧真正做到可以在一个站点发现问题定位问题并解决问题。图7监控中心示例 扩展编程模型集成三方监控 函数实例的生命周期完全由平台控制用户无法控制实例的启动与回收也不感知实例的暂停与重启这就使得在函数计算上执行除主线程外的背景线程格外困难。监控探针就是诸多重要的背景线程的一种。 FC 扩展了编程模型发布 Runtime LifeCycle 功能Runtime LifeCycle 会监听函数实例生命周期事件允许函数实例在暂停和回收前回调用户的函数逻辑。这一功能的发布使 FC 集成三方 APM 监控成为可能。用户只需要在实例暂停前将采集的指标发出去、在实例回收前将内存中的数据清理掉就可以在 APM 平台上实时地查看监控指标了。 图8Tingyun APM 示例 图9NewRelic APM 示例 总结 函数计算可观测性经历了 1.0 - 2.0 的发展从闭门造车的可观测发展成开源的可观测从平台的可观测发展为开发者的可观测从FaaS Only 的可观测演进成了云原生的可观测。 作为首家兼容开源可观测、拥抱容器生态和云原生开发者的 FaaS 提供商函数计算也将更有实力实现开发者业务的平滑迁移。 未来规划 FC 可观测性相比于一年前前进了一小步从黑盒的可观测演进成了微弱烛光的可观测但距离 “Serverless 应用白盒化” 的目标还有着很长的路要走。我们希望能够兼容开发者的监控体验支撑着用户平滑地放心地将业务迁到 Serverless 上来。 接下来我们会继续投入做以下事情 完善监控中心支持报警配置预警异常指标提供实例级别指标做到代码问题可定位环境现场可追溯集成开源项目集成 PrometheusOpentelemetry配置 Grafana 大盘丰富指标内容目前还有一些指标是不好透出的没有暴露的我们要逐步都暴露出来 希望函数计算的可观测性成为一盏灯照亮每一个 Serverless 应用。 原文链接 本文为阿里云原创内容未经允许不得转载。