smart_an的专栏

作者简介：大家好，我是哥，前中兴通讯、美团架构师，现某互联网公司联系qq：184480602，加我进群，大家一起学习，一起进步，一起对抗互联网寒冬学习必须往深处挖，挖的越深，基础越扎实！

互联网行业内在进行微服务高可用建设的时候，不可避免的要考虑一个事情，如何部署才能提高系统的可用性和稳定性。所以一般情况下，不会只部署一个机房，这样无法完全避免一个机房内网络故障、机房断电，遭受区域网络攻击的风险。所以有了多机房建设的，但是多机房建设同样也有问题，他们无法近距离的部署，如果部署区域太近（如在同一个城市），依然无法避免区域断电、洪灾、水灾、火灾、地震等灾难情况的发生。所以业内的大型互联网企业，会耗费大量的人力物理在基础设施建设方面。

大家都知道，一个主机（或称为节点）可以部署多个Pod，Pod作为Kubernetes中的最小部署单元。是一组一个或多个紧密关联的容器的集合，它们共享相同的网络命名空间和存储卷。affinity 可以实现就近部署，增强网络能力实现通信上的就近路由，减少网络的损耗。如同一个BCC聚类多个实例Pod。anti-affinity 反亲和性主要是出于高可靠性考虑，尽量分散实例Pod，某个节点故障的时候，对应用的影响只是 N 分之一或者单实例。

在互联网电商场景中，我们经常会遇到有计划的流量洪峰，比如 双11、618购物节，积分竞拍和定时抢购的疯狂场景。这种是在预期内的，知道会发生并有一定的准备。而那些预期之外的突发流量异常，才是真正给我们带来挑战的部分，比如：硬件故障：如服务器宕机，机房断电，光纤被挖断等。缓存击穿：一般发生在应用重启导致的缓存失效，以及短时间内大量缓存过期失效时。大量的无法命中，使请求直击后端服务，造成服务提供者超负荷运行，引起服务不可用。程序BUG：如程序逻辑导致内存泄漏；JVM长时间FullGC等。

在复杂的互联网场景中，不可避免的会因为一些内在或者外在的因素，导致出现请求超时的情况。而典型的业务超时场景主要有如下：网络延迟或者抖动或者丢包，从而导致响应时间变长。容器甚至云主机资源瓶颈情况：如CPU使用率过高、内存使用是否正常、磁盘IO压力情况、网络时延情况等资源使用情况异常，也可能导致响应时间变长。负载均衡性问题：多实例下分配的流量不均衡，目前看云基础场景，这个情况不多见。

云基础场景下的治理手段各种各样，这边讲解了初级版的异常重试，让用户有一个更优良的使用环境。后续的章节我们逐一了解下超时保护、故障注入、熔断限流、异常驱逐等高级用法。

丰富的流量管理策略为我们系统的稳定性，以及流量的多样化（金丝雀发布、ABTesting、分级扩散流量、流量染色）使用提供了保证。

丰富的流量管理策略为我们系统的稳定性，以及流量的多样化（金丝雀发布、ABTesting、分级扩散流量、流量染色）使用提供了保证。

在微服务系列中，我们讲过很多限流，熔断相关的知识。老生长谈的一个话题，服务的能力终归是有限的，无论是内存、CPU、线程数都是，如果遇到突如其来的峰量请求，我们怎么友好的使用限流来进行落地，避免整个服务集群的雪崩。无论是应用层级还是存储层级，无非是跟前端约定一个规则，返回默认参数或者默认回到方法，让前端以用户友好体验的方式进行降级，保证服务端不至于崩溃。

前面的章节，我们学习了微服务中对熔断降级的原理，参考这篇《服务治理：熔断、降级、限流了解了固定窗口算法、滑动窗口算法、 漏桶原理和令牌桶原理，本文对Hystrix做进一步的分析。Hystrix是Netflix开源的一款具备熔断、限流、降级能力的容错系统，设计目的是将应用中的系统访问、多链路服务调用、第三方依赖服务的调用，通过流量资源控制的方式隔离开。避免了在分布式系中的某个服务故障沿着调用链向上传递，出现整体的服务雪崩，并以此提升系统的稳定性和健壮性。

Sentinel 被称为高可用流量管理框架，分布式系统流量卫兵。假如对一个接口QPS（每秒请求数）最大限制为10000，在QPS超过10000之后的请求我们就要限制其访问，并给出友好的提示。不限制QPS无限的次数就会造成服务器超量访问而宕机。在服务调用的过程中，如果调用链路中的某个资源出现了不稳定，比如错误数增加，请求平响升高，则大概率会导致请求堆积，进而诱发整个链路的雪崩，解决办法就是熔断、限流、降级。

作者简介：大家好，我是哥，前中兴通讯、美团架构师，现某互联网公司联系qq：184480602，加我进群，大家一起学习，一起进步，一起对抗互联网寒冬学习必须往深处挖，挖的越深，基础越扎实！

Apache Dubbo 是一款分布式微服务开发框架，它提供了 RPC通信 与 微服务治理 两大关键能力。这意味着，使用 Dubbo 开发的微服务，将具备相互之间的远程发现与通信能力， 同时利用 Dubbo 提供的丰富服务治理能力，可以实现诸如服务发现、负载均衡、流量调度等服务治理诉求。同时 Dubbo 是高度可扩展的，用户几乎可以在任意功能点去定制自己的实现，以改变框架的默认行为来满足自己的业务需求。

RPC：Remote Procedure Call Protocol，指的是远程过程调用协议，一般使用在分布式业务或者微服务架构风格中。即一个节点通过网络调用的方式来请求另一个节点提供的服务的过程，也可以简单的理解为client访问server上提供的函数（像调用本地函数一样，去调用一个远端服务）。通过本篇我们详细学习了RPC的概念和原理，以及它能够提供的能力。也对目前业内主流的RPC的框架有了一定的了解。后面一篇我们以Dobbo为例子，来学习下怎么使用RPC框架来进行服务之间的通信。

回顾下前面几篇关于微服务的介绍，我们可以了解到从当单体系统到微服务，再到服务网格的演进过程。那单体系统和微服务相比，有哪些区别呢，下面是对功能性的对比?单体系统微服务系统单体系统微服务系统程序、数据、配置集中管理按照功能拆分、微服务化、松耦合开发效率低下分模块快速迭代发布全量，启动慢平滑发布，快速启动可靠性差熔断、限流、降级，超时重试，异常离群服务内直接调用轻量级通信技术单一跨语言。

除了 Eureka、Consul，还有其他的的注册中心技术，如Zookeeper、Nocas等。解耦服务之间相互依赖的细节我们知道服务之间的远程调用必须要知道对方的IP、端口信息。我们可以在调用方直接配置被调用方的IP、端口，这种调用方直接依赖IP、端口的方式存在明显的问题，如被调用的IP、端口变化后，调用方法也要同步修改。通过服务发现，将服务之间IP与端口的依赖转化为服务名的依赖，服务名可以根据具微服务业务来做标识，因此，屏蔽、解耦服务之间的依赖细节是服务发现与注册解决的第一个问题。

Eureka是Netflix OSS套件中关于服务注册和发现的解决方案。因为Spring Cloud 在它的微服务解决方案中对Eureka进行了集成，并作为优先推荐方案进行宣传，所以早期有用 Spring Cloud 来建设微服务系统的同学会比较熟悉。目前大量公司的微服务系统中依旧使用Eureka作为注册中心，它的核心设计思想也被后续大量注册中心产品借鉴。但目前Eureka 2.0已经停止维护，所以新的微服务架构设计中，不再建议使用。

先少后多（微服务数量）、先粗后细(粒度)基于业务逻辑进行拆分（用户群体、业务领域等模型）基于可靠性（核心模块独立化、主次链路隔离）基于性能拆分（独立拆分高性能场景）接口需保证幂等接口数据定义严禁内嵌，透传规范化工程结构，符合微服务风格不止对计算服务记性拆分，服务层 -> 缓存层 -> 数据层 的逐步拆解，才能发挥最大功效。

微服务架构提倡的单一应用程序划分成一组松散耦合的细粒度小型服务，辅助轻量级的协议，互相协调、互相配合，实现高效的应用价值，符合我们应用服务开发的发展趋势。后续我们围绕它的核心模块：服务注册与发现、API 网关服务、分布式配置中心、服务通信、服务治理、分布式服务追踪与监控等，从原理到实践，一步步展开来研究。

在很多项目的业务初期阶段，高速迭代上线是首要考虑的事情，对后期的容量预估、可扩展性和系统健壮性、高可用一般没有那么重视。但随着业务的发展，用户量、请求量的暴增，发现原来的单体系统已经远远不满足需求了，特别是随着互联网整体的高速发展，对系统的要求越来越高。但是物理服务器的CPU、内存、存储器、连接数等资源有限，单体系统能够承受的的QPS也是有限的，某个时段大量连接同时执行操作，会导致web服务和数据库服务在处理上遇到性能瓶颈。