puppeteer服务模版工具链研发

[huenchao]

puppeteer是什么：

puppeteer是一款google开源的nodejs库，它提供了高阶API来控制chromium内核的浏览器。

puppeteer能做什么：

1. 可以生成页面快照或者pdf。
2. 可以做网站爬虫。
3. 可以做预渲染、SSR等。
4. 可以做e2e测试、性能测试、兼容性测试、谷歌插件测试等。

现状：

现有的成果：我们在b端的业务需求中，几乎把puppeteer能做的事情全都做了。 现有的困难：虽然它功能很强大，使用很便捷，但使用它的过程中，我们总会遇到一些问题或者说考虑以下问题（当然不仅限只有以下几个点）：

• puppeteer本身的现有的bug。(案例：可以搜的到的去github issue看bug标签)

• DevTools协议相关的问题。（案例：DevTools不支持file协议，所以别指望用puppeteer去做组件包测试的问题、低版本截图可能会出现空白：https://bugs.chromium.org/p/chromium/issues/detail?id=848161）

• 浏览器版本、兼容性相关的问题。(不熟悉浏览器启动参数组合配置，不清楚内核升级后的兼容性问题，例如chromium71后，不允许修改host等头部)

• 服务内存、日志、错误定位，排查，处理体系的问题。（怎么更友好的把服务与公司的监控体系结合在一起使用？案例: 下面就是多进程配合puppeteer使用导致的内存泄漏问题,僵尸进程的问题一直没能有效解决。首先，你没办法登上到服务器上看具体情况，第二错误不好复现。）

• 多进程的调度管理问题。 (案例: 我们每次开启、关闭一个浏览器的开销其实很大的，最好是利用websocket连接一个运行的chromium实例，跑完就断开连接，这样浏览器一直开着，只是需要程序连接上去的开销而已。这个在单pod上玩没有任何问题，一旦扩容会出现ECONNREFUSED的问题。报错日志大体如下所示，这个问题我暂时也没能解决：

  { Error: connect ECONNREFUSED 127.0.0.1:39491
   at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1107:14)
  errno: 'ECONNREFUSED',
  code: 'ECONNREFUSED',
  syscall: 'connect',
  address: '127.0.0.1',
  port: 39491 })

• 服务规范、维护、研发体验和效率的问题。（案例：目前我们nodejs关于网络监控中间件的使用方式直接在应用层上做cat打点，应用层代码级别的问题，导致应用层以下的问题，更多是依赖运维发现，因为应用层以下出现的问题，基本不会在应用层上被捕获。所以你去观察cat监控日志全都是没问题的。下面是levi-api服务网关层的抓包截图，出现TCP rst，最后导致的网关层连接失败，但levi-api服务完全感知不到。因为我们服务发送rst之后，应用层根本没机会处理，cat对http request打点的代码都不会执行到。
  

• 测试和部署相关的问题。（目前node服务全部基于pm2部署，egg这种自带多进程管理模块的需要单独配置，不方便）

• 服务间（包括跨语言）消息调度的问题。(http、mq、rpc)

现状与需求碰撞在一起后：

就拿用puppeteer爬虫举例，我们其实就想利用这个工具模拟浏览页面，把需要的页面内容copy下来，但是每次开发都要去写一套服务代码，而且几乎每次需求都可能又遇到未知的坑：

• 如果爬虫需求有一些特殊限定，比如浏览公司c端页面，安全希望我们走内网，我们就要给浏览器请求上设定内网host，从而我们就要关心不同浏览器版本支不支持这个修改特性，如果之前没有接触过，程序报错的error信息文案，根本想不到是因为浏览器的限定。
• 如果线上爬虫存量很大，我们就需要想办法开多进程去跑，我们开发就要关心僵尸进程的问题，oom的问题等等。
• 爬虫任务完成后，上下游消息交互方式又要去处理，当然最简单的方式是http相互调用。但是如果处于某些原因我们被要求rpc通信，mq通信，作为一个前端node开发，又要去关心这些事情。
• 等等等等。

怎么提高开发体验、效率、减少心智负担？

• 有一个合适的cli工具：用它可以直接创建一套容器模版，我们期待这个容器模版帮我们处理了前后端通信问题，多进程调度问题，代码覆盖率问题，本地调试的问题、mock的问题、单元测试等等。（工程化的cli可以参考create-react-app、egg-bin等，求脑爆）
• 可维护、可扩展机制设计：现状上面提到的一些问题是我工作中遇到的问题，有些解决了，有些依然没找到合适的方法解决，解决方法或许通用，或许不通用。当我们有了一套合适的开发cli工具后，我们如何沉淀我们遇到的问题和解决方案，我个人觉得像strap、egg这种插件机制挺好用的（求脑爆），总之，我们需要出一个渐进式的机制设计，不断完善我们的cli工具和生态。
• 错误、网络监控：梳理一遍现有公司架构提供的可用工具，结合实际和使用体验和案例，把好用的、直接能用的集成到模版里，把没有的，急需的整理出来。举个例子，针对我们这个模版框架，我们就很关心内存问题，我们怎么监控内存，发现内存异常后，开发怎么能快速定位到oom、memory corruption 发生的原因？因为有时候可能真的检查不出来你的代码错误。因为他从逻辑上完全是正确的，造成oom的原因是gc内存的速度慢于你消费内存的速度。我希望是有一个，或者多个工具组合，可以把错误产生的链路复现出来。
• 如何无感升级、降级、切换应用的底层依赖？比如dockerfile的选择、浏览器版本的选择等。（本地开发无感切换？线上部署无感切换？不会造成break-change。）

讨论&&目标：

PS:设定讨论范围,我个人认为我们是要设计或者说是整合出一套针对puppeteer应用的框架。所以，对于存储、会话管理、安全等等不是重点讨论范围，但框架模版的设计，要很好的兼容这些场景的接入。

• 模版研发（根据具体需求选择合适的dockerfile【puppeteer版本、浏览器版本】、合适的进程调度方案，上下游服务通信机制，监控报警，日志采集，模版提示，帮助开发选出合理的模版）？模版内的研发约束(测试方案、lint、dockerfile、gitlab issue提交规范），统一部署方案。
• 怎么去做统一的升级、降级？如果我在开发中，发现我的需求需要某些依赖降级或者升级，怎么不破坏代码，最小侵入的一键式升级、降级依赖，我们这里的依赖不单单指npm包。
• 如何把监控和框架强依赖、无感。
• 错误日志过滤、整理。因为很多puppeteer触发的报错，举个例子，报错信息是page crash，造成的原因可能是 chromium bug, OOM, memory corruption 等等。
• 关于测试，我们真的关注测试的范围是什么？能不能收敛测试的范围，不要让调试链路这么长。
• 研发的辅助工具，那些好用的，适合引入的。不止是帮助写代码的。
• 每个点需要多少人力时间，有哪些可以从开源中抄的？那些是已经有的，并且真的好用的。先筛选，再抄，再自己研发。

目标就是让开发只关注puppeteer能做什么？尽最大可能的让开发和部署保持一致性，你可以理解它几乎是一个小FasS平台，让交付保持一致性。

[huenchao]

周二(今天)16:00～18:00 23楼6号会议室，大家有时间针对这个主题进行一次简短的讨论吗？

讨论的主要内容是：

1. 以puppeteer为解决方案的nodejs模版建设，目标让开发测尽量少考虑需求以外的事情。

2. cli的建设，目标是让开发更标准化，不仅限于(代码覆盖率、单元测试、e2e、常见问题提示、依赖升降级)

3. 公司现有的监控平台有哪些？监控手段有哪些？ 能不能复用或者抽取部分功能设计成容易帮我们定位pptr服务的。我们监控的重点在于内存+网络，因为docker可以保证交付的一致性，但是底层依赖的宿主环境线上和本地还是有差别的。我们如何通过内存+网络的数据结合错误堆栈，分析、过滤、总结问题发送的来源。

4. 本次讨论内容限定在45分钟内，内容结果和过程将会以RFC的形式，记录在issue中。

[huenchao]