第一步部分：后端（因为笔者是做后端的所以放在第一个），前后端的后端分两个部门。

业务处理：里面包含model，算法，业务逻辑，网络通信，多线程，多进程。

web服务器：使用任何能返回json和二进制的数据类型的框架就行。此时不再去控制前端页面的跳转了。

第二部分：api文档服务器。api文档是作为连接后端和前端的桥梁。他定义了各种api文档的请求方式和返回数据的类型。文档室友后端的人员编写。前端根据文档模拟请求数据。最难的地方在于，随着后台的开发，api的接口会进行改变，增加修改删除或者返回的数据发生变化，这些都是不可避免的。那么api的版本问题就给前端带来了问题，明明昨天请求还是OK的，今天就挂了，没有正确的数据，也会影响前端的开发进度。

有人会说放在word或者excel里面文档，那后端每开发或改动一个新功能，都要给前端一份新的api的文档，我们做的就是软件，追求的是效率，岂能容忍这种低效率的事情。

建议自行搭建一个api文档服务器：每一个API文档能够非常容易的定义请求和响应数据结构，最好能够自动生成请求和响应示例，更重要的是，生成的示例必须看起来是符合业务需求的真实数据；支持api版本发布；自动创建版本历史记录，同时要能够非常方便的查看历史版本；能够通过WEB浏览器访问；树形目录结构，方便阅读和搜索；

第三部分：前端（笔者前端功底还是比较薄弱的）：这里的前端是可以独立的，没有后端也能访问，只是获取不到后端数据。既然可以单独访问也就是说他有自己的web服务器，一般webpack和node.js构建起服务器。那么他如何和后端数据进行通信的？当然是通过api文档文档服务器里面的api描述进行数据请求。前端同时控制页面的跳转。

此时会有一个问题，前端和后端都是独立的，那么如何保证他们之间的通信的安全性？

解决方案：基于oauth2的通信，对返回数据进行加密（用AES加密数据，用RSA加密AES的秘钥）

 

利用闲暇时光，对自己的个人网站进行了改版。虽然自己博客没写几篇，但对博客网站却进行了多次改版。转念又想。独乐乐不如众乐乐，于是又开源了出来，供大家学习和交流。这次和上次不同的是，这次使用了Node全栈开发。并且所有代码都开源出来了。相比上次，这次功能也添加了很多，后期也将逐渐完善，长期维护和更新。为此，也打算写一个更为详细的免费的《Node全栈开发——带你从零开发前后端分离的个人网站》教程。敬请期待。接下来将对博客网站进行简单的说明!
运行效果
首页+详情页
编辑器+发布文章
个人信息+后台管理
项目说明
该项目作为一个个人网站使用。不过我的想法是不仅仅是只想开源一个博客网站，进一步说是给程序员打造自己的一片小天地。目前实现了一个博客网站的大部分功能，设计风格参考了掘金。更多功能后续会逐渐添加和完善。和上一个版本不同的是，前端采用了react hooks进行重构,服务端使用Egg进行了重构，是一个完整的js全栈项目。希望能给想学js全栈开发的同学提供一手资料。该项目会长期维护和更新。会逐渐向企业级开发靠拢。欢迎大家学习交流。
项目地址
先贴上项目地址以表尊敬！如果该项目对您有帮助。深感荣幸！动动手指帮忙给个Star吧！
前端地址
immisso/blog-web​github.com
后端地址 immisso/blog-web后端地址 
immisso/blog-server​github.com
关于Demo
后续我会把项目部署到自己的博客网站
柒叶，一叶相思，二叶离愁，三叶久离，四叶惜别，五叶写意，六叶程情，柒叶携手​www.immisso.com
现在该地址上部署的是老版本博客，如果需要看新版本的在线效果可能需要等段时间，空了我会尽快部署上去。
技术栈
该个人网站采用了前后端分离开发模式，前端采用React+antd+umi+dva开发，服务端采用Node+Egg开发，数据库使用了Mysql,使用Sequelize作为ORM来操作数据库。使用sequelize-cli做数据库的迁移。主要功能模块包括如下
前端：
React
Antd
umi
dva
react-markdown
highlight.js
服务端：
Egg全家桶
Mysql
Sequelize
Sequelize-cli
功能描述
该网站最大的一个亮点是，自己实现了一个一款比较好用的Markdown编辑器（因为我找遍了npm官网，也没找到一款好用的react markdown编辑器，所以只好自己实现）。设计风格参考掘金，虽然功能可能还不够多，也不够完善，但是绝大多数情况下是够用的。后续也会在此基础上开发一款教程，用于写教程和文档，类型于掘金的小册功能。下面和就列举一下当前已经实现了的部分功能。
主网站
登录功能
注册功能
文章列表
点赞功能
评论功能（登录用户和游客用户）
一款好用的Markdown编辑器
集成了阿里云OSS上传图片功能
保存草稿
修改草稿
发表文章
个人信息更新
管理系统
分类管理（分类列表、添加、删除）
标签管理（标签列表、添加、删除）
文章管理（文章列表、删除）
评论管理（评论列表、删除）
待开发功能
写教程功能
邮件提醒功能
用户管理功能
主题风格
代码风格
第三方登录功能
功能很多，逐步完善吧！

分离开发就一定得分离发布吗
自从应用前后端分离开发模式以来，分工明确，合作愉快。最近后端一般是用 NET Core 开发，前端使用的 Vue 技术栈。如果偶尔后端人力不足，有点数据库基础的前端工程师还可以拿 Node.js 帮着实现一部分后端需求。移动端的 Android 团队已经精简得只剩下一个人了，只需要维护一个框架应用，处理点硬件调用，把移动端页面往里一套就能解决问题。
各团队已经习惯了分离开发，除了讨论接口设计，其他时候团队间交流最多的可能就是：“API 测试地址是啥，我需要联调一下。”所以各团队也习惯了自己发布，公布地址给其他团队测试、联调。久而久之，居然形成了分离开发就得分离发布的印象。
对于较大型一些的项目来说，分离发布可能是必要的：纯静态的前端部分可以发布到 CDN，后端部分可以发布到多个服务器上外加一层负载均衡。但是对于使用人数不过几百人，并发最多几十人的小型应用来说，就一台应用服务器，把所有东西揉吧揉吧，放一起就能当作一体式开发的 Web 应用发布出来，真没必要去分离。
就上面的例子来说，除了应用后端需要跑程序，需要 NET Core Runtime，另外两项全是纯静态。然而，
A: 另外两项不是静态的，因为要通过构建生成！B: 什么构建？A: Vue 框架写的，需要通过 npm run build 构建了才能发布。B: 那么，构建结果是不是纯静态的？A: 构建结果应该不是纯静态的吧，需要在 IIS 上建站点发布。B: 那么，构建结果直接用浏览器可以打开吗？不用 IIS，只用静态 http-server 可以部署吗？A: 好像可以B: 那就是纯静态！
这是一个插曲，不过这得强调一下，“构建”这一过程的结果，不一定就非得是动态的 Web 应用。我们已经在前端工程化上实践了这么久，应该了解：前端工程化之后，构建的结果是静态的，不需要在服务器上跑程序，只需要服务器按 URL 提供静态资源。
分析下后端应用的发布内容
现在来看一下后端发布的结果(部分)
.../api_publish  |-- wwwroot/  `-- *.dll
程序中，所有 API 都是通过路由中间件解析 URL 之后转发到各 Controller 的。假如发布后绑定了域名 api.project.cn，那么：
//api.project.cn/ 打开的是项目模板提供的一个默认页面，这个页面在 wwwroot 中 —— 对了，wwwroot 就是这个 Web 应用的静态资源目录
//api.project.cn/api/... 这个子路径下提供全套 Web API 服务
因为应用后端目前只提供 Web API 服务，wwwroot 里只不过放了一些没用的静态资源 —— 都是创建项目时模板提供的静态资源，完全可以删得一个不剩。wwwroot 中的内容删干净之后，访问 http://api.project.cn/ 会得到一个 404，但没关系，因为 API 完好！
那么，如果把 wwwroot 里放上前端构建的结果呢？
看看前端项目结构
.../project_root  |-- src/    
这个结构中，dist 目录是 npm run build 构建出来的，这是一个发布目录，只有 dist 中的内容需要部署到 Web 服务器上。
揉一下子
现在把 dist 目录放在后端发布目录 api_publish 中去，改名为 wwwroot，替换掉原来的 wwwroot，Api 的发布目录就变成了这样：
.../publish  |-- wwwroot/    
这个目录在 IIS 里部署出来，直接访问 //api.project.cn/(之前绑定的域名)，我们会毫无悬念地看到前端页面出来了。由于前端页面中 Ajax 调用的 Base URL 都是 //api.project.cn/，所以 API 调用也没有问题。
不过是 Web 应用的主页一般不会通过 //api.project.cn/ 来访问，所以绑定 sys.project.cn 域名来访问。//sys.project.cn/ 没有问题，可以打开页面。之前绑定的 api.project.cn 并未取消，所以 Ajax 调用也没有问题。
注：从 //sys.project.cn/ 通过 Ajax 调用 //api.project.cn/ 可能会存在跨域问题，不过在这个案例中，跨域问题早就处理过了，不细说。
申请 SSL 证书
接下来，开始申请 SSL 证书。如果只申请一个证书(收费证书很贵的)，是该申请 api.project.cn 的，还是 sys.project.cn 的？
不管 api.project.cn 还是 sys.project.cn 都可能在接收到的请求中包含敏感信息，也可能在响应中包含敏感数据。别的不说，Ajax 调用就已经涉及到了两个部分的信息交换，任何一方不安全，整体都是不安全的。
但是只有一个证书，就得放弃一个域名，放弃哪一个比较好？
sys.project.cn 是应用入口，应该告知用户，而 api.project.cn 是在页面中隐含调用的，所以应该放弃 api.project.cn。而放弃 api.project.cn，就意味着需要把 Web API 部署为 sys.project.cn 的子路径中，即 //sys.project.cn/api/。然后把前端 Ajax 调用的 Base URL 改为 //sys.project.cn/api/ 即可。
这不，//sys.project.cn/ 和 //sys.project.cn/api 就把前后端揉合在一起了，搞成一体式发布。
再来个移动端
对了，还有一个针对移动端的前端静态资源需要发布，它和发布应用前端原理一样，但是得发布到 .../wwwroot/m/。问题是，需要以虚拟目录的形式发布吗？
其实这个问题不是难题，纯静态的东西，怎么揉都行。
一体式发布
如果，三端不是同时发布，而是各有各的生命周期，那最好发布成三个目录：
.../publish/api/，部署为 IIS 站点(删除掉其中的 wwwroot 目录)
.../publish/sys/，做成符号链接(Windows 下用 Junction)到 .../publish/api/wwwroot
.../publish/mobile/，可以直接在 IIS 中部署成 /m 虚拟目录，也可以 sys 那样做成一个符号链接
对于多数小项目来说，三端都是同时发布、联合测试的。这种情况下，就可以使用一个构建脚本将前端 dist 、移动端 dist 和 Web API 发布目录拷贝到一起，按如下结构发布：
.../publish/  |-- *.dll  `-- wwwroot/          
分离式开发
一体式发布说完了，再回过头来说说分离式开发。
因为一开始的问题出现在部署的时候，所以我们反推了一体式发布的过程。但实际上，应该反过来，按正常的顺序，从项目开始开发的时候来规划。
项目开始开发，说明它的需求已经确定下来。那么，就基本上能确定用户该怎么来使用它，它应该怎样部署。所以创建项目工作区的时候会想到这样一个目录结构：
.../project  |-- wwwroot/    
然后进行分工计划：
前端一组写 wwwroot，但要把 wwwroot/m 这个目录保留给二组
前端二组写 wwwroot/m
后端组写 project
如果直接在整个工作区中协作复杂度会比较高，而且前端工程师看到后端代码会头痛，后端工程师看到前端代码也头痛。所以拆分项目，同时决定构建方法：
为 wwwroot 创建一个前端项目 web，构建输出到 wwwroot
为 wwwroot/m 创建另一个前端项目 mobile，构建输出到 wwwroot/m
project 从源文件中删除 wwwroot，不关心前端过程
构建方法：按如下顺序整体构建构建 project，并整体发布到 .../publish/构建 web，得到 .../web/dist，将其拷贝到 .../project/wwwroot/构建 mobile，得到 .../mobile/dist，拷贝到 .../project/wwwroot/m/
然后各组领任务，项目技术负责人开始创建项目文件，编写开发规范……

前后端分离开发已成为业界的共识，但分离的同时也带来了部署的问题。传统web模式下，前端和后端同属一个项目，模板的渲染理所当然由后端渲染。然而随着node的流行，以及webpack的模块化打包方案，让前端在开发阶段完全有能力脱离后端环境：通过本地node启动一个服务器，搭配Mock数据，马上就可以进行业务开发了。
但是到了部署阶段，问题也就显现出来：前端最后打包出来的js，css以及index.html，到底放在哪里？静态文件js，css或者图片，我们还可以在CI阶段上传到cdn服务器上，但是最后的html模板index.html一定需要放在一个服务器上，然而这个服务器到底由前端还是后端维护？
前端维护HTML
如果html模板由前端维护，那么前端就需要自己使用一个静态服务器：提供HTML的渲染和API接口的转发。常见的单页应用，也是推荐使用Nginx进行部署。
使用Nginx部署，这里又分两种情况： 
 静态资源完全由Nginx托管，也就是js,css和index.html放在同一个dist目录里。在这种情况下，webpack的publicPath一般不用特别设置，使用默认的/即可 
 静态资源上传CDN，Nginx只提供index.html。在这种情况下，webpack的publicPath要设置成cdn的地址，例如://static.demo.cn/activity/share/。但这又会引发一个问题，由于qa环境，验证环境，生产环境的cdn地址通常不同，为了让index.html可以引入正确的静态文件路径，你需要打包三次，仅仅为了生成三份引用了不同路径的html(即使三次打包的js内容完全一样)
nginx配置
server {
    listen       80;
    server_name  localhost;

    location / {
        root   /app/dist; # 打包的路径
        index  index.html index.htm;
        try_files $uri $uri/ /index.html; # 单页应用防止重刷新返回404，如果是多页应用则无需这条命令
    }

    location /api {
        proxy_pass https://anata.me; #后台转发地址
        proxy_set_header   X-Forwarded-Proto $scheme;
        proxy_set_header   X-Real-IP         $remote_addr;
    }
}
理论上qa，yz，prod环境的接口转发地址也不同，因此你还需要三份nginx.conf配置
后端维护HTML
很多情况下，我们需要渲染的页面带上后端注入的动态数据，又或者页面需要支持SEO，这种情况下，我们只能把模板交给后端渲染。那么后端维护的html模板怎么获取打包后的hash值呢？ 
前端打包后的index.html直接发给后端(简单粗暴，并不推荐)  
前端打包时通过插件webpack-manifest-plugin后生成一个manifest.json文件，该文件其实是个key-value的键值对，key代表了资源名称，value记录了资源的hash
{
  "common.css": "/css/common/common-bundle.804a717f.css",
  "common.js": "/js/common/common-bundle.fcb76db9.js",
  "manifest.js": "/js/manifest/manifest-bundle.551ff423.js",
  "vendor.js": "/js/vendor/vendor-bundle.d99dc0e4.js",
  "page1.css": "/css/demo/demo-bundle.795bbee4.css",
  "page1.js": "/js/demo/demo-bundle.e382801f.js",
}
后端的index.html
<!DOCTYPE html>
<html lang="en">

<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>demo</title>
  <link href="<%= manifest['page1.css']%>" rel="stylesheet">
</head>

<body>
  <h1>demo</h1>
  <script src="<%= manifest['page1.js'] %>"></script>
</body>
</html>
后端通过读取这个json文件，就可以动态渲染出文件的引用路径。
如果你曾经用过百度的打包工具FIS，它最后打包产出的map.json就是类似的资源文件列表。
使用这种方法还有一个好处：前面我们说过，如果文件上传至cdn，那么前端维护的html可能需要打包三次，因为不同环境的cdn地址不同。现在html交给后端维护了，那么这个问题就很好解决，前端只需要打包一次，不同环境的cdn地址可以让后端动态拼接生成。
当然，使用这种方法也会带来一个问题，这个json文件，后端怎么获取？
把这个json文件和其他静态资源一起打包上传到cdn上，后端服务器每次启动时，先到cdn上获取这个json文件，然后存到内存里
wget --tries=3 --quiet -O manifest.json http://static.demo.cn/demo/manifest.json?`date +%s` ## 防止缓存
方案的优点：简单方便，每次前端打包，manifest.json就会自动更新，上传到cdn同时覆盖前一个版本。 
方案的缺点：如果manifest.json更新了，后端则需要重启服务以便获取新的配置，当集群多的时候，重启耗费的代价可能很大。
2. 将manifest.json的内容放在配置中心里，后端则需要接入配置中心。每次CI打包后，调用配置中心更新接口，后端就能自动获取最新的配置。
在我平时工作项目中，这两种方案均有实现。
Node中间层
使用Nginx部署时，为了解决跨域问题，我们一般需要配置proxy_pass指向提供api的后端服务。
后端采用了SOA，微服务的架构时，proxy_pass指向的api服务器，其实本质也是一个转发服务。
前端ajax请求
// 获取商品列表
ajax.get('/api/queryProductList')

// 获取价格列表
ajax.get('/api/queryPriceList')
Nginx转发
location /api {
    proxy_pass https://demo.com; #后台转发地址
    proxy_set_header   X-Forwarded-Proto $scheme;
    proxy_set_header   X-Real-IP         $remote_addr;
}
接口转发到 https://demo.com/api/queryProductList 和 https://demo.com/api/queryPriceList
查询商品列表和查询价格列表其实是由两个不同的soa服务提供：
查询商品: product.soa.neko.com 
查询价格: price.soa.neko.com
因此，本质上https://demo.com这个服务也只是用来转发接口，同时对数据做部分的组装。那么这个服务，就可以用Node中间层来替代。使用了Node中间层，模板的渲染也可以从Nginx转移到Node了。
当然，多了一层Node，对于前端的综合要求也随之提高，后端的部署，监控，日志，性能等等问题也随之而来，全栈（干）工程师应运而生。
工作现状
我司大部分to C的前端项目，都是采用Node层渲染模板加转发接口的开发模式，还有少量项目采用Java tomcat渲染html模板。
大部分页面都是多页应用，并不是典型的单页应用。
Node层渲染模板，又分两种情况： 
需要支持SEO，则采用传统的模板渲染，填充展示数据。但是JS的业务代码，依旧前后端分离，并不在Node项目里。这类页面，一般都是采用Jquery+webpack模块化打包。 
 不需要支持SEO，则Node只渲染一个空html模板，页面内容完全由JS生成。这类页面，一般采用最新的前端MVC框架，比如Vue和React。
当然近几年比较流行的SSR方案，让Node渲染模板时可以直接使用Vue和React的同构组件，直出页面后，用户的交互体验又如单页应用般流畅，只能说：历史总是惊人的相似。
 从某种程度上说，SSR是一种向传统模式的回归，不过这种回归并不是倒退，而是一种螺旋式的发展。
实战
理论知识讲了那么多，现在我们来实战一下。在上一篇
深红：webpack多页面打包实践​zhuanlan.zhihu.com
里，我介绍了webpack多页打包的原理，同时搭建了一个简单的webpack4-boilerplate。这个模板只是一个前端开发模板，其实它还对应着一个node后端模板koa2-multipage-boilerplate。
这个node项目最重要的就是实现了前面说的：如何读取manifest.json文件，动态渲染静态文件的引用路径，从而前后端分离开发和部署。
详情见chunkmap.js这个koa2中间件的源码。
const chunkmap = require('./chunkmap');
app.use(chunkmap({
  staticServer: '//0.0.0.0:9001',
  staticResourceMappingPath: './mainfest.json'
}));
这个中间件接受两个参数 
staticServer：静态资源服务器地址，本地开发时，填写的就是webpack4-boilerplate这个前端项目启动的服务器。到了qa，产线时，则填写真正的cdn地址  
staticResourceMappingPath: 资源映射文件路径，也就是manifest.json文件
本地开发时的manifest.json，不带hash值
{
  "home.css": "/css/home/home-bundle.css",
  "home.js": "/js/home/home-bundle.js",
}
打包后的manifest.json，带hash值
{
  "home.css": "/css/home/home-bundle.d2378378.css",
  "home.js": "/js/home/home-bundle.cb49dfaf.js",
}
使用了这个中间件后，koa的ctx.state全局变量上就带有一个bundle属性，里面的内容是：
{
  "home.css": "//0.0.0.0:9001/css/home/home-bundle.d2378378.css",
  "home.js": "//0.0.0.0:9001/js/home/home-bundle.cb49dfaf.js",
}
然后通过模板引擎，动态渲染出实际页面。当然你也可以在页面中动态生成展示内容，从而支持SEO。
<!DOCTYPE html>
<html lang="zh-cn">
<head>
  <title><%= title %></title>
  <link href="<%= bundle['home.css']%>" rel="stylesheet">
</head>

<body>
  <div id="app"></div>
  <script src="<%= bundle['home.js']%>"></script>
</body>
</html>
总结
前后端分离带来了工作效率上的提高，Node中间层则给前端打开了一条走进后端的道路。当然机遇总是与挑战并存，在前端技术日新月异的今天，真想说一句：老子学不动了！
参考
大公司里怎样开发和部署前端代码？​www.zhihu.com