拒绝白嫖!开源模式的反击:向不要脸的云服务商收费!

年底将至,又到了大多数打工人开始编写年终小结的时候,但是总有那么一群人,平时碌碌无为,一等到年底,就到处打听到处收集各种成效数字,然后各种不要脸的洋洋洒洒的写在自己的年终小结里,仿佛那些完全没参与过的项目都是他一手打造的,彷佛那些别人辛苦一年才做出的成绩理应给...
继续阅读 »

年底将至,又到了大多数打工人开始编写年终小结的时候,但是总有那么一群人,平时碌碌无为,一等到年底,就到处打听到处收集各种成效数字,然后各种不要脸的洋洋洒洒的写在自己的年终小结里,仿佛那些完全没参与过的项目都是他一手打造的,彷佛那些别人辛苦一年才做出的成绩理应给他一样。

遇到这种人,气不气?

其实这种人不在少数,也正是有这样的人,才会有拿来主义,才会有做事毫无底线的云服务商,才导致了开源商业模式一再萎靡。

当然,老实人并不代表着一定要被欺负!就在1月15号,Elastic 公司 官方宣布:改变 Elasticsearch 和 Kibana 的开源协议,由 Apache 2.0 变更为 SSPL 与 Elastic License。

这次变更的主要针对目的,就是那些毫无底线的云服务商!

微信图片_20210203172125 (1).jpgElastic 公司 的CEO Shay Banon在他的博文中解释到:

虽然,从Apache 2.0 变更为 SSPL 与 Elastic License会改变一部分源代码,但是对于绝大多数的使用免费版本的用户及Elastic 公司的云客户以及自主管理软件客户也不会受到影响。唯一会受影响的,就是云服务商。

SSPL 允许用户以自由且不受限制的方式使用并修改代码成果,但是SSPL也有自己的要求:那就是如果将产品以作为一种服务进行交付,那么必须同时公开发布所有关于修改及 SSPL 之下管理层的源代码。

由此将限制云服务商在不对项目做出任何贡献的前提下,发布云服务商自己的 Elasticsearch 与 Kibana 服务,从而达到保护Elastic 公司的权益,亦可以让公司在开发免费产品方面持续投入的热情和资源,避免恶性循环。

微信图片_20210203172149.png

对于为什么会这么做,Shay Banon也给出了自己的解释:

长久以来,云服务商不断地肆意的将免费的开源软件集成到自己的云产品中,同时将其作为自己的云服务解决方案给予客户使用,俗称白嫖~造成了许多客户越来越多的放弃这些开源厂商的付费版本,直接断绝了开源厂商的经济来源!

早在Elastic之前,就有不少开源公司进行了变更:

Redis、MongDB、OpenCV、Google,Elastic绝不会是最后一个。

此次Elastic主要是借鉴了MongoDB的类似经验。

微信图片_20210203172152.png早在2018 年 10 月,MongoDB 就已经宣布将开源协议从 GNU AGPLv3切换到 SSPL,无论当时如何引起部分用户的不满,MongoDB 至少目前还很健康的继续经营,股价也从 2018 年的不足 100 美元 / 股涨到现在的 361 美元 / 股。可以说是开源公司学习的楷模。微信图片_20210203172155.jpg

SSPL 就是由 MongoDB 最初创建的可提供源代码的许可证,旨在体现开放源码理想的许可证,允许自由和不受限制地使用,修改和重新分发。

SSPL最简单也是最核心的一点就是前文提过的:如果将产品以作为一种服务进行交付,那么必须同时公开发布所有关于修改及 SSPL 之下管理层的源代码。

SSPL 是基于GPLv3 的 copyleft 许可证。并没有经过 OSI(Open Source Initiative,开源促进会,批准开源协议的机构) 批准,因此官方还特意声明:为了避免混淆,我们暂时不将两个产品称为开源,而使用“免费和开放” 进行描述。

有时候甚至会觉得,SSPL纯粹就是被那些习惯了白嫖的云服务商逼出来的产物,就像当每个人做事都只顾着看别人的成效数字,又有几个人能真正做好事呢?


收起阅读 »

Spring Initializr中生成的mvnw是干吗的?

来源于公众号-程序猿DD当我们使用Spring Initializr来创建Spring Boot工程的时候,有没有发现在工程根目录下有两个名为mvnw的文件:从命名、图标、扩展名来猜测,这两个文件的作用应该是一样的,只是cmd文件应该是用在windows下跑的...
继续阅读 »

来源于公众号-程序猿DD

当我们使用Spring Initializr来创建Spring Boot工程的时候,有没有发现在工程根目录下有两个名为mvnw的文件:

微信图片_20210203173520.jpg

从命名、图标、扩展名来猜测,这两个文件的作用应该是一样的,只是cmd文件应该是用在windows下跑的,而另外一个则是用于linux环境下跑的。

那么这个文件到底是用来做什么呢?下面我们一起尝试了解一下:

第一步:打开读一下

微信图片_20210203173526-1024x1531.png

因为内容较多,我这里就不放出来了。内容也非常易懂,只要你了解shell和maven,就能知道这个脚本主要做这几件事:

  1. 检测你是否有安装Maven,如果没有,就自动下载一个(这样才能完成后续的构建任务)

  2. 检查你是否有安装Java或者配置是否正确,这个无法自己完成,如果报错了,就要自己处理一下,比如JAVA_HOME没有,那就自己配置下。

  3. 检查否存在版本不兼容的情况,如果不兼容他会下载合适的版本来帮助你完成构建

更多检查的细节可以自行打开查看和学习

第二步:执行验证下

执行命令:mvnw install

微信图片_20210203173531.png等待构建完成,我们再看看:微信图片_20210203173534.png完美!轻松简单的完成了一个Spring Boot项目的构建!

收起阅读 »

开源模式反击之后,白嫖服务商竟然大叫“好自为之!”

来源于公众号-程序猿DD还记得刚给大家介绍过Elastic宣布将改变 Elasticsearch 和 Kibana 的开源协议,由 Apache 2.0 变更为 SSPL 与 Elastic License。这一举动自然引起一些用惯了白嫖的云服务商的不满,这不...
继续阅读 »

来源于公众号-程序猿DD

还记得刚给大家介绍过Elastic宣布将改变 Elasticsearch 和 Kibana 的开源协议,由 Apache 2.0 变更为 SSPL 与 Elastic License。

这一举动自然引起一些用惯了白嫖的云服务商的不满,这不Logz.io公司官网就发布了一篇,简单总结就是:Elastic,你不讲武德!

微信图片_20210203173353.png

Logz.io公司描述到,Elastic的举动,已经在开源社区引起了轩然大波,无数依赖于Elasticsearch的组织都开始混乱无比。(潜台词:用惯了别人的东西一下子没得用了不知道该咋办)

而Logz.io声称已经联系了很多类似的组织,这些组织的共同点,就是认为Elasticsearch和Kibana应该保持开源而不是使用SSPL。Logz.io正在和这些组织商量一起打造一个真正的开源的Elasticsearch和Kibana版本。

所谓的真正开源,是Logz.io似乎准备自己搭建一个永远用Apache 2.0协议的Elasticsearch和Kibana项目,而维护整个项目的将是他们与多个志同道合的组织。(潜台词:以后没有白嫖的东西了,不自己做还能怎么办呢)

Logz.io公司同时还重申了自己公司的立场:

作为一个客户至上的组织,Logz.io公司最关注的是客户和社区用户的成功。Logz.io公司致力于用最好的平台来支持社区,以满足社区成员的可观察性需求。Logz.io公司将继续致力于在未来支持Kibana和Elasticsearch,并为客户提供最好的观测平台。

这里稍微介绍下,Logz.io公司主要基于AI的日志分析平台致力于帮助用户公司跟踪网站、应用及软件的情况,以避免发生代价高昂的停机故障。这些基本都依赖于Elasticsearch、Logstash和Kibana(ELK)堆栈的云服务分析日志。 所以说,Elastic的这次改变对他们是毁灭性的打击。

说够了远大前景,自然要吐槽下不满,文中,Logz.io公司对于Elastic团队的不满溢于言表:

Logz.io公司自从2014年来一直很敬佩Elastic,钦佩他们的公司文化、领导及业务(潜台词:先夸夸你再摔你),但是在最近几年,Elastic对于开源项目的投入已经江郎才尽,所有的心思都花在了商业上。同时认为Elastic决定关闭源代码以阻止竞争是一种背叛,背叛了他们的初衷:

微信图片_20210203173359.png

同时Logz.io公司认为一家价值数十亿美元的公司试图残酷地阻止竞争迫使社区用户为Elasticsearch付费,是不讲武德的!(潜台词:你家大业大,你给我白嫖下咋的了,你就应该继续免费,然后再战胜我们这些白嫖的人,这才是厉害啊)

最后,Logz.io公司相信,在Apache2下合作提供Elasticsearch和Kibana开源,对Logz.io公司的客户来说是正确的。对于任何依赖这些开源项目的人来说,这是正确的做法。最重要的是,Logz.io公司认为这对开源软件的未来是正确的。(潜台词:白嫖用户来关心开源软件的未来了!)


收起阅读 »

为什么汉字不能当密码,假如用汉字做密码,又会怎样?

来源于公众号“程序猿DD”日常生活中,密码的使用十分常见。基本上,登录APP、手机支付、开机解锁,都需要使用密码。密码的形式也多种多样:数字密码,指纹密码,字母密码等,却唯独没有汉字,这是为什么呢?如何提高密码的安全性呢?这个问题你想过吗?今天,我们来揭秘一下...
继续阅读 »

来源于公众号“程序猿DD”

日常生活中,密码的使用十分常见。基本上,登录APP、手机支付、开机解锁,都需要使用密码。密码的形式也多种多样:数字密码,指纹密码,字母密码等,却唯独没有汉字,这是为什么呢?如何提高密码的安全性呢?这个问题你想过吗?今天,我们来揭秘一下。

汉字不能当密码的原因

1.使用传统

有关密码组成中没有汉字这一问题,首先要追溯到计算机的发明。我们知道,电子计算机最初是由外国人发明,世界上主流的编程语言也是英文,而Windows在电脑系统界占据极大的份额,密码也就顺理成章地由英文、数字等组成。

微信图片_20210203173207.jpg

而且,英语作为世界通用语言,其易用性和通用性相对较高,因此更加普遍地为大众所接受和使用。你再看,它不支持中文字符,对于其他的语言,也不支持啊~

2.汉字加密难度大

其实密码是可以设置成汉字的,不过密码是加密存储,数学和英文只需要占用一个字符就可以迅速完成加密过程,而汉字一般需要占用两个甚至更多字符,相比之下,汉字的加密会更加麻烦。除此之外,还需要考虑字符编码,不同的字符编码对字符的存储方式可能会不同。因此,若使用汉字作为密码,其加密存储过程十分复杂。

安全度较高的密码往往由大小写字母、数字以及特殊符号组成,很多用户拥有极高的安全意识,再加上很多密码设置页面会提示用户当前密码的安全程度,这种情况下设置的密码,其安全度已经处于较高水平。因此再开发难度更大更复杂的汉字密码则不是那么必要了。

一般来讲,设置密码时,网站页面或是APP会提示当前密码的安全程度。大家设置时,可以根据提示进行修改,尽量使自己的密码安全度更高一些~

4.保护密码更安全

我们需要通过输入法输入密码,在使用字母、数字和符号时,手机屏幕上只会显示星号或实心圆点,而若使用汉字密码,输入法的候选字出现在屏幕上,十分容易被其他人看见。而使用字母、数字和字符作为密码,输入时的安全性和便捷性更高,只要手速过快,其他人就跟不上哦!

而且使用中文输入时,还要考虑到输入法的输入习惯记录功能(即词库),输入法能够识别我们的密码,可能带来不必要的麻烦。

5.统一标准

对于一些大型的(尤其是在全世界各地区提供服务的)网站和应用,使用统一的密码规范能够降低服务和维护成本。如果我们习惯使用中文作为密码,而某个国外的服务器却不支持中文,那用户体验会受到极大影响!

另外,如果支持了中文,那俄语、法语等要不要支持?工作量大大提升,是不是?

最后,为大家简述了一些提高密码安全性的tips,大家可以了解一下!

如何提高密码安全性?

1.避免设置连续的数字或字母;

2.避免使用包含个人相关信息的字母或数字,如姓名、生日、身份证号等;

3.不要将密码告知他人,也尽量不要记录在手机、电脑等设备上;

4.密码不要过于单一,不同的网站或应用上尽量使用不同的密码;

5.将账号绑定手机号、邮箱等,可以多重保护密码安全,忘记密码时要及时更换密码。


收起阅读 »

AWS回应Elastic修改开源协议:创建“真正”开源的Elasticsearch分支

来源于公众号“程序猿DD”前几天刚给大家介绍过Elastic公司宣布:改变 Elasticsearch 和 Kibana 的开源协议,由 Apache 2.0 变更为 SSPL 与 Elastic License而在不久之后,云服务商Logz.io公司就对这一...
继续阅读 »

来源于公众号“程序猿DD”

前几天刚给大家介绍过Elastic公司宣布:改变 Elasticsearch 和 Kibana 的开源协议,由 Apache 2.0 变更为 SSPL 与 Elastic License

而在不久之后,云服务商Logz.io公司就对这一行为表达了自己的不满。

但是事情还没完,就像最近国内某郑姓女星的瓜层出不穷吃都吃不完一样,开源协议的宫斗剧也是一出接着一出。

当初Elastic公司改变协议的一大目的,就是针对自己的竞争对手AWS(Amazon Web Services——Amazon云服务)。为此Elastic公司的CEO,Shay Banon甚至曾经发文怒斥过AWS的一些行为。

如果说Logz.io公司还只算小打小闹,那么就在前几天,1月21号,AWS 官方做出回应,宣布将基于目前仍为开源状态的 Elasticsearch 和 Kibana( 7.10 版本)创建分支,开源许可证也会继续使用 Apache License 2.0。(和Logz.io公司发文中的意图不谋而合)

为了确保这个分支能够健康的持续发展使用,AWS 也宣称会负责后续的维护工作。

微信图片_20210203173028.png当然,和Logz.io公司发文中直接开怼Elastic不同,AWS更多的采用了隐晦的嘲讽模式(大公司的公关团队就是不一样!)。例如,AWS 声称自己将要创建的这个分支才是真正开源的 Elasticsearch,显然是在暗喻 Elastic 公司即将采用的双许可证方案(SSPL + Elastic License)算不是真正的开源,因为上述两个协议都不是 OSI (Open Source Initiative,开源促进会,批准开源协议的机构) 批准的开源许可证。微信图片_20210203173031.png

不过,AWS类似的事情并不是没有过。早在2019 年AWS就推出一个 Elasticsearch 的发行版——Open Distro for Elasticsearch,当时他们就对外标榜这款采用了 Apache License 2.0协议的产品,是 100% 开源。

AWS做这个申明的时候似乎忘了Amazon 靠着 Elastic 开发出来的东西赚到的钱就比他们自身赚到的还要多,因为这些内容可以跟 Amazon 的其他产品结合得更紧密,让别人使用更方便。

也为了这个Open Distro for Elasticsearch,Elastic 就在当年在加州联邦法院起诉Amazon 侵犯了自己的商标,一次次的矛盾升级之后最终才导致了Elastic痛下决心,进行开源协议改变。

不知道这一次,之前习惯了白嫖的AWS,是否能做出一个更好的开源Elasticsearch,让我们拭目以待!


收起阅读 »

关于密码你不知道的冷知识?至今还有 3% 的人使用“123456”作为密码

之前我们报导过 2020年被用烂大街的密码《2020 最烂密码 TOP 200 曝光!》,500 多万个泄漏密码表明,共有近 3% 的人使用“123456”作为密码。而最近知名黑客网站 Have I Been Pwned 上一个密码“ji32k7au4a83”...
继续阅读 »

之前我们报导过 2020年被用烂大街的密码《2020 最烂密码 TOP 200 曝光!》,500 多万个泄漏密码表明,共有近 3% 的人使用“123456”作为密码。而最近知名黑客网站 Have I Been Pwned 上一个密码“ji32k7au4a83”的使用次数引起了热烈讨论。

Have I Been Pwned 是一个可以查询用户的邮箱是否被泄漏的网站,它的一个密码查询功能 Pwned Passwords 记录着在数据泄露中暴露的 551 509 767 个真实密码,用户可以在这里查询某个密码被使用的次数。比如查询一下 2018 年最烂密码“123456”,得到 23 174 662 次的结果:

1.jpg

“123456”这样简单易记的数字串被很多人作为密码使用,这很容易理解,但是有一个密码 “ji32k7au4a83”的使用次数让人费解,并且在最近引起了热烈讨论。

硬件/软件工程师 Robert Ou 最开始在 Pwned Passwords 上发现“ji32k7au4a83”竟然有 141 次使用,他觉得这不太正常,因为这个字符串太“偏”了,于是他在社区提问。

随后就有人指出了原因(估计就是使用者),原来“ji32k7au4a83”是汉语注音符号系统中“我的密码”的对应字符串。

汉语注音符号是以章太炎的记音字母作蓝本,1913 年由中国读音统一会制定,1918 年北洋政府教育部正式颁行的一套注音系统。

2.png

1918 年第一个版本如下:

声母介音韵母
ㄍㄎㄫㄐㄑㄬㄉㄊㄋㄅㄆㄇㄈㄪㄗㄘㄙㄓㄔㄕㄏㄒㄌㄖㄧㄨㄩㄚㄛㄝㄟㄞㄠㄡㄢㄤㄣㄥㄦ

经过一个多世纪的发展,目前注音符号已经变化不少。目前中国台湾、澎湖、金门与马祖仍在使用注音符号,详情可以查看百科。

3.jpg

以上中招的朋友看完本文请记得修改密码。

据说,黑客会根据网民习惯设置的密码,收集起来编写成为“常用密码库”,直接使用现成的常用密码库去匹配破解,往往就能短时间破解大量账号。有安全机构研究显示,黑客大约只要17分钟就可以破解1000个帐号。

那我们平时该如何去设置密码呢?

安全专家的建议是,设置密码满足这三点:

  1. 密码长度最好8位或以上;

  2. 密码没有明显的组成规律;

  3. 尽量使用三种以上符号,如“字母+数字+特殊符号”。


收起阅读 »

开源商业模式正在被云服务商杀死!

对程序员圈子来说,Mapbox是一家专注于地图绘制的卓越软件公司。从Mapbox GL JS(他们的2D地图渲染器)到自动驾驶和导航库,再到增强现实、3D可视化,甚至视频游戏技术,Mapbox在这一领域做到非常棒,其创新成果占有巨大的市场份额。而且这些内容都是...
继续阅读 »

对程序员圈子来说,Mapbox是一家专注于地图绘制的卓越软件公司。从Mapbox GL JS(他们的2D地图渲染器)到自动驾驶和导航库,再到增强现实、3D可视化,甚至视频游戏技术,Mapbox在这一领域做到非常棒,其创新成果占有巨大的市场份额。而且这些内容都是开源的,也是让众多程序员喜欢他们的原因之一。

但是昨天看到了一个让我震惊的新闻:最新版本的Mapbox GL JS将不再是开源的!!!

作为个人来说,我并非是一个完美的热衷于开源的粉丝,因为我知道,创建和维护开源代码是多么一件吃力不讨好的事情,真的是非常累人,所以我一直很尊敬那些愿意开源的程序员,并且哪怕是开源,哪怕是对方过去已经丢弃不用的想法,我都觉得自己没有权力肆意使用对方的想法和知识产物。

但是同样的,直到昨天看到那个新闻之前,我仍然对商业开源软件抱着些许的客观、浪漫、自欺欺人的想法。在我的想法中,这是一个在当下重名利的世界中,保持着那颗开源的心,一直以开源做为自己的商业模式,持续走下去的童话故事,而Mapbox就是故事的主角,

去年的时候我也写过关于Mapbox商业模式的文章,就是他即提供了一种免费开源的版本,也提供了一种收费的版本,这些收费版本当然有一些独到的免费版本没有的功能。 听起来,有点像王者荣耀中有皮肤和没皮肤的概念。

如果对开源的商业模式有进一步了解兴趣的,建议可以看下Joseph Jacks的博文,链接地址如下:https://medium.com/open-consensus/2-open-core-definition-examples-tradeoffs-e4d0c044da7c

在最初的时候,没有人相信这种模式管用,但是随后发生的一切让人大跌眼睛,像Elastic、D2iQ(以前的Mesosphere)、MongoDB和Cloudera这样的几十家公司,都通过这种过往没出现过的方式,成功赚取了数十亿美元的投资。当然和现在相比,那个时候他们开放的开源版本可是开放好多。

直到今天,看了那个新闻之后,我们不由得感慨,开源模式即将死去!

那是什么让他从一时兴旺到如今的一命呜呼呢?

云服务商!

我们先回到Mapbox的例子,在Mapbox GL JS使用的案例中,Mapbox最早的决定是,开源其基于浏览器的地图渲染器的最早的两个版本(像我们熟知的Snap-Maps、纽约时报和CNN都用过)。自2014年首次发布以来,它在web开发人员中一直非常流行。一旦你知道你在找什么,你就会开始到处看到它。

微信图片_20210120152742.png

而对于我自己来说,当我的团队开始构建一个标记卫星图像的项目时,我才亲身体验了Mapbox GL JS的功能是有多么强大。使用Mapbox GL JS的功能,支持复杂几何图形的自由形式绘图,最终的成品是可以在地图上形成形状,也就是说是我的标记是被投影到地球上的一个真实位置,而不是简单的仅仅是悬浮在想象中的二维空间。这种效果让人感觉明显和直截了当,非常好用。

但事实上如果我不用Mapbox GL JS,从零开始设计就会非常非常困难。因为即使是用徒手画的简单形状也可以包含数千个单独的点。这样的话很快,我的屏幕上就会被数十万个顶点的形状填满,然后很显然,我的浏览器就会崩溃。而Mapbox GL JS是通过调用计算机上图形卡来帮助解决这个问题,如果不依靠Mapbox那几万小时的艰苦的工程工作,我们不可能在预算和时间有限的情况下完成该功能。Image for post

而这周Mapbox决定公布一个Mapbox GL JS的新版本,这个新版本不再开源瞬间震撼到了我!不仅仅是因为之前的V1版本是一个广受欢迎的开源版本,而是因为Mapbox作为一个开源代码的代名词给予我的那种崇高的敬意。在我的看法里,如果你要描述Mapbox是一家怎么样的公司而不提到开源,就像你和一个从未喝过的人谈到巧克力牛奶时不说这是一种液体一样!

Mapbox迄今为止,仍拥有超过800个开源项目,并在Github公共存储库活动方面一直名列全球前40名。并且Mapbox一直在给世界上知名度最高的开源软件贡献者提供各种工作机会,不仅仅是地图行业。

所以说,到底突然发生了什么?

其实,一切都源头还都是因为开源不再是一个在当下这个时代能站得住脚的商业模式!

Mapbox选择保持Mapbox GL JS的V2版本的专有权而不再开源就是一个强烈的信号。虽然这信号背后到底代表着什么还不是很清楚,但是已经让我咬牙切齿。。。

在我看来,这已经意味着我们要迎接一个时代的结束,这预示着代表着开源这种商业模式的寿命的终结!

其实我的潜意识里一直有着这个想法,早在Mapbox的新闻之前,但是Mapbox的新闻是真正为我心中猜想敲上实锤的那最后一击。

为了了解即使像Mapbox这样的公司也决定从开源转变的原因,我觉得可以先看下Mongo DB和Redis Labs这两个行业同行之前已经发生过的故事。

就在两年前,知名科技博主Ben Thompson写过一份文章,文章中阐述了一份总结关于AWS(Amazon Web Services——Amazon云服务), MongoDB和开源代码的经济回报。按他的说法就是:如果你提供了你的独家代码作为开源代码,并且让它变得流行起来,那么那些云服务商必然将用这些代码来为他们自己所用,为他们制造一些竞争性的服务,就好比用你制作的武器来攻击你一般,并且他们的心中没有丝毫歉意和犹豫,他们的眼中只有利益,对于这种行为,你的律师最后只会对你说一句无能为力,因为你曾经自己将这些内容开源了!

Ben在文中提到AWS推出了一项与MongoDB和Redis的付费产品直接竞争的对手服务,但也没有完全击败对手。事实上,自从那个时候起,MongoDB的股价从那时起已经上涨了275%,Redis在几个月前刚刚筹集了1亿美元,正式跨过了10亿美元的神奇估值门槛。

微信图片_20210120152751.png

但我想表述的更重要的不仅仅是Mongo和Redis在受到AWS的攻击后依旧蓬勃发展,而是他们是如何做到的?

这两家公司都以公司一贯的方式反击:一支知识产权的律师大军。

Redis采取了一种策略,在现有开源工具的更新版本中加入了一个有着严格限制性条件的commons条款,不过这让一些著名的开源代码的支持者非常不满:

微信图片_20210120152753.png

鉴于此,Redis后来用了另外一种方法,申请了一个完全新颖和独特的许可证,虽然这不会比commons条款更糟,但几乎可以肯定的是也不会更好。

另一家公司MongoDB呢?它也采取了俗称poison pill(毒丸) 的法律策略,在AWS推出竞争性的服务后不久,它就为自己的软件申请了一个新的、同样是虚构的许可证Server-Side Public License (SSPL)。

这些动作都是为了对抗云服务商的一系列举措。

更准确的说,他们的开源产品对任何有规模的公司都会起到使用时是否合规这个问题。

当然,这么做的代价就是Redis和Mongo从根本上减少了开源的开放性。从结果看,他们做的很好,虽然这是以牺牲了它们最初的理想为代价的,但毕竟活着是最重要的。

但是很多开源作者觉得自己被出卖了一样,我能理解他们的感受,但是我也理解Redis或MongoDB这么做是理性的生意行为。

回到Mapbox上,至少已经有一家云服务商公开的将Mapbox的代码复制并粘贴到他们的收费服务中: Azure,微软的云服务

去年,Azure发布了由Mapbox GL JS支持的地图样式,它是Azure地图服务的一个关键特性。为此,Mapbox甚至在他们公司的博客上写了一个声明。

虽然我们可以理解为Mapbox写这个声明是件好事,但我严重怀疑这是导致了Mapbox GL JS不再开源的开始。毕竟,在竞争无比激烈的公共云世界里,一旦一个云服务商开始提供服务,其他服务商肯定很快就照猫画虎一样开始提供类似服务。Mapbox终于发现自己的处境与MongoDB和Redis是如此的相似:它们在为那些万亿美元的科技巨头免费提供研发基础!

与Mongo和Redis不同,Mapbox最终还是抵抗了一些冲动。他们没有改变产品开源部分的基本许可证,而是彻底打破了这一局面。旧版本仍然是一个成熟且非常有用的版本,将保留其原始的许可证。同时Mapbox召集社区成员无限期地维护这个版本,我希望这会有用。

而新版本将保持一定程度的公开(例如代码都发布在Github上)。但是它不再是开源那样的了。对我来说,这感觉是一个更诚实的方法,而不是试图用一个没见过的、完全未经证实的许可证或一些“看似明白”的条款来穿针引线制造一种假象。

有些人可能会觉得这是一场悲剧,因为这意味着社区捐献可能会减少。诚然,尽管贡献者名单很长,但Mapbox的现任和前任员工还是贡献了最大的份额。但是这个项目已经吸引了一个庞大的、全球性的工程师群体,他们用它来建造东西,对它进行技术讲座。毫无疑问,昨天对于那些充满创作热情的用户来说的确是一个悲伤的日子。他们会继续过下去,但肯定有一种莫名的失落感。

至于这么做是否偏离了Mapbox最初的使命或公司文化?我想这条来自一位自公司成立以来一直在公司工作的现任员工的微博很好的总结了这一点:

微信图片_20210120152756.png

现实中很多事情都是很无奈的,毕竟我们要吃饭要生存下去。

很久以前我天真的以为围绕开源建立一家公司是很容易的,并且其他人都会很道德的使用这些开源的信息,但是现在我不再敢肯定这些。

我仍然相信开源是世界上一股强大的向善力量。我仍然认为,有的公司可以战略性地、认真地为开源做出贡献,不仅为自己的使命服务,也为集体利益服务。

但是,相对的,我再也不相信那些靠着风投存活下去的公司能够负责任地推行这种策略,将软件作为其价值主张的核心。我不再认为这是一个可行的模式,因为或快或慢,他们都会被他们的野心所吞噬,因为如果不这么做,他们最终只能在被自己的武器干掉和背叛最初的理念中间二选一。

昨天真是令人难过的一天。不仅仅因为Mapbox的宣布令人失望,而且就在昨天,我终于不得不向自己承认一点:

云服务商真的杀死了开源!

(来源于公众号:程序猿DD)


收起阅读 »

关于高阶JAVA枚举你不知道的事!

JAVA枚举,比你想象中功能还要强大!我经常发现自己在Java中使用枚举来表示某个对象的一组值。在编译时确定类型可以具有什么值的能力是一种强大的能力,它为代码提供了结构和意义。当我第一次了解枚举时,当时我认为它们只是一个为常量命名的工具,可以很容易地被静态常量...
继续阅读 »

微信截图_20210203171135.png

JAVA枚举,比你想象中功能还要强大!

我经常发现自己在Java中使用枚举来表示某个对象的一组值。

在编译时确定类型可以具有什么值的能力是一种强大的能力,它为代码提供了结构和意义。

当我第一次了解枚举时,当时我认为它们只是一个为常量命名的工具,可以很容易地被静态常量字符串ENUM_VAL_NAME所取代。

后来我发现我错了。事实证明,Java枚举具有相当高级的特性,可以使代码干净、不易出错,功能强大。

让我们一起来看看Java中的一些高级枚举特性,以及如何利用这些特性使代码更简单、更可读。

枚举是类!

在Java中,枚举是Object的一个子类。让我们看看所有枚举的基类,Enum<E>(为简洁起见进行了修改)。

public abstract class Enum<E extends Enum<E>>
    implements Constable, Comparable<E>, Serializable {
  private final String name;
  
  public final String name() {
      return name;
  }
  
  private final int ordinal;
  
  public final int ordinal() {
      return ordinal;
  }
  
  protected Enum(String name, int ordinal) {
      this.name = name;
      this.ordinal = ordinal;
  }
  
  public String toString() {
      return name;
  }
  
  public final boolean equals(Object other) {
      return this==other;
  }
  
  public final int hashCode() {
      return super.hashCode();
  }
  
  public final int compareTo(E o) {
      Enum<?> other = (Enum<?>)o;
      Enum<E> self = this;
      if (self.getClass() != other.getClass() && // optimization           self.getDeclaringClass() != other.getDeclaringClass())
          throw new ClassCastException();
      return self.ordinal - other.ordinal;
  }
}

我们可以看到,这基本上只是一个常规的抽象类,有两个字段,name和ordinal。

所以说枚举都是类,它们具有常规类的许多特性。

我们能够为枚举提供实例方法、构造函数和字段。我们可以重写toString(),但不能重写hashCode()或equals(Object other)。

接下来我们看下我们的枚举示例,Operation

enum Operation {
    ADD,
    SUBTRACT,
    MULTIPLY
  }

这个枚举表示一个Operation可以对两个值执行,并将生成一个结果。关于如何实现此功能,您最初的想法可能是使用switch语句,如下所示:

 public int apply(Operation operation, int arg1, int arg2) {
    switch(operation) {
      case ADD:
        return arg1 + arg2;
      case SUBTRACT:
        return arg1 - arg2;
      case MULTIPLY:
        return arg1 * arg2;
      default:
        throw new UnsupportedOperationException();
  }
}

当然,这样子会有一些问题。

第一个问题是,如果我们将一个新operation添加到我们的Operation中,编译器不会通知我们这个开关不能正确处理新操作。

更糟糕的是,如果一个懒惰的开发人员在另一个类中复制或重新编写这些代码,我们可能无法更新它。

第二个问题是默认情况default,每段程序里面都是必需的,尽管我们知道在正确的代码里它永远不会发生。

这是因为Java编译器知道上面的第一个问题,并且希望确保我们能够处理在不知情的情况下向Operation中添加了新枚举。

还好,Java8用函数式编程为我们提供了一个干净的解决方案。

函数枚举实现

因为枚举是类,所以我们可以创建一个枚举字段来保存执行操作的函数。

但是在我们找到解决方案之前,让我们先来看看一些重构。

首先,让我们把开关放在enum类中。

 enum Operation {
  ADD,
  SUBTRACT,
  MULTIPLY;
  
  public static int apply(Operation operation, int arg1, int arg2) {
    switch(operation) {
      case ADD:
        return arg1 + arg2;
      case SUBTRACT:
        return arg1 - arg2;
      case MULTIPLY:
        return arg1 * arg2;
      default:
        throw new UnsupportedOperationException();
    }
  }
}

我们可以这样做:Operation.apply(Operation.ADD, 2, 3);

因为我们现在从Operation中调用方法,所以我们可以将其更改为实例方法并使用this,而不是用Operation.apply()来实现,如下所示:

public int apply(int arg1, int arg2) {
  switch(this) {
    case ADD:
      return arg1 + arg2;
    case SUBTRACT:
      return arg1 - arg2;
    case MULTIPLY:
      return arg1 * arg2;
    default:
      throw new UnsupportedOperationException();
  }
}

像这样使用:Operation.ADD.apply(2, 3);

看起来变好了。现在让我们更进一步,通过使用函数式编程完全消除switch语句。

enum Operation {
              ADD((x, y) -> x + y),
              SUBTRACT((x, y) -> x - y),
              MULTIPLY((x, y) -> x * y);
  
              Operation(BiFunction<Integer, Integer, Integer> operation) {
                      this.operation = operation;
              }
  
              private final BiFunction<Integer, Integer, Integer> operation;
  
              public int apply(int x, int y) {
                      return operation.apply(x, y);
              }
  
  }

这里我做的是:

  • 添加了一个字段 BiFunction<Integer, Integer, Integer> operation

  • 用BiFunction创建了用于Operation的构造函数。

  • 调用枚举定义中的构造函数,并用lambda指定BiFunction<Integer, Integer, Integer>。

这个java.util.function.BiFunction operation字段是对采用两个参数的函数(方法)的引用。

在我们的例子中,两个参数都是int,返回值也是int。不幸的是,Java参数化类型不支持原语,所以我们必须使用Integer。

因为BiFunction是用@functioninterface注释的,所以我们可以使用Lambda表示法定义一个。

因为我们的函数接受两个参数,所以我们可以使用(x,y)来指定它们。

然后我们定义了一个单行方法,它使用 ->x+y 返回一个值。这相当于下面的方法,只是更简洁而已。

  class Adder implements BiFunction<Integer, Integer, Integer> {
          @Override           public Integer apply(Integer x, Integer y) {
                  return x + y;
    }
  }

我们的新Operation实现采用相同的方式:Operation.ADD.apply(2, 3);.

但是,这种实现更好,因为编译器会告诉我们何时添加了新Operation,这要求我们更新函数。如果没有这一点,如果我们在添加新Operation时还不记得更新switch语句,就有可能得到UnsupportedOperationException()。

关键要点

  • Enum枚举是Enum的扩展类。

  • Enum枚举可以有字段、构造函数和实例方法。

  • Enum枚举字段可以存储函数。与lambda配合使用,可以创建干净、安全的特定于枚举的函数实现,并在编译时强制执行它们(而不是使用switch)。

下面是这个示例的GitHub地址。(https://github.com/alex-power/java-enum-example)

本文参考:https://medium.com/javarevisited/advanced-java-enum-features-you-need-to-know-b516a191c7e2

(来源于公众号:程序猿DD)


收起阅读 »

美国、日本、俄罗斯版“微信”大PK,即时通讯软件如何流量变现?

即时通讯软件可以说是互联网时代的基础设施了,从全球范围看,虽然各类即时通讯软件如雨后春笋般出现,但是真正能留在消费者手机中的却凤毛麟角,本文将主要对比美国版微信Whatsapp、日本版微信Line以及俄罗斯版微信Telegram的主要盈利模式。壹美国微信Wha...
继续阅读 »

即时通讯软件可以说是互联网时代的基础设施了,从全球范围看,虽然各类即时通讯软件如雨后春笋般出现,但是真正能留在消费者手机中的却凤毛麟角,本文将主要对比美国版微信Whatsapp、日本版微信Line以及俄罗斯版微信Telegram的主要盈利模式。

壹美国微信Whatsapp:拒绝广告,赚B端的钱2009年,Jan Koum和Brian Acton开发了一款用于“状态更新的APP”,并将之命名为“Whatsapp”。当这个软件升级到2.0的时候,也就真正开始了其作为即时通讯软件的生涯。
作为一个拥有16亿月活(MAU)用户的超级APP,网络效应早已经形成,但是如何赚钱成了问题——因为其开发者鲜明地表达了拒绝通过广告赚钱的逻辑。

1.jpg

按照Whatsapp开发者的观点,他们希望能为用户创造一个即时通讯平台,而不是为企业创造一个放广告的平台。于是,起先的逻辑是收取每个用户每年1美元的订阅费。
这时候就不得不提及Whatsapp的融资历程了:它的第一轮融资来自5位前雅虎的朋友,总额为25万美元;而它的第二轮和第三轮投资者就值得一说了,那就是大名鼎鼎的红杉资本(Sequoia Capital),总额6000万美元(2011年800万美元,2013年5200万美元)。
这些融资基本就负担了Whatsapp公司的所有开销,考虑到运营这个项目的成本并不是很高——事实上,主要的开销是向用户发送验证码,所以Whatsapp取消了向C端收取1美元/年订阅费的做法。
之后,当Whatsapp再次进入视野的时候,就是Facebook的扎克伯格收购Whatsapp了:在追逐Whatsapp长达2年之后,2014年2月,Facebook以190亿美元收购Whatsapp,而创始人Jan Koum也得以加入Facebook董事会。
收购之后,Whatsapp的价值就显现了:Facebook不仅将之视为一个用户数据的“留量池”,更将之纳入自己的生态体系。
Facebook推出了Whatsapp Business Application,也就是商业版Whatsapp,这样企业就可以在上面建立自己的官方档案,并得到系统认证。在档案中,这些企业可以将自己的网站链接、Facebook主页链接挂上去,甚至可以将他们的座机号连在Whatsapp中。

目前,商业版Whatsapp对于企业来说依然免费,Whatsapp是通过商业API赚钱。 Whatsapp商业API可以把Whatsapp和企业的系统进行整合,通过通知让企业和消费者接触。为了避免垃圾信息,Whatsapp限制了企业发送消息的能力,只有消费者首先联系了公司以后,公司才可以联系消费者(这点和微信的公众平台非常相似),不过API也可以帮助企业向消费者发送送货确认、活动门票等,目前Whatsapp的商业API已经和Booking.com等客户进行了深度合作。

至于Whatsapp如何通过API赚钱,那就很有趣了,Whatsapp向回复缓慢的企业收取费用。
正常情况下,当消费者联系企业后,企业可以在24小时内回复,这是免费的;但是时间一旦超过24小时,此时API就会收费,其费用是固定的,根据国家有所不同。
听起来似乎是一个特别蠢的收费逻辑,但是对于那种百万级用户的企业来说,这就卡住了咽喉:一个订票网站怎么可能同时处理百万级用户的咨询呢?所以这个需求是确实存在的。

此外,在印度,Whatsapp还有支付功能,这可能帮助Whatsapp成为当地用户首选的“寄钱APP”——就像Venm一样,这也可以成为未来的盈利点。
在F8大会上,扎克伯格也提到了这一点,未来他将把Whatsapp的支付功能拓展到更多国家,这对于希望从Whatsapp的网络效应中赚钱的商家,有极大吸引力。
至于盈利数据,Whatsapp目前没有公开过财报,来自福布斯(Forbes)的估算显示,其年收入约50亿美元,ARPU在2020年可以达到4美元。

贰日本微信Line:广告为生,内容为辅在亚洲,Line主要流行于日本、泰国、印尼和中国台湾地区,该公司成立于2000年9月,于2016年7月同时在日本、美国的纽约证交所上市,其主要股东是韩国搜索引擎巨头Naver。
从Line的财报看,2019年4季度(财年截止于2019年12月31日)它的营业收入达到608亿日元,同比增长8.6%,按照地区划分,71%的收入来自日本,29%来自海外。
同期,其在日本的MAU同比增加5.1%,季度MAU达到1.64亿,同时DAU/MAU也达到了79%,也证明了Line的用户活跃度。
从收入角度看,Line共有3个核心收入源,按营收占比,第一是广告(55.4%),第二是交流/内容/其他(29.8%),第三是战略业务(14.8%)。
在广告方面,Line主要是展示广告(Display Ads)和账号广告(Account Ads),二者占总广告收入的93.2%,而展示广告收入同比增长达到65.4%。考虑到Line为各类商家提供大量广告服务,这个成为核心收入源也就十分正常了。

Line的第二大收入源是交流/内容/其他,这部分收入比较稳定,占比超过一半的是内容部分,分别是音乐业务Line Music和漫画业务Line Manga,目前音乐业务同比增长超过40%,漫画业务也有20.1%。
继续往下挖一层,值得一提的是两点,第一点是Line的内容业务,这一部分可以简要称之为“贴纸、壁纸”。用户可以在“主题商店”和“贴图商店”中充值“Line积分”购买壁纸和表情包。

这部分可以和微信进行对比:在微信上,艺术家可以制作表情上架微信,用户对表情的打赏将直接进入艺术家账户。

第二点是“其他”,根据其财报显示,这部分主要是研究业务“Line Research”,财报写道:“有超过500万用户注册成为问卷答卷人,此项业务依然在稳健增长”,为企业提供用户调查,这也属于是对用户的货币化方法之一了。
最后是Line的第三大收入源,Line在财报中将之称为“战略业务(Strategic)”,2019Q4总收入为90亿日元,其中51亿日元收入来自IP业务“LINE FRIEND”,这里主要销售IP赋能的玩具、文具、日用品等;另外的39亿日元来自O2O/电商、Fintech和AI业务。

不过,这里更值得注意的是Line打造的支付业务“Line Pay”,2019Q4,其全球GMV达到3550亿日元,全球MAU达到650万,相比2019Q3分别增长680亿日元和100万。

整体而言,Line的收入源还是比较多的,在广告收入之外,主要是内容(漫画、音乐、表情)、IP变现以及支付业务。对于Line来说,广告和支付业务成为重要收入源并不难以想象,而内容业务的收入更多是和日本等地用户对于漫画、音乐、IP等的认可,以及二次元环境密不可分的。

叁,俄罗斯微信Telegram:绝对免费、绝对安全,发币赚钱对于不少国内用户来说,Telegram的火爆得益于曾经的“发币狂潮”——大量用户为了获得糖果空投(Airdrop)而注册Telegram,加入“电报群”。
相比于其他即时通讯软件,Telegram主打两点,第一是永远免费,第二是绝对加密。
事实上,在成立之初,Telegram就主打“隐私(Privacy)”,其创始人Pavel Durov在2013年创建Telegram,并在短时间内实现爆炸性用户增长,他曾说,在推出Telgram的15个月后,用户在Telegram上就发送了10亿条信息,而VKontakte(这是Durov之前的创业项目)花了6年半才做到的里程碑。
他同时写道,“Telegram的5000万用户均匀地分布在各个大陆,最活跃的用户来自西班牙、巴西、韩国、墨西哥、德国、马来西亚、新加坡、印度、沙特、意大利和美国,而俄罗斯的比例是1%。”
至于所谓的安全性,其实不必看Telegram的官方介绍,只需要看新闻就可以了:
据Trend Micro发布的一份关于恐怖分子通讯方式的研究报告显示,34%的恐怖分子使用Telegram进行沟通,该研究也证实了此前有关极端组织“伊斯兰国(ISIS)”使用Telegram进行秘密信息交换。
和Whatsapp类似,Telegram也不通过广告赚钱,同时还保持了开源的特性,截止到2019年,Telegram没有盈利,或者说没有创造过收入,其创始人Durov在一篇博客上写道,如果资金不足,他可能会引入“非必要的付款选项(non-essential paid options)”来给程序员发工资。
传统的收入来源都没有,Telegram却有“新的收入来源”,那就是“发币”。
2018年1月到3月,Telegram进行了代币首次发行。其白皮书显示,Telegram的加密代币被命名为“Gram”,总发行量为50亿,其中52%用于开发、44%用于代币首次发行,以及余下4%给予团队。
Telegram的区块链网络名为“TON”,该区块链项目将分为四个分支:TON服务、TON DNS、TON支付和TON区块链。
最后,这场宏大的代币首次发行募集了约17亿美元(全世界的投资者购买了约29亿个Gram代币),而来自今年1月初的报道显示,美国证券交易委员会(SEC)提交了一份法院指令,要求Telegram解释代币首次发行所产生的资金是如何使用的。不过迄今为止,Telegram一直拒绝公开账目,并且表示Gram不是有价证券(Security)。
Ton网络原定于2019年10月上线,但美国证券交易委员会将 Telegram 的上线日期推迟到了2020年4月。所以目前没人说的清Telegram到底是用这笔钱干了什么,只能关注今年4月份会不会有新的消息,并希望这一场代币首次发行不是一场闹剧。

总结整体来说,可以发现,即时通讯软件们虽然最终盈利模式并不相同,但是发展模式非常接近,可以抽象为:
1.0时代,免费的时代,主打用户之间的连接、交流,这个时代以两个“结论”作为最终答卷,APP本身看,就是DAU、MAU和用户数,而从外部看就是在市场内的占有率;
2.0时代,赚钱的时代,一般来说,APP在此时已经在一个地区成为至少是Top2的巨头,沉淀了海量用户,此时B端企业就会盯上这个APP,开始做营销、服务,而APP就可以“顺坡下驴”为这些B端企业开发功能模块,进行服务抽成——例如GMV抽成,基本来说在这个领域,中国的微信早已走在了前面。

(来源于公众号-零售威观察)

收起阅读 »

RTC vs RTMP,适合的才是最好的!

随着在线教育、电商直播、泛娱乐社交等 App 的普及,实时音视频技术的应用需求也越来越多元化。目前,市场中能够支持音视频通信的主流技术有“RTMP+CDN”和“RTC”两大阵营。选型时,开发者如何根据场景选择更适合自己的通信技术?这就要从两者的技术特点、价格、...
继续阅读 »

随着在线教育、电商直播、泛娱乐社交等 App 的普及,实时音视频技术的应用需求也越来越多元化。目前,市场中能够支持音视频通信的主流技术有“RTMP+CDN”和“RTC”两大阵营。选型时,开发者如何根据场景选择更适合自己的通信技术?这就要从两者的技术特点、价格、厂商服务综合考虑。1.png

RTMP+CDN 技术特点与适用场景

RTMP (Real Time Messaging Protocol)基于 TCP 的流媒体传输协议,最大的特点是与 CDN 的强绑定,需要借助 CDN 的负载均衡系统将内容推送到接近用户的边缘节点,使用户就近取得所需内容,提高用户访问的响应速度和成功率,解决因分布、带宽、服务器性能带来的访问延迟问题。更多适用于站点加速、点播、短视频等场景。

对于初次通过 CDN 服务来实现音视频通信的开发者来说,技术指标应主要关注延时、卡顿率、下载速度、打开速度、回源率、宽带冗余提升率等几个维度。

有研究表明,在 0.1s 以下的延迟,用户几乎是无感知的;1s 左右的延迟,用户会明显注意到延时的发生,但在该时间内思维依然是连贯的;超过 10s 的延时,用户会失去等待的耐心。在所有关键技术指标中,控制延时是 CDN 最需要提升的。

以直播场景为例,延时主要看 2 个核心指标:首播时间和再缓存时间。首播时间即从打开到看到视频画面的时间,会受域名解析、连接、第一包时间的影响,首播时间控制在 1 秒内算是不错的效果。其次是再缓冲时间,是用户观看视频时的卡顿时间。由于实际服务中视频长度不一,一般会做播放的体验统计,主要监测的是卡顿率。行业内而言,直播首播时间 300ms,卡顿率在 15% 以下算是优质的通信服务。

目前的 CDN,通常有 3-5 秒的延迟,在浏览图片、短视频等内容时用户感知不明显,对于不需要实时强互动的直播,比如体育赛事网络直播、演唱会网络直播、新闻现场直播,延迟是可以接受的,并不会影响用户体验。

2.png

而在线视频会议、在线教育、电商直播、远程医疗会诊这些对互动有非常高要求的场景,RTMP+CDN 的模式与这些场景对于低延时、无卡顿的要求有一定差距。这时,选择 RTC 技术才能更好地满足开发者的需求。

RTC 技术特点与适用场景

说到 RTC(Real Time Communication)实时音视频通信,它最大的特点就是低延时和无卡顿。从功能流程上说,它包含了采集、编码、前后处理、传输、解码、缓冲、渲染等诸多环节,RTC 不是靠“优化”各环节去实现的实时互动,而是依靠推流端实时的传输机制。

3.png

很多实时音视频服务专业厂商使用的就是 WebRTC 标准,这是一种基于浏览器的实时通信的开源解决方案,使用 UDP 私有协议来进行媒体推流,而不需要创建离散的媒体段;并且它是面向无连接的,没有 TCP 连接断开时的挥手确认连接关闭的机制,基于这两点,WebRTC 能够做到毫秒级的低延迟,远远低于基于 RTMP 协议的 CDN 分发的延迟。而且,它直接通过浏览器就可以完成推流和播放,对于开发者接入来说实在太方便。

因此,WebRTC 标准针对有高互动性要求的直播场景尤为适宜。以直播连麦为例,主播端把通信直播流发到观众端,同时也可以把观众端拉上麦,实现主播和观众的互动。使用 WebRTC,内容实时传输,主播和观众可以进行音视频连麦互动,实时沟通,延时一般低至 400ms 以内。

4.png

基于 WebRTC 标准的融云实时音视频服务,拥有超低延迟的优势,同时也支持将 RTC 音视频流合流(MCU)转码为 RTMP,并推流到第三方 CDN 上,保留了标准协议普遍被 CDN 网络支持的好处。目前,融云音视频通话,可做到全球端到端延时小于 400ms,最低延时 66ms;低延时互动直播的直播推流可以做到主播观众间延迟在 300ms 左右,保障端到端之间延迟无感知的实时互动。

CDN vs RTC 选型还需看价格服务综合比

一套实时音视频通信能力的搭建,除了要根据场景选择适合的技术外,还要看价格、服务的综合性价比。通常来说,使用 RTC 技术的成本比 RTMP+CDN 高。因为,从实践来看,UDP 传输比 TCP 传输对资源消耗要多,而且重传、封包、FEC 冗余计算等都会额外增加计算量,在多进程模式下可能还会遇到内存资源的过多消耗,这些都导致开发及使用成本的增加。

开发者选型中,性价比需综合技术特点、适用场景、价格和服务四个方面的全面考量。服务在产品上线前后的开发阶段和运营阶段,都要发挥重要作用。目前,开发者服务做得比较好的厂商比如融云,会与开发者共建开发文档,技术手册短视频化,提供场景化的 Demo,以及在官网搭建开发者专区,帮助开发者更便捷、更快速的理解 SDK。

融云全新升级的实时音视频服务,提出“以一套 SDK 解决所有通信场景”,使用融云 RTC 的开发者,同时可以用融云 IM 作为信令通道,而不用自己重新搭建或选择第三方信令通道,这样可以大大提升开发效率,减少 SDK 文档学习时间。

总体而言,RTC 低延迟直播是未来发展的趋势,而 RTMP 在当前依然拥有价格上的优势,而两者作为音视频领域的实用技术,无论是适用场景、还是贴近开发的服务都越来越多样化,开发者未来选型之路也将更顺畅。



收起阅读 »