CiciXY

CiciXY 查看完整档案

北京编辑  |  填写毕业院校SegmentFault  |  勤杂工 编辑 segmentfault.com/u/cicixy 编辑
编辑

SegmentFault 思否社区勤杂工
社区、公号、活动等等所有天马行空无与伦比的合作欢迎联系!

联系邮箱 cici@sifou.com

个人动态

CiciXY 赞了文章 · 10月23日

2 个月激烈角逐,15 支队伍突围决赛路演!Geek Online 2020 编程挑战赛完美收官!

2020 春季的一场疫情,让远程办公和在线教育在全球范围内成为一种常态。

疫情终将过去,但疫情为人们带来的新的工作及生活方式却将持续地影响着我们。后疫情时代,远程实时互动技术的重要性被提到了新的高度,下一代互联网通信云将如何作用于人们的工作和生活?

融云作为全球领先的互联网通信云厂商,一直致力于 RTC 技术的创新和发展,并于近期举办了 Geek Online 2020 编程挑战赛,希望借此机会与全球开发者一道,共同寻找 RTC 技术的更多落地场景,开辟更多使用途径。

10 月 17 日,为期两个月的编程挑战赛迎来了最为紧张的决赛阶段, 15 支队伍进行了线上的路演答辩。

决赛路演,大屏直播互动

本届 Geek Online 2020 编程挑战赛以《后疫情时代,通信云技术的创新及实践》为主题,鼓励开发者挖掘关于实时音视频和即时通讯技术的更多创意。通过近 2 个月的激烈角逐,在近百份参赛作品中,15 支队伍突出重围,闯入总决赛,他们通过线上展示的方式和大家分享,角逐最后的冠军。

本次决赛的评委共有四位,分别是融云联合创始人兼 CTO 杨攀、思否联合创始人兼 CTO 祁宁、泰岳梧桐资本合伙人杨扬以及通过线上直播参与路演的评委云启资本董事总经理陈昱。

路演答辩借助了融云 RTC 技术搭建了一个实时互动直播平台,选手轮流进入融云实时音视频 - SealRTC 平台进行画面共享,四位导师也可以在平台内实时与选手视频交流互动。

路演直播画面

部分参赛选手作品展示 & 评委点评

冠军团队 - 缘拼

该团队成员擅长 uniapp 以及微信小程序开发,作品基于融云 RTC 技术。这是一款基于兴趣、基于地理位置的同城社交类小程序,可以语音、视频构建同城兴趣小组,并将线上兴趣转换为线下社交行为。相当于将豆瓣兴趣小组音视频化。



亚军团队 - 红鲤鱼与绿鲤鱼与驴

该作品由两位选手共同完成,分别是熟悉前端、WebRTC 方向的“红鲤鱼”和熟悉后端、大数据方向的“绿鲤鱼”。这是一款帮忙新手程序员迅速熟悉融云 SDK 的小游戏,通过识别二维码拼图的游戏,让了解融云的过程有趣味性。该作品层次丰富,第一层需要用户集成融云 SDK、掌握融云的基本概念,第二层需要用户做一定程度的视频后处理,第三层需要用户做一些图像识别。



季军团队 - youweyoung

获得第三名的团队包含了一位拥有前后端多年开发经验的选手。作品基于 Android 操作系统使用 RTC 混合开发,最终做出了音视频通话应用 —— IYI网络剧场,将角色扮演类的剧本杀游戏以视频形式展现,每个场景有不同的主题人物并且可以替换,人物则是以皮影、动画等形式展现,适用于远程视频讲故事或玩剧本杀,有一定新颖性。



科技创新奖团队 - 萍水相逢的生活

这支队伍只有一位选手,他是一个心怀想法的程序员,做的产品是一个基于事务的陌生人聊天系统,事务场景可以是租房加中介的联系方式、街头偶遇添加好友、发布大字报等,这款产品的设计思路旨在为大家生活提供便利的软件。



商业价值奖团队 - MAXFLOAT

MAXFLOAT 是一支有实力,有梦想,有创意,敢拼搏,即想即做的队伍。他们认为当前城市化生活环境下人与人的交流越来越少,宠物逐渐替代朋友成为更好的伙伴,养宠物的越来越多,但随之而来的是更多的问题,比如宠物的遗失、被抛弃造成了流浪宠物越来越多,而宠物的健康,有时也不能及时得到重视。因此他们做了一款以宠物招领、寄养、寻回、宠物医生等为主,以宠物信息普及、宠物疾病普及为辅的 APP 帮助广大宠物爱好者。


包含获奖团队在内的 15 组团队,作品各具特色,即为评委以及线上观众们展示了自身的产品创意,也展示了 RTC 技术在实际应用中的能力与延展性,很多选手的作品获得了评委们的高度评价。我们对获奖团队进行了单独的采访,内容会于后续发出,敬请期待。

在选手们精彩的分享以及答辩之后,四位评委嘉宾分别给出了对于参加本次比赛的感受。


“融云始于 IM,又不止于 IM。通过融云提供的技术以及服务能力,开发者们可以更加关注线上的优化与迭代,期待更多开发者利用融云SDK,开发更创新、强大的产品。” —— 陈昱


“本次的决赛中我有很多印象深刻的作品,有的非常符合开发者的口味,有的对于使用场景有着很深入的思考。因为疫情,通信云技术的需求正在变得越来越大、越来越丰富,有很多场景需要我们去开拓,很值得开发者们关注并付出行动。” —— 祁宁


“选手们有很多创意创新点都很好,将很多现实中生活化的场景融入到比赛中,也有一些具有极客特质的项目,这些都是融云自身生态开发能力非常好的体现。对于融云来说,开发者是宝贵的资源,而通信云的生态也需要非常广泛的群体参与,共同完善。” —— 杨扬


“很高兴的看到,决赛中有很多作品提到了人们的心理问题,除开产品技术本身,还致力于解决人文层面的诉求。基于 IM 的核心能力,选手们提供了很多在线的沟通场景,比如剧本杀、狼人杀等等,基于这些实时互动的模式,通信能力已经变成了现代应用的一种基础设施,能为产业、产品和应用场景提供帮助,这让我们既感到压力,也感受到了更强大的动力。” —— 杨攀

结语

通过选手们的展示,我们可以了解到通信云技术的发展和提升不仅仅可以作用于工作和学习,关于实时音视频和即时通讯技术的应用,还有更多创新的场景等待我们用全新的思维来发掘。

Geek Online 2020 编程挑战赛虽然是第一次举办,但已经收获了参赛选手以及观看决赛路演直播观众们的一致好评,部分选手在路演结束后已经联系主办方咨询第二届比赛的安排,想要提前报名。

融云作为专注于通信的 PaaS 云服务平台,想要通过底层的基础模块支持,帮助企业与开发者构建「云通信」的能力。举办此次编程挑战赛的目的,也是希望让开发者们碰撞出技术的思维火花,加速潮流技术的应用创新,也为开发者们搭建了一个沟通、交流、合作的平台,希望能够掀起一股通信技术应用的探索与实践热潮。

点击进入大赛官网,查看更多比赛信息

查看原文

赞 1 收藏 0 评论 0

CiciXY 赞了文章 · 9月29日

APP如何做到快速流量变现?我想我找到了答案

最近经常有开发者向我讲述他们在产品变现时候面临的一些痛点:

  • 我是开发者,想做流量变现,不知道如何接广告。随便找到了一个平台没想到点击率和单价这么低。
  • 接入某某广告平台的流程异常复杂,审核资料要求极多。形式很多样但却不知道哪种合适自己。
  • 传统想法以为如果要提高广告收入,你就不得不开始破坏用户体验,但这些都是导致应用走不长久的最下策。

其实这些问题是每个开发者都会遇到的,甚至不夸张的说很多开发者因为这些问题没有解决,不得不放弃一款产品。但这些问题真的很难解决吗?答案是只要找到正确的渠道,问题很好解决。

开发者们到底需要平台们提供什么帮助?

开发者们到底需要平台们提供什么帮助?

我认为是产品持续成长和更高的收益可能性。

其实从穿山甲平台的「新星助推计划」我们就可以窥见到平台帮助开发者解决问题的思路,并了解到开发者们能如何实现破局。

首先是从2020年9月持续至2020年12月底在50亿元优质开发者专项激励基础上,额外提供3000万元成长激励金,帮助500个开发者做到激励翻倍,每月将为成长中的高潜力开发者提供最高80%的额外收益补贴。

其次,平台推出Growth Lab,其中涵盖商业化、运营调优、数据监控分析等全生命周期多元化产品工具,从拓展广告场景、提升用户留存转化、提升产品ROI等多角度助力开发者科学复盘,帮助产品快速变现,突破产品成长瓶颈。

新星助推计划的种种帮助,转化到开发者方面,会给开发者变现和成长环境,带来三个维度的改善。

  • 首先,开发者相比以前更加的省心,开发者通过新星助推计划,能获得产品能力和技能培训全方位扶持,得到更加多元化和更全面的成长机会
  • 其次,参加的开发者能得到实在的金钱收益,入选的开发者可获得最高80%的额外分成奖励,也就是说,优质开发者月收益补贴额度最高将达到180%。
  • 最后,它让开发者更放心,不仅在APP体验上为开发者完成产品把脉,穿山甲更提供的全链路生态环境,开发者们可以更好克服数据孤岛,平滑向下一发展阶段过渡。从而实现变现与用户体验的平衡。

如果你也面临开发和变现中的困境,扫描进入下方小程序,报名「新星助推计划」

新星助推计划

开发者对「新星助推计划」的评价

关于「新星助推计划」,我也和几位资深开发者聊了一下,如果你想听听他们的看法,不妨往下看看。

社交产品开发者A:我个人觉得平台的服务力是非常重要的,参加了新星助推计划后,让我感受最深的是平台带给我的超贴心的服务,相对于其他竞品在这里我听到了最为专业的买量和变现指导。

工具产品开发者B:以前一直苦于没有多种开放的商业化能力和创新的广告场景,生硬的广告展现方式让我们流失了大量用户。接入穿山甲后,了解到了平台基于的多样的广告方式,特别是激励视频,为我们拓展了新的变现思路。这次使用后不仅让我们的产品得到了更大的收益,也有效增长了用户使用时长,提升了用户留存。

摄影APP开发者C:平时比较忙,没时间去学习产品变现知识,我在使用穿山甲的过程中,发现平台提供的「开发者成长中心」小程序里不仅有官方讲师全面解读开发者的变现难题,而且面向我们这些不同需求的开发者,还推出了不同难度的课程。使我能利用碎片时间学到一些很实用的知识。

移动端小游戏开发者D:为了测算ROI,我们不仅要全渠道埋点,还必须独自承担从埋点到统计分析变现、投放数据的人力成本。这样不仅分散了资源,无形之中还限制了团队的灵感发挥。穿山甲提供数据看板的能力,大大节约了我们的时间,从而不至于陷入繁杂的数据分析和体力劳动当中。

新星助推计划

虽然上面的内容已经让你对「新星助推计划」有了一定的了解,但亲身参与才会获得更多。对于成长中以及陷于变现难题的开发者们来说,新星助推计划的确是一个值得一试的活动。

扫描进入下方小程序,报名「新星助推计划」

新星助推计划

查看原文

赞 14 收藏 2 评论 0

CiciXY 赞了文章 · 9月23日

【大数据云原生系列】大数据系统云原生渐进式演进最佳实践

1.引言

随着云原生概念的兴起,越来越多的企业投身于云原生转型的浪潮,以解决传统应用面临的弹性能力不足、资源利用率较低、迭代周期较长等问题。通过云原生技术(如容器,不可变基础设施和声明式API等),使得企业在公有云、私有云和混合云等云环境构建和运行应用变得更加容易,更能充分利用云环境的优势,加速了企业应用迭代、降低资源成本、提高系统容错性和资源弹性。

基于Hadoop生态的传统大数据系统,同样面临着弹性能力不足、资源利用率低,管理困难等问题,云原生技术天然适合解决这些问题。然而,将基于Hadoop生态的传统大数据系统改造成云原生架构,涉及到改造成本高、迁移风险大等诸多挑战。那有没有方案,既可以基于云原生技术解决大数据系统弹性能力不足,资源利用率低,管理困难等问题,又能保证改造成本、迁移风险比较低呢?腾讯云大数据团队和容器团队,基于大数据系统的现状,结合大数据技术和容器技术的特点,推出了渐进式的云原生演进方案。使用该方案,可以在较小改造成本和迁移风险的前提下,实现大数据系统的云原生化,充分利用云原生的优势。

本文依次分析了大数据系统当前面临的主要问题、云原生如何解决这些问题、大数据系统云原生改造面临的挑战,基于这些问题和调整,重点介绍了基于Hadoop Yarn on Kubernetes Pod(下文会详细介绍)的渐进式的云原生演进方案及其最佳实践。

2.大数据系统主要问题

传统的大数据系统围绕着Hadoop生态快速的发展,百花齐放,各个企业也逐步建立了自己的大数据平台,甚至是数据中台。然而,在激烈的市场竞争和不断增加的消费期望的双重驱动下,一方面业务需要快速迭代以满足迅速的增长,另一方面需要在资源需求不断增长的同时控制高昂的成本以保持企业的竞争力。这就要求大数据系统能够及时、快速的扩容以满足生产需求,又能尽可能的提高资源的使用效率,降低资源的使用成本。具体的问题体现在以下几点:

  • 弹性扩缩容能力无法满足快速增长的业务需求:随着业务的发展,流量和数据量突增,尤其对于实时计算,需要资源能够及时的扩容,以满足业务需求。尽管一些大数据管控平台尝试实现自动的扩缩容(如通过集群负载情况,进行扩容),然而,在传统大数据平台架构下,通常需要资源申请、依赖软件安装、服务部署等一系列步骤,该过程通常比较慢,对于集群负载的缓解,不够及时。
  • 在离线分离部署及粗粒度调度无法提高资源的利用率:在传统Hadoop架构下,离线作业和在线作业往往分属不同的集群,然而在线业务、流式作业具有明显的波峰波谷特性,在波谷时段,会有大量的资源处于闲置状态,造成资源的浪费和成本的提升。在离线混部集群,通过动态调度削峰填谷,当在线集群的使用率处于波谷时段,将离线任务调度到在线集群,可以显著的提高资源的利用率。然而,Hadoop Yarn目前只能通过NodeManager上报的静态资源情况进行分配,无法基于动态资源调度,无法很好的支持在线、离线业务混部的场景。
  • 操作系统镜像及部署复杂性拖慢应用发布:虚拟机或裸金属设备所依赖的镜像,包含了诸多软件包,如HDFS、Spark、Flink、Hadoop等,系统的镜像远远大于10GB,通常存在镜像过大、制作繁琐、镜像跨地域分发周期长等问题。基于这些问题,有些大数据开发团队不得不将需求划分为镜像类和非镜像类需求,当需要修改镜像的需求积累到一定程度,才统一进行发布,迭代速度受限,当遇到用户紧急且需要修改镜像的需求时,势必面临很大的业务压力。同时,购买资源后,应用的部署涉及到依赖部署、服务部署等环节,进一步拖慢应用的发布。

​ 图1 大数据系统主要问题

以上提到的弹性扩缩容、应用发布效率和资源利用率,是当前大数据系统普遍存在的问题,如何解决和应对这些问题,越来越成为企业较为关心的话题。接下来,我们将从云原生的角度来分析如何解决这些问题。

3. 云原生技术如何解决大数据系统问题

云原生技术如何解决弹性扩容问题: 在云原生架构中,应用程序及其依赖环境已经提前构建在镜像中,应用程序运行在基于该镜像启动的容器中。在业务高峰期,随着业务量的上升,向云原生环境申请容器资源,只需等待镜像下载完成即可启动容器(一般镜像下载时间也是秒级的),当容器启动后,业务应用将立即运行并提供算力,不存在虚拟机的创建、依赖软件安装和服务部署等耗时的环节。而在业务低峰期,删除闲置的容器,即可下线相应的应用程序,以节省资源使用的成本。借助云原生环境和容器技术,可以快速的获取容器资源,并基于应用镜像秒级启动应用程序,实现业务的快速启停,实时的扩缩容业务资源以满足生产需求。

云原生技术如何解决资源使用率低的问题: 在传统架构中,大数据业务和在线业务往往部署在不同的资源集群中,这两部分业务相互独立。但大数据业务一般更多的是离线计算类业务,在夜间处于业务高峰,而在线业务恰恰相反夜间常常处于空载状态。云原生技术借助容器完整(CPU,内存,磁盘IO,网络IO等)的隔离能力,及kubernetes强大的编排调度能力,实现在线和离线业务混合部署,从而使在离线业务充分利用在线业务空闲时段的资源,以提高资源利用率。

另外,使用无服务器(serverless)技术,通过容器化的部署方式,做到有计算任务需求时才申请资源,资源按需使用和付费,使用完之后及时退还资源,极大的增加了资源使用的灵活性,提升资源使用的效率,有效的降低了资源使用的成本。

云原生技术如何解决发布周期长的问题: 传统大数据系统中,所有环境基本上使用同一个镜像,依赖环境比较复杂,部署、发布周期往往比较长。有时基础组件需要更新,因为需要重新构建镜像,并上传到各个地域,耗时可能长达数天。而云原生架构使用容器进行部署,应用的发布和基础组件的更新都只需要拉取新的镜像,重新启动容器,具有更新速度快的天然优势,并且不会有环境一致性的问题,可以加快应用发布的节奏,解决应用发布周期长的问题。

4. 大数据系统向云原生架构演进的挑战

云原生的技术虽然能解决当前大数据系统遇到的问题,然而,将大数据系统从传统的基于Hadoop生态的架构,迁移到云原生架构,将会面临一些挑战:

  • 应用改造成本高:将运行在Hadoop平台的大数据应用迁移到云原生平台,一方面需要大数据团队将业务应用进行容器化改造,如系统任务的启动方式、基础设施的适配(环境变量、配置文件获取方式的变更等),这些都需要大数据团队来做适配,在资源管理的方式,则从适配Yarn修改为适配Kubernetes,总体改造成本比较高;另一方面,需要在大数据应用的资源申请层面进行改造,使其具备直接向Kubernetes集群申请资源的特性,也称为Native on Kubernetes。目前Apache Spark、Apache Flink已经从框架内核不同程度的支持了该特性,但整体的完整对依赖于社区的努力。
  • 迁移风险高:一次变更引入的改动越多,引发故障的几率也越多。在Hadoop领域,大数据应用的资源,由 Hadoop Yarn负责管理和调度,具体来说,大数据应用运行在Yarn提供的Container之中,这里的Container,是Yarn中资源的抽象,并非Linux Container,将其迁移至以容器为技术的云原生架构,跨越了底层基础架构,改动面比较大,风险相对也更高。
  • 组织架构造成额外的成本:企业里负责开发和运维Hadoop系统的团队,和容器团队通常分属不同的部门,其技术栈也有明显区别,在迁移的过程中,存在过多的跨部门沟通,带来额外的迁移成本,如果改动比较大,跨部分沟通的成本会非常大。

由此可见,将大数据应用从传统Hadoop架构迁移至Kubernetes架构,并没有那么简单,尤其是依赖社区对大数据应用本身的改造,使其具备运行在云原生平台的能力,然而这些改造,非一朝一夕所能完成,仍需要大数据应用社区在云原生方向作出更多的努力。

5. 大数据系统云原生渐进式演进方案

5.1 渐进式演进方案简介

上文提到的大数据系统现存问题,云原生技术如何解决大数据系统的问题,以及大数据系统从传统架构迁移到云原生架构的挑战。那有没有一种方案既能解决大数据系统的问题,让大数据系统架构更加云原生。又可以降低迁移过程中的改造成本,规避迁移风险呢?

接下来本文将介绍大数据系统渐进式向云原生演进的方案,通过渐进式迁移演进的方式,在架构较小改动的情况下,通过云原生技术解决大数据系统的问题。通过较小的投入,获得云原生技术的红利,并且避免迁移过程的的风险。同时后期还可以在这基础上进一步将大数据系统平滑演进到云原生架构。

渐进式演进方案主要有弹性扩缩容和离在线混合部署两种模式,两个模式的侧重点略有不同,弹性扩缩容主要聚焦于如何利用云原生资源,借助serverless技术,快速扩容资源以补充算力,满足业务实时需求。而离在线混部主要聚焦于利用在线业务空闲时段的闲置资源,通过将大数据离线计算任务调度到在线业务闲置资源的上,在保证业务稳定性的基础上,大幅提升资源的使用效率。这两种模式都使用了Yarn on Kubernetes Pod的形式,如下图,其基本思想是,将Yarn NodeManager运行在Kubernetes集群中新扩容的Pod容器内,当Yarn NodeManager Pod启动后,根据配置文件自动向已有的Hadoop集群的Yarn ResourceManager发起注册,最终以Kubernetes Pod的形式补充Yarn集群的算力。

​ 图2 Yarn on Kubernetes Pod

5.2 渐进式演进之弹性扩缩容模式

在弹性扩缩容模式中,弹性扩缩容模块会根据大数据集群资源的使用情况,动态的向serverless Kubernetes集群申请(释放)资源。申请资源的具体形式为,在Kubernetes集群中创建(销毁)Yarn operator的自定义资源(CustomResourceDefinition,CRD),集群中部署的Yarn-operator会根据crd资源来创建(删除) Yarn pod。在Yarn pod中会启动Yarn nodemanager进程,Yarn nodemanager进程启动后会自动向大数据集群中的Yarn resource-manager发起注册,扩充(减少)大数据集群的算力,满足任务的资源需求。

如图1所示,左侧是运行在腾讯云EMR(弹性MapReduce)系统上的大数据集群,右侧是腾讯云EKS(弹性容器服务)(Serverless Kubernetes)集群。

​ 图3 弹性扩缩容方案(EMR大数据集群)

该方案的关键组件是Yarn-operator和Yarn-autoscaler。Yarn-autoscaler组件通过监听Yarn集群中资源使用的情况,作出扩容或者缩容的判断,然后向EKS集群创建Yarn-operaor crd资源。Yarn-operaor根据crd资源创建或删除对应的Yarn pod实例,这两个的组件的功能如下。

1)Yarn-operator

Yarn-operator通过kubernetes接口监听大数据集群管控平台中Yarn-autoscaler模块创建的crd资源。Yarn-opterator完成的主要功能包括:

(1) 根据crd中的配置创建对应的Yarn pod;
(2) 维护pod的生命周期,在pod出现异常时,自动重启pod;
(3) 指定pod进行缩容
(4) 在pod启动失败时,标记启动失败。

其中pod异常恢复和固定pod name主要参考了kurbernetes statefulsets的设计思路,保证节点异常后能以同样的名称加入到Yarn集群。指定pod进行缩容,支持不受pod下标顺序的限制,删除任意的pod实例,对于关心集群拓扑结构的用户,操作空间更灵活。快速失败标记能够将将长时间未进入running状态的Pod主动删除,避免扩容流程长时间阻塞。

2)Yarn-autoscaler

Yarn-autoscaler组件提供按负载和按时间弹性伸缩两种扩缩容方式。对于按负载伸缩,用户可以对不同指标设置阈值来触发扩缩容,比如设置Yarn root队列的availablevcore、pending vcore、available mem、pending mem等。当Yarn中的这些指标达到预设阈值时,Yarn-autoscaler将触发扩容过程,通过向EKS集群创建的Yarn-opterator的crd资源完成Yarn集群的扩容。

​ 图4 扩缩容规则管理--负载伸缩

对于按时间弹性伸缩,用户可以设置不同的时间规则来触发扩缩容,比如设置一次性、按天、按周、按月重复的规则,当规则触发后,进行弹性扩缩容流程,通过创建(删除)EKS集中的Yarn-opterator的crd资源来完成Yarn集群算力的增减。

​ 图5 扩缩容规则管理--时间伸缩

另外对于云上客户自建的大数据集群,也可以通过将集群导入到EMR的管系统形式来实现弹性扩缩容,提升资源使用的效率。具体的只需在每个节点安装EMR agent组件,然后EMR团队在后台增加对应的集群信息,即可以完成集群的导入。EMR agent本身对集群无任何侵入,消耗的资源也比较小(CPU 消耗小于0.1核,内存消耗小于150M),主要做监控指标采集,日志采集,集群心跳上报等工作。安装完agent后,集群将完整的被EMR管控系统纳管,客户不仅可以使用弹性扩缩容的能力,还可以在既使用自身日志监控的能力的同时使用EMR提供的日志监控能力。后续也可以持续享受EMR提供的各种能力。

​ 图6 弹性扩缩容方案(用户自建集群导入EMR管控系统)

5.3 渐进式演进之在离线混部模式

对于在离线混部模式,节点上的agent组件基于监控统计cpu和内存的真实使用情况,这些统计信息由一个server统一收集,大数据管控平台通过该server,获取当前在线集群中可以提供的闲置算力的规格及数量,调用Knetes api创建对应数量的资源,ex-scheduler扩展调度器确保Pod被创建在剩余资源更多的节点上,其中申请资源的具体形式与弹性扩缩容模式中相同,由Yarn operator根据crd资源创建(删除)Yarn pod。

​ 图7 在离线混部方案

如上图所示,左侧是TKE(腾讯云容器服务)集群,右侧是EMR大数据集群。在线业务具有明显的波峰浪谷特征,而且规律比较明显,尤其是在夜间,资源利用率比较低,这时候大数据管控平台向Kubernetes集群下发创建资源的请求,可以提高大数据应用的算力。这里主要通过四个组件来实现,recomm-agent、recomm-server、ex-scheduler和Yarn-operator。

  • ceres-agent从prometheus(node-exporter、telegraf) 读取节点的cpu idle信息,作为可以超卖的cpu数量,并通过node节点的可分配内存-总体请求内存作为空闲memory数量,并将计算结果patch到Node节点的node.status.capacity字段;
  • ceres-server汇总ceres-agent在各节点patch的可超卖cpu和memory信息,根据http client提供的pod规格,返回可以支持的pod的数量;
  • ex-scheduler是基于Kubernetes scheduler extender实现的一个扩展调度器,相对于Yarn调度器,Kuberentes调度器具有更细的调度粒度,比如以milli-cores为单位进行CPU资源的调度,如500m,表示0.5个cpu、以bytes为单位进行内存资源的调度等,更细的粒度通常能带来更好的资源使用率。该调度器在score打分环节,根据待调度的pod中声明的squeezed-cpu以及ceres-agent在节点的node.status.capacity写入的squeezed-cpu,来决定Node的分值,空闲资源越多的节点,打分越高,从而筛选出实际资源空闲最多的节点。
  • Yarn-opterator的主要作用是根据crd资源,动态创建(删除)pod,功能和弹性扩容模式中的Yarn-opterator一样,这里就不再重复介绍。

5.4 渐进式演进方案如何解决大数据系统的问题

以上两种方案,解决了文章开始提到的一系列问题和挑战。借助渐进式演进的方案,既能解决大数据系统的问题和迁移的挑战,让大数据系统架构更加云原生,充分利用云原生的能力,又可以降低迁移过程中的改造成本,尽可能的规避迁移风险,其主要体现在以下几个方面:

  • 在弹性扩缩容和资源申请方面,借助基于Kubernetes的serveless服务,做到资源按需创建、按需使用和付费;而资源的调度方式,则依然保证不变。具体来说,Kubernetes只是资源的提供方,只提供创建和销毁资源的API,业务方负责调用该API来创建和销毁资源,资源在Kubernetes上创建完成之后,该资源的Yarn NodeManager组件自动向Yarn ResourceManager注册,以Kubernetes Pod的形式提供算力,后续执行作业时涉及到的资源调度,依然由Yarn负责。
  • 在镜像和发布周期方面,容器镜像技术精简了应用的运行环境,镜像只需提供应用必须的依赖环境,使其存储空间得到了极大的减少,上传和下载镜像的时间变的更短,快速启动和销毁变的很容易,总体极大的缩短了应用的发布周期。
  • 在资源利用率方面,借助云原生架构的技术能力,多方位提升系统的资源利用率,如细粒度调度(将CPU和内存这两个核心资源划分的更细,从而更充分的分配系统资源)、动态调度(基于节点真实负载情况,而非静态划分的资源,将任务调度到已分配了资源但是未实际使用的节点上,从而更充分的提高系统算力),在离线混部(根据离线任务和在线任务的周期性,削峰填谷,从而充分利用系统闲置资源)。
  • 在应用改造成本、迁移风险和组织架构方面:通过渐进式的迁移,大数据应用团队无需改造既有架构,只需制作当前所用的Hadoop版本的镜像,即可完成在Kubernetes上创建容器资源补充算力,这种方式,可以最低程度的减少变更,从而尽可能的降低迁移风险,与此同时,大数据团队保证Yarn资源调度和使用,容器团队保证Yarn pod的稳定运行,分工明确,能最大限度的保证系统的稳定性。

6. 大数据系统云原生渐进式演进最佳实践

6.1 基于EKS的弹性扩缩容最佳实践

​ 图8 用户最佳实践--弹性扩容缩容

该用户基于Hadoop Yarn自建了大数据集群,包含多种组件,如Spark、Flink、Hive等,当前遇到的主要问题是,面对临时的突发流量,如何快速的扩容以提高算力,并且在计算完成后,如何实时的释放资源以解决成本。借助腾讯云EKS的serverless能力,我们实现的快速自动扩缩容方案,正好可以满足该用户的诉求。

在控制台上,用户使用我们提供的自动扩缩容的配置策略,自由配置自动扩容、缩容的触发阈值。比如配置当剩余CPU或者内存小于指定的值时,Yarn弹性伸缩组件会调用EKS Kubernetes API创建Yarn NodeManager Pod,容器启动后自动注册到Yarn ResourceManager,从而提供算力;当触发了用户配置的缩容策略时,如剩余CPU或者内存大于指定的值时,Yarn弹性伸缩组件同样会调用EKS Kubernetes API缩容Yarn NodeManager Pod,整个过程中无需用户创建虚拟机,计费方式以Pod的CPU和内存为基础,真正的达到资源随用随建,按需付费。

6.2 混合云弹性基于TKE的在离线混部最佳实践

​ 图9 用户最佳实践--离在线混部

某客户大数据应用和存储跑在Yarn管理的大数据集群,在生产环境中,面临诸多问题,主要体现在大数据的算力不足和在线业务波谷时资源的浪费。如离线计算在算力不足时,数据准时性无法得到保证,尤其是当遇到随机紧急大数据查询任务,没有可用的计算资源,只能停掉已有的计算任务,或者等已有任务完成,无论哪种方式,总体任务执行的效率都会大打折扣。

基于TKE的在、离线混部方案,将离线任务自动扩容至云上集群,与在线业务混合部署,充分利用云上波谷时段的闲置资源,提高离线业务的算力,并利用云上资源快速的弹性扩容能力,及时补充离线计算的算力。简单来说,该方案提供了三种使用方式:

  1. 根据在线业务的波谷时段,配置定时扩容任务,在定时任务指定的时间到达时,调用TKE Kubernetes API,提交扩容请求,Yarn NodeManager则会以Pod的形式被Kubernetes创建出来,并且根据镜像里事先准备好的配置,自动向Yarn ResourceManager注册,从而提供算力资源。 该方案帮助用户提高在线集群利用率的同时,提高了离线集群的算力;
  2. 大数据管控平台也可以直接向TKE Kubernetes API发送扩展指令,以应对临时的紧急大数据查询任务,避免算力不足带来的任务无法启动,从而提高系统SLA;
  3. 用户可以在控制台上配置自动扩缩容策略,结合Ceres ServerClient资源预测,将Yarn NodeManager创建在合适的节点上。

7. 总结

本文提出了大数据云原生渐进式演进的理念和最佳实践,在极大减少改造成本、降低迁移风险的基础上,解决了大数据应用当前面临的主要问题。在未来,我们将基于最小化迁移风险、最低改造成本等原则,设计并落地更多方案,使大数据应用更原生的跑在云原生架构上,为企业带来更多的便利和实际收益。

【腾讯云原生】云说新品、云研新术、云游新活、云赏资讯,扫码关注同名公众号,及时获取更多干货!!
查看原文

赞 4 收藏 2 评论 0

CiciXY 赞了文章 · 9月21日

全面拥抱云原生应用研发的拐点已经到来

简介:随着云原生 Serverless 的概念在国内悄然升起,许多技术人似乎从中看到了希望,许多 IT 架构师已经把它作为目标技术架构之一。

Serverless 的跨代优势对有技术敏感的架构师来说是技术发展的红利,一般都在持续关注它的发展。

但是在这两年间,随着整个研发生态接触到 Serverless 的内容也越来越多,尝试也越来越多。在许多的实践中,越来越多的公司、企业开始陷入迷思。

在9月18日的云栖大会上,阿里云向全球的开发者们传递一个信息,具备规模化落地的真正的云原生Serverless 应用研发时代已经到来,全面拥抱云原生应用研发的拐点已经到来!无论是大中小微公司,无论什么业务场景,无论什么开发语言,无论是既有的存量应用还是新应用,无论多大用户流量,无论全球服务有多少节点,都可以借助阿里云云开发平台提供的 Serverless 架构服务轻松落地。


研发的未来在哪里

互联网+ 发展到今天,大家对互联网业务的发展模型越来越熟悉,敏捷开发,流量运营,模式复制。在整个创新闭环当中,技术起着至关重要的作用:

  • 帮助商业创新从 Idea 变成真实的线上服务
  • 帮助保障线上服务流量极速增长仍能提供服务
  • 帮助成功的商业实现模式的复制

所有的技术人都在为此而努力,就像奥林匹克精神那样,以 “更高更快更强” 为目标,不断优化工程实践方法。然而,这条路一路走过来的艰辛也只有技术人才懂:

  • 组建研发体系何其困难,麻雀虽小,五脏要全,如何快速完成研发团队的建设,研发基础设施的建设,是挡住商业化创新的第一道坎;
  • 用户流量每增长一百万,对技术架构都是巨大的挑战,系统什么时候会崩溃是技术人每天都要思考的问题;
  • 业务在国内取得成功后,想要在全球范围同步推出,每增加一个服务节点,系统架构都得从头再搭建一次,不同的国家地区还不一定能够保障,严重制约商业化脚步;
    • *

云原生应用研发的最后一公里魔咒

随着云原生 Serverless 的概念在国内悄然升起,许多技术人似乎从中看到了希望,许多 IT 架构师已经把它作为目标技术架构之一。

Serverless 的跨代优势对有技术敏感的架构师来说是技术发展的红利,一般都在持续关注它的发展。

但是在这两年间,随着整个研发生态接触到 Serverless 的内容也越来越多,尝试也越来越多。在许多的实践中,越来越多的公司、企业开始陷入一种迷思:

  • Serverless是不是就是FaaS?
  • 是不是只能用在一些 “计算任务” 场景?
  • 是不是只能在小程序等一些很小众的研发场景才能用呢?
  • 公司原来那么多不同语言开发的存量应用是不是完全用不上?
  • 是不是只有像阿里巴巴这种体量的公司才能玩的转?

一切好像又回到了原点,在上述的问题没有解决之前,企业集成或应用 Serverless 架构的设想停在了业务落地的 “最后一公里”。说好的云原生是云计算的未来呢?说好的云原生可以改变开发者的世界呢?要知道,没有规模,就不是云计算!没有规模,就无法产生无法计算的价值!如果一个好的概念始终无法走进普罗大众,那它可能只能被大众束之高阁,敬而远之。


回顾初心,技术是为了更好的商业创新

如果有一种方法,能够让开发者专注在商业应用逻辑的开发本身;能够让商业化应用不用担心流量的增长而崩溃;能够让全球的服务保持一致;能够让每一个商业应用随着流量的变化而动态调整资源的用量。那它一定是最接近理想状态的:让每一个商业创新都变的简单,让每一个灵感都变成可能!

今天,我们通过云栖大会,非常兴奋的向全球的开发者们传递一个信息,具备规模化落地的真正的云原生Serverless 应用研发时代已经到来,全面拥抱云原生应用研发的拐点已经到来!无论是大中小微公司,无论什么业务场景,无论什么开发语言,无论是既有的存量应用还是新应用,无论多大用户流量,无论全球服务有多少节点,都可以借助阿里云云开发平台提供的 Serverless 架构服务轻松落地。

全面拥抱云原生应用研发的拐点已经到来

在阿里云云开发平台,您可以在无需重构的情况,将已有的NodeJS应用、Java应用、Python应用、PHP应用等,轻松平滑地迁移部署到云原生Serverless架构,从此告别资源浪费,告别不靠谱的人肉流量估算人肉扩容的日子!您也可以将资源最大化地利用在自己的业务创新上,从此不再需要为团队协同环境的搭建、团队研发测试环境的搭建、应用高并发架构的搭建费时费力费钱!

阿里云云开发平台所提供的全云端Serverless研发架构服务,帮助企业和合作伙伴进行更好的商业创新。


只有更公平的创新环境才能让创新者全力比拼创意

阿里云云开发平台(https://workbench.aliyun.com )给开发者和研发团队提供了完全基于「云+浏览器」就能完成日常应用开发工作的环境,它的设计理念是使每天的应用研发生命周期也成为企业团队大协同中的一环。云开发平台集成了阿里巴巴诸多自研自用的开发能力和开发工具,籍由强大的阿里研发生态,为开发者提供更大的协同研发可能。

全面拥抱云原生应用研发的拐点已经到来

通过以下阿里巴巴自研自用服务,阿里云云开发平台让所有的研发团队不论大小,不论初创小微团队还是行业龙头企业,都能够享受到阿里巴巴这种体量规模的在线应用研发协同能力,让团队不受时间、空间、和规模的限制,让所有的创新创业都能基于一个更公平和开放的技术环境轻松启动

  • 在线团队:与阿里云云效企业组织互通,创建后即可使用阿里云云效提供的所有在线协同能力;提供4种团队角色,完全映射本地研发团队权限设计,帮助您轻松实现团队上云;
  • 在线CloudIDE环境:基于阿里巴巴前端委员会共建的 CloudIDE,与阿里巴巴内部使用的是同一套,在此基础上,意味着您同时也可以享受到阿里巴巴内部的插件生态,比如图片智能生成代码插件服务 ImgCook;
  • 在线代码托管服务:阿里云自研代码托管服务 Codeup,企业级代码管理平台,提供代码托管、代码评审、代码扫描、质量检测等功能,全方位保护企业代码资产,帮助企业实现安全、稳定、高效的研发管理,支撑百万级代码库和数万工程师协作,支持标准 git 操作,帮助您更方便的实现本地与云端代码同步管理;
  • 在线部署流水线服务:阿里云自研部署流水线服务 Flow,从代码到交付上线仅需5分钟,企业级、自动化的研发交付流水线, 提供灵活易用的持续集成、持续验证、 持续发布功能,帮助企业高质量、高效率的交付业务;
  • 「项目」「任务」协作:「项目」是协作的基本单元,相当于钉钉或者微信的一个群。你的「项目」可以是一次大型会议,一个客户项目,或者一个活动;你也可以为所在项目创建一个项目,用于追踪日常工作;进入项目后,「任务」看板把左右事项公开透明的呈现出来,让大家看见「谁」、在「何时」、要「做什么」,随时都可以掌握工作进度。任务是驱动云效项目的最小操作单位。一个个任务,让进展公开透明,让沟通卓有成效;
  • 知识库:知识库是一个为企业提供知识管理的服务,通过独立的知识库空间,结构化地组织在线协作文档,实现企业知识的积累和沉淀,促进知识的高度复用和流通
    • *

只有更强大的Serverless 架构服务才能让商业无忧成长

全面拥抱云原生应用研发的拐点已经到来

为了帮助用户提供一个无缝使用阿里云服务的环境,阿里云云开发平台会跟阿里云的诸多云产品进行集成,随时为用户的使用做好准备。您可以在云开发平台创建基于各种场景解决方案的应用,并为每个应用选用不同的云服务。

云开发平台将云原生 Serverless 领域实践最多的服务,如函数计算、应用引擎、容器服务,结合应用研发部署生命周期所需的能力,设计提供了三套标准 Serverless 架构服务,满足不同场景的应用研发部署需求,应用部署上线,流量高峰自动扩容,流量降低自动释放资源,再也不怕宕机

  • 函数计算型Serverless架构服务,这是一种羽量级Serverless应用架构服务,计算服务按请求量付费,对初创团队非常友好,这种 IT 架构适合短期快速实现的业务场景,比如促销活动,以及新业务试错场景;
  • Serverless应用引擎型架构服务,这是一种轻量级Serverless应用架构服务,计算服务按资源用量付费,对存量中小规模应用更加适合,这种架构模式,可以基于 MSE 微服务引擎,支持服务注册,服务发现机制,结合阿里云上各种中间件服务产品,能轻松构建一个复杂的系统架构。这种架构模式适合业务成熟定型,流量稳定的业务场景,也可以把业已成熟 IT 集成架构沉淀成云开发平台的公司级解决方案,让新业务在这个基础架构上敏捷迭代;
  • Serverless容器型架构服务,这是一种专业级Serverless应用架构服务,计算服务按资源用量付费,规模化复杂度高的巨型应用首选;
    • *

只有更少的约束才能让研发团队轻松实现业务升级

研发团队考虑的更多的问题是如何从现有 IT 架构演进到 Serverless 计算架构之中。云开发平台构建了这一演进路径,充分尊重用户当前研发体系,支持在现有体系中集成 Serverless 构建部署功能。演进包含两个层面,一个是存量应用的迁移,一个是新建 Serverless 应用和当前存量应用的互联互通能力。

对于存量应用的迁移,云开发平台已经上架了基于 FC,SAE,ASK 的各种架构形式的迁移解决方案,且还在不断丰富当中。比如,Java 语言的 Springboot 迁移方案,只需要把存量系统的 src 目录和 pom.xml 拖到 CloudIDE 工程目录,然后在 pom.xml 增加两处约定配置,即可完成 Springboot 应用到 Serverless 应用的迁移,让存量应用通过集成云开发 CICD 的特性,快速升级获得 Serverless 应用的所有优势。

对于采用 Serverless 架构的新建应用,云开发平台支持研发团队将公司原来已经在使用的阿里云产品编排进新建的应用架构当中,让新建的 Serverless 研发能够延续之前的研发模式。云开发平台提供的 Cloud-Native 集成研发环境支持本地研发和在线研发模式,支持云上测试环境,预发环境,正式环境三套环境的部署。

通过阿里云云开发平台提供的各种主流应用迁移方案,不论是等待开发的新应用还是已经服务于用户的在线业务,都可以通过阿里云云开发平台提供的Serverless架构服务以及Serverless框架实现平滑的架构升级。无需改变,一切已变!

全面拥抱云原生应用研发的拐点已经到来

  • 前端应用开发/迁移方案
  • VUE
  • React
  • 原生及更多框架支持
  • NodeJS 应用开发/迁移方案
  • Express应用
  • KOA应用
  • Egg应用
  • Next应用
  • Nuxt应用
  • Midway应用
  • NodeJS原生及更多类型的应用
  • Java 应用开发/迁移方案
  • 轻量级 SpringBoot 应用
  • 轻量级 SpringMVC 应用
  • 专业级 SpringBoot 应用
  • 专业级 SpringMVC 应用
  • Python 应用开发/迁移方案
  • Flask 应用
  • Django 应用
  • PHP 应用开发/迁移方案
  • PHP前后端一体化应用
  • 更多开发生态持续演进中
    • *

只有更低的侵入才能让本地研发链路全盘复用

对大多数企业的存量项目而言,将其直接迁移到云开发平台会遇到一些问题:线上开发不适应、工程仓库数量多迁移麻烦、代码托管平台的限制等等。因此对于企业级存量项目在保证不影响当前开发流程及开发者习惯的前提下集成阿里云开发平台就十分必要。在本地集成阿里云开发平台并不影响开发及测试,真正的变化在 CI/CD 阶段。

阿里云云开发平台根据大多数企业 CI/CD 的实践总结了一套适用于绝大多数场景的方法论,并提供了具体的解决方案 —— 阿里云云开发平台本地部署套件。它依托于企业的代码托管系统(常见的如Gitlab)及提供的 Hook 机制,并结合每个团队的分支提交规范(gitflow)实现线下的 CI/CD。阿里云开发平台本地部署套件支持各种形式的集成,包括常用的 Jenkins、Gitlab CI 以及 Hook,同时提供测试环境、预发环境和正式环境的部署。

全面拥抱云原生应用研发的拐点已经到来

使用阿里云开发平台本地 CI/CD 部署套件的成本极低:

  • 对于运维人员,仅需要在当前 CI/CD 逻辑中运行套件
  • 对于开发者,仅需要配置阿里云开发平台的相关认证信息

与阿里云云开发平台与本地 CI/CD 集成,您创建的应用,就是云原生Serverless应用!


只有更开放的生态才能让商业创新再次加速

没有规模,就不是云计算!没有规模,就无法产生无法计算的价值!当我们能够提供让云计算开箱即用的服务,这意味着云计算开始真正变得像这个社会的“水电煤”,人们的工作、生活,哪里需要,只需要打开开关即可获得服务,人们将更聚焦创新!

未来,阿里云云开发平台将与与行业生态一起,共建行业应用的云原生架构解决方案市场,让更多的商业创新能够实现二级加速!


总结

当我们再次回头看,如果我们真正做到了:您有一个Idea,就能快速让它从概念变成现实;您有一个服务,无论它的流量如何暴涨,都能轻松应对,无论它的流量如何变化,都能按量付费;您有一个研发团队,无论成员身处何时何地,都能高效协同;那么我们就真正做到了技术是为了更好的商业创新!

image.png

查看原文

赞 11 收藏 2 评论 0

CiciXY 关注了用户 · 9月18日

腾讯云原生 @tcloudnative

云原生技术交流阵地,汇聚云原生最新技术资讯、文章、活动,以及云原生产品及用户最佳实践内容。

关注 594

CiciXY 赞了文章 · 9月12日

鸿蒙智能硬件生态的“场景化超级终端”,到底是什么?

harmonyOS

物联网(IoT)的概念我们其实已经非常熟悉了,近些年物联网设备的飞速增长说明整个行业正在呈现一个爆发性发展的趋势。但 IoT 产业的快速发展即带来了巨大的机会,也迎来了巨大的商业和技术挑战。

为了解决这个挑战,华为提出要与生态伙伴一起共建“场景化的超级终端”。单从名字我们可能看不出来什么信息,但在本次的 HDC 大会的一场分论坛中,华为消费者 BG 软件部副总裁杨海松为我们给出了他的答案。

一、万物互联时代: 有机会、有空间、有挑战

在 5G 技术真的有实质性进展之前,一个不得不直面的现实是 —— 几乎所有的传统物联网或者智能硬件产业,发展都已不断接近天花板。

无论是硬件还是软件,无论是市场还是技术,人口红利的消耗勉强靠着全球市场扩张和新型应用功能的不断迭代来维持。但客观上已经不可避免的放缓了发展的脚步。

随着 5G 技术的逐渐成熟与落地,IoT 产业才迎来了又一次的快速发展。

“有机会、有空间,同时有挑战。”

这是杨海松对这件事情的理解,在分享中他也和我们分享了一组数据:根据 Statista 的资料显示,从 2015 年到 2025 年,人均智能设备的数量预期将从 2.09 台飙升到 9.27 台,也就是说除了手机、电脑、Pad 这新三大件之外,其他的智能设备也将逐步进入我们的生活。

这对 IoT 产业来说当然是个乐观的发展前景,未来十年也将是硬件创新非常好的机遇与发展空间。但杨海松也提出 —— 这个数字背后,其实是不断增加的硬件种类与系统下,有限的开发投入、复杂割裂的多设备使用体验,以及缺乏成熟商业模式所带来的巨大挑战。之前这个行业之所以没发展起来,还有一个很重要原因就是生态、体验、以及商业的割裂。

相对于单一的手机场景,在万物互联的时代,无论终端、业务、用户、还是其他的各种产业要素,都将呈现高度的碎片化与个性化。在各种不同的垂直业务场景下,用户对产品和服务的需求都将存在巨大差异,将这个差异放大到产业链来看则更为复杂。

以手机为例。传统的功能机搭配的软件功能和硬件能力都是固定的,发展到智能机后,软件功能得以进行丰富的扩展。那么在未来,我们手中的“手机”有没有可能变成一种“智能终端”,让软硬件都能具备扩展能力,从而满足不同用户的个性化需求?

“消费者的需求是开发产品的源动力。”很多人都认为是 5G 的发展催生了物联网的发展,但其实不然。杨海松认为改变行业的永远都不是技术,而是需求。为了解决 IoT 领域面临的挑战、满足更多用户的需求,华为提出要围绕 7 大场景,与生态伙伴一起共建“场景化的超级终端”。

二、超级终端的定义“公式”

杨海松在会上对这个超级终端提出了一个公式定义:场景化超级终端 = 核心硬件 + HarmonyOS + 核心应用

从这个公式中我们不难看出,华为的超级终端其实就是一条相对完整的生态链,从硬件到系统到应用,只有覆盖了这些完整的能力才能称之为“超级终端”。

终端对应的七大场景,分别是:智能家居、智慧出行、社交购物、智慧教育、影音娱乐、移动办公和运动健康。

现阶段,这些场景分别对应着不同的硬件设施,比如在 9 月 10 日 HDC 大会中提到的由智能手表承载的智慧出行能力,由不同的大屏间联动赋能的智慧教育等。这些硬件设备承载着不同使用场景的核心应用,在不同的方向和领域优化用户的使用体验。

但目前各种应用和硬件之间有一个很大的问题,就是生态的割裂。

早在 1995 年,比尔·盖茨在《未来之路》一书中,便提出了物联网的概念。当时他做出的一个设想基本命中了 25 年后的物联网发展:未来的住宅应该具备智能家居系统。

但他当时只想到了产品的形态,可能并没有想到物联网时代的超级终端之所以称之为超级终端,还需要有一个完整的生态来支持。不断推进自身能力迭代的 HarmonyOS,可能正是这中间承上启下最为关键的一环。

杨海松在会议中分享到,目前智能设备领域有三个最主要的痛点,“连不上、用不了、留不住”。展开来讲就是设备入网率低、平均 App 安装率低、智能特性用户使用率低,这些问题很大程度上都是生态割裂导致的。

HarmonyOS 有一项能力叫无感配网,通过降低用户联网的繁复操作,解决智能硬件入网率低的问题;FA+ 手机系统的入口,则可以解决设备 App 安装率低导致的设备或者应用沉寂。我们刚才提到的等等问题,看起来都在 HarmonyOS 所预定的能力范围之内。

本次 HDC 2020 上余承东正式宣布 HarmonyOS 将于今年 12 月推出面向手机的 beta 版本,2021 年将发布第一款搭载 HarmonyOS 手机。根据杨海松所说,第一款鸿蒙手机在各位用户手中的硬件形态将会是不一样的,而这个不一样,可能就体现在和其他智能硬件通过 HarmonyOS的生态融合当中了。

三、鸿蒙智能硬件生态发展规划:一横一纵&双赋能

IoT 领域中各种发展因素的迭加,注定了万物互联不但将激发出一个前所未有的庞大市场,也注定不是一家或几家企业便能解决的问题。未来的万物互联,将更加立体全面,既没有人能全盘通吃,也没有人能置身于事外。

华为深谙这个道理,早在去年就提出了 1+8+N 的战略。这当中的 1 指的便是我们手里的智能手机。

手机是未来智慧生活的入口,从目前来看,多数智能家居的生态链,一般都会以手机为核心。为什么会这样?因为手机是最为普及的智能硬件,基本已经达到了人手一部。

在万物互联的世界中,每一台手机其实都可以看做是一个活生生的人,承载的是发于人的需求。我们发展物联网的原因,其实也是希望以人为核心,让人与万物互联,从而为人赋予更强大的能力。

但杨海松在会议中提出了一个思考题:“手机可以替代相机、替代mp3、录音机,但是能灭掉跑步机、可穿戴设备么?”

答案他也给出来了,不能。

实现真正的万物互联,需要从手机延伸出去,扩展到智能家具、扩展到全场景当中。因此,鸿蒙智能硬件生态发展规划「一横一纵」中「一横」,便是横向的从智能家居扩展到全场景。杨海松表示鸿蒙生态将覆盖 7 大场景核心智能设备,建立全场景鸿蒙精品设备圈,并提出了 1 年内让华为鸿蒙设备规模达到 2 亿的目标。

而「一纵」则是纵向的从品牌厂家扩展到全产业链,鸿蒙硬件智能生态将联合芯片、模组、IDH、品牌厂家、服务商,快速打造鸿蒙生态产业链,1 年内让鸿蒙生态设备规模超过 1 亿。

这加起来就是 3 亿台设备,听起来有些难以实现,但结合 5G 和物联网的发展速度与规模来看,也不是没有可能。但如果想要实现这个目标,一定离不开智能硬件伙伴的帮助。

为了发展鸿蒙生态,华为在芯片、模组、开发板、解决方案等领域已经找到了很多合作企业,并为致力于加入鸿蒙生态、发展鸿蒙生态的朋友提供了技术和商业的“双赋能”,解决商业变现的“最后一公里”。

结语

物联网的发展其实仍处于战国的蛮荒发展时代,眼前的局势其实并不是十分的明朗。从简单的单一场景入网,到形成产业规模效应、形成一个完整、完善的生态,仍需要一个长远的产业协同过程。华为已经开始眺望远方的可能,付出实际行动,并见到了一些成效。

但前路唯艰,道阻且长。

“有机会、有空间、有挑战”,随着技术的发展,20 年前比尔盖茨的技术幻想已经成为了现实。我们今天对于物联网的期待、对于鸿蒙生态的期待,要等多久呢?

这个问题可能华为自身都给不出一个确切的答案。

但正如今年 HDC 大会的后缀「together」所传递的信息,携手、并肩前行,才是面对未来挑战的正确方式。

这里的「together」,既包括鸿蒙生态链条中上下游的合作伙伴,应该也包含期待未来的每一个人吧。

clipboard.png

查看原文

赞 10 收藏 0 评论 0

CiciXY 赞了文章 · 9月11日

开放与拥抱丨HMS 要打破垄断,让开发者与平台平等对话 !

HDC2020

华为在本次 HDC 大会上提到 HMS 时,使用频率很高的两个词是“开放”、“拥抱”,这两个词显示出了华为希望通过与全球合作伙伴和开发者携手,通过 HMS 生态提供能力和服务的决心。

根据华为公开的数据,截至目前,HMS 的全球注册开发者数量已经超过了 180 万,有 9.6 万以上的应用集成 HMS Core。提到这些数据时,华为消费者业务全球生态发展部总裁汪严旻说:“全球第三大移动应用生态正在破土而出。”

让开发者与平台平等对话

想要 HMS 短时间内进入大众,与苹果和安卓两大巨头三分市场是很难做到的,对于这一点,汪严旻也很坦诚的说到:

“过去的十几年里面,整个移动应用生态已经被垄断了很多年了,这一点我们在物理世界很敏感,大家没有选择,只能选择一个供应商,可能也会觉得很不爽,其实数字世界里面应用和内容也是一种垄断,这种垄断大家都希望被打破,所以我们在今天生态发展里面,我们强调我们的目标就是能够给广大的应用开发者、内容开发者、合作伙伴以及消费者提供更加公平的、多元化的、可信赖的生态选择。”

为了打破现有的格局,华为贯彻的准则是把更多利益分享给开发者,这也是华为打破苹果和安卓两大巨头垄断的一种策略。汪严旻提到了苹果、谷歌对平台内应用抽成高达 30% 的例子,他认为在这样的情况下,中国的开发者永远不可能与他们有平等的对话机会。HMS 要做的就是建立一个新的生态,可以更加公平、开放,也能让消费者更加信赖。

HDC2020g

HMS 的目标是能三分天下有其一

在消费者已经习惯了使用一种移动应用生态的时候,后入局者想要在短时间与之形成分立是很难的。华为也意识到了这个难题,汪严旻从三个方面总结了 HMS 目前面临的主要挑战。

一是如何让消费者在短时间内接受一个新的东西,这需要让头部应用尽可能的商家,和 HMS 平台进行集成开发。

二是低频刚需应用这个硬骨头,很多应用并不是头部应用,使用频率也很低,比如购买车票、机票的应用,一年可能只用几次,但却是刚需,这在 HMS 的全球生态建设中也是必不可少的。

第三,也是最重要的一点,就是在一些平台级的应用上,华为还在进行探索,积极追赶,比如搜索、地图、广告这些根应用的服务能力的提升。

从长期来看,HMS 的目标是能三分天下有其一,做到跟其他两个应用生态相当的水平。这需要整个生态能做到自我循环,从获客、增长、运营到面向,产品的设计能有一个系统自我运作完成。

汪严旻说,华为下一步的计划是首先把基础服务工作做好,把 Open line、digital line,还有包括线下全球开发者服务中心这些基础能力做好。同时构建围绕开发者的界面,包括论坛、线上线下活动等等。

与中国开发者共同进军海外

HDC2020

汪严旻提到了一个数字“38%”,这是中国开发者目前在 Google Play 和 iOS 上贡献的占比,其实从这个角度来讲,中国开发者早就三分天下有其一了,中国开发者是未来移动生态最重要的开发的力量。所以,汪严旻提出,即使做海外生态,也要更多的和中国开发者一起,把应用内容发布到海外。

现阶段 HMS 要做的,是把“基本可用”变成“好用”,这个变化涉及到两个关键点,分别是低频刚需应用要全和内容必须足够丰富。对于目前缺失的 20% 的头部应用,汪严旻说,会尽快找到替代应用,也鼓励中国应用到海外当地发展。


随着中国移动应用出海走入深水区,语言转化、法律合规、本土推广等本土化壁垒,逐渐成为挑战。而华为自身的全球化实践和经验能够帮助开发者和合作伙伴克服种种挑战。

汪严旻表示“我们坚信,每一位开发者,都是重要的合作伙伴。点点星光汇聚,便是璀璨银河。只有与开发者共同成长,才能最终打造可信赖的开放生态,为用户提供多元化创新体验。”

期待在未来,华为与全球合作伙伴和开发者携手,共建一个全场景的智慧生态。

segmentfault 思否

查看原文

赞 10 收藏 0 评论 0

CiciXY 赞了文章 · 9月10日

连接无限可能,华为 HarmonyOS 2.0 正式发布

今天(2020年9月10日),华为消费者业务 CEO 余承东又一次站在了松山湖华为开发者大会的主舞台上。今年,他带来了万众瞩目的华为鸿蒙 HarmonyOS 2.0。此次 HarmonyOS 的升级,不仅仅包括了分布式能力的全面提升,还为开发者提供了完整的分布式设备与应用开发生态,使能全场景智慧生态,引领移动产业的下一个 10 年。

开发者

三大核心能力升级,HarmonyOS 2.0为开发者掌灯

去年推出的 HarmonyOS 1.0 版本,验证了终端分布式技术的可行性,这一技术也被应用到 EMUI 中,创新出多屏协同、畅连视频通话、华为 HiCar 等跨终端体验。HarmonyOS 2.0 则在分布式软总线、分布式数据管理和分布式安全三方面进行了全面提升。

分布式软总线让多设备融合为“一个设备“,带来设备内和设备间高吞吐、低时延、高可靠的流畅连接体验。分布式数据管理让跨设备数据访问如同访问本地,大大提升跨设备数据远程读写和检索等性能。

分布式安全确保正确的人、用正确的设备、正确的使用数据。当用户进行解锁、付款、登陆等行为时系统会主动拉出认证请求,并通过分布式技术可信互联能力,协同身份认证确保正确的人;HarmonyOS 能够把手机的内核级安全能力扩展到其他终端,提升全场景设备安全性,通过设备能力互助,共同抵御攻击,保障智能家居网络安全;HarmonyOS 通过定义数据和设备的安全级别,对数据和设备都进行了分类分级保护,确保数据流通安全可信。

赋能设备厂商,HarmonyOS 用软件定义新设备

当前,智能家居设备大多数面临联网率低、APP 安装率低、服务触达率低三座大山的困境。但在发布会中我们看到,华为已经与美的、九阳、老板等设备厂商达成了合作,搭载 HarmonyOS 2.0 的智能家居设备为我们带来了不一样的体验。当走进厨房,用手机碰一碰蒸烤一体机,极速设备联网,再也不担心设备不在线;手机碰一下料理机,分分钟实现无屏变有屏,还能结合智能手表,根据运动健康信息智能推荐最佳菜谱;碰一下抽油烟机,服务直达手机,清洗维修一站式服务更无忧……这样的体验,还会担心“智能设备不智能”吗?

面对广大的设备厂商,HarmonyOS 通过 SDK、源代码、开发板/模组和HUAWEI DevEco 等装备共同构成了完备的开发平台与工具链,让HarmonyOS 设备开发易如反掌。设备厂商可以选择不同的方式加入全场景智慧生态:通过使用分布式 SDK,已经有 1200 万+设备,获得畅连、HiCar等7大能力快速接入;此次发布会后,30+ 品类的 128MB 以下 IoT 设备整机也可以使用开源代码接入;对于 128MB 以上、4GB 以下的智能设备整机,HarmonyOS 已经通过申请定向代码开始招募伙伴加入。

为了让 HarmonyOS 智能设备开发者快速上手,HarmonyOS 为其提供了丰富的模组、开发板和解决方案。同时,HUAWEI DevEco 将为 HarmonyOS 设备带来一站式开发环境,支持家电、安防、运动健康等品类的组件定制、驱动开发和分布式能力集成。在用户开发过程中,不论设备是有屏还是无屏,HUAWEI DevEco 都可以为其提供一站式开发、编译、调试和烧录,组件可以按需定制,减少资源占用,开发环境内置安全检查能力,用户在开发过程中也可以进行可视化调试。

为了共建万物互联的全场景智慧生态,HarmonyOS 将源代码捐赠给开放原子开源基金会进行孵化,这一项目就是 OpenHarmony。目前,面向 RAM 在 128KB~128MB 的 IoT 智能硬件源代码已经开放;在明年 4 月前,RAM 在 128MB 到 4GB 间的终端设备,包括平板、低内存手机等在内的设备均可以获得相关的开源代码;到明年 10 月,HarmonyOS 源代码将会面向更多全场景终端设备开放。

应用创新升级,HarmonyOS 打造全新开发体验

应用创新是一款操作系统发展的关键,应用开发体验更是如此。在发布会中我们看到,搭载 HarmonyOS 2.0 之后,许多传统应用在开发者的手中被赋予新生。在办公室开会时,只需打开智慧屏上的 WPS 应用一扫,手机上 PPT 的材料便可快速分享到大屏,还能实时批注和文件分享;想要体验大屏多人体感游戏却苦于没设备?通过 Cocos,只需拿起华为手机便可接入智慧屏游戏,手机秒变手柄,家人同享大屏游戏;上网课屏幕太小?通过智慧屏和平板协同,VIPKid 能够让你大屏上课小屏互动,线上课堂一如现场教学。

image

完整的应用开发生态中,应用框架、编译器、IDE、API/SDK 都是必不可少的。为了赋能开发者,HarmonyOS 提供了一系列构建全场景应用的完整平台工具链与生态体系,助力开发者,轻松构筑全场景创新体验。

分布式应用框架能够将复杂的设备间协同封装成简单接口,可分可合可流转,轻松实现跨设备应用协同。开发者只需要关注业务逻辑,不必关心跨端调度与通信细节,减少代码和复杂度,大幅提升全场景体验开发效率。分布式应用框架 SDK/API 开发者 Beta 版已经同步上线,分步骤提供 13000 多个 API,支持开发大屏、手表、车机等应用。

编译器方面,HarmonyOS 采用了支持高性能多语言编译的方舟编译器。其能够消除跨语言交互开销,统一运行时;统一多语言前端,让开发者能够自由选择 Java、JavaScript 及其他语言;通过组件解耦实现多设备弹性部署;操作系统、运行时和开发框架协同设计,能够完成联合优化,提高代码执行效率。

IDE 方面,HarmonyOS 2.0 打造了全场景跨设备集成开发工具 Huawei DevEco Studio。其具有三大特色能力,在编程时开发者可以实时预览UI,实现编程所⻅即所得;提供 API 智能补全,实现高效编码;面对多设备测试难题,DevEco Studio 提供了高性能模拟仿真和实时调测。

华为面向广大开发者提供了 HarmonyOS 应用开发者官网、设备开发者官网、设备合作伙伴门户、开发者论坛 @华为开发者联盟等四大平台,持续对外发布相关技术,也让开发者们互通有无,共同陪伴 HarmonyOS 一路前行。

《孙子·谋攻篇》有云:“上下同欲者胜,以虞待不虞者胜”。 华为发布 HarmonyOS 并非仓促的决定,而是一次上下同心、准备充足的征程。 当前,已经有大批设备合作伙伴、应用合作伙伴和开发者社区合作伙伴加入了 HarmonyOS 全场景智慧生态,成为先行者。HarmonyOS 抓住了 IoT 产业崛起的历史机遇,共享先进平台,共建开源平台,同合作伙伴及开发者共同发力,共赢全场景智慧时代。

segmentfault 公众号

查看原文

赞 28 收藏 2 评论 8

认证与成就

  • SegmentFault 讲师
  • 获得 13 次点赞
  • 获得 6 枚徽章 获得 0 枚金徽章, 获得 0 枚银徽章, 获得 6 枚铜徽章

擅长技能
编辑

(゚∀゚ )
暂时没有

开源项目 & 著作
编辑

(゚∀゚ )
暂时没有

注册于 2019-03-07
个人主页被 1.3k 人浏览