20200604 - Wordsworth

[vianvio]

问题列表：

1. 简历中提到的前端架构轻便，具体指什么？怎样定义和量化轻便？
2. 对于前端工作流：需求=>接口制定=>编码=>产品验收=>测试=>二次验收=>灰度发布=>全量发布 a. 接口制定后如何保证编码前后端并行？做了哪些具体方案？ b. 灰度发布如何实现？ c. 线上稳定性如何监控？ d. 监控信息存储链路是怎样的？数据量过大如何处理？埋点丢失怎么办？跨域如何处理？

[wordsworthW]

简历中提到的前端架构轻便，具体指什么？

以下只是在开发过程中的一己之见，希望您多多指点。

1. 新工程搭建的便捷 定制化 cli 生成模板，移动端、后台目前各有一套自己定制化的符合公司业务的架子。新项目启动时，不需要再重复的配置冗余 webpack 配置项了，同时架子支持灵活的拓展，目前足以支撑公司的业务。

2. 二次封装组件库的使用便捷 公司项目多是vue框架下的项目，之前一直想推进公司的自由UI引擎开发，但一直没有落地，索性就将 element-ui 一个稳定版本做了二次封装，同时做了一套后台列表页、详情页的模板引擎，减轻了产品和设计的工作量，同时又能产出一致的后台样式及使用风格。

   <!-- 列表页模板示例伪代码 -->
   <template>
   <导航栏 :内容="['首页', '基础数据', '互斥关系', '互斥体检项']" />
   <搜索栏>
   <标题>提交筛选</标题>
   <内容>
       <搜索标题>搜索：</搜索标题>
       <搜索栏 类型="输入框"></搜索栏>
   </内容>
   <操作>
       <按钮 类型="筛选"></按钮>
       <按钮 类型="重置筛选"></按钮>
   </操作>
   </搜索栏>
   <列表>
   <标题>体检互斥关系列表</标题>
   <表格 :绑定字段="['编码', '关系命名', '包含体检项目', '创建时间']" :请求接口=“/xxx/xxx”></表格>
   <操作>
       <按钮>查看详情</按钮>
       <按钮>禁用</按钮>
   </操作>
   <分页></分页>
   </列表>
   <插槽></插槽>
   </template>

3. 工具库的整理和维护提供开发便捷 前端工作做了多年，在业务开发中国年整理了许多结构短小精干的便捷函数，相对于类似于underscore实用库显得更加轻量级，同时又可以加入自己在公司业务上的一些深度定制工具库函数。 小程序场景的封装，比如支付宝小程序、微信公众号，其实有一些成熟的功能可能多个项目都有藕合代码，将他们抽离出通用逻辑，这样不同项目只需要直接使用即可，大大减少了开发成本

4. 自有组件库的维护贴合业务 公司移动端、后台有蛮多组件其实都是通用的，之前利用了一些碎片的时间索性就整理了一套公司的公共组件库，基本涵盖了公司大大小小的业务。每次的更新迭代也会同步的实时更新文档，前期很难，越到后期维护起来越是得心应手，同时真的切身的减轻了开发量

怎样定义和量化轻便？

以我工作过程中来谈，

• 定义：

可以更加专注于业务本身，而不去考虑一些重复性的样式算法逻辑工作，同时保证高质量降低返工或BUG风险。

• 量化：

因为所处公司都不是太大，所以人力成本一直是比较艰难的。

1. 多个项目的解耦与内聚过程，更能解放团队的劳动力，轻量化团队。

2. 技术人员大多都想有一部分时间做自己的学习整理过程，就一直协调前端团队在老项目中找到最优解，把怎么能让自己不再重复以前做的事。

3. 分出时间成本微重构项目，把之前能做的更好的地方做好，什么地方可以单独提出来，什么地方以后可能在用的到，同时也保证了产品质量，并且不用再去返工修改。

[wordsworthW]

接口制定后如何保证编码前后端并行？做了哪些具体方案？

1. 产品需求会后，相关前后端开发人员会在一起加一个接口协调的会议。包含旧接口的修改，新接口的字段定义，以及复杂业务逻辑是否需要前端进行分担

2. 前后端协商出接口格式，并产出接口文档

3. 前端开发页面，同时根据接口文档生成mock模拟数据 后端同步进行接口的开发

4. 每天利用10分钟的晨会协调中间出现的问题，比如接口某些字段难以如期给出，或者前端缺少交互用的某些字段需要补充

5. 前后端会在排期接近尾声一起过一下真实数据，由于mock产生的数据尽可能贴近真实数据，所以仅仅需要很少的时间就可以交付

以上过程比较适用于小团队开发任务，已经按照这种模式进行很长时间的磨合了，前端质量很高，同时又帮后端进行了一轮测试前的预演

灰度发布如何实现？

前端灰度发布策略：

1. 没加入埋点之前： 存在两套环境，一个正式环境与一个灰度发布环境 公司项目都是以vue框架下的单页面应用为主，并且未使用服务器渲染。使用 nginx 判断变量 upstream 到不同 server，前端入口一般都是一个 html 文件，后再去加载各种静态资源，通过对入口文件的控制，结合 nginx 方案可以做到很好的灰度和 A/B 测试方案。

2. 加入埋点之后： 由于埋点产生用户标识uuid以及用户特征（UA、cookie、IP、位置、使用频次及使用场景）。 又由于公司业务后期加入渠道概念，每个渠道有一个唯一的key，所以加载项目时都会预先加载一个配置接口。 入口文件加载的manifest.[version].js文件在后台配置版本号，同时根据客户端发来的用户、渠道等信息，可以定向的让固定人群固定渠道看到指定版本的产品。

线上稳定性如何监控？

1. 服务器方面: 公司项目倾向于低运算，高I/O的业务场景。实时监控服务器的CPU负荷、内存使用情况及网络流量情况，对CPU使用大于50%，内存占用大于80%，流量大于历史时间段30%以上做了钉钉报警以及公司所有技术负责人的邮件通知。

2. 前端方面 2-1 埋点网络监控 埋点已经稳定上线了小半年，已经可以得出现有业务每天的PV／UV访问数学模型，每15分钟会进行该时段下的数据统计，并套入实时的数据进行模型推测。对严重偏离预测的统计结果进行实时上报，同时对业务时间段15分钟内不产生访问的情况进行技术部全员警告推送。 2-2 异常捕获 在项目中独立引入一个报错监控的 JS 来单独的完成对整个项目的监控，对前端代码抛出异常的位置进行现场保护及数据推送。 a. 使用window.onerror捕获JS运行时错误 b. 使用window.addEventListener('unhandledrejection')捕获未处理的promise reject错误 c. 重写console.error捕获console.error错误 d. 在跨域脚本上配置crossorigin="anonymous"捕获跨域脚本错误 e. window.addEventListener('error')捕获资源加载错误 f. 重写window.XMLHttpRequest和window.fetch捕获请求错误

监控信息存储链路是怎样的？

数据量过大如何处理？

1. 前端采用Math.random()条件进行无差别的过滤 优点：实现简单，同时可以显著的减小服务器压力 缺点：对于想要的关键数据进行了无差别过滤，对于轻度偶发的数据无法进行大量收集

2. 服务器开启一个采样控制器，可以动态的调整流入数据 优点：可以灵活的控制什么样的监控数据、埋点数据流入，从而精确命中想要拿到的数据 缺点：服务器压力过大，没有从根本上减轻服务器请求数据

3. 方案1和方案2的折中 服务器开启一个采样控制器，监控实时流量，产生一个控制阀值 前端首次打开加载这个控制阀值，同时设置这个控制阀值的失效时间，开启随机过滤 优点：动态且显著的降低了服务器流入流量，又不会固定的漏掉过多的有效数据 缺点：仍然存在漏掉实际想要的数据，可以提高请求优先级绕过随机过滤

埋点丢失怎么办？

1. 服务器存放了客户端产品完整的路由地图，在缺失了1-2个路由信息时，可根据路由地图补齐埋点路径，同时根据上下路径可以补齐一些埋点信息。

2. 由于自用的埋点系统使用了 navigator.sendBeacon 给服务器发送数据，该API存在无应答机制，某些时候用户页面切换过快可能存在乱序问题，所以在每个埋点信息发送时都带了该数据的序列号，服务器做分析时会根据该序列号进行排序。 客户端保留埋点的完整备份，当用户在某个页面停留1min以上同时浏览页面数大于3时，判定为该埋点为有效数据，开启定时器将客户端埋点信息的完整备份发送给服务器，服务器根据当前唯一标示判断redis缓存中该次埋点是否需要补齐。

跨域如何处理？

埋点服务和异常捕获服务，从下边两种方法解决跨域。

1. 在 Githubissues.

2. Githubissues is a development platform for aggregating issues.