共计 5775 个字符，预计需要花费 15 分钟才能阅读完成。
简介： 明天咱们推出了一个新的栏目「云原生 Talk」，聚焦云原生时代下，企业数字化转型的门路和实际办法。站在 2020 年这个节点，有太多企业数字化转型的故事值得被记录，无论是互联网与科技企业，还是（新）批发、芯片、电子资料、社交资讯、房地产、新能源、在线教育、汽车与出行…… 预感将来的最好形式就是发明将来，用「云原生 Talk」记录云原生时代下每个造梦者的故事。
造梦者 | 不瞋，阿里云 Serverless 负责人
“ 唯有超过，能力让咱们走上来。”
这是不瞋在阿里的第十年。从 2010 年退出阿里云，不瞋参加了阿里云飞天分布式系统的研发，历任批量计算的架构师、表格存储（NoSQL）研发经理，深度参加了阿里云零碎研发和产品迭代的全过程。2016 年不瞋成为阿里云函数计算产品研发负责人，致力于构建下一代弹性、高可用的无服务器计算平台。
无服务器（Serverless）是不瞋下一个十年要攻克的技术难题。在这波 Serverless 浪潮里，阿里云始终走在最后面，无论是技术还是产品，在国内的丰盛度都是第一。“从不敢漫不经心，Serverless 在国内还处于晚期阶段，只有把技术和产品打磨成熟，让用户体验做到更好，这一战才算胜利。”
咱们对不瞋做了一个简略的采访，针对大家比较关心的 Serverless 倒退、技术难点以及落地状况，听听他的想法。
承受还是张望？
云计算将来肯定会成为整个社会和商业的基础设施，届时应用云计算就应该像当初咱们应用水电煤一样简略，不须要理解水从哪里来、怎么过滤、怎么铺设管道等一系列问题，只须要关上水龙头接一杯水而已。而 Serverless 的概念正好能够帮忙云计算朝这个方向往前走一步，它提倡的是人们不须要关怀应用逻辑以外的服务相干的事件，包含治理、配置、运维等，用多少就付多少。
从这个角度来看，Serverless 是真正让云计算变成社会商业基础设施的一个实现门路，也更靠近当初业内提倡的云原生的形式，因而人们在应用云计算的过程中天然就应该依照 Serverless 的形式来应用。
国外的开发者在 Serverless 畛域的心智显著比国内开发者建设的更好。因为国外很多公司一开始就是基于 Lambda 生态来守业的，而国内一些大企业曾经陆续开始应用 Serverless 的工具和产品，还有很大一部分企业处于张望状态。
一个新产品的呈现也是要有一个适应期的，所以在 Serverless 这样一系列产品呈现之后，用户对于是否应用、是否迁徙、如何迁徙是有很多顾虑的。常常会有企业征询对于函数计算的安全性如何保障，函数计算的稳定性如何保障，以及传统我的项目迁徙到 Serverless 架构是否有比拟大的革新老本和革新危险等。这些顾虑很失常，然而我置信，随着 Serverless 的倒退，FaaS 定义的越发宽泛，工具链建设的越发残缺，这些问题都会逐步被解决。实践上，技术能解决的问题，都不算问题。
没有规模，不要自建 Serverless
Serverless 带来的极致弹性体验、老本节约、开发效率晋升等，都是十分具备吸引力的。传统业务在开发上线的过程中，须要团队单干，每个人开发一部分，合并代码，开发联调，而后进行资源评估，测试环境搭建、线上环境搭建、测试上线、运维。然而在 Serverless 时代下，开发者只须要开发本人那局部性能 / 函数，而后部署到测试环境、线上环境即可，前期很大一部分运维工作都不必思考和放心。
能够毫不夸大的说，如果企业本人通过云主机搭建的数据库服务，个别状况下可用性不如云厂商提供的数据库服务，此外，API 网关、数据存储服务等也是云厂商提供的产品性能更好，也更安全可靠。
小企业最好不要本人去建设 Serverless。因为 Serverless 的外围因素是按量应用，这就意味着如果明天的量很小，你就用很少的资源；如果明天的量很大，就须要调动更多的资源。“双十一”的时候，流量都是亿的量级，如果你的企业外部没有按亿级做单位的这种流量的机器资源，你怎么去调度这些资源给别人应用呢？ 没方法实现按量调度，就别提 Serverless 了。那些不具备资源规模化的企业不倡议去自建 Serverless 能力，然而能够通过应用私有云的产品来实际 Serverless。
当下，各大厂商都看准了 Serverless 是将来，就算它不是云计算的终态，也是通往终态的一个路径，一方面是因为 Serverless 能够解决很多理论问题，更“像”或者说更“贴近”真正的云计算；另一方面，大家都不想在云计算倒退的浪潮中落伍。所以，Serverless 成了必争之地。
对于 Serverless 能力的竞争次要有三局部：
一是性能 ，包含平安、稳固、弹性等在内，性能这部分如果做不好，我感觉不用说做不做 Serverless，就算云计算也别做了，因为性能是 Serverless 的外围能力，所有都建设在平安、稳固、性能之上。
二是性能 ，想要把 Serverless 做好，性能是不可短少的。因为 Serverless 不仅仅是 FaaS，就算是 FaaS 也不仅仅是在线运行，还包含很多货色，如 BaaS、触发器、日志、监控、告警等。只有在性能上满足开发者的诉求，开发者才有可能违心应用。
最初是体验 ，Serverless 的体验太重要了，体验包含方方面面，如性能的易用性、稳定性、安全性、产品的灵活性、工具链的完整性等。除了后面说的三点，我感觉社区、生态、凋谢等，也十分重要。
阿里云作为国内第一批推出 Serverless 平台的私有云厂商，其 FaaS 平台产品被称为函数计算。从事件触发、反对语言以及用户体验等方面考量，函数计算有很多数据值得关注：
事件触发： 阿里云函数计算能够被阿里云上的服务事件触发，例如阿里云对象存储（OSS）、日志服务（SLS）、音讯服务（MNS）、表格存储（OTS）、API 网关、CDN 等，其个性在于独特的 Callback 机制大大减少开发者对于异步模型的架构和代码老本；
反对语言： 阿里云函数计算目前反对支流开发语言如 Node.js、Java、Python，并通过 Custom Runtime 反对 Go、C/C+、Ruby、Lua 语言等；
用户体验： 阿里云函数计算提供了基于 Web 的控制台和 SDK；用户能够通过 Web 控制台治理函数利用，也能够通过交互式的命令行来操作；
服务模式： 函数能够被服务和利用治理，单个函数实例能够并行执行多个申请，无效节俭计算资源老本。
辣手的难题
Serverless 的痛点很辣手，例如传统我的项目如何疾速迁徙到 Serverless，如何平滑过渡，如何 Serverless 化，Serverless 架构下如何进行更优的调试，如何更好的节约老本等，每一个都是难题。我的共事许晓斌在《喧闹的背地：Serverless 的概念及挑战》一文中曾提到落地 Serverless 面临的挑战：
在支流的场景大规模的落地 Serverless，并不是一件容易的事件，面临的挑战有很多，上面我具体分析一下这些挑战：
挑战一：业务轻量化艰难
要实现彻底的主动弹性，按理论应用资源付费，就意味着平台须要可能在秒级甚至毫秒级别扩容出业务实例。这对基础设施是一个挑战，对业务，尤其是比拟宏大的业务利用来说，更提出了很高的要求。如果一个利用的散发和启动须要十分钟，那么主动弹性的响应能力就根本无奈跟上业务流量的变动了……
挑战二：基础设施响应要求极高
一旦 Serverless 的利用或者函数的实例可能实现秒级，甚至毫秒级扩容，相干基础设施就很快会面临微小的压力。最常见的基础设施就是服务发现和日志监控零碎，本来整个集群实例的变动频率可能是每小时几次，当初这个频率变成了每秒几次；此外，如果这些零碎的响应能力跟不上实例变动的速度，那么整个体验也就大打折扣了。
挑战三：业务过程生命周期与容器不统一
Serverless 平台依赖标准化的利用生命周期，能力实现齐全主动的容器腾挪，利用自愈等个性。而在基于规范容器及 Kubernetes 的体系下，平台能管制的生命周期就是容器的生命周期。因而就须要业务做到业务过程的生命周期和容器的生命周期保持一致，具体包含启动、进行、以及 readiness probe 和 liveness probe 的标准等等……
挑战四：可观测能力需欠缺
在 Serverful 的模式下，如果生产环境呈现任何问题，服务器是不会隐没的，用户会很天然的想到登陆到服务器下来。到了 Serverless 模式下，用户不须要关怀服务器了，也就是说默认状况下是看不到服务器了，那么这个时候如果零碎出现异常了，而且平台无奈实现自愈怎么办呢？……当围绕 Serverless 模式的全面可观测能力有余的时候，用户必然不会对此感到释怀。
挑战五：研发运维心智须要扭转
简直所有的研发，在职业生涯中第一次部署本人的应用程序的时候，都是面向一台服务器的，或者说是面向一个 IP 的，这是一种十分弱小的习惯。在 Serverless 逐步落地的过程中，研发须要转换一些思维的模式，逐渐地去适应“IP 随时可能会发生变化”这样一种心智，转而更多的从服务版本，以及从流量的视角去运维本人的零碎。
打个比喻，Serverless 目前确切来说曾经有了一个状态，也就是有一个框架，然而这个框架里还有很多格子（问题）没有被填满（解决），这也是大家明天对是不是该用 Serverless 存在疑难的中央，起因之一是还没有看到足够多的胜利案例。 但事实上，阿里在 2019 年双十一就曾经成功实践了 Serverless。不仅如此，阿里云还带动了一批企业应用函数计算产品，从而节俭了大量的 IT 老本。
“ 成为用户须要的 Serverless”
函数计算有几个十分典型的利用场景，比方 Web 利用、AI 推理、音视频解决、图文解决、实时文件解决、实时流解决等，目前函数计算领有大量的客户群体，如石墨文档、芒果 TV、新浪微博、码隆科技等。
以微博为例，函数计算均匀每天承载微博几十亿次申请，其毫秒级伸缩计算资源可能确保在热点事件产生时，利用仍能保障稳固的延时，用户体验齐全不受拜访次数的影响。通过函数计算运行图片解决服务，微博实现了继续的老本节俭，再也不须要为平滑解决业务顶峰带来的流量激增而提前预留大量闲置机器资源，同时因为不须要保护简单的机器状态，工程师能够集中精力与产品团队单干减少业务价值，而不是花工夫治理基础设施。
不仅像新浪这样的晚期互联网企业曾经落地 Serverless，一些新兴的守业公司也正在退出 Serverless 营垒。
蓝墨是一家由美国留学生回国守业的高科技公司，专一于挪动互联时代数字出版和挪动学习畛域的新技术钻研及平台经营。随着在线教育迎来需要暴发，蓝墨加大了整合业界优质课程资源的力度，一直拓展本身的业务边界，在博得时机的同时，技术团队也面临了前所未有的挑战。
视频解决相干业务是蓝墨技术团队遇到的最辣手的问题之一。蓝墨每天都要解决大量视频教材资源，波及到视频剪辑、切分、组合、转码、分辨率调整、客户端适配等一系列简单的技术工作。在前几年的技术实际中，蓝墨技术团队通过 FFmpeg 等技术曾经建设起一整套自主可控视频解决机制，撑持了业务的疾速倒退。但往年的业务增长速度是蓝墨的工程师们始料未及的，高峰期数十倍于今年的视频解决需要让现有的架构不堪重负，重大影响了用户体验。
蓝墨当初的外围诉求概括有三个：节省成本、极致弹性、免运维，而这些恰好是 Serverless 最善于解决的问题。 通过对国内云厂商提供的 Serverless 服务的多方面调研后，蓝墨技术团队统一认为在视频解决畛域阿里云函数计算是最适宜他们的计划。
因为 FC 齐全兼容现有的代码逻辑，也可能反对各类支流的开发语言，所以蓝墨技术团队能够把代码逻辑以近乎无缝连接的形式从原有的架构迁徙到 FC 上，并且老本极低。通过对接 OSS 触发器，只有 OSS 上有新的视频源文件上传，就能主动拉起函数计算实例，开启一次视频解决业务的生命周期。
通过整合 Serverless 工作流，还能对分布式工作进行对立编排，实现对于大文件切片后进行并行处理并最终合并的简单操作，可能在短时间内迅速调集上万个实例的计算资源，实现视频解决工作的疾速执行；
另一方面，相比于传统的形式，基于函数计算 FC 的 Serverless 计划在视频解决场景下，能够帮忙蓝墨节俭了 60% 左右的 IT 老本投入。
下一个十年的主战场
现实中的 Serverless，应该是：更欠缺的产品状态，更极致的弹性能力，更好用的工具链，更节约的老本，更高效的开发效率，更便捷疾速的迁徙速度，更简便弱小的上云体验。要做到能让开发者以一种形式专一于业务代码的开发，无需关注运行平台的差异性，一处编写能够处处运行，开发者只有把握一种形式就能够在不同业务之间没有学习老本地切换。
站在开发者的视角，Serverless 的整个研发模型对研发体系也带来了挑战。对于前端来说，Serverless 不仅补足了前端工程师现有的能力，还可能使整个前端行业的定位发生变化。原来常常有人会认为前端的工作很简略，面向 UI 做好开发就行，剩下的工作能够交给后端。然而前端和 Serverless 联合之后，大家对前端的诉求就不仅仅是开发一个页面了，而是要能交付整个利用的开发。
然而相应来讲，后端同学可能第一反馈就是，那这是不是把我反动了？我就不须要干活了？其实不是这样的。Serverless 研发模式的演进有助于帮忙他们往更底层演进，让他们聚焦于真正须要做技术钻研的局部。比方，这些数据的能力、服务的能力，怎么做得更好、更扎实，这是咱们冀望看到的。
阿里云正在通过工具链、社区以及产品能力的联合，打一张十分乏味且会对 Serverless 的整体倒退十分无利的牌。阿里云 Serverless 的指标是成为“大家须要的 Serverless”，这是与其余云厂商截然不同的中央。只有将用户需要放在首位的 Serverless 厂商，能力将 Serverless 产品做好。
将来，Serverless 将无处不在，任何足够简单的技术计划都可能被实现为全托管、Serverless 化的后端服务。不只是云产品，也包含来自合作伙伴和三方的服务，云及其生态的能力将通过 API + Serverless 来体现。事实上，对于任何以 API 作为性能透出形式的平台型产品或组织，如钉钉、滴滴、微信等，Serverless 都将是其平台策略中最重要的局部。
