一个好的技术架构可以帮助开发者高效开发和定位问题。这个系列是我总结的组里的节点架构。这种架构是经过时间和用户验证的，所以兼具稳定性和合理性。不过也有可能是我在简化架构的时候埋了一些坑，欢迎大家提出。作为“服务器”，最重要的功能就是接受请求并返回响应。系列的第一篇文章是介绍架构，搭建一个可以运行的服务。Architecture设计一个程序，分为几个模块util-toolmiddleware-custommiddlewaremodel-modelservice-各种服务接口controller层-处理业务router-路由层-apis(method,path,controller,role,des)-page(path,controller,view,role,des)可以看到有一个请求进来1.首先会经过路由层，路由匹配不上响应4042.middleware层是一个中间件层，主要是用于各种请求的通用处理逻辑（登录状态验证、权限验证、通用变量挂载等）3.然后进入controller层真正处理这个请求。4.请求处理完成后，如果是页面请求，则返回视图，如果不是，则返回json数据。5、中间件层和控制器层都会用到util工具类和logger日志管理这两个模块。这两个模块其实是独立于这个系统的，可以在任何系统中使用。根据图中可以看出controller层会引用service层，service会引用model层。让我们看一个例子。一个好的团队应该根据业务类型和紧密度进行分类。比如systemA系统负责用户相关，systemB系统负责文章相关，systemC系统负责产品相关。1.不是只有一个节点系统负责那么多功能，节点不适合场景，必然会出现系统与其他系统的交互。而系统难免会提出完整性等要求。因此，需要将请求交互封装成一个模型。除了上面的模型，用户模型也可以封装成模型，文章模型也可以封装成模型，产品模型也可以封装成模型。而且它也可以用模型层来完成。写在一处代购可以让用户自动登录。2、有了模型层，为什么还需要服务层？服务可以特定于业务。比如服务层的接口可以是用户名更改、用户等级修改、文章发布、文章评论等，其实是否需要细分为服务和模型，取决于模型的细化程度。例如//ModelsystemA.jsconstmd5=require('md5')constrequest=require('request')classsystemA{constructor(){}request(opts,cb){vartime=newDate();varsign=md5(time+'secret_key')if(opts.qs)opts.qs._sign=sign;request(opts,(err,res,data)=>{if(err){cb(err)}else{cb(null,data)}})}}module.exports=systemA//Serviceuser.jsconstapi=require('../model/systemA')api.request({url:'http://127.0.0.1:8000/home',qs:{a:6}},(err,data)=>{})本篇介绍各层的定义，下篇结合代码搭建系统
