高可用架构经验

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/chosen0ne/article/details/75313375

之前给组内同学分享了高可用方面的一些经验,具体见slideshare。一些关键点整理如下:

高可用
    - 冗余
        - 服务
            - 负载均衡
                - lvs + keepalived
                - 多组lvs,一组lvs间是vip漂移,组与组之间是通过DNS轮询完成,即域名对应多个vip(不同运营商对应不同ip)
            - 反向代理
            - 应用服务
            - 服务化框架
        - 存储
            - 缓存
            - 结构化存储
            - KV
        - 硬件设备
            - 交换机
            - 网卡
            - 机柜
            - 公网出口
            - 机房
    - failover
        - watch-dog检测
            - sentinel
            - mysql MHA
        - 调用方检测
            - MCF
            - momostore
            - HTTPClient代理
        - 框架、服务自动实现
            - 分布式存储
                - HBase
                - Cassandra
                - redis cluster
                - codis


稳定性:
    - 稳定性是需要高可用的保证
    - 实现细节上需要考虑
        - 资源上限:线程数、内存队列长度、连接数……
        - 突增流量:限流
        - 非核心服务故障:降级
        - 依赖服务变慢:fail-fast
            - 如过服务调用路径很长,其中某个环节变慢。这种情况下,如果不处理,请求占用的资源会越来越多,响应时间也会越来越慢。合理的处理方式是当服务慢到一定程度时,fail-fast,并且最好在调用的源头实现,可以保证没有占用过多的资源。
        - m*n依赖的影响扩大:实现上解决;自动隔离;合理的超时时间
            - m个服务实例需要访问n个数据源,客户端随机路由到一个服务实例,服务实例按照一定规则访问数据源。如果某个数据源变慢,由于随机访问服务,所有的服务实例都会访问该数据源,目前moa层面是通过线程池处理每个请求,如果数据源越来越慢,并且请求不变,会导致线程池中堆积了大量访问该数据源的请求,而没有资源处理其他请求。这就是一个数据源故障,进而影响所有上层服务的情况。
                - 实现上解决:线程池只做计算,通过事件循环处理网络IO。
        - 队列消费端高可用:多消费者抢占消费
        
性能&扩展性:
    - 异步:异步处理部分逻辑,降低响应时间
    - 水平扩展性:通过加机器解决请求的增加
        - 服务层面:要做到无状态,可以将状态放到存储上
        - 存储层面:做到一种好的数据分布策略
            - hash:
                - 缓存:增删节点,rehash严重,会有大量穿透风险
                - 存储:每个hash分片保证高可用
                - 扩容:成倍扩容,不太合理
            - 一致性hash
                - 缓存:增删节点时,rehash可控;并且通过虚拟节点,可以进一步优化
                - 扩容:支持单个实例扩容
                - 示例:Cassandra
            - range:
                - 存储:需要存储数据分布的元数据。
                - 扩容:支持单个实例扩容
                - 示例:HBase
            - hash + range:
                - hash key先hash到一个值域,再进行range划分
                - 分布比较均匀
                - 示例:redis cluster,codis
            - 二级映射:号段 + 尾号 => range + hash:
                - 陌陌

监控&报警:
    - 发现问题,快速解决问题
    - 类别:
        - 资源监控:cpu,内存,IO,网络……
        - JVM监控:
            - gc次数
            - gc耗时
        - 服务监控:
            - 耗时分布(95%, 99%等)
            - 请求量
            - error count
            - 线程数
            - HugeTimeout
            - FrequencyCount
            - 调用链
            - MOA-Watcher 

没有更多推荐了,返回首页