HTTP基础系列之：一文搞懂URL

将上例的 indexhtml 改造成如下形似：

再在 nginx 的 proxy_pass 配置成它所代理的 SpringBoot 的真实访问路径。例如：

简单起见，我们这里的 Spring Boot 就运行在本地，并占用 8080 端口。

在结合上述的配置，意味着我们在页面发起的 >

对于前后端分离，认识上有个误区，那就是很多人自称：我们老早就分离了，全AJAX，使用Angular或者什么什么就可以了。

这个说法是不合适的，打个比方，别人问的是“如何解决家禽把蛋生在水草边的问题？”，但实际上人家养的是鸭子，答题的却是养鸡的，所以回答“不让去水边就行了”，这显然不在点子上。

这两年业界说的前后端分离，是限于偏展示类的系统（用A代替），而不是应用、管控类Web项目（用B代替），在B类项目里，前后端是天然分离的，对此，除了

少部分后端开发人员，基本所有人的认识都是一致的。上一段中这样回答的人一般都是只做B类项目，在B类项目里，前后端分离是共识，不需要讨论。

那么，剩下的问题就是讨论A类项目的前后端分离了。这个问题的核心在什么地方呢，在于模板的与数据结合的位置，以及，模板的控制权在谁手里。经过这两年的讨论，基本上我们可以达成的共识就是：模板应当由前端人员去控制，主要原因有两方面：

-性能优化（尤其是外部资源的管理与发布，请求合并等等）

-协作的顺畅性（已形成模板的界面片段的返工等问题）

那么，模板到底应该在什么地方跟数据结合？

这个问题就比较折腾了，有部分人尝试像B类项目那样，使用js模板，然后在浏览器端执行，这是存在一些问题的，比如说seo不友好，首屏性能不够，尤其对于首页DOM量很大的电商类网站，差距很明显。

所以我们还是得把主要的模板放在服务端来执行。在这个过程中，阿里作了一些尝试，那就是引入Node层，在这一层把模板与数据进行合成，然后浏览器拿到的就

是生成好的HTML了，但也不是所有HTML都是这么生成好的，还是会有一些内容等到了浏览器之后，再用js去加载和生成。

所以这一定会是一个混合方案，同一个系统中存在两种模板，一种在服务端执行，一种在浏览器中执行，互为补充。

至于说这个方案中，是否中间层一定要是node，我觉得无所谓，只要是能正常做web项目的东西都可以，这个还是要看所在企业的技术积累方向，当然node

做这块是有一些优势的，比如对前端人员的语言友好性，前后端模板的通用性等等，但这些都是细节，重点还是整体方案和流程。

这时候回头看你问题中的这句：

>前后端分离的意思是，前后端只通过JSON来交流，组件化、工程化不需要依赖后端去实现。

我相信你这里对前后端的限定是以浏览器为准的，但事实上，A类项目中，前后端的分界一定要延伸到服务器端的模板层，也就是在这一层里，把各种来源的数据整合到模板中，这个数据未必是JSON格式的，会存在有JSON，XML，特定的二进制等等。

组件化这个话题就更复杂了，在刚才组织形式中，很难说出究竟什么才是组件。是某个商品的模板吗？是数据吗？是数据和模板的结合体吗？没法回答。在此，我说一句自己的看法：像电商这种项目的前端部分，基本不存在组件的概念，甚至不存在组件化的价值，因为这里面可复用的东西太少了，也不易提取，大多数东西都是不带逻辑的界面模板。

最近因为ReactJS的流行，带来了一个Isomorphic的概念，这是一种很有意义的探索，但是否能解决这类问题，尚不得而知，根据我的理解，它对B类项目是较好的补充方案，但对A类项目暂时还缺乏可用性，因为A类项目中，运行期的DOM变更并不多，多是整片的改变，用这个方案去解决的话，有些牛刀杀鸡的感觉。

关于B类项目的组件化，我之前那个没写完的系列是关于它的，但经过最近一年多的思考，我又觉得需要再重新写一篇东西了。感谢你的问题提醒了我，这就写。

1单体项目是否需要采用docker进行部署
2如果采用docker部署是否有必要采用docker-compose进行服务编排？

答案是也许有必要，也许没必要，docker的优势很多，但是对于垂直架构的项目优势未必那么明显，总之一句你需要根据自己的项目情况去考虑。笔者之所以会写这篇文章，大概率是基于省事的目的去部署一些小的项目。同时也是提供一种前后端分离的项目的部署方案(但绝对不是最有方案),以及在这种模式下的docker如何去工作才能达到我们的目的。

然而最终的目的是为了偷懒，省事。让前后端分离项目的部署方式变的简单。就也许在这种模式下，你只需要5分钟就可以实现部署，或许吧，不妨把这个当作一个目标。

本文目标:

上图将部署流程分为三部分，本地开发环境，阿里云容器镜像服务，以及linux服务器。下面分成三个部分对上图进行说明，工欲善其事，必先利其器。先进行说明，后面才能对每部分做的工作比较清晰。

本地开发环境分成三个项目

先解释一下图中的相关名词

容器镜像服务，分门别类的存储我们的镜像 。这个是镜像服务的唯一用途，就相当于maven的仓库是一样的。

我们也可以搭建自己的私服仓库，例如开源的harbor等，都非常好用，在企业中用私服会比较多。

首先我们需要在linux服务器上搭建Docker环境，也就是我们在linux上有一个docker。再将我们的镜像运行在docker上。

从上图我们发现在docker上运行这很多容器，mysql，redis，nginx，pitaya-java,pitaya-admin,pitaya-h5

然而我们的容器是需要通信的，例如:大家都知道pitaya-java是一个springboot的项目，他需要访问mysql进行数据存储服务，需要访问redis缓存我们的令牌信息等。

也就是说，我们运行的这些容器之间是要相互能通信的。所以我们在docker上创建了一个内部网络叫做pitaya-network，他在172200这个网段，我们需要我们的容器都加入pitaya-network这个网络，并且分配固定的IP地址,指定固定端口。

为什么需要分配固定IP地址，指定固定端口 因为我们的容器也可能会和服务器一样，会挂掉，如果随机分配的话，创建新的容器，IP地址可能会变，我们容器间不能通信，例如java服务访问不了mysql，这样我们的线上就无法提供客户正常服务了。

本文我们做一个大概的概述，针对上面的结构以下问题是我们急需解决的？

其实针对java项目和vue项目制作镜像方式不同，但是原理一样，原理无非就是基于docker build这个命令制作镜像，但是java的镜像制作和推送可能更加简单，只需要一条命令即可，因为maven提供了制作镜像的插件。这些内容在下一篇文章都会涉及到！

想要表达清楚一键事情是非常不容易的事情，特别是通过文字，既不想废话连篇，又想表达清楚真的很难，因为细节比较多！然而我觉得弄清楚大方向是非常必要的，然后再进行分解，希望能说的明白，我会加油的，如果写的不好也希望大家原谅！

1、代理多个前端服务：

2、前后端or多个后端结合代理
增加相应的location
访问的时候后面添加对应的路径 ：
如下图
访问 16168139227:8082 默认会代理到16168139227:8085端口
访问 16168139227:8082/img就会自动代理到16168139180/img下

---