node express的拆分

用node express来做web应用是相当给力的，大概分以下四步走就基本到位了：
1 设计几个静态页面来满足业务功能，获得输入项、展现后台返回数据
2 确认好一些前端调用后端的接口服务，并实现它们
3 登录设计
4 最好根据业务特点将页面和后端调用分下类，页面放在不同的静态目录下，接口也分配到不同的路由下

这样服务器上node app.js就可以提供相应的web服务了，但是这样的话，还是有些不完美。首先这样运行不能充分发挥服务器CPU的并行能力，只会跑在一个单核上，那么在代码里实现cluster或者在外面用pm2来启动不就行了么？是可以的。不过还是不够理想，因为它实际上还是一个单体应用，所有功能紧密耦合，一个地方出错没有catch到，会影响整个服务的。而且要对任意一处的修改，也是会影响整个服务的。
解决方案是拆分为多个express。靠！已经按模块化思想，做成了多个router这种迷你应用程序，效率高，系统资源消耗低，你给整出这种多个完整版的express实例出来，怎么就算优化了呢？
眼光要往远看的，虽然express比router是要多消耗资源，但是也带来了些好处，比如多个express，OS本身就会安排到不同CPU核上去跑，这个调度你是不用考虑的；如果是容器化部署，这些express甚至可以跑在不同的容器上，是不是更high一点了。一个express的运行跟其他的express是没有任何关系的，像故障啊，代码修改啊大家是相互隔离影响的。如果某个服务需要多个实例来承担，就让这个express跑多个进程即可，不用所有服务都跑这么多的进程的。
听起来好像不错，是吧，本来已经是router模块化了，再改成多个express那不是分分钟的事情么？且慢，有两个事情开发人员必须要考虑到，一是express彼此之间不共享内存，相互传递数据得依赖web调用；二是登录认证彼此不互信，你可以考虑使用基于域名的cookie或者用redis来存放凭据，不过最好整一套sso方案或者接入已有的统一身份认证系统，这样不用为每个子应用开发一套登录认证。
整明白了，其实不一定哪种方案就一定比其他方案更优，根据实际情况综合评估，代价最小的可能才是最适合的。