背景
微保前端架构在业务倒退中，依据业务、团队、开发等理论状况，一直进化调整。本文将具体介绍微保前端的架构演进过程，以及团队最终抉择应用腾讯云 Serverless 技术撑持前端架构的起因。
微保团队应用 Serverless 技术的次要利用场景：
- 前端开发同学，利用在 BFF 层，目前接入的有小程序，H5 页面。
- 数据组同学，面向的风控和举荐算法利用，做计算应用。
微保架构 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 技术的总体架构
微保每一次架构的调整，都致力于让各种研发角色的职责更为繁多、内聚，角色间更加解耦。但这种调整也须要有配套的工具，其中的 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 中文网！