(个人经验分享)网站部署历程[2023.1更新]

本文分析本人从懵懵懂懂买了个云服务器一直到现在为止，网站部署方面所经历的升级
适合为那些还没开始或者刚刚开始，迷茫的朋友们，稍微指一下路。

无域名时期

刚买了一个云服务器，在里面安装了tomcat，将自己的项目打包传上去之后，就能通过IP[+端口]访问了，那个时候对于tomcat配置，最多只会改改端口号而已，因为也不太会写应用，所以满足一下自己的好奇心就够了，没有去买域名。

买域名啦

拥有了自己的域名之后，高高兴兴将域名解析到服务器，结果发现居然要备案！备案虽然现在已经很简单了，但是对于新手而言还是很麻烦的欸，第一次备案前前后后花了1个多月的时间完成啦。

不同域名对应不同tomcat应用

总不能一个域名下的所有三级域名都对应一个网页吧？所以在刚开始我是通过tomcat自身的server.xml中配置不同的host来区分不同应用的，比如如下这样：

<Host name="localhost"  appBase="webapps" unpackWARs="true" autoDeploy="true">
    <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs"
                   prefix="localhost_access_log" suffix=".txt"
                   pattern="%h %l %u %t &quot;%r&quot; %s %b" />

</Host>
<Host name="yionr.cloud"  appBase="webapps" unpackWARs="true" autoDeploy="true">
    <Context path="/" docBase="/usr/local/tomcat/webapps/ROOT/" reloadable="true" />
</Host>

<Host name="upload.yionr.cloud"  appBase="webapps" unpackWARs="true" autoDeploy="true">
    <Context path="/" docBase="/usr/local/tomcat/webapps/upload/" reloadable="true" />
</Host>

效果就是访问yionr.cloud时会指向ROOT应用，访问upload.yionr.cloud时会指向upload应用。如果需要更多的话直接复制粘贴改name，改docBase就行了。

将http访问变成https（失败）

每次访问http页面，chrome地址栏左边就会有一个不安全的字样，看着很难受，而且https逼格多高呀！所以就研究了这个。首先要买一张ssl证书，这个阿里云有一个免费的ssl证书可以买，买了之后将证书绑定到一个域名上，接下来就可以开始服务器端的配置了。

和上面一样，在那个时候，是通过纯tomcat实现的。主要依据阿里云官方文档辅以个别博文做出来的，中间重启了tomcat n多次，很痛苦！然鹅，从最终效果而言，我是很不满意的，因为一个tomcat，只能用一张证书，部署给一个（三级）域名。而且一般而言做了https的话，可以将http访问强制转发为https访问，这在阿里云官方文档中也有操作指示。只是做了这个之后，更痛苦的事情就来了：我当时有三个三级域名，导致虽然我www的域名能很好的跳转变成https，但是其他两个会变成类似这样:
之所以会这样，是因为ssl证书是对应一个三级域名的，而开启强制https，则会将其他对应不上的三级域名也强行使用这张证书，所以就会到这这样。光看就知道这还不如都不要https呢！起码还能直接访问，不会报这种页面。所以那会儿就短暂的放弃了SSL的部署。

个人博客的搭建

对于我们这些学渣而言，总是喜欢搞这种花里胡哨的东西

之前在csdn里面写了一段时间的博客，浏览量确实还不错。那会儿有一种很充满正义感的想法（倡导？）：大家选择不同平台写博客并没什么问题，但是请不要照抄好不好？？？我老是会遇到同一篇博文在好几个平台，甚至一个平台里好几个博主抄袭，甚至都不带原链接，或者有的原链接套娃现象。

所以我那时候就暗示自己，一定不要抄袭别的博客，因为我需要查阅的时候看着这些重复且参考意义不大的博文很痛苦，不想把这种痛苦也经由我带给别人。当然，对自己还有的一点要求就是 博文的质量尽量高一点，不像某些博文只是针对他自己的配置，基本情况都不说一下就发（后来虽然我也有这么写过，但是我觉得不太合适的博文就设为私密，只能自己看，日后完善之后再公开）

然鹅，我现在也能体会一点那些人的心情了。。。

回到正题，由于在这些专门的博客网站上发博客总是会有点限制，能DIY的内容比较少，加上一些没太所谓的原因，并以此为借口，自己就去研究搭了一个个人博客。

我一开始还想着自己写一个博客网站出来，结果在完成了极为简陋的写博文页面和浏览页面之后 我就放弃了。

我采用的是hexo框架，发布在自己云服务器的httpd服务上。hexo官方文档很友好，基本上看文档就能完成搭建和部署等操作。而且使用这种第三方的个人博客能给用户提供大量的主题，反正花里胡哨的，初次使用一定会被惊艳到的！

后来

后来。。。我就来到了B站。。。 那么有些人就奇怪了，个人博客还不满足为什么又选择了一个平台。

是这样的，网站有个技术叫SEO，可以简单理解为网站在互联网上的曝光度。SEO越好，用户在搜索引擎中搜索问题就越容易在显示结果中靠前。而SEO主要和网站代码有关，我没这方面的研究，甚至百度索引都没进（搞不来啊，太麻烦了。不过google的倒是做了）。所以就又有点想借由第三方平台增加一下曝光度了。我们这些写博客的肯定不只是为了自己做点笔记，更希望能为当初和我们一样困惑着的网民解惑啊！

再后来

没错，我又回来了。。。因为B站毕竟不是一个专业的博客平台，相关服务不如csdn做得好。人们总是这样，怎么说呢？生在福中不知福？也不太准确，有点探索精神的人们，肯定不会因为一开始就选择了一个很不错的平台而感到满足，因为**没有比较怎么会知道一个平台做的好呢？**探索一遍得出结论，我觉得我这个行为也没什么毛病噢。

使用nginx

到这里为止，我的网站上有tomcat和httpd两个web应用，这会导致一个问题，这两个肯定都不能占用同一个80端口啊！这就导致要访问其中某个应用必然得带上端口号，这太丑了。所以有这个需求推动我去学习nginx。

之前没有需求的时候去学习nginx 完全没有动力，甚至学了一大半都不知道这玩意儿能干啥，在有需求之后，学习起来很快乐，最终效果也很好。这个故事告诉我们，学习技术要由兴趣驱动啊！

学完nginx之后发现，这可真是个大宝藏啊：之前折腾的https，不同三级域名指向不同应用等操作都可以由nginx统一，而且更加简单的解决。真后悔没早点学，如果你也是一个后端小白，看到我这篇文章的话，切记，在学习部署网站之前一定要先学nginx！他很简单，从头到尾就整一个配置文件而已，上手很容易。

到此为止，我对网站的搭建已经是很满意了：通过www能访问部署在httpd上的静态博客，通过其他三级域名能访问tomcat中不同的应用，而且这些都是可以https直接访问的。甚至还能启多个tomcat在nginx里面做负载均衡，如果你不知道这样做有什么用的话，我给你举一个例子：

假如你的一个tomcat出了意外，比如上传war包，他虽然加载了，但是页面显示不出来，你不知道怎么做，那当然是选择重启了。而重启的过程中，页面都不会有响应。但是如果同时启动了多个tomcat的话，可以先部署一个，在重启的过程中，负载均衡的tomcat能顶替提供正常访问，待重启成功之后，再重启另一个，这样相比之前单tomcat，能极大提高用户方的体验吧！

使用Docker

你以为到上面为止已经没有什么好完善了的吗？不不不，学习Docker为你打开新世界的大门！

在用上nginx之后，确实一切都变得简单起来。但是总有些不方便的地方：由于买的云服务器是学生机，加上tomcat机制不是很了解，导致不清楚为什么tomcat在短时间内多次重启会越来越慢，一开始只要十几秒钟，后面长起来可能都要10多分钟；由于用了多个tomcat，所以每次部署应用总是要不同目录访问来访问去，而且在复制tomcat的时候，有时候可能会忘记改端口什么的，导致一系列很麻烦的操作、配置文件也分散在不同角落。

以上只是我在运维中的一些问题，大家使用不同的策略来部署肯定会有别的问题。而Docker都能很好的帮我解决这些烦恼，没有理由不用他。现在，我的不同应用的配置文件基本上都集中在一个地方，然后通过数据卷映射到每个容器中。想要多个tomcat一条命令就搞定，tomcat容器启动速度也是不用质疑的，完全不会出现几分钟打不开的情况。不同应用的端口也能得到统一的管理。实在是太棒了。

Docker进阶

再次更新这篇博文已经是2023年1月了，然而上次是2020年8月。那么在这段时间我的服务器有什么新玩法呢？下面开始介绍：

上面讲到tomcat。我大学一开始学的是SSM框架，是要打war包部署到tomcat中运行的，但是后面SpringBoot就完全不需要了嘛，自带tomcat了。这个时候部署方式就发生了一点变化，需要自己能写一点DockerFile自己做镜像了，一开始出于懒惰这部分项目都直接独立于docker运行，后面还是太麻烦，所以花时间整合了一下。
针对简单的SpringBoot项目写DockerFile其实是很简单的， 1. from jdk; 2. add jar; 3. expose port; 4. java -jar xxx
更进一步，可以将Docker和IDEA集成一下:

从而达到跟IDEA正常运行项目一样，直接将项目做成镜像，然后在远程部署Docker实例。一键上云啊! (不过提到这个词,我还是out了，因为现在FC、Paas方便得多，还没深入用过)

原先SSM项目也差不多，只不过改为1. from tomcat; 2. cp war; 3. expose port; 4. startup.sh 而已。

CDN

虽然当前站点流量并没有达到瓶颈（不懂SEO其实排名并不好，没什么访问量）, 但是不妨碍我想体会一下CDN的各州功能，CDN这块我选择了CloudFlare(因为有13可装)。几年轻度使用下来有利有弊吧。
弊比较好说就先说了，用了cf之后很明显！国内访问速度会变得特别慢，其他倒没什么。
好处就比较多了，它的功能特别丰富：它可以代替一些nginx的工作， 比如强制所有地址转https，涉及倒文件传输服务的，可以限制最大容量，以及他可以发通用证书，直接一个证书配所有域名，这个就爽。（但是要生效他的证书就必须走cloudflare代理，但是开了代理就会导致国内访问速度变得很慢。所以如果要国内访问比较快的话其实还是要用别的证书）
另外，可以看得出cf特别卷，三天两头就发布个新功能，像图床、FC、Zero Trust（代替验证码的方案）等等等等（我全都没用过:)）。但是已经接入这个平台了，以后看看可以方便的用上这些服务吧。

内网穿透

随着开始工作了之后， 内网服务开始变得丰富了起来。群晖、Unifi、home-assistant、openwrt、这些也都是一应俱全。但是这些都只能在家里的时候能够访问，所以加一个内网穿透可以说十分有必要，方便外地摸鱼（bushi）
不过内网穿透不是这一两年才开始搞的， 其实早在19年20年我就开始在用了， 只是那个时候应用比较少。
内网穿透还是用我熟悉的frp，完全够用。最近在看IPV6， 因为家里宽带升级到1000M了， 实测有100M的上行。IPV6运营商分配了一个60位前缀的地址，如果能用起来的话，直接就不需要穿透了，穿透还要局限于阿里云的5M小水管。
后面有缘再更新吧！

IPV6

SEO

待续