转载

环信首席架构师梁宇鹏谈架构、管理及成长

EGO是高端技术人聚集和交流的组织,每周我们都会对一位会员进行人物专访,在展示会员风采的同时,也分享会员们对技术、对工作、对人生的感悟,本周,我们邀请到了环信首席架构师梁宇鹏。

环信首席架构师梁宇鹏谈架构、管理及成长

擅长的领域

我一直的工作都在即时通讯领域,所以对IM相关的业务都比较熟悉。亲手做过的系统规模从十万、百万到千万级别一路增长过来,在分布式系统设计和服务高可用保证等领域也算有些积累。

分布式系统设计方面。曾经把一个百万级天天报警超时的系统,优化为基本零报警的千万级系统,而且期间系统承载用户翻了一番;也曾经把一个系统的速度提高到原来的一百倍性能,机器数量还减少了一半;现在刚刚把一个系统从十万级别做到千万级别,就是环信的这套系统,而且这个过程中用户数是按月指数级增长的。

即时通讯方面。我开始的大多数时间都专注在XMPP方面,但是随着移动互联网的兴起,网络情况和用户通讯需求的变化,大概在12年左右设计了适应移动互联网的新的通讯协议,现在正在做最新的更简化更通用的版本。

后端服务的云化不可阻挡

后端服务的云化不可阻挡,越来越多的后端服务会挪到云上。如果你做云服务,这服务的规模也会越来越大。亿级的平台应该不在少见,遇到的挑战越来越大,随之而来的技术也会越来越有意思。现在的容器化就是一个例子。

即时通讯领域之前还是在于沟通,从移动互联网开始到后面的物联网,重心应该更在于连接,链路更加不稳定,承载的数据却更加多元。长远来看,万物都将互联。借着云服务的东风,我们将有可能把这样的通讯框架作成基础设施。一个可靠而稳定的通讯框架,将极大促进各种创新应用和服务的出现。

搭建现实与理想桥梁的架构师

架构师最重要的素质,可以搭建现实与理想的桥梁。用总理的话说,既可以仰望星空,又能脚踏实地。

对于一个还不错的工程师来讲,如果他做过百万级的系统,你让他再做一套百万级的系统,他可以做出来。但你再让他做一套千万级的系统,那就未必了。更进一步,你让他做一套十万级的系统,如果他之前没做过,你会发现他做出来的还是一套百万级的系统。

不要奇怪。

所以这里有两点,一是知道理想是什么样子,也就是知道目标系统的架构;二是明白当前的现实情况,发现最需要优化改造的地方。

这对于一个快速发展的创业公司尤其重要,业务发展快,要求系统承载能力可以跟得上,慢一步失去机会,公司的生存都会受影响。与此同时,团队小资源有限,人力尤其紧张,你不可能把所有想做的改造一下子都做完。很多人讲创业需要拼,但是终究需要遵循物理规律。

所以你需要规划这样的演化路线,让系统跟得上公司发展的步伐,又不至于过分透支团队。我们常讲,一个能够运行的系统要好过一个完美的系统,有时候为了能够支撑业务我们会做一些比较脏的事情,但更多的时候,你还需要考虑,如果实在要做这些事情,如果做可以让他们在以后的系统演化中也用得到,至少可以事半功倍。

这也是作为首席架构师最大的挑战。

我们的系统经住了考验,之前刚刚在QCon2015上做了分享。

架构师与程序员的差别

架构师明显要比工程师有更广度的技术覆盖,仍然有几个能力不可或缺。 一是系统性思维。能从整体上把握系统,又能能够抓住系统的本质,找出系统层面的瓶颈点。工程师思维往往会专注在把一个组件优化到极致,但架构师更多需要想的是这个组件在整个系统的位置,以及它能发挥的作用。如果系统瓶颈点不在这里,这个组件再优化百倍都是没有意义的。 二是规划和设计能力。能够设计出理想的系统,又能迈出设计的第一步,按部就班完成整个系统。

架构师不光能知道系统的未来,重要的是带领团队按照设定的路线走到那一天。这里面就涉及按照规划整个系统的演进方向问题。就算你可以制作搭建房屋的每一个组件,能盖成房子还是需要额外的能力的。

三是推广能力。架构师出现的时候,面对的系统往往不是一个人能做完的。这个时候,你需要向其他工程师来讲解整个系统的设计思路,并能够得到他们的理解和认可。后面这点很重要,如果工程师不认可就不会好好实现,最后的效果必定大打折扣,当然如果不能理解,那就更糟了,你得到的不是你想要的。还有比这更惨的么?

至于如何修炼,我现在能给的建议是,在针对性的训练外,一定要注意归纳总结。你肯定见不全所有系统,但你至少能够了解并分辨同类系统。在你见系统的时候,也就是学习的时候,带着问题的思考可能更有帮助。比如,这个系统是做什么的,为了能够达到设计目标做了哪些事情,这些事情是为了什么,又如何能应用到其他系统中去。

有的人,见山始终是山,他就只能做业务系统,因为在他眼中系统都是独立的;有的人,见山不是山,他在一个系统内学到的东西可以应用到同类系统内,但始终跨不出同类。修炼的目标要是,见山还是山,你在能看到所有细节的设计后,仍然能看到整体的系统。

最有成就感的事

人总是容易对第一次印象深刻,讲一下关于单元化架构的事情吧。

微博的粉丝服务平台(类似微信公众号)有一个重要功能是群发。开始做的时候,已经有一个老的系统只能发送一万条每秒左右。由于系统的限制,我们通过一些批量操作方面的优化,也加了很多机器,也只能提高到十倍左右。因为微博的用户里有粉丝是亿级别的,按照十万的速度,也要二十分钟左右才能覆盖所有粉丝,这对于时效性要求比较高的资讯类信息是比较难以接受的,因为首发就意味着关注,粉丝的关注就是金钱。

所以我们就在思考新的方案来解决这个问题。当然粉丝规模还不是唯一比微信公众号更难的一点,还有一点是,微信公众号是单独的用户体系,数据规模都在可控范围内,但微博的粉丝服务平台却是基于当前的微博用户,用户规模更大。最终的解决方案就是现在用到的单元化架构。

之所以说有成就感,除了刚才说的技术方面,还有一些其他原因。这是我第二次不按常理出牌,第一次就是前面提到的千万级系统的优化,但这次步子更大。在此之前,国内很少听到对单元化架构的讨论,印象中当时的资料也只有Facebook提到过,虽然最近跟他们的人交流好像还处在很不成熟的状态。

这就带来了一个问题,你是在创新还是在折腾?我不仅要回答团队内部,因为这个项目是公司当时的战略重点,不过这倒还简单,反正我带团队做,失败了我自己负责;还要回答给我们的运维支持团队,因为所有服务用单元化集中后,运维平台的监控都需要一些改动,原来他们是按照服务来分团队的,现在我一台机器几个服务好多人管。管过机器你就知道,大家做事方法不一样,很容易你删掉我的文件我停掉你的权限。

好在最后,我得到了所有团队的大力支持,这个实验性的改造得以落地。最终用一半的机器达到了原系统一百倍的性能,效果非常不错。

这个事情我也在13年的QCon上海分享过。

技术人要找到自己的道路

最开始系统不稳定人又少的时候,我大部分精力都放在技术上,很多事几个人一讨论就开工了。最近几个月系统规模上来了团队规模也大了,非技术工作就多了起来。基本上,我百分之三十的精力在纯技术上,设计系统和协议、代码编写以及复审,百分之五十的精力在人员招聘、培训和管理上,还有百分之二十左右是在社区分享和交流。后面的时间,可能技术工作又要占到百分之五十吧,因为要做秘密项目了。

我想说的是,对于一个技术人来讲,如何调整不重要,重要的是要了解自己应该做什么,方向明确了再调整都是简单的事。而这个了解其实很难,你需要不断调整自己的思考角度,思考做的事情对团队的价值,然后让自己发挥的作用最大化。

阮一峰曾经翻译过的一篇Nicholas C. Zakas的文章,“ 七个对我最好的职业建议 ”。虽然我觉得这些东西大部分是知者知之,不知者不知,还是建议阅读一下。

提倡社区分享和交流

太多的人忽视了社区分享和交流,或者由于对新技术玩心太重,或者由于过于忙碌,导致很长时间都难有提高。

分享与交流最直接的好处是可以促进思考。为了分享,你需要对过去进行总结,有效的思考可以将经历变成经验沉淀下来。而为了交流,你又需要跳出自身的角度审视遇到问题,这样又会引发更深层次的思考。这是个人成长的第一步。

就算你自己思考再多,到了真正的交流之时,你必然还会发现很多没有想周全的地方。不过你大可以放轻松,这是个体逃不出去的局限所致。但你确可以借交流的机会,让自己的思考变得更加全面。当然还有一些时候,你会发现自己思考的完全是错的,或者别人已经发明了更好的方法,原来你解决的问题根本就不是问题了,这个时候,交流实际上是在拯救你了。 另一方面,技术人需要产生自己的影响力,并为整个社区的发展贡献力量,这是所有技术人的成长最难的一步,如果不是最后一步的话。想做到这点,就需要重视分享和交流。这个Tim Yang(此处能否加之前Tim的采访文章的链接)前几天也强调过,就不在此赘述。

故障是推动技术进步的机会

团队开始的时候有一部分人并没有太多互联网服务相关的经验,做事情比较Geek,对于性能变化和系统兼容性方面不够敏感,导致经常出现升级问题,而且由于系统降级方面设计不足,线上问题能做的补救措施也有限。我们的服务有一个时期不够稳定。

我曾经写过一篇文章“ 什么不要做?关于失败和优化 ”,专门讲解这个问题。

好在我们还是典型的技术公司,最终大家经过讨论,技术问题还总能通过技术手段解决。这里要提醒的一点是,事故其实是最好的达成共识并推动技术进步的机会。当然前提是,你们有良好的复盘习惯。 曾经写过的一篇文章“ 故障之后 ”,也许可以作为一个例子。

自组织的团队管理

团队之所以称为团队,因为他们在为一个目标而努力,因此我觉得愿景管理是第一位的。在此基础上,你需要建立规则来让协作更加顺畅,如果还能有些指标可以量化,那你的团队就可以在技术上保证公平,并且基本可以正常地运转了。

但这样的团队至少可能存在两个问题,一是管理者的单点,如果没人管理马上变为一团散沙;二是创新能力不足,因为团队的目标都来自于指派,并以此调动资源进行配合。

为了解决这些问题,我们正在尝试和探索新的方式,旨在发动所有成员的能动性,这就是自组织的团队。

在“ 自组织是不是团队管理的乌托邦? ”一文中详谈过这个问题,包括自组织相关的思维方式、创新问题、开发模式和团队管理等,有兴趣的可以看看。

有一点需要指出,就是跟赋权一节里讲的一样,管理者需要不断从具体事务中抽离出来,让成员之间自行形成协作,以摆脱对管理者的依赖。这样下去,管理工作才不至于越来越重。

希望EGO做好桥梁纽带的作用

期望EGO做一个真正属于技术人的学习型组织。

技术路越往前走,同行的人就越少。EGO把这帮人联系在一起,让这条路不那么孤单。我相信这只是起点。

EGO想要帮助技术人提高,学习就不可或缺。但这种学习未必是一个课程。就像前面提到的,技术人之间的交流本身就是学习的过程。当然,加上成员背景各异,你将更有机会通过他们了解不同行业和领域的信息,打开视野看另外的世界。

另一方面,我个人觉得,组织应该是属于所有成员的组织,应该在意所有成员的关切。所以如果你有想要学习的领域或者知识,都可以通过组织来寻找解决方案。而这也是我对自己作为学习委员的要求,我会帮助大家对接整个组织内的成员,让我们的专家发挥应有的价值,从而让每个成员都得到提高。

让EGO真正属于每一个人。

环信首席架构师梁宇鹏谈架构、管理及成长

正文到此结束
Loading...