世界是 Container 的,也是 Microservice 的,但最终还是 Serverless 的

Posted by Mike on 2022-01-03

世界上有两种基础设施,一种是拿来主义,另一种是自主可控。

原谅我也蹭个已经被浇灭的、没怎么火起来的热点。不过我们喜欢的是拿来主义,够用就行,不想也不需要过多的控制,也不想惹过多的麻烦,也就是 fully managed。

之所以想到写这篇文章,源于前几天看到的这篇来自微软 Azure 的博客内容: The Future of Kubernetes Is Serverless ,然后又顺手温习了一遍 AWS CTO 所撰写的 Changing the calculus of containers in the cloud 这篇文章。这两篇文章你觉得有可能有广告的嫌疑,都是在推销自家的共有云服务,但是仔细品味每一句话,我却觉得几乎没有几句废话,都很说到点子上,你可以点击进去看下原文。

有个前提需要说明的是,这里的 Serverless 指的是 Serverless infrastructure,而不是我们常听到的 AWS Lambda,Microsoft Azure Functions 或 Google Cloud Functions 等函数(功能)即服务(FaaS)技术,为了便于区分,我们将这些 FaaS 称为无服务器计算,和我们本文要介绍的无服务器基础设施还是不一样的。

IaaS:变革的开始

说到基础设施,首先来介绍下最先出现的 IaaS,即基础设施即服务。IaaS 免除了大部分硬件的 provision 工作,没人再关心机架、电源和服务器问题,使得运维工作更快捷,更轻松,感觉解放了很多人,让大家走上了富裕之路。

当然这一代的云计算服务,可不只是可以几分钟启动一台虚拟机那么简单。

除了 VM 之外, IaaS 厂商还提供了很多其他基础设施和中间件服务,这些组件被称为 building block ,比如网络和防火墙、数据库、缓存等老三样,最近还出现了非常多非常多的业务场景服务,大数据、机器学习和算法,以及IoT等,看起来就像个百货商店,使用云计算就像购物,架构设计就是购物清单,架构里的组件都可以在商店里买到。

基础设施则使用 IaaS 服务商所提供的各种服务,编写应用程序可以更专注于业务。这能带来很多好处:

  • 将精力集中投入到核心业务
  • 加快上线速度
  • 提高可用性
  • 快速扩缩容
  • 不必关心中间件的底层基础设施
  • 免去繁杂的安装、配置、备份和安全管理等运维工作

在 AWS 成为业界标准之后,各大软件公司,不管是新兴的还是老牌的,都开始着手打造自己的云,国外有微软、谷歌、IBM等,国内的 BAT 也都有自己的云,以及京东和美团这样的电商类公司也有自己的云产品,独立的厂商类似 UCloud 和青云等公司也发展的不错,甚至有开饭馆的也要出来凑热闹。而开源软件 OpenStack 和基于 OS 的创业公司和产品也层出不穷。

全民皆云。

容器:云计算的深入人心

之后在 2013 年,容器技术开始面向大众普及了。在 LXC 之前,容器对普通开发人员甚至 IT 业者来说几乎不是同一个维度的术语,那是些专业人员才能掌控的晦涩的术语和繁杂的命令集,大部分人都没有用过容器技术;但是随着 Docker 的出现,容器技术的门槛降低,也在软件行业变得普及。随着几年的发展,基本可以说容器技术已经非常成熟,已成为了开发的标配。

随着容器技术的成熟和普及,应用程序架构也出现了新的变化,可以说软件和基础设施的进化相辅相成。人们越来越多的认识到对技术栈的分层和解耦更加重要,不同层之间的技术和责任、所有权等界限清晰明了,这也和软件设计中的模块松耦合原则很相像。

在有了责权明晰的分层结构之后,每个人可以更容易集中在自己所关注的重点上。开发人员更关注应用程序本身了,在 Docker 火了的同时,也出现了 app-centric 的概念。甚至 CoreOS 还将自己对抗 OCI/runc 的标准称为 appc 。当然现在的 Docker 也不是原来的 Docker ,也是一个组件化的东西,很多组件,尤其是 runtime ,都可以替换为其他运行时。

和以应用程序为重心相对应的是传统的以基础设施为中心,即先有基础设施,围绕基础设施做架构设计和开发、部署,受基础设施的限制较多。而随着 IaaS 等服务的兴起,基础设施越来越简单,越来越多容易入手,而且还提供了编程化的接口,开发人员也可以非常方便的对基础设施进行管理,可以说云计算的出现也使得开发人员抢了一部分运维人员的饭碗(遗憾的是这种趋势太 high 了停不下来。。。)。

当然,现在以应用为中心这一概念也已经深入人心。特别是进化到极致的 FaaS ,自己只需要写几行代码,其他平台全给搞定了。

编排:兵家必争之地

容器解决了代码的可移植性的问题,也使得在云计算中出现新的基础设施应用模式成为可能。使用一个一致的、不可变的部署制品,比如镜像,可以让我们从复杂的服务器部署中解脱出来,也可以非常方便的部署到不同的运行环境中(可移植性)。

但是容器的出现也增加了新的工作内容,要想使用容器运行我们的代码,就需要一套容器管理系统,在我们编写完代码,打包到容器之后,需要选择合适的运行环境,设置好正确的扩容配置,相关的网络连接,安全策略和访问控制,以及监控、日志和分布式追踪系统。

之所以出现编排系统,就是因为一台机器已经不够用了,我们要准备很多机器,在上面跑容器,而且我不关心容器跑在哪台机器上,这个交给调度系统就行了。可以说,从一定层面上,编排系统逐渐淡化了主机这一概念,我们面对的是一个资源池,是一组机器,有多少个 CPU 和多少的内存等计算资源可用。

rkt vs Docker 的战争从开始其实就可以预料到结局,但在编排系统/集群管理上,这场“战争”则有着更多的不确定性。

Mesos(DC/OS)出来的最早,还有 Twitter 等公司做案例,也是早期容器调度系统的标配;Swarm 借助其根正苗红以及简单性、和 Docker 的亲和性,也要争一分地盘;不过现在看来赢家应该是 K8s,K8s 有 Google 做靠山,有 Google 多年调度的经验,加上 RedHat/CoreOS 这些反 Docker 公司的站队,社区又做得红红火火,总之是赢了。

据说今年在哥本哈根举办的 Kubecon 有 4300 人参加。不过当初 Dockercon 也是这声势,而现在影响力已经没那么大了,有种昨日黄花、人老色衰的感觉,不知道几年之后的 Kubernetes 将来会如何,是否会出现新的产品或服务来撼动 Kubernetes 现在的地位?虽然不一定,但是我们期待啊。

Serverless infrastructure:进化的结果

但是呢,淡化主机的存在性也只是淡化而已,并没有完全消除主机的概念,只是我们直接面向主机的机会降低了,不再直接面向主机进行部署,也不会为某些部门分配独占的主机等。主机出了问题还得重启,资源不够了还得添加新的主机,管理工作并没有完全消失。

但是管理一套集群带来了很大的复杂性,这也和使用云计算的初衷相反,更称不上云原生。

从用户的角度再次审视一下,可以发现一个长时间被我们忽略的问题:为什么只是想运行容器,非得先买一台 VM 装好 Docker,或者自己搭建一套 Kubernetes 集群,或者使用类似 EKS 这样的服务,乐此不疲的进行各种配置和调试,不仅花费固定的资产费,还增加了很多并没有任何价值的运维管理工作。

既然我们嫌弃手动在多台主机中部署容器过于麻烦,将其交给集群管理和调度系统去做,那么维护调度系统同样繁杂的工作,是不是也可以交给别人来做,外包出去呢?

按照精益思想,这些和核心业务目标无关,不能带来任何用户价值的过程,都属于浪费行为,都需要提出。

这时候,出现了 Serverless infrastructure 服务,最早的比如国内的 hyper.sh (2016.8 GA),以及去年发布的 AWS 的 Fargate(2017.12),微软的 ACI(Azure Container Instance,2017.7) 等。

hyper.sh 为例,使用起来和 Docker 非常类似,可以将本地的 Docker 体验原封不动的搬到云端:

1
2
3
4
5
6
7
8
9
$ brew install hyper  
$ hyper pull mysql
$ hyper run mysql
MySQL is running...
$ hyper run --link mysql wordpress
WordPress is running...
$ hyper fip attach 22.33.44.55 wordpress
22.33.44.55
$ open 22.33.44.55

大部分命令从 docker 换成 hyper 就可以了,体验如同使用 Docker 一模一样,第一次看到这样的应用给人的新奇感,并不亚于当初的 Docker 。

使用 Serverless infrastructure,我们可以再不必为如下事情烦恼:

  • 不必再去费心选择 VM 实例的类型,需要多少 CPU 和内存
  • 不必再担心使用什么版本的 Docker 和集群管理软件
  • 不必担心 VM 内中间件的安全漏洞
  • 不必担心集群资源利用率太低
  • 从为资源池付费变为为运行中的容器付费
  • 完全不可变基础设施
  • 不用因为 ps 时看到各种无聊的 agent 而心理膈应

我们需要做的就是安心写自己的业务应用,构建自己的镜像,选择合适的容器大小,付钱给 cloud 厂商,让他们把系统做好,股票涨高高。

Fargate(此处也可以换做 ACI ):大厂表态

尽管 AWS 不像 GCP 那样“热衷”于容器,但是 AWS 也还是早就提供了 ECS(Elastic Container Service)服务。

去年发布的 AWS Fargate 则是个无服务器的容器服务,Fargate 是为了实现 AWS 的容器服务,比如 ECS(Elastic Container Service) 和 EKS(Elastic Kubernetes Service) 等,将容器运行所需要的基础设施进行抽象化的技术,并且现在 ECS 已经可以直接使用 Fargate。

和提供虚拟机的 EC2 不同,Fargate 提供的是容器运行实例,用户以容器作为基本的运算单位,而不必担心底层主机实例的管理,用户只需建立容器镜像,指定所需要的 CPU 和内存大小,设置相应的网络和IAM(身分管理)策略即可。

对于前面我们的疑问,AWS 的答案是基础设施的坑我们来填,你们只需要专心写好自己的应用程序就行了,你不必担心启动多少资源,我们来帮你进行容量管理,你只需要为你的使用付费就行了。

可以说 Fargate 和 Lambda 等产品都诞生于此哲学之下。

终于可以专心编写自己最擅长的 CRUD 了,happy,happy。

Serverless infrastructure vs Serverless compute

再多说几句,主要是为了帮助大家辨别两种不同的无服务器架构:无服务器计算和无服务器基础设施。

说实话一下子从 EC2 迁移到 Lambda ,这步子确实有点大。

Lambda 等 FaaS 产品虽然更加简单,但是存在有如下很多缺点:

  • 使用场景:Lambda 更适合用户操作或事件驱动,不适合做守护服务、批处理等业务
  • 灵活性:固定的内核、AMI等,无法定制
  • 资源限制:文件系统、内存、进程线程数、请求 body 大小以及执行时间等很多限制
  • 编程语言限制
  • 很难做服务治理
  • 不方便调试和测试

Lambda 和容器相比最大的优势就是运维工作更少,基本没有,而且计费更精确,不需要为浪费的计算资源买单,而且 Lambda 响应更快,扩容效率会高一些。

可以认为 Fargate 等容器实例,就是结合了 EC2 实例和 Lambda 优点的产品,既像 Lambda 一样轻量,更关注核心的应用程序,还能像 EC2 一样带来很大的灵活性和可控性。

云原生会给用户更多的控制,但是需要用户更少的投入和负担。

Serverless infrastructure 可以让容器更加 cloud native。

fully managed:大势所趋

所谓的 fully managed,可以理解为用户花费很少的成本,就可以获得想要的产品、服务并可以进行相应的控制。

这两天,阿里云发布了 Serverless Kubernetes ,Serverless Kubernetes 与原生的 Kubernetes 完全兼容,可以采用标准的 API、CLI 来部署和管理应用,还可以继续使用各种传统资产,并且还能获得企业级的高可用和安全性保障。难道以后我们连 Kubernetes 也不用自己装了,大部分人只需要掌握 kubectl 命令就好了。

IaaS 的出现,让我们丢弃了各种 provision 工具,同时,各种 configuration management 工具如雨后春笋般的出现和普及;容器的出现,又让我们扔掉了刚买还没看几页的各种 Chef/Puppet 入门/圣经,匆忙学起 Kubernetes;有了 Serverless infrastructure,也差不多可以和各种编排工具说拜拜了。

不管你们是在单体转微服务,还是在传统上云、转容器,估计大家都会喜欢上 fully managed 的服务,人人都做 Ops,很多运维工作都可以共同分担。当然,也会有一部分运维工程师掩面而逃。

本文转载自:「 人间指南 」,原文:https://tinyurl.com/exvzu9tb ,版权归原作者所有。欢迎投稿,投稿邮箱: editor@hi-linux.com