视频投票网站怎么做的,wordpress php版本太低,wix做网站步骤,网站建立有哪些功能戳蓝字“CSDN云计算”关注我们哦#xff01;导读#xff1a;从 2016 年 AWS 发布 Lambda 以来#xff0c;全世界的开发者和云厂商对 Serverless 的热情在不断高涨。假设不想在开发应用程序并将其部署在服务器上的过程细节上花费精力#xff0c;是否有一种简单的架构模型能够… 戳蓝字“CSDN云计算”关注我们哦导读从 2016 年 AWS 发布 Lambda 以来全世界的开发者和云厂商对 Serverless 的热情在不断高涨。假设不想在开发应用程序并将其部署在服务器上的过程细节上花费精力是否有一种简单的架构模型能够满足我们这种想法呢答案已经存在这就是今天软件架构世界中新鲜但是很热门的一个话题——Serverless无服务器架构。本文作者将利用自身多年的研发经验带领我们深入了解 Serverless 行业的发展《喧哗与骚动》是我喜欢的作家威廉·福克纳的一部小说小说用多个家庭成员的意识流从不同的视角描绘了一家三代的悲剧。这部小说有意思的地方在于对于同样一件事情从不同人跳跃的意识中能看到迥然相异的景象。今天大家理解Serverless也有点这个意思因此我以此为题展开分析。文章只代表作者本人观点。Serverless is like teenage sex不知道大家有没有听过这样的话Big data is like teenage sex: Everyone talks about it, nobody really knows how to do it, everyone thinks everyone else is doing it, so everyone claims they are doing it.我们把Big data换一下AI is like teenage sex: Everyone talks about it, nobody really knows how to do it, everyone thinks everyone else is doing it, so everyone claims they are doing it.我们把AI换成ServerlessServerless is like teenage sex: Everyone talks about it, nobody really knows how to do it, everyone thinks everyone else is doing it, so everyone claims they are doing it.从中可以总结出以下几点所有人都在说 Serverless几乎没人知道怎么落地 Serverless但是大家都觉得其他人在大力做 Serverless所以大家都宣称自己在做 Serverless。Serverless 和很多词如微服务一样是没有精确定义的也没有事实的标准。什么是事实标准Kubernetes 是事实标准对 Java 程序员来说 Spring Boot / Spring Cloud 是事实标准。事实标准就是一种思想/方法论得到了广泛落地占领了市场。落地通常意味着两个点它是开放开源的。因此不会有 vendor lock-in所有人可以放心用有大量的成功案例。很多人将其用到关键的商业系统中因此得到了广泛验证。今天 Serverless/FaaS 领域有这个东西吗还没有。Serverless 的愿景下面是来自 Google Trends 的一个图其中红色是 Microservices蓝色是 Serverless。从 2016 年 AWS 发布 Lambda 以来全世界的开发者和云厂商对 Serverless 的热情在不断高涨这说明大家对 Serverless 所描绘的愿景都非常 buy in。这个愿景是什么呢图片来源网络愿景是无服务器但工程师们都知道服务器本质上是存在的最多是加一层抽象让我们看不到服务器但它依旧很好的发挥作用。我个人觉得有关 Serverless 愿景描绘最清楚的是一个比喻这个比喻来自 UC Berkeley 在今年2月发表的那篇论文[1]图片来源网络简单来说就是我们今天对云资源的操作方式就类似于几十年前早期程序员写汇编的方式。如果你没写过/学过汇编语言或者已经忘了汇编语言我特地找了本书拍了一段内容下来图片来源网络是不是对图中的这些寄存器、栈、程序计数器、以及相关的汇编指令感到很陌生了如果让你用这样的语言写业务逻辑那效率必然会变得非常低。幸好我们有 JavaGoJavaScript 这样的高级语言而这些高级语言还配套了相关的编译器/虚拟机编译器/虚拟机能够高效地把面向业务的高级语言翻译成面向机器的汇编/机器码。今天虽然基本的计算机体系结构没有发生本质的变化但我们的程序所运行的环境相比较20年前已经发生了本质的变化。20 年前的程序大都跑在单机上今天我们的程序都要为了跑在云上而设计了。为了让程序跑在云上我们就需要配套的工作包括云资源容器、缓存、队列的申请和回收、包括弹性伸缩的控制等等。这些事情和业务逻辑没有任何关系但研发/运维同学却为此花费了大量的时间。我想做一个不太成熟的类比单机时代操作系统管理了硬件资源贴着资源层高级语言让程序员描述业务贴着业务层编译器/VM 把高级语言翻译成机器码交给操作系统今天的云时代资源的单位不再是 CPU、内存、硬盘了而是容器、分布式队列、分布式缓存、分布式文件系统。云上的 OS 这个角色基本上可以说是被 Kubernetes 生态给占了那么云上的编译器/VM 呢开发语言和框架呢好像还没有。图片来源网络今天我们把应用程序往云上搬的时候a.k.a Cloud Native)往往都会做两件事情第一是把巨型应用拆小微服务化第二就是摇身一变成为 yaml 工程师写很多 yaml 文件来管理云上的资源。本质上大家都在把面向单机体系架构编写的应用程序硬搬到云体系架构上。我认为这里存在两个巨大的 gap这两个 gap 在图中用灰色的框表示了1. 编程语言和框架目前主流的编程语言基本都是假设单机体系架构运行的面对分布式问题的时候再叠一层框架上去。其对应的资源也依旧停留在单机体系结构的那些资源上当然这里是有例外的比如 erlang/OTP 天生就是为分布式设计的。云时代首先基本的资源单位发生了变化从原来的 cpu、内存变成了容器、函数、分布式队列等等其次云天生分布式因此单机时代大行其道的同步模型就不再适合。2. 编译器程序员不应该花大量时间去写 yaml 文件这些面向资源的 yaml 文件应该是由机器生成的我称之为云编译器高级编程语言用来表达业务的领域模型和逻辑云编译器负责将语言编译成资源描述。我个人很看好 Erlang 的 Actor 模型这个模型在其他语言上也有实现例如语法参考 Ruby 并运行在 Erlang OTP 上的 ElixirJVM 上的 Akka以及 .NET 上的 Orleans。不同于其他语言的设计Actor 模型从一开始就是基于分布式的前提做的设计因此这种模型如果把其对应的资源管理换成纯粹的云资源管理我觉得是有极大可行性的。如果用一句话来总结我觉得 Serverless 的愿景应该是Write locally, compile to the cloud.大家在忙什么为了能够稍微清晰一点地去看这一大堆的产品和技术我简单的把 Serverless 领域做的事情分了三个层自下而上分别是资源层、DevOps 层和框架及运行时层。图片来源网络资源层关注的是资源如容器的生命周期管理以及安全隔离。这里是 Kubernetes 的天下FirecrackergVisor 等产品在做轻量级安全沙箱。这一层关注的是如何能够更快地生产资源以及保证好安全性。DevOps 层关注的是变更管理、流量调配以及弹性伸缩还包括基于事件模型和云生态打通。这一层的核心目标是如何把运维这件事情给做没了NoOps。虽然所有云厂商都有自己的产品各种 FaaS但是我个人比较看好 Knative 这个开源产品原因有二第一是其模型非常完备第二是其生态发展非常迅速和健康。很有可能未来所有云厂商都要去兼容 Knative 的标准就像今天所有云厂商都在兼容 Kubernetes 一样。以下是 Knative 近一年的贡献者及贡献数量的增长情况数据来自演讲「Knative a Year Later: Serverless, Kubernetes and You」。[2]图片来源网络框架和运行时层呢由于个人经验所限我看的仅仅是 Java 领域其实核心的还是在解决 Java 应用程序启动慢的问题GraalVM。当然框架如何避免 vendor lock-in 也很重要谁都怕被一家云厂商绑定怕换个云厂商要改代码这方面主要是 Spring Cloud Function 在做。刚需在哪里产品想要成功需要有核心竞争力这个核心竞争力往往就是你解决了一个用户很头疼、但其他产品没有解决的问题。我姑且把这样的问题称为用户的刚需。那么 Serverless 能解决哪些用户的什么刚需呢我先对用户做一些简单的分析图片来源网络很多技术产品基本都是经历了如下四个阶段初创期一个小团队围绕新的业务做试错从无到有技术上什么能快速上线用什么这个时候团队规模很小可能两三个人所有代码放在一个应用内不需要分布式不需要隔离。成熟期业务成功了用户在不断增多业务也变得越来越复杂这个时候团队的规模增长到数十到上百人团队还处在一个部门相互之间有足够的信任沟通带宽也有足够的保证。一个应用的模式已经不能满足协作的需要架构师开始做应用拆分系统成了分布式的按照业务的划分做了进程级别的隔离。平台期业务太成功了就希望把已经沉淀的能力赋能给其他类似的业务相比较于成熟期这时候有了一些新的变化。首先是参与开发的人数增长得更多了往往是数百上千其次大多数参与开发的成员已经不再是核心产品团队的成员他们往往在不同部门了相互之间的信任已经大大减弱沟通带宽也开始显著变窄。由于核心团队对于其他部门的开发缺乏组织管控能力因此技术上的隔离要求被提上优先级以避免平台上的开发者不小心拖垮平台本身。伴随着隔离成本的问题也被提上日常当平台上数百个插件和平台本身跑在同一个进程内的时候资源天然是被复用的只要模糊地计算下整体即可当数百个插件被隔离到独立的容器中运行的时候他们的资源占用就需要额外的调度系统去控制和优化。云产品期平台太成功了就希望做成云服务赋能社会上类似的业务发挥更大的价值。如果说在平台期隔离还只是个重要但非必须的要求的话很多平台就没有真正做好隔离云产品期的产品必须具备非常强的隔离能力。平台期做隔离最大的诉求是稳定性不被平台上的开发者搞垮整个平台而云产品期做隔离的最大诉求是安全性。正如图中所示产品上的开发者已经和产品团队不在一个组织了而且这样的开发者还可能是恶意的因此除了容器的隔离还需要虚拟机级别的隔离网络的隔离等等。随着技术产品由小长大不断成功参与的开发者不断增长核心团队对这些开发者的控制力越来越弱沟通带宽不断缩减信任不断降低进而导致了稳定性和安全的风险不断上升这就要求隔离能力不断加强。而随着隔离的引入以及使用资源的不断增长成本就成了一个不得不面对的问题为了更优地分配资源解决成本问题就对调度提出了要求。因此对于处在平台期和云产品期的产品来说技术上的隔离能力及调度能力是他们的刚需。框架和运行时的创新前面所说的刚需都是集中在稳定性、安全性及资源成本的角度来讨论的。除此之外我们还需要讨论另外一个话题那就是开发效率而开发效率具体到技术是体现在框架上的。我们可以进一步的把框架分成两类面向技术问题提升开发效率的框架如 Spring 通过依赖注入解决对象组装问题HSF 解决分布式同步通讯问题RocketMQ 解决分布式异步通讯问题Hystrix 解决分布式通讯引入的网络不可靠问题等等。通过使用这些框架技术的天然复杂度在很大程度被屏蔽掉了。面向业务问题提升开发效率的框架阿里的很多业务平台团队都会根据自己的场景如交易、店铺、供应链开发业务型框架赋能开发快速迭代业务。通常面向技术问题的框架会有一个团队研发而面向业务问题的框架则由各类业务平台团队提供这再一次证明了康威定律的正确性。康威定律翻译成中国的土话差不多就是“屁股决定脑袋”技术型团队不愿意碰业务问题而业务平台团队的框架在解决技术问题方面也显得没有技术团队专业最终的结果是两种框架割裂得比较厉害。大家可能听过这么一个故事有一条恶龙每年要求村庄献祭一个处女每年这个村庄都会有一个少年英雄去与恶龙搏斗但无人生还。又一个英雄出发时有人悄悄尾随。龙穴铺满金银财宝英雄用剑刺死恶龙然后坐在尸身上看着闪烁的珠宝慢慢地长出鳞片、尾巴和触角最终变成恶龙。虽然看起来很夸张但在我看来这一定程度上体现了一些大中型研发组织主流框架的现状这些框架在组织发展的历史上发挥了极其重要的作用然而到了今天随着云服务不断地成熟大家都在提云原生都基于云在构建业务系统的时候需要框架还在强制用户绑定语言如 Java还没做好服务化把逻辑塞进用户的应用中。有的甚至要求用户的代码必须部署到平台的巨型应用中。这些限制短期内实现了业务目标交付了业务价值但从长期看基本上浇灭了业务开发做框架创新的热情他们更习惯于等待“位于正确定位的团队”去解决问题而“处于正确定位的团队”同学呢可能一时半会还没感受到那些问题。不出意外的话专注组织内短期业务价值的框架被推到云上、推到社区、面向更普适通用诉求的时候获得的认可就会差很多。传统的框架和运行时只管理单机层面的资源而当所有人都用云服务构建自身业务的时候框架和运行时需要管理的就不再是单机资源而是云资源了。在这方面行业里已经有了不少产品比较知名的有 Terraform[3] 和 Pulumi[4]但我觉得还不够我觉得理想的云原生框架应该是这样的能够帮助开发屏蔽云资源的管理。开发都不喜欢像写汇编一样写 yaml因此框架需要负责资源的分配、回收编排等等纯异步的事件驱动的。这是云天生的分布式特性决定的如果编程语言范式还是同步的模型这个框架就没法实现了没有 vendor lock-in。不绑定实际的云厂商唯有厂商中立的开发框架才能被广泛使用框架定义了编程 API具体的厂商可以提供相关的 driver同时具备云资源管理和大规模软件开发必须的编程范式。这里的编程范式可能描述不当但我找不到更好的词面向对象设计是最主流的编程范式Spring 就是围绕这个编程范式展开的。在一个框架中解决两个问题会给开发极好的体验。小结Serverless 这个领域看起来极其美好一旦深入去做了才发现实际非常复杂。这个复杂体现在涉及的工程技术比较广也体现在用户的期望差异很大更体现在大家对未来的判断还有很大的差异。福利扫描添加小编微信备注“姓名公司职位”加入【云计算学习交流群】和志同道合的朋友们共同打卡学习推荐阅读关于云原生需要了解什么科普帖什么是服务网格实操 | 从0到1教你用Python来爬取整站天气网大数据工程师手册全面系统的掌握必备知识与工具互联网大佬为什么爱唱歌惊呆这辆悍马自己在跑跑跑跑跑跑跑真香朕在看了
