最佳实践

微保 WeSure

最近更新时间:2021-09-02 15:53:55

本文将具体介绍微保前端的架构演进过程,以及最终选择使用腾讯云 Serverless 技术支撑前端架构的原因。

客户介绍

微医保 · 百万医疗险是腾讯控股的保险代理平台微保 WeSure,携手国内知名保险公司为用户提供的一项保险服务,不受疾病种类的限制,可以报销无论是因意外、或因疾病的治疗费用,保额最高达600万。

Serverless 解决方案

微保前端架构在业务发展中,根据业务、团队、开发等实际情况,不断进化调整,微保团队使用 Serverless 技术的主要应用场景:

  • 前端开发同学,应用在 BFF 层,目前接入的有小程序,H5 页面。
  • 数据组同学,面向的风控和推荐算法应用,做计算使用。

微保架构 v1

早期,微保团队使用经典的前后分离架构,前端开发与后端开发通过接口进行合作。合作流程如下图所示:

优势

前后端分离的架构有以下比较显著的优势:

  • 前后端开发解耦
    • 前端与后端开发并行,缩短需求整体开发周期
    • 角色分工明确,线上问题定位与修复更加清晰
      前后端分别设计与实现自己的错误监控和告警系统,前端对页面脚本错误进行捕获,上报至日志平台,经过日志处理工具,设置告警机制,将错误信息推送至相应的开发人员。
    • 利于前端组件化与后端微服务化架构
      前后端分离后,前端可以使用更为便捷的框架以及基于这些框架的基础 UI 组件,大大提升开发效率。另外,前端开发也会基于业务特点,提取业务专属的公共组件,所有组件化的沉淀,都是对生产效率的提升。
  • 部署解耦
    • 前端静态文件单独部署 CDN
      前端项目中有大量的静态文件,包括 HTML、CSS、JS、图片、视频等,将这些文件部署在 CDN 上,充分利用现有云服务的 CDN 能力,既能提升资源访问的速度又能保证资源访问的稳定性,尤其是在高并发场景下。
    • 更加快捷的 CI/CD ,前端的编译过程可以非常简单地接入 CI/CD
      前后端的统一部署相互依赖,分开部署后,可以针对前端项目以 Gitlab 的 repo 级别来做相应的 CI/CD。

前后分离的架构对于业务早期的快速发展非常有效,而且在团队规模较小时,前后端开发人员合作固定,彼此对于对方的开发习惯、性格较熟,因此跨角色沟通的问题并不突出。但随着团队规模和业务规模持续扩大,这种架构模式将会慢慢给团队带来的一些副作用。在实践中,遇到了几个以下比较明显的问题:

劣势

  • 前后端协作耦合成为开发效率提升的瓶颈
    团队规模与业务规模的扩大,意味着合作的人员变多、接口的复杂度也会相应增加。
    早期专人专项,团队成员彼此熟悉其他人的开发习惯和一些业务,因此业务接口参数的调整沟通成本较低。但随着业务规模和团队成员扩充,在各种跨业务合作时往往会遇到一些同事不习惯阅读 proto 文档,或有些复杂业务需要花费大量时间阅读 proto 文档,或前后端反复沟通接口调用时参数的具体含义等问题。如下图所示:
  • 页面渲染效率较差
    以产品详情页为例,页面的渲染至少需要请求5个后端接口,再对数据进行组装和处理。不仅增加小程序端的代码体积,同时也降低了页面渲染速度。
    即使在前端页面对接口进行并行访问,但数据的整合逻辑依然会非常复杂。小程序作为微保主要的产品承载形态,代码量巨大,几近达到微信规定的代码上限,这种对于代码的增加随着业务增长也是一个隐形的风险。如下图所示:

微保架构 v2

鉴于上述微保架构 v1 阶段前后端合作模式中的痛点,团队对架构再次进行优化,原则是业务“前”移、核心下沉。在前期的各种业务支撑中,团队积累了一些业务中台的经验,例如投保服务、续保服务、保单服务等。

中间层的引入让团队的开发效率进一步得到提升,前端对于业务的把控力及页面性能优化的操作空间也大大加强。不管是从团队的敏捷性、还是应用的体验,都有不错的改善,主要体现在以下几个方面:

优势

  • 前后端流程上的耦合大大减小,角色责任的专一性逐步形成
    基于一部分后端服务能力的积累,例如保单相关的需求,在需求评审及开发过程中,只需前端开发同学参加即可。前端开发同学与业务产品沟通业务逻辑,在 API 市场或服务文档查询相应的服务能力,完成业务开发。同时对于团队逐步开展业务中台化、前端组件化大有助益,整个架构对于丰富多变的业务需求的响应更敏捷。
  • 渲染层对后端的服务进行聚合,减少页面请求
    无论是 H5 网页还是小程序页面,均只需跟中间层进行数据交互,前端开发人员根据业务诉求,自行对接口进行聚合,端上只需1个请求就可开始渲染页面。接口聚合之前,产品详情页面的显示需要请求5个接口,平均的接口请求耗时在120ms左右,聚合后,通过中间层来请求5个内网接口,避免端与服务的多次连接耗时。
  • 中间层对数据进行加工,大大减少小程序端的逻辑代码量
    之前在小程序端的数据整合代码,有些复杂的逻辑,可以交给中间层处理,这些代码的节省对于业务持续增长时会越来越体现出价值。以年金产品详情页为例,数据在中间层聚合能够节省10KB左右的体积。

中间层的引入是对生产力的进一步解放,但基于一个巨型 App 的 Node 中间层,在后期运维中也暴露出一些问题。中间层的应用部署在2台云服务器 CVM 上,有其先天的一些不足,主要体现在以下几个方面:

劣势

  • 应对尖峰流量的冲击能力差
    微保经常会有一些运营和投放需求,这些事件会导致瞬间的大流量进入,而云服务器 CVM 的扩容速度相对滞后。
  • App 级别的部署与发布
    中间层不断积累业务代码,整个应用线性增长,每次部署与发布都是巨石应用的发布,部署效率低、风险高。
  • 使用门槛提高
    前端开发人员在开发、测试环境中需要自己在机器上查阅日志和服务操作,提高了普及的门槛。

微保架构 v3

基于上述微保架构 v2 阶段的一些限制,微保开始关注新技术,加州大学伯克利分校计算机科学 Riselab 团队的实验室研究室提出 Serverless 是云计算的下一个浪潮。国内各大厂商也都开始布局 Serverless ,腾讯云 Serverless 团队是国内较早在这方面进行部署的团队,技术已经非常成熟,在数百家企业已有成功落地实践。

微保通过调研了解到腾讯云 Serverless 云函数的优势:

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

综上,基本解决了微保架构 v2 中面临的问题。经过团队整体评估,微保决定使用腾讯云 Serverless 云函数进行架构的进一步调整。调整后的角色合作流程示意图,如下图所示:

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

使用云函数替换掉 Node App,背后考虑有以下几方面,也基本是针对 Node App 实践中遇到的一些问题去加以解决:

  • 自动扩缩容
    开发者无需专门去配置,云函数可以根据请求量在函数层级水平扩展,正常情况下,一个空的云函数(运行时间50ms),300个并发,压测可以达到6000+的 QPS,基本能够应对日常的高并发需求。
  • 函数级别的开发与部署
    一个云函数对应一个 Gitlab 的项目,函数开发与发布都是围绕单个项目进行 CI/CD,高效、安全。
  • 按需收费
    对于金融模式下的流量特点,大部分情况下请求量较少,云函数的使用可以避免稳定的资源投入,空闲情况下费用大大减少。
  • 简单的运维管理
    开发者无需在服务器上自己维护服务和查阅日志,通过云函数的配套工具轻松管理函数、查阅日志,也可以根据自己的诉求设置告警机制。

Serverless 优化业务架构

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

目录