2020-05-16 【Serverless】

绿油油的大草原

今日鸡汤：

熬夜是因为没有勇气结束这一天，赖床是因为没有勇气开始这一天。

祝大家每天都能心满意足的睡去，充满期待的起来。

今天分享一下我拜读Mike Roberts大作Serverless Architecture的笔记，原文来自这里：
Serverless Architecture

Serverless架构？
Serverless architectures are application designs that incorporate third-party “Backend as a Service” (BaaS) services, and/or that include custom code run in managed, ephemeral containers on a “Functions as a Service” (FaaS) platform. By using these ideas, and related ones like single-page applications, such architectures remove much of the need for a traditional always-on server component. Serverless architectures may benefit from significantly reduced operational cost, complexity, and engineering lead time, at a cost of increased reliance on vendor dependencies and comparatively immature supporting services.

Serverless 用于描述两种场景：
1）BaaS：利用第三方且部署在云上的应用来管理服务端的逻辑和状态。
2）FaaS：服务端逻辑由应用开发人员写，但它运行在无状态的container中，且由事件驱动。

FaaS的特征?

1. 从根本上讲，FaaS 能让你在运行自己的后端代码时，不需要操心底层的服务器系统以及处理那些long-lived的服务器应用。
2. FaaS不依赖特定的框架或库，你可以用多语言来实现。
3. 与传统的部署方式完全不同，你不需要自己跑自己写好的应用，只需要把函数代码上传给FaaS provider，之后它会帮我们做所有的事情，比如创建资源、初始化VM、管理进程等等。
4. provider可以自动化、可伸缩的进行水平扩展。因此当你的服务请求量大时，它会自动的帮你进行扩展。
5. FaaS 的函数默认是通过Provider定义的事件类型触发的。当然，你也可以设置通过一个inbound的HTTP请求来触发函数。

FaaS 的启动延迟问题？
当你的函数上传到FaaS平台上，它也需要一些时间去初始化你的函数，也就是启动延迟。有两种情况：
如果之前这个函数和container已经初始化过，那么会直接拿来用，叫做“热启动”。
如果没有，那么需要重新创建container等等操作，叫做“冷启动”。冷启动会带来更多的启动延迟问题。

API Gateways
在FaaS中，可以用API Gateway去转发请求到后端不同的FaaS函数。一般来说，API Gateway会将HTTP请求参数mapping为更具体的FaaS函数参数，或者将整个HTTP请求作为一个JSON object往后传。FaaS函数执行完逻辑后将结果转发回API Gateway，API Gateway再做一个Mapping，将结果转换为标准HTTP response。

除了单纯的转发，API Gateway也会做鉴权、输入交验、返回码mapping等等。

Serverless与PasS?
引用一个经典的解释

If your PaaS can efficiently start instances in 20ms that run for half a second, then call it serverless. -- Adrian Cockcroft

也就是说，大多数PaaS应用程序都不能依据事件启停应用，而FaaS平台正是这样做的。PaaS和FaaS最大的运维区别在于扩展能力。对PaaS应用，你需要考虑如何扩展，而FaaS应用就不需要。

Serverless 与Container?
使用Serverless FaaS很重要的原因在于避免在OS级别管理应用进程，并且它的scale是自动管理的、透明的、且颗粒度很小。然而Container平台依旧需要管理cluster的大小。
对于事件驱动且每个应用模块事件类型数不多的应用，FaaS是一个好选择。但对于由大量同步请求驱动的应用程序来说，container是一个好选择。

Serverless 与NoOps?
Serverless不代表No Ops，它只在某种程度上意味着"No sysadmin“，但"ops"需要的monitor、deployment、security、networking、support、production dubugging、 system scaling仍然需要做。

优势有什么？
降低运营成本。一方面，通过与他人共享降低了在基础设施的开销，另一方面，不用自己开发和管理服务器，降低了人力成本。
从BaaS和FaaS两方面来说：
1） 通过BaaS，降低了开发成本。比如鉴权和数据库这种大多数应用程序都拥有的类似的服务，你不用自己去实现，只需要调用现成的BaaS服务即可。
2） 通过FaaS，扩展了成本。通过FaaS，你只需要按需付费。

缺陷是什么？
首先，供应商控制。通过Serverless，系统的一部分控制权给了第三方，因此，当你对你跑在它上面的服务有需求时，供应商可能无法做到及时响应。
其次，多租户问题。虽然服务提供商竭力做到让每个客户都认为是自己独占服务器，但Serverless模式下，各个客户的服务还是多租户模式，这就会存在安全问题、鲁棒性问题和性能问题。
另外，供应商锁定问题。同样的Serverless服务不同家供应商的实现可能会不尽相同，因此当你想要更换服务商时，你的运营工具、代码、服务架构和设计等各个方面都可能需要作出改变，以适应新的服务商。
还有，安全问题，Serverless模式带来很多安全问题，