(个人经验分享)网站部署历程

type

status

date

slug

summary

无域名时期

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

买域名啦

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

不同域名对应不同tomcat应用

总不能一个域名下的所有三级域名都对应一个网页吧？所以在刚开始我是通过tomcat自身的server.xml中配置不同的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官方文档很友好，基本上看文档就能完成搭建和部署等操作。而且使用这种第三方的个人博客能给用户提供大量的主题，反正花里胡哨的，初次使用一定会被惊艳到的！

图床

写个人博客就要涉及到图床了，所谓图床，就是一个专门存储图片的区域，当然也可以是博客服务器本身，但是我的服务器带宽只有1M，所以还是算了吧。。。我选择的是阿里云的OSS，买了个学生特惠的资源包。可能会有人和我一样，觉得OSS，对象存储好像很高大上，感觉很难的样子。不是这样的，他的底层存储结构相对于常见的文件系统确实可能不太一样，但是这对于用户(我们)而言是透明的，官方的教程也很完善，跟着做轻轻松松能够在10分钟内搭建出来。在配置好对象存储之后使用起来是很舒服的：我用的写作工具是Typora，它内置了往文档内插入图片时的几种处理方式：

我选择的是PicGo-Core命令行版，千万不要被以上这些名词表面描述的给吓到了，其实真的很简单，配置好之后，当我往MD中以任何形式插入图片，这个图片都会自动上传到我配置的OSS上去，OSS访问带宽什么的都是与ECS独立的，而且真的很快，下个几百兆的文件，沾满我100多M的带宽那是绰绰有余呢。没错，OSS不仅能存放图片，大部分的文件都能存的。

后来

后来。。。我就来到了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其实是很简单的，

from jdk

add jar

expose port

java -jar xxx IDEA集成Docker操作

更进一步，可以将Docker和IDEA集成一下：

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

原先SSM项目也差不多，只不过改为

from tomcat

cp war

expose port

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

时隔半年，2023年7月，我又来更新啦！

今年给家里重新办了宽带，还是用中国移动，但是升级到了1000M（之前都是100M），上行有100M！之前对于ipv6完全没有了解，但是由于自己家里宽带水平一下子飞跃了，所以就开始琢磨了一下。然后发现运营商对于IPV6居然这么大方！直接给了个60位前缀的公网网段！这是什么概念呢，ipv6也分为网络位也主机位两部分，分别是64/64 ，简单算一下， 60位前缀的网段，一共可以分出 (2^64)*2^(64-60) 个公网ip，目前我想象不到未来有什么可能性能用掉这么多公网ip（可以发掘一下）。

我家用的网络设备是UBNT和OPENWRT，琢磨了一下，开启了IPV6，然后把个别设备接了公网IP，然后配了一下防火墙把部分端口映射出去了。外网用IPV6直连我的群晖，拖了一个文件上传试了一下，100M满当当，不要太幸福！！！看来通过阿里云5M小水管走内网穿透的日子要一去不复返了呀。

但是实际这么久用下来，还是有些缺陷的，比如公司内部不知道为什么没有开启IPV6，当然不止公司，其实没开启IPV6的地方还挺多的；又比如运营商给的网段也不是固定不变的，隔个几天就会换一批，有时候一两天就换，有时候一个多月才换。无奈只能加上DDNS，但是完全不影响性能好吧！

后续可能会考虑把更多服务部署到本地。不过还得考虑一下家庭宽带能否做这件事以及备案等方面的问题。

ALL in Notion

4月份的时候开始有想法要升级一下自己的博客（之前有一次面试被面试官刺痛了：你博客咋还用jQuery的呀？）。随着想法的推移（懒），整体思路经历了几个阶段：

改造成页面中集成交互的博文（不是嵌入codepen这种第三方的形式，而是更深层次的，参考GPS 工作原理 (longtian.info)）

改成THREEJS项目，主页形式是自己的卧室，同时对接大量第三方，同步自己的状态（例如，正在开车、正在听什么歌、正在玩什么游戏等等），同时也包含正经的博客，但是相对会更偏3D主题（如果你完全想象不到，给你一个参考： Henry Heffernan - Portfolio 2022 去年这种项目新出现了很多，这个相对其实内容也没有这么丰富，我随便找的）

把博客集成到Noiton中，以上两种优化手段再以Notion集成为基础重新考虑

针对方案1，我的实际行动只是了解到了 MDX 库，另外在形式上还有看到过ppt形式的，例如http://slhck.info/ffmpeg-encoding-course/#/8 当然这还有很大的优化空间，比如分成两边，一遍显示demo的形式。

方案2，我在学习了将近两星期之后，成功做出了能实时显示我正在听的歌（Spotify API）的一个THREEJS组件，但是就没有然后了。

方案3，这两天正在进行中！在github上尝试了 nextjs-notion-starter-kit 和 NotionNext，觉得后者各方面都挺不错。这两天主要的工作量在于：之前博客都采用markdown，但是notion导入markdown其实并没有这么完美，比如有的行内代码标记会消失、有的格式会错乱，表格内嵌图片会转成数据库等等，我每篇文章都要处理过去。

后续处理好了之后，我会先按自己的喜好再优化一下这个next主题，然后就会考虑上面说的两点优化方式。