没啥技术含量，主要是说明下几种模式，大家可以参考
前后端彻底分离部署
- 模式一
参考图
说明： 利用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 以及低代码的时代了，越来越多可选的模式可以使用了，但是核心还是基本都是
以上几种，只是托管模式变了（我们关注点不一样了，我们核心是关注业务操作了，其他的平台帮助我们解决了）