7.1　业务服务化带来的问题

在2009年，阿里巴巴技术团队基于共享服务理念完成了对淘宝平台的服务化改造后，不管是业务部门的运营人员还是技术团队都沉浸在业务更快速的响应、更好地支持业务的创新的喜悦中，但上线后接下来两个月发生的事情却让技术人员始料未及。平台在出现错误的时候很难定位问题，甚至出现了问题没人承认。

为什么会出现这样的情况，根本原因就是业务的服务化。整个服务化后的淘宝平台各个服务间的服务调用关系变得纷繁复杂（如图7-1所示）。对这样复杂的服务调用关系以及每天海量的服务调用，而且所有的服务都是以“点对点”的方式进行交互，就自然会导致出现问题时很难定位。

图7-1　淘宝平台服务化后错综复杂的服务调用关系图

服务化后的平台，意味着用户在淘宝或天猫上任何一次页面请求都可能会造成后端很多台服务器间的服务交互和数据通信，还是以商品订单创建为例，说明应用进行服务化后带来的各种问题。

图7-2中展示了一次订单创建所需要调用的各种服务，其中某些服务（如图中用户校验、快递优惠、商品优惠）是通过订阅消息同时触发的服务，在整个订单创建的请求处理过程中，不仅仅有很多服务之间直接调用，同时还有服务同步和异步调用的并存，还会对数据库、缓存、分布式文件系统进行访问。也就是用户在前端进行的一次订单创建的操作，会造成后端几十台服务器之间的访问和交互，虽然在服务之间的调用都是有序进行的，但从最终体现看，服务之间的调用形成了一个网状关系。

在这样的服务调用状况下，假如“库存检查”服务出现了异常，就很难定位这次异常到底是在哪个业务场景中产生的。因为在淘宝、天猫订单创建场景中都会调用“库存检查”这个服务，而且每天会被调用几千万次，如何知道这次异常到底是在哪一个订单创建过程中调用所产生的？从实际生产环境所出的问题来看，很多问题绝不单单靠“库存检查”服务上的单机日志定位问题，必须非常清楚地知道该服务被调用所在的业务场景和具体的订单创建请求的服务上下文，才能定位问题。举例来说，当一个服务出现问题后，为了定位该问题，一般采用测试的方式希望重现该错误，但这个服务的开发人员怎么测试自己的服务都是没有问题的，与调用这个服务的前一服务两点间怎么测试也无法重现问题，而最后发现是服务调用链路上在当前出问题服务之前的第三个服务因为数据格式没有校验，造成了后面服务的异常。可以想象如果出现这样的问题采用传统的日志查看方式定位问题，就需要在海量的日志信息中花费很长时间进行日志比对，解决问题的效率会非常低下，甚至没法定位问题。

图7-2　淘宝订单创建服务调用流程示意图

除了对问题进行快速定位外，服务化过程中，不同角色的技术人员还需要一系列管控。

作为一个服务开发人员，当他开发的服务投入生产环境后，这个服务是否正常可能直接影响他的绩效考核。但作为整个服务体系中的这个服务，有可能如上述例子中那样同时在不同的业务、不同的场景中被调用，那如果你是这个服务的开发者，你一定会比较关心以下两个问题：

·我的服务在什么链路下被调用，调用场景和数据是否合理？

·目前服务调用趋势怎样？产生的瞬间峰值有多少？是否达到服务能力的最高水位？

同时，还有另外一类人群的工作也与业务服务化息息相关，那就是在阿里巴巴有一群称为业务架构师的资深专家，业务架构师主要负责针对业务的需求，通过对服务的组装设计出满足业务需求的服务调用链路，是典型的即能跟技术研发人员平滑沟通，也有足够对业务敏感度和精深理解的综合型人才。业务架构师是最直接为业务的稳定和用户使用体验负责的角色，但不能苛求业务架构师对所有参与这次业务请求实现的所有服务都了如指掌，每一个服务都有可能是由不同的团队开发或维护的，所以业务架构师会一直关心和思考以下几个问题：

·在当前的业务流程设计中，我依赖了哪些应用、哪些服务？

·整个链路的依赖路径是怎样的？哪些服务对当前业务处理来说是最为核心的？这些依赖如果出错，会有什么影响？

·一次业务请求处理的时间到底花在了什么地方？是因为某一个服务耗时很长，还是某一个数据库的访问操作耗时最久，需要有一个清晰直观的定位。

·我所负责的业务链路中，过去一段时间哪些服务是出错率比较高的，哪些服务是业务链路的处理瓶颈？

正是因为服务开发人员和业务架构师对于分布式服务调用跟踪方面的需要，阿里巴巴中间件团队历时两年多的时间打造了针对分布式服务调用链跟踪平台——“鹰眼”。

在业界，跟淘宝的鹰眼类似的平台有不少，如Twitter的Zipkin，这一类平台的实现都起源于Google Dapper论文（http://research.google.com/pubs/pub36356.html），感兴趣的读者可以查看该论文对此类分布式服务跟踪平台的原理实现有一个更详细的了解。在本书中会简要介绍鹰眼的实现过程以及今天阿里巴巴集团围绕鹰眼平台所打造的一系列的数字化运营能力。

如果我们把整个淘宝的分布式服务架构比喻为遍布全国的高速公路网络，每一次的页面请求都可以认为是一辆汽车在这个高速公路网络中穿行，把高速上的每一个收费站比喻为处理请求的服务。那么我们希望查看一辆汽车在高速上的行走轨迹的话，如何实现？最简单的方法就是在这辆车每次经过收费站的时候记录下车辆通过的时间和相关信息，并将这些信息统一发送到服务器端保存起来（如图7-3所示）。

图7-3　汽车通过高速收费口日志记录信息

当我们希望查看鲁A123BC这辆车的行驶轨迹时，只需从日志文件中查找出该车辆的日志信息，就能清晰地还原出该车辆的行驶路线和过路费等信息（如图7-4）。

图7-4　某辆车经过不同高速收费口日志记录信息

上面高速路网络和汽车的示例直观地展现了鹰眼平台的核心实现思路，就是通过一套分布式日志平台实现对服务调用链路的跟踪。今天的鹰眼平台记录了淘宝每天上千亿次的服务调用信息，日志信息来自超过500多个前端和后端应用，还有数百个数据库、缓存、存储，日志量超过3千亿行。同时以图形化的方式给服务的开发人员、运维人员、业务架构师提供了完善的服务调用跟踪信息，为服务出错后的快速定位、服务链路的性能优化、服务链路的流程优化等提供了非常有价值的参考数据。