Serverless是目前很火的一个话题，相信大家一定听说过，但是如果去百度、谷歌或者维基百科去查，就会发现它连一个准确的定义都没有。什么是无服务器？为什么Serverless最近这么火？今天就带大家详细了解一下Serverless，看看它是什么？Serverless能解决什么问题？从字面上看，Serverless包括两部分：server和less。这里的Server是指Server端是Serverless解决问题的边界；而less可以理解为较少的关注，这就是Serverless解决问题的目的。因此，结合起来，Serverless意味着“更少关心服务器端”。什么是服务器？我们先来看Server。这里我以Web应用的经典MVC架构为例。MVC架构主要分为前端和后端。前端负责客户端的体验，即View层；后端负责业务的业务逻辑和数据处理，即Control层和Model层。如果你有一定的开发经验，你应该知道你的代码在本地开发调试时的数据流向。通常我们在自己的电脑上开始一个端口号，比如127.0.0.1:3001。当浏览器访问这个地址时，可以调用和调试自己的代码。但是如果我们要把这个web应用部署到互联网上，提供给互联网用户访问，就需要服务器的运维知识。如果要考虑容灾和容错，可以部署多个web应用实例，保证异地多活。为了让多个Web应用实例能够在容灾和容错场景下稳定地切换流量，我们需要使用负载均衡服务和反向代理服务。负载均衡服务，顾名思义，就是负责将流量平均分配给各个应用机器；常见的反向代理是Nginx，它的任务是从请求中解析出域名信息，将请求转发到上游upstream的监听地址。服务器的边界就是上图中整个蓝色的部分，负责应用或者代码的在线运维。Serverless解决问题的边界是服务器的边界，即服务器的运维。服务端运维的发展史，从Serverfull到Serverless，我们可以先看看Serverfull的概念，然后比较Serverfull和Serverless的区别，相信这样可以加深大家的理解。Serverful就是我们负责所有的服务端运维，serverless就是我们负责更少的服务端运维，大部分的运维工作交给自动化工具。这听起来可能很抽象，所以让我举个例子。假设我有一家互联网公司，我的产品是一个“ToDoList”网络应用——也就是对每个用户的待办事项列表进行记录管理。对于这个网站的研发，我们将其简化为两个独立的角色：研发工程师小程和运维工程师小付。做研发的小程是一名精通前后端的全栈工程师，但他只关心应用的业务逻辑。具体来说，程小奔负责整个基于MVC的Web应用的开发、升级和bug修复。负责运维的小服务只关心应用的服务端运维。例如，负责部署在线小程的Web应用，绑定域名，日志监控等。当用户访问量大时，扩大应用；当用户访问量较小时，缩小应用；服务器宕机，重启或者换台服务器等。在史前时代，Serverfull的运维工程师小付一开始就承诺包揽所有的运维事宜，小成不需要关心任何与部署相关的事情操作和维护。所以，程小奔每次发布新的应用，都会给小付打电话，让小付部署上线最新的代码。小服务器需要管理迭代版本的发布，合并分支，启动应用，遇到问题回滚。如果线上出现问题，应该抓取线上日志，发给程小奔解决。小程和小付通过岗位职责的安排，将研发和运维完全分开。优点很明显：分工明确，小程可以专心做好自己的事情；缺点也很明显：小付变成了工具人，陷在大量的运维工作中，处理各种发布相关的琐碎琐事。这个时代，研发和运维是分开的，服务器运维全部交给小付，纯人工处理，也就是Serverfull。到了农耕时代，我们可以停下来思考DevOps。其实发布版本、处理线上故障等工作，应该是小程负责的，不应该是小付帮忙的吧？其实，小付也逐渐发现，很多日常工作都是重复性的工作，尤其是在新版本发布的时候。而不是每次都等着小程打电话，万一在线失败，还得自己抓日志发过去。效率很低，不如干脆自己做一套运维控制台OpsConsole，让小程自己处理部署和日志抓取的工作。说到做到，OpsConsole上线后，小服务器确实轻松了一些，但是架构优化节省资源，资源计划的扩缩容，还是需要对小服务器进行定期的review。除了开发任务，每次发布新版本或者解决线上故障，小程都要跑到OpsConsole平台去处理。这个时代是研发和运维DevOps。小程也参与了小付的工作，小付工具化了服务器端运维的一部分工作，让他可以做更专业的事情。与史前时代相比，农耕时代的小衣服将部分人类劳动工具化，效率更高。这时候已经有Serverless的趋势了。大家想想能不能进一步提高效率，让小程连OpsConsole平台都可以用上？工业时代，serverless小服务器发现资源优化和扩容方案也可以通过性能监控+流量预估来解决，所以小服务器基于小程的开发流程，进一步优化OpsConsole系统，帮助小程搭建代码自动发布流水线：扫码——测试——灰度验证——上线。现在小程甚至不需要登录OpsConsole，只要将最新的代码合并到Git仓库指定的开发分支中，剩下的就由流水线自动处理并发布上线。这个时代R&D不需要运维，NoOps是免运维的。小付的服务器运维工作完全自动化，小成又回到了最初，只需要关心自己的应用业务。不难看出，在服务端运维的发展历程中，对于小程来说，小付的作用越来越弱，需要小付参与的事情越来越少，都被取代了通过自动化工具。说到这里，你肯定会想，既然服务器是免运维的，那小付会不会丢了性命丢了饭碗呢？未来实现免运维NoOps，并不意味着小付会失业，而是小服务需要转型，转型为更底层的服务，构建基础设施，提供更智能、更节省资源的服务，和更周到的服务。小程完全可以不为运维所困扰，自信大胆的依靠Serverless服务，专注做好自己的业务，提升用户体验，思考商业价值。免运维NoOps并不是说服务端运维不存在，而是通过覆盖研发部署所有需求的全知无所不能的服务，让研发小程同学越来越不了解。另外，NoOps是一种理想状态，因为我们只能无限接近NoOps。另外，你需要知道的是，大部分互联网公司，包括一线互联网公司，还处在DevOps时代。只不过Serverless的概念已经被提出，NoOps的时代即将到来。按照上面的分解，Serverless可以称为服务端免运维，这就是Serverless需要解决的问题。什么是无服务器？总结一下，Serverless有两种含义：第一种：狭义的serverless（最常见）=Serverless计算架构=FaaS架构=Trigger（事件驱动）+FaaS（功能即服务）+BaaS（postClientasaservice，持久化或第三方服务）=FaaS+BaaS第二种：广义Serverless=服务器端免运维=具有Serverless特性的云服务我用图片来说明这两个概念。虽然大家可以看到广义的serverless包含的东西更多，适用范围也更广，但是我们在工作中经常说的serverless一般都是指狭义的serverless。这是有历史原因的。2014年11月，亚马逊推出了第一个真正意义上的serverlessFaaS服务：Lambda。Serverless的概念才进入大多数人的视野，因此Serverless一度等同于FaaS。图中有几个不熟悉的名词，先给大家解释一下。FaaS（FunctionasaService）是功能即服务，BaaS（BackendasaService）是后端即服务。XaaS（XasaService）是X即服务。这是云服务提供商喜欢使用的一种命名方式。比如大家熟悉的SaaS、PaaS、IaaS都是这样。先说FaaS，functionasaservice。它还有一个名字叫做ServerlessComputing，它允许我们随时随地创建、使用和销毁一个函数。大家可以想一下一个普通函数的使用过程：需要先从代码中加载到内存中，即实例化，然后在被其他函数调用时执行。在FaaS中也是如此。函数需要被实例化，然后被触发器或其他函数调用。两者最大的不同在于Runtime，也就是函数的上下文，函数执行的上下文。FaaS的运行时是预先设置好的。运行时加载的功能和资源都是云服务商提供的，我们可以使用但不能控制。你可以理解为FaaS的运行时是临时的。调用函数后，临时运行时与函数一起销毁。FaaS函数调用后，云服务商会销毁实例，回收资源，所以FaaS推荐无状态函数。如果你是前端工程师，可能很容易理解函数不能改变Immutable。简单解释一下，就是说只要函数的参数是固定的，那么返回的结果也一定是固定的。以上面的MVC架构web应用为例，View层是客户端展示的内容，通常不需要函数计算能力；Control层是一个典型的函数使用场景。在MVC架构中，一个HTTP数据请求对应一个Control功能，我们完全可以用FaaS功能来替代Control功能。当HTTP数据请求量较大时，FaaS功能会自动扩容并同时运行多个实例；当HTTP数据请求量较小时，会自动收缩；当没有HTTP数据请求时，也会收缩为0实例，节省开支。这一刻，你可能有点迷茫。Runtime不可控，FaaS函数无状态，函数实例不断膨胀和收缩。如果需要持久化一些数据怎么办？MVC中的Model层如何解决？在这一点上我将要介绍另一个客人——BaaS。BaaS其实是一个集合，指的是具有高可用性和弹性、免运维的后端服务。简单来说，就是专门支持FaaS的服务。FaaS就像是高铁的车头。如果我们的后端服务还是老旧的绿色火车车厢，肯定会分崩离析，而BaaS就是专门为FaaS准备的高铁车厢。MVC架构中的Model层需要我们使用BaaS来解决。对于Model层，我们以MySQL为例。后端服务最好把FaaS操作的数据库的命令封装成一个HTTPOpenAPI，提供给FaaS调用，控制这个API的请求频率和限流降级。后端服务本身可以通过连接池、MySQL集群等方式进行优化，各大云服务商自己也在改造自己的后端服务，BaaS的集合也在与日俱增。基于Serverless架构，我们可以将传统的MVC架构完全转化为BaaS+View+FaaS的组合，重构或者实现。这样看，也就不难理解狭义的Serverless的含义了。第一种：狭义的Serverless（最常见）=Serverless计算架构=FaaS架构=Trigger（事件驱动）+FaaS（功能即服务）+BaaS（后端即服务，持久化或第三方服务)=FaaS+BaaSServerless毋庸置疑，正是因为FaaS架构的缘故，它才火起来，进入大家的认知。所以我们最常见的Serverless指的就是ServerlessComputing架构，它是由Trigger、FaaS、BaaS架构组成的应用。这也是我给的狭义的serverless的定义。那么广义上的Serverless是什么？将狭义的Serverless服务提升到广义，具有以下特点。大家可以回忆一下小型服务器的工作。要实现NoOps，应该满足什么条件？小服务器的工作职责：不需要用户关心服务器端的事情（容错、容灾、安全验证、自动伸缩、日志调试等）。按用量付费（通话次数、时长等），低成本和高性能并行，在大多数场景下都省钱。快速迭代和试错能力（多版本控制、灰度、CI&CD等）。从广义上讲，Serverless其实就是服务器免运维，也是未来的大趋势。综上所述，当我们说到Serverless的时候，基本上都是指狭义的Serverless，但是当我们说到某个服务的Serverless时，往往是指广义的Serverless。总结一下serverless可以解决哪些问题？Serverless可以让应用在服务端免运维。为什么Serverless很难定义？Serverless将服务端运维高度抽象为一个解决方案，包含的信息太多。狭义的Serverless是指使用FaaS+BaaS的Serverless架构开发的应用；Serverless广义上是指具有Serverless特性的云服务。现在的云服务商都在积极将他们提供的各种云服务做成Serverless。
