大型应用系统在业务发展过程中架构设计如何跟上？会有哪些陷阱和应对方法？ 本分享介绍途牛在业务高速增长同时的系统架构发展过程，以及这过程中总结下来的经验和架构实例。

大型应用系统在业务发展过程中架构设计如何跟上？会有哪些陷阱和应对方法？

途牛首席架构师赵国光在本次演讲中先对途牛的整体业务与系统进行了介绍，随后介绍了途牛在业务高速增长的同时系统架构发展过程，以及在这过程中总结下来的经验和架构实例。最后总结了如何做好架构师。

途牛的业务与系统整体介绍

途牛是一个以休闲度假为主的，综合类的在线旅游入口，它的品类包括跟团、自助、自驾、机票、酒店等等，有超过180万的SKU，它的产品覆盖了中国以及世界的很多个地方。

旅游产品的特点也是我们系统要解决的难点。首先它的产品具有组合性，它的产品构成非常复杂，他包含机票、酒店、门票…所有旅行中需要的资源，它不是一个单独的东西。另外就是它的价格波动性，典型的是机票和酒店的价格是高频变动的，所以旅游产品的价格也会跟着波动。第三就是一个团期的概念，这个是不同于一些普通的电商产品的概念。是什么意思呢？就是说我买一个东西，我不会说买哪一天的遥控器，而我们的旅游产品一定是买哪一天去出游。对于同一个SKU，它的库存和价格都可以打到每一天上，每一天有每一天的价格，每一天有每天的库存。那我们再回到我们这个SKU上面，我们就会发现SKU，再加上组合性，再加上团期的放大效应，这个数量就会变得非常大，这是旅游产品面临的一个特点和它的难点。另外途牛对接了有超过两万家的供应商，不同供应商的特点是他们的数据结构不一样，对接的接口也不一样。

途牛的整体架构是这样的，最上层是前端应用，下面是数据适配层和接口代理以及一些独立的应用，中间两层是我们的业务服务和公共服务。最底层是存储、队列、文件系统、调度等等。我们希望把稳定的、抽象的放到下层，把一些高频的业务变化放在上层，原则上不允许下层去依赖于下层，就是不允许稳定的去依赖于一个高频变化的，一定是上层依赖于下层。

系统演化过程中的经验

途牛的整体架构演化到现在，而且它还在不断的演化过程当中，在演化的过程当中，我们积累了一些经验想跟大家分享。

首先是垂直架构的问题，垂直架构有可能是很多大型的应用系统都会经历的一个阶段。

必须要承认，就是不是一个决定在所有的时间都是正确的。但是当公司发展到一定程度的时候，垂直架构的问题就会现象出来。首先就是重复建设，因为垂直架构一定会开发一些相同的或者是类似的东西出来，那会浪费一定的人力。第二，各个品类或者是各个业务之间，他们的数据是无法打通的，品类内部的数据格式、交互方式都是仅考虑自身特点的，不会是互相很好兼容的。第三，缺乏业务沉淀，就是这种垂直架构下，我们是没有一个平台化的能力的。

第二个想跟大家聊一聊微服务化。首先微服务是一个非常好的架构风格，我们也一直在这上面做。想通过这个跟大家分享一下，就是我们在做的过程中对它的一些体会，和在实践中的一些认知。首先，我们认为微服务技术框架并不等于微服务化，这是两个不同的概念。比方说我画了一个小图，比方说这个四方块是一个单体的应用，里面有四个模块，我把这四个模块变成四个应用去部署，然后再给它放一个服务化的一个调度平台，我们发现我们的微服务化改造完成了。实际上我们想一下我们会发现好像跟原来的系统没什么差别是不是？实际上我认为这种不叫微服务化，它充其量是批上了一层微服务化的技术上的外衣。那么其实这个时候我们付出了一些东西对不对？我们付出了管理成本，但是给我们带来了收益是什么，我认为微服务化最大的收益应该是解耦和复用。因为服务化过程是有负担的，是有成本的，我们要做的就是我们得到的收益要大于我们的成本，这个也很容易理解，我们原来的一个单体的应用只有一个应用，那微服务化可能至少把它拆开几个，那我当然管理的成本就变高了。微服务之间一定要追求解耦和复用，在单体结构中的模块之间的耦合放到微服务里面就变成分布式系统之间的耦合问题。所以如果微服务化管理不善的话，它至少会带来我们三个方面的成本，第一个就是服务的治理。第二个就是我们的问题排查会非常困难，那么多系统交织在一起。第三个问题就是组织上的问题，我们很难避免。因为你把服务拆散了，放到了不同的团队，那么一个工作势必要更多的团队一起去协调，这个就是成本。

另外一个就是伴随着微服务不小心会引入一些问题，比方说重复。举个小例子，比方说A系统调用B系统，这是一个很简单的关系，然后有一天这个B它需要在这里面开发一点东西，这个东西跟B原来的职责有点相似的，但是又有一点不同，那为了不影响原来的功能，最好的办法或者说最简单的办法，不是最好的办法，最简单的办法把B拷一份，便成了B撇，在B撇这个地方改，这种就造成了重复。

在分布式系统下，数据一致性问题本来就存在，我们做的微服务化之后这个问题会变得更加地明显，所以我们就要更加警惕一点，不要再人为地去增加这种数据一致性的问题。你比方说这个A调B、B调C，然后B把C从刚才取出来的数据加工一下在反馈给A，这也就是一个很简单的操作，所有的系统都会遇到。那么B处于好意，它为了加快给A的响应速度，它把C反馈来的数据缓存了，这样的话会得到几个好处，第一个A调它调速会变快，第二个它调用C的量变少了，C的负担减轻了。实际上马上会带来另外一个问题，就是这个数据变化通知的问题，如果你的数据永远不变，这样做有可能是可以的，那么我们最后就是要去思考，到底要不要引入这个、得到这个好处，同时付出这个成本？因为所有的设计家架构的设计都是权衡的，实际上如果B跟C是两个团队的话，B把数据缓存了C有可能都不知道，它怎么通知你？是否要引入这种缓存结构，我们要权衡到底是否需要。

在技术架构上我们有两点经验，一个就是技术架构至少要跟上，最好是要略微领先于我们的业务架构。第二就是避免能够建到的小轮子，建立一个轮子一定要很好用、很通用，重复建立小轮子的话，既浪费成本，又得不到太好的效果。

架构实例

下面介绍几个架构实例。不同场景下企业应用面对的复杂度是不同的，大概总结下来可以有三类：第一个就是量，单纯的量大就构成了复杂度； 第二个是业务逻辑复杂，业务逻辑特别没逻辑；第三个就是高频的变化和快速开发。幸运的是多数情况我们应该不需要同时解决所有问题。那就是根据业务情况权衡，设计就是权衡。

我们先看第一个应用的架构事例，这是一个订单系统，大概的位置是这样的，一个前端，然后它和产品、资源、库存、等等有一些服务配合，把一个产品卖出去。有多个产品品类，不同品类它的状态的流转方式和操作的规则不完全相同，最讨厌的是不完全相同，就是它有一部分相同，还有一部分是不同的。另外就是资源匹配非常非常多，这个是一个订单的状态流转图。

这是刚才我列出来的九个，但是途牛远不止这个，那么现在大家看到的这个案例可能它面临的复杂度第一个是业务逻辑复杂，第二个可能就是它的业务变化。那么，假设我在这个订单上面我需要去加入一个品类的需求的时候，怎么做呢？我们往往会最简单的会想到两种办法，第一个是通过if-else或者是通过flag等一系列的标志，去把代码插入进去。还有一种就是我拷贝一个订单出来，把它的不同的地方做到这个里面去，首先第一种方式很不好，它丧失了隔离性对吧？它很容易把一个订单变得太多if和else的代码团，最后很难维护。而且如果一个品类出了问题，或者一个品类流量特别大等等，都会影响到其他的品类。第二种方式也不好，还是我们刚才说的，这个重复性是我们要尽量避免的，它虽然思考问题上很简单，easy和simple是两个截然不同的概念对吧？这种很easy、容易想到的，但是它最后我们做起来并不简单。

面对这种企业运营的核心复杂度最好方法就是在领域模型上去寻求解决方式，这是我们主要的领域模型，通过分析最大的领域模型就两个：资源、订单，现在很直观，订单应该是我们的一个聚合根，我们把它抽象出资源管理器，出游人、价格、合同等等概念，它每一个是有不同的职责。那么我只要去实现这些职责，并且再根据不同的品类去注入这些东西就好了。

最主要的代码就出现在这里，并且这种模型是相对稳定的，是追求可复用的，而在上面这些我会通过编排不同的状态做什么什么事情，那可以在上面去做。把这个案例总结一下，我觉得应对企业应用的复杂性的很好的一个办法就是领域系统，我们在领域模型上去思考问题，第二就是业务上还是要选择隔离，不同业务要隔离，但隔离的方式不是简单的复制。

我们来看第二个，这个价格管理是干什么用的呢？这是一个三亚五日游的产品，去三亚玩五天，这里面会把每一天你去三亚最低花多少钱展现在这里，最低价。它需要解决的问题是什么呢？我们要选择那种把所有的资源组合到一起，最便宜的那个摆到网站上面。

这样做的第一是吸引，再一个这确实也是一种价值是吧？我可以把这个最便宜的组合帮客人挑出来，告诉你们。那问题就是机票和酒店他们经常变化，一旦价格变了，假如价格涨了，我给客人展示的是3000块钱，一点进去3500，那马上客人会觉得受到了欺骗，对我们的感受很不好，所以这个价格一定要跟得上它的变化，那跟得上的难度有多少呢？我们的预售期有180天，就是这个旅游产品有预售期的概念，就是我们要提前算180天以后的价格，每一天都算进来，这样直观的看来这个系统所面临的复杂度是量的问题。第二个就是它随着功能在不断地增加，它的存散职责越来越分散，这个黄色的线就是利润的价格，就是我要加多少钱卖，这个黑色的线就是成本价，红色的线是售卖价。

首先我们追求的就是先把服务化分装，把它的复杂度封装到这个服务的内部，减轻周围系统的压力，就是不要一个职责让好多个系统都去参与实现。第二个应对量的问题，首先我们要把计算模型抽象出来，然后中间通过异步化的方式去连接他们，比方说我算一个东西要分两步，一个是算资源的价格，一个是算产品的价格，打个比方，那不同的应用可能有不同的抽象方法，我们通过异步的方式把他们连接起来。异步就可以在这个地方有一定的缓冲，所以它就可以增加我们的吞吐量。第二个就是独立扩展，说到扩展性又必须考虑到应用的负载均衡策略，往往无状态的应用更利于水平扩展。第三个就是数据运营，我们可以通过查询感知到哪些产品是热门的，是需要更好的实时性的，那就要给更多的资源去计算，所以服务的自我运营能力也很重要。

下面介绍两个技术架构的实例。途牛有超过1000个系统，每天的内部调量有几十个亿，那么我一定要需要一个服务化框架来管理这些系统。

Pebble的整体转型架构大概是这样的，分层架构的一个很大的好处就是你可以把底层抽掉一层，再插上一层，对上层完全无感知，只要你们的接口定义是相同的，所以它就可以有很好的扩展性。

架构师的角色

最后我发表一下关于架构师的角色的理解。就是我们最应该关注的是什么，应该怎样做才能最好的帮助组织达成目标、同时在这个过程中成就自己。我觉得不仅是架构师，对于资深的工程师也是一样，这也是一个很好的问题。

首先要理解业务。这种理解业务并不是指说所有的流程、所有的代码都是我写的，这系统里面的交互、谁给谁发什么消息我都清楚，这种是清楚实现，跟理解业务还不完全是一码事。理解业务是说要理解我们做这个工作为什么要做，它对我们公司带来什么样的价值，怎么样得到业务反馈，系统会向哪个方向演进以及这其中的难点可能是什么，这经常会在响应时间、吞吐、扩展性等问题上体现。把系统理解成有生命力的，做了这个功能系统变成了什么？看到了太多系统最后做成了四不像。同时，也只有理解业务才能和各方有效的沟通，不会鸡同鸭讲，架构师要能同技术人员沟通时用技术语言，同业务人员沟通时讲人话。

第二个就是首先要定义问题，而不是首先去想怎么解决问题，我觉得定义问题更重要了。

第三个就是关注人的问题，这也是我最想对自己说的。一个研发过程涉及到了太多的人：业务、项目、产品、研发、运维… 必须要认识到就算大家的目标是一样的，考虑问题的出发点和方式还是会不同，每个人的知识背景、思维方式、乃至最现实的考核指标都是不同的。事实上每个人都是自己领域的专家，都会看到自己认为很重要的“问题”。这个问题的解决方式就是认识到“人的不同”。首先是坚定自己做的事情是对的，然后去和人沟通，争取到互相都认可的东西把事情做下去。

最后就是权衡了，架构设计就是权衡。假设研发人员的能力不变，那么实现一个功能完备、运行效率高质量好、并且工期很短的需求是不可能的。怎么去做权衡？就像CAP怎么权衡，我觉得还是基于对业务的理解，只有深入的理解业务，我才能在三点当中找到这个平衡点去做权衡。