通信

通信

你以为在做的是微服务?不!你只是做了个比单体还糟糕的分布式单体!

科技创新大兴 发表了文章 • 0 个评论 • 71 次浏览 • 2021-04-01 11:19 • 来自相关话题

昨晚睡觉前,顺手撸了几个群聊的聊天记录。发现一个很有意思的名词“分布式单体”,顺藤摸瓜看了一下之前的聊天记录,由于内容骂骂咧咧,我就不贴出来了。大致内容就是某公司在做微服务改造,但改的不伦不类,形式上像微服务,而本质上依然是单体,甚至连单体都不如。这样的改造现... ...查看全部

昨晚睡觉前,顺手撸了几个群聊的聊天记录。发现一个很有意思的名词“分布式单体”,顺藤摸瓜看了一下之前的聊天记录,由于内容骂骂咧咧,我就不贴出来了。大致内容就是某公司在做微服务改造,但改的不伦不类,形式上像微服务,而本质上依然是单体,甚至连单体都不如。微信截图_20210401111022.png

这样的改造现象,其实在国内还是蛮多见的。今天我们就来聊聊这个有趣的话题:分布式单体。各位看官,看看你们公司是不是也犯了这样的错误?

分布式单体为什么不好

先思考一个问题:从单体改造到微服务的时候,你们是不是按这样的步骤来的?

  1. 确定业务领域,拆分存储,定义各微服务的边界

  2. 改造代码逻辑,将原来的内部service调用改成dubbo或feign这样的远程调用

通过这样的改造,我们得到了很多好处,比如:

  1. 代码库分开了,减少了麻烦的解决代码冲突的困扰

  2. CI/CD分开了,每个拆分后的服务都可以独立开发、部署、运行

  3. 数据库分开了,独立运行,不同业务模块不会互相影响

这样一顿操作,我们把一个臃肿的单体应用变成了多个精炼的分布式应用,似乎完美的实现了改造?但这样就实现了微服务的核心目标了吗?继续思考下面的问题:

  1. 代码库是分开了,但每个服务都在独立迭代吗?是不是每个需求都要协调一大堆同步接口?

  2. CI/CD是分开了,但每次发布都是自由的吗?是不是每次功能的发布都拖上了一大推的服务要一起发布?

  3. 数据库是分开了,但似乎有个服务挂了,依然导致很多功能就都不正常了?

看似我们得到了很多好处,但我们的开发效率真的得到了提升吗?虽然我们以前一个单体应用启动要3分钟,现在拆分后,一个项目启动30秒,但每次开发调试要同时开好几个项目同时启动?这样的开发体验真的爽到了吗?

看似完成了微服务改造,实则依然是个单体应用,只是从原本的集中式实现,变成是分布式实现。原来我们只是做了一次无用功,真正的收益微乎其微。

而实际上,这样的改造,除了收益不高之外,还带出了更多的坏处。如果你们公司是这样做的,有没有发现,这样做之后,好像系统故障的频率更高了?稳定性似乎比单体应用还差?(如果没有,那一定要感谢你们的运维团队真的很给力,同时建议把这篇转给运维团队,采访下这样的改造是不是他们变得更累了?!)

为什么这样的改造会导致系统更加不稳定呢?其实道理很简单,原本我们在单体应用中,未拆分的远程调用都是内部调用,这个内部调用所能引发的故障率是微乎其微的,而将这部分内容拆成了远程调用后,每一个调用都增加了网络IO的因素,每一次调用的故障率都增加了。那么系统的整体故障率是随着系统拥有多少同步远程调用的数量增加而增加的。当运维团队与开发水平没有支持好这部分增加的复杂度时,那么改造的系统,必然稳定性会比原来的单体应用更差。

所以,这样改造的结果,不但没有得到很多的收益,反而会带来很多稳定性上的损失。

改造走样的元凶

那么为什么会造成上面所说的问题呢?我觉得主要有两方面:

  1. 领域拆分的不合理,引出了过多的同步远程调用

这个是最根本的问题,也是在改造过程中最常见的。这部分说实话是整个改造过程中最难的,因为需要对业务有非常深入的认识,对系统设计的领域模型、用户行为有足够的理解。在做拆分的时候,尽可能的减少同步远程调用,取而代之的是走消息的异步交互,同时根据业务需要也可以做适当的数据冗余。这样就能保证,每个被拆分后的微服务之间可以获得更低耦合度。

因为更低的耦合度,我们才能在不做任何优化的情况下,获得更少的分布式所带来的稳定性损失。对于后面要将的第2点的工作量也就越少。同时,对于真正的独立开发、部署、运行也成为可能。

  1. 简单粗暴的实现,缺少分布式的保护机制

在很多团队里,因为业务需求多与人员配置少的矛盾之下,开发人员很容易出现对远程调用不做足够的保护机制,比如:接口提供方的限流策略(保护自己不被别人搞死),接口调用方的降级策略(保护业务更高的可用性),接口调用方的熔断策略(保护自己不被别人拖死)。只有认真对待每一个分布式环境下的依赖点,那么才能解决因为分布式改造所牵连出的诸多问题。

但要做好这一点的核心,还是对第一点的把握,只有在领域模型上做更合理的拆分规划,才能支持开发人员做好这个点,不然随意的拆分,一大堆接口调用压给本就压力很大的开发人员,那这部分的开发质量肯定很难保障了,自然而然的系统稳定性就开始随着接口复杂度的增加而不断下降了。最后,开发人员就会开始来我们群里吐槽了…甚至大家也开始怀疑微服务根本带不来效率的提升!

转载于公众号“程序猿DD”


【IT八卦】没有手机的古代人是如何通信?

好玩创意大兴 发表了文章 • 0 个评论 • 140 次浏览 • 2020-12-07 12:00 • 来自相关话题

没有手机,古代人如何通信,我们一起说说关于古代人通讯的那些事今天,小编正躲在空调房里玩着手机,此时异地恋的男友给小编打了一个视频电话。作为一个已经异地谈恋爱两年,有着半年已经没有见到人影在高原服役的的男友的小编当机立断的点开了视频。不过好景并不长,刚腻歪了一会... ...查看全部

没有手机,古代人如何通信,我们一起说说关于古代人通讯的那些事

今天,小编正躲在空调房里玩着手机,此时异地恋的男友给小编打了一个视频电话。作为一个已经异地谈恋爱两年,有着半年已经没有见到人影在高原服役的的男友的小编当机立断的点开了视频。不过好景并不长,刚腻歪了一会儿,视频那头传来了集合的哨子声,小编的男友也只能匆匆挂断了视频集合去了。小编我看了看手机,靠在沙发后面叹了一口气,这时脑海里浮现了这么一个问题:古代人没有手机,没有电子邮箱,没有各种APP,那么他们靠什么通信呢?今天就让我们一起说一说关于古代人通信的那些事儿。

在远古时期,人们的力量与大自然相比是十分弱小的,为了能够活命,为了能够更好的生存,这些远古人经常是一群群的聚集在一起生存,有着自己的地盘,靠采集果实和狩猎为生。每当发现了一些可以食用的果实,或是有毒致命的果实,人们都通过喊的方式来告诉自己部落的同伴一起来采集或是记住下次不要采集这种果实。每次狩猎时,人们都是通过喊叫的方式去恐吓动物,使一些小动物变的胆怯。

以便获取食物来源,或是为了吓走一些想要抢走劳动成果的其他动物。另外当凶猛野兽袭击的时候,人们可以通过喊叫来震慑这些野兽,为自己赢得宝贵的逃跑时间,也可以通过此方式来告诉自己的同伴有危险来临了。喊叫出的声音的大小和长短程度都代表着不同的意思,我们现如今复杂的语言体系也是从当时的喊叫进化过来的,毫无疑问的可以这么说,喊叫是最原始的一种通讯方法了吧。

这种通过喊叫来传递信息的方法至今我们仍在沿用,比如一个人在楼上,另一个人在楼下的时候,交流方式可还得靠喊叫啊,毕竟老祖宗留下来的东西不能丢不是吗?除了光靠喊叫的这种传递信息的办法之外,还有一种很方便的方法就是铛铛裆的敲了。在喊叫之后出现的方式应该是敲敲敲了,用鼓槌击打鼓面,用不同的声响和频率传达不同的意思,也就有了一鼓作气这个成语的由来了,由于怕对方也知道自己敲鼓的所表达的含义。

于是就设计出不同的击打方式。不过小编想了想,好像这种方式我们现在依然在使用。这让小编想起了自己的学生时代了,有时候自习课想要偷懒睡一会儿,又怕班主任的突然袭击,便会跟自己的同桌相约定班主任来了敲几下桌子给自己提个醒。除了铛铛裆的敲的方式之外,还有一种对暗号的通信方式,暗号除了文字,还有吹笛子、弹琴、吹箫各种各样奇怪的方式,这种对暗号的方式经常存在于秘密情报的传递之中。

也经常在武侠电影和武侠电视剧中看到这样的情况,你个普通老百姓可是用不到这种暗号方式,太累了。当然这种通信方式各国部队、间谍机构现在仍在使用。不过小编一些,学生之间好像也会使用这种对暗号的方式诶。还记得小编读大学的时候,觉得食堂的饭菜难以下咽,于是自己买了个锅自己煮饭,但是这可是违纪品,总是怕查寝的,后来寝室里的几位姐妹也纷纷购买了电锅,每天设立一个暗号口令。

一旦门反锁后有人敲门就要对暗号口令,靠着这种方式,小编的锅和自己的其他3位室友的锅安安稳稳的度过了它们的四年大学时光。我们看古装剧的时候是否会注意到这么一个细节,每当皇上在大殿上想要传达什么口信的时候,都会讲口信的内容告诉自己身边的贴身太监,让他把这个口信通过一个个传递到大殿之下。有时候传下去的口信就那么几个字,费事又费力,还浪费口舌。

说实话,小编以前上学的时候老师有时候就喜欢玩传话这个游戏,每次到了最后一个人那里,传的话肯定是变味了,甚至十分的搞笑,真的不知道古代会不会有这种类似的情况发生。除了这两个人肉手段之外,在周幽王时代也出现了烽火狼烟传递消息的方式了。一说起周幽王时代,所有人都会想起周幽王烽火四诸侯只为博得褒姒的微笑,当时为了传递有敌军来犯的消息便会在边境的高墙上设立岗哨。

一旦这些岗哨发现有敌军入侵之后,便会点着烽火台上的燃料,释放出滚滚黑烟,表示有外敌入侵,见状所有的岗哨就一个个的点燃了烽火台上的燃料,信息就这么被传递了。后来人们发现之前说到的这三个传递信息的方式太繁琐,费事又费力,有时候还会发生话被传错了的风险。于是人们开始利用各种各样的动物来传递信息。最早用动物传达信息和书信的人应该是苏武了吧。

他在牧羊的贝加尔湖畔用鸿雁像汉朝传回了所有人被匈奴扣押了的重要的信息。除了鸿雁传书之外,最普遍的还是飞鸽传书了,当然也有人用鹦鹉、狗、青鸟等动物来传递信息的。除了各种各样的动物,古代人还用放飞风筝和孔明灯来传递消息的,更为甚者,还有人将写好的信件放在荷花灯或是竹筒里,让它们顺流而下去传递消息。总是用这些原始的办法传递信息总也不是个事啊。

统一六国之后的秦始皇修建了全国统一的驰道,设立了驿站,专门用来传递官方重要文件和重要信息。此时纸还没有被发明出来,人们把需要传递的信息都写在了竹签上,再把竹签放进竹筒里,两端密封防止被人偷看。或是用木头雕刻两个一模一样的鲤鱼,鲤鱼中间是挖空的竹签的形状,需要传递信息的时候,就把竹签放进鲤鱼的凹槽里,再合上用绳子牢牢的系住。

在打结的地方再沾上黏土,这样再也不怕被偷看了,或许这也是鱼传尺素这个成语的由来吧。到了唐代出现了官邮,类似于我们现在的中国邮政,只不过大部分是为官方服务的,整个官邮是以唐朝首都为中心向周围辐射,每隔30里路就有一个驿站,供人休息换马,除了陆路也发展出了水路驿站,利用河水和船传递信息。到了宋朝出现了普通邮递、快递和加急快递。

元明清三个朝代都是沿用宋朝的模式,中国邮政的雏形就这么出现了。看了古代人通信方式,小编突然觉得自己生活在现代真的很幸运。有手机,有WiFi,有各种聊天APP,若是想要联系,信手沾来,比以前不知道要方便多少倍呢。


手把手教学实现消息通信

IM即时通讯王叫兽 发表了文章 • 2 个评论 • 149 次浏览 • 2020-09-09 10:09 • 来自相关话题

一、背景作为一名 Web 开发者,在日常工作中,经常都会遇到消息通信的场景。比如实现组件间通信、实现插件间通信、实现不同的系统间通信。那么针对这些场景,我们应该怎么实现消息通信呢?本文阿宝哥将带大家一起来学习如何优雅的实现消息通信。好的,接下来我们马上步入正题... ...查看全部

一、背景

作为一名 Web 开发者,在日常工作中,经常都会遇到消息通信的场景。比如实现组件间通信、实现插件间通信、实现不同的系统间通信。那么针对这些场景,我们应该怎么实现消息通信呢?本文阿宝哥将带大家一起来学习如何优雅的实现消息通信。

好的,接下来我们马上步入正题,这里阿宝哥以一个文章订阅的例子来拉开本文的序幕。小秦与小王是阿宝哥的两个好朋友,他们在阿宝哥的 “全栈修仙之路” 博客中发现了 TS 专题文章,刚好他们近期也打算系统地学习 TS,所以他们就开启了 TS 的学习之旅。

时间就这样过了半个月,小秦和小王都陆续找到了阿宝哥,说 “全栈修仙之路” 博客上的 TS 文章都差不多学完了,他们有空的时候都会到 “全栈修仙之路” 博客上查看是否有新发的 TS 文章。他们觉得这样挺麻烦的,看能不能在阿宝哥发完新的 TS 文章之后,主动通知他们。


好友提的建议,阿宝哥怎能拒绝呢?所以阿宝哥分别跟他们说:“我会给博客加个订阅的功能,功能发布后,你填写一下邮箱地址。以后发布新的 TS 文章,系统会及时给你发邮件”。此时新的流程如下图所示:

在阿宝哥的一顿 “操作” 之后,博客的订阅功能上线了,阿宝哥第一时间通知了小秦与小王,让他们填写各自的邮箱。之后,每当阿宝哥发布新的 TS 文章,他们就会收到新的邮件通知了。

阿宝哥是个技术宅,对新的技术也很感兴趣。在遇到 Deno 之后,阿宝哥燃起了学习 Deno 的热情,同时也开启了新的 Deno 专题。在写了几篇 Deno 专题文章之后,两个读者小池和小郭分别联系到我,说他们看到了阿宝哥的 Deno 文章,想跟阿宝哥一起学习 Deno。

在了解他们的情况之后,阿宝哥突然想到了之前小秦与小王提的建议。因此,又是一顿 “操作” 之后,阿宝哥为了博客增加了专题订阅功能。该功能上线之后,阿宝哥及时联系了小池和小郭,邀请他们订阅 Deno 专题。之后小池和小郭也成为了阿宝哥博客的订阅者。现在的流程变成这样:

这个例子看起来很简单,但它背后却与一些设计思想和设计模式相关联。因此,接下来阿宝哥将分析以上三个场景与软件开发中一些设计思想和设计模式的关联性。

二、场景与模式

2.1 消息轮询模式

在第一个场景中,小秦和小王为了能查看阿宝哥新发的 TS 文章,他们需要不断地访问 “全栈修仙之路” 博客:

这个场景跟软件开发过程中的轮询模式类似。早期,很多网站为了实现推送技术,所用的技术都是轮询。轮询是指由浏览器每隔一段时间向服务器发出 HTTP 请求,然后服务器返回最新的数据给客户端。常见的轮询方式分为轮询与长轮询,它们的区别如下图所示:

这种传统的模式带来很明显的缺点,即浏览器需要不断的向服务器发出请求,然而 HTTP 请求与响应可能会包含较长的头部,其中真正有效的数据可能只是很小的一部分,所以这样会消耗很多带宽资源。为了解决上述问题 HTML5 定义了 WebSocket 协议,能更好的节省服务器资源和带宽,并且能够更实时地进行通讯。

WebSocket 是一种网络传输协议,可在单个 TCP 连接上进行全双工通信,位于 OSI 模型的应用层。WebSocket 协议在 2011 年由 IETF 标准化为 RFC 6455,后由 RFC 7936 补充规范。

既然已经提到了 OSI(Open System Interconnection Model)模型,这里阿宝哥来分享一张很生动、很形象描述 OSI 模型的示意图:

(图片来源:https://www.networkingsphere.com/2019/07/what-is-osi-model.html)

WebSocket 使得客户端和服务器之间的数据交换变得更加简单,允许服务端主动向客户端推送数据。在 WebSocket API 中,浏览器和服务器只需要完成一次握手,两者之间就可以创建持久性的连接,并进行双向数据传输。

介绍完轮询和 WebSocket 的相关内容之后,接下来我们来看一下 XHR Polling 与 WebSocket 之间的区别:

对于 XHR Polling 与 WebSocket 来说,它们分别对应了消息通信的两种模式,即 Pull(拉)模式与 Push(推)模式:

场景一我们就介绍到这里,对轮询和 WebSocket 感兴趣的小伙伴可以阅读阿宝哥写的 “你不知道的 WebSocket” 这一篇文章。下面我们来继续分析第二个场景。

2.2 观察者模式

在第二个场景中,为了让小秦和小王能及时收到阿宝哥新发布的 TS 文章,阿宝哥给博客增加了订阅功能。这里假设阿宝哥博客一开始只发布 TS 专题的文章。

针对这个场景,我们可以考虑使用设计模式中观察者模式来实现上述功能。观察者模式,它定义了一种一对多的关系,让多个观察者对象同时监听某一个主题对象,这个主题对象的状态发生变化时就会通知所有的观察者对象,使得它们能够自动更新自己。

在观察者模式中有两个主要角色:Subject(主题)和 Observer(观察者)。

在第二个场景中,Subject(主题)就是阿宝哥的 TS 专题文章,而观察者就是小秦和小王。由于观察者模式支持简单的广播通信,当消息更新时,会自动通知所有的观察者。因此对于第二个场景,我们可以考虑使用观察者设计模式来实现上述的功能。接下来,我们来继续分析第三个场景。

2.3 发布订阅模式

在第三个场景中,为了让小池和小郭能及时收到阿宝哥新发布的 Deno 文章,阿宝哥给博客增加了专题订阅功能。即支持为阿宝哥博客的订阅者分别推送新发布的 TS 或 Deno 文章。

针对这个场景,我们可以考虑使用发布订阅模式来实现上述功能。在软件架构中,发布 — 订阅是一种消息范式,消息的发送者(称为发布者)不会将消息直接发送给特定的接收者(称为订阅者)。而是将发布的消息分为不同的类别,然后分别发送给不同的订阅者。同样的,订阅者可以表达对一个或多个类别的兴趣,只接收感兴趣的消息,无需了解哪些发布者存在。

在发布订阅模式中有三个主要角色:Publisher(发布者)、 Channels(通道)和 Subscriber(订阅者)。

在第三个场景中,Publisher(发布者)是阿宝哥,Channels(通道)中 Topic A 和 Topic B 分别对应于 TS 专题和 Deno 专题,而 Subscriber(订阅者)就是小秦、小王、小池和小郭。好的,了解完发布订阅模式,下面我们来介绍一下它的一些应用场景。

三、发布订阅模式的应用

3.1 前端框架中模块/页面间消息通信

在一些主流的前端框架中,内部也会提供用于模块间或页面间通信的组件。比如在 Vue 框架中,我们可以通过 new Vue() 来创建 EventBus 组件。而在 Ionic 3 中我们可以使用 ionic-angular 模块中的 Events 组件来实现模块间或页面间的消息通信。下面我们来分别介绍在 Vue 和 Ionic 中如何实现模块/页面间的消息通信。

3.1.1 Vue 使用 EventBus 进行消息通信

在 Vue 中我们可以通过创建 EventBus 来实现组件间或模块间的消息通信,使用方式很简单。在下图中包含两个 Vue 组件:Greet 和 Alert 组件。Alert 组件用于显示消息,而 Greet 组件中包含一个按钮,即下图中 ”显示问候消息“ 的按钮。当用户点击按钮时,Greet 组件会通过 EventBus 把消息传递给 Alert 组件,该组件接收到消息后,会调用 alert 方法把收到的消息显示出来。

以上示例对应的代码如下:

main.js

Vue.prototype.$bus = new Vue();

Alert.vue


<script>
export default {
  name: "alert",
  created() {
    // 监听alert:message事件
    this.$bus.$on("alert:message", msg => {
      this.showMessage(msg);
    });
  },
  methods: {
    showMessage(msg) {
      alert(msg);
    },
  },
  beforeDestroy: function() {
    // 组件销毁时,移除alert:message事件监听
    this.$bus.$off("alert:message");
  }
}
</script>

Greet.vue


<template>
  <div>
    <button @click="greet(message)">显示问候信息</button>
  </div>
</template>
 
<script>
export default {
  name: "Greet",
  data() {
    return {
      message: "大家好,我是阿宝哥",
    };
  },
  methods: {
    greet(msg) {
      this.$bus.$emit("alert:message", msg);
    }
  }
};
</script>

3.1.2 Ionic 使用 Events 组件进行消息通信

在 Ionic 3 项目中,要实现页面间消息通信很简单。我们只要通过构造注入的方式注入 ionic-angular 模块中提供的 Events 组件即可。具体的使用示例如下所示:

import { Events } from 'ionic-angular';
 
// first page (publish an event when a user is created)
constructor(public events: Events) {}
createUser(user) {
  console.log('User created!')
  this.events.publish('user:created', user, Date.now());
}
 
 
// second page (listen for the user created event after function is called)
constructor(public events: Events) {
  events.subscribe('user:created', (user, time) => {
    // user and time are the same arguments passed in `events.publish(user, time)`
    console.log('Welcome', user, 'at', time);
  });
}

介绍完发布订阅模式在 Vue 和 Ionic 框架中的应用之后,接下来阿宝哥将介绍该模式在微内核架构中是如何实现插件通信的。

3.2 微内核架构中插件通信

微内核架构(Microkernel Architecture),有时也被称为插件化架构(Plug-in Architecture),是一种面向功能进行拆分的可扩展性架构,通常用于实现基于产品的应用。微内核架构模式允许你将其他应用程序功能作为插件添加到核心应用程序,从而提供可扩展性以及功能分离和隔离。

微内核架构模式包括两种类型的架构组件:核心系统(Core System)和插件模块(Plug-in modules)。应用逻辑被分割为独立的插件模块和核心系统,提供了可扩展性、灵活性、功能隔离和自定义处理逻辑的特性。


对于微内核的核心系统设计来说,它涉及三个关键技术:插件管理、插件连接和插件通信,这里我们重点来分析一下插件通信。

插件通信是指插件间的通信。虽然设计的时候插件间是完全解耦的,但实际业务运行过程中,必然会出现某个业务流程需要多个插件协作,这就要求两个插件间进行通信;由于插件之间没有直接联系,通信必须通过核心系统,因此核心系统需要提供插件通信机制。

这种情况和计算机类似,计算机的 CPU、硬盘、内存、网卡是独立设计的配置,但计算机运行过程中,CPU 和内存、内存和硬盘肯定是有通信的,计算机通过主板上的总线提供了这些组件之间的通信功能。

下面阿宝哥将以基于微内核架构设计的西瓜播放器为例,介绍它的内部是如何提供插件通信机制。在西瓜播放器内部,定义了一个 Player 类来创建播放器实例:


let player = new Player({
  id: 'mse',
  url: '//abc.com/**/*.mp4'
});

Player 类继承于 Proxy 类,而在 Proxy 类内部会通过构造继承的方式继承 EventEmitter 事件派发器:


import EventEmitter from 'event-emitter'
 
class Proxy {
  constructor (options) {
    this._hasStart = false;
    // 省略大部分代码
    EventEmitter(this);
  }
}

所以我们创建的西瓜播放器也是一个事件派发器,利用它就可以实现插件的通信。为了让大家能够更好地理解具体的通信流程,我们以内置的 poster 插件为例,来看一下它内部如何使用事件派发器。

poster 插件用于在播放器播放音视频前显示海报图,该插件的使用方式如下:


new Player({
  el:document.querySelector('#mse'),
  url: 'video_url',
  poster: '//abc.com/**/*.png' // 默认值""
});

poster 插件的对应源码如下:


import Player from '../player'
 
let poster = function () {
  let player = this; 
  let util = Player.util
  let poster = util.createDom('xg-poster', '', {}, 'xgplayer-poster');
  let root = player.root
  if (player.config.poster) {
    poster.style.backgroundImage = `url(${player.config.poster})`
    root.appendChild(poster)
  }
 
  // 监听播放事件,播放时隐藏封面图
  function playFunc () {
    poster.style.display = 'none'
  }
  player.on('play', playFunc)
 
  // 监听销毁事件,执行清理操作
  function destroyFunc () {
    player.off('play', playFunc)
    player.off('destroy', destroyFunc)
  }
  player.once('destroy', destroyFunc)
}
 
Player.install('poster', poster)

(https://github.com/bytedance/xgplayer/blob/master/packages/xgplayer/src/control/poster.js)

通过观察源码可知,在注册 poster 插件时,会把播放器实例注入到插件中。之后,在插件内部会使用 player 这个事件派发器来监听播放器的 play 和 destroy 事件。当 poster 插件监听到播放器的 play 事件之后,就会隐藏海报图。而当 poster 插件监听到播放器的 destroy 事件时,就会执行清理操作,比如移除已绑定的事件。

看到这里我们就已经很清楚了,西瓜播放器内部使用 EventEmitter 来提供插件通信机制,每个插件都会注入 player 这个全局的事件派发器,通过它就可以轻松地实现插件间通信了。

提到 EventEmitter,相信很多小伙伴对它并不会陌生。在 Node.js 中有一个名为 events 的内置模块,通过它我们可以方便地实现一个自定义的事件派发器,比如:


const EventEmitter = require('events');
 
class MyEmitter extends EventEmitter {}
 
const myEmitter = new MyEmitter();
 
myEmitter.on('event', () => {
  console.log('大家好,我是阿宝哥!');
});
 
myEmitter.emit('event');

3.3 基于 Redis 实现不同系统间通信

在前面我们介绍了发布订阅模式在单个系统中的应用。其实,在日常开发过程中,我们也会遇到不同系统间通信的问题。接下来阿宝哥将介绍如何利用 Redis 提供的发布与订阅功能实现系统间的通信,不过在介绍具体应用前,我们得先熟悉一下 Redis 提供的发布与订阅功能。

3.3.1 Redis 发布与订阅功能

Redis 订阅功能

通过 Redis 的 subscribe 命令,我们可以订阅感兴趣的通道,其语法为:SUBSCRIBE channel [channel …]。


➜  ~ redis-cli
127.0.0.1:6379> subscribe deno ts
Reading messages... (press Ctrl-C to quit)
1) "subscribe"
2) "deno"
3) (integer) 1
1) "subscribe"
2) "ts"
3) (integer) 2

在上述命令中,我们通过 subscribe 命令订阅了 deno 和 ts 两个通道。接下来我们新开一个命令行窗口,来测试 Redis 的发布功能。

Redis 发布功能

通过 Redis 的 publish 命令,我们可以为指定的通道发布消息,其语法为:PUBLISH

channel message。
➜  ~ redis-cli
127.0.0.1:6379> publish ts "
pub/sub design mode"

当成功发布消息之后,订阅该通道的客户端就会收到消息,对应的控制台就会输出如下信息:


1) "message"
2) "ts"
3) "pub/sub design mode"

了解完 Redis 的发布与订阅功能,接下来阿宝哥将介绍如何利用 Redis 提供的发布与订阅功能实现不同系统间的通信。

3.3.2 实现不同系统间的通信

这里我们使用 Node.js 的 Express 框架和 redis 模块来快速搭建不同的 Web 应用,首先创建一个新的 Web 项目并安装一下相关的依赖:


$ npm init --yes
$ npm install express redis

接着创建一个发布者应用:

publisher.js


const redis = require("redis");
const express = require("express");
 
const publisher = redis.createClient();
 
const app = express();
 
app.get("/", (req, res) => {
  const article = {
    id: "666",
    name: "TypeScript实战之发布订阅模式",
  };
 
  publisher.publish("ts", JSON.stringify(article));
  res.send("阿宝哥写了一篇TS文章");
});
 
app.listen(3005, () => {
  console.log(`server is listening on PORT 3005`);
});

然后分别创建两个订阅者应用:

subscriber-1.js


const redis = require("redis");
const express = require("express");
 
const subscriber = redis.createClient();
 
const app = express();
 
subscriber.on("message", (channel, message) => {
  console.log("小王收到了阿宝哥的TS文章: " + message);
});
 
subscriber.subscribe("ts");
 
app.get("/", (req, res) => {
  res.send("我是阿宝哥的粉丝,小王");
});
 
app.listen(3006, () => {
  console.log("server is listening to port 3006");
});

subscriber-2.js


const redis = require("redis");
const express = require("express");
 
const subscriber = redis.createClient();
 
// https://dev.to/ganeshmani/implementing-redis-pub-sub-in-node-js-application-12he
const app = express();
 
subscriber.on("message", (channel, message) => {
  console.log("小秦收到了阿宝哥的TS文章: " + message);
});
 
subscriber.subscribe("ts");
 
app.get("/", (req, res) => {
  res.send("我是阿宝哥的粉丝,小秦");
});
 
app.listen(3007, () => {
  console.log("server is listening to port 3007");
});

接着分别启动上面的三个应用,当所有应用都成功启动之后,在浏览器中访问 http://localhost:3005/ 地址,此时上面的两个订阅者应用对应的终端会分别输出以下信息:

subscriber-1.js


server is listening to port 3006
小王收到了阿宝哥的TS文章: {"id":"666","name":"TypeScript实战之发布订阅模式"}

subscriber-2.js


server is listening to port 3007
小秦收到了阿宝哥的TS文章: {"id":"666","name":"TypeScript实战之发布订阅模式"}

以上示例对应的通信流程如下图所示:

到这里发布订阅模式的应用场景,已经介绍完了。最后,阿宝哥来介绍一下如何使用 TS 实现一个支持发布与订阅功能的 EventEmitter 组件。

四、发布订阅模式实战

4.1 定义 EventEmitter 类


type EventHandler = (...args: any[]) => any;
 
class EventEmitter {
  private c = new Map<string, EventHandler[]>();
 
  // 订阅指定的主题
  subscribe(topic: string, ...handlers: EventHandler[]) {
    let topics = this.c.get(topic);
    if (!topics) {
      this.c.set(topic, topics = []);
    }
    topics.push(...handlers);
  }
 
  // 取消订阅指定的主题
  unsubscribe(topic: string, handler?: EventHandler): boolean {
    if (!handler) {
      return this.c.delete(topic);
    }
 
    const topics = this.c.get(topic);
    if (!topics) {
      return false;
    }
    
    const index = topics.indexOf(handler);
 
    if (index < 0) {
      return false;
    }
    topics.splice(index, 1);
    if (topics.length === 0) {
      this.c.delete(topic);
    }
    return true;
  }
 
  // 为指定的主题发布消息
  publish(topic: string, ...args: any[]): any[] | null {
    const topics = this.c.get(topic);
    if (!topics) {
      return null;
    }
    return topics.map(handler => {
      try {
        return handler(...args);
      } catch (e) {
        console.error(e);
        return null;
      }
    });
  }
}

4.2 使用示例


const eventEmitter = new EventEmitter();
eventEmitter.subscribe("ts", (msg) => console.log(`收到订阅的消息:${msg}`) );
 
eventEmitter.publish("ts", "TypeScript发布订阅模式");
eventEmitter.unsubscribe("ts");
eventEmitter.publish("ts", "TypeScript发布订阅模式");

以上代码成功运行之后,控制台会输出以下信息:

收到订阅的消息:TypeScript发布订阅模式

五、参考资源

维基百科 - 发布/订阅

Ionic 3 - Events

implementing-redis-pub-sub-in-node-js-application

原文地址https://blog.csdn.net/qiwoo_weekly/article/details/108250534


WICC 2019:融云首次解密全球通信网底层基础架构

科技创新融云那些事 发表了文章 • 0 个评论 • 316 次浏览 • 2020-06-16 18:34 • 来自相关话题

日前,2019 全球互联网通信云大会(WICC)在上海圆满落幕。作为大会主办方的融云,面对场内外数万开发者,首次对其自建的全球通信网(SD-CAN)的架构进行解密,分享了架构设计背后的故事和演进历程。在连续多年稳居国内即时通讯领域市场占有率第一之时,融云已然将... ...查看全部

日前,2019 全球互联网通信云大会(WICC)在上海圆满落幕。作为大会主办方的融云,面对场内外数万开发者,首次对其自建的全球通信网(SD-CAN)的架构进行解密,分享了架构设计背后的故事和演进历程。

在连续多年稳居国内即时通讯领域市场占有率第一之时,融云已然将目光放在了更广阔的全球市场之上。自 2016 年起,融云跟随中国出海企业进行海外布局,为他们提供安全、可靠的全球通信云服务能力。时至今日,在全球化布局上,融云拥有 3 个数据中心,3000 多个动态加速节点,并自研最优链路调度算法,可以有效解决跨国、跨运营商、大规模用户访问导致的响应慢、丢包高、服务不稳定等诸多痛点。


融云首席架构师李淼演讲
突破代码所无法解决的难题,跨过技术调研与选型瓶颈

融云首席架构师李淼认为:“代码可以解决的问题都不是问题,代码解决不了的问题才是最难的问题”。在李淼眼中,什么是代码解决不了的难题?那就是搭建全球互联的通信云底层基础架构。

早期,融云通过提供 SDK,让开发者更易集成融云的通信云能力到自己的 App 应用中,这是融云将通信云技术普惠给广大开发者的初衷。融云凭借安全、可靠的互联网通信云技术能力,服务的中国企业越来越多,并且随着中国出海企业逐渐布局到了海外市场,为了进一步助力中国企业出海,融云自建全球通信网络的想法应运而生。

融云讲了一个真实案例,曾经有落地韩国的旅游 App 客户向融云反映,自己的用户在韩国、泰国等地常常因连接不畅,导致体验不佳。后来融云在韩国、泰国部署了加速节点,对当地的链路进行加速,解决了这个问题,但由于终端客户分布的随机性很大,当用户漫游到除韩国、泰国以外的海外地区,甚至到北欧等地时,仍然面临连接问题。

解决客户的问题就是融云研发团队的使命,融云全球通信网的构建已经变得刻不容缓。可以说,是客户的海外布局需求让融云打开了建设全球通信网络的大门。

融云全球通信加速网络演变历程

融云对全球通信网络的平台能力定义是:用户能够就近接入、覆盖区域广泛、通信质量稳定、支持动态路径切换。2016 年,融云全球通信加速网络 v1 版本正式上线运行,基本满足了出海客户对于全球通信的需求,并显示出性能优越、资源消耗低、结构简单、运维方便等优势。同时,融云持续在寻找对应区域的服务商上,加大技术和人力的成本投入,进行资源配置的优化和整合。通过对两年的运营数据比对:在没有加速网络的情况下,融云对海外用户整体的连通率大概只有 78% 左右,通过加速网络,融云在全球的用户整体连通率可以达到 99.5% 以上,全球互联互通的成效初显。

但是,v1 版本的全球通信网络同时也面临着多中心重复建设、链路选择不智能、功能相对单一等问题。因此,2018 年融云决定放弃 v1 版本中的架构设计,重新搭建通信云全球互联的底层基础架构,进行 v2 版本迭代。

由于融云全球通信加速网络 v2 版本采用自研的边缘节点,承载了更多的业务数据的处理能力,显示出四大优势:第一,支持多中心接入。在设计时增加了新的路由节点,在整个网络里,可通过边缘节点向路由节点汇聚数据流量,数据可向任意一个数据中心导入;第二,多协议支持。自研的边缘节点,使 v2 版本不仅能支持 HTTP、HTTPS,还能支持 WebSocket、WebSocketS 以及实时音视频 RTC 的信令等更多协议;第三,管控方便。v2 版本可以精确地控制每个客户的流量转向和流量调度;第四,灵活调度。相比于 v1 版本只能通过下发配置的方式进行调度,在 v2 版本可通过管控节点的方式对流量周转进行控制。

优化之路境无止境

5G 正式商用后,融云 SD-CAN 全球通信网络除了承载人与人之间的通信,还将更多地承载人与物、物与物的通信。针对互联网通信请求高并发、小数据包的传输特点,为全球客户提供优质的网络加速服务,这是融云未来所要面临的挑战。

面对挑战,融云希望全球通信网络在边缘计算和去中心化的实时数据交换方面有所突破。首先,在边缘计算方面,由于融云目前很多协议、逻辑、控制都是通过类似模块的方式写成,如果要更新这些,需要重新部署服务来解决。尽管现在可以做到使用户无感、无损地更新迭代,但要降低运营成本,融云要在边缘节点上增加类似 FaaS(Function as a Service)的能力,并通过一些动态语言在边缘结点上实现脚本化的运维操作,通过管控节点下发这些计算能力。

其次,在去中心化的实时数据交换方面。虽然 RTC 本身就是去中心化的实时交换,但是现在的交换数据一般都是音视频,融云后续会建立双端 TCP 连接,通过去中心化的网络,实现两个用户之间的文件传递和数据交互。

结语

融云历经三年的潜心研发,最终构建起安全、可靠的全球互联网通信云网络。在全球通信网络的架构演进之路上,融云始终如一,抱定为客户带来至佳体验的宗旨,在专业化的道路上不懈探索。随着 5G 通信和物联网技术的全面覆盖,融云势必将通过 SD-CAN 全球通信网络为出海开发者和企业提供更为强劲的服务能力。

【融云观察】央媒联手互联网平台试水短视频:海外网微叭合讲华人故事

科技创新融云那些事 发表了文章 • 0 个评论 • 98 次浏览 • 2020-06-16 18:34 • 来自相关话题

随着新媒体行业和技术的高速发展,以短视频为代表的新型传播方式与新兴业态方兴未艾。12月19日,人民日报海外网在京举办“全球华人生活短视频大赛”颁奖盛典,活动在微叭等众多互联网平台的鼎力支持下成绩斐然,全球网友踊跃参与,自8月1日启动到10月15日征集结束,陆续... ...查看全部

随着新媒体行业和技术的高速发展,以短视频为代表的新型传播方式与新兴业态方兴未艾。12月19日,人民日报海外网在京举办“全球华人生活短视频大赛”颁奖盛典,活动在微叭等众多互联网平台的鼎力支持下成绩斐然,全球网友踊跃参与,自8月1日启动到10月15日征集结束,陆续收到来自世界各地网友的投稿超10万件,总观看量逾6亿。


全球华人生活短视频大赛颁奖盛典
“全球华人生活短视频大赛”面向全世界各地的华侨华人,以“衣食住行”的变化为立足点,以短视频的形式展现当下全球华人多元丰富的生存状况与精神面貌。作为当前全网最大的语音短视频互娱社区之一,小桨科技积极参与到本次大赛中,并在其短视频平台“微叭”上特设活动分赛区,邀请海外用户参与短视频征集活动,充分调动全球华人网民的参与积极性,同时微叭还大力扶持优质视频参赛者,让优质创作者获得更多的曝光量。在此次颁奖盛典上,凭借着出色的活动组织能力和平台上的海量优质视频,小桨科技(微叭)也荣获了主办方颁发的最佳合作伙伴奖。

在这次“全球华人生活短视频大赛”活动中,人民日报海外网和微叭的合作,是中央级媒体和互联网视频平台联合的一次有益尝试,双方发挥各自的长处,从质量、内容、创新、技术等方面,提升了参赛短视频的可视性,也让网友们亲身感受到了祖国成立这70年来生活中一点一滴的变化。

活动开始至今,微叭平台上“全球华人生活短视频大赛”活动总曝光已超过1亿人次,无论是国内用户还是海外的华人华侨,都可以在短视频下方通过语音、文字多种形式随时聊天互动,对于此次征集活动中的优秀短视频,用户还可以点赞送花来表达对作品的支持。而不得不提的是,作为微叭的即时通讯云服务商,融云以稳定的技术及服务在背后默默地全程支持了此次活动。

一直以来,融云依托先进的技术实力,为开发者和企业提供安全、可靠的即时通讯及实时音视频通信云服务,是业界内唯一一家承诺在海量用户并发的情况下消息不丢、不重、不乱序的企业。根据第三方分析机构艾瑞发布的2019《全球互联网通信云行业研究报告》显示,融云在即时通讯市场占有率稳居第一。


微叭——边看边聊
选择融云的另一个重要原因则是微叭拥有着大量的海外用户。微叭表示,融云是行业内唯一一家在海外设立数据中心的互联网通信云服务商,在实际测试中,微叭业务使用融云后,通信连通率、消息到达率等重要数值的测试结果得到明显提升。

以此次“全球华人生活短视频大赛”为例,活动参与者遍布全球上百个国家和地区,融云通过多海外数据中心和遍布全球的优质接入点,结合融云自研的最优链路调度算法,解决因跨国、跨运营商、大规模用户访问而导致的响应慢、丢包高、服务不稳定等问题,为此次“全球华人生活短视频大赛”提供了安全、稳定、可靠的互联网通信云服务,助力活动平稳顺利地进行。

随着全球化市场的拓展,越来越多的中国企业像微叭一样正在凭借出色的综合实力逐步走向世界舞台,在世界经济和文化的交流中扮演重要角色。作为全球领先的互联网通信云服务商,融云将不断提升自身技术实力和服务质量,持续以通信技术底层能力赋能所有中国出海企业,降低产品的研发和运维成本,以全球化通信能力为中国企业的海外发展保驾护航。

探解融云云服务实力的背后:对技术与服务的精髓把握

科技创新融云那些事 发表了文章 • 0 个评论 • 81 次浏览 • 2020-06-16 18:31 • 来自相关话题

2019年底,首届全球互联网通信云(WICC)大会成功举办,让主办方融云这个名字格外亮眼。融云已经连续多年在IM即时通讯市场稳居第一,截止目前,用户覆盖全球233个国家和地区,日活超7千万,SDK触达用户42亿,日均消息量150亿。即在全国的手机用户中,平均每... ...查看全部

2019年底,首届全球互联网通信云(WICC)大会成功举办,让主办方融云这个名字格外亮眼。融云已经连续多年在IM即时通讯市场稳居第一,截止目前,用户覆盖全球233个国家和地区,日活超7千万,SDK触达用户42亿,日均消息量150亿。即在全国的手机用户中,平均每个手机中至少有5款App的底层通信能力是由融云赋能。融云已跃升为继微信、QQ之后的我国第三大通信平台,而作为PaaS服务,融云则稳居互联网通信云赛道第一,因此融云对通信云服务的发展趋势以及自身未来走向,成为业界关注的焦点。

通信云服务产业的发展趋势

在信息技术的驱动下,通信的形式、场景一直在持续迭代。现今,移动互联网各应用中的IM和实时音视频通话,企业级场景中企业内外部沟通都需要通信云服务来完成。智能硬件场景中,智能对讲机、执法记录仪以及各种智能终端的人与物、物与物的数据传输能力,实现不同设备之间的联动控制,都有赖于高品质的通信云服务。

未来,通信云产业发展有两个重要方向值得关注。首先是服务的稳定性。5G带来信息交互的高频化和TB量级的通信需求,能稳定提供亿级通信能力的通信云厂商,在市场中显得尤为重要。消息高并发呈常态,通信质量的稳定性和可靠性届时是检验通信云厂商的试金石。

其次是全球布局。随着一带一路的国家战略深化推进,中国企业面临着全球化的机遇与挑战。为这些出海企业提供云服务的厂商,未来重要的发展就是把自己的云服务能力扩展到全球。拥有全球通信网的融云即是这方面的杰出代表,融云为满足出海企业高质量的通信需求,2016年开始搭建SD-CAN全球通信加速网,并自研最优链路调度算法,能够为出海客户提供包括亚太、中东、非洲等新兴市场地区的网络质量的优化,完成了全球化的战略布局。

这两个产业发展趋势让我们看到,拥有亿级通信服务能力、且全球布局的通信云厂商价值凸显。

做好通信云服务核心是技术,本质是服务

拥有亿级通信服务能力、且全球布局的通信云厂商融云是如何做好通信云服务的?融云CTO杨攀认为核心是技术,本质是服务。崇尚技术,追求服务,是融云认为做好通信云的根本所在。

好的核心技术标准是什么?它应该是不断满足客户日益复杂的产品需求,不断进化的架构支持更高的海量并发场景,以及不断追求性能的极致体验。成立5年来,融云的SDK接口数量从279个增长到597个,服务端的API接口数量从36个增长到107个,开发者后台设置从13个增长至83个参数选项,极大地满足了客户对产品功能的需求。此外,融云对性能的极致追求,使消息的接收速度提升了30倍,启动速度提升了5倍,智能设备能耗实现了3倍的优化。融云不仅对性能不断加以优化,在服务端,还可按照客户的要求把上行和下行数据进行分离,以实现高并发的稳定性服务。


融云产品技术云图
通过融云的产品技术云图不难看出,融云为各种场景提供了大量的产品和技术能力,以满足各行业的客户需求。从最底层的数据中心和全球架构的加速网络,到开放的API接口和各种SDK插件,客户可直接应用于自身垂直场景的构建。融云还拥有全终端的平台覆盖能力,除了支持移动平台,还有Web、Linux等各种混合开发的框架。5G时代,向客户输送覆盖全球亿级并发的、高品质的通信服务能力是融云不懈的追求。

融云CTO杨攀同时认为做好通信云,本质在服务。融云是业内首家发布“云服务”体系的PaaS厂商,五大服务从稳定性、可靠性、安全性、个性化、先进性等多维度为客户提供贯穿于客户全生命周期的管家式贴身服务。在服务逻辑上,融云完成了从被动服务向主动服务的升级,从接受客户提需求到主动和客户探讨需求的转换。之前,故障是由客户报知,现在是主动进行故障报警,甚至通过数据质量驱动的方式把故障消灭于萌芽。融云在服务中更加注重细节,除了原有的工单模式,还提供IM北极星作为排查工具,直接判断客户的各种问题。

此外,对于通信业务,服务的可靠性是重中之重。每个通信云厂商都应追求一份业务三份投入,一份基础设施投入,一份冗余备份投入,一份质量数据投入。融云认为,基础设施投入增长率应远高于业务发展(流量)的增长率;CDN加速多备份、云存储多备份、可用区多备份、国际链路多备份是冗余备份中必不可少的投入;基于应用提供业务核心数据,追求对质量数据的投入,通信云厂商才能助力客户持续且精准运营。

未来,融云把发展交给开发者

未来,融云要把自己的发展交给开发者,向开发者开放,实现与开发者共创共赢。对此,融云将做好两个开放。首先,融云要将开发文档开放,与开发者共创共建。其次,融云将开放一个频道,对开发集成过程中的共同需求投票,针对有价值的需求和创意,联手广大开发者共创,共同把融云的平台做得更好。去年,融云已经进行了初步的尝试与实践。比如,在极客行活动中,让开发者从零开始集成产品功能,对于所遇问题,或文档、设计等理念不清晰的地方进行全程记录,以对应产品迭代和功能演进。

此外,对初接触通信云的开发者来说,融云现有500多个SDK接口,杨攀认为过于复杂了,未来,要把场景化的应用做深做透,做好场景化代码的片段示例和场景化教学小视频,提供开放调试工具集合,比如打包几十个SDK接口适用一个场景,甚至把Demo都集成好,追求在开发便捷性上的提升。

结语

做好技术与服务是企业的发展之道,这或许被看作是老生常谈,但如何让这两个方面真正相得益彰,则决定了企业能够获得多少续航的动力和上升的空间,也决定了企业发展的想象空间。而融云的做法,恰恰展示的就是对技术与服务的参悟能力和深入挖掘能力,这成就了今天的融云。融云的未来更开放、更贴近开发者,要与开发者共创共赢,赋能更多行业与场景,让我们期待拥有技术与服务双核实力的融云,为互联网通信云市场的发展注入全新动力。

【融云分析】H.264视频编码的基本原理和过程

科技创新融云那些事 发表了文章 • 1 个评论 • 72 次浏览 • 2020-06-16 18:25 • 来自相关话题

前言:在音视频通信中,音视频的数据压缩是有效降低带宽的主要方法;其中,视频占用了更高比例的带宽,视频压缩更为重要。如果不压缩,一副 RGB 图像,按照 800 x 600 的分辨率, 每秒 25 帧的帧率, 那么:每秒的数据量 = 800 x 600 x 3 ... ...查看全部

前言:
在音视频通信中,音视频的数据压缩是有效降低带宽的主要方法;其中,视频占用了更高比例的带宽,视频压缩更为重要。

如果不压缩,一副 RGB 图像,按照 800 x 600 的分辨率, 每秒 25 帧的帧率, 那么:每秒的数据量 = 800 x 600 x 3 x 25 x 8 ( bit )。

H.264 压缩后,平均码率可以减少 20 倍;如果使用动态码率,对于某些简单场景的监控等,可以更大的压缩视频,同时保证视频质量。

视频压缩工具有很多,H.263、Mpeg-4、 VP8、VP9、 H.264 等等。目前最常见和最常用的视频压缩算法是 H.264,基于 H.264 比较流行的开源工具有 X264、OpenH264 以及 FFmpeg (内部集成 x264 和 OpenH264 ), 解码工具大多用 FFmpeg 实现。

视频编码的基本要求:

1:有足够的压缩比,能将压缩结果控制在一个范围内;

2:压缩后的视频,解压后要保证一定的视频质量。

H.264 的优势有什么呢?

1:很好的网络亲和性,更适合复杂网络传输;

2:更高的视频压缩比,在同等视频质量下;大约是H.263,Mpeg-4 的 2 倍;

3:目前移动端已经广泛支持 H.264 硬件编解码,效率和速度更快。

H.264/AVC 的常用概念:
帧和场:

视频的一帧,可以看做是一副完整的图像, 一帧视频可以分成两个隔行的场,通常叫做 “顶场” 和 “底场”。

为什么会有“场”的概念?

因为早期在电子显像管电视机中,图像是由电子逐行扫描显示的。为了更好的显示动态图像,就会先隔行扫描显示图像的 “顶场”,然后在扫描显示图像的“底场”。这样运动图像的显示效果会更好。

但是隔行扫描的实际效果是模糊了图像。目前随着科技的发展,在视频编码中,通常直接用一副完整的图像。

档次和级:

(1)基本档次:基于 I 帧 和 P 帧 ,支持 CAVLC 编码;适合视频会议,视频电话,实时视频流等。

(2)主要档次:支持各行视频,增加 B 帧编码,支持 CABAC 编码。主要用于视频存储等。

(3)扩展档次:支持流之间的切换,改进误码性能;主要用于视频点播等。


YUV 4:2:0 图像:
一帧没有经过压缩的位图数据一般保存的数据是每个像素用 RGB 表示,每个颜色分别用一个字节表示。

我们这里常用的 YUV 图像指的是 YUV 4:2:0 图像,用四个亮度 Y 分量对应一对 UV 色度分量。


RGB 转换 YUV 4:2:0 的公式:

Y = 0.299R + 0.587G + 0.114*B;

U = -0.169R – 0.331G + 0.5 *B ;

V = 0.5 R – 0.419G – 0.081*B;

由此可见,RGB 图像转到 YUV 4:2:0 图像的这一过程中是有图像质量损失的。

为什么用 YUV 4:2:0 ?

首先, YUV 4:2:0 比 RGB 图像小一半。每个像素为 12 bit。

其次,早期的电视分为黑白电视和彩色电视,如果是黑白电视,那么直接播放 Y 亮度分量。

如果是彩色电视,那么就可以全部直接播放。

视频编码系统的基本结构:

视频的压缩原理与过程:
1:我们先看一幅图像:(图1)


这幅图像中,大部分是绿色,如果仅仅将小球保留,绿色用一个变量和坐标表示,那么这幅图像的信息就可以很好的减少,也可以根据变量和坐标恢复图像。

2:再看一副图像:(图2)


这幅图像的小球,向右上角移动了一格,其它内容和信息都与上图基本一致;

如果已经有了“图1”, 那么只需要将“图2”与“图1”中的不同信息保存下来,那么就可以根据“差别信息”参考“图1” 来恢复显示“图2” 了。

这就是视频压缩的本质和原理:

空域压缩;

时域压缩。

GOP:
我们可以按照一定的图像数量进行编码,如 25 帧图像为一组,每组的第一帧图像通过帧内编码,我们称之为 IDR 帧,其它图像参考其它图像的信息进行编码,我们称之为 P 帧 / B 帧,那么可以将这一组数据一个 GOP。

如果一个 GOP 的第一帧图像 IDR 帧丢失或者损坏,那么这个 GOP 后面的所有视频数据将会解码错误。只有等到下一个 GOP,当解码器遇到 IDR 帧会即时刷新图像,清空参考图像列表。


宏块:
H.264 编码的最小单位,我们可以看做是一个宏块,就是一个 16 x 16 的图像区域,也可以划分的更小,如 8 x 8。

什么是预测编码?
在视频压缩中,就是将预测值与实际值作差,然后再次压缩。

帧内预测:

IDR帧 ,I 帧:
帧内编码就是当前帧不参考其它帧,可以独立解码的一种编码方式;

可以简单的想象为,一副 BMP 图像压缩为一副 JPEG 图像;

通常帧内编码的图像,我们称之为 I 帧 intra picture,就是不需要参考其它图像,可以自己独立解码出图像的视频数据帧。

需要注意的是:IDR 帧是 I 帧,但是 I 帧不是 IDR 帧。IDR 帧是一个 GOP 的第一帧,GOP 中间有可能出现 I 帧,后面的帧有可能参考 I 帧之前的视频帧,但是不可能越过 IDR帧。一般 IDR 帧 前面还有 SPS 和 PPS 信息。

在帧内编码中,宏块最多可以有九种预测模式,我们可以找到与原图最相近的预测图像:


帧间预测:
帧间预测技术分为 B 帧预测和 P 帧预测。

B 帧预测 – 双向预测:
主要是参考之前编码的帧和之后编码的帧;

B 帧的数据量更小,但是 B 帧由于需要参考后续帧,那么就会引入延时;

同时用到更多的计算开销;

B 帧不会作为参考帧,所以,丢弃 B 帧也不会引起花屏;如上面的“GOP 图“。

P 帧预测 – 单向预测:
主要参考之前编码过的视频帧;

后面为了清晰说明原理,以 BaseLine 为示例基础,仅包含 I 帧 和 P 帧;

运动矢量:
如:“图1”的小球位置坐标假设为(x0,y0), “图2”的小球位置坐标假设为(x1,y1),那么小球的运动矢量就是(x1 – x0,y1 – y0);

运动估计:
得到运动矢量的过程就是运动估计;


将预测数据和实际数据相减,去掉时域上的数据冗余,就得到了预测的“残差”数据,也就是补偿数据;

解码视频数据,可以根据补偿数据,运动矢量和参考图像恢复出当前图像。

这一步极大的减少了时间域上的图像冗余数据。

DCT – 离散余弦变化 :
这是一个复杂的数学名词,简单描述,就是去除像素间的相关性;

目的当然是进一步压缩数据。

举个例子:


更多的情况可能是图中情况,即便是这样,有效数据也更好的减少了,多了很多 “0” :


量化:
量化过程在不降低视觉效果的前提下减少图像的编码长度,减少图像信息中视觉恢复中不必要的信息。

量化结果,实际上是由量化步长决定的 (QStep),量化步长越小,图像的细节信息保留的越多,码率越高,图像质量越高。反之,量化步长值越大,图像质量越差。

量化是有损压缩,这一步的图像质量有一定的损失。但是前提是不影响正常的视觉和图像质量。

zig-zag 扫描 ,也有人称之为”锯齿扫描” :


zig-zag 扫描和 FFmpeg 官方标志

游程编码 – (RLC, Run Length Coding):
又称“运行长度编码”或“行程编码”,是一种统计编码,是一种无损压缩的编码方式。

其实锯齿扫描和游程编码可以看做是一体的。

游程编码进一步压缩保存了有效的保存扫描数据。

熵编码:
利用信源的统计特性进行码率压缩的编码称之为“熵编码”,也叫统计编码。

从名称来看,还是要压缩数据;这一步是无损压缩。基本原理就是给高频率数据短码,低频率数据长码。

从定义来看,就是指定一组数据中,根据数据出现概率来编码的一种方式。

在 H.264 中,也就是之前提到过的 CABAC 编码 和 CAVLC 编码。


本文图片部分主要来自于“百度图库”和《新一代视频编码压缩标准》。

融云 CTO 杨攀:出海社交娱乐项目的通信技术应用指南

科技创新融云那些事 发表了文章 • 0 个评论 • 83 次浏览 • 2020-06-16 18:10 • 来自相关话题

近日,由白鲸出海主办的《出海东南亚 释放娱乐新势能》线上分享会开启,邀请融云、Akamai、HAGO、AppsFlyer 等企业负责人和行业专家,围绕着泛娱乐和游戏行业所关注的出海话题进行研讨。在分享会上,融云联合创始人兼 CTO 杨攀重点剖析了目前东南亚出海... ...查看全部

近日,由白鲸出海主办的《出海东南亚 释放娱乐新势能》线上分享会开启,邀请融云、Akamai、HAGO、AppsFlyer 等企业负责人和行业专家,围绕着泛娱乐和游戏行业所关注的出海话题进行研讨。在分享会上,融云联合创始人兼 CTO 杨攀重点剖析了目前东南亚出海市场趋势,并就出海项目中的通信技术应用给出了自己的观点。

出海聚焦6大领域 社交成为基础诉求

在分享中,杨攀指出,随着国内竞争的加剧和中国企业在海外逐渐形成生态体系后,越来越多的企业开始将国内流行的业务模式带到海外。特别是东南亚地区,得益于区域地理位置的优势,以及在文化、历史及宗教方面与中国的渊源,这一地区的用户习惯与中国更为接近,也成为了出海企业的重心。

杨攀表示,目前在东南亚市场,中国出海产品普遍集中在社交、电商、金融、游戏、工具和内容这 6 大领域,且应用社交化的趋势非常明显,社交不再单纯是某一款通信应用,而是每一款应用中都带有社交属性。


“目前的应用基本上都是需要注册使用的,用户自带身份就天然的需要进行沟通,无论是平台运营者与用户,还是用户与用户之间,沟通是一个基础的诉求”,杨攀认为,即使是对于看似不需要社交能力的工具类应用而言,引入社交属性,可以使应用无论是活跃、留存还是用户的召回上,都可以大幅增强用户黏性。

关于疫情对全球社交带来的影响

根据融云平台数据来看,在疫情的影响下,全球线上社交的整体业务量猛增,其中,原本在线上拥有自传播能力的社交平台或应用,在其热门话题或活跃 KOL 的引导助力下,业务量保持着稳定增长。但值得关注的是,对于部分产品,特别是仍处于初创期的产品,会依赖于线下推广和线上流量购买,在无法进行线下推广和市场投入趋于保守的现状态下,很难获得业务量的增长。


同时可以看到,受疫情的影响,大量的办公业务和教育机构也从线下搬到了线上。受此影响,融云平台每日的消息量相较于 2019 年提升了 3 倍以上,单日峰值消息量突破千亿条。同时实时音视频单月使用分钟数也较 2019 年平均值增长了 4 倍以上。

典型社交通信场景分析

目前各类社交形态所使用的主要通信服务包含了 IM 聊天、语音沟通、视频沟通和直播互动等。杨攀将社交通信场景概况为两大类,一类是以 IM 功能为主的私密社交、兴趣社群、直播互动场景,另一类则是以 RTC 能力为主的音视频直播、音视频通话等场景。


出海企业可以根据产品逻辑和场景需求,选择适合的互联网通信能力来构建自己的产品业务。但通信云 PaaS 服务不同于标准化的 SaaS 产品,杨攀表示,“通信业务与产品业务逻辑是紧密结合的,每家的产品都有自己的特点,所以在应用内构建通信能力的过程中,产品架构的设计以及如何用融云 SDK 接口组合成开发者想实现的功能和服务,这都是非常依赖于实践经验的。”对此,融云提供了业务和技术解决方案的咨询服务,针对客户的业务场景诉求,融云产品技术专家可量身定制产品解决方案,解决架构性能及技术实现问题。

融云的出海全球化服务

显然,东南亚地区已成为中国企业出海的重点市场,融云多年前即在新加坡建立了海外物理数据中心,成为了国内唯一一家在海外建有数据中心的通信云厂商。以新加坡为中心,辐射整个东南亚地区及邻近的南亚、澳洲等市场,让融云的客户进入印尼、马来西亚、越南等国家和地区,均可以获得业界高质量的通信服务。

“物理形式的数据中心,比任何形式的网络优化都要来的有效果,目前融云在边缘节点做到 2 跳,核心节点做到 1 跳,就可以连接到融云的数据中心。”杨攀表示,基于出海客户的真实诉求,融云自建了全球通信网(SD-CAN),依托海外数据中心,通过 SD-CAN 遍布全球的优质接入点,结合融云自研的最优链路调度算法,解决服务响应慢、服务不稳定等问题。


融云全球通信云服务
“IM 是一个中心化的服务,可以通过融云的海外数据中心进行消息的传递,但在 RTC 方面,融云是去中心化的。”杨攀表示 IM 和 RTC 完全是两个业务逻辑,他举例称,融云在全球均布有核心节点,比如在印度有两个用户进行音视频通话,不需要经过数据中心,只需要通过融云位于孟买的核心节点,即可实现实时互动交流。目前,融云在东南亚及南亚市场可以做到端到端延时小于 300ms,保障用户之间延迟无感知的实时互动。

从 2016 年开始服务出海客户至今,融云业务已全面覆盖全球的 233 个国家和地区,在欧美、中东、东南亚及非洲等地均拥有大量的客户,服务于 StarMaker、小象直播、Opera、Razorpay、Castbox、Lispon 等众多知名的出海应用。杨攀表示,一方面融云会继续打磨自身的产品技术,优化全球通信网络,另一方面不断提升开发者服务水平,通过为开发者提供北极星(质量问题排查)、业务数据监控等服务,让开发者可以快速定位排查问题,监测通信质量,进而不断优化产品业务,最终为用户带来更稳定流畅的通信体验。

艾瑞报告:通信云三大应用场景助力5G时代万物互联

科技创新融云那些事 发表了文章 • 0 个评论 • 75 次浏览 • 2020-06-16 18:10 • 来自相关话题

“未来在每个互联网、企业级应用、智能硬件设备上都有望看到通信云的身影”,当5G时代到来,各类数字信息建设将驶入新的快车道,通信云的价值也将日渐突显,成为在每个行业发展中“无处不在”的底层基础技术。近期艾瑞发布的《2019年全球互联网通信云行业研究报告》认为,通... ...查看全部

“未来在每个互联网、企业级应用、智能硬件设备上都有望看到通信云的身影”,当5G时代到来,各类数字信息建设将驶入新的快车道,通信云的价值也将日渐突显,成为在每个行业发展中“无处不在”的底层基础技术。

近期艾瑞发布的《2019年全球互联网通信云行业研究报告》认为,通信云已进入2.0阶段,完成从传统通信向提供“IM+实时音视频”整合通信能力的“互联网通信云”的迭代。随着应用场景从互联网应用、企业级应用向智能硬件的突破性拓展,通信云将向3.0时代进一步升级。在三大应用场景与各行业融合发展带来的乘法效应下,5G时代的通信云有望迎来发展的黄金期。

最广泛的应用场景:互联网应用

——互联网通信云开启互联网应用的社交突破口

互联网应用是互联网通信云最广泛应用的场景,通信云已经落地于社交、直播、教育、游戏、电商、生活等各个领域,可以帮助各类互联网应用的开发者快速获得IM和实时音视频能力,实现应用内社交、音视频通话、直播互动等不同场景下的沟通,为互联网应用带来多层面的价值。

图片10

一、构建与用户沟通的桥梁,增强用户与平台的互动性。

互联网通信云是互联网应用构筑用户沟通网络的基础,可以让平台服务从以往图文、视频、音频等单一的形式向问答、社群、直播等进行延展,强化平台的粘性。例如在在线教育领域,互联网通信云厂商融云助力新东方、韦博英语在移动端打造班级群聊,同班学员间可进行在线即时交流,让学习不再孤单;在互联网金融领域,通信云可以帮助金融机构在公众服务平台上构建“专家在线直播互动”、“客服沟通”等场景,通过聊天室管理、用户管理、消息管理、聊天互动等多种功能的支持,为金融机构带来耳目一新的在线互动体验。

二、助力企业通过打开社交突破口,探寻商业创新之道。

互联网通信云通过提供IM+实时音视频的整合通信能力,可以助力互联网应用更好的进行创新,如去年以来一些社交性应用便借助通信云的实时语音技术打造“声音交友”场景;通过在线k歌、排麦领唱等方式,构造游戏化音乐社交场景。通信云还可以帮助不同行业构建以兴趣为纽带的垂直化社交,如近期国内发布的“移动电影院V2.0”产品便借助IM和实时音视频技术,开启了“观影社交”模式的探索,为社交领域的后入者提供了很好的思路。

三、与更多新技术融合,有望产生“杀手级”颠覆性应用。

5G网络具有超宽带、超高速度、超低延时的特点,5G时代的互联网通信云与AR、VR等新技术的融合,将可以助力互联网应用为用户带来视觉、听觉、触觉上的全新互动体验,探索新的视频社交、VR社交场景,将产生更多“杀手级”颠覆性的互联网应用,更有望开启新的互联网时代。

深具潜力的应用场景:企业级应用

——互联网通信云担当企业内外部和业务系统的连接器

为企业客户提供通信个性化解决方案,是互联网通信云现阶段非常具有潜力的发展方向。随着企业对数字化办公的需求越来越强烈,使用个人通讯软件存在敏感信息外泄的隐患,搭建一整套企业内部的通信系统显得尤为重要,覆盖全终端、多渠道的互联网通信云已然成为企业的首选。融云面向政务机构、中大型企业提供完整企业通信解决方案——融云RCE,可实现“连接内部、连接外部、连接业务、跨国沟通”四大类场景,并满足各行业大中型企业“安全、可定制”的个性化需求。

图片11

一、通过“内外连接”,企业将可以迅速建立与内部、外部连接的通信网络,有效促进企业沟通效率的提升。

在“连接内部”上,互联网通信云可帮助企业打造安全、可靠的私有版通讯工具,通过对客户端、链路端、服务端、运维端的安全防护,从根源上解决用户通信安全的核心问题。在“连接外部”上,互联网通信云可以帮助企业实现与用户、企业与上下游厂商的场景化沟通,如在金融领域,可帮助金融机构实现销售过程的“双录”,规范金融销售行为,并构建VIP客户音视频客服等场景,为客户体验提升提供支持;在房产领域,通信云可以帮助房产机构建立“视频看房”,让客户通过远程高清画面即可了解房源的真实状态,帮助销售提升成交率。

二、通过“连接业务”,推动企业信息化系统的融合化。

通过企业IM与OA、ERP、CRM等业务系统无缝对接,互联网通信云可成为企业内外部和业务系统的连接器,促进企业通信软件与企业内部业务、企业内部信息化应用走向融合,最终整合成覆盖全终端、多渠道的一整套系统。

三、通过“跨国沟通”,帮助企业快速实现全球化运营。

互联网通信云将彻底改变传统通信受区域、运营商限制的局限性,通过构建覆盖全球的通信网络,实现无时间与地域限制、成本更加低廉的全球化沟通,降低通信方式给企业全球运营带来的风险和管理的复杂性,帮助企业更快速完成向“全球化运营”的高质蜕变,成为真正意义上的“跨国企业”。

突破性的应用场景:智能硬件

——互联网通信云赋能智能硬件构建万物互联时代

5G将移动互联网扩展到物联网领域,物联网将驱动智能硬件成为互联网通信云新兴的应用场景。艾瑞报告指出,当与物(设备)相关的信息传递被纳入到通信云的范畴,通信云的应用场景将实现延展,不仅可实现“人与人的沟通”,更可实现“人与物的沟通、物与物的沟通”,通信云也将从2.0阶段迈向3.0阶段。

图片12

互联网通信云对于智能硬件的价值主要体现在,能够实现设备与用户之间、设备与设备之间数据通信能力,方便开发者和企业客户开展物联网创新性业务。目前在TO B领域,互联网通信云可为智能楼宇、智能交通、智能制造的发展提供支持,推动传统通信设备升级为互联网通信,加速移动智能设备配送调度、工业自动化等新兴业务实现快速、低成本的设备间通信;在TO C领域,互联网通信云可为智能手表、智能音箱、智能机器人等个人消费智能硬件,实现不同产品之间的联动控制。

国内通信云厂商已经在智能硬件领域展开了技术落地的相关实践,例如融云等厂商推出了智能穿戴设备音视频解决方案,可以为手表、眼镜、执法记录仪等智能设备提供音视频解决方案,满足远程监护、维修、执法等场景的应用需要,实现无缝的沟通与协作。

互联网通信云的三大场景方向在各个行业进行发酵、裂变,对于全球通信将产生全面的重塑效应:在5G开启的万物智联世界里,帮助各行业全面构建四通八达的“枢纽”与“管道”,以全新的通信方式为全球经济增长带来新的活力。随着中国通信云厂商已成为2.0阶段的“全球互联网通信云服务商”,可以提供覆盖三大应用场景的通信云服务,中国将成为互联网通信云发展中屹立前沿的佼佼者,推动新时代全球通信方式变革与产业创新。

融云观察:快速洞悉伊利立体化协同时代背后的通信奥秘

科技创新融云那些事 发表了文章 • 0 个评论 • 126 次浏览 • 2020-06-16 18:09 • 来自相关话题

2017年乳制品消费总量已达到2691.66万吨,人均消费量将达到20.83千克,国人持续增加的乳制品需求使行业发展和竞争并存。借助移动信息化手段增强竞争力,逐渐成为乳制品企业的普遍选择,通过互联网通信云技术与行业特征的有机融合,将对行业内各企业的研发、生产、... ...查看全部

2017年乳制品消费总量已达到2691.66万吨,人均消费量将达到20.83千克,国人持续增加的乳制品需求使行业发展和竞争并存。借助移动信息化手段增强竞争力,逐渐成为乳制品企业的普遍选择,通过互联网通信云技术与行业特征的有机融合,将对行业内各企业的研发、生产、管理和服务等各环节带来深刻变革。

就全国乳制品企业来说,当前信息化建设的路任重而道远。信息孤岛现象比较普遍、数据无法充分共享、信息的价值不能完全发掘、全球通信需求难以满足,加之系统的灵活性、扩展性及兼容性欠佳,都会导致企业无法对业务的快速变化进行及时响应。

作为国内乳制品行业的领头羊,内蒙古伊利实业集团股份有限公司(以下简称“伊利集团”)走在了移动信息化建设的前沿。伊利集团是唯一一家进入全球乳业8强的亚洲乳企,创造了亚洲乳企迄今为止的最高排名,如今正为国内外千万家庭提供着来自草原牧场的健康鲜奶,以高品质、高科技含量、高附加值的多元化产品,赢得了广大消费者的高度信赖。优秀的管理模式让伊利集团在乳制品行业全产业链发展道路上跻身前列,而伊利集团能够取得现在的成绩,与其较早从集团内部开展移动信息化建设的决策是密不可分的。

“三剑合璧”助力伊利集团大步迈向立体化协同时代

经过深入详细的需求调研分析,伊利集团亟需在市场上寻找一家可靠的协同办公软件服务商,并建立持久的合作关系。伊利集团的企业管理和技术团队对多家主流协同管理服务商进行了全面细致的对比,最终选择了OA行业唯一主板上市公司——泛微,助力其开拓乳制品行业全面移动信息化的先河。

在技术和产品方面,伊利集团重视泛微17年间在协同办公软件领域的专注,认同其以OA系统帮助企业构建全员统一的移动办公平台,特别是在企业级移动互联大潮下,泛微发布了以“移动化、社交化、平台化、云端化”四化为核心的全新系列产品;另一方面,伊利集团也看重泛微背后融云为其赋予的扎实的通信云能力,融云基于海量业务的技术锤炼,从基础架构到精细化运营,充分体现为合作伙伴赋能及技术倍化的实力;伊利集团选择泛微和融云,还得益于二者具备完善的合作伙伴体系,通过合作可获得快速的技术支持及更大的综合价值,“三强”可共同构建立体协同办公云图。

融云泛微_900x500

“五大中心、三大平台”实现移动信息化全面升级

根据伊利集团所面临的市场业务需求,泛微为其打造了覆盖“五大中心”(门户集成中心、流程审批中心、知识汇聚中心、身份认证中心、知识共享中心),跨越“三大平台”(综合办公平台、企业微信平台、移动办公平台)的全新协同办公系统,为伊利集团全国33个省市、70多家分子公司、500多个业务部门,共60000多人提供了高效协同办公方式,驱动企业移动信息化加速发展。

其中,融云的云通信能力作为贯穿这一套移动协同办公系统的重要主线,“通信引擎”、“自有系统连通”、“特色功能”和“全球通信加速网络”等底层技术为整套系统增光添彩,帮助伊利集团真正实现管理战略的快速落地和移动信息化的全面升级。

毅力2

(伊利集团内部通信平台)

l 通信引擎完成资源整合

如何解决整套协同办公系统的通信问题,以提高企业内外部协同办公的效率,对拥有供应链、经销商、分公司架构的伊利集团来说是个复杂且棘手的问题。通过整合融云云通信能力后的泛微协同办公系统,伊利集团可做到内外部1对1沟通,多人沟通,并通过调用组织架构通讯录,自动生成特定业务群组,不仅扫清员工沟通障碍,使生产和工作经验得到有效及时的传递,也令资源得到有效整合。

l 自有系统连通可扩展激发新活力

在引进泛微协同办公系统之前,伊利集团已自助开发乳业生产、质量以及供应链环节中的一系列配套软件,然而系统平台无法连通扩展导致了信息共享的瓶颈。而基于融云通信系统中良好的兼容性,泛微可为伊利集团提供统一消息总线,无缝对接企业自有的业务系统,将企业的沟通机制和办公系统有机结合,整体办公效率轻松提升。

l 特色功能让协同系统大放异彩

利用融云的即时通讯和实时音视频能力,泛微针对伊利集团的业务需求,专门打造了特色功能,如“PIN功能”、“已读未读”、“来电/拨号提醒”等。事实证明,在伊利集团的多个办公场景中,这些特色功能成功避免信息遗漏,并且加速了协同系统的创新。

伊利3

(特色功能——PIN功能)

l 全球通信加速网络助力国际化发展

融云的全球通信加速网络,已在全球建立了三大数据中心,3000多个加速节点,服务范围已覆盖全球233个国家和地区,当泛微与融云相遇,可助力伊利集团这样国际化的企业,大幅提升企业在全球的通信体验,在世界的任何一个地方,均能实现稳定的办公与流畅的沟通。

对于泛微和融云的牵手,泛微网络研发副总裁杨国生评价道,我们在经过严格的技术测评后选择了与融云合作,在合作过程中,融云在产品性能、功能方面都表现良好,尤其是在高并发环境下的服务稳定性和高可用性都经受住了严峻的考验。

不仅如此,泛微借助融云在即时通讯和实时音视频中积累的丰富技术经验,不仅获得强大的技术产品支撑,还通过专业的线下合作伙伴大会接触各个行业的头部客户。未来,泛微和融云双方将进一步联手共同推动企业信息化的发展。

WICC 2019:融云首次解密全球通信网底层基础架构

科技创新融云那些事 发表了文章 • 0 个评论 • 316 次浏览 • 2020-06-16 18:34 • 来自相关话题

日前,2019 全球互联网通信云大会(WICC)在上海圆满落幕。作为大会主办方的融云,面对场内外数万开发者,首次对其自建的全球通信网(SD-CAN)的架构进行解密,分享了架构设计背后的故事和演进历程。在连续多年稳居国内即时通讯领域市场占有率第一之时,融云已然将... ...查看全部

日前,2019 全球互联网通信云大会(WICC)在上海圆满落幕。作为大会主办方的融云,面对场内外数万开发者,首次对其自建的全球通信网(SD-CAN)的架构进行解密,分享了架构设计背后的故事和演进历程。

在连续多年稳居国内即时通讯领域市场占有率第一之时,融云已然将目光放在了更广阔的全球市场之上。自 2016 年起,融云跟随中国出海企业进行海外布局,为他们提供安全、可靠的全球通信云服务能力。时至今日,在全球化布局上,融云拥有 3 个数据中心,3000 多个动态加速节点,并自研最优链路调度算法,可以有效解决跨国、跨运营商、大规模用户访问导致的响应慢、丢包高、服务不稳定等诸多痛点。


融云首席架构师李淼演讲
突破代码所无法解决的难题,跨过技术调研与选型瓶颈

融云首席架构师李淼认为:“代码可以解决的问题都不是问题,代码解决不了的问题才是最难的问题”。在李淼眼中,什么是代码解决不了的难题?那就是搭建全球互联的通信云底层基础架构。

早期,融云通过提供 SDK,让开发者更易集成融云的通信云能力到自己的 App 应用中,这是融云将通信云技术普惠给广大开发者的初衷。融云凭借安全、可靠的互联网通信云技术能力,服务的中国企业越来越多,并且随着中国出海企业逐渐布局到了海外市场,为了进一步助力中国企业出海,融云自建全球通信网络的想法应运而生。

融云讲了一个真实案例,曾经有落地韩国的旅游 App 客户向融云反映,自己的用户在韩国、泰国等地常常因连接不畅,导致体验不佳。后来融云在韩国、泰国部署了加速节点,对当地的链路进行加速,解决了这个问题,但由于终端客户分布的随机性很大,当用户漫游到除韩国、泰国以外的海外地区,甚至到北欧等地时,仍然面临连接问题。

解决客户的问题就是融云研发团队的使命,融云全球通信网的构建已经变得刻不容缓。可以说,是客户的海外布局需求让融云打开了建设全球通信网络的大门。

融云全球通信加速网络演变历程

融云对全球通信网络的平台能力定义是:用户能够就近接入、覆盖区域广泛、通信质量稳定、支持动态路径切换。2016 年,融云全球通信加速网络 v1 版本正式上线运行,基本满足了出海客户对于全球通信的需求,并显示出性能优越、资源消耗低、结构简单、运维方便等优势。同时,融云持续在寻找对应区域的服务商上,加大技术和人力的成本投入,进行资源配置的优化和整合。通过对两年的运营数据比对:在没有加速网络的情况下,融云对海外用户整体的连通率大概只有 78% 左右,通过加速网络,融云在全球的用户整体连通率可以达到 99.5% 以上,全球互联互通的成效初显。

但是,v1 版本的全球通信网络同时也面临着多中心重复建设、链路选择不智能、功能相对单一等问题。因此,2018 年融云决定放弃 v1 版本中的架构设计,重新搭建通信云全球互联的底层基础架构,进行 v2 版本迭代。

由于融云全球通信加速网络 v2 版本采用自研的边缘节点,承载了更多的业务数据的处理能力,显示出四大优势:第一,支持多中心接入。在设计时增加了新的路由节点,在整个网络里,可通过边缘节点向路由节点汇聚数据流量,数据可向任意一个数据中心导入;第二,多协议支持。自研的边缘节点,使 v2 版本不仅能支持 HTTP、HTTPS,还能支持 WebSocket、WebSocketS 以及实时音视频 RTC 的信令等更多协议;第三,管控方便。v2 版本可以精确地控制每个客户的流量转向和流量调度;第四,灵活调度。相比于 v1 版本只能通过下发配置的方式进行调度,在 v2 版本可通过管控节点的方式对流量周转进行控制。

优化之路境无止境

5G 正式商用后,融云 SD-CAN 全球通信网络除了承载人与人之间的通信,还将更多地承载人与物、物与物的通信。针对互联网通信请求高并发、小数据包的传输特点,为全球客户提供优质的网络加速服务,这是融云未来所要面临的挑战。

面对挑战,融云希望全球通信网络在边缘计算和去中心化的实时数据交换方面有所突破。首先,在边缘计算方面,由于融云目前很多协议、逻辑、控制都是通过类似模块的方式写成,如果要更新这些,需要重新部署服务来解决。尽管现在可以做到使用户无感、无损地更新迭代,但要降低运营成本,融云要在边缘节点上增加类似 FaaS(Function as a Service)的能力,并通过一些动态语言在边缘结点上实现脚本化的运维操作,通过管控节点下发这些计算能力。

其次,在去中心化的实时数据交换方面。虽然 RTC 本身就是去中心化的实时交换,但是现在的交换数据一般都是音视频,融云后续会建立双端 TCP 连接,通过去中心化的网络,实现两个用户之间的文件传递和数据交互。

结语

融云历经三年的潜心研发,最终构建起安全、可靠的全球互联网通信云网络。在全球通信网络的架构演进之路上,融云始终如一,抱定为客户带来至佳体验的宗旨,在专业化的道路上不懈探索。随着 5G 通信和物联网技术的全面覆盖,融云势必将通过 SD-CAN 全球通信网络为出海开发者和企业提供更为强劲的服务能力。

你以为在做的是微服务?不!你只是做了个比单体还糟糕的分布式单体!

科技创新大兴 发表了文章 • 0 个评论 • 71 次浏览 • 2021-04-01 11:19 • 来自相关话题

昨晚睡觉前,顺手撸了几个群聊的聊天记录。发现一个很有意思的名词“分布式单体”,顺藤摸瓜看了一下之前的聊天记录,由于内容骂骂咧咧,我就不贴出来了。大致内容就是某公司在做微服务改造,但改的不伦不类,形式上像微服务,而本质上依然是单体,甚至连单体都不如。这样的改造现... ...查看全部

昨晚睡觉前,顺手撸了几个群聊的聊天记录。发现一个很有意思的名词“分布式单体”,顺藤摸瓜看了一下之前的聊天记录,由于内容骂骂咧咧,我就不贴出来了。大致内容就是某公司在做微服务改造,但改的不伦不类,形式上像微服务,而本质上依然是单体,甚至连单体都不如。微信截图_20210401111022.png

这样的改造现象,其实在国内还是蛮多见的。今天我们就来聊聊这个有趣的话题:分布式单体。各位看官,看看你们公司是不是也犯了这样的错误?

分布式单体为什么不好

先思考一个问题:从单体改造到微服务的时候,你们是不是按这样的步骤来的?

  1. 确定业务领域,拆分存储,定义各微服务的边界

  2. 改造代码逻辑,将原来的内部service调用改成dubbo或feign这样的远程调用

通过这样的改造,我们得到了很多好处,比如:

  1. 代码库分开了,减少了麻烦的解决代码冲突的困扰

  2. CI/CD分开了,每个拆分后的服务都可以独立开发、部署、运行

  3. 数据库分开了,独立运行,不同业务模块不会互相影响

这样一顿操作,我们把一个臃肿的单体应用变成了多个精炼的分布式应用,似乎完美的实现了改造?但这样就实现了微服务的核心目标了吗?继续思考下面的问题:

  1. 代码库是分开了,但每个服务都在独立迭代吗?是不是每个需求都要协调一大堆同步接口?

  2. CI/CD是分开了,但每次发布都是自由的吗?是不是每次功能的发布都拖上了一大推的服务要一起发布?

  3. 数据库是分开了,但似乎有个服务挂了,依然导致很多功能就都不正常了?

看似我们得到了很多好处,但我们的开发效率真的得到了提升吗?虽然我们以前一个单体应用启动要3分钟,现在拆分后,一个项目启动30秒,但每次开发调试要同时开好几个项目同时启动?这样的开发体验真的爽到了吗?

看似完成了微服务改造,实则依然是个单体应用,只是从原本的集中式实现,变成是分布式实现。原来我们只是做了一次无用功,真正的收益微乎其微。

而实际上,这样的改造,除了收益不高之外,还带出了更多的坏处。如果你们公司是这样做的,有没有发现,这样做之后,好像系统故障的频率更高了?稳定性似乎比单体应用还差?(如果没有,那一定要感谢你们的运维团队真的很给力,同时建议把这篇转给运维团队,采访下这样的改造是不是他们变得更累了?!)

为什么这样的改造会导致系统更加不稳定呢?其实道理很简单,原本我们在单体应用中,未拆分的远程调用都是内部调用,这个内部调用所能引发的故障率是微乎其微的,而将这部分内容拆成了远程调用后,每一个调用都增加了网络IO的因素,每一次调用的故障率都增加了。那么系统的整体故障率是随着系统拥有多少同步远程调用的数量增加而增加的。当运维团队与开发水平没有支持好这部分增加的复杂度时,那么改造的系统,必然稳定性会比原来的单体应用更差。

所以,这样改造的结果,不但没有得到很多的收益,反而会带来很多稳定性上的损失。

改造走样的元凶

那么为什么会造成上面所说的问题呢?我觉得主要有两方面:

  1. 领域拆分的不合理,引出了过多的同步远程调用

这个是最根本的问题,也是在改造过程中最常见的。这部分说实话是整个改造过程中最难的,因为需要对业务有非常深入的认识,对系统设计的领域模型、用户行为有足够的理解。在做拆分的时候,尽可能的减少同步远程调用,取而代之的是走消息的异步交互,同时根据业务需要也可以做适当的数据冗余。这样就能保证,每个被拆分后的微服务之间可以获得更低耦合度。

因为更低的耦合度,我们才能在不做任何优化的情况下,获得更少的分布式所带来的稳定性损失。对于后面要将的第2点的工作量也就越少。同时,对于真正的独立开发、部署、运行也成为可能。

  1. 简单粗暴的实现,缺少分布式的保护机制

在很多团队里,因为业务需求多与人员配置少的矛盾之下,开发人员很容易出现对远程调用不做足够的保护机制,比如:接口提供方的限流策略(保护自己不被别人搞死),接口调用方的降级策略(保护业务更高的可用性),接口调用方的熔断策略(保护自己不被别人拖死)。只有认真对待每一个分布式环境下的依赖点,那么才能解决因为分布式改造所牵连出的诸多问题。

但要做好这一点的核心,还是对第一点的把握,只有在领域模型上做更合理的拆分规划,才能支持开发人员做好这个点,不然随意的拆分,一大堆接口调用压给本就压力很大的开发人员,那这部分的开发质量肯定很难保障了,自然而然的系统稳定性就开始随着接口复杂度的增加而不断下降了。最后,开发人员就会开始来我们群里吐槽了…甚至大家也开始怀疑微服务根本带不来效率的提升!

转载于公众号“程序猿DD”


【IT八卦】没有手机的古代人是如何通信?

好玩创意大兴 发表了文章 • 0 个评论 • 140 次浏览 • 2020-12-07 12:00 • 来自相关话题

没有手机,古代人如何通信,我们一起说说关于古代人通讯的那些事今天,小编正躲在空调房里玩着手机,此时异地恋的男友给小编打了一个视频电话。作为一个已经异地谈恋爱两年,有着半年已经没有见到人影在高原服役的的男友的小编当机立断的点开了视频。不过好景并不长,刚腻歪了一会... ...查看全部

没有手机,古代人如何通信,我们一起说说关于古代人通讯的那些事

今天,小编正躲在空调房里玩着手机,此时异地恋的男友给小编打了一个视频电话。作为一个已经异地谈恋爱两年,有着半年已经没有见到人影在高原服役的的男友的小编当机立断的点开了视频。不过好景并不长,刚腻歪了一会儿,视频那头传来了集合的哨子声,小编的男友也只能匆匆挂断了视频集合去了。小编我看了看手机,靠在沙发后面叹了一口气,这时脑海里浮现了这么一个问题:古代人没有手机,没有电子邮箱,没有各种APP,那么他们靠什么通信呢?今天就让我们一起说一说关于古代人通信的那些事儿。

在远古时期,人们的力量与大自然相比是十分弱小的,为了能够活命,为了能够更好的生存,这些远古人经常是一群群的聚集在一起生存,有着自己的地盘,靠采集果实和狩猎为生。每当发现了一些可以食用的果实,或是有毒致命的果实,人们都通过喊的方式来告诉自己部落的同伴一起来采集或是记住下次不要采集这种果实。每次狩猎时,人们都是通过喊叫的方式去恐吓动物,使一些小动物变的胆怯。

以便获取食物来源,或是为了吓走一些想要抢走劳动成果的其他动物。另外当凶猛野兽袭击的时候,人们可以通过喊叫来震慑这些野兽,为自己赢得宝贵的逃跑时间,也可以通过此方式来告诉自己的同伴有危险来临了。喊叫出的声音的大小和长短程度都代表着不同的意思,我们现如今复杂的语言体系也是从当时的喊叫进化过来的,毫无疑问的可以这么说,喊叫是最原始的一种通讯方法了吧。

这种通过喊叫来传递信息的方法至今我们仍在沿用,比如一个人在楼上,另一个人在楼下的时候,交流方式可还得靠喊叫啊,毕竟老祖宗留下来的东西不能丢不是吗?除了光靠喊叫的这种传递信息的办法之外,还有一种很方便的方法就是铛铛裆的敲了。在喊叫之后出现的方式应该是敲敲敲了,用鼓槌击打鼓面,用不同的声响和频率传达不同的意思,也就有了一鼓作气这个成语的由来了,由于怕对方也知道自己敲鼓的所表达的含义。

于是就设计出不同的击打方式。不过小编想了想,好像这种方式我们现在依然在使用。这让小编想起了自己的学生时代了,有时候自习课想要偷懒睡一会儿,又怕班主任的突然袭击,便会跟自己的同桌相约定班主任来了敲几下桌子给自己提个醒。除了铛铛裆的敲的方式之外,还有一种对暗号的通信方式,暗号除了文字,还有吹笛子、弹琴、吹箫各种各样奇怪的方式,这种对暗号的方式经常存在于秘密情报的传递之中。

也经常在武侠电影和武侠电视剧中看到这样的情况,你个普通老百姓可是用不到这种暗号方式,太累了。当然这种通信方式各国部队、间谍机构现在仍在使用。不过小编一些,学生之间好像也会使用这种对暗号的方式诶。还记得小编读大学的时候,觉得食堂的饭菜难以下咽,于是自己买了个锅自己煮饭,但是这可是违纪品,总是怕查寝的,后来寝室里的几位姐妹也纷纷购买了电锅,每天设立一个暗号口令。

一旦门反锁后有人敲门就要对暗号口令,靠着这种方式,小编的锅和自己的其他3位室友的锅安安稳稳的度过了它们的四年大学时光。我们看古装剧的时候是否会注意到这么一个细节,每当皇上在大殿上想要传达什么口信的时候,都会讲口信的内容告诉自己身边的贴身太监,让他把这个口信通过一个个传递到大殿之下。有时候传下去的口信就那么几个字,费事又费力,还浪费口舌。

说实话,小编以前上学的时候老师有时候就喜欢玩传话这个游戏,每次到了最后一个人那里,传的话肯定是变味了,甚至十分的搞笑,真的不知道古代会不会有这种类似的情况发生。除了这两个人肉手段之外,在周幽王时代也出现了烽火狼烟传递消息的方式了。一说起周幽王时代,所有人都会想起周幽王烽火四诸侯只为博得褒姒的微笑,当时为了传递有敌军来犯的消息便会在边境的高墙上设立岗哨。

一旦这些岗哨发现有敌军入侵之后,便会点着烽火台上的燃料,释放出滚滚黑烟,表示有外敌入侵,见状所有的岗哨就一个个的点燃了烽火台上的燃料,信息就这么被传递了。后来人们发现之前说到的这三个传递信息的方式太繁琐,费事又费力,有时候还会发生话被传错了的风险。于是人们开始利用各种各样的动物来传递信息。最早用动物传达信息和书信的人应该是苏武了吧。

他在牧羊的贝加尔湖畔用鸿雁像汉朝传回了所有人被匈奴扣押了的重要的信息。除了鸿雁传书之外,最普遍的还是飞鸽传书了,当然也有人用鹦鹉、狗、青鸟等动物来传递信息的。除了各种各样的动物,古代人还用放飞风筝和孔明灯来传递消息的,更为甚者,还有人将写好的信件放在荷花灯或是竹筒里,让它们顺流而下去传递消息。总是用这些原始的办法传递信息总也不是个事啊。

统一六国之后的秦始皇修建了全国统一的驰道,设立了驿站,专门用来传递官方重要文件和重要信息。此时纸还没有被发明出来,人们把需要传递的信息都写在了竹签上,再把竹签放进竹筒里,两端密封防止被人偷看。或是用木头雕刻两个一模一样的鲤鱼,鲤鱼中间是挖空的竹签的形状,需要传递信息的时候,就把竹签放进鲤鱼的凹槽里,再合上用绳子牢牢的系住。

在打结的地方再沾上黏土,这样再也不怕被偷看了,或许这也是鱼传尺素这个成语的由来吧。到了唐代出现了官邮,类似于我们现在的中国邮政,只不过大部分是为官方服务的,整个官邮是以唐朝首都为中心向周围辐射,每隔30里路就有一个驿站,供人休息换马,除了陆路也发展出了水路驿站,利用河水和船传递信息。到了宋朝出现了普通邮递、快递和加急快递。

元明清三个朝代都是沿用宋朝的模式,中国邮政的雏形就这么出现了。看了古代人通信方式,小编突然觉得自己生活在现代真的很幸运。有手机,有WiFi,有各种聊天APP,若是想要联系,信手沾来,比以前不知道要方便多少倍呢。


手把手教学实现消息通信

IM即时通讯王叫兽 发表了文章 • 2 个评论 • 149 次浏览 • 2020-09-09 10:09 • 来自相关话题

一、背景作为一名 Web 开发者,在日常工作中,经常都会遇到消息通信的场景。比如实现组件间通信、实现插件间通信、实现不同的系统间通信。那么针对这些场景,我们应该怎么实现消息通信呢?本文阿宝哥将带大家一起来学习如何优雅的实现消息通信。好的,接下来我们马上步入正题... ...查看全部

一、背景

作为一名 Web 开发者,在日常工作中,经常都会遇到消息通信的场景。比如实现组件间通信、实现插件间通信、实现不同的系统间通信。那么针对这些场景,我们应该怎么实现消息通信呢?本文阿宝哥将带大家一起来学习如何优雅的实现消息通信。

好的,接下来我们马上步入正题,这里阿宝哥以一个文章订阅的例子来拉开本文的序幕。小秦与小王是阿宝哥的两个好朋友,他们在阿宝哥的 “全栈修仙之路” 博客中发现了 TS 专题文章,刚好他们近期也打算系统地学习 TS,所以他们就开启了 TS 的学习之旅。

时间就这样过了半个月,小秦和小王都陆续找到了阿宝哥,说 “全栈修仙之路” 博客上的 TS 文章都差不多学完了,他们有空的时候都会到 “全栈修仙之路” 博客上查看是否有新发的 TS 文章。他们觉得这样挺麻烦的,看能不能在阿宝哥发完新的 TS 文章之后,主动通知他们。


好友提的建议,阿宝哥怎能拒绝呢?所以阿宝哥分别跟他们说:“我会给博客加个订阅的功能,功能发布后,你填写一下邮箱地址。以后发布新的 TS 文章,系统会及时给你发邮件”。此时新的流程如下图所示:

在阿宝哥的一顿 “操作” 之后,博客的订阅功能上线了,阿宝哥第一时间通知了小秦与小王,让他们填写各自的邮箱。之后,每当阿宝哥发布新的 TS 文章,他们就会收到新的邮件通知了。

阿宝哥是个技术宅,对新的技术也很感兴趣。在遇到 Deno 之后,阿宝哥燃起了学习 Deno 的热情,同时也开启了新的 Deno 专题。在写了几篇 Deno 专题文章之后,两个读者小池和小郭分别联系到我,说他们看到了阿宝哥的 Deno 文章,想跟阿宝哥一起学习 Deno。

在了解他们的情况之后,阿宝哥突然想到了之前小秦与小王提的建议。因此,又是一顿 “操作” 之后,阿宝哥为了博客增加了专题订阅功能。该功能上线之后,阿宝哥及时联系了小池和小郭,邀请他们订阅 Deno 专题。之后小池和小郭也成为了阿宝哥博客的订阅者。现在的流程变成这样:

这个例子看起来很简单,但它背后却与一些设计思想和设计模式相关联。因此,接下来阿宝哥将分析以上三个场景与软件开发中一些设计思想和设计模式的关联性。

二、场景与模式

2.1 消息轮询模式

在第一个场景中,小秦和小王为了能查看阿宝哥新发的 TS 文章,他们需要不断地访问 “全栈修仙之路” 博客:

这个场景跟软件开发过程中的轮询模式类似。早期,很多网站为了实现推送技术,所用的技术都是轮询。轮询是指由浏览器每隔一段时间向服务器发出 HTTP 请求,然后服务器返回最新的数据给客户端。常见的轮询方式分为轮询与长轮询,它们的区别如下图所示:

这种传统的模式带来很明显的缺点,即浏览器需要不断的向服务器发出请求,然而 HTTP 请求与响应可能会包含较长的头部,其中真正有效的数据可能只是很小的一部分,所以这样会消耗很多带宽资源。为了解决上述问题 HTML5 定义了 WebSocket 协议,能更好的节省服务器资源和带宽,并且能够更实时地进行通讯。

WebSocket 是一种网络传输协议,可在单个 TCP 连接上进行全双工通信,位于 OSI 模型的应用层。WebSocket 协议在 2011 年由 IETF 标准化为 RFC 6455,后由 RFC 7936 补充规范。

既然已经提到了 OSI(Open System Interconnection Model)模型,这里阿宝哥来分享一张很生动、很形象描述 OSI 模型的示意图:

(图片来源:https://www.networkingsphere.com/2019/07/what-is-osi-model.html)

WebSocket 使得客户端和服务器之间的数据交换变得更加简单,允许服务端主动向客户端推送数据。在 WebSocket API 中,浏览器和服务器只需要完成一次握手,两者之间就可以创建持久性的连接,并进行双向数据传输。

介绍完轮询和 WebSocket 的相关内容之后,接下来我们来看一下 XHR Polling 与 WebSocket 之间的区别:

对于 XHR Polling 与 WebSocket 来说,它们分别对应了消息通信的两种模式,即 Pull(拉)模式与 Push(推)模式:

场景一我们就介绍到这里,对轮询和 WebSocket 感兴趣的小伙伴可以阅读阿宝哥写的 “你不知道的 WebSocket” 这一篇文章。下面我们来继续分析第二个场景。

2.2 观察者模式

在第二个场景中,为了让小秦和小王能及时收到阿宝哥新发布的 TS 文章,阿宝哥给博客增加了订阅功能。这里假设阿宝哥博客一开始只发布 TS 专题的文章。

针对这个场景,我们可以考虑使用设计模式中观察者模式来实现上述功能。观察者模式,它定义了一种一对多的关系,让多个观察者对象同时监听某一个主题对象,这个主题对象的状态发生变化时就会通知所有的观察者对象,使得它们能够自动更新自己。

在观察者模式中有两个主要角色:Subject(主题)和 Observer(观察者)。

在第二个场景中,Subject(主题)就是阿宝哥的 TS 专题文章,而观察者就是小秦和小王。由于观察者模式支持简单的广播通信,当消息更新时,会自动通知所有的观察者。因此对于第二个场景,我们可以考虑使用观察者设计模式来实现上述的功能。接下来,我们来继续分析第三个场景。

2.3 发布订阅模式

在第三个场景中,为了让小池和小郭能及时收到阿宝哥新发布的 Deno 文章,阿宝哥给博客增加了专题订阅功能。即支持为阿宝哥博客的订阅者分别推送新发布的 TS 或 Deno 文章。

针对这个场景,我们可以考虑使用发布订阅模式来实现上述功能。在软件架构中,发布 — 订阅是一种消息范式,消息的发送者(称为发布者)不会将消息直接发送给特定的接收者(称为订阅者)。而是将发布的消息分为不同的类别,然后分别发送给不同的订阅者。同样的,订阅者可以表达对一个或多个类别的兴趣,只接收感兴趣的消息,无需了解哪些发布者存在。

在发布订阅模式中有三个主要角色:Publisher(发布者)、 Channels(通道)和 Subscriber(订阅者)。

在第三个场景中,Publisher(发布者)是阿宝哥,Channels(通道)中 Topic A 和 Topic B 分别对应于 TS 专题和 Deno 专题,而 Subscriber(订阅者)就是小秦、小王、小池和小郭。好的,了解完发布订阅模式,下面我们来介绍一下它的一些应用场景。

三、发布订阅模式的应用

3.1 前端框架中模块/页面间消息通信

在一些主流的前端框架中,内部也会提供用于模块间或页面间通信的组件。比如在 Vue 框架中,我们可以通过 new Vue() 来创建 EventBus 组件。而在 Ionic 3 中我们可以使用 ionic-angular 模块中的 Events 组件来实现模块间或页面间的消息通信。下面我们来分别介绍在 Vue 和 Ionic 中如何实现模块/页面间的消息通信。

3.1.1 Vue 使用 EventBus 进行消息通信

在 Vue 中我们可以通过创建 EventBus 来实现组件间或模块间的消息通信,使用方式很简单。在下图中包含两个 Vue 组件:Greet 和 Alert 组件。Alert 组件用于显示消息,而 Greet 组件中包含一个按钮,即下图中 ”显示问候消息“ 的按钮。当用户点击按钮时,Greet 组件会通过 EventBus 把消息传递给 Alert 组件,该组件接收到消息后,会调用 alert 方法把收到的消息显示出来。

以上示例对应的代码如下:

main.js

Vue.prototype.$bus = new Vue();

Alert.vue


<script>
export default {
  name: "alert",
  created() {
    // 监听alert:message事件
    this.$bus.$on("alert:message", msg => {
      this.showMessage(msg);
    });
  },
  methods: {
    showMessage(msg) {
      alert(msg);
    },
  },
  beforeDestroy: function() {
    // 组件销毁时,移除alert:message事件监听
    this.$bus.$off("alert:message");
  }
}
</script>

Greet.vue


<template>
  <div>
    <button @click="greet(message)">显示问候信息</button>
  </div>
</template>
 
<script>
export default {
  name: "Greet",
  data() {
    return {
      message: "大家好,我是阿宝哥",
    };
  },
  methods: {
    greet(msg) {
      this.$bus.$emit("alert:message", msg);
    }
  }
};
</script>

3.1.2 Ionic 使用 Events 组件进行消息通信

在 Ionic 3 项目中,要实现页面间消息通信很简单。我们只要通过构造注入的方式注入 ionic-angular 模块中提供的 Events 组件即可。具体的使用示例如下所示:

import { Events } from 'ionic-angular';
 
// first page (publish an event when a user is created)
constructor(public events: Events) {}
createUser(user) {
  console.log('User created!')
  this.events.publish('user:created', user, Date.now());
}
 
 
// second page (listen for the user created event after function is called)
constructor(public events: Events) {
  events.subscribe('user:created', (user, time) => {
    // user and time are the same arguments passed in `events.publish(user, time)`
    console.log('Welcome', user, 'at', time);
  });
}

介绍完发布订阅模式在 Vue 和 Ionic 框架中的应用之后,接下来阿宝哥将介绍该模式在微内核架构中是如何实现插件通信的。

3.2 微内核架构中插件通信

微内核架构(Microkernel Architecture),有时也被称为插件化架构(Plug-in Architecture),是一种面向功能进行拆分的可扩展性架构,通常用于实现基于产品的应用。微内核架构模式允许你将其他应用程序功能作为插件添加到核心应用程序,从而提供可扩展性以及功能分离和隔离。

微内核架构模式包括两种类型的架构组件:核心系统(Core System)和插件模块(Plug-in modules)。应用逻辑被分割为独立的插件模块和核心系统,提供了可扩展性、灵活性、功能隔离和自定义处理逻辑的特性。


对于微内核的核心系统设计来说,它涉及三个关键技术:插件管理、插件连接和插件通信,这里我们重点来分析一下插件通信。

插件通信是指插件间的通信。虽然设计的时候插件间是完全解耦的,但实际业务运行过程中,必然会出现某个业务流程需要多个插件协作,这就要求两个插件间进行通信;由于插件之间没有直接联系,通信必须通过核心系统,因此核心系统需要提供插件通信机制。

这种情况和计算机类似,计算机的 CPU、硬盘、内存、网卡是独立设计的配置,但计算机运行过程中,CPU 和内存、内存和硬盘肯定是有通信的,计算机通过主板上的总线提供了这些组件之间的通信功能。

下面阿宝哥将以基于微内核架构设计的西瓜播放器为例,介绍它的内部是如何提供插件通信机制。在西瓜播放器内部,定义了一个 Player 类来创建播放器实例:


let player = new Player({
  id: 'mse',
  url: '//abc.com/**/*.mp4'
});

Player 类继承于 Proxy 类,而在 Proxy 类内部会通过构造继承的方式继承 EventEmitter 事件派发器:


import EventEmitter from 'event-emitter'
 
class Proxy {
  constructor (options) {
    this._hasStart = false;
    // 省略大部分代码
    EventEmitter(this);
  }
}

所以我们创建的西瓜播放器也是一个事件派发器,利用它就可以实现插件的通信。为了让大家能够更好地理解具体的通信流程,我们以内置的 poster 插件为例,来看一下它内部如何使用事件派发器。

poster 插件用于在播放器播放音视频前显示海报图,该插件的使用方式如下:


new Player({
  el:document.querySelector('#mse'),
  url: 'video_url',
  poster: '//abc.com/**/*.png' // 默认值""
});

poster 插件的对应源码如下:


import Player from '../player'
 
let poster = function () {
  let player = this; 
  let util = Player.util
  let poster = util.createDom('xg-poster', '', {}, 'xgplayer-poster');
  let root = player.root
  if (player.config.poster) {
    poster.style.backgroundImage = `url(${player.config.poster})`
    root.appendChild(poster)
  }
 
  // 监听播放事件,播放时隐藏封面图
  function playFunc () {
    poster.style.display = 'none'
  }
  player.on('play', playFunc)
 
  // 监听销毁事件,执行清理操作
  function destroyFunc () {
    player.off('play', playFunc)
    player.off('destroy', destroyFunc)
  }
  player.once('destroy', destroyFunc)
}
 
Player.install('poster', poster)

(https://github.com/bytedance/xgplayer/blob/master/packages/xgplayer/src/control/poster.js)

通过观察源码可知,在注册 poster 插件时,会把播放器实例注入到插件中。之后,在插件内部会使用 player 这个事件派发器来监听播放器的 play 和 destroy 事件。当 poster 插件监听到播放器的 play 事件之后,就会隐藏海报图。而当 poster 插件监听到播放器的 destroy 事件时,就会执行清理操作,比如移除已绑定的事件。

看到这里我们就已经很清楚了,西瓜播放器内部使用 EventEmitter 来提供插件通信机制,每个插件都会注入 player 这个全局的事件派发器,通过它就可以轻松地实现插件间通信了。

提到 EventEmitter,相信很多小伙伴对它并不会陌生。在 Node.js 中有一个名为 events 的内置模块,通过它我们可以方便地实现一个自定义的事件派发器,比如:


const EventEmitter = require('events');
 
class MyEmitter extends EventEmitter {}
 
const myEmitter = new MyEmitter();
 
myEmitter.on('event', () => {
  console.log('大家好,我是阿宝哥!');
});
 
myEmitter.emit('event');

3.3 基于 Redis 实现不同系统间通信

在前面我们介绍了发布订阅模式在单个系统中的应用。其实,在日常开发过程中,我们也会遇到不同系统间通信的问题。接下来阿宝哥将介绍如何利用 Redis 提供的发布与订阅功能实现系统间的通信,不过在介绍具体应用前,我们得先熟悉一下 Redis 提供的发布与订阅功能。

3.3.1 Redis 发布与订阅功能

Redis 订阅功能

通过 Redis 的 subscribe 命令,我们可以订阅感兴趣的通道,其语法为:SUBSCRIBE channel [channel …]。


➜  ~ redis-cli
127.0.0.1:6379> subscribe deno ts
Reading messages... (press Ctrl-C to quit)
1) "subscribe"
2) "deno"
3) (integer) 1
1) "subscribe"
2) "ts"
3) (integer) 2

在上述命令中,我们通过 subscribe 命令订阅了 deno 和 ts 两个通道。接下来我们新开一个命令行窗口,来测试 Redis 的发布功能。

Redis 发布功能

通过 Redis 的 publish 命令,我们可以为指定的通道发布消息,其语法为:PUBLISH

channel message。
➜  ~ redis-cli
127.0.0.1:6379> publish ts "
pub/sub design mode"

当成功发布消息之后,订阅该通道的客户端就会收到消息,对应的控制台就会输出如下信息:


1) "message"
2) "ts"
3) "pub/sub design mode"

了解完 Redis 的发布与订阅功能,接下来阿宝哥将介绍如何利用 Redis 提供的发布与订阅功能实现不同系统间的通信。

3.3.2 实现不同系统间的通信

这里我们使用 Node.js 的 Express 框架和 redis 模块来快速搭建不同的 Web 应用,首先创建一个新的 Web 项目并安装一下相关的依赖:


$ npm init --yes
$ npm install express redis

接着创建一个发布者应用:

publisher.js


const redis = require("redis");
const express = require("express");
 
const publisher = redis.createClient();
 
const app = express();
 
app.get("/", (req, res) => {
  const article = {
    id: "666",
    name: "TypeScript实战之发布订阅模式",
  };
 
  publisher.publish("ts", JSON.stringify(article));
  res.send("阿宝哥写了一篇TS文章");
});
 
app.listen(3005, () => {
  console.log(`server is listening on PORT 3005`);
});

然后分别创建两个订阅者应用:

subscriber-1.js


const redis = require("redis");
const express = require("express");
 
const subscriber = redis.createClient();
 
const app = express();
 
subscriber.on("message", (channel, message) => {
  console.log("小王收到了阿宝哥的TS文章: " + message);
});
 
subscriber.subscribe("ts");
 
app.get("/", (req, res) => {
  res.send("我是阿宝哥的粉丝,小王");
});
 
app.listen(3006, () => {
  console.log("server is listening to port 3006");
});

subscriber-2.js


const redis = require("redis");
const express = require("express");
 
const subscriber = redis.createClient();
 
// https://dev.to/ganeshmani/implementing-redis-pub-sub-in-node-js-application-12he
const app = express();
 
subscriber.on("message", (channel, message) => {
  console.log("小秦收到了阿宝哥的TS文章: " + message);
});
 
subscriber.subscribe("ts");
 
app.get("/", (req, res) => {
  res.send("我是阿宝哥的粉丝,小秦");
});
 
app.listen(3007, () => {
  console.log("server is listening to port 3007");
});

接着分别启动上面的三个应用,当所有应用都成功启动之后,在浏览器中访问 http://localhost:3005/ 地址,此时上面的两个订阅者应用对应的终端会分别输出以下信息:

subscriber-1.js


server is listening to port 3006
小王收到了阿宝哥的TS文章: {"id":"666","name":"TypeScript实战之发布订阅模式"}

subscriber-2.js


server is listening to port 3007
小秦收到了阿宝哥的TS文章: {"id":"666","name":"TypeScript实战之发布订阅模式"}

以上示例对应的通信流程如下图所示:

到这里发布订阅模式的应用场景,已经介绍完了。最后,阿宝哥来介绍一下如何使用 TS 实现一个支持发布与订阅功能的 EventEmitter 组件。

四、发布订阅模式实战

4.1 定义 EventEmitter 类


type EventHandler = (...args: any[]) => any;
 
class EventEmitter {
  private c = new Map<string, EventHandler[]>();
 
  // 订阅指定的主题
  subscribe(topic: string, ...handlers: EventHandler[]) {
    let topics = this.c.get(topic);
    if (!topics) {
      this.c.set(topic, topics = []);
    }
    topics.push(...handlers);
  }
 
  // 取消订阅指定的主题
  unsubscribe(topic: string, handler?: EventHandler): boolean {
    if (!handler) {
      return this.c.delete(topic);
    }
 
    const topics = this.c.get(topic);
    if (!topics) {
      return false;
    }
    
    const index = topics.indexOf(handler);
 
    if (index < 0) {
      return false;
    }
    topics.splice(index, 1);
    if (topics.length === 0) {
      this.c.delete(topic);
    }
    return true;
  }
 
  // 为指定的主题发布消息
  publish(topic: string, ...args: any[]): any[] | null {
    const topics = this.c.get(topic);
    if (!topics) {
      return null;
    }
    return topics.map(handler => {
      try {
        return handler(...args);
      } catch (e) {
        console.error(e);
        return null;
      }
    });
  }
}

4.2 使用示例


const eventEmitter = new EventEmitter();
eventEmitter.subscribe("ts", (msg) => console.log(`收到订阅的消息:${msg}`) );
 
eventEmitter.publish("ts", "TypeScript发布订阅模式");
eventEmitter.unsubscribe("ts");
eventEmitter.publish("ts", "TypeScript发布订阅模式");

以上代码成功运行之后,控制台会输出以下信息:

收到订阅的消息:TypeScript发布订阅模式

五、参考资源

维基百科 - 发布/订阅

Ionic 3 - Events

implementing-redis-pub-sub-in-node-js-application

原文地址https://blog.csdn.net/qiwoo_weekly/article/details/108250534


WICC 2019:融云首次解密全球通信网底层基础架构

科技创新融云那些事 发表了文章 • 0 个评论 • 316 次浏览 • 2020-06-16 18:34 • 来自相关话题

日前,2019 全球互联网通信云大会(WICC)在上海圆满落幕。作为大会主办方的融云,面对场内外数万开发者,首次对其自建的全球通信网(SD-CAN)的架构进行解密,分享了架构设计背后的故事和演进历程。在连续多年稳居国内即时通讯领域市场占有率第一之时,融云已然将... ...查看全部

日前,2019 全球互联网通信云大会(WICC)在上海圆满落幕。作为大会主办方的融云,面对场内外数万开发者,首次对其自建的全球通信网(SD-CAN)的架构进行解密,分享了架构设计背后的故事和演进历程。

在连续多年稳居国内即时通讯领域市场占有率第一之时,融云已然将目光放在了更广阔的全球市场之上。自 2016 年起,融云跟随中国出海企业进行海外布局,为他们提供安全、可靠的全球通信云服务能力。时至今日,在全球化布局上,融云拥有 3 个数据中心,3000 多个动态加速节点,并自研最优链路调度算法,可以有效解决跨国、跨运营商、大规模用户访问导致的响应慢、丢包高、服务不稳定等诸多痛点。


融云首席架构师李淼演讲
突破代码所无法解决的难题,跨过技术调研与选型瓶颈

融云首席架构师李淼认为:“代码可以解决的问题都不是问题,代码解决不了的问题才是最难的问题”。在李淼眼中,什么是代码解决不了的难题?那就是搭建全球互联的通信云底层基础架构。

早期,融云通过提供 SDK,让开发者更易集成融云的通信云能力到自己的 App 应用中,这是融云将通信云技术普惠给广大开发者的初衷。融云凭借安全、可靠的互联网通信云技术能力,服务的中国企业越来越多,并且随着中国出海企业逐渐布局到了海外市场,为了进一步助力中国企业出海,融云自建全球通信网络的想法应运而生。

融云讲了一个真实案例,曾经有落地韩国的旅游 App 客户向融云反映,自己的用户在韩国、泰国等地常常因连接不畅,导致体验不佳。后来融云在韩国、泰国部署了加速节点,对当地的链路进行加速,解决了这个问题,但由于终端客户分布的随机性很大,当用户漫游到除韩国、泰国以外的海外地区,甚至到北欧等地时,仍然面临连接问题。

解决客户的问题就是融云研发团队的使命,融云全球通信网的构建已经变得刻不容缓。可以说,是客户的海外布局需求让融云打开了建设全球通信网络的大门。

融云全球通信加速网络演变历程

融云对全球通信网络的平台能力定义是:用户能够就近接入、覆盖区域广泛、通信质量稳定、支持动态路径切换。2016 年,融云全球通信加速网络 v1 版本正式上线运行,基本满足了出海客户对于全球通信的需求,并显示出性能优越、资源消耗低、结构简单、运维方便等优势。同时,融云持续在寻找对应区域的服务商上,加大技术和人力的成本投入,进行资源配置的优化和整合。通过对两年的运营数据比对:在没有加速网络的情况下,融云对海外用户整体的连通率大概只有 78% 左右,通过加速网络,融云在全球的用户整体连通率可以达到 99.5% 以上,全球互联互通的成效初显。

但是,v1 版本的全球通信网络同时也面临着多中心重复建设、链路选择不智能、功能相对单一等问题。因此,2018 年融云决定放弃 v1 版本中的架构设计,重新搭建通信云全球互联的底层基础架构,进行 v2 版本迭代。

由于融云全球通信加速网络 v2 版本采用自研的边缘节点,承载了更多的业务数据的处理能力,显示出四大优势:第一,支持多中心接入。在设计时增加了新的路由节点,在整个网络里,可通过边缘节点向路由节点汇聚数据流量,数据可向任意一个数据中心导入;第二,多协议支持。自研的边缘节点,使 v2 版本不仅能支持 HTTP、HTTPS,还能支持 WebSocket、WebSocketS 以及实时音视频 RTC 的信令等更多协议;第三,管控方便。v2 版本可以精确地控制每个客户的流量转向和流量调度;第四,灵活调度。相比于 v1 版本只能通过下发配置的方式进行调度,在 v2 版本可通过管控节点的方式对流量周转进行控制。

优化之路境无止境

5G 正式商用后,融云 SD-CAN 全球通信网络除了承载人与人之间的通信,还将更多地承载人与物、物与物的通信。针对互联网通信请求高并发、小数据包的传输特点,为全球客户提供优质的网络加速服务,这是融云未来所要面临的挑战。

面对挑战,融云希望全球通信网络在边缘计算和去中心化的实时数据交换方面有所突破。首先,在边缘计算方面,由于融云目前很多协议、逻辑、控制都是通过类似模块的方式写成,如果要更新这些,需要重新部署服务来解决。尽管现在可以做到使用户无感、无损地更新迭代,但要降低运营成本,融云要在边缘节点上增加类似 FaaS(Function as a Service)的能力,并通过一些动态语言在边缘结点上实现脚本化的运维操作,通过管控节点下发这些计算能力。

其次,在去中心化的实时数据交换方面。虽然 RTC 本身就是去中心化的实时交换,但是现在的交换数据一般都是音视频,融云后续会建立双端 TCP 连接,通过去中心化的网络,实现两个用户之间的文件传递和数据交互。

结语

融云历经三年的潜心研发,最终构建起安全、可靠的全球互联网通信云网络。在全球通信网络的架构演进之路上,融云始终如一,抱定为客户带来至佳体验的宗旨,在专业化的道路上不懈探索。随着 5G 通信和物联网技术的全面覆盖,融云势必将通过 SD-CAN 全球通信网络为出海开发者和企业提供更为强劲的服务能力。

【融云观察】央媒联手互联网平台试水短视频:海外网微叭合讲华人故事

科技创新融云那些事 发表了文章 • 0 个评论 • 98 次浏览 • 2020-06-16 18:34 • 来自相关话题

随着新媒体行业和技术的高速发展,以短视频为代表的新型传播方式与新兴业态方兴未艾。12月19日,人民日报海外网在京举办“全球华人生活短视频大赛”颁奖盛典,活动在微叭等众多互联网平台的鼎力支持下成绩斐然,全球网友踊跃参与,自8月1日启动到10月15日征集结束,陆续... ...查看全部

随着新媒体行业和技术的高速发展,以短视频为代表的新型传播方式与新兴业态方兴未艾。12月19日,人民日报海外网在京举办“全球华人生活短视频大赛”颁奖盛典,活动在微叭等众多互联网平台的鼎力支持下成绩斐然,全球网友踊跃参与,自8月1日启动到10月15日征集结束,陆续收到来自世界各地网友的投稿超10万件,总观看量逾6亿。


全球华人生活短视频大赛颁奖盛典
“全球华人生活短视频大赛”面向全世界各地的华侨华人,以“衣食住行”的变化为立足点,以短视频的形式展现当下全球华人多元丰富的生存状况与精神面貌。作为当前全网最大的语音短视频互娱社区之一,小桨科技积极参与到本次大赛中,并在其短视频平台“微叭”上特设活动分赛区,邀请海外用户参与短视频征集活动,充分调动全球华人网民的参与积极性,同时微叭还大力扶持优质视频参赛者,让优质创作者获得更多的曝光量。在此次颁奖盛典上,凭借着出色的活动组织能力和平台上的海量优质视频,小桨科技(微叭)也荣获了主办方颁发的最佳合作伙伴奖。

在这次“全球华人生活短视频大赛”活动中,人民日报海外网和微叭的合作,是中央级媒体和互联网视频平台联合的一次有益尝试,双方发挥各自的长处,从质量、内容、创新、技术等方面,提升了参赛短视频的可视性,也让网友们亲身感受到了祖国成立这70年来生活中一点一滴的变化。

活动开始至今,微叭平台上“全球华人生活短视频大赛”活动总曝光已超过1亿人次,无论是国内用户还是海外的华人华侨,都可以在短视频下方通过语音、文字多种形式随时聊天互动,对于此次征集活动中的优秀短视频,用户还可以点赞送花来表达对作品的支持。而不得不提的是,作为微叭的即时通讯云服务商,融云以稳定的技术及服务在背后默默地全程支持了此次活动。

一直以来,融云依托先进的技术实力,为开发者和企业提供安全、可靠的即时通讯及实时音视频通信云服务,是业界内唯一一家承诺在海量用户并发的情况下消息不丢、不重、不乱序的企业。根据第三方分析机构艾瑞发布的2019《全球互联网通信云行业研究报告》显示,融云在即时通讯市场占有率稳居第一。


微叭——边看边聊
选择融云的另一个重要原因则是微叭拥有着大量的海外用户。微叭表示,融云是行业内唯一一家在海外设立数据中心的互联网通信云服务商,在实际测试中,微叭业务使用融云后,通信连通率、消息到达率等重要数值的测试结果得到明显提升。

以此次“全球华人生活短视频大赛”为例,活动参与者遍布全球上百个国家和地区,融云通过多海外数据中心和遍布全球的优质接入点,结合融云自研的最优链路调度算法,解决因跨国、跨运营商、大规模用户访问而导致的响应慢、丢包高、服务不稳定等问题,为此次“全球华人生活短视频大赛”提供了安全、稳定、可靠的互联网通信云服务,助力活动平稳顺利地进行。

随着全球化市场的拓展,越来越多的中国企业像微叭一样正在凭借出色的综合实力逐步走向世界舞台,在世界经济和文化的交流中扮演重要角色。作为全球领先的互联网通信云服务商,融云将不断提升自身技术实力和服务质量,持续以通信技术底层能力赋能所有中国出海企业,降低产品的研发和运维成本,以全球化通信能力为中国企业的海外发展保驾护航。

探解融云云服务实力的背后:对技术与服务的精髓把握

科技创新融云那些事 发表了文章 • 0 个评论 • 81 次浏览 • 2020-06-16 18:31 • 来自相关话题

2019年底,首届全球互联网通信云(WICC)大会成功举办,让主办方融云这个名字格外亮眼。融云已经连续多年在IM即时通讯市场稳居第一,截止目前,用户覆盖全球233个国家和地区,日活超7千万,SDK触达用户42亿,日均消息量150亿。即在全国的手机用户中,平均每... ...查看全部

2019年底,首届全球互联网通信云(WICC)大会成功举办,让主办方融云这个名字格外亮眼。融云已经连续多年在IM即时通讯市场稳居第一,截止目前,用户覆盖全球233个国家和地区,日活超7千万,SDK触达用户42亿,日均消息量150亿。即在全国的手机用户中,平均每个手机中至少有5款App的底层通信能力是由融云赋能。融云已跃升为继微信、QQ之后的我国第三大通信平台,而作为PaaS服务,融云则稳居互联网通信云赛道第一,因此融云对通信云服务的发展趋势以及自身未来走向,成为业界关注的焦点。

通信云服务产业的发展趋势

在信息技术的驱动下,通信的形式、场景一直在持续迭代。现今,移动互联网各应用中的IM和实时音视频通话,企业级场景中企业内外部沟通都需要通信云服务来完成。智能硬件场景中,智能对讲机、执法记录仪以及各种智能终端的人与物、物与物的数据传输能力,实现不同设备之间的联动控制,都有赖于高品质的通信云服务。

未来,通信云产业发展有两个重要方向值得关注。首先是服务的稳定性。5G带来信息交互的高频化和TB量级的通信需求,能稳定提供亿级通信能力的通信云厂商,在市场中显得尤为重要。消息高并发呈常态,通信质量的稳定性和可靠性届时是检验通信云厂商的试金石。

其次是全球布局。随着一带一路的国家战略深化推进,中国企业面临着全球化的机遇与挑战。为这些出海企业提供云服务的厂商,未来重要的发展就是把自己的云服务能力扩展到全球。拥有全球通信网的融云即是这方面的杰出代表,融云为满足出海企业高质量的通信需求,2016年开始搭建SD-CAN全球通信加速网,并自研最优链路调度算法,能够为出海客户提供包括亚太、中东、非洲等新兴市场地区的网络质量的优化,完成了全球化的战略布局。

这两个产业发展趋势让我们看到,拥有亿级通信服务能力、且全球布局的通信云厂商价值凸显。

做好通信云服务核心是技术,本质是服务

拥有亿级通信服务能力、且全球布局的通信云厂商融云是如何做好通信云服务的?融云CTO杨攀认为核心是技术,本质是服务。崇尚技术,追求服务,是融云认为做好通信云的根本所在。

好的核心技术标准是什么?它应该是不断满足客户日益复杂的产品需求,不断进化的架构支持更高的海量并发场景,以及不断追求性能的极致体验。成立5年来,融云的SDK接口数量从279个增长到597个,服务端的API接口数量从36个增长到107个,开发者后台设置从13个增长至83个参数选项,极大地满足了客户对产品功能的需求。此外,融云对性能的极致追求,使消息的接收速度提升了30倍,启动速度提升了5倍,智能设备能耗实现了3倍的优化。融云不仅对性能不断加以优化,在服务端,还可按照客户的要求把上行和下行数据进行分离,以实现高并发的稳定性服务。


融云产品技术云图
通过融云的产品技术云图不难看出,融云为各种场景提供了大量的产品和技术能力,以满足各行业的客户需求。从最底层的数据中心和全球架构的加速网络,到开放的API接口和各种SDK插件,客户可直接应用于自身垂直场景的构建。融云还拥有全终端的平台覆盖能力,除了支持移动平台,还有Web、Linux等各种混合开发的框架。5G时代,向客户输送覆盖全球亿级并发的、高品质的通信服务能力是融云不懈的追求。

融云CTO杨攀同时认为做好通信云,本质在服务。融云是业内首家发布“云服务”体系的PaaS厂商,五大服务从稳定性、可靠性、安全性、个性化、先进性等多维度为客户提供贯穿于客户全生命周期的管家式贴身服务。在服务逻辑上,融云完成了从被动服务向主动服务的升级,从接受客户提需求到主动和客户探讨需求的转换。之前,故障是由客户报知,现在是主动进行故障报警,甚至通过数据质量驱动的方式把故障消灭于萌芽。融云在服务中更加注重细节,除了原有的工单模式,还提供IM北极星作为排查工具,直接判断客户的各种问题。

此外,对于通信业务,服务的可靠性是重中之重。每个通信云厂商都应追求一份业务三份投入,一份基础设施投入,一份冗余备份投入,一份质量数据投入。融云认为,基础设施投入增长率应远高于业务发展(流量)的增长率;CDN加速多备份、云存储多备份、可用区多备份、国际链路多备份是冗余备份中必不可少的投入;基于应用提供业务核心数据,追求对质量数据的投入,通信云厂商才能助力客户持续且精准运营。

未来,融云把发展交给开发者

未来,融云要把自己的发展交给开发者,向开发者开放,实现与开发者共创共赢。对此,融云将做好两个开放。首先,融云要将开发文档开放,与开发者共创共建。其次,融云将开放一个频道,对开发集成过程中的共同需求投票,针对有价值的需求和创意,联手广大开发者共创,共同把融云的平台做得更好。去年,融云已经进行了初步的尝试与实践。比如,在极客行活动中,让开发者从零开始集成产品功能,对于所遇问题,或文档、设计等理念不清晰的地方进行全程记录,以对应产品迭代和功能演进。

此外,对初接触通信云的开发者来说,融云现有500多个SDK接口,杨攀认为过于复杂了,未来,要把场景化的应用做深做透,做好场景化代码的片段示例和场景化教学小视频,提供开放调试工具集合,比如打包几十个SDK接口适用一个场景,甚至把Demo都集成好,追求在开发便捷性上的提升。

结语

做好技术与服务是企业的发展之道,这或许被看作是老生常谈,但如何让这两个方面真正相得益彰,则决定了企业能够获得多少续航的动力和上升的空间,也决定了企业发展的想象空间。而融云的做法,恰恰展示的就是对技术与服务的参悟能力和深入挖掘能力,这成就了今天的融云。融云的未来更开放、更贴近开发者,要与开发者共创共赢,赋能更多行业与场景,让我们期待拥有技术与服务双核实力的融云,为互联网通信云市场的发展注入全新动力。

【融云分析】H.264视频编码的基本原理和过程

科技创新融云那些事 发表了文章 • 1 个评论 • 72 次浏览 • 2020-06-16 18:25 • 来自相关话题

前言:在音视频通信中,音视频的数据压缩是有效降低带宽的主要方法;其中,视频占用了更高比例的带宽,视频压缩更为重要。如果不压缩,一副 RGB 图像,按照 800 x 600 的分辨率, 每秒 25 帧的帧率, 那么:每秒的数据量 = 800 x 600 x 3 ... ...查看全部

前言:
在音视频通信中,音视频的数据压缩是有效降低带宽的主要方法;其中,视频占用了更高比例的带宽,视频压缩更为重要。

如果不压缩,一副 RGB 图像,按照 800 x 600 的分辨率, 每秒 25 帧的帧率, 那么:每秒的数据量 = 800 x 600 x 3 x 25 x 8 ( bit )。

H.264 压缩后,平均码率可以减少 20 倍;如果使用动态码率,对于某些简单场景的监控等,可以更大的压缩视频,同时保证视频质量。

视频压缩工具有很多,H.263、Mpeg-4、 VP8、VP9、 H.264 等等。目前最常见和最常用的视频压缩算法是 H.264,基于 H.264 比较流行的开源工具有 X264、OpenH264 以及 FFmpeg (内部集成 x264 和 OpenH264 ), 解码工具大多用 FFmpeg 实现。

视频编码的基本要求:

1:有足够的压缩比,能将压缩结果控制在一个范围内;

2:压缩后的视频,解压后要保证一定的视频质量。

H.264 的优势有什么呢?

1:很好的网络亲和性,更适合复杂网络传输;

2:更高的视频压缩比,在同等视频质量下;大约是H.263,Mpeg-4 的 2 倍;

3:目前移动端已经广泛支持 H.264 硬件编解码,效率和速度更快。

H.264/AVC 的常用概念:
帧和场:

视频的一帧,可以看做是一副完整的图像, 一帧视频可以分成两个隔行的场,通常叫做 “顶场” 和 “底场”。

为什么会有“场”的概念?

因为早期在电子显像管电视机中,图像是由电子逐行扫描显示的。为了更好的显示动态图像,就会先隔行扫描显示图像的 “顶场”,然后在扫描显示图像的“底场”。这样运动图像的显示效果会更好。

但是隔行扫描的实际效果是模糊了图像。目前随着科技的发展,在视频编码中,通常直接用一副完整的图像。

档次和级:

(1)基本档次:基于 I 帧 和 P 帧 ,支持 CAVLC 编码;适合视频会议,视频电话,实时视频流等。

(2)主要档次:支持各行视频,增加 B 帧编码,支持 CABAC 编码。主要用于视频存储等。

(3)扩展档次:支持流之间的切换,改进误码性能;主要用于视频点播等。


YUV 4:2:0 图像:
一帧没有经过压缩的位图数据一般保存的数据是每个像素用 RGB 表示,每个颜色分别用一个字节表示。

我们这里常用的 YUV 图像指的是 YUV 4:2:0 图像,用四个亮度 Y 分量对应一对 UV 色度分量。


RGB 转换 YUV 4:2:0 的公式:

Y = 0.299R + 0.587G + 0.114*B;

U = -0.169R – 0.331G + 0.5 *B ;

V = 0.5 R – 0.419G – 0.081*B;

由此可见,RGB 图像转到 YUV 4:2:0 图像的这一过程中是有图像质量损失的。

为什么用 YUV 4:2:0 ?

首先, YUV 4:2:0 比 RGB 图像小一半。每个像素为 12 bit。

其次,早期的电视分为黑白电视和彩色电视,如果是黑白电视,那么直接播放 Y 亮度分量。

如果是彩色电视,那么就可以全部直接播放。

视频编码系统的基本结构:

视频的压缩原理与过程:
1:我们先看一幅图像:(图1)


这幅图像中,大部分是绿色,如果仅仅将小球保留,绿色用一个变量和坐标表示,那么这幅图像的信息就可以很好的减少,也可以根据变量和坐标恢复图像。

2:再看一副图像:(图2)


这幅图像的小球,向右上角移动了一格,其它内容和信息都与上图基本一致;

如果已经有了“图1”, 那么只需要将“图2”与“图1”中的不同信息保存下来,那么就可以根据“差别信息”参考“图1” 来恢复显示“图2” 了。

这就是视频压缩的本质和原理:

空域压缩;

时域压缩。

GOP:
我们可以按照一定的图像数量进行编码,如 25 帧图像为一组,每组的第一帧图像通过帧内编码,我们称之为 IDR 帧,其它图像参考其它图像的信息进行编码,我们称之为 P 帧 / B 帧,那么可以将这一组数据一个 GOP。

如果一个 GOP 的第一帧图像 IDR 帧丢失或者损坏,那么这个 GOP 后面的所有视频数据将会解码错误。只有等到下一个 GOP,当解码器遇到 IDR 帧会即时刷新图像,清空参考图像列表。


宏块:
H.264 编码的最小单位,我们可以看做是一个宏块,就是一个 16 x 16 的图像区域,也可以划分的更小,如 8 x 8。

什么是预测编码?
在视频压缩中,就是将预测值与实际值作差,然后再次压缩。

帧内预测:

IDR帧 ,I 帧:
帧内编码就是当前帧不参考其它帧,可以独立解码的一种编码方式;

可以简单的想象为,一副 BMP 图像压缩为一副 JPEG 图像;

通常帧内编码的图像,我们称之为 I 帧 intra picture,就是不需要参考其它图像,可以自己独立解码出图像的视频数据帧。

需要注意的是:IDR 帧是 I 帧,但是 I 帧不是 IDR 帧。IDR 帧是一个 GOP 的第一帧,GOP 中间有可能出现 I 帧,后面的帧有可能参考 I 帧之前的视频帧,但是不可能越过 IDR帧。一般 IDR 帧 前面还有 SPS 和 PPS 信息。

在帧内编码中,宏块最多可以有九种预测模式,我们可以找到与原图最相近的预测图像:


帧间预测:
帧间预测技术分为 B 帧预测和 P 帧预测。

B 帧预测 – 双向预测:
主要是参考之前编码的帧和之后编码的帧;

B 帧的数据量更小,但是 B 帧由于需要参考后续帧,那么就会引入延时;

同时用到更多的计算开销;

B 帧不会作为参考帧,所以,丢弃 B 帧也不会引起花屏;如上面的“GOP 图“。

P 帧预测 – 单向预测:
主要参考之前编码过的视频帧;

后面为了清晰说明原理,以 BaseLine 为示例基础,仅包含 I 帧 和 P 帧;

运动矢量:
如:“图1”的小球位置坐标假设为(x0,y0), “图2”的小球位置坐标假设为(x1,y1),那么小球的运动矢量就是(x1 – x0,y1 – y0);

运动估计:
得到运动矢量的过程就是运动估计;


将预测数据和实际数据相减,去掉时域上的数据冗余,就得到了预测的“残差”数据,也就是补偿数据;

解码视频数据,可以根据补偿数据,运动矢量和参考图像恢复出当前图像。

这一步极大的减少了时间域上的图像冗余数据。

DCT – 离散余弦变化 :
这是一个复杂的数学名词,简单描述,就是去除像素间的相关性;

目的当然是进一步压缩数据。

举个例子:


更多的情况可能是图中情况,即便是这样,有效数据也更好的减少了,多了很多 “0” :


量化:
量化过程在不降低视觉效果的前提下减少图像的编码长度,减少图像信息中视觉恢复中不必要的信息。

量化结果,实际上是由量化步长决定的 (QStep),量化步长越小,图像的细节信息保留的越多,码率越高,图像质量越高。反之,量化步长值越大,图像质量越差。

量化是有损压缩,这一步的图像质量有一定的损失。但是前提是不影响正常的视觉和图像质量。

zig-zag 扫描 ,也有人称之为”锯齿扫描” :


zig-zag 扫描和 FFmpeg 官方标志

游程编码 – (RLC, Run Length Coding):
又称“运行长度编码”或“行程编码”,是一种统计编码,是一种无损压缩的编码方式。

其实锯齿扫描和游程编码可以看做是一体的。

游程编码进一步压缩保存了有效的保存扫描数据。

熵编码:
利用信源的统计特性进行码率压缩的编码称之为“熵编码”,也叫统计编码。

从名称来看,还是要压缩数据;这一步是无损压缩。基本原理就是给高频率数据短码,低频率数据长码。

从定义来看,就是指定一组数据中,根据数据出现概率来编码的一种方式。

在 H.264 中,也就是之前提到过的 CABAC 编码 和 CAVLC 编码。


本文图片部分主要来自于“百度图库”和《新一代视频编码压缩标准》。

融云 CTO 杨攀:出海社交娱乐项目的通信技术应用指南

科技创新融云那些事 发表了文章 • 0 个评论 • 83 次浏览 • 2020-06-16 18:10 • 来自相关话题

近日,由白鲸出海主办的《出海东南亚 释放娱乐新势能》线上分享会开启,邀请融云、Akamai、HAGO、AppsFlyer 等企业负责人和行业专家,围绕着泛娱乐和游戏行业所关注的出海话题进行研讨。在分享会上,融云联合创始人兼 CTO 杨攀重点剖析了目前东南亚出海... ...查看全部

近日,由白鲸出海主办的《出海东南亚 释放娱乐新势能》线上分享会开启,邀请融云、Akamai、HAGO、AppsFlyer 等企业负责人和行业专家,围绕着泛娱乐和游戏行业所关注的出海话题进行研讨。在分享会上,融云联合创始人兼 CTO 杨攀重点剖析了目前东南亚出海市场趋势,并就出海项目中的通信技术应用给出了自己的观点。

出海聚焦6大领域 社交成为基础诉求

在分享中,杨攀指出,随着国内竞争的加剧和中国企业在海外逐渐形成生态体系后,越来越多的企业开始将国内流行的业务模式带到海外。特别是东南亚地区,得益于区域地理位置的优势,以及在文化、历史及宗教方面与中国的渊源,这一地区的用户习惯与中国更为接近,也成为了出海企业的重心。

杨攀表示,目前在东南亚市场,中国出海产品普遍集中在社交、电商、金融、游戏、工具和内容这 6 大领域,且应用社交化的趋势非常明显,社交不再单纯是某一款通信应用,而是每一款应用中都带有社交属性。


“目前的应用基本上都是需要注册使用的,用户自带身份就天然的需要进行沟通,无论是平台运营者与用户,还是用户与用户之间,沟通是一个基础的诉求”,杨攀认为,即使是对于看似不需要社交能力的工具类应用而言,引入社交属性,可以使应用无论是活跃、留存还是用户的召回上,都可以大幅增强用户黏性。

关于疫情对全球社交带来的影响

根据融云平台数据来看,在疫情的影响下,全球线上社交的整体业务量猛增,其中,原本在线上拥有自传播能力的社交平台或应用,在其热门话题或活跃 KOL 的引导助力下,业务量保持着稳定增长。但值得关注的是,对于部分产品,特别是仍处于初创期的产品,会依赖于线下推广和线上流量购买,在无法进行线下推广和市场投入趋于保守的现状态下,很难获得业务量的增长。


同时可以看到,受疫情的影响,大量的办公业务和教育机构也从线下搬到了线上。受此影响,融云平台每日的消息量相较于 2019 年提升了 3 倍以上,单日峰值消息量突破千亿条。同时实时音视频单月使用分钟数也较 2019 年平均值增长了 4 倍以上。

典型社交通信场景分析

目前各类社交形态所使用的主要通信服务包含了 IM 聊天、语音沟通、视频沟通和直播互动等。杨攀将社交通信场景概况为两大类,一类是以 IM 功能为主的私密社交、兴趣社群、直播互动场景,另一类则是以 RTC 能力为主的音视频直播、音视频通话等场景。


出海企业可以根据产品逻辑和场景需求,选择适合的互联网通信能力来构建自己的产品业务。但通信云 PaaS 服务不同于标准化的 SaaS 产品,杨攀表示,“通信业务与产品业务逻辑是紧密结合的,每家的产品都有自己的特点,所以在应用内构建通信能力的过程中,产品架构的设计以及如何用融云 SDK 接口组合成开发者想实现的功能和服务,这都是非常依赖于实践经验的。”对此,融云提供了业务和技术解决方案的咨询服务,针对客户的业务场景诉求,融云产品技术专家可量身定制产品解决方案,解决架构性能及技术实现问题。

融云的出海全球化服务

显然,东南亚地区已成为中国企业出海的重点市场,融云多年前即在新加坡建立了海外物理数据中心,成为了国内唯一一家在海外建有数据中心的通信云厂商。以新加坡为中心,辐射整个东南亚地区及邻近的南亚、澳洲等市场,让融云的客户进入印尼、马来西亚、越南等国家和地区,均可以获得业界高质量的通信服务。

“物理形式的数据中心,比任何形式的网络优化都要来的有效果,目前融云在边缘节点做到 2 跳,核心节点做到 1 跳,就可以连接到融云的数据中心。”杨攀表示,基于出海客户的真实诉求,融云自建了全球通信网(SD-CAN),依托海外数据中心,通过 SD-CAN 遍布全球的优质接入点,结合融云自研的最优链路调度算法,解决服务响应慢、服务不稳定等问题。


融云全球通信云服务
“IM 是一个中心化的服务,可以通过融云的海外数据中心进行消息的传递,但在 RTC 方面,融云是去中心化的。”杨攀表示 IM 和 RTC 完全是两个业务逻辑,他举例称,融云在全球均布有核心节点,比如在印度有两个用户进行音视频通话,不需要经过数据中心,只需要通过融云位于孟买的核心节点,即可实现实时互动交流。目前,融云在东南亚及南亚市场可以做到端到端延时小于 300ms,保障用户之间延迟无感知的实时互动。

从 2016 年开始服务出海客户至今,融云业务已全面覆盖全球的 233 个国家和地区,在欧美、中东、东南亚及非洲等地均拥有大量的客户,服务于 StarMaker、小象直播、Opera、Razorpay、Castbox、Lispon 等众多知名的出海应用。杨攀表示,一方面融云会继续打磨自身的产品技术,优化全球通信网络,另一方面不断提升开发者服务水平,通过为开发者提供北极星(质量问题排查)、业务数据监控等服务,让开发者可以快速定位排查问题,监测通信质量,进而不断优化产品业务,最终为用户带来更稳定流畅的通信体验。

艾瑞报告:通信云三大应用场景助力5G时代万物互联

科技创新融云那些事 发表了文章 • 0 个评论 • 75 次浏览 • 2020-06-16 18:10 • 来自相关话题

“未来在每个互联网、企业级应用、智能硬件设备上都有望看到通信云的身影”,当5G时代到来,各类数字信息建设将驶入新的快车道,通信云的价值也将日渐突显,成为在每个行业发展中“无处不在”的底层基础技术。近期艾瑞发布的《2019年全球互联网通信云行业研究报告》认为,通... ...查看全部

“未来在每个互联网、企业级应用、智能硬件设备上都有望看到通信云的身影”,当5G时代到来,各类数字信息建设将驶入新的快车道,通信云的价值也将日渐突显,成为在每个行业发展中“无处不在”的底层基础技术。

近期艾瑞发布的《2019年全球互联网通信云行业研究报告》认为,通信云已进入2.0阶段,完成从传统通信向提供“IM+实时音视频”整合通信能力的“互联网通信云”的迭代。随着应用场景从互联网应用、企业级应用向智能硬件的突破性拓展,通信云将向3.0时代进一步升级。在三大应用场景与各行业融合发展带来的乘法效应下,5G时代的通信云有望迎来发展的黄金期。

最广泛的应用场景:互联网应用

——互联网通信云开启互联网应用的社交突破口

互联网应用是互联网通信云最广泛应用的场景,通信云已经落地于社交、直播、教育、游戏、电商、生活等各个领域,可以帮助各类互联网应用的开发者快速获得IM和实时音视频能力,实现应用内社交、音视频通话、直播互动等不同场景下的沟通,为互联网应用带来多层面的价值。

图片10

一、构建与用户沟通的桥梁,增强用户与平台的互动性。

互联网通信云是互联网应用构筑用户沟通网络的基础,可以让平台服务从以往图文、视频、音频等单一的形式向问答、社群、直播等进行延展,强化平台的粘性。例如在在线教育领域,互联网通信云厂商融云助力新东方、韦博英语在移动端打造班级群聊,同班学员间可进行在线即时交流,让学习不再孤单;在互联网金融领域,通信云可以帮助金融机构在公众服务平台上构建“专家在线直播互动”、“客服沟通”等场景,通过聊天室管理、用户管理、消息管理、聊天互动等多种功能的支持,为金融机构带来耳目一新的在线互动体验。

二、助力企业通过打开社交突破口,探寻商业创新之道。

互联网通信云通过提供IM+实时音视频的整合通信能力,可以助力互联网应用更好的进行创新,如去年以来一些社交性应用便借助通信云的实时语音技术打造“声音交友”场景;通过在线k歌、排麦领唱等方式,构造游戏化音乐社交场景。通信云还可以帮助不同行业构建以兴趣为纽带的垂直化社交,如近期国内发布的“移动电影院V2.0”产品便借助IM和实时音视频技术,开启了“观影社交”模式的探索,为社交领域的后入者提供了很好的思路。

三、与更多新技术融合,有望产生“杀手级”颠覆性应用。

5G网络具有超宽带、超高速度、超低延时的特点,5G时代的互联网通信云与AR、VR等新技术的融合,将可以助力互联网应用为用户带来视觉、听觉、触觉上的全新互动体验,探索新的视频社交、VR社交场景,将产生更多“杀手级”颠覆性的互联网应用,更有望开启新的互联网时代。

深具潜力的应用场景:企业级应用

——互联网通信云担当企业内外部和业务系统的连接器

为企业客户提供通信个性化解决方案,是互联网通信云现阶段非常具有潜力的发展方向。随着企业对数字化办公的需求越来越强烈,使用个人通讯软件存在敏感信息外泄的隐患,搭建一整套企业内部的通信系统显得尤为重要,覆盖全终端、多渠道的互联网通信云已然成为企业的首选。融云面向政务机构、中大型企业提供完整企业通信解决方案——融云RCE,可实现“连接内部、连接外部、连接业务、跨国沟通”四大类场景,并满足各行业大中型企业“安全、可定制”的个性化需求。

图片11

一、通过“内外连接”,企业将可以迅速建立与内部、外部连接的通信网络,有效促进企业沟通效率的提升。

在“连接内部”上,互联网通信云可帮助企业打造安全、可靠的私有版通讯工具,通过对客户端、链路端、服务端、运维端的安全防护,从根源上解决用户通信安全的核心问题。在“连接外部”上,互联网通信云可以帮助企业实现与用户、企业与上下游厂商的场景化沟通,如在金融领域,可帮助金融机构实现销售过程的“双录”,规范金融销售行为,并构建VIP客户音视频客服等场景,为客户体验提升提供支持;在房产领域,通信云可以帮助房产机构建立“视频看房”,让客户通过远程高清画面即可了解房源的真实状态,帮助销售提升成交率。

二、通过“连接业务”,推动企业信息化系统的融合化。

通过企业IM与OA、ERP、CRM等业务系统无缝对接,互联网通信云可成为企业内外部和业务系统的连接器,促进企业通信软件与企业内部业务、企业内部信息化应用走向融合,最终整合成覆盖全终端、多渠道的一整套系统。

三、通过“跨国沟通”,帮助企业快速实现全球化运营。

互联网通信云将彻底改变传统通信受区域、运营商限制的局限性,通过构建覆盖全球的通信网络,实现无时间与地域限制、成本更加低廉的全球化沟通,降低通信方式给企业全球运营带来的风险和管理的复杂性,帮助企业更快速完成向“全球化运营”的高质蜕变,成为真正意义上的“跨国企业”。

突破性的应用场景:智能硬件

——互联网通信云赋能智能硬件构建万物互联时代

5G将移动互联网扩展到物联网领域,物联网将驱动智能硬件成为互联网通信云新兴的应用场景。艾瑞报告指出,当与物(设备)相关的信息传递被纳入到通信云的范畴,通信云的应用场景将实现延展,不仅可实现“人与人的沟通”,更可实现“人与物的沟通、物与物的沟通”,通信云也将从2.0阶段迈向3.0阶段。

图片12

互联网通信云对于智能硬件的价值主要体现在,能够实现设备与用户之间、设备与设备之间数据通信能力,方便开发者和企业客户开展物联网创新性业务。目前在TO B领域,互联网通信云可为智能楼宇、智能交通、智能制造的发展提供支持,推动传统通信设备升级为互联网通信,加速移动智能设备配送调度、工业自动化等新兴业务实现快速、低成本的设备间通信;在TO C领域,互联网通信云可为智能手表、智能音箱、智能机器人等个人消费智能硬件,实现不同产品之间的联动控制。

国内通信云厂商已经在智能硬件领域展开了技术落地的相关实践,例如融云等厂商推出了智能穿戴设备音视频解决方案,可以为手表、眼镜、执法记录仪等智能设备提供音视频解决方案,满足远程监护、维修、执法等场景的应用需要,实现无缝的沟通与协作。

互联网通信云的三大场景方向在各个行业进行发酵、裂变,对于全球通信将产生全面的重塑效应:在5G开启的万物智联世界里,帮助各行业全面构建四通八达的“枢纽”与“管道”,以全新的通信方式为全球经济增长带来新的活力。随着中国通信云厂商已成为2.0阶段的“全球互联网通信云服务商”,可以提供覆盖三大应用场景的通信云服务,中国将成为互联网通信云发展中屹立前沿的佼佼者,推动新时代全球通信方式变革与产业创新。

融云观察:快速洞悉伊利立体化协同时代背后的通信奥秘

科技创新融云那些事 发表了文章 • 0 个评论 • 126 次浏览 • 2020-06-16 18:09 • 来自相关话题

2017年乳制品消费总量已达到2691.66万吨,人均消费量将达到20.83千克,国人持续增加的乳制品需求使行业发展和竞争并存。借助移动信息化手段增强竞争力,逐渐成为乳制品企业的普遍选择,通过互联网通信云技术与行业特征的有机融合,将对行业内各企业的研发、生产、... ...查看全部

2017年乳制品消费总量已达到2691.66万吨,人均消费量将达到20.83千克,国人持续增加的乳制品需求使行业发展和竞争并存。借助移动信息化手段增强竞争力,逐渐成为乳制品企业的普遍选择,通过互联网通信云技术与行业特征的有机融合,将对行业内各企业的研发、生产、管理和服务等各环节带来深刻变革。

就全国乳制品企业来说,当前信息化建设的路任重而道远。信息孤岛现象比较普遍、数据无法充分共享、信息的价值不能完全发掘、全球通信需求难以满足,加之系统的灵活性、扩展性及兼容性欠佳,都会导致企业无法对业务的快速变化进行及时响应。

作为国内乳制品行业的领头羊,内蒙古伊利实业集团股份有限公司(以下简称“伊利集团”)走在了移动信息化建设的前沿。伊利集团是唯一一家进入全球乳业8强的亚洲乳企,创造了亚洲乳企迄今为止的最高排名,如今正为国内外千万家庭提供着来自草原牧场的健康鲜奶,以高品质、高科技含量、高附加值的多元化产品,赢得了广大消费者的高度信赖。优秀的管理模式让伊利集团在乳制品行业全产业链发展道路上跻身前列,而伊利集团能够取得现在的成绩,与其较早从集团内部开展移动信息化建设的决策是密不可分的。

“三剑合璧”助力伊利集团大步迈向立体化协同时代

经过深入详细的需求调研分析,伊利集团亟需在市场上寻找一家可靠的协同办公软件服务商,并建立持久的合作关系。伊利集团的企业管理和技术团队对多家主流协同管理服务商进行了全面细致的对比,最终选择了OA行业唯一主板上市公司——泛微,助力其开拓乳制品行业全面移动信息化的先河。

在技术和产品方面,伊利集团重视泛微17年间在协同办公软件领域的专注,认同其以OA系统帮助企业构建全员统一的移动办公平台,特别是在企业级移动互联大潮下,泛微发布了以“移动化、社交化、平台化、云端化”四化为核心的全新系列产品;另一方面,伊利集团也看重泛微背后融云为其赋予的扎实的通信云能力,融云基于海量业务的技术锤炼,从基础架构到精细化运营,充分体现为合作伙伴赋能及技术倍化的实力;伊利集团选择泛微和融云,还得益于二者具备完善的合作伙伴体系,通过合作可获得快速的技术支持及更大的综合价值,“三强”可共同构建立体协同办公云图。

融云泛微_900x500

“五大中心、三大平台”实现移动信息化全面升级

根据伊利集团所面临的市场业务需求,泛微为其打造了覆盖“五大中心”(门户集成中心、流程审批中心、知识汇聚中心、身份认证中心、知识共享中心),跨越“三大平台”(综合办公平台、企业微信平台、移动办公平台)的全新协同办公系统,为伊利集团全国33个省市、70多家分子公司、500多个业务部门,共60000多人提供了高效协同办公方式,驱动企业移动信息化加速发展。

其中,融云的云通信能力作为贯穿这一套移动协同办公系统的重要主线,“通信引擎”、“自有系统连通”、“特色功能”和“全球通信加速网络”等底层技术为整套系统增光添彩,帮助伊利集团真正实现管理战略的快速落地和移动信息化的全面升级。

毅力2

(伊利集团内部通信平台)

l 通信引擎完成资源整合

如何解决整套协同办公系统的通信问题,以提高企业内外部协同办公的效率,对拥有供应链、经销商、分公司架构的伊利集团来说是个复杂且棘手的问题。通过整合融云云通信能力后的泛微协同办公系统,伊利集团可做到内外部1对1沟通,多人沟通,并通过调用组织架构通讯录,自动生成特定业务群组,不仅扫清员工沟通障碍,使生产和工作经验得到有效及时的传递,也令资源得到有效整合。

l 自有系统连通可扩展激发新活力

在引进泛微协同办公系统之前,伊利集团已自助开发乳业生产、质量以及供应链环节中的一系列配套软件,然而系统平台无法连通扩展导致了信息共享的瓶颈。而基于融云通信系统中良好的兼容性,泛微可为伊利集团提供统一消息总线,无缝对接企业自有的业务系统,将企业的沟通机制和办公系统有机结合,整体办公效率轻松提升。

l 特色功能让协同系统大放异彩

利用融云的即时通讯和实时音视频能力,泛微针对伊利集团的业务需求,专门打造了特色功能,如“PIN功能”、“已读未读”、“来电/拨号提醒”等。事实证明,在伊利集团的多个办公场景中,这些特色功能成功避免信息遗漏,并且加速了协同系统的创新。

伊利3

(特色功能——PIN功能)

l 全球通信加速网络助力国际化发展

融云的全球通信加速网络,已在全球建立了三大数据中心,3000多个加速节点,服务范围已覆盖全球233个国家和地区,当泛微与融云相遇,可助力伊利集团这样国际化的企业,大幅提升企业在全球的通信体验,在世界的任何一个地方,均能实现稳定的办公与流畅的沟通。

对于泛微和融云的牵手,泛微网络研发副总裁杨国生评价道,我们在经过严格的技术测评后选择了与融云合作,在合作过程中,融云在产品性能、功能方面都表现良好,尤其是在高并发环境下的服务稳定性和高可用性都经受住了严峻的考验。

不仅如此,泛微借助融云在即时通讯和实时音视频中积累的丰富技术经验,不仅获得强大的技术产品支撑,还通过专业的线下合作伙伴大会接触各个行业的头部客户。未来,泛微和融云双方将进一步联手共同推动企业信息化的发展。

通信 交流