写完 Node.js 写 kotlin，越来越觉得之前 Node.js 写出来的项目，都是简单的单体工程，甚至连 mvc 的样子都没有，因为 mvc 规范都没有。

Node.js 这个东西，其实更加适合做中间层，或者说是作为前端开发者的强有力的辅助工具。或者说作为前端开发者想尝鲜后端开发的上手工具。

但如果说追求大规模、工程化、稳定性高的后端，恐怕 Node.js 无法胜任，我感觉到的几个缺点，简单列一下：

1. 就JavaScript本身而言，就有「动态类型一时爽，代码重构火葬场」的苦难（就是我现在碰到的）。

2. 就 mvc 结构而言，没有明显的 mvc 分层，多人维护的话，容易写重复代码，因为很难找到想要的代码，那就自己再写一套！

3. Spring 这一套，用的人多，前人踩的坑也多，有官方维护，稳定度也高（ PS:Node.js 的社区那一套发展迅猛，但稳定性不算高）

所以如果想真正做一个后端开发者，要走的路还太多太多，现在仅仅是入门而已。

今天第一次陪伴部署 SpringCloud项目，陪伴下来体会颇多，深感运维同学的辛苦，有几个坑点，小小地记录一下。

1. 运维的部署配置文件也需要进行 code review「看来并不只有开发需要 review 呀」。

2. 整个公司的项目分为前端、后端，dev【测试环境】 staging【预发布环境】 production【正式环境】 环境的配置文件全都掌管在运维手里，也是一个phabricator的工程（phabricator，代码托管软件，类似于 github、gitlab）。

3. 部署SpringCloud，port需要运维指定，因为整个公司公用一个注册与发现中心（Eureka），开发人员自己指定端口有可能有冲突，而且端口分配可能有分配规则，比如根据项目组分配。

4. 服务间的调用，api层后的网关层来鉴权，我们可以理解为对外暴露的端口，比如9000（那么我们要做的事情还有很多，首先 ①阿里云管理平台首先要暴露；② 阿里云服务器防火墙关闭。部署在集群里的各种服务可以互相调用（端口9001、9002 9003因为端口没有暴露，所以其实是可以互相调用的，只需要通过了9000的验证）。当然，只买了一台阿里云的乞丐版部署在一台服务器也可以，做着玩…

5. 一个服务真正的在跑，需要很多配置，服务本身的IP、port，还要在Eureka上注册，mysql需要配置好，因为mysql redis也是在另外一台服务器上，mysql、redis账号、密码要配置正确；白名单要加上。

6. 运维的工作风险很高，手工操作总有可能出现问题，因为人为的失误造成数据丢失，后果很严重。所以，能脚本化就脚本化，人不可靠。

7. 运维需要7*24小时待命，任意时间段都有可能出现救火的情况，运维和后端一起通宵是很常见的事情…

8. 任何时候的批量修改生产环境的数据，都需要考虑修改失败，数据回退的情况，所以数据备份是一定的，否则数据无法恢复就gg了。

运维辛苦，运维牛逼。