zhusong.me
《人来人往》- 陈奕迅
在2016年～2019年的时间里，我曾在工作之余花费了巨量的精力和时间在完成yidot.net上。而在来京东之后，因工作原因，yidot.net的巨量维护工作逐渐变得困难，于是一直搁置到了现在。2023年4月份，在经历京东3次裁员风波（2022年3月、2022年6月、2023年3月），以及招募我进来的领导当前所面临的尴尬裁员境地后，我终于又重新意识到追求自身变化和进步的急迫以及重要性。也非常感慨在京东这5年时间里，忘却了曾经的很多想法，同时也正在逐渐失去以前的行动能力，所以为了激励自己能做出正向变化，这是我构建zhusong.me的第一个原因。在这一点上，我其实一直知道自己不是一个聪明的人，反而是一个略显笨拙的类型——所以在工作上，尽量对每件事情都很认真、积极、主动，满分投入，我知道有些事情上天注定，无法改变，这这正是现实生活，希望能通过写博客，与自己和解。第二个原因是我一直都很喜欢找个安静的环境静下来写点文章，既能打发无聊时间，又能总结和记录发生过的事——不轰轰烈烈而平平淡淡的事，希望自己能够坚持下去。第三个原因我为什么不使用yidot.net来记录，从功能上yidot.net即实现了文章、问答，富文本编辑器也都是正常work，其实主要是因为yidot.net太重，想要一个支持ssr的框架来做。下面是博客一些细节，主要分为5个部分：
- 博客
- 音乐
- 书籍
- 摄影
- 淞味
这是根据我本人的兴趣爱好来制定的，我本人喜欢写文章，音乐（李荣浩+毛不易+陈奕迅=我）、书籍和做饭，但摄影是记录的基础，所以也囊括进来了:P。
zhusong.me选择的技术栈及为何选择？
yidot.net是react实现的，当时为了快速实现不同功能，堆叠了很多不可思议的代码，尤其是富文本编辑器draft-js部分。一直有想重构的想法，但仍然不敢下手动它。而域名zhusong.me更适合博客使用，用新的技术栈实现亦并不复杂，于是慎重选择了支持ssr的next.js（基于react）。既是为了能在前端框架上的技能掌握更加熟练，支持快速出活，同时也为了能对搜索引擎的优化会更好，彻底解决yidot.net的csr带来的seo问题。后端对数据库的操作上，选择了node，足够轻量。
zhusong.me的备案
如果继续使用阿里云的国内服务器，则面临着备案的问题，曾记得以前是不强制备案的，现在新政后，不备案无法正常展示网站内容。如果继续使用阿里云香港的服务器，虽不用备案，但价格昂贵。所以最终选择了国外的VPS（ishosting）提供的香港服务器。因服务器压力较小，选择了不高的配置2C3G 30GSSD 1G带宽。
zhusong.me的架构
虽然网站功能较为单一，但服务器环境较为复杂，主要是为了使用以前已经弄好的资源。
Server HK即是在ishosting.com购买的香港服务器，通过nginx将https://zhusong.me的请求转发到localhost:3000即next.js服务，next.js通过fetch /api/接口获取数据ssr渲染页面返回到用户浏览器，而/api/通过nginx影射到node:8080端口，通过请求DB返回内容。在图片和视频上，因braft-editor提供xhr扩展，yidot.net:80曾经做过图片和视频上传能力，所以editor将图片和视频跨域upload到yidot.net的oss本地磁盘上。用户浏览器通过访问oss的图片和视频时也是经过Server SZ1的nginx将/articleImg/或者/articleVideo/影射到本地SSD。之所以有点绕，是因为以前yidot.net设计了整套流程，本次复用起来更绕了，后续为了节省成本和服务器响应时间，以及下面所列举的点，会慢慢进行优化。
- 在高可用上关于图片视频服务器（CDN服务器）、mysql服务器、应用服务器的高可用目前没有设计任何方案。
- 在SEO的优化上，目前没有设计任何方案。
- 在体验上存在诸多问题。例如分页、样式，草稿箱、手机适配等。
zhusong.me的next.js
next.js的路由在于pages文件夹的路径树设计。在dev环境下，getStaticProps每次都会调用，所以DB的数据更新后，[slug].js页面刷新后，页面随着刷新，但在prod环境下，只有当下次 next build 后才会更新数据，否则一直显示的是老数据。为了解决这个问题，将[slug].js页面的getStaticProps改成getServerSideProps，即non static path 或者改成csr的模式（但这不符合目的），即可解决这个问题。
next.js的环境变量，可以在package.json的scripts中dev中填入NEXT_PUBLIC_DOMAIN_ENV=development，即可访问项目根路径下的.env.development环境文件，如果在build中填入NEXT_PUBLIC_DOMAIN_ENV=production，即可访问项目根路径下的.env.production环境文件。
next.js作为ssr服务存在，在通过npm run build后生成.next文件夹，并通过npm run start运行，可以指定其他非3000端口。而我的做法是：通过在serverHK安装svn，并svn checkout源码，通过npm run build后npm run start运行。每次svn commit，在服务器svn update，重新运行，本套逻辑脚本化处理，后续考虑更佳部署方案。
zhusong.me的node server
采用node并非一时脑热，而是继续采用java，并没有更多成长，于是为了探索node，故强制用node。
node server用的是express框架，为了能够类似next.js根据不同环境加载相应的环境变量，故引入dotenv，在package.json中scripts里增加prod、dev，不同环境设置不同的NODE_ENV="production"或者"development" 加载不同的环境变量，并在代码中通过判断process.env.NODE_ENV是prodction还是development加载不同的配置文件，例如：
if(process.env.NODE_ENV == 'production') {
data = dotenv.parse(fs.readFileSync(path.resolve('.env.production'),'utf8'));
} else {
data = dotenv.parse(fs.readFileSync('.env.development', 'utf-8'));
}并将环境文件里的内容加载到环境里：
for (const k in data) {
process.env[k] = data[k]
}在服务器上，通过svn checkout 源码，node run prod 运行绑定8080端口。
zhusong.me的https证书
zhusong.me采用的是在阿里云申请的DigiCert 免费版 SSL证书，并在nginx 443配置，具体参考相应的阿里云教程即可。
zhusong.me的nginx配置
nginx配置并不复杂，80 server 需要影射到443：
server{
listen 80 default_server;
server_name zhusong.me www.zhusong.me
rewrite ^(.*) https://www.zhusong.me$1 permanent;
}
server{
listen 443;
server_name zhusong.me;
return 301 https://www.zhusong.me$request_uri;
}
server {
listen 443 default_server;
#省略https证书配置等
location /api/ {
proxy_pass http://127.0.0.1:8080/api/;
}
location / {
proxy_pass http://127.0.0.1:3000;
}
}zhusong.me的草稿方案（仅供参考）
编写此篇文章时，因编辑器的bug问题导致崩溃多次。于是为了能及时存储，为此设计了草稿功能。具体思路是：
- 如果采用定时同步草稿，则多开TAB会造成草稿之间的交叉覆盖。LocalStorage本地维护无法做到服务器能力。
- 文章不提交，用户无法访问最新内容。
为了解决上面的问题，将定时同步改为编辑器内容变更，同时距离上次同步已超过10s后进行草稿覆盖，即使是多开TAB，未变更内容的TAB也不会触发更新草稿，即可避免交叉覆盖的问题。草稿保存在服务器，具体分为：
- 新建文章时仅一份草稿db record（id=1，article_id=null），加载的编辑器初始内容为草稿表内容（非文章表），即开2个tab同时提交新文章，这2个tab加载的草稿属于同一份。提交文章时，往文章表和草稿表（草稿表多article_id字段）内插入相同内容的记录。
- 修改文章时，每份文章仅一份草稿，载的编辑器初始内容为该article_id的草稿表内容。提交变更时，同步更新草稿表和文章表，即可保证每次加载草稿都是最新内容。
后面会花更多时间和精力在优化seo、网站体验、性能上，希望zhusong同学能够继续坚持。