ldaysjun的博客

​ 服务不论如何优化，总会有达到瓶颈的时候，在资源不足，请求量过大的情况下，服务本省可以使用一些策略，提升服务的吞吐量触，发降级处理就是策略之一。​ 所谓的降级服务其实就是牺牲掉一些逻辑处理，或者停止部分依赖服务的请求。以保障服务可以提供关键能力。这么来看，服务降级很难做到不侵入业务，这种降级逻辑都是预埋在服务内的。服务降级本质为了解决在有限资源条件下，为了更大程度处理请求。将强一致性改为最终一致性是很有效的方案，写可以使用异步化处理，读可以使用缓存。

​ 单体服务被拆分为多个服务，调用关系错综复杂，突发大流量很可能把当前一些服务压垮，造成资源的耗尽。甚至直接导致雪崩效应。​ 服务限流可以把这种突发流量超出处理范围的部分丢弃掉，或者阻塞他们在队列里。避免雪崩。这个时候通过监控机制，我们可以完成扩容等方案，进而处理流量的暴增。限流的设计其实也是为了提升服务的容错性，保证在突发流量的情况下，服务不会过载。为了节省资源，部署服务的时候，同样不可能把一个不常见的峰值作为扩容的标准。限流的设计需要注意以下几点。限流需要设置开关，关闭开关，关闭限流。

​ 最经典的比喻就是轮船的设计，隔离设计的英文叫”Bulkheads”，被翻译为隔板，我们的轮船的船舱就是通过隔板隔离出来的空间。其中一个船舱进水了，并不会影响其他船舱，也不会造成沉船，是一种很安全的设计。在我们微服务的设计当中，难免一些服务”进水(故障)”，隔离设计保证其中一个服务出现问题，其他服务可以保证正常提供服务。​ 隔离设计选择根据用户维度进行隔离还是根据业务级别隔离，需要根据业务来恒定。甚至两种都结合使用。隔离粒度根据业务来权衡。

​ 在流量突增的情况下，为了保证服务的可用性，能做些什么呢？例如活动运营平台，平时流量不是很多，3台机器就可以解决。但是突然上线了一个奖励非常大的奖品，3台服务均到达高负载的状态，直接造成雪崩效应，应对这种突发流量，为了保证服务的可用性，引入一个新的概念，服务限流。​ 开源的限流组件有很多，重要的是了解他们的实现原理，以及各个算法的应用场景，例如：计数器就适合在集群的场景下使用，配合滑动窗口，令牌通和漏斗提供了比较精准的限流策略，漏斗是让服务以恒定速率处理请求，但是令牌通算法是允许一定程度的流量突发。

​ 集群服务中的节点ip不会永远不变，如果变化了怎么办？1台机器处理不过来，扩容了3台，如何让新增的3台快速投入使用，流量如何很快的流入新增的机器。集群中出现有问题的机器，如何下线呢？解决这些问题需要引入一个新的概念，服务发现服务IP与端口的确定方式。服务注册与发现。服务下线服务健康监测。节点加入或退出，如何通知订阅者变化。查看应用的订阅列表，发布列表，以及订阅节点。当A节点访问B集群的机器，这次访问究竟应该访问哪个节点？基于什么策略如何确定的？这又涉及到另一个概念，负载均衡。

​ 通篇主要是讲解gRPC的请求过程，具体的比如服务的创建，连接。编解码，http2的创建，这些细节都没有详细描述，后面有机会在具体探讨。这次主要是了解大体流程。

​ 本篇主要是构建一个服务，约定一些规则，其中也涉及到gRPC的安装，protoc工具的生成，这些随便一搜有很多的资料可供参考。下一篇分析gRPC的详细调用过程。

以gRPC为示例，分析什么是RPC框架，已经RPC框架原理弹性设计相关：服务限流、服务重试、服务熔断、服务隔离、服务降级，服务状态服务注册，服务发现、健康检查