关于腾讯云:发布更新|腾讯云-Serverless-产品动态-20200922

一、API 网关签名工具正式公布公布工夫: 2020-09-21 产品背景: 用户反馈在应用 Postman 等工具调用密钥对认证 API 时,生成签名还须要运行代码,过程比较复杂。 产品性能: API 网关签名工具是腾讯云 API 网关为用户提供的 Web 工具,可用于生成密钥对认证 API 的申请签名。用户能够在工具页面上填入指定的参数,生成申请签名。 产品体验: https://console.cloud.tencent... 产品文档: https://cloud.tencent.com/doc... 二、Serverless Framework 提供标准的我的项目组织和环境隔离办法性能公布工夫: 2020-09-11 产品背景: 用户在应用 Serverless Framework 组件部署业务时,须要进行环境隔离和组件之间的组织治理,之前的组件文档只提供了简略的应用入门领导,短少利用和我的项目开发领导。 产品性能 Serverless Framework 新增标准的我的项目组织和环境隔离等办法,用户按照标准的形式组织我的项目,便于前期项目管理、拓展和保护。 产品文档: https://cloud.tencent.com/doc...https://cloud.tencent.com/doc...One More Thing立刻体验腾讯云 Serverless Demo,支付 Serverless 新用户礼包 ???? serverless/start 欢送拜访:Serverless 中文网!

September 22, 2020 · 1 min · jiezi

关于腾讯云:大数据云原生系列大数据系统云原生渐进式演进最佳实践

1.引言随着云原生概念的衰亡,越来越多的企业投身于云原生转型的浪潮,以解决传统利用面临的弹性能力有余、资源利用率较低、迭代周期较长等问题。通过云原生技术(如容器,不可变基础设施和申明式API等),使得企业在私有云、公有云和混合云等云环境构建和运行利用变得更加容易,更能充分利用云环境的劣势,减速了企业应用迭代、升高资源老本、进步零碎容错性和资源弹性。 基于Hadoop生态的传统大数据系统,同样面临着弹性能力有余、资源利用率低,治理艰难等问题,云原生技术人造适宜解决这些问题。然而,将基于Hadoop生态的传统大数据系统革新成云原生架构,波及到革新老本高、迁徙危险大等诸多挑战。那有没有计划,既能够基于云原生技术解决大数据系统弹性能力有余,资源利用率低,治理艰难等问题,又能保障革新老本、迁徙危险比拟低呢?腾讯云大数据团队和容器团队,基于大数据系统的现状,联合大数据技术和容器技术的特点,推出了渐进式的云原生演进计划。应用该计划,能够在较小革新老本和迁徙危险的前提下,实现大数据系统的云原生化,充分利用云原生的劣势。 本文顺次剖析了大数据系统以后面临的次要问题、云原生如何解决这些问题、大数据系统云原生革新面临的挑战,基于这些问题和调整,重点介绍了基于Hadoop Yarn on Kubernetes Pod(下文会具体介绍)的渐进式的云原生演进计划及其最佳实际。 2.大数据系统次要问题传统的大数据系统围绕着Hadoop生态疾速的倒退,百花齐放,各个企业也逐渐建设了本人的大数据平台,甚至是数据中台。然而,在强烈的市场竞争和一直减少的生产冀望的双重驱动下,一方面业务须要疾速迭代以满足迅速的增长,另一方面须要在资源需要一直增长的同时管制昂扬的老本以放弃企业的竞争力。这就要求大数据系统可能及时、疾速的扩容以满足生产需要,又能尽可能的进步资源的应用效率,升高资源的应用老本。具体的问题体现在以下几点: 弹性扩缩容能力无奈满足快速增长的业务需要:随着业务的倒退,流量和数据量突增,尤其对于实时计算,须要资源可能及时的扩容,以满足业务需要。只管一些大数据管控平台尝试实现主动的扩缩容(如通过集群负载状况,进行扩容),然而,在传统大数据平台架构下,通常须要资源申请、依赖软件装置、服务部署等一系列步骤,该过程通常比较慢,对于集群负载的缓解,不够及时。在离线拆散部署及粗粒度调度无奈进步资源的利用率:在传统Hadoop架构下,离线作业和在线作业往往分属不同的集群,然而在线业务、流式作业具备显著的波峰波谷个性,在波谷时段,会有大量的资源处于闲置状态,造成资源的节约和老本的晋升。在离线混部集群,通过动静调度削峰填谷,当在线集群的使用率处于波谷时段,将离线任务调度到在线集群,能够显著的进步资源的利用率。然而,Hadoop Yarn目前只能通过NodeManager上报的动态资源状况进行调配,无奈基于动静资源调度,无奈很好的反对在线、离线业务混部的场景。操作系统镜像及部署复杂性拖慢利用公布:虚拟机或裸金属设施所依赖的镜像,蕴含了诸多软件包,如HDFS、Spark、Flink、Hadoop等,零碎的镜像远远大于10GB,通常存在镜像过大、制作繁琐、镜像跨地区散发周期长等问题。基于这些问题,有些大数据开发团队不得不将需要划分为镜像类和非镜像类需要,当须要批改镜像的需要积攒到肯定水平,才对立进行公布,迭代速度受限,当遇到用户紧急且须要批改镜像的需要时,势必面临很大的业务压力。同时,购买资源后,利用的部署波及到依赖部署、服务部署等环节,进一步拖慢利用的公布。 图1 大数据系统次要问题 以上提到的弹性扩缩容、利用公布效率和资源利用率,是以后大数据系统普遍存在的问题,如何解决和应答这些问题,越来越成为企业较为关怀的话题。接下来,咱们将从云原生的角度来剖析如何解决这些问题。 3. 云原生技术如何解决大数据系统问题云原生技术如何解决弹性扩容问题: 在云原生架构中,应用程序及其依赖环境曾经提前构建在镜像中,利用程序运行在基于该镜像启动的容器中。在业务高峰期,随着业务量的回升,向云原生环境申请容器资源,只需期待镜像下载实现即可启动容器(个别镜像下载工夫也是秒级的),当容器启动后,业务利用将立刻运行并提供算力,不存在虚拟机的创立、依赖软件装置和服务部署等耗时的环节。而在业务低峰期,删除闲置的容器,即可下线相应的应用程序,以节俭资源应用的老本。借助云原生环境和容器技术,能够疾速的获取容器资源,并基于利用镜像秒级启动应用程序,实现业务的疾速启停,实时的扩缩容业务资源以满足生产需要。 云原生技术如何解决资源使用率低的问题: 在传统架构中,大数据业务和在线业务往往部署在不同的资源集群中,这两局部业务互相独立。但大数据业务个别更多的是离线计算类业务,在夜间处于业务顶峰,而在线业务恰恰相反夜间经常处于空载状态。云原生技术借助容器残缺(CPU,内存,磁盘IO,网络IO等)的隔离能力,及kubernetes弱小的编排调度能力,实现在线和离线业务混合部署,从而使在离线业务充分利用在线业务闲暇时段的资源,以进步资源利用率。 另外,应用无服务器(serverless)技术,通过容器化的部署形式,做到有计算工作需要时才申请资源,资源按需应用和付费,应用完之后及时退还资源,极大的减少了资源应用的灵活性,晋升资源应用的效率,无效的升高了资源应用的老本。 云原生技术如何解决公布周期长的问题: 传统大数据系统中,所有环境基本上应用同一个镜像,依赖环境比较复杂,部署、公布周期往往比拟长。有时根底组件须要更新,因为须要从新构建镜像,并上传到各个地区,耗时可能长达数天。而云原生架构应用容器进行部署,利用的公布和根底组件的更新都只须要拉取新的镜像,重新启动容器,具备更新速度快的人造劣势,并且不会有环境一致性的问题,能够放慢利用公布的节奏,解决利用公布周期长的问题。 4. 大数据系统向云原生架构演进的挑战云原生的技术尽管能解决以后大数据系统遇到的问题,然而,将大数据系统从传统的基于Hadoop生态的架构,迁徙到云原生架构,将会面临一些挑战: 利用革新老本高:将运行在Hadoop平台的大数据利用迁徙到云原生平台,一方面须要大数据团队将业务利用进行容器化革新,如零碎工作的启动形式、基础设施的适配(环境变量、配置文件获取形式的变更等),这些都须要大数据团队来做适配,在资源管理的形式,则从适配Yarn批改为适配Kubernetes,总体革新老本比拟高;另一方面,须要在大数据利用的资源申请层面进行革新,使其具备间接向Kubernetes集群申请资源的个性,也称为Native on Kubernetes。目前Apache Spark、Apache Flink曾经从框架内核不同水平的反对了该个性,但整体的残缺对依赖于社区的致力。迁徙危险高:一次变更引入的改变越多,引发故障的几率也越多。在Hadoop畛域,大数据利用的资源,由 Hadoop Yarn负责管理和调度,具体来说,大数据利用运行在Yarn提供的Container之中,这里的Container,是Yarn中资源的形象,并非Linux Container,将其迁徙至以容器为技术的云原生架构,逾越了底层基础架构,改变面比拟大,危险绝对也更高。组织架构造成额定的老本:企业里负责开发和运维Hadoop零碎的团队,和容器团队通常分属不同的部门,其技术栈也有显著区别,在迁徙的过程中,存在过多的跨部门沟通,带来额定的迁徙老本,如果改变比拟大,跨局部沟通的老本会十分大。由此可见,将大数据利用从传统Hadoop架构迁徙至Kubernetes架构,并没有那么简略,尤其是依赖社区对大数据利用自身的革新,使其具备运行在云原生平台的能力,然而这些革新,非久而久之所能实现,仍须要大数据利用社区在云原生方向作出更多的致力。 5. 大数据系统云原生渐进式演进计划5.1 渐进式演进计划简介上文提到的大数据系统现存问题,云原生技术如何解决大数据系统的问题,以及大数据系统从传统架构迁徙到云原生架构的挑战。那有没有一种计划既能解决大数据系统的问题,让大数据系统架构更加云原生。又能够升高迁徙过程中的革新老本,躲避迁徙危险呢? 接下来本文将介绍大数据系统渐进式向云原生演进的计划,通过渐进式迁徙演进的形式,在架构较小改变的状况下,通过云原生技术解决大数据系统的问题。通过较小的投入,取得云原生技术的红利,并且防止迁徙过程的的危险。同时前期还能够在这根底上进一步将大数据系统平滑演进到云原生架构。 渐进式演进计划次要有弹性扩缩容和离在线混合部署两种模式,两个模式的侧重点略有不同,弹性扩缩容次要聚焦于如何利用云原生资源,借助serverless技术,疾速扩容资源以补充算力,满足业务实时需要。而离在线混部次要聚焦于利用在线业务闲暇时段的闲置资源,通过将大数据离线计算任务调度到在线业务闲置资源的上,在保障业务稳定性的根底上,大幅晋升资源的应用效率。这两种模式都应用了Yarn on Kubernetes Pod的模式,如下图,其根本思维是,将Yarn NodeManager运行在Kubernetes集群中新扩容的Pod容器内,当Yarn NodeManager Pod启动后,依据配置文件主动向已有的Hadoop集群的Yarn ResourceManager发动注册,最终以Kubernetes Pod的模式补充Yarn集群的算力。 图2 Yarn on Kubernetes Pod 5.2 渐进式演进之弹性扩缩容模式在弹性扩缩容模式中,弹性扩缩容模块会依据大数据集群资源的应用状况,动静的向serverless Kubernetes集群申请(开释)资源。申请资源的具体模式为,在Kubernetes集群中创立(销毁)Yarn operator的自定义资源(CustomResourceDefinition,CRD),集群中部署的Yarn-operator会依据crd资源来创立(删除) Yarn pod。在Yarn pod中会启动Yarn nodemanager过程,Yarn nodemanager过程启动后会主动向大数据集群中的Yarn resource-manager发动注册,裁减(缩小)大数据集群的算力,满足工作的资源需要。 如图1所示,左侧是运行在腾讯云EMR(弹性MapReduce)零碎上的大数据集群,右侧是腾讯云EKS(弹性容器服务)(Serverless Kubernetes)集群。 图3 弹性扩缩容计划(EMR大数据集群) ...

September 21, 2020 · 1 min · jiezi

关于腾讯云:Istio-运维实战系列2让人头大的『无头服务』上

本系列文章将介绍用户从 Spring Cloud,Dubbo 等传统微服务框架迁徙到 Istio 服务网格时的一些教训,以及在应用 Istio 过程中可能遇到的一些常见问题的解决办法。 什么是『无头服务』?『无头服务』即 Kubernetes 中的 Headless Service。Service 是 Kubernetes 对后端一组提供雷同服务的 Pod 的逻辑形象和拜访入口。Kubernetes 会依据调度算法为 Pod 调配一个运行节点,并随机调配一个 IP 地址;在很多状况下,咱们还会对 Pod 进行程度伸缩,启动多个 Pod 来提供雷同的服务。在有多个 Pod 并且 Pod IP 地址不固定的状况下,客户端很难通过 Pod 的 IP 地址来间接进行拜访。为了解决这个问题,Kubernetes 采纳 Service 资源来示意提供雷同服务的一组 Pod。 在缺省状况下,Kubernetes 会为 Service 调配一个 Cluster IP,不论后端的 Pod IP 如何变动,Service 的 Cluster IP 始终是固定的。因而客户端能够通过这个 Cluster IP 来拜访这一组 Pod 提供的服务,而无需再关注后端的各个实在的 Pod IP。咱们能够将 Service 看做放在一组 Pod 前的一个负载均衡器,而 Cluster IP 就是该负载均衡器的地址,这个负载均衡器会关注后端这组 Pod 的变动,并把发向 Cluster IP 的申请转发到后端的 Pod 上。(备注:这只是对 Service 的一个简化形容,如果对 Service 的外部实现感兴趣,能够参考这篇文章 如何为服务网格抉择入口网关?) ...

September 18, 2020 · 5 min · jiezi

关于腾讯云:腾讯云-Serverless-ETL-蘑菇街实战落地

背景 蘑菇街旨在做一家高科技轻时尚的互联网公司,公司的外围主旨就是购物与社区的互相联合,为更多消费者提供更无效的购物决策倡议。 蘑菇街上每天有几百万网友在这里交换时尚、购物的话题,互相分享,这些行为会产生大量的数据,当这些数据源产生数据后,须要有一个组件获取数据源的数据,将数据写到 kafka,蘑菇街研发团队以往的解决办法,一是通过 Lofstash、Filebeat 等开源的数据存储计划解决,二是本人写代码实现这种逻辑。 开始数据量小的时候还能够,随着业务的一直扩张,数据越来越大,为了保障可用性、可靠性以及性能相干的内容,须要大量的研发资源投入,因而,亟待新的解决方案反对。 CKafka 全称是 Tencent Cloud Kafka ,是一款适宜私有云部署、运行、运维的分布式、高牢靠、高吞吐和高可扩大的音讯队列零碎。它 100% 兼容开源的 Kafka API,目前次要反对开源的 0.9, 0.10, 1.1.1, 2.4.2 四个大版本,并提供向下兼容的能力。 目前 Tencent Cloud Kafka 保护了近万节点的集群,沉积数据达到了 PB 级。是一款集成了租户隔离、限流、鉴权、平安、数据监控告警、故障疾速切换、跨可用区容灾等等一系列个性的,历经大流量测验的、牢靠的私有云上 Kafka 集群。 CKafka 目前服务对象包含拼多多、微信、哔哩哔哩,以及腾讯外部的一些大的利用,包含腾讯视频、微视等。 蘑菇街的抉择蘑菇街团队比照市场上的技术解决方案,从学习老本、扩缩容能力以及人工保护老本和稳定性方面思考。 腾讯云 Serverless 云函数具备人造的劣势: 反对多语言学习成本低,不须要学习开源计划,不须要学习散布式调度有限的弹性扩容能力多重触发形式,事件触发、定时触发、被动触发集群稳定性和可用性的保护老本简直没有按理论用量计费,1ms计费,费用很低同时,腾讯云 Serverless 云函数+ Ckafka 提供自建的 UI 交互界面,可进行流量告警配置,同时管制台上可进行扩容配置且安全可靠。 腾讯云 Serverless 团队为蘑菇街提供的业务解决方案,是通过云函数将一个实例中某个 Topic 的音讯转储至另一个实例对应的 Topic上,比照原来的 Connector 计划,腾讯云云函数 SCF 可能通过腾讯云控制台进行治理,能管制触发阈值,触发开关等,能够很不便地对每个函数进行治理。简略来讲, 音讯转储:将 Topic 的音讯同步至离线集群集群迁徙:在集群迁徙合并的过程中起到一个双写的作用 通过比照,腾讯云 Serverless 云函数 + Ckafka 是最优的解决方案,蘑菇街最终决定抉择应用腾讯云 Serverless 云函数 + Ckafka 使用在的音讯同步业务上。 ...

September 17, 2020 · 1 min · jiezi

关于腾讯云:腾讯云推出云原生etcd服务

背景腾讯云容器服务TKE从2016年提供服务至今,已服务成千上万企业构建其容器化平台, 一方面,腾讯云容器团队在提供容器服务时积攒并欠缺了一套万级K8s集群的etcd治理平台,用于撑持腾讯云容器产品稳固运行,该平台同时也撑持了腾讯外部业务如云监控,api网关,欢畅游戏等,另一方面,咱们积极参与etcd社区,将咱们大规模实际过程中遇到的问题和解决方案,反馈和奉献给社区,是社区2020年最沉闷的奉献团队之一。 容器团队在屡次客户访谈中理解到,很多客户不想本人运维etcd,冀望可能应用腾讯云容器服务外部etcd平台的能力和教训。 因而咱们推出了腾讯云原生etcd服务。 腾讯云原生etcd服务介绍etcd是什么etcd是一个分布式、高牢靠的键值存储,能够容忍集群中局部节点故障,只有有一半以上节点存活即可对外提供服务。次要用于元数据存储,服务发现,分布式选举等场景,如Kubernetes,CoreDNS等。基于etcd提供的Watch机制,能够很不便的实现公布订阅等性能。 为什么要推出etcd服务容器团队在访问客户时理解到,很多客户因为对etcd理解水平不够,导致在理论应用和运维过程中呈现过很多问题。 例如有些客户应用了v3的api写数据却应用了v2的api进行数据备份,还有些客户因为集群复原时参数指定的有问题导致集群无奈失常重建,从而影响业务复原,更有甚者,因为主动压缩参数配置的有问题而频繁的应用defrag进行碎片整顿,还有很多业务因为应用姿态的问题导致etcd性能重大降落,频繁leader选举,间接造成业务不可用,数据失落等。 此外,用户自建etcd往往还须要本人再保护一套etcd监控告警零碎和备份复原机制,减少了运维累赘,自建etcd集群容易忽略监控和备份机制,往往出了问题之后才后知后觉。尽管目前业界曾经有了很多基于K8s的etcd治理计划,肯定水平上加重了运维累赘,如etcd-operator(目前已不再保护),基于helm部署的etcd等,但这些我的项目在可用性和易用性上并没有保障,出了问题之后往往更难复原。 腾讯云容器团队目前线上运维了上万套K8s集群,后端应用了上千套etcd集群作为撑持存储,在保障etcd稳固经营的过程中,咱们遇到过很多问题,也因而积攒了大量的实践经验,并孵化出了一套自动化etcd治理平台:蕴含欠缺的监控告警,备份复原和容灾机制,弱小的巡检能力可能帮忙咱们进行热点数据分析,混沌工程帮忙咱们被动发现一些暗藏的bug,可控的变更和降级机制可能让咱们针对问题版本进行疾速降级。 目前咱们曾经在腾讯外部为多个业务团队提供etcd服务,保障业务疾速上线和稳固经营。 为服务更多客户,咱们推出了云原生etcd产品服务,将咱们外部的能力提供进去,衷心冀望可能帮您解决etcd的运维累赘。 腾讯云原生etcd服务介绍腾讯云容器团队提供的云原生etcd服务能够帮忙您: 一键部署经腾讯外部大规模验证的高牢靠高性能etcd集群,反对跨可用区容灾能力、业余团队为您提供最优化的性能配置。集成云原生监控能力,提供欠缺的监控和告警机制提供etcd日常运维治理能力: 备份复原:反对主动备份和手动备份、劫难状况能够抉择从备份复原集群配置升降、集群扩缩容:借助腾讯云上计算存储资源,您能够不便疾速调整etcd集群配置和节点个数etcd版本升级:帮忙您疾速平安地跟进社区bugfix版本更新,版本上线前会通过外部大规模场景验证,防止因etcd本身bug造成隐患。一键部署etcd集群 集成云原生监控除原生指标外,集成云原生监控还同时反对扩大的巡检指标,如数据一致性巡检,集群衰弱探测,业务写QPS巡检等。 etcd集群治理 腾讯云原生etcd服务产品劣势易用应用的托管部署您能够在腾讯云容器服务控制台一键创立高牢靠,高性能etcd集群, 即可在几分钟内启动一个可投入生产的etcd集群。底层资源基于K8s部署,通过operator进行治理,反对将节点打散到不同的可用区,在3个可用区的状况下,单可用区挂掉不影响集群失常服务,节点挂掉之后能够疾速自愈,最大水平升高不可用工夫。数据长久化存储于腾讯云云硬盘,具备多正本的容灾能力。您不须要过多关注etcd的各项简单参数,咱们会依据您的集群配置,主动适配到适合的参数配置。 平安的数据拜访反对开启https双向认证及鉴权,数据拜访更加平安。反对通过平安组来限度拜访起源。 欠缺的数据备份/复原您能够在控制台创立集群时或集群创立实现后设置etcd的备份策略,反对定时的将数据备份到腾讯云对象存储COS服务,您也能够手动来触发备份。在集群数据异样须要回滚的状况下,能够通过COS备份来复原集群。 全面的监控告警无缝对接腾讯云原生监控服务(托管prometheus服务),默认提供您须要关注的各项性能指标和可用性指标,您也能够自行聚合须要的监控指标和面板,帮忙您更好的监控etcd集群状态。 热点数据分析除默认的监控能力外,咱们额定提供了热点数据分析和慢查问剖析能力,能够帮忙您更好的剖析异样申请起源,及时发现问题并进行优化。 欠缺的保障机制云原生etcd服务的高可靠性让您能够释怀将数据放在云端,无需放心数据失落,也简化了传统运维工作中为保障数据高牢靠带来的额定工作量和额定的 IT 投入老本。 牢靠的版本验证和更新机制版本上线前会通过欠缺的内部测试和大规模验证,通过混沌工程进行故障演练,保障版本的稳定性。 全流程的运维服务您无需关怀云原生etcd服务的装置、部署、版本更新及故障解决,容器团队为您罢黜后顾之忧。 内测邀请咱们诚挚邀请您参加腾讯云原生etcd服务的内测, 您能够通过以下链接提交内测申请:https://cloud.tencent.com/app... 附录:《三年之久的 etcd3 数据不统一 bug 剖析》 《万级K8s集群背地etcd稳定性及性能优化实际》 【腾讯云原生】云说新品、云研新术、云游新活、云赏资讯,扫码关注同名公众号,及时获取更多干货!!

September 16, 2020 · 1 min · jiezi

关于腾讯云:腾讯云-SeverlessExpress-项目开发和灰度发布最佳实践

本文首发于 Serverless 中文网Serverless 利用基本概念一个 Serverless 利用是由单个或者多个组件实例形成的。每个组件中都会有一个 serverless.yml 文件,该文件定义了组件的一些参数,这些参数在部署时用于生成实例的信息。例如 region 参数,定义了资源的所在区。 组织是在 Serverless 利用下层的概念,次要是为了治理。例如,一个公司会有不同部门进行 Serverless 利用开发,设置不同组织名称,不便做前期的权限治理。 示例:开发一个 express 利用,最根本的是引入 express 组件,业务两头可能会波及到其余一些云产品(如对象存储 COS),所以整个利用目录如下: Serverless.yml 文件serverless.yml 文件中定义了利用组织形容及组件 inputs 参数,每次部署时会依据 serverless.yml 文件中的配置信息进行资源的创立、更新和编排。 一份简略的 serverless.yml 文件如下: # serverless.ymlorg: xxx-department # 用于记录组织信息,默认为您的腾讯云 APPIDapp: expressDemoApp # 利用名称,默认为与组件实例名称stage: ${env:STAGE} # 用于开发环境的隔离,默认为 devcomponent: express # (必填) 援用 component 的名称,以后用到的是 express-tencent 组件name: expressDemo # (必填) 组件创立的实例名称inputs: src: src: ./ exclude: - .env region: ap-guangzhou runtime: Nodejs10.15 functionName: ${name}-${stage}-${app}-${org} #云函数名称 apigatewayConf: protocols: - http - https environment: releaseyml 文件中的配置信息: ...

September 16, 2020 · 2 min · jiezi

关于腾讯云:云原生下离在线混部实践系列深入浅出-Google-Borg

Google Borg 是资源调度治理和离在线混部畛域的鼻祖,同时也是 Kubernetes 的起源与参照,已成为从业人员首要学习的榜样。本文尝试管中窥豹,简略从《Large-scale cluster management at Google with Borg》一文中分析 Google Borg 的设计理念和性能特点,用以抛砖引玉。 Google Borg 是什么?Google Borg 是 Google 外部自研的一套资源管理零碎,用于集群资源管控、调配和调度等。在 Borg 中,资源的单位是 Job 和 Task。Job 蕴含一组 Task。Task 是 Borg 治理和调度的最小单元,它对应一组 Linux 过程。相熟 Kubernetes 的读者,能够将 Job 和 Task 大抵对应为 Kubernetes 的 Service 和 Pod。 在架构上,Borg 和 Kubernetes 相似,由 BorgMaster、Scheduler 和 Borglet 组成。 Borg AllocsBorg Alloc 代表一组可用于运行 Task 的资源,如 CPU、内存、IO 和磁盘空间。它实际上是集群对物理资源的形象。Alloc set 相似 Job,是一堆 Alloc 的汇合。当一个 Alloc set 被创立时,一个或多个 Job 就能够运行在下面了。 ...

September 15, 2020 · 3 min · jiezi

关于腾讯云:Prometheus-Metrics-设计的最佳实践和应用实例看这篇够了

Prometheus 是一个开源的监控解决方案,部署简略易使用,难点在于如何设计合乎特定需要的 Metrics 去全面高效地反映零碎实时状态,以助力故障问题的发现与定位。本文即基于最佳实际的 Metrics 设计办法,联合具体的场景实例——TKE 的网络组件 IPAMD 的外部监控,以集体实践经验谈一谈如何设计和实现适宜的、可能更好反映零碎实时状态的监控指标(Metrics)。该篇内容适于 Prometheus 或相干监控零碎的初学者(可无任何根底理解),以及近期有 Prometheus 监控计划搭建和保护需要的零碎开发管理者。通过这篇文章,能够加深对 Prometheus Metrics 的了解,并能针对实际的监控场景提出更好的指标(Metrics)设计。 1 引言Prometheus 是一个开源的监控解决方案,它可能提供监控指标数据的采集、存储、查问以及监控告警等性能。作为云原生基金会(CNCF)的毕业我的项目,Prometheus 曾经在云原生畛域失去了大范畴的利用,并逐步成为了业界最风行的监控解决方案之一。 Prometheus 的部署和应用能够说是简略易上手,然而如何针对实际的问题和需要设计合适的 Metrics 却并不是那么间接可行,反而须要优先解决裸露进去的诸多不确定问题,比方何时选用 Vector,如何设计合适的 buckets,Summary 和 Histogram 指标类型的取舍等。然而,要想无效助力故障及问题的发现与定位,必须要有一个正当无效的 Metrics 去全面高效地反映零碎实时状态。 本文将介绍基于最佳实际的 Metrics 设计办法,并联合具体的场景实例——TKE 的网络组件 IPAMD 的外部监控,以集体实践经验谈一谈如何设计和实现适宜的、可能更好反映零碎实时状态的监控指标(Metrics)。 本文之后的第 2 节将对 Prometheus 的 Metrics 做简略的介绍,对此已有理解的读者可跳过。之后第 3 节将介绍 Metrics 设计的最佳实际。第 4 节将联合具体的实例利用相干设计办法。第 5 节将介绍 Golang 上指标收集的实现计划。 2 Prometheus Metrics Type 简介Prometheus Metrics 是整个监控零碎的外围,所有的监控指标数据都由其记录。Prometheus 中,所有 Metrics 皆为时序数据,并以名字作辨别,即每个指标收集到的样本数据蕴含至多三个维度的信息:名字、时刻和数值。 而 Prometheus Metrics 有四种根本的 type: ...

September 15, 2020 · 4 min · jiezi

关于腾讯云:腾讯会议大规模使用Kubernetes的技术实践

腾讯会议,一款提供灵便合作的线上会议解决方案。其中大量的模块是有状态服务,在应用Kubernetes为其进行容器化部署时,Pod降级需放弃共享内存、长连贯服务。降级时只容忍ms级抖动,需提供大规模分批灰度公布、业务配额管制等能力,并同时解决集群节点负载不平衡、上万Pods的Workload的HPA性能差等问题。这里将向大家介绍TKEx容器平台及其在灰度公布、资源管理、弹性伸缩等方面的能力。 海量规模下Kubernetes面临的挑战在腾讯自研业务中,曾经有几百万核跑在Kubernetes上,要在如此体量的容器场景提供牢靠稳固的容器服务,无论在底层、集群能力、经营或运维等各个方面都面临具体挑战。 咱们怎么进行容器牢靠高性能的灰度公布? 尤其是在自研业务外面,大量的服务是有状态的服务, 原生的Kubernetes StatefulSet曾经无奈满足咱们如此大规模的容器公布需要。调度层面须要做哪些优化,从而保障在Pod漂移和重调度的过程中保障业务的稳定性。在优化资源编排性能方面,如何在整个平台层面和业务层面做好后盾治理。在大规模的弹性伸缩方面如何提供高性能和全面的弹性伸缩能力。TKEx容器平台简介TKEx容器平台的底层基于腾讯私有云的TKE和EKS两个产品,它是应用Kubernetes原生的技术手段服务于腾讯外部的业务, 包含腾讯会议、腾讯课堂、QQ及腾讯看点等。TKEx在灰度公布、服务路由、弹性伸缩、容器调度、资源管理、多集群治理、业务容灾、在离线混部等方面做了大量工作,比方: 通过Kubernetes API/Contoller/Operator的原生形式适配腾讯外部各种零碎,比方服务路由零碎、CMDB、CI、平安平台等。通过申明式的形式,对所有的托管业务进行生命周期治理。反对在线业务、大数据、AI等类型作业。实现在线业务和离线业务的混合部署,同时晋升整个资源的利用率。通过优化linux的内核,加强资源底层隔离能力。集成Tencent Cloud Mesh(TCM)服务为自研业务提供ServiceMesh服务。在大规模的集群外面,对弹性伸缩的各种组件进行革新和优化,以保障它的性能和可用性。基于业务产品维度,提供多租户和配额治理能力。上面是TKEx平台缩略版的架构图,仅包含本次探讨的相干能力。 底层基于TKE和EKS两个产品,在下层服务于在线业务、AI训练以及大数据作业。两头这四个框次要包含在利用和路由治理、资源编排调度、弹性伸缩、混部。上面会重点介绍其中前三个局部。高效稳固的公布能力业务没有大规模应用StatefulSet的滚动更新能力,对于有状态服务来说,原生的滚动更新机制的公布可控性太差,对于multi-zone容灾部署的业务更是很难做精细化的公布策略。咱们提供了分批灰度公布策略供有状态服务应用,约80%的Workload都抉择了这种策略。 以一个业务分两批进行公布为例,第一批降级两个Pod,用户能够指定是哪两个Pod,也能够依照肯定比例指定第一批是10%,由平台主动抉择10%的Pod进行灰度,残余Pods在第二批进行灰度。 主动分批机制:如果Pod的探针欠缺且能实在反映业务是否可用,用户能够应用主动分批机制,上一批次实现后可通过自定义的批次工夫距离和健康检查机制主动进行下一批的灰度公布或者主动回滚。手动分批机制:用户也能够通过手动分批机制,在上一批次灰度实现后,可人为在业务层面确认上一批的灰度是否胜利,来决定是否触发下一批灰度还是回滚。分批灰度公布更平安、更牢靠、更可控的个性,整个公布过程更灵便。因为单个批次内所有选中Pods的更新都是并发的,因而能够应酬紧急疾速公布的需要。 StatefulSetPlus是咱们用来实现分批灰度公布的CRD,它继承了Kubernetes原生的StatefulSet的所有能力,并在此之上新增和优化了大量个性。StatefulSetPlus次要提供的外围个性包含主动的以及手动的分批灰度公布,在公布异样时能够进行全量一次回滚或者分批次的回滚。Pod更新的策略反对两种模式,一种是Pod重建的形式,另一种是Pod的原地降级形式。同时咱们还提供了一些高级个性,比方: 反对Pod降级过程中放弃Pod应用的共享内存数据不失落,这个个性非常适合于像腾讯会议这样的音视频业务。如果降级过程中触发了Workload的扩容,那么扩容的时候会应用上一个好的版本进行扩容,而不是像原生的StatefulSet和Deployment一样,应用最新的镜像进行扩容,因为最新的镜像版本有可能是不可用的,扩容进去的Pod可服务型存在危险。在存储编排方面,咱们继承了StatefulSet的Per Pod Per PV的个性,同时也反对Per Workload Per PV的个性,即单个StatefulSetPlus上面所有的Pod共享一个PV,也就是相似Deployment共享PV的模式。在StatefulSet外面,当节点出现异常,比方呈现了NodeLost的状况下,出于有状态服务的可用性思考,不会进行Pod重建。在StatefulSetPlus中,监听到NodeLost后,对应的Pod会主动漂移。这还不够,咱们会通过NPD检测,上报事件或Patch Condition疾速发现节点异样,对StatefulSetPlus Pod进行原地重建或者漂移等决策。StatefulSetPlus还有一个十分重要的个性,就是它反对ConfigMap的版本治理以及ConfigMap的分批灰度公布,这是决定ConfigMap是否大规模在生产中应用的要害能力。这里特地介绍一下,如何反对Pod降级过程中放弃共享内存数据不失落,并且在降级过程中,单个Pod只有毫秒级的服务抖动。次要的实现原理就是在Pod外面,通过一个占位容器和业务容器进行文件锁的抢占动作,来实现降级过程中两个容器的角色进行疾速切换。 动静的资源调度和治理kubernetes的调度原生是应用动态调度的形式,在生产环境会呈现集群外面各个节点的负载不平衡的状况,并且造成很大的资源节约。 动静调度器是咱们自研的一个调度器扩展器,次要工作是均衡集群中各个节点实在的负载,在调度的时候,将各个节点的实在负载纳入考量的领域。 动静调度器必须要解决的一个技术点是调度热点的问题。当集群中有一批节点负载比拟低,这时用户创立大量的Pod,这些Pod会集中调度到这些低负载的节点下面,这将导致这些低负载节点在几分钟之后又会成为高负载节点,从而影响这批节点上Pod的服务质量,这种景象尤其在集群扩容后很容易呈现。咱们自研的调度热点躲避算法,极大的防止了某个节点因为低负载被动静调度器调度后成为提早性的高负载热点,极少数高负载节点在de-scheduler中会基于Node CPU的历史监控进行节点降热操作。。 咱们心愿可能疾速地感知集群的异常情况,包含kubelet异样、docker异样、内核死锁以及节点是否呈现文件描述符行将耗尽的状况,从而能在第一工夫去做决策,防止问题的好转。其中疾速发现这个动作是由Node Problem Detector(NPD)组件负责的,NPD组件是基于社区的NPD进行了大量的策略扩大。 NPD检测到异样后,除了NPD组件自身对节点自愈的动作之外,de-scheduler还会基于异样事件和以后集群/Workload现状帮助进行动作决策,比方Pod驱赶、Container原地重启。这里要重点提一下,咱们基于Self算法的分布式的Ping检测,可能疾速发现节点的网络异常情况,由de-scheduler对网络异样节点上的Pods进行漂移。 在腾讯外部,产品的治理是分多个层级的,因而在配额治理方面,咱们没有应用Kubernetes原生的ResourceQuota机制,而是研发了DynamicQuota CRD来实现多层级的、动静的面向业务的Quota治理。 比方从业务维度,腾讯会议是一个产品、腾讯课堂是一个产品,每个产品上面都会有多级业务模块,在做资源布局和配额治理的时候,是基于产品维度的。在理论部署的时候,实际上Workload绑定到对应的CMDB的最初一级模块。所以,这里须要主动的将产品配额下发到CMDB多级模块的机制,通过DynamicQuota不只是做资源应用下限的管制,更重要的是保障这个业务有这么多配额能够用,避免被其余业务抢占了。 当然这里还有一些关键问题,比方为了防止资源节约,咱们须要把一些产品的闲暇资源借调给其余曾经超过配额管制然而须要持续应用更多资源的业务,这样配额就有了灵便的弹性。 同时咱们也利用了DynamicQuota管制在线业务和离线业务占用资源的比例,次要是为了保障在线业务始终会有肯定的配额能够应用,避免离线业务无限度强占整个平台的资源,同时也能更好的管制集群负载。 大规模和高性能的弹性伸缩在扩缩容方面,这里次要介绍纵向扩缩容和横向扩缩容做的工作。社区的VPA不太适宜很多腾讯的自研业务,因为扩缩容都是基于Pod的重建机制,在扩容成果和对业务的感知方面,都不是很好。 咱们自研了Vertical Workload AutoScaler (VWA) CRD用于Pod的垂直扩缩容,次要解决的问题是: 当业务呈现突发流量的时候,HPA扩容不及时,导致上面Pod的资源利用率暴涨,进而引发业务的雪崩。VWA有更快的响应速度,并且不须要重建Pod,因而比HPA更快更平安。业务在应用容器规格的时候,常常把容器规格配置得比拟高,Pod资源使用率会比拟低,通过VWA主动进行降配,优化资源利用率。当节点呈现高负载的状况下,这个节点下面跑着在线和离线业务,咱们会通过VWA疾速地对离线业务容器进行在线降配,从而保障在线业务的服务质量。这外面外围的个性,包含提供原地降级容器规格的能力,而不须要重建Container,性能上做了优化,单集群能反对上千个VWA对象的扩缩容。同时也反对VWA的个性化配置,比方能够配置每一个VWA对象的循环同步周期,每次扩容的最大比例以及缩容的最大比例等。 最初再介绍一下在HPA方面咱们做的工作。Kubernetes原生的HPA Controller是内置在kube-controller-manager外面的,它存在着以下缺点: 它不能独立部署,如果集群中有成千上万的HPA对象,原生HPA Controller是很难接受的,稳定性也间接受限于kube-controller-manager。另外在性能方面,原生HPA Controller在一个协程外面遍历所有HPA对象,所以在大规模HPA场景下,同步实时性得不到保障。咱们自研了一个HPAPlus Controller,它兼容了原生的HPA对象,而后能够独立部署,在性能方面相似VWA一样做了很多性能优化,同时丰盛了每个HPA对象可自定义的配置,比方同步周期、扩容比例、容忍度等。 HPAPlus-Controller还实现了与CronHPA和VWA进行联动决策,比方当VWA继续扩缩容达到了所属节点的下限,无奈持续扩容的时候,这个时候会主动托管给HPA触发横向扩容。 总结腾讯自研业务海量规模,除了文中介绍到弹性伸缩、调度和资源管理、灰度公布等方面面临的挑战外,咱们还在多集群治理、在离线混部、ServiceMesh、异构计算、AI/大数据框架反对等多方面做了大量工作。另外,TKEx底层正在大量应用EKS弹性容器服务来提供更好的容器资源隔离能力、弹性能力,以实现真正的零集群运维老本和高资源利用率的指标。 【腾讯云原生】云说新品、云研新术、云游新活、云赏资讯,扫码关注同名公众号,及时获取更多干货!!

September 15, 2020 · 1 min · jiezi

关于腾讯云:三年之久的-etcd3-数据不一致-bug-分析

问题背景诡异的 K8S 滚动更新异样笔者某天收到共事反馈,测试环境中 K8S 集群进行滚动更新公布时未失效。通过 kube-apiserver 查看发现,对应的 Deployment 版本曾经是最新版,然而这个最新版本的 Pod 并未创立进去。 针对该景象,咱们最开始猜想可能是 kube-controller-manager 的 bug 导致,然而察看 controller-manager 日志并未发现显著异样。第一次调高 controller-manager 的日志等级并进行重启操作之后,仿佛因为 controller-manager 并没有 watch 到这个更新事件,咱们依然没有发现问题所在。此时,察看 kube-apiserver 日志,同样也没有呈现显著异样。 于是,再次调高日志等级并重启 kube-apiserver,诡异的事件产生了,之前的 Deployment 失常滚动更新了! etcd 数据不统一 ?因为从 kube-apiserver 的日志中同样无奈提取出可能帮忙解决问题的有用信息,起初咱们只能猜想可能是 kube-apiserver 的缓存更新异样导致的。正当咱们要从这个切入点去解决问题时,该共事反馈了一个更诡异的问题——本人新创建的 Pod,通过 kubectl查问 Pod 列表,忽然隐没了!纳尼?这是什么骚操作?通过咱们屡次测试查问发现,通过 kubectl 来 list pod 列表,该 pod 有时候能查到,有时候查不到。那么问题来了,K8s api 的 list 操作是没有缓存的,数据是 kube-apiserver 间接从 etcd 拉取返回给客户端的,难道是 etcd 自身出了问题? 家喻户晓,etcd 自身是一个强一致性的 KV 存储,在写操作胜利的状况下,两次读申请不应该读取到不一样的数据。怀着不信邪的态度,咱们通过 etcdctl 间接查问了 etcd 集群状态和集群数据,返回结果显示 3 个节点状态都失常,且 RaftIndex 统一,察看 etcd 的日志也并未发现报错信息,惟一可疑的中央是 3 个节点的 dbsize 差异较大。接着,咱们又将 client 拜访的 endpoint 指定为不同节点地址来查问每个节点的 key 的数量,后果发现 3 个节点返回的 key 的数量不统一,甚至两个不同节点上 Key 的数量差最大可达到几千!而间接通过 etcdctl 查问方才创立的 Pod,发现拜访某些 endpoint 可能查问到该 pod,而拜访其余 endpoint 则查不到。至此,根本能够确定 etcd 集群的节点之间的确存在数据不统一景象。 ...

September 15, 2020 · 5 min · jiezi

关于腾讯云:istio-常见的-10-个异常

总结应用 istio 常见的10个异样: Service 端口命名束缚流控规定下发程序问题申请中断剖析sidecar 和 user container 启动程序Ingress Gateway 和 Service 端口联动VirtualService 作用域VirtualService 不反对 host fragment全链路跟踪并非齐全通明接入mTLS 导致连贯中断用户服务监听地址限度1. Service 端口命名束缚istio 反对多平台,不过 Istio 和 k8s 的兼容性是最优的,不论是设计理念,外围团队还是社区, 都有一脉相承的意思。但 istio 和 k8s 的适配并非齐全没有抵触, 一个典型问题就是 istio 须要 k8s service 依照协定进行端口命名(port naming)。 端口命名不满足束缚而导致的流量异样,是应用 mesh 过程中最常见的问题,其景象是协定相干的流控规定不失效,这通常能够通过查看该 port LDS 中 filter 的类型来定位。 起因k8s 的网络对应用层是无感知的,k8s 的次要流量转发逻辑产生在 node 上,由 iptables/ipvs 来实现,这些规定并不关怀应用层里是什么协定。 istio 的外围能力是对 7层流量进行管控,但前提条件是 istio 必须晓得每个受管控的服务是什么协定,istio 会依据端口协定的不同,下发不同的流控性能(envoy filter),而 k8s 资源定义里并不包含七层协定信息,所以 istio 须要用户显式提供。 istio 的解决方案:Protocol sniffing协定嗅探概要: ...

September 15, 2020 · 4 min · jiezi

关于腾讯云:Apache-Flink-on-K8s四种运行模式我该选择哪种

1. 前言Apache Flink 是一个分布式流解决引擎,它提供了丰盛且易用的API来解决有状态的流解决利用,并且在反对容错的前提下,高效、大规模的运行此类利用。通过反对事件工夫(event-time)、计算状态(state)以及恰好一次(exactly-once)的容错保障,Flink迅速被很多公司驳回,成为了新一代的流计算解决引擎。 2020 年 2 月 11 日,社区公布了 Flink 1.10.0 版本, 该版本对性能和稳定性做了很大的晋升,同时引入了 native Kubernetes 的个性。对于 Flink 的下一个稳固版本,社区在 2020 年 4 月底解冻新个性的合入,预计在 2020 年 5 月中旬会推出 Flink 1.11,在新版本中将重点引入新个性,以扩容 Flink 的应用场景。 1.1 Flink 为什么抉择 KubernetesKubernetes 我的项目源自 Google 外部 Borg 我的项目,基于 Borg 多年来的优良实际和其超前的设计理念,并凭借泛滥寒门、大厂的背书,时至今日,Kubernetes 曾经成长为容器治理畛域的事实标准。在大数据及相干畛域,包含 Spark,Hive,Airflow,Kafka 等泛滥出名产品正在迁往 Kubernetes,Apache Flink 也是其中一员。 Flink 抉择 Kubernetes 作为其底层资源管理平台,起因包含两个方面: 1)Flink 个性:流式服务个别是常驻过程,常常用于电信网品质监控、商业数据即席剖析、实时风控和实时举荐等对稳定性要求比拟高的场景; 2)Kubernetes 劣势:为在线业务提供了更好的公布、管理机制,并保障其稳固运行,同时 Kubernetes 具备很好的生态劣势,能很不便的和各种运维工具集成,如 prometheus 监控,支流的日志采集工具等;同时 K8S 在资源弹性方面提供了很好的扩缩容机制,很大水平上进步了资源利用率。 1.2 Flink on Kubernetes 的倒退历史在 Flink 的晚期发行版 1.2 中,曾经引入了 Flink Session 集群模式,用户得以将 Flink 集群部署在 Kubernetes 集群之上。 ...

September 15, 2020 · 4 min · jiezi

关于腾讯云:TKE-集群组建最佳实践

Kubernetes 版本Kubernetes 版本迭代比拟快,新版本通常蕴含许多 bug 修复和新性能,旧版本逐步淘汰,倡议创立集群时抉择以后 TKE 反对的最新版本,后续出新版本后也是能够反对 Master 和节点的版本升级的。 网络模式: GlobalRouter vs VPC-CNIGlobalRouter 模式架构: 基于 CNI 和 网桥实现的容器网络能力,容器路由间接通过 VPC 底层实现;容器与节点在同一网络立体,但网段不与 VPC 网段重叠,容器网段地址富余。VPC-CNI 模式架构: 基于 CNI 和 VPC 弹性网卡实现的容器网络能力,容器路由通过弹性网卡,性能相比 Global Router 约进步 10%;容器与节点在同一网络立体,网段在 VPC 网段内;反对 Pod 固定 IP。网络模式比照: 反对三种应用形式: 创立集群时指定 GlobalRouter 模式;创立集群时指定 VPC-CNI 模式,后续所有 Pod 都必须应用 VPC-CNI 模式创立;创立集群时指定 GlobalRouter 模式,在须要应用 VPC-CNI 模式时为集群启用 VPC-CNI 的反对,即两种模式混用。选型倡议: 绝大多数状况下应该抉择 GlobalRouter,容器网段地址富余,扩展性强,能适应规模较大的业务;如果前期局部业务须要用到 VPC-CNI 模式,能够在 GlobalRouter 集群再开启 VPC-CNI 反对,也就是 GlobalRouter 与 VPC-CNI 混用,仅对局部业务应用 VPC-CNI 模式;如果齐全理解并承受 VPC-CNI 的各种限度,并且须要集群内所有 Pod 都用 VPC-CNI 模式,能够创立集群时抉择 VPC-CNI 网络插件。参考官网文档 《如何抉择容器服务网络模式》: https://cloud.tencent.com/doc... ...

September 14, 2020 · 2 min · jiezi

关于腾讯云:Registry-容器镜像服务端细节

引言通常咱们在应用集群或者容器的时候,都会接触到存储在本地的镜像,也或多或少对本地镜像存储有肯定的理解。然而服务端的镜像存储细节呢?本文次要介绍容器镜像的服务端存储构造,对于自建镜像服务或是对容器镜像底层原理或优化有趣味的同学能够理解一下。 相干开源我的项目目前容器镜像服务相干的开源我的项目次要有以下两个。 Registry (https://github.com/docker/dis...Harbor (https://github.com/goharbor/h...Registry具备根本的镜像上传、下载以及对接第三方鉴权的能力。Harbor则基于Registry做了相应的企业级扩大的我的项目。提供了更多权限、审计、镜像等性能,目前是CNCF孵化我的项目之一。其余详情参考相干文章。这篇文章次要解说Registry我的项目的存储细节。 镜像细节在理解服务端之前,咱们来理解一下客户端的镜像容器的存储环境。 联结文件系统 UnionFS(Union File System)Docker的存储驱动的实现是基于UnionFS。简略列举一下UnionFS下存储镜像的一些特点。 首先,UnionFS是一个分层的文件系统。一个Docker镜像可能有多个层组成(留神他们是有程序的)。 其次,只有顶层是可写的,其它层都是只读的。这样的机制带来的益处是镜像层能够被多个镜像共享。对于Docker镜像来说,所有层都是只读的。当一个镜像运行时,会在该镜像上减少一个容器层。十个雷同的镜像启动,仅仅是减少十个容器层。销毁容器时也仅仅是销毁一个容器层而已。 UnionFS是一个分层的文件系统。一个Docker镜像可能有多个层组成(留神他们是有程序的)。只有顶层是可写的,其它层都是只读的。这样的机制带来的益处是镜像层能够被多个镜像共享。对于Docker镜像来说,所有层都是只读的。当一个镜像运行时,会在该镜像上减少一个容器层。十个雷同的镜像启动,仅仅是减少十个容器层。销毁容器时也仅仅是销毁一个容器层而已。当容器须要读取文件的时候:从最上层镜像开始查找,往下找,找到文件后读取并放入内存,若曾经在内存中了,间接应用。(即,同一台机器上运行的docker容器共享运行时雷同的文件)。当容器须要增加文件的时候:间接在最下面的容器层可写层增加文件,不会影响镜像层。当容器须要批改文件的时候:从上往上层寻找文件,找到后,复制到容器可写层,而后,对容器来说,能够看到的是容器层的这个文件,看不到镜像层里的文件。容器在容器层批改这个文件。当容器须要删除文件的时候:从上往上层寻找文件,找到后在容器中记录删除。即,并不会真正的删除文件,而是软删除。这将导致镜像体积只会减少,不会缩小。由此能够思考很多平安和镜像优化上的问题。 在镜像构建中记录敏感信息而后再下一个构建指令中删除平安吗?(不平安)在镜像构建中装置软件包而后再下一个构建指令中清理软件包能减小镜像体积吗?(并不能)UnionFS个别有两种实现计划:1. 基于文件实现。文件整体的笼罩重写。2. 基于块实现,对文件的批改只批改大量块。 镜像的服务端存储细节提供一个镜像元信息(manifest)用于参考: ➜ ~ docker pull ccr.ccs.tencentyun.com/paas/service-controller:7b1c981c7b1c981c: Pulling from paas/service-controllerDigest: sha256:e8b84ce6c245f04e6e453532d676f7c7f0a94b3122f93a89a58f9ae49939e419Status: Image is up to date for ccr.ccs.tencentyun.com/paas/service-controller:7b1c981cccr.ccs.tencentyun.com/paas/service-controller:7b1c981c{ "schemaVersion": 2, "mediaType": "application/vnd.docker.distribution.manifest.v2+json", "config": { "mediaType": "application/vnd.docker.container.image.v1+json", "size": 4671, "digest": "sha256:785f4150a5d9f62562f462fa2d8b8764df4215f0f2e3a3716c867aa31887f827" }, "layers": [ { "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip", "size": 44144090, "digest": "sha256:e80174c8b43b97abb6bf8901cc5dade4897f16eb53b12674bef1eae6ae847451" }, { "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip", "size": 529, "digest": "sha256:d1072db285cc5eb2f3415891381631501b3ad9b1a10da20ca2e932d7d8799988" }, { "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip", "size": 849, "digest": "sha256:858453671e6769806e0374869acce1d9e5d97f5020f86139e0862c7ada6da621" }, { "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip", "size": 170, "digest": "sha256:3d07b1124f982f6c5da7f1b85a0a12f9574d6ce7e8a84160cda939e5b3a1faad" }, { "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip", "size": 8461461, "digest": "sha256:994dade28a14b2eac1450db7fa2ba53998164ed271b1e4b0503b1f89de44380c" }, { "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip", "size": 22178452, "digest": "sha256:60a5bd5c14d0f37da92d2a5e94d6bbfc1e2a942d675aee24f055ced76e8a208f" }, { "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip", "size": 22178452, "digest": "sha256:60a5bd5c14d0f37da92d2a5e94d6bbfc1e2a942d675aee24f055ced76e8a208f" } ]} ...

September 14, 2020 · 1 min · jiezi

关于腾讯云:从0到1学习边缘容器系列3应用容灾之边缘自治

导语:边缘计算模式下,云端的控制中心和边缘端的设施之间网络环境较简单,网络品质差次不齐没有保障。用户往往心愿在弱网环境下,边缘容器能提供高可用的业务能力。TKE 边缘容器团队在弱网环境下提出了边缘自治性能。本文着重介绍了边缘容器在弱网环境下为了保障业务高可用而做的工作。 问题背景边缘计算应用的边缘设施数量宏大、散布全国各地,网络环境简单,因特网、以太网、5G、WIFI 等状态均有可能。因而,云端的控制中心和边缘端的设施之间网络环境较简单,网络品质差次不齐没有保障。 kubernetes 传统工作模式是所有组件 list-watch kube-apiserver,而后 reconcile 各种资源到冀望状态。各节点的衰弱都强依赖于其与 kube-apiserver 通信的稳固。kubernetes 在传统的集群环境上工作很完满,因为大多数集群都能保障在一个局域网内。然而,在边缘计算的业务场景下,有一个稳固的网络环境着实是一件侈靡的事件。 在这样的背景下,如何保障边缘集群的业务高可用性以及服务高可用性?始终都是一个难题。为此咱们腾讯云边缘容器团队(TKE@EDGE)设计了两个利器来专门啃下这块硬骨头,本篇将重点讲第一个利器——边缘自治。 (注:此文提到的网络环境,都是指节点与云端的网络环境,而不是业务运行所在环境。) 需要举例咱们来以一个常见的厂房模型来介绍一下用户在弱网环境下应用传统 kubernetes 遇到的问题以及 TKE 边缘容器团队在此类场景下提出的解决方案。 如上图所示,该案例采纳的部署模式为:用户在腾讯云私有云上购买了几台 CVM 机器作为 master 节点,其上部署了 kube-apiserver、kube-controller-manager、kube-scheduler 三大组件。而后依据业务需要,为每一个厂房都创立多个边缘 worker 节点,部署 kubelet 和 kube-proxy 以及 dockerd。同厂房节点之间能够相互拜访, 不同厂房节点网络不互通。比方两个散布在北京和广州的厂房的边缘节点尽管能够归属于同一个集群,然而它们之间的网络是不互通的。每个厂房内所有节点会通过公网连贯至云端管控端,然而这个网络通道都属于不牢靠的弱网环境。 厂房A在北京地区,厂房B在广州地区。二者之间是不能互通的。 用户通过 kubernetes 治理平台进行workload的治理,master 与 worker 节点所在的厂房之间的网络环境网络环境是不能保障的,可能弱网A断网,网络B依然失常。用户在这样的场景下,提出了几个需要: 节点即便和 master 失联,节点上的业务能持续运行保障如果业务容器异样退出或者挂掉,kubelet 能持续拉起保障节点重启后,业务能持续从新被拉起来用户在厂房内部署的是微服务,须要保障节点重启后,同一个厂房内的微服务能够拜访对于用户来说,这些诉求是他们的根本需要,也是其业务上云的关键因素。用户想要既享受 kubernetes 带来不便的治理运维,同时也要具备弱网环境下的容灾能力。这对传统规范 kubernentes 解决方案提出了挑战。 规范kubernetes解决形式咱们来复习一下规范的 kubernentes 下,如果节点断网失联并且产生异样重启的行为后,会呈现哪些景象呢? 失联的节点状态置为 NotReady 或者 Unknown 状态失联的节点上的业务进场异样退出后,容器能够被拉起失联的节点上的 Pod IP 从 Endpoint 列表中摘除失联的节点产生点重启后,容器全副隐没不会被拉起咱们顺次来看,首先,在传统的模式下,节点是否衰弱取决于节点上 kubelet 组件的心跳或者续租。如果网络断了,云端组件当然会认为节点是不可用状态。这个状态能够提醒用户,该节点可能有异样,须要运维染指。同时,因为 kubelet 还在接管所有本机 Pod,即便业务容器异样退出,容器也是能够持续被拉起的。失联的节点上所有的 Pod ,它们的 IP 都会被从 Endpoint list 中摘除,导致微服务不能拜访到这个节点,在传统 kubernentes 集群中,这是一个高可用的措施。然而在边缘集群内,这个“节点不可用=服务不可用”等式是否还成立呢?这个中央是须要探讨的,其实很多业务场景下,用户心愿节点即便和云端断网,该节点上的 Pod 也要能持续对外提供服务。 ...

September 14, 2020 · 2 min · jiezi

关于腾讯云:从0到1学习边缘容器系列2之-边缘应用管理

边缘容器作为以后热门的钻研方向,腾讯云容器团队在手不释卷做技术钻研的同时,也心愿能普惠到更多的云原生技术开发者们,为此推出【从0到1学习边缘容器系列】。上次咱们推出了第一篇《边缘计算与边缘容器的起源》,这次咱们和大家来聊聊边缘场景下的容器利用部署和治理。 大家对应用Kubernetes治理利用曾经比拟相熟,然而边缘场景下的利用部署和治理是否存在不同的需要呢?本文将和大家一起探讨边缘场景下常见的容器利用治理计划。 1. 边缘简略服务场景 在笔者接触过的边缘需要中局部用户业务场景比较简单,如:拨测服务。这种场景的特点是用户心愿在每个节点部署雷同的服务,并且每个节点起一个 pod 即可,这种场景个别举荐用户间接应用 daemonset 部署。对于 daemonset 的特点和应用形式读者能够浏览 kubernetes 官网文档。 2.边缘单站点部署微服务场景 第二种场景是部署边缘 SAAS 服务,因为波及客户商业秘密,此处暂不举例。用户会在一个边缘机房内部署一整套微服务,包含账号服务、接入服务、业务服务、存储及音讯队列,服务之间借助kubernetes的dns做服务注册和发现。这种状况下客户能够间接应用 deployment和service,其中最次要的艰难不在于服务治理而是边缘自治能力。 对于deployment和service的应用形式读者能够浏览kubernetes 官网文档,对于TKE@edge 边缘自治能力咱们将会在后续推出相干文章介绍。 3.边缘多站点部署微服务场景 场景特点边缘计算场景中,往往会在同一个集群中治理多个边缘站点,每个边缘站点内有一个或多个计算节点。心愿在每个站点中都运行一组有业务逻辑联系的服务,每个站点内的服务是一套残缺的微服务,能够为用户提供服务因为受到网络限度,有业务联系的服务之间不心愿或者不能跨站点拜访惯例计划1.将服务限度在一个节点内 该计划的特点: 服务以daemonset形式部署,以便每个边缘节点上均有所有服务的 pod。如上图所示,集群内有A、B两个服务,以daemonset部署后每个边缘节点上均有一个 Pod-A和Pod-B 服务通过localhost拜访,以便将调用链锁定在同一个节点内。如上图所示,Pod-A和Pod-B之间以localhost拜访 该计划的毛病: 每个服务在同一个节点内只能有一个 Pod,这是因为daemonset工作机制所限,对于须要在同一节点上运行多个 Pod的服务来说这个限度极为不便。 Pod须要应用 hostnetWork模式,以便Pod之间能够通过localhost+port拜访。这意味着须要用户很好地治理服务对资源应用,避免出现资源竞争,如端口竞争。 2.服务在不同站点叫不同的名字 该计划的特点: 雷同服务在不同站点叫不同的名字,以便将服务间的拜访锁定在同一个站点内。如上图所示,集群内有A、B两个服务,在site-1中别离命名为 svr-A-1、Svc-B-1,在site-2中别离命名为 svr-A-2、Svc-B-2。该计划的毛病: 服务在不同站点名字不同,因此服务之间不能简略地通过服务名A和B来调用,而是在 site-1中用 Svc-A-1、Svc-B-1,在site-2中用 Svc-A-2、Svc-B-2。对于借助 k8s dns 实现微服务的业务极为不敌对。场景痛点1.k8s自身并不间接针对下述场景提供计划。 首先是泛滥地区部署问题:通常,一个边缘集群会治理许多个边缘站点(每个边缘站点内有一个或多个计算资源),核心云场景往往是一些大地区的核心机房,边缘地区绝对核心云场景地区更多,兴许一个小城市就有一个边缘机房,地区数量可能会十分多;在原生k8s中,pod的创立很难指定,除非应用节点亲和性针对每个地区进行部署,然而如果地区数量有十几个甚至几十个,以须要每个地区部署多个服务的deployment为例,须要各个deployment的名称和selector各不相同,几十个地区,意味着须要上百个对应的不同name,selector,pod labels以及亲和性的部署yaml,单单是编写这些yaml工作量就十分微小;services服务须要与地区关联,比方音视频服务中的转码和合成服务,要在所属地区内实现接入的音视频服务,用户心愿服务之间的互相调用能限度在本地区内,而不是跨地区拜访。这同样须要用户同样筹备上百个不同selector和name的本地区deployment专属的service的部署yaml;一个更简单的问题是,如果用户程序中服务之间的互相拜访应用了service名,那么以后环境下,因为service的名称各个地区都不雷同,对于用户而言,原来的利用甚至都无奈工作,须要针对每个地区独自适配,复杂度太高。2.另外,应用方为了让容器化的业务在调度计划上与之前运行在 vm或者物理机上的业务保持一致,他们很天然就想到为每个 pod 调配一个公网IP,然而公网IP数量显著是不够用的。 综上所述,原生k8s尽管能够变相满足需要1),然而理论计划非常复杂,对于需要2)则没有好的解决案。 为解决上述痛点,TKE@edge 开创性地提出和实现了 serviceGroup 个性,两个yaml文件即可轻松实现即便上百地区的服务部署,且无需利用适配或革新。 seviceGroup性能介绍serviceGroup能够便捷地在共属同一个集群的不同机房或区域中各自部署一组服务,并且使得各个服务间的申请在本机房或本地区外部即可实现,防止服务跨地区拜访。 原生 k8s 无法控制deployment的pod创立的具体节点地位,须要通过统筹规划节点的亲和性来间接实现,当边缘站点数量以及须要部署的服务数量过多时,治理和部署方面的极为简单,乃至仅存在实践上的可能性;与此同时,为了将服务间的互相调用限度在肯定范畴,业务方须要为各个deployment别离创立专属的service,治理方面的工作量微小且极容易出错并引起线上业务异样。 serviceGroup就是为这种场景设计的,客户只须要应用ServiceGroup提供的DeploymentGrid和ServiceGrid两种tkeedge自研的kubernetes 资源,即可不便地将服务别离部署到这些节点组中,并进行服务流量管控,另外,还能保障各区域服务数量及容灾。 serviceGroup要害概念1.整体架构 ...

September 14, 2020 · 1 min · jiezi

关于腾讯云:从0到1学习边缘容器系列1之-边缘计算与边缘容器的起源

对于云计算大家曾经耳熟能详了,边缘计算又是一种什么玩法以及存在哪些挑战呢? 笔者特地访问专家,整顿了系列文章,和大家从0到1来学习边缘计算的技术。 30秒理解什么是边缘计算?边缘计算为什么重要?依据边缘计算产业联盟的定义,边缘计算是在凑近物或数据源头的网络边缘侧,交融网络、计算、存储、利用外围能力的开放平台,就近提供边缘智能服务,满足行业在麻利联接、实时业务、数据优化、利用智能、平安与隐衷爱护等方面的要害需要。边缘计算将计算、网络、存储、带宽等能力从云延长到网络边缘的新型架构模式,其能效敌对、带宽短缺、提早低等个性很好地补充了集中化计算模式遇到的问题。 图片:边缘计算技术作为5G网络架构中外围,智能化革新趋势剖析 30秒看完边缘计算集中式的3大难题随着信息技术的倒退,计算资源模式由繁多的集中化变成了往集中化和边缘化两个方向的分化,集中化即以后热火朝天的云计算,边缘化即最近几年衰亡的边缘计算。云计算给世界带来的改革大家引人注目,但有了云计算为什么还须要边缘计算呢?这就须要一起来理解集中式的云计算中遇到的问题: • PUE 问题。PUE(Power Usage Effectiveness)电源应用效率,是评估数据中心能源效率的指标。集中式数据中心耗电量微小,属于高耗能产业,不合乎绿色能源、节能减排理念,其规模和数量受政策限度。依据 IDC 统计,寰球数据中心数量在 2015 年达到高峰,而后开始逐年降落,预计 2021 年会比 2015 年升高 15%。 数据起源:数据中心白皮书数据及预测、光大证券研究所 • 平安隐衷问题。利用和数据是企业的外围资源,随着越来越多的行业互联网化,如何保障利用和数据的可靠性、安全性是企业最关怀的议题之一。 • 技术新需要问题。随着技术的倒退,单靠数据中心曾经很难满足需要。 典型场景包含: 1)物联网技术,大量的智能终端位于网络边缘,集中计算模式不能满足所有利用场景; 2)挪动互联网技术的倒退,5G 为挪动互联网注入了微小的能量,集中计算模式满足不了直播、游戏、音视频等利用在带宽、提早等方面的需要。 30秒理解边缘计算倒退现状目前边缘计算钻研畛域次要集中在:计算模型、体系结构、信息安全等方面。 • 计算模型次要有:雾计算、挪动边缘计算、智能边缘计算等,涵盖物联网、无线通信网、挪动互联网等畛域。 • 体系结构有:ETSI 参考架构、MEC 架构、ECC 参考架构、SWoT 架构、AI-EC 架构。 目前边缘计算钻研热点次要是提早敏感、实时性要求高的场景,如: • 云基础设施 2.0。国内外各大云厂商逐步从 “核心云” 模式转换到 “云计算 + 边缘计算”模式,细化出多种行业云:金融云、游戏云、直播云、教育云等。 • 物联网。随着 IoT 规模的快速增长,越来越多的数据无奈间接上传到云核心,在设施侧实现数据存储、剖析、解决将越来越重要 • 工业互联网。工业互联网的实质和外围是把设施、生产线、工厂、供应商、产品和客户严密地连贯交融起来,从而提高效率,推动整个制作服务体系智能化。 • CDN。CDN 实质上是在凑近用户的地位散发内容,边缘计算能够让 CDN 离用户更近,提供更低时延、更大带宽的服务。 • 5G。国家标准组织 ETSI 认为挪动边缘计算 MEC 是一种将基站和互联网业务深度交融的技术,能够灵便地在物理网络切分出逻辑网络以满足复杂多变的利用需要。 ...

September 14, 2020 · 2 min · jiezi

关于腾讯云:容器服务-TKE-上服务暴露的几种方式

准备常识1. K8S 上 Service 类型ClusterIP通过集群的外部 IP 裸露服务,抉择该值,服务只可能在集群外部能够拜访,这也是默认的 ServiceType。 NodePort通过每个 Node 上的 IP 和动态端口(NodePort)裸露服务。 NodePort 服务会路由到 ClusterIP 服务,这个 ClusterIP 服务会主动创立。 通过申请 <NodeIP>:<NodePort>,能够从集群的内部拜访一个 NodePort 服务。 LoadBalancer应用云提供商的负载局衡器,能够向内部裸露服务。 内部的负载均衡器能够路由到 NodePort 服务和 ClusterIP 服务。 ExternalName通过返回 CNAME 和它的值,能够将服务映射到 externalName 字段的内容(例如, foo.bar.example.com)。 没有任何类型代理被创立。本文暂不探讨这种类型。 参考文档:https://cloud.tencent.com/document/product/457/45487 平台相干基础知识腾讯云容器服务(Tencent Kubernetes Engine ,TKE)基于原生 Kubernetes 提供以容器为外围的、高度可扩大的高性能容器治理服务,齐全兼容原生 Kubernetes API ,同时扩大了腾讯云的云硬盘、负载平衡等 kubernetes 插件,为容器化的利用提供高效部署、资源调度、服务发现和动静伸缩等一系列残缺性能,解决用户开发、测试及运维过程的环境一致性问题,进步了大规模容器集群治理的便捷性,帮忙用户降低成本,提高效率。 2. TKE 上四层网络流量裸露形式TKE 上默认应用 service-controller 来治理 CLB 上四层监听器和规定。这种形式, CLB 后端绑定每个节点的 NodePort,CLB 接管外界流量,转发到其中一个节点的 NodePort 上,再通过 Kubernetes 外部的负载平衡,应用 iptables 或 ipvs 转发到 Pod。 ...

September 11, 2020 · 2 min · jiezi

关于腾讯云:车联网容器应用探索5G下边缘云计算的车路协同实践

导语 | 5G网络下,多接入边缘计算(MEC)应运而生。联合TKEStack弱小的集群治理能力和异构计算资源管理能力,腾讯打造了一个性能齐备的边缘计算PaaS平台TMEC,提供了高精确度定位、视频解决、无线网络QoS管制和5G切片等多种特色业务能力,很好地撑持了车路协同、5G云游戏、视频直播等利用。本文是腾讯云技术专家杨勇&何猛老师在「云加社区沙龙online」的分享整顿,心愿与大家一起交换。 一、5G典型利用场景及其挑战1. 从主动驾驶说起主动驾驶在国内是十分热的话题,业界的规范分成了不同的等级,有的分成了5级、有的分成了6级。 如上图所示,国家工信部相干标准将主动驾驶等级规范定义为6级。目前国内的厂家和国内的一些厂家,绝大部分处于处于L2或者L3的程度。腾讯也有主动驾驶相干的产品,目前有数百人的团队从事主动驾驶等相干产品和技术的研发工作。 从实际落地的角度看,主动驾驶汽车商用的成熟性目前来看并不高,这两头存在很多问题,其中技术、老本和平安是妨碍主动驾驶产品规模商用的次要因素。 2. 主动驾驶技术和挑战典型的主动驾驶车辆波及到硬件和相干软件的系统性挑战。次要包含以下四个方面: 第一是高精地图,其中包含厘米级精度、丰盛的路标数据和三维重建能力。 第二是多传感器,其中包含摄像头、激光雷达、毫米波雷达、超声传感器、惯导和卫星天线等。 第三是环境建模及智能决策,其中包含多传感器交融感知、路线和区域辨认、环境模型构建、智能预测和决策等。 第四是车身管制,其中包含车辆自动控制、驾驶策略执行及布局。 总体来看,在目前的程度之下,整个主动驾驶车辆因为要装置多种传感器、工控机及零碎控制软件,老本比拟昂扬,而且激光雷达等传感器的使用寿命也比拟无限。业内人士已经估算过,主动驾驶车辆的老本不会低于20万美元,这极大妨碍了主动驾驶汽车产品大规模商用落地。 3. 三大重点因素即便主动驾驶车辆装备了这么多的业余传感器和其它业余设施,在一些异常情况下还是不能很好的解决理论路况上呈现的一些平安问题,包含特斯拉在内的主动驾驶汽车曾呈现屡次交通事故,导致财产损失和人员伤亡。 比方,在超视距的状况下,车载传感器包含雷达或者摄像头检测不到转弯后方的车辆,或者从街角对面驶过来一个车辆,就很容易产生交通事故。 方才也提到了从老本的角度来讲,主动驾驶车辆的老本是十分昂扬的。 另外从出行效率角度来讲,作为交通管理部门或城市市政管理部门,晋升交通出行效率是他们次要工作指标之一。但主动驾驶车辆在路线上行驶的时候,思考平安因素,会相应采取一些比拟激进的策略。 比如说它的行车速度可能会比拟低,同时在产生异样事变的时候,它会加速或者停车避让,这就使得整个交通的效率并不能失去无效的晋升。 4. 车联网的技术实现C-V2X综合以上因素业界提出了 C-V2X 这个概念,这外面的 C 是蜂窝网络的意思, V2X 的全称是 vehicle to everything,就是说,基于蜂窝通信的 V2X 技术,使得车辆和路线所有参与方都能进行实时的数据交换,通过这种信息替换,来进一步晋升包含车辆和其它参与方的安全性,同时晋升出行效率。 咱们看到 V2X 次要包含四种场景: 第一个是 V2V(车辆对车辆),它次要解决一些车辆之间的可能产生的一些异样情况,比如说车辆碰撞事件; 第二个是 V2I,就是车辆和路边基础设施,比方红绿灯等,通过车辆和红绿灯的数据交换来及时揭示车辆加速或者放弃肯定车速,疏导车辆通过绿波带,既能晋升行车平安,也能够晋升车辆出行效率。 第三个 V2N,通过和通信网络的交互来为驾乘人员提供一些个性化信息服务。 第四个 V2P,通过和行人之间的数据交换,来为行人或非机动车收回一些平安揭示。 C-V2X 的指标总体上涵盖信息服务、交通安全、交通效率和辅助主动驾驶,它的指标之一就是把单车解决不了的问题移到路端去解决,通过路侧设施和车辆之间的 C-V2X音讯交互来进一步辅助主动驾驶,晋升交通安全能力,晋升路线出行效率,造成“聪慧的车”和“聪慧的路”。 5. 单车智能到云端智能那么依照“聪慧的车”到“聪慧的路”的想法,咱们是不是能够将齐全依附主动驾驶车辆自身所具备的智能决策能力给它迁徙到云端下来实现?这样还能够大幅升高车辆的购买老本,而且因为云端有高性能、可扩大的计算能力,能够做很多车端胜任不了的计算工作。 另外咱们晓得,当初主动驾驶汽车在车端要做大量的基于计算机视觉或者雷达数据的路况实时剖析,这种高性能计算在车辆计算单元上的解决,其准确性等方面还有待晋升,如果能移到云端去做,准确性可能会进步很多,而且云端还能够做很多简单的算术和逻辑运算。 然而这里有一个问题,即云端计算存在的时延问题。主动驾驶智能决策的时延要求十分高,如果移到云端去计算,整个数据链路拉长势必造成时延的减少,这就可能给主动驾驶业务带来重大的影响。例如车辆在高速公路上以120公里/小时的速度行驶,每秒钟就能行驶 30 多米,时延增大就可能会引发重大的交通事故。 所以移到云端是个不错的想法,但它又带来了时延方面的负面因素,这种状况就为边缘计算的部署提供了一个契机。也就是,把云端那些计算工作移到路侧的边缘计算平台上来进行,通过在路侧的基础设施上部署边缘计算平台和车联网的利用,从而对车辆进行实时的智能揭示和决策。 在凑近网络接入的路侧基础设施上进行边缘计算,它的益处是非常明显的。第一,计算能力大幅晋升,有利于准确度的晋升;第二,不须要占用过多的核心网或者骨干网络带宽;第三,能够无效升高时延,在网络的边缘侧只有通过基站就能够间接将音讯分发给路上的终端,数据传输门路比互联网到无线核心网再到无线接入网的门路短了很多,这就是边缘计算在车联网中利用的背景。 二、多接入边缘计算平台及其关键技术1. MEC在5G网络中的地位边缘计算在车联网外面会施展着重要作用,目前咱们看到各地对于 C-V2X 的新基建建设项目,重点的内容就是 C-V2X利用 和 MEC 服务的建设和部署。 ...

September 11, 2020 · 2 min · jiezi

关于腾讯云:TKE基于弹性网卡直连Pod的网络负载均衡

前言Kubernetes在集群接入层设计并提供了两种原生资源Service和Ingress,别离负责四层和七层的网络接入层配置。 传统的做法是创立Ingress或LoadBalancer类型的Service来绑定腾讯云的负载平衡将服务对外裸露。这种做法将用户流量负载到用户节点的NodePort上,通过KubeProxy组件转发到容器网络中,但这种计划在业务的性能和能力反对会有所局限。 为了解决这个问题,TKE容器团队为在腾讯云上应用独立或托管集群的用户提供了一种新的网络模式,利用弹性网卡直连Pod的计划很大的加强了性能和业务能力的反对。 本文将会从传统的模式的问题动手,比拟新旧模式的区别,并在最初提供新直连模式的应用指引。 传统模式面临的问题与挑战性能与个性KubeProxy在集群中会将用户NodePort的流量通过NAT的形式转发到集群网络中。这个NAT转发带来了以下一些问题。 NAT转发导致申请在性能上有肯定的损失。进行NAT操作自身会带来性能上的损失。NAT转发的目标地址可能会使得流量在容器网络内跨节点转发。NAT转发导致申请的起源IP被批改了,客户端无奈获取起源IP。当负载平衡的流量集中到几个NodePort时。过于集中的流量会导致NodePort的SNAT转发过多,使得源端口耗尽流量异样。还可能导致 conntrack 插入抵触导致丢包,影响性能。KubeProxy的转发具备随机性,无奈反对会话放弃。KubeProxy的每个NodePort其实也起到独立的负载平衡作用,因为负载平衡无奈收敛到一个中央,所以难以达到全局的负载平衡。为了解决以上问题,咱们以前给用户提供的技术倡议次要是通过Local转发的形式,防止KubeProxyNAT转发带来的问题。然而因为转发的随机性,一个节点上部署多个正本时会话放弃仍旧无奈反对。而且Local转发在滚动更新时,容易呈现服务的闪断,对业务的滚动更新策略以及优雅停机提出了更高的要求。咱们有理由去寻找更好的计划解决这个问题。 业务可用性通过NodePort接入服务时,NodePort的设计存在极大的容错性。负载平衡会绑定集群所有节点的NodePort作为后端。集群任意一个节点的拜访服务时,流量将随机调配到集群的工作负载中。这就意味着局部NodePort的不可用,或者是Pod的不可用都不会影响服务的流量接入。 和Local拜访一样,间接将负载平衡后端连贯到用户Pod的状况下,当业务在滚动更新时,如果负载平衡不可能及时绑定上新的Pod,业务的疾速滚动可能导致业务入口的负载平衡后端数量严重不足甚至被清空。因而,业务滚动更新的时候,接入层的负载平衡的状态良好,方能保障滚动更新的平安安稳。 负载平衡的管制面性能负载平衡的管制面接口。包含创立删除批改四层、七层监听器,创立删除七层规定,绑定各个监听器或者规定的后端。这些接口大部分是异步接口,须要轮询申请后果,接口的调用工夫绝对较长。当用户集群规模较大时,大量的接入层资源同步会导致组件存在很大的时延上的压力。 新旧模式比照性能比照Pod直连模式曾经在腾讯TKE上线,是对负载平衡的管制面优化。针对整个同步流程,重点优化了批量调用和后端实例查问两个近程调用比拟频繁的中央。优化实现后,Ingress典型场景下的管制面性能较优化前版本有了95%-97%左右的性能晋升。目前同步的耗时次要集中在异步接口的期待上。 后端节点突增 (应答集群扩容的场景) 七层规定突增(应答业务第一次上线部署到集群的场景) 除去管制面性能优化这样的硬核优化,负载平衡可能间接拜访容器网络的Pod就是组件业务能力最重要的组成部分了,其不仅防止了NAT转发性能上的损失,同时防止了NAT转发带来的各种对集群内业务性能影响。然而在启动该我的项目时这一块还没有特地好的拜访容器网络的反对。所以一期思考集群CNI网络模式下Pod有弹性网卡入口,这个入口能够间接接入到负载平衡以达到间接拜访的目标。负载平衡间接后端拜访到容器网络,目前曾经有通过云联网解决的计划,后续也会持续跟进这种更贴近集群网络的直连计划。 接下来可能间接拜访了,如何保障滚动更新时的可用性保障呢?咱们找到了官网提供的一个个性ReadinessGate。这个个性在1.12正式提供进去,次要是用来管制Pod的状态。默认状况下,Pod有以下Condition:PodScheduled、Initialized、ContainersReady,当这几个状态都Ready的时候,Pod Ready的Condition就通过了。然而在云原生的场景上面,Pod的状态是十分有可能须要参考其余状态的。ReadinessGate提供了这样一个机制,容许为Pod的状态判断增加一个栅栏,由第三方来进行判断与管制。这样Pod的状态就和第三方关联起来了。 负载平衡流量比照传统NodePort模式 申请细节过程申请流量进入负载平衡申请被负载平衡转发到某一个节点的NodePortKubeProxy将来自NodePort的流量进行NAT转发,目标地址是随机的一个Pod。申请进入容器网络,并依据Pod地址转发到对应节点。申请来到Pod所属节点,转发到Pod。新的Pod直连模式 申请细节过程申请流量进入负载平衡申请被负载平衡转发到某一个Pod的ENI弹性网卡直连与Local拜访的区别看起来这两种拜访形式的成果是一样的,然而在细节上还是存在一些差异。 从性能上区别不大,开启Local拜访时,流量不会进行NAT操作也不会进行跨节点转发,所以仅仅多了一个到容器网络的路由。没有进行NAT操作,起源IP就可能正确获取了。会话放弃性能可能会有以下问题,当一个节点上存在多个Pod时,流量到哪一个Pod是随机的,这个机制可能会使话放弃呈现问题。ReadinessGate的引入后面有两个细节,能够在这里失去解答。 为什么要求集群版本高于 1.12为什么kubectl get pod -o wide的后果中READINESS GATES列有内容。这里波及到一个滚动更新相干的问题当用户开始为利用做滚动更新的时候,Kubernetes会依据更新策略进行滚动更新。然而其判断一批Pod启动的标识仅包含Pod本身的状态,并不会思考这个Pod在负载平衡上是否曾经进行配置健康检查是否通过。有的时候当接入层组件高负载,不能及时对这些Pod进行及时调度的话,这些滚动更新胜利的Pod可能并没有正在对外提供服务,从而导致服务的中断。为了将滚动更新和负载平衡的后端状态关联起来,TKE接入层组件引入了Kubernetes 1.12中引入的新个性ReadinessGate。TKE接入层组件只有在确认后端绑定胜利并且健康检查通过时,通过配置ReadinessGate的状态来使Pod达到Ready的状态,从而推动整个工作负载的滚动更新。 在集群中应用ReadinessGate的细节Kubernetes集群提供的是一个服务注册的机制,你只须要将你的服务以MutatingWebhookConfigurations资源的模式注册到集群中就能够了。集群会在Pod创立的时候依照你的配置的回调门路告诉你,这个时候就能够对Pod做一些创立前的操作,在这个Case外面就是给Pod加上ReadinessGate。惟一须要留神的就是这个回调过程必须是Https的,所以标配须要在MutatingWebhookConfigurations中配置签发申请的CA,并在服务端配置该CA签发的证书。 ReadinessGate机制的劫难复原用户集群中的服务注册或是证书有可能被用户删除,尽管这些零碎组件资源不应该被用户批改或毁坏。但在用户对集群的摸索或是误操作下,这类问题会不可避免的呈现。所以接入层组件在启动时会查看以上资源的完整性,在完整性受到破坏时会重建以上资源,增强零碎的鲁棒性。 QPS和网络时延比照直连与NodePort是服务利用的接入层计划,其实最终参加工作的还是用户部署的工作负载,用户工作负载的能力间接决定了业务的QPS等指标。所以咱们针对这两种接入层计划,在工作负载压力较低的状况下,重点针对网络链路的时延进行了一些比照测试。直连在接入层的网络链路上可能优化10%左右的工夫。同时测试中的监控也发现,直连模式缩小了大量VPC网络内的流量。测试场景,从20节点到80节点,逐渐增大集群规模,通过wrk工具对集群进行网络延时的测试。针对QPS和网络时延,下图给出了直连场景与NodePort的比照测试。 KubeProxy的一些设计思考KubeProxy的毛病也在前文中提到的一样显著。然而基于云上负载平衡、VPC网络的各种个性,咱们能给出各种其余更加本地化的接入层计划。但这并不意味着KubeProxy的设计不好或是作用不大。其对集群接入层的设计极具普适性、容错性,根本实用于所有业务场景下的集群,作为一个官网提供的组件这个设计是十分适合的。 新模式应用指引前置要求Kubernetes集群版本须要高于 1.12。集群网络模式必须开启VPC-CNI弹性网卡模式。直连模式Service应用的工作负载需应用VPC-CNI弹性网卡模式。控制台操作指引登录 容器服务控制台。参考控制台 创立 Service 步骤,进入 “新建Service” 页面,依据理论需要设置 Service 参数。 其中,局部要害参数信息需进行如下设置,如下图所示: 服务拜访形式:抉择为【提供公网拜访】或【VPC内网拜访】。网络模式:勾选【采纳负载平衡直连Pod模式】。Workload绑定:抉择【援用Worklocad】,并在弹出窗口中抉择 VPC-CNI 模式的后端工作负载。单击【创立服务】,实现创立。Kubectl操作指引Workload示例:nginx-deployment-eni.yaml 留神spec.template.metadata.annotations中申明了tke.cloud.tencent.com/networks: tke-route-eni,在工作负载应用VPC-CNI弹性网卡模式。apiVersion: apps/v1kind: Deploymentmetadata: labels: app: nginxname: nginx-deployment-enispec: replicas: 3 selector: matchLabels: app: nginxtemplate: ...

September 10, 2020 · 2 min · jiezi

关于腾讯云:基于腾讯云的-Rust-和-WebAssembly-函数即服务

腾讯云云函数 (SCF) 曾经反对十多种编程语言和运行时框架。腾讯云最近公布的 SCF custom runtime(自定义运行时)更进一步 —— SCF 当初能够反对用任何编程语言编写的函数。 本文将介绍如何在云函数 SCF 中运行用 Rust 编写的 WebAssembly 函数。 咱们先介绍一些基本概念,而后回顾一个残缺但简略的 hello world 示例,部署您的第一个 WebAssembly 无服务器函数。最初,咱们将用一个机器学习即服务 (MLaaS) 示例来做一些有用的事件。该示例承受数据并以 SVG 格局返回拟合模型和可视化。 这是本教程完结时你将创立的最终利用。它齐全是「无服务器」的,只有应用时会产生老本。 HTML 和 JavaScript UI 能够托管在任何计算机上,包含笔记本电脑上。在腾讯云 Serverless 上的后端函数执行机器学习和 SVG 绘图。 为什么抉择 WebAssembly 和 Rust传统的无服务器函数基于重量级的框架。开发者必须在特定的利用框架中编写函数,比方 Node.js 中的 JavaScript 或 Python Boto。 腾讯云 SCF Custom Runtime 突破了这种模式,容许开发者用任何语言编写无服务器函数。 为了演示这个劣势,本文提供了基于 Bash 脚本的函数、基于 Deno 的 TypeScript 函数和基于 Rust 的本机二进制函数的示例。这使咱们可能在腾讯云上创立和部署基于 web 组件的无服务器函数。 为什么要这么做?以下是一些起因: WebAssembly 是为性能而设计的。 WebAssembly 函数能够比用JavaScript 或者 Python 快 10 倍。WebAssembly 函数是可移植的。尽管能够在 SCF Custom runtime上运行本地二进制文件,但必须将这些二进制文件编译到 Custom runtime 的确切操作系统环境中。目前在 X86 CPU 上应用的是 CentOS 7.6,之后可能会更改。正如咱们将要看到的,WebAssembly 函数是可移植的,并且非常容易部署和治理。WebAssembly 函数是平安的。家喻户晓,即便应用 Docker,本地二进制应用程序也可能会毁坏容器。因为你的应用程序可能依赖于许多第三方库,因而你的依赖项中存在危险代码的危险实在存在。 WebAssembly 有着基于能力的平安模型, 为你的代码提供更好的运行时爱护。尽管 WebAssembly 兼容各种编程语言,但 Rust、AssemblyScript (TypeScript)、C/C++ 和 Go 是写 WebAssembly 函数的最佳语言,尤其是 Rust。Rust 是一种风行且越来越受注目的编程语言,社区十分沉闷。Rust 让咱们可能写一个高效但内存平安的函数。最初,在腾讯云上编写和部署 WebAssembly 函数实际上非常简单,在一个小时内就能够实现。 ...

September 10, 2020 · 3 min · jiezi

关于腾讯云:2020腾讯全球数字生态大会聚焦新基建-原生见不凡

自主翻新是云计算的外围生命力,也是云厂商的外围竞争力!从服务器到数据中心,再到云端软件,腾讯云如何在自研畛域进行布局?来原生技术专场,分享腾讯自研技术积淀与产品利用将来!9月11日,9:30,云上见!

September 9, 2020 · 1 min · jiezi

关于腾讯云:Istio-运维实战系列1应用容器对-Envoy-Sidecar-的启动依赖问题

本系列文章将介绍用户从 Spring Cloud,Dubbo 等传统微服务框架迁徙到 Istio 服务网格时的一些教训,以及在应用 Istio 过程中可能遇到的一些常见问题的解决办法。 故障景象该问题的体现是装置了 sidecar proxy 的利用在启动后的一小段时间内无奈通过网络拜访 pod 内部的其余服务,例如内部的 HTTP,MySQL,Redis等服务。如果利用没有对依赖服务的异样进行容错解决,该问题还经常会导致利用启动失败。上面咱们以该问题导致的一个典型故障的剖析过程为例对该问题的起因进行阐明。 典型案例:某运维同学反馈:昨天晚上 Istio 环境中利用的心跳检测报 connect reset,而后服务重启了。狐疑是 Istio 环境中网络不稳固导致了服务重启。 故障剖析依据运维同学的反馈,该 pod 曾多次重启。因而咱们先用 kubectl logs --previous 命令查问 awesome-app 容器最初一次重启前的日志,以从日志中查找其重启的起因。 kubectl logs --previous awesome-app-cd1234567-gzgwg -c awesome-app从日志中查问到了其重启前最初的错误信息如下: Logging system failed to initialize using configuration from 'http://log-config-server:12345/******/logback-spring.xml'java.net.ConnectException: Connection refused (Connection refused) at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350) at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)从错误信息能够得悉,利用过程在启动时试图通过 HTTP 协定从配置核心拉取 logback 的配置信息,但该操作因为网络异样失败了,导致利用过程启动失败,最终导致容器重启。 是什么导致了网络异样呢?咱们再用 Kubectl get pod 命令查问 Pod 的运行状态,尝试找到更多的线索: ...

September 9, 2020 · 3 min · jiezi

关于腾讯云:Kubernetes-服务部署最佳实践二-如何提高服务可用性

引言上一篇文章咱们围绕如何正当利用资源的主题做了一些最佳实际的分享,这一次咱们就如何进步服务可用性的主题来开展探讨。 怎么进步咱们部署服务的可用性呢?K8S 设计自身就思考到了各种故障的可能性,并提供了一些自愈机制以进步零碎的容错性,但有些状况还是可能导致较长时间不可用,拉低服务可用性的指标。本文将联合生产实践经验,为大家提供一些最佳实际来最大化的进步服务可用性。 如何防止单点故障?K8S 的设计就是假如节点是不牢靠的。节点越多,产生软硬件故障导致节点不可用的几率就越高,所以咱们通常须要给服务部署多个正本,依据理论状况调整 replicas 的值,如果值为 1 就必然存在单点故障,如果大于 1 但所有正本都调度到同一个节点了,那还是有单点故障,有时候还要思考到劫难,比方整个机房不可用。 所以咱们不仅要有正当的正本数量,还须要让这些不同正本调度到不同的拓扑域(节点、可用区),打散调度以防止单点故障,这个能够利用 Pod 反亲和性来做到,反亲和次要分强反亲和与弱反亲和两种。更多亲和与反亲和信息可参考官网文档Affinity and anti-affinity。 先来看个强反亲和的示例,将 DNS 服务强制打散调度到不同节点上: affinity: podAntiAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: - key: k8s-app operator: In values: - kube-dns topologyKey: kubernetes.io/hostnamelabelSelector.matchExpressions 写该服务对应 pod 中 labels 的 key 与 value,因为 Pod 反亲和性是通过判断 replicas 的 pod label 来实现的。topologyKey 指定反亲和的拓扑域,即节点 label 的 key。这里用的 kubernetes.io/hostname 示意防止 pod 调度到同一节点,如果你有更高的要求,比方防止调度到同一个可用区,实现异地多活,能够用 failure-domain.beta.kubernetes.io/zone。通常不会去防止调度到同一个地区,因为个别同一个集群的节点都在一个地区,如果跨地区,即应用专线时延也会很大,所以 topologyKey 个别不至于用 failure-domain.beta.kubernetes.io/region。requiredDuringSchedulingIgnoredDuringExecution 调度时必须满足该反亲和性条件,如果没有节点满足条件就不调度到任何节点 (Pending)。如果不必这种硬性条件能够应用 preferredDuringSchedulingIgnoredDuringExecution 来批示调度器尽量满足反亲和性条件,即弱反亲和性,如果切实没有满足条件的,只有节点有足够资源,还是能够让其调度到某个节点,至多不会 Pending。 ...

September 9, 2020 · 2 min · jiezi

关于腾讯云:Kubernetes-服务部署最佳实践一-如何更好地设置-Request-与-Limit

如何为容器配置 Request 与 Limit? 这是一个即常见又辣手的问题,这个依据服务类型,需要与场景的不同而不同,没有固定的答案,这里联合生产经验总结了一些最佳实际,能够作为参考。 所有容器都应该设置 requestrequest 的值并不是指给容器理论调配的资源大小,它仅仅是给调度器看的,调度器会 "察看" 每个节点能够用于调配的资源有多少,也晓得每个节点曾经被调配了多少资源。被分配资源的大小就是节点上所有 Pod 中定义的容器 request 之和,它能够计算出节点残余多少资源能够被调配(可分配资源减去已调配的 request 之和)。如果发现节点残余可分配资源大小比以后要被调度的 Pod 的 reuqest 还小,那么就不会思考调度到这个节点,反之,才可能调度。所以,如果不配置 request,那么调度器就不能晓得节点大略被调配了多少资源进来,调度器得不到精确信息,也就无奈做出正当的调度决策,很容易造成调度不合理,有些节点可能很闲,而有些节点可能很忙,甚至 NotReady。 所以,倡议是给所有容器都设置 request,让调度器感知节点有多少资源被调配了,以便做出正当的调度决策,让集群节点的资源可能被正当的调配应用,防止陷入资源分配不均导致一些意外产生。 老是遗记设置怎么办有时候咱们会遗记给局部容器设置 request 与 limit,其实咱们能够应用 LimitRange 来设置 namespace 的默认 request 与 limit 值,同时它也能够用来限度最小和最大的 request 与 limit。示例: apiVersion: v1kind: LimitRangemetadata: name: mem-limit-range namespace: testspec: limits: - default: memory: 512Mi cpu: 500m defaultRequest: memory: 256Mi cpu: 100m type: Container重要的线上利用改如何设置节点资源有余时,会触发主动驱赶,将一些低优先级的 Pod 删除掉以开释资源让节点自愈。没有设置 request,limit 的 Pod 优先级最低,容易被驱赶;request 不等于 limit 的其次; request 等于 limit 的 Pod 优先级较高,不容易被驱赶。所以如果是重要的线上利用,不心愿在节点故障时被驱赶导致线上业务受影响,就倡议将 request 和 limit 设成统一。 ...

September 9, 2020 · 1 min · jiezi

关于腾讯云:深入了解服务网格数据平面性能和调优

在腾讯,曾经有很多产品已应用或者正在尝试应用istio来作为其微服务治理的根底平台。不过在应用istio时,也有一些对通信性能要求较高的业务会对istio的性能有一些担心。因为envoy sidecar的引入,使两个微服务之间的通信门路变长,导致服务延时受到了一些影响,istio社区始终以来也有这方面的声音。基于这类埋怨,咱们心愿可能对这一通信过程进行优化,以更好的满足更多客户的需要。 首先,咱们看一下istio数据面的通信模型,来剖析一下为什么会对延时有这么大的影响。能够看到,相比于服务之间间接通信,在引入istio 之后,通信门路会有明显增加,次要包含多出了两次本地过程之间的tcp连贯通信和用户态网络代理envoy对数据的解决。所以咱们的优化也分为了两局部进行。 内核态转发优化那么对于本地过程之间的通信优化,咱们能做些什么呢?其实在开源社区曾经有了这方面的摸索了。istio官网社区在2019年1月的时候曾经有了这方面探讨,在文档外面提到了应用ebpf的技术来做socket转发的数据代理,使数据在socket层进行转发,而不须要再往下通过更底层的TCP/IP协定栈的一个解决,从而缩小它在数据链路上的通信链路长度。 另外,网络开源我的项目cilium也在这方面有一个比拟深刻的实际,同样也是应用了ebpf的技术。不过在cilium中本地网络减速只是其中的一个模块,没有作为一个独立的服务进行开发实际,在腾讯云外部没法间接应用,这也促使了咱们开发一个无依赖的解决方案。 当然在初期的时候,咱们也对ebpf的技术进行了一个验证,从验证后果中能够看到,在应用了ebpf的技术之后,它的延时大略有20%到30%的晋升,阐明ebpf的技术利用在本地通信上还是有肯定优化能力的。 简略介绍一下ebpf,看一下它是怎么做到减速本地通信的。首先ebpf能够看作是一个运行在内核外面的虚拟机,用户编写的ebpf程序能够被加载到内核外面进行执行。内核的一个verify组件会保障用户的ebpf程序不会引发内核的crash,也就是能够保障用户的ebpf程序是平安的。目前ebpf程序次要用来追踪内核的函数调用以及平安等方面。下图能够看到,ebpf能够用在很多内核子系统当中做很多的调用追踪。 另外一个比拟重要的性能,就是咱们在性能优化的时候应用到的在网络上的一个能力,也就是上面提到的sockhash。sockhash自身是一个ebpf非凡的一个kv存储构造,次要被用作内核的一个socket层的代理。它的key是用户自定义的,而value是比拟非凡的,它存储的value是内核外面一个socket对象。存储在sockhash中的socket在发送数据的时候,如果可能通过咱们挂在sockhash当中的一个ebpf当中的程序找到接管方的socket,那么内核就能够帮忙咱们把发送端的数据间接拷贝到接收端socket的一个接管队列当中,从而能够跳过数据在更底层的解决,比方TCP/IP协定栈的解决。 在sidecar中,socket是怎么被辨认并存储在sockhash当中来实现一个数据拷贝的呢?咱们须要剖析一下数据链的本地通信的流量特色。 首先从ingress来讲,ingress端的通信会比较简单一点,都是一个本地地址的通信。ingress端的envoy过程和用户服务过程之间通信,它的原地址和目标地址刚好是一一对应的。所以咱们能够利用这个地址的四元组结构它的key,把它存储到sockhash当中。在发送数据的时候,依据这个地址信息反向结构这个key,从sockhash当中拿到接收端的socket返回给内核,这样内核就能够帮咱们将这个数据间接拷贝给接收端的socket。 egress会略微简单一点,在一个egress端服务程序对外收回的申请被iptables规定重定向到了envoy监听的一个15001的端口。在这里,发起方的源地址和接管方的目标地址是一一对应的,然而发起方的目标地址和接收端的源地址有了一个变动,次要是因为iptables对地址有一个重写。所以咱们在存储到sockhash中的时候,须要对这部分信息进行一个解决。因为istio的特殊性,间接能够把它改写成envoy所监听的一个本地服务地址。这样再存储到sockhash当中,它们的地址信息还是能够反向一一对应的。所以在查找的时候,还是能够依据一端的socket地址信息查找到另一端的socket,达到数据拷贝的目标。 通过对ebpf减速原理的剖析,咱们开发进去一个ebpf的插件,这个插件能够不依赖于集群自身的网络模式,应用daemonset形式部署到k8s集群的各个节点上。其中的通信成果如下图所示,本地过程的一个通信在socket层间接被ebpf拦挡当前,就不会再往下发送到TCPIP协定栈了,间接在socket层就进行了一个数据拷贝,缩小了数据链路上的一个解决流程 上面是对成果的一个测试,从整体来看,它的延时有大略5到8%的延时晋升,其实晋升的幅度不是很大,次要起因其实在整个通信的流程当中,内核态的一个解决占整个通信解决的工夫,延时其实是比拟少的一部分,所以它的晋升不是特地显著。 另外ebpf还有一些缺点,比方它对内核版本的要求是在4.18版本之后才有sockhash这个个性。另外sockhash自身还有一些bug,咱们在测试当中也发现了一些bug,并且把它提交到社区进行解决。 Envoy 性能钻研与优化后面介绍了对istio数据面对流量在内核的解决所进行的一些优化。在istio数据面的性能问题上,社区留神到比拟多的是在内核态有一个显著的转发流程比拟长的问题,因而提出了应用eBPF进行优化的计划,然而在Envoy下面没有太多的声音。尽管Envoy自身是一个高性能的网络代理,但咱们还是无奈确认Envoy自身的损耗是否对性能造成了影响,所以咱们就兵分两路,同时在Envoy下面进行了一些钻研。 首先什么是Envoy?Envoy是为分布式环境而生的高性能网络代理,能够说基本上是作为服务网格的通用数据立体被设计进去的。Envoy提供不同层级的filter架构,如listenerFilter、networkFilter以及HTTPFilter,这使envoy具备十分好的可扩展性。Envoy还具备很好的可察看性,内置有stats、tracing、logging这些子系统,能够让咱们更容易地对系统进行监控。 进行istio数据面优化的时候,咱们面对的第一个问题是Envoy在istio数据面中给音讯转发减少了多少延时?Envoy自身提供的内置指标是很难反映Envoy自身的性能。因而,咱们通过批改Envoy源码,在Envoy解决音讯的开始与完结的地位进行打点,记录时间戳,能够取得Envoy解决音讯的延时数据。Envoy是多线程架构,在打点时咱们思考了性能和线程平安问题:如何高效而又精确地记录所有音讯的解决延时,以不便后续的进行剖析?这是通过如下办法做到的: a. 给压测音讯调配惟一数字ID; b. 在Envoy中预调配一块内存用于保留打点数据,其数据类型是一个构造体数组,每个元素都是同一条音讯的打点数据; c. 提取音讯中的数字ID当作工夫戳记录的下标,将工夫戳记录到预调配的内存的固定地位。通过这种形式,咱们平安高效地实现了Envoy内的打点记录(毛病是须要批改Envoy以及压测工具)。 通过离线剖析,咱们发现了Envoy内音讯解决延时的一些散布特色。左图是对Envoy解决延时与音讯数量分布图,横轴是延时,纵轴是音讯数量。能够看到在高延时部份,音讯数量有异样减少的景象,这不是典型的幂率散布。进一步对高延时部份进行剖析后发现,这些高延时音讯平均地散布于整个测试期间(如上图右所示)。 依据咱们的教训,这通常是Envoy外部转发音讯的worker在周期性的执行一些耗费CPU的工作,导致有一部分音讯没方法及时转发而引起的。 深入研究Envoy在istio数据面的性能实现后,咱们发现mixer遥测可能是导致这个问题的根本原因。Mixer是istio老版本(1.4及以前)实现遥测和策略查看性能的一个组件。在数据面的Envoy中,Mixer会提取所有音讯的属性,而后批量压缩上报到mixer server,而属性的提取和压缩是一个高CPU的耗费的操作,这会引起延时数据分析中失去的后果:高延时音讯转发异样增多。 在确定了起因之后,咱们对Envoy的架构作了一些改良,给它减少了执行非关键工作的AsyncWorker线程,称为异步工作线程。通过把遥测的逻辑拆分进去放到了AsyncWorker线程中去执行,就解决了worker线程被阻塞的问题,进而能够升高envoy转发音讯的延时。 进行架构优化之后,咱们也做了比照测试,上图左测是延时与音讯数量图,能够看到它高延时局部失去显著的改善。上图右能够看出Envoy整体的延时升高了40%以上。 优化Envoy架构给咱们带来了第一手的教训,首先CPU是影响Istio数据面性能的要害资源,它的瓶颈次要呈现在CPU下面,而不是网络IO操作。第二,咱们对Envoy进行架构优化,能够升高延时,然而没有解决基本问题,因为CPU的应用没有升高,只是遥测逻辑转移到另外的线程中执行,升高Envoy转发音讯的延时。优化CPU使用率才是数据面优化的外围。第三点,Envoy的不同组件当中,mixer消化掉了30%左右的CPU,而遥测是mixer的外围性能,因而后续遥测优化就变成了优化的重要方向。 怎么进行遥测优化呢?其实mixer实现遥测是非常复杂的一套架构,应用Istio mixer遥测的人都深有体会,幸好istio新版本中,不止对istio的管制面作了大的调整,在数据面mixer也同样被移除了,意味着Envoy中高耗费的遥测就不会存在了,咱们是基于istio在做外部的service mesh,从社区失去这个音讯之后,咱们也疾速跟进,引入适配新的架构。 没有Mixer之后,遥测是如何实现的。Envoy提供了应用wasm对其进行扩大的形式,以放弃架构的灵活性。而istio社区基于Wasm的扩大开发了一个stats extension扩大,实现了一个新的遥测计划。与mixer遥测相比,这个stats extension不再上报全量数据到mixer server,只是在Envoy内的stats子系统中生成遥测指标。遥测零碎拉取Envoy的指标,就能够取得整个遥测数据,会大大降低遥测在数据面的性能耗费。 而后咱们对istio 1.5应用Wasm的遥测,做了一个性能的测试。发现整个Envoy代理在同样测试条件下,它的CPU升高10%,而应用mixer的遥测其实占用了30%的CPU,外面大部分逻辑是在执行遥测。按咱们的了解,Envoy至多应该有20%的CPU降落,然而实际效果只有10%左右,这是为什么呢? 新架构下咱们遇到了新的问题。咱们对新架构进行了一些实现原理和技术细节上的剖析,发现Envoy应用Wasm的扩大形式,尽管带来了灵活性和可扩展性,然而对性能有肯定的影响。 首先,Wasm扩大机制跟Envoy host环境是通过内存拷贝的形式进行通信,这是Wasm虚拟机的隔离性机制决定的。Envoy为了放弃架构灵活性的同时保障性能,使设计了一个非Wasm虚拟机运行扩大(如stats extension)的模式,即NullVM模式,它是一个假的Wasm虚拟机,实际上运行的扩大还是被编译在Envoy外部,但它也逃离不掉Wasm架构带来的内存拷贝影响。 其次,在实现extension与Envoy的通信时,一个属性的获取要通过屡次的内存拷贝,是一个非常复杂的过程。如上图所示,获取request.url这个属性须要在Envoy的内存和Wasm虚拟机内存之间进行一个简单的拷贝操作,这种形式的耗费远大于通过援用或指针提取属性。 第三,在实现遥测的时候,有大量的属性须要获取,通常有十几二十个属性,因而Wasm扩大带来的总体额定损耗十分可观。 另外,Wasm实现的遥测性能还须要另外一个叫做metadata_exchange扩大的反对。metadata_exchange用来取得调用对端的一些节点信息,而metadata_exchange扩大运行在另外一个虚拟机当中,通过Envoy的Filter state机制与stats 扩大进行通信,进一步减少了遥测的额定耗费。 那么如何去优化呢?简略对Wasm插件优化是没有太大帮忙,因为它的底层Wasm机制曾经决定了它有不少的性能损耗,所以咱们就开发了一个新的遥测插件tstats。tstats应用Envoy原生的扩大形式开发。在tstats扩大外部,实现了遥测和metadata_exchange的联合,打消了Wasm带来的性能弊病。Tstats遥测与社区遥测兼容,生成雷同的指标,tstats基于istio管制面的EnvoyFilter CRD进行部署,用户能够平滑降级,当用户发现tstats的性能没有满足需要或者呈现一些问题时,也能够切换应用到社区提供的遥测扩大。 在tstats扩大还优化了遥测指标的计算过程。在计算指标的时候有许多维度信息须要填充,(目前大指标有二十几个维度的填充),这其实是一个比较复杂的操作,其实,有很多指标的维度都是节点信息,就是发动服务调用的客户端和服务端的一些信息,如服务名、版本等等。其实咱们能够将它进行一些缓存,减速这些指标的计算。 通过优化之后,比照tstats遥测和官网的基于Wasm的遥测的性能,咱们发现CPU升高了10到20%,绝对于老版本的mixer来说升高了20%以上,合乎了咱们对envoy性能调研的一个预期。上图右能够看到在延时上有一个显著的升高,即便在P99在不同的QPS下,也会有20%到40%的总体升高(这个延时是应用echo service做End-to-End压测失去的)。 ...

August 25, 2020 · 1 min · jiezi

关于腾讯云:Pod-Terminating原因追踪系列之一containerd中被漏掉的runc错误信息

前一段时间发现有一些containerd集群呈现了Pod卡在Terminating的问题,通过一系列的排查发现是containerd对底层异样解决的问题。最初尽管通过一个短小的PR修复了这个bug,然而找到bug的过程和对问题的反思还是值得和大家分享的。 本文中会借由排查bug的过程来剖析kubelet删除Pod的调用链,这样不仅仅能够理解containerd的bug,还能够借此理解更多Pod删除不掉的起因。在文章的最初会对问题进行反思,来探讨OCI呈现的问题。 一个删除不掉的Pod可能大家都会遇到这种问题,就是集群中有那么几个Pod无论如何也删除不掉,看起来和下图一样。当然可有很多可能导致Pod卡在Terminating的起因,比方mount目录被占用、dockerd卡死了或镜像中有“i”属性的文件。因为节点上简单的组件(docker、containerd、cri、runc)和过长的调用链,导致很难霎时定位呈现问题的地位。所以个别遇到此类问题都会通过日志、Pod的信息和容器的状态来逐渐放大排查范畴。 当然首先看下集群的信息,发现没有应用docker而间接用的cri和containerd。间接应用containerd照比应用docker会有更短的调用链和更强的鲁棒性,照比应用docker应该更稳固才对(比方经常出现的docker和containerd数据不统一的问题在这里就不会呈现)。接下来当然是查看kubelet日志,如下(只保留了外围局部),从这条日志中能够发现貌似是kubelet调用cri接口,最终调用runc去删除容器时报错导致删除失败。 $ journalctl -u kubeletFeb 01 11:37:27 VM_74_45_centos kubelet[687]: E0201 11:37:27.241794 687 pod_workers.go:190] Error syncing pod 18c3d965-38cc-11ea-9c1d-6e3e7be2a462 ("advertise-api-bql7q_prod(18c3d965-38cc-11ea-9c1d-6e3e7be2a462)"), skipping: error killing pod: [failed to "KillContainer" for "memcache" with KillContainerError: "rpc error: code = Unknown desc = failed to kill container \"55d04f7c957e81fcf487b0dd71a4e50fe138165303cf6e96053751fd6770172c\": unknown error after kill: runc did not terminate sucessfully: container \"55d04f7c957e81fcf487b0dd71a4e50fe138165303cf6e96053751fd6770172c\" does not exist\n: unknown"接下来咱们打算剖析下容器以后的状态,简略介绍下,containerd中用container来示意容器、用task来示意容器的运行状态,创立一个容器相当于创立container,而把容器运行起来相当于创立一个task并把task状态置为Running。当然停掉容器就相当于把task的状态设置为Stopped。通过ctr命令看下containerd中container和task的状态,容器55d04f对应的container和task都还在、task状态是STOPPED。接下来查看containerd日志,咱们节选了一小部分,发现了如下景象,第一条日志是stop容器55d04f时做umount失败,接下来都是kill容器55d04f时发现container不存在。 error="failed to handle container TaskExit event: failed to stop container: failed rootfs umount: failed to unmount target /run/containerd/io.containerd.runtime.v1.linux/k8s.io/55d04f.../rootfs: device or resource busy: unknown"error="failed to handle container TaskExit event: failed to stop container: unknown error after kill: runc did not terminate sucessfully: container "55d04f..." does not exist"error="failed to handle container TaskExit event: failed to stop container: unknown error after kill: runc did not terminate sucessfully: container "55d04f..." does not exist"error="failed to handle container TaskExit event: failed to stop container: unknown error after kill: runc did not terminate sucessfully: container "55d04f..." does not exist"当然失去这些信息直觉会认为排查方向是: ...

August 20, 2020 · 3 min · jiezi

关于腾讯云:Pod-Terminating原因追踪系列之二exec连接未关闭导致的事件阻塞

前一阵有客户docker18.06.3集群中呈现Pod卡在terminating状态的问题,通过排查发现是containerd和dockerd之间事件流阻塞,导致后续事件得不到解决造成的。 定位问题的过程极其艰巨,其中不乏大量工具的应用和大量的源码浏览。本文将梳理排查此问题的过程,并总结残缺的dockerd和contaienrd之间事件传递流程,一步一步找到问题产生的起因,特写本文记录分享,心愿大家在有相似问题产生时,可能迅速定位、解决。 对于本文中提到的问题,在docker19中曾经失去解决,但docker18无奈间接降级到docker19,因而本文在结尾参考docker19给出了一种简略的解决方案。 删除不掉Pod置信大家在解决现网问题时,常常会遇到Pod卡在terminating不动的状况,产生这种状况的起因有很多,比方《Pod Terminating起因追踪系列之一》中提到的containerd没有正确处理错误信息,当然更常见的比方umount失败、dockerd卡死等等。 遇到此类问题时,通常通过kubelet或dockerd日志、容器和Pod状态、堆栈信息等伎俩来排查问题。本问题也不例外,首先登录到Pod所在节点,应用以下两条指令查看容器状态: #查看容器状态,看到容器状态为updocker ps | grep <container-id>#查看task状态,显示task的状态为STOPPEDdocker-container-ctr --namespace moby --address var/run/docker/containerd/docker-containerd.sock task ls | grep <container-id> 能够看到在dockerd中容器状态为up,但在containerd中task状态为STOPPED,两者信息产生了不统一,也就是说因为某种原因containerd中的状态信息没有同步到dockerd中,为了探索为什么两者状态产生了不统一,首先须要理解从dockerd到containerd的整体调用链: 当启动dockerd时,会通过NewClient办法创立一个client,该client保护一条到containerd的gRPC连贯,同时起一个协程processEventStream订阅(subscribe)来自containerd的task事件,当某个容器的状态发生变化产生了事件,containerd会返回事件到client的eventQ队列中,并通过ProcessEvent办法进行解决,processEventStream协程在除优雅退出以外永远不会退出(但在有些状况下还是会退出,在后续会推出一篇文章,恰好是这种状况,敬请期待~)。 当容器过程退出时,containerd会通过上述gRPC连贯返回一个exit的task事件给client,client接管到来自containerd的exit事件之后由ProcessEvent调用DeleteTask接口删除对应task,至此实现了一个容器的删除。 因为containerd始终处于STOPPED状态,因而通过下面的调用链猜想会不会是task exit事件因为某种原因而阻塞掉了?产生的后果就是在containerd侧因为发送了exit事件而进入STOPPED状态,但因为没有调用DeleteTask接口,因而本task还存在。 模仿task exit事件通过发送task exit事件给一个卡住的Pod,来模仿容器完结的状况: /tasks/exit {"container_id":"23bd0b1118238852e9dec069f8a89c80e212c3d039ba030cfd33eb751fdac5a7","id":"23bd0b1118238852e9dec069f8a89c80e212c3d039ba030cfd33eb751fdac5a7","pid":17415,"exit_status":127,"exited_at":"2020-07-17T12:38:01.970418Z"}咱们能够手动将上述事件publish到containerd中,然而须要留神的一点的是,在publish之前须要将上述内容进行一下编码(参考containerd/cmd/containerd-shim/main_unix.go Publish办法)。失去的后果如下图,能够看到事件胜利的被publish,也被dockerd捕捉到,但容器的状态依然没有变动。 #将file文件中的事件发送到containerddocker-containerd --address var/run/docker/containerd/docker-containerd.sock publish --namespace moby --topic /tasks/exit < ~/file 当咱们查看docker堆栈日志(向dockerd过程发送SIGUSR1信号),发现有大量的Goroutine卡在append办法,每次publish新的exit事件都会减少一个append办法的堆栈信息: 通过查看append办法的源码发现,append办法负责将收到的containerd事件放入eventQ,并执行回调函数,对收到的不同类型事件进行解决: func (q *queue) append(id string, f func()) { q.Lock() defer q.Unlock() if q.fns == nil { q.fns = make(map[string]chan struct{}) } done := make(chan struct{}) fn, ok := q.fns[id] q.fns[id] = done go func() { if ok { <-fn } f() close(done) q.Lock() if q.fns[id] == done { delete(q.fns, id) } q.Unlock() }()}形参中的id为container的id,因而对于同一个container它的事件是串行解决的,只有前一个事件处理完结才会解决下一个事件,且没有超时机制。 ...

August 20, 2020 · 2 min · jiezi

关于腾讯云:大型Kubernetes集群的资源编排优化

背景云原生这个词想必大家应该不生疏了,容器是云原生的重要基石,而Kubernetes通过这几年的疾速迭代倒退曾经成为容器编排的事实标准了。越来越多的公司不论是大公司还是中小公司曾经在他们的生产环境中开始应用Kubernetes, 原生Kubernetes尽管曾经提供了一套十分残缺的资源调度及治理计划然而在理论应用过程中还是会碰到很多问题: 集群节点负载不平衡的问题业务创立Pod资源申请不合理的问题业务如何更疾速的扩容问题多租户资源抢占问题这些问题可能是大家在应用Kubernetes的过程中应该会常常遇到的几个比拟典型的资源问题,接下来咱们将别离介绍在腾讯外部是如果解决和优化这些问题的。 集群节点负载不平衡的问题咱们晓得Kubernetes原生的调度器多是基于Pod Request的资源来进行调度的,没有依据Node以后和过来一段时间的实在负载状况进行相干调度的决策。这样就会导致一个问题在集群内有些节点的残余可调度资源比拟多然而实在负载却比拟高,而另一些节点的残余可调度资源比拟少然而实在负载却比拟低, 然而这时候Kube-scheduler会优先将Pod调度到残余资源比拟多的节点上(依据LeastRequestedPriority策略)。 如上图,很显然调度到Node1是一个更优的抉择。为了将Node的实在负载状况加到调度策略里,防止将Pod调度到高负载的Node上,同时保障集群中各Node的实在负载尽量平衡,咱们扩大了Kube-scheduler实现了一个基于Node实在负载进行预选和优选的动静调度器(Dynamic-scheduler)。 Dynamic-scheduler在调度的时候须要各Node上的负载数据,为了不阻塞动静调度器的调度这些负载数据,须要有模块定期去收集和记录。如下图所示node-annotator会定期收集各节点过来5分钟,1小时,24小时等相干负载数据并记录到Node的annotation里,这样Dynamic-scheduler在调度的时候只须要查看Node的annotation便能很快获取该节点的历史负载数据。 为了防止Pod调度到高负载的Node上,须要先通过预选把一些高负载的Node过滤掉,如下图所示(其中的过滤策略和比例是能够动静配置的,能够依据集群的理论状况进行调整)Node2过来5分钟的负载,Node3过来1小时的负载多超过了对应的域值所以不会参加接下来的优选阶段。 同时为了使集群各节点的负载尽量平衡,Dynamic-scheduler会依据Node负载数据进行打分, 负载越低打分越高。如下图所示Node1的打分最高将会被优先调度(这些打分策略和权重也是能够动静配置的)。 Dynamic-scheduler只能保障在调度的那个时刻会将Pod调度到低负载的Node上,然而随着业务的高峰期不同Pod在调度之后这个Node可能会呈现高负载。为了防止因为Node的高负载对业务产生影响咱们在Dynamic-scheduler之外还实现了一个Descheduler,它会监控Node的高负载状况将一些配置了高负载迁徙的Pod迁徙到负载比拟低的Node上。 业务如何更疾速的扩容问题业务上云的一个重要劣势就是在云上能实现更好的弹性伸缩,Kubernetes原生也提供了这种横向扩容的弹性伸缩能力(HPA)。然而官网的这个HPA Controller在实现的时候用的是一个Gorountine来解决整个集群的所有HPA的计算和同步问题,在集群配置的HPA比拟多的时候可能会导致业务扩容不及时的问题,其次官网HPA Controller不反对为每个HPA进行独自的个性化配置。 为了优化HPA Controller的性能和个性化配置问题,咱们把HPA Controller独自抽离进去独自部署。同时为每一个HPA独自配置一个Gorountine,并且每一个HPA多能够依据业务的须要进行独自的配置。 其实仅仅优化HPA Controller还是不能满足一些业务在业务顶峰时候的一些需要,比方在业务做流动的时候心愿在流量高峰期之前就可能把业务扩容好。这个时候咱们就须要一个定时HPA的性能,为此咱们定义了一个CronHPA的CRD和CronHPA Operator。CronHPA会在业务定义的工夫进行扩容和缩容,同时还能和HPA一起配合工作。 业务创立Pod资源申请不合理的问题通过Dynamic-scheduler和Descheduler来保障集群各节点的负载平衡问题。然而我可能会面临另一个比拟头疼的问题就是集群的整体负载比拟低然而可调度资源曾经没有了,从而导致Pod Pending。这个往往是因为Pod 资源申请不合理或者业务顶峰时段不同所导致的,那咱们是否能够依据Node负载状况对Node资源进行肯定比例的超卖呢。于是咱们通过Kubernetes的MutatingWebhook来截获并批改Node的可调度资源量的形式来对Node资源进行超卖。 这里须要留神的是节点的超卖管制须要比拟灵便不能一概而论,比方负载高的Node超卖比例应该要设置比拟小或者不能设置超卖。 多租户资源抢占问题当平台用户增多的时候,如果对资源不做任何管制那么各租户之间资源抢占是不可避免的。Kubernetes原生提供的ResourceQuota能够提供Namespace级别对资源配额限度。然而腾讯外部资源估算治理通常是按产品维度,而一个产品可能会包含很多Namespace的显然ResourceQuota不太适宜这种场景。其次ResourceQuota只有资源限度性能不能做资源预留,当业务要做流动的时候不能保障流动期间有足够的资源能够应用。 为了实现一个产品维度且有资源预留性能的配额治理性能,咱们设计了一个DynamicQuota的CRD来治理产品在各集群的配额。如下图所示产品2在各集群所占的配额资源其它产品多无奈应用。 如果一个产品占用配额始终不应用就可能会导致平台资源的节约,因而咱们在产品配额预留的根底上提供了在不同产品间配额借调的性能。如下图所示产品1临时不必的配额能够借调给产品2长期应用。 当平台有多集群的时候,产品配额须要如何调配。为了简化配下发操作,如下图所示管理员在下发产品配额的时候只需配置一个该产品的配额总量,配额下发模块会依据产品目前在各集群的应用状况按比例调配到各个集群。 产品在各集群的资源应用状况是会时刻变动的,所以产品在各集群配额也须要依据业务的应用状况进行动静的调整。如下图所示产品在集群2中的配额曾经快用完的时候,配额调整模块会动静的把配额从应用不多的集群1和集群3调到集群2。 在线业务和离线业务混合部署是云平台的发展趋势,所以咱们在设计配额治理的时候也把在离线配额管制思考进去了。如下图所示咱们在集群维度加了一个离线配额管制,一个集群的离线业务资源应用不能超过该集群总资源的30%(这个比例能够依据理论状况进行调整)。其次一个产品的在线业务和离线业务配额之和又不能超过产品在该集群的总配额。 总结下面提到的计划只是简略说了一下咱们的一些解决问题的思路,其实在真正运作的过程中还有很多细节须要思考和优化。比方:下面提到的产品配额治理如果一个产品的配额有余了,这时候业务有顶峰须要进行HPA扩容,这时候配额治理模块须要对这种扩容优化并放行。【腾讯云原生】云说新品、云研新术、云游新活、云赏资讯,扫码关注同名公众号,及时获取更多干货!!

August 19, 2020 · 1 min · jiezi

关于腾讯云:基于Rustvmm实现Kubernetes运行时

随着容器及K8s的宽泛应用,越来越多的容器平安与隔离问题被裸露进去,如:容器逃逸、程度攻打、DDos攻打等严重威胁了办公和生产环境的平安与稳固,影响了业务的失常运行。平安容器技术孕育而生,产生了kata、gVisor、unikernel等多种平安容器计划。本文旨在介绍各种平安容器计划,剖析各计划特点,联合腾讯在容器平安畛域的实际,帮忙读者抉择适宜本身个性的容器运行时。同时引入Rust-VMM我的项目,介绍 Rust-VMM 技术和生态,演示如何应用K8s调度和启用Rust-VMM平安容器运行时,瞻望以Rust语言实现的容器运行时的广大前景。 容器平安与隔离一个基于K8s集群构建的基础设施中,外部存在不同档次的隔离,从容器到Pod再到节点最初到cluster,每一层隔离都有它的特点和个性,咱们尤其关注Pod级别的隔离个性。 相比其余档次的平安隔离,Pod及容器级别的隔离对咱们的挑战十分大。容器在运行时应用root运行过程,只管应用namespace技术为容器空间内的pid、uts、fib等进行了隔离,但因为各个容器共享零碎内核,容器与内核间不足隔离爱护,容易引发容器逃逸等平安问题,典型容器逃逸攻打如:CVE-2018-14634、CVE-2016-5195、CVE-2019-5736 及 CVE-2019-14271等。 docker.vh.neargle.com:8888/?command_exec=python3 -c "import docker;client = docker.DockerClient(base_url='unix:///var/run/docker.sock');data = client.containers.run('alpine:latest', r'''sh -c \"echo 'ssh-rsa xxxxx root@620e839e9b02' >> /tmp/root/root/.ssh/authorized_keys\" ''', remove=True, volumes={'/': {'bind': '/tmp/root', 'mode': 'rw'}})"上述脚本是一个简略的例子,这段代码会向docker.sock的端口发动申请,拉起一个alpine的容器,容器内过程会向所在主机注入一段SSH的公钥。在容器里的歹意用户或者攻击者,就能够获轻松得这个容器所在host主机的SSH的登录权限,从而可能非法查看同主机其余容器空间的信息,篡改要害文件或记录,甚至以主机为跳板攻打整个集群。 还有一个就是Noisy Neighbor,就是吵闹街坊问题。对于Noisy Neighbor,容器方面曾经有了很多停顿,比方对于CPU、memory、bandwidth甚至是buffer IO,基于Cgroup对这些资源曾经有了一些隔离和限度,然而这些限度并不能齐全解决Noisy Neighbor的问题,还是有一些吵闹的过程会影响到失常的业务过程的运行。 # kubectl run --rm -it bb --image=busybox sh/ # f(){ f|f& };f # WARNING: Don't try this!下面是一个简略的例子,启动一个busybox的容器,在外面执行一个嵌套循环的指令,会把这台主机上所有的file descriptor全副耗尽,造成这台主机上失常运行的业务过程工作不失常,这个是Noisy Neighbor的危险和问题。 对于上述问题,倡议用户关注官网的破绽报告,降级操作系统或docker的版本,依据平安指引配置容器环境,同时能够参考以下措施加强容器集群的平安防护级别。 在物理层面上隔离,为不同的租户之间划分不同的Hardware Isolation域,让不同的租户应用不同的硬件空间,从物理上、网络上以及存储上彻底的隔离,这也是最间接最无效的办法。利用一些Security Tools,包含常常用的SElinux或者Cgroup隔离,划分不同的资源拜访和平安规定,然而这些平安规定须要编写大量的profile文件,实现起来难度颇大。入侵检测机制,主机进攻的一种伎俩。入侵检测的软件或者过程会监控这台主机上有危险的过程或者有危险的文件,对于这些文件的读写操作都会有平安方面的记录,会即时预警,即时响应。比方对于containerd-shim/busybox/docker-runc的要害过程,比方docker-runc对于bash、init或者对于fd的拜访都能够做到即时的预警和标记。对于下面提到的容器逃离破绽,通过入侵检测的机制,就能够有一个比拟无效的进攻。定制Linux Kernel Patch,一些非凡的资源隔离或者安全漏洞,也能够为kernel打一些本身特有的patch来加以防备,然而这里的patch面临的问题是多种多样的,所以这里就不再开展细讲了,如果有关注的同学能够参考一下腾讯对于Linux Kernel方面的一些文章和报道。容器运行时上述平安实际计划和措施可能很大水平的缩小对外提供服务时受攻打的范畴,进步容器服务的平安能力。但咱们依然想要寻找一种简略的、无效的、对立的runtime解决办法,咱们把眼光投入到CNCF runtime landscape,能够看到有多种解决方案。 简略梳理一下这些解决方案,都是依照两大规范划分的。一个就是CRI的规范,偏差于kubelet或者K8s这一侧的规范。还有一侧的规范就是OCI,就是偏差于容器底层根底实现。 ...

August 18, 2020 · 1 min · jiezi

关于腾讯云:基于Rustvmm实现Kubernetes运行时

随着容器及K8s的宽泛应用,越来越多的容器平安与隔离问题被裸露进去,如:容器逃逸、程度攻打、DDos攻打等严重威胁了办公和生产环境的平安与稳固,影响了业务的失常运行。平安容器技术孕育而生,产生了kata、gVisor、unikernel等多种平安容器计划。本文旨在介绍各种平安容器计划,剖析各计划特点,联合腾讯在容器平安畛域的实际,帮忙读者抉择适宜本身个性的容器运行时。同时引入Rust-VMM我的项目,介绍 Rust-VMM 技术和生态,演示如何应用K8s调度和启用Rust-VMM平安容器运行时,瞻望以Rust语言实现的容器运行时的广大前景。 容器平安与隔离一个基于K8s集群构建的基础设施中,外部存在不同档次的隔离,从容器到Pod再到节点最初到cluster,每一层隔离都有它的特点和个性,咱们尤其关注Pod级别的隔离个性。 相比其余档次的平安隔离,Pod及容器级别的隔离对咱们的挑战十分大。容器在运行时应用root运行过程,只管应用namespace技术为容器空间内的pid、uts、fib等进行了隔离,但因为各个容器共享零碎内核,容器与内核间不足隔离爱护,容易引发容器逃逸等平安问题,典型容器逃逸攻打如:CVE-2018-14634、CVE-2016-5195、CVE-2019-5736 及 CVE-2019-14271等。 docker.vh.neargle.com:8888/?command_exec=python3 -c "import docker;client = docker.DockerClient(base_url='unix:///var/run/docker.sock');data = client.containers.run('alpine:latest', r'''sh -c \"echo 'ssh-rsa xxxxx root@620e839e9b02' >> /tmp/root/root/.ssh/authorized_keys\" ''', remove=True, volumes={'/': {'bind': '/tmp/root', 'mode': 'rw'}})"上述脚本是一个简略的例子,这段代码会向docker.sock的端口发动申请,拉起一个alpine的容器,容器内过程会向所在主机注入一段SSH的公钥。在容器里的歹意用户或者攻击者,就能够获轻松得这个容器所在host主机的SSH的登录权限,从而可能非法查看同主机其余容器空间的信息,篡改要害文件或记录,甚至以主机为跳板攻打整个集群。 还有一个就是Noisy Neighbor,就是吵闹街坊问题。对于Noisy Neighbor,容器方面曾经有了很多停顿,比方对于CPU、memory、bandwidth甚至是buffer IO,基于Cgroup对这些资源曾经有了一些隔离和限度,然而这些限度并不能齐全解决Noisy Neighbor的问题,还是有一些吵闹的过程会影响到失常的业务过程的运行。 # kubectl run --rm -it bb --image=busybox sh/ # f(){ f|f& };f # WARNING: Don't try this!下面是一个简略的例子,启动一个busybox的容器,在外面执行一个嵌套循环的指令,会把这台主机上所有的file descriptor全副耗尽,造成这台主机上失常运行的业务过程工作不失常,这个是Noisy Neighbor的危险和问题。 对于上述问题,倡议用户关注官网的破绽报告,降级操作系统或docker的版本,依据平安指引配置容器环境,同时能够参考以下措施加强容器集群的平安防护级别。 在物理层面上隔离,为不同的租户之间划分不同的Hardware Isolation域,让不同的租户应用不同的硬件空间,从物理上、网络上以及存储上彻底的隔离,这也是最间接最无效的办法。利用一些Security Tools,包含常常用的SElinux或者Cgroup隔离,划分不同的资源拜访和平安规定,然而这些平安规定须要编写大量的profile文件,实现起来难度颇大。入侵检测机制,主机进攻的一种伎俩。入侵检测的软件或者过程会监控这台主机上有危险的过程或者有危险的文件,对于这些文件的读写操作都会有平安方面的记录,会即时预警,即时响应。比方对于containerd-shim/busybox/docker-runc的要害过程,比方docker-runc对于bash、init或者对于fd的拜访都能够做到即时的预警和标记。对于下面提到的容器逃离破绽,通过入侵检测的机制,就能够有一个比拟无效的进攻。定制Linux Kernel Patch,一些非凡的资源隔离或者安全漏洞,也能够为kernel打一些本身特有的patch来加以防备,然而这里的patch面临的问题是多种多样的,所以这里就不再开展细讲了,如果有关注的同学能够参考一下腾讯对于Linux Kernel方面的一些文章和报道。容器运行时上述平安实际计划和措施可能很大水平的缩小对外提供服务时受攻打的范畴,进步容器服务的平安能力。但咱们依然想要寻找一种简略的、无效的、对立的runtime解决办法,咱们把眼光投入到CNCF runtime landscape,能够看到有多种解决方案。 简略梳理一下这些解决方案,都是依照两大规范划分的。一个就是CRI的规范,偏差于kubelet或者K8s这一侧的规范。还有一侧的规范就是OCI,就是偏差于容器底层根底实现。 ...

August 18, 2020 · 1 min · jiezi

关于腾讯云:发布更新|腾讯云-Serverless-产品动态-20200813

一、云函数 SCF + Ckafka 联结转储计划正式公布公布工夫: 2020-08-06 产品背景: SCF + Ckafka 联结转储计划能够帮忙用户节俭应用与开发成本,用户能够将 Ckafka 音讯转储同步转储至音讯队列 Ckafka,用于 Ckafka 集群间的数据同步。 产品性能 高度可定制化反对自定义换行符、数据筛选等,帮忙开发者疾速实现 Ckafka 各种的场景转储服务。转储音讯队列 Ckafka 的计划将应用云函数 SCF 的 Ckafka 触发器进行,通过 Ckafka 触发器将音讯同步至音讯队列另一个集群内。产品文档: https://cloud.tencent.com/doc... 二、Serverless CICD 解决方案正式公布公布工夫: 2020-08-06 产品背景: 应用 Serverless 利用的用户,每次批改代码后都须要执行部署命令去更新。通过与 Coding CICD / GitHub CICD 能力联合,能实现自动化部署,主动公布,晋升开发效率。 产品性能: 配置 Coding CICD / GitHub CICD 对应的 Pipeline,当用户推送代码到指定分支时,执行主动部署事件。 产品文档: https://cloud.tencent.com/doc... 三、API 网关新版控制台概览页正式公布公布工夫: 2020-08-06 产品背景: API 网关之前的控制台概览页较为繁多,展现的信息较少,告警等全局配置项不足入口。 产品优化: 从单栏式的概览页改为双栏式,新增疾速入口、异样告警、配额限度、最新布告等四个特色模块,晋升用户体验 产品体验: https://console.cloud.tencent... One More Thing立刻体验腾讯云 Serverless Demo ???? serverless/start ...

August 13, 2020 · 1 min · jiezi

关于腾讯云:腾讯云-Serverless-支撑新东方核心业务算力资源

谈起 Serverless 计算,在技术圈热度很高 —— 所有人都在说 Serverless,大家都宣称在做 Serverless,但每个 Serverless 又不一样。咱们不禁想问,Serverless 是不是只是一个炒热度的空洞热门词? 其实不然,Serverless 作为一种更易用、低成本、免运维的通用计算服务,曾经在互联网外围业务中承当重要的算力角色,实用于各种计算利用场景。也正是因为其作为通用计算撑持,场景泛滥,业内应用 Serverless 计算的场景笼罩宽泛,随处可见。 纵观国内 Serverless 畛域,腾讯云 Serverless 已在泛滥互联网计算服务场景中施展重要的作用。腾讯云 Serverless 技术已广泛应用于数百家企业,成为企业外围业务的撑持,是早曾经成熟的技术。咱们熟知的 58 短信、百视通、新东方、腾讯地图等企业的视频转码计算的业务,曾经齐全基于腾讯云 Serverless 计算服务撑持。 在新东方的外围业务 —— 课程视频转码计算的业务中,曾经基于腾讯云 Serverless 计算服务落地。个别的业务场景对资源的需要通常有两类,一类是计算密集型,须要弱小的计算力反对;一类是 I/O 密集型,偏重于网络和存储。对于新东方来说,随着在线教育行业的炽热,线上教育正逐步成为新东方的外围业务。而新东方的外围业务中的视频转码局部就是计算密集型业务,须要性能弱小又经济耐用的算力解决方案。 背景在视频利用、社交利用等场景下,用户上传的图片、音视频的总量大、频率高,对解决零碎的实时性和并发能力都有较高的要求。传统的容器服务,须要用户本人保护容器集群,弹性伸缩效率较低。 如果应用腾讯云 Serverless 云函数,当用户上传的视频短片,能够应用多个云函数对其别离解决,对应不同的清晰度,例如:1080p、720p 等,能够满足不同场景下用户的需要,同时,也满足挪动网络带宽较小且不稳固的个性。 腾讯云 Serverless 云函数在视频利用、社交利用等场景下的外围价值: 高效整合:凭借云函数(SCF)的弱小联动能力,将视频上传、视频解决、图片解决、存储场景有机地整合为一体。灵活处理:用户能够自定义转码函数,帮忙客户疾速搭建定制化工作解决能力,补救以后独自云服务的性能盲点。平滑迁徙:能够把 ffmpeg 业务不便地从物理机、云主机或容器中移植到云函数。老本低廉:腾讯云首发 1 毫秒计费粒度,真正实现了按理论用量计费,绝对传统计算服务,帮忙用户取得显著的老本劣势。运行原理应用云函数 + ffmpeg 和 COS 联动做音视频转码的运行原理如下图: 比照劣势(和传统容器服务) 如上图所示:在实现方面,两者差异不大;开发流程上,云函数更加简略高效;云函数自带能力较欠缺,如果须要对接自建平台,起 agent 不如容器计划简略。在运维方面,云函数更加易用和省心,在费用方面,云函数相比容器服务可节俭费用 30% 以上。 应用腾讯云 Serverless 云函数实现音视频转码服务的劣势: 云函数提供规范运行环境,并且保障资源的高可用和弹性伸缩,无需专人保护;云函数基于理论业务耗费免费,不存在资源节约;云函数的开发调试流程效率会更加高效,依赖和业务解耦,能够别离独自更新,反对实时热更新;运行环境隔离,单次申请失败不影响其余申请的失常执行。当然,当现有业务引入云函数时,须要留神以下两点: 云函数的引入,须要对接现有 CI/CD 流程,开发方式上有肯定的转变;现有业务代码须要做肯定的革新:次要在 ffmpeg 的编包上(云函数能够提供编包工具、提供相干)。客户案例:新东方上面咱们以新东方为例,看看新东方是如何实现业务迁徙,应用腾讯云 Serverless 云函数的。 ...

August 11, 2020 · 1 min · jiezi

关于腾讯云:腾讯云-Serverless-CICD-自动化部署实战

本文将为大家解说 Serverless 工作原理、架构劣势和 Serverless 利用的开发流程,以及如何应用 Serverless CI/CD 能力进行自动化部署。 本次和大家分享的提纲如下: 什么是 Serverless CI/CD? Serverless 介绍Serverless 架构CI/CD 与 Serverless CI/CDServerless CI/CD 利用 Serverless 利用开发流程Serverless CI/CD 劣势Serverless CI/CD 实战 基于 Coding CI/CD 的自动化部署基于 Github CI/CD 的自动化部署什么是 Serverless CI/CD?1. Serverless 介绍下图一张逻辑架构图,最下面application,上面是系统资源。咱们能够通过虚拟机、容器、数据库、存储等来提供系统资源。同时,咱们须要对这些系统资源进行保护,比方资源申请、环境搭建、容灾、扩缩容等。 Serverless 是什么呢?Serverless 就是把底层的这些资源以及对这些资源的运维都交给云厂商来保护、这些资源对业务来说是黑盒的,业务只须要关注本人业务逻辑的开发即可。 这种架构思维和办法就是 Serverless。 Serverless 直译过去叫无服务器,实际上他不是真的不须要服务器,只不过服务器由云厂商来保护。Serverless 是一种软件系统架构思维和办法,不是软件框架、类库或者工具,它的核心思想:毋庸关注底层资源,比方:CPU、内存和数据库等,只需关注业务开发。 2. Serverless 架构Severless 的架构如下图所示。客户端申请将发送的 API 网关,由云函数进行解决,调用底层资源进行返回。利用云函数主动伸缩的劣势,罢黜用户运维的懊恼。 应用 Severless 开发利用,能打消传统海量服务器组件需要,升高开发和运维复杂性。Serverless 按需调用,按需伸缩,按应用免费,升高启动老本。因为底层资源调配工作都由云厂商解决,用户只需专一业务逻辑开发即可。 3. CI/CD 与 Serverless CI/CDCI/CD 是 继续集成(Continuous Integration)和继续部署(Continuous Deployment)的简称。指在开发过程中主动执行一系列脚本来减低开发引入 bug 的概率,在新代码从开发到部署的过程中,尽量减少人工的染指。 ...

August 7, 2020 · 1 min · jiezi

关于腾讯云:通过腾讯云-Serverless-Regsitry-快速开发与部署一个-WordCount-实例

在学习 MapReduce 的过程中,不少人接触的第一个我的项目就是单词计数。单词计数通过两个函数 Map 和 Reduce,能够疾速地统计出文本文件中每个单词呈现的个数,它尽管简略,但也是最能体现 MapReduce 思维的程序之一。而 Serverless 的呈现,为 MapReduce 进行大数据处理又提供了一个新的部署计划,Serverless 与 MapReduce 到底如何联合呢? 本文将通过一个简略的教程,领导大家疾速开发一个基于 MapReduce 的 WordCount 利用模版,并在 Serverless 利用核心 Registry 里实现复用。 前提条件已装置 Serverless Framework,并保障您的 Serverless Framework 不低于以下版本: $ serverless –vFramework Core: 1.74.1 (standalone)Plugin: 3.6.14SDK: 2.3.1Components: 2.31.6实现概要上面是该实例的实现流程: 创立函数与 COS Bucket。用户将对象上传到 COS 中的源存储桶(对象创立事件)。COS Bucket检测到对象创立事件。COS 调用函数并将事件数据作为参数传递给函数,由此将 cos:ObjectCreated:* 事件公布给函数。SCF 平台接管到调用申请,执行函数。函数通过收到的事件数据取得了 Bucket 名称和文件名称,从该源 Bucket中获取该文件,依据代码中实现的 wordcount 进行字数统计,而后将其保留到指标 Bucket 上。部署胜利后,本模版将会为您创立以下资源: 两个 SCF 函数:Mapper 和 Reducer。三个 COS Bucket:srcmr、middlestagebucket 和 destmr。Mapper 函数将会绑定 srcmr 触发,Reducer 函数将会绑定 middlestagebucket 触发,destmr 将会用来接管最终的统计后果。开发步骤通过 COS 组件实现创立上传文件的 COS 存储桶的配置文件编写,yml 文件配置如下# serverless.ymlorg: serverlessapp: MapReduce_Demostage: devcomponent: cosname: destmrinputs: bucket: destmr region: ap-guangzhou同理,实现其它两个存储桶配置。 ...

August 5, 2020 · 3 min · jiezi

关于腾讯云:腾讯云-Serverless-产品动态-20200730

一、Serverless Framework 反对 - debug 命令打印部署日志正式公布公布工夫: 2020-07-28 产品介绍: 用户在进行部署和移除 Serverless 利用时,提供日志记录的能力,如果部署失败,用户能够依据部署日志查问失败的具体起因,并针对性的进行批改。 产品性能: 用户运行 sls deploy 或者 sls remove 命令时,减少 --debug 参数,即可输入每个步骤具体的部署日志。反对单组件的部署记录输入,也反对在利用的根目录下,对整个利用的部署流程进行日志输入和查看。产品文档: https://cloud.tencent.com/doc... 二、Serverless Framework 新版利用监控可视化页面正式公布公布工夫: 2020-07-28 产品介绍: 新版本的 Serverless Framework 利用监控可视化页面,用户可查看到整个利用的组织构造,利用蕴含的实例,实例的环境辨别信息等,构造层次分明,不便用户更便捷的治理利用。 产品新增性能: 反对利用级别的聚合展现,每个利用下若蕴含多个实例,别离展现。反对每个实例中的环境隔离展现。反对利用检索。产品体验: https://serverless.cloud.tenc... 三、云函数 SCF 反对预置并发正式公布公布工夫: 2020-07-27 产品介绍: 云函数 SCF 预置并发反对并发实例按配置事后启动,而不是在承受申请时才启动。 通过此性能,为函数的指定版本设定预置并发数量,事后进行计算资源的筹备,以此升高冷启动、并发实例及业务代码初始化引起的耗时,升高对业务的影响。 产品性能: 反对函数已公布的版本设定冀望数量的预置并发数。预置并发在配置实现后即开始启动。当云函数后盾实现预置并发的扩容时,可按需批改并发数。当不再打算应用某个预置并发配置时,可进行删除操作。产品文档: https://cloud.tencent.com/doc... One More Thing疾速体验腾讯云 Serverless Demo 并支付老手代金券 ???? serverless/try 欢送拜访:Serverless 中文网!

July 31, 2020 · 1 min · jiezi

关于腾讯云:又双叒叕是第一腾讯云-Serverless-云函数怎么可以这么优秀

首个通过可信云认证,取得 FaaS 畛域 1 号证书腾讯云 Serverless 云函数第一个取得可信云认证! 刚刚,在 2020 中国可信云大会上传来喜讯,腾讯云凭借在云函数畛域的卓越问题,取得了国内 FaaS(Function as a Service,函数即服务)畛域首张可信云认证,代码编号「FaaS-0001」,这意味着腾讯云在 FaaS 畛域的实力取得国家权威认可。 第三方权威机构 FaaS 评测国内第一腾讯云 Serverless 云函数在 Forrester 评测中,国内第一,寰球前三! 往年 3 月份,独立的寰球征询与服务机构 Forrester 公布《TheForrester New WaveTM: Function-As-A-Service Platforms, Q1 2020》报告指出,腾讯云 FaaS 能力凭借在产品体验、安全性、策略愿景等方面的劣势,综合评分位居寰球前三,成为中国惟一进入寰球 Top 3 的云厂商。Forrester 官网给予「强劲表现者」评估。 Serverless 技术的衰亡,让 FaaS 成为继 IaaS、PaaS、SaaS 之后一种新的计算能力提供形式。它让用户更加聚焦业务自身,而无需关注简单的服务器配置和治理,包含弹性部署和主动扩容等工作全副交给云厂商,省去了大量的运维操作,被普遍认为是下一代云计算倒退的重要方向,包含亚马逊、谷歌、微软等国内顶级云厂商都在该畛域减速布局。 近年来,腾讯云在 FaaS 畛域继续发力,势头迅猛。包含在策略层面全面聚焦解决开发者痛点,针对 Serverless 架构下的开发、运维、调试和部署等全生命周期的能力建设,落地 Serverless 开发的全云端闭环体验,也为开发者提供了企业级 Serverless 我的项目上云的最佳实际。 寰球独创 1ms 计费粒度腾讯云 Serverless 云函数第一个反对 1ms 计费粒度,实现真正按用量计费。 同时,往年上半年,腾讯云 Serverless 寰球首发的 1 毫秒的计费粒度更是独步寰球。进一步升高用户的资源老本,防止资源节约,真正实现按需付费。此外,4月份,腾讯云对外公布国内首个 Serverless 数据库新品 —— PostgreSQL for Serverless。据介绍,该数据库相比一般云上数据库,可能最快1秒实现部署,且老本可升高 70%。 ...

July 30, 2020 · 1 min · jiezi

关于腾讯云:又双叒叕是第一腾讯云-Serverless-云函数怎么可以这么优秀

首个通过可信云认证,取得 FaaS 畛域 1 号证书腾讯云 Serverless 云函数第一个取得可信云认证! 刚刚,在 2020 中国可信云大会上传来喜讯,腾讯云凭借在云函数畛域的卓越问题,取得了国内 FaaS(Function as a Service,函数即服务)畛域首张可信云认证,代码编号「FaaS-0001」,这意味着腾讯云在 FaaS 畛域的实力取得国家权威认可。 第三方权威机构 FaaS 评测国内第一腾讯云 Serverless 云函数在 Forrester 评测中,国内第一,寰球前三! 往年 3 月份,独立的寰球征询与服务机构 Forrester 公布《TheForrester New WaveTM: Function-As-A-Service Platforms, Q1 2020》报告指出,腾讯云 FaaS 能力凭借在产品体验、安全性、策略愿景等方面的劣势,综合评分位居寰球前三,成为中国惟一进入寰球 Top 3 的云厂商。Forrester 官网给予「强劲表现者」评估。 Serverless 技术的衰亡,让 FaaS 成为继 IaaS、PaaS、SaaS 之后一种新的计算能力提供形式。它让用户更加聚焦业务自身,而无需关注简单的服务器配置和治理,包含弹性部署和主动扩容等工作全副交给云厂商,省去了大量的运维操作,被普遍认为是下一代云计算倒退的重要方向,包含亚马逊、谷歌、微软等国内顶级云厂商都在该畛域减速布局。 近年来,腾讯云在 FaaS 畛域继续发力,势头迅猛。包含在策略层面全面聚焦解决开发者痛点,针对 Serverless 架构下的开发、运维、调试和部署等全生命周期的能力建设,落地 Serverless 开发的全云端闭环体验,也为开发者提供了企业级 Serverless 我的项目上云的最佳实际。 寰球独创 1ms 计费粒度腾讯云 Serverless 云函数第一个反对 1ms 计费粒度,实现真正按用量计费。 同时,往年上半年,腾讯云 Serverless 寰球首发的 1 毫秒的计费粒度更是独步寰球。进一步升高用户的资源老本,防止资源节约,真正实现按需付费。此外,4月份,腾讯云对外公布国内首个 Serverless 数据库新品 —— PostgreSQL for Serverless。据介绍,该数据库相比一般云上数据库,可能最快1秒实现部署,且老本可升高 70%。 ...

July 30, 2020 · 1 min · jiezi

关于腾讯云:京东智联云在-Serverless-的探索

本文整顿自 ServerlessDay · China 大会 - 《京东智联云在 Serverless 的摸索》的分享,讲师为京东智联云的 PaaS 产品负责⼈朱琅。本文次要分为三局部: ⾸先会介绍下 Serverless 的概念和定义,期间会讲讲我个⼈对 Serverless 的了解;第⼆局部,我会着重介绍下 Serverless 在京东智联云的应⽤;最初,会讲述我对 Serverless 将来的瞻望。Serverless 的概念和定义提到 Serverless,⼤家基本上第⼀工夫会想到的就是 AWS lambda,没错,让 Serverless 这个名称真正⽕起来的其实就是 AWS 推出的 FaaS 服务 -- Lambda,它是⼀个平台,容许你在云上容许独⽴的代码段,通过事后设置好的事件触发代码的运⾏。 除了 FaaS 之外,还有BaaS,尽管和 Blockchain as a Service 的缩写⼀样,但它其实是 Backend as a Service -- 后端即服务的缩写,⽆需编写/治理所有服务端组件,与虚拟机和容器相⽐,概念上更靠近 SaaS(软件即服务),BaaS 服务都是畛域通⽤的组件服务,通过 API 调⽤的⽅式来使⽤。 说完了定义,再来看下 Serverless 的发展史。 最早能够追溯到 2006 年,Zimki 推出的代码执⾏平台,它是⾸个提出按使⽤免费的服务;接着就是 2011 年的 Parse,它提供了 BaaS 框架,⽅便⽤户基于它更快的构建应⽤程序,起初是被 Facebook 收买;到了 2012 年,相继有 Fribase 和 IronWorker 服务,前者是⼀个针对挪动端的应⽤开发平台,起初被 Google 收买了,后者是基于容器的应⽤负载平台;到了 2014 年,也就是 AWS 推出了 Lambda,⾸个云上的 FaaS 服务,将 Serverless 概念带到了⼤众的视线中;紧接着在 2016年,Google,Azure,IBM 别离在他们的云服务上上线了 FaaS 服务。 ...

July 28, 2020 · 2 min · jiezi

关于腾讯云:如何优雅地部署一个-Serverless-Nextjs-应用

上一篇 前端福音:Serverless 和 SSR 的天作之合,具体介绍了 SSR 相干常识,同时也提到了 Serverless 给 SSR 计划带来的福利。但它只是将 Next.js 利用部署到 Serverless 服务上而已,并不适宜理论生产业务。为此本篇专门针对 Next.js 的 SSR 计划进行了摸索和优化,一步一步带大家理解,如何基于 Serverless 架构部署一个理论的线上业务。 领先体验:serverless-cnode本文次要内容: 如何疾速部署 Serverless Next.js如何自定义 API 网关域名如何通过 COS 托管动态资源动态资源配置 CDN基于 Layer 部署 node_modules如何疾速部署 Serverless Next.js因为自己对 Serverless Framework 开发工具比拟相熟,并且长期参加相干开源工作,所以本文均应用 Serverless Components 计划进行部署,请在开始浏览本文之前,保障以后开发环境曾经全局装置 serverless 命令行工具。本文仍然上一篇中介绍的 Next.js 组件 来帮忙疾速部署 Next.js 利用到腾讯云的 Serverless 服务上。 咱们先疾速初始化一个 Serverless Next.js 我的项目: $ serverless create -u https://github.com/serverless-components/tencent-nextjs/tree/master/example -p serverless-nextjs$ cd serverless-nextjs该我的项目模板曾经默认配置好 serverless.yml,能够间接执行部署命令: $ serverless deploy大略 30s 左右就能够部署胜利了,之后拜访生成的 apigw.url 链接 https://service-xxx-xxx.gz.apigw.tencentcs.com/release/ 就能够看到首页了。 ...

July 23, 2020 · 4 min · jiezi

关于腾讯云:Serverless-应用实践及典型案例解析

本文整顿自 ServerlessDay · China 大会 - 《Serverless 利用实际及典型案例解析》的分享,讲师为腾讯云 Serverless 高级架构师卢萌凯、猎豹挪动前端总监董文枭、江娱互动技术经理董文强、新东方高级工程师李垦。本文次要分为四局部: Serverless 的劣势和价值基于 Serverless 构建 REST APIServerless 和服务端渲染的联合Serverless 构建音视频转码计划Serverless 的劣势和价值为什么咱们投入这么大工夫和精力来做 Serverless 呢?因为咱们深信云计算的将来趋势之一就是 Serverless。因为 Serverless 让云服务的利用变得更加简略、高效。比方用云主机部署利用的时候,不仅要搭建和保护环境,同时也要评估业务的资源用量,尤其是对于经营类的流动,如果一旦评估的不精确,要么会造成资源的微小节约,要么服务可能会被打爆,甚至停服下线。 而 Serverles 可能做到按需应用,让业务完满的弹性伸缩,对于运维同学来讲,几乎不能更爽。而且和预付费的实例不同,Serverless 是 pay as you go的模式,只有当业务运行时才会占用资源,只有源被占用了才会计费,简略来讲,就是,我理论用多少就付多少钱。这种计费模式对于存在显著波峰波谷的服务,劣势相当显著。 另外,云计算的倒退,肯定是让用户更加专一于业务。而对于运维来讲,那些繁琐的且对业务倒退没有外围价值的资源保护工作,就能够 offload 给云厂商,这样就能更加专一业务层面的运维。这就是 Serverless 所带来的价值,他不仅把用户对云的应用老本降到了最低,也最大水平上的减速了利用的上线过程。 咱们也能够回顾下云计算呈现及倒退的这些年里,和自建 IDC 相比,用户就是越来越聚焦业务,资源的应用效率也越来越高,而 Serverless 在当下把这些劣势做到了极致。 咱们再来简略看下云函数是怎么形成 Serverless 架构,以及Serverless利用具体是怎么运行的。 开发者在理论应用时,能够借助 WEB IDE 或者本地 IDE 实现代码开发,而后通过在线或者插件、工具的形式把代码以及所用到的相干依赖,一起打包部署到云函数平台,在代码里,咱们能够像传统开发方式一样去调用后端的 BaaS,比方拜访数据库、对象存储、音讯队列、第三方服务接口等。计算逻辑和后端服务独特形成了所谓的 Serverless 利用架构。 而终端用户依据平台提供的申请形式,去触发部署在云函数平台上的业务代码,比方发送 http 申请等,平台会依据用户的申请量去拉起相应的计算资源去运行用户代码。平台会保障资源的可用性和弹性伸缩,因而用户只用关注和聚焦业务及其运行状况。 基于 Serverless 构建 REST API接下来进入明天的正题,首先咱们来看下 REST API 这个场景。这里会用到 Serverless Framework 来辅助开发和部署。借助 Serverless Framework 的 SCF 组件,咱们能够把本地开发好的 REST API 利用疾速部署到云上,咱们只须要提前写好相应的 yaml。Serverless Framwork 会基于 yaml 里的配置信息,疾速创立云函数、API 网关等云资源。 ...

July 20, 2020 · 2 min · jiezi

ServerlessDays-China无服务器的未来

6 月 18 日举办的 ServerlessDays China 流动,技术大咖星散。来自加州大学伯克利分校,serverless.com,腾讯云和谷歌云等云计算畛域的学者与专家独特探讨了无服务器计算的最新翻新,用例和将来方向。 O'Reilly 在 2019 年对 1500 名 IT 专业人士的考察中,有 40% 的受访者在采纳无服务器架构的机构中工作。 公布于2020年的 DataDog 考察显示,当初有超过 50% 的 AWS 用户正在应用无服务器的 AWS Lambda 函数即服务(FaaS)。 无服务器技术正在成为支流。 Serverless Days 是无服务器技术的国内前沿技术盛会。来自业界和学术界的出名专家,就为什么无服务器风行一时、以及企业为什么要关注无服务器,分享了很多理论案例与洞见。 Johann Schleier-Smith 谈到了无服务器计算的历史和将来。他是《简化的云编程:Berkeley 对于无服务器计算的观点》论文的作者之一,该报告将无服务器计算定义为无状态 FaaS(函数即服务,例如 AWS Lambda)和有状态存储 BaaS(后端即服务,例如 AWS S3)。 在咱们的定义中,要使服务被认为是无服务器的,它必须在无需显式配置的状况下主动扩大,并依据应用状况进行计费。 — Berkeley 对于无服务器计算的观点依据 Schleier-Smith 的说法,无服务器计算曾经大大简化了零碎或基础架构治理,正进入简化利用程序开发的新阶段。无服务器 FaaS 基础架构有三种次要办法,都能够为执行用户提交的代码提供隔离和平安的沙箱。 FaaS 基础架构的第一种办法是应用零碎或硬件级别的虚拟机,例如 AWS Firecracker。这种办法为应用程序提供了最佳的隔离和安全性,但很慢并且治理起来很简单。云服务提供商会装置并疏导操作系统和运行时软件堆栈(例如,Node.js或 Python)以运行用户的代码。 AWS Lambda 的胜利证实了这种办法的可扩展性。第二种办法是应用容器,例如 Docker。容器由 Kubernetes 等解决方案治理。这种办法的安全性较差,但性能比零碎级虚拟机高得多。在执行任何用户代码之前,云服务提供商将应用操作系统和运行时堆栈来加载及启动容器镜像。第三种新兴办法是应用特定于应用程序的虚拟机,例如 WebAssembly。这种办法提供了高度的形象。 WebAssembly 虚拟机不须要绑定(bootstrap)本人的操作系统或软件堆栈,只执行编译后的字节码应用程序。 WebAssembly 提供了一个高级的“基于性能”的平安模型,用于拜访系统资源(例如,通过WASI 标准),而不是粗粒度的操作系统级隔离。然而,与操作系统容器不同,WebAssembly 的毛病是仅反对编译为 WebAssembly 字节码的应用程序。目前,仅反对 C/C ++,Rust 和AssemblyScript( TypeScript 的子集)。数据隔离有多种办法,应用程序能够依据须要抉择不同的办法。 — Johann Schleier-Smith这三种办法提供了一系列解决方案,并且在性能,安全性和易用性三者中获得均衡。随着技术的倒退,这三种办法之间的界限越来越含糊。例如,在零碎级 VM 和容器之间架起了桥梁,LightVM 办法尝试将相干的操作系统函数间接编译到 VM 中以实现更快的性能。 ...

July 15, 2020 · 1 min · jiezi

企业级-Serverless-应用实战

本文整顿自 ServerlessDay · China 大会 - 《企业级 Serverless 利用实战》的分享,讲师为腾讯云 Serverless 高级产品经理方坤丁。本文次要分为四个局部: Serverless 2020 : 趋势与挑战Serverless 典型场景部署企业级 Serverless 利用实战演示 : Serverless SSRServerless 2020 : 趋势与挑战首先,谈一下对于 Serverless 在 2020 的趋势。我大略是从 3-4 年前开始接触 Serverless,到了往年,发现有以下一些特色,我会把他们分成三个局部: 第一点,对于开发者来说,Serverless 通过按需付费、弹性扩缩容的个性,极大的赋能开发者,让他们关注于实现业务,而不须要思考底层资源。第二点,对于越来越多的企业来说,从2019年开始,他们逐渐开始尝试、深刻应用甚至拥抱 Serverless。因为 Serverless 可能显著的降低成本,并且缩小运维的工作。这对于企业来说,尤其是非科技企业来说,是有十分强的吸引力的。并且在 2020年,曾经能够看出更多的企业在借助 Serverless 来实现业务了。第三点,能够看到云服务和 Serverless 的联合越来越严密。方才也说到 BaaS 自身是 Serverless 中的重要局部。那么在 2020 年,越来越多的云服务,正在通过 Serverless 的形式提供。比方 PG SQL 提供了 Serverless DB ,Serverless HTTP,以及上午提到的 Serverless AI 等服务。 然而,与此同时,咱们也发现,随着这些趋势的倒退,也面临了不少的挑战,仍然分成三个方面来探讨: 对于开发者来说,怎么提供一个残缺的开发、调试和排障的能力,并且提供更弱小的扩大能力,是十分要害的。也就是生态的建设。对于企业来说,面临的问题更加细节,很多概念在工业化的实际中,都会遇到很多理论的问题。包含权限的划分、资源的治理、还有 CI/CD 等解决方案,怎么无缝适配到企业的架构中呢?最初,对于云来说,联合越发严密,然而云产品为了保障通用性和普适性,自身会有比较复杂的配置,并且云资源间接的组合须要带来比拟大的学习老本,也对于企业带来了不少挑战。 Serverless 典型场景那么,在和企业的实际中,咱们也发现 Serverless 对于几种典型的场景反对的十分优良,在这里也心愿和大家分享: ...

July 14, 2020 · 2 min · jiezi

基于-API-网关-云函数-SCF-部署-Serverless-外卖订单系统

API 网关联合云函数 SCF 的应用场景十分丰盛,本文将介绍如何基于 API 网关+云函数 SCF 疾速部署 Serverless 的外卖订单零碎。 音讯推送应用的典型场景 外卖订单零碎架构图 Demo 实战1. 装置Serverless Frameworknpm install -g serverless2. 初始化我的项目模板sls init -t websocket-order3. 查看我的项目目录下载到本地后,查看我的项目目录构造如下: 蕴含 DB、网关、函数等多个子模块。 db 目录用于创立 PG Serverless 数据库实例apigateway 用于创立对应的 API : /bill 下单 API,HTTP 类型/get_shop_info,获取店铺菜单 API/pgws,用于做音讯推送的 websocket API函数列表如下: 音讯推送相干函数: 注册函数 ws_register.py, 配置 DB 的环境变量传输函数 ws_trans.py ,配置 DB 的环境变量以及 apiid= 音讯推送API登记函数 ws_unregister.py ,配置 DB 的环境变量以及 apiid= 音讯推送API下单函数 bill.py , 配置 DB 的环境变量以及 apiid= 音讯推送API拉取店铺信息函数 get_shop_info.py,配置 DB 的环境变量初始化 DB 函数 init_db.py ,配置 DB 的环境变量4. 批改配置信息。将 .env.example 文件为 .env 文件,在 API 密钥治理 中获取 SecretId 和 SecretKey。# secret for credentialTENCENT_SECRET_ID=xxxxxxTENCENT_SECRET_KEY=xxxxxx# global configREGION=ap-shanghai我的项目部署sls deploy --all6. 更新配置及部署执行 init_db-dev 函数,进行数据库初始化。在控制台或者 vscode 插件中,点击测试 init_db-dev 函数,对数据库进行初始化的建表等操作更新 apiid 配置,再次部署 查看输入信息,在 function_bill 目录和 function_ws_trans 目录的 serverless.yml 中,别离配置 websocket API 的 apiid ,并重新部署两个函数,刷新环境变量配置。 ...

July 13, 2020 · 1 min · jiezi

如何购买腾讯云学生服务器图文教程

当初云服务商对学生都是很优惠的,腾讯云学生服务器腾讯云也推出了9.9元购买云服务器的优惠活动,是一款固定的优惠套餐,蕴含特价云服务器、域名(加钱可选)、收费对象存储空间(6个月),然而好多用户却不晓得在哪里申请,须要什么条件,流程是怎么样的,上面给大家做个介绍 学生服务器官网链接腾讯云学生服务器官网: https://cloud.tencent.com/act/campus套餐蕴含特价云服务器、域名(可选)、50G收费对象存储空间(6个月);每日限量100个,每个用户限购1个,并赠送2次体验价续费机会,优惠续费需在本页面进行。流动链接 流动对象面向腾讯云官网通过集体认证的在校大学生。 如果你是学生身份的话,速速注册腾讯云支付学生服务器。【注】企业用户、协作者、后付费用户暂不反对参加此流动。 流动规定特地留神:符合条件的用户可购买腾讯云服务器校园优惠套餐,套餐内蕴含云服务器,对象存储,域名(可选),可选产品需加价购买同一个身份证号码、手机号对应的多个账号仅限一个帐号购买特地留神:本套餐每日限量100个,每个用户限购1个,此前购买旧版学生套餐的用户也可购买流动购买的云服务器,每台服务器仅可绑定1个ip若晋升了配置,或调整了网络带宽,将无奈进行优惠续费不反对降配和带宽计费模式切换,退款后将不再保留购买资格购买产品若产生退款,参照官网退款规定本次流动不反对代金券领取学生服务器价格1个月3个月12个月(举荐)加购域名10元60元120元(举荐)额定加8元失常的1核2G内存的服务器价格是:71元到106元一个月;腾讯云CVM服务器失常价格查问 或者 腾讯云AMD云服务器失常价格查问 舒适揭示:你用学生身份购买了学生服务器一个月的话,一个月过完,你还想用服务器的话,就不能持续享有学生服务器价格了(以失常价格购买腾讯云服务器),所以机会只有一次,好好把握你的学生身份,举荐学生购买一年,不便彻底体验和相熟云服务器。 学生服务器有什么劣势?劣势一: 领有1核2G内存的服务器配置,价格非常低,性价比高。非学生服务器价格能够查问 腾讯云CVM服务器失常价格查问 或者 腾讯云AMD云服务器失常价格查问劣势二:享有腾讯云扶助大学生守业相干优惠政策。流动链接 劣势三:加入校园守业大赛,腾讯云校园招聘炽热启动 流动链接 劣势四:鞭策自我学习云计算,大数据,互联网以及编程等常识,轻松应答大学生待业问题。学生服务器能够用来干什么?服务器编程。编写各种web零碎,用java,PHP,pthyon,go等多种语言编写web零碎。间接部署在云服务器上,联合域名拜访,你就能让你的web零碎运行在互联网上,包含web演示站。建网站。利用wordpress为代表的建站程序疾速建设本人的网站,记录本人的学习历程,记录本人的生存,记录其它的相干有意义的事件。而后获取肯定访问量,前期利用广告来变现,百度联盟和谷歌广告。学习Linux网站运维。当初IT企业和互联网企业都须要大量的零碎运维人员。不便这一方面的同学待业。部署本人的开源产品,或者搭建一个git代码托管服务器。学生服务器期限和价格1个月3个月12个月(举荐)加购域名10元60元120元(举荐)额定加8元失常的1核2G内存的服务器价格是:71元到106元一个月;腾讯云CVM服务器失常价格查问 或者 腾讯云AMD云服务器失常价格查问 学生服务器与非学生服务器有什么区别?价格更便宜,配置雷同(1核2G内存),性能一样,不会升高服务器性能。学生服务器只能学生身份购买(通过腾讯云学生身份认证)非学生服务器,学生能够买,其它任何人也能够买,只是价格更高!文章起源:http://tencent.yundashi168.com/556.html

July 11, 2020 · 1 min · jiezi

如何将-Web-框架迁移到-Serverless

Serverless 通常翻译为「无服务架构」,是一种软件系统设计架构思维和办法,并不是一个开发框架或者工具。他的呈现是为了让开发者更加关注业务的开发,而将繁冗的运维和部署交给云厂商。Serverless 由 Faas 和 Baas 组成,Faas 为开发者提供业务运算环境,而后与 Baas 提供的数据和存储服务,进行交互,从而提供与传统服务统一的体验。然而因为 Faas 是无状态的,并且其运行环境是有读写限度的,最重要的是它是基于事件触发的。因而如果传统 Web 服务想迁徙到 Serverless 上,是须要进行相干革新和非凡解决的,为此迁徙老本是必不可少的。本文将具体帮忙大家分析下,如何 Serverless 化传统的 Web 服务。 读完本文将理解到: 传统 Web 服务特点Serverless 实用场景Web 框架如何迁徙到 Serverless应用 Serverless Components 疾速部署 Web 框架传统 Web 服务特点Web 服务定义: Web 服务是一种 面向服务的架构 (SOA) 的技术,通过规范的 Web 协定提供服务,目标是保障不同平台的应用服务能够互操作。日常生活中,接触最多的就是基于 HTTP 协定的服务,客户端发动申请,服务端承受申请,进行计算解决,而后返回响应,简略示意图如下: 传统 Web 服务部署流程:通常须要将我的项目代码部署到服务器上,启动服务过程,监听服务器的相干端口,而后期待客户端申请,从而响应返回处理结果。而这个服务过程是常驻的,就算没有客户端申请,也会占用相应服务器资源。 个别咱们的服务是由高流量和低流量场景交替组成的,然而为了思考高流量场景,咱们须要提供较高的服务器配置和多台服务进行负载平衡。这就导致服务处在低流量场景时,会多出很多额定的闲置资源,然而购买的资源却须要依照高流量场景进行付费,这是十分不划算的。 如果咱们的服务能在高流量场景主动扩容,低流量场景主动缩容,并且只在进行计算解决响应时,才进行免费,而闲暇工夫不占用任何资源,就不须要免费呢? 答案就是 Serverless。 Serverless 实用场景下面曾经提到了 Serverless 的两个外围特点:按需应用和免费 和 主动扩缩容。而且近几年 Serverless 的利用也越来越宽泛,然而它并不是银弹,任何技术都是有它的适宜场景和不适宜场景。咱们不能因为一项技术的炽热,而自觉的追捧。Serverless 是有它的局限性的,个别 Serverless 适宜如下几种场景: 异步的并发,组件可独立部署和扩大应答突发或服务使用量不可预测无状态,计算耗时较短服务申请延时不敏感服务须要疾速开发迭代的业务如果你的服务不满足以上条件,笔者是不举荐迁徙到 Serverless。 Web 框架如何迁徙到 Serverless如果你的服务是以上提到的任何话一个场景,那么就能够尝试迁徙到 Serverless 上。 ...

July 10, 2020 · 4 min · jiezi

Serverless-CVM-实战

之前了解过 Tencent Serverless Toolkit for VS Code 的IDE 插件,刚好借此使用下,相较于之前没有 IDE 插件,编码在本地,但是 debug 非常繁琐,需要上传代码到云端控制台操作,现在有了 IDE 插件从本地编码测试上传部署一条路,快速体验下此为 SCF 添翼的神器。 接下来看看 Serverless + CVM 实战 项目背景目前有客户有需求对数量众多的测试环境想通过非工作时间进行关机操作,同时腾讯提供关机不收费的 CVM 操作,一定程度可以节省 IT 开支,每天早上工作时间提前进行开机,如此如果人工来操作重复周期性的操作显然非常不合适,但是共有云目前没有提供这种对服务器定时开关机操作的产品功能,只能利用其 API 来进行,但是需要一台具备公网能力的服务器来发起API调用请求,此时刚好利用 Serverless 的 Tencent Serverless Toolkit for VS Code 小试牛刀,本次示例利用腾讯云函数(SCF)简单示例下 Serverless 的一小部分功能。 之前由于没有IDE,将程序部署到SCF后运行不便与调试,现在有了神器Tencent Serverless Toolkit for VS Code,简单方便的本地配置,快速拉取云端函数并可以在本地模拟COS,CMQ,API网关等出发事件运行还书,本地化的开发,调试,可谓补齐了SCF不便于代码上传调试的缺点,利用此插件可在本地快捷调试代码,一键上传程序,为SCF如虎添翼。 项目编写1. 根据模版创建项目 2. 填写项目名称填写项目名称完成项目创建 3. 了解项目结构在项目模版中,主要关注index.py 和template.yaml Index.py 为业务逻辑代码Template.yaml 为腾讯云SCF配置相关,如下为我的定时任务配置为提高安全性其中由于使用的了腾讯云的secretid/secretkey,将其作为变量放置在配置中,业务代码从配置中获取, 其中也配置了超时时间以及定时cron Resources: default: Type: TencentCloud::Serverless::Namespace cvm_oper: Properties: CodeUri: . Description: cvm oper Environment: Variables: secretid: AKIDZyGxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx secretkey: kFUTDkxxxxxxxxxxxxxxxxxxxxxxxx Events: stop_cvm: Properties: CronExpression: 0 59 11 * * MON-FRI * Enable: true Type: Timer Handler: index.main_handler MemorySize: 128 Runtime: Python3.6 Timeout: 10 VpcConfig: SubnetId: '' VpcId: '' Type: TencentCloud::Serverless::Function ...

July 7, 2020 · 1 min · jiezi

Serverless-Registry-设计解读与实战

在 6 月 19 日的 ServerlessDays China 大会中,Serverless 发布了一款全新的产品: Serverless Registry,它究竟是怎样的一款产品,为我们解决了哪些用户痛点呢? 接下来将为大家进行具体解读。 一、设计理念相信大家对 Serverless 的组件化开发流程都不算陌生了,但作为开发者,在使用 Serverless 组件进行项目开发时,各位可能会遇到这样的疑惑: Serverless 目前究竟支持哪些组件?除了跳到官网查看文档,有没有其更快捷的方法了解各组件的基本信息?我开发了自己的组件模版后,应该如何分享给他人进行复用?面对用户的使用痛点,我们希望设计一款组件模版管理产品,它可以: 支持组件或模版的可视化展示与查询,方便用户快速定位目标模版并进行部署;支持查看组件或模版的详细信息,使用说明,并提供源代码下载路径,保证整个使用流程的透明化;支持组件的共享与复用,所有上传后的组件模版都是公开的,打造开源生态的 Serverless 模版仓库。基于这些目标,Serverless Framework 的可视化模版仓库 Serverless Registry 应运而生。 二、功能简介Serverless Regsitry 的基本功能很简洁,主要为以下两点: 组件模版的发布上传在腾讯云官方的文档中已经为大家介绍了组件开发流程规范,作为开发者,用户可以基于官方流程,自主开发组件或模版,通过 Serverless Framework CLI,将其发布到 Registry 上,所有发布到 Registry 的项目均支持复用,其中优秀的项目会作为推荐模版,显示到 Registry 官网上,增加宣传和曝光度。 组件模版的复用对于组件模版的使用者而言,用户通过 Registry 官网或者 Serverless Framework CLI,都可以快速获取到组件或者模版的信息,并支持项目源代码的下载复用,完成项目的快速部署,操作流程简单方便,对于新手来说也会十分友好。 Registry 官网介绍页面目前有三个入口: 直接输入 https://registry.serverless.com/serverless 中文网「模版仓库」模块进入Dashboard 控制台您可以根据使用习惯来进入 Registry 的页面 进入页面后,看到整个界面是非常清晰,您可以迅速掌握目前支持的组件列表以及组件的基本信息。 当组件过多的时候,可以通过搜索栏迅速找到您想使用的组件,目前支持组件名称、标签、简介等多个关键词搜索。 点开组件详情页,可以看到该组件的全部信息,顶部标签栏介绍了组件的版本、作者、发布日期等基本信息,介绍页具体介绍了组件的产品特性和使用教程,哪怕您对该组件并不了解,也可以通过详情页基本掌握组件的信息和使用方法,对于新手来说是非常友好的部署体验。 除此之外,部分组件已经支持一键部署,点击按钮后,直接跳转到 Dashboard 控制台,快速部署一个组件模版。 往期回顾Tencent Serverless Hours 第一期线上分享会回放Tencent Serverless Hours 第二期线上分享会回放Tencent Serverless Hours 第三期线上分享会回放One More Thing3 秒你能做什么?喝一口水,看一封邮件,还是 —— 部署一个完整的 Serverless 应用? ...

July 6, 2020 · 1 min · jiezi

使用-ServerLess-实现云原生

笔者有幸经历了 IaaS(OS)、CaaS(Container),在这两年又听到了 FaaS(Funtion),这也是运维开发领域里的第三个阶段了吧,今天我将从一个不懂得开发的系统工程师视角以及结合之前的几篇系列文章为各位诠释这个概念。 本文来自 Serverless 社区用户「StatLee」投稿一、简述一开始听到 ServerLess 我以为是类似于 VPS(建站主机)亦或者是 VM、Container 之类的具备完整 OS 或半完整 OS 生态的一个全新开发方式,后来发现我完全理解错了,如果说传统的云计算是这样分层的: 那么 FaaS(ServerLess 为代表的的 Funtion As A Service)就是把 SaaS 再进行精细化拆分,可以看这张图就明白了(特别是红圈部分): 传统以为 Application 就是业务的最终形态,可是随着以开发领域为首的「微服务」及运维领域为首的「SRE/DevOps」理念出来后,传统的业务运维明显已经不能满足新一代业务的需求,为了更贴合这些新的需求,实现: 模块拆分化(即一个功能作为一个模块,而非一个业务作为一个模块)最小颗粒化变更(即分层变更,变更时通过合理调度时变更间隔缩短,实现快速迭代)的目的云厂商最终在以往的「最终形态」上又拆分了 Function 出来,多个 Function 再组成 Application,除了业务上的好处,这样做的好处还可以支持将 Function 拆分单独作为某个服务通过简单的加壳(API 化)提供给外部调用,从商业角度讲,这样的模式能够给 Application 本身创造的价值之外提供了更多的细分变现领域。 所以,为什么 ServerLess 这么火(至少表面看),就是因为 ServerLess 是上述所说 FaaS 的最佳体现。 二、实操我们开始创建今天的主角,ServerLess(python 版本随自身业务需求而变)创建一个云函数: 创建 SCF(云函数,ServerLess) 从云函数的功能上来看,与腾讯云的功能整合度还是比较高的,在规划上笔者建议通过私有网络来构造云函数应用。 对接 cvm apiv3 sdk来实现拉取cvm列表,首先将用到的SDK文件放在云函数所在目录下。通过 VSCode 插件一键部署。这里推荐使用 VSCode 来作为主 IDE,无论是构造 API 的 Django 所用的 TKE 可以通过 Remote Development 插件来进行远程开发,还是 ServerLess 也可以通过腾讯云提供的 ServerLess ToolKit(当然大部分提供 ServerLess 的云厂商都有提供 Toolkit,安装 ToolKit 时主要不要在 Remote IDE 窗口下点击,否则就变成为远端安装了)进行开发,基本上做到完全体验一致。通过 CVM SDK 获取 ins-id、内网 IP,再调用 Django 构造的接口进行传参。结果调用成功添加数据: ...

July 6, 2020 · 1 min · jiezi

腾讯云主机使用2安装nginx

腾讯云的centos主机配置的yum源是有nginx的,so安装非常方面,不像之前那样还需要安装nginx的支撑组件。话不多说,开始1、还是先看看有没有 yum search nginx2、有了,就安装吧 yum install nginx3、安装完后,rpm -qa | grep nginx 查看 4、最常用的命令 启动nginx:systemctl start nginx停止nginx:systemctl stop nginx加入开机启动:systemctl enable nginx查看nginx的状态:systemctl status nginx5、输入 ip:80 发现并不是我们熟悉的 welcome to nginx!,而是一个centos的英文站点,这个去配置文件看看。 6、去/etc/nginx/nginx.conf看看 这里 /usr/share/nginx/html文件夹下的index.html就是展现的内容

July 5, 2020 · 1 min · jiezi

在云函数-SCF-里为-Nextjs-跑-SSR

很多时候我们都希望首屏速度快,SEO 友好,那么相比于客户端渲染,SSR 渲染将是这方面的优势。Next.js、Nuxt.js 都是 SSR 框架。本篇文章将介绍 Next.js。 通常我们在部署 SSR 的时候,会担心运维等问题,但如果我们把它部署在云开发上就可以不必担心~ 试试看看喽~ 环境准备安装node.js安装云开发工具 @cloudbase/clinpm i @cloudbase/cli搭建云环境首先在打开云开发并新建环境创建完成后会自动进入环境初始化阶段,这个阶段大概持续 2~3 分钟。初始化项目当环境初始化完成后我们就可以进行初始化项目啦~ 使用 CLI 工具初始化一个云开发项目 $ tcb inittcb init? 选择关联环境 xxx - [xxx-xxx]? 请输入项目名称 nextSSR? 选择模板语言 Node? 选择云开发模板 Hello World✔ 创建项目 cloudbase-next 成功!初始化结束后的项目目录如下: nextSSR└─. │ .editorconfig │ .gitignorev1 │ a.txt │ cloudbaserc.js │ README.md │ └─functions └─app index.js然后我们进入到项目中 $ cd nextSSR在 functions 文件夹下创建 next.js 应用:$ npm init next-app functions/next 等待初始化 next.js 项目... ...

July 2, 2020 · 2 min · jiezi

大数据平台是否更应该容器化

大数据的发展历史大数据技术起源于Google在2004年前后发表的三篇论文,分布式文件系统GFS、分布式计算框架MapReduce和NoSQL数据库系统BigTable,熟称"三驾马车"。在论文发表后,Lucene开源项目的创始人Doug Cutting根据论文原理初步实现了类似GFS和MapReduce的功能。并在2006年,将该部分功能设置成独立的项目即大名鼎鼎的Hadoop项目。Hadoop项目中主要包括分布式文件系统HDFS和大数据计算引擎MapReduce两个组件。 图片来源于网络 在早期,MapReduce既是一个执行引擎,又是一个资源调度框架,集群的资源调度管理由MapReduce自己完成。但是这样不利于资源复用,也使得MapReduce非常臃肿。于是一个新项目启动了,将MapReduce执行引擎和资源调度分离开来,这就是Yarn。2012年,Yarn成为一个独立的项目开始运营,随后被各种大数据产品支持,成为大数据平台上最主流的资源调度系统。伴随着时代的发展,大数据场景下的计算引擎层出不穷,主要的有内存式计算引擎Spark,分布式实时计算Storm,流计算框架Flink等。这些计算引擎都使用Yarn进行资源管理和调度。 大数据平台目前存在的问题目前绝大多数大数据平台都是基于Hadoop生态,使用Yarn作为核心组件来进行资源管理和调度。但这样的平台普遍存在如下问题: (1) 资源弹性不足,无法按需自动扩容。大数据系统资源的高峰往往具有明显的周期性。例如实时计算资源消耗主要在白天。离线分析中,日报型的计算任务资源的高峰一般在22:00以后。周报和月报型的计算任务业务高峰往往也是在一个固定的时间点。并且离线计算有时还有突发的计算任务,例如需要对历史数据做一个统计。目前的大数据系统普遍缺乏资源的弹性,无法按需进行快速扩容,为了应对业务高峰和突发的计算任务只能预留出足够多的资源来保证任务能够正常响应。 (2) 资源利用率低。日志留存和流量清单等存储密集型的业务CPU使用率长期小于30%。而计算类的业务虽然CPU消耗很高,但是存储的资源使用率小于20%。大量资源闲置。并且考虑在线业务往往在低峰期会有大量的资源闲置。这些资源其实离线计算业务是完全可以利用的,但目前大数据的系统架构这部分资源完全没有被利用。导致资源利用率进一步降低。 (3) 资源隔离性差。从Hadoop2.2.0版本开始,Yarn开始使用cgroup实现了CPU资源隔离,通过JVM提供的内存隔离机制来实现内存资源隔离。对于磁盘IO和网络IO的隔离目前社区还在讨论中YARN-2139,YARN-2140。对于文件系统环境的隔离,社区在Hadoop 3.0版本中支持通过Classpath isolation HADOOP-11656来避免不同版本的jar包冲突,但无法做到完整的文件系统隔离。整体上看Yarn的资源隔离做的并不完善,这就造成了,多个任务运行到同一个工作节点上时,不同任务之间会存在资源抢占的问题,不同任务之间相互影响。 (4) 系统管理困难。在大数据系统中缺少统一的管理接口,也缺少路由管理,网络管理,磁盘管理等能力。这就造成大数据平台的开发往往需要对管理系统进行深度定制。开发工作量大,系统管理困难,并且平台迁移困难。例如大数据平台中需要提供对大数据组件UI页面的访问能力。在大数据平台构建中,为了能够访问组件的UI页面往往需要单独进行网络的打通,进行额外的路由的配置。并且很多时候这些配置都缺少标准的接口,无法做到自动化,管理起来十分困难。 (5) 管理方式不统一。在线业务和大数据业务虽然属于不同的业务类型,但就管理平台来说提供的功能是类似的。主要提供资源管理,业务(任务)管理,权限管理,可视化展示与操作等方面的功能。但因为管理方式不统一,底层框架与运行方式不同,造成了在线业务和大数据业务往往需要开发不同的平台,由不同的团队运维来管理,这极大的增加了额外的人力投入,造成不必要的人力损失。 Kubernetes编排系统现状介绍Kubernetes是谷歌开源的生产级的容器编排系统,在谷歌内部长达15年的使用积累,依赖其对功能场景的清晰定义,声明式API的简洁易用,充分的扩展性,逐步在容器编排领域的竞争中胜出,成为这一领域的领导者。伴随着微服务,DevOps,持续交付等概念的兴起和持续发酵,并依托于云原生计算基金会CNCF,Kubernetes保持着高速发展,正在成为"云计算时代的操作系统"。 Kubernetes究竟有多热门,根据CNCF年初(2020)的统计数据,在2019年84%的企业在生产环境中使用了Kubernetes。随着在生产环境的广泛使用,Kubernetes的成熟度已经得到了大范围的检验。很多公司已经提出了所有组件容器化的目标,借助云原生的技术,来提升组件运维管理和研发流程的效率。 图片来源于网络 Kubernetes 如何解决大数据的问题对于在线业务,使用容器技术能够很好的提高资源使用率,基于容器构建CI/CD流程可以大幅提升研发效能和系统管理能力,使用集群的自动伸缩功能可以根据需要动态申请和释放资源,提高资源使用的弹性。那么在大数据场景下,使用容器能否解决大数据平台目前遇到的问题呢? 首先对于资源弹性不足的问题,Kubernetes可以通过弹性扩缩容来实现业务高峰时的快速扩容,避免为了应对业务高峰预留过多的资源。更进一步可以直接使用无服务计算(Serverless)技术,直接将大数据业务跑在无服务计算的容器上,做到按需使用和付费,使资源的使用完全弹性。 Kubernetes集群自动扩缩容原理 对于资源使用率低的问题。一方面Kubernetes支持更加细粒度的资源划分,这样可以尽量做到资源能用尽用,最大限度的按需使用。另外一方面支持更加灵活的调度,并根据业务SLA的不同,业务高峰的不同,通过资源的超卖和混合部署来进一步提升资源使用率。由于在线业务和离线业务两者之间SLA要求明显不同,业务高峰期也明显不同,容器化后使用离线在线混合部署,一般对资源使用率的提升在30%以上。 对于资源隔离性差的问题。容器技术从一开始就支持不同资源的隔离。CPU,内存,磁盘IO,网络IO,设备等这些都有比较完整的支持。在线业务使用容器技术,通过Kubernetes编排系统能够很好的将不同业务实例混合部署到相同的节点上,实例之间使用隔离技术,完整的隔离,相互之间完全不受影响。 Kubernetes隔离能力示意图 对于系统管理困难的问题,Kubernetes不仅提供资源管理的能力,还提供路由管理,网络管理,监控日志等多方面的能力。同时对外通过统一的声明式API进行访问。基于Kubernetes构建大数据平台,可以极大的简化系统开发的难度,减少系统管理的复杂度。例如在大数据平台中,使用Kubernetes提供的路由管理能力Service和 Ingress可以十分方便实现对大数据组件UI的访问,并且Kubernetes还提供标准的声明式API来管理,极大的简化了自动化的复杂度。 Kubernetes ingress 提供访问大数据各个组件UI示意图 如果在线业务和大数据业务都统一使用容器化的方式来部署,使用Kubernetes编排框架来管理。这样就能将大数据业务和在线业务在同一个平台中实现管理和运维。避免平台管理团队的人员分散,大大提高平台管理团队工作效率。 统一的业务管理平台示意图 大数据容器化技术现状大数据组件众多,按照类别大致可以分为文件存储系统,NoSQL数据库,计算框架,消息中间件,查询分析等。常用的大数据组件具体的分类如下表所示: 大数据组件分类代表性组件主要作用文件存储系统HDFS数据底层存储NoSQL数据库Hbase、MongoDB非结构化数据存储计算框架Hadoop MapReduce、Spark、Storm、Flink离线计算和流计算消息系统Kafka、ZeroMQ、RabbitMQ消息存储和转发数据查询分析Hive、Impala、Druid数据查询和分析这些组件现在一般都有对应的开源项目来支持部署到Kubernetes上,本文将对一些常用的组件在Kubernetes的部署进行分析。 文件存储系统HDFS on Kubernetes HDFS主要包括Datanode,Namenode和Journalnode三个组件。在Kubernetes中进行部署时,由于Datanode需要存储HDFS中的数据,对磁盘要求非常高,所以在Kubernetes中部署时Datanode采用DaemonSet的方式进行部署,每个存储节点部署一个Datanode实例。而Namenode和Journalnode由于需要保持名称不变,在Kubernetes中采用StatefulSet的方式进行部署。 NoSQL数据库Hbase on Kubernetes Hbase主要包括两种类型的节点,HMaster节点和HRegionServer节点。其中HMaster节点作为主节点,负责管理多个HRegionServer节点。HRegionServer节点作为worker节点,负责管理各个region。由于Hbase的实际数据存储在HDFS中,Hbase本身并不存储数据,所以HMaster和HRegionServer并不需要挂载磁盘。只是为了保持实例名称不变,HMaster和HRegionServer都采用StatefulSet的方式进行部署。 数据查询分析Hive on Kubernetes Hive主要包括hive-Server和metastore两个组件。其中hive-Server作为访问入口,可以按照在线服务一样使用Deployment进行部署。metastore因为需要保持名称不变,所以使用了StatefulSet的方式进行部署。 计算框架Spark on Kubernetes ...

July 2, 2020 · 1 min · jiezi

云函数-SCF-中-PHP-的一些入门坑

本文来自 Serverless 社区用户「逸笙」投稿由于云函数 SCF 本身是用 bootstrap.php 来调用我们的入口函数,默认为 index.main\_handler,意思是调用 index.php 文件中的 main\_handler(),所以很多地方写法要有改变。php 一般提供网页服务,所以我主要讲API 网关配合的云函数 SCF。 main_handler($event, $context)函数会传入2个参数,首先这2个参数是object,需要用->来访问子项,如 $event->{'headers'} ,不是很方便,我一般转换成数组: $event = json_decode(json_encode($event), true);这样就比较方便了,如 $event'headers' 。 大家可以打印这两个参数看一眼里面有些什么。 我们可以从中获取到很多有用的东西,比如: $_GET = $event['queryString'];$_POST = $event['body'];$_COOKIE = $event['headers']['cookie'];在云函数 SCF 中运行的 php 程序,因为浏览器是提交给 API 网关,不是提交给 SCF 的,这些超全局变量完全没有获取到东西,所以要这样来获取。 但我们发现,$event['body'] 与 $event['headers']['cookie'] 本身是一个长字符串,里面有好几个值,并且里面 url 编码了,这样不方便使用,所以做些小操作: $postbody = explode("&",$event['body']);foreach ($postbody as $postvalues) { $pos = strpos($postvalues,"="); $_POST[urldecode(substr($postvalues,0,$pos))]=urldecode(substr($postvalues,$pos+1));}$cookiebody = explode("; ",$event['headers']['cookie']);foreach ($cookiebody as $cookievalues) { $pos = strpos($cookievalues,"="); $_COOKIE[urldecode(substr($cookievalues,0,$pos))]=urldecode(substr($cookievalues,$pos+1));}这样就方便使用了。 ...

July 2, 2020 · 2 min · jiezi

手把手带你利用云函数-SCF-轻松实现一个热点资讯小程序

第一步,环境配置打开微信小程序开发 IDE,创建一个小程序项目,AppID 需要自己去小程序官网注册一个,然后后端服务注意选择小程序-云开发。 注意,以前的老版本 IDE,在蓝色框那里会有一个腾讯云的选项。实际上都是使用的腾讯云服务,统一选择小程序-云开发就好。 点击新建,会出现这样一个界面: 可以看到,微信开发者工具的脚手架已经为我们创建好了一些模板代码,今天,猪脚就是我们的 cloudfunctions 部分,即如何利用腾讯云为我们即将写的新闻小程序提供数据服务。 在开发之前,我们发现控制台报了一个错误,提示我们没有开通云服务。我们发现微信开发者工具的顶部工具栏中,云开发那个按钮是灰色的,点击进去,提示我们开通,表示我们没有开通云开发服务,点击它,新建一个。 配置完毕之后,你可能会关系费用问题,不用担心,默认的配置是完全免费的,如果你用户量不太大,基本上够你的日常需求了,对个人开发者来说,相当的友好。 第二步:云函数开发及部署云服务开通完毕,接下来可以部署下脚手架为我们提供的云函数,可以看到 cloudfunctions 文件夹提示未选择环境,我们右键点击,选择我们刚才开通的那个云开发环境。然后展开目录,对准 login 这个目录,右键,选择 然后,关闭 IDE,重启 IDE,在点击第一个按钮,获取 openid,此时可以看到获取 openid 是成功的了。 这里表示我们的云开发环境从开通到部署的链路已经打通了,接下来的事情,当然是写自己的云函数了。我们是要做一个新闻咨询的小程序,所以,一般来说,找一个自己经常看的觉得内容质量不错的新闻内网站看看人家提供了什么接口没,分两步走: 如果有提供了接口,我们在云函数中直接调用接口,拿到数据,喂给小程序前端即可,这种最方便了。通常情况下是没有接口的,此时怎么办?一个思路是使用云函数去爬取新闻网站的内容,存放到云开发 db 上面,然后小程序端来读云开发 db 中的内容,亦或者直接通过通过爬虫程序生成一个 json 返回给小程序端,不通过存储 db 这个过程。其缺点是没有缓存数据,每次都要经过爬虫去爬,用户可能等很久才能看到新闻,体验并不好。目前,云开发套件里面有提供 db 服务,所以,既然提供了,当然就直接拿来使用了,提升用户体验的事,当然就得干了。本文为了简便期间,目的就是为了介绍如何在小程序中使用腾讯云的云函数功能,因此,就不介绍 db 的存储了。那么,开始吧。 新建云函数直接对这 cloudfunctions 那个文件夹点击新建云函数,成功之后就会看到目录里面有脚手架生成的一些框架代码了。 // 云函数入口文件const cloud = require('wx-server-sdk')cloud.init()// 云函数入口函数exports.main = async (event, context) => { const wxContext = cloud.getWXContext() return { event, data:data }}大多看到是这种,其中 wxContext 是小程序的上下文,这里可以拿到小程序的 AppID 等等一些常量信息。 ...

June 29, 2020 · 2 min · jiezi

起势的-Serverless正在挺进云计算的腹地深处

2020 年 6 月 19 日,全球最负盛名的 Serverless 大会 --ServerlessDays · China 于线上直播的形式正式召开举办。腾讯云作为 Serverless 的先行者,从 2017 年至今,经过三年的沉淀,腾讯云 Serverless 的用户规模以及产品下载、调用等次数每年都在急速增长。云计算的下半场会是无服务器化吗,Serverless 能否再次引领云计算领域的又一次红利?这一切,都在这场大会中得到揭晓。 Serverless 起势2020 年 6 月 19 日,首次进入中国的 ServerlessDays 于线上直播的形式展开。期间 ServerlessDays Organiser--Ant Stanley、Author of “A Berkeley View on Serverless Computing”--Johann Schleier-Smith、Serverless.com CEO--Austen Collins 等众多国外知命的 Serverless 技术专家纷纷到场。 开场,ServerlessDays 会议的组织者、Serverless 社区的技术专家 Ant Stanley 通过分享了自己对于无服务器化的理解,从 Herman Hollerith 到简单的 Lambda 函数,Ant Stanley 认为无服务器化是近百年历史中坚持不断创新的最终结果。 无服务器化,这也凸显了 Serverless 如今起势的原因所在。 过去这些年,随着云计算技术的发达普及,企业的业务形式也从根本上发生了变化。线下转线上,已经成为诸多行业的演变趋势。即便是业务受限于线下场景,线上也成为了企业业务的一个重要入口。 不仅如此,云计算也衍生出了众多基于云上场景才能实现的技术能力,分布式存储、虚拟化、大数据、容器化等等..... 如果没有云的发展,很难想象大数据行业的情况会是怎样,也许会从数据密集型转变为人力密集型;如果没有云计算,很难想象现如今支撑人工智能运行的平台会是什么样子.... 如果没有云计算,很多线上互联网业务都会被迫停止,为了业务发展,被迫组建大量的线下地推团队..... 可以说,云计算不只是作为一个平台,更是在以生态之姿来覆盖全部领域。由上至下去看,云计算这一片生态的蓝海蔚为壮观。 ...

June 28, 2020 · 2 min · jiezi

利用-Serverless实现-COS-CDN-Combo-Handler

背景小 S 维护的一个前端系统,单个页面中有数个没有依赖关系的 js, css 需要加载,此时浏览器会分别去请求对应的文件。此时小 S 收到 Leader 给的一个任务:优化前端的静态资源请求,尽量做合并。 什么是 Combo Handler?相信很多前端同学并不陌生。2008 年 7 月 YUI Team 宣布在 YAHOO! CDN 上对 YUI JavaScript 组件提供 Combo Handler 服务。简单讲,当前端有 n 个 js 需要分别去拉取时,通过 cdn combo 技术能用一个请求把 js 在服务端合并后拉回,同理可用于 css 文件。现状小 S 马上开始着手,看了下手头的项目,目前静态资源是经过 腾讯云 CDN 的,静态资源放在了 腾讯云对象存储 COS,js、css 文件因为模块的不同,被打包成了多个。而腾讯云 CDN 目前不支持 Combo 的方式。 分析小 S 开始想到了 HTTP2.0,但看了 CDN 的请求配置已开启 HTTP2.0,这一块能提升的空间已不大。那是否能做静态的离线合并处理,看似可行的一条路,但改动量不小,且确实涉及到一些历史原因,这块不好动。小 S 突然想起以前了解过的 CDN Combo,那从请求实时合并入手,也是可行的。但可惜,目前接入的 CDN 没能支持。 此时天空飘来一句秦牛·道格拉斯·正威的话打在了小 S 身上 ...

June 24, 2020 · 2 min · jiezi

性能提升40-腾讯-TKE-用-eBPF-绕过-conntrack-优化-K8s-Service

Kubernetes Service 用于实现集群中业务之间的互相调用和负载均衡,目前社区的实现主要有userspace,iptables和IPVS三种模式。IPVS模式的性能最好,但依然有优化的空间。该模式利用IPVS内核模块实现DNAT,利用nf_conntrack/iptables实现SNAT。nf_conntrack是为通用目的设计的,其内部的状态和流程都比较复杂,带来很大的性能损耗。 腾讯云 TKE 团队 开发了新的IPVS-BPF模式,完全绕过nf_conntrack的处理逻辑,使用eBPF完成SNAT功能。对最常用的POD访问ClusterIP场景,短连接性能提升40%,p99时延降低31%;NodePort场景提升更多。详情见下表和性能测量章节。 一、容器网络现状iptables模式存在的问题: 1.可扩展性差。随着service数据达到数千个,其控制面和数据面的性能都会急剧下降。原因在于iptables控制面的接口设计中,每添加一条规则,需要遍历和修改所有的规则,使得其控制面性能是O(n²)。在数据面,规则是用链表组织的,使得其数据面的性能是O(n)。 2.LB调度算法仅支持随机转发。 IPVS模式IPVS 是专门为LB设计的。它用hash table管理service,对service的增删查找都是O(1)的时间复杂度。不过IPVS内核模块没有SNAT功能,因此借用了iptables的SNAT功能。IPVS 针对报文做DNAT后,将连接信息保存在nf_conntrack中,iptables据此接力做SNAT。该模式是目前Kubernetes网络性能最好的选择。但是由于nf_conntrack的复杂性,带来了很大的性能损耗。 二、IPVS-BPF方案介绍eBPF 介绍eBPF是Linux内核中软件实现的虚拟机。用户把eBPF程序编译为eBPF指令,然后通过bpf()系统调用将eBPF指令加载到内核的特定挂载点,由特定的事件来触发eBPF指令的执行。在挂载eBPF指令时内核会进行充分验证,避免eBPF代码影响内核的安全和稳定性。另外内核也会进行JIT编译,把eBPF指令翻译为本地指令,减少性能开销。 内核在网络处理路径上中预置了很多eBPF的挂载点,例如xdp, qdisc, tcp-bpf, socket等。eBPF程序可以加载到这些挂载点,并调用内核提供的特定API来修改和控制网络报文。eBPF程序可以通过map数据结构来保存和交换数据。 基于eBPF的IPVS-BPF优化方案针对nf_conntrack带来的性能问题,腾讯TKE团队设计实现了IPVS-BPF。核心思想是绕过nf_conntrack,减少处理每个报文的指令数目,从而节约CPU,提高性能。其主要逻辑如下: 在IPVS内核模块中引入开关,支持原生IPVS逻辑和IPVS-BPF逻辑的切换在IPVS-BPF模式下,将IPVS hook点从LOCALIN前移到PREROUTING,使访问service的请求绕过nf_conntrack在IPVS新建连接和删除连接的代码中,相应的增删eBPF map中的session信息在qdisc挂载eBPF的SNAT代码,根据eBPF map中的session信息执行SNAT此外,针对icmp, fragmentation均有专门处理,详细背景和细节,会在后续的QCon在线会议上介绍,欢迎一起探讨。 优化前后报文处理流程的对比 可以看到,报文处理流程得到了极大简化。 为什么不直接采用全eBPF方式很多读者会问,为什么还要用IPVS模块跟eBPF相结合,而不是直接使用eBPF把Service功能都实现了呢? 我们在设计之初也仔细研究了这个问题, 主要有以下几点考虑: nf_conntrack对CPU指令和时延的消耗,大于IPVS模块,是转发路径的头号性能杀手。而IPVS本身是为高性能而设计的,不是性能瓶颈所在IPVS有接近20年的历史,广泛应用于生产环境,性能和成熟度都有保障IPVS内部通过timer来维护session表的老化,而eBPF不支持timer, 只能通过用户空间代码来协同维护session表IPVS支持丰富的调度策略,用eBPF来重写这些调度策略,代码量大不说,很多调度策略需要的循环语句,eBPF也不支持我们的目标是实现代码量可控,能落地的优化方案。基于以上考虑,我们选择了复用IPVS模块,绕过nf_conntrack,用eBPF完成SNAT的方案。最终数据面代码量为:500+行BPF代码, 1000+行IPVS模块改动(大部分为辅助SNAT map管理的新增代码)。 三、性能测量本章节通过量化分析的方法,用perf工具读取CPU性能计数器,从微观的角度解释宏观的性能数据。本文采用的压测程序是wrk和iperf。 测试环境复现该测试需要注意两点: 不同的集群和机器,即使机型都一样,也可能因为各自母机和机架的拓扑不同,造成性能数据有背景差异。为了减少这类差异带来的误差,我们对比IPVS模式和IPVS-BPF模式时,是使用同一个集群,同样一组后端Pod, 并且使用同一个LB节点。先在IPVS模式下测出IPVS性能数据,然后把LB节点切换到IPVS-BPF模式, 再测出IPVS-BPF模式的性能数据。(注:切换模式是通过后台把控制面从kube-proxy切换为kube-proxy-bpf来实现的,产品功能上并不支持这样在线切换)本测试的目标是测量LB上软件模块优化对于访问service性能的影响,不能让客户端和RS目标服务器的带宽与CPU成为瓶颈。所以被压测的LB节点采用1核机型,不运行后端Pod实例;而运行后端服务的节点采用8核机型NodePort 为了采集CPI等指标,这里LB节点(红色部分)采用黑石裸金属机器,但通过hotplug只打开一个核,关闭其余核。 ClusterIP 这里LB节点(左边的Node)采用SA2 1核1G机型。 测量结果 IPVS-BPF模式相对IPVS模式,Nodeport短连接性能提高了64%,clusterIP短连接性能提高了40%。 NodePort优化效果更明显,是因为NodePort需要SNAT,而我们的eBPF SNAT比iptables SNAT更高效,所以性能提升更多。 如上图所示,iperf带宽测试中IPVS-BPF模式相对IPVS mode性能提升了22%。 上图中,wrk测试表明nodePort service 短连接p99延迟降低了47%. 上图中,wrl测试表明clusterIP service短连接的p99延迟降低了31%。 指令数和CPI 上图中从Perf工具看,平均每个请求耗费的CPU指令数, IPVS-BPF模式下降了38%。这也是性能提升的最主要原因。 IPVS-BPF 模式下CPI略有增加,大概16%。 ...

June 24, 2020 · 1 min · jiezi

使用-Serverless-飞书打造你的个性化消息提醒系统

一、前言在日常工作学习生活中,我们可能会遇到以下情形: 自己管理的某台服务器宕机了,但是没有得到及时的提醒,导致业务受到损失某些自己很想注册的网站悄悄开放注册,但是自己并没有及时得知,于是只能继续漫无目的的等待……如果每件事都花时间去关注,那我们的时间必然会不够用,那有没有什么办法可以让这些消息集中起来并且及时推送呢?在这里我想向大家推荐一个解决方案,那就是使用 Serverless + 飞书打造属于自己的个性化消息提醒系统。 二、准备工作首先注册一个飞书账号,然后在飞书网页版登录打开飞书开放平台,点击创建企业自建应用,并输入应用名称和应用副标题,然后点击确定创建 在企业自建应用列表中点击刚刚创建成功的应用,并记录 App ID 和 App Secret 二、编写代码在本地新建一个项目目录,名称随意,这里以 feishu-notify 为例分别创建 3 个文件:.env,index.py 和 serverless.yml按如下说明进行编码.envTENCENT_SECRET_ID=AKID********************************TENCENT_SECRET_KEY=********************************注:这里的 TENCENT_SECRET_ID 和 TENCENT_SECRET_KEY 可在腾讯云控制台的访问密钥中获取,如果没有密钥则需要自己新建一个serverless.ymlmyFunction: component: "@serverless/tencent-scf" inputs: name: feishu-notify-py codeUri: "./" handler: index.main_handler runtime: Python3.6 region: ap-guangzhou description: My Serverless Function Used to Notify Myself memorySize: 128 events: - apigw: name: serverless parameters: protocols: - https endpoints: - path: "/" method: POST注:可以点击这里查看serverless.yml中所有可用属性的属性列表index.pydef main_handler(event, context): import requests import json print(event) CONFIG = { "app_id": "********************", "app_secret": "********************************" } # my auth if 'myauth' not in event['queryString'] or event['queryString']['myauth'] != 'feishu1': return 'forbidden' # Get content postContent = event['body'] try: postContent = json.loads(postContent) except: return 'error in json_loads(line: 19)' if 'content' not in postContent: return 'invalid params' content = postContent['content'] # Get tenant_access_token try: res = requests.post('https://open.feishu.cn/open-apis/auth/v3/tenant_access_token/internal/', { "app_id": CONFIG['app_id'], "app_secret": CONFIG['app_secret'] }) except: return 'error in get_tenant_access_token' data = json.loads(res.text) if data['code'] != 0: return data['msg'] token = data['tenant_access_token'] # Get chat_id try: res = requests.get('https://open.feishu.cn/open-apis/chat/v4/list', headers={ 'Authorization': 'Bearer %s' % (token) }) except: return 'error in get_chat_id' data = json.loads(res.text) if data['code'] != 0: return data['msg'] groupList = data['data']['groups'] myGroupId = groupList[0]['chat_id'] # Send message try: res = requests.post('https://open.feishu.cn/open-apis/message/v4/send/', json={ "chat_id": myGroupId, "msg_type": "text", "content": { "text": content } }, headers={ 'Authorization': 'Bearer %s' % (token), 'Content-Type': 'application/json' }) except: return 'error in send message' data = json.loads(res.text) if data['code'] != 0: return data['msg'] return 'success'关于 index.py,这里有几点需要作出说明: ...

June 24, 2020 · 2 min · jiezi

使用-serverless-在腾讯云部署第一个函数

Serverless 是各大云服务商提供出来的一种无服务的计算资源。为什么叫无服务呢,因为如果你使用 serverless,你只需要关注应用层,而无需关心底层基础设施,无需运维。简而言之,serverless 并不是真的无服务,而是关于有服务的不归你管,云服务商帮你搞定,比如 Google,AWS 或者 TencentCloud。 关注点分离,好呀好!有了 serverless 以后只需要也只能关心业务了,这也不知是喜是忧。但你也无需过于担心,这是对已有并且成熟的开发模式的挑战,解决痛点有限,因此很多团队对于替换为 serverless 也动力不足。 但是我仍然建议你学习 serverless,毕竟各大云厂商对于 serverless 有很多免费额度可以让你薅羊毛,对于个人开发者利好。 Serverless Frameworkserverless 是基于各大云服务商的产品,每一个云厂商对于 serverless 都有一套自己的 API。为了能够兼容这些 API,为了让你的代码 Write Once, Run Everywhere,于是 serverless framework 诞生了。 通常认为 serverless = faas + baas,然而 serverless framework 只兼容到了 faas,对于 baas,如各家提供的数据存储服务,要做到兼容还是很难。快速开始serverless framework 与腾讯云的云函数来开始一个 hello world 吧! $ npm install -g serverless$ mkdir hello$ cd hello$ serverless create --template tencent-nodejs --name helloServerless: Generating boilerplate..._______ __| _ .-----.----.--.--.-----.----| .-----.-----.-----.| |___| -__| _| | | -__| _| | -__|__ --|__ --||____ |_____|__| \___/|_____|__| |__|_____|_____|_____|| | | The Serverless Application Framework| | serverless.com, v1.67.0-------'Serverless: Successfully generated boilerplate for template: "tencent-nodejs"此时在 hello 目录自动生成了关于 serverless 在腾讯云的 hello, world 版。由于缺少关于腾讯云的 plugin 需要首先装包 ...

June 23, 2020 · 2 min · jiezi

Serverless-GitHub-Actions-完美自动化部署静态网站

作为强迫症患者,一直对自动化部署非常痴迷,个人认为全自动部署最重要的就是稳定可靠。经过研究测试,最终使用 GitHub 和腾讯云两大平台,成功完成了全自动部署网站的实践。 本文来自 Serverless 社区用户「Stille」投稿方案简介业务需求博主有一个简单的纯静态文档站点 docs.ioiox.com,使用的的是 docsify 项目的 Markdown 渲染程序,平时通过本地 VSCode 编辑文档,并提交到 GitHub。早前是直接使用 GitHub Pages 绑定域名来访问,但由于网络问题,体验并不好。 寻求方案腾讯云对象存储 COS 服务能够提供静态网页服务,并可以配置 CDN 域名进行访问。那么就需要解决以下两个问题: 如何使 GitHub 自动同步文件到腾讯云 COS腾讯云 COS 对应的 CDN 如何自动刷新解决方案GitHub Action - 配置每次 Push 代码后自动上传到 COS腾讯云云函数 SCF - 检测到 COS 内文件变动后自动刷新对应的 CDN 链接方案流程图 第一阶段 - GitHub Actions 2019 年 11 月,GitHub 正式开放了 GitHub Actions 这个功能,不再需要申请就能自由使用,目前是按照 workflow 的使用时长来收费,个人用户每月 2000 分钟的免费额度也基本够用了。 获取腾讯云 API 密钥登录腾讯云控制面板 - 访问控制 - 访问密钥 - API 密钥管理 ...

June 18, 2020 · 3 min · jiezi

Serverless-技术在格灵深瞳的落地实践

格灵深瞳是一家全国领先的人工智能物联网科技企业。专注于把先进的人工智能科技转化为具备低成本、大规模部署能力的产品和服务,并深度结合应用场景,为用户提供高性能、 可靠实用的智慧解决方案。目前,在智慧安防、智能零售、智慧银行和新能源领域,为遍布全国和全世界的客户提供包含智能传感器、 智能识别、智能云计算和服务机器人的综合智能解决方案和服务。 随着业务的快速增长,需求迭代、资源投入、运维压力也随之变的越来越紧迫。怎样提升研发效能、保障业务快速上线,怎样提升资源利用效率、降低成本开销,怎样减少运维的压力、又能保障系统的可靠运转,逐渐成为我们的重点诉求。在此基础上,我们开始考虑引入新的技术,并做了一些调研,最终锁定了 Serverless 技术。 Serverless 想必大家或多或少都有接触,也是最近云计算领域非常火的一个技术方向,核心是帮用户屏蔽了底层的资源、提供按需请求、按需使用、按需付费的一种全新服务,像腾讯云的云函数 SCF 和对象存储等都是 Serverless 化的服务。在这里也和大家分享下,我们业务和 Serverless 是如何结合的。 我们考虑使用 Serverless 技术方案是经过一些调研,结合我们自己的业务需求最终决定的,主要有以下几点: 我们服务的客户与场景流量潮汐现象很明显,Serverless 自动弹性伸缩能力可以为我们解决这个问题,比起普通服务器,可以提高机器利用效率,降低成本。我们部分业务场景,如图片采集和上传,是典型的事件触发摸式。我们通过前端直接上传图片到对象存储,通过回调与云函数,实现统一的图片信息处理。将这类事件触发通过 Serverless 方案处理,与核心后端逻辑解耦,既降低了应用复杂性也缓解了后端压力。转移部分运维压力,创业公司永远面临人手不够的问题,我们的运维资源有限,通过成熟的云厂商 Serverless 方案,可以借助成熟的框架与云服务厂商实现更好的可靠性保障,提供更稳定的服务。产品原型验证与短期需求,相信大部分研发同学都遇到过原型验证与短期需求的『折磨』,这类需求往往时间紧迫,生命周期很短却又需要经过编码、测试、部署、上线整个研发流程,使用 Serverless 方案可以大大加快这类需求的开发与迭代速度。总的来说,使用 Serverless 的技术方案,对于我们团队最大的收益就是加快了产品迭代,在验证原型方面效率和服务稳定性上提升了不少。 当然,和其他新技术的应用一样, Serverless 的技术方案在落地过程中也遇到了问题。 第一个问题是源代码与版本管理问题Serverless 方案与我们现有的源代码管理及关联的 CI/CD 流程无法直接整合、开始的时候上线与部署有不少手动操作的方式,研发的配合与流程被打断,后面我们结合自己的研发流程,通过开发运维工具适配api解决了这个问题。 第二个问题是私有化部署问题我们的应用既提供公有云服务,也要为有需要的客户做私有化部署,所以更倾向于使用同构的技术方案,能应用在不同的云基础设施上,这方面 Knative 与腾讯云支持的 Serverless Framework 都是不错的选择。 Serverless 技术有众多优势,但是作为这两年才兴起的技术方案,其概念、形式都没有定型,很多实践也都在探索的阶段,这方面腾讯云 Serverless 团队,在周边社区和生态支持还是比较全面的。对中小型企业与开发者而言,我们更希望社区与企业共同努力演化出如 Kubernetes 之于云原生一样的事实标准方案,如果有了统一的、基础设施般的标准,能降低学习、开发、运维等各方面成本,进而给更多开发者使用和迁移的信心。 Serverless 作为将来的技术趋势之一,肯定是值得了解和尝试的,但是任何技术都有其适合的场景和业务需求。作为一个年轻的团队,我们并不排斥新的技术与方案,但是技术方案的选择是多方因素综合考虑的结果、除了场景是否适合、性能是否满足等技术指标外,还要考虑与现有的技术方案是否兼容、迁移成本评估、可运维性甚至团队成员的学习成本等多方面因素。建议有意向使用 Serverless 技术的团队可以从新的、非核心的业务场景开始尝试。 Serverless Framework 30 天试用计划我们诚邀您来体验最便捷的 Serverless 开发和部署方式。在试用期内,相关联的产品及服务均提供免费资源和专业的技术支持,帮助您的业务快速、便捷地实现 Serverless! 详情可查阅:Serverless Framework 试用计划One More Thing3 秒你能做什么?喝一口水,看一封邮件,还是 —— 部署一个完整的 Serverless 应用? ...

June 17, 2020 · 1 min · jiezi

揭秘日活千万腾讯会议全量云原生化上TKE技术实践

腾讯会议,一款联合国都Pick的线上会议解决方案,提供完美会议品质和灵活协作空间,广泛应用在政府、医疗、教育、企业等各个行业。大家从文章8天扩容100万核,腾讯会议是如何做到的?都知道腾讯会议背后的计算资源已过百万核,如此体量的业务,如何通过云原生技术提升研发和运维效率,是一个非常有价值的课题。这里我将为大家揭秘腾讯自研上云容器平台TKEx在支持腾讯会议全量云原生化上云背后的技术。 TKEx平台是以腾讯云容器服务(Tencent Kubernetes Engine, TKE)为底座,服务于腾讯自研业务的容器平台。腾讯自研业务类型众多、规模超大,云原生上云面临的挑战可想而知。TKEx平台在腾讯自研业务上云的过程中沉淀的最佳实践和解决方案,我们将会在TKE中提供给客户。 腾讯会议业务特性在Kubernetes中,我们习惯把应用分为无状态和有状态两类,有状态应用主要指实例标识、网络、存储的有状态。腾讯会议的一些服务有如下特性: 使用IPC共享内存,里面存放的有状态数据从MB到GB大小不等。 升级时IPC数据不能丢失;升级时只能允许ms级的抖动,用户无感知;部分服务最多的实例数过万,要求高效完成一次版本升级;全球多地域部署,要求部署高效;部分服务要求每个实例都分配EIP;这对Kubernetes管理这种有状态服务提出了更高能力和性能要求。TKEx平台抽象出业务特性背后的产品需求,在灰度发布、多集群工作负载管理、计算资源管理运营、Node稳定性等方面进行了增强和优化,沉淀出了通用的音视频业务容器编排能力。 StatefulSetPlus强大的灰度发布能力StatefulSetPlus是我们2018年研发并投入生产的首批Operator之一,核心特性包括: 兼容StatefulSet所有特性,比如按序滚动更新。支持分批灰度更新和回滚,单批次内的Pods可并发更新、可串行更新。 支持各个批次手动待升级勾选Pods。支持用户配置各个批次待升级Pods的比例进行灰度。支持分批回滚和一键失败回滚。发布过程可暂停。支持单个StatefulSetPlus对象管理上万个Pods。支持ConfigMap的分批灰度发布。对接了TKE IPAMD,实现了Pod固定IP。支持HPA和原地VPA。升级过程中的扩容使用LastGoodVersion。支持Node核心状态自检,Node异常时Pod能自动漂移。支持容器原地升级。支持升级失败Pods的容忍率控制,大规模升级过程中升级失败Pods占比小于x%时可继续升级。 这里主要介绍为腾讯会议上TKE新增的两个发布能力增强:大规模自动分批灰度发布和ConfigMap分批灰度发布。 支持单个StatefulSetPlus上万Pods的自动分批发布能力TKEx平台在原来StatefulSetPlus手动分批发布能力基础上,这次又开发了自动分批发布的特性,解决像腾讯会议这种大体量业务灰度发布的痛点。用户只要在发布时配置各个批次更新副本的百分比,比如第一批40%,第二批60%。StatefulSetPlus-Operator会根据Readiness探针完成情况,自动进行下一批次的更新,其原理如下。 StatefulSetPlus核心Field说明如下: batchDeployConfig: batchNum:分几批升级batchAuto:是否自动分批发布,true表示自动分批发布batchIntervalMinutes:两次分批发布之间的间隔分钟数podsNumToUpdate:各批次发布的pod数量,如果不设置则将pod平均到每批次发布StatefulSetPlus对发布过程进行了精细化的监控,提供staus.batchDeployStatus查询发布详细状态,这使得通过CI Pipeline发布变得更显示和可控。 batchDeployStatus: action:当前操作,Next表示进行下一批发布,WaitToConfirm表示等待确认该批次发布是否成功,Completed表示所有批次均已确认发布成功。batchDeadlineTime:本批次发布的Deadline,如果超过该时间,本批次的Pod仍然未Running & Ready,那么本批次发布失败,进入自动回滚流batchOrder:当前批次batchOrdinal:本批次发布pod的Index的起点batchReplicas:本批次发布的pod的数量currentDeployComplete:本批次发布是否完成currentOrderSuccessPer:成功升级的pod所占百分比currentOrderProgress:本批次发布是否成功currentRollbackProgress:本批次回滚是否成功generalStatus:本次发布全局状态可在annotations加上platform.tkex/pause-auto-batchDeploy: "true"来暂停自动分批发布和失败自动回滚。 在TKEx平台上,通过如下操作流程即可轻松完成自动分批发布。 腾讯会议最大的模块需要支持上万个Pods的灰度发布,这是前所未有的挑战。这一次,我们对StatefulSetPlus-Operator进行了优化,性能得到大幅提升。对于一万个pod的StatefulSetPlus,分5批自动升级,单批次2000个pod,不挂载cbs盘的场景,表现如下: 非原地升级方式:单批次升级处理耗时40-45秒,单批次升级从发起升级到升级完成耗时三分半钟,升级过程中单次同步StatefulSetPlus status耗时10秒左右。原地升级方式:单批次升级处理耗时30秒左右,单批次升级从发起升级到升级完成耗时一分十秒左右,升级过程中单次同步StatefulSetPlus status耗时10秒左右。正常情况下(非升级过程),同步StatefulSetPlus status毫秒级。支持ConfigMap的分批灰度发布和版本管理Kubernetes原生的ConfigMap更新是一次性全量更新到容器内的对应的配置文件,所以通过原生的方式更新配置文件是极其危险的事情。Kubernetes 1.18支持了Immutable ConfigMap/Secret,可以保护关键配置被误改导致业务受影响。业务对容器环境下配置文件的发布同样有着分批灰度发布的极高诉求。 于是我们给StatefulSetPlus赋予了分批发布配置文件的能力,提升了云原生场景下配置文件发布的安全性,原理如下: 方案概述: 用户修改ConfigMap后提交,后台自动创建一个新的ConfigMap,其中ConfigMap Name后缀是data内容的hash值,防止同样的data内容创建出多个ConfigMap,然后在Lable中添加没有data hash值的真正的ConfigMap名字,另外在lable中添加version,或者允许业务自定义一些lable以便标识ConfigMap的版本。Kubernetes对Pod的修改只支持更新栏位 spec.containers[*].image, spec.containers[*].resources(if inplace resources update feature enabled),spec.initContainers[*].image, spec.activeDeadlineSeconds or spec.tolerations(only additions to existing tolerations),因此需要修改kube-apiserver代码,使得允许update/patch volumes。通过StatefulSetPlus的分批灰度发布能力,逐个批次的对Pods引用的ConfigMap进行修改,由kubelet volumemanager自动reload configmap,因此ConfigMap的更新不需要重建Pods。为防止ConfigMap累积过多,影响etcd集群的性能,我们在自研组件TKEx-GC-Controller增加ConfigMap的回收逻辑,只保留最近10个版本的ConfigMap。用户只要在更新Workload页面,选择手动分批或者自动分批更新,在数据卷选项重新选择新版本的ConfigMap即可。可以在更新业务镜像的同时也更新ConfigMap配置文件,或者只更新ConfigMap配置文件。 ConfigMap配置文件更新,需要容器内业务进程能watch到配置文件的变更进行重启加载或者热加载。然而有些业务当前并没有这个能力,因此TKEx在ConfigMap发布的入口提供配置文件更新后的ProUpdate Hook,比如业务进程的冷/热重启命令。 如何保证有状态服务的升级只有ms级抖动拒绝胖容器模式(把容器当虚拟机用)是TKEx平台的原则,如何使用镜像发布并且提供像进程重启一样的ms级业务抖动,这是腾讯会议容器化上云最有挑战性的需求之一。TKEx平台在灰度发布能力上已经做了长期的技术沉淀,上万个业务模块在使用,但当前能力仍无法满足这一需求,镜像预加载+容器原地升级的方案,仍与这目标差距甚远。 经过多个方案的设计、分析、测试对比,考虑通用性、云原生、发布效率多个因素,最终使用如下方案: Pod里面有3个关键容器,它们的职责分别如下: biz-sidecar: Sidercar容器职责很简单,检测Pod是否在升级中。通过Readyness Probe比较EmptyDir Volume中的业务发布版本文件version1和version2的内容是否相等,相等则Ready,否则notReady。biz-container:容器启动脚本会将环境变量(预注入)里的一个版本号写到versionX文件中,然后开始循环等文件锁,如果成功获取文件锁则启动业务进程。文件锁是防止Pod内同时运行多个版本的业务Container的关键,用文件锁来做不同版本容器的互斥。biz-pause:启动脚本会将环境变量里的一个版本号写到versionX文件里,然后就进入无限sleep状态。这个容器是备用容器,当业务升级时,它就会通过原地升级的方式切换到biz-container的角色。升级流程概述 ...

June 16, 2020 · 1 min · jiezi

前端福音Serverless-和-SSR-的天作之合

什么是 SSRSSR 顾名思义就是 Server-Side Render, 即服务端渲染。原理很简单,就是服务端直接渲染出 HTML 字符串模板,浏览器可以直接解析该字符串模版显示页面,因此首屏的内容不再依赖 Javascript 的渲染(CSR - 客户端渲染)。 SSR 的核心优势: 首屏加载时间:因为是 HTML 直出,浏览器可以直接解析该字符串模版显示页面。SEO 友好:正是因为服务端渲染输出到浏览器的是完备的 html 字符串,使得搜索引擎能抓取到真实的内容,利于 SEO。SSR 需要注意的问题: 虽然 SSR 能快速呈现页面,但是在 UI 框架(比如 React)加载成功之前,页面是没法进行 UI 交互的。TTFB (Time To First Byte),即第一字节时间会变长,因为 SSR 相对于 CSR 需要在服务端渲染出更对的 HTML 片段,因此加载时间会变长。更多的服务器端负载。由于 SSR 需要依赖 Node.js 服务渲染页面,显然会比仅仅提供静态文件的 CSR 应用需要占用更多服务器 CPU 资源。以 React 为例,它的 renderToString() 方法是同步 CPU 绑定调用,这就意味着在它完成之前,服务器是无法处理其他请求的。因此在高并发场景,需要准备相应的服务器负载,并且做好缓存策略。什么是 ServerlessServerless,它是云计算发展过程中出现的一种计算资源的抽象,依赖第三方服务,开发者可以更加专注的开发自己的业务代码,而无需关心底层资源的分配、扩容和部署。 特点: 开发者只需要专注于业务,无需关心底层资源的分配、扩容和部署按需使用和收费自动扩缩容更详细的有关 Serverless 介绍,推荐阅读:精读《Serverless 给前端带来了什么》 Serverless + SSR结合 Serverless 和 SSR 的特点,我们可以发现他们简直是天作之合。借助 Serverless,前端团队无需关注 SSR 服务器的部署、运维和扩容,可以极大地减少部署运维成本,更好的聚焦业务开发,提高开发效率。 ...

June 11, 2020 · 3 min · jiezi

万物皆可-Serverless-之使用-SCFCOS-给未来写封信

或许你有用过或者听说过《给未来写封信》,这是由全知工坊开发的一款免费应用,你可以在此刻给自己或他人写下一封信,然后选择在未来的某一天寄出,想必那时收到信的人看着这封来自过往的信时一定会十分感动吧。 本文来自 Serverless 社区用户「乂乂又又」供稿这次我就带大家一起来使用无服务器云函数 SCF 和对象存储 COS,快速开发一个属于自己的「给未来写封信」应用。 效果展示写下一封信,然后投递: 一封来自很久以前的信: 写给未来的自己 你也可以访问letter.idoo.top/letter来亲自体验一下(仅供测试之用,不保证服务一直可用) 操作步骤第一步:新建 python 云函数参见我之前的系列文章《万物皆可 Serverless 之使用 SCF+COS 快速开发全栈应用》 第二步:编写云函数Life is short, show me the code.老规矩,直接上代码 import jsonimport datetimeimport randomfrom email.mime.text import MIMETextfrom email.header import Headerimport smtplib# 是否开启本地debug模式debug = False# 腾讯云对象存储依赖if debug: from qcloud_cos import CosConfig from qcloud_cos import CosS3Client from qcloud_cos import CosServiceError from qcloud_cos import CosClientErrorelse: from qcloud_cos_v5 import CosConfig from qcloud_cos_v5 import CosS3Client from qcloud_cos_v5 import CosServiceError from qcloud_cos_v5 import CosClientError# 配置存储桶appid = '66666666666'secret_id = 'xxxxxxxxxxxxxxx'secret_key = 'xxxxxxxxxxxxxxx'region = 'ap-chongqing'bucket = 'name'+'-'+appid#配置发件邮箱mail_host = "smtp.163.com"mail_user = "xxxxxxxxxx@163.com"mail_pass = "xxxxxxxxxxxxxx"mail_port = 465# 对象存储实例config = CosConfig(Secret_id=secret_id, Secret_key=secret_key, Region=region)client = CosS3Client(config)#smtp邮箱实例smtpObj = smtplib.SMTP_SSL(mail_host, mail_port)# cos 文件读写def cosRead(key): try: response = client.get_object(Bucket=bucket, Key=key) txtBytes = response['Body'].get_raw_stream() return txtBytes.read().decode() except CosServiceError as e: return ""def cosWrite(key, txt): try: response = client.put_object( Bucket=bucket, Body=txt.encode(encoding="utf-8"), Key=key, ) return True except CosServiceError as e: return False#获取所有信件def getletters(): letterMap = {} letterTxt = cosRead('letters.txt') # 读取数据 if len(letterTxt) > 0: letterMap = json.loads(letterTxt) return letterMap#添加信件def addletter(date, email, letter): letterMap = getletters() if len(letterMap) > 0: letterMap[date+'_'+randomKey()] = email+'|'+letter return cosWrite('letters.txt', json.dumps(letterMap, ensure_ascii=False)) if len(letterMap) > 0 else False#删除信件def delletter(letter): letterMap = getletters() if len(letterMap) > 0: letterMap.pop(letter) return cosWrite('letters.txt', json.dumps(letterMap, ensure_ascii=False)) if len(letterMap) > 0 else False# 获取今日日期def today(): return datetime.datetime.now().strftime("%Y-%m-%d")# 判断信件是否到期def checkDate(t): return t[0:10] == today()# 根据时间生成uuiddef randomKey(): return ''.join(random.sample('zyxwvutsrqponmlkjihgfedcba0123456789', 6))# api网关回复消息格式化def apiReply(reply, html=False, code=200): htmlStr = r'''<!DOCTYPE html><html lang="zh-cn"><head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> <meta name="viewport" content="width=device-width, user-scalable=no, initial-scale=1.0, maximum-scale=1.0, minimum-scale=1.0"> <title>给未来的自己写封信</title> <style> html, body { padding: 0px; margin: 0px; height: 100vh; } .main { display: flex; flex-direction: column; justify-content: center; align-items: center; } .main_phone { display: flex; flex-direction: column; justify-content: start; align-items: center; } </style></head><body id='body'> <div class="main" style="width: 80vw;"> <div style="height: 5vh;"></div> <div id='letter_top'> <p style="text-align: center;">开始写信</p> <wired-textarea id="letter" style="height: 320px;width: 300px;" placeholder="此刻平静地写下一封信,给未来的自己一份温暖..." elevation="6" rows="14"></wired-textarea> </div> <div style="display: flex;align-items: center;justify-content: center;"> <div id='letter_left'> <p style="text-align: center;">开始写信</p> <wired-textarea id="letter" style="height: 320px;width: 300px;" placeholder="此刻平静地写下一封信,给未来的自己一份温暖..." elevation="6" rows="14"></wired-textarea> </div> <div style="width: 16px;"></div> <div> <p style="text-align: center;">送信日期</p> <wired-calendar id="calendar"></wired-calendar> </div> </div> <wired-divider style="margin: 16px 0;"></wired-divider> <p id="hitokoto"></p> <div> <wired-input id="email" placeholder="收件邮箱"></wired-input> <wired-button onclick="send()">投递</wired-button> </div> <div style="height: 5vh;"></div> </div> <script> let datex = ''; let myEmail = document.getElementById('email'); let myLetter = document.getElementById('letter'); let myCalendar = document.getElementById('calendar'); let width = window.innerWidth || document.documentElement.clientWidth || document.body.clientWidth let height = window.innerHeight || document.documentElement.clientHeight || document.body.clientHeight let pc = width >= height let today = new Date(); let info = today.toString().split(' '); let selected = `${info[1]} ${today.getDate()}, ${today.getFullYear()}`; document.getElementById('body').classList.add(pc ? 'main' : 'main_phone'); document.getElementById('letter_left').style.display = pc ? 'block' : 'none'; document.getElementById('letter_top').style.display = pc ? 'none' : 'block'; myCalendar.setAttribute("selected", selected); myCalendar.addEventListener('selected', () => { let selectedObject = myCalendar.value; let date = new Date(new Date().setDate(selectedObject.date.getDate())); datex = date.toISOString().substr(0, 10); }); function send() { if (datex.length < 1 || myEmail.value.length < 1 || myLetter.value.length < 1) { alert('信件内容、送信日期或投递邮箱不能为空'); return; } fetch(window.location.href, { method: 'POST', body: JSON.stringify({ date: datex, email: myEmail.value, letter: myLetter.value }) }).then(res => res.json()) .catch(error => console.error('Error:', error)) .then(response => alert(response.ok ? '添加成功:)' : '添加失败:(')); } </script> <script src="https://v1.hitokoto.cn/?encode=js&select=%23hitokoto" defer></script> <script src="https://unpkg.com/wired-elements@2.0.5/lib/wired-elements-bundled.js "></script></body></html>''' return { "isBase64Encoded": False, "statusCode": code, "headers": {'Content-Type': 'text/html' if html else 'application/json', "Access-Control-Allow-Origin": "*"}, "body": htmlStr if html else json.dumps(reply, ensure_ascii=False) }#登陆邮箱def loginEmail(): try: smtpObj.login(mail_user, mail_pass) return True except smtplib.SMTPException as e: print(e) return False#发送邮件def sendEmail(letter): temp=letter.split('|') receivers = [temp[0]] message = MIMEText(temp[1], 'plain', 'utf-8') message['From'] = mail_user message['To'] = temp[0] message['Subject'] = '一封来自很久以前的信' try: smtpObj.sendmail(mail_user, receivers, message.as_string()) print("send email success") return True except smtplib.SMTPException as e: print("Error: send email fail") return False#每天定时检查需要发送的信件def check_send_letters(): loginEmail() letters = getletters() for date in letters.keys(): if checkDate(date): sendEmail(letters[date])def main_handler(event, context): if 'Time' in event.keys(): # 来自定时触发器 check_send_letters() return if 'httpMethod' in event.keys(): # 来自api网关触发器 if event['httpMethod'] == 'GET': return apiReply('', html=True) # 返回网页 if event['httpMethod'] == 'POST': # 添加信件 body = json.loads(event['body']) flag = addletter(body['date'], body['email'], body['letter']) return apiReply({ 'ok': True if flag else False, 'message': '添加成功' if flag else '添加失败' }) return apiReply('', html=True)没错,这就是前面展示的网页应用的全部源码了,使用云函数 SCF 构建一个完整的前后端的全栈应用就是这么简单。 ...

June 10, 2020 · 7 min · jiezi

万物皆可-Serverless-之借助微信公众号简单管理用户激活码

作为一名独立开发者,最近我在考虑给自己的应用加入付费功能,然后应用的核心功能只需使用激活码付费激活即可。这个需求涉及到了激活码的保存、校验和后台管理,传统的做法可能是自己购买服务器,搭建配置服务器环境,然后创建数据库,编写后端业务逻辑代码,必要的时候还要自己去写一些前端的界面来管理后台数据。 这是一个十分耗时且无趣的工作。本文则独辟蹊径,尝试带大家使用云函数 SCF 和对象存储 COS,快速编写上线自己的用户激活码后端管理云函数,然后把自己的微信公众号后台做为应用前台,简单管理用户激活码。 效果展示 可以看到,现在我们只需要在自己的微信公众号后台回复 会员@激活时长,就可以添加并回复一个指定有效期的会员激活码,实现了在微信公众号简单管理用户激活码的需求。 操作步骤第一步:新建 python 云函数参见之前的系列文章《万物皆可 Serverless 之使用 SCF+COS 快速开发全栈应用》 第二步:编写云函数话不多说,上代码 import jsonfrom wechatpy.replies import ArticlesReplyfrom wechatpy.utils import check_signaturefrom wechatpy.crypto import WeChatCryptofrom wechatpy import parse_message, create_replyfrom wechatpy.exceptions import InvalidSignatureException, InvalidAppIdExceptionimport datetimeimport random# 是否开启本地debug模式debug = False# 腾讯云对象存储依赖if debug: from qcloud_cos import CosConfig from qcloud_cos import CosS3Client from qcloud_cos import CosServiceError from qcloud_cos import CosClientErrorelse: from qcloud_cos_v5 import CosConfig from qcloud_cos_v5 import CosS3Client from qcloud_cos_v5 import CosServiceError from qcloud_cos_v5 import CosClientError# 配置存储桶appid = '66666666666'secret_id = u'xxxxxxxxxxxxxxx'secret_key = u'xxxxxxxxxxxxxxx'region = u'ap-chongqing'bucket = 'name'+'-'+appid# 微信公众号对接wecaht_id = 'xxxxxxxxxxxxxxx'WECHAT_TOKEN = 'xxxxxxxxxxxxxxxxxxx'encoding_aes_key = 'xxxxxxxxxxxxxxxxxxxxxx'# 对象存储实例config = CosConfig(Secret_id=secret_id, Secret_key=secret_key, Region=region)client = CosS3Client(config)#微信公众号后台消息加解密实例crypto = WeChatCrypto(WECHAT_TOKEN, encoding_aes_key, wecaht_id)# cos 文件读写def cosRead(key): try: response = client.get_object(Bucket=bucket, Key=key) txtBytes = response['Body'].get_raw_stream() return txtBytes.read().decode() except CosServiceError as e: return ""def cosWrite(key, txt): try: response = client.put_object( Bucket=bucket, Body=txt.encode(encoding="utf-8"), Key=key, ) return True except CosServiceError as e: return False#获取所有会员激活码def getvips(): vipMap = {} vipTxt = cosRead('vips.txt') # 读取数据 if len(vipTxt) > 0: vipMap = json.loads(vipTxt) return vipMap#添加会员激活码def addvip(days): vip=randomKey() vipMap = getvips() if len(vipMap) > 0: vipMap[vip] = (datetime.datetime.now()+datetime.timedelta(days=days)).strftime("%Y-%m-%d") return cosWrite('vips.txt', json.dumps(vipMap, ensure_ascii=False)),vip if len(vipMap) > 0 else False,''#删除会员激活码def delvip(vip): vipMap = getvips() if len(vipMap) > 0: vipMap.pop(vip) return cosWrite('vips.txt', json.dumps(vipMap, ensure_ascii=False)) if len(vipMap) > 0 else False# 获取今日日期def today(): return datetime.datetime.now().strftime("%Y-%m-%d")# 判断激活码是否到期def checkVip(t): return t == today()# 随机生成激活码def randomKey(): return ''.join(random.sample('zyxwvutsrqponmlkjihgfedcba0123456789', 6))#每天定时检查删除过期的激活码def check_del_vips(): vipMap = getvips() if len(vipMap) < 1: return for vip in vipMap.keys(): if not checkVip(vipMap[vip]): vipMap.pop(vip) return cosWrite('vips.txt', json.dumps(vipMap, ensure_ascii=False))# api网关响应集成def apiReply(reply, txt=False, content_type='application/json', code=200): return { "isBase64Encoded": False, "statusCode": code, "headers": {'Content-Type': content_type}, "body": json.dumps(reply, ensure_ascii=False) if not txt else str(reply) }def replyMessage(msg): txt = msg.content if '@' in txt: keys = txt.split('@') if keys[0] == '会员': # 会员@356 --> 添加一个365天的会员激活码 flag,vip=addvip(keys[1]) return create_reply(f"您的激活码:{vip},有效期:{keys[1]}天" if flag else "添加失败", msg) return create_reply("喵呜 ''", msg)def wechat(httpMethod, requestParameters, body=''): if httpMethod == 'GET': signature = requestParameters['signature'] timestamp = requestParameters['timestamp'] nonce = requestParameters['nonce'] echo_str = requestParameters['echostr'] try: check_signature(WECHAT_TOKEN, signature, timestamp, nonce) except InvalidSignatureException: echo_str = 'error' return apiReply(echo_str, txt=True, content_type="text/plain") elif httpMethod == 'POST': msg_signature = requestParameters['msg_signature'] timestamp = requestParameters['timestamp'] nonce = requestParameters['nonce'] try: decrypted_xml = crypto.decrypt_message( body, msg_signature, timestamp, nonce ) except (InvalidAppIdException, InvalidSignatureException): return msg = parse_message(decrypted_xml) if msg.type == 'text': reply = replyMessage(msg) else: reply = create_reply('哈◔ ‸◔?\n搞不明白你给我发了啥~', msg) reply = reply.render() reply = crypto.encrypt_message(reply, nonce, timestamp) return apiReply(reply, txt=True, content_type="application/xml") else: msg = parse_message(body) reply = create_reply("喵呜 ''", msg).render() reply = crypto.encrypt_message(reply, nonce, timestamp) return apiReply(reply, txt=True, content_type="application/xml")def main_handler(event, context): if 'Time' in event.keys(): # 来自定时触发器 return check_del_vips() httpMethod = event["httpMethod"] requestParameters = event['queryString'] body = event['body'] if 'body' in event.keys() else '' response = wechat(httpMethod, requestParameters, body=body) return responseOK, 教程结束, ...

June 9, 2020 · 4 min · jiezi

Serverless-国内发展的纵向观察

云计算正在各领域持续深化其影响力,同样,各领域下日益变化的需求,也在倒逼云计算不断进行自我优化。2008 年可以说是大家比较公认的云计算元年,因为在这一年中越来越多的行业巨头和玩家注意到这块市场并开始入局。近年来,随着企业数字化转型在全球范围的普及,云计算产业得到了快速的发展。云正在重塑企业 IT 架构,外加上疫情的影响,数字化也被提上了许多企业的日程表,这更是加快了基于云服务的企业数字化转型。 但是力的作用是相互的,在改变行业的同时,行业也在改变着你。由于市场对于高效、快速、实时的需求越来越重,云计算的发展却逐渐“滞后”。原因在于过去十年来随着云计算的普及,许多应用和环境都已经变为了服务,开发者可以直接使用其中所集成的某一能力,是“构建一个框架运行在一台服务器上,对多个事件进行响应”的模式,但是这种模式对时下这种快速响应的需求已经感到了吃力。 2012 年,随着 Serverless 这一理念的推出,这一理念在霎时间就风靡了全球。在那个云计算还在努力扩张的时代,这种无服务器化的想法极大刺激了全球开发者的神经。Serverless 的出现更是将主机管理、操作系统管理、资源分配、扩容,甚至是应用逻辑的全部组件都集成为服务,开发者可以更直接的把大部分后台能力作为一个能力接口来使用。将开发过程中的能力使用改为服务使用,通过构建或使用一个微服务或微功能来响应事件。 那么这些企业为什么要采用 Serverless 呢?在此前 InfoQ 报道的一篇《2019 年 Serverless 应用报告:三分之二的落地实践都成功了?》的文章,其中提到了对于企业和开发者来说,促使他们使用 Serverless 最直接的因素有以下三点: 首先,「减少运营成本」是大家采用 Serverless 的第一大原因,应用 Serverless 之后,就无需为潜在的流量高峰购买大部分时间处于空闲状态的服务器机架;第二,「自动按需扩展」,采用 Serverless 之后,可以随时扩展到当前的使用量,消除了意外或者季节性流量高峰的困扰;第三是「无服务器维护」,由于企业中大部分开发人员都是软件工程师,并不是系统管理员,所以对于软件的修复、保护和管理并不擅长,而使用 Serverless 之后,这些工作都可以交给供应商,他们只需专注于软件开发。毫无疑问,这都是 Serverless 最具竞争力的优势。而这些深入人心的能力,就是 Serverless 在短短几年的发展历程中快速积累形成的。 Serverless,不只是一个单纯的理念Serverless 译为无服务器架构, 首次出现是在 2012 年;2014 年年底 AWS 推出了 Lambda 产品标志着 Serverless 逐渐走向商业化;2016 年 Google Cloud Function 和微软 Azure Function 的成功,使得 Serverless 理念开始成为趋势。 从理念空谈到实践落地,Serverless 开始走向繁荣。 提到 Serverless,很多人的第一印象就是 FaaS+BaaS,当然这是 Serverless 的一种实现形式,也是主流对 Serverless 的理解,但是对于 Serverless 的完整定义却一直都是这个领域内的问题之一。由于没有准确的定义,使得 Serverless 在前几年的定位过于宽泛,各类技术炒作也层出不穷。不过在最近几年的发展中,随着落地实践案例不断增多,业内对于 Serverless 的认知在加深,对于 Serverless 的定义也逐渐变得清晰。 ...

June 9, 2020 · 2 min · jiezi

万物皆可-Serverless-之云函数-SCFKaggle-端到端验证码识别从训练到部署

随着验证码技术的更新换代,传统的验证码识别算法已经越来越无用武之地了。近些年来人工智能迅速发展,尤其是在深度学习神经网络这一块生态尤为繁荣,各种算法和模型层出不穷。 本文来自 Serverless 社区用户「乂乂又又」供稿今天本文就尝试带大家借助 Kaggle+SCF 快速训练部署一个端到端的通用验证码识别模型,真正的验证码识别从入门到应用的一条龙服务,哈哈哈~ 效果展示 操作步骤第一步:了解 kaggle没做过数据科学竞赛的同学,可能不太了解 kaggle 哈。 Kaggle is the world’s largest data science community with powerful tools and resources to help you achieve your data science goals.这是 kaggle 官网)的自我介绍,简单来说 kaggle 是全球最大的数据科学交流社区,上面有许多关于数据科学的竞赛和数据集,并且提供了一些数据科学在线分析的环境和工具,一直以来吸引了全球大批数据科学爱好者,社区极其繁荣。 这里我们主要是用 kaggle 的 Notebooks 服务里的 kernel 环境来快速在云端训练自己的验证码识别模型。 你可能会问在本地训练不可以吗,为啥非得折腾着上云?哈哈,这还真不是折腾,普通人的电脑算力其实是有限的,而训练模型是需要强大 GPU 算力的支持,不然要训练到猴年马月~ 我们再来看一下 kaggle 上的 kernel 环境的配置: CPU 4核心,16 GB 运行内存GPU 2核心 13 GB 运行内存每个 kernel 有 9 小时的运行时长,GPU 资源每周 30 小时使用时长。除了硬件资源之外,kernel 环境里已经配置好了一些机器学习的常用库,包括 Pytorch, Tensorflow 2 等,它的机器学习环境是开箱即用的,零配置,零维护。 ...

June 9, 2020 · 2 min · jiezi

万物皆可-Serverless-之使用云函数-SCF-快速部署验证码识别接口

验证码识别是搞爬虫实现自动化脚本避不开的一个问题。通常验证码识别程序要么部署在本地,要么部署在服务器端。如果部署在服务器端就需要自己去搭建配置网络环境并编写调用接口,这是一个极其繁琐耗时的过程。 本文来自 Serverless 社区用户「乂乂又又」供稿但是现在我们通过腾讯云云函数 SCF,就可以快速将本地的验证码识别程序发布上线,极大地提高了开发效率。 效果展示 可以看到,识别效果还是蛮好的,甚至超过了肉眼识别率。 操作步骤传统的验证码识别流程是 图像预处理(灰化,去噪,切割,二值化,去干扰线等)验证码字符特征提取(SVM,CNN 等)验证码识别下面我就带大家一起来创建、编写并发布上线一个验证识别云函数 第一步:新建 python 云函数参见系列文章《万物皆可Serverless之使用 SCF+COS 快速开发全栈应用》 第二步:编写验证识别云函数 Life is short, show me the code.这里我就以一个最简单的验证码识别程序为例,直接上代码 import ioimport osimport timefrom PIL import Image as imageimport json#字符特征chars = { '1': [1, 1, 1, 0, 1, ...], '2': [1, 0, 0, 1, 0, ...], '3': [0, 1, 0, 0, 1, ...], # 其他字符特征...}# 灰度处理def covergrey(img): return img.convert('L')# 去除验证码边框def clearedge(img): for y in range(img.size[1]): img.putpixel((0, y), 255) img.putpixel((1, y), 255) img.putpixel((2, y), 255) img.putpixel((img.size[0]-1, y), 255) img.putpixel((img.size[0]-2, y), 255) img.putpixel((img.size[0]-3, y), 255) for x in range(img.size[0]): img.putpixel((x, 0), 255) img.putpixel((x, 1), 255) img.putpixel((x, 2), 255) img.putpixel((x, img.size[1]-1), 255) img.putpixel((x, img.size[1]-2), 255) img.putpixel((x, img.size[1]-3), 255) return img# 去除干扰线并转换为黑白照片def clearline(img): for y in range(img.size[1]): for x in range(img.size[0]): if int(img.getpixel((x, y))) >= 110: img.putpixel((x, y), 0xff) else: img.putpixel((x, y), 0x0) return img# 去噪/pnum-去噪效率def del_noise(im, pnum=3): w, h = im.size white = 255 black = 0 for i in range(0, w): im.putpixel((i, 0), white) im.putpixel((i, h - 1), white) for i in range(0, h): im.putpixel((0, i), white) im.putpixel((w - 1, i), white) for i in range(1, w - 1): for j in range(1, h - 1): val = im.getpixel((i, j)) if val == black: cnt = 0 for ii in range(-1, 2): for jj in range(-1, 2): if im.getpixel((i + ii, j + jj)) == black: cnt += 1 if cnt < pnum: im.putpixel((i, j), white) else: cnt = 0 for ii in range(-1, 2): for jj in range(-1, 2): if im.getpixel((i + ii, j + jj)) == black: cnt += 1 if cnt >= 7: im.putpixel((i, j), black) return im# 图片数据二值化def two_value(code_data): table = [serverless] for i in code_data: if i < 140: # 二值化分界线140 table.append(0) else: table.append(1) return table# 图片预处理def pre_img(img): img = covergrey(img) # 去色 img = clearedge(img) # 去边 img = clearline(img) # 去线 img = del_noise(img) # 去噪 return img# 处理图片数据def data_img(img): code_data = [serverless] # 验证码数据列表 for i in range(4): # 切割验证码 x = 5 + i * 18 # 可用PS确定图片切割位置 code_data.append(img.crop((x, 9, x + 18, 33)).getdata()) code_data[i] = two_value(code_data[i]) # 二值化数据 return code_data# 验证码识别def identify(data): code = ['']*4 # 验证码字符列表 diff_min = [432]*4 # 初始化最小距离--不符合的数据点个数(共120数据点) for char in chars: # 遍历验证码字符(每个字符比较一次4个验证码) diff = [0]*4 # 各验证码差距值(每个字符判断前重置此距离) for i in range(4): # 计算四个验证码 for j in range(432): # 逐个像素比较验证码特征 if data[i][j] != chars[char][j]: diff[i] += 1 # 距离+1 for i in range(4): if diff[i] < diff_min[i]: # 比已有距离还要小(更加符合) diff_min[i] = diff[i] # 刷新最小距离 code[i] = char # 刷新最佳验证码 return ''.join(code) # 输出结果def predict(imgs): code = '' img = imgs.read() img = image.open(io.BytesIO(img)) img = pre_img(img) # 预处理图片 data = data_img(img) # 获取图片数据 code = identify(data) # 识别验证码 return codedef apiReply(reply, code=200): return { "isBase64Encoded": False, "statusCode": code, "headers": {'Content-Type': 'application/json', "Access-Control-Allow-Origin": "*"}, "body": json.dumps(reply, ensure_ascii=False) }def main_handler(event, context): main_start = time.time() flag = True if 'image' in event['queryString'] else False code = predict(event['queryString']['image']) if 'image' in event['queryString'] else '无效的请求' return apiReply({ 'ok': flag, 'code': code, 'spendTime': str(time.time()-main_start) })老规矩,先捋一下整个云函数的流程。 ...

June 8, 2020 · 4 min · jiezi

万物皆可-Serverless-之使用云函数-SCFCOS-免费运营微信公众号

是的,你没听错,这一次我来带大家直接上手运营微信公众号。 本文来自 Serverless 社区用户「乂乂又又」供稿震惊,Awesome,哼,我才不信捏,所谓无图无真相 ~ 效果展示 更多的体验,可以关注我的微信公众号: 乂乂又又 (仅供测试,不要乱搞哈~) 嗯,这次我信了,快点教一下我吧,嘤嘤嘤~ 操作步骤在上一篇《万物皆可Serverless之使用SCF+COS快速开发全栈应用》教程中, 我们用腾讯云无服务器云函数 SCF 和对象存储实现了一个后端云函数,这个云函数可以根据我们的请求返回对应的结果。 现在我们将尝试在这个云函数的基础上解析微信 XML 消息,实现公众号消息的自动回复,关键词回复,文字菜单等功能。 第一步:添加相关依赖为了快速完成开发,这里我们选择 python 第三方开源库 wechatpy 来接入微信公众平台。 wechatpy 支持以下功能 普通公众平台被动响应和主动调用 API企业微信 API微信支付 API第三方平台代公众号调用接口 API小程序云开发 API可见功能是十分完整的,不仅支持普通公众平台主被动调用,企业微信和微信支付,甚至还支持第三方平台代公众号调用接口,拿来运营微信公众号是十分绰绰有余的~ 由于腾讯云函数的运行环境中缺少第三方库,需要我们自己手动上传添加依赖,这里我们需要添加的第三方依赖有:wechatpy、otionaldict、xmltodict 以及 timeout\_decorator 其中 wechatpy 需要依赖 otionaldict、xmltodict,timeout\_decorator 是用来限制函数运行时长的,具体的依赖文件可以自行 pip 安装后 copy 到云函数项目根目录,如上图。 第二步:接入微信公众号 这里需要记下自己的 AppID、Token 和 EncodingAESKey,消息加密方式建议选为安全模式。这个页面先不要关,一会儿上线发布好云函数还需要过来再次修改配置。 第三步:编写云函数解析并回复微信公众号消息这一步可以直接参考 wechatpy 的官方文档 Life is short, show me the code. 这里我就直接上代码了(原始业务代码已略去,可以按照自己的需求开发) import jsonimport timeout_decoratorfrom wechatpy.replies import ArticlesReplyfrom wechatpy.utils import check_signaturefrom wechatpy.crypto import WeChatCryptofrom wechatpy import parse_message, create_replyfrom wechatpy.exceptions import InvalidSignatureException, InvalidAppIdException# 是否开启本地debug模式debug = False# 腾讯云对象存储依赖if debug: from qcloud_cos import CosConfig from qcloud_cos import CosS3Client from qcloud_cos import CosServiceError from qcloud_cos import CosClientErrorelse: from qcloud_cos_v5 import CosConfig from qcloud_cos_v5 import CosS3Client from qcloud_cos_v5 import CosServiceError from qcloud_cos_v5 import CosClientError# 配置存储桶appid = '66666666666'secret_id = u'xxxxxxxxxxxxxxx'secret_key = u'xxxxxxxxxxxxxxx'region = u'ap-chongqing'bucket = 'name'+'-'+appid# 对象存储实例config = CosConfig(Secret_id=secret_id, Secret_key=secret_key, Region=region)client = CosS3Client(config)# cos 文件读写def cosRead(key): try: response = client.get_object(Bucket=bucket, Key=key) txtBytes = response['Body'].get_raw_stream() return txtBytes.read().decode() except CosServiceError as e: return ""def cosWrite(key, txt): try: response = client.put_object( Bucket=bucket, Body=txt.encode(encoding="utf-8"), Key=key, ) return True except CosServiceError as e: return Falsedef getReplys(): replyMap = {} replyTxt = cosRead('Replys.txt') # 读取数据 if len(replyTxt) > 0: replyMap = json.loads(replyTxt) return replyMapdef addReplys(reply): replyMap = getReplys() if len(replyMap) > 0: replyMap[reply]='我是黑名单' return cosWrite('Replys.txt', json.dumps(replyMap, ensure_ascii=False)) if len(replyMap) > 0 else Falsedef delReplys(reply): replyMap = getReplys() if len(replyMap) > 0: replyMap.pop(reply) return cosWrite('Replys.txt', json.dumps(replyMap, ensure_ascii=False)) if len(replyMap) > 0 else False# 微信公众号对接wecaht_id = 'xxxxxxxxxxxxxxx'WECHAT_TOKEN = 'xxxxxxxxxxxxxxxxxxx'encoding_aes_key = 'xxxxxxxxxxxxxxxxxxxxxx'crypto = WeChatCrypto(WECHAT_TOKEN, encoding_aes_key, wecaht_id)# api网关响应集成def apiReply(reply, txt=False, content_type='application/json', code=200): return { "isBase64Encoded": False, "statusCode": code, "headers": {'Content-Type': content_type}, "body": json.dumps(reply, ensure_ascii=False) if not txt else str(reply) }def replyMessage(msg): txt = msg.content ip = msg.source print('请求信息--->'+ip+'%'+txt) # 用来在腾讯云控制台打印请求日志 replysTxtMap = getReplys() # 获取回复关键词 if '@' in txt: keys = txt.split('@') if keys[0] == '电影': #do something return if keys[0] == '音乐': #do something return if keys[0] == '下架': #do something return if keys[0] == '上架': #do something return if keys[0] == '回复': #do something return if keys[0] == '删除': #do something return elif txt in replysTxtMap.keys(): # 如果消息在回复关键词内则自动回复 return create_reply(replysTxtMap[txt], msg) return create_reply("喵呜 ''", msg)def wechat(httpMethod, requestParameters, body=''): if httpMethod == 'GET': signature = requestParameters['signature'] timestamp = requestParameters['timestamp'] nonce = requestParameters['nonce'] echo_str = requestParameters['echostr'] try: check_signature(WECHAT_TOKEN, signature, timestamp, nonce) except InvalidSignatureException: echo_str = 'error' return apiReply(echo_str, txt=True, content_type="text/plain") elif httpMethod == 'POST': msg_signature = requestParameters['msg_signature'] timestamp = requestParameters['timestamp'] nonce = requestParameters['nonce'] try: decrypted_xml = crypto.decrypt_message( body, msg_signature, timestamp, nonce ) except (InvalidAppIdException, InvalidSignatureException): return msg = parse_message(decrypted_xml) if msg.type == 'text': reply = replyMessage(msg) elif msg.type == 'image': reply = create_reply('哈◔ ‸◔?\n好端端的,给我发图片干啥~', msg) elif msg.type == 'voice': reply = create_reply('哈◔ ‸◔?\n好端端的,给我发语音干啥~', msg) else: reply = create_reply('哈◔ ‸◔?\n搞不明白你给我发了啥~', msg) reply = reply.render() print('返回结果--->'+str(reply)) # 用来在腾讯云控制台打印请求日志 reply = crypto.encrypt_message(reply, nonce, timestamp) return apiReply(reply, txt=True, content_type="application/xml") else: msg = parse_message(body) reply = create_reply("喵呜 ''", msg) reply = reply.render() print('返回结果--->'+str(reply)) # 用来在腾讯云控制台打印请求日志 reply = crypto.encrypt_message(reply, nonce, timestamp) return apiReply(reply, txt=True, content_type="application/xml")@timeout_decorator.timeout(4, timeout_exception=StopIteration)def myMain(httpMethod, requestParameters, body=''): return wechat(httpMethod, requestParameters, body=body)def timeOutReply(httpMethod, requestParameters, body=''): msg_signature = requestParameters['msg_signature'] timestamp = requestParameters['timestamp'] nonce = requestParameters['nonce'] try: decrypted_xml = crypto.decrypt_message( body, msg_signature, timestamp, nonce ) except (InvalidAppIdException, InvalidSignatureException): return msg = parse_message(decrypted_xml) reply = create_reply("出了点小问题,请稍后再试", msg).render() print('返回结果--->'+str(reply)) # 用来在腾讯云控制台打印请求日志 reply = crypto.encrypt_message(reply, nonce, timestamp) return apiReply(reply, txt=True, content_type="application/xml")def main_handler(event, context): body = '' httpMethod = event["httpMethod"] requestParameters = event['queryString'] if 'body' in event.keys(): body = event['body'] try: response = myMain(httpMethod, requestParameters, body=body) except: response = timeOutReply(httpMethod, requestParameters, body=body) return response请求参数解析和COS读写部分可参考上一篇《万物皆可 Serverless 之使用 SCF+COS 快速开发全栈应用》教程 ...

June 8, 2020 · 5 min · jiezi

腾讯云云函数-SCF-日志检索最佳实践

开发者在云函数的开发调试、在线运维过程中,难免会遇到函数调用失败需要定位问题的情况,通常我们使用日志作为主要排障手段。 在云函数控制台中,我们可以看到包含函数调用状态的日志列表,直接筛选可过滤查看所有调用失败的日志。 如果我们能够从网关返回信息中拿到某个失败请求的 RequestId ,我们还可以根据 RequestId 检索指定请求的日志。 这是最基础的日志检索使用方法。 实际定位问题的过程中,有可能出现以下几种场景: 函数里的部分异常有进行捕获,但函数的调用状态依然是成功,此时怎么找到已捕获的异常?函数错误调用非常多,我只想查看某些指定模块的日志信息怎么办?收到告警提示我函数运行时间超过 x 秒,我如何迅速找到指定运行时长范围的调用日志?我要查看的业务日志包含多个不同的关键词,想要一次性找到多个关键词所在的日志怎么办?针对以上场景,我们可以利用「高级日志」功能解决上述全部问题。 高级日志如何使用下面给大家分享一下已捕获的异常,查找函数运行时间大于 x 的请求,关键词组合检索中如何使用高级日志。 1. 已捕获的异常云函数比较多的使用场景是和 API 网关组合使用实现 REST API ,以下我们结合一个实际的业务场景说明如何使用高级日志。 以下模拟一个 HTTP PUT 请求实现教师录入学生信息的功能。 def teacher_put(): print('insert info') try: fh = open("/tmp/testfile", "w") fh.write("students info xxxx") except IOError: print("Error: cannot find the file or open file failed") else: print("write info success") fh.close() return('teacher_put success') def main_handler(event, context): print(str(event)) if event["pathParameters"]["user_type"] == "teacher": if event["pathParameters"]["action"] == "get": return teacher_get() if event["pathParameters"]["action"] == "put": return teacher_put()由于上面写文件时的 IO 异常已被捕获,所以当找不到文件时,函数调用结果依然为成功,API 请求返回 null 。如果使用普通调用日志功能,需要逐条查看日志,这将会非常麻烦。 ...

June 8, 2020 · 1 min · jiezi

江娱互动世界争霸产品迁移至腾讯云云函数的实践

社交,是游戏玩家的一项基本需求,那么,在游戏中,成熟稳定的聊天系统担负着玩家交流的重要使命。 做为一家从不 996 的游戏创业公司,我们的两款产品《世界争霸》和《农场小镇》都在使用自研的聊天系统。随着在线人数逐渐增多,系统的稳定性和成本面临着更多的考验。于是,升级技术栈势在必行。 至此,核心目标已经出现,以保障性能为前提,同时做到省事和省钱。最终,腾讯云的云函数产品进入了我们的视线。 云函数,无需服务器,省去运维烦恼,只需要关注于业务逻辑代码,可谓省事。按量付费,用多少花多少,避免业务低谷期的资源浪费,可谓省钱。非常适合游戏聊天系统 API 这种复杂度低的中小型需求。 那么接下来我们关注的是,现有系统能不能无缝迁移过去,也就是云函数能不能满足目前所有的特定需求,我们一个一个来说。 第一个需求:少改代码原来的 API 部分是采用 swoole 做为底层扩展,部署在腾讯云的 CVM 上,并使用腾讯云的负载均衡来接收外部请求。代码层面则是使用了 composer 进行包管理,一款开源的 easyswoole 框架做为 http 业务的架子。 换用云函数的方案的话,非代码层面就变成了腾讯云 API 网关加云函数来提供服务,而为了方便,依然需要继续使用 composer 进行包管理。原来基于 swoole 的 http 框架无法继续使用,改代码的重点就在这里。 首先就是逻辑入口。我们需要确保用一个云函数来处理所有请求,毕竟云函数个数是有限的,而业务需求是无限的。 那么入口其实就只是一个路由而已,而我们需要做的,就是定义一种简单的路由格式,并在云函数入口代码处得到需要的信息,并转给原有的类进行处理,并返回特定的内容。 以下是一个简单的 url 格式例子:https://url/controller/action... 只需要解析云函数给出的 path,就能得到 controller 和 action,做一些判断后,调用相应类的方法,然后返回。基于这样的入口,原有的逻辑处理类就可以被调用到了。 其次,需要处理一下原来的逻辑处理类的父类,弃用框架后需要自己来做一个基本功能的父类,比如获取 querystring 内容、解析 body,返回统一格式的返回值等,这里就不细说。 上图中用 php 作为示例,不同的语言,思路都类似,说白了就是个适配问题。另外代码里还有一些需要改动的地方,比如数据库配置信息,云函数可以用环境变量来传递。比如原来的耗时任务的异步操作,这个后续会说到。 第二个需求:快速发布快速发布的能力很重要,因为我们在迁移过程中,会反复得尝试各种东西。那为什么不用本地测试呢?因为进行迁移时云函数本地测试的功能还不支持 PHP。使用 API 网关和云函数的组合时,发布流程是这样子的: 开发代码部署云函数 $LATEST 版本基于 $LATEST 版本打一个新版本号API 网关对应路径切换版本API 网关发布测试版本API 网关线上使用版本切换这是一个很麻烦的过程。一开始做迁移时,第三步还不支持 API 调用,无法做自动化步骤。当然后来已经支持了这个能力。也有更简单的方案:API 网关直接指向云函数的 $LATEST 版本。然后部署云函数即可。不过这个方案只适合测试阶段,不适合线上阶段的发布。 ...

June 5, 2020 · 1 min · jiezi

万物皆可-Serverless-之使用-SCFCOS-快速开发全栈应用

我一直想做一个网页应用,奈何没有系统学习过前端,直到后来我接触到腾讯云无服务器云函数 SCF,让前端可以快速获得后端的能力同时,一并解决了前端数据请求跨域的问题。 本文来自 Serverless 社区用户「乂乂又又」供稿没错,云函数 SCF 就是那种一旦用了就无法回到原来那种神奇的东西,让人不禁感叹为什么没有早点遇到 SCF 然后我花了大概一天的时间编写调试上线发布云函数(应用后端),然后又用了一天的时间学了下前端,主要是确定要用到的技术栈(后面我会再讲到这个问题),然后第三天正式开始开发应用,将云函数引入前端调用,测试数据,调整布局,打包网页发布到 coding pages。 所以在我是一个前端初学者的背景下,前后仅花了大概三天的时间,就完成了这样一个比较简单的网页应用 这就是 Severless 的魅力所在,它可以让你快速开发上线全栈应用,无论你是前端或是后端开发者都可以获益许多。 效果展示首页 视频播放页 更详细的体验可访问 https://wo-cao.cn/ ,仅做测试之用,不要乱搞哦~ 是不是有点跃跃欲试涅?让我们开始吧~ 前端部分由于初涉前端,前端丰富得让人眼花缭乱的生态让我花费了一整天的时间来确定所要用的框架。 这里大体说下我用到的前端技术栈,帮助小伙伴快速进入实际开发状态,不要像我这个前端小白一样在框架的选择上耗费太多时间 需求第三方库html预编译Pugcss预编译Stylusjs预编译TypeScript、Bable开发框架Vue代码美化ESlint、Prettier网页打包Parcel状态管理VuexUI组件Wired-Elements视频播放Dplayer、Hls.js数据请求Axios然后贴一下搜索列表页面的源码,展示一下 Vue+Pug+TypeScript+Stylus 写起网页来有多酸爽 <template lang="pug"> div(style="margin:2.5vw;display: flex;flex-wrap: wrap;") div#box(v-bind:class="pc ? 'box_pc' : 'box_phone'" v-bind:value="item.title" v-for="(item,index) in items" @click="playx(index)") wired-image(v-bind:class="pc ? 'img_pc' : 'img_phone'" elevation="2" :src="item.cover") div(style='width:100%;') p(style="text-align: center;font-size:1rem;") {{ item.title }}</template><script lang="ts">import 'wired-elements'import { open, pc, refreshPath } from '../app/tools/window'export default { name: 'ResultList', data() { return { pc: true, items: this.$store.getters.getJsonState } }, mounted() { this.pc = pc ? true : false }, methods: { playx(index: number) { let video = this.items[index] this.$store.commit('setPlayState', video) open(this, video.title, '/play') } }}</script><style lang="stylus" scoped>.img_pc max-width 17vw.img_phone max-width 22vw.box_pc margin:3vw; flex: 0 0 13%;.box_phone margin:2.5vw; flex: 0 0 28%; </style>具体的开发过程就不细讲了,因为我本身只是前端初学者,继续讲下去难免有班门弄斧,误导他人的嫌疑~ ...

June 5, 2020 · 4 min · jiezi

揭秘-Kubernetes-attachdetach-controller-逻辑漏洞致使-pod-启动失败

前言本文主要通过深入学习k8s attach/detach controller源码,了解现网案例发现的attach/detach controller bug发生的原委,并给出解决方案。 看完本文你也将学习到: attach/detach controller的主要数据结构有哪些,保存什么数据,数据从哪来,到哪去等等;k8s attach/detach volume的详细流程,如何判断volume是否需要attach/detach,attach/detach controller和kubelet(volume manager)如何协同工作等等。现网案例现象我们首先了解下现网案例的问题和现象;然后去深入理解ad controller维护的数据结构;之后根据数据结构与ad controller的代码逻辑,再来详细分析现网案例出现的原因和解决方案。从而深入理解整个ad controller。 问题描述一个statefulsets(sts)引用了多个pvc cbs,我们更新sts时,删除旧pod,创建新pod,此时如果删除旧pod时cbs detach失败,且创建的新pod调度到和旧pod相同的节点,就可能会让这些pod一直处于ContainerCreating 。现象kubectl describe pod kubelet log kubectl get node xxx -oyaml 的volumesAttached和volumesInUsevolumesAttached: - devicePath: /dev/disk/by-id/virtio-disk-6w87j3wv name: kubernetes.io/qcloud-cbs/disk-6w87j3wvvolumesInUse: - kubernetes.io/qcloud-cbs/disk-6w87j3wv - kubernetes.io/qcloud-cbs/disk-7bfqsft5k8s存储简述k8s中attach/detach controller负责存储插件的attach/detach。本文结合现网出现的一个案例来分析ad controller的源码逻辑,该案例是因k8s的ad controller bug导致的pod创建失败。 k8s中涉及存储的组件主要有:attach/detach controller、pv controller、volume manager、volume plugins、scheduler。每个组件分工明确: attach/detach controller:负责对volume进行attach/detachpv controller:负责处理pv/pvc对象,包括pv的provision/delete(cbs intree的provisioner设计成了external provisioner,独立的cbs-provisioner来负责cbs pv的provision/delete)volume manager:主要负责对volume进行mount/unmountvolume plugins:包含k8s原生的和各厂商的的存储插件 原生的包括:emptydir、hostpath、flexvolume、csi等各厂商的包括:aws-ebs、azure、我们的cbs等scheduler:涉及到volume的调度。比如对ebs、csi等的单node最大可attach磁盘数量的predicate策略 控制器模式是k8s非常重要的概念,一般一个controller会去管理一个或多个API对象,以让对象从实际状态/当前状态趋近于期望状态。 所以attach/detach controller的作用其实就是去attach期望被attach的volume,detach期望被detach的volume。 后续attach/detach controller简称ad controller。 ad controller数据结构对于ad controller来说,理解了其内部的数据结构,再去理解逻辑就事半功倍。ad controller在内存中维护2个数据结构: ...

June 3, 2020 · 2 min · jiezi

万物皆可-Serverless-之使用云函数-Timer-触发器实现每天自动定时打卡

不晓得大家有没有遇到过定时打卡的需求,比如商品秒杀,火车票定时开售、每日健康打卡等。这时候我们往往可以通过一些技术手段,编写一些自动化操作的脚本,来实现定时自动打卡的操作。 本文来自 Serverless 社区用户「乂乂又又」供稿当然本文并不探讨如何编写自动化的操作脚本,而是和大家介绍一下如何使用腾讯云函数的 Timer 触发器实现定时任务,来快速、稳定、低成本地实现一些 fancy 的操作(骚操作) 效果展示每日健康信息自动更新 每日定时数据报告 可以看到,定时任务搭配邮箱发送云函数运行结果,用起来还是蛮舒服的,还可以给自己做一个每日科技资讯推送、数据报告之类的小玩意,自娱自乐。其他的用途请大家大开脑洞,自行脑补吧~ 实战教程1. 新建云函数 运行环境我们选择 python3,模板函数选择定时拨测,然后点击下一步 模板函数的描述里写着「本示例代码的功能是定时拨测 URL 列表中的地址,并通过邮件发送告警」 而这正是我们想要的实现的功能,不过这个模板函数的邮件发送有点问题,我们稍后会详细说明 2. 模板函数分析下面我们来分析一下这段示例代码 # -*- coding: utf8 -*-import sysimport ossys.path.insert(0, os.path.dirname(os.path.abspath(__file__)) + "/..")import loggingimport jsonimport requestsfrom email.mime.text import MIMETextfrom email.header import Headerimport smtpliblogger = logging.getLogger()logger.setLevel(logging.DEBUG)# Third-party SMTP service for sending alert emails. 第三方 SMTP 服务,用于发送告警邮件mail_host = "smtp.qq.com" # SMTP server, such as QQ mailbox, need to open SMTP service in the account. SMTP服务器,如QQ邮箱,需要在账户里开启SMTP服务mail_user = "XXXXXXXXX@qq.com" # Username 用户名mail_pass = "****************" # Password, SMTP service password. 口令,SMTP服务密码mail_port = 465 # SMTP service port. SMTP服务端口# The URL address need to dial test. 需要拨测的URL地址test_url_list = [ "http://www.baidu.com", "http://www.qq.com", "http://wrong.tencent.com", "http://unkownurl.com"]# The notification list of alert emails. 告警邮件通知列表email_notify_list = { "XXXXXXXXX@qq.com", "XXXXXXXXX@qq.com"}def sendEmail(fromAddr, toAddr, subject, content): sender = fromAddr receivers = [toAddr] message = MIMEText(content, 'plain', 'utf-8') message['From'] = Header(fromAddr, 'utf-8') message['To'] = Header(toAddr, 'utf-8') message['Subject'] = Header(subject, 'utf-8') try: smtpObj = smtplib.SMTP_SSL(mail_host, mail_port) smtpObj.login(mail_user, mail_pass) smtpObj.sendmail(sender, receivers, message.as_string()) print("send email success") return True except smtplib.SMTPException as e: print(e) print("Error: send email fail") return Falsedef test_url(url_list): errorinfo = [serverless] for url in url_list: resp = None try: resp = requests.get(url, timeout=3) print (resp) except ( requests.exceptions.Timeout, requests.exceptions.ConnectionError, requests.exceptions.ConnectTimeout) as e: logger.warn("request exceptions:" + str(e)) errorinfo.append("Access " + url + " timeout") else: if resp.status_code >= 400: logger.warn("response status code fail:" + str(resp.status_code)) errorinfo.append("Access " + url + " fail, status code:" + str(resp.status_code)) if len(errorinfo) != 0: body = "\r\n".join(errorinfo) subject = "Please note: PlayCheck Error" for toAddr in email_notify_list: print ("send message [%s] to [%s]" % (body, toAddr)) sendEmail(mail_user, toAddr, subject, body)def main_handler(event, context): test_url(test_url_list)if __name__ == '__main__': main_handler("", "")这里要讲一下云函数的执行入口, ...

June 3, 2020 · 4 min · jiezi

万物皆可-Serverless-之免费搭建不限速-5-大云盘

大家应该都体验过网盘限速的痛苦,当我们在网络上好不容易找到资源准备下载时,却发现下载速度最快不过 200、300KB/S,这不禁让我回想起初中那会儿,家里使用电话线拨号上网时的网速,一个 4GB 的系统镜像要下整整一天。 本文来自 Serverless 社区用户「乂乂又又」供稿有人可能会说,你可以充钱开会员啊。 呵,你以为我是差开年费会员的钱吗?开玩笑,我可是连月费会员(连续包月最便宜那种)都舍不得开的人。 没错,穷就一个字,我只说一次,有钱人的快乐咱想象不到。 那么有什么办法可以曲线救国呢?废话少说,上图片! 效果预览搭建好的云盘主页 测试一下文件上传速度 测试一下文件下载速度 可以看到,整个网盘的上传和下载速度还是可以接受的(我这里是联通的 100M 宽带),会比一般网盘下载限速快许多。除此之外,基于解析出来的是 onedrive 直链,我们可以很轻松地实现文件在线预览的功能,见下图: 音频文件可直接在线播放 甚至可以在线预览 office 三件套 可以看到我们使用 Serverless+OneDrive 搭建好的云盘功能还是蛮 ? 的, 更详细的体验可以访问我已经搭建好的网盘,地址:http://onedrive.idoo.top/ 你是不是已经跃跃欲试了呢?马上开始教程,Let's go~~~ 实战教程1. 获取 OneDrive首先, 注册一个 OneDrive 账号。 具体可以参考网上的这篇教程《免费注册微软 Office365 教育版 OneDrive 网盘 5T 空间》 2. 下载 OneManagerOneManager-php 是一个 Onedrive 的列表索引和管理程序,可以部署到 heroku/SCF/normal 空间。 值得注意的是此程序的文件上传下载是走的 OneDrive 服务器,并不会消耗你的云函数流量。 下载完之后解压: 3. 新建云函数打开云函数控制台 云函数控制台 这里,我们把函数地区选到中国香港,然后点击新建 运行环境选择 php7.2,创建方式选择空白函数,依次点击下一步,完成。 函数创建完成后,打开函数代码,选择本地上传文件夹,将我们之前解压好的 OneManager-php 程序上传,选择保存。 ...

June 3, 2020 · 1 min · jiezi

基于-Serverless-架构的编程学习小工具

之前我做过一个在线编程的软件,目前用户量大概有几十万,通过这个 App 不仅仅可以进行代码的编写、运行还可以进行编程的学习。自己一直对 Serverless 架构情有独钟,恰好赶到我的这个 App 学习板块被很多人吐槽难用,索性就对这个学习板块进行重构,并且打算在重构的时候,直接将这个学习板块搬上 Serverless 架构。 本文作者 Anycodes基于 Serverless 架构重构是出于两个方面考虑 —— 一是 Serverless 架构能让个人开发者的运维工作变得简单,尤其是不用操心服务器,也不用关心流量洪峰(当然,对于我的个人项目而言,也没太多的洪峰),二是 Serverless 架构的按量付费,极大节约了成本。 整体设计数据库设计这个部分在之前是若干个大模块,现在统一整理到一个模块中进行项目重构,所以这里继续复用之前的数据库: 在这个数据库中,四个模块分别是:新闻文章、开发文档、基础教程以及图书资源。其中开发文档包括大分类,子列表以及正文等内容,这里表关联并没有使用外键,而是直接用的 ID 进行表之间的关联。 说实话,这个数据库设计的并不是很好,原因是因为初次构建这个数据部分,绝大部分数据都是在其他站点采集而来,当时由于模块快速上线,便直接按照原有格式存储,所以可以认为这个数据库中有很多表的字段其实是无效的,或者针对这个项目是未被使用的。 后端设计后端将会整体部署到一个函数上,功能整体结构: 整体功能就是云函数 SCF 绑定 API 网关触发器,用户访问 API 网关指定的地址,触发云函数,然后函数在入口处进行功能拆分,请求不同的方法获得对应的数据。 这里要额外说明一下,后端整体接口部署在一个函数的原因,是因为我这个模块的使用量并不是非常频繁,所以部署到一个函数上也不会出现超过最大实例的限制,如果超出限制是可以申请扩容的; 其次,所有的接口都是对数据库增删改查,放入到一个函数中,在一定程度上可以保证容器的活性,降低部分冷启动带来的问题,同时容器的复用,也可以在一定程度上降低后台数据库链接池的压力;除此之外,所有的接口功能,都是只需要最少的内存(64M)即可完整运行,不会因为个别接口的预估内存较大,进而影响影响整体的成本。 所以这里评估之后,是可以将多个接口,放入到一个函数中,对外提供对应的服务。 前端设计前端设计,预计在学习资源部分需要有 8 个页面,主要就是科技类新闻、教程、文档、图书等相关功能,通过墨刀绘制的原型图如下: 前端项目开发将会采用 Vue.js,并且将其部署到对象存储中,通过腾讯云对象存储的静态网站功能对外提供服务。 项目开发后端函数开发后端函数开发主要包括三部分 部分资源的初始化,部分资源初始化,需要在函数外进行,这样可以保证复用实例的时候不会再次建立链接,防止数据库连接池出现问题:def getConnection(dbName): conn = pymysql.connect(host="", user="root", password="", port=3306, db=dbName, charset='utf8', cursorclass=pymysql.cursors.DictCursor, ) conn.autocommit(1) return connconnectionArticle = getConnection("anycodes_article")数据库查询操作这一部分主要就是针对不同接口查询数据库,例如获取文章分类: def getArticleCategory(): connectionArticle.ping(reconnect=True) cursor = connectionArticle.cursor() search_stmt = ('SELECT * FROM `category` ORDER BY `sort`') cursor.execute(search_stmt, ()) data = cursor.fetchall() cursor.close() result = {} for eve_data in data: if eve_data['pre_name'] not in result: result[eve_data['pre_name']] = [] result[eve_data['pre_name']].append({ "id": eve_data["sort"], "name": eve_data["name"] }) return result例如获取文章列表: ...

June 2, 2020 · 2 min · jiezi

Serverless-Framework-OCR-快速搭建通用文字识别应用

在日常的工作生活中,文字识别与我们息息相关,比如身份证识别、随手拍扫描、纸质文档电子化等,无不显示着文字识别技术的重要性。为此,腾讯云通用文字识别产品 General OCR 应运而生,基于行业前沿的深度学习技术,支持将图片上的文字内容智能识别为可编辑的文本,大幅提升信息处理效率。而 Serverless Framework 与 OCR 的结合,则为用户提供了方便快捷、成本更低的通用文字识别应用部署方案。 为什么要用 Serverlesss Framework 来搭建,我们看看 Serverlesss Framework 有哪些优势: 0 配置,弹性扩缩容:Serverless Framework 基于云上 Serverless 资源完成开发,无需复杂配置,即可高效、快速构建 OCR 应用,并支持弹性扩缩容,降低使用成本,助力业务上线;实时监控,方便运维:部署成功后,您可通过 Serverless Dashboard 实时查看基础监控指标和应用级别的监控指标,并支持实时日志的输出和远端调试能力,屏蔽本地和云端环境的差异,提供完善的排障功能;组件化开发:提供组件化的开发和集成,便于用户修改和资源复用,使用更加灵活。接下来我们一起通过 Serverless Framework Component,快速搭建一个基于腾讯云 OCR 的文字识别应用 该模版主要包含以下组件: Serverless Express:通过云函数和 API 网关构建的 Express 框架实现 RESTful API。Serverless Website:前端通过托管 React 静态页面到 COS 对象存储中完成静态网站部署。实战前请确认: Node.js 版本需不低于 8.6,建议使用 Node.js 10.0 及以上版本开通腾讯云通用文字识别 OCR 服务快速搭建一个基于腾讯云 OCR 的文字识别应用,具体步骤如下: 1. 安装通过 npm 全局安装 Serverless Framework: npm install -g serverless安装完毕后,通过运行 serverless -v 命令,查看 Serverless Framework 的版本信息,确保版本信息不低于以下版本: ...

June 1, 2020 · 1 min · jiezi

腾讯云云函数快速入门实践

云函数 (Serverless Cloud Function,SCF) 是腾讯云为企业和开发者们提供的无服务器执行环境。无服务器并非真的没有服务器,而是说用户无需购买服务器,无需关心服务器 CPU、内存、网络配置、资源维护、代码部署、弹性伸缩、负载均衡、安全升级、资源运行情况监控等,也就是说不用专门安排人力做这些,只需专注于代码编写并上传即可。很大程度上降低了研发门槛,提升业务构建效率。 由于 Serverless 拥有近乎无限的扩容能力,核心的代码片段完全由事件或者请求触发,平台根据请求自动平行调整服务资源,用户只需为运行中的云函数付费,若云函数未运行,则不产生任何费用。 使用云函数是一种怎样的体验呢?一起来实践!使用腾讯云函数之前,我们先做一下准备工作:进入腾讯云注册页面,注册账号,开通云函数服务。腾讯云云函数提供了满足多种开发场景的工具和能力,目前支持通过控制台、SCF CLI、SCF VS Code 插件完成函数创建,创建函数的详细步骤可参考: https://cloud.tencent.com/doc... Hello World以云函数控制台为例,带领大家一起创建你的第一个模版函数。 登录云函数控制台,点击左侧导航栏「函数服务」,在函数服务页面上方选择地域,单击「新建」,如下图所示: 在「新建函数」页面填写函数名称,选择「运行环境」,控制台目前已支持的语言包括:Python 2.7 & 3.6、Node.js 6.10 & Node.js 8.9、Node.js 10.5、Java 8、Php 5 & Php 7。例如,我们选择运行环境:Python 3.6 ,选择模版函数快速创建,之后点击「下一步」: 配置保持默认,单击「完成」,可看到如下图所示: 说明:index.main_handler 参数值表示 SCF 控制台会将此段代码自动保存为 index.py 文件,并将该文件压缩和上传至 SCF 平台,用于创建云函数。 示例代码中的 main_handler 为入口函数,主要参数为: event 参数:可以获取触发源的消息。context 参数:可以获取本函数的环境及配置信息。如何使用控制台部署函数您只需要在线编辑函数代码,点击「保存」即完成部署。 如何配置触发器在已创建函数的详情页面,选择左侧「触发管理」,单击「创建触发器」 在弹出的「创建触发器」窗口中,将触发方式设置为「API 网关触发器」,其它参数保持默认配置,点击「提交』。如下图所示: 体验云端测试函数部署测试:选择「函数代码」,单击「测试」,运行代码并返回测试结果。如下图所示: 触发器配置测试:触发器创建成功后,会在该函数的触发方式页面生成访问路径。如下图所示: 在浏览器里「打开该访问路径」,若有如下显示则说明函数部署成功。 查看监控 查看日志 如果您想详细了解「如何借助云函数监控日志快速发现并定位问题」,可报名参加 6 月 4 日(周四)20:00 举办的 Tencent Serverless Hours 第三期线上分享会。 ...

June 1, 2020 · 1 min · jiezi

Serverless-与-Flask-框架结合进行-Blog-开发

随着时间的发展,Serverless 架构越来越火热,其按量付费、弹性伸缩等诸多优质特性,让人眼前一亮,不得不惊叹云计算为我们带来的便利。 本实践通过一个博客系统的开发,和大家简单地体验一下基于 Serverless 架构的博客系统是什么样的。 开发前的思考博客系统需要哪些功能?本文仅仅是 demo 性质,所以功能比较少,只有两个页面。具有文章管理、分类管理、标签管理以及留言管理等功能。同时为了方便用户管理,要有前台和后台两部分。前台如何做?前台可能是用户流量比较大的(相对后台而言),所以这部分就是用单独的函数。每个功能一个函数,初步判断前台可能需要:获取文章分类,获取文章列表,获取评论列表,增加评论,获取标签列表等接口。后台如何做?后台理论上是管理员的专属地盘,所以这一部分流量比较小,可以通过 flask-admin,放入到一个函数中来解决。为什么前台要那么多函数,后台用一个框架?整个项目就用一个框架不好么?首先要回答,整个项目用一个框架也是可以的,但是并不好。例如这个项目的后台,使用的是 Flask 框架,用了 flask-admin 来做后台管理,这个开发过程很简单,可能整个后台就一百来行代码就搞定了,但是这涉及到: 网页的返回,需要 APIGW 开启响应集成,响应集成的性能其实很差,所以相对来说,不太适合放在前端;一个完整项目比较大,可能需要的资源也会更多,那么我们就需要给这个函数更多的资源内存,可能会导致收费的增加,例如我的后台给的资源是 1024,我的前端每个函数给的内存资源是 128/256,在执行同样时间的时候,明显后者的费用降低了 4~8 倍。同样,函数可能涉及大冷启动,冷启动一个函数和冷启动函数中的一个完整的框架/项目,前者的速度和性能可能会更好一下;函数都有并发上限的,如果所有的资源全都请求到一个函数,那么很可能实际用户并发几个的时候,对用的函数并发就可能是几十几百,这很可能在用户稍微多一点的情况下,就会触及用户实例的上限限制,后台功能是非频繁功能,前台相对来说是更频繁的,所以前台是用单独接口更合理。登陆功能怎么做?非常抱歉,函数并不能像传统开发,将客户的一些登录信息缓存到机器上,但是客户端依旧可以使用 cookie,所以利用这个方法,可以做以下流程: 后台登录入口处,拉取 APIGW 传过来的 APIGW Event,看其中 headers/cookie 是否存在,不存在就会返回登录页面;如果 headers/cookie 存在,取 cookie 中的 token 字段,判断 token 字段是否和服务端的 token 字段吻合,吻合进入系统后台,不吻合返回登录页面用户登录,请求后台的登陆功能,如果账号密码正确,则返回给用户一个 token,客户端将 token 记录到 cookie 中问题来了: token 是什么?Token 可以认为是一个登录凭证,生成方法可以按照自己设计升级,本实践比较简单,就直接用账号密码组合,然后 md5。token 存在那里?下次如何获取?Token 可以存在 Mysql 数据库中,也可以存在 Redis 中,甚至可以存在 COS 中,例如 Redis 和 COS,都可以利用其自身的一些特性做一些额外的操作,例如数据有效期(用来做登录过期等)。当然本文不想做的那么麻烦,所以每次用户请求过来,都是单独计算 token,然后进行的对比。这种 token 登陆方法可以用于其他项目么?还是仅适用于这种博客系统。可以适用其他项目,很多项目都可以通过这种方法来做,例如我自己的 Anycodes,也是通过 Token 进行鉴权,只不过在 Serverless 架构下,Token 如何存储是一个问题,但是我个人推荐有钱就用 redis,没钱就用 cos,不想额外花钱就像我,每次是用单独对比。token 存在 redis 可以理解,但是存在 cos 是为什么?cos 本身是对象存储,用来存储文件的,其实完全可以用来存储 token,例如我们每次生成一个新的 token,都把这个 token 设置为一个文件,文件内容就是这个 token 对应的用户信息或者是权限信息,或者其他的信息,然后存储桶策略设置成文件过期时间,例如文件存入 1 天自动删除,那么 1 天之后,你存储的这个 token 文件就会被删除。等用户带着 token 过来的时候,直接通过内网请求 cos(没有流量费)获取指定文件名,如果获取到了就下载回来(文件一般也就 1K 或者以下),然后进行其他操作,不存在就证明用户已过期,或者 token 错误,让他重新登录就好了。当然,这种方法可能不是最优解,但是确实是在 Serverless 条件下的一个有趣的做法。可以在小项目中尝试使用。项目本地开发如何进行调试?众所周知 Serverless 架构的本地调试很难。确实如此,虽然说本地调试很困难,但也不是不能越过去的,可以根据项目自己的需求,来做一些调试策略。项目开发项目开发过程主要就是数据库的增删改查,为了更加适应 Serverless 架构下的项目开发,也为了提高项目的开发效率特总结了相关的开发技巧和经验。 ...

May 29, 2020 · 13 min · jiezi

从企业微信机器人到小爱同学用-Serverless-实现生活智能化

通过定时触发器,可以简单快速地定制一个企业微信机器人。我们可以用它来实现喝水、吃饭提醒等小功能,还能实现定时推送新闻、天气,甚至是监控告警的小功能。 使用企业微信机器人在企业微信中,选择添加机器人: 之后,我们可以根据文档进行企业微信机器人的基础功能定制: 以下是用 curl 工具往群组推送文本消息的示例(注意要将 url 替换成机器人的 webhook 地址,content 必须是 utf8 编码): curl '企业微信机器人地址' \ -H 'Content-Type: application/json' \ -d ' { "msgtype": "text", "text": { "content": "hello world" } }'通过 Python 语言实现: url = ""data = { "msgtype": "markdown", "markdown": { "content": "hello world", }}data = json.dumps(data).encode("utf-8")req_attr = urllib.request.Request(url, data)resp_attr = urllib.request.urlopen(req_attr)return_msg = resp_attr.read().decode("utf-8")此时,我们可以通过 Serverless Framework 部署一个机器人的基本功能,并且设置好 API 网关触发器: index.py 文件如下: import osimport jsonimport urllib.requestdef main_handler(event, context): url = os.environ.get("url") data = { "msgtype": "markdown", "markdown": { "content": "hello world", } } data = json.dumps(data).encode("utf-8") req_attr = urllib.request.Request(url, data) resp_attr = urllib.request.urlopen(req_attr) return resp_attr.read().decode("utf-8")serverless.yaml 文件如下: ...

May 27, 2020 · 4 min · jiezi

基于-Serverless-与-Websocket-的聊天工具实现

传统业务实现 Websocket 并不难,然而函数计算基本上都是事件驱动,不支持长链接操作。如果将函数计算与 API 网关结合,是否可以有 Websocket 的实现方案呢? API 网关触发器实现 WebsocketWebSocket 协议是基于 TCP 的一种新的网络协议。它实现了浏览器与服务器全双工 (full-duplex) 通信,即允许服务器主动发送信息给客户端。WebSocket 在服务端有数据推送需求时,可以主动发送数据至客户端。而原有 HTTP 协议的服务端对于需推送的数据,仅能通过轮询或 long poll 的方式来让客户端获得。 由于云函数是无状态且以触发式运行,即在有事件到来时才会被触发。因此,为了实现 WebSocket,云函数 SCF 与 API 网关相结合,通过 API 网关承接及保持与客户端的连接。您可以认为云函数与 API 网关一起实现了服务端。当客户端有消息发出时,会先传递给 API 网关,再由 API 网关触发云函数执行。当服务端云函数要向客户端发送消息时,会先由云函数将消息 POST 到 API 网关的反向推送链接,再由 API 网关向客户端完成消息的推送。 具体的实现架构如下: 对于 WebSocket 的整个生命周期,主要由以下几个事件组成: 连接建立:客户端向服务端请求建立连接并完成连接建立;数据上行:客户端通过已经建立的连接向服务端发送数据;数据下行:服务端通过已经建立的连接向客户端发送数据;客户端断开:客户端要求断开已经建立的连接;服务端断开:服务端要求断开已经建立的连接。对于 WebSocket 整个生命周期的事件,云函数和 API 网关的处理过程如下: 连接建立:客户端与 API 网关建立 WebSocket 连接,API 网关将连接建立事件发送给 SCF;数据上行:客户端通过 WebSocket 发送数据,API 网关将数据转发送给 SCF;数据下行:SCF 通过向 API 网关指定的推送地址发送请求,API 网关收到后会将数据通过 WebSocket 发送给客户端;客户端断开:客户端请求断开连接,API 网关将连接断开事件发送给 SCF;服务端断开:SCF 通过向 API 网关指定的推送地址发送断开请求,API 网关收到后断开 WebSocket 连接。因此,云函数与 API 网关之间的交互,需要由 3 类云函数来承载: ...

May 26, 2020 · 4 min · jiezi