《淘宝业务发展及技术架构》分享

1、 主持人：今天我们特别请来淘宝资深技术专家范禹给我们分享淘宝业务发展及技术架构，接下来时间交给范禹，大家欢迎！ 范禹：大家下午好，首先感谢刘警给我这个机会跟大家做技术交流，接下来我开始讲一下，花名叫范禹，现在在淘宝技术研发部产品技术业务平台团队，今天的主要内容分为下面几块，因为主题叫淘宝业务与技术发展，前面业务会简单提一下，然后介绍一下淘宝前期技术发展过程，然后是最近几次比较大的技术结构上的变化，还有当前面临的挑战和问题，最后是讨论时间。 淘宝业务很多，我们有主站交易，有搜索，有广告，数据平台等很多相关业务，我是做主站交易平台，主要是java系统，我更多是讲这块，其他像开放平台、搜索、广告不大

2、会涉及到，我看问题中有位同学问我p4p广告如何定位到目标用户的，这个我不太知道，如果有兴趣可以邀请相关同学给大家做一个交流。 淘宝是03年成立的，这是淘宝03年的页面，ued的同学发给我淘宝历年的首页，这个页面我第一次看到觉得还不错，很有欧美网站的风格，这就是03年淘宝刚创立时候的样子，里面像买家通道、卖家通道、淘宝者联盟，淘宝者联盟可能并不是现在的淘客，应该是那时候的一个社区，03年5月份的时候淘宝推出，那时候的页面是这样子，当时是比较简单的购物网站。 （taobao2004）接下来就到了04年，从右上角导航上看，其实主体框架已经定下来，我要买、我要卖、我的淘宝，这几块功能这么多年来都没有大

3、的变化，可能是交互或者说用户体验上的改变，但是它的功能可能并没有特别大的变化。 04年在业务上我认为有两块比较重要的东西，一个是旺旺从贸易通改造成淘宝im工具，成为方便买卖购物交流的im工具，这是我认为业务上比较大变化的东西。另外支付宝从淘宝慢慢发展，成为独立的一家公司。 我印象中04年业务上关注的pv跟uv比，就是每个用户在淘宝上停留的时间，因为以前淘宝刚成立的时候，很多门户网站跟ebay签了排他协议，淘宝不能在大的网站上投广告，可能找一些网站联盟，他们是弹窗式的广告，平均每个用户在淘宝待几个页面，当时目标就是让用户多看几个页面。 （taobao2005）到了2005年，页面上跟现在越来越像

4、了，也是越来越丰富，05年比较大的业务变化，一个是跟一拍的整合，因为当年阿里巴巴跟雅虎的一个合作，然后一拍并入到淘宝，另外在一些方面做了尝试，比如说“我的淘宝”改造。 （taobao2006）这是2006年的淘宝，这个上面的导航看上去更像了，最右边有一个新功能叫团购，当时花很大力气做了个团购项目，可能是时机没到，不然的话可能就没有现在的拉手什么这么多网站了，当时我们做的是一个卖家发起的团购，但是因为淘宝本身就是一个充分竞价的平台，价格都是很透明的，团购感觉效果不是很明显。06年还做了一个很重大的尝试，招财进宝项目，就是淘宝的p4p，后来大家有听说过，看到历史的介绍，后来做了下线。 06年我印象

5、中淘宝业务考核最大的就是pv，06年pv到达一个亿，这是在06年的时候。 （taobao2007）然后到了2007年，页面有什么规律的话，就是内容越来越多，越来越密集，07年业务上好像没有什么大的变化，我印象比较深刻的就是07年夏天的时候，淘宝每日支付宝成交到达了一个亿，我认为这是一个比较大的业务上的东西。业务上会过的比较快，因为业务上的东西大家平时也看得到。 （taobao2008）到了08年，页面导航上看到的明显变化是，淘宝商城，从4月1号淘宝商城新的平台上线，然后08年阿里妈妈跟淘宝合并，淘宝中有了自己的广告部门，06年的时候淘宝尝试招财进宝p4p广告，后来并没有成功，在07年的时候，那

6、时候的雅虎开始做p4p，再到后来阿里妈妈最终成为淘宝很重要的一块业务，就是广告部门。08年淘宝开始推另外一个业务，就是top 淘宝开放平台，这是业务上比较大的变化。 （taobao2009）这就到了2009年，09年印象比较深刻，09年底商城开始做促销，开始搞秒杀，然后在09年双十一的时候，商城交易额到达每天5000万，这是09年底一个比较大的事情，然后09年初业务上还做了一个很大的变化，08年b2c商城是独立平台，商品交易跟淘宝主站分离的，09年初公司决定把这两个平台从底层上做了一个合并，这是更偏系统一点，业务上并没有大的改变。 2010年、2011年就不多介绍，大家从网站上都能看到。 前面

7、很快过了一下淘宝这几年业务上的变化，从页面导航，业务展现，让大家对淘宝这几年业务发展有一个简单的了解。 下面讲一下淘宝前期技术发展历程，我是按时间分了几个阶段，03年5月份到04年1月份，这是淘宝创建的时候，网上应该有很多相关报道，我这里就不做太多描述，（前期技术发展）在湖畔里面开发的淘宝，采用很典型的lamp结构，这是当时的一个结构图，很简单。当时从公司决定说做一个淘宝到上线是很短的，最快的方式把这个淘宝做出来，大家可以想想看是一个什么样的方式，买了一个比较流行的phpauction的现成交易系统，然后在上面做了改进，就成为淘宝最开始的一个系统，当时很简单，就是十来台机器，然后就把这个系统搭

8、上去了。 （前期技术发展2004）淘宝到2004年的时候流量开始上涨，mysql出现压力高的情况下，到2004年5月份的时候做了迁移，从mysql迁移到oracle，引入sqlrelay管理链接的中间件，当时公司有比较多oracle方面比较牛的人，虽然它的license比较贵，但是从业务考虑，还先支持业务的发展，所以从mysql迁到了oracle。 从这张图大家可以看到其实上面的结构并没有大的改变，还是这种php开发语言，就是在db这层做了一个变化，这是04年前半年淘宝的大致结构。 （前期技术发展（2004.2）淘宝2004年2月份到10月份淘宝的系统有了一次比较大的变化，从php迁移到了ja

9、va，这个我前一阵子在阿里味上看到你们这边王齐他做了一次技术人生分享，他应该参与了这个项目，他和sun的一支开发团队帮助淘宝把架构从php迁移到了java。 其实从php迁移到java一个很重要的原因，因为阿里巴巴在这里已经有了比较多的积累，像宝宝他们已经有比较多的人在java系统上做了比较多的积累，淘宝也就从php迁移到这里，还请了一支比较强大的外援帮我们做迁移。 我看到有同学在给我的问题表格上有问到淘宝跟阿里巴巴他们的技术结构有什么异同，我觉得可能从mvc框架层面并没有大的不同，因为当时迁移到java的时候，采用的也是webx框架，用的是antx项目打包管理工具，代码管理的工具，然后还引入

10、了isearch搜索引擎，因为之前数据库load高很大的原因，就是商品搜索占据了很大的数据库资源。 经过2004年这次比较大的从php到java的迁移，淘宝的结构够变成这张图上面大家可以看到的，然后服务器用的是一个weblogic上面，当时weblogic也是买来的。 （2004.10）从2004年10月份到2006年10月份，这一年多两年时间，系统上并没有特别大的变化，这里的变化列了一下，一个是weblogic迁移到jboss，weblogic其实没有什么不好，它提供很多profile之类的工具，还是不错的，但是它是要钱的，所以从weblogic迁移到了jboss。淘宝当时主要有三个数据库，

11、都是三个小型机，db1、db2、dbc，这三个数据库，做了一个支持分库的数据访问框架，然后抛弃了ejb，ejb本来就没怎么用，可能用的是发异步消息等，用的不多。那时候也是跟随着业界的潮流，因为spring开始流行了，以spring作为管理工具，然后基于bdb做缓存，加速网站访问，像esi缓存。然后淘宝的运维团队开始组建自己的cdn网络，淘宝在这之前，用的主要是一些商业的cdn，像chinacache这种，后来可能从流量、从成本上考虑，自己建立自己的cdn网络可能成本上或者对用户的服务上会更好，所以开始创建自己的cdn结构。 然后发展商品类目属性体系。 （2006.10）到了2006年的时候，结

12、构变成这样了，多了一个缓存，然后06-07年的时候是淘宝访问量越来越多，我印象比较深刻的就是当时两个比较困扰的问题，一个是淘宝的图片，因为淘宝图片数量很大，每张商品最少一张图片，而且图片虽然不大，但是数量很多，一个商品有好几张缩略图，在list、店铺上都有好几张缩略图，文件访问有问题，我们是存在商业的nas硬件上的，随着数量和访问量增加，这个nas慢慢不能支撑这个访问，另外一个就是搜索引擎，因为isearch搜索引擎是全内存的，当时内存是4个g还是8个g，具体忘记了，而因为淘宝商品慢慢增长，之前一台机器就能把全部商品加载进去，但是慢慢淘宝商品量增长，单台机器内存已经不能支撑全部商品，所以当时做

13、的两个大的技术改造，就是开发了分布式文件系统就是tfs；把isearch改造成了分布式：通过merge，把两列商品merge，合并成一个结果，解决了单机容量的问题，这是06到07年在系统结构上变化比较大的两块。 从这张图里面看到java并没有大的变化，主要变化是在下面search从单列变成多列。这里很快介绍了03年成立到07年这段时间淘宝系统上几次变化较大的过程。 （18-内容提要）接下来主要讲一下从07年到现在我认为系统层面比较大的几次变迁。 （19-业务中心化）到07年的时候，都是小步快跑的方式，主要业务都是在一个系统里面，工程师数量也不是很多，开发效率还是不错的，一个需求分下来，开发工程

14、师能够很快的响应，而且发布很快，不需要做很多的协调，慢慢到07年的时候，统一的一个业务系统叫denali，这个名字是04年从php迁移到java时候的一个产出，经过前面几年快速发展，这个系统变得越来越庞大，里面什么功能都有，什么功能都做在这个系统里面，同时工程师开发人员的人数也是越来越多，从最开始的几个人、几十个人发展到一两百个人，有很多地方出现瓶颈，首先是开发效率，因为这个denali代码太庞大了，里面很多工程师开始抱怨，打包部署一次，半个小时过去了，打包一次部署失败，可能半天就过去了，当时宝宝他们做了一些eclipse的插件，例如热替换，但是很多东西还是不能很好地解决开发效率的问题，这样就

15、影响了需求响应时间；另外，代码都在一个系统里面，很多项目在并行，很多分支需要合并，然后发布需要协调。我印象中当时一个很重要的目标，就是需求准时发布，系统发布进入了一个火车模型，因为很多需求都在一个分支上改，每周约定两个发布点，比如说周二要发布的时候，发现有些功能在同样分支上的功能并没有测试通过，那没有办法，没有人保证说我这个功能发上去会不会有问题，因为代码已经提交了，我不发这个功能，因为代码提交了，因此合并了，比较难解决，所以这个火车经常晚点，可能从周二延到周三，周三再有一个测试不通过，那继续延，就变成了一个常态。业务方：运营、市场部门抱怨很大的一个东西。 从系统上07年开始碰到的另外一个问题

16、：数据库连接池的问题，随着网站访问量的增加，我们必须要增加更多的机器来应对更多pv请求，但是每个机器都要直接访问数据库，数据库像oracle连接池到达几千个的时候，那就有问题了，当时开发跟dba经常做的一个很重要的工作，是把top多少的sql找出来，看能不能优化，尽量减少sql的执行量和时间。 （20）另外一个问题是，故障不能很好的隔离，比方说我一个不是特别重要的功能，可能这个功能代码写的有问题，但它运行所有请求都到达同样的地方，这就引起了整个系统的故障，这是07年的时候，我们碰到的一些问题。应对的策略比较简单，因为所有东西都在一个里面，那我们想的办法就是不要在一个里面，就进行拆分系统，几个比

17、较大的动作，第一个是用户中心在08年的时候开始上线，接下来是千岛湖项目，把交易、定单从这个库迁到另外一个库，所以叫“千岛湖”等等。从denali里面拆分出了uic用户中心，然后从denali里面迁出了交易中心，然后拆分出了类目属性中心，然后再经过一个“五彩石”的项目，这个项目两个目标，第一个是把b2c和c2c平台整合，第二个是做系统拆分，把店铺中心、商品、评价等淘宝主要业务系统从denali里面拆分出来，成为独立业务中心。 与这个拆分系统并行的就是拆分数据库。这里先说一下淘宝主要的三个数据库：db1、db2，是按照用户分的，用户一半在db1，一半在db2，如果这个用户在db1，他发的商品就是在

18、db1，与之相关的商品订单也在一起；dbc是一个大杂烩，不在前面两个的都在这里，前面因为做了很多系统拆分，数据库上面也做了很多垂直拆分，按照业务像uic有专门的库，tc有专门的库，店铺有专门的库，还有评价等，做了一系列垂直拆分。还有一个人是员组织结构上的支持，因为淘宝之前组织结构分法是比较土的，开发人员分成开发一组、开发二组，一个项目可能是一个轮循的方式，当然会有主营业务，两个开发团队协调一下，看项目放在哪里。 在系统拆分完之后，组织结构做了产品线的划分，有专门的团队在维护uic，有专门团队维护tc等等，做到了人员结构上的一个垂直化和产品化。 （21-业务中心化）07年我们为了解决问题做一些应

19、对策略，这张图看得不是很清楚，这是淘宝业务拆完之后，淘宝业务跟系统的对照图，里面具体的字不用关注，图中是从一个买家角度，他从搜索到商品详情，再到登录，再到购买，买家在淘宝上每用到的一个业务功能，我们拆出了一系列系统来对应。第二层我们称为前端系统，直接接收用户url请求的系统；下面一层叫业务中心，封装各个业务的逻辑，像uc用户中心，sc就是店铺中心，ic就是商品中心，tc是交易中心，经过08年，慢慢系统就变成这个样子。 （22） 刚才讲到了我们解决07年碰到问题的时候所采取的方案，在这个过程中其实我们在技术上有了一些积累，先讲一下业务中心的模式，比较简单，它分为一个center，负责核心业务逻辑

20、，负责数据存储，与数据库打交道，它是独立部署的应用，对外通过淘宝的应用调度框架hsf，提供业务服务，前端应用负责接收用户请求，然后通过center提供的客户端jar包来调用center的服务，进行页面展现，这个就是业务中心模式。 为了做到这个模式，我们发展了一些技术支持的东西，像系统间的通信，是hsf，基于mina做的一个服务调度框架，还做了一个notify，为了解决异步通讯问题，淘宝的交易过程中很多的状态变更需要发送，所以做了一个notify异步消息中间件。 （23）配置管理上面做了一个configserver，最开始是hsf的一部分，因为做系统调用就有一个服务寻址的过程， configse

21、rver就是负责提供注册功能，center向configserver注册说我对外可以提供什么版本的服务，client就连到configserver，拿到由哪些center可以提供这样子的服务，这个就是configserver，configserver慢慢的成为一个全网的配置中心，很多系统上的配置慢慢的都是放在configserver里面来实现启动时或者启动后的一个实时配置获取及推送。 因为07面左右淘宝从一个机房迁移到两个机房，两个机房间的数据库需要做切换，那时候做了一个rjdbc的工具，就是可以控制我这个应用连哪个数据库，主库在哪里，备库在哪里，然后也是有一些工具能支持这个动态的切换，这是在

22、技术上的一些发展。从图上看到，这里面多了一个hsf系统间调用，业务中心负责和db之间的连接，然后他们之间的寻址方式是通过configserver来做。 （24）从2007年开始的两年艰苦奋斗，基本完成了整个系统的业务中心改造，这个系统看上去挺美的，每个系统职责很清晰，分工明确，每次很多人分享的时候，一拿就拿出一张清晰的系统结构图来看，团队的分工也很成熟，那时候还追求可维护性，追求配置能够实时推送，hsf通过osgi研究动态升级、部署；可扩展性也不错，因为系统经过拆分，从一个大集群变成很多小集群，单个集群就可以通过简单的水平伸缩来支持更多的访问量，然而我们还没来得及庆祝的时候，新的问题就出现了。

23、（25）整个09年下半年，系统稳定性面临了严峻挑战，那时候感觉每周都有故障报告。之前代码都是在一个denali里面，经过两年拆分，这个拆分变得不可控了，08年的时候，整个淘宝应用有71个，到09年变成187个，可能超出了业务发展，然后到了去年变成了329个，现在都已经变成400多个了，拆分力度越来越细，有点矫枉过正了，现在单个功能，一些开发人员都想拆成单独系统，当然他是有一定目的的，目的就是说我拆的越细，我的系统跟别人关系越来越小，我要什么时候发布都可以，发布的时候不要做太多协调，可控性比较强一点，但是整体变得不可控。因为应用数量不断增加，系统依赖关系越来越复杂，很多故障是因为一个非关键的路径

24、系统，但是影响了整个交易，关于稳定性，淘宝最重要的指标是支付宝付款有没有下跌，这是稳定性上最重要的指标，但是影响这个指标的原因有很多，比如说网络有问题，访问的人少了，买的人也少了，路径很长。第二点开发人员已经很难搞清楚我一个url请求，后面的系统调用到底是怎么样子，已经很难有人搞明白，比如说一次出价，到底出价这个系统调了后面多少系统，在后面的系统又调了多少个系统接口，往往都是等出了故障才知道原来这里这样子的，很多故障事后review大家都在深刻检讨，我不应该这样来设计，但这时候已经是整个系统问题，不是某一个系统的问题。另外一点09年业务上也有了一些新的发展，像秒杀，运营好像很喜欢，动不动搞一个

25、秒杀ipad，另外是店铺、商品详情装修个性化，搞的页面越来越大，页面渲染逻辑越来越复杂，都是对我们系统不断的挑战。 刚才讲到系统依赖关系，这个图，最中间的是淘宝类目属性服务，周边有很多服务依赖它，这是单纬度的，随便拎一个出来都是这种状况，特别刚才提到用户中心、商品中心这些系统，我们通过程序尝试地画了一张全网的应用关系依赖关系图，这个肉眼基本上看不出来。（26、27） （28）09年底，2010年初的时候，稳定性形势严峻，印象比较深的是在2010年玉树的地震，网游不可用，大量流量到淘宝，导致我们当天晚上出现问题。技术部老大东邪下达了命令，稳定性提到了很高的优先级。这时候我们也开始重新审视我们的系

26、统，过去两年系统哪里有问题，并且采取一系列措施，因为前面一次变更，从单系统进行业务中心化，这次系统结构上并没有特别大的变化，更多的是我们对于系统的发展以及在一些运维管控上面的思考，一些措施，我们当时想到办法，就是简化和监控。因为之前的系统监控比较弱，我们先做了监控系统，首先让系统运行情况透明化，每天把主要系统运行的详细情况，比如说pv多少、qps多少、内存、cpu怎么样，每个接口变化怎么样，直接发送到开发系统的负责人那里，第二个是简化系统结构，之前所有都是远程服务调用，有个系统要展现商品详情，就要远程调用一下ic服务去拿到商品详情，那我们就考虑，因为我们毕竟是一个网站，soa这种服务的规范没必

27、要做得太标准，我们慢慢基于cache做数据交换，而不是每次都远程先去访问业务中心，业务中心再去访问数据库。做一些异步降低耦合，按需加载，弱依赖的降解容错，做了很多简化系统上的措施，然后集中力量去对关键的系统，就是买家购买路径上关键系统去提升它的qps，提升应对支撑负载的能力，然后专门设计了一个秒杀系统，因为秒杀开始的时候，曾经把系统搞死过一次，因为一下流量可能是平时的几倍或者十几倍这样子，瞬间的流量，我们设计一个专门的秒杀系统来与正常的购买系统相隔离。最后还做了一些容量规划，定期的对线上系统做性能压测，根据以往的pv变化，预计接下来的pv增长怎么样，再根据这个系统的极限能力去提前做加机器的准备

28、，做了很多简化系统依赖，做了监控、报警、容量规划等等，依赖降级这样的事情。 这里截了几张图，这是每天我会收到的系统运行报表，上面是淘宝最大的展现商品的应用，现在平时每天pv在几个亿，它的一些变化趋势是怎么样子，我比较关心的是响应时间，它的变化，比方说rt是47毫秒，它是在变好还是变坏，如果变坏，我们要去看是上了什么功能或者什么东西影响了这个时间，如果它突然间变大，我们看哪里出了问题。 下面这张图，是我们做的这个监控系统会定时的每天自动对线上采样一两台机器做性能压测，比如说五个用户到十个用户的时候，我们压上去，看支撑到的qps是多少，从图中大致能看到什么时候这个系统出现问题。 （图）经过大半年努

29、力，淘宝的可用性从09年的99.5%，就是三个9不到，算下来有43小时这个网站不能用的，到2010年全年可用性是99.95，有一个比较大的改进，每提升一个点，这个挑战都是很大的，因为这个站线太长了，从网络到后端存储，每个地方都有可能有问题，今年到现在，不可用时间的已经用掉83分钟，就是接下来那个时间也不多了，所以我们现在压力也是挺大的。 刚才主要讲我们在解决09年系统在拆分业务中心化之后碰到的一些问题以及大致的解决方式，就在我们应对稳定性的同时，另外一个互联网公司永远的话题也迎来挑战，数据的存储与检索，数据的规模是一个很重要的因素，数据量少的时候，其实你用什么方案都是差不多的，当数据到达一定规

30、模的时候，这个就是会变成一个很大的挑战，支撑能力、成本都是很大的挑战，最开始是淘宝商品库告急，淘宝商品存放在两台小型机里面，余量变得很少，随时都有崩盘的可能，2010年初的时候面临一个选择，我们到底是两台变四台还是说我们就用另外的低成本的方案替换，因为小型机都是几百万一台，后面的存储也很贵，当两台变四台可能还好，当四台变八台的时候，成本是很高的。 羂芁薂薅羁莄蒄袃羁肃芇蝿羀膆蒃蚅罿芈芆薁肈羇蒁蒇肇肀芄螆肆膂葿螂肅莄节蚈肅肄薈薄肄膆莀袂肃艿薆螈肂莁荿蚄膁肁薄薀螈膃莇蒆螇芅薂袅螆肅莅螁螅膇蚁蚇螄芀蒄薃螃莂芆袁螃肂蒂螇袂膄芅蚃袁芆蒀蕿袀羆芃蒅衿膈蒈袄袈芀莁螀袇莃薇蚆袇肂莀薂袆膅薅蒈羅芇莈螇羄羇薃蚃羃

31、聿莆蕿羂芁薂薅羁莄蒄袃羁肃芇蝿羀膆蒃蚅罿芈芆薁肈羇蒁蒇肇肀芄螆肆膂葿螂肅莄节蚈肅肄薈薄肄膆莀袂肃艿薆螈肂莁荿蚄膁肁薄薀螈膃莇蒆螇芅薂袅螆肅莅螁螅膇蚁蚇螄芀蒄薃螃莂芆袁螃肂蒂螇袂膄芅蚃袁芆蒀蕿袀羆芃蒅衿膈蒈袄袈芀莁螀袇莃薇蚆袇肂莀薂袆膅薅蒈羅芇莈螇羄羇薃蚃羃聿莆蕿羂芁薂薅羁莄蒄袃羁肃芇蝿羀膆蒃蚅罿芈芆薁肈羇蒁蒇肇肀芄螆肆膂葿螂肅莄节蚈肅肄薈薄肄膆莀袂肃艿薆螈肂莁荿蚄膁肁薄薀螈膃莇蒆螇芅薂袅螆肅莅螁螅膇蚁蚇螄芀蒄薃螃莂芆袁螃肂蒂螇袂膄芅蚃袁芆蒀蕿袀羆芃蒅衿膈蒈袄袈芀莁螀袇莃薇蚆袇肂莀薂袆膅薅蒈羅芇莈螇羄羇薃蚃羃聿莆蕿羂芁薂薅羁莄蒄袃羁肃芇蝿羀膆蒃蚅罿芈芆薁肈羇蒁蒇肇肀芄螆肆膂葿螂肅莄节蚈肅肄薈薄肄

32、膆莀袂肃艿薆螈肂莁荿蚄膁肁薄薀螈膃莇蒆螇芅薂袅螆肅莅螁螅膇蚁蚇螄芀蒄薃螃莂芆袁螃肂蒂螇袂膄芅蚃袁芆蒀蕿袀羆芃蒅衿膈蒈袄袈芀莁螀袇莃薇蚆袇肂莀薂袆膅薅蒈羅芇莈螇羄羇薃蚃羃聿莆蕿羂芁薂薅羁莄蒄袃羁肃芇蝿羀膆蒃蚅罿芈芆薁肈羇蒁蒇肇肀芄螆肆膂葿螂肅莄节蚈肅肄薈薄肄膆莀袂肃艿薆螈肂莁荿蚄膁肁薄薀螈膃莇蒆螇芅薂袅螆肅莅螁螅膇蚁蚇螄芀蒄薃螃莂芆袁螃肂蒂螇袂膄芅蚃袁芆蒀蕿袀羆芃蒅衿膈蒈袄袈芀莁螀袇莃薇蚆袇肂莀薂袆膅薅蒈羅芇莈螇羄羇薃蚃羃聿莆蕿羂芁薂薅羁莄蒄袃羁肃芇蝿羀膆蒃蚅罿芈芆薁肈羇蒁蒇肇肀芄螆肆膂葿螂肅莄节蚈肅肄薈薄肄膆莀袂肃艿薆螈肂莁荿蚄膁肁薄薀螈膃莇蒆螇芅薂袅螆肅莅螁螅膇蚁蚇螄芀蒄薃螃莂芆袁螃肂蒂螇袂

33、膄芅蚃袁芆蒀蕿袀羆芃蒅衿膈蒈袄袈芀莁螀袇莃薇蚆袇肂莀薂袆膅薅蒈羅芇莈螇羄羇薃蚃羃聿莆蕿羂芁薂薅羁莄蒄袃羁肃芇蝿羀膆蒃蚅罿芈芆薁肈羇蒁蒇肇肀芄螆肆膂葿螂肅莄节蚈肅肄薈薄肄膆莀袂肃艿薆螈肂莁荿蚄膁肁薄薀螈膃莇蒆螇芅薂袅螆肅莅螁螅膇蚁蚇螄芀蒄薃螃莂芆袁螃肂蒂螇袂膄芅蚃袁芆蒀蕿袀羆芃蒅衿膈蒈袄袈芀莁螀袇莃薇蚆袇肂莀薂袆膅薅蒈羅芇莈螇羄羇薃蚃羃聿莆蕿羂芁薂薅羁莄蒄袃羁肃芇蝿羀膆蒃蚅罿芈芆薁肈羇蒁蒇肇肀芄螆肆膂葿螂肅莄节蚈肅肄薈薄肄膆莀袂肃艿薆螈肂莁荿蚄膁肁薄薀螈膃莇蒆螇芅薂袅螆肅莅螁螅膇蚁蚇螄芀蒄薃螃莂芆袁螃肂蒂螇袂膄芅蚃袁芆蒀蕿袀羆芃蒅衿膈蒈袄袈芀莁螀袇莃薇蚆袇肂莀薂袆膅薅蒈羅芇莈螇羄羇薃蚃羃聿莆蕿羂

34、芁薂薅羁莄蒄袃羁肃芇蝿羀膆蒃蚅罿芈芆薁肈羇蒁蒇肇肀芄螆肆膂葿螂肅莄节蚈肅肄薈薄肄膆莀袂肃艿薆螈肂莁荿蚄膁肁薄薀螈膃莇蒆螇芅薂袅螆肅莅螁螅膇蚁蚇螄芀蒄薃螃莂芆袁螃肂蒂螇袂膄芅蚃袁芆蒀蕿袀羆芃蒅衿膈蒈袄袈芀莁螀袇莃薇蚆袇肂莀薂袆膅薅蒈羅芇莈螇羄羇薃蚃羃聿莆蕿羂芁薂薅羁莄蒄袃羁肃芇蝿羀膆蒃蚅罿芈芆薁肈羇蒁蒇肇肀芄螆肆膂葿螂肅莄节蚈肅肄薈薄肄膆莀袂肃艿薆螈肂莁荿蚄膁肁薄薀螈膃莇蒆螇芅薂袅螆肅莅螁螅膇蚁蚇螄芀蒄薃螃莂芆袁螃肂蒂螇袂膄芅蚃袁芆蒀蕿袀羆芃蒅衿膈蒈袄袈芀莁螀袇莃薇蚆袇肂莀薂袆膅薅蒈羅芇莈螇羄羇薃蚃羃聿莆蕿羂芁薂薅羁莄蒄袃羁肃芇蝿羀膆蒃蚅罿芈芆薁肈羇蒁蒇肇肀芄螆肆膂葿螂肅莄节蚈肅肄薈薄肄膆莀袂肃艿薆螈肂莁荿蚄膁肁薄薀螈膃莇蒆螇芅薂袅螆肅莅螁螅膇蚁蚇螄芀蒄薃螃莂芆袁螃肂蒂螇袂膄芅蚃袁芆蒀