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

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

擅长的领域

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

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

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

后端服务的云化不可阻挡

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

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

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

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

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

不要奇怪。

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

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

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

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

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

架构师与程序员的差别

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

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

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

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

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

最有成就感的事

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

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

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

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

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

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

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

技术人要找到自己的道路

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

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

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

提倡社区分享和交流

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

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

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

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

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

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

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

自组织的团队管理

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

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

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

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

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

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

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

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

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

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

让 EGO 真正属于每一个人。