1 - Serverless Handbook
1.1 - 开始 Serverless
什么是 serverless？
Serverless is other people’s servers running your code.
无服务器架构就是在他人的服务器上运行你的代码。
平台即服务（PaaS）的逻辑演进路径如下：PaaS 源于云计算（Cloud）, 云计算源于虚拟专用服务器（VPS）, 虚拟专用服务器源于托管服务（Colocation）, 托管服务源于桌面电脑上运行的Web服务器
-
最初我们都使用实体服务器
-
随后出现了主机托管
- 服务器托管解决了物理问题，但无法改变服务器闲置的事实。
-
后来虚拟化技术出现了
- 虚拟专用服务器（VPS）应运而生
-
云出现
-
Platform as a Service
1.2 - Serverless的优点和缺点
无服务器是一个生态系统：
核心理念如下：
- 后端尽可能少做
- 客户端将所有部分整合起来
- 静态文件通过快速内容分发网络获取
- 数据库确保数据一致性
- 尽可能多的工作在编译和部署阶段完成
无服务器架构的优势
无服务器的主要优点是不需要管理服务器。服务器成了别人的问题。
-
节省时间：
注于应用程序代码，无需再处理繁琐的维护任务。
使用无服务器架构，你能节省原本用于管理服务器的时间。
-
编程效率
您能更高效地编写后端代码。
更小、更自包含的代码（理想情况下是单一函数）带来清晰度和专注力。做好一件事并将其做到极致。
专注度提升后，你将获得：
-
更轻松的测试
-
更快速的理解
-
更短的开发周期
-
-
通常更便宜
无服务器架构则按执行次数和运行时长计费。无需预先配置大量机器以防流量激增
-
可扩展性
Google likes to call serverless architectures from prototype to prodution to planet-scale.
谷歌喜欢将无服务器架构称为从原型到生产到全球规模。
无服务器架构的缺点
-
低负载时延迟较高： 每个请求都要等待计算机从休眠状态唤醒
-
有时成本高昂： 按使用量付费的定价方式在大量使用时成本高昂。如大量的请求或较长的运行时间，或者高流量应用
-
供应商锁定
原因： 在别人的基础设施上构建
-
系统复杂性： 用系统的复杂性来换取应用代码的简洁性
1.3 - 架构原则
万物皆会故障
每种后端架构背后的设计原则都指出：
-
任何环节都可能且必将发生故障
-
你的系统仍需保持正常运行
-
让故障易于修复
如何设计弹性架构
弹性是关键。设计能够承受冲击以及错误的系统。在单个组件失效时仍能作为整体运行。
目标是：
- 隔离错误：当错误发生时隔离错误，将其限制在小范围内
- 确保操作可重现：多次触发相同操作必须产生相同结果
- 持续重试直至成功：错误往往是暂时的，重试后即可消除
- 使系统可调试：存储足够的信息以便后续追溯
- 移除无法处理的请求：有时请求无法被处理。确保这些请求不会导致系统崩溃或干扰有效请求
- 当出现异常时通知工程师：错误可能是正常运行的一部分。当错误过多时，让系统发出警报并指出问题所在
小型、独立、可重放的操作
为实现最高容错性，请确保每个操作遵循以下算法：
-
获取请求
-
检查请求是否已处理
-
若已处理，则完成
-
如果没有，就按你的方式处理
-
触发下一步
-
将请求标记为已处理