来源 | 微观技术 作者 | 微观技术 大型互联网架构设计,讲究一个 如果能掌握这四个方面,应付大厂面试以及日常工作中的架构方案设计,基本不是什么难题。 今天,一起来学习下 一、系统拆分有句古话 "牵一发而动全身"。 面对一个庞然大物,如果没有一个合理的分工分层。任何一个小小失误都会被无限放大,酿成巨大灾难。 万物相通,回到我们的软件架构。 早前的系统都是单体系统,比如电商业务,会员、商品、订单、物流、营销等模块都堆积在一个系统。每到节假日搞个大促活动,系统扩容时,一扩全扩,一挂全挂。只要一个接口出了问题,整个系统都不可用。 “鸡蛋不能放在一个篮子里”,这种连带风险换谁都承受不起。 因此, 慢慢的就有了我们现在看到的 二、解耦软件开发有个重要原则“高内聚、低耦合”。 小到 就以 Spring 框架给我们提供了一个很好的思路,里面有个重要设计 核心就是采用动态代理技术,通过对字节码进行增强,在方法调用的时候进行拦截,以便于在方法调用前后,增加我们需要的额外处理逻辑。 当然还有一个重要思路就是 三、异步同步指一个进程在执行请求的时候,若该请求需要一段时间才能返回信息,那么这个进程将会一直等待下去,直到收到返回信息才继续执行下去。 效率会大大降低,聪明的人想到了 如果是非实时响应的动作可以采用异步来完成,线程不需要一直等待,而是继续执行后面的逻辑。 如:线程池(ThreadPoolExecutor)、消息队列等都是这个原理。 比如一个用户在淘宝下了一笔购物订单,关心的是订单是否创建成功,能否进行后续的付款流程。 至于其他业务动作,如短信通知、邮件通知、生成订单快照、创建超时任务记录,这些非核心动作用户并不是特别关心。 我们可以采用消息队列的 其他事情,由不同的 Task 任务订阅消息异步处理,彼此间互不干扰。 四、重试重试主要是体现在远程的 RPC 调用,受 为了提升用户体验,调用方可以通过 接口重试是一把双刃剑,虽然客户端收到了
关于
五、补偿我们知道不是所有的请求都能收到成功响应。除了上面的 业务补偿根据处理的方向分为两部分:
补偿有很多的实现方式: 1、本地建表方式,存储相关数据,然后通过定时任务扫描提取,并借助反射机制触发执行。 2、也可以采用简单的消息中间件,构建业务消息体,由下游的消费任务执行。如果失败,可以借助 MQ 的重试机制,多次重试。 六、备份任何服务器都有宕机的可能性,一旦存储了数据,带上状态,如果发生故障,数据丢失,后果是我们无法承受的。 所以, 那如何备份,不同的框架有不同的玩法。我们以 Redis 为例: Redis 借助
一旦主节点挂了怎么办? 这里引入哨兵机制。哨兵机制可以实现主从库的自动切换,有效解决了故障转移。整个过程分为三个阶段:监控、选主、通知。 除了 Redis 中间件外,其他常见的 MySQL、Kafka 消息中间件、HBase 、ES 等 ,凡是涉及到数据存储的介质,都有备份机制,一旦主节点挂了,会启用备份节点,保证数据不会丢失。 七、多活策略虽然有了上面的 在一些极端情况,如:机房断电、机房火灾、地震、山洪等不可抗力因素,所有的服务器都可能出现故障,无法对外提供服务,导致整体业务瘫痪。 为了降低风险,保证服务的 24 小时可用性,我们会采用 常见的 不同的方案技术要求、建设成本、运维成本也都不一样。 多活的技术方案复杂,需要考虑的问题点也非常多,这里只是抛砖引玉就不过多展开。 八、隔离隔离属于物理层面的分割,将若干的系统低耦合设计,独立部署,从物理上隔开。 每个子系统有自己独立的代码库,独立开发,独立发布。一旦出现故障,也不会相互干扰。当然如果不同子系统间有相互依赖,这种情况比较特殊,需要有默认值或者异常特殊处理,这属于业务层面解决方案。 隔离属于分布式技术的衍生产物,我们最常见的微服务解决方案。 将一个大型的复杂系统拆分成若干个微服务系统,这些微服务子系统通常由不同的团队开发、维护,独立部署,服务之间通过 隔离使得系统间边界更加清晰,故障可以更加隔离开来,问题的发现与解决也更加快速,系统的可用性也更高。 九、限流高并发系统,如果遇到流量洪峰,超过了当前系统的承载能力。我们要怎么办? 一种方案,照单全收,CPU、内存、Load 负载飙得很高,最后处理不过来,所有请求都超时无法正常响应。 另一种解决方案,“舍得,有舍有得”,多余的流量我们直接丢弃。 限流定义:
根据作用范围:限流分为单机版限流、分布式限流。 1、单机版限流 主要借助于本机内存来实现计数器,比如通过 AtomicLong#incrementAndGet(),但是要注意之前不用的 key 定期做清理,释放内存。 纯内存实现,无需和其他节点统计汇总,性能最高。但是优点也是缺点,无法做到全局统一化的限流。 2、分布式限流 单机版限流仅能保护自身节点,但无法保护应用依赖的各种服务,并且在进行节点扩容、缩容时也无法准确控制整个服务的请求限制。而分布式限流,以集群为维度,可以方便地控制这个集群的请求限制,从而保护下游依赖的各种服务资源。 限流支持多个维度:
常见的限流算法:
十、熔断熔断,其实是对调用链路中某个资源出现不稳定状态时(如:调用超时或异常比例升高),对这个资源的调用进行限制,让请求快速失败,避免影响到其它的资源而导致级联错误。 熔断的主要方式是使用断路器阻断对故障服务器的调用。 断路器有三种状态,关闭、打开、半打开。 状态机: 1、关闭(Closed)状态:在这个状态下,请求都会被转发给后端服务。同时会记录请求失败的次数,当请求失败次数在一段时间超过一定次数就会进入打开状态。 2、打开(Open)状态:在这个状态下,熔断器会直接拒绝请求,返回错误,而不去调用后端服务。同时,会有一个定时器,时间到的时候会变成半打开状态。目的是假设服务会在一段时间内恢复正常。 3、半打开(Half Open)状态:在这个状态下,熔断器会尝试把部分请求转发给后端服务,目的是为了探测后端服务是否恢复。如果请求失败会进入打开状态,成功情况下会进入关闭状态,同时重置计数。 目前,市面流行的解决方案是阿里的开源框架 十一、降级降级是系统保护的一种重要手段。 正如 “好钢用在刀刃上”,为了使 比如电商大促,业务在峰值时刻,系统抵挡不住全部的流量时,系统的负载、CPU 的使用率都超过了预警水位,可以对一些非核心的功能进行降级,降低系统压力,比如把 当然,不同业务、不同公司,处理方式也各不相同,需要结合实际场景,和业务方一块讨论,最后达成一个统一认可的降级方案。 总结下来:降级是通过暂时关闭某些非核心服务或者组件从而保护核心系统的可用性。 - END - |
|
来自: 昵称10087950 > 《JAVA》