我想寻找一款基于Node.js的企业级开发解决方案类似于 https://github.com/shuzheng/zheng
发布于 1 个月前 作者 stuartZhang 647 次浏览 来自 问答

大家好,

我公司的新项目的正在进行技术选型。所以,我想寻找一款基于Node.js的企业级开发解决方案,类似于 https://github.com/shuzheng/zheng 不用那么地强大,只要有一些基本功能就行。

7 回复

没有这么全的,只有一些 CMS 的,而且并不适合广泛的应用场景,要像这样的,估计要自己搭。其中涉及确实有点多。

我理解。我看阿里巴巴技术博客里提过“大集市模式(集成如数据库、模板引擎、前端框架等功能)”在Node.js圈子里并不流行。相反,插件模式的实践倒是很多。阿里团队给的理由是:因为固定的技术选型会使框架的扩展性变差,无法满足各种定制需求。

我就是不知道如何向我的领导解释。感觉,我要错过一次机会了。

这倒不是,你说的是解决方案,像他这个就是java语言解决所有应用场景。

我的思考如下:

第一,其实用node来做公司所有的技术解决方案其实真的不多,毕竟大公司不差钱,java也是做,node也是做,反正对于老板来说,招的都是程序员,管你写的是冬瓜还是西瓜。

第二,node的开发者远没有java的后端技术功底强(别钻牛角尖,我说的是大多数情况),因为node的开发者大多是JavaScript的使用者,也就是写的前端,前端就这么多知识点要学,后端的知识哪还学的过来,而且java 有众多 apache 企业级解决方案项目,比如 big data 类的,而且 java 编译型语言,速度怎么也比解释语言快吧。也就是说大多数node的程序员,后端的能力不足以搭建一个这样的东西。

我倒是觉得 egg.js + docker + Jenkins 就已经是企业级方案了,(企业级高扩展框架、持续集成、docker 微服务)、docker swarm 其实自带负载均衡的。其他的东西通过 RPC 调吧。

@MiYogurt JAVA字节码也是解释执行的。只是JAVA从源码到字节码的编译过程,使得开发体验更好了。我感觉这个套路很像Typescript。

我所在的公司做html5的人很少。JAVA的开发体验又太爽了。很少有JAVA开发者愿意在html5方面有更多的精力投入。而,作为“过客”,他们写出来的html5代码还不够我后期打补丁的呢。

所以,我想建议领导,使用《Node.js微服务 + 大前端》的方案。这样就能比较彻底地解决我们单位html5人荒的问题了。开发者能够从Node.js的微服务端入坑,从后端向前端,循序渐进地培养与成长。然后,一方面,大数据(分析) 作为 一个独立的“后端服务组件”由专门的,其他的团队去做。WEB APP团队不管那个服务组件,所以是微服务;另一方面,WEB APP专注于

  1. 数据收集,
  2. 业务功能,
  3. 数据报表(即,大数据可视化)

的 实现。然后,WEB APP团队内的同事就能够循序渐进地把整个WEB APP完美地扛起来。

其实,我宁愿后端使用Python。因为缺少强大的Python IDE,所以Python开发者使用Visual Studio Code写JS会感觉更舒服一些儿。可能会增加一些JS的吸引力。

下面是我的设计:

后端服务组件: (就WEB APP团队,这都是黑盒子)

  • Mysql, Redis, Solr, LBS服务组件, 大数据分析服务组件

Node.js微服务:

  • Sequelize(数据库ORM),Redis(连接器),solr-node-clientFollow Redirects(支持301重定向的HTTP Client)
  • Express(Web framework) ,Connect Redis(共享会话管理),Connect SSE(消息推送) ,Passport(登录/单点登录)
  • Handlebars.js(模板引擎;就React/Vue.js/Angular.js而言,这个可忽略,因为React/Vue.js/Angular.js提供了自己的基于Node.js的“后端同构直出”解决方案。如果使用非Node.js的微服务端的话,它们的同构直出就不用想了。)

移动前端:

  • 首选React;次选Vue.js;再次Angular.js;最后 Handlebars.js + jQuery + Bootstrap

PC前端:

  • Handlebars.js(JS技术栈的模板引擎是前后端通用的) + jQuery + Bootstrap + Page(前端路由) + IziToast(消息通知)
  • 动画引擎与库:Instantclick + Velocity.js + Wow.js + Typeahead.js + Slideout.js + Cleave.js + Magic animations

预编译与打包-Client:

  • Grunt — Project build任务管理平台
  • Babel + Webpack — 预编译ES 7 JS到ES 5。目前,预编译后最多可以兼容到IE 8。
  • PostCSS + SCSS — 预编译SCSS到CSS。

预编译与打包-Server:

  • 针对Node.js 6.11.3 LTS版本,JS预编译为可选,因为大部分的ES 6语法已经被完美支持了。
  • 但是,为了享受async/await异步函数语法,需要引入一个第三方库co。直到Node.js v8+版本,async/await异步函数才被原生支持。

代码静态扫描:

  • JS — ESLint 绑定VSCode提供及时的语法错误高亮提示
  • CSS — Stylelint 绑定VSCode提供及时的语法错误高亮提示

IDE开发工具:

  • Visual Studio Code

自动化测试工具:

  • 前端 — mocha + 原生断言API + Chrome Headless
  • 微服务 — mocha + 原生断言API

数据库更新管理:

  • Sequelize Migrations(简单地说,就是:
  1. 脚本化 数据表结构更新的操作。代替了 独立的更新数据库的SQL文件。
  2. 类似Git/SVN,它能够实现 对 数据库表结构的 版本控制。
  3. 它也能够被用来向特定的数据表预添加或删除一些数据。 )

在我设计的架构里,没有提及web socket与著名的socket.io框架的主要原因是:相对于Express与KOA 2框架而言,socket.io并没有提供“后端路由”的功能。但是,作为一款Web Framework,路由应该是它的主要功能(大约得占6成多)。所以,我偏向于使用 Restful + SSE 两个单工通讯信道 来代替 web socket的双工通讯信道。又因为HTTP/2.0协议要求平台底层实现使用“多路复用”技术,所以两个单工信道并不会造成比一个双工信道更多资源消耗。于是,这个 优先降低开发成本的 架构设计 还算是合理。

@i5ting 狼叔,看我上面设计的架构多完善,给个精华,好吗?我单位的技术决策并不能遮盖我设计的架构的光辉。

首先,我认为不是node人荒,而是html5人荒。从我们单位的现状来看,拒绝Node.js的开发者,从一贯的态度来看,他们对html5也是能逃就逃的。

其次,微服务主要是通过RPC做聚合,不涉及后端的高级知识。调用一下Solr,调用一下数据库。基本上,都是陈词滥调的 添删改查。真有些技术含量的业务都被封装成“后端服务组件”了。比如,大数据分析,LBS地理评估,文本检索算法。那才是后端王冠上的大钻石。

接着,WEB APP离不开前端(不包括:后端服务组件),也就离不开“弱类型 脚本语言js”。这是WEB APP项目避不开的 工程难关。与其饮鸩止渴,不如迎难而上,把《微服务的后端》与《前端》作为一个整体,统一地探索与想办法。Python也是弱类型,从工程技术上说,Python把这个问题解决得很成功(通过“约定”)。更何况,目前ECMAScript的社区更活跃,生态更完善。各种代码静态扫描工具还那么地丰富,更可以和IDE做捆绑(做实时错误高亮提示)。前端的Chrome headless自动化测试,后端的mocha与原生断言机制,更是给力。

最后,那些喊node人荒的团队。其本质上,他们是html5人荒。因为这个时代学习html5非常合理的入口 就是 从命令行js开始。话又说回来,学习哪一门计算机语言不是先从命令行小程序开始,再向更高级的GUI领域延展?

@stuartZhang 是的,就是这种困境,前端不精通后端,后端不今天前端,这其实是很正常的事情,前后都精通的人早去做 CEO 了。做报表收集的话,最主要还是前端的 js 按钮进行绑定,收集用户操作信息。其实数据库这个东西把,node 可以读,java 可以读,其他语言也可以 读,跟用不用 node 没啥区别,你也可以用其他语言做客户端,提供 http 接口,所以说数据库是公共的,bigdata 可以用,你这个前端数据收集也可以用,做好分布式就 ok。

目前这个架构不错了,后续可以慢慢升级。

@MiYogurt 感谢你的理解。我在单位里不得志。所以,特别是最近,我经常在论坛上,发发牢骚。我需要说出我的想法。要不然,我就要郁闷死了。

回到顶部