几种前后端分离开发部署模式说明

没啥技术含量，主要是说明下几种模式，大家可以参考

前后端彻底分离部署

• 模式一 
  参考图

 

 

说明： 利用ci/cd 基于nginx 部署静态网站(website 直接存储在nginx服务器中)，接口调用使用独立的api gateway，此方法的好处是不同的团队负责，而且nginx 特别适合前端静态资源，不好的的是
版本很重要（因为独立部署的，做好测试以及版本控制很重要不然配合不好容易ui不能使用报错，当然这个也不是nginx 的问题，核心还是版本控制）

• 模式二 
  参考图

 

 

静态站点数据放s3，nginx 做为cache 以及路由控制，实际上与模式一类似，主要是集中存储了

• 模式三 
  实际上是二的变体，数据直接走s3，nginx 都不需要了，比较适合的场景是使用云端的服务，比如阿里的oss，aws 的s3.。。。 
  因为云端的可靠性以及灵活性是很方便的，比以上中自建的s3 会好很多，而且自建s3一般是不会直接暴露到外部的
• 总结 
  以上几种方式，数据分离比较开的，每个团队管理自己的，但是问题也会比较明显协调以及统一部署很重要，而且彻底分离会有 
  跨域请求的问题，解决方法比较多，jsonp，cors。。。。，当然如果nginx 同时提供了api gateway 的proxy 那么也就没有跨域的 
  问题了，相当与混合一起了，但是独立部署，即有独立的好处，也有统一的好处，就是需要做好nginx 的配置管理，同时本地测试 
  的话，需要结合proxy 进行处理（webpack 就直接支持）

前后端独立开发但是合并部署

• 模式一 
  参考图

 

 

说明：实际上还算是独立部署，但是对于后端包含了一个入口，可以直接引用website 的资源，好处很明显不存在跨域的问题了，静态资源可以放s3
或者自己部署的nginx

• 模式二 
  参考图

 

 

说明：每个服务包含自己的前端（可以独立开发，但是使用一个后端通用的打包集成模式，比如maven使用frontend plugin，打包为jar 包，使用框架自己的resource 处理机制），好处比较明显，版本管理好弄，而且管理体系比较统一，而且也没有跨域的问题了

• 模式三 
  参考图

 

 

说明： 实际上是二的变体，二是让后边做为核心，使用后边统一的ci/cd 体系，三模式是让前端做为核心（一般主要需要使用nodejs一些的技术栈）

说明

以上是几种玩法， 实际上玩法还是很多的，而且现在是一个serverless 以及低代码的时代了，越来越多可选的模式可以使用了，但是核心还是基本都是
以上几种，只是托管模式变了（我们关注点不一样了，我们核心是关注业务操作了，其他的平台帮助我们解决了）