[转]当当网高可用架构的志–转

正文转自:http://www.cnblogs.com/davidwang456/articles/5340650.html

声称:本文内容出自于TOP100Summit旗下技术沙龙品牌into100沙龙第17期:愈可用高并发解决之道,如需要转载请联系主办方进行授权。 
嘉宾:史海峰,当当架构部总监。2012年参加当当,负责一体化架构设计、技术标准制定,善于把握复杂工作需求,提出创新性解决方案,参与重点项目方案设计,对系统架构进行持续改造优化,推动技术革新,组织内外部技术交流。 
以下也分享整理正文: 
系面临的非功能性需求 
今天咱们的主题是当当大可用架构设计之道,高可用并无是功能性的需,而是人情的IT当中非功能性需求的等同有些。大家可以望自身这里罗列了诸多非功能性需求,但是就中档并从未「高可用」这三只字。 

 

举一个例,比如说你买了同样台苹果手机,无论是当手机要电脑,还是MP3,还是特别为此来拘禁视频的,都是功力;那么不功能性呢,比如说大家颇崇拜乔布斯,产品设计极致体验,苹果手机就生1单键,简单好用,这就是一个非功能性需求。另外还有众多对象选购土豪金的无绳电话机,就是为区别开,因为颜料不等同。这个颜色为是免功能性需求。 
咱们大概介绍几个非功能性需求。 
扩展性,有一部分好像之足抽象成统一模型的物,如果说做好的口舌虽足以支持扩大。用一个以前的例子,我先是开电信行业的,比如说有一个求要以世界通上起来一个5片钱之套餐,接着以如于动感地带开一个10片钱的套餐,那么我们虽可做成一个型,做成一个套餐的产品,品牌是一个特性,价格为是一个属性。这样的话,神州行再来一个50块钱之套餐,我们不怕不需要改变什么用,增加有布局,定义有出品特性就足以了,这即是扩展性。 
大效率是说公针对现有的资源使用是匪是够高效。比如说有人写的代码比较烂,一启动就百分之几十的CPU使用率,这便无太合理。 
可测试,很多支之同班不当回事,觉得出好效益逻辑就是够了。但是你开出来的事物是要是保证质量的。开个玩笑,如果说测试的阿妹很美好,你肯手把手的使她如何来测试功能,但只要是妹妹走了,来了一个糙爷们还得你还手把手的驱动,你便非甘于了。因此要要发一个测试的完整方法、功能说明、测试用例。 
这些非功能性的需要,是百分之百系统是勿是正常稳定、可靠运行,以及被一个团伙长期沿用下来的一个前提。 
如果可用性,涉及到许多上面。比如说伸缩性,是否会以业务量增长的前提之下,通过水平扩展可以很容易支撑更多的作业。比如说安全性、可靠性,数据会不见面少?所以这之中很多的点,最终都是决定了可用性。 
这就是说可用性是呀吗?可用性就是即时套系统最终是为用户之所以的,是起这些作用的,但是任何地方只要无能够维系好,不克N个用户直接就此,那您这个体系就无法体现其的值。这是死主要之,很多恰恰工作几乎年的,或者是直接以举行产品研发的同室,对这点没亲自的认知,没有以雅晚上叫人通话说生了啊问题而快来拍卖一下,没有如此切身的痛苦的体会。 
「高可用」到底是呀 

 

属下去我们说一下啊是青出于蓝可用。CAP理论是依以分布式数据的气象来描写三者不可兼得,就是一致性、可用性和分区容忍性。在普体系层面也得这么明白,因为大部分系的骨干就是多少,数据本身受限于这三单特征只能满足个别只,不能够三独联合满足,整个系统啊是这么。 
在互联网状况里,因为数据量大分区容忍性是要使支持的。一致性可以稍容忍一些,但是可用性是早晚要保证的。所以最后多数底互联网商家大部分之事体系统就是是牺牲一致性,保证可用性和分区容忍性。 
我们继续向生看,什么得影响可用性。 

 

附带是人祸,携程公司去年吧起了「惨案」,系统宕机一下午,一直到晚才还原;还有阿里云,去年达到了一个云盾的功效,用户在实施可执行文件的时刻,就将这可执行文件给删除了,回头用户更找找这可执行文件的时光便搜不顶了。还有是BUG,在某有些一定情景下网发生题目,这是很健康的。 
规划缺陷是使要说的,它比BUG更宏观一些,是布局及之问题,不是说公增加几单判断,改一下代码就可以化解之。基本上是属一旦发觉了,要么就是是大改,要么就重构,调整原来的设计,很不便及时去解决。 
关于说性能瓶颈与资源贫乏,大家理解即便是如此多之服务器,如果代码性能写得好,可能能够扛住还多请,如果写得不比,可能略增长部分就算颇了。 
属性瓶颈就是是短板,比如说负责某个模块是一个从未有过啊更的有点同学,代码质量未顶胜,他就算可能变成了整整体系的短板,这个模块出了问题,其他的代码写得又好,整个系统或者不能够因此。 

 

最终还有一对未知的动静。大家做技术做的年月长会遇到不少无法解释的「未解的谜」,我们一般叫「灵异事件」,这个是赖经常发出的,你莫亮堂问题在何,但是过段时间就来同样不成,就好象冥冥之中有人打你平,但是毕竟是可以找到原因解决之。 
关于说黑天鹅的事件,则是以前从来不曾起了之状况,突然冒出了,让你无清楚应怎么处置,而且可能是一两年才面世同潮,你见面如考虑值不值得找它怎么冒出的。 
再有有随后就再度为无出新了,谁啊未了解是怎么回事,你就是不理解怎么处置了。最后一个是雾里看花之,我们无懂得会面世什么的事情,出现的情咱也未晓得怎样应对。科学告诉我们,已了解之我们得以错过全力化解,但是不得要领的,我们鞭长莫及看清。 

 

关于系统故障,有一个海因法则,意思是说出现并严重的事,都是由于许多的隐患,很多之粗题目,或者说一些问题远非露出来,最终引发特别特别的事故。负责运维的同班都掌握,公司本着网的可用性是发出指标的,是99.9%要99.99%,还是99.999%,如果说公司尚未这个事物压在您作为KPI,那就算不过走运了,出了问题不一定让您将不顶奖金。如果说公的号发出,我愿意研发与架构的同桌还设明,而非是只有运维的同校掌握,否则即是铺保管不做到,举个例子如果可用性标准是99.99%,一年体系可以悬挂的时光是53分钟,99.999%虽说是5分钟,大家想就懂得,携程挂了一致下午,整个可用指标便截止不成为了,KPI就得无了。 

 

强可用同时是一个概率的题材。一个犬牙交错的网,比如说多模块或者分段系整合的系,是可以通过有些智大概去估算的。前些年说道计算好生气,很多人口还说俺们出一个云要自动运行,几万台服务器必须使来自动还原的体系,最好是分钟级恢复,秒级恢复。这些都是一个概率,怎么去算吗?比如说我来星星点点只手机,最近一个月内发出3不成不同一点遗弃1光手机,这是吹事件,那么多自己掉的票房价值就确定了,比如就是1/30。我生个别独手机的说话来啊补,没有手机用底票房价值就是1/900。但是丢手机的概率增加了,我便设盘活心理准备,没随哪天就会错过一个。 
大部分体系是几乎光抑是几十贵服务器组成一个小之集群,还有很多暨她平行和上下依赖之系。这种系统还可以为此这种方法去算,大概是如何的几率。 
其一还干到容量评估,要考虑系统负荷是小?比如说像我们原先开公司级系统就此小型机,小型机的可靠性很高,平时即令是50%横之负载,这个时段三四玉机械加在一起就够用了,因为挂同一华基本上系统非会见起极端好影响。但是只要就此无顶可靠的PC服务器或者其它解决办法,因为担心或出现的景,所以现在无数互联网公司用的凡常年运行10%之CPU或者是20%之CPU状态。 
咱俩可设想一个体系,比如说一令机械挂了,影响系部分出现问题的概率有差不多大,多只体系总有一天会发题目,如果说系统足够大,大家可想像,无论是Facebook、谷歌,还是BAT基本上每日都见面产生各式各样的稍题目。所以进一步复杂的体系进一步难以评估,我们设包出现问题的当儿可控。高可用并无是十拿九稳,我们是故更多发生题目的概率去降低整个体系产生问题之票房价值。 
还有一个说法让墨菲定律。基本上你想到的极充分之业务它总会发生的。上学的时,数学老师会说,小概率事件基本上不会见有。但是于IT,在一个复杂环境中,在上千台上万高服务器的联谊众多被,几百人几千人开的系,一定会时有发生一致龙来题目的。所以人算不如天算,你总算出来概率很没有,你保证自己有题目的概率就是几十万分之一,你以为这一世就赶不达了?不见得的。 
这就是说怎么收拾?就是天天准备着。这是自己举行了如此多年支出极特别之体会。我们做的是一个7×24小时对外服务的系,不克终止。不克止住的定义不是说比如说一些企业那样,白天有人因此,晚上莫人为此,晚上出事了,我们来得及修补修补。但是比如电商是7×24小时的,半夜三四接触都产生下单的。人家在熬夜开心下单的当儿,你生了问题,阻止人家的下单,要不然就是是打电话投诉,要不然是找地方吐槽。 
系统故障不仅是技巧上之题目,最沉痛的凡潜移默化客户体验,前一段时间我们的褒贬系统发出了接触多少题目:一个客户购买了一个面条机,反馈说并无是坐产品本身做不好面条要退货,因为任何因,这个因为产品已经用了了用照确定是免可知退货的。结果用户想评论的早晚评论不了,用户就是当说当点击评论按钮时,系统报告接口错误,觉得就是当针对他,其实这只有是系故障,但是用户并无见面如此想。 

 

当你开了各种各样的备选,觉得万无一失了,难免发生同等龙或还是碰头翻船了。但是遇到这么的业务为是善,经验都是以是时节累起的。那么什么是赛可用?基本上就是三句子话,降低故障出现的几率;缩小故障影响之限制;出现故障快速恢复。不能够因为凡单小问题不怕以为无所谓,反正自己同样堆的服务器,挂一个就是吊一个吧,这种状态糟糕说会见不见面另外一个也吊起了。因此有题目如果尽早处理,最终的目的就是吃用户可健康的利用。 
争规划大可用架构 

 

愈可用架构设计常用之「姿势」。大家收看就是平等劫持飞行器。我们发一个比喻说开运维这种系统,就是始在飞机修飞机。首先系统一直运转,其次运营、产品各种事务单位会无鸣金收兵取各种各样需求,然后领导或不知晓技术,不了解啊叫分支、什么让循环、什么让面向对象;但是知道两个词,一个是快捷,一个凡是迭代。 
所以开这件业务的时光难度是比大的。我们不能够给这架飞行器停下来歇几龙,把翅膀换了重复飞上;而是成年以天空飞的,飞上的时候或就是是只阿帕奇直升机,特别是创业公司。回头要拓展一个事务,增加部分成效,做在开在原的政工大了,新的工作化了主营业务,结果变成了F15,从直升机变成了战斗机,然后变成F16,变成F22。一旦技术团队没办好,一头栽下,技术集团的声就砸了。要么是没有做下,要么是做出来以后一律达线悬挂了,市场用都白花了,这个事而术来负担。 
本身在四单领域里面分别提炼了几久大可用相关的架方式。 

 

工作架构纵使是据产品是呀功效,有啊要求。 

  • 首先是领域切分,不要管鸡蛋在一个篮子里,比如说有的传统网站,有良多之二级域名。某一个二级域名挂了,都是差之服务器,其他的还好提供健康的服务。
  • 系统分级,哪些系统对用户来说比较主要,级别就会再也强,我们将花更多心思去维持,其他的相对差一些。
  • 退耦合,最近在绑架构圈当中流行一个乐章让康威定律(编者注:Conway’s
    law: Organizations which design systems […] are constrained to
    produce designs which are copies of the communication structures of
    these
    organizations),是靠系架构是同合作社团队架构是生关系之。降低耦合也是这般,不要把系统整治得无比复杂,你的团伙和团伙不要与太多的单位打交道。优化架构,让系统的涉及尽可能的简单、明确。这样出现问题范围可控。
  • 发出贬损服务是什么意思为?可以牺牲局部用户体验来确保基本功能的可用。

网架构当中,分以下几点。 
第一独凡是数量独立,不允超过系统访问数据库是常识大家还亮,但是过多商行召开不好,因为从没有力的计失去决定。这种业务做起来不极端爱,需要管理或说大家认可才行,但是实际是异常主要之,因为数量而无切分,系统十分不便切分,耦合就杀沉痛。时间长了产生了问题,你并谁写的,谁改变的这个数额还无晓得,那怎么处置? 
第二触及是集群分布,这个就不取了。 
第三只是冗余部署。比如说电商工作是出动乱的,每天的上午11点要么是下午4、5触及签订单量都见面加强,上班族都要休息一下,给自己的累找有思想慰藉,这个时起购物。但未克说不怕立即点增长就弹性部署一糟。所以必然要是来冗余,一般来讲是3-5加倍,保证哪怕突然来了一波流量而吧足以扛得下马。 
尤其是电商企业,可能会见为一些促销,可能有的业务部门搞促销的时光,没有打招呼技术机构,觉得这个促销没什么,可能一两龙即整治定矣,然后流量预估为尽管上200%。但是要是赶上这是网络红人、明星或是稍微鲜肉出了书写、发了唱片或者过了哟衣服,一下子成了爆款,系统绝非扛住,然后运营回头就得抱怨白折腾了。 
第四只读写分离之不用说了。
 
技术架构方面,仔细说一下。要是稍微店发生了呀问题,几个人点个头,达成共识就好了;但是一个上规模的店堂,技术团队几百人数还是上千人口之团,如果技术面控制不了的语,就会起大惨重的隐患。 

  • 第一是选项采取的艺平台,有的店java也发、PHP也发、Python、Go等等的啊都产生。
  • 其次是人手效果,有的局说咱的工程师还设开全栈工程师,我们的工程师什么都见面。创业团可以,但是一般成熟之局都是专业分工,专业分工就来了一个题目,大家毕竟如果通,而且不少东西用有人不断运维,因此尽管发生必要统一技术标准。
  • 其三碰就算是专业标准,比如说代码、发布的正统都如发。如果说得沉淀的话,以上说的标准是好做成一个统一之框架,现在当当也在举行一个框架。
  • 再有就是是客观之选型,一方面不同特点的艺需要因此到适当的现象中。另一方面不确切的技能选型一定要是硬着头皮遮。因为今天无数同桌都产生好高涨的求学热情,新技巧层出不穷。这样的话很多总人口会犯一个「锤子心理」的错误。
  • 像我近年当当当上请了扳平本书,花了少于单月看罢,然后赶上做一个色,我便以为自己挺懂得了,英雄出矣用武之地。锤子心理是什么意思呢?他起了一个锤,看哪个都是钉子,就想敲诈敲。这种气象是一旦控制的。
  • 莫不这技能不是匪可知就此,但是不是充实系统的当,公司能无克循环不断运营。比如导致来一个牛人,这个牛人好写了一个框架,用了什么算法。用起来的确好好,但是下牛人走了怎么惩罚?出了问题怎么处置?谁管?这种题材且是若考虑的。
  • 还有就是是频频集成。我们只要于技术界去保险多数测试都得以挂至,不克说换一个测试或是变一个支付就经常犯有再次的初级错误。

基础架构 

  • 于一个完完全全的网当中有有同事务没有关系的系统,比如运维平台的是,是为降低运维的风险,同时也是以提高效率,保证质量。
  • 准统一监督,那么稀一个体系谁知道何出题目,哪里不正常,所以要要统一监督。
  • 还有是压测工具,比如双十一,你出没有发信心?谁胆敢说?我们设进行测试,压测之后咱们说5加倍没问题,10加倍没问题。但是未压测谁胆敢说?
  • 再有即使是流量控制。常见是分散和限流,如果说出一个页面访问量太好,可以分及类似之页面去,更老的时候咱们只能限流。

电商系统架构 

 

其一图是一个比较简单的电商系统架构,主要说说系统子。最上面的触发是亮,包括首页、搜索、列表、活动专题页这些东西,这个展示莫过于都是用户查询的,没有操作,只要用户可看便好了,这些数据是可缓存,可以静态化的,可以通过如此的法子确保用户访问,可以管多少都缓存起来。比如说当当的首页,是免依靠任何系统的,其他系统都挂了,首页打开是没问题的,毕竟主站是极度要命之流量入口。 
再有第二点即是交易系统。和订单系统是上下游的干,交易系统是甚成订单的,订单系统是拍卖订单的。交易系统的订单数是在自己之数据库中。为什么吧?因为毕竟用户来了,终于下单了,一定要预留。订单系统吧老复杂,不可知说为订单系统挂了,导致订单无法充分成了。所以生成订单就宗业务是在交易系统完成的。订单系统可异步去处理订单,订单系统来了问题,用户该进要好打的,这是电商当中非常重要的。 
老三单凡是货物数量核心,就是为对前面的当即同积聚面向用户的看,我们的数据是单身生同一份只有读的对外提供,和后的PIM系统是分离的。PIM是描摹,这边是读。如果PIM挂了,没有问题。后台系统不见面针对前台造成极其老之熏陶。 

 

交易系统是极核心之,最充分的沉重是殊成订单。除了核心的生成订单的功力,还可开啊也?第一虽是若赶紧!比如说促销,这里没写价格和库存,价格同库存都是快数据,要求尽量准确的,我们还是实时的。但是促销是可以缓存的,因为今尚非是网智能去调动促销政策的,都是乘人工设置的,节奏及效率都是比小的,缓存下来以后,基本上是OK的。避免促销服务不安宁对交易来震慑,如果用户点半上没反应,用户就是见面倒之,要落因。 
还有一个市单缓存,就是订单生成之前的旋数据,要选出办法、要描绘地址、要摘是不是为此红包、抵用券、优惠卡这些事物,选得多了,万一客户端浏览器崩溃了、网断了还是是闪断、交易系统应用服务器某一个节点挂了,怎么惩罚?这是极其重点的随时,都曾临门一脚了,我们是来缓存的,数据量也无是非常怪,只要他以可比短缺的流年内开辟,填的事物还于,还可顺利的朝下活动。这个为是充分关键之。我记忆以前有些网站发出了问题,要还选择同合,那个时刻看怪苦恼,除非此事物坏需要,否则那就算了。 
电商数据模型 

 

即时是电商最广泛的数据模型,商家来宣布商品、设置促销、价格、库存这些事物。用户来浏览、收藏、加入购物车,最后下单。对于平台电商来说,就见面出现多单局,商品要以企业来划分,订单也如按公司来分。但是针对用户来说,收藏、加购物车的货色还有订单对应之是差不多只企业。 
夫时刻有一个死明白的题材,比如查询收藏列表,或者是企业管理他的货物之时光,怎么样可以便捷的拍卖?商品或产生几千万上亿,肯定不会见在一个数据库里,多独数据库,按什么分?后止按商家分,前边按用户分,中间两模仿数据库。 
说起来逻辑其实很简单,但是不少创业公司无琢磨过这个从,中间就是一个库,上面设一个目,数据量小尚并未问题,一旦那个了怎么惩罚?觉得就是解决不了的题目。 
更为吧,这就是一个景象,还有一些再具象的现象。比如说我们正提到购物车或者是收藏夹,如果以购物车或者是珍藏夹,商品数未按照用户来分,也非遵循协议家分,就仍商品ID来分,均匀的遍布于咱们的数据层是休是实用? 
此逻辑在平时或者没有问题,但是电商有一个说法让爆品,大家可想像一下,平时凡是绝非问题之,正常下独自正常浏览,一旦出现爆品,就会油然而生热点数据。爆品所于的数量分片会被用户集中浏览,热点问题没有主意化解就是计划性缺陷。再怎么划分,那一个货品就以一个仓库中,你为不克把她同样照两半。就是本人正好说的,可能突然从天而降一下,时间呢未添加,但是你扛不停止,扛不停歇怎么惩罚?我们说话加以。 

 

资源隔离重点保障,这吗是老大重要的。比如商品数核心让前台提供商品数量,是分成三单集群的。那边的是网站,这边是App,这边是购物车和市,各自都有协调的缓存和数据库,数据完全同的。为什么而分离?和刚说的同等,首先交易下单是无限着重之还要性能要保,不克吃外场景的震慑。其次移动端也大重大,大家还是当大哥大及操作,其实对快是雅关爱的,不可知为网站流量大了,导致手机浏览缓慢,甚至好挂掉一个集群,其他的尚健康,其实就是不用把鸡蛋置于一个篮子里。用空间更换时间,用时变空间。 
经过框架来建开发规范 

 

咱举行的一个框架为ddframe,这是咱技术面想做的工作。很多底互联网企业开平均工作经历来3年尽管正确了。因为及时几年各种创业公司比较多,膨胀的也殊厉害,要找有起经验的工程师很麻烦。很多开同学没有更了各种惨痛教训,开发还是较随便的,因此我们得开一个支出的框架去吃他俩做一些标准之行,能够使得之失去帮衬他们,尽量不去做一些非常的政工,因此我们举行了ddframe。 
框架来几乎独模块:包括无与伦比中心之片、包括跟监察的属、SOA的片段DubboX、还有作业框架elastic-job、以及分布式数据库中件sharding-JDBC。 
Dubbox是咱以Dubbo的局面做了二次开发,现在产生诸多合作社于于是,这个局部将一般的服务登记、软负载、路由于都搞定了。 
elastic-job是分布式作业调度框架。采用分布式作业调度框架前发出啊问题呢?第一单凡是怎落实避免单点,很多口是这么做的,两雅机器还配备,其中同样玉crontab注释一下,一玉机器发出题目了,就失另外那台机械及管注释去丢,这是蛮低效的,而且是一心依靠人的。机器多了怎么收拾?因此我们要分布式的课业调度。这是我们去年付出之,最近唯品会以咱们的头版本基础及,自己做了一个里的课业调度平台,当然为欢迎大家用。我们怎么自己做,为什么未用TBSchedule,是坐我们发现没特意适合的,所以自己开。 
其次单模块就是RDB,就是分布式数据库问题,和强可用关系不太怪,不详细介绍。总体而言,我们是思念经过统一的框架、技术组件降低开发人员实现之复杂度,减少风险,不叫她们找劳动。 
发出了框架就发出了工具,有矣工具就生出了一起的语言。大家好回想一下历史课,秦始皇统一六皇家之后开了哟,统一度量衡、钱币、文字。有矣这些合并的东西,大家互动之间比较便于交流、积累经验,如果说某某团体于闲了,也可支撑别的团队,有人以有团体腻了,可以去其他的团。 
运维及督查 

 

本俺们来一个运维平台,但是去年技术圈出现了那基本上之各种风波,运维经理说运维太重要吗尽惊险了,因此我们召开了一个要挟的生环境灰度发布,不允而一样键发布,给大家一个缓冲。自动备份也是深主要之,如果说您意识灰度发布第一独节点就报错了,你只要举行的政工就是回滚。 

 

联网下去是监督。监控是一个分外挺的体系,非常的关键。一个好之监控网可能更牛,因为即使是24小时还发生运维的同窗,但是运维同学也发生打盹的下,或者是从来不留神。经常我们会以影片中看到,某一个那个盗窃进入及某一个高楼中间,保安就当那里喝个茶叶啊的,保安从未有过看。这种事情是经常会面有。 
还要发生了监督就产生矣数,监控无自然点报警,但是你有了数额以后可以看大势。比如说最要害的一点–预算。我们今年要选购多少令服务器,多数凡是拍首拍出去的,业务说我们今年业务量增多30%,我们大多购买30%底服务器,就是这么撞首拍出来的,其实这是匪精确的。 
倘若系统于少数场景下出人命关天的性衰竭,需要去评估,或者一旦失去看,不同之事务模式会对系造成不同的下压力。比如有系统今年负荷反而下降了,就于下减服务器。有的可能多200%,原来10%底载重,现在变成了30%了,那么这种,哪怕你的业务增长30%,这个压力要提高200%。这是什么概念?之前是10%顶30%,现在尽管是30%届90%了。你独自来产生矣这些数量,才足以合理的夺估算。 
大促或者出现爆品时怎么收拾 
相信于上海底同校为还赶上过这样的状态。在地铁站,高峰时限流,用栏杆把丁挡住。限流基本上是电商标配,以前不曾,所以动不动就挂了。现在秋了,如果起了爆品,出现了热门数据怎么处置? 
卿无能够说流量一来你便挂了,这个时刻限流就生重大了。举例来说可扛得住8000,8000外面的即使拦截,不被进入。比如淘宝去年双十一零点后的几乎分钟,有人手机淘宝上无错过,或者是支付宝支出未了,就在爱人围里发截图说淘宝以挂了,但是没多少人口对,因为多数丁是得采取的,他正好倒霉,是被限流了。有了限流今天来10加倍即10加倍,来20倍没有章程,但是系统扛得住,把任何的流量扔了,保证了基本的进项。 
这就是说最终我们欠做的事情都召开了,还能怎么处置为?就不得不请佛祖保佑了。这种时刻发生信仰也许会针对你的系可用性指标小帮助。不管有无发出因此,我们得竭尽全力一下,在大团结之代码注释当中放上一个佛祖保佑一下。

 

 

分类:
聊天架构

 

相关文章