请求限流
请求限流是在面对未知流量的情况下,防止系统被冲垮的最后一道有效的防线。可以针对集群、业务系统和具体API维度进行限流。
具体实现可以分为集群版和单机版,区别就是集群版是使用后端统一缓存如Redis存储数据,但有一定的性能损耗;单机版则在本机内存中进行存储(推荐)。
常用的限流算法:计数器、漏桶、令牌桶(推荐)
熔断降级
服务熔断
当下游的服务因为某种原因突然变得不可用或响应过慢,上游服务为了保证自己整体服务的可用性,不再继续调用目标服务,直接返回,快速释放资源。如果目标服务情况好转则恢复调用。
熔断是为了解决服务雪崩,特别是在微服务体系下,通常在框架层面进行处理。内部机制采用的是断路器模式,其内部状态转换图如下:
服务降级
当负荷超出系统整体负载承受能力时,为了保证核心服务的可用,通常可以对非核心服务进行降级,如果返回缓存内容或者直接返回。
服务降级的粒度可以是API维度、功能维度、甚至是系统维度,但是都需要事前进行服务级别的梳理和定义。
真实场景下,通常是在服务器负载超出阈值报警之后,管理员决定是扩容还是降级。
业务隔离
API网关统一了非业务层面的处理,但如果有业务处理的逻辑,不同业务之间就可能会相互影响。要进行业务系统的隔离,通常可以采用线程池隔离和集群隔离,但对于Java而言,线程是比较重的资源,推荐使用集群隔离。
PUSH推送
消息推送系统 针对不同的场景推出多种推送类型,满足用户的个性化推送需求,并集成了苹果、华为、小米、FCM 等厂商渠道的推送功能,在提供控制台快速推送能力的同时,也提供了服务端接入方案,方便用户快速集成移动终端推送功能,与用户保持互动,从而有效地提高用户留存率,提升用户体验。
设备建连、注册、绑定用户流程
消息推送过程
在非常多的业务场景中,当业务发生时用户未必在线,也未必有网络。因此,在 MPS 中所有消息均会被持久化。业务发生时,MPS 会尝试做一次推送(第三方渠道推送或自建的TCP 连接推送)。
自建渠道中,会通过查询缓存来判断用户的终端是否有 TCP 连接,如果存在则推送,客户端收到推送消息后,会给服务端回执,服务端即可更新消息状态。如果推送失败,或者回执丢失,用户在下一次建立连接时,会重新接受消息通知,同时客户端会进行逻辑去重。
微服务体系
TODO另写一篇文章介绍,期待!