由于博客搬家，图片的存储来源也对应的替换了，所以参考了微信公众号里的文章，按照上面的策略自建了图床。

实现上来说，就是把图片存到自己账户的对象存储 COS 里面，如果开启了自定义域名，则可以让图片路径也带有关键词，对于 SEO 会比较友好。

实现步骤很简单，如下所示：

1. 安装命令行工具 Serverless Framework

   1	npm install -g serverless

2. 下载项目模版代码

   1 2	sls init imgbed-for-scf cd imgbed-for-scf/scf

   在配置文件config.js 里填入您的 SecretId 与 SecretKey

   1 2 3 4 5 6 7

   const config = { tencent_cos: { SecretId: 'XXXXXXXXXX', //您的 SecretId SecretKey: 'XXXXXXXXXXX', //您的 SecretKey } } module.exports = config

3. 部署
   回到根目录下，执行 sls deploy 完成部署。

   1 2	cd .. sls deploy

4. 测试
   部署成功后，打开 scf 目录下的 upload.html 文件，将创建成功的 API 网关 URL，填入 scf_url 字段里，之后打开该页面，就可以使用了。

为了便于访问，我还将 scf 目录下的 upload.html 也通过静态托管的方式存储在了 COS 里面，这样访问起来会更加方便。

最终效果如下

看到 Tencent Serverless 最新发布了 Registry (可以翻译为模板商城，或者模板仓库)，并且提供了详细的官方开发指南。不仅想起之前创建一个 Python/PHP 的脚手架函数很麻烦，忍不住把几个常用的 hello world demo 发布上去尝鲜体验一下，特此记录。

前提条件

1. 下载安装了新版的 Serverless Framework

   1	npm install - g serverless

2. 拥有一个腾讯云账号

步骤

1. 查看可用组件和模板

查看可用模板中，可以看到主要列举的是一些官方的组件和模板

• 访问 Serverless 注册中心页面：https://registry.serverless.com
• 使用sls registry命令列出所有推荐的组件或者项目模板

发现官方的模板仓库在这里>>

2. 开发上传自己的模板

准备好自己的代码项目，例如一个非常简单的 Python 3.6 Hello World。目录结构如下：

1
2
3
4

.
└── src
   |── index.py       # 入口函数
   └── serverless.yml # 依赖的组件配置说明，此处使用 scf 组件

此处的 serverless.yml 可以参考 scf 组件的全量配置。

为了让 Registry 识别到这是一个模板，需要在外层再创建一个 serverless.yml，并且描述一些模板相关的信息。此时，目录结构如下：

1
2
3
4
5

.
├── src
|   |── index.py       # 入口函数
|   └── serverless.yml # 依赖的组件配置说明，此处使用 scf 组件
└── serverless.yml # 模板说明文件

外层的 serverless.yml 描述如下：

1
2
3
4
5
6
7
8
9
10
11
12

name: python-hello-world # 项目模板的名字
author: Tinafang # 作者的名字
org: Tencent Cloud, Inc. # 组织名称，可选
description: Deploy a Python 3.6 hello world demo. # 描述你的项目模板
keywords: tencent, serverless, python # 关键字
repo: https://github.com/serverless-components/python-hello-world # 源代码
readme: https://github.com/serverless-components/python-hello-world/tree/master/README.md # 详细的说明文件
license: MIT # 版权声明
src: # 描述项目中的哪些文件需要作为模板发布
  src: ./src # 指定具体的相对目录，此目录下的文件将作为模板发布
  exclude: #描述在指定的目录内哪些文件应该被排除
    - .env

本地部署验证成功，并且检查项目已经把秘钥文件排除之后，只需一行命令，就可以把模板发布到云端：

1

sls registry publish

发布成功，可以看到如下结果：

1
2
3
4

serverless ⚡ registry
Publishing "python-hello-world@0.0.0"...

Serverless › Successfully published python-hello-world

Serverless Component 全新版本于 4 月 8 日发布，本文将从下面几个方面对本次发布的新特性进行一次解读，希望可以在使用的时候也更加了解其背后的原理和行为，目录如下：

• 1. 什么是 Serverless Component?
• 2. 以 Express 组件为例，浅析架构及部署原理
  • 概念和架构说明
    • 1. component 参数
    • 2. name 参数
    • 3. org 参数
    • 4. app 参数
    • 5. stage 参数
    • 1. 注册中心 Registry
    • 2. 云端部署引擎 Deloyment Engine
    • 3. 事件中心 Event Bus
• 3. 执行 serverless deploy 之后，Component 都做了哪些事情？
• 4. 开发利器：实时日志 & 云端调试
• 5. Component 之间的组织和引用
• 6. Serverless, 未来已来
  • 【快速部署你的 Express.js 应用】
• 附录： Serverless Framework 支持命令列表

1. 什么是 Serverless Component?

Serverless Component 是 Serverless Framework 重磅推出的基础设施编排能力，开发者可以方便通过 Serverless Components 构建，组合并部署你的 Serverless 应用。

这个定义依然有点抽象，我们可以通过一些实际的例子来说明他的组合方式：

云上有很多产品，这些产品都有着对应的配置。然而对于一个客户来说，我只关心我是业务实现，并不想关心底层的云资源的配置是怎样的，以及到底应该怎样组合这些产品。那么 Component 就是为了解决这个问题而出现的，它支持开发者用最少的配置，构建一个 Serverless 产品/框架/应用。

如下所示，几行 yaml 配置就可以部署一个基本的腾讯云对象存储 COS 桶：

再进一步，如果你希望搭建一个 Express.js 的 Web 框架，那么在这过程中，如果要用云上的 Serverless 产品实现，则需要组合不同的基础产品，并且对框架进行适配和改写。相信开发者都希望尽可能避免这种改造适配的工作，而 express 组件就可以将原有应用平滑的部署到云端，无需任何改造和配置。

到了这里，可能对于很多开发者来说，支持框架适配已经可以完成很多业务的部署和迁移了。但是对于很多客户而言，他们所需要实现的比这还要具体，例如直接希望实现一个从前端、到web服务再到数据库的网站，或是一个动态博客系统，论坛，登录功能等具体的能力。那么此时，Serverless Component 依然能够通过组合进行实现。但是这次会直接通过模板来提供这些应用的支持。

相信上述概念完成后，你已经对于 Component 有个大致的了解了。那么，再深入一点，Component 这么神奇，那他在背后，究竟帮我做了哪些事呢？

前言

由于种种原因，最近终于下定决心把博客重新部署下。整理了下现有博客的一些问题：

1. 手动构建和发布，比较繁琐，容易误操作
2. 依赖本地设备，换电脑的时候没法写博客了（电脑快被收了 > <）
3. 使用的部署工具是 serverless component v1，官方已经不再维护
4. 域名解析有点问题，每次都重定向到 cos 桶地址，并且在微信里被封禁，打不开，分享机制很不友好。

基于上述问题，终于决定迁移自己的博客了，当前的进展如下：

• 新的域名
  https://blog.tinafang.com，解决问题 4
• 升级为 component v2，解决问题 3
• 增加一些友情站点，例如 yuga, only 的
• 兼容之前的博客地址，包括 cos 和 自定义域名
• 传到 Github Repo 中，解决问题 2
• 接入 Github Actions 的自动化 CI 流程，解决问题 1
• 搭建自己的图床，对图片的大小，尺寸进行优化

步骤

1. 将本地代码提交到 github 远端上

1. 在gitHub 上 创建新库 https://github.com/tinafangkunding/tina-blog
2. 终端cd工程文件所在文件目录，
3. git init
4. git add -A (进入文件 添加文件,-A表示添加全部文件)
5. git commit -m “提交说明”
6. git remote add origin url (该url是你库的url)
7. git push -u origin master （将本地的仓库提交到github账号里）

刷新后，即可看到代码 https://github.com/tinafangkunding/tina-blog

2. 升级为 component v2 的部署方式

1. 在本地环境把旧的 serverless.yml 改名，重建一个新的 serverless.yml
2. 并且将配置修改为 v2 规范：website component 的 v2 版本配置参考，也可以参考下文的配置。
3. 为新的 blog.tinafang.com 申请证书，半小时之后申请和验证都完成了。
4. 在 serverless.yml 中配置新域名和证书 id，指定原有的 cos-bucket（覆盖部署），并且手动部署成功。
5. 在 dns 中加一个 cname 记录。等待 1-2 分钟即可生效

此时，再次执行下列命令，更新到 github 仓库

git add -A
git commit -m "v2"
git push

最近在调研 SSR 场景，并且在使用 Next.js 框架，特此记录分享。

概念说明：Next.js & SSR

Server-Side-Rendering（SSR）泛指服务端渲染的技术，指的是在 Server 端将 HTML 渲染好，再返回给 Client 端。并且 SSR 是在对页面每个请求发出时，都会重新抓取和生成页面（和 SSG 静态页面生成相比，是更加动态的渲染方式）。

Next.js 是一个轻量级的 React 服务端渲染应用框架。支持多种渲染方式，包括客户端渲染、静态页面生成、服务端渲染。使用 Next.js 可以方便的实现 SSR，实现页面的服务端渲染。

Next.js 支持的几种渲染方式

1. 客户端渲染 CSR Client Side Render

在浏览器上执行渲染，页面在浏览器获取 js 和 css 文件后渲染，路由也是客户端路由。
缺点：

• 白屏，加载时间长
• SEO 不友好，因为搜索引擎访问页面时默认不会执行 js，只看 html，所以看不到请求数据

但在一些场景中 CSR 也是适用的，例如有权限的（私有）页面，和 SEO 无关，并且页面内容经常更新，此时不需要预加载，直接通过 CSR 实现即可。

2. 静态页面生成 SSG Static Site Generation

为了解决方法1 的问题，可以在后端进行一次渲染，浏览器直接请求，从而不需要每个客户浏览器端渲染。将动态内容静态化。

• 解决白屏和 SEO 问题
• 但这种方式对所有用户请求的内容都一样，无法生成用户相关内容

通过 async 方法 getStaticProps 获取内容，适用于静态页面生成过程中需要请求到外部数据的时候。例如页面中的信息要从 DB 中拉取，之后才能生成静态页。

3. 服务端渲染 SSR Server Side Render

当页面和用户相关时，用 SSR 可以解决

• SEO 和白屏问题
• 生成用户相关内容，不同用户结果不同

通过 getServerSideProps 获取内容，在后端调用 renderToString() 的方法，把整个页面渲染成字符串。

附一张 CSR 和 SSR 和 SSG 的对比图，图片来源为参考文献中的文章。

几种方案的优劣对比，图源详见参考文献。

听了 10 月 27 日凌晨 Next.js Conf 大会的 Keynote，Next.js 10 发布了几个激动人心的特性，忍不住尝鲜体验下。

原文博客：
https://nextjs.org/blog/next-10

本次发布的特性主要聚焦于开发者体验的提升和用户体验的提升。

亮点目录：

1. 内置图片组件 Image Component : next/image，自动进行图片优化
2. 国际化路由 Internationalized Routing，多语言支持，自动语言检测
3. Next.js Analytics 性能测试，测试客户场景下真实性能
4. Next.js commerce 电商系统工具包 https://nextjs.org/commerce
5. SSR/SSG 渲染方法getStaticProps / getServerSideProps 快速切换
6. React 17 的支持

1. 内置图片组件 Image Component，自动进行图片优化

当前网络上图片的占比有 50% 左右，图片的大小和尺寸很难控制（一半以上的图片都在 1M 以上）。一张比较大的图片，如果不经优化，在小尺寸设备，如手机端的显示并不好，也无必要。例如，2000 × 2000 像素的图片，在 100 × 100 的手机屏上显示就没有必要，并且加载速度慢。此外，就算研发和业务可以优化图片大小，但是对于客户上传的内容（CMS）也比较难控制和管理。

因此，Next.js 10 通过内置的图片组件 Image Component 解决这个问题，用法如下：

1
2
3

import Image from 'next/image'

<Image src="/profile-picture.jpg" width="400" height="400">

通过 next/image 组件，图片会被自动 “懒加载(lazy-loaded)”，也就是只在用户快刷到图片时才加载。此外，限制了图片尺寸，防止布局偏移（layout shift)。
此外，image 组件将大尺寸图片自动裁剪和适配，生成适应屏幕尺寸的，WebP 格式的小图（WebP 比 JPEG 图小 30% 左右），这种情况下，即使是客户上传 CMS 中的图片内容也可以被自动裁剪和适配。

周五看到了 yugasun 发布的博文如何优雅的部署一个 Serverless Next.js 应用，看到案例是一个基于 cnode 的论坛，于是很好奇改造一些已有的 Next.js 项目到 serverless，迁移成本如何。话不多说，直接动手实践下：

Part 1 : 迁移流程

1.1 本地部署 Next.js 项目

先去 Github 上找了一些多星的 Next.js 项目，发现了一个有趣的仿 V2EX 站点遂 fork 了一份，下载到了本地。

为了保持包的精简，在本地安装了对应的 production 环境依赖：

1

npm install --production

之后通过运行 next dev 命令本地部署

1

npm run dev

根据输出，访问 http://localhost:3000 即可查看到效果了。so far, so easy!

1.2 部署 Next.js 项目到云端

根据 Next.js 组件中的案例配置文档，在项目的一级目录下分别创建下 serverless.yml 和 .env 两个文件。

1
2
3

# .env
TENCENT_SECRET_ID=xxxxxx
TENCENT_SECRET_KEY=xxxxxx

.env 文件主要用于授权创建对应的云资源，如果项目后续要持续更新，建议直接配置永久秘钥，如不创建也没关系，可以直接通过微信扫码的临时授权方式来部署。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

# serverless.yml
org: orgDemo
app: appDemo
stage: dev
component: nextjs
name: nextjsV2EX

inputs:
  src:
    dist: ./
    hook: npm run build
    exclude:
      - .env
  region: ap-shanghai
  runtime: Nodejs10.15
  apigatewayConf:
    protocols:
      - http
      - https
    environment: release

serverless.yml详细配置参考

之后的步骤很简单，安装 serverless framework 工具后，直接通过一行命令进行部署：

安装（ Mac 如没有权限，可以尝试下 sudo npm install -g serverless）

1

npm install -g serverless

部署

1

sls deploy

接下来，神奇的事情发生了，部署完成后（虽然等待了几分钟）直接访问输出的 URL，我惊讶的发现这个仿 V2EX 站点已经完全迁移到了云端。

至此，一行业务代码和配置都没有改，这种体验简直不要太好。

想要实现 B 站自动签到打卡，但是不想为闲置资源付费？

Serverless 让你不必买服务器，本地电脑也不用装 Python PHP 这些环境，全云端托管运行！

本文基于 @happy888888/BiliExp 的代码，用 Github Actions 或 CLI 自动部署到腾讯云云函数上。

前提

1. 开通云函数 SCF 的腾讯云账号，在访问秘钥页面获取账号的 TENCENT_SECRET_ID，TENCENT_SECRET_KEY

   注意！为了确保权限足够，获取这两个参数时不要使用子账户！需要提前开启云函数服务。此外，腾讯云账户需要实名认证。

2. 一个或多个B站账号，以及登录后获取的SESSDATA，bili_jct，DedeUserID (获取方式参考下图)

获取 cookieDatas（以 Chrome 为例）：登录 B 站 -> 右键点击「检查」-> application -> cookies

3. SCKEY (可选，用于账号失效时用微信提醒,不用请留空，详情见http://sc.ftqq.com/)

部署方案一：利用 Github Actions

1. fork Github 项目 https://github.com/happy888888/BiliExp

2. 在fork后的github仓库的 “Settings” –》“Secrets” 中添加”Secrets”，name和value分别为：

• name为”TENCENT_SECRET_ID” value为腾讯云用户SecretID(需要主账户，子账户可能没权限)
• name为”TENCENT_SECRET_KEY” value为阿里云账户SecretKey
• name为”biliconfig” value为B站账号登录信息，格式参照config/config.json文件

  1 2 3 4 5 6 7 8 9 10 11 12

  { "cookieDatas":[ { "SESSDATA": "", "bili_jct": "", "DedeUserID": "" } ], "email": "", "SCKEY": "", "说明":"cookieDatas由浏览器获取，获取详情见首页说明；email用于邮件消息推送，SCKEY用于微信消息推送，详情见http://sc.ftqq.com/，这两项不用请留空" }

  环境变量添加完毕后如下图：

3. 添加完上面 3 个”Secrets”后，进入”Actions” –》”deploy for tencentyun”，点击右边的”Run workflow”即可部署至腾讯云函数(如果出错请在红叉右边点击”deploy for tencentyun”查看部署任务的输出信息找出错误原因)。部署完成后的流程如下所示：

注: 首次fork可能要去actions里面同意使用actions条款，如果”Actions”里面没有”deploy for tencentyun”，点一下右上角的”star”，”deploy for tencentyun”就会出现在”Actions”里面

Welcome to Hexo! This is your very first post. Check documentation for more info. If you get any problems when using Hexo, you can find the answer in troubleshooting or you can ask me on GitHub.

Quick Start

Create a new post

1

$ hexo new "My New Post"

More info: Writing

Run server

1

$ hexo server

More info: Server

Generate static files

1

$ hexo generate

More info: Generating

Deploy to remote sites

1

$ hexo deploy

More info: Deployment

0. 前言：并不完美的 Serverless

作为腾讯云 Serverless 的产品经理，除了自己接触 Serverless 开发外，每天也会面对非常多的开发者，一方面会感受到开发者对于 Serverless 技术的热情，另一方面也会收集到非常多的吐槽、问题和反馈，总结起来，在使用 Serverless Framework 时，客户往往有几个“不吐不快”痛点：

• 本地、云端环境不一致导致的开发、调试的问题。例如一些依赖库安装和本地调试成功，但在云端部署则失败。这种情况下进行版本迭代、问题定位都不够友好。
• 监控、告警能力的缺失：针对 Serverless 应用，目前资源级别的监控需要去手动配置。但如果涉及到应用内部的监控，则很难直观查看，从而导致发现问题、定位问题的流程较长。
• 怎样组织 Serverless 应用，不同的函数之间的调用关系、环境划分、资源的管理及权限控制等。

针对上面这些痛点问题，Serverless 团队看在眼里，急在心上。终于，在开发小哥日以继夜的努力中，5 月 12 日，腾讯云 Serverless 团队正式发布里程碑特性，通过支持应用级别监控以及 Dashboard 资源管理，有效解决上述问题！下面我们就来一起了解一下本次发布的新特性吧~

1. Serverless Dashboard 新特性抢先看

1.1 应用管理

不知道是否有小伙伴曾经有过这样的烦恼？在部署了 Serverless 应用后，不知道在哪里查看部署完毕的资源信息、实例状态和部署记录。过段时间想要再次查询也难以追溯。那么本次发布的应用管理页面则以 Component 为粒度，聚合了所有 Serverless Framework 部署的资源，并且展示了实例状态、访问链接以及上次的部署信息。此外，在管理详情中还支持删除 Serverless 应用、下载项目代码进行二次开发等操作，开发者可以更方便、集中的管理账号下的 Serverless 应用。

1.2 部署详情及输出

Serverless Framework 的特性之一就是可以便捷的联动关联的云上资源，因此不同的 Serverless Component，可能会联动不同的云上资源，如网关、云函数、COS等。相信许多小伙伴在进行二次开发时，都想要了解每个 Component 具体创建了的资源信息。在本次发布的部署详情页中，不仅可以查看到 Serverless 实例的基本信息，还可以在输出（output）页面中查看到 Serverless Component 对应的输入、输出信息。通过该页面，可以查看到对应的资源配置，如地域信息、资源id、使用的语言环境、支持的协议信息等。有了这个页面，可以直观的看到对应的资源配置，再也不担心不同应用之间搞混配置啦。

1.3 应用级别监控

当前 Serverless Framework 已经支持了多种 Web 框架的一键部署。在部署完毕后，相信许多开发者会希望查看到基于应用级别的监控数据。而这往往在基础资源的监控中是难以体现出来的。那么本次发布最为亮眼的能力，即支持了应用级别的监控页面，实现了”0“配置的监控指标展示。当前已经支持 Express.js Component 的应用级别监控。无需去多个产品的控制台查看监控，无需自助上报数据，无需借助第三方 APM 插件，只需一次部署，立刻查看 Express 应用的监控信息！