#化鲲为鹏，我有话说#华为云的负载均衡是怎么用的呢？在华为云创建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功能的基本前提，熟练使用连接池和负载均衡配置可以在有限资源的前提下最大化的提升应用性能。

本文探讨如下几个问题：什么是架构属性约束和架构属性的关系有哪些架构属性各个架构属性涉及知识点什么是架构属性首先，问个很简单的问题！请看下面的Java代码：class Person {    private String name;    private int age;    public void skill() {         ......     }}请问上面的代码中:name和age被称为Person这个类的什么？skill又称为Person这个类的什么呢？name和age一般被称为字段、成员变量或属性；skill一般被称为方法，表示Person所具有的功能！我们稍微修改下代码：Architecture {    private String safe;    private String performance;    public void func() {         ......safe(安全性)和performance(性能)就是Architecture(架构)的属性！func就是架构所具有的功能！架构属性一般又称为质量属性！这些架构属性和架构功能是从哪来的呢？在之前的文章中提到过约束包含：功能性约束（这个系统要完成的功能）、非功能性约束（可用性、扩展性、容错性等）、其它约束（人员技能、法律法规、公司规定等）实际上，架构属性和架构功能是从约束而来:对「功能性约束」的决策结果就是架构功能对「非功能性约束」的决策结果就是架构属性而对「其它约束」的决策可能会同时影响到架构功能和架构属性给架构属性和架构功能下个定义：架构属性是对「非功能约束」决策后，架构所具有的特征，且受到一些其它约束的影响架构功能是对「功能约束」决策后，架构所具有的功能，且受到一些其它约束的影响以在线教育系统为例，来说明一下：这个系统需要具有在线直播的功能，完成这个功能约束后，系统即有了在线直播这个架构功能这个系统需要4个9的可用性，如果这个系统达到了这个非功能性约束，系统即有了高可用的架构属性法律法规规定，现在直播需要有《信息网络传播视听节目许可证》或《广播电视节目制作经营许可证》，如果你没有，那么你的系统就没法进行直播也就没有了直播这个功能；而如果人员技能不达标或者某些突发情况，那可能导致系统就不具备高可用这个属性，号称「能同时支持8位明星同时×××的微博」，不是又挂了吗？架构属性架构属性一般包括如下方面：性能，伸缩性，可用性，安全性，容错性，灾难恢复，可访问性，可运维，管理，灵活性，可扩展性，可维护性，国际化，本地化。还有法律法规，成本，人员等对上面架构属性的影响。下面分别讨论（由于涉及的内容很多，这里只是一个概要，详细内容后续慢慢讨论）。性能我们经常挂在嘴边的优化，绝大部分情况下指的是「性能优化」。「性能优化」的目的就是提高系统响应速度。而优化的原因就是系统响应速度不够快。一般认为，一个网页打开速度超过3s，用户就开始没有耐心了；如果超过5s，用户就要打算放弃访问了；而如果超过10s以上用户还没关闭，这个网站不是12306就是查分网站。上面指的「响应速度」主要分为系统性能和用户感知性能。这两者的区别是：系统性能指系统自身的响应，即调用一个接口，此接口多久能返回。而用户感知性能，是用户操作后到操作反馈的时间。举个简单的例子，假设一个页面完整加载完要3s，如果用户一点击就白页，3秒后再显示出来，那么用户感知性能就是3秒；而如果一点击1秒之内就加载了第一屏或者立即就有一个加载反馈，那么用户感知性能就在1s以内。虽然系统性能实际是一样的，但是用户的感知性能却不同。性能方面的知识点主要涉及各种优化：前端优化，网络优化，代码优化，数据库优化，JVM优化等等等等，提高TPS，QPS等系统性能和用户感知性能（用户体验）伸缩性如果你玩游戏的话，你肯定知道「开服」和「合服」吧？其实这就是伸缩性！简单来说，伸缩性就是：「你的系统能否能通过简单的增加部署，来应对更多的访问量」！例如：原来你的系统只有一台服务器，现在一台服务器撑不住了，你能否不修改任何代码，只增加一台一样的服务器就可以支撑更多的人来访问？相对的，反过来，如果你的用户量减少了，两台服务器浪费了，你能否直接关闭一台服务集，来节约成本？伸缩性涉及的知识点主要涉及分布式相关内容：应用集群，负载均衡，负载均衡算法，分布式事务，分库分表，拆分应用，服务化，SOA，微服务等可用性可用性可能是最基本的架构属性了。你经常听到的3个9,4个9,5个9就是指可用性的。可用性指的是：「系统能够连续多长时间正常运行？」3个9就表示系统全年可用时间占全年时间的99.9%，即不可用时间是365*24*60*60*0.1%=31536秒，大概8个多小时，好像时间还挺长的4个9就表示系统全年可用时间占全年时间的99.99%，即不可用时间是365*24*60*60*0.01%=3154秒，大概50多分钟。基本上最多只能出一次故障5个9就表示系统全年可用时间占全年时间的99.999%，即不可用时间是365*24*60*60*0.001%=315秒，大概5多分钟。基本上等于系统全年都要保证可用。一般情况下，系统故障了5分钟还不一定能定位到问题，更不要说解决问题了。可用性和伸缩性涉及知识点有些重合，因为保障可用性的方法就是「冗余」，实际就是集群和分布式：集群，多数据中心，主备切换，心跳，注册中心，负载均衡，负载均衡算法（轮询、随机、hash），容错（见容错处理）等安全性最近Facebook出现了系统漏洞，5000多万的用户数据被泄露了。之前的携程也是，不少的知名系统都出现过安全问题。安全性就是：「保障用户在使用系统的过程中，信息不会被泄露，导致个人财产受到损失，个人安全受到威胁等」安全性相关知识点包括：各种攻击防范（CSRF，SQL注入，脚本注入，DDos等），https，鉴权，授权，单点登录，加解密等容错性做系统时，我们都听说过，要把用户当傻瓜，要把操作做得尽量简单。而实际上，我们也要把用户当做破坏分子，他们不小的概率不会按照正常情况来操作你的系统。比如：电话号码里面写了字符啦，添加了各种表情啦，狂点提交按钮啦，狂刷新啦等等等等。你的系统需要应对这些。容错性就是：「系统对非正常情况（输入、输出、操作，异常数据等）的宽容程度」。你不能动不动就给个500错误，需要对可能的情况做容错处理。比如：前后端的数据检查，友好的错误提示。容错性涉及知识点：如何进行异常处理？非正常输入输出处理。网络波动，请求超时，服务挂掉，硬件问题，用户体验等灾难恢复灾难恢复和容错性比较类似，只是程度上的区别。用户输入错误这样的问题，可能只是导致这个用户的流程无法走下去。而「灾难」会影响一部分甚至所有用户都无法使用系统，从而导致可用性问题。比如：服务器宕机、机房断电、硬盘损坏、甚至地震了。你如何保证你的系统在上述情况下还能正常对外提供服务？灾难恢复涉及的知识点：线路的快速切换，负载均衡算法，硬件损坏的恢复，跨DC备份等可访问性类似让视觉障碍之类的残疾人也能使用你的软件，这个好像目前考虑得不是太多，暂不讨论。主要还是用户体验方面，只是面向的群体不同，优化的点也就不同。监测（可运维）上面说可用性，4个9时基本就要保障机器全年都要可用，为了达到这个目标，就要对系统进行监控，以期在早期发现问题，在影响系统可用性前，就将其解决。这就是监测。主要包括完善的监控视图，异常数据的提醒，日志的记录等监测涉及知识点：日志记录，日志统计，请求跟踪，机器负载监控，请求监控等，偏运维。管理如果你做过线上系统，应该会遇到过需要不停机调整系统某些参数的情况。例如：调整日志的输出级别，删除某些数据，刷新缓存。管理指：「运行时修改系统配置、刷新缓存等能力」。这里需要注意的是，要避免对线上系统的影响，比如：全量刷新了缓存，导致系统雪崩了。管理涉及知识点：需要权衡哪些配置需要在线进行调整。灵活性系统上线后，可能主要是运营人员对系统进行操作，一般运营人员不懂技术，如何提供方便的功能，能够让运营人员方便的使用系统。例如：用户下错单了，运营人员需要取消订单；敏感词审核了；屏蔽某些用户了；调整工作流流程了等等等等灵活性指：「非技术人员修改软件内部使用的业务规则的能力」。灵活性涉及知识点：确定哪些功能需要后台管理功能，及相关功能的设计。比如是否需要完善的权限体系，及运营人员如何管理权限体系。可扩展性系统开发是个持续的过程，对内项目一般会分期，一期二期三期；互联网项目会不断的根据用户反馈进行迭代。如何方便的进行迭代就是架构的可扩展性。扩展性指：「扩展软件使其可以做现在还不能做的事的能力。即添加新功能的难易程度。」扩展性涉及知识点：主要是设计方面的考量。面向对象设计、组件设计，高内聚，低耦合等。一些架构风格，例如插件风格，过滤器风格等对扩展性比较友好。其实大部分架构都支持可扩展性，只是支持的程度不同而已可维护性开发为什么要使用框架？为什么要走变更流程？为什么有各种开发流程？为什么发布代码还要提交运维申请？是为了管理项目，提高开发进度，能够跟进项目计划，确定是否出现偏差，及时进行调整。这些都是可维护性的范畴。可维护性指：「系统是否能快速的开发、测试、发布？」可维护性这个属性偏流程管理，包括编码规范，开发流程，测试流程，发布流程等国际化支持多国语言的能力。比如：很多网站分为中文站，国际站。这就需要考量，是使用相同的数据进行翻译，还是部署不同的系统等。本地化以符合最终用户文化习俗的方式展示数字、货币、日期等其它影响因素法律法规：某些行业会受到法律或监管机构的管理，需要符合法律法规。例如金融行业成本：成本不够，可能就会先降低甚至忽略某些架构属性的要求人员水平：人员水平也可能会降低或提高某些架构属性举个例子这些架构属性，就是在做系统架构时需要考虑的点。依然以在线教育系统为例：这个系统需要支持多少学员同时在线学习？能容忍多长时间的系统响应？这是「性能」系统需要连续多长时间不出问题？3个9?4个9？还是5个9？这是「可用性」如果系统出现了问题，该如何处理？如何响应？这是「系统容错」如果学员增多了，能否能方便的多部署系统来支持？反之，如果学员减少了，能否减少系统部署来节约成本？这是「伸缩性」如果要新增直播的功能，能否方便的添加？且基本不影响现有功能？这是「扩展性」系统能否防御恶意攻击？是否能保证用户的信息安全？这是「安全性」如何能以最小的花费来完成系统？这是「成本」考量目前的团队技术水平如何？这是「人员」考量系统出现问题或异常情况，是否能快速的通知相关人员？这需要完善的监控系统，这是「可运维性」系统如何能快速的开发、测试、发布？这是「可维护性」有哪些法律法规需要遵守？是否需要申请直播功能有国外用户吗？需要国际化吗？总结本文梳理了什么是架构属性；有哪些架构属性及相关知识点！后续对各个属性进行详细讨论。每个约束之间并不是正交的，可能满足的某个约束，却违背了另外一个或多个约束，这就需要架构师来进行取舍。就像CAP原则一样，一个分布式系统不可能同时满足可用性、一致性和分区容错性。一个架构也不可能同时满足所有的约束。©本文转自（Ala6）博客51CTO博客，如需转载，请自行联系原作者。原文链接（http://blog.51cto.com/13982920/2308354）

尊敬的华为云客户：华为云计划于2018/11/08将弹性负载均衡服务（ELB）控制台，从云服务器控制台迁移至网络控制台，届时请您前往网络控制台购买并查看弹性负载均衡的相关资源。路径：登录华为云控制台—所有服务—网络—弹性负载均衡ELB如您有任何问题，欢迎您拨打华为云服务热线：4000-955-988与我们联系。感谢您对华为云的支持！

【摘要】 弹性负载均衡（ Elastic Load Balance，简称ELB）将访问流量自动分发到多台云服务器，扩展应用系统对外的服务能力，实现更高水平的应用容错。上一章我们学习了如何创建共享云硬盘，我们基于上一个模板加入创建负载均衡ELB的内容。弹性负载均衡（ Elastic Load Balance，简称ELB）将访问流量自动分发到多台云服务器，扩展应用系统对外的服务能力，实现更高水平的应用容错。上一章我们学习了如何创建共享云硬盘，我们基于上一个模板加入创建负载均衡ELB的内容。tosca_definitions_version: huaweicloud_tosca_version_1_0node_templates:  myecs:    type: HuaweiCloud.ECS.CloudServer    properties:      availabilityZone: cn-south-1a      flavor: c1.medium      imageId: a3934478-bfeb-4a02-b257-9089779f0380      instances: 1      name: my-ecs      nics:        - subnetId:            get_reference: mysubnet      rootVolume:        size: 40        volumeType: SATA      securityGroups:        - id:            get_reference: mysg      vpcId:        get_reference: myvpc      mountedVolumes:        - mountPath: '/dev/sdc'          volumeId:            get_reference: myevs    requirements:      - vpcId:          node: myvpc      - securityGroups.id:          node: mysg      - nics.subnetId:          node: mysubnet      - mountedVolumes.volumeId:          node: myevs  mysg:    type: HuaweiCloud.VPC.SecurityGroup    properties:      name: my-sg    requirements:      - vpcId:          node: myvpc  mysgrule:    type: HuaweiCloud.VPC.SecurityGroupRule    properties:      direction: ingress      ethertype: IPv4      maxPort: 5444      minPort: 5443      protocol: TCP      securityGroupId:        get_reference: mysg    requirements:      - securityGroupId:          node: mysg  mysubnet:    type: HuaweiCloud.VPC.Subnet    properties:      cidr: '192.168.1.0/24'      dhcpEnable: true      gateway: 192.168.1.1      name: my-subnet      vpcId:        get_reference: myvpc    requirements:      - vpcId:          node: myvpc  myvpc:    type: HuaweiCloud.VPC.VPC    properties:      cidr: '192.168.0.0/16'      name: my-vpc  myevs:    type: HuaweiCloud.EVS.SharedVolume    properties:      size: 10      availabilityZone: cn-south-1a      volumeType: SATA  myelb:    type: HuaweiCloud.ELB.LoadBalancer.External    properties:      name: my-elb      vpcId:        get_reference: myvpc    requirements:      - vpcId:          node: myvpc  myelb-listener:    type: HuaweiCloud.ELB.Listener    properties:      protocol: TCP      name: my-elb-listener      backendPort: 80      backendProtocol: TCP      port: 80      lbAlgorithm: roundrobin      loadBalanceId:        get_reference: myelb    requirements:      - loadBalanceId:          node: myelb  myhealth:    type: HuaweiCloud.ELB.HealthMonitor    properties:      unhealthyThreshold: 3      healthyThreshold: 3      healthCheckInterval: 5      healthCheckConnectPort: 80      healthCheckTimeout: 10      listenerId:        get_reference: myelb-listener    requirements:      - listenerId:          node: myelb-listener  mymember:    type: HuaweiCloud.ELB.Members    properties:      serverIds:        - get_reference: myecs      listenerId:        get_reference: myelb-listener    requirements:      - serverIds:          node: myecs      - listenerId:          node: myelb-listener首先创建一个elb元素，它是部署华为云PaaS层私网LoadBalancer对象，通过创建LoadBalancer，可以为一组具有相同功能的容器应用提供一个统一的入口地址，并将请求进行负载分发到后端的各个容器应用上。参数vpcId是ELB实例所属的VPC，弹性负载均衡需要与后端监听的弹性云服务器处于同一个VPC下。elb-listener元素是弹性负载均衡下的监听器，一个loadBalancer可对应多个监听器，支持对监听器进行增加、删除。它有几个属性值：    1.         protocol是负载均衡器协议。    2.         name是监听器的名称，设置为my-elb-listener。    3.         backendPort表示云服务器端口，可根据实际情况修改。    4.         backendProtocol是云服务器协议。    5.         port是负载均衡器端口，默认为80，可根据实际情况修改。    6.         lbAlgorithm是监听器负载均衡方式，roundrobin:轮询算法, leastconn:最少连接, source:源IP算法;其中轮询算法支持会话保持功能。    7.         loadBalanceId是所属的负载均衡器ID，将elb-listener与之前创建的elb关联起来。,然后创建health-monitor元素，它是弹性负载均衡下的健康检查，一个Listener对应一个健康检查，一个健康检查管理多个弹性云服务器，支持对健康检查进行增加删除。    1.         unhealthyThreshold判定健康检查结果为fail的阈值，即健康检查连续失败多少次后，将后端云服务器的健康检查状态由success改为fail。    2.         healthyThreshold判定健康检查结果为success的阈值。    3.         healthCheckInterval是健康检查时间间隔（秒）。    4.         healthCheckConnectPort是健康检查使用端口，可根据实际情况修改，默认为云服务器端口。    5.         healthCheckTimeout是健康检查超时时间（秒）。    6.         listenerId健康检查所属的监听器ID，将health-monitor与elb-listener元素相关联。member元素是弹性负载均衡下的弹性云服务器，一个Listener可以对应多个弹性云服务器，并且可以对监听器进行增加删除。一个HealthMonitor管理多个云服务器。    1.         serverIds是后端云服务器ID。    2.         listenerId是所属的监听器ID，该参数将member与elb-listener元素相关联。为确保ELB健康检查正常运行，需要在后端弹性云服务器的安全组中添加入方向规则，允许来自100.125.0.0/16网段HTTP协议的访问，同时需要确保云服务器上80端口可返回200。部署堆栈时elb参数组中的vpcId及member参数组中的serverId需要根据实际情况填写，未正确填写会导致堆栈部署失败。负载均衡创建成功：

本篇文章讲述如何通过创建经典型公网负载均衡 (elb-external)示例模板创建堆栈。该模板创建一个包含一个监听器的经典型公网负载均衡，监听器后端可添加2个弹性云服务器。【部署结果展示】点击资源名称可以跳转到所创建的弹性负载均衡资源页面。健康检查：后端云服务器：【部署过程详解】*部署前准备：创建2台弹性云服务器，云服务器可以不绑定弹性IP。创建弹性云服务器时，如果所选择的的安全组规则未包含监听器衡健康检查需要放行的规则，则需要添加，下面以System-default安全组为例添加规则：其中协议及端口为监听器健康检查使用的协议及端口，源地址固定为100.125.0.0/16：创建弹性云服务器，创建成功后将弹性云服务器的ID拷贝下来，后续填写堆栈配置参数时使用：*参数填写：1.为堆栈填写名称及描述2.填写堆栈的配置参数：模板中包含了负载均衡，监听器，健康检查及后端云服务器四个部分，堆栈配置参数按照这四个部分进行了标签分类，可在对应的标签下填写相关组件的参数。部署时可以直接使用示例模板中的参数，也可以根据实际情况自行选择。2.1 监听器参数：监听器参数说明如下：2.2 负载均衡参数：负载均衡参数如下，其中负载均衡名称自动生成，创建完成后可以在堆栈详情页面看到：模板中的负载均衡默认带有弹性IP，未带有弹性IP的使用方式可以参考经典型私网负载均衡(elb-internal)。参数中的计费方式，EIP类型及VPC的ID均支持下拉选择：2.3 健康检查参数：健康检查的参数设置如下，需要保证协议中设置的访问方式畅通，这里使用TCP 22作为健康检查的协议及端口：2.4 后端云服务器参数：在后端云服务器参数中填写刚才拷贝的弹性云服务器的ID：*模板参数与弹性负载均衡界面对应关系：1.负载均衡：2.监听器：3.健康检查：*扩展：后端云服务器个数的扩展1 通过增加数组长度增加个数：输入界面：2 通过split函数，添加分隔符，弹性云服务器的输入参数可以缩减为一个，这里使用“, ”为分隔符，多个弹性云服务器ID通过“, ”分隔：输入界面：