BAT 解密（二）：聊聊业务如何驱动技术发展

在《 BAT解密（一）：聊聊技术发展的驱动力 》一文中，我们详细阐述了对于服务类的业务来说，业务发展是技术发展的驱动力。那接下来我们就看看业务究竟是如何驱动技术发展的。

互联网业务千差万别，但由于他们具有“规模决定一切”的相同点，其发展路径也基本上是一致的。互联网业务发展一般分为几个时期：初创期、快速发展期、竞争期、成熟期。

不同时期的差别主要体现在两个方面：复杂性、用户规模。

业务的发展第一个主要方向就是“业务越来越复杂”，我们来看看不同时期业务的复杂性的表现。

互联网业务刚开始一般都是一个创新的业务点，这个业务点的重点不在于“完善”，而在于“创新”，只有创新才能吸引用户；而且因为其“新”的特点，其实一开始是不可能很完善的。只有随着越来越多的用户的使用，通过快速迭代试错、用户的反馈等手段，不断的在实践中去完善，去继续创新。

初创期的业务对技术就1个要求：“快”，但这个时候却又是创业团队最弱小的时候，可能就那么几个技术人员，所以这个时候十八般武艺都需要用上：能买就买，有开源的就用开源的，能模仿的就模仿，甚至可能是能偷就偷。

继续以淘宝和QQ为例：

第一版的淘宝（http://www.yixieshi.com/it/20770.html ）：

第一版QQ（http://www.yixieshi.com/it/20770.html ）：

可以看到最开始的淘宝和QQ与现在的淘宝和QQ相比，几乎看不出是同一个业务了。

当业务推出后经过市场验证如果是可行的，吸引的用户就会越来越多，此时原来不完善的业务就进入了一个快速发展的时期。业务快速发展时期的主要目的是将原来不完善的业务逐渐完善，因此会有越来越多的新功能不断的加入到系统里面。对于绝大部分技术团队来说，这个阶段技术的核心工作是快速的实现各种需求，只有这样才能满足业务发展的需要。

如何做到“快”，一般会经历如下几个阶段：

1. 堆功能

业务进入快速发展期的初期，此时团队规模也不大，业务需求又很紧，最快实现业务需求的方式是继续在原有的系统里面不断的增加新的功能，重构、优化、架构等方面的工作即使想做，也会受制于人力和业务发展的压力而放在一边。

2. 优化期

“堆功能”的方式在刚开始的时候好用，因为系统还比较简单，但随着功能越来越多，系统开始变得越来越复杂，后面继续堆功能会感到越来越吃力，速度越来越慢。一种典型的场景是做一个需求要改好多的地方，一不小心就改出了问题。直到终于有一天，技术团队或者产品人员再也受不了这种慢速的方式，终于下定决定要解决这个问题了。

如何解决这个问题，一般会分为两派：一派是优化派，一派是架构派。

优化派其主张主要是将现有的系统优化，例如采用重构、分层、优化某个MySQL查询语句，将机械硬盘换成SSD，将数据库从MySQL换成Oracle，增加Memcache缓存等等。优化派的优势是对系统改动较小，可以比较快速的实施；缺点就是可能过不了多久，系统又撑不住了。

架构派其主张主要是将系统架构调整，主要是将原来的大系统拆分为多个互相配合的小系统。例如将购物系统拆分为登录认证子系统、订单系统、查询系统、分析系统等。架构派的优势是一次调整可以支撑比较长期的业务发展，缺点是动作较大，耗时较长，对业务的发展影响也比较大。

相信在很多公司都遇到这种情况，而我敢打赌大部分情况下都是“优化派”会赢，主要的原因还是因为此时“优化”是最快的方式，至于说“优化派”支撑不了多久这个问题，其实也不用考虑太多，因为业务能否发展到那个阶段，还是个未知数，保证当下的竞争力是最主要的问题。

3. 架构期

经过优化期后，如果业务能够继续发展，慢慢的就会发现优化也顶不住了，毕竟再怎么优化，系统的能力总是有极限的，Oracle再牛，也不可能一台Oracle顶住1亿的交易量；小型机再好，也不可能一台机器支持100万在线。此时已经没有别的选择，只能进行架构调整，在优化期被压制的架构派开始扬眉吐气了，甚至会骄傲的说“ 看看吧，早就说要进行架构调整，你们偏要优化，现在还是顶不住了吧，哼 ”。

架构期可以用的手段很多，但归根结底可以总结为一个字“拆”，什么地方都可以拆，例如：

• 拆功能：例如将购物系统拆分为登录认证子系统、订单系统、查询系统、分析系统等；

• 拆数据库：MySQL一台变两台，2台变4台，增加DBProxy、分库分表等；

• 拆服务器：服务器一台变两台，2台变4台，增加负载均衡的系统，例如Nginx、HAProxy等；

3个不同时期的对比如下：

当业务继续发展，已经形成一定规模后，一定会有竞争对手开始加入行业来竞争（“一直在模仿、从未被超越”的腾讯、财大气粗的阿里巴巴），毕竟大家都想分一块蛋糕，甚至有可能一不小心还会成为下一个阿里巴巴。当竞争对手加入后，大家互相学习和模仿，业务更加完善，也不断的有新的业务创新出来，而且由于竞争的压力，对技术的要求是更上一层楼的“快”了。

新业务的创新，给技术带来的典型压力就是新的系统会更多，同时，原有的系统也会拆的越来越多。两者合力的一个典型后果就是系统数量在原来的基础上又增加了很多。架构拆分后带来的美好的时光又开始慢慢消逝，技术工作又开始进入了“慢”的的状态，这又是怎么回事呢？

原来系统数量越来越多，到了一个临界点后就产生了质变，即：系统数量的 量变带来了技术工作的质变 。主要体现在如下几个方面：

重复造轮子：系统越来越多，各系统相似的工作越来越多。例如：每个系统都有存储、都要用缓存、都要用数据库，新建一个系统，这些工作又要都搞一遍，即使其他系统已经做过了一遍，这样怎么快的起来？

系统交互一团乱麻：系统越来越多，各系统的交互关系变成了网状。系统间的交互数量和系统的数量成平方比的关系，例如4个系统的交互路径是6个，10个系统的交互路径是45个。每次实现一个业务需求，都需要几个甚至10几个系统一起改，然后互相调用来调用去，联调成了研发人员的灾难、联测成了测试人员的灾难、部署成了运维的灾难。

针对这个时期业务变化带来的问题，技术工作主要的解决有段有：

1）平台化、服务化：解决“重复造轮子”的问题。例如：

• 存储平台化：淘宝的TFS、京东JFS

• 数据库平台化：百度的DBProxy、淘宝TDDL

• 缓存平台化：Twitter的Twemproxy，豆瓣的BeansDB、腾讯TTC

2）消息队列、服务框架：解决“系统交互”的问题。例如：

• 消息队列：淘宝的Notify、MetaQ、开源的Kafka、ActiveMQ等

• 服务框架：Facebook thrift、阿里巴巴的Dubbo、当当网Dubbox、淘宝的HSF

当企业熬过竞争期，成为了行业的领头羊，或者整个行业整体上已经处于比较成熟的阶段，市场地位已经比较牢固后，业务创新的机会已经不大，竞争压力也没有那么激烈，此时求快求新已经没有很大空间，业务上开始转向为“求精”：我们的响应时间是否比竞争对手快？我们的用户体验是否比竞争对手好？我们的成本是否比竞争对手低 ？等等。

此时技术上其实也基本进入了成熟期，该拆的也拆了，该平台化的也平台化了，技术上能做的大动作其实也不多了，更多的是进行优化。但有时候也会出现为了满足某个优化，系统做很大的改变这种情况。例如为了将用户响应时间从200ms降低到50ms，可能就需要从很多方面进行优化：CDN、数据库、网络等。这个时候的技术优化没有固定的套路，只能按照竞争的要求，找出自己的弱项，然后逐项优化。在逐项优化的时候，可以采取之前各个时期采用的手段。

服务类业务的发展第二个主要方向就是“ 用户量越来越大 ”。

互联网业务的发展会经历“初创期、发展期、竞争期、成熟期”几个阶段，不同阶段典型的差别就是用户量的差别，简单来说就是用户量随着业务的发展而越来越大。

用户量增大对技术的影响主要体现在2个方面：性能要求越来越高、可靠性要求越来越高。

用户量增大对技术带来的第一个挑战就是性能要求越来越高。以互联网企业最常用的MySQL为例，再简单的查询，再高的硬件配置，单台MySQL机器支撑的TPS和QPS最高也就是万级，低的可能是几千，高的也不过几万。当用户量增长后，必然要考虑使用多台MySQL，从一台MySQL到多台MySQL不是简单的数量的增加，而是本质上的改变，即： 原来集中式的存储变为了分布式的存储 。

稍微有经验的工程师都会知道，分布式将会带来复杂度的大幅度上升。以MySQL为例，分布式MySQL要考虑分库分表、读写分离、复制、同步等很多问题。

用户量增大对技术带来的第二个挑战就是可靠性要求越来越高。当你有1万个用户的时候，宕机1小时可能也没有很大影响；但当你有了100万用户的时候，宕机10分钟，投诉电话估计就被打爆了，这些用户再到朋友圈喷一下你的系统有多烂，很可能你就不会再有机会发展下100万用户了。

除了口碑的影响，可靠性对收入的影响也会随着用户量增大而增大。1万用户宕机1小时，你可能才损失了几千块，100万用户宕机10分钟，损失可能就是几十万了。

虽然用户量增加给性能和可靠性带来了很大的挑战，但幸运的是，应对这些挑战的方式却可以概括为1个字“拆”，简单来说就是“一台不够拆为两台，两台不够拆为4台。以此类推”。常见的拆的方式有：

• 拆硬件：数据库分库分表、业务处理分开到多个机器

• 拆地点：双机房部署、多机房部署、数据中心

• 拆功能：例如将购物系统拆分为登录认证子系统、订单系统、查询系统、分析系统等

如果你还记得前面业务复杂度里面讲到的一些手段的话，你一定会对这几个手段很熟悉。是的，这几个方式在应对复杂度的时候也可以用过。

当然，“拆”只是手段，“合”起来才是关键。不管我们的系统怎么拆，站在用户的角度，他都是理解为一个统一的业务。比如说，微信内部肯定分成了很多子系统，但用户并不需要理解这些，用户只管用微信即可。

常见合起来的手段有：

• 客户端“合”：Memcached的一致性hash

• 网络“合”：DNS、F5

• 系统“合”：Nginx负载均衡、LVS、中间件（淘宝的TDDL等）

• 业务“合”：单点登录

究竟用户规模发展到什么阶段才会由量变带来质变，虽然不同的业务有所差别，但基本上可以按照如下这个模型去衡量。

通过前面的分析，我们可以看到业务驱动技术发展的两大主要因素是 复杂性和用户规模 ，而这两个因素的本质原因其实都是“量变带来质变”。

应对业务质变带来的技术压力，不同时期有不同的处理方式，但不管什么样的方式，其核心目标都是为了满足业务的“快”的要求，当你发现你的业务快不起来的时候，其实就是技术的水平已经跟不上业务发展的需要了，技术变革和发展的时候就到了。更牛逼的做法是在问题还没有真正暴露出来就能够根据趋势预测下一个转折点，提前做好技术上的准备，这对技术人员的要求是非常高的。

在应对复杂性和用户规模带来的技术压力时，“拆”是一种常见的的手段，可以拆系统、拆业务、拆机器、拆地点。等等，总之一句话： 哪里不满足就拆哪里！但拆容易，如何将拆完后的东西“合”起来才是关键 。

除了“拆”以外， 服务化、平台化是另外一种有效的手段 ，将公共的东西独立出来，避免重复造轮子，既节省了重复投入的人力和资源成本，也能够快速支撑新的业务的实施。

李运华，十余年软件设计开发经验，经历了电信行业和移动互联网行业，曾就职于华为和UCWEB，先后担任软件开发工程师、系统分析师、架构师、技术leader等角色； 现担任阿里巴巴移动事业群（原UCWEB）资深软件工程师，带领多个研发团队，承担架构设计、架构重构、技术团队管理、技术培训等职责。

技术上专注于开源技术、系统分析、架构设计，对互联网技术的特点和发展趋势有较深入的研究和理解。先后负责过游戏接入高可用项目、飞鸽事件发布订阅系统、交易平台系统解耦项目，对于系统解耦、高性能、高可用架构有丰富的经验。

为你定制的容器技术大会

容器与微服务架构是近几年来开发者社区的技术热点，在与容器结合使用后，微服务架构的优点得到了进一步的放大。有很多的文章都在讨论微服务和单体式架构的区别，到现在，整个社区也开始理性起来，单体式架构和微服务架构并非相互替代的关系，单体式的架构更适合轻量级的简单应用，微服务架构相对复杂，对比起来，并不容易落地。

本专题不谈概念，只讲实践。比如企业如何使用Spring Boot框架构建微服务应用，从SOA转型微服务，有哪些难点和痛点，在此之前应该做好哪些准备等。简单来说，在内容策划上，微服务专题希望能和参会者分享微服务架构应该如何落地，更加偏重案例分享。

如果您对这次会议感兴趣，戳这里啦。