大家好，
我公司的新项目的正在进行技术选型。所以，我想寻找一款基于Node.js的企业级开发解决方案，类似于 https://github.com/shuzheng/zheng 不用那么地强大，只要有一些基本功能就行。
我理解。我看阿里巴巴技术博客里提过“大集市模式（集成如数据库、模板引擎、前端框架等功能）”在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专注于
- 数据收集，
- 业务功能，
- 数据报表（即，大数据可视化）
的 实现。然后，WEB APP团队内的同事就能够循序渐进地把整个WEB APP完美地扛起来。
其实，我宁愿后端使用Python。因为缺少强大的Python IDE，所以Python开发者使用Visual Studio Code写JS会感觉更舒服一些儿。可能会增加一些JS的吸引力。
下面是我的设计：
后端服务组件： （就WEB APP团队，这都是黑盒子）
- Mysql, Redis, Solr, LBS服务组件, 大数据分析服务组件
Node.js微服务：
(数据库ORM)，
（连接器），
，
（支持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（简单地说，就是：
- 脚本化 数据表结构更新的操作。代替了 独立的更新数据库的SQL文件。
- 类似Git/SVN，它能够实现 对 数据库表结构的 版本控制。
- 它也能够被用来向特定的数据表预添加或删除一些数据。 ）
在我设计的架构里，没有提及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。
目前这个架构不错了，后续可以慢慢升级。
