技术架构如何抓大放小

编者按：本文来自微信公众号“caoz的梦呓”（ID:caozsay），作者 caozsay，36氪经授权发布。

其实旧文提过几次关于抓大放小，技术架构莫做无用功的话题。

不过最近还是有朋友想要开启新项目，做一些数据工具，来咨询一些技术架构的问题。想翻点旧文给他，发现都是七七八八散列在不同文章里，而且不成体系，想想干脆整理一下。希望能对一些创业小公司，小团队有所帮助。

所以今天的内容，大部分都是旧文所写过的，只是新的整理。

1、为什么要抓大放小？

那么对于初创企业来说，资源不足，人力不足，成本考量，都是很重要的因素，如果不能集中资源，人力，不能控制成本，那么可能小公司在最初的运维成本都是熬不过去的。

但很多人没意识到，对于巨头来说，这个问题依然存在。

对巨头来说，人力和资源成本或许没那么重要，但时间成本很关键，毕竟大家都要拼效率，如果你过于追求一些无意义细节的优化调整，可能会错过重要战机。

但实际上，对巨头来说，有些系统的资源成本也是蛮重的，如果不能做到抓大放小，那么开销成本可能会指数级上升，而收益却不会有太大的提升，这也是无法忍受的。

是的，就算是巨头，也要核算收益比。

那么典型的例子，我以前讲过的，为什么淘宝，百度，谷歌，这些巨头的搜索结果都不会超过100页。这是一个典型的资源开销和收益比的问题。

没有用户会在意100页以后的搜索结果，如果需要，他应该换一个搜索选项。

在搜索场景中，大翻页的资源开销优化是个严峻的技术挑战，也是当年无数独立网上社区用开源论坛系统被搜索蜘蛛抓死的原因。很多刚入门的程序员并不十分理解这一点。以前我提到这个话题的时候，不少程序员很困惑。这是理解索引优化，理解搜索效率，理解性能优化很好的一个话题。我有旧文提过这个话题，这里不展开。

顺便说一句，搜索引擎在多词联合搜索的时候，你会发现搜索结果经常会舍弃某个词，这个问题也是值得思考的一个搜索效率话题，这里也不展开，毕竟不是本文主题。

2、抓大放小的关键技巧是什么？

这个说来，我得瑟一句，作为经济适用架构师，我的纯技术水平远逊于数不清的同行，但在这个问题上，我自信会超过95%以上的同行，甚至更高。

抓大放小的关键，不是技术基本功，而是需求理解力。

这就是当年我编写的cnzz统计，超越了技术牛人们搞的武林榜的原因，他们技术架构功力远胜于我，但我强在需求理解力。

那为什么说需求理解力很重要呢，因为需求理解力可以让你知道，什么是可以舍弃的。

抓大放小的第一个重要技巧，舍弃不必要的诉求和所需要的资源。

下面是案例

1、搜索引擎的结果超过100页是可以舍弃的，性能优化压力一下子轻松了好多。

2、当年做网站统计分析中，来源分析，受访页面分析，每个网站只看Top1000足以。

有人做统计系统问我，那么多来访，那么多受访页面，都存下来，数据库怎么设计的，我说干嘛要都存下来，谁看啊，以4399为例，几十万游戏，运营负责人每天看看最多人玩的几百个还不够么，很多游戏一天访问量几次，谁关心啊。

能理解么，99%的存储数据根本没人看，你存它干嘛呢。

3、当时有朋友帮我做过一个监测分析的数据平台，我很穷么，整台破服务器放着，监测各APP的排名变化趋势，从中寻找某些机会。

那么上百个国家的排行，每个国家又有不同分类排行，而且要保存每天的排名数据，所以数据量很大。

那他就找我，说这个存储的数据量很大，第一是存储压力很大，每天服务器跑不动，第二是数据规模很大，硬盘不够用，要加资源，加服务器。

我穷么，经济适用架构师，我就跟他分析，我说你存那么多东西干嘛呢？

中国美国的，总榜排名Top 200的APP，子榜单 Top100的，才值得每日实时监测数据变化存储。

排名低于Top 200的，除了开始存储原始排名外，只有显著变动的时候才值得存储，比如某个APP今天排名855名，明天排名842名，我需要关心它变动么，我知道它一直在800名左右还不够么，今天855，明天655，也许才有可能值得看一下对不对。

除了中国和美国，可能总榜我只关心Top100，子榜单只关心Top50，对不对，其他的同理，原始值可以存，但只有显著变化的时候，才存储变化。

设置一些阈值，只记录顶部的每日变化和非顶部的显著变化，这样非顶部的APP就算是一飞冲天，我也不会错过它的增长趋势和轨迹，对于大部分沉默APP，我大概知道他们排名就可以了，每天那点小变化有啥值得关心的。

就这一个策略，数据存储压力减少了70%可能还不止。

什么是无用功，浪费大量资源去记录一堆永远无人关心的沉默数据，还要为这堆沉默数据做各种性能优化和压力测试，就是无用功。

除了舍弃一些不必要的存储外，抓大放小的第二个技巧，容忍存在一些不那么高的精确度。

比如说，如果你要看订单数量，需要非常准确，实时性也很高，因为每个订单都有金额来往，一点都差不得。但如果，就好比这篇文章的访问量，当然我不是说不做准确的统计，而是在系统设计的容忍度上，这种数据的安全级别没那么高，时间精度也不需要实时同步，可以做异步更新，在数据库的配置上，可以优先考虑效率而不是安全，这个参数配置的不同对存储性能影响还是非常大的。

当年做cnzz系统的时候，技术不过关么，这么高并发请求怎么办，异步处理，容忍一定程度的数据丢失风险。还能咋办，那后来大家还是觉得数据蛮准的，当然这有其他技巧，这里不展开了。

抓大放小的第三个技巧是，忙闲数据的区分处理。

啥叫忙闲数据，新浪微博就是典型，大V的信息每天被大量曝光，这是忙数据，很多僵尸用户你都不知道活着没活着，就算活着，每天也没几个人看。这就是闲数据。

当年杨卫华老师分享过他们的架构方案，冷热数据分开处理，推拉结合。

把忙数据，作为热数据，走推送机制，数据少，请求频次高。闲数据，作为冷数据，走拉取机制，数据多，但请求频次低。基于二者结合，才能保障系统效率的可支撑性。

那么如何定义忙闲数据，要有一套规则和策略，不同系统应该有不同的策略，并通过请求频次来不断反思这个策略。

这个没有一定之规，你说照抄个方案放之四海而皆准，这个真没有。

但方法论可以有，假如你让我给你设计，我会先把当前的请求信息统计下来，看看请求的集中度如何，请求的响应频次如何，然后我基于这些数据，制定一些规则，并且用这些规则模拟处理同样的请求，看看是否有更好的效率提升，以及提升率是多少。

这也是我常说的，脱离具体场景诉求谈架构的，有一个算一个，都是耍流氓。做架构的第一件事，把需求捋清楚，把业务目标捋清楚，把请求数据的频次，规模，数据容量捋清楚，然后才可能有合适的方案，还有做模拟测试，来评估方案的有效性。

抓大放小的第四个技巧是，必要时响应降级。

以前腾讯邮箱搞过，出现严重状况时，信件可读，但无法发送和回复，保留最常用的基本功能。那现在腾讯邮局很强壮，这个现象似乎见不到了。

这个也是非常重要的原则，任何时候，你要考虑到系统有崩溃的风险，有数据丢失的风险，有被入侵的风险，有资源挤压的风险。那么很多使用缓存产品的平台，缓存崩溃重启的时候，会有所谓的雪崩效应，连带数据库和各种中间件一起崩溃。

在这种时候，响应降级的设计就很关键，让你能维持最基本和最必须的功能，保证用户最基本的体验。

响应降级，你就必须明确，系统设计里，哪部分是最核心的，最基础的服务，在其他模块全部崩溃的时候，依然可以幸存的，要尽可能独立出来，做足准备。这是关键时刻救命的设计，可以在最危险的时候，减少你用户或者客户的流失。而且，也可以有效减少你紧急恢复系统时，疲于奔命的压力。

很多时候，我们没办法做到100%的系统安全和健壮，这时候，要尽量优先确保核心服务的安全和健壮。这也是一种抓大放小，因为你要明确什么是核心和优先保障的业务模块。

事实上，很多很多上市公司都做不到这一点。

善于抓大放小，很多时候，一些系统设计，你可以用更少的资源，更低的成本，搭建更强壮更庞大的系统。

技术人员，经常文人相轻，很多时候会说，那个牛逼的系统架构，都需要多少服务器，多少存储，才能满足怎样的业务，我说可以更少，可以更低成本，有些人是不服气的，我比那些牛逼的人强么？你单论技术，应该是不如，但如果我处于同样的位置，我会干什么，不是空谈架构，没意义。

先把需求理解一下，然后把业务数据梳理一下，我常说的，不但要看业务的请求频次，还要看请求的集中度，特别是高并发期间，请求是否集中在特定数据表，特定条件，以及特定的数据列中，如果存在一定的集中度，一定有办法可以做出特别处理。从未被请求的，或者极少被请求的，是否也可以单独处理呢？省的挤占资源。然后呢，制定一些规则，让规则可以尽量适应不同时期的不同集中度变化。

当年我在运维成本上的抠门程度其实是蛮严重的，穷惯了，现在很多人可能不习惯这种作风了，能比我抠门的不多，但还是有几个的，不过这种人现在不吃香了，不就是拼服务器资源么，谁在乎呢。

最近有些朋友问我，公司业绩增长迅猛，负载支撑压力大，或者要启动一些数据量比较大的分析平台，没有技术经验，问我怎么办，回头遇到类似的，我就把这篇扔给他们。