阿里中间件需要怎样的架构师

本文为 100offer 发起的知乎 Live「阿里中间件需要怎样的架构师」活动笔录。主持人为 100offer 首席人才官康康，分享嘉宾为阿里中间件团队的高级专家姬风、自修。

康康（主持人）：我们曾经向很多优秀的候选人了解过他们的职业发展目标，很多人会说想做架构师。但是我觉得，走在架构师之路上，最重要的事情还是先去了解一下，资深的架构师、顶级团队的架构师是一种什么样的状态，才能让大家了解应该前进的方向。我们很荣幸地邀请到顶级技术团队，阿里中间件的技术 Leader 姬风和自修为我们进行分享。

一、阿里中间件为什么被称作「架构师的摇篮」？在阿里中间件团队有哪些职业发展的路线呢？

姬风：首先介绍下中间件背景。这个团队本身是淘宝的平台架构组，是随着阿里电商业务一起成长起来的团队。中间件一直支撑着世界上最大的电商交易业务场景，尤其是大家耳熟能详的双十一大促。

我觉得阿里中间件被称为架构师的摇篮的原因是：

一方面，支撑的业务场景的复杂度，有比较大的锻炼。比如：中间件团队参加和主持双十一备战，推动一些全局横向的项目，经常看到中间件一起和业务方的研发一起梳理系统的架构依赖和稳定性，一起解决业务上的难题、提升系统的可用性、扩展性和性能

另一方面是由于阿里业务的规模：

• 系统规模 – 业务有很多部分的核心压力是在中间件系统上的，比如数据库、消息、缓存和存储，非常考验研发在稳定性和性能上的设计能力，同时也需要考虑服务端能同时支撑上万个客户端，可以给其上的服务提供高并发，可以水平扩容，而且服务是不能停机的
• 使用规模 – 中间件产品会被上千个业务方使用，推动整个业务的升级的过程比较漫长，设计时必须考虑到后续的可持续维护和未来的扩展机制，这都是很可贵的经验

近年来我们在阿里云上输出的场景也带来新的锻炼。我们不仅仅服务于电商行业，也开始为阿里云的其他客户，比如央企、金融、制造、汽车各个行业提供我们的架构支撑，这也是一个很好的锻炼架构师的机会。输出中间件的同时也可以接触到各行各业的业务，了解业务方在做什么事情，这对架构师很有帮助。

康康：我们想深入问一下，在阿里中间件有哪些职业发展路线呢？

姬风：中间件主要还是以技术为主。

有一部分人会做技术团队的 leader。对于一个团队的技术 leader 来说，技术水平是不能差的。而且需要承担团队发展方面的判断，这关乎团队的发展，和其他同学的未来。我们 leader 需要对业务发展趋势有一定的判断，提前做一定的技术储备，避免业务的发展受到技术的限制。

还有一部分人做横向架构的事情。一般都会有跨团队、部门沟通，推进事情的能力，对技术落地的进度、风险有很强的把控力。

有一部分专精于技术领域。他们了解业界的同行并且能够对最新的技术趋势和走势进行预判，也会做产品的架构设计和解决方案设计。遇到困难的时候，这一类人会做技术公关充当救火队长的角色。

还有一部分偏向业务方面。通常都会对业务发展有较强的判断力和商业敏感度。这类人群会站在用户的角度思考、用产品的思路将技术进行抽象和封装，让技术更容易被他人使用。他们会让技术产生商业价值，因此通常是一个产品经理的角色。

在中间件，职业路线也不会非常死板，有些时候需要人才身兼多职，毕竟人员的发展也不会一成不变。”跳出自己的舒适圈”也是一种对于能力的锻炼。

二、阿里中间件的技术栈涵盖哪些范围？

自修：中间件的范围分为：

• 基础中间件

• 运维平台

• 稳定性相关平台

• 云产品服务

• 计算平台

• 存储平台

这个图，从下往上看技术栈，就会一目了然了。这些都是在一次次双十一中久经考验的产品。

图的底部就是阿里的 Iaas 层面面，主要包括了网络、机房。

往上就是存储层、数据库相关的，包括缓存 Tair、文件系统相关的 TFS、我们的框表 HBase、面向海量数据分析型的列式数据库 HiStore 以及面向于时间序列相关的 HiTSDB，还承接阿里巴巴整个交易平台过程中需要的关系型数据库 MySQL 和金融场景相关的 OceanBase。

再往上是应用层的运行容器，包括 Linux 和 Tomcat。

在往上，属于分布式的数据层，就是如何把海量数据进行分库分表，围绕这些数据库进行数据迁移。

再往上是整个的消息中间件，包括事务消息、顺序消息的中间件 Notify 和 Metaq。还有我们在集团中广泛应用的服务框架 HSF。

在向上，就是整个阿里巴巴应用的接入层了，包括 Tengine、LVS。

从图上再向右看去，我们会看到实时计算平台 JStorm 和之前提到过的分布式日志系统 EagleEye、TLog 和所有服务器上都在部署的日志收集器。

再向右，是资源管理/调度弹性/容器化系统。

整个左半部分，由中间件的这些技术，承接着所有的业务产品，包括淘宝、天猫、1688、AE、B2B以及圈子收购的子公司优酷、高德等等。我们将所有这些技术经验沉淀出了产品，并在云上形成服务。目前已经形成云产品的包括，EDAS、DRDS、MQ、TXC，以及面向监控的 ARMS 和时间分片的 SchedulerX，以及围绕这些服务的云产品中台。

三、所面对的技术场景和技术挑战有哪些？

自修：第一个挑战 - 11.11大促

我们每年都会在11.11的前4-5个月就开始进行演练。比如我们平时使用10台机器，在大促那天则需要100台机器。那么我们如何在11.11那天快速的建站？比如如何在 10 分钟内部署完毕？怎么在同城、异城进行容灾。对此我们其实有一整套的自动化工具。

中间件所有的服务加起来约有上百个。在上百个里面，举一个例子就是 Tengine/Nginx，熟悉的同学知道，Nginx 要配各种各样的域名、upstream 等。那么我们有一套工具可以快速的根据不同的机器负载、不同的机房设置形成快速的配置的修改、上下线等等。现在我们整个建站，包括底层的机房建设、IDC、网络、上层的中间件、应用层，在大促的前一天基本上可以在 10 个小时内完成。

第二个挑战 – 海量数据实时分析：

刚刚有同学问到，存储是如何压缩的。这里可能会涉及到不少有技术含量的东西，太细节的我就不说了，主要是通过以下几种手段：

1. 我们主要是通过列存的方式把数据 appendonly 上去。

2. 我们目前的数据库体系下面有 17、18 种对业务层透明高效的压缩算法。我们的低成本存储压缩比可以达到 10:1 左右。

面对海量数据，要做实时分析，其实是有非常大的挑战的，比如：

1. 业务系统中可能有许多维度，我们需要根据任意维度进行查询。

2. 面向海量数据时，如何在快速、实时、低延时地导入过程中，还能让业务方可用。

3. 整个阿里巴巴体系下，基本以 MySQL 生态为准的，如何兼容 MySQL

4. 以 MySQL 做海量数据实时分析的话，索引会越来越膨胀，其实会非常不适合海量数据的分析的。如何设计一整套的智能索引，低成本、高效地导入，还要有实时分析，其实对技术方面有非常大的额挑战

第三个技术挑战 - 海量数据实时写入

我可以举一个例子来说明这种挑战：普通的 SATA 盘，每秒钟也就能写入 500M 左右的数据，大家可以想一下，一小时才能写入多少数据。如何才能达到每小时 10T 的写入数据？大家可以算一下，这个差距是非常大的。

海量日志过来之后，怎么才能做到快速的收集、写入呢。

再分享一个技术挑战：

我们现在所有的系统，在它没有出问题的时候其实我们就已经能预测问题在哪里了。我可以从异常检测和根源上分析整个链路的问题。比如你在淘宝上下了一个订单，背后有几千个系统在流转，通过消息、RPC、数据库等等，万一链路出现一点点问题，在11.11那天的高并发量的情况下，怎么找出根源问题？

中间件深入研究了一个时间序列数据库，主要应用于系统监控、实时分析、面向未来物联网、车联网等领域的几大存储。这里面有几个重要的核心，比如无论你用哪种语言，无论是C++、Java，怎么把字节通过压缩的算法达到最高的压缩比而且最快的写入速度？我们可以通过自研的深入研究的压缩算法能够从 16 个字节 256 位降低到 1.37 个 byte。

一个亲身经历：

我刚到阿里中间件的时候发现一个问题：各个服务之间都是需要手动配置和部署、需要运维人员专门负责的。为此我深入研究了其中的问题，然后写了一整套的引擎，把各个服务之间从下往上的串联起来、配置全都自动化。之后一个实习生写了一个很漂亮的web页面，把整个服务并行启动。之后新来的员工就可以一键就可以开启所有的服务。这里面就包括了挑战，如何自动化、如何快速、如何分布式、如何高可用等等。

姬风：由技术形成产品的难度

刚刚自修谈到的挑战，我其实也有非常切身的体验，我这里补充一个非技术上的挑战场景吧，关于我们中间件的云产品。

我现在是 EDAS 和 ARMS 两个云产品的研发负责人，现在的云产品同时支持公有云和私有云两个版本。我一个比较深刻的体验师，从一个好的技术到好的产品，其实有很长、很难的路要走。

其实两年前做中间件，主要服务于内部业务，自己做研发和运维。这就好比以前手机只要保证信号好、待机时间长、声音清晰就可以了，外观反而并不那么重要。

但是中间件做完云产品之后就发现自己的客户群发生了变化，客户更多并且分布全国各地。有些对你的技术产品有足够的了解，而更多的则是完全不了解的。我们对客户的业务也更加陌生，因为客户已经不仅仅局限于电商。

这时的挑战就是怎么让这些客户一步步的掌握我们的技术架构并熟练的运用到他们的业务里面。其实这是对我们目前采用的这套分布架构的重新思考和总结。我们可以把以前自己认为很常见的一些常识性的东西转换为实际性的方法论然后教给我们的合作伙伴。

关于部署和运维的挑战

我们原本都是自己运维内部产品，集团内部的部署规模也是一套到几套而已。现在则需要我们快速的部署到客户环境里并且同时把中间件的技术产品和运维交给合作伙伴和客户去做。这是一个完全没有考虑过的挑战：整个运维的成本和问题的排查。

以前出了问题是阿里动手排查和使用调试工具、监控等等。但是现在客户场景里可能没有这样的工具，而我们也没有机会接触到客户的这些机器。而且有些客户环境比较复杂，甚至不会让我们登录。

我们的挑战就是如何积累一些平时排查的经验把它变成一个自动化的工具，再通过我们的监控数据进行自动分析，实现系统级别的弹性的扩缩和调度。让它能够在问题发生的时候自动发现并重新恢复，再通知合作伙伴。

四、中间件需要有何种素养的架构师？

康康：首先请自修老师，分享下阿里中间件架构师的胜任力模型

自修：

• 1.需要对业务有本质的理解，技术再牛逼，解决不了业务的问题也是没用的。所以一定要站在业务的角度去了解他们的需求，它到底是要并发高还是流量高，还是要分布式，还是要高可用

• 2.技术的广度

• 3.技术的厚度

• 4.经验丰富。其实经验丰富并不是由时间决定的，而是根据平时的学习、探索等方方面面组成的，这也就是为什么有些人会问”我的工作时间比别人长但是找不到工作”

• 5.沟通能力，因为团队协作需要良好的沟通

• 6.动手能力

• 7.市场洞察，需要观察整个业界在做什么、有什么新的发展、技术等等

• 8.领导力，能够团结力量然后为了同一个目标努力

康康：你觉得八个要点中最重要的是哪一个？

自修：业务理解最重要。刚刚列的顺序就是按照我心中的重要性的排列。

康康：为了获得胜任架构师的素养，新毕业的工程师通常需要多少时间或精力？

姬风： 我刚到阿里的时候其实没想过要做中间件。当时淘宝已经完成了服务化的转型，而我投入到这个团队里面也是帮忙做一些排查业务问题、调差性能等等琐碎的事。后来有一个机会可以支持整个服务框架的多语言调用。当时中间件以Java为主，懂非Java的人很少，我也只能硬着头皮上了。

但我觉得这段经历很宝贵，尤其是把服务框架涉及到的技术点从头到尾都用C语言实现了一遍。这对技术的提升很高而且可以更好的贴近系统底层并且了解更多的细节。这也算是一种技术的累积。

之后我做了一段时间淘宝的运维系统。那段时间正好是和阿里的牛人一起合作。在运维系统可以获得许多一线经验并且学习到牛人的技巧，比如他们怎么思考、架构上面有哪些问题、他们为什么要采用这样的技术手段来解决这些问题。当时更像是一种观摩的状态。

再之后我就做了Eagle eye的链路跟踪的产品。其实之前积累的这些问题排查和服务架构等等都在做新产品的时候有很好的帮助。如果没有之前的技术背景打底，我也不可能对产品有更深入的理解。另外这个阶段也是在开拓自己之前未知的领域。

因为Eagle eye涉及到的数据量非常庞大，所以在如何计算和存储的方面上自己也恶补了许多知识。现在回顾起来，其实当时自己也走了许多弯路。如果我当时是一个更有经验的构架师那可能就会少绕一些弯路，我也会对数据规模也有一定的敏感度，而这个产品也会更快一些。

再之后做链路跟踪产品然后满足了一些实时监控需求的时候，我们发现有许多客户会提出很多类似的业务需求。我们刚开始是在代码上做出修改然后上线。后来需求太多实在做不动了，我们一想这些都是通用的需求，是不是可以用一个更好的产品化的方式提供？我们对Eagle eye的技术做了一次重构和一个实时数据处理平台，并开放给业务方让他们配制出自己的流程。

刚开始是深入的积累，然后是跟牛人学习。这段时间里需要做很多的思考。最后会接触很多新的技术领域并深入拓展。

康康：架构师对系统底层需要了解到什么程度？

自修：这个可以从两个方面来回答。

如果偏向业务架构师的，那就需要对业务有深入了解，对业务需求有比较深入的了解。

如果偏向于技术栈架构师，那就需要对底层有深入了解，比如事件驱动驱动模型、异步模式、并行、Linux 系统等等。

除去刚刚讲的之外，还需要掌握经典的一些基础算法，哈希、排序、最短路径、矩阵运算与傅里叶变换、动态规则等等。

技术体系不同，架构师面对的技术栈也不同，比如说我，我必须要对海量数据分析这块有更多的了解，比如哈希索引、bitmap索引、布隆过滤器、数据库索引、MapProduce 等等

我总结四个关键词，围绕它们去形成一个全面的知识体系就离架构师的路不远了。

• 稳定

• 成本

• 效率

• 性能

康康：成为架构师的途径有哪些？

姬风：或许有很多人会感到困惑：「做架构师到底是技术还是业务？追求广度还是深度？应该去大公司还是小公司？」

其实怎么都可以，毕竟条条大路通罗马。我的建议是先做靠谱的事情，不要浮躁。对于交代下来的事情要认真、考虑的更全面、更积极主动、对事情做更多的反思。如果这些都能做到那么你已经可以超过 80% 的人了。

这些会帮助建立起一个靠谱主动的信任关系。关系建立后会带来更多的机会，而机会也会带来越来越大的挑战。这时专业知识会碰到许多原本没有覆盖过的地方，从而需要你去选择兴趣点和未来的倾向。在这段时间里可以多看看领域的同行的经验，学习他们的长处来找到自己要突破的技术点。在这段时间里也要有阶段性的产出，比如一些总结和分享，之后就会慢慢的成为一个专家。

往架构师方面发展需要培养判断能力和独立思考能力。你需要具备发展方向的判断、技术和业务能产生多少价值的判断、复杂度和可行度的判断、对人的能力的判断。而这些都是架构师需要考虑的方方面面。

在经过基础的锻炼后就可以从事一些基本的构架师工作了。这时开始就需要有意识的往全面性发展。你可以参加一些跨部门项目来了解别人的方案和自己的架构师设计来做对比。同时也不要放弃一线编码的工作，这会帮助保持自己的技术敏感度。比如最关键的编码部分应该有架构师来完成，因为这些地方会影响最后的成功与否。

康康：现实问题 – 公司技术架构不复杂的情况下，想成为架构师，平时工作中应该怎样学习累积？

姬风：我的建议是不要为了架构而架构。在这种技术架构不复杂的情况下，其实还有很多开源的产品、技术大会去看可以提升自己的架构能力，可以从中收获一些积累。也有可能业务架构比较复杂，这样就有一些机会在公司推动或验证比较完整的、从上到下从前到后的架构。这是大公司不能给到的麻雀虽小五脏俱全的机会。

如果想在生产系统上得到鲜血淋漓的教训的话，去阿里更适合一些，因为阿里有这样的场景和机会，在家里没办法体验到这种感觉。

康康：不少中高端技术人才层面临一个职业发展的困惑 – 技术路线和管理路线如何选择？是不是技术上要达到架构师的高度之后才能有资格跨入到技术管理人这样的管理角色？

自修：在阿里的体系里面 P 和 M 其实并不是分的那么清楚。我们所有的技术 leader 其实也负责 M 的职责。我举个例子，没有金刚钻怎么揽瓷器活。你需要在技术水平上达到一定的程度、在业务了解上达到一定的高度。公司也会对技术人员做一定的判定。

康康：在面试架构师时，如何考察？

自修：招聘的时候有 4 个关键词：聪明、乐观、自省、皮实

之后则是看硬的技能和资格，比如过往的经验、知识面、教育背景、做过的事情和我们的事情的匹配度等等。然后还有软的方面，比如情商、智商、兴趣点、偏好、特质等等。阿里的面试通常都会由很多面试官综合考核和判断候选人是否合格，包括分析你的技术、架构、情商等等。

我的建议是面试回答问题的时候答案不要太过圆滑和完美，如果你懂就直接回答，不需要绕过去。此外我们也会注意你平时会看哪些书、对未来的规划怎么样、团队中的协调能力、一些思考等方面。

姬风： 我通常会寻找候选人的那些可以打动我的亮点。我会问他们之前做过的项目，寻找一些代表性的能力。我也会看候选人的方案思考、选择的过程和结果，以及最后总结出了什么。能打动我的亮点就是他们的设计思路、表达清不清晰，比如像我这种不懂业务的人也能听得明白的描述。

我会看整个设计的架构、考虑思考的全面性、有没有考虑到风险点、上下游相关方要坐的事以及了不了解他们需要做的事情。我会考察候选人有没有在设计里为未来的需求预留铺垫。

也会根据阿里的业务提问来看看候选人的方案是怎么样的，我希望能看到基础能力和对框架的了解、技术的深度和广度的体现。同时我也关注技术上有没有保持好奇心、有没有跟进新的技术。

此外还有一些非技术的特质，比如：主动性、责任心、Ownership、沟通和推动

康康：因为架构安排人员，还是因为人员调整架构？

姬风：其实这个还是要看情况的，比较人员的背后都对应一个组织关系。对于初创公司或者团队来说，可以在架构制定出来之后安排任务然后划分人员。而那些涉及跨部门协作的，需要考虑人的问题，因为系统需要人的投入和维护，需要有一个平衡，比如架构落实之后人员有没有能力承担、有没有时间完成等等。

同时架构的边界也要划分清楚，最好根据组织架构再进行划分，否则会出现三不管地带。而且如果划分不准确会导致资源浪费、重复开发或冲突问题。因此就像我说过的一样，不能为了架构而架构，具体还是要看人员和情况。

Q&A

Q：Eagle eye 监控日记如何采样？存储如何压缩？如何权衡存储和计算成本？有什么优化手段？

姬风：Eagle eye 的监控日志是按照 trace ID 采样，它的好处是可以完整的保存数据。由于压缩是 high store 列式存储方式，有比较高的文本的压缩比。而链路日志主要是分析问题，所以不需要对所有的数据进行计算和存储，这样我们可以通过采样的方式计算和存储。从而对字段进行编码压缩、分析链路的形态对形态做压缩处理。

Q：如何沉淀排查经验？什么样的形式？一般的流程是：特征->问题->解决方案，怎么获得特征？怎么判断问题？怎么触发解决方案？

姬风：因为监控平时可以收到很多系统信息，而业务都是带有季节性的，所以信息都是带有季节性特征的。这样就可以抽取出一个模型，甚至提炼出公式。根据公式的分析我们可以做一些数据预测。当我们发现预测的数据和实际上发生的模式不一致时，就可以判断出来这个时候会发生问题。我们将根据排查出来的问题归类，然后反推它会产生什么样的特征，最后通过特征可以推倒到解决方案。

Q：能否谈一下阿里内部微服务架构的技术栈？对于类 dubbo 的 rpc 框架使用和 spring cloud 全家桶的对比？

姬风：阿里主要还是推 dubbo 的 rpc 框架。不过今年阿里也会在云产品上基于 spring cloud 提供一个完整的基于中间件的一套分布式的实现，让我们的外部客户可以基于spring cloud 的这种 api 开发，但是又具备中间件的技术支撑能力。

Q：消息中间件的可靠性达到了多少？

姬风：这个还是要看它的存储的。如果它是单份的，那么可靠性就是4个9。而随着备份数、冗余数的增多，可靠性也会上升。

Q：在中间件团队中有 PM 的角色吗？还是 Architect 就承担了 PM 的工作？

姬风：中间件团队其实没有专职的PM角色。如果要做跟业务有关的项目，有些人可以承担PM的角色。因为PM会专注于业务的结果，而架构师可以在技术上面保障业务的结果。由于平时是没有PM角色的，所以一般都是架构师自己去承担的。

Q：能否谈一下 OSGI 这个技术的未来？是否是个不实用的技术？

姬风：目前不是特别流行。中间件曾经使用过 OSGI 做中间件的类隔离容器，不过 OSGI 的使用人群并不多，而且新人加入的时候学习成本也比较高，所以后来我们自己做了一个类隔离容器，OSGI 就不怎么使用了。不过未来Java也会自己推出一个新项目的，而它的新版本也已经具备了类似 OSGI 的功能了。

Q：推荐一些值得学习的书籍？

最近阿里出版了一本《沉浸在双十一》，我自己看的一些书还有《系统的思考》《邓小平时代》《三体》《浪潮之巅》《数学之美》《在线》

Q：作为中间件运维从业者，想要进阶到架构师是否需要开发经验？

姬风：如果没有开发经验很有可能会对系统底层的知识不太了解以及对架构的经验可能会比较浅。我的建议是尽量具备一些开发的经历和深度的专长。

Q：在使用一些开源技术组件的选型上，阿里团队会考虑哪些方面，使用什么指标评估呢？

姬风：通常我们会使用一些社区上比较活跃、成熟度比较高的产品。这样我们就可以投入到社区里去做一些回馈。在选用了开源组件之后，我们内部也会有人去研究它的代码然后继续的维护下去

Q：这个中间件和阿里的中台是否是类似的？

姬风：中间件是中台里面的一个部门。

Q：阿里中间件技术团队以后会在深圳这边设立部门么？

姬风：中间件是主要以杭州为主，北京也有不少，不过深圳目前没听说过有计划。

Q：阿里自己研发 rocketMQ，如何评价 kafka，kafka 这个级别应用能满足阿里性能要求吗？

自修：我们所有的 rocketMQ 目前都是支持 kafka 接口的

今年，100offer 开始利用知乎 Live， 分享职业发展中的专业经验与优秀团队内部情况，可以前往「100offer 活动中心」查看更多 100offer 发起的知乎 Live。