行业动态

开幕地址：

2018年就职于某国企云估算公司。虽然项目在疫情期间被公司隐瞒，但凭借3年的云估算经验，我也学到了很多关于云估算的知识。

云计算的愿景——随着互联网的发展，未来云计算必将成为整个社会和商业的基础设施。那时，使用云计算应该像我们今天使用水、电和煤一样简单，不知道它们来自哪里。来，不需要关注运维等相关知识，用户只需要关心业务逻辑即可。

这个愿景提到运维，接下来我会讲一下服务器端运维的发展历程。

从满到少

full表示运维都是我们自己负责，less表示服务器端运维少由我负责，大部分操作交给手动工具，所以比较具体，我会以一个实际的例子来说明运维从full到less的过程。

如果（别问我是谁~）有一家互联网公司，做一个在线笔记项目是很有必要的。为了方便，我将两个核心职位简化为两个角色：研发工程师肖拓，运维工程师肖磊。

两个角色的简单介绍

开发工程师肖拓是技术大鳄，精通前后端的全栈工程师。他只需要关心应用程序的业务逻辑。在整个MVC架构中，从服务端的View到业务逻辑层，再到数据存储的Model层，包括代码版本管理、bug修复，都由小程来管理。

运维工程师肖磊头脑很硬。他不仅要负责甩锅，还要负责重启。他只关心应用服务器的运维。它还负责在服务器宕机时重新启动服务器。

史前时代

项目跌跌撞撞，终于启动了。小雷承诺运维包罗万象。小拓不需要关心任何部署。小拓每次上线，都要通知小雷最新的代码。至于小头，做个版本备份，有问题回滚，也抓个在线日志给小头解决。

这看起来很棒。业务的开发和运维是完全分离的。一切似乎都是那么美好，但缺点是小雷变成了一个工具人，被各种复杂的事物所困。自拔不仅没有提升个人能力，也没有时间让小雷深入研究提高运维效率。

农业时代

为了逃避这种重复性的工作，小雷深思熟虑，每次出现bug，都要给小拓提供日志。我只是一个工具人，为什么不做一个工具，让他手动刮日志呢？

于是小雷做了一个（操作台，云厂商有对应的产品如Log Easy、Log 等），让小拓自己读取日志。小雷的功能上线后，小拓在处理产生bug的时候，就不用让小雷帮忙拉日志了，小雷的工作就轻松多了。

看来小拓的工作量减少了。虽然想想那些原本是肖拓的工作，但肖磊以前只是个工具人。

尝过甜头的小雷，再次陷入了沉思。这提高了效率。是否可以部署、扩容、减容、关机后重启？手动？

工业时代

此时，我们已经来到了当下的主流时代。现在很多大厂都在这个时代。右图是我之前监督过的天猫后端工程系统DEF。经过不断优化，小雷在这个时代，项目应该优化成什么？

上线前除了对代码进行检查和预测试外，还在发布时做了灰度发布和手动回滚。一切都是手动的。

可能有人会问，小雷的一连串革命似乎让他失业了？

未来并不遥远

目前的发展趋势，虽然他已经做了一些免费的运维工作，小雷并没有丢掉性命，但他想往下层的方向转变，如何越来越节省资源？开发朋友只专注于业务，不被运维所迷惑服务器运维技术，这将是小雷未来的​​方向。

你如何定义你说了多少？在新的less框架模型下，之前的工作职能必须做哪些改变？

先看一张图：

因为认知错误，很难看清很多人的大致情况。有这么一句话，当你认为对方的行为很疯狂的时候，很可能大家掌握的信息信息很差，我也是。在检查之前，我仍然无法理解No 是如何成功运行该项目的，真是太神奇了。根本原因是我们用侠义的认知来试图解释概括。针对这个问题，我也给出两个推论：侠义和泛化：

第一种：窄（最常见）=架构=FaaS架构=（风暴驱动）+FaaS（功能即服务）+BaaS（前端即服务，持久化或第三方服务）=FaaS+ BaaS之二：通用化=服务器端免费运维=有特色的云服务

把这两个定义和上图结合起来，很容易切入正题，大家可以仔细看看。

基于新模型，每个位置会发生哪些变化？

后端工程师：不仅是现有页面开发，也是FaaS开发

前端工程师：放弃与后端工程师联调开发到BaaS，转入下层服务，专门支持FaaS进行开发

运维工程师：容器和基础架构

有了这样一个名词，我突然觉得有些不知所措了，因为我只是一个后端工程师，所以只能简单谈谈我对FaaS的理解。

FaaS

全名是asa。也就是说，这是云厂商常用的命名方式。 被称为 XaaS。

该功能由云厂商提供的触发器触发，它会根据语言启动相应的环境，并提供一定的标准上下文，每个触发器，提供的上下文都不一样，我们需要做什么不同的触发器下的业务逻辑也不同。常见的触发器包括http触发器、api调用触发器、定时器触发器等。FaaS的生命周期如下。

1、用户通过互联网访问地址，触发触发器

2、启动云厂商预设的环境，即函数执行容器

3、初始化运行环境

4、运行函数

5、操作结束后等待一段时间（3-5分钟），如果期间有电话，返回第4步，但没有进入第6步

6、破坏环境和函数。

从这一步可以看出，无论什么函数和环境最终都会被破坏，所以FaaS是一个无状态函数，对于后端朋友来说很容易理解，因为我们写的大部分函数都是它是无状态的，前端的朋友会害怕，没有感觉缺的数据库。

如果你想存储数据怎么办？这是 BaaS 层应该处理的问题，超出了我们讨论的范围。

为什么 Node 在 FaaS 中如此受欢迎？

本题需要讲JIT，JIT即时编译（英文：Just-in-time），详情可以看

这有点困难。一般的意思是JS同时编译和执行。与java不同的是，它会在编译后执行。这个特性让代码在冷启动阶段跑得更快，但我的理解也有限。这个JIT问题还是比较深的，知乎有对应的题目，有兴趣的朋友可以去看看。

由于对速度的要求，node 脱颖而出，成为 FaaS 的流行语言。

总结

说到这里，你应该有点了解了。作为后端工程师服务器运维技术，我们现在应该怎么做？学习 node 并在 FaaS 环境中开发！ ！ ！

核心理论：增值编程

目前的状态与三年前一样，当时后端工程被提上日程。去年，在紧迫的招聘市场中，懂工程和工程框架的后端已经脱颖而出，摆脱了内卷化，拿到了更高的薪水。但是，按照目前的发展速度，工程相关的内容很快就会被困在内卷中。下一个目标是什么？就是节点的学习。其实单纯使用是不够的，还要学会调整最好的方法，看看一些优秀框架的源码，学习FaaS的原理等等。

最后，持续学习是我们降低自身价值的一种手段，我们必须顺势而为才能成功。技术红利的机会不多。如果不抓住之前的工程红利，那么接下来的 FaaS 技术红利就用不上。在错过之前，花点时间增加价值。