我是一个比较喜欢写东西的人，无论是生活中的点滴，还是学技术的笔记，再或者是自己针对某些内容的看法，我总想的是把这些内容记录下来，以后进行查阅比较方便，或者以后进行回忆比较有趣。

在以前，我用过Wordpress，我也用过Zblog，我也用过Hexo的博客的开源项目，我同样也用过云主机、虚拟空间以及Github Pages等，但是我一直都有几个比较头疼的点：

1. Wordpress和Zblog需要数据库，一般情况下数据库比较贵，这个比较头疼；
2. Hexo博客等不需要数据库，或者Zblog可以使用Sqlite相对来说也是没有成本的，还是比较爽，但是我把这些项目放在哪里是个问题，因为云主机、虚拟空间也是要花很多钱的；
3. Github Pages貌似还是一个很方便的点，但是在国内的速度等以及自由程度等，貌似还是有很大的挑战的；

在过去一段时间，我也和一些小伙伴尝试过，将Zblog，Wordpress等部署在Serverless架构，希望可以通过Serverless架构为我节省一笔费用，然而让我措手不及的是“自定义镜像太慢了”，而且在一定程度下放在NAS中的Sqlite数据，还可能出现损坏，我猜测是“锁”的问题；

所以，我的博客该何去何从，作为了一个非资深的羊毛党，但是却是资深的强迫症，解决博客的问题成了我一时之间所思考的内容：

1. 博客要有足够快的响应；
2. 博客要尽可能地做到0成本；
3. 博客要有一系列的拓展能力，例如搜索，留言等；
4. 发表博客可以非常简单和方便；
5. ……

此时此刻，我将目标瞄准到了：

1. Serverless Devs的静态网站组件
2. Hexo博客系统
3. Algolia的搜索能力
4. Gitalk的留言能力
5. Github Action的CD能力

说到做到，直接“开干”。

创建博客

其实创建一个博客系统非常容易，在下载、安装Serverless Devs工具之后，只需要初始化Hexo的模板即可：

s init devsapp/website-hexo

初始化完成之后，我们只需要配置一下密钥信息，就可以通过：

s deploy

直接将项目部署到线上。

当然，在这个过程中，我们还可以做很多的事情，例如寻找一个靠谱好看的模板，添加一些文章，修改一些模板上的配置等，反正最终我的效果就是：

image

集成Github Action

当我完成了博客的创建，我随后创建了一个Github的仓库，将Hexo推了上去。接下来，要做的就是创建一个自动发布的脚本，即我每次在Github发布文章，都会自动同步到我的博客中。

我在本地项目，通过:

s cli cicd

并且选择了Github Action：

image

之后参考所提供的案例：

   Serverless Devs的官网是通过Serverless Devs部署的: http://short.devsapp.cn/cicd/github/action/practice

通过进行密钥配置：

image

以及Yaml内容的完善：

name: Website Publish

on:
  push:
    branches: [ master ]

jobs:
  publish-website:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - uses: actions/setup-node@v2
        with:
          node-version: 12
          registry-url: https://registry.npmjs.org/
      - run: npm install
      - run: npm install -g @serverless-devs/s
      - run: s config add --AccountID ${{secrets.ALIYUN_ACCOUNT_ID}} --AccessKeyID ${{secrets.ALIYUN_ACCESS_KEY_ID}} --AccessKeySecret ${{secrets.ALIYUN_ACCESS_KEY_SECRET}} -a website_access
      - run: s deploy

最终将代码推送到线上，发现尝试触发，已经可以进行自动发布了：

image

拓展能力

完成上面的内容很简单，貌似也没什么额外或者值得尖叫的，或许以后可以通过更新Github里面的文档，来进行博客的更新，就是最大的好处了吧？

接下来两个事情：

• Algolia的搜索能力
• Gitalk的留言能力

首先是Algolia的搜索能力的集成，没什么难度，按照一些配置文档，就可以搞定，此处不在进行赘述。

其次就是集成Gitalk的留言能力，或许，这一步才是真正的开胃菜，或许让我对Serverless架构尖叫的点吧。

我非常简单，轻松地将Gitalk配置完成，并且尝试使用，我突然发现一个非常尴尬的事情：Gitalk出现了一个403

image

通过搜索，找到了这个仓库：
https://github.com/Rob--W/cors-anywhere

在issue里发现了罪魁祸首：

image

enmmm，大概就是说，这个仅仅是一个demo，但是很多人却直接使用了，现在我不给大家用了，给大家加点限制了，如果有需要，就自己部署一套这个服务吧。

我？？黑人问号懵逼脸。但是那能怎么办呢？没办法就只能自己看一下这个项目，把项目Clone到本地，发现这是一个Node.js的项目，灵机一动，是不是可以自己通过函数计算搭建一个这个服务？

于是我：

第一步，修改一下代码中的默认port（当然也可以不修改，通过环境变量设置）：

image

第二步，创建一个s.yaml:

edition: 1.0.0          #  命令行YAML规范版本，遵循语义化版本（Semantic Versioning）规范
name: my-blog       #  项目名称
access: "default"  #  秘钥别名

services:
  function-test: #  服务名称
    component: devsapp/fc  # 组件名称
    actions:
      pre-deploy:
        - run: npm install
          path: ./
    props: #  组件的属性值
      region: cn-hongkong
      service:
        name: gitalk-cors
        description: gitalk cors项目
        nasConfig: auto
        vpcConfig: auto
        logConfig: auto
      function:
        name: server
        memorySize: 128
        codeUri: './'
        runtime: custom
        timeout: 60
      triggers:
        - name: httpTrigger
          type: http
          config:
            authType: anonymous
            methods:
              - GET
              - POST
              - DELETE
              - PUT
      customDomains:
        - domainName: auto
          protocol: HTTP
          routeConfigs:
            - path: /*

然后再加一个bootstrap文件：

#!/bin/bash
node server.js

完成之后，只需要一行s deploy：

image

随即，将Gitalk中的文件进行修改，将我们刚部署完的域名替换到proxy中：

image

完成之后，我们无需进行部署，只需要推到Github即可，Github Action会按照我们之前的预期，来帮助我们做自动化发布，发布完成之后，我们可以尝试在我们的博客上登陆，评论：

image

总结

创建博客方法很多，其实流程也很顺利，但是基于Serverless架构来做的博客，真的可以说是非常省心：

1. 避免了Github Pages等在国内的响应速度慢的问题；
2. 一些需要自定义的行为，完全可以通过更高的灵活度来进行实现（例如自己部署了这个仓库的代码：https://github.com/Rob--W/cors-anywhere ）；
3. 相对传统的服务器来说，Serverless架构也更省钱；