在系统生命周期中, 免不了要做升级部署, 对于关键服务, 我们应该能做到不停服务完成升级。另外服务的SLA标准一般都要在四个9以上所以对于优雅停服的需要就十分有必要了。
服务器负载平衡 (SLB) 通过以下方式提供网络性能和内容交付：实施一系列算法和优先级来响应对网络。
GTM（Global Traffic Manager的简写）即全局流量管理，基于网宿智能DNS、分布式监控体系，实现实时故障切换及全球负载均衡，保障应用服务的持续高可用性。GTM基于资源的健康状况及流量负载做智能调度决策，为用户提供最佳访问IP。网宿GTM，提供更可靠、稳定和安全的流量调度服务，助您轻松构建混合云应用。
LB,SLB,ALB，GSLB,CDN，傻傻分不清楚，听风看雨。。。毒鸡汤看多了，我快掩饰不住我的悲伤了。。。
基于DNS解析的GSLB方案实际上就是把负载均衡设备部署在DNS系统中。在用户发出任何应用连接请求时，首先必须通过DNS系统来请求获得服务器的IP地址，基于DNS的GSLB正是在返回DNS解析结果的过程中进行智能决策，给用户返回一个最佳的服务器的IP地址。从用户的视角看，整个应用流程与没有GSLB参与时没有发生任何变化。
健康检查 主动运行状况检查可以在每个上游群集的基础上进行配置。如服务发现部分所述，主动运行状况检查和SDS服务发现类型齐头并进。但是，即使使用其他服务发现类型，也有其他需要进行主动健康检查的情况。 Envoy支持三种不同类型的健康检查以及各种设置（检查时间间隔，标记主机不健康之前所需的故障，标记主机健康之前所需的成功等）： HTTP：在HTTP健康检查期间，Envoy将向上游主机发送HTTP请求。如果主机健康，预计会有200个回应。如果上游主机想立即通知下游主机不再转发流量，则返回503。 L3 / L
这些核心特性使得Nacos成为一个功能丰富、灵活且可靠的服务发现和配置管理解决方案，适用于构建和管理大规模的分布式系统。
注册中心不应仅提供服务注册和发现功能，还应保证对服务可用性监测，对不健康的服务和过期的进行标识或剔除，维护实例的生命周期，以保证客户端尽可能的查询到可用的服务列表。
七层健康检查，使用HTTP协议，支持GET、HEAD两种请求方法，HEAD只获取头部信息，不获取实际内容，更加轻量的探测，两种方式，都是依赖RS返回的HTTP CODE与设置的健康状态码比对(默认为1xx、2xx、3xx、4xx)，如果不在健康状态码范围内或者在响应超时时间内没有返回任何状态码并且达到不健康阈值次数，则判定为不健康。
相信很多小伙伴的公司都是服务治理，自动化运维了吧，那么我们很多东西都变成我们自己去设置了，比如自己创建一个域名，绑定他的代理机器，它的web负载均衡这些东西。所以今天跟大家一起来看看负载均衡
-多年互联网运维工作经验，曾负责过大规模集群架构自动化运维管理工作。 -擅长Web集群架构与自动化运维，曾负责国内某大型金融公司运维工作。 -devops项目经理兼DBA。 -开发过一套自动化运维平台（功能如下）： 1)整合了各个公有云API，自主创建云主机。 2)ELK自动化收集日志功能。 3)Saltstack自动化运维统一配置管理工具。 4)Git、Jenkins自动化代码上线及自动化测试平台。 5)堡垒机，连接Linux、Windows平台及日志审计。 6)SQL执行及审批流程。 7)慢查询日志分析web界面。
upstream是Kong网关将流量转发到的多个target的集合，target可以是域名、ip，不同target可以有不同的port，且可分配不同的权重。通过使用upstream，Kong网关提供如下功能：
1. **服务发现**：Nacos 作为一个服务注册中心，允许服务提供者在启动时将自身服务信息注册到 Nacos Server，服务消费者则可以通过 Nacos 获取服务列表，进而找到所需的服务提供方进行调用，实现了服务间的自动发现与绑定。
通过对Nacos注册与发现源码阅读，将其核心原理归纳提炼。包含：注册、发现、节点之间通信、健康检查类型。
前者依赖客户端自我报告,较易失效或延迟发现问题。后者由服务端定期检查,可更快准确发现客户端异常。但也增加服务端负载。
Spring Cloud Alibaba Nacos 作为注册中心不止提供了服务注册和服务发现功能，它还提供了服务可用性监测的机制。有了此机制之后，Nacos 才能感知服务的健康状态，从而为服务调用者提供健康的服务实例，最终保证了业务系统能够正常的执行。
大家好，又见面了，我是你们的朋友全栈君。引言 在过去的几年中，随着互联网的快速发展和企业应用WEB化，服务器负载均衡（SLB）技术已经不再陌生。 服务器负载均衡根据用户数据请求中的4-7层信息将其智能转发到后端少则数台多则成百上千台应用服务器， 并且确保根据事先定义的策略选择最佳的服务器进行转发，从而一定程度上解决了应用的可用性、扩展性等问题。 但是，随着用户对应用可用性和扩展性需求的进一步增加，越来越多的用户不满足于在单一数据中心提供服务，开始考虑容灾、用户就近访问等问题。 这正是负载均衡设备中的全局服务器负载均衡技术（GSLB）所要解决的问题。尽管GSLB技术早在数年前就是大部分负载均衡设备提供的必备功能， 但由于用户需求较小、功能不够完善、性能不足、价格高昂等因素，目前部署GSLB的用户在负载均衡整个用户群中所占比例还是很小。相信在未来几年中，GSLB的应用比例将快速增加。 本文针对GSLB相关技术及解决方案进行介绍。 GSLB技术 市场上存在的GSLB技术可以归纳为以下几类： 基于DNS的GSLB 绝大部分使用负载均衡技术的应用都通过域名来访问目的主机，在用户发出任何应用连接请求时，首先必须通过DNS请求获得服务器的IP地址，基于DNS的GSLB正是在返回DNS解析结果的过程中进行智能决策， 给用户返回一个最佳的服务IP。用户应用流程与没有GSLB时未发生任何变化。这也是市场上主流的GSLB技术。 基于应用重定向的GSLB 基于应用重定向的GSLB是在负载均衡设备收到用户应用请求并选择最佳服务IP后，通过应用层协议将用户请求重定向到所选择的最佳服务IP。这种方式只适用于支持应用重定向的协议（如HTTP、MMS），且性能较差。 基于IP地址伪装（三角传输）的GSLB 有个别负载均衡设备厂商采用这种技术来实现GSLB。当用户应用请求到达一台负载均衡设备时，这台负载均衡设备计算出对于该用户最佳的服务IP（定义在另一台同一厂商负载均衡设备上）并将用户请求转发给该IP。 第二台负载均衡设备直接将响应返回用户，但必须将源地址修改为第一台负载均衡设备的服务IP。这种方式要求所有站点必须为同一厂家的负载均衡设备，另外地址伪装的数据包会可能被互联网中的路由设备过滤掉。 因为所有用户请求都要经过广域网三角方式传输而不是发到最佳的负载均衡设备，用户访问效果和性能都比较差。 基于主机路由注入的GSLB(Anycast) 在多个站点定义相同的服务IP，并由负载均衡设备或路由器将该IP的主机路由发送出去，这样网络中会存在多条到达该主机地址的路由。由于路由设备总是选择最近（Metric最小）的路由转发数据， 用户的访问请求总是被转发到最近的负载均衡设备。这种方式要在不同站点广播相同的主机路由，由于运营商的限制问题很难实现。另外这种方式策略非常简单，只能根据最短路由选择，客户无法定义灵活的选择策略。 根据上面的分析，后面的三种方式都有很多局限性或性能较差，这也是为什么基于DNS的GSLB成为主流技术的原因。在基于DNS的GSLB具体实现中，不同厂家的功能会有所不同，也有部分用户自己开发智能DNS实现类似功能。 总体来说，一个完善的基于DNS的GSLB设备可以满足以下需求： 支持任何IP应用。 各服务站点可以使用不同厂家的本地服务器负载均衡设备或直接使用真实服务器。 GSLB控制设备可直接作为授权DNS，也可以配置为DNS代理方式。DNS代理方式在做GSLB决策控制同时可以对后端DNS服务器进行负载均衡。当业务量增加时可以通过增加后端的真实DNS服务器数量进行扩展。 内置国际IANA机构提供的全球各区域地址分配表，且用户自定义区域可以包含足够多的IP前缀。同时区域定义支持树状分层结构，如China.Beijing.HaiDian。这些功能在GSLB控制设备进行静态基于区域选择服务站点时是必须的。 支持返回A记录和CNAME等记录。尤其在多级GSLB控制时，返回CNAME是必须具备的。 支持丰富的GSLB策略，常见的如往返时间（RTT）、权重、活动服务器等。 具有灵活的自定义脚本用于过滤各种非法DNS请求或攻击。 强大的DDoS攻击防护功能。一旦GSLB控制设备被攻击瘫痪，所有业务都无法提供。 基于DNS的GSLB工作原理 下面我们对基于DNS的GSLB的工作原理进行简单介绍。
腾讯云的负载均衡产品发布至今，产品形态变化还是比较大的，最开始有传统型负载均衡，应用型负载均衡，后面结合自身产品特性以及云上相关用户的产品需求，逐渐开始改造，使其管理更加方便，更加适应全量云用户业务行为。
Nacos是阿里巴巴开源的注册中心和配置中心的技术解决方案，目前有很多公司都在使用它，并落地到自己的业务产品中，好吧你们知不知道它是支持健康检查机制的呢？下面我将带着大家一起来理解它的健康检查机制的核心原理及业务背景。
https://kubernetes.io/zh-cn/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/
目前的网络架构是每个主机都有⼀个独立的 IP 地址，那么服务发现基本上都是通过某种方式获取到服务所部署的 IP 地址。
负载均衡可以定期向后端服务器发送 Ping 命令、尝试连接或发送请求来探测后端服务器运行的状况，这些探测称为健康检查。负载均衡通过健康检查来判断后端服务的可用性，避免后端服务异常影响前端业务，从而提高业务整体可用性。
该模块在Tengine-1.4.0版本以前没有默认开启，它可以在配置编译选项的时候开启：./configure --with-http_upstream_check_module
严格来说，nginx自带是没有针对负载均衡后端节点的健康检查的，但是可以通过默认自带的ngx_http_proxy_module模块和ngx_http_upstream_module模块中的相关指令来完成当后端节点出现故障时，自动切换到健康节点来提供访问。下面列出这两个模块中相关的指令：
在之前的文章中完成了客服对话的Demo功能，但是现在的连接是无限制的长时间连接没有做心跳、失活、超时断连等功能，心跳的实现方法有很多种，并且WebSocket就提供了ping/pong类型的消息。
DDoS 高防 IP 通过健康检查帮助用户自动识别后端服务器的运行状况，自动隔离异常的服务器，以此降低了后端服务器异常对整体业务可用性的影响。
随着人们的生活水平的不断提高，人们对身体健康越来越重视，很多人都做过体检，一般公司都会有一年一度的体检福利，健康体检是家喻户晓了。
Nginx 的健康检查这块笔者在网上看了很多文章，基本都是零零散散的，讲各种实现方式，没有一篇能完整的讲当下的 Nginx 实现健康检查的几种方式，应该选哪一种来使用，于是笔者想总结一篇。
内容概况 云计算的特点是开箱即用，可以随时的扩缩容，不用考虑硬件的损坏问题，也有丰富的云服务和云平台供我们选择。在本次演讲中，黎山通过实际应用场景为我们讲述了基础设施及代码的重要性，以及在云计算的运维
目前腾讯云、阿里云等大型云厂商基本上都是通过提供CLB服务进行路由转发，什么是CLB？
PolarisMesh（北极星）是腾讯开源的服务治理平台，致力于解决分布式和微服务架构中的服务管理、流量管理、配置管理、故障容错和可观测性问题，针对不同的技术栈和环境提供服务治理的标准方案和最佳实践。
服务（Service）是 Nacos 世界的一等公民。Nacos 支持几乎所有主流类型的“服务”的发现、配置和管理：
Tengine本质上就是nginx，用法跟nginx一模一样，由淘宝团队进行二次开发。它在Nginx的基础上，针对大访问量网站的需求，添加了很多高级功能和特性。Tengine的性能和稳定性已经在大型的网站如淘宝网，天猫商城等得到了很好的检验。它的最终目标是打造一个高效、稳定、安全、易用的Web平台。
公司业务线上对后端节点的健康检查是通过nginx_upstream_check_module模块做的，这里我将分别介绍这三种实现方式以及之间的差异性。
初次与 Gcore 相识还是因为当年的伯力机器对国内北方部分联通效果相当不错，于是随大流也购买了一台。不过时至今日 Gcore 的重心已经从主机业务慢慢的迁移到了云平台，服务也更加的多样化了。之前在对比选择支持按条件解析的 DNS 服务时，先后用过 Dnspod ，AWS ，但最终还是在 Gcore 安了家。
之前写过一篇文章，介绍Nginx如何监控各server流量，主要是通过新增第三方status模块查看所有server及upstream状态进行查看，之后总有人问有没有办法监控upstream并进行告警，所以今天介绍一下，完整的upstream监控及告警方法
Consul是一款开源的服务发现和配置管理工具，具有强大的健康检查功能，能够检测服务的健康状态并自动修复。
【编者的话】本文对比了Zookeeper、etcd和Consul三种服务发现工具，探讨了最佳的服务发现解决方案，仅供参考。 如果使用预定义的端口，服务越多，发生冲突的可能性越大，毕竟，不可能有两个服务监听同一个端口。管理一个拥挤的比方说被几百个服务所使用的所有端口的列表，本身就是一个挑战，添加到该列表后，这些服务需要的数据库和数量会日益增多。因此我们应该部署无需指定端口的服务，并且让Docker为我们分配一个随机的端口。唯一的问题是我们需要发现端口号，并且让别人知道。
原创 高相林（禅鸣） [阿里巴巴云原生](javascript:void(0)😉 作者 | 高相林（禅鸣） **导读：**集群升级是 Kubernetes 集群生命周期中最为重要的一环，也是众多使用者最为谨慎对待的操作之一。为了更好地理解集群升级这件事情的内涵外延，我们首先会对集群升级的必要性和难点进行阐述；随后会对集群升级前必须要做的前置检查进行逐一讲解；接下来会对两种常见的升级方式进行展开介绍；最后对集群升级的三个步骤进行讲解，帮助读者从理论走入实践。 升级的必要性&难点 在 Kubernetes
导读：集群升级是 Kubernetes 集群生命周期中最为重要的一环，也是众多使用者最为谨慎对待的操作之一。为了更好地理解集群升级这件事情的内涵外延，我们首先会对集群升级的必要性和难点进行阐述；随后会对集群升级前必须要做的前置检查进行逐一讲解；接下来会对两种常见的升级方式进行展开介绍；最后对集群升级的三个步骤进行讲解，帮助读者从理论走入实践。
ZooKeeper、Consul、Eureka和新生的Nacos 都实现了注册中心的功能。那么从哪些方面进行对比，进而选型呢？
Euraka 使用时需要显式配置健康检查支持；Zookeeper,Etcd 则在失去了和服务进程的连接情况下任务不健康，而 Consul 相对更为详细点，比如内存是否已使用了90%，文件系统的空间是不是快不足了。
总的来看，目前Consul 自身功能，和 spring cloud 对其集成的支持都相对较为完善，而且运维的复杂度较为简单（没有详细列出讨论），Eureka 设计上比较符合场景，但还需持续的完善。
注：本作品采用 知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议 进行许可。
服务注册中心本质上是为了解耦服务提供者和服务消费者。对于任何一个微服务，原则上都应存在或者支持多个提供者，这是由微服务的分布式属性决定的。更进一步，为了支持弹性扩缩容特性，一个微服务的提供者的数量和分布往往是动态变化的，也是无法预先确定的。因此，原本在单体应用阶段常用的静态LB机制就不再适用了，需要引入额外的组件来管理微服务提供者的注册与发现，而这个组件就是服务注册中心。
gRPC 在当前最常见的应用就是在微服务场景中，所以不可避免的会有服务注册与发现问题，我们使用gRPC实现的服务可以使用 Consul 或者 etcd 作为服务注册与发现中心，本文主要介绍Consul。
内容来源：2017 年 12 月 21 日，驻云科技资深架构师翟永东在“云时代企业架构的搭建”进行《云上架构如何实现高性能和高可用》演讲分享。IT 大咖说（微信id：itdakashuo）作为独家视频合作方，经主办方和讲者审阅授权发布。 阅读字数：2851 | 8分钟阅读 摘要 云上架构需要关注多方面的因素，本次主要讲的是高可用和高性能，从这两方面展开深度的解析如何搭建完善的云上架构。 嘉宾演讲视频及PPT回顾：http://suo.im/4sKQd8 云上架构概述 云上搭建架构不单单需要考虑到性能和可用性
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
即时通信 IM
实时音视频
