阅读 6862

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

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

初步规划BFF

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

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

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

也是在2019年7月,搭建了BFF第一个项目(已废弃),BFF公司已经内部自封框架了,我不是公司第一个使用node.js的(但是其他人应该没有前端和我一样吧,连续几个月全部是在做node.js BFF开发)。

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

crazy_coding

编写jenkins脚本,编写Docker脚本部署,由于以前没有接触过这两个东西,所以都是现学现用。

第一个版本上线的时候也踩了不少坑,因为一些Docker相关的服务转发和对容器不是很熟的原因,整体来说上线还算OK。

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

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

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

study

BFF调用中台登录,登录后的权限,用户信息落入Redis,也解决分布式的权限问题,api由原来的20个透传,变成了60个接口左右,其中还有需要有两个登录接口,分别登录到两个不同的系统(P和C),把两个系统的授权信息全部存入Redis,可以说强行解决了用户授权的问题,其实这里我们意识到两个系统不容易融合,所以一直考虑SSO单点登录的问题,花了不少的时间考虑单点登录,但是最终不是我们来做这么事,由其它组的人开一个系统,把两个系统的账号密码mapping存入他们系统,再每次登录的时候去他们的系统寻找mapping关系,如果有mapping,就自动登录另一个系统,也算强行解决了两个系统的登录差异,这里还设计了一张登录记录表,每次的登录信息存入表中。

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

用了三个星期的时间,虽然对C系统的业务没有什么很多的了解,但是把Java语法翻译到JS语法这个工作还是完成了。

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

重新架构BFF层,CBSBFF分开,开始拓展更多的业务系统

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

还有一个很重要的问题就是,BFF对接两个两个系统,以及还有对端的一些api,全都是在单体系统中,需要做架构拆分,于是架构师最后给出了一个方法,先拆成三个服务,一个是BFF代理服务,另外两个,一个对接P服务,一个对接C服务 于是在19年年底,快放假的前两个星期,我开始了改造之路,一边进行改造,一边进行迭代,组人并不多,BFF我在写,其他同事在做微前端改造(感觉自己错过了一个亿的经验值),于是这些事一点点积压的非常忙,有时间就疯狂学习,在家就疯狂写代码。

2020

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

dehiscence

重新架构后带来的好处

面向对象式编程,代码更简洁易懂,也更好维护了。 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 快速上手

666

关注下面的标签,发现更多相似文章
评论