关于云原生-cloud-native:云原生赋能传统行业软件离线交付

一.离线交付的痛点在传统行业,如政府、能源、军工、公安、工业、交通等行业,为了避免数据泄露和运行平安思考,个别状况下网络会采取内外网隔离的策略,以防备不必要的危险,毕竟在平安防护方面,网络物理隔离是网络安全进攻最无效的伎俩,而网络隔离在软件交付过程中,对于内部软件开发厂商来说将会带来一系列的交付难题,也减少大量老本投入。例如: 1. 现场装置部署和验收测试,效率低下 交付过程中须要将应用程序及依赖的所有资源装置到离线客户环境,而客户环境有可能是物理服务器、虚拟机、公有云及K8s容器等各种环境,加上离线环境网络的限度,就会导致离线环境装置和部署效率低下。因为装置配置过程简约,容易出错,在最终交付环境中须要从新进行验证测试工作,也须要节约很多工夫。如果部署的是微服务架构的利用零碎复杂性更高,工作量还会加倍。 2. 离线环境定制开发和产品升级,老本高 定制开发须要开发人员投入,老本原本就高,在离线环境须要依据客户反馈继续迭代,迭代过程产品一直降级,每降级一次就要走一次装置部署和验证测试过程,老本很高。如果有些工作必须驻场开发,老本更高。 3. 网络不通,无奈近程运维 交付实现后,利用须要继续运维,保障运行稳定性和性能继续可用,在网络无奈联通的状况下,出任何问题都须要安顿人员现场反对,甚至须要安顿人员长期驻场。 二.技术选型上述问题的根本原因是因为,利用零碎的多环境适配、利用装置部署、利用降级、利用运维等操作自动化水平不高,须要大量人员手工操作,所以效率很低,解决问题的重点在解决利用治理的自动化。以后,云原生技术曾经越来越成熟,而云原生技术次要解决的就是利用治理的自动化问题,具体有两种开源实现计划 :1. Rancher+Helm Rancher是一款K8s管理工具,他提供K8s的治理UI,包治理应用Helm。对应离线交付的问题,Rancher能够装置在多种运行环境(物理服务器、虚拟机、公有云),并且提供局部利用自动化运维性能,它能够解决 多环境适配和 利用运维问题,而 利用装置部署和 利用降级问题能够通过Helm包解决。 2. Rainbond+利用模版 Rainbond是“以利用为核心”的利用治理平台,利用模版是Rainbond对利用打包的计划,Rainbond提供利用的全生命周期治理(利用开发、利用编排、利用交付和利用运维)。Rainbond能够部署到各种运行环境上(物理服务器、虚拟机、公有云),还能够部署到已有K8s集群和Ranchar上,解决客户多环境适配问题;Rainbond提供利用运维面板解决利用运维问题,应用比较简单,不须要懂容器概念;Rainbond的利用模版是一个亮点,只有在Rainbond上运行起来的利用就能够一键公布成利用模版,简化了利用模版的制作,而且利用模版能够导出离线包,特地适宜离线环境的 利用装置部署和 利用降级。 上面别离比拟一下两个计划 Rainbond相比Rancher最大的长处就是易用性,不须要学习K8s和容器相干技术和概念,另外,Rainbond提供的一体化开发环境和模块编排性能,能大幅度提高定制开发的效率。Rancher最大的长处是齐全兼容K8s体系,如果理解K8s能很快上手。 Helm和利用模版比拟 比照项Helm利用模板装置和降级大量配置全自动制作流程人工编写全自动导出和导入离线包不反对反对配置调整反对预约义的配置调整反对模块定制不反对反对兼容其余K8s版本兼容须要事后装置RainbondRainbond的利用模版 跟 OAM的设计思路完全一致,“以利用为核心”的设计理念,屏蔽掉容器基础设施的复杂性和差异性,为平台的使用者带来低心智累赘的、标准化的、统一的利用治理与交付体验。 综合比照,在离线交付场景Rainbond+利用模版的计划劣势显著,上面咱们结合实际例子,来解说Rainbond+利用模版交付离线客户的整个过程。 三.应用Rainbond利用模版进行离线环境的利用交付基于Rainbond进行离线环境的利用交付,只需将开发环境已开发好的业务公布至利用市场,基于利用市场导出利用模板的离线包,在交付环境中进行导入操作,导入后基于利用市场一键装置即可主动运行。 事后筹备环境 领有两套Rainbond集群,模仿开发环境及交付环境(开发环境为在线环境,交付环境为离线环境)。开发环境装置,参考 在线装置 文档;交付环境装置,参考 离线装置 文档;领有U盘、光盘等离线环境下利用模板离线包传输介质。1.业务部署整个流程始于开发环境,咱们首先须要将业务搬迁至Rainbond之上。在开发环境基于部署本人的业务,能够反对源代码或是镜像。以后以Spring Cloud微服务框架 Pig 为例,部署参考SpringCloud Pig 在Rainbond部署及利用制作。 2.利用公布 将开发测试环境已开发实现的利用公布至外部组件库:点击利用左侧导航栏 公布 按钮,抉择 公布到组件库 ,该过程须要 新建利用模板,利用模板定义了以下信息: 选项名阐明名称定义利用名称(必填)公布范畴利用模板的可见范畴,以后团队为以后团队可见,企业所有团队可见(必选)分类标签利用标签,可依照架构、行业、部署形式进行分类简介利用形容,帮忙使用者理解此利用Logo利用的Logo图片创立利用模板后定义利用公布版本: 选项名阐明版本号当同利用屡次公布时,如果版本号雷同,则会笼罩已公布的版本,如果不同,将公布为新版本,利用降级或回滚时,平台依据版本判断(必填)版本别名利用别名,例如 高级版,高级版版本阐明以后公布版本的阐明,可辨别不同版本的性能差别等信息公布组件模型配置: 选项名阐明连贯信息当连贯信息中呈现明码类的信息,可抉择每次部署时主动生成随机值环境变量编辑该组件默认的环境变量伸缩规定定义该组件可伸缩的最大最小节点数,及节点伸缩步长,最小装置内存限度。公布插件模型信息: 要公布的利用中其组件携带有插件时,会进行展现并在公布过程中追随组件公布。 所有信息配置结束后,点击公布按钮进行公布,业务开发过程中定义的组件间依赖关系、环境配置、长久化存储、插件、运行环境及上述定义的所有信息都将会被打包公布。 3.利用导出 将利用模板进行本地化导出,在首页利用市场中找到已公布的利用,点击最初方扩大按钮,抉择导出利用模板,抉择利用版本后点击利用模板标准下的导出按钮,导出过程齐全自动化,待导出实现后点击下载按钮即可将利用模板下载至本地,保留至U盘等挪动存储设备中,带到离线交付环境中去。 接下来进入离线交付流程,交付人员携带着装有离线包的U盘等挪动存储设备,开始导入利用模版。 4.利用导入 应用已导出的利用模板在交付环境中导入,点击利用市场界面的离线导入按钮,抉择本地的利用模板上传,上传完毕后抉择导入范畴: 企业或团队,企业为以后交付环境所有人可见,团队为指定团队下的人员可见;点击确认导入即进入自动化导入步骤。 5.一键部署 利用导入后点击装置按钮在以后交付环境即可一键部署该业务零碎,该环境业务运行环境与开发环境完全一致,到此实现离线环境下的软件交付。 6.增量降级 ...

November 11, 2021 · 1 min · jiezi

关于云原生-cloud-native:铺天盖地的云原生究竟是什么

文|togettoyou 目前次要负责云原生服务治理平台的研发 日常致力于 Go 、云原生畛域 本文 3164 字 浏览 5 分钟 ▼ 云原生仿佛曾经是一个陈词滥调的概念了,相干的文章层出不穷。 自己当初工作中负责云原生服务治理平台的研发(次要治理各类云原生基础设施,平台服务和第三方托管利用),但即便如此,常被问起云原生是什么时,我也很难简洁的向人表述分明,导致自我也常常问一遍,云原生到底是什么,我又在做什么。 PART. 1 云原生到底是什么云原生是一个组合词,即 Cloud Native 。 Pivotal(已被 VMware 收买)官网的 What is cloud native?[1] 一文中提到云原生是一种构建和运行应用程序的办法,云原生开发交融了 DevOps、继续交付、微服务和容器的概念在外面。 CNCF(云原生计算基金会)在 cncf/toc[2] 给出了云原生 V1.0 的定义: 云原生技术有利于各组织在私有云、公有云和混合云等新型动静环境中,构建和运行可弹性扩大的利用。云原生的代表技术包含容器、服务网格、微服务、不可变基础设施和申明式 API。 这些技术可能构建容错性好、易于治理和便于察看的松耦合零碎。联合牢靠的自动化伎俩,云原生技术使工程师可能轻松地对系统作出频繁和可预测的重大变更。 云原生计算基金会(CNCF)致力于培养和保护一个厂商中立的开源生态系统,来推广云原生技术。咱们通过将最前沿的模式民主化,让这些翻新为公众所用。 联合官网的定义,我集体对云原生简洁的了解就是:云原生并不是某种具体技术,而是一类思维的汇合,用来帮忙疾速构建和运行应用程序,其中既涵盖着一整套技术体系(容器、服务网格、微服务、不可变基础设施和申明式 API),也蕴含着利用开发的治理要点(DevOps、继续交付、康威定律[3]),只有合乎这类思维的利用就能够称为云原生利用。 PART. 2 云原生技术体系云原生的一整套技术体系其实是紧密联系的,这得从软件架构的逐渐演进说起。 即 :单体 -> 微服务 -> 基于 K8s 上的微服务 -> 服务网格 单体架构,将所有的性能集成在一个工程里,我的项目倒退晚期,利用的开发绝对简略,即便须要对利用进行大规模更改、测试、部署也很容易,甚至是横向扩大。运行多个实例后,一个负载均衡器就能够搞定。 随着时间推移,一个胜利的利用必然变得越来越臃肿,代码库随之收缩,团队治理老本一直进步,即俗话说的陷入单体天堂。面对单体天堂,开发者难以了解代码全副,开发速度变迟缓,部署周期变长,而且横向扩大也会遇到挑战,因为利用不同模块对资源的需要是互相冲突的,有些可能须要的是更大内存,有些可能须要的是高性能 CPU,作为单体利用,就必须都满足这些需要。 当呈现一个问题,天然会有针对该问题的解决方案,云原生技术体系之一的微服务架构就是针对单体天堂的解决方案。既然单体利用是将全副性能都集成在一个工程里去编译部署,那当初只有把各个性能拆分进去(通常是依据业务能力或者依据子域合成,子域围绕 DDD 来组织服务),将每个拆分的模块作为一个独自的服务,独立部署(服务之间通常通过 REST+JSON 或 gRPC+ProtoBuf 进行通信),使这一个个的服务独特提供整个利用的性能。 但微服务也不是银弹,引入微服务架构后,分布式系统也带来了各种复杂性。诸如配置核心、服务发现、网关、负载平衡等业务无关的基础设施层面都须要开发者自行在业务层面实现。 比方一个常见的微服务架构解决方案(图源凤凰架构[4]),就须要开发者自行引入各种组件: 我的项目开发实现后终归要到部署流程的,晚期的传统做法是把应用程序间接部署到服务器上,但服务器的零碎、环境变量等是会一直变动的,甚至装置了新的利用,就会引起和其余利用的抵触,导致利用自身须要跟着用户零碎环境的扭转而做出扭转。为了解决这个问题,不可变基础设施的口号就喊响了。 第一阶段是将服务部署为虚拟机,将作为虚拟机镜像打包的服务部署到生产环境中,每一个服务实例都是一个虚拟机。第二阶段,为了缩小开销,将服务部署为容器,作为容器镜像打包的服务部署到生产环境中,这样每一个服务实例都是一个容器。不可变基础设施: ...

November 9, 2021 · 1 min · jiezi

关于云原生-cloud-native:BFE-Ingress-Controller正式发布

大家期待已久的BFE Ingress Controller终于在近日正式公布! BFE Ingress Controller是基于 BFE 实现的Kubernetes Ingress Controller,用于反对在 Kubernetes 中应用 Ingress来裸露服务并进行负载平衡、SSL终结等,目前已正式公布并能够下载应用。BFE Ingress Controller采纳Apache-2.0 License,我的项目地址:https://github.com/bfenetwork... 。 背景随着云原生、容器化的一直推动,以及用户对BFE弱小能力的应用和理解,咱们一直收到社区的反馈,心愿可能为在Kubernetes环境中部署的服务,应用BFE进行流量接入和转发。 在Kubernetes中,对外裸露服务有Ingress、LoadBalancer、NodePort等多种形式。Ingress 是对服务的内部HTTP/HTTPS拜访进行治理的 API 对象。采纳Ingress裸露服务时,须要部署Ingress Controller,以依据 Ingress 资源上定义的规定对流量进行管制和路由。 往年2月,BFE开源社区的开发者们发动了基于BFE的Ingress Controller的我的项目,目标是提供一款Ingress Controller,使用户可能在应用Ingress进行流量接入时,享受到BFE的泛滥优良特点和弱小能力。通过大半年的开发和测试,BFE Ingress Controller终于在本月公布了。 次要性能BFE Ingress Controller实现了Kubernetes原生Ingress的性能,并基于BFE的能力,扩大了路由规定形容能力和服务间的流量调度能力。次要性能包含: HTTP/HTTPS流量路由 反对依据Host、Path、Header、Cookie对申请进行路由反对Path的准确匹配、前缀匹配反对Host的准确匹配、通配符匹配多Service之间负载平衡 反对在提供雷同服务的多个Service之间按权重进行负载平衡TLS终结灰度公布 反对基于HTTP Header/Cookie的服务灰度公布更多信息,见BFE Ingress Controller的文档。 如何部署咱们提供了BFE Ingress Controller的Docker镜像、所需的yaml配置文件、欠缺的手册,您能够依据手册中的“部署指南”,疾速上手部署BFE Ingress Controller。 Ingress配置通过配置Ingress资源,能够定义 Kubernetes 集群内服务对外提供服务时的流量路由规定。BFE Ingress Controller反对原生定义的Host规定、Path规定,并利用注解(Annotation)反对了Header和Cookie规定、多服务之间负载平衡的反对。在手册中的“配置指南”局部,咱们提供了具体的阐明和多个示例。 后续打算后续,咱们会将更多的BFE的成熟能力,退出到BFE Ingress Controller当中,并提供对Gateway API的反对。 期待您的应用反馈,并心愿有更多人退出BFE开源社区一起建设。

October 15, 2021 · 1 min · jiezi

关于云原生-cloud-native:柯基数据通过Rainbond完成云原生改造实现离线持续交付客户

1.对于柯基数据 南京柯基数据科技有限公司成立于2015年,提供一站式全生命周期常识图谱构建和运维、智能应用服务,致力于“链接海量数据,从大数据中开掘智慧“。帮忙企业使用常识图谱技术打造世界领先的认知工作自动化智能引擎。 目前在药企、医疗机构、军工院所、科技情报及出版等畛域服务了数十家大客户,积攒了丰盛的行业常识图谱使用开发教训。典型客户有国防科技大学、中国航空、中国电科等。 2.柯基数据的云原生之路 大家好,我是南京柯基数据的解决方案架构师刘占峰,云原生技术在交付运维上的劣势让我获益匪浅。作为我的项目合作伙伴,Rainbond继续助力柯基多套业务零碎的疾速开发和交付部署。在应用Rainbond之前,因为业务迭代周期短,波及组件多,平台版本更新耗时耗力,服务运维难度大。很多我的项目中,客户的运维能力储备有余,基于传统的交付和治理形式,客户对于业务运维基本接管不起来,只有打草惊蛇,必须要咱们派工程师到现场解决。针对交付运维存在的问题,各个业务平台开始着手云原生革新。 最开始咱们尝试本人搭建公司外部的开发测试环境,过程中遇到的两个小坑。 第一个坑是:环境搭建实现后应用体验却不佳,所有波及到磁盘读写的操作都显得异样卡顿,集群中的 Etcd 集群日志中一直报告处于 “read_only” 状态,随之而来的是服务器负载的一直飙升。 咱们带着狐疑的情绪求助了Rainbond开源社区,通过多方面的排查,咱们把眼光落在了磁盘的IO性能上。替换了高性能的磁盘之后,咱们重新安装了整个开发测试环境,磁盘性能的晋升确实解决了 Etcd 集群时常不工作的问题。 第二个坑是:应用了共享存储的服务却仍然处于读写极慢的状态,这着实令在场的所有工程师又开始头大了。确认了硬件性能之后,开始将眼光放在操作系统配置参数下面,操作系统内核在一直报告与共享存储无关的谬误:  NFS:__nfs4_reclaim_open_state: Lock reclaim failed!指征 nfs client 和 nfs server 之间存在同步差别,差得多了就会开始报警。通过一直摸索,工程师们终于锁定了与 nfs 性能无关的两个零碎参数,Linux nfs 客户端对于同时发动的NFS申请数量进行了管制,若该参数配置较小会导致 IO 性能较差。 echo "options sunrpc tcp_slot_table_entries=128" >> /etc/modprobe.d/sunrpc.conf批改了这两个参数后,共享存储的性能失去了显著的晋升,令人摸不到头脑的内核报警信息也随之隐没。开发测试环境终于能够顺畅应用了。 接下来面临新的挑战是如何将咱们的多套业务零碎顺利迁徙到 Rainbond 下来,所幸Rainbond 的应用很简略,整体学习梯度并不平缓,咱们很轻松把业务零碎分批的部署在 Rainbond 下来。然而 Rainbond 工程师组织的云原生利用评估却指出了业务零碎有多处不合乎云原生特色之处,提出了一些整改意见。在整改过程中,咱们对云原生也有了更深刻了解。 Elasticsearch等有状态组件须要将组件部署类型调整成为有状态单实例或有状态多实例,不能够是无状态 咱们最开始并不理解什么是有\无状态组件,所以并没有留神辨别组件的部署类型。Rainbond工程师提醒咱们,Elasticsearch在Rainbond平台中应该应用有状态的组件部署类型进行部署。 L1级云原生利用特色——可伸缩性 云原生利用重视部署组件所应用的资源类型,像数据库类型、音讯队列类型的服务组件对在Rainbond平台上,应该应用StatefulSet资源类型进行部署。通过对服务组件定义有状态或者无状态的部署类型,来规定应用StatefulSet或Deployment资源类型来部署实例。 反对横向伸缩 咱们的多套业务零碎,在接触云原生革新之前,都是传统的单体架构,部署时也根本不思考高可用个性。这使咱们的业务零碎相对而言软弱许多,没有任何容错能力,一旦服务器宕机,整个业务零碎就失去了服务能力。云原生革新的过程中,咱们借助于Rainbond人造的微服务能力,十分轻松的将咱们的业务零碎拆分成为更为正当的微服务架构。更令咱们惊喜的是,这些拆分进去的微服务组件,大多数间接具备了横向伸缩的能力,借助Rainbond的一键伸缩能力,迅速扩大成为多实例的集群,极大的进步了零碎的可用性。而针对某几个不能够一键伸缩的组件,Rainbond工程师们也提供了正当的意见,疏导咱们对这几个非凡的组件进行批改,使之实现了“无状态化”。当初,通过云原生革新的业务具备了“小强”个别倔强的生命力,再也不怕服务器宕机了。 L1级云原生利用特色——可伸缩性 通过程序数据拆散等伎俩,实现应用程序的无状态化,就让云原生利用能够随便横向伸缩多个实例。实例数量的伸缩一方面使云原生利用具备了高可用性,也间接影响其抗并发的能力。Rainbond还提供主动伸缩性能,实现削峰填谷。 所有配置反对环境变量配置,形如 ${GATEWAY_PORT:8083} 以往咱们都将服务的配置项写成固定的值,这样的做法使得咱们每到一个新的部署环境,都要从新更改大量的配置文件。Rainbond工程师指出,云原生利用应该将配置保留到环境当中,以环境变量加默认值的形式申明进去。而大多数须要批改的配置项,如不同组件之间的连贯地址信息,就能够通过Rainbond依赖关系中的连贯信息来互相注入,省去了大量的配置工作。 L1级云原生利用特色——可配置性 云原生利用推崇的一种最佳实际,就是将配置保留在环境之中。在不同的运行环境中,利用环境变量来进行配置,是一种十分好的体验。Rainbond反对为每个服务组件设置环境变量,也能够基于配置组性能,批量配置环境变量。 组件次要端口通过环境变量  ${PORT} 定义 Rainbond工程师提供了一个小技巧,将组件监听端口的配置,用一个固定的环境变量来配置,这个变量的值会随着咱们在Rainbond管制台上手动增加的端口号来主动变更,这样,咱们就能够在不更改代码和配置的状况下,随便变更想要监听的端口号,这很不便。 L1级云原生利用特色——可配置性 作为对环境变量的补充,Rainbond提供了一系列能够主动生成的环境变量,这些特定的环境变量极大不便了用户的应用。 所有组件须要对立时区 对立所有组件的时区配置是十分有必要的,Rainbond工程师提供了一个技巧,让时区的设置变成了一个很简略的事件。只须要运行环境的镜像中蕴含 tzdata 软件包,咱们就能够基于 TZ=Asia/shanghai 这样一个环境变量的配置,实现时区的配置了。 L1级云原生利用特色——根底可观测性 对立工夫在运维畛域非常重要,在云原生畛域,时区的配置也能够基于环境变量进行配置。 所有业务须要定义健康检查策略 ...

September 2, 2021 · 1 min · jiezi

关于云原生-cloud-native:云原生多云容器编排平台karmada上手指南

karmada是华为开源的云原生多云容器编排平台,指标是让开发者像应用单个k8s集群一样应用多k8s云。它的第一个release(v0.1.0)呈现在2020年12月,而正式公布则是在2021年4月25日,在深圳召开的华为开发者大会(HDC.Cloud)2021上。karmada汲取了CNCF社区的Federation v1和v2(也称为kubefed)我的项目教训与教训,在放弃原有k8s资源定义API不变的状况下,通过增加与分布式工作负载部署治理相干的一套新的API和管制面组件,不便用户将工作负载部署到多云环境中,实现扩容、高可用等指标。官方网站:https://karmada.io/代码地址:https://github.com/karmada-io...应用karmada治理的多云环境蕴含两类集群:host集群:即由karmada管制面形成的集群,承受用户提交的工作负载部署需要,将之同步到member集群,并从member集群同步工作负载后续的运行状况。member集群:由一个或多个k8s集群形成,负责运行用户提交的工作负载 架构图如下:本文形容karmada的上手流程,应用的karmada版本为v0.7.0后的commit:c4835e1f,与8月公布的v0.8.0差了二十几个commit。 karmada装置1.1. 装置docker依照docker官网文档在本机装置docker,对debian来说流程如下:装置根底工具 sudo apt-get update sudo apt-get install \ apt-transport-https \ ca-certificates \ curl \ gnupg \ lsb-release装置docker的gpg key: curl -fsSL https://download.docker.com/linux/debian/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg装置docker源 echo "deb [arch=amd64 signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/debian $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null装置docker apt-get updatesudo apt-get install docker-ce docker-ce-cli containerd.io1.2. 装置繁难k8s开发集群管理工具:kindkind官网对其形容:kind is a tool for running local Kubernetes clusters using Docker container “nodes”. kind was primarily designed for testing Kubernetes itself, but may be used for local development or CI.在本地曾经装置好go (1.11以上) 和docker的状况下,执行上面指令装置kind: ...

August 26, 2021 · 2 min · jiezi

关于云原生-cloud-native:一名分布式存储工程师的技能树是怎样的

很多刚刚进入存储行业或者想要转行到分布式存储行业的工程师,常常有困惑,就是“一名分布式存储工程师的技能树是怎么的?” 于是咱们高举这个问题专门去找了咱们的研发大拿们。 先说主题:“一名分布式存储工程师的技能树是怎么的?”咱们认为狭义上存储应该蕴含数据库,不过分布式数据库个别是“独挡一面”的:技术特点、技术难度、利用场景上都独具特色。 探讨分布式数据库齐全能够是一个独自的话题,因而这里先聚焦探讨分布式数据库之外的分布式存储。 分布式存储的话题还是很大,从拜访语义上,个别分为对象存储、块存储和文件存储。 先说对象存储,它的利用场景相对来说略窄,不如块存储是云计算的基石(IaaS时代,你创立个虚拟机,总得有块硬盘吧),它不如文件存储历史之久和利用之广,这次要是下层利用的拜访语义决定的,下层利用大多要么通过虚拟化的块存储拜访语义,要么通过文件POSIX语义拜访数据。 技术实现上,AWS S3是对象存储的事实标准,对象不反对更改,能承受短期的正本间的数据不统一。 对象存储的特点是谋求低成本,实现EC往往是必须的。 接下来,咱们探讨分布式块存储和分布式文件存储。它们的共性个别是谋求高性能,谋求数据强一致性。分布式块存储个别是给虚拟机提供虚构硬盘的,亦即各大公有云的EBS产品,大多数利用场景中,它只被一个客户端应用。而分布式文件系统往往被多个客户端并发应用,会面临并发的、海量的文件读写,技术上难度系数比拟高。 咱们的YRCloudFile定位是高性能分布式文件系统,因而咱们把重心放在着重探讨分布式文件系统工程师的技能树。鉴于每个局部都可做独自议题开展,所以这里仅简述。 咱们认为的分布式文件存储工程师的技能树骨干: 1)介质: 基于HDD设计是一回事,基于高性能SSD设计就齐全是另外一回事了。比方基于HDD用一般同步线程就够了,基于SSD,同步线程是跑不满硬件的,如果要进行IO polling的话,libaio好不好用,用内核最新的io_uring稳定性是否ok,都是面向SSD设计分布式文件存储时要应用的技能。另一方面,设施的低延时也突出线程上下文切换的性能损耗。 2)元数据架构: 是做有元数据结构,还是做无元数据的分布式构造。 咱们通过比照和选型,抉择了有元的。那么目录树如何切分?集群成员关系如何建设和保护,各种异样网络状况下,对于某个节点是死是活,集群各个成员是否达成统一?这也都是分布式文件存储工程师技能树上要把握的内容。 3)可靠性和一致性: 避免某块盘彻底坏了,要容错,个别都做正本,要么是多正本,要么用EC。那如何保障正本间数据的一致性? 4)效率: 很多客户都习惯于应用Linux本地文件系统,因为有pagecache,因而即使硬盘是HDD,客户个别都用的十分顺畅。转到分布式文件系统后,数据都是分布式搁置,数据可能在本地,也可能在远端,性能还能满足客户的需要吗?如何保障? 分布式文件系统个别都会用各种缓存,比方利用到客户端缓存,那么如何保障各个客户端之间的缓存一致性? 咱们认为分布式文件存储很有实践高度,也很有工程挑战。近年来国内技术提高十分疾速,技术分享也很全面。分布式存储的要害实践,网上曾经有很多,但须要新入行的敌人们去梳理脉络,从而本人去建设常识树。 互联网把世界拉平的同时,也把常识边界拉平了,你总能找到对于某个子话题的技术材料,但难就难在你须要晓得有这个子话题,难在你须要晓得要找哪方面的材料。 因而咱们认为,对于资深的分布式存储工程师来说,挑战次要是优良的工程实际,次要是如何去把模块实现得更简洁、更正当、更高性能。 而对于刚入行,想做分布式存储的工程师,或者具体一些,想做分布式文件存储的敌人们来说,须要有机会去体验构建分布式存储的理论过程,挑战次要是如何建设一棵正确的常识树 —— 这也是本话题的指标。 依据咱们的教训,要本人单打独斗地去构建这样的常识树,耗时很长,且对集体综合能力要求很高。 因而咱们是十分举荐各位参加一个分布式存储的我的项目。 能够是开源我的项目,也能够退出做分布式存储的公司。

July 19, 2021 · 1 min · jiezi

关于云原生-cloud-native:使用-Docker-管理用-Rust-编写的-WebAssembly-程序

开发者能够通过 DockerHub 和 CRI-O 等 Docker 工具在 WasmEdge 中部署、治理和运行轻量级 WebAssembly 应用程序。 WasmEdge 是由 CNCF (Cloud Native Computing Foundation) 托管的 WebAssembly 运行时,是边缘计算应用程序的执行沙箱。尽管 WebAssembly 最后是作为浏览器应用程序的运行时而创造的,但其轻量级和高性能的沙箱设计使其成为通用应用程序容器的一个极具吸引力的抉择。 如果在 2008 年曾经有了 WASM + WASI,那么咱们压根无需开创 Docker 这个我的项目了。 — Docker 联结创始人 Solomon Hykes与 Docker 相比, WebAssembly 在启动时快一百倍, 占用更小的内存和磁盘空间,并且具备更优定义的平安沙箱。然而,毛病是 WebAssembly 须要本人的语言 SDK 和编译器工具链,使其作为开发者环境比 Docker 更受限制。WebAssembly 越来越多地用于边缘计算场景,通常这些场景中,部署 Docker 比拟艰难,或是应用程序的性能至关重要。 Docker 的一大劣势是其丰盛的工具生态系统。咱们心愿为 WasmEdge 开发者带来相似 Docker 的工具。为了实现这一点,咱们为 CRI-O 创立了一个名为 runw 的代替 runner 来加载并运行 WebAssembly 字节码程序,如同他们是 Docker 镜像文件一样。 在 CRI-O 中装置 WebAssembly runner为了在 CRI-O 中反对 WebAssembly,您只需下载 runw 二进制码公布并将其装置到您的 CRI-O 中。 ...

July 1, 2021 · 5 min · jiezi

关于云原生-cloud-native:深度解读畅捷通云原生架构转型实战历程

在信通院 2021 年云原生产业大会上,畅捷通取得 2021 年度云原生优良案例。 畅捷通公司是用友团体旗下的成员企业,专一于服务国内小微企业的财务和治理服务。一方面,畅捷通将本人的产品、业务、技术架构互联网化;另一方面,畅捷通推出了畅捷通一站式云服务平台,面向小微企业提供以数智财税、数智商业为外围的平台服务、应用服务、业务服务及数据增值服务,致力于建设“小微企业服务生态体系”。 依据易观国内的报告,目前畅捷通在国内小微企业云服务市场的覆盖率放弃第一。有超过 130 万家企业与机构通过应用畅捷通的软件及服务,实现降本提效、继续翻新、数智化转型。 晚期,畅捷通的业务利用都是构建在公司自主研发的 CSP 平台之上,包含客户管家、易代账、好会计和好生意等,每个企业调配一个独立的虚机,资源齐全隔离,初期该平台计划极大简化了开发的复杂度,进步了开发效率,满足公司向云服务倒退的最后需要。 新的需要 随着用户规模的增多,现有为每个用户调配一个独立虚机的计划产生的问题很突出。首先体现在虚机的数量日益宏大,在客户转换率不高的状况下,容易造成资源的节约,同时运维老本也偏高;其次,不同的用户软件迭代的版本不尽相同,还须要专门设计保护多套版本的补丁更新零碎;第三,产品须要停服上线,业务会呈现短暂不可用的状况;最初,如果若干用户的业务呈现高峰期,不能疾速弹性扩容,资源的利用率不高。 在此背景下,畅捷通研发团队决定尝试以后业界比拟通用的云原生架构设计计划,利用云上的基础设施,共享计算资源和存储资源,采纳容器化计划,疾速弹性扩容,利用微服务架构,按利用更新产品,彻底解决以后运维老本偏高、弹性有余、资源利用不平衡的问题。 小微企业的特点是数量多、单个企业业务量绝对较小、企业 IT 能力无限。以畅捷通好生意产品为例,采纳现有的云原生架构,可能不便畅捷通疾速开发出一款应答大规模小型用户,反对弹性可扩大的 SaaS 利用。同时通过服务的编排,又能疾速搭建出其余产品线,如智+。目前曾经有超过 20 万的付费用户正在应用畅捷通提供的云原生架构企业云服务,每天产生的业务数据达百 G 以上。 云原生利用架构的驱动力 国内云计算产品疾速倒退,企业应用往云端迁徙趋势显著,加上政府部门激励企业上云推出补贴政策,企业上云已成为大势所趋。 尤其在疫情阶段下,商业模式的改革,生产形式的转变,只有企业上云能力更有利于推动企业放慢数字化、智能化的转型,更无效的帮忙企业实现“客户在线、业务在线、人员在线、治理在线”。而当初的云原生技术带来的价值能更好的帮忙企业进行数智转型。 1. 实时在线 采纳智能接入网关,就近接入云企业网,在 VPC 间、VPC 与本地数据中心间搭建私网通信通道,通过主动路由散发及学习,进步网络的疾速收敛和跨网络通信的品质和安全性,保障用户寰球范畴实时在线,减速实现整个客群的线上线下一体化。 2. 数智化 通过云端便宜的存储、弱小的算力资源以及泛滥的算法模型,畅捷通用极低的老本存储海量数据并在线实时剖析,为用户提供更多的商业决策。 3. 疾速响应市场需求 采纳 DDD 设计思维,利用微服务架构,疾速开发高内聚、低耦合的利用。这些利用通过服务的编排,能疾速组合更多的利用,满足不同行业和畛域的客户群体,达到疾速上线、迭代优化的成果。 4. 稳固高牢靠 利用容器和微服务架构,能够疾速构建和运行可弹性扩大的利用。零碎呈现故障或者性能瓶颈的时候,通过镜像能够秒级复原受损利用,保障了零碎的高可用性。利用云原生技术的红利,畅捷通能够只关注业务的开发,一方面减速构建新利用,另一方面也能够优化现有利用并在云原生架构中集成,达到奔跑中更换轮子的成果,去更不便地让历史存量的客户降级到云上。 云原生利用架构设计 云原生利用架构设计路线 原有产品是部署在物理 IDC 中,通过对 cloudfoundry 云平台的二开,实现每个租户间虚机的隔离。但因为每个租户独享容器+数据库,当用户量达到几十万级时,数据库的降级效率、容器部署老本、硬件运维复杂度都显著晋升。通过利用的微服务化、上云来解决降本提效的问题火烧眉毛。 畅捷通通过基础设施上云、数据库上云、技术框架和业务框架的重构,实现了在多租户之间容器部署、利用共享、DB 共享,产品基于 EDAS 及集成在其上的阿里云容器服务 Kubernetes 版 ACK。心愿通过云原生的技术红利,解决以后运维老本高、零碎弹性有余、产品迭代交付周期长的问题。 利用架构的革新 1. 微服务架构 将简单利用依照业务的视角切分为高内聚、低耦合模块,这些模块独立开发、独立公布。业务畛域一共分为四层,即外围畛域服务层、业务畛域服务层、应用服务层和接口服务层。其中外围畛域服务层包含受权、UOM、组织(Party)、产品、计价、促销和存量模型模块,次要提供外围畛域常识、能力服务;业务畛域服务层是提供好生意业务的业务性能,包含洽购、库存治理和销售畛域服务;应用服务层基于具体利用场景,调用畛域服务,解决利用中具体的业务问题。每层服务都是一个独自的微服务,基于 EDAS 进行服务的全生命周期治理,通过引入 Spring Cloud 实现服务的注册发现以及治理。 此外,因为 EDAS 无缝集成了 ACK ,反对以容器的模式托管利用到阿里云 Kubernetes 集群或混合星散群(其余云域或IDC内自建集群),因而可能与畅捷通底层K8s集群买通,实现了 K8s 集群的定时弹性能力和基于 CPU/RT/Load 等某一监控指标的主动弹性能力。 ...

June 29, 2021 · 3 min · jiezi

关于云原生-cloud-native:阿里云中间件首席架构师李小平企业为什么需要云原生

作者|李小平前天我加入了信通院的云原生产业大会,加入会议的企业十分多,并且来自于各行各业,我在会场上十分感叹。我想起 2019 年的时候,我在搜索引擎上搜寻“云原生”这个词,那时的搜寻频率还比拟低,而 2019 年又是云原生在国内开始飞速发展的一年。而往年的云原生会场上,曾经有十分多的企业来加入,这些企业在技术、产品、生态中都在利用云原生,所以说,整个云原生曾经从最开始的技术变成了行业,当初倒退成了比拟大的产业,并且这个产业的规模每年以十分快的速度在增长。 在明天,可能有很多咨询机构、企业,或者是集体开发者都在解读云原生,兴许很多人对云原生都有比拟深刻的意识了。大家都能够认同的是,云原生必定与云无关,然而它扭转了什么,为企业带来什么价值呢?最外围的点应该是能够扭转企业的利用架构;还有一种可能是不扭转利用架构,只是把整个运维体系基于云原生进行重塑。但所有的这些,背地的目标都是为了减速企业的价值发明过程,简略的说,和制作企业改进生产线是一样的,外围点就是改进咱们作为软件企业的生产线。 阿里在云原生的实际从 2006 年就开始了。咱们在做云原生的过程中积攒了很多教训,咱们认为,明天云原生对于企业数字翻新次要提供了多个价值: 一是资源弹性。弹性这个词大家很容易了解,实际上弹性有不同的层面。比如说基于虚拟机的弹性,提供的弹性能力是分钟级的。如果基于这些技术的利用是毫秒级的,那么分钟级只解决了资源弹性问题,整个利用高可用问题还须要进一步解决。如果说弹性到了利用的层面,到了毫秒级,高可用问题也失去肯定水平的解决。 除此以外,零碎的稳定性也是大家十分关注的方面。云原生就是把整个软件结构过程中非功能性个性拉进去放到云原生产品下来,帮忙利用开发从非功能性处理过程中解脱进去,更多的专一在功能性。同样的,云原生有很多工具理念,能够让咱们变得更好,整个软件开发从代码到上线的工夫大幅缩短。同样的,明天在基于云原生可观测性下面咱们会积攒十分多的数据,这些数据能够联合机器学习这些能力,帮忙咱们改善企业的用户体验。这些对于业务来讲会带来比拟大的价值。 阿里云原生的实际历程明天,云原生在 CNCF、国内相干的开源、还有三方组织的推动下,能够使得一家企业在做技术选型的时候有十分多的选项。大家通常会面临一个问题,在这么多抉择外面,要真正达到生产可用的目标到底选谁?特地是当咱们的业务须要在十分短的工夫内就上线,在业务高速倒退的阶段,咱们应该选什么样的架构,选什么样的开源凋谢的产品,这个是摆在宽广企业技术决策者以及架构师背后的难题。在云原生畛域中,阿里云是绝对比拟早开始做自研的。从 2006 年到 2009 年互联网的中间件开始倒退,到阿里云正式成立,整个过程中咱们通过云原生解决很多业务问题。通过利用云原生相干技术,从晚期很好地反对了淘宝的高速倒退,到了 2015 年当前很好地反对了阿里的中台建设,以及到明天随着阿里巴巴整个生产零碎、外围零碎全副 100% 上云,这个过程中咱们使用的云原生技术,像容器技术、微服务技术支持的规模都是百万级以上。相干调研显示,这样的云原生落地规模在寰球范畴内都是十分当先的。实际上,对于很多企业来讲,兴许用不到这些规模,然而阿里通过解决这样的大规模下的性能、稳定性问题,积攒了十分多的硬核技术,最终可能把这些技术转变成了产品,通过阿里云对外输入,服务于各行各业的广大客户。 咱们认为,云原生对于整个软件的扭转,或者对软件公司的开发流程的扭转是十分粗浅的。首先 K8s 曾经变成了软件交付的规范界面,它扭转的不止是运维,而是从 CICD 到后续公布上线整个生产链条。因为所有生产流程失去扭转,以及很多企业通过云原生技术重塑了软件架构,使得软件架构从传统架构变成了新的、咱们称之为现代化的利用架构,因而云原生能够通过这种生产工具的改进进一步扭转企业的生产关系,最终影响企业,使得企业在软件开发过程中失去了极大的提速。阿里云在云原生实际过程中,积攒了很强的技术竞争力,体现在这些方面:一、咱们有十分多当先的技术解决云原生畛域外面的稳定性问题、可靠性问题,大规模下的高并发问题等。同时,咱们会把所有的这些技术通过开源凋谢的模式输入。咱们晓得,在云原生的世界,企业须要的是开源凋谢的技术,而不是被像阿里这样独自一个厂商所锁定的技术。这个过程中咱们基于开源凋谢技术标准积攒了很多产品的硬核能力。在产品上,除了大家看到的基于云原生利用架构里,还包含云原生数据库、云原生大数据等。 在云原生相干的畛域有比拟多的测评,在这些测评里,例如阿里云容器产品 ACK,在去年 Gartner 评测中拿到满分,寰球厂商中只有两个厂商拿到满分,阿里云是其中之一。往年,阿里云再次入选 Gartner 容器竞争格局。在新兴的计算状态畛域中,往年阿里云进入 Forrester FaaS 领导者象限,函数计算取得了寰球 FaaS 产品最高分。在可观测性里,阿里云代表国内云厂商进入 Gartner APM 象限。所有这些三方评估从另外一个层面反映了阿里云产品的能力。容器架构上,咱们基于开源凋谢的 K8s 技术体系,基于阿里云的硬件做深度的优化,在比拟多的畛域和场景里为宽广 K8s 利用提供服务。咱们把在 K8s 集群外面超大规模集群治理的能力输入到 ACK 产品外面,使得阿里云的客户在治理集群的时候,能够解脱大规模集群的治理复杂性问题。比方完满日记,作为美妆行业的独角兽公司,他们的业务倒退速度十分快,但在业务疾速倒退过程中,他们面临的问题就是在大促的场景中怎么更好地预留资源,以及在大促时怎么样比拟好地解决新上线的性能,以及需要的稳定性问题。在这个过程中,他们利用 PTS 作为压测,所有利用跑在 ACK 平台下面,通过压测模仿大促的流量,从而可能把整个大促从须要投入较大的状态晋升到具备能够常态化的做大促压测的能力,也通过这个能力使得零碎稳定性相干问题失去疾速收敛。 云原生中间件从微服务、音讯到各种利用工具以外,依据企业常见的 IT 场景,云原生中间件也提供了很多解决方案。阿里云中间件诞生于团体内的大规模调用场景,同时兼容开源,并且融入了更多产品能力,例如在整个大促过程中体现优异的可观测性、高可用能力等,都属于云原生中间件产品体系。同样在中间件畛域里,咱们也和较多企业客户有相应的单干。畅捷通是一家做 SaaS 的企业,迄今曾经为超过四百万的小微企业做了云管。ToB 类型的利用复杂度较高,最大的问题就是整个软件的公布频率是十分快的,怎么样在高频软件公布上面可能比拟好的解决软件的各种 BUG,或者解决设计上的有余带来的稳定性的问题,这是在后期探讨过程中畅捷通提出来的关注点。通过利用云原生中间件,不仅解决了整个利用的可观测性问题,并且让利用具备 360 度无死角可观测能力,通过利用探测可能疾速发现在整个压测过程中各种可能的不稳固危险,从而使得相应危险失去疾速的收敛。 Serverless很多学术机构在 Serverless 畛域深入研究,咱们预感 Serverless 极有可能会成为下一代支流技术趋势。阿里云在 Serverless 畛域里做到业界当先的毫秒级计费,以及在整个阿里云底层做深度优化,使客户的利用真正达到了智能的弹性、极致的运维和大幅晋升开发效率。阿里云也和许多企业客户达成深度单干,进行 Serverless 落地实际,通过帮忙客户将利用迁到 Serverless 技术体系上,达到比拟快的利用部署;同时,把利用的稳定性问题、运维都委托给 Serverless 这样的云产品去解决。 ...

June 24, 2021 · 1 min · jiezi

关于云原生-cloud-native:Cilium-首次集成国内云服务阿里云-ENI-被纳入新版本特性

作者:清弦阿里云技术专家,次要负责 ACK 容器网络设计与研发,阿里云开源 CNI 我的项目 Terway 次要维护者,Cilium Alibaba IPAM 负责人 背景近期 Cilium 社区公布了 Cilium 1.10 正式版本,在这个版本中正式反对阿里云 ENI 模式,阿里云也是国内首家反对 Cilium 的云厂商。 Cilium 是一个基于 eBPF 的高性能容器网络我的项目,提供网络、可观测性、平安三方面的解决方案。 Cilium 自身反对 Overlay 网络模式部署在各种云平台或者自建的集群上,然而这种非云原生的网络模式会带来不小的性能损耗。阿里巴巴云原生容器服务团队向 Cilium 社区奉献了阿里云 ENI 模式,使得在阿里云上能够以云原生形式运行 Cilium 。云原生容器服务团队奉献 PRhttps://github.com/cilium/cil...https://github.com/cilium/cil... 架构AlibabaCloud Operator 是集群内的网络资源控制器,承当对网络资源(ENI、ENIIP)对立治理、调配工作。 Cilium agent 通过 list-watch 机制、CNI 申请对 Operator 调配的地址资源进行配置、治理。这种架构将所有阿里云 OpenAPI 调用集中到 Operator 中,能够无效的进行 API 申请治理,防止大规模集群下 API 流控问题。 基于 Cilium 1.10 + 阿里云 ENI 的高性能云原生网络Cilium 应用了 EBPF 内核技术对传统数据链路进行了优化,绕过了Conntrack 模块,对容器场景下网络性能有了十分大的进步。在阿里云上应用 Cilium 1.10 + 阿里云 ENI 模式有多种依照形式,请浏览 Cilium 社区的装置文档[1]。为了使云上用户享受到更加杰出的网络性能,阿里云自研的开源 CNI 插件 Terway [2] 与 Cilium 实现了更好的联合。Terway 反对应用阿里云的弹性网卡来实现的容器网络。使得容器网络和虚拟机网络在同一个网络立体,在不同主机之间容器网络通信时不会有封包等损失,不依赖于分布式路由也能让集群规模不受限于路由条目限度。目前,Terway IPvlan 模式曾经深度集成 Cilium 。 ...

June 18, 2021 · 1 min · jiezi

关于云原生-cloud-native:OpenKruise-SidecarSet-助力-Mesh-容器热升级

作者| 赵明山(立衡) 前言OpenKruise 是阿里云开源的云原生利用自动化治理套件,也是以后托管在 Cloud Native Computing Foundation ( CNCF ) 下的 Sandbox 我的项目。它来自阿里巴巴多年来容器化、云原生的技术积淀,是阿里外部生产环境大规模利用的基于 Kubernetes 之上的规范扩大组件,也是紧贴上游社区规范、适应互联网规模化场景的技术理念与最佳实际。OpenKruise 在 2021.5.20 公布了最新的 v0.9.0版本( ChangeLog ),上一篇文章咱们介绍了新增 Pod 重启、删除防护等重磅性能,明天向大家介绍另一个外围个性,即 SidecarSet 基于上一个版本扩大了特地针对 Service Mesh 场景的反对。 背景:如何独立降级 Mesh 容器SidecarSet 是 Kruise 提供的独立治理 Sidecar 容器的 workload。用户通过 SidecarSet 可能便当的实现对 Sidecar 容器的主动注入和独立降级,详情请参考:OpenKruise 官网 默认状况下,Sidecar 的独立降级程序是先进行旧版本的容器,而后再创立新版本的容器。这种形式尤其适宜不影响 Pod 服务可用性的 Sidecar 容器,例如日志收集 agent ,然而对于很多代理或运行时的 Sidecar 容器,如 Istio Envoy,这种降级办法就有问题了。Envoy 作为 Pod 中的一个 Proxy 容器代理了所有的流量,这种场景下如果间接重启降级,Pod 服务的可用性必然会受到影响,因而须要思考利用本身的公布和容量状况,无奈齐全独立于利用做 Sidecar 的公布。 阿里巴巴团体外部领有上万的 Pod 都是基于 Service Mesh 来实现相互间的通信,因为 Mesh 容器降级会导致业务 Pod 的不可用,因此 Mesh 容器的降级将会极大妨碍 Service Mesh 的迭代。针对这种场景,咱们同团体外部的 Service Mesh 团队一起单干实现了 Mesh 容器的热降级能力。本文将重点介绍在实现 mesh 容器热降级能力的过程中 SidecarSet 是表演了怎么的重要角色。 ...

June 18, 2021 · 3 min · jiezi

关于云原生-cloud-native:春色满园关不住带你体验阿里云-Knative

作者 | 元毅 导读:Knative 是基于 Kubernetes 的开源 Serverless 利用编排框架。阿里云 Knative 在社区 Knative 根底之上,与阿里云产品进行了深度的交融,给你带来最纯正的容器化 Serverless 体验。 对于 Knative Knative 是基于 Kubernetes 的开源 Serverless 利用编排框架。实际上 Knative 蕴含的不单单是 Workload,它还有 Kubernetes 原生的流程编排引擎和齐备的事件零碎。Knative 指标是基于 Kubernetes 提供利用 Serverless 工作负载编排的标准化。Knative 外围模块次要包含事件驱动框架 Eventing 和部署工作负载的 Serving。 1. Serverless 服务引擎 - Serving Knative Serving 外围能力就是其简洁、高效的利用托管服务,这也是其撑持 Serverless 能力的根底。当然作为 Serverless Framework 就离不开按需分配资源的能力,Knative 能够依据利用的申请量在顶峰期间主动扩容实例数,当申请量减少当前主动缩容实例数,能够十分自动化地帮忙您节省成本。 Serving 还提供了流量治理能力和灵便的灰度公布能力。流量治理能力能够依据百分比切分流量,灰度公布能力能够依据流量百分比进行灰度。 1)简略的利用模型 提供了极简的利用模型 - Knative Service ,同时满足服务部署、服务拜访以及灰度公布的能力。能够用上面的公式表述:Knative Service = 工作负载(Deployment)+ 服务拜访( Service )+ 灰度流量( Ingress )。 ...

June 9, 2021 · 1 min · jiezi

关于云原生-cloud-native:OpenYurt-v040-新特性发布高效地管理边缘存储资源

作者 | 高文俊起源|阿里巴巴云原生公众号 简介OpenYurt 是由阿里云开源的基于原生 Kubernetes 构建的、业内首个对于 Kubernetes 非侵入式的边缘计算我的项目,指标是扩大 Kubernetes 以无缝反对边缘计算场景。它提供了残缺的 Kubernetes API 兼容性;反对所有 Kubernetes 工作负载、服务、运营商、CNI 插件和 CSI 插件;提供良好的节点自治能力和云边协同能力。OpenYurt 能够轻松部署在任何 Kubernetes 集群服务中,让弱小的云原生能力扩大到边缘。 边缘本地存储OpenYurt v0.4.0 版本推出全新个性:边缘本地存储管理,用于高效地治理边缘节点的存储资源,用户能够通过 ConfigMap 来动静配置集群内节点的本地资源,并能无缝对接 CSI 存储插件,通过原生的 PV/PVC 形式应用本地存储。该我的项目组件次要蕴含两个局部, 一个是定义在集群中 kube-system namespace 的 node-resource-topo ConfigMap, 一个是部署在集群中 kube-system namespace 上面的 node-resource-manager Daemonset, 每个 Node 节点上的 node-resource-manager 通过挂载 node-resource-topo ConfigMap 的形式生产并治理用户定义的本地资源。架构如下: 次要长处: 简略易用:node-resource-manager 能够仅通过定义 ConfigMap 就实现对集群中的本地资源的初始化和更新。易于集成:node-resource-manager 能够与 csi 插件集成来实现 kubernetes 集群中的相干本地资源的生命周期治理。与云平台无关:node-resource-manager 能够轻松部署在任何齐全兼容 Kubernetes API 的集群中。对于边缘本地存储设备治理的详情和应用办法,请参考 configmap.md:https://github.com/openyurtio/node-resource-manager/blob/main/docs/configmap.md。 IOT 设施治理 API阿里联结 VMware 在 OpenYurt 社区推出了 IOT 边缘设施治理的 API 规范定义,API 基于 Kubernetes 的 CRD(custom resource definitions)模型实现。任何边缘平台只需实现对应 CRD Controller,即能通过这些 API 接入 OpenYurt 集群,实现面向终态的设施治理。将来咱们将持续基于 OpenYurt + EdgeX Foundry 来进行 IOT 等边缘场景下的摸索,共建对立 API 下的多场景设施接入、使能和交融能力,打造云原生 IOT 畛域规范。 ...

June 3, 2021 · 1 min · jiezi

关于云原生-cloud-native:蚂蚁云原生应用运行时的探索和实践-ArchSummit-上海

Mesh 模式的引入是实现利用云原生的要害门路,蚂蚁团体已在外部实现大规模落地。随着 Message、DB、Cache Mesh 等更多的中间件能力的下沉,从 Mesh 演进而来的利用运行时将是中间件技术的将来状态。利用运行时旨在帮忙开发人员疾速的构建云原生利用,帮忙利用和基础设施进一步解耦,而利用运行时最外围是 API 规范,冀望社区一起共建。 蚂蚁团体 Mesh 化介绍蚂蚁是一家技术和翻新驱动的公司,从最早淘宝里的一个领取利用,到当初服务寰球十二亿用户的大型公司,蚂蚁的技术架构演进大略会分为如下几个阶段: 2006 之前,最早的支付宝就是一个集中式的单体利用,不同的业务做了模块化的开发。 2007 年的时候,随着更多场景领取的推广,开始做了一下利用、数据的拆分,做了 SOA 化的一些革新。 2010 年之后,推出了快捷领取,挪动领取,撑持双十一,还有余额宝等景象级产品,用户数到了亿这个级别,蚂蚁的利用数也数量级的增长,蚂蚁自研了很多全套的微服务中间件去撑持蚂蚁的业务; 2014 年,像借呗花呗、线下领取、更多场景更多业务状态的呈现,对蚂蚁的可用性和稳定性提出更高的要求,蚂蚁对微服务中间件进行了 LDC 单元化的反对,撑持业务的异地多活,以及为了撑持双十一超大流量的混合云上的弹性扩缩容。 2018 年,蚂蚁的业务不仅仅是数字金融,还有数字生存、国际化等一些新策略的呈现,促使咱们要有更加高效的技术架构能让业务跑得更快更稳,所以蚂蚁联合业界比拟风行的云原生的理念,在外部进行了 Service Mesh、Serverless、可信原生方向的一些落地。 能够看到蚂蚁的技术架构也是追随公司的业务翻新一直演进的,后面的从集中式到 SOA 再到微服务的过程,置信搞过微服务的同学都深有体会,而从微服务到云原生的实际是蚂蚁近几年本人摸索进去的。 为什么要引入 Service Mesh蚂蚁既然有一套残缺的微服务治理中间件,那为什么还须要引入 Service Mesh 呢? 拿蚂蚁自研的服务框架 SOFARPC 为例,它是一个功能强大的 SDK,蕴含了服务发现、路由、熔断限流等一系列能力。在一个根本的 SOFA(Java) 利用里,业务代码集成了 SOFARPC 的 SDK,两者在一个过程里运行。在蚂蚁的大规模落地微服务之后,咱们就面临了如下的一些问题: 降级老本高:SDK 是须要业务代码引入的,每次的降级都须要利用批改代码进行公布。因为利用规模较大,在一些大的技术变更或者平安问题修复的时候。每次须要数千个利用一起降级,费时费力。版本碎片化:因为降级老本高,SDK 版本碎片化重大,这就导致咱们写代码的时候须要兼容历史逻辑,整体技术演进艰难。跨语言无奈治理:蚂蚁的中后盾在线利用大多应用 Java 作为技术栈,然而在前台、AI、大数据等畛域有很多的跨语言利用,例如 C++/Python/Golang 等等,因为没有对应语言的 SDK,他们的服务治理能力其实是缺失的。 咱们留神到云原生里有 Service Mesh 一些理念开始呈现,所以开始往这个方向摸索。在 Service Mesh 的理念里,有两个概念,一个是 Control Plane 管制立体,一个是 Data Plane 数据立体。管制面这里临时不开展,其中数据立体的核心思想就是解耦,将一些业务无需关系的简单逻辑(如 RPC 调用里的服务发现、服务路由、熔断限流、平安)形象到一个独立过程里去。只有放弃业务和独立过程的通信协议不变,这些能力的演进能够追随这个独立的过程自主降级,整个 Mesh 就能够做到对立演进。而咱们的跨语言利用,只有流量是通过咱们的 Data Plane 的,都能够享受到方才提到的各种服务治理相干的能力,利用对底层的基础设施能力是通明的,真正的云原生的。 ...

May 27, 2021 · 2 min · jiezi

关于云原生-cloud-native:Containerd-入门实战

Containerd 入门实战上一篇文章中咱们八卦了一下 containerd 的前世今生,以及在以后云原生生态中的地位(不小心鸽了这么久,小弟深感羞愧,现附上一篇文章的链接~)。那么本篇文章就来看看怎么应用 containerd 吧! 装置部署安装包下载containerd 提供了两种压缩包,一种是 containerd-${version}-${os}-${arch}.tar.gz,这个压缩包中仅蕴含了 containerd 相干的二进制文件;另外一个是cri-containerd-cni-${version}-${os}-${arch}.tar.gz,这外面是一个比拟全的压缩包,除了 containerd 相干的二进制,还蕴含了 runc(containerd 运行所依赖的底层容器运行时)以及相干命令的二进制(比方 ctr),如果作为 K8s 的容器运行时,倡议间接抉择第二种压缩包。压缩包地址都在arm ci 记录。目前我的树莓派上,因为装置部署了依赖 containerd 的 K3s,间接的部署了 arm 架构的 containerd 。 下载之后解压缩、配置环境变量,就能够应用cri命令查看 containerd 的版本了 $ export PATH=$PATH:/usr/local/bin:/usr/local/sbin$ ctr versionClient: Version: 1.3.7 Revision: 8fba4e9a7d01810a393d5d25a3621dc101981175Server: Version: 1.3.7 Revision: 8fba4e9a7d01810a393d5d25a3621dc101981175 UUID: c05a8353-d52c-44cd-88fe-af5b58f32b5b配置相干containerd 的配置文件默认在/etc/containerd/config.toml,也能够应用命令 containerd config default > /etc/containerd/config.toml 生成一个默认的配置文件。最简略配置文件如下: subreaper = trueoom_score = -999[debug] level = "debug"[metrics] address = "127.0.0.1:1338"[plugins.linux] runtime = "runc" shim_debug = true启动 containerdlinux 零碎中能够间接应用 systemd 启动守护过程,systemd 配置文件也在压缩包中: ...

May 20, 2021 · 2 min · jiezi

关于云原生-cloud-native:面对不可避免的故障我们造了一个上帝视角的控制台

简介: 混沌工程随着云原生的倒退逐步进入大家的视线,通过混沌工程能够很好地发现和解决在云原生化过程中的高可用问题。阿里巴巴在 2019 年开源了底层的混沌工程工具 - chaosblade,今年年初再次开源混沌工程控制台 chaosblade-box,ChaosBlade 品牌进一步降级。本文次要围绕云原生面临的高可用挑战和混沌工程时机,具体介绍开源控制台的设计、个性和实际和将来布局,旨在帮忙企业更好的理解控制台并通过其来实现混沌工程落地,解决云原生零碎下高可用问题。 作者 | 肖长军(穹谷)起源 | 阿里巴巴云原生公众号 混沌工程随着云原生的倒退逐步进入大家的视线,通过混沌工程能够很好地发现和解决在云原生化过程中的高可用问题。阿里巴巴在 2019 年开源了底层的混沌工程工具 - chaosblade,今年年初再次开源混沌工程控制台 chaosblade-box,ChaosBlade 品牌进一步降级。本文次要围绕云原生面临的高可用挑战和混沌工程时机,具体介绍开源控制台的设计、个性和实际和将来布局,旨在帮忙企业更好的理解控制台并通过其来实现混沌工程落地,解决云原生零碎下高可用问题。 去年年底 AWS 和 Google 都呈现了比较严重的服务故障:AWS 故障是因为解决数据流服务 kinesis 呈现问题,导致很多云服务不可用;Google 故障是因为登录服务的扩容配额问题导致多服务不可用。从中能够发现,他们都存在因服务依赖不合理,导致一个服务故障影响多个服务不可用,短少应急预案,整个故障复原工夫比拟长,监控告警零碎不欠缺等问题,Google 故障产生几十分钟后才感知故障的产生,AWS 的 CloudWatch 处于不可用的状态。故障不可避免,所有的所有时时刻刻存在着失败的危险。 尤其随着麻利开发、DevOps、微服务、云原生架构和治理的呈现,利用的交付能力大大晋升,但零碎的复杂度也日益减少,在业务疾速迭代的同时,如何保障业务继续的高可用性和稳定性面临着很大的挑战。混沌工程通过被动注入故障的形式,提前发现零碎的薄弱点,推动架构的改良,最终实现业务韧性。 打不倒我的必使我弱小,建设韧性架构是混沌工程的指标。韧性架构蕴含两局部,一部分是韧性零碎,比方具备冗余性、扩展性、降级熔断、故障隔离等,防止级联故障,构建容灾容错的韧性零碎。另一部分是韧性组织,蕴含高效交付、故障预案、应急响应等组织协同建设。高度韧性的零碎也会呈现预期之外的故障,所以韧性的组织能补救韧性零碎缺失的局部,通过混沌工程构建极致的韧性架构。 常见的云原生高可用架构架构基本上是基于多可用区,或者是跨地区级的容灾架构,业务利用采纳微服务架构下集群部署,中间件具备容错容灾能力等等。从底层设施到下层业务,都存在潜在的故障危险,比方机房断网、整个可用区不可用、集群宕机、中间件节点 crash 等。从可用区到集群、主机,再到细粒度的申请,故障影响的爆炸半径逐步减小,这也是混沌工程准则中十分重要的一点 -- 管制爆炸半径。管制爆炸半径的形式个别有两种:一是环境隔离,通过隔离试验的机房、集群等来管制影响面;二是基于试验工具或平台本身的场景控制能力,比方 chaosblade 试验工具,通过试验参数来管制试验粒度,比方微服务调用提早,能够管制到单个服务接口、版本,甚至一次申请。上面咱们来介绍一下 chaosblade 混沌试验工具。 Chaosblade 是一款遵循混沌试验模型的混沌试验执行工具,具备场景丰盛度高、简略易用等特点,而且扩大场景也特地不便,开源不久便被退出到 CNCF Landspace 中,成为支流的一款混沌工具。chaosblade 是个间接下载解压即可应用的工具,不须要装置,它反对的调用形式蕴含 CLI 形式,间接执行 blade 命令,这里举个做网络屏蔽的例子:咱们增加 -h 参数就能够看到十分欠缺的命令提醒,比方要一个 9520 端口调用做网络丢包,它的演练指标是 network;它的 action 是丢包;它的 matcher 就是调用近程的一个服务端口 9520。执行胜利后会返回试验后果,每一个试验场景咱们都会作为一个对象,它会返回一个试验对象的 UID,此 UID 用于后续的试验治理,比方销毁、查问试验都是通过此 UID 来做的。要销毁试验,也就是复原试验,间接执行 blade destroy 命令就能够。 ...

March 29, 2021 · 2 min · jiezi

关于云原生-cloud-native:关于云原生

Pivotal 是云原生利用的提出者,并推出了 Pivotal Cloud Foundry 云原生利用平台和 Spring 开源 Java 开发框架,成为云原生利用架构中先驱者和探路者。 Pivotal最后的定义早在2015年Pivotal公司的Matt Stine写了一本叫做迁徙到云原生利用架构的小册子,其中探讨了云原生利用架构的几个次要特色: 合乎12因素利用面向微服务架构自服务麻利架构基于API的合作抗脆弱性我已于2017年翻译了本书,详见迁徙到云原生利用架构。 CNCF最后的定义到了2015年Google主导成立了云原生计算基金会(CNCF),起初CNCF对云原生(Cloud Native)的定义蕴含以下三个方面: 利用容器化面向微服务架构利用反对容器的编排调度重定义到了2018年,随着近几年来云原生生态的一直壮大,所有支流云计算供应商都退出了该基金会,且从Cloud Native Landscape中能够看出云原生无意鲸吞原先非云原生利用的局部。CNCF基金会中的会员以及包容的我的项目越来越多,该定义曾经限度了云原生生态的倒退,CNCF为云原生进行了从新定位。 以下是CNCF对云原生的从新定义(中英对照): Cloud native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach.云原生技术有利于各组织在私有云、公有云和混合云等新型动静环境中,构建和运行可弹性扩大的利用。云原生的代表技术包含容器、服务网格、微服务、不可变基础设施和申明式API。 These techniques enable loosely coupled systems that are resilient, manageable, and observable. Combined with robust automation, they allow engineers to make high-impact changes frequently and predictably with minimal toil.这些技术可能构建容错性好、易于治理和便于察看的松耦合零碎。联合牢靠的自动化伎俩,云原生技术使工程师可能轻松地对系统作出频繁和可预测的重大变更。 ...

February 19, 2021 · 1 min · jiezi

关于云原生-cloud-native:解读容器的2020寻找云原生的下一站

2020 年注定是不凡的。它在阴郁中开始,在惊叹中完结,也让将来变得更加错综复杂。那么,容器与云原生的 2020 年呢?你是否记得它是怎么开始的?它又将走向何方? Kubernetes:企业基础设施的规范形象在 2020 年,没有人再会去质疑一个平台团队驳回 Kubernetes 作为本人的基础设施的合理性。事实上,2020 年的 Kubernetes 我的项目曾经十分靠近于地实现了它最重要的使命,即:为云计算基础设施带来一层能够让平台团队基于此结构“所有”的平台层形象。 咱们曾经可能看到,明天的云原生社区曾经开始宽泛认可 Kubernetes 我的项目作为“The platform for platform”的定位与价值,越来越多的平台团队正在基于 Kubernetes 构建各种各样的下层平台,比方 PaaS / Serverless / AI Platform  / Database PaaS 等等。面向终态的申明式 API 与其背地“辛勤”工作的控制器,为“构建基础设施层形象”这个充斥了挑战的技术难题,提供了一个可能在复杂度与可用性之间获得均衡的解决方案。正是基于此,Kubernetes 我的项目才领有了宏大的集成生态,让这个“企业基础设施的规范形象”,逐渐成为了业界公认的事实。 而更为重要的是,Kubernetes 真正的胜利之处,在于它真正押注的是构建形象的办法而非这些形象自身。在绝大多数状况下,企业基于 Kubernetes 构建下层平台,都会引入各种各样其余的形象作为补充,甚至取代或者暗藏掉 Kubernetes 的局部内置形象:阿里巴巴开源CloneSet、腾讯的 GameStatefulSet实际等扩大型工作负载等都是这个趋势的最好的案例。 随同着 Kubernetes 生态从底层到应用层能力的逐步完善,在 2020 年,更多大型互联网终端企业开始退出到了云原生的梯队当中。咱们看到本来的 Mesos 生态标杆 Apple 公司成为了 KubeCon 2020 北美上的相对配角,而金融巨头 MasterCard 则分享了他们基于 OAM、Kubernetes 和 Crossplane 我的项目构建跨云、跨运行时利用交付平台的外部落地案例。而尤为值得一提的是,这些以往在底层根底技术上给人以”激进“印象的大型非云企业,在 2020 年纷纷祭出了对很多新兴技术比方 Virtual Cluster和规范利用模型技术上的落地与思考。云原生浪潮对整个技术产业带来的深远影响可见一斑。 此外,咱们也不难察看到,Kubernetes 的极大遍及以及基于它衰亡的下层生态,正在跟安卓(Android)的倒退门路越来越显著的趋同。安卓可能对下以一套对立的形式形象与集成不同的手机、电视、甚至汽车等硬件设施,对上则为程序员暴露出对立的一套开发接口,使他们可能以这套对立的形象去拜访或者享受到这些基础设施能力。这种定位与 Kubernetes 十分相似,这里惟一的区别在于,安卓服务的程序员是 APP 开发者,而 Kubernetes 服务的“程序员”,则是平台构建者。在这个背景下,诸如“Kubernetes 摈弃 Docker”之类的新闻会很容易了解:安卓自身就不须要专一于手机的电池是哪个牌子的。 ...

January 24, 2021 · 2 min · jiezi

关于云原生-cloud-native:VoltDB成功入选CNCF-Landscape云原生数据库全景图

近日,VoltDB正式入选 CNCF Landscape(可能是目前其中惟一的关系型分布式内存数据库)。此次VoltDB 进入 CNCF Landscape,意味着 VoltDB 正式成为了 CNCF 认可的构建云原生最佳实际中的一环。 云原生计算基金会(CNCF ,Cloud Native Computing Foundation)致力于云原生技术的遍及和可继续倒退。CNCF Landscape 是 CNCF 中的一个重要我的项目,在每年的 CNCF 年度报告中都会被提及。它用意从云原生的层次结构,以及不同的性能组成上,让用户理解云原生体系的全貌,并帮忙用户在不同组件档次去抉择失当的软件和工具进行反对(https://landscape.cncf.io/),受到了宽广开发者和使用者对该项目标关注和器重。 云原生分布式内存数据库能够提供更好的弹性和伸缩性能,简化甚至齐全自动化运维,更好适应和反对业务变动及扩张,并降低成本。 VOLTDB是由2014年图灵奖得主、PostgreSQL和Vertica等产品的创始人Michael Stonebraker博士领导开发的下一代关系型、内存数据库管理系统,面向毫秒级实时事务处理、实时数据分析、边 缘计算和简单流解决计算等利用。 可在 x86 服务器集群或虚拟环境上实现每秒数百万次数据处理,提供开源和商业版本。VoltDB特点如下: 如果您对VoltDB的工业物联网大数据低提早计划、全生命周期的实时数据平台治理等感兴趣,欢送私信,进入到咱们的官网交换群。

January 7, 2021 · 1 min · jiezi

关于云原生-cloud-native:云原生20时代华为云DevOps立体运维实践

摘要:随着云原生2.0时代的降临,越来越多的企业及集体抉择应用云原生技术来构建业务,云原生技术给业务构建、交付带了便当的同时,对运维也提出了更高的要求。2020年12月,中国DevOps社区峰会在北京举办。DevOps大咖齐聚一堂,其中华为私有云利用运维域产品经理闫硕受邀分享《华为云DevOps平面运维实际》。 华为云作为云原生技术的先行者与遍及者,始终致力于云原生产业的推动与倒退。在华为云提出的云原生2.0全景图中,利用麻利助力企业以利用为核心,上云更高效,翻新更麻利。其中,高效运维则是重要保障。 随着云原生2.0时代的降临,越来越多的企业及集体抉择应用云原生技术来构建业务,云原生技术给业务构建、交付带了便当的同时,对运维也提出了更高的要求。 传统运维到云原生2.0场景运维有诸多区别,传统运维在根底资源方面工作量较大,须要自行构建运维零碎,同时又难以进行基础设施维度的弹性扩容。而在云原生2.0场景下,根底资源运维大多由云厂商提供,所以用户能够有更多的精力来关注业务自身的运维,与此同时云厂商会提供更加通用、普适的运维产品,升高用户的运维工具构建老本。相比与传统运维,云原生2.0场景下的运维更加的弹性、麻利,能够针对虚机资源、利用进行弹性扩缩容,以此来应答业务的顶峰与低谷。 那么在云原生2.0场景下运维要求又有哪些?首先,须要有一套高效的运维流程,依靠规范的运维标准来实现日常的各种运维动作;其次运维工具也是必不可少的,须要有一套以利用为核心,并且可能具备可视化展现各种维度监控指标的监控平台;日志性能也是运维过程中必不可少的工具,通过日志收集、存储、剖析等过程,展现各种日志文件剖析后的数据,作为日常运维的重要依据;最初,链路拓扑也是自动化运维的重要性能点,因为利用上司的实例个数泛滥,须要可视化展现每个微服务实例之间的调用关系,呈现问题时,下钻到微服务外部进行办法级别的故障诊断。 华为云平面运维解决方案是为云上客户量身定制的一个解决方案,蕴含AOM(利用运维治理服务)、APM(利用性能治理服务)、LTS(日志服务)。笼罩IaaS层的基础设施状态,Paas层的中间件及数据库状态,应用层的各类利用状态及指标这三层,造成立体化运维剖析能力。华为云立体化运维解决方案遵循DevOps规范,能够麻利高效的获取云上利用的各类异样,并辅助运维人员疾速定位。同时立体化运维解决方案以利用为核心,展现利用指标、拓扑、状态信息,提供利用视角的监控运维模式,满足日常巡检、故障排查等多种运维场景。 华为云平面运维解决方案具备以下特点:** ** 1 对立运维监控治理:资源、利用、业务一站式监控与剖析 反对集群、虚机、网络、磁盘、数据库、利用、容器及业务等上百种监控指标与秒级监控,通过集群与虚机、虚机与利用、利用与资源对立建模,对各种指标智能关联剖析,用户通过对立的告警入口和下钻找到问题根因。 2 日志剖析:分布式日志集中搜寻与实时查看 将虚机上的利用、开源组件、零碎等日志集中采集到数据库,用户通过日志治理疾速找到利用实例日志,提供实时刷新、日志上下文查看、秒级搜寻、日志下载等罕用性能。 3 利用拓扑剖析:利用关系与异样高深莫测、故障下钻 对利用衰弱状态可视化治理,包含利用运行状态、时延、谬误、负载、依赖关系,包含数据库、缓存、消息中间件、NOSQL等各类开源组件。 华为云平面运维解决方案致力于打造全方位的云上整体运维计划,将云原生2.0运维的优良实际以云服务的形式提供给内部客户,帮忙客户应答云原生2.0场景下的各种运维难题。全面笼罩基础设施层、应用层、数据库或中间件等多维度监控指标,用户无需自建各种简单的运维零碎,也可即刻应用开箱即用的运维性能。 点击即刻体验平面运维 https://www.huaweicloud.com/product/aom.html 本文分享自华为云社区《云原生2.0时代,华为云DevOps平面运维实际》,原文作者:灰灰哒 。点击关注,第一工夫理解华为云陈腐技术~

January 5, 2021 · 1 min · jiezi

关于云原生-cloud-native:青云QingCloud-携手英特尔-打造基于-KubeSphere-的精选开源云解决方案

12 月 14 日,青云QingCloud 联结英特尔发表,单方携手打造的基于 KubeSphere 容器平台的精选开源云解决方案正式公布。该解决方案深度交融 KubeSphere 在容器云畛域的技术劣势与英特尔在硬件畛域的综合实力,通过搭载 KubeSphere 操作系统,和针对特定容器云利用负载的硬件配置倡议,帮忙企业疾速搭建麻利、满足不同负载要求的容器云平台,一步落地云原生,减速实现数字化转型。此前,青云QingCloud 旗下青立方超交融曾经入选英特尔中国区首批精选解决方案。 青云QingCloud 副总裁林源示意:“英特尔是青云QingCloud 长期稳固的策略合作伙伴,单方携手打造精选开源云解决方案,可能更好地帮忙企业实现云原生的转型与翻新,跨基础设施地疾速构建、部署及运维容器架构,DevOps 即点即用,微服务治理性能继续欠缺,一步跨入云原生利用时代。” 当下,企业正面临数字化转型的阵痛,越来越多的企业心愿部署混合云,但传统的 Kubernetes 架构在混合云异构环境中面对“集群对立治理、疾速跨集群部署、自在扩大、低成本运维”等需要越来越力不从心。如何帮忙企业解决混合云容器化的实际困难,疾速开发、交付云原生利用,成为考验云服务与解决方案提供商的新课题。 为帮忙企业疾速构建面向云原生利用的容器混合云,青云 QingCloud 自主研发了以 Kubernetes 为内核的云原生分布式操作系统 KubeSphere,作为分布式、多租户、多集群治理的企业级开源容器平台。KubeSphere 以“开箱即用”为设计初衷,架构能够便捷地使第三方利用与云原生生态组件进行即插即用的集成,反对云原生利用在多云与多集群的对立散发和运维治理,并提供即点即用的 DevOps 性能,领有灵便可选的微服务框架,提供运维敌对的向导式操作界面,具备全栈 IT 自动化运维能力等,极大地简化了云原生利用开发、交付复杂程度,帮忙企业一步跨入云原生。同时,KubeSphere 还可提供商业验证的 SDN 与 SDS 能力,在与青云QingCloud 全栈云平台交融之后,帮忙企业搭建强壮的容器基础设施。 基于此,KubeSphere 可广泛应用在“利用多区高可用”、“迅速部署容器架构,轻松治理与运维” 、“多维管控 Kubernetes,升高运维复杂度”、“麻利开发与自动化运维,助力企业 DevOps”等场景。而为了便于企业用户及开发者下载应用,KubeSphere 保持 100% 开源准则,通过开源社区与寰球用户、开发者沟通交流,目前在 GitHub 上 Stars 达到 4200 多个,Forks 达到 640 个,开源社区用户形成来自 90 多个国家和地区。其中,KubeSphere 已取得绿米 Aqara、原本生存、微众银行、新浪、遥望网络、津燃华润等企业用户的广泛应用。 此次青云QingCloud 与英特尔基于优势互补、强强联合的初衷,携手推出以 KubeSphere 为软件外围,集成英特尔硬件产品的精选开源云解决方案,通过针对容器云工作负载进行性能验证和优化,实现软硬件更佳交融,可能高效地利用计算、存储、网络等资源,充分发挥 KubeSphere 和英特尔在云原生场景的技术、性能后劲,使云基础设施以更强的弹性伸缩能力撑持下层业务,实现云原生利用的疾速开发和交付。该解决方案还具备杰出的总体领有老本(TCO),能够帮忙行业用户显著升高后期的选型和测试老本。 KubeSphere 容器平台和英特尔,都经验了市场的重复磨炼和实际利用考验,深受行业用户信赖。随着基于 KubeSphere 容器平台的精选开源云解决方案推出,企业能够升高容器云部署以及集群运维治理的门槛,实现容器场景下的云原生疾速落地,为零碎演进提供最易用的工具型解决方案,放慢数字化转型过程。 ...

December 30, 2020 · 1 min · jiezi

关于云原生-cloud-native:ArgoCD-KubeVela以开发者为中心的GitOps

10人将获赠CNCF士多$100礼券!来参加2020年CNCF中国云原生考察 问卷链接(https://www.wjx.cn/jq/9714648...) 客座文章作者:Deng Hongchao,阿里巴巴软件工程师 介绍 Argo CD是为Kubernetes提供的GitOps继续交付工具。它是CNCF Argo我的项目的一部分,该我的项目是一组Kubernetes原生工具,用于在Kubernetes上运行和治理作业和应用程序。 KubeVela是一个基于Kubernetes和OAM(凋谢应用程序模型,Open Application Model)的开源应用程序引擎。KubeVela次要是为平台和经营团队设计的,以便在Kubernetes上轻松创立简略但面向开发人员的高度可扩大的形象。对开发人员(也就是最终用户)暗藏了在Kubernetes上配置利用程序清单的很多复杂性,比方伸缩策略、部署策略和入口,但容许平台团队基于组织策略独立定制和管制这些配置。 在这篇博文中,咱们将分享基于阿里云的用例,应用Argo CD和KubeVela构建以开发者为核心的继续利用交付流水线的教训。 以开发者为核心的GitOps体验 现实状况下,开发人员心愿专一于编写应用程序并将其代码推送到git仓库上,而不用放心CI/CD流水线以及配置和运行应用程序时的其余操作问题。Kubernetes上一个十分风行的模式是将应用程序从git主动部署到生产环境中。这就是Argo CD的用武之地。它会继续监督git仓库的新提交,并主动将它们部署到生产环境中。Argo CD利用仓库中预约义的Kubernetes部署清单文件来创立或降级在Kubernetes上运行的应用程序。这种模式被称为GitOps,是在阿里巴巴的古代云原生堆栈中实现继续主动利用交付的要害。 尽管概念上很简略,但在将GitOps利用到更宽泛的最终用户场景时,会呈现几个重要的问题。第一个问题是,理论的生产应用程序是简单的,须要开发人员了解如何配置许多不同类型的Kubernetes资源。第二个问题(与第一个问题相干)是,对于每个开发人员来说,学习如何正确配置和保护所有这些对象,同时恪守组织平安、听从性和操作策略变得十分具备挑战性。即便是简略的谬误配置也可能导致部署失败,甚至服务不可用。第三个问题是,当Kubernetes标准或组织策略发生变化时,必须更新所有利用程序清单以反映这些变动。对于一个可能领有数千个应用程序和数百万行Kubernetes清单文件的YAML的组织来说,这是一项微小的工作。这些问题产生了对应用程序形象的强烈需要,该形象将开发人员与不会间接影响其应用程序的平台和操作关注点隔离开来,并提供了一个锚来防止配置漂移。Kubernetes的外围形象,通过无意的设计,并没有为形象应用程序提供一个规范的机制。 思考到这个指标,KubeVela被创立和设计为一个最小的、可扩大的应用程序引擎,供平台构建人员在Kubernetes上创立“相似PaaS”的体验。具体来说,KubeVela提供了简略而无效的形象,将应用程序配置问题与平台和操作问题拆散开来。上面是一个名为appfile的工件示例: 通过应用appfile并将其与Argo CD一起部署,开发人员只须要编写一个简略的利用配置,并将代码推送到git。而后,他们的应用程序将被主动部署,并开始在指标Kubernetes集群上解决实时流量。在幕后,平台和经营团队有能力用CUElang模板事后定义和/或批改这些形象的行为,并确保它们满足组织的安全性、听从性和其余经营需要。 在上面,咱们将更具体地解释上述GitOps工作流是如何工作的。 KubeVela搭配Argo CD 先决条件 对于平台运营者来说,惟一的“技巧”是使KubeVela成为Argo CD的自定义插件,这样它就能“了解”appfile格局。 注册插件 Argo CD容许通过编辑argocd-cm ConfigMap集成额定的配置管理插件,如Kubevela。 将以下文件保留为argo-cm.yaml: data: configManagementPlugins: | - name: vela init: command: ["sh", "-xc"] args: ["vela traits"] generate: command: ["sh", "-xc"] args: ["vela export"]而后执行以下命令更新argocd-cm ConfigMap: kubectl -n argocd patch cm/argocd-cm -p "$(cat argo-cm.yaml)"配置argo-repo-server Argo CD有一个名为argo-repo-server的组件,它从Git中提取部署清单文件并出现最终输入。在这里,咱们将应用vela cli解析appfile并将其出现到Kubernetes资源中。 ...

December 29, 2020 · 2 min · jiezi

关于云原生-cloud-native:SeataAT-如何保证分布式事务一致性

作者 | 陈健斌(funkye) github id: a364176773起源|阿里巴巴云原生公众号 Seata 是一款开源的分布式事务解决方案,star 高达 18100+,社区活跃度极高,致力于在微服务架构下提供高性能和简略易用的分布式事务服务,本文将分析 Seata-AT 的实现原理,让用户对 AT 模式有更深刻的意识。 Seata 事务模式是什么?1. Seata 对事务的定义Seata 定义了全局事务的框架。 全局事务定义为若干分支事务的整体协调: TM 向 TC 申请发动(Begin)、提交(Commit)、回滚(Rollback)全局事务。TM 把代表全局事务的 XID 绑定到分支事务上。RM 向 TC 注册,把分支事务关联到 XID 代表的全局事务中。RM 把分支事务的执行后果上报给 TC。(可选)TC 发送分支提交(Branch Commit)或分支回滚(Branch Rollback)命令给 RM。 Seata 的全局事务处理过程,分为两个阶段:执行阶段>  :执行分支事务,并保障执行后果满足是可回滚的(Rollbackable)和长久化的(Durable)。实现阶段> :依据执行阶段后果造成的决定,利用通过 TM 收回的全局提交或回滚的申请给 TC,> TC 命令 RM 驱动 分支事务 进行 Commit 或 Rollback。 Seata 的所谓事务模式是指:运行在 Seata 全局事务框架下的分支事务的行为模式。> > 精确地讲> ,应该叫作> 分支事务模式> 。 不同的事务模式区别在于分支事务应用不同的形式达到全局事务两个阶段的指标。> > 即,答复以下两个问题: 执行阶段>  :如何执行并保障执行后果满足是可回滚的(Rollbackable)和长久化的(Durable)。实现阶段> :收到 TC 的命令后,做到事务的回滚/提交。 ...

December 28, 2020 · 3 min · jiezi

关于云原生-cloud-native:Dubbo-30-前瞻系列服务发现支持百万集群带来可伸缩微服务架构

作者 | 刘军(陆龟)起源|阿里巴巴云原生公众号 本文是一篇对于 Dubbo 地址推送性能的压测文章,咱们冀望通过比照的形式展示 Dubbo3 在性能方面的晋升,尤其是新引入的利用级地址模型。但要留神,这并不是官网正式版本的性能参考基线,并且因为环境和工夫起因,局部比照数据咱们并没有采集,但只有记住咱们只是在定性的检测阶段成绩,这些限度总体上并不会有太大影响。摘要本文次要围绕下一代微服务框架 Dubbo 3.0 在地址推送链路的性能测试开展,也是在性能层面对 Dubbo 3.0 在阿里落地过程中的一个阶段性总结,本轮测试了 Dubbo2 接口级地址发现、Dubbo3 接口级地址发现、Dubbo3 利用级地址发现。压测数据表明,在百万实例地址的压测场景下: 基于接口级地址发现模型,Dubbo3 与 Dubbo2 比照,有超过 50% 常驻内存降落,Full GC 距离更是显著拉长。Dubbo3 新引入的利用级服务发现模型,能够进一步实现在资源占用方面的大幅降落,常驻内存比 Dubbo3 接口级地址进一步降落 40%,利用实例扩缩容场景增量内存调配根本为零,雷同周期内(1 小时) Full GC 缩小为 2 次。Dubbo 3.0 作为将来撑持业务零碎的外围中间件,其本身对资源占用率以及稳定性的晋升对业务零碎毫无疑问将带来很大的帮忙。 背景介绍1. 下一代服务框架 Dubbo 3.0 简介一句话概括 Dubbo 3.0:它是 HSF & 开源 Dubbo 后的交融产品,在兼容两款框架的根底上做了全面的云原生架构降级,它将成为将来面向阿里外部与开源社区的主推产品。 Dubbo 3.0 诞生的大背景是阿里巴巴在推动的全站业务上云,这为咱们中间件产品全面拥抱云上业务,提供外部、开源统一的产品提出了要求也提供了契机,让中间件产品无望彻底解脱自研体系、开源体系多线作战的场面,有利于实现价值最大化的场面。一方面阿里电商零碎大规模实际的教训能够输入到社区,另一方面社区优良的开发者也能参加到我的项目奉献中。以服务框架为例,HSF 和 Dubbo 都是十分胜利的产品:HSF 在外部撑持历届双十一,性能优异且久经考验;而在开源侧,Dubbo 坐稳国内第一开源服务框架宝座,用户群体十分宽泛。 同时保护两款高度同质化的产品,对研发效率、业务老本、产品质量与稳定性都是十分大的考验。举例来说,首先,Dubbo 与 HSF 体系的互通是一个十分大的阻碍,在阿里外部的一些生态公司如考拉、饿了么等都在应用 Dubbo 技术栈的状况下,要实现顺利平滑的与 HSF 的互调互通始终以来都是一个十分大的阻碍;其次,产品不兼容导致社区输入老本过高、品质验收等老本也随之增长,外部业务积攒的服务化教训与成绩无奈间接赋能社区,二次革新适配 Dubbo 后功能性、稳定性验收都要从新投入验证。为彻底解决以上问题,联合上文提到的阿里团体业务整体上云、开源以及云产品输入策略,咱们制订了全面倒退 Dubbo 3.0 的打算。 ...

December 28, 2020 · 1 min · jiezi

关于云原生-cloud-native:阿里云开源项目-OAM-负责人张磊入选中国开源先锋-33-人

起源|阿里巴巴云原生公众号 2020 年 12 月 23 日,由 SegmentFault 思否发动的第二届“中国技术先锋”年度评比后果揭晓,CNCF 利用交付畛域小组 Co-chair、阿里云高级技术专家、OAM 开源我的项目负责人张磊入选 2020“中国开源先锋 33 人”年度榜单。 近两年,开源始终是技术圈十分炽热的话题。本次评比后果是 SegmentFault 思否依靠数百万开发者用户数据分析,以及各科技企业和集体在国内技术畛域的行为、影响力指标产生, 旨在让那些助推中国开源生态倒退路线上要害的“幕后英雄“走入大家的视线,从而带动中国外乡开源文化的凋敝。 Kubernetes 老兵与首个云原生“凋谢利用模型”在开源技术的反对和推动下,近年来云原生的理念不断丰富和落地,并迅速构建起以容器技术、容器编排技术为外围的生态,有数据显示,Kubernetes 已成为被企业选用最多的容器编排技术。 张磊能够说是 Kubernetes 畛域最晚期的玩家,从 2014 年就开始进入 Kubernetes 上游从事技术工作,2015 年即成为 Kubernetes 社区最早的一批  Maintainer 之一,并于 2016 年即被推选为 CNCF 官网大使。在 Kubernetes 社区中,张磊是 Kubernetes 容器运行时接口(CRI)和 KataContainers 运行时的晚期设计者和维护者之一,也是 Kubernetes 等价类调度、拓扑资源管理等多个大颗粒外围个性的次要作者。 2018 年后退出阿里巴巴,张磊主导提出了基于 Kubernetes 的“云原生利用交付体系”,同年以最高票当选 CNCF 利用交付畛域小组 co-chair,是目前 CNCF 七大畛域小组中惟一一位华人 co-chair,主导小组将 Argo 等多个出名利用治理畛域开源我的项目纳入 CNCF 孵化器当中,同时被举荐为 Argo 开源社区 TOC。 2019 年末,张磊团队主导阿里云联结微软 CTO Office 团队独特提出了“凋谢利用模型”开源我的项目 OAM (Open Application Model),这是业界第一个云原生利用交付与治理畛域的规范模型与框架。 ...

December 28, 2020 · 1 min · jiezi

关于云原生-cloud-native:引领云原生发展浪潮-阿里云开启云原生大规模落地元年

点击观看《原生 · 新生》视频 12 月 23 日,由阿里云主办的 “2020 云原生实战峰会” 隆重揭幕,此次峰会以“原生减速·数创降级”为主题,峰会主论坛上德勤中国合伙人刘俊龙、阿里云云原生利用平台负责人丁宇等人别离发表演讲,深剖云原生大规模落地现状,探讨企业级云原生如何助力企业数据上云,以及云原生数据智能与 AI 如何助力企业实时决策;并面向全行业成立云原生实战联盟,推动全行业的云原生实际过程。 峰会分设教育实战专场、互动娱乐实战专场、企业 CIO 大咖面对面、互联网 CTO 研发效力三板斧等论坛,围绕“企业云原生落地实战”这一外围主题,竟然之家、T3 出行、玩物失意、好将来、江娱互动、玩吧、兴为教育、学霸君、VIPKID 为代表的十余家数字翻新先锋企业,与现场 300 余位技术管理者分享本身业务的云原生架构设计与技术建设的丰盛教训,独特探讨云原生在不同行业的最佳落地办法。 阿里云云原生利用平台负责人丁宇 新冠疫情期间,云计算向市场证实了本身价值,如何充沛开掘云红利成为企业抢滩数字翻新的事不宜迟。丁宇示意,“云原生是开释云计算红利的最短门路,减速企业数字化翻新降级。当企业面对业务变动、迭代、翻新以及平安挑战时,云原生是实现资源高效极致弹性、利用麻利交付、业务智能化、外围业务平安保障的最佳路径。”会上,阿里云联结行业先锋企业广州趣丸、学霸君、玩物失意,以及云原生产业头部企业杭州谐云、博睿宏远、易联通达、德勤和用友政务,独特发表成立云原生实战联盟,致力于打造云原生落地最佳实际标杆,推动云原生在全行业的落地普惠。 实战联盟成立云原生实战联盟正式成立 与此同时,云原生实战联盟将在后续开展理论落地流动,真正践行技术普惠。其中包含:成立 CTO 数创先锋营,面向全国 100+ 互联网 CTO,在行业洞察、技术策略及组织治理等方面深度交换,打造高质量的技术管理者顾问团;成立互联网技术实战营,基于业务场景,面向技术人打造场景化的技术实战空间。其中,CTO 数创先锋营在此次峰会上发展了“研发效力三板斧”的课程,阿里云云效 DevOps 平台高级解决方案架构师张裕,提出了云原生 DevOps 降级五步曲。现场案例与办法解说联合,帮忙企业从手工不确定交付运维、工具辅助窗口制交付运维、管控的继续交付和自动化运维、继续交付和人工辅助智能,走向全链路继续交付和自运维的云原生门路,最终落地实际云原生 DevOps,助力企业实现 10 倍效力晋升。 阿里云数据库产品事业部总经理占超群 面对数据量井喷、实时化、业务交融多样化等挑战,云计算时代的数据库须要进行交融翻新和改革,企业须要更加智能化、一体化、麻利化的数据库平台。阿里云数据库产品事业部总经理占超群示意,“阿里云企业级数据库系统全面云原生化,减速数据处理向分布式、数据库与大数据一体化、在离线一体化演进,一站式解决数据生产、存储、剖析、生产的全链路用户需要。利用云原生数据库技术和产品体系,助力业务进行数智化翻新更实时在线、更全局、更简略、更麻利。例如:中国邮政引入云原生分布式数据库 PolarDB-X 和云原生数据仓库 AnalyticDB,实现全国业务大集中,在订单业务峰值超过 1 亿件的状况下,零碎平滑稳固运行。” 阿里云通用计算平台负责人关涛 为应答更加复杂多变的业务环境,企业须要更加高效智能的实时决策能力。阿里云通用计算平台负责人关涛示意,“基于极致弹性、扩展性、存储拆散、免运维、容灾的云原生架构,企业级数据智能与 AI 进一步具备了智能剖析与决策的能力,例如基于实时计算 Flink 和 SaaS 模式云数据仓库 MaxCompute,天猫 双11 业务决策从 ‘3 小时’ 降级为实时,流量匹配效率晋升 300%。” 洞悉云原生在行业的落地现状、挑战与实际,是致力于数字翻新企业的必修课。会上,围绕“企业级云原生数据库系统助力数据上云”的主题,T3 出行技术核心副总经理汤义强、竟然之家 IT 负责人薄青松、阿里云数据库产品事业部总经理占超群缺席圆桌会议,独特探讨“阿里云原生数据库如何让竟然之家、T3 出行的业务更快、更稳、更平安?”围绕“云原生数据智能与 AI 助力企业实时决策”的主题,玩物失意 CTO 张淼、好将来 AI 中台算法科学家杨非、江娱互动数据分析经理董文强、阿里云通用计算平台负责人关涛缺席圆桌会议,独特探讨“企业如何通过数据智能助力业务继续且衰弱的增长”。 ...

December 24, 2020 · 1 min · jiezi

关于云原生-cloud-native:都-2021-年了Serverless-能取代微服务吗

起源 | Serverless 公众号编译 | OrangeJ作者 | Mariliis Retter “Serverless 能取代微服务吗?” 这是知乎上 Serverless 分类的高热话题。 有人说微服务与 Serverless 是相背离的,尽管咱们能够基于 Serverless 后端来构建微服务,但在微服务和 Serverless 之间并不存在间接的门路。也有人说,因为 Serverless 内含的 Function 能够视为更小的、原子化的服务,人造地符合微服务的一些理念,所以 Serverless 与微服务是天作之合。马上就要 2021 年了,Serverless 是否终将取代微服务?从微服务到 Serverless 须要通过怎么的门路?本文将对 Serverless 与微服务在劣势劣势上进行深度比照。 从概念上讲,微服务完全符合 Serverless 性能构造,微服务能够轻松实现不同服务的部署和运行时隔离。在存储方面,像 DynamoDB 这样的服务能够让每个微服务领有独立的数据库,并独立地进行扩大。在咱们深入探讨细节之前,先别急着“站队”,无妨先基于你团队的理论状况,实在的去思考是否适宜应用微服务,千万不要因为 "这是趋势 "而去抉择它。 微服务在 Serverless 环境下的劣势可抉择的可扩展性和并发性Serverless 让治理并发性和可扩展性变得容易。在微服务架构中,咱们最大限度地利用了这一点。每一个微服务都能够依据本人的需要对并发性/可扩展性进行设置。从不同的角度来看这十分有价值:比方加重 DDoS 攻打可能性,升高云账单失控的财务危险,更好地分配资源......等等。 细粒度的资源分配因为可扩展性和并发性能够自主抉择,用户能够细粒度管制资源分配的优先级。在 Lambda functions 中,每个微服务都能够依据其需要,领有不同级别的内存调配。比方,面向客户的服务能够领有更高的内存调配,因为这将有助于放慢执行工夫;而对于提早不敏感的外部服务,就能够用优化的内存设置来进行部署。 这一个性同样实用于存储机制。比方 DynamoDB 或 Aurora Serverless 数据库就能够依据所服务的特定(微)服务的需要,领有不同级别的容量调配。 松耦合这是微服务的个别属性,并不是 Serverless 的独有属性,这个个性让零碎中不同性能的组件更容易解耦。 反对多运行环境Serverless 性能的配置、部署和执行的繁难性,为基于多个运行时的零碎提供了可能性。 尽管 Node.js (JavaScript 运行时)是后端 Web 利用最风行的技术之一,但它不可能成为每一项工作的最佳工具。对于数据密集型工作、预测剖析和任何类型的机器学习,你可能抉择 Python 作为编程语言;像 SageMaker 这样的专用平台更适宜大我的项目。 ...

December 23, 2020 · 1 min · jiezi

关于云原生-cloud-native:向我看齐京东智联云成-2020-TOP100-Summit技术标兵

12月17日-20日, 2020TOP100寰球软件案例钻研峰会(以下简称“TOP100峰会”)在京举办。在本届峰会上,京东智联云凭借深厚的技术积淀,多个我的项目取得业界认可,2020中国国内服务交易贸易会(2020服贸会)服务案例、云原生技术中台实际、DevOps实际入选2020年度最值得学习案例。 作为科技界颇具影响力的案例钻研峰会,TOP100峰会每年面向国内外软件、互联网畛域研发团队,甄选有学习价值的100个技术创新及研发治理实际。凭借在云计算、人工智能、大数据等畛域的技术实际和突出表现,京东智联云在这场“百家争鸣”的年初盘点中,三项案例均播种业界的认可,为新锐公司和晚期实际学习者奉上了可参考的学习门路。 2020服贸会,不仅是疫情产生以来第一场重大的国际经贸流动和国家级、国际性、综合型的展会。同时,也是一场线下线上充沛交融的数字孪生展会。会上,京东智联云会展云总经理庄珑鹏分享如何在短时间通过全链条的会展服务平台,推动传统会展行业的数字化转型和智能化降级。 京东智联云会展云总经理庄珑鹏 作为2020服贸会的技术服务商,京东智联云打造的“云上服贸会”数字平台,从0到1重构会展产业,为寰球1.8万家参展参会企业与机构提供全场景、全笼罩的数字化性能服务和技术保障。在“展”的方面,通过“立体+3D虚构单体展台”提供智能体验;在“论”的方面,通过视频直播、视频会议等形式,实现“云上”会议的多模式调配;在“洽”的方面,通过即时通讯、视频洽谈、在线翻译、智能客服等多种工具,搭建云端虚构洽谈间;全方位推动会展行业“从线下到线上,从繁多到交融”的数智化转型。 除了分享传统会展行业的数智化革新计划,会上,京东智联云研发总监王碧波分享了云原生畛域的“京东计划”。在Kubernetes之上以云原生规范形式构建一套残缺的技术中台能力,能够为下层业务提供跨云对立的运行底座,晋升业务施行混合云以及多云交付的效率,但这项工作的难点在于根底的数据库和中间件如何实现云原生革新。 京东智联云研发总监王碧波 据王碧波介绍,京东智联云的云原生技术中台,是对罕用数据库和中间件依照Kubernetes规范模式实现革新,并采纳operator模式晋升自动化运维能力。基于这些根底能力,京东智联云将各畛域的根底技术中台能力也实现了云原生革新,同时提供了自动化性能以便当下层业务应用技术中台组件,从而极大晋升各种根底能力的运维效率,升高了下层业务施行混合云的难度和对外赋能的交付难度。 现在很多公司都十分关注企业研发效力,也在破费很大的人力物力投入到麻利、DevOps、数字化转型之中。但研发效力度量应该怎么做?如何无效评估团队和交付能力及趋势?如何防止谬误的、有副作用的度量形式?这一系列问题仍旧不足标准规范的答案。 京东智联云DevOps与研发效力技术总监&首席架构师张乐,通过分享某家跨国企业大规模麻利转型和度量的案例,并比照业界支流公司的成功经验,总结出研发效力度量的七大准则。张乐示意,京东智联云在实践中总结出的研发效力度量体系,是一套被证实切实可行的、通过度量为抓手剖析软件交付价值流的产出和瓶颈,从而有针对性地促成企业研发效力晋升的体系化办法。 京东智联云DevOps与研发效力技术总监&首席架构师张乐 京东智联云依据业务场景建设适当的研发效力度量体系、建设高度灵便可配置的效力度量平台,定期通过数据洞察效力趋势、继续发现和解决瓶颈。半年内,在保证质量的前提下,京东智联云研发的DevOps均匀需要交付周期缩短超过30%。 TOP100峰会不仅是一场属于互联网人交换分享的盛会,更是流传国内外优良的新理念、新思路、新技术的重要平台。作为京东团体技术能力对外输入的外围通道,京东智联云所开展的技术之网,已笼罩供应链、物流、会展等各个行业,将来也将继续向业界开释独特的技术价值,携手生态搭档,独特拓展更多的未知边界。 举荐浏览: 知你所想,推你所愿 | 深度解读展会场景智能举荐搭建之路会展云技术解读 | 基于服务设计的线上展览会展云技术解读 | 多重平安保障护航云上会展欢送点击【京东智联云】,理解开发者社区 更多精彩技术实际与独家干货解析 欢送关注【京东智联云开发者】公众号

December 23, 2020 · 1 min · jiezi

关于云原生-cloud-native:邀请函丨-华为云-TechWave-云原生-20-技术峰会

冬天到了,春天还会远么? 跌宕起伏的 2020 终于迎来序幕是时候以新技术、新姿势进击 2021 云原生技术蓬勃发展从 1.0 到 2.0 时代云原生如何引领企业智能降级进入新阶段,赋能各行各业迎来万象更新?企业的新生能力又如何与既有能力立而不破、有机协同? 12月30日华为云 TechWave 云原生 2.0 技术峰会诚邀您光临现场

December 23, 2020 · 1 min · jiezi

关于云原生-cloud-native:云原生-DevOps-服务商-KodeRover-获千万元天使轮融资

SegmentFault 12 月 21 日音讯,云原生软件数字化交付SaaS服务商 KodeRover 取得盈动资本千万元天使轮融资。 据理解,KodeRover 本轮融资将次要用于旗舰交付产品的研发、招聘软件工程技术人才,同时聚焦技术社区建设。 KodeRover 为企业构建一体化交付平台,能够集成企业外部任何代码源KodeRover 成立于 2019 年初,团队成员均来自硅谷和国内的高校和云计算/互联网企业。其创始人李倩曾在七牛云负责重要交付零碎总架构师,郭健和葛俊别离毕业于斯坦福大学和中国科技大学,均有在硅谷顶尖公司十年以上的工作教训。 KodeRover 云原生软件交付工具以标准化的 SaaS 产品模式为企业软件研发团队提供从构建到公布的一体化工程交付平台,应用门槛非常低,5 分钟实现装置,10分钟就能开始应用。简直能够集成企业外部任何代码源、开源软件、外部零碎和多云基础设施。 KodeRover 通过并行式开发,使得工程师在开发过程中,主动实现代码集成、部署、验证、自测、联调、公布等工作。这种边开发边验证的形式,将工程师变更软件验证所需均匀工夫从 4 小时缩短到了 5 分钟以内,在提到交付效率的同时极大的升高了产品开发的老本。 目前,KodeRover 已服务了包含字节跳动、腾讯等数十家客户,为其提供集成测试治理能力。 KodeRover 创始人兼 CEO 李倩向媒体走漏,KodeRover 云原生交付技术平台的倒退还处于极晚期阶段,营业支出已实现成倍增长。李倩说:“2021 年 KodeRover 将推出更多产品性能,欢送酷爱软件工程、云计算、想扭转世界的技术业余及经营人才退出团队,在云原生畛域一起打造中国技术品牌。”

December 21, 2020 · 1 min · jiezi

关于云原生-cloud-native:资源成本双优化看-Serverless-颠覆编程教育的创新实践

作者 | 计缘起源 | Serverless 公众号 说起 Serverless 这个词,我想大家应该都不生疏,那么 Serverless 这个词到底是什么意思?Serverless 到底能解决什么问题?可能很多敌人还没有粗浅的领会和体感,这篇文章我就和大家一起聊聊 Serverless。 什么是 Serverless咱们先将 Serverless 这个词拆开来看。Server,大家都晓得是服务器的意思,阐明 Serverless 解决的问题范畴在服务端。Less,大家必定也晓得它的意思是较少的。那么 Serverless 连起来,再稍加润饰,那就是较少的关怀服务器的意思。 Serverfull 时代咱们都晓得,在研发侧都会有研发人员和运维人员两个角色,要开发一个新零碎的时候,研发人员依据产品经理的PRD开始写代码开发性能,当性能开发、测试完之后,要公布到服务器。这个时候开始由运维人员布局服务器规格、服务器数量、每个服务部署的节点数量、服务器的扩缩容策略和机制、公布服务过程、服务优雅高低线机制等等。这种模式是研发和运维隔离,服务端运维都由专门的运维人员解决,而且很多时候是靠纯人力解决,也就是 Serverfull 时代。 DevOps 时代互联网公司里最辛苦的是谁?我置信大多数都是运维同学。白天做各种网络布局、环境规划、数据库布局等等,早晨熬夜公布新版本,做上线保障,而且很多事件是重复性的工作。而后缓缓就有了赋能研发这样的声音,运维同学帮忙研发同学做一套运维控制台,能够让研发同学在运维管制台上自行公布服务、查看日志、查问数据。这样一来,运维同学次要保护这套运维控制台零碎,并且不断完善性能,轻松了不少。这就是研发兼运维的 DevOps 时代。 Serverless 时代慢慢的,研发同学和运维同学的关注点都在运维控制台了,运维控制台的性能越来越弱小,比方依据运维侧的需要减少了主动弹性扩缩、性能监控的性能,依据研发侧的需要减少了自动化公布的流水线性能。因为有了这套零碎,代码品质检测、单元测试、打包编译、部署、集成测试、灰度公布、弹性扩缩、性能监控、利用防护这一系列服务端的工作基本上不须要人工参加解决了。这就是 NoOps,Serverless 时代。 Serverless在编程教育中的利用2020 年注定是不平庸的一年,疫情期间,多少家企业如割韭菜般倒下,又有多少家企业如雨后春笋般茁壮成长,比方在线教育行业。 没错,在线教育行业是这次疫情的最大受益者,在在线教育在这个行业里,有一个细分市场是在线编程教育,尤其是少儿编程教育和面向非专业人士的编程教育,比方编程猫、斑马 AI、小象学院等。这些企业的在线编程零碎都有一些独特的特点和诉求: 屏幕一侧写代码,执行代码,另一侧显示运行后果。依据题目编写的代码都是代码块,每道题的代码量不会很大。运行代码的速度要快。反对多种编程语言。能撑持不可预计的流量洪峰冲击。例如小象学院的编程课界面: 联合上述这些特点和诉求,不难看出,构建这样一套在线编程零碎的外围在于有一个反对多种编程语言的、强壮高可用的代码运行环境。 那么咱们先来看看传统的实现架构: 从 High Level 的架构来看,前端只须要将代码片段和编程语言的标识传给 Server 端即可,而后期待响应展现后果。所以整个 Server 端要负责对不同语言的代码进行分类、预处理而后传给不同编程语言的 Runtime。这种架构有以下几个比拟外围的问题。 工作量大,灵活性差首先是研发和运维工作量的问题,当市场有新的需要,或者洞察到新业务模式时须要减少编程语言,此时研发侧须要减少编程代码分类和预处理的逻辑,另外须要构建对应编程语言的 Runtime。在运维侧须要布局撑持新语言的服务器规格以及数量,还有整体的 CICD 流程等。所以反对新的编程语言这个需要要落地,须要研发、运维破费不少的工夫来实现,再加上黑/白盒测试和 CICD 流程测试的工夫,对市场需求的撑持不能疾速的响应,灵活性绝对较差。 高可用本人兜底其次整个在线编程零碎的稳定性是重中之重。所以所有 Server 端服务的高可用架构都须要本人搭建,用以保障流量顶峰场景和稳态场景下的零碎稳固。高可用一方面是代码逻辑编写的是否优雅和欠缺,另一方面是部署服务的集群,无论是 ECS 集群还是 K8s 集群,都须要研发和运维同学一起布局,那么对于对编程语言进行分类和预处理的服务来讲,尚能给定一个节点数,然而对于不同语言的 Runtime 服务来讲,市场需求随时会变,所以不好具体掂量每个服务的节点数。另外很重要的一点是所以服务的扩容,缩容机制都须要运维同学来实时手动操作,即使是通过脚本实现自动化,那么 ECS 弹起的速度也是远达不到业务预期的。 ...

December 21, 2020 · 2 min · jiezi

关于云原生-cloud-native:阿里-10-年一个普通技术人的成长之路

作者 | 宋意  阿里巴巴高级技术专家起源|阿里巴巴云原生公众号 导读:不论是什么角色,成长是咱们每个人都必须经验的过程。作为一个技术人,成长不仅是技术上的一直精进,也包含日常工作中的方方面面。本文次要讲述了阿里巴巴高级技术专家在阿里 10 年的成长之路,分享他从一个一般技术人开始,在阿里的三个阶段,以及在降职、转岗、带团队、做事等方面的心得感悟。自我介绍宋健,花名宋意,2008 年开始加入工作,至今 12 年多始终专一在运维畛域。2010 年 6 月退出支付宝,做过监控、SRE、资源管理、运维产品等方面的工作,经验并参加了阿里运维从脚本到工具化再到主动智能化的演进过程,在阿里的 10 年依据部门变动有三个阶段: 2010.6-2013.1,支付宝(零碎运维部)2013.2-2015.12,技术保障(支付宝、阿里云、淘宝、B2B 等运维部门对立后的新 BU)2016.1-至今,天基(负责阿里寰球数据中心和运维体系的“数字化、自动化、智能化”建设)个人经历1. 支付宝关键词:开源监控、监控值班、应急响应入职后退出的团队是运维部的监控组,那个时候团队刚刚开始组建,所有的货色从零开始,好在有 B2B 的兄弟团队能够借鉴教训,利用 nagios 疾速构建了支付宝第一代监控零碎。过了几个月因为 双11 的起因,咱们的下班地点由华星时代搬到了电信二枢纽机房,因为支付宝过后的外围机房在那里,咱们须要 7*24 小时在现场以便疾速处理紧急事件。过后小组应该是 6 个同学,一白班一晚班一失常班,咱们一边值班一边保护监控零碎。 随着业务的疾速倒退服务器一直减少,很快一台 nagios 已无奈满足需要,调研后引入 centreon 解决了 nagios 的程度扩大问题。监控项的增加和保护以编辑 nagios 配置文件为主,没有方法凋谢所有人员,因而监控项的保护工作也是由监控团队负责,PE 和 DBA 只有整顿好需要收回邮件即可。但新建业务和扩容的频率越来越高,每天要花费大量工夫编辑文件受理监控需要且常常出错,和需求方协商后确定了针对不同业务组件设定监控模板的计划,再想方法主动获取到服务器信息,那个时候还没有专门 CMDB,起初总算实现了新机器上线主动匹配模板增加监控和告警。重要的告警都是通过短信收回,告警短信须要和线上业务的短信辨别开防止相互影响,所以咱们又洽购了几十个短信猫,专门学习了如何通过服务器管制短信猫发送短信,再起初还演进出了利用短信猫接管短信敞开告警的能力。 这样的状况持续一年左右逐步稳定下来,有了教训积淀后咱们开始尝试引入外包值班,而后开始招聘和培训外包同学,制订值班和应急规范,建设相应的流程零碎。外包值班又继续了差不多一年工夫,因为监控能够看到所有业务数据,出于平安思考又进行了去外包化。目前监控值班的角色依然存在,办公地点在西溪的寰球运行指挥核心,有专门的办公室和门禁限度,外面全是各种酷炫大屏,整个经济体的业务由他们 7*24 小时守护着。 这两年就是不停的做事件,不停的遇到问题和解决问题,逢山开路遇水搭桥。 2. 技术保障关键词:监控对立、OD 拆散、资源管理2013 年我所在部门由支付宝调整至团体,到团体后参加的第一个我的项目是对立团体监控零碎。原来淘宝、支付宝、阿里云、B2B 等业务都是自建监控团队和零碎,组织层面对立后必然要将零碎进行整合,整合后的新零碎叫 alimonitor。过后我的项目主导方是在运维开发团队,我参加进来时我的项目曾经启动,只有我一个人是在监控团队,这也是我第一次参加较大型的跨团队我的项目。因为刚调整到团体跟其它成员都不相熟,所以跟大家单干起来阻力很大,但我还是积极参与到我的项目中,每天跑到开发团队加入晨会,直到有一次在晨会上被气哭,但神奇的是从那天后单干就变的十分顺畅,再也感触不到壁垒的存在。我的项目继续了差不多一年工夫胜利上线,通过这个我的项目使我和开发团队的同学们建设起了良好的信赖关系,对后续的工作起到了很大帮忙。 开发团队负责着团体所有的运维工具,除 alimonitor 外还有 staragent、armory、aone 等,有段时间这些工具常常产生故障,甚至在双十一、双十二的关键时刻掉链子,起初从业务团队转来一位资深同学负责团队,并发动了运维工具的 OD 拆散我的项目,我作为次要负责人承当所有工具的 PE 职责,也是这时候我开始带团队,最终推动 10 多个产品上百个利用实现 OD 拆散标准化革新,解决了工具的稳定性问题。因为每个工具负责了运维的其中一个环节,所有工具承载的业务加起来形成了团体的工具运维体系,这段经验使我对运维业务有了更全面和深层次的了解。 工具 PE 的事件稳固后我又接到了一个事件,负责整个团体开发测试环境的资源管理,测试环境过后有好几万台服务器,但没有人晓得哪些机器在用以及谁在用,而且每年还有数千台的物理机新增估算,老本节约十分重大。我接手后首先建设了一个资源生命周期管理系统,使所有新资源的申请全副通过零碎,并且对已有资源发动盘点和认领,所有资源设置有效期,到期后能够续租或开释,零碎还会定期巡检资源的应用状况,再配合宕机回收、闲置降配等经营策略,最终将测试资源盘点的清清楚楚,不仅年度预算 0 新增,还将回收的几千台物理机在双十一时声援了生产环境。再起初持续尝试通过混部晋升测试资源使用率,调研多个计划后抉择了跟 jstorm 团队单干,但上线后经常出现 jstorm 工作把测试机资源占满,影响业务的日常测试引发投诉,受限于过后技术限度最终没能持续推动上来。 ...

December 21, 2020 · 2 min · jiezi

关于云原生-cloud-native:围观|第一代云原生企业米哈游如何让想象发生

作者 | 贾宁宇起源|阿里巴巴云原生公众号 在米哈游的办公区,有一间会议室,专门留给了阿里云工程师。 往年,是这家二次元文化公司创建的第九年,米哈游和阿里云的交情,也有八年了。 米哈游总裁刘伟还记得多年前,王坚博士带着八位公司高管和负责团队到达米哈游办公室时的情景。那天,在米哈游租用的小小的办公区中,只有 30 多个工位,甚至没有一间会议室能同时包容这十来名访客。 那时,米哈游创建不久,阿里云也还在对外服务的起步阶段,两个老成持重的小兄弟机缘巧合走到了一起,彼此摸索着前行。 那一天,王坚博士讲了这样一段话:“如果客户坐着飞机在天上飞,咱们只在地上看,是很容易出故障的。要做,咱们就和客户一起在天上飞。” 临走时,王坚博士将本人的手机号写给了刘伟。他说,有任何问题,间接打电话给我。 许多年过来了,所幸,这样的一通电话从未拨出去。而阿里巴巴外围零碎也早已实现 100% 上云,验证了那句“和客户坐在同一架飞机上”。 工夫一晃而过。2020 年 9 月,在米哈游与阿里云并行的第八年,这家二次元文化公司上线了最新的代表作《原神》,寰球五大区服齐全承载在阿里云上。 在这一年年底,《原神》像游戏行业的一匹黑马,热度节节上升。 11 月 30 日,谷歌将 Google Play 2020 年度最佳游戏颁发给了《原神》;仅一天后,苹果又将 App Store 2020 iPhone 年度游戏交给了《原神》。 这可能是中国游戏首次取得“双冠”殊荣。 在这一年,阿里云也早已从当年的小兄弟成长为云计算行业的领军者,成为许多行业的数字化底座,也为许多中国游戏企业提供服务。 从“置信”开始回到 2012 年,米哈游刚刚做出二次元游戏《崩坏学园》。 那一年,手游市场还处于起步阶段,动漫游戏更是开发者寥寥,环视 App Store,没有几个成型的手机动漫游戏。但在米哈游心里,将来的游戏市场,肯定有国产动漫的一席之地。 偶合的是,云计算的行业阶段和动漫游戏有些相似。作为一个新生技术,中国的云计算行业起步不久,但米哈游和阿里云都有着一个对于将来的幻想。 没有人晓得将来如何到达,“置信”就是惟一的门路。 传统IT时代,游戏公司的做法是本人购买服务器、自建机房、配置运维人员。这样斥巨资能力启动的重模式,将许多有想法的创业者挡在了游戏行业的门外,在那个期间,研发游戏简直只能是大公司的专利。 云计算带来了一个新机会——跳过所有后期的 IT 设施投入,间接在网页上点点鼠标,就能调用云算力。这简直是为米哈游这样的守业团队量身定制的完满产品。 米哈游开创团队晚期合影 “崩 1”上线时,应用了阿里云的两台云服务器,小小的尝试,开启了米哈游的“云上之旅”。 回顾起来,米哈游能够说是一代互联网守业企业的代表。诞生在云端,所有业务都在云上,率先感触着云计算高弹性、高并发、低成本等种种特色,堪称“云原生企业”。 也正是这一代“云原生企业”的疾速成长,推动着中国云计算的倒退与遍及。 2016 年,米哈游上线了第三款游戏:《崩坏 3》。但在此时,米哈游仍只有两名运维人员——在传统自建服务器机房的时代,这简直是不可设想的。 作为晚期云计算的“吃螃蟹”用户,米哈游踩过坑。 “问题是很难防止的,要害是能不能解决问题。”米哈游的技术负责人刘霄回顾说。 一年年过来,米哈游也慢慢成长起来,从三个人到几十人,再到几百、上千人,不再是那个没有会议室的小团队。 米哈游也为阿里云工程师们专门留了一间会议室,对他们说,“随时来、随时用”。 “取道”阿里云,平安出海起初,米哈游规模尚小,在拓展海内市场的过程中也遇到了一些挫折。 “所幸当初规模小,用户不算多,这件事的负面影响还能管制。如果是在“崩 3”、《原神》这样规模的游戏上,那损失就不可估量了。”回想起来,刘霄还有些后怕,“所以应该说,对于大部分游戏公司,云就是最好的抉择,没有之一。” 2016 年,米哈游正式开启全面“出海”。在海内服务区,《崩坏 3》最后抉择了一家海内云服务商,却遭逢了几次黑客的 DDoS 攻打,更有一次甚至影响用户失常拜访。 ...

December 21, 2020 · 1 min · jiezi

关于云原生-cloud-native:年终盘点-七年零故障支撑-双11-的消息中间件-RocketMQ怎么做到的

作者 | 愈安起源|阿里巴巴云原生公众号 2020 年双十一交易峰值达到 58.3W 笔/秒,消息中间件 RocketMQ 持续数年 0 故障丝般顺滑地完满反对了整个团体大促的各类业务安稳。往年双十一大促中,消息中间件 RocketMQ 产生了以下几个方面的变动: 云原生化实际。实现运维层面的云原生化革新,实现 Kubernetes 化。性能优化。音讯过滤优化交易集群性能晋升 30%。全新的生产模型。对于提早敏感业务提供新的生产模式,升高因公布、重启等场景下导致的生产提早。云原生化实际1. 背景Kubernetes 作为目前云原生化技术栈实际中重要的一环,其生态曾经逐渐建设并日益丰盛。目前,服务于团体外部的 RocketMQ 集群领有微小的规模以及各种历史因素,因而在运维方面存在相当一部分痛点,咱们心愿可能通过云原生技术栈来尝试找到对应解决方案,并同时实现降本提效,达到无人值守的自动化运维。 消息中间件早在 2016 年,通过外部团队提供的中间件部署平台实现了容器化和自动化公布,整体的运维比 2016 年前曾经有了很大的进步,然而作为一个有状态的服务,在运维层面依然存在较多的问题。 中间件部署平台帮咱们实现了资源的申请,容器的创立、初始化、镜像装置等一系列的根底工作,然而因为中间件各个产品都有本人不同的部署逻辑,所以在利用的公布上,就是各利用本人的定制化了。中间件部署平台的开发也不齐全理解团体内 RocketMQ 的部署过程是怎么的。 因而在 2016 年的时候,部署平台须要咱们去亲自实现消息中间件的利用公布代码。尽管部署平台大大晋升了咱们的运维效率,甚至还能实现一键公布,然而这样的计划也有不少的问题。比拟显著的就是,当咱们的公布逻辑有变动的时候,还须要去批改部署平台对应的代码,须要部署平台降级来反对咱们,用最近比拟风行的一个说法,就是相当不云原生。 同样在故障机替换、集群缩容等操作中,存在局部人工参加的工作,如切流,沉积数据的确认等。咱们尝试过在部署平台中集成更多消息中间件本人的运维逻辑,不过在其余团队的工程里写本人的业务代码,的确也是一个不太敌对的实现计划,因而咱们心愿通过 Kubernetes 来实现消息中间件本人的 operator 。咱们同样心愿利用云化后云盘的多正本能力来升高咱们的机器老本并升高主备运维的复杂程度。 通过一段时间的跟进与探讨,最终再次由外部团队承当了建设云原生利用运维平台的工作,并依靠于中间件部署平台的教训,借助云原生技术栈,实现对有状态利用自动化运维的冲破。 2. 实现 整体的实现计划如上图所示,通过自定义的 CRD 对消息中间件的业务模型进行形象,将原有的在中间件部署平台的业务公布部署逻辑下沉到消息中间件本人的 operator 中,托管在外部 Kubernetes 平台上。该平台负责所有的容器生产、初始化以及团体内所有线上环境的基线部署,屏蔽掉 IaaS 层的所有细节。 Operator 承当了所有的新建集群、扩容、缩容、迁徙的全副逻辑,包含每个 pod 对应的 brokerName 主动生成、配置文件,依据集群不同性能而配置的各种开关,元数据的同步复制等等。同时之前一些人工的相干操作,比方切流时候的流量察看,下线前的沉积数据察看等也全副集成到了 operator 中。当咱们有需要从新批改各种运维逻辑的时候,也再也不必去依赖通用的具体实现,批改本人的 operator 即可。 最初线上的理论部署状况去掉了图中的所有的 replica 备机。在 Kubernetes 的理念中,一个集群中每个实例的状态是统一的,没有依赖关系,而如果依照消息中间件原有的主备成对部署的计划,主备之间是有严格的对应关系,并且在高低线公布过程中有严格的程序要求,这种部署模式在 Kubernetes 的体系下是并不提倡的。若仍然采纳以上老的架构形式,会导致实例管制的复杂性和不可控性,同时咱们也心愿能更多的遵循 Kubernetes 的运维理念。 ...

December 17, 2020 · 2 min · jiezi

关于云原生-cloud-native:刚刚阿里云知行动手实验室正式开放公测了

起源|阿里巴巴云原生公众号 常常去 GitHub 看 trending 开源我的项目源码,明明都看得懂,为什么感觉对技术晋升不显著?B 站热门教程都学了,极客工夫也氪金了,听的时候感觉有条有理,到本人写的时候却写不进去?这大略就是传说中的“听过很多情理,却仍然写不好代码”。知行不能合一,始终以来都是技术人成长过程中的通病。 阿里云资深技术专家儒枭已经在内网公布过一篇技术人成长的文章 -《我看技术人的成长门路》,受到了数万阿里人的认可,他总结了技术人成长的 721 准则:70% 做中学,20% 向别人学习,10% 自学。但大部分技术人的学习仿佛都倒过去 follow 了 127 准则。即使是晓得“在做中学(Learning by doing)”的重要性,但面对像 K8s 这样有着平缓的学习曲线和简单的环境搭建的新技术,对绝大部分开发者来说都是在线劝退。 阿里云知口头手实验室正式凋谢公测 在 2020 年 12 月 16 日,云原生生态大会上,etcd 作者、CNCF 技术监督委员会委员、阿里云资深技术专家李响正式公布了阿里云知口头手实验室 start.aliyun.com。 它解决了开发者学习新技术最初一公里的问题,开发者能够在浏览器中间接利用阿里云提供实在环境来学习新技术。和传统的学习形式比有以下劣势: 沉迷式、可交互学习体验知口头手实验室集代码、shell 命令行、文档三个窗口于一个浏览器页面,通过鼠标点击即可实现命令执行、代码批改等操作,无需关上 N 个窗口、来回复制粘贴。 收费云资源实验室以及应用到的各种云资源都是收费的,无需放心任何费用的问题。单个试验环境能够收费应用一小时,试验完结后资源主动开释。 零门槛利用创立知口头手实验室间接屏蔽了环境筹备的复杂性,让开发者能够专一于学习、预研新技术新产品自身。点击鼠标,参加试验才是最佳的打开方式。 目前反对的试验场景公测期间,知口头手实验室以 Spring Cloud Alibaba 实现的微服务场景为主,提供了较完整的微服务试验。次要包含了:Nacos Config 分布式配置、Nacos Discovery 服务注册&发现、Dubbo Spring Cloud 分布式调用,以及Sentinel 限流熔断、Seata 分布式事务、RocketMQ 音讯等。根本涵盖了微服务开发的次要模块。 后续打算后续,咱们会持续丰盛知口头手实验室反对的试验场景,次要包含支流开源我的项目以及热门云服务体验试验。 在微服务畛域,除了将反对 Dubbo 这样支流的微服务框,咱们会深刻微服务外部,反对微服务架构外围模式的周边,包含测试、部署、集成、调试等试验场景。在容器调度畛域,将反对 Kubernetes 相干的试验场景。在 AI 畛域,将反对 Flink 等热门开源我的项目的试验场景。将来咱们还会凋谢自定义试验接入性能,让宽广开发者能够将本人的场景放到知口头手实验室来。 ...

December 17, 2020 · 1 min · jiezi

关于云原生-cloud-native:如何在数智化时代少走弯路-这里有100个案例可以借鉴

“他山之石,可以攻玉” from 《诗经·小雅·鹤鸣》 当今时代,企业是驱动翻新的次要能源。翻新不是易事,通过他人的案例看清翻新办法,对防止反复犯错或少走弯路都不无裨益。 科技界有这么一个榜单,每年向当先企业和晚期实践者征集年度里程碑或卓越成绩背地的案例故事,从中精选出 100 件案例,如同商业畛域的哈佛案例,帮忙大家在互联网时代凋谢、自在地吸取案例带来的独特价值,转化为所有研发核心可用的促成成长的案例。 兴许你曾经猜到了,这就是 寰球软件案例钻研峰会(简称“壹佰案例”) ,亦称 TOP100 Summit 。作为科技界颇具影响力的案例钻研峰会,TOP100 Summit 借助于纯学术和理论案例钻研方面的联合显现出微小推动力。不同于媒体的追赶热点和离奇概念,TOP100在案例评比时,更崇尚业余的力量和案例落地实际,案例提交者须要从案例指标、胜利要点与背地教训、ROI 剖析、案例启发、案例对组织的意义等多个维度进行结构化提炼,从而达到让听众有所收益的目标,保障了每年公布的案例学习榜单是最有学习价值的。 往年的 TOP100 Summit 将于 12月17-20日在北京举办 ,峰会将分为六大技术角色论坛、十八大专题。对于产品、经营、效力、大前端、工程实际、AI、工具链、DevOps等畛域都设立了专题,别离笼罩游戏、软件、电商、金融、能源、交通、石油、游戏、医疗、工业、批发、出行、教育等行业。 在往年最具代表的 TOP100 中,京东共入选 6 个案例,波及研发效力、产品翻新、经营增长、云原生、DevOps、数据平台等多个畛域。 其中,京东智联云提交的 3 个案例从泛滥海选案例中怀才不遇,为大家带来云上服贸会、研发效力度量、云原生等前沿技术的最佳落地实际 。更令人兴奋的是,来自京东智联云的三位技术大咖,将在峰会中现场揭秘案例背地的摸索历程与实际心得。 上面就带大家提前剧透下获选的 3 个案例带来的胜利启发及案例剖析: 案例剧透1,把「服贸会」搬到线上:数字孪生催生的跨畛域产品翻新 分享嘉宾:庄珑鹏 | 京东智联云 商业平台部总经理 | 案例简述 2020年中国国内服务贸易交易会即2020服贸会不仅是疫情产生以来第一场重大的国际经贸流动,是国家级、国际性、综合型的会展。同时,也是一场线下线上充沛交融的数字孪生会展。如何在短时间实现全链条的会展服务的平台建设,如何围绕“展、论、洽”三大会展场景恰到好处地去做产品翻新,产品部门如何利用IOT、AI、云计算等技术让会议“从线下走向线上”,以上三个问题是本次分享重点要分享的内容。数字经济浪潮下,产业数字化转型和智能化降级早已不仅是一种技术手段,更是一种产品思维,是将来竞争的战略思维。通过本案例的分析,心愿让听众特地是产品经理们了解在这个浪潮下如何利用新技术改造传统业务。 | 案例背景 传统会展行业历经已久,造成了稳固的规模和行业生态,这次疫情,使得很多问题减速裸露,信息化伎俩繁多,不足人工智能、大数据等先进技术和伎俩,不反对云上虚构展厅,不反对多国语言,整个会展行业亟待全面数字化、智能化降级转型。 | 胜利要点 京东从0到1重构会展产业:从线下走向线上,从繁多实现交融京东以技术、资源、实战经验推动会展基础设施数智化在数智化的过程中,如何用产品思维解决「线下到线上」的新问题在这个案例中,重点介绍产品侧与技术侧协同,如何在以下用户场景实现冲破:线上线下交融、沉迷式会展体验、在线洽谈,大容量高清视频会议,AI能力(人工智能翻译,机器人现场交互),高平安保障等方面。| 案例 ROI 剖析 “线上+线下”办展办会新模式,最大限度地拓展了参会参展的范畴和空间。目前看国内外展会“线上”比例绝对偏低,服贸会是展会行业顶级会展线上的一大冲破。 基于服贸会的胜利案例,联合目前会展行业的具体情况再度进行维度降级,将已有服务联合行业需要进行多租户SaaS衍生,具备行业会展云能力。| 案例启发 基于服贸会最佳实践经验,如何用技术助力传统会展行业的数字化转型和智能化降级;增强政企互动,关注企业数智化转型,加大新型基础设施投入,实现基础设施的全面数字化和智能化。2,研发效力度量的误区、体系化实际和效力晋升案例 分享嘉宾:张乐 | 京东 DevOps与研发效力技术总监 & 首席架构师 | 案例简述 现在很多公司都十分关注企业研发效力,也在破费很大的人力物力投入到麻利、DevOps、数字化转型之中。然而,转型是否真的有成果、是否达到了预期,有时却是很难答复的一个问题。咱们常常讲,没有度量就无奈改良。本次分享聚焦在研发效力度量畛域,首先会解说一家跨国企业大规模麻利转型和度量的失败案例,并比照微软、Facebook、阿里、腾讯、百度等业界支流公司的成功经验,总结出研发效力度量的七大准则。而后会分享近期在实践中总结出的研发效力度量体系,这是一套被证实切实可行的、通过度量为抓手剖析软件交付价值流的产出和瓶颈,从而有针对性地促成企业研发效力晋升的体系化办法。进而对京东团体的研发效力度量体系建设过程和效力改良案例进行具体分析。最初会给出经验总结和避坑指南,置信对听众系统性了解该畛域有所启发。 | 案例背景 研发效力度量应该怎么做?如何无效评估团队和交付能力及趋势?如何防止谬误的、有副作用的度量形式?业界BAT和国外支流公司是怎么做的?有没有能够参照的、比拟残缺的度量模型?有没有理论利用的胜利案例? ...

December 16, 2020 · 1 min · jiezi

关于云原生-cloud-native:从零入门-Serverless-教你使用-IDEMaven-快速部署-Serverless-应用

作者 | 许成铭(竞霄) 阿里云开发工程师 SAE 利用部署形式1. SAE 概述 首先,简略介绍一下 SAE。SAE 是一款面向利用的 Serverless PaaS 平台,反对 Spring Cloud、Dubbo、HSF 等支流开发框架,用户能够零代码革新间接将利用部署到 SAE,并且按需应用、按量计费、秒级弹性。SAE 充分发挥 Serverless 的劣势,为用户节俭闲置资源老本;在体验上,SAE 采纳全托管、免运维的形式,用户只需聚焦外围业务的开发,而利用生命周期治理、微服务治理、日志、监控等性能交由 SAE 实现。 ** 2. SAE 利用部署形式 在应用 SAE 时,您能够在管制台上看到 SAE 反对三种部署形式,即能够通过 WAR 包、JAR 包和镜像的形式进行部署,如果您采纳 Spring Cloud、Dubbo、HSF 这类利用,能够间接打包上传,或者填入包的地址便能够部署到 SAE 上;对于非 Java 语言的场景,您也能够应用镜像间接来部署,后续咱们也会反对其余语言间接上传包的模式进行部署。 SAE 除上述控制台界面部署的形式之外,还反对通过 Maven 插件或者 IDE 插件的形式进行部署,这样您无需登录控制台,就能够执行自动化部署操作,同时能够集成如云效、Jenkins 等工具实现 CICD 流程。 Maven 插件部署 如何应用 Maven 插件进行部署?首先须要为利用增加 Maven 依赖 toolkit-maven-plugin,接下来须要编写配置文件来配置插件的具体行为,这里定义了三个配置文件: toolkit_profile.yaml 账号配置文件,用来配置阿里云 ak、sk 来标识阿里云用户,这里举荐应用子账号 ak、sk 以升高平安危险。toolkit_package.yaml 打包配置文件,用来申明部署利用的类型,能够抉择 war、jar、url 以及镜像的形式来进行部署,若采纳 war、jar 的形式,则会将以后利用进行打包上传,而 url 或者镜像的形式则要显示的填写对应的包地址或者镜像地址进行部署。toolkit_deploy.yaml 部署配置,即能够配置该利用的环境变量、启动参数、健康检查等内容,这与管制台上的配置选项是统一的。这三个文件都有对应的模板,具体的模板选项能够查看产品文档,接下来通过运行 Maven 打包部署命令 mvn clean package toolkit:deploy 即可自动化部署到 SAE 上。 ...

December 15, 2020 · 1 min · jiezi

关于云原生-cloud-native:一个改变世界的箱子

作者 | 云希起源|阿里巴巴云原生公众号 一个时代的改革往往始于一个渺小的翻新。 1956 年,对航运无所不通的卡车大亨麦克莱恩第一次将集装箱用于货物运输时,恐怕连他本人也设想不到,一个一般的铁箱子将会引发一场寰球的微小改革。 集装箱尺寸统一,运输流程规范、零碎。每个箱子只装一件货物,能在港口、火车、轮船间自在装卸。它大大晋升效率的同时,也让运输成本升高了 90%,从本质上突破了各个国家、港口之间的物流壁垒。 这个箱子将世界就变成了一座大工厂,促使了寰球分工和资源流通——苹果找到中国的富士康,丰田公司发明出“及时生产”,美国人吃到了巴西的牛肉……一个微不足道的翻新让世界的经济和政治格局都为之扭转。 在 IT 届,这个箱子被称为“容器”。 和集装箱一样,容器将利用封装好后,便能够在任意环境之下自在装卸、麻利运行,进步研发效率的同时,大大降低了运维老本,从而掀起科技圈的新浪潮。 自 2013 年 Docker 呈现以来,“容器”便成为云计算畛域煊赫一时的关键词。2019 年公开信息显示,Docker 开源版的下载次数超过 800 亿次,有约有三分之一的财产 100 强和五分之一的寰球 500 强公司都应用 Docker 企业版。权威机构 Gartner 预测,2022 年将有 75% 的企业应用容器。 不同于以往追寻硅谷的姿势, 国内的容器化实际早在 10 年前便已拉开帷幕。 性能危机这其中,布局最早的是阿里。 2011 年,随着云计算的遍及,阿里巴巴走过物理机时代,全面迈向虚拟机。 如果说物理机是家里的电脑,那虚拟机则是在电脑上模拟出的许多台小电脑,它领有残缺的软硬件性能,应用体验就跟电脑统一。但“虚拟化”有性能损耗。如果一台 100 个 CPU 的物理机能虚构进去 100 台小电脑,那么只有 90 台真正干活,另外 10 台要额定做管理工作,损耗由此造成。 规模小时损耗无伤大雅,但阿里数万集群,光是虚拟化过程中耗损的算力就抵得过一家中型互联网公司。 2011 年,为了缓解微小的虚拟化损耗,淘宝的第一个程序员蔡景现(花名:多隆)和第一代架构师林昊(花名:毕玄)在无心插柳中研发出了阿里第一代容器——T4。 T4 同样基于物理机而来。一般虚拟机将整个操作系统运行在虚构的硬件平台上,进而提供运行环境供给用程序运行,而 T4 则间接在宿主平台上加载运行应用程序。 所以 T4 应用体验和虚拟机统一,却能缩小性能损耗,一经推出便大受欢迎,并逐步取代虚拟机,承当了团体整个交易系统的计算资源。 但它仍然无奈解决阿里高企的运维老本。 彼时,为了维系宏大集群的稳固,阿里运维团队超过 300 人,24 小时轮班,仍然追不上逐年攀升的业务量。“双11” 期间,用户暴涨,利用激增,数以百计的工程师更要手动扩容,用人肉筑起堤坝才不至于被流量洪峰冲倒。 ...

December 15, 2020 · 2 min · jiezi

关于云原生-cloud-native:云原生体系下的技海浮沉与理论探索

作者 | 王银利(芸峥)起源|阿里巴巴云原生公众号 概述攻技者,短之;实践者,长之;践行者,胜之。能够这么说,一座城市的良心就体现在下水道上,不管这座城市有多少高楼大厦,建设得有如许雄伟,只有是下雨天,雨水就变成了城市良心的测验者。如果由城市建设来类比云原生体系的建设,那么云原生的良心又应该是什么?谁是云原生的暴风雨?谁又是云原生良心的测验者? 云原生带来的业务价值十分多,次要有如下几条: 疾速迭代:天下文治,唯快不破。咱们想要在残暴的市场竞争中争得一席之地,就必须后发制人。云原生的实质就是帮忙业务疾速迭代,外围因素就是继续交付。安全可靠:云原生通过可观测机制,能够疾速让咱们从谬误中复原,同时通过逻辑多租和物理多租等多种隔离形式,限度非法应用。弹性扩大:通过将传统的利用革新为云原生利用,做到弹性扩缩容,可能更好地应答流量峰值和低谷,并且达到降本提效的目标。开源共建:云原生通过技术开源可能更好地帮忙云厂商关上云的市场,并且吸引更多的开发者共建生态,从一开始就抉择了一条“飞轮进化”式的路线,通过技术的易用性和开放性实现快速增长的正向循环,又通过一直壮大的利用实例来推动了企业业务全面上云和本身技术幅员的不断完善。接下来,本文将由浅入深,从云原生的方方面面进行剖析,包含根底的概念、罕用的技术、一个残缺的平台建设体系,让大家对云原生有个初步的理解。 什么是云原生?1. 云原生的定义云原生的定义始终在发生变化,不同的组织也有不同的了解,比拟闻名的有 CNCF 和 Pivotal 。上面是 CNCF 的最新定义: 云原生技术有利于各组织在私有云、公有云和混合云等新型动静环境中,构建和运行可弹性扩大的利用。云原生的代表技术包含容器、服务网格、微服务、不可变基础设施和申明式 API。 这些技术可能构建容错性好、易于治理和便于察看的松耦合零碎。联合牢靠的自动化伎俩,云原生技术使工程师可能轻松地对系统作出频繁和可预测的重大变更。 云原生计算基金会(CNCF)致力于培养和保护一个厂商中立的开源生态系统,来推广云原生技术。通过将最前沿的模式民主化,让这些翻新为公众所用。 另外,作为云计算领导者,Heroku 的创始人 Adam Wiggins 整顿了驰名的云原生十二因素(The Twelve-Factor App:https://12factor.net/zh_cn/))。之后,同样作为云计算领导者,Pivotal (已被 VMWare 收买)的 Kevin Hoffman 出版了 Beyond the 12 factor App 一书,基于原十二因素新增了三个新因素,即云原生十五因素 。 十五因素综合了他们对于 SaaS 利用简直所有的教训和智慧,是开发此类利用的现实实际规范。十五因素实用于任何语言开发的后端应用服务,将流程自动化和标准化,升高新员工的学习老本;并且划清了与底层操作系统间的界线,以保障最大的可移植性。 下图可概览云原生所有的定义和特色: 2. 云原生实质从字面意思上来看,云原生能够分成云和原生两个局部。 云是和本地绝对的,传统的利用必须跑在本地服务器上,当初风行的利用都跑在云端,云蕴含了 IaaS、PaaS 和 SaaS 。 原生就是土生土长的意思,咱们在开始设计利用的时候就思考到利用未来是运行在云环境上,要充分利用云资源的长处,比方️云服务的弹性和分布式劣势。 云原生既蕴含技术(微服务、麻利基础设施),也蕴含治理(DevOps、继续交付、康威定律、重组等)。云原生也能够说是一系列云技术、企业治理办法的汇合。 1)云原生不是业务自身好几个人问我云原生是什么,我会反诘他们,如果你想本人的业务疾速迭代,你心愿云原生是什么。云原生肯定不是一个具体的货色,而是代表了如何谋求问题的实质,它原本是什么,就是什么,它是一套方法论。 云原生的实质是帮忙业务疾速迭代,不是业务自身,不是技术重叠,不是生吞活剥。咱们不应该看咱们有什么,而要看客户原本要的是什么。 那么云原生其实就是代表了科技的提高,咱们不光要进步新业务的迭代效率,还要打破旧业务的迭换效率。一个好的架构个别会兼容人类的愚昧,所以这里的旧业务可能是历史包袱,可能是常识瓶颈带来的偏见。 咱们无时无刻都在变成旧,无时无刻都在发明新。人要敢于质疑本人,质疑过来,质疑权威,才有创立新的能源和洞见。 2)云原生不是云计算云计算(Cloud Computing)和云原生(Cloud Native)有很大区别,次要体现在以下六个方面: 起源云原生应用程序源于云原生。如前所述,它们构建并部署在云中,真正地拜访了云基础设施的弱小性能。云计算应用程序通常是在外部应用传统基础设施开发的,并且通过调整后能够在云中近程拜访。 设计云原生应用程序被设计为多租户实例托管(微服务架构)。云计算应用程序在外部服务器上运行,因而它们没有任何多租户实例。 便捷性云原生应用程序是高度可扩展性,能够对单个模块进行实时更改,而不会对整个应用程序造成烦扰。云计算应用程序须要手动降级,从而会导致应用程序中断和敞开。 价格云原生应用程序不须要任何硬件或软件上的投资,因为它们是在云上进行的,通常能够在被许可方取得,因而应用起来绝对便宜。云计算应用程序通常比拟低廉,因为它们须要进行根底降级以适应一直变动的需要。 实现因为不须要进行硬件或软件配置,云原生应用程序很容易疾速实现。云计算应用程序须要定制特定的装置环境。 3)云原生自身是简单的云原生扭转的不止是技术,最终去扭转的是业务。云原生既然会帮忙业务疾速迭代,那么业务代码和我的项目流程必然会产生根本性变动。典型的就是业务越来越轻,底座越来越厚,数据处理越来越自动化,非人用户越来越多。 接下来,咱们能够从尤瓦尔赫拉利的三部简史来窥探下云原生的实质。 21 世纪随着人工智能的倒退,人类社会将由人文主义逐步过渡到数据主义。人类社会如果是一个比拟大的数据网络,包含人类的情感都只是进化论抉择下的生物算法,那么每一个人只是其中的一个数据处理器,能够是智人,能够是虚拟人,也能够是将来的超人类。咱们能够拿共产主义和资本主义的区别来举例。共产主义是集中式算法,通过国家的数据网络计算每一个人的需要再进行调配;资本主义是分布式算法,多数的资本家掌控大部分的社会资源。 ...

December 14, 2020 · 7 min · jiezi

关于云原生-cloud-native:专访-CNCF-大使张磊让云原生不再是大厂专属

近日,GitHub 上的 Go 语言趋势榜呈现了一个新的我的项目 —— KubeVela。 据我的项目官网文档,KubeVela 是“一个简略易用且高度可扩大的利用治理平台与外围引擎,KubeVela 是基于 Kubernetes(K8s)与 Open Application Model(OAM)技术构建的”。 在云原生浪潮席卷寰球的明天,置信大家对 K8s 必定不会生疏,那么 KubeVela 和 OAM 又是什么技术呢?事实上,K8s 的小名尽管曾经路人皆知,但在很多社区网友的反馈中,咱们仿佛看到围绕 K8s 的云原生生态目前只是几家头部大厂的专属。很多一线业务同学都反馈 K8s 太简单了,太难学了,如果没有大厂的投入和技术储备来基于 K8s 构建出场景化的下层平台进去,要落地云原生技术,感觉基本搞不定。 而去年十月,阿里云与微软单干独特开源了 OAM 我的项目,旨在为云原生生态提供一个以利用为核心的、对立的下层形象技术,从而大大降低业务研发同学上手云原生技术的门槛,真正享受到云原生带来的极致麻利与研发效力晋升。而刚刚公布的 KubeVela 我的项目,正是 OAM 模型在 Kubernetes 上的残缺实现。 现在间隔 OAM 我的项目开源正好过来一年, 那么 OAM 我的项目现在有何停顿?本次公布的 KubeVela 我的项目又将为国内的 K8s 生态带来哪些影响?带着这些问题,咱们与 KubeVela 我的项目背地的设计者之一、CNCF 利用交付畛域小组 co-chair、官网大使,来自阿里云的工程师张磊,具体的聊了聊。 采访嘉宾介绍 以下为采访原文: 请给还不理解 OAM 的敌人介绍一下 OAM 和 KubeVela 我的项目吧。<张磊>:Kubernetes 和云原生技术的各种外围概念,间隔咱们业务用户其实是很边远的。理论的落地过程也通知咱们,仅仅有基础设施层形象,离云原生“丝般顺滑”的云端利用治理与交付体验,还是存在着微小的鸿沟。在 Kubernetes 与用户之间,还存在着一层名叫“应用层”形象亟待填补。所以,很多业务用户对“云原生”、Kubernetes 的价值其实广泛不足体感,这个状况不仅在阿里外面存在,在整个社区里也是个让人头疼的问题。只有咱们的业务研发接触到的是“代码”、“利用”而不是“Pod”、“StatefulSet”,那么“让研发专一于写代码”这个美妙、奢侈的云原生欲望,才可能真正实现。 而 Open Application Model(OAM)凋谢利用模型,以及它的 Kubernetes 实现 KubeVela 我的项目,正是阿里云联结微软等云原生社区中坚力量,独特推出的“以解决用户侧诉求”为外围的云原生应用层我的项目。其中,OAM 的设计思维是为包含 Kubernetes 在内的任何云端基础设施提供一个对立、面向最终用户的利用定义模型;而 KubeVela,则是这个对立模型在 Kubernetes 上的残缺实现。对于业务研发人员来讲,KubeVela 能够被认为是云原生社区的 Heroku。而对于平台团队来讲,KubeVela 因为具备极高的可扩展性,则能够被认为是一个“以利用为核心”的、高度可扩大的 Kubernetes 发行版。而 OAM 我的项目,这是 KubeVela 背地的外围 API 范式和插件化能力治理模型。 ...

December 11, 2020 · 2 min · jiezi

关于云原生-cloud-native:Github-2020-年度报告你以为新冠击溃了开发者不他们创造了更多代码

作者 | DD 编辑部起源 | Serverless 公众号 2020 年马上就要过来了,在这一年中每个人必定都有本人独特的感悟与回顾,这一年中每一个人都经验着新冠疫情给咱们带来的各种变动。 相比其余职业,可能程序员从工作角度上来说,受到的影响会更小一点,因为程序员只有有一台电脑,哪怕在家里也能失常动工,甚至于很多程序员在疫情期间破费在我的项目开发上的工夫更多了。这一点咱们从 Github 平台公布的 2020 年度报告(报告下载地址:https://octoverse.github.com/)也能够发现端倪。 GithubGithub 平台作为微软旗下的代码托管平台,在世界范畴内领有数以千万计的开发者用户,逐步曾经成为了治理开源我的项目开发以及发现开源代码的首选办法。这次一共颁布了三份报告,别离是:2020-community-report、2020-productivity-report、2020-security-report。 从报告中咱们能够看到,目前 Github 平台的用户数曾经超过了 5600 万,兴许是因为更多的人开始在家办公,开源我的项目的数量在按 40% 的速度疾速减少,越来越多的人将开源作为一种与社区中其他人一起学习、发明的形式。而其中,程序员所占的比例始终是最大的。 报告中也提到,Python 作为时下热门的一种语言,在过来的一年中,共有来自 202 个国家和地区的 361832 位开发者上传了相干的我的项目做出了本人的奉献。 而随着疫情的变动,开源我的项目在咱们生存中表演的角色也随着 2020 年人们习惯待在家里而扭转。 首先从开发人员申请 merge 所破费的工夫能够看出,今年年初和去年同期相比,申请 merge 破费的工夫要多几个小时,然而到了 3 月份之后这个工夫疾速缩短,意味着更多的人们开始投入他们的开源我的项目,尤其可能因为他们发现只能待在家里后,从而有更多的工夫去解决那些他们能够在家里做的我的项目。 其次,与去年同期相比,新建开源数据库数量多了很多,例如 5 月份就同比增加了 40%,这阐明当被迫待在家里时,人们随即就开始了分享发明、学习。 经专家预测,到 2025 年可能会有超过 1 亿的用户应用 Github 分享各自的开源我的项目。 其中,来自全世界各地区的人口比重逐步减少,在 2020 年,美国的开源用户奉献比例降落到了 22.7%,而对应的是来自中国和印度的开源用户奉献别离回升到了 9.76% 和 5.2%。 而在 2015 年这个比例还是美国 30.4%、德国 7.3%、英国 5.8%。 预计到了 2025 年,美国会进一步降落到 16.4%,中国和印度会别离减少至 13.3% 和 7.9%,同时南美洲和非洲也会大幅晋升。 绝对应的,从沉闷用户看,除了北美地区显示降落之外,其余地区都处于回升趋势。 阿里开源首个 Serverless 开发者平台最初再通知大家一个好消息,10 月 23 日,阿里巴巴正式发表开源首个 Serverless 开发者平台 Serverless Devs,这也是业内首个反对支流 Serverless 服务/框架的云原生全生命周期治理的平台。Serverless Devs 是一个开源凋谢的 Serverless 开发者平台,致力于为开发者提供弱小的工具链体系。通过该平台,开发者能够一键体验多云 Serverless 产品,极速部署 Serverless 我的项目。 ...

December 11, 2020 · 1 min · jiezi

关于云原生-cloud-native:专访-CNCF-大使张磊让云原生不再是大厂专属

起源|阿里巴巴云原生公众号 近日,GitHub 上的 Go 语言趋势榜呈现了一个新的我的项目 —— KubeVela。 据我的项目官网文档,KubeVela 是“一个简略易用且高度可扩大的利用治理平台与外围引擎,KubeVela 是基于 Kubernetes(K8s)与 Open Application Model(OAM)技术构建的”。 在云原生浪潮席卷寰球的明天,置信大家对 K8s 必定不会生疏,那么 KubeVela 和 OAM 又是什么技术呢?事实上,K8s 的小名尽管曾经路人皆知,但在很多社区网友的反馈中,咱们仿佛看到围绕 K8s 的云原生生态目前只是几家头部大厂的专属。很多一线业务同学都反馈 K8s 太简单了,太难学了,如果没有大厂的投入和技术储备来基于 K8s 构建出场景化的下层平台进去,要落地云原生技术,感觉基本搞不定。 而去年十月,阿里云与微软单干独特开源了 OAM 我的项目,旨在为云原生生态提供一个以利用为核心的、对立的下层形象技术,从而大大降低业务研发同学上手云原生技术的门槛,真正享受到云原生带来的极致麻利与研发效力晋升。而刚刚公布的 KubeVela 我的项目,正是 OAM 模型在 Kubernetes 上的残缺实现。 现在间隔 OAM 我的项目开源正好过来一年, 那么 OAM 我的项目现在有何停顿?本次公布的 KubeVela 我的项目又将为国内的 K8s 生态带来哪些影响?带着这些问题,咱们与 KubeVela 我的项目背地的设计者之一、CNCF 利用交付畛域小组 co-chair、官网大使,来自阿里云的工程师张磊,具体的聊了聊。 采访嘉宾介绍 以下为采访原文: 1. 请给还不理解 OAM 的敌人介绍一下 OAM 和 KubeVela 我的项目吧。<张磊>:Kubernetes 和云原生技术的各种外围概念,间隔咱们业务用户其实是很边远的。理论的落地过程也通知咱们,仅仅有基础设施层形象,离云原生“丝般顺滑”的云端利用治理与交付体验,还是存在着微小的鸿沟。在 Kubernetes 与用户之间,还存在着一层名叫“应用层”形象亟待填补。所以,很多业务用户对“云原生”、Kubernetes 的价值其实广泛不足体感,这个状况不仅在阿里外面存在,在整个社区里也是个让人头疼的问题。只有咱们的业务研发接触到的是“代码”、“利用”而不是“Pod”、“StatefulSet”,那么“让研发专一于写代码”这个美妙、奢侈的云原生欲望,才可能真正实现。 而 Open Application Model(OAM)凋谢利用模型,以及它的 Kubernetes 实现 KubeVela 我的项目,正是阿里云联结微软等云原生社区中坚力量,独特推出的“以解决用户侧诉求”为外围的云原生应用层我的项目。其中,OAM 的设计思维是为包含 Kubernetes 在内的任何云端基础设施提供一个对立、面向最终用户的利用定义模型;而 KubeVela,则是这个对立模型在 Kubernetes 上的残缺实现。对于业务研发人员来讲,KubeVela 能够被认为是云原生社区的 Heroku。而对于平台团队来讲,KubeVela 因为具备极高的可扩展性,则能够被认为是一个“以利用为核心”的、高度可扩大的 Kubernetes 发行版。而 OAM 我的项目,这是 KubeVela 背地的外围 API 范式和插件化能力治理模型。 ...

December 10, 2020 · 2 min · jiezi

关于云原生-cloud-native:2020-云原生生态大会即将开幕15-位重磅嘉宾线上集结

随着云原生技术的迅猛发展,IT 基础设施正在产生微小改革,许多企业都将其架构迁徙至云原生平台,通过云原生技术,使得企业在私有云、公有云和混合云等云环境之中,构建和运行利用变得更加容易,更能充分利用云环境的劣势。 将来推广云原生技术理念,推动和优化云原生生态倒退,一场云原生畛域盛会 —— 「2020 云原生生态大会」行将揭幕! SegmentFault 思否作为本次大会的联结媒体主办方,诚邀各位云原生技术使用者和爱好者,共议共谈云原生! 流动议程 大会工夫是12月16日-12月17日,模式为线上直播,感兴趣的敌人能够点击「报名链接」,即可报名!

December 10, 2020 · 1 min · jiezi

关于云原生-cloud-native:ChaosBlade-x-SkyWalking-微服务高可用实践

起源|阿里巴巴云原生公众号 前言在分布式系统架构下,服务组件繁多且服务间的依赖盘根错节,很难评估单个故障对整个零碎的影响,而且申请链路长,如果监控告警、日志记录等根底服务不欠缺会造成故障响应、故障定位问题难,所以如何构建一个高可用的分布式系统面临着很大挑战。混沌工程就此产生,在可控范畴或环境下通过对系统注入故障,察看零碎行为并发现零碎缺点,以建设对分布式系统因意外条件引发凌乱的能力和信念,继续晋升零碎的稳定性和高可用能力。 混沌工程的施行流程是制订混沌试验打算、定义稳态指标,做出零碎容错行为假如,而后执行混沌试验,查看零碎稳态指标等。也因而混沌试验整个过程须要牢靠的、易于应用且场景丰盛的混沌试验工具注入故障以及残缺的分布式链路追踪和系统监控工具,以便触发应急响应预警计划与疾速地进行故障定位,并察看整个过程零碎的各项数据指标等。本篇文章咱们介绍混沌试验工具(ChaosBlade)和 分布式系统监控工具(SkyWalking),并且联合一个的微服务案例分享一下 ChaosBlade  和 SkyWalking 微服务高可用实际。 工具介绍1. ChaosBladeChaosBlade 是一款遵循混沌工程试验原理,提供丰盛故障场景实现,帮忙分布式系统晋升容错性和可恢复性的混沌工程工具,可实现底层故障的注入,并且在企业上云或往云原生零碎迁徙过程中业务连续性保障,特点是操作简洁、无侵入、扩展性强。ChaosBlade 能够在可控范畴或环境下,通过故障注入,来继续晋升零碎的稳定性和高可用能力。 ChaosBlade 不仅应用简略,而且反对丰盛的试验场景,场景包含: 根底资源:比方 CPU、内存、网络、磁盘、过程等试验场景;Java 利用:比方数据库、缓存、音讯、JVM 自身、微服务等,还能够指定任意类办法注入各种简单的试验场景;C++ 利用:比方指定任意办法或某行代码注入提早、变量和返回值篡改等试验场景;Docker 容器:比方杀容器、容器内 CPU、内存、网络、磁盘、过程等试验场景;云原生平台:比方 Kubernetes 平台节点上 CPU、内存、网络、磁盘、过程试验场景,Pod 网络和 Pod 自身试验场景如杀 Pod,容器的试验场景如上述的 Docker 容器试验场景;ChaosBlade 将场景按畛域实现封装成一个个独自的我的项目,不仅能够使畛域内场景标准化实现,而且十分不便场景程度和垂直扩大,通过遵循混沌试验模型,实现 chaosblade cli 对立调用 。 2. SkyWalkingSkyWalking 是一个开源的 APM 零碎,包含对云本地架构中的分布式系统的监督、跟踪和诊断性能。外围个性如下: 服务、服务实例、端点指标剖析根本原因剖析服务拓扑图剖析服务、服务实例和端点依赖性剖析检测到慢速服务和终结点性能优化分布式跟踪和上下文流传数据库拜访指标。检测慢速数据库拜访语句(包含SQL语句)。报警工具装置及应用ChaosBlade 的装置和应用都很简便,ChaosBlade 各场景通过  chaosblade cli 对立调用,仅须要下载对应的 tar 包,解压后应用 blade 可执行文件来进行混沌试验,下载地址详见:https://github.com/chaosblade-io/chaosblade/releases 。 1. ChaosBlade 装置本次咱们的理论环境是 linux-amd64,下载最新版本 chaosblade-linux-amd64.tar.gz 包,装置步骤如下: ## 下载wget https://chaosblade.oss-cn-hangzhou.aliyuncs.com/agent/github/0.9.0/chaosblade-0.9.0-linux-amd64.tar.gz## 解压 tar -zxf chaosblade-0.9.0-linux-amd64.tar.gz## 设置环境变量 export PATH=$PATH:chaosblade-0.9.0/## 测试 blade -h2. ChaosBlade 应用ChaosBlade 装置实现后,仅须要应用 blade 可执行文件即可创立目前所反对的所有场景的混沌试验。首先应用 blade -h 查看如何应用,抉择子命令之后只须要逐层向下应用 -h 即可看到残缺的应用案例以及各参数的具体解析,上面咱们来演示一下: ...

December 9, 2020 · 4 min · jiezi

关于云原生-cloud-native:2020-阿里云原生实战峰会即将开幕-云原生落地的正确姿势

起源|阿里巴巴云原生公众号 2020 的各种意外,让数字翻新成为应答不确定性最为确定的倒退动能。一方面,数字化成为晋升企业外围竞争力的要害;另一方面,云原生取代传统 IT 成为企业数字化最短门路,减速数字化翻新过程。过来十年,企业通过云计算、大数据、人工智能等新兴技术搭上了数字化的第一趟高速列车,初尝数字化红利。明天,云原生凭借高效、便捷、低成本等个性,最大化开释云计算红利,帮忙企业在数字化的根底上极速翻新,降级为数字创新型企业。 2020 年 12 月 23 日,阿里云将在北京国贸大酒店召开以“原生减速·数创降级”为主题的 “2020 阿里云原生实战峰会”。峰会分为主论坛和在线教育、互动娱乐、企业数字化转型、互联网 CTO 数创先锋营四大分论坛。300 多个行业数字翻新企业先锋,独特探讨云原生落地的现状、挑战与翻新实际,寻找云原生化最佳门路驱动业务增长和翻新。 2020 阿里云原生实战峰会 5 大亮点值得期待主论坛及四大分论坛汇聚 300 位技术管理者,共话云原生定义及利用实际。来自云原生实际先锋企业的技术负责人、资深架构师、技术专家现场分享,议题笼罩在线教育、互动娱乐、数字化转型等不同畛域,为企业落地云原生提供无力参考。公布云原生落地权威报告,深度分析云原生驱动企业转型落地痛点。阿里云与德勤强强联手,以数百家来自不同行业大中小型企业为样本,联合各行业实际案例,以「策略剖析+行业实战」勾画中国企业云原生实际最真群像。云原生技术委员会重磅公布,阿里云产品、服务、人才、生态多维降级。阿里云针对企业理论落地云原生过程中所遇艰难,对产品、服务、生态等方面进行全面焕新降级,为企业提供更加高效、便捷、符合本身业务特色的云原生落地助力。国内首个 CTO 数创先锋营正式开营,构建云原生常识体系,体验场景价值。国内首个以“云原生驱动增长”为外围的技术实战营,联合阿里巴巴本身数字化转型实际和教训积淀,针对实际研发、运维等技术场景,打造系统化云原生常识体系。首发云原生最佳实际案例集,云原生化门路最佳参考。面向数据库、大数据畛域,汇聚 30 个经典的头部客户案例,聚焦互联网、在线教育、游戏、互娱、新批发、能源、交通出行等 10 大重点行业的最佳实际。2020 年初,从天而降的疫情为中国企业按下了数字化降级的减速键,所有企业霎时进入临战状态,残暴的是,很多企业第一次意识到数字化重要性,却没有能力做出及时反馈陷入低谷。作为云原生畛域的引领者和实践者,面对疫情、复产停工以及新基建万亿投资等多重冲击,阿里云义不容辞,号召行业泛滥数字翻新企业先锋,协同生态实现云原生普惠,独特打造抵挡将来不确定性的外围竞争力。 戳链接,立刻报名:https://7e.7-event.cn/7e/seasonfair/app/tevent/index/reg/1741

December 9, 2020 · 1 min · jiezi

关于云原生-cloud-native:工商银行基于-Dubbo-构建金融微服务架构的实践服务发现篇

作者 | 张远征起源|阿里巴巴云原生公众号 导读:Dubbo 作为散布式微服务框架,泛滥公司在实践中基于 Dubbo 进行分布式系统架构。重启开源后,咱们不仅看到 Dubbo 3.0 最新的 Roadmap 公布,而且还看到阿里在本身电商开始推动 Dubbo 和外部 HSF 的交融,并在 双11 上开始应用 Dubbo 3.0。本文是工商银行基于 Dubbo 构建金融微服务架构的分享,次要讲述了服务发现的应答策略和成绩,后续将公布工行大规模服务监控治理的实际,以及从企业角度怎么去对 Dubbo 二次开发等内容。欢送关注。背景及概览工行传统的业务零碎个别都是基于 JEE 的单体架构,面对金融业务线上化及多样化的发展趋势,传统架构曾经无奈满足业务的需要。因而从 2014 年开始,工行抉择了一个业务零碎做服务化的尝试,并验证、评估、比照了过后的几个分布式服务框架,最终抉择了绝对欠缺、并且国内曾经有较多公司落地应用的 Dubbo。与此同时,工行还对 Dubbo 做了企业定制,帮忙这个业务零碎实现了服务化的落地,上线之后也收到了十分好的成果。 2015 年,工行开始扩充服务架构的落地范畴,一方面帮忙传统业务零碎进行架构转型,另一方面也逐步积淀了相似中台的超大规模服务群组,撑持业务零碎疾速服务的组合和复用。随着教训积攒,工行也一直对 Dubbo 进行迭代优化和企业定制,同时围绕服务也逐渐打造了欠缺的服务生态体系。 2019 年,工行的微服务体系也正式降级为工行开放平台外围银行零碎的要害能力之一,助力工行 IT 架构实现真正的分布式转型。 工行的微服务体系组成如下图所示: 基础设施方面,不论是业务零碎的服务节点,还是微服务平台本身的工作节点,都已部署在工行的云平台。服务注册发现方面,除了惯例的服务注册核心外,还配合部署了元数据中心,用于实现服务的按节点注册发现。服务配置方面,通过内部的分布式配置核心,以实现各类动静参数的对立治理和下发。服务监控方面,实现对服务各类运行指标的对立采集和存储,并与企业的监控平台对接。服务跟踪方面,次要是用于实时跟踪服务的整体链路,帮忙业务零碎疾速定位故障点,并精确评估故障的影响范畴。服务网关是为了满足传统业务零碎拜访服务需要,在 Dubbo 服务订阅及 RPC 能力之上,实现了新服务、新版本的主动发现、主动订阅和协定转换能力(HTTP 协定转 RPC 协定),实现 7×24 小时不间断运行。服务治理平台,提供给运维人员和开发测试人员一个一站式的治理、监控、查问的平台,晋升日常服务治理的效率。最大的挑战通过工行多年的落地实际,本文共总结了以下两方面的最大挑战: 性能容量方面,目前线上服务数(即 Dubbo 概念中的服务接口数),已超 2 万,每个注册核心上的提供者条目数(即每个服务的所有提供者累计),已超 70 万。依据评估,将来须要能撑持 10 万级别的服务数,以及每个注册核心 500 万级的提供者条目数。高可用方面,工行的指标是:微服务平台任何节点故障都不能影响线上交易。银行的业务零碎 7×24 小时运行,即便在版本投产工夫窗内,各业务零碎的投产工夫也是互相错开的,平台本身节点要做降级,如何防止对线上交易带来影响,特地是注册核心的本身的版本更新。本文将先从服务发现方面,来分享一下工行的应答策略及功效。 服务发现难点和优化1. 入门 在 Dubbo 中,服务的注册订阅及调用是一个规范范式,服务的提供者初始化时注册服务,服务消费者初始化时订阅服务并获取全量提供者列表。而运行期间,服务提供者发生变化时,服务消费者可获取最新的提供者列表。消费者与提供者之间点对点 RPC 调用,调用过程不经注册核心。 在注册核心的抉择上,工行在 2014 年就抉择了 Zookeeper。Zookeeper 在业界的各类场景下有大规模的利用,并且反对集群化部署,节点间数据一致性通过 CP 模式保障。 ...

December 8, 2020 · 2 min · jiezi

关于云原生-cloud-native:Meet-new-Sentinel-Go-committers

起源|阿里巴巴云原生公众号 Sentinel 是阿里巴巴开源的,面向分布式服务架构的流量管制组件,次要以流量为切入点,从限流、流量整形、熔断降级、零碎自适应爱护等多个维度来帮忙开发者保障微服务的稳定性。Sentinel 承接了阿里巴巴近 10 年的 双11 大促流量的外围场景,例如秒杀、冷启动、音讯削峰填谷、集群流量管制、实时熔断上游不可用服务等,是保障微服务高可用的利器,原生反对 Java/Go/C++ 等多种语言,并且提供 Istio/Envoy 全局流控反对来为 Service Mesh 提供高可用防护的能力。 2020 年年初,Sentinel 社区发表了 Sentinel Go 版本的公布,为 Go 语言的微服务和根底组件提供高可用防护和容错能力的原生反对,标记着 Sentinel 朝着多元化与云原生迈出了新的一步。在这半年的工夫内,社区推出了近 10 个版本,逐渐对齐了外围高可用防护和容错能力,同时也在一直裁减开源生态,与 dubbo-go、蚂蚁 MOSN 等开源社区进行共建。 11 月,Sentinel Go 1.0 GA 版本正式公布,标记着 Go 版本正式进入生产可用阶段。详情请看:《阿里 双11 同款流控降级组件 Sentinel Go 正式 GA,助力云原生服务稳稳稳》。 Meet new Sentinel Go committers可喜的是,社区在 11 月迎来了三位新 committer。接下来,咱们一起来意识下这三位新 committer。 1. 是什么契机让你理解到 sentinel 的? 之前在阿里实习过,对 Sentinel 本来有过一些接触。工作中有一些流控需要,就深刻调研过 Sentinel,缓缓的开始和Sentinel开源负责人宿何一起共创 Sentinel Go 这个我的项目。 ...

December 7, 2020 · 1 min · jiezi

关于云原生-cloud-native:阿里-双11-同款流控降级组件-Sentinel-Go-正式-GA助力云原生服务稳稳稳

作者 | 赵奕豪(宿何)  Sentinel 开源我的项目负责人起源|阿里巴巴云原生公众号 前言微服务的稳定性始终是开发者十分关注的话题。随着业务从单体架构向分布式架构演进以及部署形式的变动,服务之间的依赖关系变得越来越简单,业务零碎也面临着微小的高可用挑战。 在生产环境中大家可能遇到过各种不稳固的状况,比方: 大促时霎时洪峰流量导致系统超出最大负载,load 飙高,零碎解体导致用户无奈下单。“黑马”热点商品击穿缓存,DB 被打垮,挤占失常流量。调用端被不稳固第三方服务拖垮,线程池被占满,调用沉积,导致整个调用链路卡死。这些不稳固的场景可能会导致严重后果,但很多时候咱们又容易漠视这些与流量/依赖相干的高可用防护。大家可能想问:如何预防这些不稳固因素带来的影响?如何针对流量进行高可用的防护?如何保障服务“稳如磐石”?这时候咱们就要请出阿里双十一起款的高可用防护中间件 —— Sentinel。在往年刚刚过来的天猫 双11 大促中,Sentinel 完满地保障了阿里成千上万服务 双11 峰值流量的稳定性,同时 Sentinel Go 版本也在近期正式发表 GA。上面咱们来一起理解下 Sentinel Go 的外围场景以及社区在云原生方面的摸索。 Sentinel 介绍Sentinel 是阿里巴巴开源的,面向分布式服务架构的流量管制组件,次要以流量为切入点,从限流、流量整形、熔断降级、零碎自适应爱护等多个维度来帮忙开发者保障微服务的稳定性。Sentinel 承接了阿里巴巴近 10 年的 双11 大促流量的外围场景,例如秒杀、冷启动、音讯削峰填谷、集群流量管制、实时熔断上游不可用服务等,是保障微服务高可用的利器,原生反对 Java/Go/C++ 等多种语言,并且提供 Istio/Envoy 全局流控反对来为 Service Mesh 提供高可用防护的能力。 今年年初,Sentinel 社区发表了 Sentinel Go 版本的公布,为 Go 语言的微服务和根底组件提供高可用防护和容错能力的原生反对,标记着 Sentinel 朝着多元化与云原生迈出了新的一步。在这半年的工夫内,社区推出了近 10 个版本,逐渐对齐了外围高可用防护和容错能力,同时也在一直裁减开源生态,与 dubbo-go、蚂蚁 MOSN 等开源社区进行共建。 就在近期,Sentinel Go 1.0 GA 版本正式公布,标记着 Go 版本正式进入生产可用阶段。Sentinel Go 1.0 版本对齐了 Java 版本外围的高可用防护和容错能力,包含限流、流量整形、并发管制、熔断降级、零碎自适应爱护、热点防护等个性。同时 Go 版本已笼罩支流开源生态,提供了 Gin、gRPC、go-micro、dubbo-go 等罕用微服务框架的适配,并提供了 etcd、Nacos、Consul 等动静数据源扩大反对。Sentinel Go 也在朝着云原生的方向一直演进,1.0 版本中也进行了一些云原生方面的摸索,包含 Kubernetes CRD data-source, Kubernetes HPA 等。对于 Sentinel Go 版本而言,咱们冀望的流控场景并不局限于微服务利用自身。云原生根底组件中 Go 语言生态占比拟高,而这些云原生组件很多时候又不足细粒度、自适应的爱护与容错机制,这时候就能够联合组件的一些扩大机制,利用 Sentinel Go 来爱护本身的稳定性。Sentinel 底层通过高性能的滑动窗口进行秒级调用指标统计,联合 token bucket, leaky bucket 和自适应流控算法来透出外围的高可用防护能力。 ...

December 7, 2020 · 3 min · jiezi

关于云原生-cloud-native:更高更快更稳看阿里巴巴如何修炼容器服务内外功

作者 | 守辰、志敏起源|阿里巴巴云原生公众号 11 月 11 日零点刚过 26 秒,阿里云再一次抗住了寰球最大的流量洪峰。往年 双11 是阿里经济体外围零碎全面云原生化的一年,相比去年外围零碎的上云,云原生化不仅让阿里享受到了云计算技术老本优化的红利,也让阿里的业务最大化取得云的弹性、效率和稳定性等价值。 为应答 双11,阿里云原生面临怎么的挑战?为了反对阿里这样大规模业务的云原生化,阿里云原生面临怎么样的挑战呢? 1. 集群多、规模大基于对业务稳定性和零碎性能等方面的综合思考,大型企业往往须要将业务集群部署到多个地区,在这样的场景下,撑持多集群部署的容器服务能力十分必要。同时,为了简化多集群治理的复杂度,以及为不能实现跨集群服务发现的业务提供反对,还须要关注容器服务中单个集群对大规模节点的治理能力。另外,大型企业的业务简单多样,因而一个集群内往往须要部署丰盛的组件,不仅包含次要的 Master 组件, 还须要部署业务方定制的 Operator 等。集群多、规模大,再加上单个集群内组件泛滥, 容器服务的性能、可扩展性、可运维性都面临着很大的挑战。 2. 变动快、难预期市场瞬息万变,企业,特地是互联网企业,如果仅凭借教训、依附布局来应答市场变动,越来越难以撑持业务倒退,往往须要企业疾速地进行业务迭代、部署调整以应答市场的变动。这对为业务提供利用交付疾速反对、弹性伸缩性能和疾速响应撑持的容器服务提出了很大的要求。 3. 变更多、危险大企业 IT 零碎的云原生化过程不仅要面临一次性的云迁徙和云原生革新老本,还将继续应答因为业务迭代和基础设施变更、人员流动带来的危险。而业务的迭代、基础设施的变更会无奈防止地为零碎引入缺点,重大时甚至造成故障,影响业务失常运行。最初,这些危险都可能会随着人员的流动进一步加剧。 阿里云容器服务大规模实际1. 高扩展性为了进步容器服务的可扩展性,须要自底向上、联动利用和服务一起优化。 1)接口最小化针对下层 PaaS,容器服务依靠 OAM(Open Application Model) 和 OpenKruise Workload 提供了丰盛的利用交付能力形象。对于 PaaS 层来说,只须要读取汇总的利用部署统计数值即可,极大缩小了下层零碎须要批量查问 pod、event 等信息的工作量,进而减小了对容器服务的管控压力;同时,通过把数量多、占用空间大的 pod 及 events 信息转存到数据库中, 并依据数据库中的内容提供一个对立的、可内嵌的部署状态查看和诊断页面的形式,能够使 PaaS 层防止间接拜访容器服务来实现相干性能。 2)分化而治之“分化而治之”是指要对业务做出正当的划分,防止因为所有业务和利用都集中在少数几个命名空间中,导致容器服务管控(控制器和 APIServer)在查问命名空间下所有资源时产生过大耗费的状况。目前在阿里外部最宽泛的实际形式是应用“利用名”做为命名空间。一方面利用是业务交付的根本单位,且不受组织调整的影响;另一方面,容器服务的组件以及业务本人的 Operator,在解决时往往会 list 命名空间下的资源,而命名空间默认在控制器和 APIServer 中都实现有索引,如果应用利用作为命名空间能够利用默认的索引减速查问操作。 3)苦修内外功对于容器服务的外围管控,须要扎实的内功做根底。针对大规模的应用场景,阿里云的容器服务进行了大量的组件优化,比方通过索引、Watch 书签等的形式,防止间接穿透 APIServer 拜访底层存储 ETCD,并通过优化 ETCD 闲暇页面调配算法、拆散 event 和 lease 存储至独立 ETCD 的办法,晋升 ETCD 自身的存储能力,其中不少曾经反馈给了社区,极大升高了 ETCD 解决读申请的压力。 详情可查看:https://4m.cn/JsXsU。 ...

December 4, 2020 · 2 min · jiezi

关于云原生-cloud-native:深入解读KubeVela-与-PaaS-有何不同

作者 | 邓洪超  阿里云高级技术专家 起源|阿里巴巴云原生公众号 在 KubeVela 我的项目公布当前,很多国内外的社区同学们都会问到一个相似的问题:KubeVela 的体验真的十分棒,能够说是 Kubernetes 上的 Heroku 了。这么看来, KubeVela 跟 Heroku 这样的 PaaS 产品到底是不是一类我的项目呢? 明天,咱们就专门来聊一个这个话题:KubeVela 与 PaaS 有何不同? 备注:本文所提到的 PaaS,既包含 Heroku 这样的经典 PaaS 产品,也包含各种各样的基于 Kubernetes 的“云原生” PaaS。它们尽管底层实现不同,然而对用户提供的应用接口和体验是类似的。但 OpenShift 是一个例外,作为一个比 Kubernetes 自身还简单的我的项目,OpenShift 不属于本文所探讨的简略易用、面向用户的 PaaS 之列,而是一个纯粹的 Kubernetes 发行版。首先,咱们先说论断:KubeVela 可能为用户带来十分靠近 PaaS 的体验,但 KubeVela 并不是 PaaS。 为什么说 KubeVela 不是 PaaS?大多数 PaaS 都能提供残缺的利用生命周期治理性能,同时也十分关注提供简略敌对的用户体验,以及对研发效力的晋升。在这些点上,KubeVela 跟 PaaS 的指标和提供的用户体验,是高度一致的。但如果你去钻研 KubeVela 的实现细节,就不难发现 KubeVela 的整体设计与实现其实与各类 PaaS 我的项目的差异是十分大的。如果从用户视角来看,这些区别则会间接反馈在整个我的项目的“可扩展性”上。 进一步来说,PaaS 的用户体验虽好,但却往往是不可扩大的。咱们能够间接拿比拟新的 Kubernetes PaaS,比方 Rancher Rio 我的项目来看。这个我的项目提供了很好的利用部署体验,比方 Rio run 来让你疾速部署一个容器化利用、主动调配域名和拜访规定等等。然而,如果咱们想让 Rio 反对更多的能力以满足不同的用户诉求呢? ...

December 3, 2020 · 2 min · jiezi

关于云原生-cloud-native:云原生上云后的聚石塔是如何应对-双11-下大规模应用挑战的

起源|阿里巴巴云原生公众号主笔 | 在德(阿里巴巴技术专家)、佳旭(阿里巴巴技术专家)联结作者 | 杭羽、照前、岭峰、大猿 云原生被认为是云计算的重要发展趋势,并且曾经成为数字新基建必不可少的一个组成部分。每年的阿里巴巴 双11 都是考验各种前沿技术的最佳“实战场”,而往年云原生技术在 双11 中的大规模利用,充分证明了云原生技术的能源与前景。 本文会零碎解说聚石塔在 2019 年 7 月份以阿里云容器服务为基础设施,进行云原生实际的摸索和教训、带来的价值与扭转,及其在 双11 中的利用,心愿对云原生化建立能够借鉴应用的案例和样板。 聚石塔业务背景与介绍聚石塔最早上线于 2012 年,是阿里团体为应答电商治理和信息化挑战,帮忙商家疾速解决信息化建设与治理的瓶颈打造的一款凋谢电商云工作平台。它的价值在于汇聚了整个阿里系的各方资源优势,包含阿里团体下各个子公司的平台资源,如淘宝、天猫、阿里云等,通过资源共享与数据互通来发明有限的商业价值。 依靠于聚石塔,各种业务类型(如 ERP、CRM、WMS 等业务)的服务商为淘宝、天猫等淘系的商家提供服务,服务商须要遵循聚石塔平台的公布规定、数据安全、稳定性建设等要求。这种关系决定了聚石塔平台的技术和架构,更间接决定服务商的技术演进方向和先进性。 聚石塔业务痛点聚石塔承接的业务大类能够分为两个局部: 传统电商链路中,订单服务链路上的零碎:比方 ERP 零碎,CRM 零碎,WMS 零碎。电商行业中间接面向客户的小程序场景,比方手淘与千牛客户端的小程序业务。综合聚石塔的的业务类型,存在如下的业务痛点: 1. 标准化和稳定性问题对于订单服务链路的零碎而言,稳定性永远是最后面的“1”,一个零碎抖动可能就会导致订单履约链路中断甚至造成资损以及客诉。稳定性和标准化是不分家的,置信大家对此对有强烈的感触。而此类零碎的开发语言不对立,有 Java、PHP、.Net 等;技术栈简单,波及 Windows 零碎、Linux 零碎、单体利用、分布式应用,堪称形形色色。因而须要一套跨语言、跨平台的通用 PaaS 平台来解决利用的标准化、运维的标准化问题,并提供通用的链路问题观测伎俩,来帮忙服务商和平台标准公布运维操作,发现链路问题,打消稳定性隐患。 2. 突发流量下的弹性问题对于利用小程序的业务零碎而言,最大的挑战就是须要应答突发流量以及流量的不确定性。尤其在 双11 期间,手淘端各类小程序插件会面临比平时多十倍甚至百倍的流量。面对这种不确定性的流量洪峰,聚石塔须要一套能够实现流量预估、流量观测、流量管制以及规范利用疾速扩缩容的 PaaS 平台。对于订单服务链路的零碎而言,弹性能力也是关键点,在原来的架构下扩容须要经验创立虚拟机资源、部署并配置利用等诸多环节,服务商广泛感觉流程长、效率低。以上咱们都总结为弹性能力的挑战。 3. 效率和老本的问题聚石塔在云原生之前的利用部署根本都是基于 VM 间接部署过程,这种形式不足过程间的资源隔离。同时当 ECS 数量变多,资源的对立治理就变得非常复杂,很容易造成资源争抢导致利用稳定性问题以及资源节约导致的多余老本开销。同时,在传统的 VM 部署模式中,利用的扩缩容不仅仅须要解决利用的代码包启动,还须要解决利用的端口抵触,利用所关联的存储资源分配,利用流量在 SLB 的挂载和摘除,利用配置的散发以及长久化,整个部署过程会变得十分耗时且容易出错。 聚石塔云原生落地计划针对上述的业务痛点,聚石塔开始摸索技术演进方向以及系统性的解决方案,以便为淘系服务商带来服务上质的晋升。云原生带来的技术红利,比方应用环境标准化、DevOps 思维、弹性伸缩、跨语言的服务化能力以及运维自动化等,都不仅能够帮忙聚石塔的服务商解决现存架构中的稳定性和老本问题,同时也能够帮忙咱们疏导服务商实现技术架构的降级。 因而,聚石塔进行了从新定位,被动拥抱云原生。整体来看,目前的聚石塔云原生技术底座基于阿里云容器服务,平台指标是赋能服务商利用架构的稳定性降级,打造基于云原生的、面向业务链接的 DevOps PaaS 平台。 那么,为什么聚石塔会抉择阿里云容器服务作为云原生基础设施呢? 阿里云容器服务 ACK(Alibaba Cloud Container Service for Kubernetes)是寰球首批通过 Kubernetes 一致性认证的服务平台,提供高性能的容器利用治理服务,反对企业级 Kubernetes 容器化利用的生命周期治理。作为国内云计算容器平台的领军者,从 2015 年上线后,一路随同并撑持 双11 倒退。 ...

December 2, 2020 · 3 min · jiezi

关于云原生-cloud-native:利用-Arthas-解决启动-StandbyNameNode-加载-EditLog-慢的问题

作者 | yhf20071 【Arthas 官网社区正在举办征文活动,加入即有奖品拿~点击投稿】 公司新搭 HDFS 集群,namenode做ha,然而在启动 StandbyNamenode 节点的时候呈现奇怪的景象:空集群加载 Editlog 很慢,每次重启简直耗时都在二三十分钟 为了不便大家了解,大抵说下 StandbyNamenode(以下简称 SNN)启动过程: SNN 启动时,如果本地没有 FSImage会去 ANN(ActiveNamenode)拉取 FSImage如果本地有 FSImage,则会依据 transactionId 去 JournalNode 拉取 gap 的 editlog,在本地做合并问题就出在第 2 步,在从 JournalNode 拉取 EditLog 过程中呈现固定 15s 提早。一般来说,空集群简直没有操作, editlog 不会太大,不应该呈现每次从 JournalNode 拉取 EditLog 都消耗 15s 的工夫,日志如下(为了不便察看截取局部日志): 2020-11-04 18:27:27,577 INFO namenode.RedundantEditLogInputStream (RedundantEditLogInputStream.java:nextOp(177)) - Fast-forwarding stream 'http://cbdp-online1.sdns.fin ancial.cloud:8480/getJournal?jid=hdfs-ha&segmentTxId=213656&storageInfo=-64%3A272699407%3A1603893889358%3ACID-aa8ec1b5-a501-4195-9299-e14abefbdc11&inProgressOk=true' to transaction ID 184269 2020-11-04 18:27:42,582 INFO namenode.FSEditLogLoader (FSEditLogLoader.java:loadEditRecords(289)) - replaying edit log: 1/44 transactions completed. (2%) 2020-11-04 18:27:42,583 INFO namenode.FSImage (FSEditLogLoader.java:loadFSEdits(162)) - Edits file http://cbdp-online1.sdns.financial.cloud:8480/getJournal?jid=hdfs-ha &segmentTxId=213656&storageInfo=-64%3A272699407%3A1603893889358%3ACID-aa8ec1b5-a501-4195-9299-e14abefbdc11&inProgressOk=true, http://cbdp-online2.sdns.financial.cloud:8 480/getJournal?jid=hdfs-ha&segmentTxId=213656&storageInfo=-64%3A272699407%3A1603893889358%3ACID-aa8ec1b5-a501-4195-9299-e14abefbdc11&inProgressOk=true, http://cbdp-onli ne3.sdns.financial.cloud:8480/getJournal?jid=hdfs-ha&segmentTxId=213656&storageInfo=-64%3A272699407%3A1603893889358%3ACID-aa8ec1b5-a501-4195-9299-e14abefbdc11&inProgres sOk=true of size 5981 edits # 44 loaded in 15 seconds......2020-11-04 18:27:42,583 INFO namenode.RedundantEditLogInputStream (RedundantEditLogInputStream.java:nextOp(177)) - Fast-forwarding stream 'http://cbdp-online1.sdns.financial.cloud:8480/getJournal?jid=hdfs-ha&;segmentTxId=213700&storageInfo=-64%3A272699407%3A1603893889358%3ACID-aa8ec1b5-a501-4195-9299-e14abefbdc11&inProgressOk=true' to transaction ID 184269 2020-11-04 18:27:57,588 INFO namenode.FSEditLogLoader (FSEditLogLoader.java:loadEditRecords(289)) - replaying edit log: 1/53 transactions completed. (2%) 2020-11-04 18:27:57,589 INFO namenode.FSImage (FSEditLogLoader.java:loadFSEdits(162)) - Edits file http://cbdp-online1.sdns.financial.cloud:8480/getJournal?jid=hdfs-ha&;segmentTxId=213700&storageInfo=-64%3A272699407%3A1603893889358%3ACID-aa8ec1b5-a501-4195-9299-e14abefbdc11&inProgressOk=true, http://cbdp-online2.sdns.financial.cloud:8480/getJournal?jid=hdfs-ha&;segmentTxId=213700&storageInfo=-64%3A272699407%3A1603893889358%3ACID-aa8ec1b5-a501-4195-9299-e14abefbdc11&inProgressOk=true, http://cbdp-online3.sdns.financial.cloud:8480/getJournal?jid=hdfs-ha&;segmentTxId=213700&storageInfo=-64%3A272699407%3A1603893889358%3ACID-aa8ec1b5-a501-4195-9299-e14abefbdc11&inProgressOk=true of size 7088 edits # 53 loaded in 15 seconds1.首先通过日志初步定位代码,粗略定位耗时办法trace org.apache.hadoop.hdfs.server.namenode.FSEditLogLoader loadFSEdits2.下面的后果只能确定大抵耗时办法块,不能精确定位理论耗时办法,如果要精确定位,须要一层一层开展,其中还波及回调函数、native 函数;为了能够更不便的定位代码,咱们先执行 profiler start,察看下耗时函数调用profiler start/stop ...

November 30, 2020 · 2 min · jiezi

关于云原生-cloud-native:Arthas-实践生产环境排查-CPU-飚高问题

作者 | 李昊(能够养肥) 【Arthas 官网社区正在举办征文活动,加入即有奖品拿~点击投稿】 生产环境 CPU 告警: 13:40 收到咱们的生产环境服务器绿版 CUP 超负载告警告诉。 此时心里只有一个想法,重启大法好,马上登录服务器,执行 top 发现过程 30247 和 28337 占用 CPU 为 200 多和100 多根本占用了 4 核的 3 核,整个过程大略用时 30 秒,保护群仍然很平静,经营的电话也没打过去,这时候我判定,这次问题应该影响面很小,用户可能也临时没有发现,好吧,还有工夫做排查。 Arthas排查过程:开启 Arthas 工具找到对应的 30247 运单模块和 28337 领取模块,抉择运单模块进入:java -jar arthas-boot.jar 执行 dashboard 命令,线程 35 和 12042 不失常 CUP 占用 49%:dashboard 执行 thread 35  thread 12042 定位代码行:thread 35thread 12042 查看代码,业务需要为生成一个至多蕴含 2 个数字的随机字符串,咱们应用的对立的工具类办法,该办法中先通过 UUID.randomUUID() 随机出一个 10 位的字符池,而后再从这个字符池中随机须要位数的字符串,如果随机进去的 10 位字符池中都是字母,则二次随机时候就会呈现死循环,问题代码如下:public static String getRandomStr(boolean numberFlag, int length) { String retStr = ""; String strTable = numberFlag ? UUID.randomUUID().toString().replaceAll("-", "").substring(0, 10) : "1234567890abcdefghijkmnpqrstuvwxyz"; int len = strTable.length(); boolean bDone = true; do { retStr = ""; int count = 0; for (int i = 0; i < length; i++) { double dblR = Math.random() * len; int intR = (int) Math.floor(dblR); char c = strTable.charAt(intR); if (('0' <= c) && (c <= '9')) { count++; } retStr += strTable.charAt(intR); } if (count >= 2) { bDone = false; } } while (bDone); return retStr; }线下模仿不到二万次 UUID.randomUUID() 前十位会呈现一次全字母的状况。 ...

November 30, 2020 · 2 min · jiezi

关于云原生-cloud-native:RocketMQ-很慢引出了一个未解之谜

作者 | 秋天 【Arthas 官网社区正在举办征文活动,加入即有奖品拿~点击投稿】 前段时间发现,在应用 RockerMQ console 时,查问音讯的时候呈现很慢,查问耗时大于 10 秒,少则 5、6 秒,多则 14+ 秒。 如下图: 这到底是为什么?查问音讯为啥会呈现这么大的耗时? 以后应用的开发环境:操作系统是 Windows10,JDK8,RocketMQ 为 4.5.2。 在其它机器上则没有此问题,也在本机器上的虚拟机 VMware 上装置的 Linux 部署了 RocketMQ 和 console,并且验证是没问题的。 那么到底我的机器是怎么了??? 因为以后是接口的耗时问题,咱们并不知道耗时次要在哪个中央,所以应用 Arthas 来跟踪下调用链的耗时。 应用 trace 命令: trace 命令办法外部调用门路,并输入办法门路上的每个节点上耗时。trace 命令能被动搜寻 class-pattern/method-pattern 对应的办法调用门路,渲染和统计整个调用链路上的所有性能开销和追踪调用链路。 trace org.apache.rocketmq.console.service.impl.MessageServiceImpl queryMessageByTopic 从以后调用门路失去次要耗时在于:DefaultMQPullConsumer 结构器初始化 + DefaultMQPullConsumer 启动耗时。那么接下来咱们持续往外部跟进。 此时咱们关注下 DefaultMQPullConsumer 结构器初始化: trace org.apache.rocketmq.client.consumer.DefaultMQPullConsumer <init> 从结构器初始化入口看,耗时并不大。 那么接下来再看下 DefaultMQPullConsumer 的启动办法: [E] 开启正则表达式匹配,默认为通配符匹配trace -E org.apache.rocketmq.client.consumer.DefaultMQPullConsumer start trace -E org.apache.rocketmq.client.consumer.DefaultMQPullConsumer <init>|start ...

November 30, 2020 · 2 min · jiezi

关于云原生-cloud-native:Aliyun-Java-Initializr-和-Spring-官方的到底有什么区别

起源 | 阿里巴巴云原生公众号 2020 年初,阿里云推出了本人的 Java 工程脚手架工具 -- Aliyun Java Initializr。置信初看到这个产品时,同学们都会有类似的疑难:“这货色跟 Spring 官网的脚手架不是一回事么?”在没有对 Aliyun Java Initializr 进行具体理解前,有这样的想法和疑难是很失常的,置信你亲自用了之后,肯定会收回“真香”的感叹。 因为除了根底的语言和网络劣势外,它的示例代码、多种获取形式、组件的丰盛度、基于浏览器的收费开发运行环境,都会让你骑虎难下。 试用地址:https://start.aliyun.com/bootstrap.html 1. 提供 Ready-to-use 的示例代码Aliyun Java Initializr 的一个重要特色就是能提供简略易懂的示例代码。示例代码分为两个层级的,一个是组件级的,另外一个是架构级的。其中,组件级的示例代码向用户展现如何配置和应用对应的组件;而架构级示例代码则做到了 Ready-To-Use 的水平,用户能够在架构示例的根底上填充本人的业务逻辑。 2. 反对多种形式来获取生成的内容Aliyun Java Initializr 反对通过网页下载、git clone、IDEA 插件、Spring CLI 等形式来获取生成的内容。其中,git clone 形式是 Aliyun Java Initializr 独家反对的,用户应用此办法能够省去下载、寻找、解压、建仓的麻烦,非常不便。将来,initializr 还能够间接将生成的代码同步到 Codeup、码云等代码托管平台,进一步晋升开发者应用的便利性。 3. 一键运行,在浏览器中运行和测试代码Aliyun Java Initializr 提供了一套基于浏览器的 (命令行 + 编辑器) 的开发运行环境 -- 入手实验室。在这里,你能够间接将生成的代码输入实验室环境中,仅通过浏览器就能够实现开发、测试工作。全程收费。 4. 更加丰盛的组件反对Aliyun Java Initializr 不仅继承了 Spring 官网反对的各种组件,还为国内用户减少了很多罕用的组件。无论是 Spring Cloud Alibaba 全家桶(包含 RocketMQ、Dubbo、Nacos、Sentinel、Seata 等),还是各种 web 开发的常见框架,在这里你都能够迅速的找到。 ...

November 30, 2020 · 1 min · jiezi

关于云原生-cloud-native:什么是低代码LowCode

起源 | 阿里巴巴云原生公众号 作者 | 楚衡 导读:什么是低代码?咱们为什么须要低代码?低代码会让程序员就业吗?本文总结了低代码畛域的基本概念、外围价值与行业现状,带你全面理解低代码。前言如果抉择用一个关键词来代表行将过来的 2020 年,我置信所有人都会认同是“新冠”。疫情来得太快就像龙卷风,短短数月就阻断了全世界范畴内有数人与人之间的物理连贯。但好在,咱们曾经全面迈入互联网时代: N95 口罩再厚,也阻挡不了信息比特流的顺畅流通(宅男:B 站仍然香)。居家隔离再久,也障碍不了钉钉音讯的准时送达(社畜:工作仍然苦)。逍遥子在 9 月份的云栖大会上说:“新技术代表的新生产力,肯定是咱们全速战败疫情、创始将来最好的原动力。” 那么在后疫情时代,到底须要什么样的新技术,能力真正解放 IT 生产力,减速社会数字化转型,Make The World Great Again?我认为是低代码(Low-Code)。 基于经典的可视化和模型驱动理念,联合最新的云原生与多端体验技术,低代码可能在适合的业务场景下实现大幅度的提效降本,为业余开发者提供了一种全新的高生产力开发范式(Paradigm Shift)。另一方面,低代码还能让不懂代码的业务人员成为所谓的平民开发者(Citizen Developer),补救日益扩充的专业人才缺口,同时促成业务与技术深度合作的终极麻利状态(BizDevOps)。本文将重点介绍低代码相干背景常识,包含低代码的定义与意义、相干概念、行业倒退等,冀望能帮忙大家更好地意识与了解低代码这个新兴畛域。 什么是低代码?“Low-Code” 是什么?如果你是第一次据说,没准也会跟我当年从老板口中听到这个词后的心田戏一样:啥?“Low-Code”?“Code” 是指代码我晓得,但这个“Low”字是啥意思?不会是老板发现我最近赶工写的代码很丑很 “Low” 吧... 想多了,老板怎么可能亲自 review 代码呢。那难道是指,“Low-level programming”里的“Low”?老板终于发现让我等编程奇才终日堆 Java 业务代码太节约,要派我去闭关写一个高性能 C 语言网络库... 显然也不是,老板哪能有这技术情怀呢。那到底是什么意思?作为一名搜商比情商还高的程序员,能问 Google 的绝不会问老板。于是我一顿操作后,不假思索地点开了第一条搜寻后果。果不其然,这是一条充斥自在芬芳只有翻墙能力闻到的 Wikipedia 词条:Low-code development platform。 1. Wikipedia 定义 从 Wiki 的这段定义中,咱们能够提炼出几个要害信息: 低代码开发平台(LCDP)自身也是一种软件,它为开发者提供了一个创立应用软件的开发环境。看到“开发环境”几个字是不是很亲切?对于程序员而言,低代码开发平台的性质与 IDEA、VS 等代码 IDE(集成开发环境)简直一样,都是服务于开发者的生产力工具。与传统代码 IDE 不同的是,低代码开发平台提供的是更高维和易用的可视化 IDE。大多数状况下,开发者并不需要应用传统的手写代码形式进行编程,而是能够通过图形化拖拽、参数配置等更高效的形式实现开发工作。2. Forrester 定义顺着 Wiki 的形容还能发现,原来 “Low-Code” 一词早在 2014 年就由 Forrester 提出了,它对低代码开发平台的始祖级定义是这样的: ...

November 30, 2020 · 3 min · jiezi

关于云原生-cloud-native:云原生实践政务安全大脑云端密码应用…腾讯在湾区创见大会发布了哪些重点

11月28日-29日,首届“湾区创见·2020网络安全大会”在深圳召开。作为目前华南地区规格最高、规模最大的网络安全大会,本届大会以“新基建,新平安”为主题,聚焦探讨新基建背景下,5G、人工智能、云计算、大数据等前沿科技利用带来的全新平安命题。 腾讯作为本次大会的协办方,主导承办了私有云平安专场,并在大会上正式公布了腾讯政务平安大脑解决方案。同时,为建设更加巩固的云上平安防线,腾讯平安云鼎实验室携手深圳市商用明码行业协会成立了“鼎云明码利用联结实验室”,为应答产业数字降级过程中的云上平安挑战提供了新思路。 腾讯副总裁马斌在大会现场演讲 后疫情时代,在减速新基建布局的同时,更要围绕数字经济的新载体做好残缺且前置的平安防护,从而为产业数字化降级打消“后顾之忧”。腾讯副总裁马斌在大会主论坛上示意“在不断完善、迭代现有云平安防护体系的同时,咱们也须要适应云计算‘原生’的发展趋势,从新的角度去看平安问题。”腾讯将继续凋谢平安能力,分享在多年实际中积攒的防护教训,助力推动平安普惠,护航数字经济巩固倒退。 凋谢“腾讯级”云原生平安建设能力护航数字政府和明码利用全新降级云计算无疑是以后撑持产业数字降级的最大载体,并且曾经成为平安攻防的“主战场”。依靠在政务云之上的数字政府建设,更是面临严厉的平安挑战。腾讯平安《2019寰球高级持续性威逼(APT)》指出:“政府是APT攻打的重灾区。从行业散布上看,受攻打最多的是政府,占比17%以上。”然而,传统平安计划大部分依附产品堆砌,普遍存在进攻生效、响应迟缓、联动性差等问题。在此背景下,数字政府的平安解决方案迫切需要降级。 而具备近20年来的平安教训和技术积攒的腾讯,在这片“新战场”上开释出了新能量。6月24起,第127届广交会首次在“云端”举办,两万六千多家企业“云上”参展,间断10天24小时不间断地直播。腾讯平安依靠私有云为“云上广交会”提供了平安重保服务,累计拦挡超百万次各类平安攻打、图片/文本/音频危险检测数近十亿,最终确保0平安危险,0安全事故。 基于云上广交会的重保教训和其它政务平安建设的实际,腾讯平安构建了一套云原生的政务平安大脑解决方案,并在本次湾区创见·2020网络安全大会的云平安分论坛上正式对外公布。整体计划由平安大数据平台、基于零信赖的身份平安、“云网边端”平面防护、利用生命周期平安、数据生命周期平安、AI平安管控核心等局部组成。 腾讯政务平安大脑依靠新一代威逼情报、人工智能、大数据技术、零信赖等技术,提出“一个体系、两个晋升、三项智能”的平安建设理念。“一个体系”是指构建新一代数字政府智能化平安体系;“两个晋升”是指解决政府客户的两个重点问题,包含平战结合、平安治理闭环能力晋升;“三项智能”包含:针对政府云、网、数、利用等外围资产,提供一体化破绽、威逼的智能感知能力;面向一线运维人员,提供智能化运维能力,从而加重平安运维工作量;面向指挥人员,提供智能决策能力,帮忙掌控全局、精准决策。 腾讯平安公布腾讯政务平安大脑 而为了响应相干部门一直出台的《网络安全法》、《明码法》等一系列法律法规中对国密算法提出的新要求,帮忙政企单位解决明码利用实际中的“难做、难用、难管”的三大难题。腾讯平安云鼎实验室在本次大会上携手深圳市商用明码行业协会成立了鼎云明码利用联结实验室。单方将聚焦云端明码利用的全新场景,围绕明码利用的行业实际、标准化与翻新钻研、产品研发、靶场实训平台搭建、前沿技术摸索等方面开展深度单干,进一步凋谢腾讯的平安能力,致力于帮忙宽广企业解决大规模业务零碎合规明码技术利用层面的难题。 鼎云明码利用联结实验室揭牌典礼 适应云原生平安趋势腾讯助力守好数字降级生命线公开数据显示,预计到2021年中国云平安服务市场规模将达到115.7亿元,将来三年年均增长率为45.2%。面对后劲微小的市场和更加谋求高效的云架构需要,本届大会汇集了来自行业钻研机构、头部平安企业和明码测评机构的多位专家,围绕“云原生”平安、政务平安和明码利用等行业前沿话题进行了重点探讨。 沙利文公司及头豹研究院高级分析师李庆在现场联合市场、技术等方面为大家带来了云平安将来几年发展趋势的探讨;绿盟科技翻新核心总监刘文懋、青藤云平安创始人兼CEO张福等头部平安厂商的专家基于本身实际分享了对于“云原生平安”的了解。而作为测评机构的代表,鼎铉平安测评部副部长邹超针对明码在云端的利用进行了解读。 因为“云原生平安”具备开箱即用、弹性、自适应、全生命周期防护等显著劣势,对于大多数企业来说,上云曾经成为了应答数字时代平安问题的“最优解”。目前,腾讯平安已搭建了蕴含平安治理、数据安全、利用平安、计算平安、网络安全等五个层面的齐备云原生平安防护体系。截止目前,腾讯曾经获得了1500多项云平安技术专利,位列行业第一。往年上半年,腾讯在云根底平安和云业务平安上的能力,取得了Gartner、Forrester、IDC、Sullivan等国内权威平安机构的认可。腾讯云还取得了德国、韩国、新加坡、美国、欧盟五个国家和地区的最高平安资质认证,守护腾讯云超过百万的客户。 将来,腾讯平安将持续深入在平安技术研发和产品利用上的投入与能力开释,以低成本、高易用、高平安的产品和服务,助力湾区及中国产业倒退,守护好数字化改革的生命线。

November 30, 2020 · 1 min · jiezi

关于云原生-cloud-native:2020双11Dubbo30-在考拉的超大规模实践

很多开发者始终以来好奇:阿里本人有没有在用Dubbo,会不会用Dubbo?在刚刚完结的双11,咱们理解到阿里云往年提出了“三位一体”的理念,行将“自研技术”、“开源我的项目”、“商业产品”造成对立的技术体系,最大化技术的价值。终于,在2020的双11,阿里巴巴经济体也用上了Dubbo!本文是阿里双十一在考拉大规模落地 Dubbo3.0 的技术分享,零碎介绍了 Dubbo3.0 在性能、稳定性上对考拉业务的撑持。 覃柳杰(花名:未宇)Github ID: qinliujie,Apache Dubbo PMC;阿里巴巴微服务框架 HSF 负责人,负责 HSF 研发及 Dubbo 在阿里的落地。HSF 是阿里外部的分布式的服务框架,作为团体中间件最重要的中间件之一,历经十多届双十一大促,承受万亿级别流量的锻炼,非常的稳固与高效。另外一方面,Dubbo 是由阿里中间件开源进去的另一个服务框架,并且在 2019 年 5 月以顶级我的项目身份从 Apache 毕业,坐稳国内第一开源服务框架宝座,领有十分宽泛的用户群体。 在团体业务整体上云的大背景下,首要挑战是实现 HSF 与 Dubbo 的交融,以对立的服务框架反对云上业务,同时在此基础上衍生出适应用下一代云原生的服务框架 Dubbo 3.0,最终实现自研、开源、商业三位一体的指标。往年作为 HSF&Dubbo 交融之后的 Dubbo 3.0 在团体双十一落地的第一年,在兼容性、性能、稳定性下面都面临着不少的挑战。可喜的是,在往年双十一在考拉下面大规模应用,体现稳固,为今后在团体大规模上线提供了撑持。 Dubbo 3.0 总体方案 在下面的计划中,能够看进去咱们是以 Dubbo 为外围,HSF 作为性能扩大点嵌入到其中,同时保留 HSF 原有的编程 API,以保障兼容性。为什么咱们选址以 Dubbo 为外围根底进行交融,次要这两点的考量: 1.Dubbo 在内部领有十分宽泛的大众根底,以 Dubbo 为外围,合乎开源、商业化的指标; 2.HSF 也经验过外围降级的状况,咱们领有比拟丰盛的解决教训,对于 Dubbo 3.0 新外围外部落地也是处于可控的范畴之内。 选定这个计划之后,咱们开始朝着这个方向致力,因为 Dubbo 开源已久,不像 HSF 这样经验过超大规模集群的考验验证,那么咱们是如何去保障它的稳定性呢? 稳定性为了保障新外围的稳固,咱们从各个方面进行坚固,保障十拿九稳 1.功能测试HSF3 共有集成用例数百个, 100% 笼罩到了 HSF 的外围性能;HSF3 的单测共有上千个,行覆盖率达到了 51.26% ...

November 30, 2020 · 1 min · jiezi

关于云原生-cloud-native:高德最佳实践Serverless-规模化落地有哪些价值

起源 | 阿里巴巴云原生公众号 作者 | 何以然(以燃) 导读:已经看上去很美、始终被张望的 Serverless,现已逐步进入落地的阶段。往年的"十一出行节",高德在外围业务规模化落地 Serverless,由 Serverless 撑持的业务在流量高峰期的体现非常优良。传统利用也能带来同样的体验,那么 Serverless 的差异化价值又是什么呢?本文分享高德 Serverless 规模化落地背地的实际总结。随着 Serverless 概念的进一步遍及,开发者曾经从张望状态进入尝试阶段,更多的落地场景也在一直解锁。“Serverless 只适宜小场景吗?”、“只能被事件驱动吗?” 这些晚期对 Serverless 的质疑正在逐步消散,用户正在更多的外围场景中,开始采纳 Serverless 技术达到提效、弹性、老本优化等目标。作为地图利用的领导者,高德为带给用户更好的出行体验,一直在新技术畛域进行摸索,在外围业务规模化落地 Serverless,现已获得显著功效。 2020 年的“十一出行节”期间,高德地图发明了记录 ——截止 2020 年 10 月 1 日 13 时 27 分 27 秒,高德地图当日沉闷用户冲破 1 亿,比 2019 年 10 月 1 日提前 3 时 41 分达成此记录。 期间,Serverless 作为其中一个核心技术场景,安稳扛住了流量高峰期的考验。值得一提的是,由 Serverless 撑持的业务在流量高峰期的体现非常优良,每分钟函数调用量靠近两百万次。这再次验证了 Serverless 根底技术的价值,进一步拓展了技术场景。 业务场景自主出行是高德地图的外围业务,波及到用户出行相干的性能诉求,承载了高德地图 APP 内最大的用户流量。下图为自主出行外围业务中利用 Node FaaS 的局部场景,从左至右顺次为:主图场景页、路线布局页、导航完结页。 随着性能的进一步拓展,高德地图从导航工具降级为出行服务平台和生存信息服务入口,进一步拓展了出行相干的生存信息服务场景,带给用户更全面的用户体验。上图性能为场景举荐卡片,旨在依据用户出行用意举荐信息,晋升用户出行体验。此性能需具备疾速迭代,款式调整高灵活性的能力。因而,将卡片款式模版寄存于云端,通过服务下发的模式渲染至客户端无疑为最优抉择,能够满足业务疾速灵便迭代的目标。 通过计划评估判断,此场景类型属于无状态服务,基于阿里云 Serverless 成熟的生态,高德最终抉择接入 Node FaaS(阿里云函数计算)服务能力,出行前端搭建了场景举荐卡片服务。卡片的 UI 模版获取、数据申请聚合&逻辑解决、拼接生成 Schema 的能力均在 FaaS 层失去实现,客户端依据服务下发的 Schema 间接渲染展现,达到更加轻便灵便的指标。 ...

November 27, 2020 · 1 min · jiezi

关于云原生-cloud-native:申通快递-双11-云原生应用实践

起源 | 阿里巴巴云原生公众号 作者 | 溪恒、遥方 一年一度的 “双11” 大促中,交易额每年都在刷新,承接这些交易商品的快递包裹的数量也在成倍增长。这些疾速的增长对物流零碎带来了微小的挑战,让物流治理更加麻利来应答 “双11” 成为了必须解决的问题。 申通是目前国内最大的物流公司之一,为了解决 “双11” 的技术挑战,申通在物流场景引入 IOT、大数据和 AI 等先进和创立的技术手段,通过一直的技术疾速迭代,使得物流资源失去无效的配置,推动了物流行业的倒退。 疾速的技术迭代带来了对 IT 基础设施的挑战,申通近年来全面将传统利用切换应用云原生架构,通过云原生架构实现利用的疾速迭代、稳固的高可用、资源的动静扩缩容来撑持起疾速的技术创新。 上云前,申通应用线下机房作为计算及数据存储平台,一到 双11 资源需要就收缩,大促之后则闲置节约;上云和云原生化后,简直全副的资源都是按量购买,应用云原生技术疾速扩缩容,双11 前疾速扩容,双11 开释,真正做到了开箱即用,不产生一天节约。与去年 双11 当天相比,往年 11 月 1 到 3 日,在业务量大幅晋升的状况下,IT 投入反而升高了 30%。上云的成效显著。  申通云原生化架构的背景目前申通正在把业务从 IDC 机房往云上搬迁,外围业务零碎目前曾经在云上实现流量承接。原有 IDC 零碎帮忙申通晚期业务疾速倒退,但也裸露了不少问题,传统 IOE 架构,各零碎架构的不标准,稳定性,研发效率等都限度了业务倒退需要。 随着云计算在国内的越发成熟,更多的企业在把本人外围零碎往云上搬,享受云计算带来的技术红利。在跟阿里云屡次技术交换之后最终确定阿里云为惟一合作伙伴,为申通提供稳固的计算、数据处理平台。 采纳云原生利用架构的诉求/驱动力快递公司是十分典型的云边一体架构,实操环节很重。大量的业务逻辑下沉到边缘,所以申通在上云革新过程中,也在尝试做云边一体化的架构降级。通过云边一体,能够让开发在同一个平台下面实现云上业务及边缘侧的业务开发。同时快递公司还有典型的大数据处理场景,全网每天会新增几亿条扫描数据,须要对这些数据进行实时剖析,对数据的解决要求十分高。 之前应用线下机房作为计算及数据存储平台的形式,使申通在业务增长过程中遇到了一些瓶颈,比方软件交付周期过长、大促保障对资源的要求、零碎稳定性挑战等等。而云原生技术就是来解决传统利用降级迟缓、架构臃肿、不能疾速迭代等方面的问题。正是看中了云原生技术可能给咱们带来的价值才驱使咱们转为应用私有云作为次要计算资源。 站在企业的角度来看,在这样一个疾速多变的时代,云原生给咱们带来的价值也正是企业最须要的: 唯快不破。这里的“快”有两层含意,一是业务利用疾速上线,通过云原生技术能够做到疾速上线部署;二是在业务爆发式增长的时候,对资源的需要要做到开箱即用。稳中求变。业务稳定性永远是第一位。通过监控埋点,业务日志收集,链路监控等伎俩保障了在疾速迭代过程中业务零碎的稳定性。节俭资源。通过对计算资源的水位监测,联合业务的峰值状况,当发现资源利用率偏低采纳降配规格及数量,升高整个资源的费用。相比于一次性投入租建机房及相应的维护费用,应用私有云老本投入更低。开拓创新。采纳微服务架构,将之前臃肿的架构进行正当拆分,再联合容器编排的能力做到继续交付。让企业胜利转型成为一家 DevOps 驱动的公司。申通云原生架构历程1. 云原生化技术改造原架构是基于 Vmware+Oracle 数据库的架构,通过上阿里云全面转型基于 Kubernetes 的云原生架构体系。应用服务架构重构次要分两局部: 1)程序代码革新降级利用容器化跟虚拟机比起来,容器能同时提供效率和速度的晋升,让其更适宜微服务场景。所以咱们引入容器技术。通过利用容器化解决了环境不统一的问题,保障利用在开发、测试、生产环境的一致性。 微服务革新原先很多业务是基于 Oracle 的存储过程及触发器实现的,零碎之间的服务依赖也是走的数据库 OGG 同步实现。带来的问题就是零碎十分难保护,也十分不稳固。通过引入 Kubernetes 的服务发现来做微服务计划,按业务域进行拆分,让整个零碎更易于保护。 2)引入云原生数据库计划通过引入 OLTP 跟 OLAP 型数据库,将在线数据与离线剖析逻辑拆到两种数据库中,取代之前齐全依赖 Oracle。特地是在解决历史数据查问场景下解决了 Oracle 反对不了的业务需要。 ...

November 25, 2020 · 2 min · jiezi

关于云原生-cloud-native:今年最火的-Golang-云原生开源项目可能就是它了

起源 | 阿里巴巴云原生公众号 在互联网与云计算技术倒退的突飞猛进过来五年中,利用研发人员对效率与麻利的极致谋求,终于把业界带进了一个簇新的云原生时代。而云原生理念的迅速遍及,火了 Docker,红了 Kubernetes ,也间接让一个编程语言成为了现在服务端的“当家花旦”。不消多讲,这位在云原生畛域里正红的发紫的“角儿”,就是 Golang。 不过,正如同 “PHP 不肯定是最好的编程语言”一样,Go 语言自身也不是“万能钥匙”。Go 语言之所以可能乘上云原生这趟高速列车,究其原因,更多是与它如下几个特质密切相关: 语法简略,容易上手。云原生社区是一个对开源和贡献者十分看重的生态,这就使得很少须要纠结于语法细节的 Go 语言迅速成为了这个社区的“不二之选”。否则的话,云原生 CNCF 社区里大量我的项目都得忙着探讨这个指针那个援用,什么 Kubernetes CRD 之类的翻新设计预计都得凉。golang.org 库十分丰盛。咱们古代软件开发行业,考究的就是“面向 library” 编程,谁没事儿都不会手撸一个 HTTP 框架或者并发库。开箱即用的库越多,咱研发效率就越高。在这一点上,Go 语言不仅有先天劣势,而且雪球越滚越大,未然是云原生一霸了。部署简略。Go 语言我的项目开发完了,一个动态文件就能够运行了,特地适宜间接扔在 Docker 里跑。大家能够设想一下如果 Kubernetes 是 Python 或者 Ruby 开发的,这玩意儿线上部署得多头疼。性能还不错,优化也绝对简略。Go 语言不能说是性能之王,但它很好的均衡了性能和程序员的心智累赘。对于 Docker、Kubernetes 这几个我的项目的定位来说,这个平衡点恰到好处。所以到了 2020 年,Go 语言曾经成为了”云原生“这个圈子最重要的一枚“入场券”:Linux 内核不懂,咱还有机会缓缓学;Go 语言不会?您可就真要举步维艰了。 而俗话说得好:要想语言学得好,入手练习不能少!咱们云原生社区最大的一个益处,就是 Go 语言开源我的项目多,优质的 Go 语言开源我的项目更多!从最底层的 containerd,到编排层的 Kubernetes,再到现在正红的发紫的 Istio,轻易拿出一个来,那就足够咱们好好钻研一阵子了。 不过,这些出名我的项目当初大多曾经比拟成熟,基本上很少承受大颗粒的 feature 进去。而且即便提 Pull Request(PR)下来了,它的合并速度也是慢的令人发指。所以大家都在问,在云原生畛域中,还有哪些比拟晚期的、热门的 Go 语言我的项目还能让咱们宽广的 YAML 工程师们”一展宏图“呢? 这不,就在刚刚完结的、云原生畛域最权威的 KubeCon 北美峰会 2020 上,由 Open Application Model (OAM)社区公布的 KubeVela 开源我的项目,着实让人眼前一亮。 ...

November 24, 2020 · 2 min · jiezi

关于云原生-cloud-native:OpenKruise阿里巴巴-双11-全链路应用的云原生部署基座

起源 | 阿里巴巴云原生公众号 作者 | 王思宇(酒祝) OpenKruise 是由阿里云于 2019 年 6 月开源的云原生利用自动化引擎,实质是基于 Kubernetes 规范扩大进去一个的利用负载我的项目,它能够配合原生 Kubernetes 应用,并为治理利用容器、sidecar、镜像散发等方面提供更加弱小和高效的能力,从而在不同维度上通过自动化的形式解决 Kubernetes 之上利用的规模化运维和规模化建站问题,包含部署、降级、弹性扩缩容、Qos 调节、健康检查、迁徙修复等等。 OpenKruise 官网:https://openkruise.io/GitHub 我的项目地址:https://github.com/openkruise/kruiseKruise 是 Cruise 的谐音,'K' for Kubernetes,寓意 Kubernetes 上利用的航行和主动巡行,它满载着阿里巴巴多年在大规模利用部署、公布与治理最佳实际,以及阿里云 Kubernetes 服务数千客户的需要积淀。 OpenKruise: 阿里巴巴 双11 全链路利用的云原生部署基座在阿里巴巴经济体的整体云原生化过程当中,阿里的技术团队逐步积淀出了一套紧贴上游社区规范、适应互联网规模化场景的技术理念与最佳实际。这其中,最重要的无疑是如何对利用进行自动化的公布、运行和治理。于是,阿里云容器团队将这些能力通过  OpenKruise 反哺社区,以期指引业界云原生化最佳实际,少走弯路。 往年 双11,阿里巴巴实现了外围零碎的全面云原生化。截至 2020 年 双11,阿里巴巴外部已运行近十万 OpenKruise 的 workload、治理着上百万容器。 1. 外部运行的 OpenKruise 版本代码超 95% 来自社区仓库下图展现了阿里巴巴外部运行的 OpenKruise 版本与开源版本之间的关系: 从上图能够看出:Github 上的 OpenKruise 就是咱们主体的上游仓库,而外部的上游仓库只基于公共接口实现了极少数外部耦合性能(这部分代码只占据了不到 5%),也就是说阿里巴巴外部运行的 OpenKruise 其中 95% 以上的代码齐全来自于社区仓库。 有两点值得阐明: 所有通用能力,咱们都会间接基于开源仓库开发和提交,而后再同步到外部环境。社区成员为 OpenKruise 奉献的每一行代码,都将运行在阿里外部环境中。2. 在 Kubernetes 上自动化应用程序工作负载治理做下层业务的同学可能对 “利用负载(workload)” 不足概念,这里先简略做个介绍。不晓得你是否有好奇过,每一次利用扩缩容、公布操作的背地是如何实现的呢?在云原生的环境下,咱们都是通过面向终态的形式去形容利用的部署需要(须要的机器数、镜像版本等等),见下图: ...

November 24, 2020 · 2 min · jiezi

关于云原生-cloud-native:云原生趋势下的迁移与容灾思考

起源 | 阿里巴巴云原生公众号 作者 | 孙琦 导读:下一个云原生颠覆的畛域会不会是在传统的容灾畛域呢?在云原生的趋势下,如何构建利用零碎的迁徙与容灾计划?趋势1. 云原生发展趋势云原生(Cloud Native)是最近几年十分火爆的话题,在 2020 年 7 月由信通院公布的《云原生倒退白皮书(2020)年》明确指出:云计算的拐点已到,云原生成为驱动业务增长的重要引擎。咱们不难发现云原生带给 IT 产业一次从新洗牌,从利用开发过程到 IT 从业者的技术能力,都是一次颠覆性的反动。在此基础上,呈现了基于云原生平台的 Open Application Model 定义,在云原生平台根底上进一步形象,更加关注利用而非基础架构。同时,越来越多的私有云开始反对 Serverless 服务,更加阐明了将来的发展趋势:利用为外围,轻量化基础架构层在零碎建设过程中的角色。然而无论如何变动,IT 整体倒退方向,肯定是向着更有利于业务疾速迭代、满足业务需要方向演进的。 2020 年 9 月,Snowflake 以每股 120 美金 IPO,发明了往年规模最大的 IPO,也是有史以来最大的软件 IPO。Snowflake 利用云原生形式重构了数据仓库,胜利颠覆了行业竞争格局。这正是市场对云原生发展趋势的最佳认可,所以下一个云原生颠覆的畛域会不会是在传统的容灾畛域呢? 2. 为什么云上须要全新的迁徙和容灾?1)传统计划的局限性在这种大的趋势下,传统的迁徙和容灾依然停留在数据搬运的档次上,而疏忽了面向云的个性和用户业务从新思考和构建。云计算的愿景是让云资源像水、电一样按需应用,所以基于云上的迁徙和容灾也理当适应这样的历史潮流。Snowflake 也是通过这种商业模式的翻新,胜利打破旧的竞争格局。 为什么传统容灾的伎俩无奈满足云原生需要呢?简略来说,二者关注的外围不同。传统的容灾往往以存储为外围,领有对存储的至高无上的控制权。并且在物理时代,对于计算、存储和网络等基础架构层也没有无效的调度办法,无奈实现高度自动化的编排。而基于云原生构建的利用,外围变成了云原生服务自身。当用户业务零碎全面上云后,用户不再享有对底层存储的相对控制权,所以传统的容灾伎俩,就风光不在了。 我认为在构建云原生容灾的解决方案上,要以业务为外围去思考构建办法,利用云原生服务的编排能力实现业务零碎的连续性。 2)数据安全性AWS CTO Werner Vogels 已经说过:Everything fails, all the time。通过 AWS 的责任共担模型,咱们不难发现云商对底层基础架构负责,用户依然要对本身本身数据安全性和业务连续性负责。 我认为在云原生趋势下,用户最间接诉求的来自数据安全性即备份,而迁徙、复原、高牢靠等都是基于备份体现出的业务状态,而备份能力可能是由云原生能力提供的,也有可能是第三方能力提供的,但最终实现业务状态,是由编排产生的。 用户上云并不等于居安思危,相同用户要学习云的正确打开方式,能力最大水平来保障业务的连续性。尽管云在底层设计上是高牢靠的,然而依然防止不了外力造成的影响,例如:光缆被挖断、断电、人为误操作导致的云平台可用区无奈应用,所以才有了相似“蓝翔决定了中国云计算稳定性”的调侃。我认为用户决定将业务迁徙到云上的那一刻开始,备份、迁徙、复原、高牢靠是一个间断的过程,如何正当利用云原生服务的个性实现业务连续性,同时进行老本优化,升高总体领有老本(TCO)。 3)避免厂商锁定某种意义上说,云原生的方向是新一轮厂商锁定,就像当年盛极一时的 IOE 架构一样,只不过当初换成了云厂商作为底座承载利用。在 IOE 时代,用户很难找到完满的替代品,然而在云时代,这种差别并不那么显著。所以大部分的客户通常选用混合云作为云建设策略,为了让利用在不同云之间可能平滑挪动,利用容灾技术的迁徙肯定是作为一个常态化需要存在的。Gartnar 也在多云管平台定义中,将迁徙和 DR 作为独自的一项能力。充分说明迁徙与容灾在多云环境的的常态化趋势。 云迁徙与云容灾的关系1. 云迁徙需要的产生在传统环境下,迁徙的需要并不非常突出,除非是遇到机房搬迁或者硬件降级,才会想到迁徙,但这里的迁徙更像是搬铁,迁徙工具化与自动化的需要并不显著。当 VMware 呈现后,从物理环境到虚拟化的迁徙需要被放大,但因为是繁多的虚拟化平台,基本上虚拟化厂商本身的工具就齐全可能满足需要了。在虚拟化平台上,大家忽然发现原来只能人工操作的物理环境一下子轻捷起来,简略来说,咱们的传统服务器从一堆铁变成了一个文件,并且这个文件还可能被来回挪动、复制。再起初,进入云时代,各家云平台风生水起,国内云计算市场更是百家争鸣,上云更是成为了一种刚性需要。随着工夫的推移,出于对老本、厂商锁定等诸多因素的影响,在不同云之间的相互迁徙更是会成为一种常态化的需要。 ...

November 23, 2020 · 2 min · jiezi

关于云原生-cloud-native:从基础设施到云原生应用全方位解读阿里云原生新锐开源项目

起源 | 阿里巴巴云原生公众号 2020 年 11 月 19 日,由 InfoQ 主办的“2020 中国技术力量年度榜单盛典”隆重召开,并正式揭晓了“开源杰出贡献人物”、“开源新锐我的项目”和“云原生行业落地榜样”等重大奖项。在此前的入围赛中,仅“开源新锐我的项目”单项,阿里云原生就入围了 10 多个开源我的项目,在创新能力、社区成就和用户反馈等多项指标中一骑绝尘,占据了参评我的项目整体近五分之一。而在本次揭晓的“2020 中国技术力量年度榜单”决赛后果中,最终阿里云高级技术专家罗毅荣获“十大开源杰出贡献人物”、Open Application Model(OAM)荣登“十大开源新锐我的项目”、由阿里云原生团队撑持的完满日记电商业务案例获评“2020 年度十大云原生行业落地榜样”。 在 2020 年,阿里不仅实现了 双11 外围零碎全面云原生化,一举成为寰球规模最大、实力最硬核的云原生实际,并首次实现自研、开源、商业“三位一体”,以此为根底拉开了极具竞争力的云原生产品家族的尾声。为了让大家有更全面的意识,咱们借此机会整顿了阿里从应用层到中间件到基础设施三层平面构造的云原生新锐开源我的项目和技术能力。 云原生生态价值“聚焦点”:OAM 凋谢利用模型与 KubeVela 凋谢利用平台我的项目现如今,云原生技术的迅猛发展可能让很多人都感觉到目迷五色,但如果咱们去探寻“云原生”的实质,就不难发现这项技术与理念发动的初衷,是为了让云端的开发人员更轻松的、以齐全基础设施无关的形式去交付与治理利用。随同着这个初衷和诉求,才有了 Kubernetes 这样为平台团队屏蔽掉了“虚拟机”、“存储”等底层概念的对立的基础设施层形象我的项目。然而,理论的落地过程通知咱们,仅仅有基础设施层形象,离云原生“丝般顺滑”的云端利用治理与交付体验,还是存在着微小的鸿沟。在 Kubernetes 与用户之间,还存在着一层名叫“应用层”形象亟待填补。 作为本次 2020 年中国技术力量十大开源新锐我的项目的获奖者,Open Application Model(OAM)凋谢利用模型,以及它的 Kubernetes 实现 —— KubeVela 我的项目,正是阿里云联结微软等云原生社区中坚力量,独特推出的云原生应用层外围我的项目。其中,OAM 的设计思维是为包含 Kubernetes 在内的任何云端基础设施提供一个对立、面向最终用户的利用定义模型;而 KubeVela,则是这个对立模型在 Kubernetes 上的残缺实现。所以,对于业务研发人员来讲,KubeVela 能够被认为是云原生社区的 Heroku。而对于平台团队来讲,KubeVela 因为具备极高的可扩展性,能够被认为是一个“以利用为核心”的、高度可扩大的 Kubernetes 发行版。 有了 OAM 和 KubeVela,现今的平台工程师终于领有了一个能够方便快捷地将任何一个 Kubernetes 社区能力封装形象成一个面向最终用户的应用层平台个性的弱小工具。而作为这个平台的使用者,业务研发们不须要理解任何 Kubernetes 相干的常识,只通过极简的应用层语义就能够残缺形容出本人的代码构建和利用部署细节,而后一键交付进来。 云原生中间件实现自研、开源、商用“三位一体”,造成微服务最佳实际中间件是云原生从概念到落地的承接。K8s 屏蔽了底层云基础设施的差别,成为了云原生时代微服务利用的操作系统。在云原生操作系统和云原生利用之间,须要一层形象,向下屏蔽掉底层的复杂性,向上提供便捷、牢靠的能力,让利用低成本、甚至无老本的迁徙到新的云基础设施上部署和运行,并享受到云按需付费、极致扩缩容等能力。阿里云原生中间件承当了这样的职责。 阿里云原生中间件脱胎于阿里团体外部,并通过 双11 这样举世无双的场景造成了微服务畛域最佳实际,从 2011 年 Dubbo 开源开始,阿里云原生中间件就开始尝试在云产品和开源方面进行致力,心愿能让反对阿里外围业务的中间件零碎从关闭走向凋谢,服务更宽泛的用户。在而后几年陆续推出了 Dubbo、RocketMQ、Spring Cloud Alibaba、Nacos、Sentinel、Arthas、Seata、ChaosBlade 等多个为人熟知的开源我的项目,并造成了微服务畛域最佳实际。短短两年工夫,Spring Cloud Alibaba 从 Spring 社区毕业,成为了最受中国开发者欢送的 Spring Cloud 实现。 ...

November 23, 2020 · 1 min · jiezi

关于云原生-cloud-native:阿里云原生中间件首次实现自研开源商用三位一体技术飞轮效应显现

起源 | 阿里巴巴云原生公众号 对于阿里的技术同学来说,每年的 双11 都是一场“盛宴”。为了让顾客有顺滑的购物体验,给商户提供更多样化的让利流动,阿里电商平台对于效率、可靠性、规模性的要求在 双11 的驱动下成倍进步,激发着技术人的后劲。作为根底技术外围之一,阿里中间件也会在每年 双11 迎来一次技术的全面演进和降级。 阿里在 2019 年实现了全站的外围零碎上云,对于阿里中间件来讲,这是一个意义不凡的时机和挑战。实际上,从 2011 年 Dubbo 开源开始,阿里中间件就曾经尝试在云产品和开源方面致力摸索,心愿让反对阿里外围业务的中间件零碎从关闭走向凋谢,服务更宽泛的用户。过来几年,阿里云推出了 EDAS 产品线,心愿可能把阿里在微服务和利用托管体系的实践经验分享给用户;与此同时,阿里云还在开源社区中推出了 Dubbo、RocketMQ、Nacos、Seata 等多个为人熟知的开源我的项目,激励宽广开发者共建中间件生态体系。 阿里云在摸索中始终存在的苦恼,是外部的自研体系、商业化的产品技术与开源的我的项目,三方的技术路线始终没有机会融为一体。然而,就在往年阿里云提出了“三位一体”理念,行将“自研技术”、“开源我的项目”、“商业产品”造成对立的技术体系,最大化技术的价值。随着阿里自研体系的上云,这个时机终于到来了。往年,让阿里云中间件技术人最兴奋的,除了反对 双11 大促的再一次胜利,更是能用这些技术继续赋能阿里云上数以万计的企业、机构、开发者以及他们的用户,把 双11 的技术红利施展到极致。 基于团体场景,积淀 Spring Cloud Alibaba 全家桶,造成微服务畛域最佳实际在考拉入淘过程中,团体基于开源外围预研的下一代服务框架 Dubbo 3.0,完满交融了外部 HSF 的个性。考拉基于 Dubbo 以及 MSE 提供的服务发现和流量治理能力,轻松实现了与团体外围电商业务的接入。在往年 双11 大促中,考拉外围链路上的数百个利用运行在 Dubbo 3.0 这个版本上。Nacos 与 Dubbo/Spring Cloud Alibaba 生态实现无缝整合。2018 年,随着阿里开源策略的推动,阿里云以 10 年 双11 积淀的注册核心和配置核心为根底开源了 Nacos,以简略易用、性能卓越、高可用、个性丰盛等外围竞争力疾速成为畛域首选。并且跟阿里 Dubbo/Spring Cloud Alibaba 生态实现无缝整合,造成微服务畛域最佳实际。2020 年,随着阿里全站上云的全面推动,阿里云将阿里经济体外部注册核心和配置核心用 Nacos 重构实现,并以云产品 MSE 撑持了淘宝、饿了么、考拉等外围 BU 安稳度过 双11。阿里微服务体系通过阿里外部场景锤炼出高性能和高可用的外围竞争力,通过开源构建了生态和规范,凭借 MSE、EDAS 等云产品实现产品化和能力输入。基于此,阿里云中间件实现了三位一体的正向循环,通过规范继续输入阿里巴巴的外围竞争力,让内部企业疾速享有阿里微服务能力,减速企业数字化转型! ...

November 23, 2020 · 1 min · jiezi

关于云原生-cloud-native:展现非凡领跑力京东会展云斩获十大云原生行业落地典范奖项

11 月 19 日,由InfoQ 发动并组织的“2020中国技术力量年度榜单评比”后果正式揭晓。_京东智联云凭借2020中国国内服务贸易交易会数字平台案例_,从300多参评我的项目中怀才不遇,斩获“十大云原生行业落地榜样”奖项,充沛展现了京东会展云不凡的领跑力。 “2020 中国技术力量年度榜单评比”是由国内软件开发者在线新闻/社区平台—InfoQ作为第三方独立媒体,创建13年来首次推出的榜单类流动。由宏大的专家团队、编辑和开发者社区对参评我的项目进行多维度评估。 “云原生”作为此次评比中IT圈最煊赫一时的畛域,竞争十分激烈。而京东智联云冲破重围的秘诀正是在于会展行业云原生的翻新模式。_作为2020年中国国内服务贸易交易会官网技术服务商,京东智联云从0到1重构会展产业结构,用技术助力传统会展行业的数智化降级,造成了一个千锤百炼、可复制、可推广的数智化会展平台_。 作为京东技术与服务对外输入的窗口,京东智联云开展科技想象力,搭建“云上服贸会”数字平台。围绕“展、论、洽”三大外围会展场景,聚合云计算、AI、大数据、5G等技术劣势,冲破工夫、空间、语言限度,解决了传统会展行业信息化伎俩繁多、不足先进技术等弊病,打造365天永不闭幕的服贸会。 中国国内服务贸易交易会是寰球惟一的、国际性和综合型的服务贸易展会,也是疫情产生以来第一场重大的国际经贸流动。京东智联云作为服贸会的官网技术服务商,秉承“打造一场云展会,积攒一个新平台,引领一轮新经济”的理念,为寰球展客商提供全链条的会展服务,不仅体现了牢靠的科技实力,更承当起一份社会责任。 将来,京东智联云将一直夯实技术底座,推动展会行业从线下走向线上,从繁多走向交融,用技术领跑会展2.0时代,驱动传统会展行业数智改革。 举荐浏览: 知你所想,推你所愿 | 深度解读展会场景智能举荐搭建之路会展云技术解读 | 基于服务设计的线上展览会展云技术解读 | 多重平安保障护航云上会展欢送点击【京东智联云】,理解开发者社区 更多精彩技术实际与独家干货解析 欢送关注【京东智联云开发者】公众号

November 23, 2020 · 1 min · jiezi

关于云原生-cloud-native:阿里云-OAM-入选2020中国技术力量年度榜单定义云原生应用交付标准

2020 年 11 月 19 日,备受关注的「2020 中国技术力量年度榜单」评比后果终于揭晓。在该榜单设立的「年度开源新锐我的项目」、「开源杰出贡献人物」、「云原生行业落地榜样」三大分项中,阿里云云原生均占据一席之位,体现亮眼。其中,由阿里云和微软云共同开发并开源的云原生利用定义模型 OAM (Open Application Model)再露矛头,通过 10000+ 开发者的公开票选,在 55 个参评我的项目中怀才不遇,入选「年度十大开源新锐我的项目」。 OAM 我的项目由 2019 年 10 月底正式开源, 是目前 CNCF 利用交付畛域小组主推的云原生利用平台(含 PaaS )构建规范,也是业界惟一一个支流的利用平台构建框架我的项目。 OAM 作为一个基础设施无关的、高度可扩大的利用定义与能力治理模型,旨在为宽广利用开发者和云原生利用平台的构建者提供一套对立的「以利用为核心」的构建范式。所以,对于 Kubernetes 来说,OAM 即是一个可能为它带来「利用定义」的增强型能力,同时也是一个专一于封装、组织和治理 Kubernetes 中各种利用治理能力的平台层框架。基于 OAM 构建的云原生利用平台,人造适宜微服务架构利用,在用户界面上,可能轻松屏蔽掉容器基础设施的复杂性和差异性,在能力高度可插拔的前提下,为平台的使用者带来低心智累赘的、标准化的、统一的利用治理与交付体验。 而就在刚刚完结的云原生技术「最高盛宴」 KubeCon 北美峰会 2020 上,OAM 重要子项目 KubeVela 正式宣告开源。作为一个基于 Kubernetes 与 OAM 技术构建的、简略易用且高度可扩大的利用治理平台与外围引擎,KubeVela 的开源使 OAM 理念失去更好的实现。仅开源三天,即播种 GitHub 300+ Star。 对于利用开发人员来讲,KubeVela 简略易用,又功能强大,能够被认为是云原生社区的 Heroku。 而对于平台团队来讲,KubeVela 则能够被认为是一个“以利用为核心”的 Kubernetes 发行版,它原生的可扩展性容许平台工程师基于它构建出任何满足本人诉求的云原利用生平台。 目前,OAM 我的项目曾经成为阿里云利用 PaaS 产品以及外部利用治理平台的模型层的根底依赖,在生产环境中服务了数千名来自不同场景的利用开发者。截止 2020 年中,OAM 曾经成为了十余家来自不同国家、行业的平台团队构建利用 PaaS 的外围依赖。 咱们十分心愿和更多的开发者一起参加到 OAM 我的项目的建设中来,欢送你返回 OAM 官方网站 及 GitHub 我的项目地址更好地理解、学习和应用,也欢送钉钉搜寻群号:23310022 ,和将近 2000 名开发者互动交换!

November 20, 2020 · 1 min · jiezi

关于云原生-cloud-native:6-岁是时候重新认识下-Serverless-了

起源 | Serverless 公众号 背景Serverless 概念从 2012 年开始提出,真正推出相干云产品是 2014 年 AWS 推出 Lambda。如果咱们将 Serverless 比作一个婴儿,那么它曾经 6 岁了。 尽管业界对 Serverless 尚无统一认可的定义,然而我置信大部分开发者在听到  Serverless 时,会联想到 Lambda,并且冒出“函数”、“按需(调用次数)免费”、“事件驱动”等关键词。的确当年刚刚诞生的 Serverless 就像上面可恶的“紫薯人”,紫色充斥神秘感(当年刚推出的时候相对是黑科技),让人印象粗浅。 刚刚出世的 Serverless AWS 的微小影响力以及自身携带的一身黑科技,的确让人记住了 Serverless,然而也正因为诞生的时候太印象粗浅,以至于当初提到曾经 6 岁的 Serverless,很多人的印象还是停留在Serverless=Lambda或者Serverless=FC(Function Compute),这不得不说是某种遗憾。 当初的 Serverless 明天企业都在全面数字化转型,整个技术架构体系都渴望依靠云原生来获取微小技术红利,Serverless 从诞生的第一天起就是云原生的,所以咱们有必要再系统地认识一下 Serverless 的理念以及这些年诞生的相干产品,置信不论你是前端、后端、架构师、SRE、CTO,都会有所播种,并且在将来能更好地施展 Serverless 的技术价值助力商业胜利。 定义业界始终在尝试定义 Serverless,比方 CNCF 给出的定义是:NoOps 和 Pay as You Run,还有伯克利说 Serverless = FaaS + BaaS。然而我想说,Serverless 其实无需再去定义,他自身就曾经十分清晰明确:“Server + less”,他是一个理念,核心思想就是你不再须要关注 Server,作为比照的是 IaaS 时代,购买服务器,装置各种工具,再在下面开发本人的业务。 Server 不会隐没,而是让个别的开发者不须要再关注 Server,这意味着【智能弹性】、【疾速交付】、【更低成本】,这也是 Serverless 相干产品的典型个性。 ...

November 20, 2020 · 2 min · jiezi

关于云原生-cloud-native:Forrester-最新报告阿里云稳居领导者地位引领云原生开发浪潮

起源 | 阿里巴巴云原生公众号 日前,国内权威钻研机构 Forrester 公布了《The Forrester Wave: Public Cloud Development And Infrastructure Platforms In China,Q4 2020》报告,报告对中国支流私有云厂商从策略、产品和市场格局三个维度进行了全面评估,并重点关注开发人员体验、开发服务和基础设施操作三大外围因素。阿里云在容器服务、Serverless/微服务测评中均取得了最高分,并在利用开发服务 9 项测评中拿到了国内综合最高分,稳居云原生畛域领导者位置。 Forrester 报告对阿里云的评估是:阿里云领有当先的企业开发和经营平台。作为中国公共云市场上的第一家公司,阿里云在帮忙中国企业满足其开发和经营要求方面领有丰盛的教训……阿里云提供丰盛的服务,在容器、微服务、Serverless 等方面利用宽泛,并具备批发、金融、制作和政府等多种垂直解决方案。对于须要数字化转型的企业来说,阿里云是现实的抉择。 容器服务拿到最高分,打造最强云原生技术生态Forrester 报告显示,随着越来越多的中国开发人员应用公共云构建新利用,促使其旧的利用架构向现代化转型,当先的云服务商致力于打造全面丰盛的开发体验和翻新的利用实际,这些因素也正是云服务商外围竞争力的体现。在利用开发服务能力的测评中,阿里云容器取得最高分。 过来几年,容器服务越来越被企业所承受。阿里云提供了业界最丰盛的容器产品家族,其容器服务曾经间断数年规模超 400% 高速增长。2019 年天猫 双11,阿里巴巴外围零碎首次实现 100% 上云。往年 双11,阿里巴巴外围零碎全面云原生化,80% 外围业务部署在阿里云容器 ACK 上,可在 1 小时内扩大超百万容器,扛住了每秒 58.3 万笔的交易峰值。 目前,阿里云容器服务(ACK)已在中国及海内 21 个私有云可用区开服,同时也反对客户在自有机房和边缘端的部署应用 Kubernetes,基于神龙弹性裸金属实例的弱小性能,具备极致性能、高效调度、全面平安的特点。同时,阿里云还提供了丰盛且差异化产品:兼容 Istio 的服务网格(ASM)、基于弹性容器实例的无服务器 Kubernetes(ASK)、提供镜像扫描的独享版容器镜像服务 (ACR)、基于轻量虚拟机技术的平安沙箱容器运行时和边缘计算容器服务(ACK@Edge)、基因计算服务(AGS)等。9 月底,阿里云率先通过信通院容器规模化性能测试,取得最高级别认证——"卓越" 级别,并首先胜利实现以单集群 1 万节点 1 百万 Pod 的规模冲破,构建了国内最大规模容器集群。在此前 Forrester 专门针对公共云容器服务的测评中,阿里云作为 Strong Performer 位列国内第一。 除了在云原生体验层面继续优化,阿里云原生也在打造丰盛场景的解决方案,帮忙企业利用新技术降低成本。阿里云云效联结云原生团队打造一站式云原生 DevOps 解决方案,无论是通用 K8s 场景、Spring Cloud/Dubbo 微服务场景、还是轻量级的函数计算场景,云效 DevOps 都能从容应对,以助力更多企业迈进云研发时代,实现 DevOps 转型“超车”。 ...

November 19, 2020 · 1 min · jiezi

关于云原生-cloud-native:KubeVela-正式开源一个高可扩展的云原生应用平台与核心引擎

【起源:阿里巴巴云原生公众号】 美国西部工夫 2020 年 11 月 18 日,在云原生技术“最高盛宴”的 KubeCon 北美峰会 2020 上,CNCF 利用交付畛域小组(CNCF SIG App Delivery) 与 Open Application Model (OAM) 社区,以及来自阿里云、微软云的 OAM 我的项目维护者们在演讲中独特发表了 KubeVela 开源我的项目的正式公布。 从 11 月 18 号到 20 号,在为期三天的 KubeCon 北美峰会上有间断 3 场技术演讲,会从不同维度介绍对于 KubeVela 我的项目的具体细节,其中还包含一个长达 1 个半小时的 KubeVela 互动教学环节。多个重量级组织以如此规模和密度在 KubeCon 北美峰会演讲中介绍一个首次公布的社区开源我的项目,在 KubeCon 诞生以来并不多见。 什么是 KubeVela ?一言以蔽之,KubeVela 是一个简略易用且高度可扩大的利用治理平台与外围引擎。KubeVela 是基于 Kubernetes 与 OAM 技术构建的。 具体的说,对于利用开发人员来讲,KubeVela 是一个非常低心智累赘的云原生利用治理平台,外围性能是让开发人员方便快捷地在 Kubernetes 上定义与交付古代微服务利用,无需理解任何 Kubernetes 自身相干的细节。在这一点上,KubeVela 能够被认为是云原生社区的 Heroku。 另一方面,对于平台团队来讲,KubeVela 是一个弱小并且高可扩大的云原生利用平台外围引擎。基于这样一个引擎,平台团队能够疾速、高效地以 Kubernetes 原生的形式在 KubeVela 中植入任何来自云原生社区的利用治理能力,从而基于 KubeVela 打造出本人须要的云原生平台,比方:云原生数据库 PaaS、云原生 AI 平台、甚至 Serverless 服务。在这一点上,KubeVela 能够被认为是一个“以利用为核心”的 Kubernetes 发行版,以 OAM 为外围,让平台团队能够基于 KubeVela 疾速打造出属于本人的 PaaS、Serverless 乃至任何面向用户的云原生平台我的项目。 ...

November 19, 2020 · 3 min · jiezi

关于云原生-cloud-native:111720-KubeCon-北美-2020-阿里巴巴完整议题

作为引领云原生技术倒退的风向标,由 CNCF (Cloud Native Compute Foundation)举办的 KubeCon + CloudNativeCon 始终是连贯全世界云原生开发者的重要阵地,也是寰球云计算首领共话云原生将来方向的舞台。北美工夫 2020 年 11 月 17 日 - 20 日,来自当先的开源和云原生社区采纳者、技术人员将再一次在线上汇聚。 在本次峰会上,阿里巴巴将带来 7 场围绕容器、Kubernetes、社区倒退方向的演讲和分享,无论是分享数量、嘉宾分量还是话题品质,都再一次成为吸引寰球眼光的中国云原生技术力量焦点。 上面就让咱们先睹为快,看看在 2020 北美 KubeCon + CloudNativeCon 上阿里巴巴有哪些值得关注的话题、嘉宾和分享环节。 点击查看阿里巴巴 @KubeCon2020 北美残缺议题:https://kccncna20.sched.com/?searchstring=alibaba&iframe=no&w=100%25&sidebar=yes&bg=no 11 月 18 日对于 ContainerD 的最新进展和深度探讨工夫:11 月 18 日 PM 15:00-15:35 分享嘉宾:傅伟(等),阿里云高级工程师 作为 ContainerD 我的项目的外围维护者,阿里云高级工程徒弟伟将与来自 Apple、IBM 等企业的我的项目成员一起,进行一场围绕 ContainerD 最新进展的设计和架构介绍以及最新性能的深度钻研探讨,包含 NRI  NRI (Node Resource Interface)、new Sandbox API、将 CRI (Container Runtime Interface) 的实现迁徙至 ContainerD 内核,以及为了更好的代理反对在近程的 snapshotters 到镜像散发方面所做的改良等。期待大家一起来理解如何更好地应用和奉献 ContainerD 我的项目。 ...

November 18, 2020 · 1 min · jiezi

关于云原生-cloud-native:订单峰值激增-230Serverless-如何为世纪联华降本超-40|双11-云原生实践

作者 | 朱鹏 导读:2020 年 双11,世纪联华基于阿里云函数计算 (FC) 弹性扩容,利用于大促会场 SSR、线上商品秒杀、优惠券定点发放、行业导购、数据中台计算等多个场景,业务峰值 QPS 较去年晋升 230%,研发效率交付提效超过 30%,弹性资源老本缩小 40% 以上。当 双11 走过 11 个年头,传统企业正在凭借云原生技术悄悄逆势崛起,参加到这场寰球购物狂欢节中。联华华商旗下的世纪联华超市近期迎来了一年一度的 “双11” 大促流动。 时光回到 2014 年的 双12,支付宝联结杭州多家线下品牌和商场门店,推出五折优惠促销流动。在这一次生产狂欢中,滨江区世纪联华店所有的柜员 POS 机前排起了长队,队伍挪动速度异样迟缓,商场工作人员示意,服务器出现异常导致领取出了问题。 6 年后的明天,眼帘再次回到世纪联华超市 双11 大促现场,人潮涌动,却颠三倒四。参加大促的人数是 6 年前的几倍,但现场领取却稳固又顺滑,这种天壤之别的转变,源于世纪联华对云原生技术的大胆尝试。 世纪联华大促现场 技术架构演进之路咱们有幸采访到世纪联华的技术人员,理解到世纪联华在技术架构演进一路走来的不容易。 2014 年及以前:物理单机架构的劫难过来所有 POS 机及会员卡领取机器全副部署在各个门店,这套架构继续了近十年之久。 这套架构的最大益处是不受网络影响,在当年网络根底建设还不欠缺的状况下,商家能够尽最大可能地保障单个门店的交易稳定性不受外界影响。这套架构的最大问题是:当门店机器呈现故障时,业余的技术管理员很难第一工夫赶到现场及时修复,系统维护工作变得十分困难。 2014 年世纪联华的 双12 流动中,因为业务遭逢爆炸性流量,多个门店领取时好时坏,短时间也无奈保护,导致用户体验差,这让世纪联华的技术人信心改良这套应用了十多年的老零碎。 2014~2018 年:地方机房部署架构的演进在 2014 年经验了 双12 大促流动的问题后,联华技术人信心改良各项零碎,于是将交易系统和会员零碎陆续迁徙到自建的地方物理机房,商品零碎也改迁为地方下发机器,在浙江省各个门店的 POS 机,通过互联网连贯至地方机房。 相比 2014 年以前的架构,新架构次要解决了三个问题: 问题修复可集中保护解决商品调整价格下发全走网络数据能够集中查问统计然而新架构遗留的最大的问题是: 管理人员须要把握所有机器细节运维过程中可能呈现宕机、断网等事件,考察绝对艰难,应急解决计划单薄2018 年~2019 年年中:全面上云随着国内公共云建设的进一步倒退,世纪联华也开始全面应用阿里云产品,将本地业务包含 MySQL 等全副迁徙到了阿里云 ECS 上。 全面上云很好地应答了宕机、计算节点断网等事件的产生,这也动摇了世纪联华应用阿里云的信心。 然而业务急剧的扩大,数据库的查问写入越来越多,全面上云的架构在 2019 年中促销流动中,某台 16 核 32G 的 MySQL 数据库所在的 ECS ,因为会员查问业务实现未做好弹性扩容筹备,定时业务陡增导致申请提早微小,重大影响了用户体验。 ...

November 18, 2020 · 1 min · jiezi

关于云原生-cloud-native:云原生社区Meetup第一期-上海站招募

11月28日,咱们将邀请到云原生社区创始人宋净超等技术专家,从最佳落地实际、不同场景技术改造、利用优化等方面和技术爱好者们一起论道云原生~ 如果你对云原生感兴趣,欢送大家文末扫码报名,一起来和小伙伴们交换互通哇~ [玫瑰]

November 18, 2020 · 1 min · jiezi

关于云原生-cloud-native:2019-年-CNCF-中国云原生调查报告

中国 72% 的受访者生产中应用 Kubernetes在 CNCF,为更好地理解开源和云原生技术的应用,咱们定期考察社区。这是第三次中国云原生考察,以中文进行,以便更深刻地理解中国云原生技术采纳的步调及如何在宏大且一直倒退的社区中赋能开发者并作出改革。本报告基于 2018 年 3 月和 2018 年 11 月公布的前两份中国报告。 https://www.cncf.io/blog/2018/03/26/cncf-survey-china/https://www.cncf.io/blog/2018/11/13/cncf-survey-china-november-2018/中国云原生考察的重点49% 的受访者在生产中应用容器,另有 32% 打算这样做。与 2018 年 11 月相比,这是一个显著的增长,过后生产中仅 20% 应用容器。72% 的受访者在生产中应用 Kubernetes,高于 2018 年 11 月的 40%。私有云的使用率从 2018 年 11 月的 51% 降落到了 36%,取而代之的是应用 39% 的混合新选项。CNCF 我的项目呈指数增长。CNCF 现有四个在中国诞生并在该地区更宽泛应用的我的项目:孵化阶段的 Dragonfly 和 KubeEdge,以及刚毕业的 Harbor 和 TiKV。2019 年中国云原生考察包含 300 名受访对象 - 其中 97% 来自亚洲,次要是中国。 容器应用咱们晓得容器曾经扭转了基于云的基础架构,然而在过来的一年中,容器在生产中的应用已成为常态。依据咱们今年初公布的 2019 寰球云原生考察,84% 的受访对象在生产中应用容器,使得容器在寰球范畴内无处不在。 https://www.cncf.io/wp-content/uploads/2020/08/CNCF_Survey_Report.pdf中国考察表明,只管中国的容器应用落后于寰球,但其势头正在加强。在中国考察中,将近一半(49%)的受访对象在生产中应用容器 - 从 2018 年 3 月考察的 32% 和 2018 年 11 月的 20% 跃升至更高水平。 ...

November 18, 2020 · 3 min · jiezi

关于云原生-cloud-native:Fluid-04-新版本正式发布支持数据预热优化小文件场景

作者 | 顾荣Photo Creidt @ 轻零 导读:为了解决大数据、AI 等数据密集型利用在云原生计算存储拆散场景下,存在的数据拜访延时高、联结剖析难、多维治理杂等痛点问题,南京大学 PASALab、阿里巴巴、Alluxio 在 2020 年 9 月份联结发动了开源我的项目 Fluid。近期 Fluid 0.4 版本正式公布,次要新增了以下四项重要性能,别离是: 通过 DataLoad 自定义资源,提供简略易用且可定制的数据预热能力加强海量小文件数据集的撑持能力,扩大 Fluid 对 AI 利用的反对场景凋谢 HDFS 文件系统兼容接口,反对 Spark 等框架的数据拜访反对多数据集单节点混合部署,适应生产环境中的共享集群环境Fluid 我的项目地址:https://github.com/fluid-cloudnative/fluid 与 Fluid 0.3 相似,上述性能的开发需要同样来自泛滥社区用户的生产理论反馈,此外,Fluid v0.4 还进行了一些 bug 修复和文档更新,欢送应用体验 Fluid v0.4!感激为此版本做出奉献的社区小伙伴,在接下来的版本性能迭代中,咱们会持续宽泛关注和驳回社区倡议,推动 Fluid 我的项目的倒退,期待听到大家更多的反馈!下文是本次新版本公布性能的进一步介绍。 反对被动的数据预热在进行 AI 利用的模型训练时,数据预热是一种常见的优化伎俩。数据预热是指在利用运行前,将利用所须要的数据事后从近程存储系统中拉取到本地的计算集群,供之后利用运行时应用。数据预热通过一种程序的、有规定的并行数据读取模式,防止了数据密集型利用间接生产近程存储系统数据时,因为随机数据读取造成的许多不必要的通信开销。 因而,在 Fluid 0.4 版本中,咱们实现了一个新的 Kubernetes 自定义资源 - DataLoad,以 Kubernetes 资源的形式为用户提供了申明式的 API 接口,以控制数据预热的相干行为。DataLoad 自定义资源的一个简略示例如下所示: apiVersion: data.fluid.io/v1alpha1kind: DataLoadmetadata: name: imagenet-dataloadspec: dataset: name: imagenet namespace: default另外,通过大量的额定配置,DataLoad 还可实现子目录加载、缓存正本数量管制、元数据同步等许多可定制的性能,更多与 DataLoad 应用相干的细节请参考 Github 上的示例文档。 ...

November 17, 2020 · 1 min · jiezi

关于云原生-cloud-native:KubeCon-北美前瞻|在-2020-最后容器领域有哪些值得你关注的话题

起源 | 阿里巴巴云原生公众号 走过了技术和理念被宽泛承受的期间,2020 年对于云原生的利用和倒退尤为要害。 在刚刚过来的 双11,阿里巴巴落地了寰球最大规模的云原生实际,通过外围零碎的全面云原生化,使底层硬核技术降级带来了磅礴能源和极致效力:每万笔峰值交易的 IT 老本较四年前降落了 80%。这样的标志性事件让咱们看到,来到 2020 年,更多的企业开始关注云原生为业务带来的真正价值,越来越多的从“上云”到“云上”的云原生架构转型落地实际正在演出。 以容器、Kubernetes、Serverless、微服务等为基石的云原生技术之所以可能失去疾速倒退并在企业中被广泛应用,离不开凋谢、规范的思维,以及开源社区和宽广我的项目贡献者的力量。 作为引领云原生技术倒退的风向标,由 CNCF (Cloud Native Compute Foundation)举办的 KubeCon + CloudNativeCon 始终是连贯全世界云原生开发者的重要阵地,也是寰球云计算首领共话云原生将来方向的舞台。北美工夫 2020 年 11 月 17 日 - 20 日,来自当先的开源和云原生社区采纳者、技术人员将再一次在线上汇聚。为了保障参会用户在虚构会场可能取得更好的学习和体验成果,2020 北美 KubeCon + CloudNativeCon 对议题品质的审核十分严苛,以确保每一场演讲和教程的价值。而在此次流动上阿里巴巴将带来 7 场围绕容器、Kubernetes、社区倒退方向的演讲和分享,无论是分享数量、嘉宾分量还是话题品质,都再一次成为吸引寰球眼光的中国云原生技术力量焦点。 上面就让咱们先睹为快,看看在 2020 北美 KubeCon + CloudNativeCon 上阿里巴巴有哪些值得关注的话题、嘉宾和分享环节。 KubeVela:混合云环境下的标准化云原生利用交付零碎分享嘉宾:邓洪超,阿里云高级技术专家今日咱们听到不少用户呐喊:“为何在 Kubernetes (K8s) 上部署利用如此艰难?”从设计实质上,K8s 是一个基础架构平台 -- 它封装了基础架构层能力,然而却并没有解决应用层的形象和治理问题。这就导致在不同的 k8s 集群中部署利用的定义是不统一的、针对利用的运维能力形容是不统一的,使得不同环境下用户无奈对立“利用”语言,体验割裂且应用艰难。 为了解决这个问题,咱们须要一个规范的利用模型和形象来弥合利用治理与基础架构之间的鸿沟。在这场分享中,阿里云高级技术专家邓洪超将介绍凋谢利用模型(OAM)以及它的实现我的项目 KubeVela,以及如何以平台无关的形式在不同的环境下以对立的定义来部署和治理利用。他将带来对于 OAM 和 KubeVela 的技术细节解说,以及探讨如何联合云服务和已有的开源我的项目来减速推动跨环境下的标准化利用治理。 如何基于 Kubernetes 和 KubeVela 对立治理云原生利用和云服务分享嘉宾:孙健波,阿里云技术专家随着 K8s 体系不断完善和成熟,基于 K8s 的利用开发实际越来越广泛。而对于利用开发和运维人员来说,想要编排和应用云资源是一件十分艰难的事件,通常须要破费十分多的精力在不同云产品控制台中逐个创立云服务并别离进行配置。这里的问题从实质上来说就是云和 K8s 是两个不同的零碎,短少操作互通的局部。 ...

November 16, 2020 · 1 min · jiezi

关于云原生-cloud-native:重塑技术引擎-阿里落地全球最大规模云原生实践支撑双11

4982亿,2020年天猫双11再创生产新纪录。58.3万笔/秒,双11交易峰值再创新高,阿里云又一次扛住寰球最大规模流量洪峰。这所有背地撑持的“技术引擎”又是如何为近十亿寰球购物者的狂欢提供着“无感知护航”? 近日,在阿里巴巴双11技术沟通会上,阿里云研究员、阿里云云原生利用平台负责人丁宇示意,往年双11实现了外围零碎全面云原生化的重大技术冲破,实现资源效率、研发效率、交付效率的三大晋升,万笔交易的资源老本4年降落80%,研发运维效率均匀增效10%以上,规模化利用交付效率晋升了100%。阿里巴巴在2020双11实现了寰球最大规模的云原生实际。 阿里云研究员,阿里云云原生利用平台负责人丁宇 与2019年全面云化相比,2020年全面云原生化革命性重构了双11“技术引擎”。从产品和技术两方面来看,产品侧,阿里云通过提供容器服务ACK、云原生数据库PolarDB/Redis、音讯队列RocketMQ、企业级分布式应用服务EDAS、微服务引擎MSE、利用监控服务ARMS等数十款云原生产品全面撑持双11。技术侧,云原生四大核心技术实现规模和翻新的双重冲破,成为从技术能力向业务价值成绩转变的样本: 反对寰球最大容器集群、寰球最大Mesh集群,神龙架构和ACK容器的组合,能够实现1小时扩容1百万个容器,混部利用率晋升50%,万笔交易成本4年降落80%。领有国内最大计算平台、顶级实时计算能力。大数据平台批处理单日计算数据量达到1.7EB,实时计算峰值每秒30亿条记录;PolarDB读写性能进步50%+,计算资源利用率进步60%+。云原生中间件首次实现自研、商用、开源的“三位一体”,通过阿里云服务寰球客户。云原生中间件服务框架峰值调用量超百亿QPS。外围业务规模实际Serverless,弹性伸缩能力会晋升10倍,大幅晋升压测撑持效率和稳定性。云原生技术不仅在阿里外部大规模遍及,也正通过阿里云服务全社会的双11。大促期间,阿里云原生还撑持了中国邮政、申通快递、完满日记、世纪联华等客户,稳固高效应对双11大促的流量。以物流行业为例,申通快递将外围零碎搬到云上,采纳阿里云容器服务,亿级包裹过境,零碎稳如泰山,IT老本还升高了30%;以大型商超为例,世纪联华基于阿里云函数计算(FC)弹性扩容,业务峰值 QPS超过2019 年双11的230%,研发效率交付提效超过 30%,弹性资源老本缩小 40% 以上。 继9月云栖大会上阿里巴巴发表成立云原生技术委员会,云原生降级为阿里技术新策略。2020双11外围零碎全面云原生化,成为云原生技术委员会推动阿里经济体全面云原生化的重要里程碑。阿里巴巴团体首席技术官程立示意,云原生带来最大的不同是让阿里真正实现了自研、商用、开源的“三位一体”,双11的核心技术能够间接给到客户应用,省略了通过云上积淀再输入的过程,升高了客户获取“双11同款技术引擎”的门槛和老本,可帮忙客户疾速迈入数字原生时代。 阿里巴巴团体首席技术官程立 云原生是开释云计算红利的最短门路,也将成为全面上云的新底座。丁宇示意,“云原生是云计算的再降级,是真正意义的云技术反动,推动从Cloud Hosting演进到Cloud Native,从基于自有、关闭的技术体系,走向规范、凋谢公共的云技术体系。除了撑持双11之外,这些双11的同款技术也通过阿里云撑持全社会,成为数字新基建的基础设施。”

November 13, 2020 · 1 min · jiezi

关于云原生-cloud-native:效率提升一倍成本下降-80阿里云落地全球最大规模云原生实践

2020 天猫 双11 狂欢季成交额最终定格在 4982 亿,同比增长 26%。11 日 0 点 26 秒,阿里云扛住了 58.3 万笔/秒的订单创立峰值,但下单体验仍然丝般顺滑,背地的云原生技术功不可没。 据悉,本次 双11 外围零碎实现了全面云原生化,底层硬核技术降级带来了磅礴能源和极致效力:每万笔峰值交易的 IT 老本较四年前降落了 80%,规模化利用交付效率晋升了一倍之多,这也是寰球最大规模的云原生实际。 阿里云云原生利用平台负责人丁宇走漏,往年 双11 发明了诸多“云原生的第一次”:例如 80% 外围业务部署在阿里云容器 ACK 上,可在 1 小时内扩大超百万容器;首次大规模利用 Serverless,弹性伸缩性能晋升 10 倍以上;云原生中间件峰值调用量超百亿 QPS;云原生数据库 PolarDB 和云原生数仓 AnalyticDB 首次大规模利用,别离晋升 50% 读写性能和 100 倍 TPS…… 此外,计算的纪录也被一直刷新:实时计算 Flink 解决峰值达 40 亿条/秒,相似一秒看完 500 万本新华字典的所有信息;MaxCompute 单日计算数据量达 1.7 EB,相当于为寰球 70 多亿人每人解决 230 张高清照片;PolarDB 刷新解决峰值新纪录,TPS 高达 1.4 亿,比去年晋升 60%;AnalyticDB 解决了 7.7 万亿行实时数据,相当于 5.5 个国家图书馆的数据总量。 ...

November 12, 2020 · 1 min · jiezi

关于云原生-cloud-native:如何实现云原生这些云原生工具很关键

作者:Kentaro Wakayama翻译:Bach(才云) 校对:星空下的文仔(才云)、bot(才云) 在过来的十年中,云计算有了微小的增长。依据 Gartner 预测,2020 年寰球公共云服务市场将增长 17%,总额将达到 2664 亿美元,远高于 2019 年的 2278 亿美元。云计算使世界上一些大型公司重塑并主导其所在行业。这些公司的产品基于云服务,并利用云原生技术来比竞争对手做到更快,更具适应性。许多企业采纳了云原生技术,并将概念引入其外部部署应用程序。 理解和抉择正确的云原生技术对于进步开发速度、缩小开发和保护工具及基础架构至关重要。这篇文章形容了值得理解的云原生技术,并举荐了能够应用的云原生工具。 K8sMeetup 什么是云原生? 云原生对于速度和敏捷性,这是对于云的劣势,更快地解决业务挑战并升高 IT 老本。CNCF 提供了一个官网的定义: 云原生技术有利于各组织在私有云、公有云和混合云等新型动静环境中,构建和运行可弹性扩大的利用。云原生的代表技术包含容器、服务网格、微服务、不可变基础设施和申明式 API。这些技术可能构建容错性好、易于治理和便于察看的松耦合零碎。联合牢靠的自动化伎俩,云原生技术使工程师可能轻松地对系统作出频繁和可预测的重大变更。 简而言之,云原生的指标是依照业务需要,速度地向用户或客户交付软件产品。 云原生技术具备以下长处: 速度:疾速开发并部署云原生应用程序,缩短产品上市工夫。许多云应用云原生组件,以轻松托管应用程序。可扩展性和可用性:解决 100 个客户的云原生应用程序能够无缝扩大到服务数百万个客户。资源能够做到始终适应需要,与传统的动态扩大资源相比,这样无疑节俭了资金。此外,诸如主动故障转移和蓝绿部署的技术也已被植入云原生工具中。品质:开发云原生应用程序时要牢记不可变性(immutability)和去耦性,这能够进步应用程序健壮性并易于保护,从而晋升软件品质。因为云原生技术是开源的,并由 CNCF 反对,因而公司能够防止供应商锁定,并从社区的保护和开发工作中受害。K8sMeetup 如何实现云原生 要迁徙到云原生零碎,咱们须要一种相似以下的结构化办法: 纵向:抉择一项不是要害的服务,而后将其启动,迁徙到云原生技术上。横向:专一于单个云原生性能,例如继续集成(CI)或继续交付(CD),并将其部署在所有现有服务中。抉择非关键工作零碎能够升高危险,同时最大水平进步胜利迁徙的几率。 K8sMeetup 云原生工具 以下是云原生工具的列表,利用全套工具的公司通常领有更快的速度、更少的阻力以及更低的开发和保护老本。 微服务(Microservice) 微服务将产品性能划分为能够独自部署的单元。例如,在传统的部署中,通常只有一个网站服务来治理 API 和客户交互。应用微服务,咱们能够将该网站合成为多种服务,例如结帐服务和用户服务,而后别离开发、部署和扩大这些服务。 此外,微服务通常是无状态的,利用十二因素利用(twelve-factor application)可充分利用云原生工具提供的灵活性。 举荐技术:Node.js代替技术:Kotlin,Golang继续集成、继续部署(CI/CD) CI/CD 是基础架构组件,它反对自动测试执行(以及可选的部署),以响应版本控制事件(例如拉取申请和合并)。CI/CD 使公司可能施行质量检验,例如单元测试、动态剖析或安全性剖析。CI/CD 是云原生生态系统中的根底工具,能够进步工程效率并缩小谬误。 举荐技术:Gitlab CI/CD代替技术:Github Actions容器 容器是云原生生态系统的外围,可通过简化开发人员操作来实现速度和品质的晋升。通过将容器与诸如 Docker 之类的工具一起应用,团队能够指定其零碎依赖性,同时提供对立且通用的执行层。该层使基础架构团队可能操作单个基础架构,例如容器编排工具(如 Kubernetes)。团队能够将容器镜像存储在容器注册表中,大多数状况下,该注册表还会提供破绽剖析和细粒度的访问控制。 举荐技术:Docker代替技术:Podman、LXD容器编排 容器编排工具用于启动和治理大量容器并打消特定语言或特定团队的部署策略。它们容许用户指定容器镜像、镜像组以及一些配置。编排人员采纳这些标准并将其转换为正在运行的工作负载。容器编排工具使基础架构团队可能保护单个基础架构组件,该组件能够执行任何合乎 OCI 标准的容器。 举荐技术:Kubernetes代替技术:Google Cloud Run基础架构即代码(Infrastructure as Code) 基础架构即代码是一种将云配置置于版本控制之下的策略。公司通常通过治理面板进行配置来手动治理云资源,但手动配置的跟踪更改十分艰难。基础架构即代码通过将云资源定义为代码并将其置于版本控制之下来解决此问题。在代码中对基础架构配置进行更改,并通过公司的部署过程来进行更改,其中能够包含同行评审(peer review)、CI/CD。版本控制提供了一个审核日志,该日志显示谁更改了资源、更改了哪些资源以及何时进行了更改。 举荐技术:Terraform代替技术:PulumiSecret ...

November 12, 2020 · 1 min · jiezi

关于云原生-cloud-native:12-Factor-App-in-Action-12要素应用实战

发现一些老铁在构建容器或应用 kubernetes 中还有些不得要领, 于是我联合本人的教训和思考, 把 "CloudNative 圣经" 的 12 Factor App 从新解读了一下, 全文如下: 首先首先确保你曾经仔细阅读了 12 Factor App 的原文: 12 Factor App 中文.12 Factor App in English.而后本文次要是依据我的一些实践经验和思考来解释, 为什么应用容器化或 CloudNative 或 k8s 要恪守 "12 Factor" 中的因素来构建利用. 咱们逐条来1. 基准代码 (一份基准代码, 多份部署)What基准代码讲的是, 须要有个外围的代码库来存储所有版本. How简略来讲, 就是你须要用 Github, 或公有采纳 Gitlab 这样的集中化计划来治理你的代码. Why集中化意味着方便管理, 试想一下你刚上线的业务忽然产生了问题, 你得 BOSS 认为对着你吼就能给你加个 Buff 让你智力+10 从而能迅速修复 Bug. 不堪重压的你间接连贯到了线上服务器手动修改了问题. 就在这所有平息之后, 度过周末的你实现了新的性能, 遗记了线上有个飞天补丁在运行, 间接上线了新的版本笼罩掉了这一修改, 就在你公布结束的一刹那, 你听到了你的 BOSS 收回了如同被人踢到了蛋的吼声后朝你走来... 别缓和, 归根结底, 这即是你的问题, 又不是你的问题, 你可能违反了公司的上线流程, 但也裸露了公司自身治理上的破绽. Anyway, 罗嗦了这么一大段就是为了通知你有基准代码的益处. ...

November 11, 2020 · 4 min · jiezi

关于云原生-cloud-native:我对云原生软件架构的观察与思考

作者 | 易立  阿里云资深技术专家 本系列文章: 第一篇 - 云原生基础设施 第二篇 - 云原生软件架构第三篇 - 云原生利用交付与运维体系前言在《解读云原生基础设施》一文中,咱们谈到了云原生计算蕴含三个维度的内容:云原生基础设施,软件架构和交付与运维体系,本文将聚焦于软件架构层面。 “Software architecture refers to the fundamental structures of a software system and the discipline of creating such structures and systems. ” - 维基百科集体了解,软件架构次要指标是解决下列挑战: 管制复杂性:因为业务的复杂性,须要咱们用更好的伎俩帮忙研发组织克服认知障碍,更好的分工协作。分而治之,关注点拆散等伎俩皆是如此。应答不确定性:业务在疾速倒退,需要在一直变动。即便再完满的软件架构,然而随着工夫的推移,团队的变动,软件架构的调整不可避免。读《设计模式》,《微服务设计》等书字里行间写的都是“解耦”两字,让咱们关注架构中确定性和不确定性的拆散,晋升架构的稳定性和应变能力。治理系统性危险:管理系统中的确定性以及不确定性危险,躲避已知陷阱,对未知的危险做好筹备。云原生利用架构的指标是构建松耦合、具备弹性、韧性的分布式应用软件架构,能够更好地应答业务需要的变动和倒退,保障系统稳定性,本文将分享一下在这个畛域的察看和思考。 缘起 - 12 因素利用2012 年,Heroku 创始人 Adam Wiggins 公布十二因素利用宣言。它为构建一个优雅的互联网利用,定义了须要遵循的一些根本准则和方法论,也宽泛影响了泛滥的微服务利用架构。十二因素重点关注:应用程序的健康成长,开发者之间的无效的合作,以及防止软件架构腐化的影响。其内容在明天也值得每个同学认真领会。 图片起源:https://12factor.net/zh_cn/ 12 因素利用为咱们提供了很好的架构领导,帮忙咱们: 构建程度伸缩的弹性利用架构,更好撑持互联网规模利用。晋升研发流程的标准化、自动化程度,晋升研发效率。缩小开发环境和生产环境的差别,并应用继续交付施行麻利开发。晋升利用的可移植性,适宜云化部署,升高资源老本和治理复杂性。松耦合架构设计微服务的核心理念是,零碎中的各个服务可被独立开发、独立部署,独立降级,各个服务之间是松耦合的。云原生利用架构理念是进一步强调架构的松耦合,升高服务之间相互依赖的水平。 1. API 优先的利用架构设计在面向对象的软件架构中,最重要的是定义对象以及对象的接口契约。SOLID 准则是最被人广为熟知的设计准则: Single responsibility principle - 繁多职责准则Open/closed principle - 凋谢/关闭准则Liskov substitution principle - 里氏替换准则Interface segregation principle - 接口隔离准则Dependency inversion principle - 依赖翻转准则将以上五个准则的英文首字母拼在一起就是 SOLID 准则,这也是帮忙咱们构建高内聚,低耦合、具备柔性的利用架构。在散布式微服务利用架构中,API 优先是契约优先(Contract First)的天然拓展。 ...

November 11, 2020 · 4 min · jiezi

关于云原生-cloud-native:阿里云-Serverless-再升级从体验上拉开差距

差距都在细节上。  Serverless 要成就云计算的下一个 10 年,不仅须要在技术上继续精进,也须要在产品体验上精耕细作。 近日,阿里云 Serverless 再度降级,公布了一系列围绕产品体验方面的优化,包含函数计算 FC 全面融入容器生态,增加容器镜像的触发;发表开源国内首个 Serverless 开发者平台 Serverless Devs,帮忙开发者实现一键体验多云产品,极速部署 Serverless 我的项目;SAE 提供了 QPS/RT 维度的弹性策略配置,减少了限流降级等企业级个性,强化了利用的全生命周期治理;Serverless 事件总线 EventBridge 重磅公布,以标准化的 CloudEvents 1.0 协定帮忙用户轻松构建松耦合、分布式的事件驱动架构。 函数计算 FC + 容器技术,1 + 1 > 2体验上有门槛? 函数计算的劣势不言而喻,它帮忙开发者承当了大量简单的扩缩容、运维、容量布局、云产品买通集成等责任,使得开发者能够专一业务逻辑、进步交付速度 (Time-to-market) ,继续优化老本。但从传统利用迁徙到函数计算上仍面临诸多挑战,例如运行环境不对立、利用构建学习老本高、代码包服务限度、交付物不足版本治理、短少风行开源工具(如 CI/CD 流水线)的反对和集成等。 解法就在容器上! 容器的生态积淀十分丰盛且成熟,已被宽泛承受应用,并且利用容器化曾经成为开发和部署的事实标准。新版函数计算 FC 反对将容器镜像作为函数交付物,把容器优良的开发、部署、生态(上线前)和函数计算本身免运维、零闲置老本、云服务集成等个性(上线后)的个性相结合,全面降级开发者体验: 简化利用 Serverless 化:无需批改代码或是从新编译二进制、共享对象(*.so),本地调试,放弃开发和线上环境统一 更大函数代码限度:解压前镜像最大反对 1 GB(相比代码包最大解压前 50MB),防止代码和依赖拆散,简化散发和部署; 容器镜像分层缓存:增量代码上传和拉取,进步开发效率和升高冷启动提早; 镜像分享、复用:逻辑能够移植、缩小反复开发建设。 混合部署:同一利用 Serverfull (ECS,容器 ACK)、Serverless (FC,ASK,SAE),不同利用混合部署或同一利用不同服务间切流,达到性能统一、资源刚性交付、疾速扩容、运维最小化的均衡。 CI/CD:继续构建、集成测试、代码上传、存储和规范的版本治理,丰盛的开源生态 CI/CD 工具能够复用。 Serverless Devs,解 Serverless 工具链之困Serverless 的落地并不是单单一个商业化产品就能解决的,而是须要一整套工具链,因为 Serverless 波及利用的创立、我的项目的开发、测试,以及公布和部署等,是对整个开发运维我的项目的全生命周期治理。 ...

November 11, 2020 · 1 min · jiezi

关于云原生-cloud-native:Dubbogo-源码笔记二客户端调用过程

作者 | 李志信 导读:有了上一篇文章《Dubbo-go 源码笔记(一)Server 端开启服务过程》的铺垫,能够类比客户端启动于服务端的启动过程。其中最大的区别是服务端通过 zk 注册服务,公布本人的ivkURL并订阅事件开启监听;而客户应该是通过zk注册组件,拿到须要调用的serviceURL,更新invoker并重写用户的RPCService,从而实现对近程过程调用细节的封装。配置文件和客户端源代码1. client 配置文件helloworld 提供的 demo:profiles/client.yaml。 registries : "demoZk": protocol: "zookeeper" timeout : "3s" address: "127.0.0.1:2181" username: "" password: ""references: "UserProvider": # 能够指定多个registry,应用逗号隔开;不指定默认向所有注册核心注册 registry: "demoZk" protocol : "dubbo" interface : "com.ikurento.user.UserProvider" cluster: "failover" methods : - name: "GetUser" retries: 3可看到配置文件与之前探讨过的 Server 端十分相似,其 refrences 局部字段就是对以后服务要主调的服务的配置,其中具体阐明了调用协定、注册协定、接口 id、调用办法、集群策略等,这些配置都会在之后与注册组件交互、重写 ivk、调用的过程中应用到。 2. 客户端应用框架源码user.go: func init() { config.SetConsumerService(userProvider) hessian.RegisterPOJO(&User{})}main.go: func main() { hessian.RegisterPOJO(&User{}) config.Load() time.Sleep(3e9) println("\n\n\nstart to test dubbo") user := &User{} err := userProvider.GetUser(context.TODO(), []interface{}{"A001"}, user) if err != nil { panic(err) } println("response result: %v\n", user) initSignal()}在官网提供的 helloworld demo 的源码中,可看到与服务端相似,在 user.go 内注册了 rpc-service,以及须要 rpc 传输的构造体 user。 ...

November 10, 2020 · 7 min · jiezi

关于云原生-cloud-native:微服务框架-GoMicro-集成-Nacos-实战之服务注册与发现

作者 | 张斌斌 导读:本文次要介绍如何应用 Golang 生态中的微服务框架 Go-Micro(v2) 集成 Nacos 进行服务注册与发现。(Go-Micro 目前曾经是 v3 版本,但因为某些起因我的项目曾经更名为 nitro 具体起因大家能够去 github 中查看。)相干背景常识1. Go-MicroGo Micro 是一个基于 Go 语言编写的、用于构建微服务的根底框架,提供了分布式开发所需的外围组件,包含 RPC 和事件驱动通信等。 它的设计哲学是「可插拔」的插件化架构,其外围专一于提供底层的接口定义和根底工具,这些底层接口能够兼容各种实现。例如 Go Micro 默认通过 consul 进行服务发现,通过 HTTP 协定进行通信,通过 protobuf 和 json 进行编解码,以便你能够基于这些开箱提供的组件疾速启动,然而如果需要的话,你也能够通过合乎底层接口定义的其余组件替换默认组件,比方通过 nacos, etcd 或 zookeeper 进行服务发现,这也是插件化架构的劣势所在:不须要批改任何底层代码即可实现下层组件的替换。 1)Micro 概述Micro 是一个微服务工具包,包含: API提供并将 HTTP 申请路由到相应微服务的 API 网关。它充当微服务拜访的繁多入口,将 HTTP 申请转换为 RPC 并转发给相应的服务也能够用作反向代理。 WebUI 是 go-micro 的 web 版本,容许通过 UI 交互拜访环境。在将来,它也将是一种聚合微型 Web 服务的形式。它蕴含一种 Web 应用程序的代理形式。将 /[name] 通过注册表路由到相应的服务。Web UI 将前缀“go.micro.web。”(能够配置)增加到名称中,在注册表中查找它,而后将进行反向代理。 ...

November 9, 2020 · 3 min · jiezi

关于云原生-cloud-native:OpenYurt-深度解读如何构建-Kubernetes-原生云边高效协同网络

作者 | 郑超 导读:OpenYurt 是阿里巴巴开源的云边协同一体化架构,与同类开源计划相比,OpenYurt 领有可实现边缘计算全场景笼罩的能力。在之前的一篇文章中,咱们介绍了 OpenYurt 是如何在弱网和断网场景下实现边缘自治的。本文作为 OpenYurt 系列文章的第四篇,咱们将着重介绍 OpenYurt 的另一个外围能力——云边通信,以及相干组件 Yurttunnel。应用场景在利用的部署和运维过程中,用户经常须要获取利用的日志,或间接登录到利用的运行环境中进行调试。在 Kubernetes 环境中,咱们通常应用 kubectl log,kubectl exec 等指令来实现这些需要。如下图所示,在 kubectl 申请链路上, kubelet 将表演服务器端,负责解决由 kube-apiserver(KAS) 转发来的申请,这就要求 KAS 和 kubelet 之间须要存在一条网络通路,容许 KAS 被动拜访 kubelet。 图一:kubectl 执行流程 然而,在边缘计算场景中,边缘节点常位于本地专有网络中,这尽管保障了边缘节点的平安,但也造成位于云端管控节点的 KAS 无奈间接拜访位于边缘节点的 kubelet。因而,为了反对通过云端节点对边缘端利用进行运维操作,咱们必须在云、边之间建设反向运维通道。 反向通道Yurttunnel 是 OpenYurt 近期开源的一个重要组件,用来解决云边通信问题。反向通道是解决跨网络通信的一种常见形式,而 Yurttunnel 的实质就是一个反向通道。一个边缘集群上司的节点常位于不同的 network region 中,而位于同一个 region 内的节点之间是能够互相通信的,因而在设置反向通道时,咱们只需保障在每个 region 内设置一个与 proxy server 相连的 agent 即可(如下图所示)。具体包含以下几个步骤: 在管控组件所在网络内,部署 proxy server。proxy server 对外开放一个公网能够拜访的 IP。在每个 region 部署个 agent,并通过 server 的公网 IP 与 server 建设长连贯。管控组件对边缘节点的拜访申请都将转发致 proxy server。proxy server 再将申请通过对应的长连贯发往指标节点。图二 ...

November 9, 2020 · 4 min · jiezi

关于云原生-cloud-native:在大规模-Kubernetes-集群上实现高-SLO-的方法

作者 | 蚂蚁金服技术专家 姚菁华;蚂蚁金服高级开发工程师 范康 导读:随着 Kubernetes 集群规模和复杂性的减少,集群越来越难以保障高效率、低提早的交付 pod。本文将分享蚂蚁金服在设计 SLO 架构和实现高 SLO 的办法和教训。Why SLO? Gartner 对 SLO 的定义:在 SLA 框架下,SLO 是零碎必须要达到的指标;须要尽可能地保障调用方的胜利。有些人可能会对 SLI/SLO/SLA 有困惑,能够先来看下三者的关系: SLI 定义一个指标,来形容一个服务有多好算达到好的规范。比方 Pod 在 1min 内交付。咱们通常从迟延、可用性、吞吐率及成功率这些角度来制订 SLI。SLO 定义了一个小指标,来掂量一个 SLI 指标在一段时间内达到好的规范的比例。比如说,99% 的 Pod 在 1min 内交付。当一项服务颁布了其 SLO 的当前,用户方就会对该服务的品质有了冀望。SLA 是 SLO 衍生进去的协定,罕用于 SLO 定义的指标比例没有实现时,服务方要赔多少钱。通常来说,SLA 的协定会具体白纸黑字造成有法律效率的合同,罕用于服务供应商和内部客户之间(例如阿里云和阿里云的使用者)。一般来说对于外部服务之间的 SLO 被突破,通常不会是经济上的抵偿,可能更多的是职责上的认定。所以,咱们在零碎外部更多关注的是 SLO。 What we concern about Larger K8s Cluster? 随着生产环境一直倒退、K8s 集群越来越简单、集群规模一直增大。如何保障大规模环境 K8s 集群的可用性?是摆在泛滥厂家背后的一个难题。对于 K8s 集群,咱们通常关怀以下几个问题: 第一个问题就是集群是否衰弱,所有组件是否失常工作,集群中 Pod 创立的失败数量有多少,这是一个整体指标的问题。第二个问题就是集群中产生了什么,集群中是否有异样产生了,用户在集群中做了些什么事件,这是一个追踪能力的问题。第三个问题就是有了异样后,是哪个组件出了问题导致成功率升高,这是一个起因定位的问题。那么,咱们该如何解决下面的问题呢? 首先,咱们要定义一套 SLO,来形容集群的可用性。接着,咱们必须有能力对集群中 Pod 的生命周期进行追踪;对于失败的 Pod,还须要剖析出失败起因,以疾速定位异样组件。最初,咱们要通过优化伎俩,打消集群的异样。SLls on Large K8s Cluster咱们先来看下集群的一些指标。 ...

November 6, 2020 · 2 min · jiezi

关于云原生-cloud-native:双十一购物节Nacos-140-Go-SDK-101发布

一年一度的双十一购物节又来了,不晓得小伙伴们有没有抢到想要的商品呢? 无论您是否“剁手”胜利,Nacos都为社区的各位奉上礼物庆贺双十一 -- Nacos 1.4.0和nacos-sdk-go 1.0.1正式公布。 Nacos 1.4.0这个版本次要变更为: 重构了naming模块的distro协定,并且下沉到了nacos-core模块。应用了jraft对旧的自实现raft协定进行了替换,进步性能和raft语义的准确性。对nacos所应用的http客户端进行了齐全地对立,并优化了一些http客户端的应用,缩小了连贯损耗,特地是CLOSE_WAIT连贯的数量。增加了一个独自批改服务元数据的BETA接口。修复了一些旧版本的bug并优化了控制台应用。具体的变更列表如下: [#1654] 修复内容高亮在配置详情页面有效的问题.[#2792] 记录操作时的用户信息当关上权限性能后。[#2835] 修复控制台不停loading如果没有该namespace的权限。[#2866] 修复客户端没有拜访 /nacos/v1/ns/operator/metrics权限的问题。[#3117] 优化外部事件机制并下沉到nacos-common模块。[#3192] 对立nacos服务端的http客户端应用。[#3315] nacos客户端反对https。[#3397] 修复一些对于启动脚本的谬误。[#3384] 修复控制台对于raft信息显示不同步的问题。[#3500] 对立控制台中服务治理和配置管理的分页列表。[#3509] 修复应用地址服务器模式获取nacos集群地址时无奈获取nacos配置文件的问题。[#3518] 在绑定角色的时候用户列表改成下拉选中的模式。[#3530] 在控制台的页面中增加刷新按钮来刷新列表。[#3533] 批改客户端缓存目录配置。[#3515][#3536][#3899] 降级依赖修复安全漏洞。[#3528] 修复客户端会获取到有效的project.version。[#3550] 修复服务端无奈创立raft协定的长久化文件的问题。[#3560] 批改浏览器标签页上的nacos logo。[#3566] 从nacos-config模块中下沉权限相干内容到nacos-auth模块。[#3576] 给NamingMaintainService增加生命周期相干接口。[#3592] 修复修复拜访无权限的名称空间时的谬误提醒。[#3628] 优化客户端更新不存在的订阅服务的频率。[#3635] 在nacos-naming模块应用Jraft替换自研raft协定。[#3651] 优化nacos服务端对http-client的应用以缩小CLOSE_WAI连贯的数量。[#3661] 优化应用Jraft时更新raft group的更新逻辑。[#3671] 挪动局部工具类到nacos-common模块复用。[#3676] 修复还原块在“内容比拟”页面中不起作用。[#3692] 重构nacos-naming模块中的Distro协定。[#3687] 校验服务名格局为Group@@ServiceName。[#3710] 修复公布服务会导致失落元数据中带有特殊字符的问题。[#3781] 修复服务实例可能间歇性掉线的问题。[#3790] 修复客户端可能产生的配置乱码问题。[#3815] 修复当客户端缓存存在中文时可能被截断的问题。[#3833] 修复新音讯告诉零碎在没有订阅者的时候抛空指针异样的问题。[#3855] 在控制台查看配置详情页面里增加上版本改变的展现。[#3904] 反对独自批改服务元数据内容的性能。[#3909] 修复nacos服务端无奈配置域名的问题。[#3973] 修复首次运行时,导入配置失败的问题。[#4110] 修复扩容集群时raft协定服务更新新节点的问题。Nacos Go SDK 1.0.1这个版本次要是修复了一些旧版本的bug以及减少客户端对于https的反对等等。 具体的变更列表请查看 https://github.com/nacos-grou... 社区随着Nacos 1.4.0的公布, Nacos社区又新增了两位Committer:Maijh97 和 wangweizZZ。 两位别离在对立http client应用,下沉auth模块,客户端的https性能,重构局部服务端线程池和修复bug等内容中作出许多奉献,并积极参与社区探讨。 Nacos社区欢送更多违心参加共建的小伙伴退出,包含但不限于: 源代码文档社区探讨多语言实现周边生态产品联合积极参与将能够取得Nacos社区赠送的精美小礼品~ ...

November 6, 2020 · 1 min · jiezi

关于云原生-cloud-native:云湖共生下一代数据湖来了

简介: 导语:利用导向出现数据价值,阿里云在数据湖上的翻新实际,撑持起数据疾速洞察和数据输入迭代。 导语:利用导向出现数据价值,阿里云在数据湖上的翻新实际,撑持起数据疾速洞察和数据输入迭代。 数据湖并非新概念,最近又被越来越多的人提及,成为新晋网红,并呈现出千人千面的景象。在往年云栖大会上,当云原生数据湖体系在线上正式公布时,就吸引了企业的关注。如果不是2020非凡期间,在10月23日举办的线下“数据湖高峰论坛规模预计会扩充几倍。在阿里云智能存储产品资深总监陈起鲲看来,线下数据湖高峰论坛提供了与用户更多的间接互动交换机会,他心愿“云原生+数据湖仓共生”给更多企业带来的技术演进和技术价值。此时,阿里云公布的业内首个云原生企业级数据湖解决方案成为他们的新抉择,这套计划将大规模利用于往年双11,撑持阿里巴巴经济体及百万客户全面上云。 数据价值的两极化 2020年,数据量持续爆发式增长,数字化转型再次成为行业的热点,咱们能够切身感受到基于云计算、大数据、AI的“新基建”带来的社会效应。数据须要更深度的价值开掘,在陈起鲲看来,数据的价值出现两极化的特色,一是及时发现,实时剖析疾速促成业务倒退;二是长期寄存,数据累积起来,摸索数据后暗藏的法则,对立剖析其价值,为业务倒退提供参考。新的数据价值给企业带来更多智能翻新利用,比方增长黑客、举荐零碎,用户行为剖析,AIoT带来的更多模型,这也意味着IT基础设施的改革。以往的计算和存储耦合的架构就会出现资源利用率非常低的情况,数据是一直累积、一直增长,但计算的算力要求可能是峰谷,为了存储更多的数据购买更多的计算,扩容的时候必须一起扩容,最终导致稳定性不是最优,两种资源无奈独立扩大,应用老本也不是最优。当然,在传统架构中,原始数据对立寄存在HDFS零碎上,引擎以Hadoop和Spark 为主,受到开源软件自身能力的限度,传统技术无奈满足企业用户在数据规模、存储老本、查问性能以及弹性计算架构降级等方面的需要。 从新定义下一代数据湖 数据湖尽管是存在很久的概念,但最近一直被提及的要害还在于利用需要,随着企业业务演进,须要更低廉的数据存储老本、更精密的数据资产治理、可共享的元数据、更实时的数据更新频率以及更弱小的数据接入工具,基于此,阿里云正式公布了云原生企业级数据湖解决方案。 数据湖对立存储用云上对象存储OSS取代HDFS,晋升数据规模、升高存储老本、实现计算和存储拆散架构;数据湖构建(DLF)服务提供对立元数据和对立的权限治理,反对多套引擎接入;EMR上Spark等计算引擎的云原生化,能够更好的利用弹性计算资源;云上的数据开发治理平台 Dataworks解决了数据湖元数据治理、数据集成、数据开发等问题。 在陈起鲲看来,阿里云云原生的数据湖解决方案从新定义了下一代数据湖体系,更具备企业个性。首先必须承载挪动互联网、IoT业务的外围生产环境。对于企业而言,新的互联网利用的生产环境,必须是企业级的生产环境。由挪动利用或社交媒体利用产生的PB级数据,搬到剖析引擎进行实时剖析是不可能的,必须在生产环境中进行大数据分析。其次必须有承载EB级别的数据量的数据湖。通过阿里云对象存储OSS作为大数据存储,大文件刹时Rename、 缓存减速等都不是问题。同时要做到与业务强耦合的数据实时剖析,须要有弹性的算力,还要有弹性性能SLA的保障,阿里云对象存储 OSS 是数据湖的对立存储层,因为存算拆散的架构,能够抉择不一样的计算引擎,同时可存储任意规模的数据,非常适合企业基于OSS构建数据湖。另外在这次论坛中,阿里云还公布了OSS加速器,不同与基于传统集群自建的缓存,OSS加速器弹性伸缩,其可能每TB提供200MBps的吞吐能力,线性扩大,随时能够开启。同时,基于OSS智能元数据架构,OSS加速器提供了传统缓存计划不具备的一致性,当OSS上文件被更新时,加速器能自动识别,确保引擎读取到的都是最新数据。再者必须是平安的寄存、对立的治理,确保业务平安和数据安全。阿里云全链路加密、云上多层爱护,自带进攻性能这些都能够保障云上数据的安全性,再加上寰球部署的集群、端到端的CRC和被动排查故障的硬件能力,互联网利用的生产环境确保业务平安。 管得住、用的上、用的好 数据在哪里,剖析就在哪里,如何存储和剖析数据,从数据当中提取出法则和价值,阿里巴巴团体副总裁、阿里云智能计算平台事业部负责人贾扬清认为,管得住、用得上,用的好,这是阿里云构建数据湖体系的外围,这些都来自于客户现场的实在需要。 管得住数据指的就是通过OSS构建数据湖,通过治理元数据可能让咱们晓得数据在什么中央,在将来面向海量数据的数据湖场景下,对象存储OSS非常适合企业构建海量、高效、平安的数据湖。用得上数据须要通过多样化计算引擎,无论是传统的、开源的引擎还是阿里云通过本人的利用构建的横向计算引擎,可对接业务利用、各类计算剖析平台,让用户更容易的用上数据。数据湖的对接次要体现在元数据与存储引擎两个方面,元数据为所有用户所共享,提供对立的元数据拜访接口,各个引擎应用定制化的元数据拜访客户端来拜访元数据,元数据服务为各个用户提供租户隔离保障和认证鉴权服务。阿里云数据湖OSS和数据仓库MaxCompute能够疾速实现企业想要的湖仓一体计划,实现了数据湖和数仓之间的无缝流转,对立智能化治理和调度,买通了数据存储和计算的不同的层面,极大的晋升了平台化服务能力,真正实现用的好数据。 全面向云原生演进 阿里巴巴团体副总裁、阿里云智能数据库产品事业部负责人李飞飞认为,从传统的自建数据分析系统、传统大数据平台、传统数仓、传统剖析型数据库等维度,到极致弹性、低成本、服务化这三个关键词定义的云原生数据库时代。具体来讲就是将Serverless、存储计算拆散、资源池化、容器化部署等技术整合起来,提供云原生的数据服务,升高了客户的门槛和学习老本。 与传统大数据解决方案不同的是,通过Serverless技术提供一键建湖,治理、建湖、计算剖析一体化的服务,采纳DLA对接OSS提供凋谢存储服务和凋谢剖析计算服务,多种数据源通过一键建湖的形式对原数据进行主动发现和治理,对下利用OSS提供低成本、高效能、强平安的云原生存储能力,对上通过数据湖治理以及缓存减速,以及利用社区的能力、缓存减速的能力,集成Spark和Crystal两种引擎提供交互式查问和简单的ETL计算剖析。用Serverless办法调用计算资源,企业在用DLA时真正做到对多元异构数据主动治理、主动发现、按需按量配置资源,尽可能降低成本。 眼下,IT零碎曾经从老本核心变为翻新核心,云和湖共生是下一代数据湖2.0的架构,咱们都熟知的英语学习平台流畅说从2016年上线高效AI英语老师,流畅说自主研发的APP定制板块中以人工智能课的模式推出,基于AI深度学习的自适应课程零碎,给用户系统化推出英语学习解决方案,截至到2020年6月30日,曾经累计大略504亿句的录音句子数量,用户的练习语音时长曾经累积到了37亿分钟。面临这么大的语音数据的挑战,流畅说在阿里云上基于OSS进行架构设计,确保数据存储的计划简略高效,基于阿里云的数据湖架构高效建设数据湖体系,撑持整个数据迭代。某国内出名社交游戏公司基于阿里云数据湖计划,通过日志服务SLS,将寰球数据实时采集加工后,投递到OSS对立存储。利用OSS海量弹性能力冷热分层,通过EMR和DLA对接OSS,搭建存算拆散的大数据架构,实现千万日活的玩家链路智能举荐实时剖析,实时渠道统计,精细化经营,帮忙公司晋升了30%的用户留存率。目前,已有几千家企业在阿里云上构建云数据湖,数据湖就应该是一直演进中、可扩大的大数据存储、解决、剖析的基础设施;以数据为导向,实现任意起源、任意速度、任意规模、任意类型数据的全量获取、全量存储、多模式解决与全生命周期治理;并通过与各类内部异构数据源的交互集成,反对各类企业级利用。着眼将来,如果是云原生的企业,能够享受到大数据分析的红利;对于更多企业而言,上云有不同阶段,须要云上数据湖和云下数据连通,通过混合云存储或者混合云产品把客户的线下数据和公共云的数据买通,对立在云端治理、对立分层,在云上对接不一样的计算引擎。在数据驱动的时代当中,阿里云将助力客户疾速迭代,协同翻新。

November 4, 2020 · 1 min · jiezi

关于云原生-cloud-native:解读云原生基础设施

简介: 云原生是云计算畛域的热点之一。就像 “一千个人眼里有一千个哈姆雷特”,大家对"云原生"的定义也见仁见智。本文将介绍云原生利用架构和生命周期治理的进化方向。 作者 | 易立  阿里云资深技术专家 导读:云原生是云计算畛域的热点之一。就像 “一千个人眼里有一千个哈姆雷特”,大家对"云原生"的定义也见仁见智。本文将介绍云原生利用架构和生命周期治理的进化方向。概述CNCF- 云原生计算基金会对于“云原生”的定义如下 : “云原生技术有利于各组织在私有云、公有云和混合云等新型动静环境中,构建和运行可弹性扩大的利用。云原生的代表技术包含容器、服务网格、微服务、不可变基础设施和申明式 API。 这些技术可能构建容错性好、易于治理和便于察看的松耦合零碎。联合牢靠的自动化伎俩,云原生技术使工程师可能轻松地对系统作出频繁和可预测的重大变更。 云原生计算基金会(CNCF)致力于培养和保护一个厂商中立的开源生态系统,来推广云原生技术。咱们通过将最前沿的模式民主化,让这些翻新为公众所用。” 在咱们的了解中,云原生计算蕴含三个维度的内容: 可编程的、动静的、弹性基础设施:反对公共云、专有云、边缘计算等不同环境。分布式应用架构:具备松耦合、可弹性扩大、高容错性等特点。翻新的利用开发、交付形式:基于自动化、可观测、可治理的软件交付流程,减速翻新效率的同时保障系统稳定性。接下来将以系列文章的模式,和大家分享阿里云容器服务团队在云原生计算畛域的摸索和思考。本文次要聚焦在云原生基础设施。 本系列文章: 第一篇 - 云原生基础设施 第二篇 - 云原生软件架构第三篇 - 云原生利用交付与运维体系云原生基础设施Gartner 将云原生基础设施划分成四大类: 咱们能够看到这几类基础设施,计算单元的粒度越来越细,也越来越多体现的云原生的特质: 模块化水平越来越高 - 自蕴含的利用打包形式,利用与底层物理基础设施解耦。自动化运维水平越来越高 - 自动化的资源调度和弹性伸缩能力,用户将关注点逐步聚焦到利用本身。弹性效率越来越高 - VM 能够实现分钟级扩容;容器能够实现秒级扩容;函数能够做到毫秒级扩容。故障恢复能力越来越高 - 随着零碎自愈性的加强,大大简化了利用架构容错的复杂性。为了更好地了解云原生计算呈现的时代背景,咱们必须要了解云计算的经济学根底与外围竞争力所在。 应“云”而生经济学家亚当·斯密提出:分工是社会倒退的必然,而且分工将极大的进步生产效率。 从经济学的角度来讲,云计算是 IT 产业倒退的必然阶段。互联网和挪动互联网时代的到来,减速了企业的数字化转型。云计算能够提供时刻在线的服务能力,并满足日益增长一直变动的计算需要。此外,云计算将 IT 服务的固定成本投入转化成为了可变老本,极大升高了翻新老本。在咖啡馆中,随处可见守业的青年人围坐在一起构画将来,是互联网和云计算让幻想变得触手可及。 云计算的规模经济云计算的经济学根底来自规模经济。直观上,批量洽购,带来更低的供应链老本;大型数据中心,升高经营老本。更重要的是,因为不同用户不同工夫的工作负载不同,能够利用规模劣势进行削峰填谷。联合自动化、智能化的供应链和经营体系,进一步晋升了硬件资产经营效率。云计算正如电力这样的公共服务基础设施,集中发电比每家每户自建发电机,有更低的老本和更高的效率。 此外,云计算是典型的平台型业务模式。随着规模的增长,会产生网络效应。提供为企业提供产品 / 服务的 ISV 与 SI,会更加青眼于那些领有更多用户的云平台。而用户会更加偏向于可能提供丰盛技术产品和服务撑持生态的云平台。随着云平台的成长,将对用户和生态产生更强的吸引力。 云计算的外围技术创新减速规模效应的造成。比方,计算资源池化与虚拟化技术,让利用和底层硬件资源解耦。一方面晋升资源利用率,升高计算成本;一方面晋升了资源的弹性供应,弹性成为差异化云基础设施和传统 IDC 的要害能力。 此外,在传统 IT 中,软件、硬件和服务由不同厂商拆散交付。而云计算将软件、硬件、服务一体化交付,极大升高了计算成本,晋升了交付效率,提供了翻新的技术能力。这外面有几个关键点: 软硬一体设计,能够针对规模和性能进行全栈优化,极大升高计算成本。而且因为云计算的规模效应,随着产量的减少,边际老本会拉低均匀制作老本。寰球支流云厂商都在 IDC 设计、网络、芯片等方向加大自研投入。以 API 形式交付 IT 能力,一方面可编程的基础设施极大晋升了 IT 的敏捷性,更好地反对业务敏捷性;一方面 API 能够更加不便地被集成到三方服务商的解决方案中,进一步减速规模效应产生。随着 IT 能力的规模化,一些数据化、智能化的翻新技术和业务模式逐步造成。比方 ECS 宕机预测和主动热迁徙,能够将虚拟机的 SLA 晋升到传统须要硬件冗余能力达到的稳定性规范;RDS 对数据库的主动优化和问题诊断,无需 DBA 的人力过多染指。云原生的崛起2013 年春,Docker 技术开源宣告了云原生计算的尾声。Docker 公司翻新地提出了利用打包标准 Docker 镜像,它将利用及其所有依赖项打包,从而使利用能够在不同的计算环境之间疾速、牢靠地运行。容器技术提供了一个优雅的形象,让开发所须要的灵活性、开放性和运维所关注的标准化、自动化达成均衡。容器镜像迅速成为了利用散发的工业规范。随后 Google 开源的 Kubernetes 因为其优良的开放性、可扩展性和沉闷的社区,在容器编排之战中怀才不遇,成为分布式资源调度和自动化运维的事实标准。Kubernetes 屏蔽了底层基础架构的差别,提供了良好的可移植性,能够帮忙利用统一地运行在不同的环境,包含数据中心、云、边缘计算等。 ...

November 4, 2020 · 3 min · jiezi

关于云原生-cloud-native:解读云原生基础设施

作者 | 易立  阿里云资深技术专家 导读:云原生是云计算畛域的热点之一。就像 “一千个人眼里有一千个哈姆雷特”,大家对"云原生"的定义也见仁见智。本文将介绍云原生利用架构和生命周期治理的进化方向。概述CNCF- 云原生计算基金会对于“云原生”的定义如下 : “云原生技术有利于各组织在私有云、公有云和混合云等新型动静环境中,构建和运行可弹性扩大的利用。云原生的代表技术包含容器、服务网格、微服务、不可变基础设施和申明式 API。 这些技术可能构建容错性好、易于治理和便于察看的松耦合零碎。联合牢靠的自动化伎俩,云原生技术使工程师可能轻松地对系统作出频繁和可预测的重大变更。 云原生计算基金会(CNCF)致力于培养和保护一个厂商中立的开源生态系统,来推广云原生技术。咱们通过将最前沿的模式民主化,让这些翻新为公众所用。” 在咱们的了解中,云原生计算蕴含三个维度的内容: 可编程的、动静的、弹性基础设施:反对公共云、专有云、边缘计算等不同环境。分布式应用架构:具备松耦合、可弹性扩大、高容错性等特点。翻新的利用开发、交付形式:基于自动化、可观测、可治理的软件交付流程,减速翻新效率的同时保障系统稳定性。接下来将以系列文章的模式,和大家分享阿里云容器服务团队在云原生计算畛域的摸索和思考。本文次要聚焦在云原生基础设施。 本系列文章: 第一篇 - 云原生基础设施 第二篇 - 云原生软件架构第三篇 - 云原生利用交付与运维体系云原生基础设施Gartner 将云原生基础设施划分成四大类: 咱们能够看到这几类基础设施,计算单元的粒度越来越细,也越来越多体现的云原生的特质: 模块化水平越来越高 - 自蕴含的利用打包形式,利用与底层物理基础设施解耦。自动化运维水平越来越高 - 自动化的资源调度和弹性伸缩能力,用户将关注点逐步聚焦到利用本身。弹性效率越来越高 - VM 能够实现分钟级扩容;容器能够实现秒级扩容;函数能够做到毫秒级扩容。故障恢复能力越来越高 - 随着零碎自愈性的加强,大大简化了利用架构容错的复杂性。为了更好地了解云原生计算呈现的时代背景,咱们必须要了解云计算的经济学根底与外围竞争力所在。 应“云”而生经济学家亚当·斯密提出:分工是社会倒退的必然,而且分工将极大的进步生产效率。 从经济学的角度来讲,云计算是 IT 产业倒退的必然阶段。互联网和挪动互联网时代的到来,减速了企业的数字化转型。云计算能够提供时刻在线的服务能力,并满足日益增长一直变动的计算需要。此外,云计算将 IT 服务的固定成本投入转化成为了可变老本,极大升高了翻新老本。在咖啡馆中,随处可见守业的青年人围坐在一起构画将来,是互联网和云计算让幻想变得触手可及。 云计算的规模经济云计算的经济学根底来自规模经济。直观上,批量洽购,带来更低的供应链老本;大型数据中心,升高经营老本。更重要的是,因为不同用户不同工夫的工作负载不同,能够利用规模劣势进行削峰填谷。联合自动化、智能化的供应链和经营体系,进一步晋升了硬件资产经营效率。云计算正如电力这样的公共服务基础设施,集中发电比每家每户自建发电机,有更低的老本和更高的效率。 此外,云计算是典型的平台型业务模式。随着规模的增长,会产生网络效应。提供为企业提供产品 / 服务的 ISV 与 SI,会更加青眼于那些领有更多用户的云平台。而用户会更加偏向于可能提供丰盛技术产品和服务撑持生态的云平台。随着云平台的成长,将对用户和生态产生更强的吸引力。 云计算的外围技术创新减速规模效应的造成。比方,计算资源池化与虚拟化技术,让利用和底层硬件资源解耦。一方面晋升资源利用率,升高计算成本;一方面晋升了资源的弹性供应,弹性成为差异化云基础设施和传统 IDC 的要害能力。 此外,在传统 IT 中,软件、硬件和服务由不同厂商拆散交付。而云计算将软件、硬件、服务一体化交付,极大升高了计算成本,晋升了交付效率,提供了翻新的技术能力。这外面有几个关键点: 软硬一体设计,能够针对规模和性能进行全栈优化,极大升高计算成本。而且因为云计算的规模效应,随着产量的减少,边际老本会拉低均匀制作老本。寰球支流云厂商都在 IDC 设计、网络、芯片等方向加大自研投入。以 API 形式交付 IT 能力,一方面可编程的基础设施极大晋升了 IT 的敏捷性,更好地反对业务敏捷性;一方面 API 能够更加不便地被集成到三方服务商的解决方案中,进一步减速规模效应产生。随着 IT 能力的规模化,一些数据化、智能化的翻新技术和业务模式逐步造成。比方 ECS 宕机预测和主动热迁徙,能够将虚拟机的 SLA 晋升到传统须要硬件冗余能力达到的稳定性规范;RDS 对数据库的主动优化和问题诊断,无需 DBA 的人力过多染指。云原生的崛起2013 年春,Docker 技术开源宣告了云原生计算的尾声。Docker 公司翻新地提出了利用打包标准 Docker 镜像,它将利用及其所有依赖项打包,从而使利用能够在不同的计算环境之间疾速、牢靠地运行。容器技术提供了一个优雅的形象,让开发所须要的灵活性、开放性和运维所关注的标准化、自动化达成均衡。容器镜像迅速成为了利用散发的工业规范。随后 Google 开源的 Kubernetes 因为其优良的开放性、可扩展性和沉闷的社区,在容器编排之战中怀才不遇,成为分布式资源调度和自动化运维的事实标准。Kubernetes 屏蔽了底层基础架构的差别,提供了良好的可移植性,能够帮忙利用统一地运行在不同的环境,包含数据中心、云、边缘计算等。 ...

November 4, 2020 · 3 min · jiezi

关于云原生-cloud-native:华为云创原会40技术精英论道云原生20

摘要:在这个全新时代,云原生技术如何与企业业务深度交融,如何施展出更大的价值?看40+技术精英齐聚“创原会”论道云原生2.0。以后云原生进入了技术与产业、生态大交融,规模化大倒退的新阶段,云原生技术须要与各行业的外围业务场景、外围诉求、以及各相干技术畛域更加严密的联合。 近日,华为云联结CNCF举办了首期“创原会·云原生技术精英沙龙”, 来自CNCF、中国信通院、Intel,以及互联网、金融、汽车、制作、新能源等行业的40多位云原生技术精英一起,探讨了以后云原生面临的问题,以及云原生2.0时代的倒退方向,旨在独特推动云原生技术和产业的成熟与标准化建设,让云原生更好的服务于企业。 云原生2.0时代 咱们还要做什么?华为云自2015年以开创会员的身份参加了云原生计算基金会的组建,在过来的这5年工夫里,华为云全面见证了云原生技术和产业的衰亡和倒退:开源我的项目能力的欠缺期、云原生产业的倒退与交融期,再到现在,云原生已被各行业宽泛承受,云原生的技术和产业倒退将进行全新的倒退时代——云原生2.0时代。在这个全新时代,云原生技术如何与企业业务深度交融,如何施展出更大的价值? 如何构筑更高效、更极致的企业IT基础设施? 容器技术实现了更小颗粒度资源分配和治理,在雷同规格的主机上,运行更多的业务过程,极大晋升了资源的利用率,然而,随着业务部署密度的减少,对主机的网络、存储都提出了更高的性能要求,同时,容器组件本身带来的资源损耗也逐渐降级,会占用大量服务器资源。来自Intel的专家杨爱林也提出了疑难:”咱们引入的这些中间层的软件无疑会消耗掉大量的硬件资源,有没有方法缩小因中间层软件引入带来的资源损耗?“ 如何建设企业新型多地多核心业务体系?两地三核心已成为各企业应答劫难危险、晋升业务体验的伎俩,随着业务的倒退,许多金融、互联网企业曾经开始着手构建多地多核心的业务架构,进一步晋升不同区域用户的业务体验。但因为以后各厂商不足对立的规范,企业实现对立多云治理难度微小,来自国内某在线教育机构的容器架构师指出:“不同的云目前在除了K8s之外仍存在着许多接口的不对立,比方跨云调度、跨云监控,如果云厂商不能对立,咱们也就无奈进行对立利用,心愿云原生能够推动这方面的建设,这样咱们后续跨云的体验更好一些。“ 如何进一步减速企业业务交付与麻利翻新?云原生产业的现有生态解决了无状态利用的疾速交付与翻新,然而,在面对企业简单的业务架构和分门别类的业务利用时,数据库、分布式中间件等组件如何疾速实现云原生化?同时,随着云原生产业与其它产业的穿插交融,在人工智能、大数据、边缘、物联网等产业利用越来越宽泛,如何更好的撑持并减速以上产业落地云原生技术的过程,构建对立的生态,也成为当下迫切需要解决的问题。有嘉宾指出,要实现疾速交付,不仅要解决基础设施的问题,还要从架构动手,解决利用如何疾速落地、问题如何疾速定位、解决,故障如何疾速复原等一系列问题。 云原生三大策略降级 减速技术落地和产业凋敝针对以上问题,华为云全联接2020正式公布了云原生2.0三大降级策略及云原生基础设施解决方案,为构建更高效的基础设施、多云多核心业务架构和丰盛的云原生利用生态提供了残缺的解决方案。 重定义基础设施 :华为云基于擎天架构实现了以利用为核心的资源调度,并且联合深度软硬协同技术,为企业提供极致性能、极优老本、极佳体验的云原生基础设施。例如,基于擎天架构独创的容器全卸载技术,容器集群资源利用率大幅晋升,可节俭30%资源老本;”新技术的利用,同样也为产业规范带来了新诉求,民生银行容器云负责人张立指出,“尽管软硬协同可能很好地晋升基础设施在性能、稳定性、平安等方面的指标,但对于接口的兼容性、标准化以及生态建设也提出了更高的要求,因而须要云原生行业增强单干并独特推动相干技术生态及接口标准化工作。“针对产业标准化的工作,华为云将从顶层架构、技术标准、产业落地规范等多个维度推出一系列白皮书,推动云原生基础设施产业标准化过程。 新赋能泛在利用:云原生技术以其规范、凋谢的劣势,曾经在一些多云业务场景下得以利用,华为流程IT容器架构师于明喆在分享中提到:“通过K8s平台的标准化,屏蔽了底层基础设施的差异性,研发团队无需感知后端的部署环境的变动,能够在寰球20+Region间实现灵便部署。”华为云基于云原生集群联邦技术打造的多云容器治理平台,实现了镜像跨云疾速散发、利用跨云调度、流量负载跨云分担、故障跨云一键式定位,能帮忙企业疾速构建多云业务,并简化多云环境下业务的运维复杂度。华为云云原生开源负责人王泽锋示意,”对于多云容器治理的钻研,华为云早在2015年就在Kubernetes社区发动了Federation我的项目,并于2018年率先推出了华为云多云容器平台。近期,咱们将继续把服务客户过程中的最佳实际回馈社区,并推动社区演进,让Federation提供与单集群始终的体验,升高客户实现多云治理的门槛”。 再降级利用架构:华为云针对客户利用架构降级的诉求,从开发工具、流程、迁徙、生态等方面动手,建设了一套残缺的解决方案,减速企业应用架构的云原生降级。某在线教育机构的容器架构师总结到:“咱们通过对无状态利用进行云原生革新,使得整个流程80%以上的场景都实现自动化;AI平台云原生化,使得离线计算工作的老本降落43%,而且实现全自动化,非常感谢华为云给咱们提供反对。”华为云打造的云原生利用核心OSC,已反对130+云原生利用,不仅蕴含微服务架构的无状态利用、分布式中间件、数据库等传统利用,还减少了AI、大数据以及边缘、5G、区块链等新型利用,帮忙企业自选式构筑“All in Container”的云原生业务架构,晋升业务的麻利创新能力。除此之外,华为云还提供了云原生数据库服务GaussDB、云原生分布式中间件服务,以满足不同企业的业务诉求。 华为云针对云原生2.0的策略降级,将进一步施展出云原生的劣势,让云原生为数字经济倒退和企业数字化转型开释更多价值! 点击关注,第一工夫理解华为云陈腐技术~

November 3, 2020 · 1 min · jiezi

关于云原生-cloud-native:Dubbogo-源码笔记一Server-端开启服务过程

作者 | 李志信dubbo-go 源码:https://github.com/apache/dubbo-go 导读:随着微服务架构的风行,许多高性能 rpc 框架应运而生,由阿里开源的 dubbo 框架 go 语言版本的 dubbo-go 也成为了泛滥开发者不错的抉择。本文将介绍 dubbo-go 框架的根本应用办法,以及从 export 调用链的角度进行 server 端源码导读,心愿能疏导读者进一步意识这款框架。下周将发表本文的姊妹篇:《从 client 端源码导读 dubbo-go 框架》。当拿到一款框架之后,一种不错的源码浏览形式大抵如下:从运行最根底的 helloworld demo 源码开始 —> 再查看配置文件 —> 开启各种依赖服务(比方zk、consul) —> 开启服务端 —> 再到通过 client 调用服务端 —> 打印残缺申请日志和回包。调用胜利之后,再依据框架的设计模型,从配置文件解析开始,自顶向下递浏览整个框架的调用栈。 对于 C/S 模式的 rpc 申请来说,整个调用栈被拆成了 client 和 server 两局部,所以能够别离从 server 端的配置文件解析浏览到 server 端的监听启动,从 client 端的配置文件解析浏览到一次 invoker Call 调用。这样一次残缺申请就清晰了起来。 运行官网提供的 helloworld-demo官网 demo 相干链接:https://github.com/dubbogo/dubbo-samples/tree/master/golang/helloworld/dubbo 1. dubbo-go 2.7 版本 QuickStart1)开启一个 go-server 服务将仓库 clone 到本地$ git clone https://github.com/dubbogo/dubbo-samples.git进入 dubbo 目录$ cd dubbo-samples/golang/helloworld/dubbo进入目录后可看到四个文件夹,别离反对 go 和 java 的 client 以及 server,咱们尝试运行一个 go 的 server。进入 app 子文件夹内,能够看到外面保留了 go 文件。 ...

November 3, 2020 · 6 min · jiezi

关于云原生-cloud-native:想成为全栈工程师要做到哪几点

导读:如何成为一名全栈工程师?须要具备哪些技术积攒?成为全栈工程师有哪些益处?心愿本文能为冀望成为全栈工程师的同学提供一点帮忙,和同学们一起分享交换。 作为开发者,咱们不适度辨别服务端 server 客户端 client,咱们是 web developer,从事 web 开发,多去了解技术和实际落地。成为全栈工程师的路线成为全栈工程师说不上难也说不上容易,其中技术积攒占了很大一部分: 1. 紧跟前沿把握足够多的输出。关注海内社区新音讯公布,业界的新产品新技术,学会高质量的获取信息,保持做和习惯做。 2. 重视学习 & 一直实际有属于本人的思考和谨严的产出。把握高效学习办法,比方咱们最近在做 K8s 容器集群相干的事件,须要了解底层设计和做集群调度,须要学习 Golang,新技术的学习过程: 投资一个好的 IDE,例如 Webstorm、Goland、IntelliJ IDEA 等,保持应用。认准官网文档,保持学习。API 手册查看,一直相熟和记忆。写学习总结,造成良性循环:定义性能 -> 代码设计 -> 实现性能 -> 重构优化 -> 优化代码设计 -> 实现 -> 重构 -> 残缺把握。总结:实际贵在保持,面对新的未知的畛域,也要迎难而上。 3. 器重基础知识 & 多做总结了解分明,事倍功半。例如作为 Web Developer: 必备常识:语言根底,Web 利用的根底,相熟 Linux 运行环境,网络传输过程 HTTP 协定,TCP 协定。进阶常识:相熟浏览器申请过程,Web Server 端口监听原理,数据库原理,浏览器申请原理,应用程序平安通信 TLS 协定,数据加密解密计划,数据签名计划。架构层面:利用分层模式,数据模型定义模式,微服务划分思路,零碎设计模式。4. 作为无线团队:收益最大的和最投资的局部把这些最常见的问题背地的原理了解分明,就能独立解决绝大多数问题,晋升全链路研发效率,和各个岗位的人沟通无障碍,合作无阻力。要做一件事件,出什么计划最合适,什么角色来做最适宜,采纳什么样的技术架构更适合: 语言是最根底的:HTML / CSS / Javascript / ECMAScript / Typescript / Node.js / Golang / Java 等。网络协议层 HTTP 协定,DNS,7 层 / 4 层负载平衡,这里会波及到服务端,前端,SRE,网络安全等各个岗位的基础知识。框架层原理和细节:利用框架 React/Koa/Spring,数据库框架,平安组件。联合公司技术体系衍生的框架层约定和业务框架:阿里/蚂蚁中间件。工程化 :CI/CD 继续集成,自动化测试,代码构建公布过程。基础设施 IaaS:公有云、混合云、私有云;AWS、阿里云等。对团队带来的价值: ...

November 3, 2020 · 1 min · jiezi

关于云原生-cloud-native:第-6-期-Arthas-征文活动开启内附第-5-期获奖名单

为了让更多开发者开始用上 Arthas 这个 Java 诊断神器,3 月 26 日,咱们联结 JetBrains 推出了第一期 Arthas 有奖征文活动:聊聊这些年你和 Arthas 之间的那些事儿。 一石激起千层浪,在前几期流动期间,咱们失去了泛滥开发者的积极响应,闻讯赶来投稿的同学川流不息。截止到当初,第五期征文活动已完结,本期流动共计 1 位同学获奖:刘慕雨。感激同学们的积极参与! 奖品阐明: 获奖同学将取得 Arthas Most Valuable User 福袋一份,蕴含阿里云定制雨伞、Arthas 贴纸、JetBrains 解压脑型球;除此之外,另送出蓝牙音响一台。 注:礼品将于开奖后 15 个工作日内收回,请急躁期待! 举荐应用 Arthas形式一:举荐应用 IDEA 插件下载 Cloud Toolkit 来应用 ArthasCloud Toolkit 是阿里云公布的收费本地 IDE 插件,帮忙开发者更高效地开发、测试、诊断并部署利用。通过插件,能够将本地利用一键部署到任意服务器,甚至云端(ECS、EDAS、ACK、ACR 和 小程序云等);并且还内置了 Arthas 诊断、Dubbo工具、Terminal 终端、文件上传、函数计算 和 MySQL 执行器等工具。不仅仅有 IntelliJ IDEA 支流版本,还有 Eclipse、Pycharm、Maven 等其余版本。 形式二:间接下载第六期征文活动开启第六期 Arthas 征文活动将于 10 月 30 日 - 11 月 30 日举办,后续征文活动将继续至 2020 年 12 月。参加即有机会拿奖,欢送大家持续踊跃投稿! ...

November 2, 2020 · 1 min · jiezi

关于云原生-cloud-native:网易数字云原生论坛中这些知识点80的企业都在关注但缺乏实践经验

信通院最新公布的《2020年中国云原生用户调查报告》中显示,2019年我国云原生产业规模已达350.2亿元,云原生曾经成为数字经济大潮下传统行业数字化转型的最新技术驱动力。10月24日,由网易旗下数字化转型根底软件提供商——网易数帆主办的网易数字+云原生论坛正是以“玩转云原生,拥抱数字化”为主题,独特探讨行业数字化转型最新趋势,研商新型数字技术倒退方向和利用前景。 网易轻舟云原生,构建企业数字化技术依据Gartner对数字化转型的定义,企业数字化转型业务模型有三个层面:面向经营的数字化转型,旨在进步企业经营效率升高经营老本;面向增长的数字化转型,可能帮忙企业业绩及利润增长;面向翻新的数字化转型,助力现有业务翻新和孵化翻新业务。基于此,企业数字化转型过程中面临着IT研发转型,IT架构转型,IT运维转型,IT组织转型等多方面的挑战。 网易轻舟资深解决方案架构师 袁梓超 网易数帆轻舟微服务平台正是源于为团体业务翻新提供IT撑持的技术积攒,堪称企业数字化转型的利器。据网易轻舟资深解决方案架构师袁梓超介绍,轻舟用到很多开源的分布式技术解决相应的问题,比方轻舟微服务架构对业务的拆分和治理,可能无效晋升迭代效率,从容应对流量峰值和业务翻新的需要;轻舟自动化的软件生产方式,可能帮忙企业疾速响应需要,及时匹配互联网热点;轻舟基于容器的AIOps运维体系,可能帮忙企业进步零碎稳定性,晋升用户体验。整体来看,就是通过利用的对立建设,造成数字化业务体系,达到数据化经营。 低代码升高IT压力,助力企业数字化建设 网易技术工程事业部业务撑持技术组技术经理 严跃杰 轻舟在服务企业客户时发现,企业在数字化转型过程中,存在大量的利用构建的需要,而这些需要远大于企业IT部门的产能,考察显示,有65%的企业存在需要积压的状况,86%的企业在寻找构建应用程序的技术人才。正是基于这样的背景,轻舟推出了低代码解决方案,蕴含了可视化开发,一键公布,利用一站式治理,开放式资产核心,代码主动生成5方面的外围能力。据网易技术工程事业部业务撑持技术组技术经理严跃杰介绍,轻舟低代码平台是基于微服务架构的低代码平台,能生产出真正代码级的应用程序,利用自身的可扩展性、开放性、可移植性、可靠性和性能都达到互联网利用的程度,技术上具备肯定的当先性。 制造业微服务实际,助力转型智能制作网易云计算技术部制造业资深架构师杨怅然以制作行业为例,分享了轻舟的解决方案。制作企业在向智能制作转型过程中,常会面临外围业务零碎的交互越来越频繁和简单的状况,产生精益生产、柔性生产、小批量多批次的业务要求,并且对系统性能迭代,流程变更,以及新技术、新零碎的集成接入要求越来越高。 网易云计算技术部制造业资深架构师 杨怅然 智能制作不只是业务打造信息化零碎,更是建设零碎间的高效合作,疾速应答业务产生的变动。轻舟为制作企业制订了整体的数字化零碎微服务革新策略,以封装或重构的模式,通过畛域驱动的微服务拆分,对立接口标准、简化利用集成,基于微服务共享能力减速业务开发,根底服务合并(中台化),能力凋谢五个步骤,从而实现业务零碎的服务化,进步IT部门的性能迭代效率和部署效率,扭转IT服务模式,最终实现网络化供应链协同。 华北区渠道合作伙伴打算公布,携手共创数字化将来 网易轻舟业务总监 汤忠 在本次大会上,网易轻舟还首发华北区渠道合作伙伴打算。据网易轻舟业务总监汤忠介绍,网易轻舟将在华北区全面开展渠道代理、解决方案、服务交付等多模式合作伙伴的招募,网易轻舟能为合作伙伴提供培训、市场、销售、返佣等全方位反对,单方以凋谢单干的态度,基于云原生技术为企业发明数字化价值。 “网易数字+”系列流动是网易数帆团队倾力打造的优质商业活动。该系列流动着眼于新型数字化技术演进,论述全球化趋势下网易对企业数字化转型的察看和思考,业余解读网易数字产业全新策略、企业数字化转型解决方案及最佳实际,为企业转型降级赋能。

November 2, 2020 · 1 min · jiezi

关于云原生-cloud-native:Serverless-对研发效能的变革和创新

作者 | 杨皓然(不瞋) 对企业而言,Serverless 架构有着微小的利用后劲。随着云产品的欠缺,产品的集成和被集成能力的增强,软件交付流程自动化能力的进步,咱们置信在 Serverless 架构下,企业的敏捷性有 10 倍晋升的后劲。本次分享我次要分为以下四个方面: 一、DevOps 的挑战以及如何升高 DevOps 施行代价?二、为什么 Serverless 是云倒退的必然结果?三、Serverless + DevOps =?四、实战案例分享 DevOps 的挑战1. DevOps 的挑战对于利用交付的整个流程而言,通常会波及三个环节,即开发、测试和运维,而在传统的组织架构中,他们对应的也往往是三个不同的团队。这三个环节各自有本人的侧重点,然而在实际上,想要让整个利用交付过程变得顺滑高效,并且让利用在上线后放弃高可用的状态,往往须要三个团队将相互之间存在的墙突破掉。 这里的墙不只是组织架构隔膜所带来的阻碍,还包含三个畛域关注点的不同。比方开发须要关注可测试性和可运维性,这些货色将会粗浅地影响利用的架构设计和开发实现,如果开发同学没有充分考虑到代码的可测试性,那么交给测试同学就会造成很大的问题,比方如何实现故障注入和精密流控,这都须要在开发时就思考分明。 对于运维而言也是一样的,开发的时候也须要思考到可运维性,比方在开发的时候就须要思考如何在服务实际上下线的时候做到平滑且不失落数据,同时这样的设计也须要和运维零碎进行粗浅的对接,这样能力十分牢靠、十分平安地连接起来,晋升运维的效率。 阿里外部之前很多故障也都是因为开发和运维之间在设计下面存在信息不统一导致的,比方在开发设计时会做三正本的高可靠保证,然而在运维侧则可能会认为正本所在的机器没有提供服务因而被谬误下线掉。 所以,DevOps 实际上蕴含了两层含意,首先是将开发、测试、运维变成一个团队;其次,还须要让整个团队的心智对立,这也是 DevOps 真正的挑战。 2. DevOps 的挑战 - 开发疾速回顾一下 DevOps 每个环节所须要思考的货色。在开发阶段,首先须要梳理业务的需要和场景,并且将需要转换为零碎设计,同时须要思考数据模型如何设计,才可能让数据库不成为单点和瓶颈。因为在阿里巴巴这样的互联网企业中,利用承载了大量的用户拜访,因而须要思考简单平衡、容错设计、流量管制等。 如果采纳了微服务架构,利用将由多个服务组成,那么还须要思考服务治理。以上全副思考到之后,将其转化为零碎设计,最初进行开发调试以及单元测试,实现了这些之后才能够将利用交给测试环节。 3. DevOps 的挑战 - 测试在测试时须要思考很多方面和维度,保障软件各方面的品质。测试包含了集成测试、端到端的 E2E 测试、性能测试、压力测试、容错测试、兼容测试、毁坏测试等。 4. DevOps 的挑战 - 运维当利用通过测试之后,就产出了一个交付物,这个交付物被认为具备了能够公布的能力,后续就须要进行运维工作了,比方利用灰度公布、降级回滚、服务器高低线、监控报警、安全补丁降级、网路配置、操作审计、生产环境引流等。 5. DevOps 的挑战 - 如何升高 DevOps 施行代价?当咱们深刻地看 DevOps 中所蕴含的这些工作项之后,其实可能感触到如果想要做一个具备弹性的、高牢靠的利用,须要思考的点是十分多的,而这些在施行了 DevOps 之后就变成了同一个团队在整个利用生命周期中须要思考的事件了。这对于团队心智和能力的要求是十分高的。 DevOps 利用交付流水线外面蕴含了很多环节,如何将这些环节十分流畅地串联起来,实现自动化也是十分重要的方面。 ...

October 30, 2020 · 2 min · jiezi

关于云原生-cloud-native:云原生时代应用架构将如何演进

作者 | 许晓斌  阿里云高级技术专家 导读:如何借助云原生技术来晋升交付速度?云原生时代背景下,研发的关注点又会有哪些转变?阿里云高级技术专家许晓斌通过本文分享从 IaaS 上云时代到 PaaS 上云时代的利用架构演进方向,以及云原生技术与利用架构演进的关系。云原生曾经进入了 PaaS 上云为主的阶段阿里巴巴曾经经验了 IaaS 上云的阶段,迈进到了 PaaS 上云的时代。在去年的“双11”,阿里巴巴就曾经实现了电商外围零碎的全面上云,这里的上云次要是在 IaaS 层。所谓 IaaS 次要就是对计算、网络、存储的虚拟化,通过了这个阶段,阿里巴巴就进入了 PaaS 上云的阶段。在 PaaS 上云这个阶段就须要应用更多的云产品,包含中间件、存储、缓存甚至是利用托管平台等。 IaaS 阶段和 PaaS 阶段其实存在很大的差异。在 IaaS 阶段,对于利用研发来说,所关怀的往往就是基础设施和资源,艰深来讲就是虚拟机或者容器等,这些对利用架构简直没有任何侵入。然而在 PaaS 上云阶段,当你应用云产品,比方云 Redis、云 RDS、云 OSS、云 RabbitMQ 等的时候,都会对于利用架构产生比拟强的侵入。那么,这样的侵入会对利用架构产生什么样的影响,是所有研发架构师所须要思考的一个问题。 云原生技术如果大家尝试去搜寻云原生技术,就会看到 Google Cloud 的定义、CNCF 的定义以及其余很多的云厂商以及开源软件的定义,而这些定义认识都各有不同。简略演绎能够分为如下图所示的几类,纵向来看,分为利用架构、生命周期治理、流量治理,以及基础设施及依赖四个维度;横向来看,又分为微服务、12 Factor Apps、容器、BaaS、GitOps/IaC 以及 Service Mesh 几个维度。 明天,大家都谈判到基于微服务架构做云原生,而不是基于巨石利用架构或者简略的 CS 架构。Quarkus 提出了 12 Factor Apps,意思就是说如果在明天想要让利用跑在 Quarkus 等这些利用托管平台上,对于利用具备肯定的要求,大略是 12 条准则,比方配置和代码拆散等,当然后续还有很多的扩大。这些准则中的很多条目标意思都是说只有你合乎这些准则,那么利用托管平台就可能为你提供更多的能力,比方免运维等。容器的外围是应用一种规范的交互方式让平台可能治理利用的生命周期,包含公布、扩容以及自愈等。 BaaS——Backend as a Service,可能尽量应用现有的服务来构建应用程序。Service Mesh 的实质是治理流量,明天的应用程序都在接管流量,提供服务时流量又须要进来,在这个过程中如何治理服务发现、流量路由规定等都须要 Service Mesh 技术。最初须要重点介绍的就是 GitOps 和 IaC(Infrastructure as Code),这些技术现在在行业外面失去了越来越多的关注,只管还没有事实上的规范,然而很多云计算公司正在一直致力。其含意是说明天在应用基础设施的时候,能够用代码去申明这些基础设施的需要。总而言之,上述这些内容都是围绕利用架构、生命周期治理、流量治理,以及基础设施及依赖这四个维度的。 ...

October 30, 2020 · 1 min · jiezi

关于云原生-cloud-native:OpenKruise解放-DaemonSet-运维之路

作者 | 王思宇(酒祝) 前言OpenKruise 是阿里云开源的大规模利用自动化治理引擎,在性能上对标了 Kubernetes 原生的 Deployment/StatefulSet 等控制器,但 OpenKruise 提供了更多的加强性能,如:优雅原地降级、公布优先级/打散策略、多可用区 workload 形象治理、对立 sidecar 容器注入治理等,都是经验了阿里巴巴超大规模利用场景打磨出的外围能力。这些 feature 帮忙咱们应答更加多样化的部署环境和需要、为集群维护者和利用开发者带来更加灵便的部署公布组合策略。 目前在阿里巴巴外部云原生环境中,利用全副对立应用 OpenKruise 的能力做 Pod 部署、公布治理,而不少业界公司和阿里云上的客户因为 K8s 原生 Deployment 等负载不能齐全满足需要,也转而采纳 OpenKruise 作为利用部署载体。咱们心愿 OpenKruise 让每一位 Kubernetes 开发者和阿里云上的用户都能便捷地应用上阿里巴巴外部云原生利用所对立应用的部署公布能力! 背景如何在 Kubernetes 集群中部署节点组件呢?置信大家对 DaemonSet 并不生疏,它可能帮忙咱们将定义好的 Pod 部署到所有符合条件的 Node 上,这大大加重了过来咱们保护节点上各类守护过程的苦楚。 在阿里巴巴外部的云原生环境中,存在不少网络、存储、GPU、监控等等相干的节点组件都是通过 DaemonSet 部署治理的。然而随着近两年 Kubernetes 集群规模越来越大,所有外围业务逐步全量上云原生之后,咱们越发感触到原生 DaemonSet 很难满足大规模、高可用的简单场景需要。 大家能够了解为原生的 DaemonSet 的确解决了 0 -> 1 的问题,防止了间接治理 Node 上各类软件包和守护过程的难题,能做到用统一化的 Pod 来部署节点组件。然而在部署之后呢?咱们面临的是 1 -> N 的一直迭代降级的问题了,而在降级能力方面,原生 DaemonSet 做的切实有些草草了事的感觉。 apiVersion: apps/v1kind: DaemonSetspec: updateStrategy: type: RollingUpdate rollingUpdate: maxUnavailable: 2 # ...apiVersion: apps/v1kind: DaemonSetspec: updateStrategy: type: OnDelete # ...以上是原生 DaemonSet 反对的两种降级形式。置信少数人应用 DaemonSet 根本都是默认的 RollingUpdate 滚动降级,这自身是没问题的,问题就在于滚动降级时只反对了 maxUnavailable 一个策略,这就让咱们很难承受了。目前阿里巴巴内的 Kubernetes 不少曾经做到单集群上万节点,这些节点可能有不同的机型、拓扑、外围水平、内核版本等等,而 DaemonSet 降级也笼罩到这上万节点上的 daemon Pod、波及所有节点上的利用 Pod。 ...

October 29, 2020 · 4 min · jiezi

关于云原生-cloud-native:云原生热点技术国内使用现状-趋势分享

导读 数字经济大潮下传统行业的数字化转型,成为云原生产业倒退的强劲驱动力,“新基建”带来的万亿级资本投入,也将在将来几年推动云原生产业的倒退迈向新阶段。据云原生产业联盟相干调研数据显示,云原生产业作为现阶段云计算PaaS市场的重要支点,2019年我国云原生产业市场规模已达350.2亿元,将来还将连续高速增长态势。 10月21日,云原生产业联盟于2020云原生产业大会公布了国内首个《中国云原生用户调研报告(2020年)》(以下简称 “报告” ),具体展现了中国用户在云原生利用建设方面的现状和需要,主观反映了容器、微服务等云原生技术的利用和挑战。 中国用户云原生建设现状01 现阶段已有 9% 的用户云原生相干投入已占总 IT 投入的一半以上,技术研发与运维为次要建设收入方向 报告显示,云原生技术价值在用户侧失去了初步认同,已有局部用户将 IT 建设的重心转移到云原生上,云原生利用建设需要在逐步增长。然而,新技术的遍及推广仍须要工夫。同时,调研数据显示,在云原生建设收入中,用户资金投入次要用于技术研发和运维。 02 云原生集群部署状态:多云/混合云架构无望在将来成为支流 报告显示,云原生服务部署状态趋于多元化,多云/混合云架构无望在将来成为支流。74% 的用户曾经在应用或将来 1 年打算采纳多云/混合云架构,仅 26% 的用户没有应用多云/混合云的打算。 03 用户最放心云原生规模化利用的安全性、可靠性和连续性 考察数据显示,晋升架构弹性扩大能力与资源利用率,是用户采纳云原生技术的重要驱动因素。通过应用云原生技术,76%的用户晋升根底平台资源利用率并节约了老本,63%的用户晋升了业务利用弹性伸缩效率和灵活性。但值得注意的是,规模化利用的安全性、可靠性和连续性成为用户抉择的次要疑虑。 博云洞察:随着云原生技术的遍及推广,预计将来几年,在产业联盟、社区组织、云原生技术厂商等的推动下,云原生技术在用户侧会有更宽泛的落地利用。 然而,报告数据显示,因为云原生技术难度较高,在选用云原生技术时,61%的用户对云原生技术在大规模利用时的安全性、可靠性、性能、连续性心存顾虑,如果用户齐全依附自研,或将导致用户建设老本出现较高增长。 目前,多云/混合云作为目前大多数企业的首选云策略,在升高多个私有云、公有云厂商绑定、业务中断等危险具备微小劣势。然而,多厂商的异构云服务和技术产品也使得企业多云 IT 环境变得更为简单,如何实现对多云/混合云进行对立纳管、实现多云资源的对立调配治理,成为企业亟需解决的难题。企业级多云治理平台(CMP)市场出现微小倒退空间。 因而,与业余的云原生技术厂商单干或将成为用户将来实现云原生落地建设最持重的抉择。 中国用户云原生技术利用现状以容器、微服务等为代表的云原生技术,带来一种全新的形式来构建利用。报告指出,云原生技术实现了利用的麻利开发,迭代效率和交付速度继续减速,用户利用公布趋于高频。目前,60% 以上的用户已在生产环境中利用容器技术,1000节点规模的容器集群可能满足近 8 成用户的生产需要。作为容器最次要的利用场景,80% 用户曾经应用或打算应用微服务。 01 容器:超6成用户在生产环境中利用容器,Docker和Kubernetes仍是支流抉择 考察数据显示,60% 以上的用户已在生产环境中利用容器技术,43% 的用户已将容器技术用于外围生产业务。同时,报告指出,容器运行时多元化发展趋势曾经浮现,但Docker 仍是现阶段最次要的抉择,83% 的用户容器运行时技术选用 Docker。此外,Kubernetes 连续在容器编排技术畛域的领导位置。 02 微服务:微服务架构趋于支流,80%用户曾经应用或打算应用微服务 在本次调研的用户中,50% 的用户曾经应用微服务架构进行利用开发。在选型方面,Spring Cloud 是现阶段用户最次要的抉择,76% 的用户在微服务框架上选用了 Spring Cloud,19% 的用户选用 Istio 来治理微服务。此外,中国外乡开源我的项目也有相当比例的利用。但值得注意的是,现有平台微服务治理能力有余、短少利用微服务拆分的标准规范,成为用户利用微服务架构的最大挑战。 博云洞察:云原生理念被认为是云计算倒退的必然导向,采纳基于云原生理念的技术和办法:以容器为基石,通过微服务化的革新,交融DevOps理念,有助于更好地实现业务“迁于云”或“生于云”,可能帮忙企业疾速构建更加适宜云的麻利应用服务。 博云基于 kubernetes 自主研发的 BeyondContainer 容器云平台,保持聚焦平台底层能力的晋升。除了提供企业级 kubernetes 集群治理能力之外,博云还可提供更高效的容器网络解决方案、负载平衡能力、胖容器解决方案等容器能力,确保能满足用户 IT 麻利化的需要。博云也作为国内容器云畛域领军企业入选 Gartner 《2020年中国 ICT 技术成熟度曲线报告》,被评为 CaaS 容器云代表性厂商。 ...

October 26, 2020 · 1 min · jiezi

关于云原生-cloud-native:云靶场实战攻防前沿趋势本届云安全挑战赛的看点都在这里

10月24日,由腾讯平安云鼎实验室联结GeekPwn发动的第二届云平安较量在上海落下帷幕,包含Nu1L、r3kapig、NeSE、0ops、天枢 Dubhe等7支国内顶级平安战队,通过8小时的强烈云端攻防反抗后,Emoji战队最终怀才不遇,凭借10209.7的惟一一个过万积分,夺得本届云靶场挑战赛一等奖,NeSE战队和0ops战队分获二、三名。 本届云平安较量蕴含“云靶场挑战赛”和“云平安凋谢赛”两大赛事,连续首届基于全栈实在云环境的赛事特点,继续为宽广平安研究者和从业人员提供实在的云环境靶场,让选手们体验到了实在的云上攻防。同时,作为搭建实在云环境的赛事组织者,腾讯平安云鼎实验室也通过搭建模仿环境和安排赛题,再一次验证了腾讯云平台的安全性,为进一步打造“平安的产业云”积攒了技术教训。 基于云端平安实际和前沿畛域的摸索,腾讯平安云鼎实验室还在现场公布了《2021年云平安九大趋势》,为新基建下的云平安建设提供前瞻性指引。 10月26日,腾讯平安将联结InfoQ独特举办云平安趋势研讨会,会集腾讯云平安总经理董志强、腾讯云平安副总经理李滨、中国信息通信研究院云大所云计算部副主任陈屹力、数世征询创始人李少鹏以及普华永道中国区信息安全与隐衷爱护合伙人万彬等多方产业首领,共论云上平安发展趋势,10月26日晚7:30,腾讯云大学直播间,敬请期待。

October 26, 2020 · 1 min · jiezi