当前，数字化在给企业带来业务创新，推动企业高速发展的同时，也给企业的IT软件系统带来了严峻的挑战。面对流量高峰，不同的企业是如何通过技术手段解决高并发难题的呢?0、引言软件系统有三个追求：高性能、高并发、高可用，俗称三高。三者既有区别也有联系，门门道道很多，全面讨论需要三天三夜，本篇讨论高并发。高并发（High Concurrency）。并发是操作系统领域的一个概念，指的是一段时间内多任务流交替执行的现象，后来这个概念被泛化，高并发用来指大流量、高请求的业务情景，比如春运抢票，电商双十一，秒杀大促等场景。很多程序员每天忙着搬砖，平时接触不到高并发，哪天受不了跑去面试，还常常会被面试官犀利的高并发问题直接KO，其实吧，高并发系统也不高深，我保证任何一个智商在线的看过这篇文章后，都能战胜恐惧，重拾生活的信心。本文先介绍高并发系统的度量指标，然后讲述高并发系统的设计思路，再梳理高并发的关键技术，最后结合作者的经验做一些延伸探讨。1、高并发的度量指标既然是高并发系统，那并发一定要高，不然就名不副实。并发的指标一般有QPS、TPS、IOPS，这几个指标都是可归为系统吞吐率，QPS越高系统能hold住的请求数越多，但光关注这几个指标不够，我们还需要关注RT，即响应时间，也就是从发出request到收到response的时延，这个指标跟吞吐往往是此消彼长的，我们追求的是一定时延下的高吞吐。比如有100万次请求，99万次请求都在10毫秒内响应，其他次数10秒才响应，平均时延不高，但时延高的用户受不了，所以，就有了TP90/TP99指标，这个指标不是求平均，而是把时延从小到大排序，取排名90%/99%的时延，这个指标越大，对慢请求越敏感。除此之外，有时候，我们也会关注可用性指标，这可归到稳定性。一般而言，用户感知友好的高并发系统，时延应该控制在250毫秒以内。什么样的系统才能称为高并发？这个不好回答，因为它取决于系统或者业务的类型。不过我可以告诉你一些众所周知的指标，这样能帮助你下次在跟人扯淡的时候稍微靠点儿谱，不至于贻笑大方。通常，数据库单机每秒也就能抗住几千这个量级，而做逻辑处理的服务单台每秒抗几万、甚至几十万都有可能，而消息队列等中间件单机每秒处理个几万没问题，所以我们经常听到每秒处理数百万、数千万的消息中间件集群，而像阿某的API网关，每日百亿请求也有可能。2、高并发的设计思路高并发的设计思路有两个方向：垂直方向扩展，也叫竖向扩展水平方向扩展，也叫横向扩展垂直方向：提升单机能力提升单机处理能力又可分为硬件和软件两个方面：硬件方向，很好理解，花钱升级机器，更多核更高主频更大存储空间更多带宽软件方向，包括用各快的数据结构，改进架构，应用多线程、协程，以及上性能优化各种手段，但这玩意儿天花板低，就像提升个人产出一样，996、007、最多24 X 7。水平方向：分布式集群为了解决分布式系统的复杂性问题，一般会用到架构分层和服务拆分，通过分层做隔离，通过微服务解耦。这个理论上没有上限，只要做好层次和服务划分，加机器扩容就能满足需求，但实际上并非如此，一方面分布式会增加系统复杂性，另一方面集群规模上去之后，也会引入一堆AIOps、服务发现、服务治理的新问题。因为垂直向的限制，所以，我们通常更关注水平扩展，高并发系统的实施也主要围绕水平方向展开。3、高并发的关键技术玩具式的网络服务程序，用户可以直连服务器，甚至不需要数据库，直接写磁盘文件。但春运购票系统显然不能这么做，它肯定扛不住这个压力，那一般的高并发系统是怎么做呢？比如某宝这样的正经系统是怎么处理高并发的呢？其实大的思路都差不多，层次划分 + 功能划分。可以把层次划分理解为水平方向的划分，而功能划分理解为垂直方向的划分。首先，用户不能直连服务器，要做分布式就要解决“分”的问题，有多个服务实例就需要做负载均衡，有不同服务类型就需要服务发现。集群化：负载均衡负载均衡就是把负载（request）均衡分配到不同的服务实例，利用集群的能力去对抗高并发，负载均衡是服务集群化的实施要素，它分3种：DNS负载均衡，客户端通过URL发起网络服务请求的时候，会去DNS服务器做域名解释，DNS会按一定的策略（比如就近策略）把URL转换成IP地址，同一个URL会被解释成不同的IP地址，这便是DNS负载均衡，它是一种粗粒度的负载均衡，它只用URL前半部分，因为DNS负载均衡一般采用就近原则，所以通常能降低时延，但DNS有cache，所以也会更新不及时的问题。硬件负载均衡，通过布置特殊的负载均衡设备到机房做负载均衡，比如F5，这种设备贵，性能高，可以支撑每秒百万并发，还能做一些安全防护，比如防火墙。软件负载均衡，根据工作在ISO 7层网络模型的层次，可分为四层负载均衡（比如章文嵩博士的LVS）和七层负载均衡（NGINX），软件负载均衡配置灵活，扩展性强，阿某云的SLB作为服务对外售卖，Nginx可以对URL的后半部做解释承担API网关的职责。所以，完整的负载均衡链路是 client <-> DNS负载均衡 -> F5 -> LVS/SLB -> NGINX 不管选择哪种LB策略，或者组合LB策略，逻辑上，我们都可以视为负载均衡层，通过添加负载均衡层，我们将负载均匀分散到了后面的服务集群，具备基础的高并发能力，但这只是万里长征第一步。数据库层面：分库分表+读写分离前面通过负载均衡解决了无状态服务的水平扩展问题，但我们的系统不全是无状态的，后面通常还有有状态的数据库，所以解决了前面的问题，存储有可能成为系统的瓶颈，我们需要对有状态存储做分片路由。数据库的单机QPS一般不高，也就几千，显然满足不了高并发的要求。所以，我们需要做分库分表 + 读写分离。就是把一个库分成多个库，部署在多个数据库服务上，主库承载写请求，从库承载读请求。从库可以挂载多个，因为很多场景写的请求远少于读的请求，这样就把对单个库的压力降下来了。如果写的请求上升就继续分库分表，如果读的请求上升就挂更多的从库，但数据库天生不是很适合高并发，而且数据库对机器配置的要求一般很高，导致单位服务成本高，所以，这样加机器抗压力成本太高，还得另外想招。读多写少：缓存缓存的理论依据是局部性原理。一般系统的写入请求远少于读请求，针对写少读多的场景，很适合引入缓存集群。在写数据库的时候同时写一份数据到缓存集群里，然后用缓存集群来承载大部分的读请求，因为缓存集群很容易做到高性能，所以，这样的话，通过缓存集群，就可以用更少的机器资源承载更高的并发。缓存的命中率一般能做到很高，而且速度很快，处理能力也强（单机很容易做到几万并发），是理想的解决方案。CDN本质上就是缓存，被用户大量访问的静态资源缓存在CDN中是目前的通用做法。缓存也有很多需要谨慎处理的问题：一致性问题：(a)更新db成功+更新cache失败 -> 不一致 (b)更新db失败+更新cache成功 -> 不一致 ©更新db成功+淘汰缓存失败 -> 不一致缓存穿透：查询一定不存在的数据，会穿透缓存直接压到数据库，从而导致缓存失去作用，如果有人利用这个漏洞，大量查询一定不存在的数据，会对数据库造成压力，甚至打挂数据库。解决方案：布隆过滤器 或者 简单的方案，查询不存在的key，也把空结果写入缓存（设置较短的过期淘汰时间），从而降低命失缓存雪崩：如果大量缓存在一个时刻同时失效，则请求会转到DB，则对DB形成压迫，导致雪崩。简单的解决方案是为缓存失效时间添加随机值，降低同一时间点失效淘汰缓存数，避免集体失效事件发生但缓存是针对读，如果写的压力很大，怎么办？高写入：消息中间件同理，通过跟主库加机器，耗费的机器资源是很大的，这个就是数据库系统的特点所决定的。相同的资源下，数据库系统太重太复杂，所以并发承载能力就在几千/s的量级，所以此时你需要引入别的一些技术。比如说消息中间件技术，也就是MQ集群，它是非常好的做写请求异步化处理，实现削峰填谷的效果。消息队列能做解耦，在只需要最终一致性的场景下，很适合用来配合做流控。假如说，每秒是1万次写请求，其中比如5千次请求是必须请求过来立马写入数据库中的，但是另外5千次写请求是可以允许异步化等待个几十秒，甚至几分钟后才落入数据库内的。那么此时完全可以引入消息中间件集群，把允许异步化的每秒5千次请求写入MQ，然后基于MQ做一个削峰填谷。比如就以平稳的1000/s的速度消费出来然后落入数据库中即可，此时就会大幅度降低数据库的写入压力。业界有很多著名的消息中间件，比如ZeroMQ，rabbitMQ，kafka等。消息队列本身也跟缓存系统一样，可以用很少的资源支撑很高的并发请求，用它来支撑部分允许异步化的高并发写入是很合适的，比使用数据库直接支撑那部分高并发请求要减少很多的机器使用量。 避免挤兑：流控再强大的系统，也怕流量短事件内集中爆发，就像银行怕挤兑一样，所以，高并发另一个必不可少的模块就是流控。流控的关键是流控算法，有4种常见的流控算法。计数器算法（固定窗口）：计数器算法是使用计数器在周期内累加访问次数，当达到设定的限流值时，触发限流策略，下一个周期开始时，进行清零，重新计数，实现简单。计数器算法方式限流对于周期比较长的限流，存在很大的弊端，有严重的临界问题。滑动窗口算法：将时间周期分为N个小周期，分别记录每个小周期内访问次数，并且根据时间滑动删除过期的小周期，当滑动窗口的格子划分的越多，那么滑动窗口的滚动就越平滑，限流的统计就会越精确。此算法可以很好的解决固定窗口算法的临界问题。漏桶算法：访问请求到达时直接放入漏桶，如当前容量已达到上限（限流值），则进行丢弃（触发限流策略）。漏桶以固定的速率进行释放访问请求（即请求通过），直到漏桶为空。分布式环境下实施难度高。令牌桶算法：程序以r（r=时间周期/限流值）的速度向令牌桶中增加令牌，直到令牌桶满，请求到达时向令牌桶请求令牌，如获取到令牌则通过请求，否则触发限流策略。分布式环境下实施难度高。4、高并发的实践经验接入-逻辑-存储是经典的互联网后端分层，但随着业务规模的提高，逻辑层的复杂度也上升了，所以，针对逻辑层的架构设计也出现很多新的技术和思路，常见的做法包括系统拆分，微服务。除此之外，也有很多业界的优秀实践，包括某信服务器通过协程（无侵入，已开源libco）改造，极大的提高了系统的并发度和稳定性，另外，缓存预热，预计算，批量读写（减少IO），池技术等也广泛应用在实践中，有效的提升了系统并发能力。为了提升并发能力，逻辑后端对请求的处理，一般会用到生产者-消费者多线程模型，即I/O线程负责网络IO，协议编解码，网络字节流被解码后产生的协议对象，会被包装成task投入到task queue，然后worker线程会从该队列取出task执行，有些系统会用多进程而非多线程，通过共享存储，维护2个方向的shm queue，一个input q，一个output q，为了提高并发度，有时候会引入协程，协程是用户线程态的多执行流，它的切换成本更低，通常有更好的调度效率。另外，构建漏斗型业务或者系统，从客户端请求到接入层，到逻辑层，到DB层，层层递减，过滤掉请求，Fail Fast（尽早发现尽早过滤），嘴大**小，哈哈。漏斗型系统不仅仅是一个技术模型，它也可以是一个产品思维，配合产品的用户分流，逻辑分离，可以构建全方位的立体模型。5、小结莫让浮云遮望眼，除去繁华识真颜。我们不能掌握了大方案，吹完了牛皮，而忽视了编程最本质的东西，掌握最基本最核心的编程能力，比如数据架构和算法，设计，惯用法，培养技术的审美，也是很重要的，既要致高远，又要尽精微。

 k8s已经成为当今容器化的标准，人们在享受容器带来的高效与便利的同时，也遇到一些烦恼：客户端和容器服务器之间可能存在多种不同形式的代理服务器，那容器中如何获取到客户端真实的源ip呢？下面我们就几种场景类型如何能获取到源ip进行讨论。 原理介绍：四层转发：Nodeport：nodeport访问方式，是将容器端口映射到节点端口，如果“服务亲和”选择“集群级别”需要经过一次服务转发，无法实现获取客户端源ip，而“节点模式”不经过转发，可以获取客户端源ip。 ELB：ELB访问方式，是通过华为云ELB产品来实现负载均衡，“服务亲和”也是需要选择“节点级别”，其中“共享型”ELB需要在节点安装TOA插件，而“独享型”ELB默认透传源ip，不需要安装TOA插件。 七层转发：Ingress：应用在七层访问时，客户端源ip默认保存在HTTP头部的“X-Forwarded-For”字段，无需做其他操作。 具体操作：一、负载均衡 ( LoadBalancer )负载均衡( LoadBalancer )的Service模式下，支持容器中获取源IP需要满足以下前提条件：1. 服务亲和选择“节点级别”而不是“集群级别”。2. 在pod所在的节点安装TOA插件。（“独享型”ELB无需进行以下操作）安装TOA插件步骤如下：1) 准备编译环境：执行如下命令，安装gcc编译器。]# yum install gcc执行如下命令，安装make工具。]# yum install make2)编译内核模块a) 下载TOA内核模块源代码。]# wget https://github.com/Huawei/TCP_option_address/archive/master.zip b)     执行如下命令，进入源码目录，编译模块。]# unzip master.zip]# cd TCP_option_address-master/src/]# make编译过程未提示warning或者error，说明编译成功，检查当前目录下是否已经生成toa.ko文件。说明：如果报错提示“config_retpoline=y but not supported by the compiler， Compiler update recommended”，表明gcc版本过老，建议将gcc升级为较新版本。3)加载内核模块执行如下命令，加载内核模块。]# insmod toa.ko执行如下命令，验证模块加载情况，查看内核输出信息。]# dmesg | grep TOA若提示信息包含“TOA: toa loaded”，说明内核模块加载成功。4)     自动加载内核模块为了使TOA内核模块在系统启动时生效，可以将加载TOA内核模块的命令加到客户的启动脚本中。在“/etc/sysconfig/modules/”目录下新建toa.modules文件。该文件包含了TOA内核模块的加载脚本，请参考如下示例：#!/bin/sh/sbin/modinfo -F filename /root/toa/toa.ko > /dev/null 2>&1if [ $? -eq 0 ]; then/sbin/insmod /root/TCP_option_address-master/src/toa.kofi注意：其中“/root/TCP_option_address-master/src/toa.ko”为TOA内核模块文件的路径，客户需要将其替换为自己编译的TOA内核模块路径。执行以下命令，为toa.modules启动脚本添加可执行权限。]# chmod +x /etc/sysconfig/modules/toa.modules这种情况下可以从四层负载均衡上获取到客户端的源IP（可以通过netstat查看）。测试要点：这种情况下可以使用netstat看到客户端连接到POD的IP地址。 二、节点访问 ( NodePort )节点访问（NodePort）类型的Service的服务亲和选择“节点级别”而不是“集群级别”，即Service的 spec.externalTrafficPolicy 需要设置为 Local。图1 服务亲和选择节点级别三、七层负载均衡（Ingress）七层负载均衡的模式下，不能在四层负载均衡上获取客户端IP（不能通过netstat查看客户端IP），需要对应用服务器进行配置，然后通过七层负载均衡的http头中的x-forward-for获取。真实的来访者IP会被负载均衡放在HTTP头部的X-Forwarded-For字段，格式如下：X-Forwarded-For: 来访者真实IP, 代理服务器1-IP,  代理服务器2-IP, ...测试要点：从容器中获取http请求头”x-forward-for”，获取的IP为客户端的IP。

如今，随着互联网规模和消费者规模的不断扩大，企业面对着高并发请求场景下的流量冲击，尤其是每逢618或双11，会有数以亿计的用户同时访问互联网进行购物，网站访问用户的激增，会导致单服务器超负荷运行，导致网站访问卡顿或失败，严重影响用户体验，会给企业带来巨大损失。华为云负载均衡服务可以轻松帮助企业解决这个难题。弹性负载均衡（Elastic Load Balance，简称ELB）是将访问流量根据转发策略分发到后端多台服务器的流量分发控制服务。弹性负载均衡可以通过流量分发扩展应用系统对外的服务能力，同时通过消除单点故障提升应用系统的可用性。ELB支持包含TCP协议和UDP协议的四层负载均衡，也支持包含HTTP协议和HTTPS协议的七层负载均衡，其中针对HTTPS协议提供多种加密协议和加密套件，满足灵活安全的业务诉求。弹性负载均衡优势：1、 性能强悍集群支持最高1亿并发连接，满足用户的海量业务访问需求。2、  高可用通过健康检查来自动剔除后端异常主机，消除单点故障; ELB采用集群化部署，支持多可用区的同城双活容灾，无缝实时切换。3、  灵活扩展根据应用流量自动完成分发，与弹性伸缩服务无缝集成，灵活扩展用户应用的对外服务能力。4、  简单易用快速部署，实时生效，支持多种协议、多种调度算法。一、满足多种场景下的高并发、高可用要求典型应用场景场景描述应用举例高访问量业务对于业务量访问较大的业务，可以通过ELB设置相应的转发规则，将访问量均匀的分到多个后端云服务器处理；同时开启会话保持功能，保证同一个客户请求转发到同一个后端云服务器，从而提升访问效率大型门户网站，移动应用市场等横向扩张系统对于存在潮汐效应的业务，可以随时在ELB上添加和移除后端云服务器，同时可以和弹性伸缩服务结合，更好的提升业务的灵活扩展能力电商，手游，直播网站等消除单点故障对于可靠性有较高要求的业务，可以在负载均衡器上添加多个后端云服务器实例。负载均衡器会通过健康检查及时发现并屏蔽故障实例，并将流量转发到其他正常运行的后端云服务器，确保业务不中断。官网，收费业务，常用的Web业务等多可用区容灾对于可靠性和容灾有很高要求的业务，负载均衡器支持跨可用区的流量转发和容灾，即使出现某个可用区网络故障，负载均衡器仍可将流量转发到其他可用区的后端云服务器进行处理。银行业务，警务业务，大型应用系统等 二、提供完善的功能，满足不同业务差异化需求1、弹性伸缩通过将ELB的后端服务器加入到弹性伸缩组，ELB可以根据流量负载快速伸缩后端服务器数量，实现业务的弹性伸缩，基于业务的压力大小来对资源进行按需使用。2、流量调度ELB实例通过监听器检查连接请求，然后根据调度算法定义的转发策略将请求流量分发至后端服务器。ELB支持三种调度算法：轮询算法、最少连接和源IP算法。l  轮训算法：根据后端服务器的权重，按顺序依次将请求分发给不同的服务器。l  最小链接算法：通过当前活跃的连接数来估计服务器负载情况的一种动态调度算法。加权最少连接就是在最少连接数的基础上，根据服务器的不同处理能力，给每个服务器分配不同的权重，使其能够接受相应权值数的服务请求。l  源IP算法：将请求的源IP地址进行Hash运算，得到一个具体的数值，同时对后端服务器进行编号，按照运算结果将请求分发到对应编号的服务器上。3、健康检查ELB通过定期向后端ECS服务器发送请求或尝试连接来测试后端服务器运行的情况。当后端某台ECS健康检查出现异常时，ELB会自动将新的请求分发到其他健康检查正常的ECS上；而当该ECS恢复正常运行时，ELB将恢复把新的请求转发给它。4、会话保持会话保持用于保持会话的连续性和一致性，由于不同服务器之间很难做到实时同步用户访问信息，这就要求把用户的前后访问会话保持到一台后端服务器上来处理。ELB提供丰富的会话保持策略，四层协议监听器支持基于源IP的会话保持，七层协议监听器支持HTTP cookie和应用程序cookie的会话保持。5、HTTP/HTTPS高级配置1）  转发策略：支持在监听其中配置，将特定URL的请求转发到特定的后端主机组处理，适用于无法做到多机状态同步的业务场景。2）  HTTPS双向认证：适用于关键业务（如银行支付），需要对通信双方的身份都做认证的场景，来确保业务安全性。3）  HTTP重定向至HTTPS：实现强制以HTTPS访问网页，提升安全性。4）  配置SNI：适用于HTTPS场景下，用户应用提供多个域名供外部访问，并且每个域名都用独立证书，解决一个应用只能使用一个证书的缺点。6、访问控制ELB支持监听器级别的访问控制，业务可以根据自身需要，配置白名单或黑名单，灵活控制业务可以被访问的范围。三、提供完善的监控和日志能力ELB提供了完善的监控和七层访问日志能力，可以让企业实时且全方位的掌控自己业务的运行状态。1、ELB监控ELB提供完善的监控数据，包括并发连接数、活跃连接数、非活跃连接数、新建连接数、后端异常主机数、流入流出包速率、流入流出带宽等。针对七层监听器，ELB还提供了七层请求的相关监控数据，比如监听器前后端返回码（3××、4××、5××、2××、499等）曲线、监听器前后端响应时间曲线等，能更协助企业对ELB前后端业务的健康状态进行深入监控。2、ELB七层访问日志针对七层监听器，ELB提供了访问日志功能，企业可以根据自身需要选择开启。通过访问日志，企业可以查看到每条经过ELB的七层业务请求记录，可进行更细粒度的业务监控和分析。日志中记录了客户端IP与端口、请求体大小、前端返回码、后端业务返回码、前端响应时间、后端响应时间等信息。

我公司购买了弹性负载均衡和NAT网关，请问用户访问的时候是从NAT网关进入还是从负载均衡进入？

场景介绍：使用竞享实例配合负载均衡和弹性伸缩服务实现以较低成本在业务高峰智能调节后端集群，保持Web最佳性能典型客户群体：社交学习平台、在线交易平台、电商、O2O等场景特点：批量操作：需支持批量创建及删除操作按需付费：根据运行时间按需精准计费规格要求：超分不敏感，可接受规格多集中部署：同Region部署计算集群应用架构图：  使用优势：成本降低：最高可帮助用户节省成本灵活便捷：用户可设置实例持续时间，到期释放规模运行：用户可申请超大规模集群处理转码任务性能保障：与按需ECS相同底层资源，性能一致搭配服务（除EVS）：弹性负载均衡（ELB）：负载均衡，作为Web应用计算集群的调度器，负责分摊流量弹性伸缩（AS）：根据用户业务需求和预设策略，自动调整计算资源

      全栈服务系统中，通过一台后台服务器可调配多台GPU服务器。在添加新的GPU服务器时，需在后台服务器上添加新的GPU服务器信息，而在新的GPU服务器上进行相关配置，使二者构建交互通道。配置新GPU服务器的主要步骤如下：      1.登录Cloud VR后台管理系统网址      2.服务器管理操作      3.GPU服务器文件配置1.登录Cloud VR后台管理系统网址        后台管理系统主要用于后台管理员对系统的用户、服务器、游戏内容、订单等进行整体监控与管理，其网址为：http://ip/vradmin（ip指后台CentOS服务器的IP地址）。        账号登录界面如下：       在上图中输入管理员账号与密码后，点击按钮进行图形验证，验证成功则进入后台管理界面管理。2.服务器管理操作      进入后台管理界面后可看到网页左侧菜单栏如下（左），点击“服务器管理”，出现三个选项（右）。                               点击“云服务器”，出现如下界面：            然后点击“添加服务器”按钮，弹出添加服务器窗口                                                      添加服务器需要编辑部分：服务器区域、服务器名称、服务器ID、服务器IP、服务器备注。a.  服务器区域选择时，可先在“区域列表”中进行添加，添加结果会在上图中的下拉选项中显示。（例如添加的GPU服务器属于上海区域，可先在“区域列表”中添加区域“上海”，然后在服务器区域下拉框中选择“上海”。）b. 服务器名称可自行设置c. 服务器IP为GPU服务器IPd. 服务器ID可自行设置e. 备注可空置       编辑完成后，点击“确认添加”则新GPU服务器添加成功，可 “云服务器”界面查看所有服务器信息，如下图下半部分所示：       3.GPU服务器文件配置       GPU云服务器添加成功后，需对该GPU云服务器上的GameMonitor程序的config.json文件进行相关配置，具体配置如下：“ServerId”修改为后台管理系统中该服务器添加时所设的“服务器ID”“WebApiAddr”修改为“tcp://ip:5556”（ ip指CentOS后台管理服务器的IP地址）       然后重新启动GameMonitor程序，则新的GPU服务器添加成功。

 负载均衡策略 由于Gemini DB for cassandra架构采用的是对等节点架构，集群内所有节点之间都是对等的，客户端通过driver连接集群时如何选择节点来处理客户端的请求呢？这时候就需要用到Load balancing Policy（LBP）了。        Cassandra提供了四种LBP可供选择：Ø  TokenAwarePolicyØ  DCAwareRoundRobinPolicyØ  RoundRobinPolicyØ  LatencyAwarePolicy 具体讲解LBP之前我们先了解一些基础概念 节点距离(host disatance)节点距离分为LOCAL、REMOTE、IGNORED三种，根据字面意思就可以推断，driver只会和节点距离为LOCAL、REMOTE类型的节点建立连接。 查询计划(query plan)Driver每次进行查询的时候，都会生成一个查询计划，查询计划决定了本次查询需要连接的协调节点(coordinate)。查询计划有以下规则： l  每次查询都会生成新的查询计划，这样让请求均匀的分布在集群内的节点上l  只会路由到可以正常处理请求的节点l  优先会路由到节点距离为LOCAL的节点上 有了上面的基础概念后，我们来逐一的讲解下不同的LBP之间的区别 TokenAwarePolicyTokenAwarePolicy 最大的优势在于可以直接定位到token所在节点，也就是说可以直接找到操作数据的节点（即 coodinate节点就是数据所在节点）。使用范例如下： 使用TokenAwarePolicy 有以下节点要求：l  必须开启QueryOptions#setMetadataEnabledl  必须指定ChildPolicy，也就是上图中的anotherPolicy，它需要依赖于另外一个LBPl  必须指定Keyspace和RoutingKey 为什么有这几条要求呢，我们一条一条分析下： 需要开启元数据的原因是driver需要请求集群的peers信息和一致性哈希环的信息，只有知道了哈希环的信息我们才能在driver端直接将数据路由到数据节点，换个说法叫就是driver其实充当了协调节点的角色。需要指定ChildPolicy的原因是需要依赖其他policy的查询计划和节点距离的计算方式。有了上面两条，最后一条就好理解了，我们需要知道我们路由的partition key的字段才能进行路由。下图的操作是一个完整的使用TokenAwarePolicy的例子： TokenAwarePolicy是Driver默认指定的LBP策略，现在我们可以考虑一个问题，如果不指定Routingkey会怎么样呢？如果不指定Routingkey，那么TokenAwarePolicy就不会生效，会直接退化为ChildPolicy。 DCAwareRoundRobinPolicy这种LBP最适用的场景就是集群部署在多数据中心，通过使用这种LBP数据的查询/写入操作会随机落在不通的数据中心内，先看下示例代码：    上面有两个参数比较重要withLocalDC 指定了 LocalDC的名字，这样我们的查询计划就会优先从LocalDC中选择节点withUsedHostsPerRemoteDc 表示从RemoteDC中选择节点数量假设我们本地数据中心有3个节点，远程数据中心有2个节点，那么三次查询计划生成的结果可能如下：可以看到每次查询本地数据中心的host都在前面（本地数据中心host的顺序都是随机的），另外两个远程数据中兴的host都在后面，这样每次请求就可以相对均匀的落在三个数据中心内了。 RoundRobinPolicyRoundRobinPolicy 适用于你只有单数据中心的情况，它每次随机生成本地数据中心的host列表，使用如下：   生成的查询计划如下图： LatencyAwarePolicy这种LBP也需要叠加在另外一种LBP之上，在此基础上，该LBP增加了延迟感知：它会收集每个主机的查询延迟，并从查询计划中排除掉性能最差的主机使用如下： 本文所有示例代码均引用datastax wiki ，引用地址：https://docs.datastax.com/en/developer/java-driver/3.0/manual/retries/

#化鲲为鹏，我有话说#华为云的负载均衡是怎么用的呢？在华为云创建ELB后，只需要配置好监听器和后端服务器组就行了。监听器：前端协议+端口 eg. https (TCP/443)后端服务器组：就是我们应用所在的服务器，知道服务器地址+端口号就行了

两种隔离机制对应的配置如下：负载均衡均衡：    降级隔离：能否从触发条件和恢复机制，解释下两者是否互相影响？或者是独立工作？

异常检测异常检测和踢出异常主机是一个动态检查上游主机是否正常工作，对不健康主机进行移除的过程。异常检测是一种被动健康检查，根据返回状态码来判断是否满足移除条件，最后将主机移除，首先我们来了解下驱逐算法。从上图中，可以看出来主机异常时首先会检查是不是有主机已经被移除了，如果没有被移除，那么直接移除这个不健康的主机，如果有主机被移除，则会率先检测是否超过移除阈值（maxEjectionPercent），如果超过这个阈值，则不会有任何行为发生，如果没超过这个阈值，那么则会将该主机移除一段时间，这段时间后则会将主机放入负载均衡池中供下游主机选择并分发请求。什么是Panic_Threshold？在负载均衡的过程中，Envoy只会考虑健康的上游主机。然而，如果健康主机的比例过低，Envoy将会无视健康状态分发所有的请求，这就是所谓的Panic Threshold，这个阈值默认为50%。这个设计的目的是防止大规模主机崩溃导致整个集群负载过高。Panic阈值需要和优先级一起配合工作。如果在某个优先级下健康主机数少了，Envoy将会将一些流量转移到低优先级的主机。如果在低优先级主机中，Envoy发现足够数量的的健康主机。Envoy将会无视Panic阈值。如果各个优先级健康程度都是100%。Envoy将忽略panic阈值而根据既定负载均衡算法路由流量。如果整体健康程度低100%，envoy认定没有足够数量健康的宿主机，但是他仍会给所有优先级的主机分发流量。但是如果给定优先级的健康宿主机比例低于了Panic阈值，这时候对于这部分优先级的宿主机，所有流量将会分发给这部分宿主机而不考虑他们的健康状态。我们定位到代码中来看下Panic Threshold是如何配置和工作的。如图，我们可以看出healthy_panic_threshold被默认设定为50%。在判断流程当中，Envoy先会拿到实时的panic_threshold值，然后通过计算健康的hosts数量与总hosts的数量比值来比较。在Envoy种有一个hostSourceToUse的方法，这个方法则是作为负载均衡的一部分，来将可用的hosts作为对象返回给调用方。其中包含很多种情况，我们在此只列举处在panic状态下的情况。如下图，若isGlobalPanic方法返回True也就是说集群内处在Panic模式，首先统计数据上会记录一次相应的数据，再次可用hosts列表将会包含所有存在的hosts而无视他们的健康状态。熔断的触发与实现Istio现在本身支持的四个参数是：连续错误个数，检测周期，主机移除比例以及基本移除时间。这四个参数看上去可以大致归类一下，连续错误个数和检测周期有点像是触发条件，但实际上真正的触发条件只有一个连续错误个数也就是consecutive_5xx。主机移除比例和基本移除时间，更像是熔断结果。我们接下来将这四个参数逐一分析下作用和实现。Consecutive_5xx:设置的是5xx以上错误的个数。Envoy中的putHttpResponseCode方法根据请求结果的http状态码来进行统计。如果返回状态码不高于500则会设定envoy统计数据中consecutive_5xx为0并且结束方法，若返回码高于500则需要进行两次判断。首先判断状态码是否是502，503以及504，如果是则会首先将gateway failure 统计数据自增1，而后判断是否触发了gateway failure的熔断，这部分和istio设定的参数关系不大，我们暂不展开。同样即便是Gateway failure或者返回值为500,501，consecutive_5xx这个统计数据也会自增1然后和设定的熔断条件进行比较（consecutive_errors）。如过consecutive_5xx和配置中的比较相等，则会触发相应的onConsecutive5xx方法，这个方法则是通知主线程，这个主机发生了触发了5xx错误熔断。有趣的是我们没展开的gateway failure达到触发条件也是会触发这个通知主线程函数，只不过参数上传入的是gateway failure这个参数。这个通知方法内会触发onConsecutiveErrorWorker，正是这个方法最重隔离主机。我们在分析隔离主机之前先来分析另一个参数MaxEjectionPercent，这个参数是最大主机隔离比例。在ejectHost这个方法中，首先会获得已配置的max_ejection_percent这个参数的值，若果没有配置则会引用默认的10%。在截图中，我们可以看出如果ejected_percent如果小于max_ejection_percent，就会对主机进行移除操作。此时我们分析下，如果我们设定为1%，即便移除后ejected_percent比例高于max_ejection_percent也会执行移除行为，类似向上取整。例如，10个主机，设定移除比例为11%，则最多会移除2个主机而不是1个。如果我们将max_ejection_percent设成0又会发生什么呢？是否像我们想象的那样一个都不移除因为毕竟0<0这个条件是不成立的。我在Istio中对应的destinationrule中将max_ejection_percent设置为0，但是发现还是会熔断1个。进而去查询istio-proxy的配置，发现max_ejection_percent并未配置下去，也就是说这个值采用的默认10%。在查询Istio中的代码applyOutlierDetection方法中找到。只有在maxEjectionPercent大于0的时候才会采用这个值，否则不会采用该值，也就是说如果我们配了0下去，这个数值不会转配到Envoy上，这也就解释了为什么Envoy中的configure_dump中并没有找到maxEjectionPercent所配置的0，并且还解释了为什么我们认为配置了0，还是会有上游主机熔断这个情况发生，因为使用了Envoy默认的10%。IntervalInterval限定的是检测周期，即多久会检测一次上游主机返回的Http code来断定是否需要对齐采取熔断策略。其实检测的这种行为都是由Detector来执行的，interval就是赋予detector的一个定时基准。 首先在armIntervalTimer方法中，启用定时器，定时器时间会读取配置的interval，如果没有这个配置则会启用默认的10s，如下图：当detector initialize的时候会直接启动这个定时器，也就是每过预设的一段时间detector会检查所有的主机的状态。若这个主机没有处在eject状态则不会做任何行为，如果这个主机处于被隔离的状态，则会检测他移除时间和现在时间相比，是否满足召回条件。上图中的checkHostForUneject就是专门检查主机状态和判断是否要召回的方法。介绍这个方法就要提到熔断的最后一个参数baseEjectionTime这个参数意味最小隔离时间，实际隔离时间为最小隔离时间与隔离次数的乘积。在checkHostForUneject这个方法中，如果主机的健康检查为健康则会直接return不作任何行为，如果主机的健康检查并不健康，则会读取baseEjectionTime而后通过计算与隔离次数的乘积得出应当被隔离的时间。当前时刻的时间会以参数的形式传递进来，now和主机最后一次移除相减得出实际隔离的时间。如果应当被隔离的时间小于等于实际被隔离的时间则会将主机召回并且重置统计参数，反之则不会有任何行为。异常点检查仍有许多istio未开放的参数，例如GatewayFailure、SuccessRate、最小健康实例数等。其实现上和负载均衡，健康检查等特性有较强的关联，许多细节仍需分析和实验。相关服务请访问https://support.huaweicloud.com/cce/index.html?cce_helpcenter_2019

上一篇我们介绍了ServiceComb内置的负载均衡组件handler-loadbalance，本篇我们将介绍Service-Center使用入门。 一. Service-Center 是什么ServiceCenter是一个服务注册中心。服务提供者可以将自身的实例信息注册到 ServiceCenter，以供服务消费者发现并使用它。 二. 为什么使用Service-Center在微服务架构中，一个应用由一组职责单一化的服务组成，各个服务被动态的部署到不同的节点。面对这样一组服务，应该如何去管理服务之间的依赖关系呢? 服务注册中心的出现正是为了解决这样的问题，它提供的注册机制，允许服务提供者将自己的信息登记到中心；提供的发现机制，供服务消费者从中心查找服务提供者信息。 服务注册中心优点：1.解耦服务提供者与服务消费者，服务消费者不需要硬编码服务提供者地址。2.服务动态发现及可伸缩能力，服务提供者实例的动态增减能通过注册中心动态推送到服务消费者端。3.通过注册中心可以动态的监控服务运行质量及服务依赖，为服务提供服务治理能力。 三. 注册发现流程如上图，Service-Center中服务发现流程大致有以下几个步骤：服务提供者向Service-Center注册服务信息服务提供者发送心跳，维持在Service-Center中的“UP”状态服务消费者向Service-Center注册服务信息服务消费者从Service-Center发现服务提供者信息服务消费者向服务提供者发送请求，并获取通讯结果•Service-Center注册发现接口基于RESTful标准实现，不受开发语言限制，实现对应接口可以参考官方API文档：https://rawcdn.githack.com/ServiceComb/service-center/master/docs/api-docs.html•Service-Center提供了简单注册与发现的Client，其中封装了API实现，可直接使用，具体可查看：https://github.com/apache/servicecomb-service-center/tree/master/pkg/client/sc 四. 使用Service-Center为了更好的理解流程，下面我们将通过“helloword”的示例，实现基于Service-Center的注册发现，并完成Consumer与Provider之间的通讯。以下仅展示了主要流程代码，完整示例请参考：https://github.com/ChinX/service-center-demo/tree/simple-demo 1.目录参考创建名为“helloworld”的项目，以下为参考目录结构：2. 服务提供端实现新建服务提供端配置文件： helloworld/rest/provider/conf/microservice.yaml新建项目入口文件： helloworld/rest/provider/provider.go01.在main函数中完成启动流程：02.启动服务提供端http监听03.向Service-Center注册自身服务，其中包含微服务创建、实例注册、心跳保活三个部分，具体代码如下：3. 服务消费端实现配置文件： helloworld/rest/provider/conf/microservice.yaml入口文件： helloworld/rest/consumer/consumer.go01.在main函数中完成启动流程：02.从Service-Center服务发现服务提供端,涉及创建服务、服务发现接口：03.请求接口“/hello”完成与服务提供端的通讯 4. 构建编译以下基于 go 1.11+ 进行构建，请检测自身 go 环境。进入 service-center-demo 目录: 五. 功能验证1. 安装启动 Service-Center从Service-Center官网获取二进制包：http://servicecomb.apache.org/release/ ，解压并运行二进制执行如上命令并得到对应的反馈信息，则说明安装部署成功。2. 启动 provider输出信息分析：服务提供端启动并监听了本地8080端口成功创建微服务服务，并打印了返回的serviceId成功注册自身实例，并打印了返回的instanceId服务提供端在启动30秒后，成功发送了一次心跳3. 启动 consumer输出信息分析：服务消费端成功创建微服务服务，并打印了返回的serviceId服务消费端成功发现provider实例，并打印了返回的provider endpoints服务提供端成功向服务提供端发送请求，并获得返回的信息“hello world”此时查看provider端控制台，若出现“2019/02/17 21:13：02 request from consumer”类似字样的打印，则说明provider端接收到consumer端的请求，共同印证了通讯的成功。 文末小结本文向社区读者从用户角度阐述了ServiceCenter的基本使用方法，完成最简单的服务注册与发现。  我们也非常欢迎爱好者们向社区提问和贡献代码:) 下篇将介绍ServiceCenter的架构与启动流程介绍。 如在阅读代码时有任何疑问想交流，欢迎扫码加入进微信群。扫描二维码添加微服务小助手期待志同道合的朋友们加入ServiceComb的大门为你们敞开~用心做开源，不忘初衷 前期阅读[学习微服务-第8天] ServiceComb内置负载均衡组件handler-loadbalance[学习微服务第7天] ServiceComb+SpringCloud Ribbon源码解读[学习微服务-第6天] 负载均衡之ServiceComb + SpringCloud Ribbon[学习微服务-第5天]ServiceComb+Zipkin源码解读[学习微服务-第4天]ServiceComb+Zipkin[学习微服务-第3天] ServiceComb内置高性能网关服务[每天学习微服务-源码解读] ServiceComb+SpringCloud Zuul[每天学习微服务-网关]ServiceComb+SpringCloud Zuul 了解更多信息请访问： 官方网站 ↓↓↓http://servicecomb.apache.org/ Github代码仓库↓↓↓https://github.com/apache?q=ServiceComb 

在上两篇 [微服务]ServiceComb + SpringCloud Ribbon：使用篇 和 [微服务]ServiceComb + SpringCloud Ribbon：源码解读篇 中介绍了负载均衡的概念和ServiceComb结合SpringCloud Ribbon的使用, 本篇将介绍ServiceComb内置的负载均衡组件handler-loadbalance本文参考于官方手册：https://docs.servicecomb.io/java-chassis/zh_CN/references-handlers/loadbalance.html简介ServiceComb提供了非常强大的负载均衡能力。它的核心包括两部分，第一部分是DiscoveryTree，通过将微服务实例根据接口兼容性、数据中心、实例状态等分组，DiscoveryFilter是其主要组成部分；第二部分是基于Ribbon的负载均衡方案，支持随机、顺序、基于响应时间的权值等多种负载均衡路由策略IRule，以及可以支持Invocation状态的ServerListFilterExt。代码示例以下代码请参考官方示例：https://github.com/apache/servicecomb-java-chassis/tree/master/samples/springmvc-sample注意该示例中并未添加重试策略，读者可自行添加验证。1. 启动负载均衡在配置文件microservice.yaml中加入以下配置注意Consumer是首字母大写在项目的pom文件中加入以下依赖提供负载均衡支持2. 配置负载均衡策略开发者还可以针对不同的微服务配置不一样的策略，只需要给配置项增加服务名，例如：其中myservice为微服务名3. 设置重试策略负载均衡模块还支持配置失败重试的策略。默认未启用重试。开启只需加如下配置↓↓↓•retryOnNext : 表示失败以后，根据负载均衡策略，重新选择一个实例重试（可能选择到同一个实例）。•retryOnSame : 表示仍然使用上次失败的实例进行重试。4. 代码调用支持Restful和Rpc调用对于Restful调用的url形式如下：cse://微服务名/资源路径?参数自定义ServiceComb的负载均衡模块提供了强大的扩展能力，包括DiscoveryFilter、ServerListFilterExt、ExtensionsFactory（扩展IRule，RetryHandler等）。loadbalance模块本身包含了每一个扩展的实现，这里不详细描述如何扩展。开发者可参考官方手册：https://docs.servicecomb.io/java-chassis/zh_CN/references-handlers/loadbalance.html文末小结本文向社区读者从使用角度阐述了ServiceComb的内置负载均衡模块。我们也非常欢迎爱好者们向社区提问和贡献代码。下章我们将介绍服务中心SeviceCenter的使用。如果在阅读代码时有任何疑问想交流，欢迎扫码加入进微信群。期待志同道合的朋友们加入ServiceComb的大门为你们敞开~用心做开源，不忘初衷

一、负载均衡算法原理与实战负载均衡算法（load balancing algorithm）,定义了几种基本的流量分发方式，在Istio中一共有4种标准负载均衡算法。•Round_Robin： 轮询算法，顾名思义请求将会依次发给每一个实例，来共同分担所有的请求。•Random： 随机算法，将所有的请求随机分发给健康的实例•Least_Conn: 最小连接数，在所有健康的实例中任选两个，将请求发给连接数较小的那一个实例。接下来，我们将根据以上几个算法结合APM（应用性能管理）的监控拓扑图来实战下。·实战环境·华为云开启了Istio服务网格的CCE集群 官方最佳时间Bookinfo应用，并且给Reviews配置了五个实例开通APM测试服务（免费）我们知道如果用户不进行任何配置，负载均衡算法默认是轮询算法，所以我们现将负载均衡算法设为随机（Random）。步骤 1在云容器引擎界面点击应用管理，选择流量治理。步骤 2右侧出现拓扑图，在上面的选项栏中选择集群，命名空间，应用。然后点击我们想配置的组件，这里是 reviews，右侧则会出现流量治理的界面。步骤 3在负载均衡算法中，由Round_Robin 改为random。步骤 4在左侧导航栏中选择流量治理下面的流量监控，再选择相应的集群，命名空间，应用。多访问几次，或者后台写脚本一直curl productpage，可以从拓扑图中观察数据。步骤 5当有流量时，鼠标右键点击reviews组件，选择展开选项这时我们可以看到所有实例的被分发情况。实例编号12345访问次数6238394252其余负载均衡算法基本一样，我们在步骤上不做赘述，直接展示结果。轮询算法：实例编号12345访问次数4747484647二、会话保持原理与实战会话保持（Session Affinity）是通过设定的某个指标来计算，将哈希值相同的请求分发至某个固定的实例来处理。现在支持基于HTTP头部设定指标和Cookie键值设定指标。我们当前还在轮询算法中，所以所有请求会均匀的分配给所有实例，设置会话保持基于HTTP请求头部，并且设为Cookie。我们后台curl的请求cookie设为了一个固定值，理论上来讲所有的请求都会分发至同一个pod。我们依然采用流量监控，展开reviews组件来观察分发情况。根据图中不难看出，所有的请求都分发至了第二个实例，因为cookie一致所以保持了这个会话链接。三、故障注入原理与实战故障注入（Fault Injection）为开发和测试人员主动向系统中引入故障，来观察系统在非正常状态下的行为，是一种可靠性，稳定性的验证手段。Istio也支持了非侵入式的注入故障，分为时延故障和中断故障。故障注入的步骤大致相同在流量治理页面的下方，选择时延故障，并且输入触发百分比和延时时间。然后再打开productpage 手动刷新几次，能明显感觉到延迟有了变化，当然也可以打开F12调试界面，观察网络请求状况，不难发现productpage请求耗时都在2秒上下。这时候我们打开流量监控界面观察下发现productpage与reviews受到了明显的影响。红色表示请求状态极差，虚线表示是由时延造成的。接下来我们来测试并且使用中断故障，我们对details配置中断故障，中断返回码设为501。配置完后，我们再去手动访问几次productpage来观察下结果。发现现在的右侧details已经报了error我们回到流量监控图，可以看到组件之间的访问情况。在给ratings配置了中断故障后，原本调用ratings组件的reviews组件，已经无法和ratings通信了。本文以华为云istio服务结合APM服务为大家演示了流量治理中的主要功能。希望大家在今后的开发和测试中可以利用istio灵活的非侵入的治理功能提高开发和测试的效率。相关服务请访问https://support.huaweicloud.com/cce/index.html?cce_helpcenter_2019

在微服务架构中，客户端负载均衡是指负载均衡器作为客户端软件的一部分,客户端得到可用的服务实例列表然后按照特定的负载均衡策略,分发请求到不同的服务。ServiceComb内置了客户端负载均衡组件，开发者可以非常简单的使用。具体可参考:https://docs.servicecomb.io/java-chassis/zh_CN/references-handlers/loadbalance.html 本文将介绍ServiceComb与SpringCloud的Ribbon负载均衡组件协同工作，以构建微服务应用。ServiceComb已适配对应的接口和配置，用户用极简单的方法配置后即可使微服务应用具备负载均衡的能力。示例以下通过一个服务提供者provider-service和消费者consumer-service作为demo演示。provider-service会启动3个微服务实例，消费者端consumer-service使用Ribbon负载均衡调用proveder-service服务的接口。其中consumer-service在调用provider-service提供的接口时会打印出真实调用的URL ↓↓↓完整示例地址：https://github.com/lisenwork/servicecomb-demo/tree/master/servicecomb-ribbon 预置条件:  示例应先安装启动服务与注册中心ServiceCenter，详细步骤请参考官网↓↓↓http://servicecomb.apache.org/cn/users/setup-environment/#%E8%BF%90%E8%A1%8Cservice-center 一开发服务消费者comsumer-service只需三步即可开发拥有负载均衡能力的微服务步骤如下：01添加依赖新建pom文件，引入如下依赖。完整pom文件内容请参考↓↓↓https://github.com/lisenwork/servicecomb-demo/blob/master/servicecomb-ribbon/consumer-service/pom.xml     02配置 在resources目录下新建ServiceComb配置文件microservice.yaml。配置微服务信息↓↓↓03项目入口新建启动类ConsumerApplication.java。如下图，启动类里同时实例化一个RestTemplate对象。该对象用于后面的服务间接口调用。新建ConsumerController.java。在该类的consumer方法里使用Ribbon的API动态获取服务实例，并打印出被选中的实例的真实IP地址和端口。最后调用服务实例的接口，获取结果并返回。04启动项目根目录下执行命令 mvn spring-boot:run二开发服务提供者provider-service01添加依赖新建pom文件，引入如下依赖。完整pom文件内容请参考↓↓↓https://github.com/lisenwork/servicecomb-demo/blob/master/servicecomb-ribbon/provider-service/pom.xml 02配置 在src/main/resources目录下新建microservice.yaml03项目入口新建启动类ProviderApplication.java新建ProviderController.java。只向外提供/provider接口04启动 服务提供者要启动3个微服务实例。打开microservice.yaml文件，分别修改微服务监听端口为8888，8889，8890，在项目根目录下执行3次命令 mvn spring-boot:run演示浏览器访问http://localhost:7777/consumer，重复刷新一定次数，观察控制台，会发现服务消费者会轮询调用服务提供者的三个实例。小结本文向社区读者从读者角度阐述了ServiceComb是如何支持SpringCloud Ribbon的。我们也非常欢迎爱好者们向社区提问和贡献代码。下章我们将介绍ServiceComb+SpringCloud Ribbon源码篇。如果在阅读代码时有任何疑问想交流，欢迎扫码加入进微信群。期待志同道合的朋友们加入ServiceComb的大门为你们敞开~用心做开源，不忘初衷前期阅读[学习微服务-第5天]ServiceComb+Zipkin源码解读[学习微服务-第4天]ServiceComb+Zipkin[学习微服务-第3天] ServiceComb内置高性能网关服务[每天学习微服务-源码解读] ServiceComb+SpringCloud Zuul[每天学习微服务-网关]ServiceComb+SpringCloud Zuul了解更多信息请访问官方网站http://servicecomb.apache.org/ Github代码仓库https://github.com/apache?q=ServiceComb

要介绍istio请求路由，我们不由得先从pilot 和 envoy开始谈起。 在服务网格中，Pilot管理和配置所有的envoy实例。在pilot中，你几乎可以配置所有的关于流量导向规则及其他故障恢复规则。而Envoy不仅会获得从pilot拿到的基本负载均衡信息，同时周期性的健康检查，也会告诉所有的envoy其他的实例现在的运行状况。负载均衡信息，及健康检查的信息可以使envoy更加智能的去分发流量。在上述的pilot结构中，不难理解，platform adapter作为平台适配器，可以使istio顺利的在任何平台下工作。Envoy Api则提供动态更新信息，服务发现及配置路由规则的功能。请求路由在istio中，envoy的存在为流入及流出的流量提供了可控和可视的基本条件。Envoy根据所维护的信息对请求流量的一方面有利于平衡各个pod的工作量，保证不会存在极端情况而是“雨露均沾”。另一方面，envoy对请求流量的分发，从使用者角度来讲是无感知的。如图中，用户通过某个地址来访问服务A，服务A的envoy实时发现了网格内存在的服务B，并且根据既定的转发规则来分发流量（1%流入pod4访问B’版本其余99%根据负载均衡信息流入pod1-pod3访问B版本）。也正是envoy挂在服务外部的这一设计，方便开发和运维人员进行故障测试，熔断以及实时监控。VirtualService & DestinationRuleVirtualserviceVirtualService中主要是定义了请求的路由规则，当某个请求满足了先前预设的路有条件，那么这个请求就会路由至预设的服务。我们看一个简单的VirtualService例子: 在这个virtualservice中，绿色范围内的host有两条内容，第一条是服务的短名称，实际上这个名称是省略后的FQDN，这里的全称应当是reviews.default.svc.cluster.local中间标红的是规则所在的namespace，而不是reviews所在的namespace。第二条则是配置给reviews组件的通过负载均衡访问的地址。黄色部分则是路由地址，其中的subset对应的是服务中的版本。DestinationRuleDestinationRule是路由后的流量访问策略，访问策略包含负载均衡算法，熔断等限制。下图是一个destinationrule的例子：黄色部分很显然是服务的两个版本。绿色部分的意义是TrafficPolicy，里面配置的是负载均衡算法设定为最小连接数，当两个主机提供服务时，会自动选择连接数最小的主机。我们也可以在这里配置连接池，TLS连接，端口级别策略，自动移除不健康主机等设置。连接池管理连接池配置给上游主机，这意味着该主机所有获取到来自envoy的链接请求，都要遵循配置好的连接池原则，这些原则既可以配在TCP层也可以配在HTTP层。所属类型描述TCPConnectionPoolSetting.TCPSettings由于HTTP和TCP的关系，这部分属性既会作用在http连接也会作用在tcp连接HTTPConnectionPoolSetting.HTTPSettings这部分是对于应用层的HTTP连接专有的配置HTTP连接池配置http1MaxPendingRequests： 到目标主机最大等待请求数，如果不设定默认是1024，这是针对http1.1设定的，对于http2因为不会将请求放入队列所以不受影响。http2MaxRequests： 对后端的最大请求数量，不设定会默认为1024、maxRequestsPerConnection: 每次连接最大的请求数，如果这个属性值设为1，那么每次连接最多发送一个请求，也就是无法保持连接。MaxRetries： 最大重试次数。TCP连接池配置MaxConnections: 最大连接数，但是只作用于http1.1也不作用于http2，因为后者只建立一次连接。ConnectionTimeOut： TCP连接超时负载均衡器配置负载均衡概述负载均衡有两种：基于负载均衡算法和基于一致性哈希。对于基于负载均衡算法的配置十分简便，只要在simpleLB配上响应的字段即可。算法字段描述ROUND_ROBIN简单的轮训算法，这也是默认的方式LEAST_CONN随机选择两个健康的主机，并且在两者中选择连接数少的一个RANDOM健康主机内随机选择PAASTHROUGH直接分发到目标地址主机基于一致性哈希的负载均衡方式可以根据HTTP header，cookie来提供soft session affinity，但是这种负载均衡方式仅支持http连接。算法字段描述httpHeaderName根据http header获得哈希httpCookie根据http cookie获得哈希useSourceIp根据IP地址获得哈希minimumRingSize哈希环中最小虚拟节点数，默认是1024负载均衡样例负载均衡策略配置十分灵活，可以针对某个服务进行配置，配置后隶属于该服务的所有pod将会按照设定的负载均衡方式进行请求的分配，除此之外，istio也允许用户进行更深一层的配置，对于服务中的版本进行负载均衡配置的。配置后符合该版本的pod 将会按照深层配置的负载均衡模式进行分配，其余的则还按服务层面的负载均衡模式进行分配。下面我们根据一个实例来看这种情况。如图所示，绿色的内容是针对服务层面设置的负载均衡方式，如果请求了ratings这个服务那么默认将会采用最小连接数这个负载均衡方式，如果请求访问这个服务需要的是v3版本这时候版本级的负载均衡方式将会覆盖服务级的负载均衡方式，这时则会使用ROUND_ROBIN的方式。不同层级的负载均衡设置可以让操作者更加细化自身的服务设计。总结本文只介绍了很小一部分istio请求路由的内容，其灵活的配置，非侵入式的设计，跨平台的支持极大地提升了开发效率，降低了测试难度。深入理解virtualservice，destinationrule等是使用istio功能的基本前提，熟练使用连接池和负载均衡配置可以在有限资源的前提下最大化的提升应用性能。