手机html网站开发工具,北京微信网站制作,网站建设征求意见稿,wordpress超强主题作者|陈仲寅#xff08;张挺#xff09; 出品|阿里巴巴新零售淘系技术部
本文是阿里巴巴前端技术专家-张挺#xff0c;在 JSConf China 「中国开发者大会」上分享的《面向传统#xff0c;Serverless 进化之路》#xff0c;主要讲述阿里集团内部逐步迁移到 Serverless 体系… 作者|陈仲寅张挺 出品|阿里巴巴新零售淘系技术部
本文是阿里巴巴前端技术专家-张挺在 JSConf China 「中国开发者大会」上分享的《面向传统Serverless 进化之路》主要讲述阿里集团内部逐步迁移到 Serverless 体系的过程以及思考。
背景
自 GMTC 以来国内各个公司在 Serverless 投入都有所变化腾讯和阿里云都铆足了劲在上面发力提出了各自的解决方案腾讯推出了 Serverless 2.0以及几天前阿里云推出的预留模式都是对 Serverless 越来越重视的表现。
本文主要介绍两部分第一是阿里在近期做的前端研发升级为拓展前端的边界和职能尝试做了一次和 Serverless 结合第二是在这其中我们尝试对现有的体系做了思考希望能将传统应用快速迁移到 Serverless 体系享受到 Serverless 红利。
现状
阿里的 Node.js 应用非常多1600 的数量让维护和治理都变的很麻烦每一次升级都要推行很久这不管对框架开发还是平台治理都是不利的。 很多 Node.js 应用都是 BFF 应用内部平台等这些应用常年大多都处在负载低10%以下没有流量的状态而且维护者大多处在离职或者不积极的状态一方面造成了资源浪费另一方面也给治理造成了困难。 其次在集团开发传统应用需要申请整个研发流程比较长需要业务了解预算和资源牵扯到很多细节。 为此我们开始了 前端研发升级 这个大项目。
整个前端研发模式升级的目的有两个一是为了“前端赋能”二是为了“前端提效”。
所谓的“前端赋能”是因为我们希望前端能够打破现有的技术壁垒朝着更底层面向数据的地方去深入探索在这之中可以从面向 UI视图本身变的更加了解业务从更面全面的视角来理解现有的体系。 而“前端提效”则是希望让 Serverless用更轻量化的方式进行业务研发降低整个前端参与业务交付的门槛同时在开发期间也能减少人力总成本让前端减负业务小步快跑成为可能。 但是阿里的 Serverless 之路非常困难不像外界已经有成熟的体系目前一些原因无法使用公有云上开放的产品阿里云也无法直接对内部提供服务同时内部的中间件在外部都没有都需要跨团队来重新建设。
Node.js 基础团队的使命就是为集团 Node.js 生态提供各种基础能力包括但不限于框架中间件包等而在 Serverless 体系中我们要负责框架、工具链、运行时、发布系统同时也需要和周边的网关监控系统等对接。 收益
去年 10 月开始我们开始进行调研 Serverless 以及了解相关知识到现在为止也已经取得了一定的阶段性成果将淘宝和飞猪两道 BU 的导购链路整个迁移到了 Serverless 体系并且承载了导购链路的千万级流量。 同时内部系统也进行了一定程度的 Serverless 升级尝试不管是重写还是传统应用迁移我们都有了一定的沉淀。
我们最初的目的是希望能降低成本按照网上 Serverless 的降低成本率能达到 90% 以上不过导购业务比较特殊流量比较大不像那些需要弹性的应用根据我们的测算单进程下函数的性能非常不错但是由于大促要提前预留一些资源整体机器成本只降低到了平时的 70%而在非大促期间不需要预留这些资源就能更低降到 40% 以下。 现在都说 DevOPS而 Serverless 最大的好处是减少运维减少固定服务器资源不需要用户关心调度等同时也简化了开发的代码专注了逻辑晚上睡觉会更加的放心不再担心机器容量不足而报警。 另一边对于我们应用治理的人来说之前会考虑各种版本碎片化的问题node 的多版本框架的多版本以及启动脚本、依赖等等问题而使用 Serverless 之后我们将这些都固化了用户也不关心这些一切都变的简单了我们也只需要治理运行时一个版本即可。 在业务前端方面带来的是挑战和机遇一方面前端的工作量增大了能干的事情也变多了成了一职多能的多面手也更了解业务了另一方面传统的后端可以从和前端沟通中解放出来更专注于提供服务。前端从传统的面向接口编程变成了面向服务编程由于集团内都是 RPC 服务在 RPC 发布时会有固定的定义和文档在调用时有工具辅助生产代码大大简化了调用链路。 在流程方面原来需要在各个环境准备和调研从一开始申请应用申请预算申请环境开始需要了解各个方面的知识和不同部门的人打交道流程审批也很长而现在只需要在我们的统一研发平台上直接申请函数组替代了原本的复杂流程也提升了整个开发体验。 同时在编码中也不再考虑路由MVC 的事情这些在网关层配置就好编写代码时会更关注逻辑和之前的构建发布不同的是现在增加了云端集成测试的步骤由于函数和前端代码一样是分版本的也不担心修改到线上的正常服务在测试完毕后只需要将旧函数的 tag 指向新函数即可这就完成了整个切流的过程而一旦碰到问题把 tag 切回去就行。 这就是我们前端研发模式升级的思考和收益带给我们的不仅仅是变化更多的是流程、思维的革新。
思考
在研发模式升级过程中我们针对现有的导购业务进行了重构可以说是使用了 Serverless 的方式进行了重写而有一些老的应用如果整体进行改造这个成本会非常之大。
这个时候开发者就会有很常见的一个疑问我原来的应用怎么迁移到 Serverless 体系
而我们的回答是两种
使用 FaaS Baas 的方式进行重构代码更精简就是需要改造成本把整个传统应用作为一个函数虽然不够优雅但是能解决迁移的问题把整个应用迁移到函数会有一些限制会对代码结构和模型做一些微调以符合整个 Serverless 的结构毕竟新的体系和传统的代码模型是有所区别的。
阿里集团采用的是 FaaS BaaS 的实现方式而 FaaS 的整体概念和传统的应用不太一样。 在概念上Serverless 比 FaaS 的外延要广FaaS 属于 Serverless 的其中一种实现方式主要解决的是用户自定义的代码逻辑如何做到 Serverless也可以叫做 Serverless Compute同时它也是事件驱动架构的一种。
而 CNCF Serverless 白皮书中也说到Serverless Compute 是一种粒度更细的部署模型通过一个或者多个 function用于响应用户的需求。可以说粒度小灵活性高是它的最大特性。
在代码层面为了让用户更好的理解我们把传统代码的结构进行了分解传统的 MVC 类型的代码会分为几层。
HTTP 服务原框架koa/midway/egg…)Node.js 运行时启动脚本等将会变为函数运行时固化下来原有的 HTTP RouterWeb 中间件等将会由 HTTP 网关承接原有的 Controller业务逻辑调用远程服务继续保留变为函数代码原有的数据库消息队列RPC 调用等都作为 BaaS 服务用户只关心对应的服务使用同一的 BaaS Client 进行调用这样分解过后我们对新旧两个体系的代码结构有了进一步认识可以开始尝试修改部分代码变成真正的 Serverless。
迁移
传统的应用会暴露出一些对外的服务供外部调用比如 HTTP,定时任务,RPC 服务等等这些服务一般我们会单独抽离目录并且和其他暴露的服务共享逻辑层代码我们也经常称这些服务为“入口”。 在 Serverless(FaaS) 化的过程中我们会根据当前部署平台的能力比如阿里云 FC腾讯 SCF 都会提供 HTTP 服务定时任务消息队列等等将这些入口代码变为基于事件驱动的函数。 我们通过构建机制在发布时生成不同的包在共享一份逻辑代码的同时部署到不同的环境这个方案最大的优势是复用了原有的逻辑部分可以和传统应用同步开发而劣势也有就是包依赖混在一起由于函数对包大小有限制可能会造成依赖过大等问题。
HTTP 相对于其他的来说会复杂很多会有很多限制这个我们在讲下游方案的时候再说。 针对上面的情况对下游的数据调用我们也有相应的方案。我们将这些方案取了几个名字比如代理模式和网关模式。
▐ 代理模式
首先来看看代理模式。一个传统的 Web 应用会分为 Router/Controller以及逻辑层在代理模式中我们会保留传统的应用只将原本的逻辑层部分迁移到了云函数中暴露出 HTTP 服务。 这样的好处是代码变的精简改动适中也易于服务复用缺点就是依旧会占用一个应用资源作为代理层。
而代理应用一般是通过 HTTP 客户端代理来实现的只是用户体感上需要做一些额外的支持让开发者在体验上感觉到是调用了远端服务。 ▐ 网关模式
第二种方式是网关模式这个模式下所有的代码都会迁移到新的体系在 Web 层简单的时候比较适用。
该模式下所有传统的 Web Router 会迁移到 HTTP Gateway 上原本的路由会话、鉴权等能力都将被网关所控制而函数本身不需要关心这些只需要关心数据即可。
业界现有的 FaaS 模型大多是这种结构集团内也采用了这类结构去实践。 在这种模式下原有的能力会碰到一些问题举一些例子
原有的 Web 中间件koa middlware会不知道如何处理中间件大多是做请求流的拦截和消费这个时候大多会拆成两部分一部分被网关所处理另一部分只能交给函数本身如果有共享的需求也可以依赖模块来完成原有的会话维持一部分平台会进行透传 cookie这个时候你依旧可以维持一个 sessionId同时使用第三方来存储数据但是如果网关不做这块那么就很麻烦了请求对象和原有的不同由于函数获取的是 eventcontext 参数或者原始的 request 对象和现有的 koa 等框架不是很一致上面的方法不一定有会导致原有的代码做出修改和挑战
▐ 伪装者模式
那么有没有不修改代码的方案呢我们尝试在函数外部进行代码包裹和数据模拟让应用整个跑在函数之上以一种 “微应用” 的方式继续存在。 我们把原有的 Web Servermidway/egg)启动起来在运行时中通过一个固定的端口转发把 FaaS 的请求参数包裹成 HTTP Request 对象而在出口处也将 HTTP Response 包裹为函数能读懂的形式通过这样续命的方式来延续传统应用。而由于阿里云上的容器只读不能写目前还无法直接用这种模式。 这种方式需要调整的是框架需要使用单进程模型机器配置轻量化的要求应用需要无状态函数机制决定以及没有长连接等高消耗的操作。 总结
关于 Serverless 的问题还有很多本文也只是介绍了其中一部分内容从阿里当前的状况讲起分享了从去年到今年的研发模式升级实践也介绍了在这其中我们的一些思考传统应用迁移到 FaaS 体系下的方式。后续的整套方案也会在经过双十一的洗礼大流量的考验后开放给大家。
原文链接 本文为云栖社区原创内容未经允许不得转载。
