专栏名称: caoz的梦呓
caoz的心得与分享,只此一家,别无分号。
分享
今天看啥  ›  专栏  ›  caoz的梦呓

[原创]技术架构如何抓大放小

caoz的梦呓  · 公众号  · 科技自媒体  · 2020-03-02 17:53

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


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


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


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%的系统安全和健壮,这时候,要尽量优先确保核心服务的安全和健壮。这也是一种抓大放小,因为你要明确什么是核心和优先保障的业务模块。


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


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


技术人员,经常文人相轻,很多时候会说,那个牛逼的系统架构,都需要多少服务器,多少存储,才能满足怎样的业务,我说可以更少,可以更低成本,有些人是不服气的,我比那些牛逼的人强么?你单论技术,应该是不如,但如果我处于同样的位置,我会干什么,不是空谈架构,没意义。先把需求理解一下,然后把业务数据梳理一下,我常说的,不但要看业务的请求频次,还要看请求的集中度,特别是高并发期间,请求是否集中在特定数据表,特定条件,以及特定的数据列中,如果存在一定的集中度,一定有办法可以做出特别处理。从未被请求的,或者极少被请求的,是否也可以单独处理呢?省的挤占资源。然后呢,制定一些规则,让规则可以尽量适应不同时期的不同集中度变化。


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


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



今天不卖课,让各位失望了。


钱多,任性,本文不开赞赏。


今天看啥 -
本文地址:http://www.jintiankansha.me/t/1RBJpfNAIm