还记得这一次微博宕机事件吗？我们怎么来避免这种情况呢？

上图就是我们一般普适的架构设计，网关层、业务层、数据访问层是无状态化的，可以无限扩展的，大家应该可以想到造成宕机的原因可能出现了DB层。那我们怎么来避免这个问题呢？

去热点化

可以将热点数据可以跟服务绑定关系？那怎么绑定呢

热点数据放在数据访问层内。

鹿晗的feed流其实就是map结构，无非就是123=大家好，这是我女朋友，关晓彤

第一次访问的时候，如果数据不在物理内存里， 从redis里读出来，在本地做缓存，下一次直接读数据访问层。

哪些数据放在数据访问层里面？

热点预测系统：1秒内超过1万次，就可以认为是热点数据。

那我们怎么知道什么是热点数据呢？

技术设计:

将数据接入到flume里,然后将数据压入kafka里，再通过spark streaming做实时计算，如果1秒内超过一万次,就把数据放到配置中心，比如 Nacos(阿里)，Apoll(携程)，数据访问层就来读取这个数据 。这中间是一致保持的长连接。

思考？1秒钟之内还没计算完的时候，访问全部打到redis，还是会出现问题啊？怎么去保护？限流、容灾降级.....

解释下上面的图：

线程来访问数据访问层das，其实本质是一个I/O线程，会将每次的请求按序排进列表，然后由workThread来依次拿取线程。

我们的请求req里，在http里的head里获取到start time(线程入队的时间 st)，workThread 取出的时候同样的是有一个时间是endtime(et) et-st 约等于0 ,et - st > 1 s 输出是小于输入，直接丢弃;et-st< 1 s  取出，做读取操作。这就是一种降级的操作。是不是有点骚。

上面讲的是读的问题，那下面我们说下写的问题。因为有很多百万级的评论输入。

其实这个就是跟我昨天写的文章中可以得到讯息。对咯。就是写MQ，异步写入。

 按图说话：MQ可以做集群，理论无限的扩展broker，就差不多解决了写入的瓶颈问题。

紧接着问题又来了，既然分析了这么多为什么，为什么下面这件事情还是会出现宕机的问题呢？

 主要还是ROI的问题投入产出比问题

计算：1T 192G内存  万兆网卡 差不多5万左右

10w台机器(肯定能够抗住80个明星出轨的并发)差不多就是50亿，试问哪家公司会这么土豪，闲置这么多机器就是为了顶住这一次的并发。只要通过限流和数据访问层的设计等等也可以保证AP型的来解决这个问题即可。

这就是业务blance的架构思维模式。基于业务的考虑的权衡。

周末加餐：架构，需要构建思维习惯

程序员的迷茫不仅需要面对技术繁杂的无力感，更重要的是因为长期埋没于软件世界浩瀚的分工体系中，无法看到软件本身的价值链，没法清楚的定位自己的位置，处理不好自身与技术、业务关系。

其实作为程序员，我们打心眼里是不喜欢业务的，宁愿从事框架工作，基础组件研究的相关事情，最烦的就是天天加班写了那么到业务代码，还是没有改变自己，最后留下了一堆的垃圾代码。

对于我们很多程序员来讲，业务在我们的脑海里就是一堆的逻辑和流程，几乎没有去考虑业务场景的感受，对用户体验痛点的体会，对业务发展的考虑。其实这些才是真正跟价值息息相关的部分。

那么我们应该怎么去理解业务呢？

指的是有目的工作和项目。业务的目标就是解决了人类社会与吃喝住行息息相关的领域问题。比如为了解决用户随时随地购物的业务问题时，程序员利用 Web 技术构建电子商务 App，而当需求升级为助用户快速选购商品时，程序员会利用数据算法等技术手段构建推荐引擎。

这条价值链条的理解可以理解为：公司依靠软件系统提供业 务服务而创造价值，程序员则是通过构建并持续演进软件系统服务能力以及业务功能 以支撑公司业务发展从而创造价值。

<<   >>

什么是架构？

组织业务：简单的理解就是拆分生命周期，确立业务边界，构建出一套解决特定业务问题的领域模型，并且确认模型之间、领域之间的关系和协作方式，完成对业务领域内的组织工作。

组织技术：软件系统就像是一种技术组织，即技术组件、技术手段依据某种逻辑被组织起来了，这些技术工具被确定了职责，有了明确分工，并以实现业务功能为目标集合在了一起。比如RPC框架或消息队列被用于内部系统之间的通信服务就如同信使一般，而数据库则负责记录结果，它更像是一名书记员。

组织人员：为了能够实现利用软件系统解决业务问题的目标，架构师还需要关注 软件系统的构建过程，他以实现软件系统为号召，从公司组织中聚集一批软件工程师，并将这些人员按不同工种、不同职责、不同系统进行组织，确定这些人员之间的协作方式，并关注这个组织系统是否运作良好比如沟通是否顺畅、产出是否达到要求、能否按时间完成等。

组织全局，对外输出：解决业务问题，推动业务增长。所以 他非常关心软件的运行状况。因为只有在软件系统运行起来后，才能对外提供服务， 才能在用户访问的过程中，解决业务问题。架构师需要关注运行过程中产生的数据比如业务成功率，系统运行资源占用数据、用户反馈信息、业务增长情况等，这些信息将会帮助架构师制定下一步架构目标和方向。 

架构目标需要适应业务的发展

架构的目标就是为了支撑业务增长，就是提升软件系统的服务能力。比如对初创团队而言，其产品是否解决业务问题这一设想还没得到确认，就立即去构造一个高性能、高可用的分布式系统，这样的架构目标远超出业务发展的需求，最后的结果就是浪费大量人力物力，却得不到任何起色。

架构师需要审时度势，仔细衡量正确性、大规模、可用性三者的关系，比如今年业务 蓬勃发展日均订单300万，基于对未来的可能预测，明年可能有3000万的订单，那么架构师应该要着重考虑大规模和可用性。

而且每一点提升的程度，也需要架构师衡量把握，比如可用性要达到2个9还是3个9。回顾自己以往的工作很多时候就是因为没有确立架构目标导致浪费了组织很多资源，比如在之前的创业团队中，经常会花费很多时间和 同事计较代码质量，这样本可以更快上线的功能却需要被延迟，当时过度追求正确性的行为是与创业团队快速验证想法的业务需求不匹配的。