首页 文章 精选 留言 我的

精选列表

搜索[思考模型],共10000篇文章
优秀的个人博客,低调大师

得物API元数据中心探索与思考

一、背景 目前市面上针对API的管理平台很多,但由于各种客观因素,这些平台的功能都更多聚焦在API文档的消费侧。而对于API文档的生成都非常依赖开发人员的手动创建,很难保障文档的实时性和有效性。市面上常见的API管理平台,由于缺乏有效的管理机制,完全依赖开发人员的主动维护,在文档体量变大之后就出现了文档归属混乱、文档重复上传、文档信息更新不及时等问题。 由于文档缺乏有效的维护,很大程度上局限了API文档在消费侧的作用。举个例子,如果一份API文档更新不及时,那么前端就很难基于过时的文档进行数据Mock。如果平台大多数的文档都存在更新不及时的问题,那其他的平台也很难把平台的API文档作为有效信息使用。 二、Mooncake API文档维护 为了解决文档的维护问题,得物技术部自研了Mooncake平台,并从文档组织规范、文档生成效率等方面做了大量的尝试。 API文档组织规范 平台用户对于接口文档的存储管理、交付时间和交付质量均有一定的诉求。平台通过规范的方式统一起来,建立接口文档项目和目录组织规范,降低接口查找难度和用户使用费力度。 规范应用名称 如果应用名称可以任意创建,从技术部现有数据看来,各域定义的巨大差异将会导致用户使用存在一定的理解成本。为统一项目命名规范,同时更清晰的展示接口与项目之间的关系,平台计划与发布平台&CMDB&网关等系统保持一致,统一采用CMDB中的应用名作为项目名称,降低文档查找的难度。 通过打通CMDB数据,统一CMDB应用名,打通与公司内部平台的数据,主要包含: 建立与发布平台的关系,自动获取应用染色环境列表,降低接口调试难度; 建立与Gitlab平台的关系,自动获取应用需求迭代数据,降低文档与需求绑定的费力度; 建立与网关平台的关系,一键同步接口网关自动关联路由组等数据信息; 打通交易网关、APM的数据,获取接口文档信息,丰富文档信息密度。 通过将应用名称规范化,Mooncake平台建立了一个规范化的应用命名体系,让用户可以更方便地查找和使用文档,并提高了团队的协作效率和产品质量。 规范文档分类 如果以类名或注解作为文档分类的依据,导致文档的可维护性逐渐降低,文档和业务的关系也逐渐削弱。为了解决这个问题,平台通过规范文档的分类,降低文档的查找和管理难度。 在技术层面上,提供多级分类能力,规范化维护文档分类,并完成商家、客服、供应链、交易等规范性分类的推动以及约束文档的落地; 在规范层面上,推进各个团队根据自己的业务场景按照统一的规范来分类文档,从而提高文档的可维护性和管理效率。例如,推动客服、商家、交易等各个域落地接口目录规范文档,项目负责人或Owner定期检查分类规范的执行情况,并对分类不规范的文档进行整理和优化。 通过技术和规范手段相结合,规范文档分类,可以降低文档的查找难度,提升文档的可维护性和管理效率。 API文档生成 MooncakeUpload Idea插件 得物技术部研发的MooncakeUpload Idea插件可以帮助解决API文档创建和录入的问题。该插件通过解析Java项目里的注解和注释,实现了一键生成API文档的功能,降低了API文档创建的费力度。相较于手动创建接口文档,使用插件上传API文档所需的时间仅为几秒钟,而且规范了接口的分类属性,使得上传文档过程更加简便和快速。在每个迭代中,使用插件可以节约将近667小时的时间。 实现原理 基于IntelliJ Platform自身的基础架构,依靠PSI(Program Structure Interface)核心特性,通过分析解析出来的语法树可以获取准确的代码信息,例如获取文件中包含的类、方法、字段和注释等信息。 核心实现 配置信息 通过IntelliJ Platform提供的虚拟文件系统(Virtual File System)功能,读取插件的信息配置,主要包括Mooncake的项目信息,人员的域账号等。从而能够获取Mooncake的分类数据,以及接口的变更人员。 // 解析misc配置文件 File miscFile = new File(editor.getProject().getProjectFile().getPath()); Element miscElement = JDOMUtil.load(miscFile); // 读取token public static String getToken(Element element, PsiFile psiFile) { try { String token = getHistoryConfig(element, psiFile, MooncakeConstant.HistoryToken); if (token.equals("")) { token = getProjectConfig(element, psiFile, MooncakeConstant.Token); } if (token.equals("")) { Messages.showErrorDialog("请先去idea/misc.xml配置MooncakeUploadApi配置", "获取配置失败!"); } return token; } catch (Exception e) { Messages.showErrorDialog("请先去idea/misc.xml配置MooncakeUploadApi配置", "获取配置失败!"); return ""; } } 原有的配置功能,会通过用户配置的项目名称信息和当前路径进行二次校验,增加了用户理解的难度,平台插件使用的问题中,80%的问题来源于配置的繁琐。因此在2.0版本之后,通过内置数据校验,降低了项目信息的配置难度,配置信息仅需一个参数即可: <component name="mooncakeUpload"> <option name="token">xxxxxxxx</option> </component> 出入参信息 依靠PSI核心特性,通过解析选中文件的语法树,提取字段信息,组装API文档的出入参和注释,主要核心逻辑: // 获取偏移量 PsiFile editorFile = e.getDataContext().getData(CommonDataKeys.PSI_FILE); PsiElement referenceAt = psiFile.findElementAt(editor.getCaretModel().getOffset()); // 获取选中的类或者方法 PsiClass selectedClass = PsiTreeUtil.getContextOfType(referenceAt, PsiClass.class); PsiMethod selectedMethod = PsiTreeUtil.getContextOfType(referenceAt, PsiMethod.class); // 获取选中类下的所有方法 PsiMethod[] psiMethods = selectedClass.getMethods(); // 获取类上的注解 String apiValue = PsiAnnotationSearchUtil.getPsiParameterAnnotationParam(selectedClass, SwaggerConstants.API, "tags"); // 获取参数所属类 PsiClass psiClass = JavaPsiFacade.getInstance(project).findClass(psiParameter.getType().getCanonicalText(), GlobalSearchScope.allScope(project)); // 获取参数所有字段 PsiField[] fields = psiClass.getAllFields(); // 字段源类型,可以获取所有信息 PsiType type = field.getType(); // 字段名称 String name = field.getName(); 可视化面板 Mooncake平台支持API文档的多级分类,为了降低接口文档的分类难度,降低对代码的侵入,基于Java的Swing GUI库,我们提供了可视化操作面板,用户可以选择需要上传的接口和分类信息,以及需求信息。 版本更新 MooncakeUploadApi上传插件是得物技术部自主研发的插件,由于存在公司的业务信息,无法上传到插件市场,只能将插件打包成Jar文件给开发使用。这种情况下,可能会出现以下问题: 用户无法及时感知到插件修复过的版本,导致升级新版本时存在困难。如果出现问题,用户还需要找Mooncake维护人员定位问题,并进行手动修复和更新,维护成本比较高; 由于不能上传插件市场,用户升级插件需要手动找到Mooncake维护的插件文档,并下载相应的Jar包进行更新,费力度高。 针对以上可能存在的问题,得物技术通过搭建私有仓库方式,最终实现了插件更新方案,如图所示: 最终实现了插件启动的自动检查版本更新,并进行通知。 结果 通过自研Mooncake Idea上传插件,实现Mooncake平台以下收益: 快速响应并定制化需求:通过打通Gitlab,插件可以根据代码分支来自动绑定接口的业务需求,以便快速响应相关问题; 提升 开发 效率:使用插件可以大幅度降低API文档创建的成本和负担,从而让开发人员更加专注于代码的开发和测试等任务中; 规范 API 文档:插件通过可视化面板交互方式,规范了文档的格式和内容,并能够快速选择上传的文档分类和字段信息,以便更好地管理和使用API文档信息,从而提高了规范化程度。 目前研发部门接通过插件每个迭代上传API文档的次数(如图所示),平均每个迭代产生数千次的变更,大大提升了维护文档 效率 ,达到降本提效的目的。 基于Gitlab MR自动解析 背景 平台提供了APIUpload插件之后,整个文档生产端现状如下: 服务端在开发阶段通过手动/插件上传API文档到Mooncake侧; 提测节点时从网关同步当前迭代新增的API接口,与Mooncake侧接口比对,查看是否存在,不存在则要求开发上传接口。 通过网关来进行新增接口卡点,可能存在以下问题: 网关侧配置的接口仅为需要走网关流量的接口,不走网关的接口,如Dubbo接口、内部接口并不能保证接口在Mooncake存在; 即使在Mooncake存在的接口,如果在上传之后又产生了变更,通过网关的卡点并不能保证最新的变更也同步到了平台。 因此,平台 在 通过上传插件降低 API 生成费力度 的同时 , 也需要将 现有的 研发 流程仍然强依赖使用者的习惯 、 API文档的质量不稳定 的风险考虑进去。 针对这个问题,平台在Gitlab的流水线中,新增了一个自动解析代码的节点。对于每个向release分支合并的MR,将其中和接口定义相关的部分进行解析并自动在平台生成/更新对应的API文档,从而保证所有接口在 发布 前一定将最终的接口定义同步到 Mooncake 平台。**** 实现 配置 Gitlab 流水线 任务 自动解析需要拉取项目的全量代码和依赖包代码,因此占用的内存空间较大; - 自动解析项目耗时较长,例如公司内部某个项目,7k+的文件需要耗时3.5min,自动解析feature分支消耗太多资源。 因此我们最终针对HTTP接口只做每个迭代的兜底,通过解析Release分支,保障每个迭代结束时,文档都是完整的和最新的。 获取二方包 源码 由于二方包在编译为Jar之后,代码的注释会丢掉,而API文档需要解析字段的注释和注解来描述字段的含义,自动解析要保证接口的完整性,需要补全二方包的注释。因此我们扫描了Pom文件的依赖包,并将公司的二方包全部下载到当前项目目录里面,并反编译解析原始数据。 获取公司内所有的二方包源代码数据: JSONArray allModuleDepsTreeData = new JSONArray(); for (String fileDepTree : arrayListScannerMgr_Dep_Tree_POM) { JSONObject treeDependeces = dependcesParse(fileDepTree); allModuleDepsTreeData.add(treeDependeces); } // 过滤公司二方包 String group = nodeChild.getGroupId(); if (group.contains("xxx") || group.contains("xxxx") || group.contains("xxx") || group.contains("xxxx")) { return true; } // 下载所有二方包 File tempFile = new File(jarScanPath.trim()); String fName = tempFile.getName(); fName = FilenameUtils.removeExtension(fName); fName = fName.replaceAll("-", "_"); 解析项目所有的代码 通过调研,Qdox工具包具备体积小,解析效率快,使用文档简单的特性,因此采用使用Qdox将项目中的所有代码解析为Java语法树,并实现API文档的信息提取。 核心逻辑如下代码所有,解析所有class,并基于Swagger注解和RestController注解提取所有的Http接口。 // 初始化builder JavaProjectBuilder builder = new JavaProjectBuilder(); builder.setEncoding(StandardCharsets.UTF_8.name()); // 读取所有class信息 builder.addSourceTree(new File(sourceDir)); Collection<JavaClass> classes = builder.getClasses(); // 过滤所有http接口 // 获取所有http api class Collection<JavaClass> httpClasses = new ArrayList<>(); for (JavaClass javaClass : classes) { if (CommonHelper.isHttpClass(javaClass)) { httpClasses.add(javaClass); } } 而接口文档信息的解析与Idea插件解析思路基本一样,最终将所有的接口方法解析为JSON格式的API文档,如图所示: 将解析的 接口 数据与 Mooncake 平台数据对比 接口在Mooncake不存在的,直接上传到Mooncake平台,保证 API 文档的完整性; 接口存在的,比对接口文档核心数据,包含出入参和路径等,不一致则更新接口文档,保证 API 文档的一致性。 三、Mooncake API元数据中心 Mooncake平台通过不断完善从生产到消费链路的信息,延长API文档的生命周期,完成API文档元数据中心的闭环。在平台的探索过程中,逐渐沉淀了丰富API文档信息,解决了API的利用率低,API信息密度低的问题。目前,API信息主要包含以下: API描述信息:如 Swagger、OpenAPI 等格式的 API 描述文件,包括 API 名称、版本、路径、参数、响应等; 接口规范:定义API请求和响应协议,规范接口分类; 稳定性:API的版本管理、生命周期、周期变更率等数据; 文档和示例:API的使用文档、示例代码、调用等; 开发平台:提供API开发者所需的工具和SDK,例如IDEA插件、Go cli等; 研发流程规范:提供接口版本周期稳定性数据,例如:调试是否成功、自动化测试用例等。 通过打造得物API元数据中心,更有效的提高API开发和管理效率,使得API能够更加透明化、可靠化、易于使用。基于丰富的API文档信息,平台围绕 调试 、 Mock 、数据开放等 API消费侧的功能也做了大量的探索尝试 。 Mooncake平台通过不断完善从生产到消费链路的信息,延长API文档的生命周期,完成API文档元数据中心的闭环。在平台的探索过程中,逐渐沉淀了丰富API文档信息,解决了API的利用率低,API信息密度低的问题。目前,API信息主要包含以下: API描述信息:如 Swagger、OpenAPI 等格式的 API 描述文件,包括 API 名称、版本、路径、参数、响应等; 接口规范:定义API请求和响应协议,规范接口分类; 稳定性:API的版本管理、生命周期、周期变更率等数据; 文档和示例:API的使用文档、示例代码、调用等; 开发平台:提供API开发者所需的工具和SDK,例如IDEA插件、Go cli等; 研发流程规范:提供接口版本周期稳定性数据,例如:调试是否成功、自动化测试用例等。 通过打造得物API元数据中心,更有效的提高API开发和管理效率,使得API能够更加透明化、可靠化、易于使用。基于丰富的API文档信息,平台围绕 调试 、 Mock 、数据开放等 API消费侧的功能也做了大量的探索尝试 。 调试 由于平台沉淀了精确的接口字段定义,因此基于这些定义对接口进行调试自测就非常方便。在提供基础调试功能的同时,平台也通过以下手段对调试的体验进行了优化: 基于文档信息,自动填充入参字段信息;同时基于文档信息进行简单的类型校验; 通过同步CMDB应用名称,自动获取染色环境名称,支持调试自动填充染色环境参数; 打通内部核心平台,优化接口签名和鉴权问题,降低接口调试难度。 对于部分仍然习惯于使用postman进行调试的用户,平台也支持将postman调试记录进行一键同步。 之所以这么执着的推动大家到Mooncake来进行调试,主要是期望将调试记录作为研发完成自测的一种“凭证”,并将其同得物现有的研发协同面板系统进行结合,把“自测凭证”作为生成前后端联调单的前置条件,通过保障联调过程中的接口质量从而提升联调效率。 整个联调过程大致如下: Mock 由于项目接口的完整性和及时性,前端可以基于平台的Mock功能,在开发阶段,前端可以Mock需求下的所有接口,充分完成功能的自测,前置联调流程,降低因为后端延迟提供接口的带来延期的风险。 基于入参字段的准确性和完整性,在Mock数据过程中,平台可以校验入参的信息的准确性,包括是否完整,数据入参类型是否准确等,提前发现问题,提升前端交付质量。 通过API文档的调试功能,平台沉淀了基于接口文档的真实数据,因此,平台可以自动为前端提供更加精准的具备业务属性的数据Mock,以及不同的异常状态码数据场景,更加真实对页面场景进行还原。 API元数据平台 将公司所有的API文档收敛到Mooncake平台,通过保障接口的完整性和及时性,可以保障所有消费平台都能拿到接口的详细信息,同时通过与其他平台协作,将接口的不同维度信息收敛到平台信息,例如接口的等级、读写属性等,丰富文档的信息密度。 通过提供OpenApi,为公司内部平台提供API信息,例如: 提供API文档包括接口名称,字段语义,出入参完整性给APM监控平台,提升Trace链路的可读性; 提供完整的出入参信息,与流量平台的接口数据比对,及时发现接口版本问题; 提供接口的变更率、是否调试成功等数据给提测平台,作为质量管控数据面板的一部分; 提供接口相关联的域名信息给网关平台,作为网关平台监控接口流量信息的依据; 将接口信息提供给接口自动化平台,可以提升测试编写接口测试用例效率。 四、展望 目前得物面对日益增长的业务,尤其是涉及分布式架构、微服务等技术和架构时,通过API元数据中心集中化管理API接口文档,在协同管理各团队、保证接口的一致性和完整性、快速演进变更、降低沟通成本等方面有着至关重要的作用。后续,平台依然会围绕已经沉淀的API信息,在接口自动化测试、API文档管理、接口健康度监控等上下游领域进行持续的探索。 *文 / migor 本文属得物技术原创,更多精彩文章请看:得物技术官网 未经得物技术许可严禁转载,否则依法追究法律责任!

优秀的个人博客,低调大师

飞猪基于 Serverless 的云+端实践与思考

作者 | 王恒飞(承荫)来源 | 阿里巴巴云原生公众号 本文整理自飞猪旅行前端技术专家--王恒飞(承荫)在【阿里云 Serverless Developer Meetup 上海站】上的分享。点击查看直播回放:https://developer.aliyun.com/live/246653。​过去两年,飞猪前端一直在积极地进行 Serverless 建设和实践,2019 年 - 2020 年我们和集团 Node 架构组、研发平台一起完成了基础能力的建设和业务试点,成为集团率先落地 Serverless 实践的 BU,2020 年 - 2021 年我们开始大规模地在飞猪推广使用 Serverless 的能力,从导购全链路到核心中后台,都能够看到 Serverless 的身影,这一年我们完成了 Serverless 从业务试点到生产力工具的转变,本文将主要分享飞猪基于 Serverless 的实践成果以及未来想要做的事情。​ Serverless 的使用规模 ​2020 年 - 2021 年飞猪 Serverless 的规模和重要度都有很大的变化,主要表现在三方面:​ 一是函数组规模增长一倍以上,Qps 峰值增长 650%。 二是使用 FaaS 开发的人员规模增长 560%,其中前端人员 80% 以上参与到 FaaS 的开发中。 三是影响力的表现,目前不仅飞猪前端都对 Serverless 很熟悉,客户端也有很多人参与到 FaaS 的开发,更重要的是后端和产品同学也知道我们有 Serverless 进行服务开发的能力。 具体的数据如下:​ 为什么要引入 Serverless ​飞猪为什么这么迫切地要引入 Serverless?这主要是出于前后端研发模式升级以及前端职能扩展的考虑,下面回顾一下飞猪前端架构的发展和研发模式的演进。​ 1. 飞猪前端架构的发展 ​飞猪前端架构总结下来就是从最初纯粹的前端开发,到解决多端一致性的跨端开发,再到接管视图服务端逻辑的前台开发,Serverless 就是前端升级转变的核心一环。 2. 研发模式的演进历程 ​前端人员为什么一定要参与服务侧开发?从前后端研发模式的演进来看,主要经历了以下三个大的阶段:​第一阶段是资源解耦,这个阶段前端把静态资源分离出来部署到 cdn,解决了和后端服务同机部署的耦合。​第二阶段是模板解耦,我们之前提到的前后端解耦大部分指的就是模板的解耦,一种不彻底的解法就是渲染解耦,服务端放一个空模板内容部分全靠 CSR,彻底的解法就是前端接管模板,可以独立部署模板也可以使用 node.js 替代。​第三个阶段就是试图解耦,一方面是由于客户端体系和前端的离线体系的限制,端侧对于视图的动态性要求极高,没有服务侧能力的前端只能将视图的动态性放在服务端做,另一方面由于端侧架构对于数据接口协议的特殊要求,需要服务端来进行协议的转换,也就是服务端常说的 Do 到 Vo 的处理,这就造成了前后端视图的耦合,为了去除这部分耦合,前端通过 Node.js 做 BFF 层来接管视图层的逻辑,Serverless 则是给了前端做 BFF 开发的最佳选择。​ 3. 为什么一定是 Serverless ​其实在 Serverless 出现之前,前端也尝试了用 node 应用来做 BFF 层的开发,飞猪也是在 2017 年通过 Midway + React *** 的架构将飞猪 PC 主链路首页、搜索、商品详情、订单详情 Node 化,但是应用级别的开发在前端存在以下几个问题:​ 开发成本高:Node 应用级别的开发对于新手前端还是具备一定的开发成本,之前做过粗略的估计,上手成本至少需要 3 人/日,还不包括后续的性能优化、内存泄漏排查等一系列能力。 运维成本高:Docker、镜像、机器日志查看、域名申请、机器替换等一系列运维能力对于前端来说具备非常高的复杂度,也是注定无法推广的一个重要原因。 机器成本高:前端在使用应用开发时过度偏向于前端架构设计带来的应用离散和机器利用率低的问题,根本原因是前端在用页面开发的思维去做应用开发,导致新建一堆应用占用大量闲置机器。 2017 - 2019 年也是集团 Node 开发停滞的两年,这个阶段由于上述问题的闲置,Node 开发无法在移动端铺开,前端使用 Node 主要在中后台的开发,这时矛盾主要表现在前端迫切渴望研发模式转变和涉足服务端开发的高昂成本,直到 Serverless 浪潮的出现让我们看到了曙光,下面来看下 Serverless 能给前端带来什么样的变化:​ Node FaaS 通过将中间件集成到 Runtime 的上下文中,开发通过 Api 的方式调用来实现极低上手和开发成本,只要会写 js 就能在 0.5 人/日内上手 FaaS 开发,同时 Serverless 容器底层通过机器统一管理、镜像统一、灵活调度、按需付费等方式向开发者屏蔽容器的运维,两者结合完美地帮我们解决了之前 Node 应用开发遇到的三大问题,至此前后端研发模式升级的最后一块拼图集齐,前端开始云+端的变革。 飞猪云+端的核心落地场景 ​ 1. 落地场景总览 ​从飞猪首页到搜索、频道,再到大促会场,Serverless FaaS 实现了在飞猪导购全链路的覆盖,成为飞猪前端的常用生产力工具之一。另外中后台开发已全面使用 FaaS 开发,并且赋能客户端同学,下图右侧的包体积平台就是飞猪客户端同学使用 Node FaaS 开发完成。​ 2. 云+端场景 - 数据协议处理 ​数据协议处理是 BFF 层最为常见的场景,包括接口合并、Do 到 Vo 的转换等,飞猪 80% 以上的 C 端 FaaS 场景都是用作数据协议的处理,通过 FaaS 来做协议转换能够解放服务端,同时增强前端对视图层的控制,可谓一举两得。​ 一个最新的例子(如下图所示),这是一个飞猪的内容详情页,页面涉及内容中台、评价中台、互动、算法等 5 个以上接口,这些接口都是现成的分散在各个系统,对于前端来说肯定是不想在端上调 5 次接口,不管是从性能还是架构设计上考虑,都是不合理的,这时就需要一个服务端接口的合并,FaaS 就非常适合做这样的事情,通过原子能力的拼装,无需服务端介入,极大缩短了需求的交付周期。​ 3. 云+端场景 - *** 同构渲染 ​*** 同构渲染并不是一个新的概念,最早在 React 支持 *** 的时候,前端就具备一套代码在 Server 和 Client 端执行的能力,飞猪这边早在 2017 年就在 pc 端上线了 Midway + React *** 的页面。​移动端由于流量比 PC 大很多,且在 Server 侧执行 Js 是一个极耗机器资源的操作,通过 Node 应用的方式做 *** 机器和运维成本跟随着页面流量指数级上升,ROI 并不高,但是 Serverless FaaS 的自动托管,能帮前端解决机器利用率和运维成本的问题。​再配合客户端的文档预加载,我们可以做到客户端预加载直出率(500ms下)100%,端外渲染 2s 达标率 90+%,性能提升 80% 以上。​ 4. 云+端场景 - 一体化应用 ​一体化研发是一种更加符合前端人员习惯的开发模式,常见的分为中后台一体化和 Rax+FaaS 一体化,将 FaaS 代码和 Assets 代码在一个仓库下开发,调试和部署能够极大地提高开发效率,目前飞猪用得最多的就是中后台一体化开发。​ Serverless 研发配套建设 ​在基础建设方面定义为两部分:研发态效率的提升和运行时稳定性的保障。​ 1. 研发态效率 ​开发阶段主要涉及的操作是新建项目、调试和发布,飞猪通过已有的 Clam 工程体系集成 FaaS 的脚手架模板,对接 def api 打通创建项目、迭代和发布的能力,让前端同学开发 FaaS 能有和开发页面一样的体验,降低上手和开发成本,同时封装 Mtop 调用和容灾 SDK,封装常用 FaaS Utils 集合的方式提高代码的复用度。​ 2. 运行时稳定性 ​通过函数监控 Alinode、网关监控 Sunfire 以及全链路日志的排查能力,做到问题的快速发现和定位。​ 通过 tair 容灾和 cdn 容灾,保障大部分场景在函数或者网关挂掉的情况下,仍能够正常展示页面。 未来 ​2020 年 - 2021 年我们完成了 Serverless 向生产力工具的转变,2021 年 - 2022 年总体来看是彻底完成飞猪研发模式转变的目标,让 FaaS 成为前后端都习以为常的一环,规划还没做具体,有以下几个关键的事情要做:​ 中后台和长尾函数 0 - 1 的弹起尝试:这块考虑到一些中后台函数和长尾函数每天可能只有几十个 Uv 够不到 Qps 级别,目前预留 1 核机器的方式仍是有些浪费,考虑在不影响初次请求的情况下尝试 0 到 1 的弹起,做到机器的极致利用率。 飞猪物理网关的替换:目前虽然飞猪 Java 的网关出于维护状态投入较低,但是一旦流量发生变化,网关的稳定性会成为瓶颈,希望能够有 Fc 专门的团队接管流量网关,之前飞猪也是完成了一个线上试点,2021 年 - 2022 年继续推进。 研发态和运行时问题的可观测增强:从 FC 底层容器到函数代码内部再到函数依赖、流量网关,不管是部署出现的问题还是线上的问题,都比较难定位,通常需要拉着 FC、研发平台、Runtime 的同学一块排查,后续希望能推动可观测性的增强,让业务开发能够快速发现问题。 写在最后 ​基于 Serverless 的云+端结合已经基本成型,这将是前端近些年来最大的变革之一,未来 FaaS 将是前端开发不可或缺的一环,我们需要用它来做研发模式升级,也需要用它帮助前端扩大职能,通过 FaaS 的能力让前端开发深入到服务层,更好地贴近业务、理解业务、帮助业务。​ 作者简介 ​王恒飞(承荫),飞猪旅行前端技术专家,飞猪 Serverless 引进和实践者,探索和推动云+端的研发模式。

资源下载

更多资源
Mario

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长,特征是大鼻子、头戴帽子、身穿背带裤,还留着胡子。与他的双胞胎兄弟路易基一起,长年担任任天堂的招牌角色。

Spring

Spring

Spring框架(Spring Framework)是由Rod Johnson于2002年提出的开源Java企业级应用框架,旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念,提供核心容器、应用上下文、数据访问集成等模块,支持整合Hibernate、Struts等第三方框架,其适用范围不仅限于服务器端开发,绝大多数Java应用均可从中受益。

Rocky Linux

Rocky Linux

Rocky Linux(中文名:洛基)是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版,作为CentOS稳定版停止维护后与RHEL(Red Hat Enterprise Linux)完全兼容的开源替代方案,由社区拥有并管理,支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性,采用模块化包装和SELinux安全架构,默认包含GNOME桌面环境及XFS文件系统,支持十年生命周期更新。

WebStorm

WebStorm

WebStorm 是jetbrains公司旗下一款JavaScript 开发工具。目前已经被广大中国JS开发者誉为“Web前端开发神器”、“最强大的HTML5编辑器”、“最智能的JavaScript IDE”等。与IntelliJ IDEA同源,继承了IntelliJ IDEA强大的JS部分的功能。

用户登录
用户注册