议题1：Serverless Dashboard 设计解读

提纲：

1. Serverless Dashboard 新特性解读

2. Serverless Dashboard 的设计思路，后期规划是怎样的？

3. 实战：一站式部署具备应用级监控能力的 Express.js 应用

议题2：Serverless SSR 应用

提纲：

1. 什么是 Serverless SSR ？

2. Serverless SSR 都有哪些优势和场景？

3. 实战：快速部署你的 SSR 框架

讲义 一、Serverless Framework背后的设计

1. Serverless Framework原理特性

在没有Serverless Framework之前，用户如果要部署一个自己的网站，做成一个Serverless能够弹性扩缩容的架构，并且还要实现监控、报警的功能。这是一个十分复杂的过程，并且需要做很多准备，比如说我们需要去购买云资源，然后要学习配置等工作。这个过程需要的时间是非常久的，并且也需要一定的门槛。

而我们Serverless Framework的目标就是降低用户的使用门槛，并且实现“开箱即用，0配置”。下图就是Serverless Framework的几个典型特性，这几大特性可以帮助我们尽可能地降低门槛，几乎不需要去了解底层资源的配置就可以快速构建一个Serverless的应用，同时很大程度上也简化、优化了我们后续的工作。

二、Serverless SSR应用实战

1. SSR的背景

首先讲一下SSR的背景，WEB前端渲染的模式在这几年间发生了几次演变。最早的后端渲染的模式虽然简单易上手，但是它的缺点是当你的网站随着业务变大之后，维护和更新模块的过程很麻烦，这对于web前端人员来说就十分痛苦了。

后来开发者开始把前端和后端的工作分隔开，后端的工程师主要是做一些API的封装以及调数据库和处理一些更高的业务，而前端的工程师则是做一些交互页面、页面渲染，而前端所需的数据都是通过后端工程师提供API的接口去取，这就是模式就是后来的客户端渲染。

它的优点就是由于前端、后端的开发是分离的，无论哪端需要去做改动都不会影响到另一端。但是它的不足之处也很明显，就是用户在打开网站的时候会有一个很长的等待时间，在这段时间内显示的是一个空白页面，这样会影响用户的使用体验。同时因为这是一个后端请求数据的形式，所以搜索引擎要抓取页面的数据也会比较困难。

因此在后期模式进一步演变，产生了Node.js。以前js只能在前端写前端的代码，而现在js放进了服务器端，可以在服务器端编写代码。通过一系列改良解决了空白页面的问题，提高了加载的效率及用户体验。

SSR就是我们演变过程最后的同构渲染，它虽然在对工程师的要求上有一点门槛，但是确确实实地解决了页面交互的问题以及搜索引擎搜索的问题。

1. Serverless SSR原理、优势和应用场景

Serverless SSR分为两部分，就是Serverless和SSR，SSR也就是前面提到的同构渲染，这里就不多介绍。Serverless本身是一个叫做无服务状态的应用，但它并不是没有服务器，只是我们感知不到。当你使用的时候，我们会替你去使用服务器；而当你执行完了，我们就会把它释放掉，这样就节省了资源、节约了成本。下图是Serverless SSR的整体架构图。

传统的SSR会走到Node Server服务器上，而Serverless SSR是依托于云函数计算的方式去返回响应。差别在于传统的SSR性能消耗大，运维成本高；而Serverless SSR在面对活动时可以自动扩容，不用担心承载限制，同时免去了运维。