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