前言
我曾在 《Serverless的喧哗与骚动》一文中对Serverless今天在行业中所处的状态做了一个比喻,这个比喻是这么说的:
Serverless就像青少年性行为:人人都在谈论它,没有人真正知道如何去做,每个人都认为别人都这么做,所以每个人都声称他们正在做。
虽然距离写那篇文章已经过去了半年的时间,但是这种状态在我看来其实没有发生太大的变化,有很多的一线研发或者管理者对Serverless技术的理解是非常片面的,有些甚至是错误的。如果缺乏对应用架构演进的理解,缺乏对于云基础设施能力的理解,缺乏对风险的判断,盲目的上新技术可能不仅无法兑现业务价值,浪费精力,然而会引入无谓的技术风险。
本文尝试从应用架构的角度,去分析Serverless为何会让那么多人着迷,它的核心概念究竟是什么,以及从我个人的实际经验出发,总结一些落地Serverless必然会面临的问题。
应用架构的演进
为了能更好的理解Serverless,让我们先来回顾一下应用架构的演进方式。十多年前主流的应用架构都是单体应用,部署形式就是一台服务器加一个数据库,在这种架构下,运维人员会小心翼翼地维护这台服务器,以保证服务的可用性。随着业务的增长,这种最简单的架构很快会面临两个问题。首先,这里只有一台服务器,如果这台服务器出现故障,例如硬件损坏,那么整个服务就会不可用;其次,业务量变大之后,一台服务器的资源很快会无法承载所有流量。解决这两个问题的最直接方法就是在流量入口加一个负载均衡器,同时单体应用同时部署到多台服务器上,这样服务器的单点问题就解决了,同时这个单体应用也具备了水平伸缩的能力。
业务进一步增长,更多的研发人员加入到团队,一起在单体应用上开发特性。这个时候由于单体应用内的代码没有明确的物理边界,大家很快就会遇到各种冲突,需要人工的协调,以及大量的冲突合并操作,研发效率直线下降。这个时候大家就开始把单体应用拆分成一个个可以独立开发,独立测试,独立部署的微服务应用,服务和服务之间通过API通讯,如HTTP、GRPC或者达博。基于领域驱动设计中限界上下文拆分的微服务架构能够大幅提升中大型团队的研发效率,如果想了解关于限界上下文的更多内容,推荐大家阅读领域驱动设计相关的书籍。
应用从单体架构演进到微服务架构,从物理的角度看,分布式就成了默认选项了,这个时候应用架构师就不得不面对分布式带来的新挑战。在这个过程中大家都会开始使用一些分布式服务和框架,例如缓存服务复述,配置服务ACM,状态协调服务管理员,消息服务卡夫卡,还有通讯框架如GRPC或者达博,以及分布式追踪系统等等,这里就不逐一罗列了。除了分布式环境带来的挑战之外,微服务架构给运维带来的新的挑战。研发人员原来只需要运维一个应用,现在可能就需要十个甚至更多的应用的,这意味着安全补丁升级,容量评估,故障诊断等事务工作量成倍的增长,这个时候,应用分发的标准,生命周期的标准,观测的标准,自动化弹性等能力的重要性就凸显出来。
现在让我们谈下“云原生”这个词,简单的理解,一个架构是否是云原生,就是看这个架构是否是长在云上的。这个“长”在云上的理解不是简单的说用云的IaaS层服务,比如简单的ECS, OSS这些基本的计算存储;而是应该理解成有没有使用云上的分布式服务,比如复述,卡夫卡等等,这些服务才是直接会直接影响到业务架构的。前面我们说到,微服务架构下,分布式服务是必要的,原来大家都是自己研发这样的服务,或者基于开源版本自己运维这样的服务,而到了云原生的时代,业务就直接使用云服务了。
另外两个不得不提的技术就是码头工人和Kubenetes,其中前者标准化了应用分发的标准,不论是弹簧引导写的应用,还是NodeJS写的应用,都以镜像的方式分发;而后者在前者的技术上又定义了应用生命周期的标准,一个应用从启动到上线,到健康检查,下线,有了统一的标准。有了应用分发的标准和生命周期的标准,云就能提供标准化的应用托管服务。包括应用的版本管理,发布,上线后的观测,自愈等等,例如对于无状态的应用来说,一个底层物理节点的故障根本就不会影响到研发,因为应用托管服务基于标准化应用生命周期可以自动完成腾挪工作,在故障物理节点上将应用的容器下的线,在新的物理节点上启动同等数量的应用容器。我们看的到,云原生进一步的释放了价值红利。
喧哗的背后:Serverless的概念及挑战
