2018-01-12北京Node Party

发表于 更新于
本文字数： 8.5k 阅读时长 ≈ 14 分钟

这里面我觉得最诚恳的是介绍运营开源项目的；libuv那块则是激励好好学习的吧哈哈

开场：观众的互动（观众自我介绍活跃气氛）

  1. 有一个22岁的，15岁就辍学了！然后还修过车，高考还失败，结果现在是某个公司的大前端技术负责人，以前还“当过CTO”
  2. 还有一个在汽车修理厂干过的…
  3. i5ting自己介绍自己：
    1. iOS什么的都干过
    2. 后来去天津，当CTO，人比较难招。然后期间就开始“布道”，就这样开始把自己变成了Node.js布道者
    3. 然后介绍了一下大会的内容等。

MQTT（讲的不太好，没听懂，就是介绍了他们公司的一些实现）

  1. 北京新浪的前端工程师
  2. 小爝也在新浪

简介MQTT

  1. TODO: 少了一张图
  2. MQTT 发布订阅范式，，机器对机器的互联网协议
  3. 协议轻量，体积小，可以保证低网速下也能准确送达，不会丢消息。

如何和Node.js结合

  1. aedes
  2. 几百台机器 -> 高并发，这就是他们的工作的重点
  3. 做成平台，可以服务整个公司。

通过group分离业务

长链接服务

  1. 1.0的话有缺陷
  2. 2.0
    1. 引入API服务，作为server和broker之间的桥梁
      1. publish接口：注意到实现里用new Date()加了时间戳
      2. receive接口：拿redis的消息队列，所以其实是一个轮询。
    2. 加入Qos1服务
      1. 用aedes-persistence-redis，但是这个东西比较简单，只适合小的规模，所以要改造。
      2. 同时，在集群下多节点写入redis有逻辑错误

解决Qos1的bug

  1. 读写分离

运维和部署

  1. 用了docker。可见docker技术真的很有必要学习。
  2. 日志是通过pm2的log机制做的。他对js的性能比较吃，并发量高的时候会影响node的性能。所以log不要太多，打关键的即可。

结尾

  1. 丢出了自己的微信二维码
  2. 但是改成了支付宝的icon来搞笑（假装）
  3. 新浪移动招Node.js工程师

评价

  1. 本来是拿来做im的
  2. 是一个非常快的实现方式
  3. aedes作者是Node.js Core的一个性能专家，非常的厉害

docker的实践和原理

张晋涛

  1. 网易有道

为什么使用容器

  1. 实际工作上，我们常有多种技术栈和框架；服务的部署和依赖可能会比较复杂。比如Node、Python、Java、Go
  2. 机器环境也可能很多，比如物理机、云主机
  3. 隔离掉基础环境，由此让彼此交互更加统一
  4. 避免出现：“为什么在我电脑上是ok的，但是在你的电脑上不行”

什么是docker

  1. 一开始是为了管理容器
    1. 容器，其实是没有实体的
    2. 2008的时候，LXC出现了，代表容器技术的出现
    3. 当时docker就是把LXC包了一层，后来加了.libcontainer，后来捐出去变成了runc
  2. 现在的作用：在一个容器里安全的去运行一个application
  3. 已经成为一个平台

开始使用docker

  1. run
  2. –rm 参数：关闭的时候会删除，仍在磁盘里，但是占用的CPU/内存被释放，当前是stopped状态，可以再次回到容器里
  3. –i：可以使用标准输入输出
  4. –t：会有一个tty

dockerfile

  1. 就是一个文本文件
  2. 可以通过build命令通过它构建出镜像

缓存构建系统

  1. 记录每一步的hash值，这样就不会每次都重复已经有的了

多阶段构建

  1. 前端的部署，我们要么就是上传到CDN，要么就是直接一个dist交付，更经常的就是nginx弄一个反向代理。
  2. 也可以弄一个dokcer容器，一样使用nginx，然后把端口暴露出去，其实很不错。

应用在自动化上

  1. 我们需要更加自动的东西，不管是啥，比如GitLab CI、jenkis等等。
  2. 即使你使用github，一样可以利用gitlab ci来做
  3. 在docker里跑一个docker——这是啥目的？TODO:

docker的架构

  1. docker命令其实就是一个cli

docker engine的架构

  1. docker build其实就是存到dockerd
  2. 某个机器的dockerd就可以用来做镜像仓库，单节点，没有高可用
  3. dockerd就是一个简单的服务，和containerd交互

关于debian和ubuntu

  1. ubuntu的镜像，是把debian的testing分支放到源码里，然后发，所以它版本更新很快，包也很新
  2. 但是ubuntu的测试时间却不够长，所以做了debian的稳定性高一点的。

如何做好一个开源项目（讲了很多好东西，是我收获比较多的三个点之一）

梁灏(hao第四声)

  1. 15年入职的talkingdata，这几年都在做iView的开发
  2. toB的公司，主要专注PC段
  3. 个人喜欢Mac的游戏，所以iView的大版本都是游戏名
  4. 他基本全职在做这个，真的是得到领导很多支持，很少做业务开发
  5. 前期借鉴ant design的风格，后来慢慢走向小巧

iView的故事

  1. 当时想问Vux作者问题，就利用支付宝捐了一杯咖啡（和微信不同，捐了之后可以加他好友）——真机智啊
  2. 当时拘泥于公司只用vue.js 1.0，后来有一个杭州的哥们给他们提了一个很大的pr，他们并没有直接使用，但也因此花了两周更新了2.0

走上开源

  1. 个人开源会比较少，公司为主体比较多，因为还是要服务公司嘛，公司也是你第一批的用户
  2. 先在小的项目里试用，然后逐渐在公司里推广起来。这时候争取leader的支持是很重要的。

持续运营

  1. 在社区发软文，做营销，他们当时差不多做一次能增加500 star，没错，开源是需要你去发软文运营的，毕竟star能让人更感兴趣。
  2. 需要注意的，是首先要保证质量，这样才有口碑
  3. 不要小版本都发，要言之有物。虽然主要是更新日志，但是要学会讲故事，来吸引人。
  4. 瑞典那边有法律：如果要把开源用在生产，开发要先在那个开源项目上修bug！
  5. 持续运营关注的平台：掘金、知乎、v2ex、开源。
    1. 掘金，对开源比较友好，你第一次发布开源项目，他还会帮你推
    2. 如果你刚加入知乎，可以投稿到某个专栏去。比如前端之巅。不然你一个新人，没人看。如果有大V点赞，就更可怕了，知乎就是这样的环境，大V效应出众
    3. v2ex：就是火的社区，没啥多说的。
    4. 开源中国：一般都会在上面同步一份
  6. 做活动：
    1. 开始前就要去散布消息
    2. 活动开始的时候现场还要有人去负责互动，带动节奏
    3. 活动结束后，要赶紧加班，把图文总结出来，作为二次推广。

国际化

  1. 做到一定程度就要考虑国际化了。
  2. 语言包配置文件，这种做法就不错，还可以利用社区贡献——毕竟你自己不可能了解太多。
  3. 文档也要支持国际化，最基本是英文了。
  4. 前期投入很多，但其实是一次性的工作。而且收益很高，以后更新自己稍微改改很快的。
  5. 沟通问题：通过GitHub把仓库授权过去后，就可以通过gitter来沟通了——可别以为国际上你还有微信qq什么的。要专业点。
  6. 运营一个官方Twitter，也可以交给国外的友人去运营。
  7. 还有现在火起来的discord，这个也很好用，而且不会被墙。——一个闭源免费实时通话软件

让更多的人参与

  1. 哪怕别人就帮你改一个标点，只要merge了，他就是一个贡献者——很多人就是这么干的，去知名仓库刷贡献。
  2. 成员也不应该直接commit，而是应该提pr，让owner来判断。这样避免单个pr考虑不周全引发其他问题，让知道的更多的owner来负责，认真review。
  3. 给issue打标签。这样关注的人会更加明确自己可以做什么。
  4. issue hunt去悬赏！现在Ant Design用的就很多
  5. 每个版本发布的时候要有release记录，不仅记录日志，并且让watch你项目的人，能收到推送，更会打一个tag，让贡献者方便切换过去。
  6. 每次发布后，再写下一个的草稿，这样下次发布的时候会更快一点
  7. 版本号的讲究：X.Y.Z。Z就是bug，Y就是功能增加，X则是破坏性的更新，可能会导致不兼容。

让Robot来做“坏人”

  1. Issue一旦多起来，会让维护者承受太多的压力
  2. GitHub还有block功能可以拉黑一些用户
  3. 如果Issue问了和项目无关的问题，你如果用一个官方的身份去干掉他，可能还会追问很尴尬。所以建立一个Robot小号，给他权限，去关闭那些不友好的issue。
  4. GitHub是有提供Api的，让你判断是“bug report”或者“feature request”，它只认可这两种。
  5. 还可以把中文的Issue自动翻译成英文！

开源寻求赞助

  1. 本身就是一个比较功利的事情，所以并不羞耻，而是理所当然的可以寻求支持和回报
  2. 比较简单粗暴：二维码打赏。但是在国内哈哈哈，经常收到1分钱也太尴尬了。只能指望铁粉。
  3. TODO: 国外的open client tive？听不清可以转到paypal里。但是各种手续费，emmm
  4. 投放广告：carbon ads，比google ads区别在于，可以定制，不至于发生样式或者风格差距很大的问题。不过可能会导致加载很慢。
  5. 最好的是寻求品牌广告了，比如掘金，还有那些教育平台。这些和技术相关的，他们也乐于接入。
  6. 在v2ex，可以在边上看到互联网广告，你可以主动去联系这些金主。

开源寻求商业化

  1. 你在同类产品里做到很好，就会有资格这么做，一切的前提都是你主要的项目做得好。不然只会得到diss
  2. MIT开源协议
  3. 能付费的肯定是企业用户而不是个人用户（不用于商业化那也没啥好收费的）
  4. 一个好的产品，是技术+咨询服务。你的咨询和售后也很关键——他们公司很多大佬来自oracle，所以深谙软件商业。
  5. 比如iView，可以推出一些生态产品，去收费。或者提供更高级的后台模版、im系统等等。

梁提问的环节

  1. iView的组件非常丰富，而且细节很多
  2. iView的日期选择器可能是全球最好的。还有键盘的可访问性，又比如颜色选择器也有键盘的可访问性。这都是国外的人（2个瑞典的长期贡献者，他们还对自动化测试非常重视）贡献的，因为国内大部分都考虑好看和可用，但是国外却会考虑很多很多。
  3. 毕竟是专做to b业务的沉淀
  4. 还是会继续专注pc端，因为移动端其他的已经做的挺好的了，所以暂时不会像ionic。

中午休息

圆桌会议环节

i5ting主持聊聊未来的发展，只抛出观点，不做结论，总结18年，放眼19年

嘉宾介绍

  1. justjavac（这老哥…增高鞋啊，好大的）
  2. 王䶮（yan第三声）
  3. 城池（花名）。阿里云高P，负责的东西很多。
  4. 小爝，在新浪，5年了，之前在阿里和国美也干过。

框架没有什么太大的变化，很多基本框架的周边封装

  1. 小爝

    1. 不接业务线的，主要是对开发做一些东西。大部分都是基于原生的JavaScript在写工作。

  2. justjavac

    1. 黑了一把Angular
    2. 趋同，比如Web Component。又比如写法上，Vue要学React的hooks。
    3. 黑了一把Vue，出身是低配Angular，降低了入门门槛，然后现在又学React
    4. 之前用jQuery是为了浏览器兼容性，写Web Page，都是多页，是给人“看”的。
    5. 现在三大框架发展了，大家都在做Web App了，是给人“用”的了
    6. 推崇React是一个很伟大的框架。
    7. React和Vue的区别：原理层，更新机制，本质上虽然都是数据趋动Dom，但是diff机制不同。React是set新状态的时候虽然它知道哪个变了但是假装不知道，而是去检查Dom是怎么变得（虚拟Dom）；Vue检查的是状态，直接从状态层做脏检查，和Angular一样，就知道是哪个Dom变了，所以和React不一样，不是那么纯的View层。
  3. 城池
    1. 说到easywebpack，你们听过dawn吗？封装了各种中间件，你只需要配置。
    2. 有人关注serveless，最开始是亚马逊提出来的
      1. function as service（fas）
      2. backend as service（bas）：把后端服务全部做成bas提供给你，比如数据库，你就只需要调服务，但是不用管数据库的知识
    3. 我们很多时候也在考虑，Node.js代替PHP和Java到底有多好？
    4. GraphQL，16年就提了，现在还没火，在很少场景下使用。但是apollo和它搭配，就可以不用改后端的代码了，就很赞。
    5. 吐槽Node.js方向招人难
    6. “企业数字化转型”。IT解决的是效率问题，数字化之后，前端可以做的更多，结合serveless之后，泛前端的概念。为业务赋能能更多。

ts现在挺好的，那么前景如何

  1. justjavac，现在有这么一些场景
    1. 项目直接用ts写，那么深度就很高
    2. 写一些库/组件，写完原生，再提供一个ts的文件。
    3. 他们项目里用的很多了
    4. 推崇了VSCode和全宇宙最强的编译器visual studio
  2. 小爝
    1. 他们那边的ts已经落地，手机App里的hybrid的开发，用Webview加载网页而不是rn或者weex，原先用zepto，后来换成vue。并且全部转ts
    2. 类型强制，所以bug减少了。对代码质量提升对人的提升都不错。当然对人的提升，还需要一些制度和工具的约束，比如文档制度
    3. 觉得thinkjs eggjs这些流行的nodejs框架但是性能多少有些问题。自己基于koa2开发了一个，但还没有开源，koa2的分层比较浅，他自己两周都写完第一版了，用ts写的
    4. 全埋点链路的sdk现在也用ts写了
    5. 推荐大家19年开始学着写ts

19年的规划

  1. 小爝
    1. 前端是为业务做支撑的。
    2. 业界会关注框架等，但是前端包括了方方面面很多的
    3. 前端有很多薄弱的事，比如监控的问题。但是目前监控问题做得好的并不多
    4. 吐槽chrome有点以前ie的意思了
  2. 王䶮（yan第三声）
    1. 腾讯刚成立了一个技术委员会，所以可能会有新的东西出来
    2. 吐槽了ant的彩蛋问题
  3. justjavac
    1. 也干了很多前端的监控问题
    2. 性能、bug等
    3. ES6和ES5的性能问题

deno的事，提到justjavac给deno提了很多pr

  1. justjavac
    1. 不兼容npm生态，但是兼容浏览器生态，也就拥抱了web的那些规范，但是目前很多不符合web规范
    2. 目前性能没法和node抗衡
    3. http服务目前的数据只有node一半，但是因为是rust，其实应该有很大很大地空间
    4. 有些库用ts写，但是这样会导致js来用这些库地时候，是要报错地——而且没有编译机制，所以会在运行时才报错

关于大前端

  1. justjavac
    1. 比较喜欢大前端，只要和view层相关的都是，所以是大前端
    2. 技术栈。比如缓存，缓存的头肯定是服务器输出的，那么这个应该是前端还是后端学？
    3. 认为和view相关的所有技术，而不是所有的技术，是大前端。
    4. 浏览器性能优化，如果后端是php，那么你还得和php合作才能
    5. 现在有了node，但是其实node算前端的，因为和view层相关
    6. 已经不是仅仅调下页面了
  2. 王䶮（yan第三声）
    1. 举例ssr的时候的cookie path，很多东西都要关注，所以排查问题需要不仅仅是页面知识
  3. 小爝
    1. 东西太多学不过来怎么办，到底学不学，全栈？
    2. 先定个目标吧，未来三年你要成为什么样的人。这样你才知道你需要什么知识。

框架工具的问题

  1. 小爝
    1. 用好一个，了解下原理就可以了。
    2. 做个选型，用现成的就可以了，没必要自己造
  2. 王䶮
    1. 想要一套代码用在所有地方，甚至想做一个sdk来实现，其实是很难的事情

重新认识nodejs后端开发（有很多的代码例子，很赞）

兴百放

  1. 去哪儿4年，然后加入了美团
  2. 所以今天大部分的内容基于去哪儿的工作

基于nodejs做的事

  1. 场景1：比如前端吐槽后端响应太慢，后端吐槽前端加字段——前后端分离，各个公司都有不同的做法
    1. 在前端和nodejs端之间的问题
    2. 用户信息 -> 权限信息 -> 页面信息，于是导致对视图文件的侵入
    3. 前端是webpack，node端是koa/express
    4. manifest.json
  2. 场景2：比如Api的微服务
    1. 实现功能单一，所以可以任意组合
    2. 怎么组织，不可回避的问题
    3. BFF（这和d2里的某一个演讲有点关系啊），很理想，不过现实也很骨感。降低了沟通成本，但是没有统一的拆分标准，学习成本也高。

BFF实践经验

  1. node和java通信：HTTP、Dubbo、Thirft
  2. Api聚合，减少网路开销
  3. Api设计原则，合理设计，规范格式，提供mock
  4. 和GraphQL结合

Nodejs框架选择

  1. koa/express
    1. 没有约束和规则，只能口头和readme，
    2. 团队合作成本高
    3. 扩展能力弱
  2. 企业级框架thinkjs/eggjs
    1. 规定了很多东西，让你能专注业务开发
    2. egg生态比较好，插件比较多

Nodejs模版引擎

  1. 必须要在维护中
  2. 门槛要低
  3. 文档详细
  4. 使用率高
  5. 提供了常用功能，减少自己的冗余代码
  6. 根据上面这些，handlebars.js、nunjucks、pug就还不错，ejs星还是少了。
    1. Pug其实就是之前的jade，书写HTML标签不太符合大众的书写习惯——通过缩进等
    2. Handlebars.js，提供的功能太基础，需要你自己写很多helper，也缺乏一些比如截断字符等功能
    3. Nunjucks是分享者推荐的，稳定

前端和后段静态资源的关联问题

  1. 分享者的需求场景：
    1. 同一个后端关联N个前端
    2. 降低耦合（webpack/模版引擎/其他构建工具）
    3. 诉求简单——加载静态资源
  2. egg-manifest插件和egg-view-asset差不多

异常处理

  1. 前端很少有人有意识去判断。因为后端有一套规范去做，但是前端没有
    1. 什么时候去try catch
    2. 什么时候throw
    3. 什么时候不做？
  2. 操作错误就应该给用户抛出，比如
    1. 读取某个io文件
    2. 发送网络请求
    3. 无效的用户输入
  3. 编码错误（bug）
    1. 参数类型/个数不匹配
    2. 读取变量undefined了
    3. 调用异步函数却没有回调

编写健壮的代码

  1. 函数功能单一，便于测试
  2. 明确错误类型
  3. 处理错误
    1. 操作错误，类型明确，直接处理；不明确就记录并传递
    2. 程序错误，直接崩溃
  4. 传递错误
    1. 同步函数，直接throw；使用者，try catch
    2. 异步函数，当然是经典方式callback（err, result）
    3. EventEmitter
  5. 使用ts避免一些非常低级的bug（毕竟公司都有bug指标呀）
  6. 使用async/await的语法（node现在对promise支持也好多了，用这个写起来也很直观）

应用监控

  1. TODO: 不太敢用findbug，因为毕竟是第三方
  2. 应用程序级别
    1. 应用错误数
    2. 接口消耗时长
    3. 接口异常信息
    4. accesslog
  3. 前端页面级别
    1. 脚本全局错误
    2. 静态资源加载
    3. 异步接口错误
    4. 页面渲染时长等
  4. watcher系统
  5. 日志系统
    1. KAFKA
    2. 每个公司可能都有自己的方式

SSR实践

  1. 他们弄的很简单，避免找错太难，自嘲并不高大上
  2. 他们是多页面，毕竟是市场活动等。用mobx
  3. react的多页？这有点意思。
  4. ssr怎么处理动态拿屏幕宽高？——服务端不能直接读，要拿agent，还要写个component来对付他，写个sniff注入到高阶组件传给客户端
  5. egg监控的是app的路径，但是这里如果有前端也有后段，你不重启node监听不了前端的变化。所以需要监控来自动重启。这应该是开发的时候。
  6. cookie传递非法字符问题也要处理

浅谈Nodejs异步那些事

宋光宇

  1. 360的奇舞团
  2. 月影那个团队的人
  3. 以前也做过ssr和首屏幕渲染方面的事儿

从异步操作说起

  1. network、filesystem、setTimeout
  2. 从fs.readFile说起
    1. 这个是js实现的
    2. 但是逐步看源码会走到c++部分了

libuv

  1. node主要就是libuv和v8模块
  2. 支持跨平台的异步io，也被很多其他框架使用

异步i/o模型

  1. BIO/NIO
    1. Block io，有阻塞，
    2. No Block io是针对单文件用的
  2. asynchronous I/O（aio）
    1. 业界只有把它叫做异步，其他都是伪异步（有用户介入）
    2. linux里没有选择。因为linux下会极大增加编码困难，兼容性低版本linux也不支持aio，所以直接线程池

Node.js到底是进程还是线程

TODO: 4个线程池

执行顺序

  1. 了解node和libuv之后，才好能大概弄清，起码是说清机制
  2. setTimeout/setInterval
  3. process.nextTick
  4. setImmediate
  5. Promis.resolve().then

Node.js是异步吗

  1. 对于开发者而言，是异步模型（虽然会被吐槽伪异步）
  2. 擅长海量I/O场景吗？
  3. cpu密集型何去何从？c++模块