姗姗来迟的 Serverless 如何助力微服务和 DevOps

对于中小型互联网创业公司来说，在技术人员紧缺的前提下，如果设计系统时需要考虑诸多例如 Web 应用服务器如何配置、数据库如何配置、消息服务中间件如何搭建等技术问题，那对于他们来说人员成本、系统维护成本会很高。

Serverless 架构应时而生，可能会大幅度改善上面提到的问题。2014 年 Serverless 架构进入大众视线，业界普遍认为，Serverless 化可大幅降低 IT 成本，将云的费用减少 10%-90%，同时还能提高服务部署效率。

2017 年 6 月腾讯云 + 未来深圳峰会上，腾讯云技术专家 黄文俊 在开发者论坛分享了腾讯 Serverless 无服务器架构最佳实践的技术内容，而且腾讯云无服务器云函数（Serverless Cloud Function）也在 4 月份全国首发，正式推出了 Serverless 产品。InfoQ 有幸采访到黄文俊，请他从 Serverless 架构、FaaS 和微服务等角度来解答一些读者比较感兴趣的话题，内容整理如下。

Serverless 发展之现状

在整个业界，大家公认为 2014 年年底 AWS 推出 Lambda 产品即标志着 Serverless 发展的开端。2016 年 Google Cloud Function 和微软 Azure Function 这两款产品的商业化，标志着 Serverless 这个产品或者服务达到了成熟期。另外在开源领域，其实还有 OpenWhisk、OpenLambda、Serverless framework、Iron.io 等项目，这些开源项目发展的也都很迅速。腾讯云在今年 4 月底正式推出了 FaaS 产品，即无服务云函数。这个产品可以简化用户运维成本，只需要上传代码就可以开发运行，利用腾讯云的全球基础设施帮助客户实现伸缩，降低用户的计算成本。

腾讯云 Serverless 服务，千呼万唤始出来

Serverless 的诞生需要两大因素：一是云产品和整个生态环境的成熟；二是客户提出了实际落地的需求。腾讯云本身拥有丰富的云产品，包括监控、日志、存储、数据库、缓存、消息队列、安全等足够成熟的云产品和服务，它们作为后端服务为云函数提供了有力支撑。同时，腾讯云越来越多的客户提出了需要用云函数产品来解决按需使用、节省费用、简化管理、快速开发的问题。

传统企业在这个过程中需求最强烈，因为他们的产品形态和应用场景更需要通过无服务技术来解决问题：一是定时任务的数据采集、收集、汇聚、计算，实时数据的收集、汇聚、计算和展示，再就是多媒体和图片的转换、优化、美化、分析、抽取，还有部分客户使用云函数进行后端服务或者后端业务的封装和开发，这都是比较典型的无服务计算的应用场景。

正是在这种需求的强烈推动下，腾讯云推出了 Serverless 服务。

其实很多初创团队和传统企业为了减少运维成本和人力成本，都会采用第三方的 CI/CD 服务，而 Serverless 服务在一定程度上也是可以解决初创团队在这方面的需求的。

腾讯云 Serverless：三年磨一剑

2014 年 Serverless 发展到现在，这三年里腾讯云做了哪些研发准备，经历了哪些测试阶段？效果如何呢？黄文俊说到，研发准备阶段可以分为两方面：一是底层，二是生态。

从底层来说，需要对资源调度能力不断提升，原有的资源调度粒度较粗，需要提升到更细粒度的资源控制能力；再就是需要做到对用户或者租户更好的隔离，确保函数或数据安全；另外对于屏蔽硬件差异、计算能力动态校正和运行调度平台优化上都做了很多基础能力的提升。从生态上来说，这几年，腾讯云推出了各种云化服务和产品，像对象存储、云数据库、分布式数据库、云缓存和消息队列等，在一定程度上也是对 Serverless 产品的推出打下了基础。

Serverless 和原有的云服务器相比，它的最明显特点就是调度粒度已经细到了函数级别。而且，Serverless 天生具有事件触发的属性，对于 web 服务来说，原有的云服务器，在没有客户访问的时候也需要维持最低的资源消耗；在遇到高并发量、高请求量的时候，则需要弹性伸缩；而 Serverless 的弹性完全是取决于用户的请求数，没有用户请求的时候没有函数运行，在有高峰来临的时候，相应的弹性也完全适配用户的访问。这个弹性并发数在理论上是没有最高峰值的，而从实际出发，腾讯云为了防止用户超费用、超流量的情况，而做了一些安全策略，有相应的应用防护、流量监控、并发流控的策略。

如何区分 FaaS、PaaS 和 Serverless

Serverless 可以说是一种流程、一种工具或是一种架构，而 FaaS 属于 Serverless 的子集。Serverless 包含了 FaaS、BaaS 这两个概念，FaaS 即 Function as a Service 函数即服务，BaaS 即 Backend as a Service 后端即服务。FaaS 是云化的函数，把函数放到云端，通过云进行函数级别的调度、弹性；BaaS 指的是各种云化的产品和服务，云存储、云数据库、云监控、云告警，都可以囊括在 BaaS 里面。而 PaaS，更多考虑的是提供一个通用平台，把平台提供给用户使用，用户自己去完成计算资源的分配、调度、扩缩容等工作。

黄文俊在这里进一步介绍了 FaaS，实际上这个函数是用户自身的一段业务代码，这段业务代码由事件触发，而支持的事件有很多种，最简单的，例如和对象存储对接之后，某个数据文件的上传即可触发函数执行，对文件进行分析，分析之后的结果，可以再次写到对象存储中或者云数据库里。发事件来源有很多种，包括对象存储里面的各种事件、前端 HTTP 请求、消息队列里的消息，甚至是监控中某个事件告警，均可以用来触发函数的执行。总的来说，FaaS 在云里就像粘合剂，把各个云产品或者服务连接在一起，形成一个链条，或类似 IFTTT 的服务。

FaaS 的诞生场景也是为了满足客户不同的需求，从整个云的发展历史来看，最开始的物理机，完全没有弹性能力，或者弹性周期很长，要经历采购、到货、部署上线；再到后来的云服务器，实现了粗粒度的弹性，可以立即申请，立即使用，不再使用时可以立即释放；到容器时，弹性能力就更细了，每个运行的容器都可以弹性伸缩，跨云调度；而到了 Serverless，弹性的能力到了函数级别，细到执行的某段代码都可以进行弹性；所以整个云的发展，就是计算能力的粒度细化，同时弹性能力的增强，因此可以说 FaaS 是云发展的必经之路。

Serverless 给运维带来的“冲击”不可小觑

有人说 Serverless 并不等于没有运维，Serverless 接下来在发展过程中肯定会给运维带来冲击，对于这一点，黄文俊则解释道，Serverless 也需要运维，只不过不像维护传统的服务器或者自己安装的数据库那样去运维。

黄文俊觉得 Serverless 的运维需要在以下四点有所提升，一是云化运维，要充分运用云上的各种运维产品，包括云日志、监控、告警、短信平台的对接，甚至微信的消息，还可以运用云函数本身来进行运维工作，利用这些工具来搭建和使用运维平台。二是业务运维，不仅要做普通的运维工作，还要从业务角度来去进行更深入的查看，分析业务瓶颈。三是充分利用原有能力的组合，尤其是在新业务开发过程中，如何通过原有的函数组合和模块组合实现功能。四是业务函数或者模块如何进行复杂调用的跟踪和分析。对于这种云化的环境，DevOps 优势体现需要更明显，开发和运维都要 DevOps，开发和运维两者需要结合得更紧密，两者作为一个团队来负责一个产品或服务的生命周期，两者需要通力合作，对整个产品或服务完整的生命周期持续跟踪、改进。

讲了这么多内容，也许有人会问，这是减轻了运维人员工作量还是增加运维人员的工作量了呢？其实这并不是减轻或增加工作量的问题，黄文俊说，要从全新的角度看待运维，而不是做好传统的服务器或数据库运维工作就行，而是需要提升自己，从业务层面甚至是决策层面来看待平台和整个业务。

微服务会大面积迁移到 Serverless 上？

微服务和 Serverless 是比较切合的，都会强调系统的解耦，未来将微服务迁移到 Serverless 有可能是顺理成章或者很容易的事情，对于这一点，黄文俊认为，微服务也是最近两年才开始火起来的，Serverless 和微服务天生都是服务属性。从微服务到 Serverless 的迁移过程中，还需要对微服务模块更细的拆解，拆解到函数级别，而每个函数就是最简功能，有可能就是微服务里的某个功能点。在拆解过程中，除了服务拆解、功能拆解、函数拆解，对开发者来说，还需要提升其他方面的能力，包括开发管理、上线管理、CI/CD 流程，上线之后的版本管理，调用跟踪和 bug 跟踪等。另外，在转移到 Serverless 上时还需要考虑服务的安全性，包括应用安全，数据安全。腾讯云在这方面会不断的提升产品能力，协助客户转移到 Serverless 之后能更容易、更安全，更方便的实现业务或功能。

目前，已经有些公司尝试用 Serverless，甚至把 Serverless 服务用于生产环境里面，还专门成立了 Serverless 部门，这是不是就代表着 Serverless 的未来更受欢迎？对于这一点，黄文俊也是认可的。实际上，Serverless 作为一套细粒度的标准化计算框架，代表着一种全新的计算提供能力，类似原有的云服务器、容器，都是以计算能力的形式提供，Serverless 未来会成为和云服务器、容器一样成为计算提供方式的一种，并且会持续演进。目前来看，Serverless 还处在发展早期，各个云厂家都有其各自的产品形态，在业界还没有形成 Serverless 的统一标准，因此这个行业还会持续发展和演进。

至于这个标准的建立，黄文俊说，不可能是某一个公司独立掌控，而是需要社区共同参与讨论、碰撞才会逐渐形成一些标准，而且这个标准对广大开发者是有好处的，可以帮助开发者脱离行业或者供应商的业务绑定，让函数在一定标准下任意在云端迁移，同时这种标准的推出也能够促使更多开发者转移到 Serverless 上来。

如果时机成熟的话，腾讯云也会回报社区，开源更多的计算接口标准或者计算实现方式，在 Serverless 上做一定的开源探索和尝试。

初创团队如何拥抱 Serverless？

初创团队使用 Serverless 需要从两个角度来评估，业务架构角度和开发运维角度。

业务架构角度包含三点：

• 一是微服务化，首先进行业务拆分，然后服务拆分，拆分之后进行云函数的设计。
• 二是提升组装能力，拆分之后再进行组装，能够通过各个服务模块、云函数、后端服务例如云数据库、云缓存、对象存储等，组装出新的业务。
• 三是利用 Serverless，业务快速上线和快速迭代，加快反馈速度，加快业务调整速度。

从开发和运维的角度来说，DevOps 是最优的发展方向：

• 一是做好 CI/CD，配置管理，实现 X as Code。
• 二是运维方面要进行云集成和云能力的探索，充分利用云监控、云日志、告警事件来提升运维能力。
• 三是提升整个团队的跨界思考能力，开发在最初写代码的时候就要考虑到维护性、安全性，资源利用和费用支出；运维人员要从业务场景、业务瓶颈、业务配置角度提升运维能力。

对于初创团队来说一开始推行微服务架构是最合适的，因为他们没有历史包袱，能够直接利用云函数和后端服务计算，直接打造整个云化业务，充分利用云计算能力，来节省宝贵人力，加快业务发展，快速迭代、快速反馈。

感谢薛梁对本文的策划和审校。

嘉宾介绍：

黄文俊，腾讯云技术专家。拥有多年企业级系统开发和架构工作经验，研究方向为企业级存储、容器平台、云计算；关注于微服务设计思考，开发流程优化，容器技术应用等领域。