对不起,我要去大厂了!

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

大家好,前段时间写了一篇关于程序员获得年薪五十万的方法,引起了一些共鸣,有一些读者私聊问我。现在不是大厂竞争很激烈吗?再说大厂的薪水待遇也没有比一些二线公司更好呀,既然如此,那为什么我们还要挤破脑袋进大厂呢?今天就和大家闲聊几句,以下说的仅代表我个人的看法。如... ...查看全部

大家好,前段时间写了一篇关于程序员获得年薪五十万的方法,引起了一些共鸣,有一些读者私聊问我。现在不是大厂竞争很激烈吗?再说大厂的薪水待遇也没有比一些二线公司更好呀,既然如此,那为什么我们还要挤破脑袋进大厂呢?
今天就和大家闲聊几句,以下说的仅代表我个人的看法。如果有不同观点,一笑置之便是。微信图片_20210318112323.jpg

金字招牌
前几年阿里在校招的时候,一直打的旗号就是阿里大学。把阿里这家公司比作了学校,我们进去不是为了赚钱,也不是为了打工,而是另外一个层面上的学习和深造。所以内网当中很多离职的小伙伴发帖都不说自己是离职,而称自己是毕业。

但你仔细想一下就会发现,除去企业宣传的目的和手段之外,还真的有那么几分道理。每年都有大量的工程师从BAT离职,进入各行各业大小公司当中继续发光发热,某种程度上来说互联网产业的发展所需要的大量人才正是这些大企业提供的。当你去面试,当你去找工作,如果你的简历当中有BAT的工作经历,就好像是清华北大的文凭一样,不说100%面试通过,但至少可以给你争取来一个面试的机会,不至于倒在简历关。

微信图片_20210318112326.jpg

今年我在申请新加坡国立大学的在职硕士的时候,就一直在犹豫。因为我想来想去,觉得对我的简历而言,这个文凭有和没有其实没多大区别。我以后要是跳槽,面试的职位一定不是靠文凭就可以争取得到的。既然如此,又何必费钱费力呢?虽然我最终还是决定继续申请,但我心里也清楚,我这么做只是为了学点东西,而不是真的指望它可以给我在职业发展上带来多大的帮助。
很多贩卖焦虑的人士一直在宣传35岁淘汰论,但我知道的几个35+从大公司出来的程序员,他们并没有被淘汰,依然混得不错。

通关地图
很多人很排斥大企业,经常说的一句话就是大厂拧螺丝。

的确如此,大厂由于分工非常明确,工具非常完善,使得大多数岗位的活非常没有技术含量,就是按照一个标准继续往下做就好了,没有惊喜也不大会有改变。我自己亲身体验过,我在阿里两年,就做了两年数据,今天用户数据A,明天用户数据B,有的时候还沦落到和BI一样做报表。我们也经常吐槽,我们哪里是算法工程师,分明就是SQL工程师。

我之前一直觉得在这两年当中,我应该什么都没有学到,所有的技能都是靠我自己业余自学的。我也一度有些后悔,觉得当初自己是不是选错了,不应该去阿里。但我来了新加坡不久之后就完全颠覆了这个看法,因为我发现我并不是什么都没有学到,有点像是冰山理论,我看到的只有水面上的一点,大部分都藏在水下。

什么意思呢,我就用拧螺丝举个例子好了。比如你在一家造航母的大公司当中做一个螺丝工,今天拧拧这个螺丝,明天拧拧那个螺丝。有一天你受不了离职了,到了一家小船厂。你一进去就发现小船厂的厂房顶太低了,现在造小船还好,有朝一日要造大船的话就不够用了。过了两天,你又发现现在拧螺丝的扳子不对,耐久度非常差,只能拧某一个型号的螺丝。又过了两天,你发现建造的船设计也有问题,居然不是流线型……

你在来小船厂之前你以为你只是拧了两年螺丝,什么都没学到,其实你已经看到了通关地图。我现在有的时候也还是会后悔,但我后悔的不再是当初的选择,而是后悔当时有机会的时候,没有把通关地图看个仔细,导致遗漏了不少。

大佬云集、资料丰富
当初我在阿里认识一个非常非常资深的前辈,他在阿里十来年了,但因为各种原因级别不是很高。我当时问他,既然你对现状如此不满,为什么不想着离开寻找更好的机会呢?

他沉思了片刻跟我说,他说我现在在这里虽然待着不顺心,但是我接触到的人都是非常优秀的。我遇到问题,还可以和你们讨论讨论。我如果出去了,我要是再遇到问题,可能连一个讨论的人都没有。
我当时听听只是觉得有道理,现在再回想起来,感受非常深刻。三观、格局、能力,能够进入大公司的,这三个方面一般都不会太差。别的不说,就拿个人能力而言,我出国以后见识了许多各种海外名校的同事,和当初阿里的同事相比说真的也不过如此。我也不知道是不是我的偏见,但就我感受下来,国外的工程师格局相对偏小。

除了优秀的同事之外,大公司里往往还有丰富的内部文档和资料。我当时在阿里内部看到了很多优秀的文章,也有很多优秀的技术沙龙和分享。现在想起来两年下来,也没有去过几次,文章和资料看得也不算多,现在想想颇为遗憾。别的不说,就拿推荐领域而言,近些年质量不错的论文往往都来源于大公司尤其是国内的大公司,以阿里、华为和头条为主。除了公开的论文,公司内部还有很多技术相关的资料和文档,这些真的可以说是有价无市,非常珍贵。

尾声
都说大公司是座围城,城外的想进去,城里的想出来。虽然很多人从城里出来了,但并不代表城里就不好,我觉得有机会还是很有必要去看一看的。

关于这点我想到了一个小故事,说是三国时期,恒温讨伐蜀汉,见到了一个曾经给诸葛亮服务过的小吏,此时已经一百余岁了。恒温就问他:今天治蜀有谁比得过诸葛亮吗?小吏从容回答说:“葛公在时,亦不觉异,自公殁后,不见其比。”意思是说孔明在时也不觉得有什么异常,但是等孔明去世了之后,才发现没有人能与他相比。

我觉得很多大公司也是一样的,我们身处其中的时候不觉有异,但我们离开之后才发现不见其比。

转载于公众号“码个蛋”


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

科技创新大兴 发表了文章 • 0 个评论 • 103 次浏览 • 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”


“力挺Java!拒绝Python”9万程序员刷爆朋友圈……

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

那天,被一个应届生朋友问到:学习编程选Java还是Python好? 我可以说“我认为编程语言没有好坏之分,用的顺手,选哪个都可以!” “没有最好的语言,只有最适合自己的语言。” 不过这样说,其实也是没有什么帮助的废话。 六年前,我... ...查看全部

微信截图_20210401105923.png

那天,被一个应届生朋友问到:学习编程选Java还是Python好? 

我可以说“我认为编程语言没有好坏之分,用的顺手,选哪个都可以!” “没有最好的语言,只有最适合自己的语言。” 

不过这样说,其实也是没有什么帮助的废话。

 六年前,我从机械工程转到了IT,在此期间,C++、Java、Python都玩过,下面说一下我对这几个语言的最大感受。 

起初因为我并不是科班出身,C++对于我这个半路出家的人来说真的太难,搞了一周也搞不明白。

 初学Python的时候用还是很顺手得,代码相对简洁,听老师讲一讲就能打出几段代码,满足了我得成就感,让我找到了编程的乐趣,不过也不是没有遇到困呐,例如遇到最主要的问题时,我就找不到思路。 

在有了Python作基础,我又去学了Java,现在我主要使用得编程语言也就定为Java了。说一下我选择它得原因:

  • 不会被歧视报错(对比C++)

  • 代码逻辑清晰(对比Python)

  • 数据结构多

  • 方便class套class

 所以,大家到底该选择哪门语言呢? 

我们不想说编程年度排名,它不足以作为参考,以及求职导向,我们首要关心的话题应该是“学了这门语言,我能找到什么工作?” 

如果你有目标公司就能确定工作方向,去他们的公司招聘主页,看看他们的技术栈和常用的编程语言,往死里嗑就对了。 

我整理了市面上用Java/Python 较多的公司: Java:阿里巴巴,去哪儿,美团,网易,搜狐,百度。

Python:知乎、豆瓣、新浪、淘宝、腾讯、金山。 

于是有人会问我:“我只是想单纯入个行,不要求大厂中厂小厂,该怎么选?” 

简单来说,如果想在一个行业深耕,Java依旧是后端首选,最重要的是,市面上用Java的面试官是最多的。

而且一般来说,不管面试官平常用什么语言,他们都看的懂Java,因为的语法直观,API清楚。 

而Python是门脚本语言,抽象层次太高,不利于初学者理解底层结构。 

Python贵在短小精悍,做project上手很快、刷题速度也很快,但如果面试官看不懂你的语法会非常吃亏。 

如果你有条件的话,可以把两种语言都系统地学一遍。但如果时间和精力不允许,基础薄弱,又为了短时间内就业,建议选择Java。 

另外我认为,编程学习一开始靠专业人士带入门是必须的,有天赋的人入了行之后自己就能越混越好,没天赋的人也能学个皮毛,明确方向。


奇奇怪怪的大佬:理发店小弟到阿里P10

好玩创意fanta2 发表了文章 • 0 个评论 • 205 次浏览 • 2021-04-01 11:19 • 来自相关话题

蚂蚁金服,可能是众多程序猿眼中梦寐以求的归宿,无数拿过数不清奖状的各个高校走出的学子精英都挤破头皮,只为能在蚂蚁占有一席之地。蚂蚁金服里不乏各种深藏不露的大佬,到了那里才会深刻明白一山还有一山高这句话究竟是什么意思有这么一位大佬,年纪轻轻就评为全球35位35岁... ...查看全部

蚂蚁金服,可能是众多程序猿眼中梦寐以求的归宿,无数拿过数不清奖状的各个高校走出的学子精英都挤破头皮,只为能在蚂蚁占有一席之地。

蚂蚁金服里不乏各种深藏不露的大佬,到了那里才会深刻明白一山还有一山高这句话究竟是什么意思

有这么一位大佬,年纪轻轻就评为全球35位35岁以下科技创新青年,是不是觉得肯定是清华北大出来的少年天才?又或是耶鲁哈佛这种海归名校渡过金的高高在上之人?如果你有机会进入到这位大佬的团队,他会笑着对你说学霸你好,我是个学渣,我没上过大学.

微信图片_20210318101415.png

没错,红雪,蚂蚁金服的资深研究员,带领着数百人的技术团队,他的经历用来拍一部励志电影也绰绰有余。

最早的红雪,高中毕业之后没上大学,而是四处打零工,在路边修过自行车,也做过理发店小弟。就差一点成为了三和大神。后来他想学自考混文凭,结果连自考的考试都挂掉了。

看到这里,如果你身边有一个这样的人,你一定会觉得这个人资质愚笨,不会有什么大出息,或许就这样浑浑噩噩的过一辈子。

红雪或许当初也面临着这样一条人生道路,哪怕好不容易自学考上了西安一所大学,结果所学专业可能面临着毕业即失业的囧境。

好在和大多数80后一样,那个年代的男生都喜欢电脑,不过红雪不是喜欢电脑游戏,他感兴趣的是硬件、板卡、内存条,空闲时分就帮同学组装电脑,要不就是学3D建模。有条件的时候还会学习各种编程书籍。

但要知道那个年代,程序员还远不如现在这样飞黄腾达,大多数人眼中的程序员就是不学无术之人,没什么大前途。

但是红雪没有放弃,03年毕业之后,他在西安找了一份工作,每个月能有1千多的盈余,全都花在了各种软件培训班上。或许编程对他来说,就是有种特别的吸引力。

但是无论红雪学的怎么样,往往他去面试的时候别人一看他的履历,甚至不考查一下他的技术能力直接就让他回家等消息。

这种情况一直到2007年,他收到了一份阿里的面试邀请。

直到今天,他和别人谈起当年时,仍对当时的情况仍记忆犹新:

从头到尾没有人来问过我有关学历的问题,也没有人问一些让人觉得不被尊重的问题,当时招聘专场有一句话让我热血沸腾 If not me, who? If not now, when?

就像那句古话,英雄不问出处,等过了面试被录取到杭州报道,看着身边那些用塑料袋装了一堆毕业证书和等级认证的日后同事,红雪并没有感到畏惧没有感到自卑,同样的他看到了一些和他一样两手空空的人,比如当时一个叫阿玺的,也是个80后,今天已经是蚂蚁副CTO,阿里巴巴最年轻合伙人。

不由赞一句,阿里这种不拘一格招揽人才的行为,真是大气,国内能做到这一点的企业屈指可数,尤其时阿里的眼光,事后并没有给予世人嘲笑的机会,这些换成其他企业或许连个面试机会都没的人,现在无一不成为了阿里的骨干。

红雪进入阿里之后,只做一件事,就是拼命的学习,就像武侠小说里面的一样,每个人都希望自己有天赋异禀的绝世才能,可以一步成天人,可以一朝成龙凤,但小说毕竟是小说,现实中我们中的每个人都是普通人,没有那种过目不忘的记忆,但勤能补拙,一倍不够就十倍,十倍不够就百倍,付出一定会有回报。

红雪就是这样,自从走进蚂蚁的那一天起,无不时时刻刻鞭策自己比别人付出更多的努力。尤其是后来到了国际业务部,按红雪的说法,每个人常常是在不同电话会议上,刚讲完印度英语,马上就切换到马来西亚英语,然后就是越南英语,再者菲律宾英语,每个地域不同的口音对他们来说就像数十门语言需要不停的切换。

而让红雪感到每天充满干劲的,就是能和一群一样志同道合的人,每天一起做着改变世界的事情。

回到20年前,谁又能想到,当年那个在理发店帮工的小弟会成为日后这样的一个人物?那些当时被洗头的人,是否有曾对其投出过轻视的眼神?

一切,都需要靠自己的双手去努力,程序员们,你们说是吗?


重磅!微信 3.0 客户端支持刷朋友圈了!从此爱上上班还是无心上班?

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

对于众多苹果粉来说,今天是一个眉飞色舞的好日子,微信Mac版客户端终于支持查看朋友圈啦!!!微信作为现在最普及的社交工具,每个人只要手机在手就会时不时想要刷刷朋友圈,看看自己的朋友们又晒了什么新鲜有趣的玩意。哪怕是在上班时候,很多人也忍不住在电脑端客户端登陆,... ...查看全部

对于众多苹果粉来说,今天是一个眉飞色舞的好日子,微信Mac版客户端终于支持查看朋友圈啦!!!

微信作为现在最普及的社交工具,每个人只要手机在手就会时不时想要刷刷朋友圈,看看自己的朋友们又晒了什么新鲜有趣的玩意。

哪怕是在上班时候,很多人也忍不住在电脑端客户端登陆,时不时的摸摸鱼偷偷懒。

微信图片_20210318104655.jpg

但是mac端的小伙伴之前就没那么幸运了,微信就一直没有mac版本的客户端,不过这一切的一切,在今天终于扬眉吐气了。

微信Mac版客户端的使用流程、功能都和之前的微信网页版类似。

在安装微信Mac版客户端后,用户只需使用微信扫描电脑上的二维码并确认后即可登录。

登录成功后,界面中一样会显示近日的联系人账号和“文件传输助手”账号。

同时,微信手机客户端上也会显示“正在使用微信Mac版”字样。

微信图片_20210318104709.jpg

不过目前只有 Mac OS X 10.7(Lion) 及以上系统才可以正常使用。

小编体验了下,Mac版客户端的朋友圈暂时只支持浏览、点赞和留言,还不能直接发布新的朋友圈。

不过Mac版的朋友圈支持播放小视频和观看直播,就是还不能通过卡片进入到小视频模块的界面。

看来腾讯在Mac版本上还是比较保守的,没有一次开通太多的功能。

不过想必很多人都会看到这个数字就恨不得点一下的强迫症吧,以后即使使用Mac上班,估计也没心思安心上班了吧~


请问消息的UpStreamMessage 的sessionId是什么作用,还有DownStreamMessage的status和消息的接受状态数字好像对不上

IM即时通讯admin 回复了问题 • 2 人关注 • 1 个回复 • 219 次浏览 • 2021-04-01 10:48 • 来自相关话题

融云X-Meetup南京站 探讨实时通信架构的高质量设计(文末附讲师PPT)

技术活动admin 发表了文章 • 0 个评论 • 245 次浏览 • 2021-03-30 18:43 • 来自相关话题

2021年3月27日,融云X-Meetup技术沙龙第二站落地南京。这场以“高质量高并发的实时通信架构设计与探索”为主题的开发者活动,邀请到融云音视频工具研发工程师王炜、IM 高级研发工程师齐新兵、壳壳互联软件工程师张熙文、虎克CEO过巍四位大咖,向现场的开发者... ...查看全部

20213月27日,融云X-Meetup技术沙龙第二站落地南京。这场以“高质量高并发的实时通信架构设计与探索”为主题的开发者活动邀请到融云音视频工具研发工程师王炜、IM 高级研发工程师齐新兵、壳壳互联软件工程师张熙文、虎克CEO过巍四位大咖,现场的开发者们分享了各自领域的干货。

1.jpg

融云X-Meetup技术沙龙 南京站现场 

音视频SDK架构设计,重在稳定可靠

沙龙上,融云音视频工具研发工程师首先发表了《融云音视频 SDK 架构分享与应用》的演讲。他认为,谈到 SDK 架构设计,融云音视频 SDK 因简洁易用、通俗易懂、可分层架构、可替换可复用、易于维护等诸多优点广为开发者所熟知。这既是融云音视频SDK架构设计的经验总结,也是融云音视频SDK架构设计的原则

目前,融云音视频SDK架构主要API接口层、数据模型层、会话管理层、基础组件层和信令层组成。在数据模型层,设计应面向业务逻辑、面向用户,要关注数据模型不同的生命周期,兼顾读开放、写限制。尤其不可忽视的是要做好保护性拷贝以便后续的运营维护。

2.png

融云音视频SDK架构

在分享会话管理层的设计要点时,王炜直接以框架设计图来阐释音视频采集、前处理、编码、传输、解码、后处理、渲染状态相互之间的逻辑关系。简捷而直观的表达,帮助开发者更好地理解其设计的精髓。

3.png

会话管理层合理设计架构

基础组件层王炜指出,因面向底层设备硬件资源,一个独立的任务管理系统,因此要更注重模块功能内聚,具备非直接耦合和接口隔离;而信令层的设计,则要求能够封装IM信令通道和进行Http请求,使之具有独立于业务功能的逻辑,不仅要有基本的通信能力,还可拆包、封包,并且不允许跨层调用。

大规模即时通讯客户端日志系统,重在发现问题

目前,融云 SDK 服务 30 万款 App, 总触达数超过 50 亿,日均消息量突破 150 亿,日均活跃用户 7000 万,日消息峰值高达 2218 亿条,秒峰值消息 2000 。这些数据实实在在地见证了融云大规模通信架构的高光时刻

在高光时刻的背后,融云IM 高级研发工程师齐新兵坦言,“当一秒钟要完成 2000 条消息的分发时,不只是我们自己的研发、运维团队,甚至是我们运营商、机房的人都时刻在担心各种意想不到的故障。”因此,能够先于客户发现问题,及时发现自身问题,确保以高质量的 SDK 服务客户,融云大规模即时通讯客户端日志系统就显得极为重要。

能否完整、及时地把系统中出现的问题反应出来,并在成功率可视化方面拥有出众表现,是大规模即时通讯客户端日志系统设计的主要诉求。灵活控制日志上传、保证移动端日志统一、保证上传成功率,以及标签日志黑名单功能,这些都是日志系统设计和升级要点。

例如,要做到灵活控制日志上传,应根据每家客户应用下发日志配置,满足不同的平台版本要设置好上传时间间隔和失败重试次数,确保日志上传的成功率和及时性。同时,还要做到灵活控制被动上传和主动上传,以便有针对性地排查问题被动上传含日志开关与上传级别方便关闭与控制主动上传可拉取指定用户特定时间段内的所有日志。

在设计中,保证移动端日志统一能有效保证日志的可视性和完整性。此外,合理利用日志标签黑名单功能,使黑名单内的日志不再入库上传,在实践中可极大减少日志量,从而减轻服务器的成本压力

直播社交 依靠融云高质量通信架构的设计

作为X-Meetup技术沙龙活动的“X”嘉宾,虎克CEO过巍分享了公司的发展历程及直播行业对PaaS通信云能力的需求。虎克自2012年开始进入商业直播领域,其形式主要是会议直播,这与现在经常看到的娱乐直播和秀场直播都不同,差异在于视频格式、物理环境不同,线上会议直播与线下内容的交互更强关联,因此对实时性的要求也比较高。随后,虎克进入了秀场直播领域,比如线上抓娃娃,直播社交等多种应用场景。

在公司发展过程中,虎克看到了越来越多有商业价值的应用场景都需要底层通信技术赋能,而想要拥有稳定可靠的通信云能力,不是一家初创公司花半年甚至一年时间,找十几个、二十几个工程师能够做得出来的。

为了快速发展,虎克最终选择与融云牵手合作。合作后,虎克负责应用场景和商业价值的实现,而所有与底层通信云相关的技术与服务都交给融云。目前,虎克已推出60多款应用产品,覆盖超过90%的典型场景,单一应用产品用户量已经突破百万。最为难得的是,所有应用产品用户体验是零投诉,这完全依赖于融云稳定、可靠的高质量高并发的实时通讯架构。

此外,直播社交领域的壳壳互联软件工程师张熙文也分享了《直播社交系统架构升级》的最佳实践,认为用户感知和视觉体验应成为架构升级过程中,重点被解决的问题,并以视觉体验中的主题皮肤设计为例,详细向开发者介绍了该设计的框架技术图。

结语

娱乐社交、电商直播应用场景,都需要音视频和IM核心功能来支撑,而行业红利的爆发,用户规模的指数级增长,又需要不断升级迭代的架构来保障用户体验。因此,掌握高质量高并发的实时通信的架构设计越来越成为开发者的必备技能。融云X-Meetup南京站技术沙龙,为开发者提供了交流的平台与机会,期待2021年下一站再相遇。

讲师PPT请点击下载↓

1融云音视频SDK架构分享与应用-王炜.pdf

2直播社交系统架构升级-张熙文.pdf

3大规模即时通讯移动平台实时日志系统实践-齐新兵.pdf


融云 2021 X-Meetup 启航 探索高并发下的高质量实时通信架构设计

技术活动admin 发表了文章 • 0 个评论 • 163 次浏览 • 2021-03-29 14:20 • 来自相关话题

2021 年 3 月 20 日,融云 X-Meetup 技术沙龙首站在重庆启航。本次沙龙,融云 WebRTC 开发工程师苏道、壳壳互联软件工程师张熙文、融云 IM 高级研发工程师齐新兵、探探科技国际化技术负责人王伟四位技术大咖,围绕如何实现“高质量高并发的实时... ...查看全部

2021 年 3 月 20 日,融云 X-Meetup 技术沙龙首站在重庆启航。本次沙龙,融云 WebRTC 开发工程师苏道、壳壳互联软件工程师张熙文、融云 IM 高级研发工程师齐新兵、探探科技国际化技术负责人王伟四位技术大咖,围绕如何实现“高质量高并发的实时通信架构的设计”这一主题,向开发者们分享了宝贵的实践经验。1.jpg

X-Meetup技术沙龙:重庆站

 
融云《大规模音视频会议实践》和《大规模即时通讯客户端日志系统实践》的演讲,分别从 RTC 和 IM 通信云全线产品,向开发者介绍了超大规模会议场景优化策略、如何做好日志系统及效果评估,解答了开发者关于底层通信架构设计的困惑;壳壳互联和探探科技也各自分享了在实践中的系统优化策略。
 
大规模音视频会议的通信架构优化设计策略
 
疫情打破了空间的局限,音视频会议越来越普遍,大家接纳并更习惯了线上会议的便捷性。进入 2021 年,随之而来的一个变化就是,大规模以及超大规模(500 人)的音视频会议需求悄然在增长。
 
在超过 20 人会议场景下,现有的多对多网络架构 SFU 与 WebRTC 的兼容场景就无法很好地解决。如果 500 人的会议,直接选择参会人之间进行音视频互动,音视频数据的完全转发对服务器资源的需求是巨大的,再加上会议中有大量人员同时接入,服务端上行流量和下行流量陡增,更加剧了服务器资源的压力。

微信图片_20210329141939.jpg融云 WebRTC 开发工程师 苏道 现场答疑

在不稳定的网络环境中,要解决上述问题,同时还要保障通信质量的稳定性,最根本的方案是设计合理的通信架构。融云苏道分享道,可以通过按需订阅与转发、优化音频流量两种策略优化通信架构,在保证效果的前提下,将极大缓解服务器的压力。

 
具体来说,按需订阅与转发策略应做到以下几点:第一、支持单独订阅某个人的某路视频或某路音频;第二、接收端仅订阅正在说话的人的视频,音频全部订阅;第三、按需订阅视频大小流。目前,融云 SDK 支持发送端视频编码,支持大小流、接收端按需订阅大流或小流。大流的清晰度高,码率高;小流的清晰度低,码率低。这样当接收端想观看清晰视频的时候订阅大流;对清晰度要求不高的时候订阅小流。另外,弱网下融云支持自动切换大小流,以保证视频的流畅性。
 
优化音频流量策略,降低音频流量则主要应做到:第一、发送端静音时不发送数据;第二、调整音频码率;第三、服务器下发音量 Top N 路。一般情况下,客户端收到音频流,在音频解码后,默认仅混流播放音量最大的 3 路声音。因此一定要避免不必要的音频包的转发,以减少服务流量,只有有效音频包,才会进入到下行分发队列。
 
除此之外,为了优化音频体验,还需注意级联情况的处理、大会议室房间和普通房间之间的切换等多个方面。最后,苏道鼓励开发者道,“架构从没有失败和成功之说,都是先做得出来且能够用,然后再进一步优化迭代,满足更多人、更多场景的需要。”
 
大规模即时通讯的客户端日志系统实践
 
日志是记录系统中各种问题信息的关键,大规模即时通讯的客户端日志系统包含了海量数据。随着业务的发展与增长,日志平台也要经历迭代升级。绝大部分开发者对日志系统的要求是:完整性、及时性、上传成功率、以及可视性。
 
针对以上诉求,融云IM高级研发工程师齐新兵分享了日志系统如何升级的实践。他认为,日志系统首先要做到灵活控制日志上传。根据每家客户应用下发日志配置,日志上传时间最好间隔在 10 秒左右,并允许上传失败重试 5 次,以确保日志上传的及时性和上传的成功率;同时还要有被动上传和主动上传机制,以方便针对性的排查问题。
 
其次,保证移动端日志统一。这需要统一编写日志模块,保证逻辑统一;梳理标签,保证日志标签内容一致;统一编写底层数据库模块,数据格式要两端一致,从而有效保证日志的可视性和完整性。除此之外,还要有日志标签黑名单功能,黑名单内的日志不再入库,不再上传,一定程度上减少日志量,减轻服务器的成本压力。
 
日志最重要的意义在于先于客户发现问题,同时也能够及时发现自身问题,确保以高质量的 SDK 服务客户。因此,齐新兵认为,大规模即时通讯的客户端日志系统在研发过程中,需要多测试,不怕暴露其中的问题,才能提升开发者体验。
 
直播社交及社交的系统架构实践
 
在直播社交领域,壳壳互联软件工程师张熙文分享了《直播社交系统架构升级》的最佳实践,他认为,影响直播社交日活的重要指标是用户感知和视觉体验。简单说,用户感知就是如何减少延迟,理论上直播延迟超过 150-200ms 便可以被人脑感知。实践中,壳壳互联在服务端和客户端分别进行技术协议和技术方案的优选,最终达到接口请求速度增加 20-40%、单位时间内服务器请求承载量增加 30% 左右,用户在直播社交中的感知速度提升。
 
直播社交受众对视觉体验的要求更高,这主要指主题皮肤的框架设计,包括合理修改 UI 元素的属性、重新布局特定 UI 元素、可运营主题皮肤、可出售主题皮肤等,因此,张熙文特别分享了主题皮肤的设计框架技术图,启发开发者从中获得新的思考。

3.png

壳壳互联张熙文分享主题皮肤的设计框架技术图

 
此外,探探科技国际化技术负责人王伟也带来了《基于探探IM系统的优化分享》。从探探 IM 架构、接入层、转发层和服务层、通信协议、通知机制等不同方面介绍了探探对高并发下的高质量实时通信架构设计的探索。

X-Meetup 技术沙龙下一站:南京
 
X-Meetup 技术沙龙是融云 2020 年组织发起的,围绕"全球通信云技术的发展与探索" 为主题,每期邀请特定行业的技术大咖作为神秘 “X” 人,与融云一起分享开发者最为关心的前沿技术和最佳实践。今年首站重庆启航后,下一站 3 月 27 日南京站正在火热报名中,融云期待与开发者们共叙音视频实战的困境和解决之道,报名到会的开发者,还将享有专属惊喜礼品,以及与 “X” 技术大咖单独交流的机会。


融云集成错误码汇总

IM即时通讯大神庵 发表了文章 • 0 个评论 • 328 次浏览 • 2021-03-18 11:45 • 来自相关话题

最近集成了融云 IM SDK,过程中遇到了错误码,这时需要去 SDK 头文件找到对应的错误码查看原因。下列给大家整理了一下,希望可以帮到大家,如果还有疑问,可以联系融云的技术:30007 : 导航 HTTP 请求失败。建议:更换网络环境,如无法解决,联系服务端... ...查看全部
最近集成了融云 IM SDK,过程中遇到了错误码,这时需要去 SDK 头文件找到对应的错误码查看原因。下列给大家整理了一下,希望可以帮到大家,如果还有疑问,可以联系融云的技术:
微信截图_20210318112905.png

30007 : 导航 HTTP 请求失败。建议:更换网络环境,如无法解决,联系服务端排查(尤其是私有云)' :

31002 : AppKey 错误。请检查您使用的 AppKey 是否正确

30010 : 创建 Socket 连接失败。建议:一般是网络不好,需更换网络试一下。

31004 : Token 无效。建议:一是 token 错误,请您检查客户端初始化使用的 AppKey 和您服务器获取 token 使用的 AppKey 是否一致;二是 token 过期,是因为您在开发者后台设置了 token 过期时间,您需要请求您的服务器重新获取 token 并再次用新的 token 建立连接

31005 : AppKey 与 Token 不匹配。建议:请检查您使用的 AppKey 与 Token 是否正确,是否匹配。一般有以下三种原因。一是 token 错误,请您检查客户端初始化使用的 AppKey 和您服务器获取 token 使用的 AppKey 是否一致;二是 token 过期,是因为您在开发者后台设置了 token 过期时间,您需要请求您的服务器重新获取 token 并再次用新的 token。三是 App 校验未通过,是因为您在开发者后台设置了 App 校验建立连接。

31007 : BundleID 不正确。建议:请检查您 App 的 BundleID 是否正确

31008 : AppKey 被封禁或已删除。建议:请检查您使用的 AppKey 是否被封禁或已删除。

31009 : 用户被封禁。建议:检查您使用的 Token 是否正确,以及对应的 UserId 是否被封禁

31010 : 用户被踢下线。建议:当前用户在其他设备上登录,此设备被踢下线'

31023 : 用户在其它设备上登录。建议:重连过程中当前用户在其它设备上登录

33001 : SDK 没有初始化。建议:在使用 SDK 任何功能之前,必须先 init

33003 : 开发者接口调用时传入的参数错误。建议:请检查接口调用时传入的参数类型和值

34001 : Connection 已经存在。建议:调用过connect之后,只有在 token 错误或者被踢下线或者用户 logout 的情况下才需要再次调用 connect。其它情况下 SDK会自动重连,不需要应用多次调用 connect 来保持连接

34005 : 连接环境不正确。建议:融云公有云 SDK 无法连接到私有云环境。请确认需要连接的环境,使用正确 SDK 版本

34006 : 连接超时。建议:当调用 connectWithToken:timeLimit:dbOpened:success:error: 接口,timeLimit 为有效值时,SDK 在 timeLimit 时间内还没连接成功返回此错误

30011 : Socket 断开。建议:Socket 连接被断开,主要有两种情况,一是用户主动调用 disconnect 之后,Socket 被服务器断开;二是中间路由原因等导致 Socket 断开

30008 : 导航 HTTP 返回数据格式错误。建议:建立连接的临时错误码,SDK 会做好自动重连,开发者无须处理。

30004 : 导航 HTTP 发送失败,是否设置 ATS。建议:如果是偶尔出现此错误,SDK 会做好自动重连,开发者无须处理。如果一直是这个错误,应该是您没有设置好ATS。ATS 默认只使用 HTTPS 协议,当HTTP 协议被禁止时 SDK 会一直 30004 错误。您可以参考 iOS 开发文档中的 ATS 设置说明。链接如下:https://support.rongcloud.cn/ks/OTQ1

30012 : PING 失败。建议:建立连接的临时错误码,SDK 会做好自动重连,开发者无须处理。

30013 : PING 超时。建议:建立连接的临时错误码,SDK 会做好自动重连,开发者无须处理。

30014 : 信令发送失败。建议:建立连接的临时错误码,SDK 会做好自动重连,开发者无须处理。

31000 : 连接 ACK 超时。建议:建立连接的临时错误码,SDK 会做好自动重连,开发者无须处理。

31001 : 信令版本错误。建议:问融云的技术人员吧

31003 : 服务器当前不可用。建议:建立连接的临时错误码,SDK 会做好自动重连,开发者无须处理。

31006 : 连接重定向。建议:建立连接的临时错误码,SDK 会做好自动重连,开发者无须处理。

32061' : 连接被拒绝。建议:建立连接的临时错误码,SDK 会做好自动重连,开发者无须处理。

20604 : 发送消息频率过高,1 秒钟最多只允许发送 5 条消息。建议:多个消息发送的时候中间加个延时

20607 : 请求超出了调用频率限制,请稍后再试。建议:不要多余频繁的调用接口

21406 : 当前用户不在该讨论组中

22406 : 当前用户不在该群组中。建议:到融云开发者后台 API 调用模块对应服务中进行查询

22408 : 当前用户在群组中已被禁言。建议:让开发者服务端人员确认一下是否在群组中

23406 : 当前用户不在该聊天室中。建议:到融云开发者后台 API 调用模块对应服务中进行查询核实

23408 : 当前用户在该聊天室中已被禁言。建议:到融云开发者后台 API 调用模块对应服务中进行查询核实

23409 : 当前用户已被踢出并禁止加入聊天室。被禁止的时间取决于服务端调用踢出接口时传入的时间。

23410 : 聊天室不存在。建议:到融云开发者后台 API 调用模块对应服务中进行查询核实

23411 : 聊天室成员超限,默认聊天室没有人数限制,开发者可以提交工单对某个 Appkey 进行聊天室人数限制,设置后加入聊天室时如果人数超限,会提示这个错误码

23412 : 聊天室接口参数无效。请确认参数是否为空或者有效

23414 : 聊天室云存储业务未开通。建议:到融云开发者后台进行开通

23423 : 超过聊天室的最大状态设置数,1 个聊天室默认最多设置 100 个

23424 : 聊天室中非法覆盖状态值,状态已存在,没有权限覆盖。建议:这个值只有创建者才能修改。如果必须修改,则需要调用 RCIMClient 中forceSetChatRoomEntry:key:value:sendNotification:autoDelete:notificationExtra:success:error:接口。具体请到 RCIMClient 中查看 API

23425 : 超过聊天室中状态设置频率,1 个聊天室 1 秒钟最多设置和删除状态 100 次。建议:降低设置和删除频率

23426 : 聊天室状态存储功能没有开通,请联系商务开通

23427 : 聊天室状态值不存在

26002 : 操作跟服务端同步时出现问题,有可能是操作过于频繁所致。如果出现该错误,请延时 0.5s 再试

34004 : 聊天室状态未同步完成,刚加入聊天室时调用获取 KV 接口,极限情况下会存在本地数据和服务器未同步完成的情况,建议延时一段时间再获取

30001 : 当前连接不可用(连接已经被释放),只能表明当前连接是断开的,具体原因还需要通过其他错误码分析

30002 : 当前连接不可用,只能表明当前连接是断开的,具体原因还需要通过其他错误码分析。建议:可能是网络不可用,请切换网络试一下

30003 : 客户端发送消息请求,融云服务端响应超时。建议:服务器可能有问题

33002 : 数据库错误,造成错误的原因:1. 需要保证连接融云成功并且数据库打开后再调用业务接口,比如发消息。2. userId 中包含特殊字符。

33003 : 开发者接口调用时传入的参数错误。建议:请检查接口调用时传入的参数类型和值

33007 : 历史消息云存储业务未开通。可以在融云开发者后台中开启该服务

30016 : 消息大小超限,消息体(序列化成 json 格式之后的内容)最大 128k bytes。建议:缩小消息体的大小,避免超过 128 k

25101 : 撤回消息参数无效。请确认撤回消息参数是否正确的填写

26001 : push 设置参数无效。请确认是否正确的填写了 push 参数

20605 : 操作被禁止。 此错误码已被弃用

20606 : 操作不支持。仅私有云有效,服务端禁用了该操作。

21501 : 发送的消息中包含敏感词 (发送方发送失败,接收方不会收到消息)

21502 : 消息中敏感词已经被替换 (接收方可以收到被替换之后的消息

34002 : 小视频时间长度超出限制,默认小视频时长上限为 2 分钟。建议:视频不要超过 2 分钟

34003 : GIF 消息文件大小超出限制, 默认 GIF 文件大小上限是 2 MB

34007 : 查询的公共服务信息不存在, 请确认查询的公共服务的类型和公共服务 id 是否匹配

34008 : 消息不能被扩展, 消息在发送时,RCMessage 对象的属性 canIncludeExpansion 置为 YES 才能进行扩展。建议:把RCMessage 对象的属性 canIncludeExpansion 置为 YES

34009 : 消息扩展失败, 一般是网络原因导致的,请确保网络状态良好,并且融云 SDK 连接正常

34010 : 消息扩展大小超出限制, 默认消息扩展字典 key 长度不超过 32 ,value 长度不超过 64 ,单次设置扩展数量最大为 20,消息的扩展总数不能超过 300

34011' : 媒体消息媒体文件 http 上传失败


融云升级到到5.0报错

IM即时通讯大神庵 发表了文章 • 0 个评论 • 158 次浏览 • 2021-03-18 11:45 • 来自相关话题

使用 pod ,从4.x版本升级到 5.x,写法和报错如下写法: [RCIM sharedRCIM].enableBurnMessage = YES; 报错:Property 'enableBurnMessage' not found on o... ...查看全部

使用 pod ,从4.x版本升级到 5.x,写法和报错如下

  1. 写法: [RCIM sharedRCIM].enableBurnMessage = YES; 报错:Property 'enableBurnMessage' not found on object of type 'RCIM *' 解决:把代码改成 RCKitConfigCenter.message.enableDestructMessage = YES; 因为 SDK 把接口从 RCIM 类移到了 RCKitMessageConf 中

  2. 解决完上述属性报错后,出现了以下报错: 报错:Apple Mach-O Linker Error

     ld: library not found for -lopencore-amrnb
     clang: error: linker command failed with exit code 1 (use -v to see invocation)

    解决:TARGETS - Build Settings - Other Linker Flags 里去掉 -l"opencore-amrnb"

  3. 解决完上述报错后,又出现了以下报错: 报错:Apple Mach-O Linker Error

     ld: library not found for -lopencore-amrwb
     clang: error: linker command failed with exit code 1 (use -v to see invocation)

    解决:TARGETS - Build Settings - Other Linker Flags 里去掉 -l"opencore-amrwb"

  4. 解决完上述报错后,又出现了以下报错: 报错:Apple Mach-O Linker Error

     ld: library not found for -lvo-amrwbenc
     clang: error: linker command failed with exit code 1 (use -v to see invocation)

    解决:TARGETS - Build Settings - Other Linker Flags 里去掉 -l"vo-amrwbenc"

希望大家可以活学活用,在报错的时候全局搜一下对应的关键词,看是不是引用的问题导致


友情链接