大涛学长Serverless 服务选型( 二 )

Serverless 简介
维基百科对于 Serverless 有较为完备的定义 [1]:
Serverless computing is a cloud computing execution model in which the cloud provider runs the server, and dynamically manages the allocation of machine resources. Pricing is based on the actual amount of resources consumed by an application, rather than on pre-purchased units of capacity. It can be a form of utility computing.在这种计算模型下，给用户会带来如下收益：
Serverless computing can simplify the process of deploying code into production. Scaling, capacity planning and maintenance operations may be hidden from the developer or operator. Serverless code can be used in conjunction with code deployed in traditional styles, such as microservices. Alternatively, applications can be written to be purely serverless and use no provisioned servers at all.概念本质上是对问题域的抽象，是对问题域特征的总结。通过特征来理解概念，可以避免注意力集中在文字描述而非概念的价值本身。
站在用户角度，我们可以抽象出 Serverless 的如下特征：

免运维 (服务器运维、容量管理、弹性伸缩等)
按资源的使用量付费

在一定规模的公司中，若严格区分开发和运维的角色，这种计算形态其实是已经存在的，并非全新的事物。但目前的技术趋势，是期望借助云的规模和技术红利优势，通过上云来降低业务在技术侧的成本，并通过技术红利反哺业务。故业界对于 Serverless 的讨论，注意力是集中在云上的服务和产品所体现的 Serverless 能力。
Serverless 开发模型
Martin Fowler 的这篇文章 [2] 站在架构的角度，对 Serverless 开发模型做了充分的阐述，这里做个简单的总结，核心围绕三点：

Event-driven 开发模型
自动弹性伸缩
OpenAPI

Serverless 开发采用 Event-driven 模型 [3] ，围绕 HTTP/HTTPS 请求、时间、消息等 Event 的生产和响应进行架构设计。在这样的模型中， Event 的生产、处理流程是核心，通过 Event 驱动整个服务流程，注意力集中在整个处理流程。对业务理解越深刻， Event 类型和业务会越匹配，技术和业务的相互促进作用会越有效。
Event-driven 模型，使得服务常驻这种理念从必选项转变为可选项，可以更好应对业务请求量的变化，如自动弹性伸缩。同时服务非常驻，可以降低所需的资源成本和维护成本，加速项目迭代。
通过文章 [2] 的两幅图可以更直观理解：
图 2
上述云产品分类可以清晰和图 1 的模型对应起来，用户在进行选择时，先整理当前业务技术所处的阶段和痛点，确定对云上方案的需求，然后再根据云厂商的产品形态做对应，选择适合当前阶段的服务和云产品。
该对应关系重点是了解云产品定位是否可以长期满足业务需求，如：

业务技术目前所处的阶段是否有对应的 Serverless 产品形态
业务快速迭代是否会受限于云产品自身的发展
云产品的稳定如何
云产品是否可以持续为业务带来技术红利

同时还需要了解云产品是否可以伴随业务发展，重点是业务对技术的需求中，哪些是云产品层面由于定位带来的限制，哪些是当前云产品的技术实现带来的限制。
若是云产品定位带来的限制，那么就需要考虑使用和业务需求定位更匹配的云产品。若是当前技术实现的限制，那么有机会和云产品共同成长，及时给云产品反馈，使得云产品可以更好满足自身的业务需求。