Forrester 最新报告:阿里云稳居领导者地位,引领云原生开发浪潮

alicloudnative阅读(225)评论(0)

头图.jpg

来源 | 阿里巴巴云原生公众号

日前,国际权威研究机构 Forrester 发布了《The Forrester Wave: Public Cloud Development And Infrastructure Platforms In China,Q4 2020》报告,报告对中国主流公有云厂商从战略、产品和市场格局三个维度进行了全面评估,并重点关注开发人员体验、开发服务和基础设施操作三大核心要素。阿里云在容器服务、Serverless/微服务测评中均获得了最高分,并在应用开发服务 9 项测评中拿到了国内综合最高分,稳居云原生领域领导者地位

1.jpg

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 转型“超车”。

Serverless 和微服务拿到国内唯一最高分,Serverless Devs 受到高度关注

在 Forrester 报告中,阿里云不仅在容器测评中获得最高分,在 Serverless 和微服务上的表现同样亮眼,是国内唯一获得最高分的云服务商。阿里云提供了所有云厂商中最完整的 Serverless 产品矩阵,包括函数计算 FC、Serverless 应用引擎 SAE、面向容器编排的 ASK、以及面向容器实例的 ECI。与此同时,阿里云也在不断优化 Serverless 产品的使用体验,包括函数计算 FC 全面融入容器生态,添加容器镜像的触发;开源国内首个 Serverless 开发者平台 Serverless Devs,帮助开发者解决目前的工具链之困;SAE 提供了 QPS/RT 维度的弹性策略配置,增加了限流降级等企业级特性,强化了应用的全生命周期管理;Serverless 事件总线 EventBridge 以标准化的 CloudEvents 1.0 协议帮助用户轻松构建松耦合、分布式的事件驱动架构。

10 月 23 日,阿里巴巴正式开源首个 Serverless 开发者平台 Serverless Devs,这也是业内首个支持主流 Serverless 服务/框架的云原生全生命周期管理的平台。Serverless Devs 包含 Serverless Devs Tool (Serverless 开发者工具)和 Serverless Devs App Store(Serverless 应用中心),帮助开发者一键体验多云产品,极速部署 Serverless 项目。

2.png

Serverless Devs:一个开源开放的 Serverless 开发者平台
https://www.serverless-devs.com/#/home

阿里云发力 Serverless,用户规模位列国内第一。在近期 CNCF Serverless 研究报告中,阿里云函数计算以 46% 的占比占据国内榜首。报告同时显示,大量的国内开发人员正在将传统架构往 Serverless 上做迁移。这个数据在信通院发布的中国首个云原生用户调查报告 2020 中也得到了证实,报告显示:阿里云在国内 Serverless 用户规模的占比达到 66%,远超其他云厂商总和。

Serverless 作为基础研发底座,被越来越多的企业所接受,并应用于业务实践中。除了互联网企业最早“尝鲜”之外,传统企业也在探索大规模使用 Serverless。以世纪联华为例,2019 年的 双11,函数计算 FC 帮助世纪联华顺利渡过了大促。今年,世纪联华全面迁移到函数计算 2.0,抗住了超过去年 230% 的业务峰值,并且研发效率交付提效超过 30%,弹性资源成本减少 40% 以上。如今,阿里整个经济体都在实践 Serverless,包括淘宝、天猫、支付宝、钉钉、飞猪、闲鱼、语雀等,并将 Serverless 的应用场景扩展到前端全栈、小程序、微服务、新零售、游戏互娱等领域。

在微服务体系中,阿里有非常深厚的积累,同时也做了很多开源方面的工作。通过一些开源项目,如 Dubbo、Nacos 等,以及商业化产品如企业级分布式应用服务 EDAS、微服务引擎 MSE 等,把阿里微服务体系中的经验和实践向外输出。另外,阿里也在把微服务体系、开源体系的技术与云进行整合,这样使用云的客户就能更方便地直接使用开源的产品。不仅如此,阿里云也在推进微服务体系向下一代去演进,尤其在云原生领域,大力推动微服务体系与 Service Mesh 融合,实现更好的兼容性和互通性,进而提高 Service Mesh 整个生态的活跃度和成熟度。

今年 双11,阿里落地了全球最大规模云原生实践,再次印证了云原生对于企业和社会的巨大价值。基于容器、微服务、Serverless 为基础的云原生技术,将加速企业核心架构互联网化,帮助企业 IT 基础设施更加具备弹性和自治能力,提升业务敏捷性,更加灵活地应对商业发展中的不确定性;同时,云原生技术将推动云边端应用一体协同,构建下一代动态、大规模、无边界的云应用架构。

谐云DevOps赋能浦发银行数字化创新

谐云科技阅读(507)评论(0)

   近日,谐云成功入围上海浦发银行2020-2022年度敏捷管理及技术教练供应商,通过DevOps赋能浦发银行数字化创新。谐云凭借其过硬的产品质量,扎实高效的工作作风,卓越的专家团队和良好的企业信誉,以绝对优势顺利入围。

    随着银行正在从一个“物理的地方”,到一种“永远在线”的服务的转变,传统的组织架构已经无法支撑起金融行业VCUA时代下的快速迭代与创新。建立以敏捷为核心的能力中心,形成科技与业务的双轮驱动模式,“敏捷组织”成为领先银行实现跨越式发展的重要手段。

谐云助力浦发银行提高IT能力

    今年,浦发银行作为世界《财富世界》500强企业,为配合其“以客户为中心,科技引领,打造一流数字生态银行,推动该行实现高质量发展”的战略目标,同时为打造高效研发体系,实现业务功能研发的敏捷迭代和快速交付,科技人员的培养模式将从面向传统研发的模式向面向开放、共享的高效研发体系的模式进行转变。

经过严格评定,谐云在DevOps领域的技术能力和团队素养得到客户认可,谐云在帮助客户落地DevOps过程改进及评级等方面具有丰富的行业经验。评标过程,谐云团队通力协作,充分展示实力,得到专家评委的一致认可。

谐云EDEP企业级研发效能平台将提高浦发银行提高系统研发的快速市场反应能力和持续交付能力,实现从需求到交付,端到端的敏捷转型推广落地。

🔹帮助打造浦发银行统一的DevOps平台,做到标准、统一、高效,全面赋能浦发银行在需求、开发、测试、运维各个环节

🔹帮助培养浦发银行一个DevOps核心团队,打造一批DevOps内部技术教练,在自主研发的道路上做好铺垫

🔹帮助支撑浦发银行未来三年五个分中心全面推广敏捷及DevOps落地,实现开放银行数字化转型战略的重要一步

🔹打破传统架构的束缚,引入精益敏捷思维,形成具有特色的敏捷文化

高效能的组织不仅做到了高效率,还实现了高质量。谐云将为浦发银行提供业内敏捷转型方法及具体实践,开展敏捷文化的宣贯和培训,选取试点项目开展敏捷导入辅导,打造敏捷标杆小组。

 谐云自研DevOps平台打造数字化金融创新战略

    谐云作为国内领先的云原生布道者,是信通院DevOps标准工作组核心成员单位,参与行业标准制定,同时拥有自研的DevOps产品——EDEP企业级效能平台,并在落地DevOps过程改进及评级等方面具有丰富的行业经验。谐云有强大的DevOps教练团队资源储备,能支撑浦发未来三年五个分中心全面推广敏捷及DevOps落地

目前谐云已成功服务众多知名的金融行业及五百强企业客户案例,擅长在大规模场景下推进敏捷及DevOps落地。

    未来,谐云将不断深化与浦发银行的紧密合作,并将持续致力于以创新云技术,提高金融行业客户核心业务生产率,与金融行业客户共同成长,为效率而进化,共同打造面向未来的金融科技新形态,为数字化金融创新战略绘制宏伟的蓝图。

END

欢 迎 免 费 试 用

联系方式:marketing&sales@harmonycloud.cn

【喜大普奔】JFrog支持 P2P下载功能

JFrogchina阅读(212)评论(0)

1.  需求背景

在大规模Docker 容器运行时环境中,如果镜像实例数 较多,需要同时大规模,多地更新镜像,比如大型电商平台需要更新所有容器的镜像时,Docker镜像中心往往成为性能瓶颈,这个瓶颈往往来自于镜像中心的网络出口,比如镜像中心所在主机有万兆网卡,则网络流量会被限制在 1000MB(注意是大 Byte),通常这个网卡会被多个应用共享使用,所以流量有很多损耗,导致无法满足 Docker 镜像实时分发的需求。即使将 Docker 镜像中心进行异地分布式部署,也存在瞬时的并发拉取流量难以满足,从而导致 Docker 拉取镜像失败,Pod 无法启动。

2. 功能介绍

为了解决这个问题,JFrog Artifactory E+ 7.9 版本支持了 P2P 功能。之前的镜像拉取方式如下:

支持 P2P 之后,镜像的分发方式如下:

JFrog P2P 功能能够让用户从 Peer 网络中直接获取制品,Peer 节点存储了种子制品和缓存过的制品,从而大大的减少 Artifactory 的下载压力。

JFrog P2P 模块的架构:

  • Tracker: 是一个Artifactory 的服务,用来广播和追踪可用的种子制品在哪个 peers 和服务器。
  • Peer: 是一个独有的JFrog应用程序,部署在 peers 节点的主机上,和其他 peers 节点通信。Peer 节点连接 Tracker 去下载制品,并且声明种子的可用性给Tracker.
  • P2P Swarm: 是一个peers 节点的逻辑集合,它形成了分布式的网络,用于给集群内的 Docker 客户端共享制品。
  • Client: 客户端软件用户和 peer 交互,通常是 Docker 或者 HTTP client.

JFrog P2P 下载的工作流:

  • Peer 安装在连接到 Artifactory 的主机上,例如 Kubernetes work node。
  • Peer 节点连接到 Artifactory Edge ,然后注册在 Trakcer 上,作为种子服务器提供服务。所有的下载都通过SSL加密,使用Artifactory的链式认证进行统一鉴权.Peer 节点监听客户端或者其他 Peer 节点的下载请求。
  • 当 Peer 节点下载好种子文件后,会自动广播给各个 Tracker自己的内容,Tracker 会存储这些种子文件的信息。
  • 当 Peer 节点监听到客户端请求时,会去 Tracker 查询哪些 Peer 节点已经缓存了该文件,Tracker 会回复 Peer 节点的请求,然后 Peer 节点开始从Peer swarm 里的这些节点去进行下载。
  • 当文件被缓存在 Peer 节点上,这个信息会被 Tracker 发现并广播,能够别并发的被其他 peer 节点拉取。下载的过程是多线程并发的执行,因此能够打满 Peer 集群内部的网络带宽,使得下载速度比从 Artifactory 服务器下载更加快。

 

3. 收益

通过 P2P 功能,用户能够极快的拉取镜像,实现业务的连续性,目前 JFrog E+版本中支持了这个功能。欢迎大家免费下载试用。

让容器应用管理更快更安全,Dragonfly 发布 Nydus 容器镜像加速服务

alicloudnative阅读(474)评论(0)

1.png

镜像对容器部署的挑战

在容器的生产实践中,偏小的容器镜像能够很快地部署启动。当应用的镜像达到几个 GB 以上的时候,在节点上下载镜像通常会消耗大量的时间。Dragonfly 通过引入 P2P 网络有效提升了容器镜像大规模分发的效率。然而,用户还是必须等待镜像数据完整下载到本地,然后才能创建自己的容器。我们希望进一步缩减镜像下载的时间,让用户能够更快地部署容器应用。同时,如何更好地保护用户数据,也是容器行业近年来的重要关注点。

为此,我们为 Dragonfly 项目引入了一个容器镜像加速服务 Nydus。Nydus 能够极大缩短镜像下载时间,并提供端到端的镜像数据一致性校验,从而让用户能够更安全快捷地管理容器应用。Nydus 由阿里云和蚂蚁集团的工程师合作开发,并大规模部署在内部的生产环境中。作为云原生生态的一部分, Nydus 在生产环境的优秀表现,让我们有信心现在将项目开源,让更多的容器用户能够体验到容器快速启动和安全加载方面的能力。

容器镜像加速服务 Nydus 地址:https://github.com/dragonflyoss/image-service

Nydus: Dragonfly 的容器镜像服务

Nydus 项目优化了现有的 OCI 镜像标准格式,并以此设计了一个用户态的文件系统。通过这些优化,Nydus 能够提供这些特性:

  • 容器镜像按需下载,用户不再需要下载完整镜像就能启动容器
  • 块级别的镜像数据去重,最大限度为用户节省存储资源
  • 镜像只有最终可用的数据,不需要保存和下载过期数据
  • 端到端的数据一致性校验,为用户提供更好的数据保护
  • 兼容 OCI 分发标准和 artifacts 标准,开箱即可用
  • 支持不同的镜像存储后端,镜像数据不只可以存放在镜像仓库,还可以放到 NAS 或者类似 S3 的对象存储上
  • 与 Dragonfly 的良好集成

架构上, Nydus 主要包含一个新的镜像格式,和一个负责解析容器镜像的 FUSE 用户态文件系统进程。

2.png

Nydus 能够解析 FUSE 或者 virtiofs 协议来支持传统的 runc 容器或者 Kata 容器。容器仓库、OSS 对象存储、NAS 以及 Dragonfly 的超级节点和 peer 节点都可以作为 Nydus 的镜像数据源。同时,Nydus 还可以配置一个本地缓存,从而避免每次启动都从远端数据源拉取数据。

镜像格式方面, Nydus 把一个容器镜像分成元数据和数据两层。其中元数据层是一棵自校验的哈希树,每个文件和目录都是哈希树中的一个附带哈希值的节点。一个文件节点的哈希值由文件的数据确定,一个目录节点的哈希值则由该目录下所有文件和目录的哈希值确定。每个文件的数据被按照固定大小切片并保存到数据层中,数据切片可以在不同文件以及不同镜像中的不同文件共享。

3.png

Nydus 能为用户带来什么?

用户如果部署了 Nydus 镜像服务,最直观的一个感受就是,容器启动变快了,从以前的明显时间消耗,变成了几乎瞬间就能启动起来。在我们的测试中, Nydus 能够把常见镜像的启动时间,从数分钟缩短到数秒钟。

4.png

另外一个不那么明显但也很重要的改进,是 Nydus 能够为用户提供容器运行时数据一致性校验。在传统的镜像中,镜像数据会先被解压到本地文件系统,再由容器应用去访问使用。解压前,镜像数据是完整校验的。但是解压之后,镜像数据不再能够被校验。这带来的一个问题就是,如果解压后的镜像数据被无意或恶意地修改,用户是无法感知的。而 Nydus 镜像不会被解压到本地,同时可以对每一次数据访问进行校验,如果数据被篡改,则可以从远端数据源重新拉取。

5.png

未来规划

前面我们介绍了 Nydus 的架构和优点。在过去的一年里,我们和内部的产品团队一起致力于让 Nydus 项目更稳定、安全和易用。在把 Nydus 项目开源之后,我们将会更关注广泛的云原生容器生态。我们的愿景是,当用户在集群中部署 Dragonfly 和 Nydus 服务的时候,无论镜像大小,用户都能够方便快捷地运行他们的容器应用,同时不需要为容器镜像的数据安全性担忧。

OCI 社区容器镜像标准

我们已经在内部生产环境中大规模部署 Nydus,而我们坚信对 OCI 镜像标准的改进需要广泛的社区合作。为此,我们积极地参与了 OCI 社区关于下一代镜像标准的讨论,并发现 Nydus 能够广泛地符合 OCI 社区对下一代镜像格式的要求。所以我们提议把 Nydus 作为 OCI 社区下一代镜像格式的示例实现,并期待和更多的云原生行业领导者们一起推进下一代镜像标准的制定和实现。

FAQ

Q1:现有的 OCI 镜像标准有什么问题?
A1:SUSE 的 Aleksa Sarai 写过一个 blog (The Road to OCIv2 Images: What’s Wrong with Tar?),详细描述了现有 OCI 镜像标准的一系列问题,简单总结就是 OCI 镜像标准使用的 tar 格式太古老,并不适合作为容器镜像格式。

Q2:Nydus 和 CRFS 有什么区别?
A2:CRFS 是 GO build team 设计的一个镜像格式。二者在主要设计思想上非常相似。细节上, Nydus 支持块级别的数据去重和端到端的数据一致性校验,可以说是在 CRFS 的 stargz 格式上的进一步改进。

Q3:Nydus 和 Azure 的 Teleport 有什么区别?
A3:Azure Teleport 更像是现有 OCI 镜像标准在基于 SMB 文件共享协议的 snapshotter 上的一个部署实现,能够支持容器镜像数据按需下载,但保留了所有目前 OCI 镜像 tar 格式的缺陷。相对的,Nydus 抛弃了过时的 tar 格式,并使用 merkle tree 格式来提供更多的高级特性。

Q4:如果运行基于 Nydus 的容器的时候网络断了怎么办?
A4:使用现有 OCI 镜像的时候,如果在容器镜像还没有完整下载的时候网络断了,容器会一开始就无法启动。Nydus 很大程度上改变了容器启动的流程,用户不需要再等待镜像数据完整下载就能启动容器。而容器运行时如果网络断了,将无法访问没有下载到本地的镜像数据。Nydus 支持在容器启动后在后台下载容器镜像数据,所以当容器镜像数据完整下载到本地后,基于 Nydus 的容器也不会受到网络中断的影响。

附录:OClv2 镜像标准

从 2020 年 6 月开始,OCI 社区花了一个多月时间密集讨论了当前 OCI 镜像标准的缺陷,以及 OCIv2 镜像格式需要满足哪些要求。OCIv2 在这里只是一个宣传命名,实际上 OCIv2 是当前 OCI 镜像标准的改进,而不会是一个全新的镜像标准。

这次镜像格式大讨论从一个邮件和一份共享文档开始,并促成了多次在线的 OCI 社区讨论会议。最后的结论也很鼓舞人心,OCIv2 镜像格式需要满足下列要求:

  • 更少的重复数据
  • 可重建的镜像格式
  • 明确的更少的文件系统元数据
  • 可以 mount 的文件系统格式
  • 镜像内容列表
  • 镜像数据按需加载
  • 可扩展性
  • 可校验和/或可修复
  • 更少的上传数据
  • 可以工作在不可信存储上

共享文档中可以找到每一个要求的详细描述。我们全程参与了整个 OCIv2 镜像格式要求的讨论,并发现 Nydus 很好地满足了全部的这些要求。这进一步促使我们开源 Nydus 项目来为社区讨论提供一个工作的代码基础。

共享文档链接:https://hackmd.io/@cyphar/ociv2-brainstorm

阿里巴巴云原生关注微服务、Serverless、容器、Service Mesh 等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践,做最懂云原生开发者的公众号。”

首次披露!云原生热点技术国内使用现状 | 趋势分享

BoCloud阅读(361)评论(0)

导读

数字经济大潮下传统行业的数字化转型,成为云原生产业发展的强劲驱动力,“新基建”带来的万亿级资本投入,也将在未来几年推动云原生产业的发展迈向新阶段。据云原生产业联盟相关调研数据显示,云原生产业作为现阶段云计算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 容器云代表性厂商。

针对异构微服务框架的统一服务治理问题,博云推出了BeyondMicroservice 微服务治理平台,提供统一的服务监控和治理,深度关注不同微服务框架运行中的服务治理问题,提供负载均衡、路由控制、访问控制、黑白名单、容错屏蔽等功能。

同时,博云 BeyondDevOps 研发运营一体化平台提供全栈式 DevOps 落地服务,为客户提供稳定可靠的 IT 交付生产线,帮助企业打造适合自己的研发运营一体化平台。

云原生技术落地逐渐成为常态。作为国内领先的云原生 PaaS 厂商,博云云原生产品服务已在金融、能源、制造等多个领域实现生产系统落地。未来,博云将进一步为客户提供更优质的产品服务,帮助客户构建面向云原生应用的新一代 IT 架构,释放 IT 基础架构生产力。

率先通过信通院容器规模化测评 阿里云获最高认证级别

alicloudnative阅读(545)评论(0)

1021头图.png

今日,由中国信息通信研究院(以下简称“信通院”)主办的 2020 云原生产业大会隆重召开。针对行业痛点,信通院面向云原生领域厂商进行了容器规模化性能标准测评。9 月底,阿里云成为率先通过信通院容器规模化性能测试的云服务商,获得最高级别认证—“卓越”级别,并首先成功实现以单集群 1 万节点 1 百万 Pod 的规模突破,构建了国内最大规模容器集群,引领国内容器落地的技术风向标

1.jpg

本次大会以“云原生应用”为主题,探讨了如何推动云原生实践落地和数字化转型,为企业用户带来最权威的云原生标准和行业最佳应用实践;发布了业内首个超大规模容器性能测评结果。此次测评范围涉及:资源调度效率、满负载压力测试、长稳测试、扩展效率测试、网络存储性能测试、采集效率测试等,客观真实反映容器集群组件级的性能表现。

2.png

据信通院《中国云原生用户调查报告 2020》显示,60% 以上的用户已在生产环境中应用容器技术。随着云原生技术的普及,越来越多的企业核心业务切换到容器,企业生产环境容器集群规模爆发式增长。目前开源版本 Kubernetes 最多可以支撑 5 千节点及 15 万 Pod,已经无法满足日益增长的业务需求。作为云原生领域的实践者和引领者,阿里云基于服务百万客户的经验,从多个维度对 Kubernetes 集群进行优化,率先实现了单集群 1 万节点 1 百万 Pod 的规模突破,可帮助企业轻松应对不断增加的规模化需求

针对大规模集群在企业的落地,阿里云基于 ACK Pro 提供了企业级的容器集群管理能力,在 APIServer 和调度器上提供了大量性能优化。通过自研高性能容器网络 Terway,优化 Pod 延迟 30%,并降低了大规模 Service 的性能开销,可解决大规模集群的网络瓶颈问题。阿里云基于企业级的镜像仓库 ACR EE,支持独享存储,并提供了按需加载镜像的能力,降低启动时间 60%,可解决大规模节点拉取镜像慢的问题。通过以上优化,阿里云为企业提供了大规模集群管理能力,相比于社区版 Kubernetes,单集群节点数在社区基础上提高了 2 倍,Pod 数提升了 6.7 倍

除了提供更大规模更加稳定的 Kubernetes 集群之外,阿里云还可提供更加高效的网络转发、扩展能力更强的存储、更高效的应用与镜像分发等能力。基于此,阿里云拥有足够弹性的“服务能力空间”,可根据企业业务量身定制满足当前所需的容器集群服务,除了支撑阿里集团内部核心系统容器化上云和阿里云的云产品本身,也将多年的大规模容器技术以产品化的能力输出给众多围绕双十一的生态公司和 ISV 公司。通过支撑来自全球各行各业的容器云,阿里云容器服务已经沉淀了支持单元化架构、全球化架构、柔性架构的云原生应用托管中台能力,管理了超过 1 万个以上的容器集群,提供企业级可靠服务。

阿里云拥有国内规模最大的容器集群、最丰富的云原生产品家族和最全面的开源贡献,提供云原生裸金属服务器、云原生数据库、数据仓库、数据湖、容器、微服务、DevOps、Serverless 等超过 100 款创新产品,覆盖新零售、政务、医疗、交通、教育等各个领域。阿里云容器服务是国内唯一连续两次入选 Gartner 2019 年和 2020 年《竞争格局:公共云容器服务》报告的厂商,阿里云覆盖 Serverless Kubernetes、服务网格、容器镜像等九项产品能力,与 AWS 平齐,产品丰富度领先 Google、微软、IBM 和 Oracle 四家厂商。

云原生已成为新常态,容器化需求从行业头部企业下沉到中小规模企业,从领先企业尝鲜变为主流企业必备,但当前国内云原生的发展分布不均,亟需标准化引导。此次容器规模化性能测评是信通院对容器行业标准的进一步完善。阿里云一直致力于推动云原生在国内的普及,将与信通院一起促进中国容器市场的规范化、标准化发展。

阿里巴巴云原生关注微服务、Serverless、容器、Service Mesh 等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践,做最懂云原生开发者的公众号。”

阿里宣布成立云原生技术委员会,释放哪些趋势信息?

alicloudnative阅读(1891)评论(0)

头图.jpg

作者 | 中国电子报记者李佳师

在今年阿里的云栖大会上,除了吸引眼球的云电脑“无影”、机器人“小蛮驴”之外,另外一个值得关注的事情是,阿里成立了云原生技术委员会,全面推动阿里经济体的云原生化。中国工程院院士王坚说,此举将“让阿里云与客户坐在同一架飞机上。”王坚为什么这样说?此举又将对未来的云计算带来哪些影响?这其中有哪些趋势信息需要关注?

云原生到了爆发的元年?

9 月 18 日,在云栖大会的第二天日早上,阿里巴巴宣布成立云原生技术委员会,负责人是阿里巴巴高级研究员蒋江伟,此外还包括达摩院数据库首席科学家李飞飞、阿里云计算平台高级研究员贾扬清、阿里云原生应用平台负责人丁宇等阿里技术负责人,组建此委员会的目的是推动阿里经济体全面云原生化,同时将阿里巴巴10多年沉淀的云原生实践,通过阿里云对外赋能数百万家企业,助力各行业迈入数字原生时代。

1.jpg

最近两三年,云原生这个词在业界被提及频率越来越高,专家表示,2020 年将是中国云原生的元年。按照 Gartner 预测,到 2022 年有 75% 的全球企业将在生产中使用云原生的容器化应用。

究竟什么是云原生?阿里云容器平台集群管理团队负责人张瓅玶在接受《中国电子报》记者采访时表示,云原生不是一个产品,而是一套技术体系和一套方法论,按照这一套方法论和技术体系,用户能够更好地让业务生长于云或者把业务迁移到云平台,从而更好地享受到云的高效和持续的服务能力。

“也就是说,如果你按照这一套框架和思路去做,企业能够真正发挥云的弹性、动态调度、自如伸缩等特性,同时也不用担心被云供应商绑定,因为遵循的是开放标准。”张瓅玶说。

云原生产业联盟不久前发布的《云原生发展白皮书(2020)》指出,云原生是面向云应用设计的一种思想理念,能够充分发挥云效能的最佳实践路径,能够帮助企业构建弹性可靠、松耦合、易管理可观测的应用系统,提升交付效率,降低运维复杂度,其代表技术包括容器技术、不可变基础设施、服务网格、声明式 API 及 Serverless 等。

2013 年云原生的概念被提出来,其后在开源社区不断得到完善,在 2015 年由谷歌牵头成立了云原生计算基金会 CNCF,推广孵化和标准化云原生相关的技术。目前 CNCF 已经有超过 300 个会员,涵盖国内外的知名 IT 企业,包括微软、亚马逊、苹果、阿里巴巴、华为、高通等,发展十分迅速。

目前,云原生技术形成了业界公认的一系列云计算技术体系和企业管理方法的集合,既包含了实现应用云原生化的方法论,也包含了落地实践的关键技术、操作工具。阿里云也于近期出版业界首本《云原生架构白皮书》,详细阐述了云原生架构的定义,可指导企业云原生化的可落地方法论。

对于大企业,云原生可以充分地利用云的优势,让企业在云上的投资获得最大的收益。对于较小企业来说,通过云原生可以获取以往只有大企业才拥有的计算资源。

拥抱云原生正在成为全球企业数字化转型的共识,《云原生发展白皮书》显示,2019 年中国云原生市场规模已达 350.2 亿元,大中型互联网企业主导云原生产业发展。

阿里巴巴集团是从 2011 年开始推动云原生,在今年成立了云原生技术委员会,推动整个阿里经济体的云原生化。这释放着一个重要的信号,就是云原生从技术、生态、需求等方方面面,现在已经发展进入一个关键点,而且是未来云计算发展的必选方向。

为什么要和用户坐同一架飞机?

尽管云原生能够带来巨大的好处,但是企业从传统 IT 走上云原生这个过程并不容易。尤其是大型系统的升级与迁移,如何控制好复杂性、控制好大型系统架构的稳定性、控制好技术的风险,从技术体系到人员技能都面临全线的升级与再造。

就像王坚院士所说,从 in-house 的基础设施、定制化的平台能力、到通用的云平台,从 Cloud Hosting 到 Cloud Native,这个过程面临着巨大的挑战。2019 年 双11 之前,阿里实现了核心交易系统 100% 上云并完成了全球最大规模的云原生实践,让阿里和客户真正坐上了同一架飞机。

云原生就是用好云的最好方式,是云计算之上的再升级,是云的下一个十年。阿里巴巴高级研究员蒋江伟表示原因有三:

  1. 云原生拥有开放、标准、vendor no lock-in 等美好特性,让云计算变得更加标准,更容易获得,释放更大红利,会真正成为如水电煤一样的基础设施,是真正意义上的云革命;
  2. 云原生让云更好用,加强用户对云厂商的信任,增强对新技术和上云接受度,是云和客户交互的信任窗口;
  3. 云 1.0 主要任务是基础设施云化,实现成本层面的更进一步优化。云 2.0 演进方向将是架构云原生化,帮助企业提升或创造新的业务价值。

云原生是云计算的再升级。目前全球的云计算巨头包括微软、亚马逊等都在加速推进云原生。就像任何技术与工具都有优劣、高低之差一样,如何能够提供更好的云原生技术、工具,如何提供更优的方法论,就成为云计算厂商竞争的焦点。

云计算其实是一个偏实践的工程技术,其技术成熟需要融合最佳实践,这也是为什么阿里会首先从支撑自身业务开始,通过实践获得成功才开始做商业化。

如何在云计算的下一程进阶、下一个十年较量中凸显出来,目前来看,阿里巴巴正在从几大的维度来推进。

据阿里云资深产品专家赵林介绍,一方面,阿里云加大对云原生产品家族的研发与开源,进一步丰富其产品家族。公开资料显示,从云原生产品丰富度来看在全球亚马逊排名第一,在中国阿里云排名第一。目前阿里云提供包括云原生裸金属服务器、云原生数据库、数据仓库、数据湖、容器、中间件、微服务、DevOps、Serverless 等超过 100 款产品。在 Gartner 的 2020 年公共云容器报告里,阿里云容器产品在 9 项产品评选中排名全球第一。在这次的云栖大会上阿里云又宣布了几项重大的云原生产品的升级。

另一方面,阿里在云原生生态上加大投入。在合作伙伴方面,此前阿里云宣布未来一年投入20亿优选合作 10000 家合作伙伴,共同服务百万客户,加速百行千业实现数字化转型;与此同时,阿里云也启动了“云原生人才计划”,计划三年内产教融合进入 300 所高校,新增培养 100 万云原生开发者。

另一方面,阿里全速推进阿里巴巴经济体的云原生化,将这些最佳实践通过阿里云向外输出,让更多的企业获得云原生的红利。“是骡子是马,得跑起来让别人看得到。”阿里巴巴这个庞大的经济体,其 IT 系统复杂度、双11 交易的高峰值,其要求的稳定性大家有目共睹,它的全面云原生化,无疑是呈现给社会最好的“样板间”。要让越来越多的企业客户将核心业务系统上云,就如同让客户搭乘飞机一样,如果阿里自己都不把全部“家当”上云,又怎么说服客户上云?这就是王坚所言的让阿里与客户真正坐上同一架飞机的真实含义。

而这样多方推进的目标,按照蒋江伟的说法,就像大规模电网的诞生催生了大量电器的使用,让电从奢侈品变成日用品一样,而云原生就相当于电网的角色,让云成为日用品,让企业业务生长云、长于云,帮助企业实现全面的数字化。现在阿里正在朝着云原生全速推进。

阿里云原生化有什么启示

云原生技术委员会的成立,代表阿里经济体 all in 云原生的决心。从这件事情上我们还可以得到一些启示。

其一,云原生是一个旅程,它需要持续地去推进。事实上,阿里云 2009 年成立, 2011 年开始推进阿里巴巴云原生,到 2019 年阿里巴巴整个核心系统上云,再到今天成立专门的技术委员会,持续推进阿里巴巴经济体的云原生化,说明云原生是一个“更快、更高、更强”不断追求极致的旅程,它需要从组织形式上、从技术上、人员技能上不断推进。

其二,云原生产品的成熟度、云原生的实践经验、技术的先进性、生态丰富度等,会成为用户选择云计算厂商的重要指标。企业数字化转型、企业推进云原生涉及方方面面,是一个巨大的系统工程,尽管基于开放标准、基于开源有非常多的工具可以选用,但是工具、方法论和交付等能力差异,在进行迁移过程中面临系统风险性、复杂度等诸多挑战,用户需要全方位的综合能力,才能够更好地去解决这些问题,这也是为什么众多的云计算厂商都在强调其产品的丰富度、成熟度以及构建生态的原因。阿里云拥有国内最丰富的云原生产品家族,最全面的云原生开源贡献,最大规模的云原生应用实践,最广泛的云原生客户群里,致力于让全社会迈入数字原生时代。

其三,从云原生技术演进的方向看,有一些重要趋势值得关注。“一个主题是全面容器化推进仍将继续;Serveless化(无服务化)是又一个主题,让研发运维应用的架构,越来越多地与基础能力、基础设施、服务器解耦,获得极致弹性、快速迭代能力;再一个主题是服务网格化,让用户能够更方便地使用底层资源;另外一个主题是未来企业运用数据、运用算法、运用 AI 的能力越来越强,越来越多的新型工作负载,催生云原生技术发展来适应这个体系。”阿里云资深产品专家赵林表示,从硬件层面看,CPU、FPGA、NPU 等异构的硬件,会促使应用架构发生全新的变化,这些变化也会带来一些新的技术与产品。

云原生被认为是企业数字化转型的最短路径:

  • 其一、云原生让数字技术变得唾手可得,降本增效、安全稳定、高可用是最基本的,帮助企业利用数据信息改变或极大拓宽商业赛道,是企业赢在未来的关键;
  • 其二、云原生可以重塑软件整个生命周期,提升架构灵活性。典型的阿里 双11 可以同时顶住流量型和时延型业务,正是得益于云原生可以降低类似业务的研发成本和技术门槛,让架构具备更高可用,在业务侧快速产生价值;
  • 其三、云原生可提供一套开放标准的技术体系,让人才可以不受平台限制充分流动,职业技能正向累计,人才池足够大,更加有利于企业招聘。

云计算发展的新拐点已至,云原生将极大地释放云的红利,在这一个新技术浪潮到来之际,唯有拥抱,才是最好的选择。阿里云已做好准备,成为这波技术浪潮里的引领者和定义者。

阿里巴巴云原生关注微服务、Serverless、容器、Service Mesh 等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践,做最懂云原生开发者的公众号。”

阿里巴巴成立云原生技术委员会,云原生升级为阿里技术新战略

alicloudnative阅读(1980)评论(0)

1.png

9 月 18 日,2020 杭州云栖大会期间,阿里巴巴正式成立云原生技术委员会(以下简称委员会),阿里巴巴高级研究员蒋江伟担任委员会负责人,达摩院数据库首席科学家李飞飞、阿里云计算平台高级研究员贾扬清、阿里云原生应用平台研究员丁宇等多位阿里技术负责人参与其中。同时,阿里云推出包括软硬结合的沙箱容器 2.0、离线实时一体化数据仓库 MaxCompute、云原生多模数据库 Lindorm 在内的多款云原生产品。

2.jpg

云原生是一种新型技术体系,被视为云计算未来的发展方向。云原生应用也就是面向“云”而设计的应用,在使用云原生技术后,开发者无需考虑底层的技术实现,只需做好自己的业务,就可以充分发挥云平台的弹性+分布式优势,实现快速部署、按需伸缩、不停机交付等。

蒋江伟表示,委员会将大力推动阿里经济体全面云原生化,并沉淀阿里巴巴 10 多年的云原生实践,对外赋能数百万家企业进行云原生改造,提升 30% 研发效率的同时降低 30% IT 成本,帮助客户迈入数字原生时代。

3.jpg

此次委员会的成立,也意味着阿里已经将云原生升级为新的技术战略方向。蒋江伟介绍,阿里拥有 10 多年的云原生实践经验,从 2009 年首次上线核心中间件系统,到 2011 年淘宝天猫开始使用容器调度技术,再到推出自研云原生硬件神龙服务器、云原生数据库 PolarDB。2019 年 双11,阿里电商核心系统 100% 上云,这也是全球规模最大的云原生实践。

公开资料显示,阿里云目前拥有国内规模最大的云原生产品家族和开源生态,提供云原生裸金属服务器、云原生数据库、数据仓库、数据湖、容器、微服务、DevOps、Serverless 等超过 100 款创新产品,覆盖政务、零售、教育、医疗等各个领域。在 Gartner 发布的 2020 年公共云容器报告中,阿里云容器以丰富的产品布局在 9 项产品评选中排名全球第一,是全球容器产品最完善的云服务商。

4.jpg

在今年疫情期间,基于阿里云容器解决方案,钉钉 2 小时内扩容 1 万台云主机支撑 2 亿上班族在线开工;申通快递将核心系统搬到阿里云上,并进行应用容器化和微服务改造,在日均处理订单 3000 万的情况下,IT 成本降低 50%;采用了阿里云原生 PaaS 平台的中国联通号卡应用,开卡业务效率提升了 10 倍,需求响应时间缩短了 50%,支撑访问量由 1000 万上升至 1.1 亿……

此前,阿里云宣布未来一年投入 20 亿优选合作 10000 家伙伴,共同服务百万客户,加速百行千业实现数字化转型。同时,阿里云还启动了“云原生人才计划”,三年内产教融合进入 300 所高校,新增培养 100 万云原生开发者。

2020 云栖大会-企业云原生创新与实践分论坛,声网、好未来、新浪微博、CNCF 等嘉宾邀你共同探讨如何帮助企业和开发者共同迈入数字原生时代。

点击链接直达直播页面:https://yunqi.aliyun.com/2020/session88

阿里巴巴云原生关注微服务、Serverless、容器、Service Mesh 等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践,做最懂云原生开发者的公众号。”

云计算PaaS及多云管理厂商BoCloud博云完成D轮融资

BoCloud阅读(325)评论(0)

2020年9月17日,云计算PaaS及多云管理代表厂商BoCloud博云(苏州博纳讯动软件有限公司)宣布完成D轮融资。本轮融资由国鑫创投、信峘投资、金浦文创、碧鸿投资、交银国际共同战略投资,原股东东方富海持续加码。

本次D轮融资之后,在PaaS平台和多云管理领域中,博云成为第一家完成D轮融资的创业厂商,这将使博云在PaaS和多云管理创业赛道的领先优势继续扩大。此前,博云于2020年1月宣布完成了亿元级C轮融资,7月宣布完成了C+轮战略融资。连续宣布完成三轮融资,彰显了博云持续获得资本市场的好评认可。

 

三大上海国资资本入局,博云加码长三角市场

依托于中国经济的转型升级,近年来上海通过产业调整,大力推进全球科创中心建设。上海国资国企为培育新基建科创优质企业,不断积极探索云计算等科技领域。

本轮新增投资方中,国鑫创投是上海国际集团下属国资经营公司的全资子公司及上海国际集团旗下唯一聚焦金融科技的直接投资平台;信峘投资是上海联和投资公司下属上海市信息投资股份有限公司设立的混合所有制私募股权投资基金管理机构,专注于先进信息技术及相关产业的投资;金浦文创是金浦投资旗下专注文创、消费以及国家鼓励的新基建等技术进步领域投资的股权投资基金。

作为长三角一体化战略中的科技和产业创新先锋,上海是博云战略发展的核心区域之一。通过为上海多家大型支付机构、大型综合性证券公司、大型股份制商业银行、全球知名连锁餐饮机构等企业提供云计算产品服务,博云在上海、长三角及全国地区领先优势持续扩大。

随着上海办公室落成启用,博云将进一步联合上海产业机构,继续加码长三角市场,为上海及长三角地区产业数字化、智能化发展贡献技术力量。

 

持续发力金融科技领域,加快拓展新应用场景

云计算作为提升信息化的关键技术,在金融科技领域大范围应用已是大势所趋。金融行业客户是博云的核心客户群体之一,数量常年保持持续增长。同时,博云的产品已在众多银行、证券、保险等金融行业多种场景下的生产系统成功落地,产品能力得到长期生产级验证,这使得博云在金融科技领域长期保持领先性。

作为本轮战略投资方之一,国鑫创投总经理徐成表示:“国鑫创投聚焦于金融科技方向,致力形成以金融机构和科技企业为核心的生态圈。我们持续关注着云技术在金融领域的落地应用,博云的产品与服务能力正是经受了大量金融机构生产系统检验,在金融行业具有坚实的客户基础。我们非常看好博云未来的发展,也将助力博云与金融机构的合作交流,希望更多金融机构通过云计算PaaS技术实现更强的业务创新能力。”

在持续发力金融科技领域的同时,博云把握行业市场新机遇,加快拓展边缘计算等创新场景。通过建设一体化边缘计算平台,打通云、边、端三层的相互协同,将原有容器云提供的云上服务编排、管理、调度等能力赋能到边缘端,将边缘端设备抽象到云中心统一管理,延伸计算能力到边缘端,帮助用户快速构建安全、高效、灵活、可靠的边缘计算平台,广泛适用于物联网、工业互联网、车联网等行业领域,为企业实现降本增效。

 

PaaS和多云管理趋势渐成主流,博云产品矩阵不断升级

在新基建的带动下,企业加速数字化转型已是大势所趋。企业云基础设施正在向多云融合变迁,在这种环境下,企业更需要构筑多云管理平台。据IDC预测,到2022年,50%的企业将会部署统一的虚拟机、Kubernetes和多云管理流程和工具,以支持跨本地和公有云部署的多云管理和治理。

另外,企业数字化转型的根本关键正是其应用程序的更新扩展与创新组合,这意味着企业更需要以应用为中心的PaaS技术,来实现企业应用和系统上云,帮助企业以更敏捷的姿态,实现真正意义的数字化转型。Gartner指出,PaaS将成为未来的主流平台交付模式。

依托行业趋势发展及深入客户实际需求,博云形成了以容器、微服务、DevOps为核心的PaaS平台,为客户提供面向应用全生命周期管理的解决方案;并以“一体化云管平台+自动化运维”为核心,打造了完整的云运营和运维平台,为客户提供跨越传统 IT 及云计算环境的资源管理解决方案。

凭借完整的产品矩阵、快速全面的服务响应能力,博云产品服务推出以来,已覆盖金融科技、高端制造、能源央企、政府及公共事业等十余个行业领域,并积累了上百家行业头部客户,产品广泛部署于核心生产场景,支撑着众多客户的生产系统稳定高效运行,为客户的数字化转型保驾护航。

 

博云领先优势持续扩大,备受市场关注与认可

与此同时,博云不断赢得国内外权威市场分析机构的关注与认可。

在 Gartner 近期发布的《2020中国 ICT 技术成熟度曲线报告》中,博云作为国内容器云代表性厂商入选报告。在爱分析发布的《银行数字化厂商全景报告中》,博云入选应用敏捷交付场景代表厂商。在2019年,IDC 评定博云为创新性容器厂商代表;Forrester 也在中国企业级容器云平台报告中将博云作为关注对象引入报告;在计世资讯发布的《中国PaaS市场研究报告》和《中国多云管理平台市场研究报告》中,博云均作为代表厂商被列入报告,并且市场份额领先同赛道创业厂商。

数字化转型进程的加速,使得以PaaS技术为代表的新一代敏捷IT建设,面临着前所未有的机遇。作为本轮追加投资的原股东,东方富海致力于投资具有成长性和上市潜力的目标公司,东方富海合伙人陈利伟先生表示:“博云经过八年的快速发展,已经处于PaaS创业赛道的领先,我们持续看好博云的发展潜力,相信博云能够进一步扩大领先优势,在PaaS赛道脱颖而出。”

此次融资,博云将继续坚定地围绕应用管理和资源管理两大场景,加强PaaS及多云管理产品矩阵的核心产品研发、加强底层技术研发投入、加强生态和渠道合作伙伴体系建设,以及在5G、边缘计算、工业互联网等新应用场景的业务拓展。同时,在 IT 国产化进程中,进一步提升底层核心技术自主研发能力,为客户提供可持续的、长期的、优质的产品与服务。

 

新增投资方信息

  • 国鑫创投
    上海国鑫创业投资有限公司(国鑫创投)作为上海国际集团下属国资经营公司的全资子公司,是国际集团旗下唯一聚焦金融科技的直接投资平台。公司以国际集团核心资源为支撑,聚焦金融科技方向,培育优质被投企业成为金融科技细分领域的头部企业,推动形成以金融机构和科技企业为核心的生态圈,促进生态圈企业合作交流。

 

  • 信峘投资
    上海信峘科技投资管理有限公司(信峘投资)是上海联和投资公司下属上海市信息投资股份有限公司设立的混合所有制私募股权投资基金管理机构。信峘投资专注于高科技领域、尤其是先进信息技术及相关产业的投资,充分发挥股东公司在集成电路、智慧城市、卫星互联网、新能源与先进制造、生物医疗等领域的产业资源,支持被投企业发展。

 

  • 金浦文创
    上海金浦文创股权投资基金(金浦文创)是由上海金浦鲲文投资管理有限公司的专注于文创、消费以及国家鼓励的新基建等技术进步领域的股权投资基金。

 

  • 碧鸿投资
    碧鸿投资是一家拥有深厚汽车产业背景的专业投资机构,其宗旨是用独到的产业资源去发现和创造价值,通过资本布局和产业联动实现多方共赢。

 

  • 交银国际
    交银国际控股有限公司(“交银国际”,股份代号:3329.HK)成立于1998年,是交通银行于境外设立的证券及金融业务国际旗舰。作为香港最早具有中资背景的持牌证券公司之一,于2017年在香港联交所主板上市,成为中国首家上市的银行系券商。交银国际拥有经验丰富的专业团队,立足交银集团优质投行业务平台,致力于以跨境、跨业和跨市场的专业经营能力和服务水平,为客户生命周期不同阶段提供全方位跨境金融服务和产品。

设计稿生成代码与 Serverless 的前世今生与未来!

alicloudnative阅读(402)评论(0)

1.png

一场脑洞实验

云栖大会云上 Hello World 活动火热进行中!每位参与者都可收获一份阿里云出品的全球唯一序列号纪念证书!

作为阿里经济体前端委员会的四大技术方向之一,前端智能化方向一被提及,就不免有人好奇:前端结合机器学习能做些什么,怎么做,未来会不会对前端产生很大的冲击等等。本文以「设计稿自动生成代码」场景为例,细述我们的思考及过程实践。

前端智能化与云 IDE 的结合,通过后者打通的各种服务与接口,再加上设计稿生成代码的能力,可以进一步地提升前端开发者的开发体验,由原来的设计稿生成代码,转变为生成可随时可部署的应用/页面,因此本文最后会介绍如何在阿里云云开发平台使用 imgcook 插件,一键完成设计稿稿生成应用,开启您的智能开发之旅。

前端智能化背景

业界机器学习之势如火如荼,「AI 是未来的共识」频频出现在各大媒体上。李开复老师也在《AI · 未来》指出,将近 50% 的人类工作将在 15 年内被人工智能所取代,尤其是简单的、重复性的工作。并且,白领比蓝领的工作更容易被取代;因为蓝领的工作可能还需要机器人和软硬件相关技术都突破才能被取代,而白领工作一般只需要软件技术突破就可以被取代,那我们前端这个“白领”工作会不会被取代,什么时候能被取代多少?

回看 2010 年,软件几乎吞噬了所有行业,带来近几年软件行业的繁荣;而到了 2019 年,软件开发行业本身却又在被 AI 所吞噬。你看:DBA 领域出现了 Question-to-SQL,针对某个领域只要问问题就可以生成 SQL 语句;基于机器学习的源码分析工具 TabNine 可以辅助代码生成;设计师行业也出了 P5 Banner 智能设计师“鹿班”,测试领域的智能化结合也精彩纷呈。那前端领域呢?

那就不得不提一个我们再熟悉不过的场景了,它就是设计稿自动生成代码(Design2Code,以下简称 D2C),阿里经济体前端委员会 – 前端智能化方向当前阶段,就是聚焦在如何让 AI 助力前端这个职能角色提效升级,杜绝简单重复性工作,让前端工程师专注更有挑战性的工作内容!

imgcook 是什么?

imgcook 使用 Sketch、PSD、静态图片等形式作为输入,通过智能化技术一键生成可维护的前端代码,包含视图代码、数据字段绑定、组件代码、部分业务逻辑代码等。

2.png

它期望能够利用智能化手段,让自己成为一位前端工程师,在对设计稿轻约束的前提下实现高度还原,释放前端生产力,助力前端与设计师高效协作,让工程师们专注于更具挑战性的工作!

设计稿生成代码的目标是让 AI 助力前端这个职能角色提效升级,杜绝简单重复性工作内容。那我们先来分析下,“常规”前端尤其是面向 C 端业务的同学,一般的工作流程日常工作内容大致如下:

3.png

“常规”前端一般的开发工作量,主要集中在视图代码逻辑代码数据联调这几大块,接下来,我们逐块拆解分析。

1. 问题定义

视图代码研发,一般是根据视觉稿编写 HTML 和 CSS 代码。如何提效?当面对 UI 视图开发重复性的工作时,自然想到组件化、模块化等封装复用物料的解决方案,基于此解决方案会有各种 UI 库的沉淀,甚至是可视化拼装搭建的更高阶的产品化封装,但复用的物料不能解决所有场景问题。个性化业务、个性化视图遍地开花,直面问题本身,直接生成可用的 HTML 和 CSS 代码是否可行?

4.png

这是业界一直在不断尝试的命题,通过设计工具的开发插件可以导出图层的基本信息,但这里的主要难点还是对设计稿的要求高、生成代码可维护性差,这是核心问题,我们来继续拆解。

1)设计稿要求高

对设计稿的要求高,会导致设计师的成本加大,相当于前端的工作量转嫁给了设计师,导致推广难度会非常大。

一种可行的办法是采用 CV(ComputerVision, 计算机视觉) 结合导出图层信息的方式,以去除设计稿的约束,当然对设计稿的要求最好是直接导出一张图片,那样对设计师没有任何要求,也是我们梦寐以求的方案,我们也一直在尝试从静态图片中分离出各个适合的图层,但目前在生产环境可用度不够(小目标识别精准度问题、复杂背景提取问题仍待解决),毕竟设计稿自带的元信息,比一张图片提取处理的元信息要更多更精准。

2)代码可维护性

生成的代码结构一般都会面临可维护性方面的挑战:

  • 合理布局嵌套:包括绝对定位转相对定位、冗余节点删除、合理分组、循环判断等方面;
  • 元素自适应:元素本身扩展性、元素间对齐关系、元素最大宽高容错性;
  • 语义化:类名的多级语义化;
  • 样式 CSS 表达:背景色、圆角、线条等能用 CV 等方式分析提取样式,尽可能用 CSS 表达样式代替使用图片。

将这些问题拆解后,分门别类专项解决,解决起来看似没完没了,但好在目前发现的大类问题基本解决。

很多人质疑道:这部分能力的实现看起来和智能化一点关系都没有,顶多算个布局算法相关的专家规则系统。没错,现阶段这部分比较适合规则系统,对用户而言布局算法需要接近 100% 的可用度,另外这里涉及的大部分是无数属性值组合问题,当前用规则更可控。如果非要使用模型,那这个可被定义为多分类问题。同时,任何深度学习模型的应用都是需要先有清晰的问题定义过程,把问题规则定义清楚本就是必备过程。

但在规则解决起来麻烦的情况下,可以使用模型来辅助解决。比如 合理分组(如下图) 和 循环项 的判断,实践中我们发现,在各种情况下还是误判不断,算法规则难以枚举,这里需要跨元素间的上下文语义识别,这也是接下来正在用模型解决的重点问题。

5.png

2. 技术方案

基于上述的概述和问题分解后,我们对现有的 D2C 智能化技术体系做了能力概述分层,主要分为以下三部分:

  • 识别能力:即对设计稿的识别能力,智能从设计稿分析出包含的图层、基础组件、业务组件、布局、语义化、数据字段、业务逻辑等多维度的信息;如果智能识别不准,就可视化人工干预补充纠正,一方面是为了可视化低成本干预生成高可用代码,另一方面这些干预后的数据就是标注样本,反哺提升智能识别的准确率;
  • 表达能力:主要做数据输出以及对工程部分接入:a)通过 DSL 适配将标准的结构化描述做 Schema2Code;b)通过 IDE 插件能力做工程接入;
  • 算法工程:为了更好的支撑 D2C 需要的智能化能力,将高频能力服务化,主要包含数据生成处理、模型服务部分:
    • 样本生成:主要处理各渠道来源样本数据并生成样本;
    • 模型服务:主要提供模型 API 封装服务以及数据回流。

6.png
(前端智能化 D2C 能力概要分层)

在整个方案里,我们用同一套数据协议规范(D2C Schema)来连接各层的能力,确保其中的识别能够映射到具体对应的字段上,在表达阶段也能正确地通过出码引擎等方案生成代码。

1)智能识别技术分层

在整个 D2C 项目中,最核心的是上述识别能力部分的机器智能识别部分,这层的具体再分解如下:

  • 物料识别层:主要通过图像识别能力识别图像中的物料(模块识别、原子模块识别、基础组件识别、业务组件识别);
  • 图层处理层:主要将设计稿或者图像中图层进行分离处理,并结合上一层的识别结果,整理好图层元信息;
  • 图层再加工层:对图层处理层的图层数据做进一步的规范化处理;
  • 布局算法层:转换二维中的绝对定位图层布局为相对定位和 Flex 布局;
  • 语义化层:通过图层的多维特征对图层在生成代码端做语义化表达;
  • 字段绑定层:对图层里的静态数据结合数据接口做接口动态数据字段绑定映射;
  • 业务逻辑层:对已配置的业务逻辑通过业务逻辑识别和表达器来生成业务逻辑代码协议;
  • 出码引擎层:最后输出经过各层智能化处理好的代码协议,经过表达能力(协议转代码的引擎)输出各种 DSL 代码。

7.png
(D2C 识别能力技术分层)

2)技术痛点

当然,这其中的识别不全面、识别准确度不高一直是 D2C 老生常谈的话题,也是 imgcook 的核心技术痛点。我们尝试从这几个角度来分析引起这个问题的因素:

  • 识别问题定义不准确:问题定义不准确是影响模型识别不准的首要因素,很多人认为样本和模型是主要因素,但在这之前,可能一开始对问题的定义就出现了问题,我们需要判断我们的识别诉求模型是否合适做,如果合适那该怎么定义清楚这里面的规则等;
  • 高质量的数据集样本缺乏:我们在识别层的各个机器智能识别能力需要依赖不同的样本,那我们的样本能覆盖多少前端开发场景,各个场景的样本数据质量怎么样,数据标准是否统一,特征工程处理是否统一,样本是否存在二义性,互通性如何,这是我们当下所面临的问题;
  • 模型召回低、存在误判:我们往往会在样本里堆积许多不同场景下不同种类的样本作为训练,期望通过一个模型来解决所有的识别问题,但这却往往会让模型的部分分类召回率低,对于一些有二义性的分类也会存在误判。

【问题定义】

深度学习里的计算机视觉类模型目前比较适合解决的是分类问题和目标检测问题,我们判断一个识别问题是否该使用深度模型的前提是——我们自己是否能够判断和理解,这类问题是否有二义性等,如果人也无法准确地判断,那么这个识别问题可能就不太合适。

假如判断适合用深度学习的分类来做,那就需要继续定义清楚所有的分类,这些分类之间需要严谨、有排他性、可完整枚举。比如在做图片的语义化这个命题的时候,一般图片的 ClassName 通用常规命名有哪些,举个例子,其分析过程如下:

8.png

  • 第一步:尽可能多地找出相关的设计稿,一个个枚举里面的图片类型;
  • 第二步:对图片类型进行合理归纳归类,这是最容易有争论的地方,定义不好有二义性会导致最有模型准确度问题;
  • 第三步:分析每类图片的特征,这些特征是否典型,是否是最核心的特征点,因为关系到后续模型的推理泛化能力;
  • 第四步:每类图片的数据样本来源是否有,没有的话能否自动造;如果数据样本无法有,那就不适合用模型,可以改用算法规则等方式替代先看效果。

D2C 项目中很多这样的问题,问题本身的定义需要非常精准,并且需要有科学的参考依据,这一点本身就比较难,因为没有可借鉴的先例,只能先用已知的经验先试用,用户测试有问题后再修正,这是一个需要持续迭代持续完善的痛点。

【样本质量】

针对样本问题,我们需要对这部分数据集建立标准规范,分场景构建多维度的数据集,将收集的数据做统一的处理和提供,并以此期望能建立一套规范的数据体系。

在这套体系中,我们使用统一的样本数据存储格式,提供统一的针对不同问题(分类、目标检测)的样本评估工具来评估各项数据集的质量,针对部分特定模型可采取效果较好的特征工程(归一化、边缘放大等)来处理,同类问题的样本也期望能在后续不同的模型里能够流通作比较,来评估不同模型的准确度和效率。

9.png
(数据样本工程体系)

【模型】

针对模型的召回和误判问题,我们尝试收敛场景来提高准确度。往往不同场景下的样本会存在一些特征上的相似点或者影响部分分类局部关键特征点,导致产生误判、召回低,我们期望能够通过收敛场景来做模式化的识别,提高模型准确度。

我们把场景收敛到如下三个场景:无线 C 端营销频道场景、小程序场景以及 PC 中后台场景。这里面几个场景的设计模式都有自己的特色,针对各个场景来设计垂直的识别模型可以高效地提高单一场景的识别准确度。

10.png
(D2C 场景)

3)思考与解法

总的来说,既然使用了深度模型,有一个比较现实的问题是,模型的泛化能力不够,识别的准确率必然不能 100% 让用户满意,除了能够在后续不断地补充这批识别不到的样本数据外,在这之前我们能做什么?

在 D2C 的整个还原链路里,对于识别模型,我们还遵守一个方法论,即设计一套协议或者规则能通过其他方式来兜底深度模型的识别效果,保障在模型识别不准确的情况下用户仍可完成诉求:手动约定 > 规则策略 > 机器学习 > 深度模型。举个例子比如需要识别设计稿里的一个循环体:

  • 初期,我们可以在设计稿里手动约定循环体的协议来达成;
  • 根据图层的上下文信息可做一些规则的判断,来判断是否是循环体;
  • 利用机器学习的图层特征,可尝试做规则策略的更上游的策略优化;
  • 生成循环体的一些正负样本来通过深度模型进行学习。

其中手动约定的设计稿协议解析优先级最高,这样也能确保后续的流程不受阻塞和错误识别的干扰。

imgcook x 云开发平台

了解前端智能化和 imgcook 大致思路之后,那么为什么会选择在云开发平台上集成 imgcook 呢?那就是 imgcook 和云开发平台通过彼此的打通,将能够为双方解决彼此的痛点,无论是为云上开发者,还是 imgcook 开发者都提供了全新的用户体验。

对于 imgcook 开发者来说,其中一个痛点就来自于对于设计稿的管理,以及前后端交互的逻辑,然而通过云开发平台,开发者不再需要在本地安装 Sketch,通过云开发平台直接上传设计稿即可开始生成代码,真正做到了0成本一键生成。

另外云开发平台上直接提供了Midway Serverless 框架,我们通过云开发平台的插件定制化,可以让开发者直接选择某个页面所使用的函数(Function),这样就节省掉编写一些前后端交互的基础逻辑或请求代码。

对于云开发平台的开发者来说,最想得到的便是极速的上线体验和更加便捷的开发体验,imgcook 可以降低云开发平台的使用门槛,比如一位 FaaS 应用工程师不再需要学习如何切图,如何写 CSS,而只需要编写 FaaS 函数的逻辑即可,剩下的前端逻辑代码都可以通过 imgcook 插件在开发平台内即可完成,这是多么棒的体验啊!

那么,接下来就看看如何快速地从0到1生成代码吧。

首先需要先打开云开发平台创建应用,选择 imgcook 创建应用:

11.png

然后在应用的 WebIDE 中通过右键打开 imgcook 云插件,就可以正式开始使用了。

12.png

第一步,在插件中选择“导入”,打开上传设计稿界面:

13.png

第二步,imgcook 可视化编辑器:

14.png

第三步,生成代码:

15.png

第四步,导出代码到应用:

16.png

第五步,上线应用:

$ npm install
$ npm run dev
正在启动,请稍后...
---------------------------------------
开发服务器已成功启动
请打开 >>> http://*****-3000.xide.aliyun.com/
---------------------------------------
感谢使用 Midway Serverless,欢迎 Star!
https://github.com/midwayjs/midway
---------------------------------------

启动成功后通过命令行的地址打开页面效果如下,是不是很简单呢?

17.png

总结

本文通过介绍前端智能化的背景,imgcook 的问题定义以及技术方案,以及如何在云开发平台上使用 imgcook 开始智能开发,总的来说,还是希望让业内的前端工程师们从使用 imgcook 开始,将日常工作中的一些繁琐、耗时的工作交给 AI 来完成,这样能关注工程师本身更感兴趣,也更有价值的事情,也相信不久的将来,前端工程师将借助于 AI 能更加快乐与从容地工作!

点击链接立即体验:https://yunqi.aliyun.com/2020/hol

阿里巴巴云原生关注微服务、Serverless、容器、Service Mesh 等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践,做最懂云原生开发者的公众号。”

写在 Dubbo go 的第五年

alicloudnative阅读(1860)评论(0)

头图.png

作者 | 于雨

阿里巴巴云原生公众号后台回复“915”即可查看 dubbogo v1.5.1 项目管理图清晰大图!

引语

dubbogo 项目已进入第五个年头。

项目发展的前两年,我们把 hessian2 协议库、网络库和整体基础框架搭建一番。从 2018 年项目被 Dubbo 官方接纳开始,依托阿里平台,社区开始形成并快速发展。与社区同学们齐心合力之下,如今全面兼容 Dubbo v2.7.x 的 Dubbo-go v1.5.1 已经发布。

立项

一个项目整体必须提炼出核心目标,指明其存在的意义和价值。有了初心,项目发展过程中产生困惑时,才能明确答复 “我是谁?从哪里来?到哪里去”。

1. dubbogo

dubbogo 项目有其自身的 milestone 要求,大致规划了每个阶段的关键里程碑,在项目发展初期仅仅是实现 Dubbo 的某个功能,但在发展过程中会不断结合当下的技术发展潮流,不断修正其未来发展方向。

其发版计划是通过“开发当前版本、规划新版本、根据反馈修正新版本”的模式定义当前版本的开发内容和下一个版本的发展方向。每次发版后会根据社区使用反馈对下一代的发展目标进行修正。

站在吃瓜人的角度,或许可以说出 “dubbogo 不就是 dubbo 的 Go 语言版本嘛,照着抄就是了” 之类的论调。而参与过 dubbogo 项目跟着社区一路走来的人,就知道 dubbogo 并不简单定位于 Dubbo 项目的 Go 语言版本。

dubbogo 初心不变,不同时间对自身定位均有升级。我认为当前 dubbogo 的定位是:

  • 全面兼容 Dubbo;
  • 一个 Go 语言应用通信框架,充分利用作为云原生时代第一语言—Go 语言的优势,扩展 dubbo 的能力。

2. dubbo-go-proxy

dubbogo 项目初期目的是依靠 Dubbo 实现 “bridge the gap between Java and Go” ,目前 dubbogo 正与 Dubbo 齐头并进,已经达到项目立项的目标。有长期生命的通信框架,大概有 5 年的成长期和 5 年的稳定成熟期。目前的 dubbogo 处在成长期和稳定成熟期的过渡期,这意味着社区如果想保持发展态势,就必须开始走多元化道路,发展自己的生态了。

眼下 dubbogo 社区正在集中精力孵化一个新的项目—实现一个基于 dubbogo 的 HTTP 网关,项目的意义是:dubbogo 自身是一个流量控制中间件,在其上扩展项目,其方向很自然就是做一个 proxy/sidecar or gateway,且社区一直有网关这方面的需求。

项目目的如下:

  • 做一个具有生产使用意义的网关;
  • dubbo-go-proxy 验证 dubbogo 的能力,对 dubbogo 未来的进化指出新方向,共同进化;
  • 优化 dubbogo 的稳定性和性能。

团队

项目立项完毕后,就进入招兵买马阶段了。

1. 来源

dubbogo 社区发展初期,其关键成员都是通过提交 issue 或者 pr 的同学撩来的。通过这种方式撩来的同学因为志同道合,有极高的概率同社区一起走下来。dubbogo 社区的 core member 就是这样来的。

其次是与其他公司的合作。dubbogo 本身是一个有着极高生产环境需求的项目,在发展过程中依次与携程、涂鸦、斗鱼、虎牙、蚂蚁金服和阿里集团有过极深的合作,其间与携程的合作对 dubbogo 成型而言极为关键。

另一个途径是与其他社区合作。dubbogo 项目发展过程中,与以下社区合作过:

  • 与 MOSN 社区合作实现 Dubbo Mesh;
  • 与 sentinel 社区合作,在 Dubbo/Dubbo-go 完整接入 sentinel 的降级和限流方案;
  • 与 Apollo 社区合作,在 Dubbo-go 中实现远程配置下发;
  • 与 Nacos 社区合作,实现基于 Nacos 的服务发现。

与其他社区合作的好处是使得双方的项目都受益:扩展双方的能力和使用场景,其次是社区间人员的流动。在合作过程中,dubbogo 自身受益极大,目前有 4 个社区 committer 来自于其它社区。合作完成后并不意味着结束,而是一个新的双赢的开始:社区项目也是发展的,当一个项目有新特性时可以同时快速被另一个项目采用验证,对扩展开发者们的技术能力和人脉也是极为有利的,dubbogo 社区目前的好几个同学同时活跃在多个社区。

dubbogo 项目已经过了草莽阶段,形成了一个的 800 多人的社区群,所以 dubbogo-proxy 项目立项后,很快就在社区群内找到很多项目爱好者。

2. 成员的 qualification

项目发展初期有很多同学会 Java 不懂 Dubbo 不会 Go,最后都通过参与项目提升了自我的能力。当然有些人会担心项目代码的质量,但只要秉持 “Community Over Code” 这个 “Apache Way”,在发展过程中这些问题都不大。

2019 年时,参与 dubbogo 项目的成员中一部分同学平时的工作是进行业务开发,秉承着对中间件通信技术 “我是谁?我从哪里来?要到那里去” 的初心参与 dubbogo 的开发,无论是对 dubbogo 抑或是对其自身技术水平提升都产生了积极的影响。

dubbogo 社区对 dubbogo 发版时间有一定期限要求,所以对参与人员的时间投入也有一定的要求。每个版本的核心功能的 owner,需要保证在 deadline 期限内完成开发任务。

dubbogo 每个版本都有一个发版人,负责相应版本的任务拆分、发展跟踪、代码 Review 和最后的测试验收,这就要求发版人自身的技术水平和时间投入极高。目前 dubbogo 每个大版本的发版人都不是同一个人,每次 dubbogo 发版,都意味着每个发版人的体力和精力的极大付出。于某在此致敬历届发版人!

管理

项目立项后,就需要明确发展大方向、发展 milestone、版本规划、以及一段时间内的具体的开发规划。项目发展初期,Roadmap 可以不清晰,先摸着石头过河,在发展过程中逐步明确其内容。

1. 需求收集

dubbogo 项目发展初期,其目标仅仅是实现 dubbo 某个版本的功能, 所以其需求收集并不用花费很久时间。随着 2019 年 8 月份发布 v1.0 后,dubbogo 越来越多地被多家生产厂商投入生产使用环境中,目前其需求方来源如下:

  • 实现 dubbo 某个版本的功能;
  • 实际使用方的生产需求;
  • 为紧跟当下最近技术发展方向而进行的技术预演。

dubbogo 当前的 K8s 注册中心技术方案就是紧跟最新技术发展方向而进行预演的极好例证,其发展时间线如下:

  • 2019 年 7 月,随着阿里集团和蚂蚁金服在云原生方向的推波助澜,阿里 dubbo 开发团队并未给出可靠的技术方向,dubbogo 社区 core members 也都没有云原生方向的技术积累和相应人才,决定先开发一个基于 kube-apiserver 的注册中心,以进行技术储备;
  • 2019 年 8 月, 调研 dubbo 的 K8s 注册中心方案后,dubbogo 社区决定抛开它独立实现一个,争取以最低代价把 dubbo 应用迁移到 K8s 环境中运行起来,同时决定未来的发展方向是 dubbogo operator;
  • 2019 年 11 月,社区的王翔同学给出了初步实现,在 2020 年 1 月随 dubbogo v1.2 版本发布;
  • 2020 年 4 月,有用户要求在 K8s 环境中 consumer 可跨 namespace 访问 provider,相应实现在 2020 年 7 月随着 dubbogo v1.5 版本发布;
  • 2020 年 5 月,dubbogo 社区和 mosn 社区合作实现了 dubbo mesh;
  • 2020 年 6 月,社区意识到 kube-apiserver 是系统的运维态 IaaS 层的核心组件,不应该跨过 PaaS 层直接暴露给应用层,否则应用层使用不当或者框架自身的流量方面的 bug 把 kube-apiserver 打垮后将造成整个系统的 P0 级故障,dubbogo v1.6 应当给出 dubbogo operator 的具体实现;
  • 2020 年 7 月,dubbogo v1.5 发布后,社区已经知道完全可以把目前的 kube-apiserver 注册中心的实现独立成为一个 dubbogo operator,未来的方向是结合 Istio 拓展其灰度发布、限流、故障注入和配置动态下发能力。

至于 dubbo-go-proxy ,dubbogo 社区并不打算借鉴其他项目,完全依靠社区同学贡献各自想法后,进行项目需求收集。目前 dubbogo 社区已经收集完毕 dubbo-go-proxy 的项目需求方的意见,社区已有 5 位同学参与项目一期开发,预计 10 月份发布初版。

2. 项目管理

需求收集完毕,定义近期一段时间内的开发目标后,就进入了项目任务拆解和项目开发管理阶段。像 dubbogo 和 dubbo-go-proxy 这种后来者项目,处于追赶阶段,个人理解它们并没有所谓的后发优势,更没有特定的技术优势,能够做的就是快速迭代,缩短与竞品的差距。

dubbogo 要求接受开发任务的各个 feature owner 必须在某个 deadline 前完成相应的开发任务。当然,feature 的等级不同,非核心 feature 【如技术预演性的 feature】允许 delay,顺延发布也无不可。

我们在项目每个版本的需求收集阶段,会把爱好者统一拉入一个小群进行沟通交流。进入开发阶段时,由于项目时间 deadline 限定以及技术匹配度两项要求,每个版本就很自然能选出能够留下来参与项目开发的人。最终参与每个版本开发的人尽量不要超过 7 个人,否则沟通成本就会剧增。

下图是 dubbogo v1.5.1 的项目管理图(阿里巴巴云原生公众号后台回复“915”即可查看清晰大图)

1.png

其有任务分解、技术风险以及风险预案。

2.png

工具是生产力,目前以 dubbogo 项目开发进度跟踪工具使用 Github Projects。如上图,每个子任务进度,这个工具都会及时显示,相应的任务 owner 可以及时根据任务进度和 deadline ,调整开发计划。更进一步的好处是,没有人会对工具产生意见,摆脱“交通基本靠走,通讯基本靠吼”的沟通模式,减少版本发版人和 feature owner 之间的戾气。

3. 代码质量

开源项目的开发任务不仅仅是开发代码,也不意味着因为各个 owner 仅仅是业余时间参与开源项目就可以降低对代码质量要求。

工具就是生产力,合适的工具能够减少人工工作量和提升代码质量。dubbogo 在项目开发过程中的各个阶段都用到了如下工具:

  • auto-comment:contributor 提出 issue 或者 pr 后,可很方便地发出预先定制的评语;
  • hound:一个 Go 语言项目静态代码检测工具,自动 Review 代码;
  • travis:一个 Github 项目自动化测试工具,可自动执行代码单测和用户自定义的集成测试,并发出钉钉通知;
  • 人工 Review:dubbogo 社区要求每个 pr 至少有三个 committer 级别的人 Review 通过;
  • goreportcard:一个很好的 Github 项目静态代码检测工具;
  • gitee:作为国内一个比较强大的代码托管网站,免费为项目提供了一些代码安全和静态代码质量检测工具,dubbogo 也经常使用,受益良多;
  • 代码规范,社区内部有一份简单的代码规范,并随着项目发展不断完善。

展望

dubbogo 项目每次发完版本,发版人都会首先发出一份 “What’s New”,除了总结最新版本的特性外,还会总结其近期进展并对未来发展进行规划,以帮助项目爱好者和使用者了解其实现思路和使用方法。

dubbogo 自身还有很多缺点,如:

  • 网站建设和文档质量都有待改进;
  • API 用户友好度不够;
  • 配置文件过多且没有合理的文档说明导致入门门槛高;
  • 整体性能改进,很多地方可添加调用链的缓存以减小锁竞争;
  • 添加 prometheus 指标,继续提高 可观测性;
  • 在协议层面支持其他微服务框架,实现原生通信,以继续提升其互联互通性;
  • dubbo-samples 用例不够丰富,继续添加测试用例,以减小入门门槛;

希望借助社区之力,在 dubbogo 发展过程中消化并解决掉这些问题,dubbogo 社区【钉钉群号 23331795】与 dubbogo 同在。

作者简介

于雨,一个有十多年服务端基础架构研发一线工作经验的程序员,目前在蚂蚁金服可信原生部从事容器编排和 service mesh 工作。热爱开源,从 2015 年给 Redis 贡献代码开始,陆续改进过 Muduo/Pika/Dubbo/Dubbo-go 等知名项目。

阿里巴巴云原生关注微服务、Serverless、容器、Service Mesh 等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践,做最懂云原生开发者的公众号。”

阿里云 OpenYurt 成为 CNCF 沙箱项目,加速原生 Kubernetes 边缘场景全覆盖

alicloudnative阅读(1990)评论(0)

1.png

2020 年 9 月 9 号,经 CNCF 技术监督委员会投票一致同意,阿里巴巴云原生边缘计算平台 OpenYurt 正式成为 CNCF 沙箱级别项目(Sandbox Level Project),标志着 OpenYurt 在边缘计算场景中构建云原生基础设施的能力受到了行业的广泛认可。

OpenYurt 项目地址:https://github.com/alibaba/openyurt

OpenYurt 致力于将阿里云在云原生边缘计算领域的大规模实践经验回馈给开源社区,加速云计算向边缘全面延伸的进程,与社区共建未来云原生边缘计算架构的统一标准。

如何打造边缘基础设施成为新课题

Gartner 预测,到 2022 年,超过 50% 的企业生成数据将在数据中心或云之外进行创建和处理,20% 的新工业控制系统将拥有分析和 AI 边缘推理能力,至少 50% 的现场物联网项目将使用容器进行边缘应用程序生命周期管理。边缘计算正在成为新时代网络、计算、存储、应用等近端整体解决方案的基础设施和基础能力。

然而,边缘计算规模和业务复杂度的日益提升对效率、可靠性、资源利用率等能力提出了新的诉求。传统云计算中心集中存储、计算的模式已经无法满足边缘设备对于时效、容量、算力的需求,如何打造边缘基础设施成了一个新课题。

OpenYurt 应运而生,边缘场景全覆盖

2017 年底,作为典型的边缘计算业务,阿里云物联网(IoT)和 CDN 服务正面临着产品规模的爆发式增长、运维复杂度急剧攀升、运维效率不高的“三难”境地,边缘应用运维管理模式的全面转型成为亟待解决的问题。

秉承“Extending your native Kubernetes to  Edge”的非侵入式设计理念,云原生边缘计算平台 OpenYurt 诞生于阿里云容器服务团队。与其他类似产品不同的是,OpenYurt 拥有可实现边缘计算全场景覆盖的能力。在短短两年内,作为公共云服务 ACK@Edge 的核心框架,OpenYurt 已实现全网覆盖和本地覆盖的全场景落地,全网覆盖的应用场景如 CDN、音视频直播、物联网、物流、工业大脑、城市大脑等;本地覆盖的应用场景和案例如阿里云 LinkEdge、优酷、盒马、AIBox、银泰商城等,其中,帮助优酷实现端到端延迟降低 75%,机器成本节省 50%;盒马鲜生实现新门店开服效率提升 70%,资源成本节省 50% 以上。

2.png

Kubernetes 生态全兼容,打造边缘云原生基础设施

自 OpenYurt 诞生以来,接管业务容器数量超过百万,覆盖新零售、医疗、物联网、在线教育、边缘智能、交通等众多行业,受到了业界广泛欢迎与认可。这一切得益于 OpenYurt 沿用了目前业界流行的“中心管控、边缘自治”的边缘应用管理架构,以非侵入式增强 Kubernetes 的设计理念,将云原生能力拓展至边缘端,可降低资源成本、降低运维复杂度、获得云边一致性运维体验、实现大规模边缘业务轻松管理。

3.png
OpenYurt 架构图

OpenYurt 主要特性包括:

  • Kubernetes 生态全兼容:对原生 Kubernetes “零”侵入,保证对原生 Kubernetes 完整生态的全部兼容,OpenYurt 集群可以紧跟 Kubernetes 社区版本升级节奏,同时也意味云原生社区主流技术(如 Service mesh, Serverless 等)可以轻松落地 OpenYurt;
  • 边缘异构资源支持:对不同边缘节点硬件架构(x86 / arm / arm64 等),硬件规格,通信协议提供一致体验;
  • 高可靠/稳定性:基于边缘自治和边缘单元化能力,为多地域,大规模的边缘应用的持续稳定运行提供保障。支持各类开源 AI 系统(如 Tensorflow,pytorch 等),为 AI 用户提供最佳体验;
  • 云平台无关:OpenYurt 可以轻松部署在任何公共云的 Kubernetes 服务中。

作为对原生 Kubernetes 完整生态全部兼容的智能开放平台,OpenYurt 将以更灵活和可扩展的体系结构方向发展,不断增强开源开发者友好体验。阿里云容器服务负责人易立表示OpenYurt 还将基于行业场景与 5G、AI、大数据、区块链等新兴技术结合,驱动企业业务加速创新。未来 OpenYurt 将与社区并肩、与生态同行,致力于推进云原生技术在边缘计算领域的生态建设与普及,与全球开发者一起拓展云原生的边界。

欢迎大家参与该项目的共建,有问题可以钉钉搜索群号:31993519,进群交流!

阿里巴巴云原生关注微服务、Serverless、容器、Service Mesh 等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践,做最懂云原生开发者的公众号。”