龙建军：云开发技术在深圳机场旅客出行服务项目上的实践

2020 年 11 月 29 日，腾讯 2020「小程序·云开发」技术峰会在北京顺利召开。本次峰会以“重新定义开发”为主题，深度聚焦小程序云开发的创新成果与实践案例。以下为腾讯云高级应用开发工程师龙建军的演讲实录：

龙建军：大家好！我今天给大家分享的主题是讲一下企业级项目：深圳机场旅客出行项目在小程序云开发技术上的一些玩法和运用。

深圳机场旅客出行服务项目是我们腾讯云中标深圳机场的一个项目，大概过亿，每年旅客人次数大概 5000 万。本次分享的主要目的，就是希望大家听了我这个分享之后可以给大家起到抛砖引玉的作用，开拓思维，帮助大家可以挖掘云开发技术的更多玩法。

我本次分享主要分四块：第一，企业级项目的特征；第二，深圳机场旅客出行服务项目的总体架构，让大家有一个宏观的把握；第三，选几个重要的场景，讲述企业级项目上我们是如何来“玩”云开发技术的；第四，基于云开发的技术的再次封装场景以及解决一些业务上的痛点。

从这个架构上可以看出，整个机场项目是有三层架构的：第一层是 C 端，第二层是应用层，第三层是后台。而运营开发技术其实自始至终贯穿在我整个项目的应用层。其实这样的架构一切目的主要就是为了满足企业级开发的诉求，比如说收拢逻辑、快速运营（运营自闭环）、安全可靠、分工清晰。

为了让大家对架构有更好的理解，从概况图中可以看出，整个架构是三层，而整个应用层是架构在云开发基础上的，应用层主要是做运营、流量保护、脱敏以及业务组装等，后台主要是做协议转发和固化逻辑。

从开发到上线、再到运营、问题排查、后续监控，其实都是完备的工具链的建设，而云开发技术在整个链条建设过程中充当的是什么样的角色？时间关系我下面主要选几个重要的场景给大家分享。真实情况是，云开发技术在整个项目架构中是一条线，但是我今天分享的在你们听来可能只是一个一个点。

场景 1：性能建设。

目前我做了两套的缓存机制，一套本地缓存，一套是云端缓存。本地缓存机制主要是通过请求云函数，返回时间戳，来判断它是否过期，云端缓存主要是通过 C 端传递过来的 Tag 标记，以云业务函数中的 Tag 标记来判断是否缓存。其实整个流程就是，每次访问 C 端会去云函数拉一个时间戳和 Tag 值，每次请求都会带上 Tag 标记，Tag 标记就和云函数的标记进行对比，目前整个云函数如果是一些通用的缓存，是用云函数自身的内存来存储，如果有一些特色的量比较大的就是用 redis 进行缓存。这个缓存好像很简单，但其实整个缓存的穿透以及缓存的雪崩都有一些额外的异常处理。

场景 2：日志建设。

我们当前完全使用的是云开发提供的日志存储方式，以前的做法是需要我们自己建立一个完整的日志系统，但用云开发比较节省能力，可以看到，我们做日志存储的时候目前就是用云开发提供的高级日志接口打印日志，这个是日志接口的代码。

这是我对业务层收拢日志打印的调用业务逻辑，就是把云函数的日

志与小程序的日志和调用服务的日志全部收拢起来。这是云开发控制台上对日志进行查询，目前云开发日志支持多种查询方式：全文检索、键值检索、模糊关键字检索等等。其实整个日志背后还有一套更加完备的监控和体系。

场景 3：可靠性和稳定性建设。

作为一个企业级项目，当然可靠性、稳定性建设是很广的讲法，目前我只是挑了一个点，因为项目比较大，有很多开发者来参与协作开发，但整个协作开发中如何来保证发布流程不要把测网代码发到现网，为了避免这种情况我创建了三个环境：

一个代表测试环境，一个代表预发环境，一个代表现网环境。这三个环境小程序里面又是如何区分的呢？其实主要是在小程序里面有一个下斜杠 config，这个就是区分核心关键字，这样就避免了每次发盘的时候都要不断的去改善环境，以防把本来测试的代码加到现网去。

场景 4：多端建设。

作为一个企业级项目，它面向的群体用户是非常多样的，所以多端支持也是必然的诉求，目前深圳机场 APP 使用的是 Flutter 技术，C 端和小程序端他们应用层，所以存在 Flutter 怎么连接应用层的函数的，目前应用层提供了 Flutter—SDK，你们在官网是可以查得到的。目前深圳机场项目有 APP、小程序、H5。

世界上没有银弹，虽然云开发技术在我们搭建整个企业级链条上提供了非常强力的支持，但是有技术的地方就有坑，而我们要做的就是趋利避害。

我们在项目开发过程中，随着需求的增长和不断的迭代，以及不是很了解项目背景的开发人员加入后产生的问题，就是云函数乱用的问题。因为我们现在创建云函数成本很低，导致云函数越来越多，也被重复开发，有点混乱。而对于混乱的问题我做了一个云函数路由分发，下面又有一个动作，一个云函数代表一个业务的功能块，一个动作代表一个 C 端的请求，把公共能力也封装成公共云函数，就是复用一下那个能力，比如像后台的 GRPT 请求、HTTP 请求，用这个云函数做这个事情，云函数路由分发我还申请了一个专利。这样做的目的，为了解决云函数混用，让大家写面向 C 端 API 的时候有一个规范和标准。

在开发过程中还有一个问题，因为现在是用云开发来打印日志，使用的成本较低，导致大家随便就在云函数里打印个日志，导致日志非常混乱，排查问题的时候会发现根本不知道哪条日志是属于我的，针对于这种情况我把所有 C 端以及服务端请求的用户行为全部统一成一个自建模型，全部日志遵循这个模型来建模，这样日志和上报都成为了标准的格式化数据，方便后续做一系列的分析以及告警和问题排查。这个模型里面万物皆事件。

这些是基于业务痛点解决的一些问题，其实我写了一个业务框架叫做 wCore，大家可以扫这个地址，就可以看到 wCore 的使用方式，当然目前还属于“毛坯房”的阶段， 并不是很完善，后续我会开发出来，期待大家一起完善它。目前这个业务框架使用在我们深圳机场项目、川航项目、深圳地铁的项目。

感谢大家的耐心听讲，我上面的分享只是蜻蜓点水，希望在云开发

道路上大家都能够玩出自己的高度和境界。如果大家有一些关于企业级小程序云开发的一些探讨，我希望和大家一起来探讨，也许我的经验可以让你少走一些弯路。谢谢大家！