一文让你迅速读懂Serverless
【3 天烧脑式基于Docker的CI/CD实战训练营 | 北京站】本次培训围绕基于Docker的CI/CD实战展开,具体内容包括:持续集成与持续交付(CI/CD)概览;持续集成系统介绍;客户端与服务端的 CI/CD 实践;开发流程中引入 CI、CD;Gitlab 和 CI、CD 工具;Gitlab CI、Drone 的使用以及实践经验分享等。
什么是 Serverless
Serverless架构,或者称为无服务器架构,是最近几年新冒出来的一种架构风格。这究竟是一种什么样的架构?无服务器,就是真的没有服务器了么?其实,对于 Serverless 来说,只是用户不用更多的去考虑服务器的相关内容了,无需再去考虑服务器的规格大小、存储类型、网络带宽、自动扩缩容问题了;同时,也无需再对服务器进行运维了,无需不断的打系统补丁、应用补丁、无需进行数据备份、软件配置等工作了。但是没有服务器,如何来将程序、应用运行起来呢?这里要介绍的是Serverless下包含的两个概念:函数即服务,Function as a Service,FaaS;后端即服务,Backend as a Service,BaaS。
函数即服务 FaaS
函数即服务 FaaS,作为一种新的计算能力提供方式,让用户抛弃了对服务器的配置和管理,仅需编写和上传核心业务代码,交由平台完成部署、调度、流量分发、弹性伸缩等能力。FaaS的出现,会从底层开始变革计算资源的形态,提供了一种新的方式来提供计算资源,同时也会给软件架构与应用服务部署带来新的设计思路,进一步降低云计算的使用门槛,推动全行业在服务架构上的创新步伐。后端即服务 BaaS
后端即服务 BaaS,其实大家已经使用很久了,这里的后端,指的就是各种云产品和云服务,例如对象存储 COS,消息队列 CMQ,云数据库 CDB、TDSQL,云缓存 CRedis、CMemcached,甚至到各种以 API 形式提供的服务如万象优图 CI,视频处理 VC。这些产品或服务,用户直接开通即可使用,无需考虑部署、扩容、备份、优化、安全等各种运维工作,做到了开箱即用,无需自己去进行服务器或应用的维护和管理,因此同样也是Serverless的一部分。为什么要 Serverless
介绍了什么是 Serverless,但是为什么会出现 Serverless,或者为什么要使用 Serverless 呢?我们这里可以从三个方面来看看,这三个方面可以类比为:天时,地利,人和。天时,这里突出的时,即时间。传统的服务器模式,应用上线前,还得完成服务器准备,环境部署,数据库准备,存储准备等各种工作;上线后,还得面临计算扩容,存储扩容,数据库维护和扩容等各种运维工作。这这个过程中,应用上线和迭代的时间、节奏,受限于各种准备和维护工作。而利用 Serverless,通过使用 SCF 产品,专注于完成业务相关的核心代码,通过直接使用 COS,CDB,CMQ,CRedis 等产品,解决数据存储,数据库,消息队列,缓存等问题,不再费心运维,而专注在业务开发和迭代上,能更快的完成应用上线,在这个互联网加速发展的时代,做到一步领先,步步领先。
地利,这里突出的利,即费用支出。传统的服务器模式,无论有没有用户正在访问,应用始终要保持运行,而在有用户访问时,又要关注服务器的资源使用率,在使用率达到一定程度时就要考虑扩容,避免突发访问量导致的资源不足。在这个过程中的费用,始终是有一部分为未使用的计算资源而支付。而 Serverless 架构,能确保所有的费用,都是用在了实际的程序运行、数据存储、用户访问中。SCF 云函数的计费方式,就是通过函数的调用次数和执行时间来统计费用,有用户访问或事件产生,才会有函数执行,才会有费用计算;相反,没有函数执行时,则没有费用支出。同理,其他的相关云产品,也是类似,例如 COS 仅收取存储、外网流量的费用,CMQ 仅收取请求次数、外网流量费用,CRedis 仅按实际使用内存大小收费。据测算,根据不同用户的应用压力情况,SCF 能为用户带来 30%~70% 的费用节省程度。
人和,这里突出的是人。传统的服务器模式,运维人员要投入大量的精力去维护服务器、数据库、存储等各种基础设施,解决各种集群、分布式系统的搭建问题,而实际运维解决自身应用问题的时间,可能只会占到很小一部分,而开发人员除了对自身业务应用的开发外,也需要投入时间,解决可能存在的各种外围系统的问题。而 Serverless 架构,无需运维人员再投入到基础设施中去了,而开发人员也可以全面关注业务系统的开发。SCF 产品,可以让开发人员直接编写业务逻辑核心代码,利用微服务架构,快速上线应用。CMQ,CDB,COS,CRedis 各种云产品,无需搭建配置,开通即可使用,而将基础运维工作交由云来完成。在这种情况下,脱离了基础运维的运维人员,可以提升自身视野,从更高角度来看待运维工作,实现业务运维;而开发人员,可以充分利用 CICD、DevOps能力,提升整个应用或业务的集成能力。
怎么用Serverless
COS、CMQ、CDB、CRedis 这类 BaaS 型云产品,由于面世的时间已经很长,对其使用的方式,基本和原有使用 MySQL、Redis 等产品相同,或者通过产品提供的 API、SDK 直接访问使用。而 SCF 云函数,作为 FaaS 产品,有着稍有不同的使用方式。事件触发:SCF 的工作模式为事件触发,因此要考虑好触发方式。例如,利用 SCF 来处理图片生成缩略图,就可以利用 COS 事件,在图片文件上传 COS 后,上传事件就能自动触发函数执行,来生成新的缩略图并再次存入 COS 中。
无状态服务:函数需要是无状态(stateless)的,缓存、日志、数据库等全部通过 CRedis、COS、CDB 这类云产品来支持,这样才能保证在业务请求突增时服务能迅速扩展。
微服务:事件驱动(event-driven)和无状态(stateless)属性正是微服务架构所需要的。因此,在一开始就将自身的应用设计为微服务架构,解耦各模块间关联,使得应用成为可生长可进化的系统。
无服务器云函数 SCF 实现独立开发、简化测试和加速部署,能够助力公司在关键时期快速上线和迭代,为初创期的产品提供了很好的解决方案。
作者:腾讯云Serverless团队
原文发布时间为:2017-08-16
本文作者:克劳德同学
本文来自云栖社区合作伙伴Dockerone.io,了解相关信息可以关注Dockerone.io。
原文标题:一文让你迅速读懂Serverless

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
我只有两天。
日全食后,一直有不详的预感,低潮来临的预感,一直暗暗恐慌一直暗暗抵抗,因为我越来越害怕低潮了,不是我能力越来越弱,而是它的能量越来越强,让我越来越难恢复,越来越需要更长的时间慢慢恢复。 终于,我还是掉进去了。 导火线是什么呢?前天晚上我处理一个很小的设计,并在亢奋的状态下用了整整一个通宵去完成,整个过程中我都很兴奋,因为我觉得我又做了一个完美的设计。可是当我做完提交昏昏睡去,一觉醒来,重新坐到电脑面前进行审视的时候,却不断否定这个设计,一点又一点,一点又一点,最后竟没有一处让我满意,这个设计根本就不能把我想表达的东西呈现出来,反而它传递出无数的问号和疑惑,就像自己千辛万苦的创造了一个垃圾。5个小时,这个成型的设计连5个小时都没能沉淀下来,存活下来…… 然后,然后就是一种从天堂坠入地狱的情绪开始在血液流淌,不知不觉的迅速蔓延、燎原。终于到昨天晚上的时候开始在表面熊熊燃烧,我终于知道它还是来了,我被巨大的绝望包围了,我开始自我否定,从工作否定到生活,从性格否定到为人,我把自己批得一无是处,非常的无助。 我无法下手去做任何事情甚至不敢说话,因为好像我每做一件事,每说一句话都会让我在几分钟后感...
- 下一篇
微服务,容器和运维:猜猜现在谁来担责
本文讲的是微服务,容器和运维:猜猜现在谁来担责【编者的话】容器技术和DevOps为我们带来了新的开发模式,本文为大家带来了应对职责分离带来的问题的宝贵经验。 贯穿软件生命周期共享相同的容器是 容器化 DevOps带来的优点之一,它简化了开发与运维团队之间的关系。这个共享能力与传统裸机(bare metal)或是虚拟环境下的开发工作是如此的不同。并且,如此一来也改变了代码迁移到生产环境时的最终责任人。 在传统的开发场景中,很多IT组织不能为开发和QA团队提供与生产环境相同的基础设施,因此他们会在精简版本上测试,即使它们一点都不同。例如,在VMware商店,开发者也许会使用 Vagrant工具 来编写和测试代码。 当开发团队将代码交付给运维,以便在生产环境中部署,然而它却未能正常工作时,挑战就出现了。“在我的机器上明明能工作的啊”,这句话已经成了此类场景的惯用语,但这对决解如何让正常工作的代码更快地从开发者迁移到生产环境的问题没有任何帮助。在DevOps和容器的新纪元里,开发者必须对最终产品承担更多责任。 容器已经重定义交付 容器已经改变了业界动态(dynamic)。这是第一次,开发者的代...
相关文章
文章评论
共有0条评论来说两句吧...