戏说系列-从术和道来看基于流量的架构设计（下）

    又过去好几天了，上周公司事情太多，所以没有时间来写了，一件事情坚持真的很不容易的，今天继续。。。

    大家看看上边的图，在规划流量阶段，通过应用上边的流控策略，包括数据局前置，基本可以解决大部分的问题，但是仍然有些问题是没有解决的。因为每天每个时段的流量的特点不同，我们需要的是可以动态，甚至是智能的对流量进行调控，所以就需要有一个智能的开关调控系统，根据流量的特点不断的人工或者智能进行流量的调控，比如限流的值，线程池的值，开关的值，这样就可以实时的智能的进行一些流控和降级的处理。。。。同时有些业务临时数据我们是看不到的，比如在抽奖的业务环境下，用户可以抽的次数在缓存里边，如果我们想要看某用户当前的可抽次数的话，那么一般可以找DBA，但是这样做太麻烦了，如果有一个智能的业务数据监控系统，那就好办多了。。这个阶段我们需要最终的效果是流量可以动态调控，系统架构可以动态的收缩。系统架构动态收缩的意思是，比如到了大促销公司机器不够，这个时候可以把一部分服务机器减少，然后流量进行降级处理，空闲出来的机器就可以给其他的应用来用，以保证核心业务的正常运行。

    

    再看看上边的图，在设计流量阶段，更多的使用大数据与AI技术实现流量可分析可预测，智能倒流，千人千面。这部分不是文章重点，暂时不讨论。

    下面我们先总结一下：

    1. 流量治理的目标：快速成功，快速失败。快速成功很好理解，请求来了，我们希望能够尽早拿到数据，尽早成功，快速成功也是可以避免流量挤压。快速失败就需要我们考虑一下了，当流量来了后如何可以快速失败呢，比如熔断，线程池隔离，降级，设置合理的超时时间，等技术就是为了应对快速失败。需要注意的是设置合理的超时时间，这一块是需要权衡的，设置的太小失败率高，设置的太大容易请求挤压和超时。
    2. 流量管理的目标：可动态调控，智能开关
    3. 通道数据的管理目标：可查看全通道数据
    4. 终极目标： 智能体验，千人千面，可分析可预测

    终于要到说说术和道的问题了，哈哈。。。流量来了，如何通过术和道的方式来看待问题呢，那么先说说银弹吧。所谓的银弹就是用上去以后会有立竿见影的效果，比如缓存，如果读的请求比较多，那么使用缓存，或者说是多级缓存，多层次的缓存，那么就可以有立竿见影的效果，比如客户端缓存（H5，APP）,接入层本地缓存(LUA),接入层本地REDIS缓存，接入层分布式缓存，应用层本地堆内缓存，应用层本地堆外缓存，应用层本地REDIS缓存，应用层分布式缓存，数据库缓存等。限流的话，具体的限流算法就不说了，比如桶漏法等。主要接入层可以使用LUA进行限流，应用层使用RateLimiter,信号量等都可以进行限流。截流主要是通过异步的方式来完成，具体可以参考上一节的截流部分。

    接下来看看术的部分，术的部分主要是流控，数据前置。流控上一章节介绍过了，数据前置主要是一种思路，能前置的数据就前置，前置的目的就是想让用户尽快尽早的拿到数据，而不是要到MYSQL才能拿到，比如能在终端拿到的就在终端拿到，能再接入层拿到的就到接入层，能在应用层拿到的就在应用层，能在本地缓存拿到的就在本地缓存，能在分布式缓存拿到的就在分布式缓存拿到。

    然后我们看看道的部分，首先看看系统拆分，从流量的角度来看的话服务化，微服务也是流量驱动的，那么如何拆分系统，拆分后系统之间的关系管理，系统的高可用和系统层面的降级都是我们需要考虑的。一般会根据业务进行拆分，比如分成用户中心，活动，支付，账务等。拆分的时候考虑好系统的边界。

    上图是通道优化的内容，通道优化我们要考虑整个通道可能的瓶颈点。从终端往后，比如带宽是否有瓶颈，网卡是否有瓶颈，路由器，交换机（一般硬件架构的瓶颈在系统运维层面已经考虑到了），操作系统是否有瓶颈（比如操作系统的版本是否支持NIO,操作系统的句柄数，最大线程数，LIMIT.D等），需要关注和了解操作系统的内核态，用户态，零拷贝，线程管理，NG是否有瓶颈，比如NG的进程数，NG的连接数，超时配置等。TOMCAT的IO模式，连接数，最大线程数等。JVM的堆内存，栈内存，GC等。本地缓存是使用堆内还是堆外缓存，还是本地REDIS，如果是堆外缓存需要考虑序列号的问题，如果是本地REDIS需要考虑连接数，超时等。MQ需要考虑发端的模式，消费端的模式，消费端的数量，一次获取记录的条数等。程序优化主要考虑使用数据类型的合理性，算法的时间复杂度等。MYSQL主要考虑是否可用使用MYSQL自己的缓存，能否走索引扫描，能否走覆盖索引扫描，数据库锁的问题。

    上图是配置管理需要考虑的内容，比如开关的值，限流的值，线程池的值，超时的值，熔断的值，降级的值。这些那些是可以动态管理的，那些是短期内无法实现的，那些是需要特别注意的。

    上图是团队建设的内容，有人说应对流量为什么还要考虑团队建设呢？线上出问题的时候能否快速的反映，快速的解决，这对一个团队也是一种挑战，如果我们的团队是积极的，有责任心的，快速反应快速学习的队伍，那么就不怕，即使有问题也可以快速的解决，但如果线上有问题了，找不到人，或者上线后没有人验证。。。。。人的问题始终是一个核心的问题。

    然后说说数据链监控的问题，比如抽奖的时候，用户当天可以抽的次数，用户总共可以抽的次数，如果我们想看某个人的次数的话可能需要赵DBA，但是这样就太麻烦了，如果公司有自己的业务数据链监控系统的话，那么就好办了，这个对应付线上的问题，及时找出问题有很大的帮助。

    上边说了这么多，什么术啊，道啊的，其实就是想说，当我们接到一个系统的时候，我们应该清楚有多少流量是前端可以挡住的，有多少静态流量走了CND，有多少静态流量走了NG的缓存，有多少静态流量走了分布式的文件系统。又有多少的动态流量走了接入层，有多少动态流量走了应用层，应用层又分别到了哪些服务，百分比是多少，多少流量走了缓存（终端的，接入层的，应用层的，分布式的），最后有多少走到了数据库。同时自己也要清楚这个链路上哪些地方有瓶颈，哪些数据是可以前置的，哪些流量可以做流控，自己心里有了一个大概的思路和想法，那么在应对这样的系统心里就有底了。

    上边其实对于具体技术的细节讲的都很少，我在这次分享也不想谈太多，懂得怎么处理才是大道，如果我告诉你限流的代码怎么写，怎么用缓存，怎么写LUA，那么大家完全可以去百度，一大把的资料，思想和思路很多时候可以让你懂得自己改怎么做，改怎么学习，去往哪个方向学习，这个才是正道，如下图：

    通过本博客大家通过流控，通道优化，数据前置等能知道自己的学习方向，并丰富自己的知识体系，最后形成自己的架构体系才是正道。至于代码怎么写，有没有DEMO，大家还是去找百度吧。。。 孩子又闹了。。。技术博客想坚持真的很难。。每次都是10点回去，到11点才有时间写，往往是一遍需要好几个夜晚。。。