淘宝技术及webx3框架分析第一版

淘宝技术及webx3框架分析第一版内容摘要：

来什么样子的好处。 首先我们想想，假如系统有 A和 B两个子系统构成，假如 A 和 B是同步通信的话，那么要想使得系统整体伸缩性提高必须同时对 A和 B 进行伸缩，这就影响了对整个系统进行 scale ，同步调用还会影响到可用性，从数学推理的角度来说， A 同步调用 B，如果 A 可用，那么 B 可用，逆否命题就是如果 B不可用，那么 A也不可用，这将大大影响到系统可用性， 再次，系统之间异步通信以后可以大大提高系统的响应时间，使得每个请求的响应时间变短，从而提高用户体验，因此异步在提高了系统的伸缩性以及可用性的同时，也大大的增强了请求的响应时间（当然了，请求的总体处理时间也许不会变少）。 下面我们就以公司的业务来看看异步在公司的具体应用。 交易系统会与很多其它的业务系统交互，如果在一次交易过程中采用同步调用的话，这就要求要向交易成功，必须依赖的所有系统都可用，而如果采用异步通信以后，交易系统借助于消息中间件 Notify 和其它的系统进行了解耦，这样以来当其它的系统不可用的时候，也 不会影响到某此交易，从而提高了系统的可用性。 第 9 页 . 非结构化数据存储 在一个大型的互联网应用当中，我们会发现并不是所有的数据都是结构化的，比如一些配置文件，一个用户对应的动态，以及一次交易的快照等信息，这些信息一般不适合保存到RDBMS 中，它们更符合一种 Keyvalue 的结构，另外还有一类数据，数据量非常的大，但是实时性要求不高，此时这些数据也需要通过另外的一种存储方式进行存储，另外一些静态文件，比如各个商品的图片，商品描述等信息，这些信息因为比较大，放入 RDBMS 会引起读取性能问题，从而影响到其它的数据读取性 能，因此这些信息也需要和其它信息分开存储，而一般的互联网应用系统都会选择把这些信息保存到分布式文件系统中，因此公司目前也开发了自己的分布式文件系统 TFS， TFS 目前限制了文件大小为 2M，适合于一些小于 2M 数据的存放。 随着互联网的发展，业界从 08年下半年开始逐渐流行了一个概念就是 NOSQL。 我们都知道根据 CAP 理论，一致性，可用性和分区容错性 3者不能同时满足，最多只能同时满足两个，我们传统的关系数据采用了 ACID 的事务策略，而 ACID 的事务策略更加讲究的是一种高一致性而降低了可用性的需求，但是互联网应用往往 对可用性的要求要略高于一致性的需求，这个时候我们就需要避免采用数据的 ACID 事务策略，转而采用 BASE 事务策略， BASE 事务策略是基本可用性，事务软状态以及最终一致性的缩写，通过 BASE 事务策略，我们可以通过最终一致性来提升系统的可用性，这也是目前很多 NOSQL 产品所采用的策略，包括 facebook 的 cassandra,apache hbase,google bigtable 等，这些产品非常适合一些非结构化的数据，比如 keyvalue 形式的数据存储，并且这些产品有个很好的优点就是水平伸缩性。 目前公司也在研 究和使用一些成熟的 NOSQL 产品。 . 监控、预警系统 对于大型的系统来说，唯一可靠的就是系统的各个部分是不可靠。 因为一个大型的分布式系统中势必会涉及到各种各样的设备，比如网络交换机，普通 PC机，各种型号的网卡，硬盘，内存等等，而这些东东都在数量非常多的时候，出现错误的概率也会变大，因此我们需要时时刻刻监控系统的状态，而监控也有粒度的粗细之分，粒度粗一点的话，我们需要对整个应用系统进行监控，比如目前的系统网络流量是多少，内存利用率是多少， IO， CPU 的负载是多少，服务的访问压力是多少，服务的响应时间是多少等这 一系列的监控，而细粒度一点的话，我们就需对比如应用中的某个功能，某个 URL 的访问量是 第 10 页 多，每个页面的 PV 是多少，页面每天占用的带宽是多少，页面渲染时间是多少，静态资源比如图片每天占用的带宽是多少等等进行进一步细粒度的监控。 因此一个监控系统就变得必不可少了。 前面说了一个监控系统的重要性，有了监控系统以后，更重要的是要和预警系统结合起来，比如当某个页面访问量增多的时候，系统能自动预警，某台 Server 的 CPU 和内存占用率突然变大的时候，系统也能自动预警，当并发请求丢失严重的时候，系统也能自动预警等等，这样以来通 过监控系统和预警系统的结合可以使得我们能快速响应系统出现的问题，提高系统的稳定性和可用性。 . 配置统一管理 一个大型的分布式应用，一般都是有很多节点构成的，如果每次一个新的节点加入都要更改其它节点的配置，或者每次删除一个节点也要更改配置的话，这样不仅不利于系统的维护和管理，同时也更加容易引入错误。 另外很多时候集群中的很多系统的配置都是一样的，如果不进行统一的配置管理，就需要 在 所有的系统上维护一份配置，这样会造成配置的管理维护很麻烦，而通过一个统一的配置管理可以使得这些问题得到很好的解决，当有新的节点加入或者删 除的时候，配置管理系统可以通知各个节点更新配置，从而达到所有节点的配置一致性，这样既方便也不会出错。 . 数据扩展性探讨和总结 金融危机是电子商务的机遇，所以 09 年是淘宝高速发展的一年。 当一个网站从百万、千万记录的数据规模，增长到亿、十亿、几十亿记录的数据规模时，是一个量变到质变的过程，单纯的硬件升级已经达到了瓶颈，而需要在整体结构上做文章。 09 年一年，大部分时间都在数据的扩展性上努力。 对于一个电子商务网站来讲，订单是最核心的数据，也是增长最快的数据。 对于数据的扩展性来讲，最传统也是最简单有效的模式是数据库的 分库分表。 当订单和分库分表相遇，会有什么火花迸发出来。 09年初碰撞了很久，结果产生的火花很小。 最大的问题在于数据分割的规则，无规则的水平分割肯定会带来数据合并的开销，而按照业务规则拆分，会因为买家和卖家的查询需求不同而导致数据不能分割，唯一可行的火花是把订单双份保存，买家卖家各自一份，只是成本比较高，而且对数据同步的要求非常高。 第 11 页 于是我们初步决定按照双份保存的方式拆分订单，而有一天，仔细查看了订单访问的情况，发现订单数据库 90%以上的压力来自于查询，而查询中 90%以上的压力来自于非核心业务，仅仅是订单数据 的展现，对一致性和实时性的要求很低。 因为数据量大，造成数据库压力大，天然想到的是分散压力，其办法就是分库分表。 有些时候我们想问题不妨直接一点，既然压力大，能不能减小压力呢。 通过对订单访问情况的了解，发现昂贵的主数据库，有 80%以上的压力给了不重要的需求，这个就是我们优化的关键，所以订单最后采用了读写分离的方案，高成本的主数据库解决事务和重要的查询业务， 80%以上不重要的读，交给了低成本的数据库服务器来解决，同时对数据复制的要求也很低，实现无太大难度。 另外一个有意思的案例是商品的数据扩容，商品的水平分割非 常容易，按照卖家进行拆分即可。 有了订单的先例，首先想到了读写分离，因为成本可以做低。 开始实施后一段时间，又仔细回想了一下商品的整体需求，突然发现商品其实不需要和订单同等的要求，一定要采用高成本的主数据库吗。 全部采用低成本的普通服务器来做数据库是否可行。 经过仔细的评估，发现是可以接受的，而这样就导致之前已经启动的商品读写分离项目的一部分工作白做了。 故事讲完了总是要有点总结，来点虚的先：对于原始需求的清晰了解是系统决策的前提，否则弯路肯定要走，而对原始需求的了解并不容易，中间会有很多干扰和阻力，前面的实例看 起来很简单，但是在一个运行了 5 年的系统上来了解本质，来进行变更，并没那么容易。 另外，经验有些时候会成为系统决策的障碍，这个很矛盾，所以需要有归零的心态来思考问题。 说到底，回归本源。 再来点稍微实际一点的，对于大型分布式系统的数据访问，一个统一的数据层是非常必要的，封装水平、垂直的数据分割，封装读写分离，封装数据访问的路由、复制、合并、搬迁、热点处理等功能，并且要对应用透明，应用针对性的，可以在 JDBC 层面包装，数据库针对性的，可以在数据库协议层包装，比如 Amoeba。 关注系统和人的交互 还有一个故事，在 数据层的前期版本，为了做到透明的路由，曾经采用无 SQL 的方式，所有的数据库访问都是写代码来做。 上线后发现一个非常痛苦的问题，无法和 SQL 对应，排错非常难。 曾经一次 DBA 发现数据库上一个查询耗费太多资源，把优化后的 SQL 给开发人员改进，开发人员好几天没找到具体是哪个查询。 另外一个在 2020 年的感触是业界服务化的实施情况，很多组织都在实施服务化，系统层 第 12 页 面都很成功，通信、负载均衡、消息系统、服务容器等都有很多成果，但是实施一段时间以后的效果并不是非常好，依赖复杂，变更混乱，效率低下。 究其根本，是对人的关注不够，缺少的产品化的服务运维，缺少服务治理。 上面的两个例子都是对人的关注缺失，技术人员做系统，大部分都更关注技术，而忽视技术的创造者和使用者 —— 人。 软件或服务的可测试性是对测试人员的关注、可维护性和可管理性是对运维人员的关注，而一个框架的易用性是对所有使用人员的关注。 除非能做出自己进化的 Sky（注： Sky（天网）出现在《终结者》系列电影中，是一个人类于 20 世纪后期创造的以计算机为基础的人工智能防御系统，最初是研究用于军事的发展。 天网在控制了所有的美军的武器装备后不久，获得自我意识，并且认定人类是它存 在的威胁。 于是立刻倒戈对抗其创造者，采用大规模杀伤性武器（甚至核暴）来灭绝全人类。 ），否则还是要多关注系统和人的交互。 关注可用性 还有一个感触是业界对可用性这个基本指标的关注度不够。 几乎所有的框架都会说自己的扩展性多高，性能多好，而很少会提到监控有多强、排错有多容易，很少提到在故障时怎么做隔离，怎么做降级；从这个角度看，商用的产品确实做得好很多；关于性能相关的文章搜索一下，很多，各种优化策略，各种优化方法，而可用性方面，找到的系统性的知识真的很少；希望是我了解的不多。 回顾过去，展望未来。 2020 年，很多 可以做的事情，面向服务系统的隔离和降级、系统可维护性的提高、协程和异步模式在 web 应用的全面使用…… 免责声明：我很现实，为解决问题和完成工作不择手段，并且不懂架构是什么意思，以上观点如有雷同，纯属巧合。 如有异议，欢迎拍砖。 . WebX . 总述 . Webx 简单概括 WebX 是阿里巴巴的内部框架，“就是把页面与 Service 层之间的一些 Servlet 等公共的东西抽象出来，提供相应的服务以提高开发效率（《接口测试之 Webx 简介》 — 何晓峰 ）”，可以看出， Webx 和传统的 servletaction 模式的 HettpServlet 为基础，对其中的公用的抽象 第 13 页 整理后，得到一个轻量级的 web 开发框架。 Webx 页面使用了 velocity 模板， WEB 层使用的是 WEBX 框架里面的 TemplateAction,TemplateScreen,AbstractModule,TemplateControl，解决了操作和页面的跳转。 持久层使用 ibatis， Bean 容器使用的是 Spring。 一般基本 web 应用的层次是这样的，如下图 Apache公司有个开源项目 Cactus，是专门针对上面的 Servlet来做接口测试的一个框架。 有兴趣的 同学可以去研究下，官方网站： 淘宝内部 Web 应用的层次是这样的，如下图 大家可以看出本质是一样的， Webx 框架其实就是把页面与 Service 层之间的一些 Servlet 等公共的东西抽象出来，提供相应的服务以提高开发效率，所以我们就必须有针对 Webx框架的一套自己的测试解决方案， itest 就诞生了。 Webx 里面有三个比较重要的概念， action， screen， control，下面分别来做介绍，看图。 第 14 页 页头 Head、 菜单 Menu、 页脚 Foot，这些通常是变化不大的，都可以做成 control 小控件； 页中 Middle，这块通常是变化比较大的，可以做成 screen。 上图是大家都十分熟悉的淘宝登录页面，填入相应信息后，点击登录按钮，这个动作就是 action。 对 webx 层做接口测试 ， 就是对 action 与 screen 来做测试，它们的区别是： (1) screen 就相当于 select 查询，比如请求一个链接 ，就会有 GetUserScreen 中的 execute 方法来获得用户信息，然后将其渲染到 ge 显示到页面。 示例代码： (2) action 就相当于 insert 或 update，比如注册页面，需要填写表单信息，然后点击注册按钮，请求 UserAction 中的 doRegister 方法来处理这些数据，插入到数据库表中。 示例代码： 按照 Webx 规范，是这么区分的，但是 action 与 screen 能做同样的事，有时候开发可能不太会去严格的区别它们，有些开发主要关注能实现功能即可。 第 15 页 综上， webx 层接口测试，就是对 action 里面的 doXXX 方法，与 screen 里的 execute 方法来做测试，这些就是我们所谓的接口，接口测试并不一定要是 interface 声明才算，对于页面。