node.js BFF开发8个月的心路历程

忙碌的日子老是过得特别快，回头一看，我已经作node.js BFF开发8个月了，基本上没写过web前端的事情，作了大半年，写篇文章来记录一下我这大半年的心路历程。

初步规划BFF

其实我刚进公司那会是作前端的，作B端前端开发，用react画页面，系统是一个持续作了一年多的，超过上百个模块的系统，画了2个月，项目人员调用，我进入移动组，参与移动端的开发，从新开发 Hybrid App，而后当时认为还有h5，小程序，因此当时画架构图，我把多端也考虑进去了，当时领导提出须要作BFF接入到中台到端，然而没有当时预料的多端，只有愈来愈壮大的BFF。

初步使用node.js，BFF的起点

2019年7月，搭建了前端Vue项目，写好了公共方法，另外的同事他们都是作IOS和Android开发的，因此没有使用过Vue，搭好了项目库框架，封装了request，utils,等一些公共方法和样式，编写了两个页面，剩下的页面就先让他们开发。

也是在2019年7月，搭建了BFF第一个项目（已废弃），BFF公司已经内部自封框架了，我不是公司第一个使用node.js的（可是其余人应该没有前端和我同样吧，连续几个月所有是在作node.js BFF开发）。

第一个版本特别的简单，纯透传，当时的写法是每个api都定义了一个router，而后 转发到另外一个服务上（暂且叫P服务，缩写的第一个字母），数据所有来源自中台，P系统在客户端没有请求后得20分钟后Session过时，因此这里只能把用户密码落入session中，透传发生401时从新使用用户帐号密码解密。

编写jenkins脚本，编写Docker脚本部署，因为之前没有接触过这两个东西，因此都是现学现用。

第一个版本上线的时候也踩了很多坑，由于一些Docker相关的服务转发和对容器不是很熟的缘由，总体来讲上线还算OK。

BFF拓展到了CBS层，也开始变得真正有价值，也开始有了踩坑

CBS customer business System
开会时leader们都是这么叫的，我预计应该是这个意思

大概是10月份左右，咱们接到了新的任务，接管另外一套系统，融入到咱们的App，从前端到后端（C服务）都要咱们写，这时候我开始看Java代码，用Node.js重写后端逻辑，也开始须要有了更多的后端的东西，Mysql,服务发现,日志，Redis缓存层，BFF鉴权，还提到了cmq(消息队列)，这些阶段我开始疯狂的学习相关后端的东西。

BFF调用中台登陆，登陆后的权限，用户信息落入Redis，也解决分布式的权限问题，api由原来的20个透传，变成了60个接口左右，其中还有须要有两个登陆接口，分别登陆到两个不一样的系统（P和C），把两个系统的受权信息所有存入Redis，能够说强行解决了用户受权的问题，其实这里咱们意识到两个系统不容易融合，因此一直考虑SSO单点登陆的问题，花了很多的时间考虑单点登陆，可是最终不是咱们来作这么事，由其它组的人开一个系统，把两个系统的帐号密码mapping存入他们系统，再每次登陆的时候去他们的系统寻找mapping关系，若是有mapping，就自动登陆另外一个系统，也算强行解决了两个系统的登陆差别，这里还设计了一张登陆记录表，每次的登陆信息存入表中。

因为对Redis，Mysql，和mq消息队列不太熟悉，因此在开发的时候也算苦不堪言，天天加班作业务，上下班作地铁，到家后就疯狂学习相关知识，在使用Redis的时候发现本身对数据结构的了解太少了，由于本身不是计算机专业，对数据结构的知识只有JS数据类型这么多，因而还花了时间去学习数据结构和算法，主要是数据结构方面的东西。之前听都没听过消息队列，即将要用了，仍是要学习学习，数据库也是接触的少之又少的东西，从语法到B+树，简单的都了解了一下，语法学习了一下，数据库仍是很菜，稍微复杂一点都得查。

用了三个星期的时间，虽然对C系统的业务没有什么不少的了解，可是把Java语法翻译到JS语法这个工做仍是完成了。

期间部署踩了无数的坑，好比：咱们的程序须要部署到多个地域，在深圳地域没法拉取到北京地域的镜像，最后让运维帮我把镜像复制到深圳镜像，并告知之后须要在另外一个平台去推镜像。如今属于流程不规范。还有其余一些坑，没少麻烦架构师帮忙看问题，（也很感谢架构师

从新架构BFF层，CBS和BFF分开，开始拓展更多的业务系统

一段时间内相对平稳作迭代，这时候架构师开始对咱们组进行要求，全部的日志必须齐全，公共组件的接入也必须规范化，同时个人代码开始被code Review，review的时候我被吐槽的不要不要的，具体问题有：语法太过于疏散，面向过程开发，习惯了function开发方式（面向过程），须要更规范的面向对象，以及全部的异步我基本都是使用了try catch包裹，一方面语法太难看，一方面不利于采集日志（这里我同架构师商量过了，也迭代了内部框架，直接调用，由框架进行错误捕捉，同时不会报出一些英文/代码错误的单词）。

还有一个很重要的问题就是，BFF对接两个两个系统，以及还有对端的一些api，全都是在单体系统中，须要作架构拆分，因而架构师最后给出了一个方法，先拆成三个服务，一个是BFF代理服务，另外两个，一个对接P服务，一个对接C服务 因而在19年年末，快放假的前两个星期，我开始了改造之路，一边进行改造，一边进行迭代，组人并很少，BFF我在写，其余同事在作微前端改造（感受本身错过了一个亿的经验值），因而这些事一点点积压的很是忙，有时间就疯狂学习，在家就疯狂写代码。

在2020 年的2月份，具体就是上个月中，这三个系统上线了，上线过程当中不算顺利，原本半分钟就能启动成功的容器，两分钟能切换的转发，由于一些别的配置，上了两个小时......

从新架构后带来的好处

面向对象式编程，代码更简洁易懂，也更好维护了。 100%原汁原味的Airbnb规范。 拆分红了三个服务，三个服务迭代开发互不影响，互相发布部署也各不影响。 新框架迭代后日志更全了，rpc调用日志，db操做日志，三方调用日志，api访问日志，对于错误记录不再用慌了。 新框架的服务发现采用中用到了多进程模式，也不会由于服务发现而影响主线程的逻辑处理。

从新架构后我遇到的鉴权问题

不一样服务之间如何对客户端的请求进行鉴权，好比我如今手头又新启了一个积分服务，这个积分服务的逻辑比较复杂，和中台的交互较少，和数据库的交互比较多，数据是本身存取的，因此也就是接口除了提供给App，还须要提供给B端管理平台，这时候管理平台的鉴权和APP的鉴权是不同的，须要调用B端系统来作管理平台的鉴权，鉴权经过后我才能给数据，同时APP的鉴权（虽然APP的鉴权也是我写的，但是不在这一个服务上，我仍是须要调用另外一个服务才能达到鉴权的目的），以为有一些繁琐，我想大厂里成百个系统必定不多是这么鉴权的，对接起来会累死。这一点目前尚未想到好的解决办法。

node开发的优势

第一优势固然是 JS语言的优点，语法上上手的成本很是少。 以前咱们是考虑了多端的场景的，多端在这里依然是优点，中台只须要给出一份数据，BFF能够根据不一样端给出不一样数据 适用nodejs作接入层很是合适，开发迅速，部署方便，成本极低 前端开发的时候老是要和后端沟通字段的问题，CBS给出的接口基本上是彻底对照页面给的，跟我基本上不须要沟通字段的问题，一方面BFF能够作接口聚合，多个接口的数据放到一个接口上，客户端减小请求次数。 这种趋势愈来愈流行，好比小程序云开发，Serverless 超轻量级服务，在一些业务场景中仍是很适用的。

槽点

Node.js的学习资源仍是太少了，好比我在学习Redis的实战教程的时候，就只能看Java版本的，学习RabbitMq的时候也是Java的。我看的数据结构和算法教程也是Java的，固然这个可能你们都是看C的，但我不会C，就很无奈了，固然书籍有JavaScript版本的，你们感兴趣能够本身看。
实战方面的踩坑，我也踩过很多，好比使用node图片处理，这方面我也是踩坑了两天才上手了。node-canvas 生成营销图。

可是，做为一个开发工程师，除了开发的能力，还要具有工程师彻彻底底的折腾主义精神。奥力给。

总结

这段时间的node.js开发，接触到了许多前端以外的东西，借着这段时间也把后端的一些知识简单的学了一下，后端其实也有不少东西，远不止我提到的这些。 对异步编程的理解也更深刻了，对于nodejs的了解也不是之前的demo级。 虽然有学习资源相对较少，但仍是不影响node.js性价比很强的事实，内存使用不多，CPU占用也很小，这一点对于企业来讲也很重要，资源就是钱。

性价比体现能够看Node + MQ 限流小计，虽然没有体现出极致性能，但仍是能够看得出一些效果的。

路漫漫其修远兮，吾将上下而求索

---

其余连接：

github博客：欢迎star，一块儿学习，一块儿成长

KOA 中间件机制和实现

Nodejs 操做 RabbitMq 快速上手