微保 Serverless 实践之架构演进

背景

微保前端架构在业务发展中，根据业务、团队、开发等实际状况，不断进化调整。本文将具体介绍微保前端的架构演进过程，以及团队最终选择使用腾讯云 Serverless 技术支撑前端架构的缘由。

微保团队使用 Serverless 技术的主要应用场景：

1. 前端开发同窗，应用在BFF层，目前接入的有小程序，H5 页面。
2. 数据组同窗，面向的风控和推荐算法应用，作计算使用。

微保架构 v1

早期，团队使用经典的先后分离架构，前端开发与后端开发经过接口进行合做。

合做流程以下图所示：

毫无疑问，先后端分离的架构有比较显著的优点：

1. 先后端开发解耦

• 前端与后端开发并行，缩短需求总体开发周期

• 角色分工明确，线上问题定位与修复更加清晰

先后端分别设计与实现本身的错误监控和告警系统，前端对页面脚本错误进行捕获，上报至日志平台，通过日志处理工具，设置告警机制，将错误信息推送至相应的开发人员。

• 利于前端组件化与后端微服务化架构

先后端分离后，前端可使用更为便捷的框架以及基于这些框架的基础UI组件，大大提高开发效率。另外，前端开发也会基于业务的特色，提取业务专属的公共组件，全部组件化的沉淀，都是对生产效率的提高。

2. 部署解耦

• 前端静态文件单独部署 CDN

前端项目中有大量的静态文件，包括 html、css、js、图片、视频等，将这些文件部署在 CDN 上，充分利用现有云服务的CDN能力，既能提高资源访问的速度又能保证资源访问的稳定性，尤为是在高并发的场景下。

• 更加快捷的 CI/CD ，前端的编译过程能够很是简单地接入 CI/CD

在先后端耦合的时代，先后端的统一部署相互依赖，分开部署后，能够针对前端项目以gitlab的repo 级别来作相应的 CI/CD。

然而， 先后分离的架构对于业务早期的快速发展很是有效，并且在团队规模较小的时候，先后端开发人员合做固定，彼此对于对方的开发习惯、性格较熟，所以跨角色沟通的问题并不突出。但随着团队规模和业务规模持续扩大，这个架构模式给团队带来的反作用慢慢浮出水面。实践中，遇到的几个比较明显的问题，以下：

1. 先后端协做耦合慢慢成为开发效率提高的瓶颈。

以下图所示：

团队规模与业务规模的扩大，意味着合做的人员变多、接口的复杂度也会相应增长。

早期专人专项你们彼此的开发习惯也熟悉，对业务也都比较熟悉，所以业务接口参数的调整沟通成本较低。但随着业务规模和团队成员扩充，在各类跨业务合做时就会有人碰到不习惯阅读proto，或有些复杂业务须要花费大量时间阅读proto文档，或先后端反复沟通接口调用时参数的具体含义等问题。

2. 页面渲染效率较差

以下图所示

以产品详情页为例，页面的渲染须要请求至少5个后端接口，而后再对数据进行组装和处理。这不只增长了小程序端的代码体积，页面渲染的速度也是被拉低了。

即便在前端页面对接口进行并行访问，但数据的整合逻辑依然会很是复杂。小程序做为微保主要的产品承载形态，代码量巨大，几近达到微信规定的代码上限，这种对于代码的增长随着业务增加也是一个隐形的风险。

微保架构 v2

鉴于上述先后端合做模式中的痛点，团队对架构再次进行优化，原则是业务“前”移、核心下沉。在前期的各类业务支撑中，团队已经有了一些业务中台的沉淀，好比投保服务、续保服务、保单服务等。

中间层的引入让团队的开发效率进一步获得提高，前端对于业务的把控力及页面性能优化的操做空间也大大增强。不论是从团队的敏捷性、仍是应用的体验，都有不错的改善，好比如下几个方面：

1. 先后端流程上的耦合大大减少，角色责任的专注性逐步造成

基于一部分后端服务能力的积累，好比保单相关的需求，在需求评审及开发过程当中，只须要前端开发同窗参加便可。前端开发同窗与业务产品沟通业务逻辑，在api市场或服务文档查询相应的服务能力，完成业务开发。同时对于团队逐步开展业务中台化、前端组件化大有助益，整个架构对于丰富多变的业务需求的响应更敏捷。

2. 渲染层对后端的服务进行聚合，减小页面请求

不论是H5网页仍是小程序页面，均只需跟中间层打交道，前端开发人员根据业务的诉求，自行对接口进行聚合，端上只须要1个请求就能够开始渲染页面。接口聚合以前，产品详情页面的显示须要请求5个接口，平均的接口请求耗时为120ms左右，聚合后，经过中间层来请求5个内网接口，避免端与服务的屡次链接耗时。

3. 中间层对数据进行加工，大大减小小程序端的逻辑代码量

以前在小程序端的数据整合代码，有些复杂的逻辑，能够交给中间层处理，这些代码的节省对于业务持续增加时会愈来愈体现出价值。以年金产品详情页为例，数据在中间层聚合可以节省10KB的体积。

中间层的引入是对生产力的进一步解放，但基于一个巨型 app 的 node 中间层，在后期的运维中也暴露出一些问题。中间层的应用部署在2台CVM机器上，有其先天的一些不足：

1. 应对尖峰流量的冲击能力差

微保常常会有一些运营和投放需求，这些事件都会致使瞬间的大流量打入，CVM的扩容相对滞后。

2. App级别的部署与发布

中间层不断积累业务代码，整个应用线性增加，每次部署与发布都是巨石应用的发布，部署效率低、风险高。

3. 前端开发人员在开发、测试环境中须要本身在机器上查阅日志和服务操做，提升了普及的门槛。

微保架构 v3

基于上面的这些限制，团队开始关注新的技术，加州大学伯克利分校计算机科学 Riselab 团队的实验室研究室提出：Serverless 是云计算的下一个浪潮。国内各大厂商也都开始布局 Serverless ，腾讯云 Serverless 团队是国内比较早在这方面进行部署的团队，技术已经很是成熟，在新东方、蘑菇街、哔哩哔哩、TP-link 等数百家企业成功落地实践。

经过调研了解到腾讯云 Serverless 云函数的优点：

• 强大的扩所容能力，特别适合应对流量洪峰，且性能稳定。
• 每一个函数都是单独运行、单独部署、单独伸缩的，用户上传代码后便可自动部署，提高了独立开发和迭代的速度。
• 云函数提供精细的日志记录，可方便地查看函数的运行情况，并对代码进行调试、测试和审计；支持相关的监控指标上报，能快速了解函数的总体运行概况，也可自定义云函数的监控指标。
• 精确到 1ms 计费规则，只对正在运行的函数计费。

综上，基本解决了架构 v2 中面临的问题，能够说是省时省力。通过团队总体评估，咱们决定使用腾讯云 Serverless 云函数进行架构的进一步调整。调整后的角色合做流程示意图，以下：

C 端的请求发至云函数 API 网关，网关转发请求至相应的云函数实例，云函数再向后请求服务的网关。整个链条上最大的变化是将云函数取代了node app，成为中间层的技术形态。

使用云函数替换掉 node app，背后的考量有如下几方面，也基本是针对 node app 实践中遇到的一些问题去加以解决：

1. 自动扩缩容

开发者不须要专门去配置，云函数能够本身根据请求量在函数层级水平扩展，正常状况下，一个空的云函数（运行时间 50 ms），300 个并发，压测能够达到 6000+ 的 qps，应对平常的高并发需求基本没什么问题。

2. 函数级别的开发与部署

一个云函数对应一个 gitlab 的项目，函数开发与发布都是围绕单个项目进行 CI/CD，高效、安全。

3. 按需收费

对于金融模式下的流量特色，大部分状况下请求量较少，云函数的使用能够避免稳定的资源投入，空闲状况下费用大大减小。

4. 简单的运维管理

开发者不须要在服务器上本身维护服务和查阅日志，经过云函数的配套工具轻松管理函数、查阅日志，也能够根据本身的诉求设置告警机制。

微保使用 Serverless 技术的整体架构

微保每一次架构的调整，都致力于让各类研发角色的职责更为单1、内聚，角色间更加解耦。但这种调整也须要有配套的工具，其中的 trade-off 须要根据短时间成本和长期利益来衡量。腾讯云Servelrss 云函数很好的支持了本次架构的从新调整。

落地中的问题和解决办法

使用腾讯云 Serverless 过程当中也难免遇到问题。

例如，公司有自建 es 集群，全部日志都会放在es里面，可是云函数的日志没法直接放入咱们es里面，只能存入腾讯云的 cls，这个对于咱们后期日志分析， 告警都很差处理。经过调研腾讯云cls， 发现里面有个挺好用的功能，能够日志投递到 kafka，在经过监听 kafka，咱们将日志成功存入咱们的 es, 且时延保证在秒级。

另外一个日志规范问题, 日志的规范关乎后期日志分析、告警， 可是实际处理中发现日志的元数据信息较少， 好比咱们有版本 tag，云函数绑定了 cmdb 相关信息，这些都但愿在日志中打印出来, 后面咱们发现云函数有个别名字段。咱们在云函数中发现一个别名字段, 经过扩展了一下这个字段，填入了更多信息， 例如版本、cmdb 相关信息，这样在日志里面相关信息也会体现出来。

关于使用腾讯云 Serverless 技术在风控和推荐算法应用的介绍会在以后的文章为你们详细展开，敬请期待！

One More Thing

当即体验腾讯云 Serverless Demo，领取 Serverless 新用户礼包 👉 serverless/start

欢迎访问： Serverless 中文网！