在金庸的笔下，独孤求败是一个从未正式出场的奇人，他功力大成之后，草木竹石可为剑，无剑胜有剑；而在互联网世界里，开发者也一样有着不同的境界，先是从基础架构做起，技术成熟后又需大包大揽，但架构越扩越大，开发者负担越来越重，兼顾服务器等基础架构和业务架构难免让人顾此失彼。技术也如武学一样，瓶颈突破，就是大成，无招胜有招的概念推动下，Serverless 架构也就应运而生。
Serverless 的理念出现时间并不长，但是却迅速吸引到了大量开发者的关注。其比 微服务 等模块化理念更为激进，直接将底层的服务器等架构剥离，让开发者“肆无忌惮”的沉浸在业务相关的架构开发之中，而不必顾忌原有的底层架构约束和限制。
8 月 18 日，腾讯云联合 InfoQ 举办的云 + 社区技术沙龙就聚焦在了 Serverless 架构之上。无招无剑无服务器，又当如何一举突破业务难题呢？此次沙龙从 Serverless 架构场景化应用、基于 Serverless 架构的小程序开发、API 网关与 SCF 深度结合应用、对象存储与 SCF 深度结合应用、享受纯粹的编程乐趣等五大主题内容，探索 Serverless 技术的应用难点，带领开发者实现无招胜有招。本文整理了讲师演讲精彩内容，感兴趣的读者可以点击【阅读原文】下载讲师演讲资料。
Serverless 架构场景化应用
Serverless 架构是近两年刚刚火起来的架构，那么在程序员眼中的 Serverless 究竟是怎样的存在呢？又如何才能把这种架构应用到业务中中去呢？
Serverless 架构介绍
首先从云计算发展的过程来看，早期大多数企业采用的是物理机托管方式，设备和 运维 需要 IDC 人员协助，投入成本较高；而云时代后，虚拟化技术发展运用，云主机代替了物理机运营，基础设施即服务（IaaS）开始流行；在容器平台时代到来后，其实还有一部分 IaaS 运维问题，这部分问题下沉到运维人员进行操作，开发者去关注应用层所需要的计算资源和存储资源的使用，这也就是平台即服务（PaaS）。
PaaS 多通过容器平台呈现，运维人员和开发人员已经开始进行抽离，在进一步发展后开始实现函数即服务（FaaS），此时运营人员并不需要关注底层的能力，而只需要关注业务相关的事情，这就使得整体业务实现了轻量化。
而 Serverless 更关注的就是上层业务的展示。其分为两种，函数即服务（FaaS）和后端即服务（BaaS）。FaaS 将原有的计算能力进行了进一步抽离，而 BaaS 则是将 COS、数据块等服务在云端开通使用，而这些服务的后端运维等都交给云。由于这些都不需要感知底层服务器架构，所以二者合起来就被称为 Serverless 架构。
FaaS 的工作原理是怎样的呢？在原来，程序员代码上传到容器或虚拟机上，启动一个进程形式代码就可以实现运转，同时能够接受外部请求和响应等动作；而 Serverless 则有不同，首先需要采用计算托管服务，用户提交代码后，代码将会以云函数形式提交到云平台进行代管，然后配置触发器设置触发源，确定代码只有在事件到了时代码才会运行。也就是说 Serverless 是按需运行的且是触发型运行的。
Serverless 的运行具有自动并发、按需运行、按使用量计费的风格。云平台会根据事件堆积的情况自动进行并发，与传统容器相比 FaaS 是完全自动的运行。这种运行特点就是按需出现，代码只有在运行起来之后才会占用计算资源，降低了平时的资源占用率。而 FaaS 的计费也是按照运行的情况进行的，能够很好的适应波峰和波谷的业务需求。
总结来看，FaaS 拥有如下几种特点，首先 FaaS 会请求自动平行调整服务资源，拥有近乎无限的弹性扩容计算能力；其次，开发者只需要聚焦代码逻辑，也就是最核心的代码片段，能够跳过其他复杂的、无聊的工作；FaaS 具有秒级部署的特点，运行无状态，能够轻易实现快速迭代、极速部署的目标；自动触发，完全由事件触发（event-trigger），空闲时不会占用资源；更重要的一点，由于开发者不再需要管理底层计算资源的服务器，也不需要去优化服务器，这就使其几乎达到零运维的水准。
SCF 无服务器云函数
腾讯云所打造的无服务器云函数（Serverless Cloud Function,SCF）也是以计算托管为目的进行研发的。和此前研发的对象存储（Cloud Object Storage,COS）一样，在使用时不需要关心底层运维、虚拟机或物理机安全性等问题，只需使用便可以。
FaaS 产品的使用方法都很简单，用户只需要关注核心代码的编写，也就是真正的业务逻辑即可。FaaS 的特点是不需要用户考虑高并发问题的，因为高并发事实上就是多个实例处理进行，业务编写时仅需要考虑事件处理即可。
整体来看，FaaS 编写只需要两步即可，第一步，编写核心代码，如果不需要外部依赖库，可直接通过控制台编辑器编写；而如果需要外部依赖，可在本地编写并调试后，提交代码压缩包；第二步，配置触发方式，即设置代码在何种条件下被运行，在内部触发器有 COS Bucket 上传文件、API 请求等；而外部触发则可以通过云 API 直接调用等。仅需要这两步就可以解决基础设施、环境配置等问题，在需要时运行代码。
目前，SCF 的运行环境支持 Python、Node.js、java、PHP、Golang 等语言。在使用方面，触发器越多，云函数能使用的场景就越多。SCF 能够支持的触发器包括了云 API、定时器、COS、CMQ Topic、API 网关、Ckafka 等触发器。
Serverless 使用场景
Serverless 场景中最常用到的就是 API 服务。原本要打造一个应用，无论是手机 APP、浏览器还是小程序介入使用都是需要通过 API 实现的，不同的前端都需要通过 Web 服务器连接后端业务代码，此外还有各种文件存储、数据库和缓存等连接。
而 API 服务转向 Serverless 架构后，前端对接的端口依然不变，而后面连接则从 Web 服务器变为了 API 网关，进而转化给云函数，触发云函数执行。云函数的执行要求无状态，这样后续的云端产品也可以完成对接，无论是 COS、CDB、CRedis 等都可以与产品进行对接。
这套体系中，API 网关可以提供 API 能力，为了方便开发也可以提供 SDK 服务，方便嵌入小程序、APP 或者网页中完成 API 调用。云函数主要完成业务逻辑处理，而状态数据及其他数据的存储则依赖于后面的文件存储和数据库等进行。API 服务是 Serverless 最常用的一种落地形式。
Ckafka 消息处理也是一种落地形式。Ckafka 目前的应用场景主要在日志存储和收集，即多台前端应用服务器将产生的日志会归档到 Ckafka，然后 Ckafka 在进行归档或后续分析。Ckafka 和云函数的对接，是由 Ckafka 收到的信息来进行收集处理，把这些推给云函数，然后再把这些消息写入对象存储中或者数据库等其他形式完成归档。
此外，如对象存储文件处理、CMQ 消息处理、定时任务等场景的应用也都会有不同的实际落地使用场景，这里便不多做介绍，读者可以在文末阅读全文中找到 PPT 有其他介绍。
总结来看，Serverless 架构对用户来讲，是在提高快速构建业务能力及上线速度，按需使用，按实际用量付费，使得这一架构灵活性更高；自动扩展，降低运维需求也让运维人员更偏重流程化运营。而 FaaS 作为 Serverless 架构中的计算组件，起到了粘合各个其他产品或服务的作用，并提供实现业务逻辑的能力。
基于 Serverless 架构的小程序开发
前面讲了 Serverless 的 FaaS 服务产品，这里再来讲一个 BaaS 类 云服务 。微信小程序有着大量的开发者和用户，那么如何降低开发门槛呢？小程序云开发就是一种可以帮助开发者提升小程序开发效率的 baas 类型的云服务。
小程序云开发简介
通过封装基础服务的访问逻辑，提供易用的小程序 SDK，最大限度的降低小程序开发的工作量。让开发者可以跳过服务器基础服务搭建的整个流程，无需关注服务器资源维护，专注于产品业务逻辑的开发。帮助实现小程序应用的快速上线、功能迭代，满足产品快速升级需求。
目前，小程序 API 已经内置了云 SDK，不需任何安装，开箱即用。只要你已经注册过小程序，就可以在小程序开发者工具里一键开通小程序云服务，不需要额外的注册流程、认证信息、注册域名、备案流程或者直接管理任何服务器资源。小程序云支持数据库、文件存储和云函数等基础服务，由于底层资源由腾讯云支持，用户不必考虑数据和安全等问题。
所具备云服务资源快速拓展能力，能够帮助产品应对业务爆发等增长场景。此外，云控制台内置在小程序 IDE，支持免认证登录，方便管理云资源。云控制台可以提供后台管理服务，方便查看小程序用户、接口调用次数、图形化查看以及修改数据库和文件存储系统的数据。
小程序开发模式的转变
从 0 开始，开发一款小程序需要做多少工作呢？我们来简单看一下，前期的准备工作有很多。首先要去微信公众平台注册一个小程序，拿到一个 appid；需要数据接口，所以要购域名并进行必要的备案；需要 web 服务，那就得购买一台主机，安装个 web 服务器；为保障代码运行，安装基础软件如 node.js 或者 PHP 等；为保证网络数据的安全传输，需要购买并部署 https；数据存储是最基础的需求，购数据库不能少，而如果应用还需要文件存储，那就要再购买一个文件存储服务，同时买一个 CDN 确保文件访问速度，这样才能有好的用户体验。
如此多的事情事实上只是解决了一个前提问题，而且这些工作之后的文档查看、数据库和文件存储使用、域名配置解析都是必不可少的工作。那么接下来需要开启的是产品功能的开发，编写业务代码、小程序后端代码、编写小程序代码然后如果一切都顺利的话就可以提交审核然后上线，看起来就很圆满。但是上线之后，服务器维护不能停，资源不够用要拓展，接口效率低需要优化，服务不稳定需要定位问题，各种监控运维还会越来越复杂。
所以，小程序云开发就是要把这些繁琐的的维护后端服务的可用性工作全部交托出去完成，而开发者只需要注意自己的业务代码就可以了。
那么小程序云开发究竟是如何做到的呢？首先用户可以在在小程序里使用内置的 SDK 完成大部分功能；如果需要云函数，只要上传代码，就能在小程序里直接调用。在产品功能确定后，可以立即开始上手编码产品功能并快速上线；上线后开发者仍然只需关注产品迭代，服务器能力拓展可以一键解决。
小程序云开发的开发模式与传统的 client-server 结构有所不同，用户不需要维护服务端基础设施。相关性能监控、接口告警、扩容、服务安全等内容也不需要开发者关注，而是交由腾讯云方面进行管理。开发者只需要在小程序内使用内置云 SDK 访问云解决方案的服务，就可以使用各种云资源和高度抽象的服务器资源，这其中包括了文件存储 API、数据库 API、云函数 API 等，开发者只需要利用这些接口，开发业务相关的功能即可。
小程序云开发的能力
在小程序云开发中有很多有趣的功能，其中，云控制台能够提供基础的能力和用户管理，包括用户的公开信息和访问注册时间等，帮助开发者管理用户。数据库也可以在云控制台里一键创建集合，可以管理数据、索引以及用户的数据更改。云控制台的文件功能中可以上传、搜索或者删除文件，云函数功能里可以新增函数、修改函数的配置，方便用户进行云函数调试和查看监控等。
用户管理是云开发的基础能力，不需开发者做任何操作，即使 API 调用也不需要，开发者可以直接在云函数里读取到当前用户的 openID，可以用来在云函数里来封装一个用户登录的功能，免去了在服务端做登录 token 检查换取 openID 的操作。
数据库底层基于 NoSQL，提供高效的读写操作性能。默认一主二从，不用担心数据安全和读的效率。用户的 openid 默认写入数据库，调用 API 插入一条数据后，记录里会有个叫 _openid 的字段，方便做基于用户的操作。
文件存储默认接入 CDN，保证文件读的速度；文件多种权限可以自行选择，满足多种不同场景；云函数则是基于腾讯云 scf 进行优化后的产品，保证服务质量绝对不逊于自建服务。目前支持 Node.js 8 以上版本，开发者可以用最新的 js 语法快速编写业务代码。在云函数里可以任意调用外部服务，各种不方便在客户端处理的敏感逻辑，以及使用 admin-sdk 操作所有数据库和文件存储服务。
目前小程序云开发的公测已经于 8 月 16 号开始，目前支持免费额度的资源让你可以先行体验。参加公测资格可以在小程序开发者官网申请，申请到公测资格后，开发者可以先使用免费额度开发服务或者体验开发流程，免费额度支持量级不大的小程序或者一些流量不大的功能。
API 网关与 SCF 深度结合应用
API 网关和 SCF 深度结合应用后能够形成一套比较完整的 Serverless 解决方案。但腾讯云的 API 网关服务并非与 SCF 绑定应用的，但是尽管目前市场上也有一些开源的 API 网关产品，可是运维成本、费用问题等都会分担在开发者身上，那么何不以服务形式做一款产品提供给客户呢？于是乎腾讯云的 API 网关就这样诞生了。
API 网关产品简介
腾讯云 API 网关是一种可以对多种后端统一管理、鉴权、限流、映射、将后端能力以 API 形式统一输出给多种前端进行调用的 API 托管服务。开发者可以在 API 网关上创建、发布、上线、下线等 API 服务。
API 网关有以下几个能力：提供统一的鉴权和认证方法，且鉴权能力灵活，支持密钥对 oauth 等鉴权模式；提供 API 转换和隐藏，通过映射转换，隐藏实际实现业务的后端；流控和配额，能为每个环境、API、认证人群提供不一样的流控策略和配额限制；输出 API 能力，可将 API 能力输出给第三方，或者注册到 API 市场售卖；
自动文档和 SDK，完成 API 配置后即可提供自动化生成的 API 文档和 SDK，更方便的支持 API 使用者的开发，或通过 swagger 直接导入生成 API；强负载能力，依赖腾讯大平台的负载能力，不惧突发大请求；ACL 控制，针对每个 API 的黑白名单，可有效做到对 API 的安全防护。
API 网关的角色分为两种，一种是发布者，一种是调用者，这两种人也可以是同一批人。发布者发布 API 到 API 网关中，然后利用提供的参数进行认证、鉴权、映射等，提供配置后直接在 API 网关上进行调试，可以在控制台上审查是否正常，如果通过了测试就可以正常发布提供给调用者使用。
API 网关会为调用者提供一些默认的二级域名，然后生成文档 SDK，调用者可以直接使用文档 SDK；调用后，API 网关会根据之前发布的配置对签单请求做校验，认证，鉴权等基础校验。后端的时候会做参数的映射，最终把请求发到后端业务。后端可以对接很多云服务，如 SCF 或传统云服务等。
API 网关与 SCF 结合使用
那么 API 网关是如何与 SCF 结合的呢？目前来讲，SCF 通过 API 网关暴露 restful API 给各种前端进行调用，而 API 网关会统一管理所有的后台函数。
在安全与限流方面，很多业务中，函数将自己的能力通过 HTTP 开放出去时，需要辨别调用者，对自身的业务有安全性诉求。通过 API 网关可对 SCF 中的业务调用进行安全认证如密钥对、OAuth、ACL 管理等，保证后台业务的安全性。
而每个函数业务能承载的业务量不同，函数使用者希望对每个函数调用做流量管理。通过 API 网关可以对后端的函数调用开启 QPS 限流，以及配额限制。SCF 通过 API 网关暴露 restful API 给各种前端进行调用。API 网关统一管理所有的后台函数。
在 CORS 方面，开发者常常将 css、js 等静态资源放在另外一个域中，访问时需要浏览器跨域调用。API 网关可以帮助后端 SCF 处理跨域请求，无需函数的开发者关心跨域问题。响应集成方面，SCF 函数返回的响应 body，可按照模板进行填写，所需的信息填写后返回给 API 网关，API 网关会将此模板中的信息抽取出来，组成新的 HTTP 格式请求返回给前端。
在响应透传方面，API 网关与 SCF 之间同样为 HTTP 请求，SCF 函数返回的响应在响应透传模式下，会被全部放进 API 网关的响应 body 中，返回给调用者。Websocket 能力是函数计算里的一个难点，因为本身函数不是常驻的。
用户选用 Websocket 方式时，API 网关会对每个调用者生成唯一的 ID 用来标识调用者，API 网关与前端调用者之间为 Websocket 长连接。与后端 SCF 依然为 HTTP。SCF 上的函数在需要推送时将信息发回到 API 网关提供的专有内网域名，并携带 API 网关分发的唯一 ID，API 网关将信息推送到前端。
开放到 API 市场后，用户将自身在 SCF 上的业务能力通过 API 网关上架到 API 市场中进行售卖，可直接售卖给使用者，获取收入。完整的上架流程均由腾讯云提供。帮助使用者快速开放自身的能力与数据。
在高并发场景下，当用户请求的并发量极大时，并且有大量 HTTPS 时，大量请求十分消耗 CPU。API 网关的高性能，及对 HTTPS 请求的异步处理，可以应对高并发场景，保证服务可用；当用户的某些静态资源需要快速调用成功，而 SCF 有冷启动无法满足时，API 网关后续将提供缓存能力，将部分前端资源缓存在 API 网关的缓存中。
使用场景与费用
具体到一些场景来看，对于小程序、公众号和电商等场景中时，用户将电商的部分系统或者小程序的后端系统等部署在 SCF 上，结合云上的 CVM，数据库、COS 等产品使用作为后端业务；API 网关对所有的后端系统统一出接口，提供给小程序、公众号或其他前端进行调用，统一管理 API，前后端解耦，用户利用 API 网关可帮助 SCF 中的系统对前端进行信息推送。
而对于 AI 推理和翻译等场景中，用户将自身的计算模型、翻译模型等放在 SCF 上，每次通过 API 网关触发来触发计算。API 网关将请求带来的数据给到后端，并对每个请求做鉴权认证或 ACL 管理保障使用的安全性。
在费用方面，目前是有减免的，每月有一百万次的免费调用。目前这一产品也没有收费，预计到年底开始收费，但是即便收费整个资源费用是非常便宜的。
SCF 与 COS 的结合应用
在谈 COS 之前先了解一下腾讯云的存储平台，在 2006 年的时候腾讯云发布了第一代分布式存储平台 TFS。经过近十年发展，2014 年存储量达到 500PB，文件量超过万亿。随着腾讯云推出，腾讯云存储系统开始对外服务，服务腾讯 EB 级别的分布式存储平台，开放商用标准化能力，服务了包括 QQ、58 等在内的上万客户。
对象存储 COS 简介
那么对象存储（Cloud Object Storage，COS）是什么呢？对象存储是腾讯云提供的面向非结构化数据，支持 HTTP/HTTPS 协议访问的分布式存储服务，它能容纳海量数据并保证用户对带宽和容量扩充无感知，可以作为大数据计算与分析的数据池。
无论是手机 APP、网站或 HTML5 页面，对象存储可根据应用程序类型提供各语言 SDK，实现无缝接入。当业务爆发、用户产生内容 (UGC) 突增时，对象存储将根据请求和流量的需求自动扩展，能够应对业务突发访问状况。
上图是对象存储 COS 应用服务架构，最上面是传输服务，当用户上传到 COS 延时高时，可以通过 CDN、运营商服务或者腾讯云专线服务进行加速；应用接入层可以选择应用服务，比如图片智能识别和处理、音视频处理、文档处理等。
COS 也可以和云上的大数据套件对接，用户可以用云上的 Ckafca 并把日志等数据直接写入 COS，COS 和大数据对接来做数据分析。再下面是数据接口，包括了一些 COS 底层应用和分布式数据存储，用户可以通过 API 或者通过 HTTP REST 来访问和操作数据。
SCF 与 COS 联动场景介绍
COS 和 SCF 结合有不少应用场景和架构。COS-SCF 应用架构大体包括如下内容，用户部分可以通过上传代码和配置触发器实现云函数平台的调控，而在云函数平台方面，用户借助 COS 触发器可以选择上传或者删除事件来触发云函数。对于上传到 COS 的文件，用户可以在云函数平台进行日志分析、跨区域复制、写云数据库、图片处理和语音识别等，甚至可以利用 SCF 对接 IoT 平台，将数据推向 IoT 终端。
通过两者联动的使用方式，能够为客户带来 COS 内文件的自动化处理流程；利用 SCF 高并发、低成本的特性参与 COS 文件的分析处理；联动云上的多个产品，扩充了应用场景。这对于用户而言，能够带来三大优势，实现一次配置，自动运行；回调灵活，对接业务；按需使用，成本低廉。
在费用方面，COS 和 SCF 结合时需要分别来看。COS 每个月有一些免费额度，在官网上有具体呈现。而 SCF 在 2018 年下半年到年底之前是完全免费的，今后即便收费价格也会相对低廉，每月还会有免费额度。
从客户案例来看，视频文件自动转码流程中，用户视频文件上传后，利用云上的转码接口，然后根据不同的码率写入 COS，COS 可以结合 CDN 进行加速。而这些都在云端操作，几乎不需要运维，价格也相对低廉。
在这个案例中，客户的痛点在于用户上传的视频文件格式、帧率多样，进行直播或转播的时候难以适应多终端类型，自建转码服务耗时耗力，还需要专人运维；而使用 COS 作为存储介质更加可靠，也不用担心容量问题；COS 上传事件自动触发 SCF，SCF 可以直接内部调用视频转码 API，速度更快；SCF 的高并发特性可以轻松应对峰值请求；整体方案实现云上资源的自动联动，几乎无需运维。
产品最佳实践
COS 和 SCF 使用的过程中，有以下几点需要注意。首先，COS 和 SCF 触发的流程中，COS 会把上传和删除事件写到自己的消息队列，在和云函数 SCF 消息队列对接，将事件投回到云函数消息队列，云函数消息队列会触发云函数执行每次的分析操作，这其实是一种异步调用。
COS 始终使用异步调用类型来调用函数，结果不会返回给 COS。在正常情况下，如果没有消息堆积，这一过程就是毫秒级；但如果某时刻有大量用户做上传视频或者删除动作，就可能产生消息堆积，则会在秒级进行 SCF 运行。
需要注意的是，COS 触发 SCF 只支持同地域配置，事件类型目前支持“文件上传”和“文件删除”两种类型。目前，COS 支持前后缀过滤触发以及同一 Bucket 中多种事件类型触发 SCF 这些功能正在开发之中。
为了避免 COS 的事件生产投递出现错误，COS 针对 Bucket 的每个事件，如文件上传、删除等，限制只能绑定一个可触发的函数。一般来讲，单个云函数支持绑定 2 个 COS 触发器，在指定的 COS Bucket 发生对象创建或对象删除事件时，会将 JSON 格式事件数据发送给绑定的 SCF 函数。
从微服务到 Serverless 架构
那么 Serverless 技术在其他公司又有怎样的应用呢？本次沙龙有幸也邀请到了同程艺龙机票事业群王晓波老师分享了同程在 Serverless 架构实践中的一些经验。
为什么要用 Serverless
为什么要做 Serverless？因为需要抢时间，很多业务来讲，时间才是真正的成本，对于电商来讲更是如此。
从后台的 SQL 支持到真正形成一个服务，之间需要做的事情有很多。一个就是环境，从开发环境、测试环境、生产环境到灰度环境等各种环境，很多故障都是由此产生。而环境的崩溃对整体周期的影响一直很严重。再个就是框架，框架层出不穷，进而会出现很多问题，难以统一。各种调用胡乱依赖，代码以外的东西需要考虑的太多，导致各种开发框架烦心事居多。
再一个就是部署，部署位置、上线下线和各种配置都需要考虑。还有运维，现在很多运维与开发会有矛盾，那么一个大的趋势就是无运维化，让运维躲在技术后面。再一个是扩容，但扩容永远无法回避的就是流量到来时难以承担，而且成本效率和资源浪费如何平衡都很难兼顾。
此前，在把应用全部微服务化之后，上千个微服务应用可以是由更多的服务拼装起来，而且这些微服务还在不断的迭代和调试，这就又需要大量的工具支撑，非常痛苦。而在性能方面，往往做好了之后才会去考虑高并发等更多的问题；安全领域是个很容易忽视的问题，但一旦出问题了，他的重要性就会显现出来，这些结合在一起就会显得太过复杂。
写代码本质是工程学，工程应该有流水线和分工，所有这些问题造成了流水线上的障碍，这就形成了应用 Serverless 架构的的一个动力。
Serverless 与传统架构的比较
传统系统架构已经应用了多年，其特点大家也都理解。传统架构能够有粗粒度的服务展现，拥有一定的系统伸缩性能力，但是其重了框架，轻了架构。而传统架构的问题也一样明显，一个简单的应用变的不简单了。
不只是网站，各种应用增加到上千个，想一想都玩不动了；流量动辄海量，每天很容易就有数亿级请求量；原本很简单的一个 SQL，一升级没法用了；最痛苦的是连缓存也跑不动，服务器加到不知道放到哪里好；运维最忙的事怎么是各种背不完的锅，总体看来就是又大又乱，一头雾水。
那么从传统架构转到微服务架构就好了吗？确实能够有一定的改善，首先接口得以统一，也能够通过限流、回退、隔离、熔断等完成容错处理；提供全链路的服务监控，利用服务注册发现，控制服务的 API 数量；统一了代码框架，能够支持多种编程语言；服务依赖关系可以利用服务的分级进行管理，服务的 CI/CD 也有明显的提升。
但是，微服务架构也是有着他的问题的。首先需要注意的是，微服务整体推进是要时间的，不可能一次改完，中间过程需要过渡，还有很多为快度打样的做的单体应用或一些简单应用，一个微服务经过长时间迭代更新后也需要新重构。
而且，在整个体系中并是只有微服务一种架构，在管理的时候，调用太多会因此不得不变复杂起来；而且，写一个微服务的成本并不小，开发过程的调试也比较麻烦；在微服务的数量越来越多后，虽然跑在 Docker 之上但一样资源占用巨大，在运维方面虽然有 DevOps，但依然有点麻烦。
微服务化之后，总结起来就是自已挖个坑然后自已再填上坑，那么能不能用一两个小时写个服务并上线，而不用关心服务器在哪部署多少？能不能只需要配管人员的配置接下来就完全是代码的事，开发人员可以像操作 IDE 那样完成他不熟悉的技能？如果代码没跑到最好能否不要计算资源成本？我们不需要人人都是全栈工程师，他就想好好写代码，而运维能否做到完全智能的，让系统与算法去解决问题? 在这些思考中，同程开始采用 Serverless 架构。
Serverless 架构解决了痛点问题，如何在业务快速变化中如何更快地开发。当然，在这快速地开发中有很多是快不起来的，比如开发环境的问题，上线部署的问题，应用弹性设计问题，可运维性的问题等等。但优势在于，Serverless 架构能够居于原有基础服务，利用原有容器平台，集成能集成的一切。
Serverless 架构的应用与未来计划
Serverless 架构有很多实用的功能，在隔离方面，采用了底层容器级隔离。在支持 Node.Js 和 LUA 支持语主级隔离（语言 VM），可以通过 Gateway 访问到应用，然后根据流量自动拉起应用和自动扩容部署实例。
资源利用率方面，最小单元能够部署 4 台物理服务器，最多可支持 1 万个应用；Serverless 在平台化建设过程中采用了动态负载均衡器，拥有豪秒级别的弹性扩容和缩容的能力；数据服务系统让 Serverless 服务能够访问常规数据源；并且将所有的功能可视化，可配置化，不再需要考虑本地环境和有多少环境不再被关注。
那么 Serverless 架构为企业节省了哪些东西呢？首先，初始项目的成本节约了有 90% 左右，申请 git、安装框架、安装模块等全部省略掉了；其次就是数据源了，定义编写路由、数据源连接、拦截器控制器、日志记录等节省约有 80%；再者就是代码编写，这块该写的还是要写的，但是工具函数、常用类库、逻辑编写、程序调试、代码版本控制等大概能提升 40% 效率。而运维角度的参与度提升是非常高的，申请应用上线、配置运行环境、申请访问路径等都可以节省掉，整体提升能够达到 90% 左右。
那么哪些代码可以放在这个平台上跑呢？几乎所有的网页、活动推广、部分变化量大的后台、实时变化大的都放进去了。因为这些页面变化非常快，对市场把握度不是很大，所以也需要实验，需要快速的变现能力，可以通过 Serverless 实现。此外，一些逻辑简单的业务服务，一些逻辑变化快的业务服务，大量的临时的小服务，都可以放在平台上。
在未来，Serverless 平台还可以在如下方向进行发展：加入更多的语言，Web 化 IDE 能力提升，更多的技能被配置化，将自动测试系统并入。
总体来看，Serverless 技术虽然热度远不及 Kubernetes 等容器技术，甚至也不比微服务名气更高。但这就是 Serverless 的风格，有着高一点的入门门槛，有着更广阔的应用前景，也有着更强大的应用回馈。想要学成绝世剑法，不能只依赖神兵利刃，功力到时，草木竹石皆可为剑，无招胜有招。
