专访阿里云高级专家赵林：从 0 到 1，中间件的研发运维之路

中间件，英文名为 Middleware，它提供应用层和系统层之间连接，是应用层实现系统资源集中调用的抽象逻辑，同时协调各个应用之间的沟通；并且自动处理分布式系统中的常见异常，最终简化大规模分布式应用的编写。

早期的中间件，起源于 1968 年 IBM 的 CICS（Customer Information Control System ）交易事务控制系统，是一个分布式的文件服务用来管理用户信息。伴随着互联网发展和分布式系统的兴起，中间件的概念也在发生演变。在分布式网络环境下，中间件面临更复杂的情况：如何解决众多应用复杂依赖的问题？如何屏蔽分布式系统的技术细节？新时代的基础中间件会追求更高性能、更强的可用性和扩展性。同时，在基础中间件基础之上，需要建立分布式系统的数据化运营能力，以及整个业务系统的高可用架构设计能力。

互联网时代，大多数企业都面临着 IT 构架转型的阵痛。一方面，业务创新受阻：传统构架建设周期长，信息孤岛现象严重；另一方面，系统处理能力有限：如果业务发展起来，传统的集中式系统很难及时扩容，导致无法处理不断增长的并发量。分布式系统将成为不可回避的选择。

为什么阿里云把中间件作为进入企业级市场的重要武器？InfoQ 就中间件的技术实现对阿里中间件高级产品专家赵林进行了采访。

受访嘉宾介绍

赵林，花名丹臣，中间件高级产品专家。2006 年加入淘宝，负责淘宝产品 DBA 团队，维护淘宝生产数据库；2009 年开始推动和设计了淘宝许多核心业务的去 IOE 历程； 2012 年转岗到中间件团队，从 0 到 1 建立起中间件云产品团队，主导了一系列的中间件产品上云及商业化，完成了一些重要客户项目的业务拓展和项目支持。

InfoQ：可以简要介绍下阿里中间件的研发初衷和历程吗？

赵林： 阿里在 2003 年 -2006 年的时候是单机的集中式的系统，采用的是 IOE 架构（IBM、Oracle 和 EMC）。随着业务的发展，传统构架的弊端逐渐显现：上线慢（高端设备的采购周期长、不能快速扩容），故障多（高并发的情况下系统的稳定性出现了多起严重的故障），成本高。技术不能束缚业务的发展，为了改变现状，2008 年 -2010 年阿里研发基础分布式中间件三大产品，大大提升阿里的业务研发团队构建分布式系统的效率。我在阿里工作十年，前五年负责维护淘宝核心数据库，见证了淘宝从只有三个数据库演化为现在的几千个数据库；近五年都在做中间件，目前负责中间件的云产品团队。

在研究分布式系统问题域的时候，我们是从分布式系统基础中间件开始入手的。当时业界对中间件的认知和今天还不一样，可供参考的资料非常少。在 2007 年到 2008 年，我们研发了三个最早的中间件：

• RPC 远程过程调用框架
  初期是一个比较简单的框架，后期改进成现在的 HSF 框架支撑了生产环境所有系统的服务化调用。目前阿里云 HSF 服务框架采用了去“中心化”的系统架构，服务的提供者和调用者都直接相连，不仅去除了中心单点的风险，还能大大提高调用效率。峰值时，每分钟调用次数可以达到 25 亿次。

• MQ 消息中间件
  在传统的拓扑结构中，系统不同业务之间的依赖性过强过多。举例说明：如交易拍照、发旺旺消息等业务，依赖于下订单这个业务；数据处理流需要经过不同的业务模块，一旦其中某个模块出现问题，就会有整个网站下不了单的风险。加入消息中间件后，处理流程发生了改变：不同模块之间无直接关联，通过消息订阅的方式获取信息。交易中心只负责下订单写数据库操作，其他中心则只需订阅交易中心的消息。这很大程度上提升了分布式系统的健壮性。

• 分布式数据库
  分布式系统中会有很多很小的数据库。为了减少上层应用开发难度，需要屏蔽底层数据库的形态，使得应用系统开发人员无需额外留意这些细节。设计分布式数据库需要注意三点：

  1. 业务拆分：根据系统的业务特性，拆分业务核心表数据，其中 Partition Key 的选择很重要。需要找到最适合自己的拆分方案。
  2. 拆分数量： 如何确定数据库和表的拆分个数？一方面需要判断业务能力的现状，这需要基于当前单个分库的业务处理能力；另一方面需要预估将来的业务，为扩展做准备。
  3. 存储方式：对数据库类型的选择，是常见关系型数据库（如 MySQL），还是 NoSQL 非关系型数据库（如 HBase）？数据是否可以采用高压缩存储以降低存储成本？(如日志数据、历史数据、物联网数据等，便可以采用高压缩存储)。根据不同的业务场景，选择不同的数据存储。如果业务场景于存储产品的技术特性非常契合，那么系统就可以发挥出最好的特性。

InfoQ：在中间件研发过程中，开源技术起到怎样的作用？

赵林： 淘宝早期没有直接构建分布式系统有两个原因，一是自身技术积累不够，优先发展业务为主 ; 二是因为当时外界没有什么开源技术可以用。开源技术在分布式系统构建初期帮助很大；而如果后期业务发展起来了，则需要对开源产品有更多的掌控能力，最后就回归到自主研发的能力上来。

在我看来分布式系统分为三个层次：

• 简单的非大规模分布式系统
  运用开源技术可以构建一个简单的分布式系统。
• 数据化运营的大规模分布式系统
  构建一个更大规模的分布式系统，必须就进行数据化运营。目前大家都在讲业务如何数据化运营，其实分布式系统也需要数据化运营。第一种层次那种简单的分布式系统，近乎一个黑盒子：我们不知道它是怎么运行的，一旦出现问题，就是黑暗世界的降临。早期时，阿里的数据化运营很基础很粗糙，比如会做一个产品统计各个主要接口的访问量或者交易数据，然后与前一天的数据进行对比判断系统有没有出现问题；后期我们又将它做为实时的。数据化的好处是你可以清晰地感知变化，这对于淘宝这样大体量的公司来讲很重要，轻微的数字浮动就是很大的影响。
• 高效运维可精确定位问题的分布式系统
  数据化运营可以及时发现系统问题；那么接下来如何改进这些问题，维护如此庞大系统？这时就需要借助于运维，在出现问题的时候，团队可以心里不慌，可以快速定位问题根源。我们实现了全链路跟踪系统：实现所有服务各个模块端到端的数据采集，为各个产品建立全链路的监控。（相关详情可参见 2014 年的阿里云监控体系现状概览一文。）

很多阿里自主研发的中间件现在是开源的。比如，远程过程调用 Dubbo、中间件消息 RocketMQ 和分布式数据库 Cobar 等。阿里技术氛围是很开放，大家也可以看到阿里在国内外做了很多的技术分享。

InfoQ：您刚才提到了阿里云实现了全链路跟踪，最开始是怎么会想到研发分布式系统的全链路跟踪？系统实现高效运维是得益于此吗？

赵林： 最早时基础中间件这一层是没有运维的，但在内部场景使用中遇到了好多问题，于是就开始开发越来越多的组件进行运维监控，组件慢慢沉淀下来就和我们中间件融合在一起。如果没有这些运维模块的话；系统是没有办法支撑起阿里如此多如此广的内部业务的，更无法谈及上云之后服务众多大中小企业。现在，经过这么多场景的历练，中间件产品已经很完整了，这层运维做得好、易用且成本低。

全链路跟踪，即从入口处开始到流经的所有系统的所有节点，都通过可视化的方式串起来。这样可以快速定位系统出现了哪些问题。

关于系统高效运维，这里再拿消息中间件的消息轨迹追踪举例：从消息的发送开始，它发到哪些 topic，有哪些订阅方，订阅方有哪些机器，被哪些机器消费，最终是消费成功还是失败。如果有机器消费失败，需要再次投递到所在集群中的另外一个机器上去，直到集群中至少一台机器消费成功，才会停止投递。如果一直投递失败，就会按照一定的策略进行不断地降级投递服务。

不过，对于企业级互联网架构，只有全链路跟踪系统是不够的，还需要一个自助式的在线压测系统。如果在开发的时候做压测，得到的结果数据不是真实的，因为这个和实际的生产环境是不一样的。我们需要压测平台与中间件基础设施相结合，自动去导流量，用它去推测每个接口每个节点到底能够实现多大的业务能力，最后再清晰地算出来结果：以这个科学数字的方式合理分布资源，告知各个业务线当前业务量是多少，是否需要对一些应用进行扩容或者缩容。

InfoQ：对各个应用组件进行全链路的监控，这意味每一个产品在开发时都要实现运维部分？

赵林： 是的，基础中间件都是自带运维的。比如 MQ 消息中间件，这是一个很广泛的产品。阿里的创新点在于实现了消息轨道追踪。消息的产生和投递、发送消息的中间件、最终投递的各个消费方、投递到消费方的哪台机器、投递次数和结果，都会清晰地显示出来。这些链路工具和 MQ 中间件是组合在一起，放在阿里云上提供给用户，这样用户的体验才是完整的。

换个角度来讲，这也是阿里中间件都变成了云服务的必要条件。否则的话：一、根本无法知道问题出现在哪里；二、客户不能每次出现问题都来找我们，不能为每个客户都配备一个中间件技术专家。一个技术产品要真正变成一个云服务，方方面面都是要做细的，要让其完整并成为真正的应用服务。如果每个客户使用过程中小小的问题还需要和产品研发团队交互；那么这就是能力很弱的产品，它不能去服务越来越多的客户。

InfoQ：那阿里采用的是将开发和运维融合在一起的 DevOps 文化吗？

赵林： 这是必须的，因为我们有太多的场景需要这个能力。我知道现在很多的大公司，基本上开发和运维还是分开的，阿里几年前也是这样的，但是现在我们在融合各个团队实现 DevOps。

做产品研发，不是说只做个 App 就大功告成了，因为服务端还不具有这样的能力。服务端去改起来还是很麻烦的。应用集群变大之后，如果一个应用有成百上千台机器的时候，连一个简单的发布都是个问题。快速发布、快速回滚，有可能需要半天或者一天，这是一个非常现实的问题。如果想发布应用，那就必须把应用的所有管理和监控都做出来。

产品功能开发出来就需要运维，不能丢给别人去运维；其对应的运维工具本来是一个产品不可或缺的部分。打个比方，这好比生孩子容易，养孩子难。通常在开发团队在自己维护的过程中，遇到一次什么样的故障，知道整个系统中有哪里需要补，这里是不是需要加一个端对端的全天候监控，那里是不是需要补一个权限漏洞：就这样一点点地形成一个更加丰富完整的体系。真正把一个系统给运维好是需要很深厚的功力，开发运维那些周边工具所花的时间精力，很可能比研发中间件核心花的时间还要多很多。

InfoQ：阿里云的企业级互联网构架图中，在中间件的业务能力这一层，业务服务被分成了不同的模块。这些模块的拆分是出于什么考虑呢？

赵林： 2008 年之前业务发展很快，没有更多的研发力量投入到基础技术的研究当中。那个时候是怎样实现更快，就怎样做。

后来开始一点点将不同的业务中心拆分出来。拆分业务时，需要特别警惕一种做法：核心应用错误地依赖非核心应用，这会导致本来应该有的弱依赖成为强依赖。我建议所有的分布式系统，都应该最先拆分用户中心。现在很多公司的系统仍然没有独立用户这一块，他们面临着和阿里当初的一样的情况：在建立分布式系统时，可能各个模块都在连接底层的用户库。这时其实用户的数据安全是没有办法保障的。因为，一无法知道谁改变了用户数据、改得有没有问题；二如果有问题，想去查也不知道怎么查。

2007 年我们拆分了用户中心。用户中心统一接管用户数据的所有访问，其他系统不允许连接用户数据库。此外，将用户中心独立出来，也可以做缓存等性能上的统一优化，省去了上层优化的成本。这同时解决了安全和性能的两方面问题。

从最开始时只有两个业务系统，然后一个一个地拆分业务应用，到最后有几千个应用。在有几千个应用的时候，应用之间依赖是很复杂的，业务系统交互的流程图是画不出来的。同时随着研发人员增多，开发代码的维护也增加了不可控性。如何管理这样的系统变成了一个新的挑战，如果能把这个问题处理好了，那么我认为分布式系统一定变成个很好的东西，它可以并且一定会支撑更大的业务量。

InfoQ：几千个应用，是怎样实现持续性部署？是基于 Docker 做到的吗？

赵林： 关于持续性部署与 Docker 之间关系的问题：一方面，我们中间件本身的部署，支持 Docker 化的部署，但是同时也支持物理机和虚拟机的部署。而另一方面，对于用户的应用，采用的是与 Jenkins、SVN 等工具的无缝对接，完成研发各个环节的持续集成。阿里云提供的企业级分布式应用服务 EDAS，可以支持用户应用的 Docker 化部署。此外，为了提高开发者体验和研发效率，我们提供了许多插件。例如改变代码无需重启就可以立刻生效，这对于一些大应用的研发格外重要。

关于 Docker：客观上讲，Docker 只能解决一些最基本的应用部署和监控问题；但是如果你真正要把一个大型分布式系统构建并且运营起来，就需要自主研发的中间件或者利用一些成熟的开源中间件产品，因为 Docker 本身并不能解决这些问题。

InfoQ：研发接下来努力的方向是什么呢？

赵林： 提高系统的效率。当规模小、服务器比较少的时候，优化效果不是很明显；但是当机器达到十万台以上规模的时候，优化 10% 就是优化了一万台机器，这就意味着可以为公司节省下来好几个亿的成本。现在很多公司不管是在线业务还是离线业务，服务器处于空跑阶段是很常见的问题。

因此利用技术手段提高资源的利用率，就成了我们一个非常重要的课题。国外像谷歌这样的公司，他们的机器利用率很高，可以达到 40%-50%；我们总体上还是比他们落后一些，我们会继续不断地提高存储和计算效率。

感谢郭蕾对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们。