负载均衡

介绍 该工程主要实现服务的自动注册发现，从而达到提高运维效率，做到服务的自动发现和动态扩展。 服务注册发现 服务启动后自动被发现 动态变更负载均衡 自动伸缩 工具 1.Registrator 这是一个由Go语言编写，针对docker使用的，通过检查本机容器进程在线或者停止运行状态，去注册服务的工具。 它通过docker socket 直接监听容器event，根据容器启动/停止等event来注册/注销服务。 每个容器的每个exposed端口对应不同的服务。 支持可插拔的registry backend，默认支持Consul, etcd and SkyDNS。 2.Consul Consul 是一个分布式高可用的服务发现和配置共享的软件。由 HashiCorp 公司用 Go 语言开发。 3.consul-template consul template可以查询consul中的服务目录、key、key-values等。这种强大的抽象功能和查询语言模板可以使consul template特别适合动态的创建配置文件。例如：创建apache/nginx proxy balancers、haproxy backends、varnish servers、application configurations。 consul-template提供了一个便捷的方式从consul中获取存储的值

正向代理 我们常说的代理指的就是正向代理。正向代理的过程，隐藏了真实的请求客户端，服务端不知道真实的客户端是谁，客户端请求的服务都被代理服务器代替请求，翻墙软件扮演的就是正向代理角色。eg：翻墙软件 反向代理 方向代理隐藏了真实的服务端，例如访问www.baidu.com时，背后可能有成千上万台服务器，但具体是哪一台为我们提供服务，我们并不知道。反向代理服务器会帮我们把请求转发到真实服务器那里去。nginx就是性能非常好的反向代理服务器。 负载均衡 网站的访问量越来越大，服务器的服务模式也得进行相应的升级，比如分离出数据库服务器，分离出图片服务器等，这些是简单的数据负载均衡，将压力分散到不同的机器上。将同一域名的访问分散到两台或多台机器上，是另一种负载均衡。 nginx不单可以作为强大的web服务器，也可以作为一个反向代理服务器，而且nginx还可以按照调度规则实现动态、静态页面的分离，可以按照轮循、ip哈希、url哈希、权重等多种方式对后端服务器做负载均衡，同时还支持后端服务器的健康检查。 nginx的upstream目前支持的四种方式的分配 轮询（默认） 每个请求按时间顺序逐一分配到不同的后端服务器。如果后端服务器down掉，能自动剔除。 weight 指定轮询几率，weight和访问比例成正比，用于后端服务器性能不均的情况 3.ip_hash

Spring Cloud作为Java语言的微服务框架，它依赖于Spring Boot，有快速开发、持续交付和容易部署等特点。Spring Cloud的组件非常多，涉及微服务的方方面面。主要功能有：服务的注册和发现，服务的负载均衡，服务的容错，服务网关，服务配置的统一管理，链路追踪，实时日志等。常用的组件有Spring Cloud Netflix组件下的，服务注册与发现组件 Eureka、网关路由组件Zuul、负载均衡组件Ribbon、声明式调用Feign、熔断器组件Hystrix。 1.Eureka Eureka是一个服务注册与发现组件，Eureka包含两个组件：Eureka Server和Eureka Client，分别为Eureka的注册中心和客户端。底层使用ConcurrentHashMap保存多个实例信息。 2.Zuul Zuul是一个API Gateway服务器，本质上是一个Web Servlet应用。Zuul 提供了动态路由、监控等服务，这些功能实现的核心是一系列的filters（过滤器） 3.Ribbon Ribbon是一个负载均衡组件，它通常和Eureka、Zuul、RestTemplate、Feign配合使用。Ribbon和Zuul配合，很容易做到负载均衡，将请求根据负载均衡策略分配到不同的服务实例中。 4.Feign Feign定义接口，并在接口上添加注解

千万级的注册用户，千万级的帖子，nTB级的附件，还有巨大的日访问量，大型网站采用什么系统架构保证性能和稳定性？ 首先讨论一下大型网站需要注意和考虑的问题。 数据库海量数据处理 ：负载量不大的情况下select、delete和update是响应很迅速的，最多加几个索引就可以搞定，但千万级的注册用户和一个设计不好的多对多关系将带来非常严重的性能问题。另外在高UPDATE的情况下，更新一个聚焦索引的时间基本上是不可忍受的。索引和更新是一对天生的冤家。 高并发死锁 ：平时我们感觉不到，但数据库死锁在高并发的情况下的出现的概率是非常高的。 文件存储的问题 ：大型网站有海量图片数据、视频数据、文件数据等等，他们如何存储并被有效索引？高并发的情况下IO的瓶颈问题会迅速显现。也许用RAID和专用存贮服务器能解决眼下的问题，但是还有个问题就是各地的访问问题，也许我们的服务器在北京，可能在云南或者海南的访问速度如何解决?如果做分布式，那么我们的文件索引以及架构该如何规划。 接下来讨论大型网站的底层系统架构，来有效的解决上述问题。 毋庸置疑，对于规模稍大的网站来说，其背后必然是一个服务器集群来提供网站服务，例如，2004年eBay的服务器有2400台，估计现在更多。当然，数据库也必然要和应用服务分开，有单独的数据库服务器集群。对于像淘宝网这样规模的网站而言，就是应用也分成很多组。 下面

千万级的注册用户，千万级的帖子，nTB级的附件，还有巨大的日访问量，大型网站采用什么系统架构保证性能和稳定性？ 首先讨论一下大型网站需要注意和考虑的问题。 数据库海量数据处理 ：负载量不大的情况下select、delete和update是响应很迅速的，最多加几个索引就可以搞定，但千万级的注册用户和一个设计不好的多对多关系将带来非常严重的性能问题。另外在高UPDATE的情况下，更新一个聚焦索引的时间基本上是不可忍受的。索引和更新是一对天生的冤家。 高并发死锁 ：平时我们感觉不到，但数据库死锁在高并发的情况下的出现的概率是非常高的。 文件存储的问题 ：大型网站有海量图片数据、视频数据、文件数据等等，他们如何存储并被有效索引？高并发的情况下IO的瓶颈问题会迅速显现。也许用RAID和专用存贮服务器能解决眼下的问题，但是还有个问题就是各地的访问问题，也许我们的服务器在北京，可能在云南或者海南的访问速度如何解决?如果做分布式，那么我们的文件索引以及架构该如何规划。 接下来讨论大型网站的底层系统架构，来有效的解决上述问题。 毋庸置疑，对于规模稍大的网站来说，其背后必然是一个服务器集群来提供网站服务，例如，2004年eBay的服务器有2400台，估计现在更多。当然，数据库也必然要和应用服务分开，有单独的数据库服务器集群。对于像淘宝网这样规模的网站而言，就是应用也分成很多组。 下面

千万级的注册用户，千万级的帖子，nTB级的附件，还有巨大的日访问量，大型网站采用什么系统架构保证性能和稳定性？ 首先讨论一下大型网站需要注意和考虑的问题。 数据库海量数据处理 ：负载量不大的情况下select、delete和update是响应很迅速的，最多加几个索引就可以搞定，但千万级的注册用户和一个设计不好的多对多关系将带来非常严重的性能问题。另外在高UPDATE的情况下，更新一个聚焦索引的时间基本上是不可忍受的。索引和更新是一对天生的冤家。 高并发死锁 ：平时我们感觉不到，但数据库死锁在高并发的情况下的出现的概率是非常高的。 文件存储的问题 ：大型网站有海量图片数据、视频数据、文件数据等等，他们如何存储并被有效索引？高并发的情况下IO的瓶颈问题会迅速显现。也许用RAID和专用存贮服务器能解决眼下的问题，但是还有个问题就是各地的访问问题，也许我们的服务器在北京，可能在云南或者海南的访问速度如何解决?如果做分布式，那么我们的文件索引以及架构该如何规划。 接下来讨论大型网站的底层系统架构，来有效的解决上述问题。 毋庸置疑，对于规模稍大的网站来说，其背后必然是一个服务器集群来提供网站服务，例如，2004年eBay的服务器有2400台，估计现在更多。当然，数据库也必然要和应用服务分开，有单独的数据库服务器集群。对于像淘宝网这样规模的网站而言，就是应用也分成很多组。 下面

0x00 基本信息 标题：Nginx高并发负载均衡原理与策略比较研究 来源：工业控制计算机 作者：张炜森,陈涛,李康 时间：2018 0x01 研究背景 Nginx 作为当下的高并发连接的负载均衡服务器因其极强的性能得到广泛的使用。 分析了 Nginx 的工作模型并针对不同的负载均衡策略给出研究，探讨了 Nginx 多进程模型对于提升集群服务器响应能力的重要作用，同时对比了 Nginx 不同的负载均衡策略的性能差距，对实际应用服务器的开发具有重要的意义。 0x02 具体内容 提出了一个以Nginx服务器为核心的后台服务器架构，对如何加速提供服务进行了针对性的优化。 从原理上解释了Nginx为什么性能突出于其他服务器程序以及Nginx对性能优化所做的处理，以及多进程模式的优点： 减少加锁操作，降低加锁粒度。 进程间运行状态独立，互不影响。 单进程编程的开发方式降低了开发的难度 。 详细解释了Nginx服务器负载均衡的策略以及具体实现方式： 轮询 加权轮询 IP Hash算法 一致性Hash算法 响应时间优先分配策略 对不同的算法进行了比较，采用QPS作为衡量标准： 轮询策略在均衡性和容灾性方面表现较好，在一致性方面表现较差，通用性较强，在无需特殊需求的场景下都可以使用。 Fair 策略自适应性较好， 在网络环境多变的情况下表现较好，容灾性强，均衡性一般，一致性较差。 IP

特征 Spring Cloud专注于为典型用例提供良好的开箱即用体验，并为其他用户提供可扩展性机制。 分布式/版本化配置 服务注册和发现 路由 服务到服务电话 负载均衡 断路器 全球锁 分布式消息 1.什么是Spring Cloud？ Spring cloud流应用程序启动器是基于Spring Boot的Spring集成应用程序，提供与外部系统的集成 微服务架构是—种架构模式或者说是一种架构风格,它提倡将单一应用程序划分成-一组小的服务,每个服务运行在其独立的自己的进程中,服务之间互相协调、互相配合,为用户提供最终价值。 2.Spring Cloud优点: 1.每个服务直接足够内聚，代码容易理解 2.开发效率高，一个服务只做一件事，适合小团队开发 3.松耦合，有功能意义的服务。 4.可以用不同语言开发，面向接口编程。 5.易于第三方集成 6.微服务只是业务逻辑的代码，不会和HTML,CSS或其他界面结合. 7.可以灵活搭配，连接公共库/连接独立库 3.Spring Cloud缺点: 1.分布式系统的责任性 2.多服务运维难度加大。 3.系统部署依赖，服务间通信成本，数据一致性，系统集成测试，性能监控。 4.Spring Boot和 Spring Cloud,请你谈谈对他们的理解 ? spring boot 是一个快速整合第三方框架 关注的是 微观 具体关注快速方便的开发单个个体的

本文来自 网易云社区 作者：李弈远 消息推送平台为公司内部和第三方应用提供统一消息推送服务，支持广播、私信、组播、附件等多种消息推送方式，覆盖IOS、Android、PC、Web等多种终端，并根据应用特定需求制定各种解决方案。 平台支持水平扩展，支持C5000K高并发下的实时消息推送，通过动态负载均衡、隔离部署、LXC虚拟化和监控报警等多种机制确保系统 的高可用，通过高可用消息队列、自动重连和ACK等机制实现消息可靠性（QoS1），并提供SDK方便产品和应用接入。 本文将在介绍消息推送服务相关功能/非功能特性的基础上，就系统为实现高可用进行的架构设计及部署方案进行探讨。 一、系统特性 1.1 功能特性 提供服务端SDK和各类终端SDK简化产品接入 对接入的产品服务端和终端进行安全认证 支持跨产品消息推送 支持广播、私信、组播、附件推送等多种消息推送方式 根据自定义条件筛选终端用户进行推送 支持IOS、Android、Web、PC、智能设备等多种终端 针对典型应用场景的各种解决方案 对接入的各产品进行统一配置管理 对推送效果进行统计 系统运行时监控及异常报警 1.2 非功能特性 消息可靠性满足QoS1 各种消息推送方式互不阻塞 具备快速水平扩展能力 系统高可用，无单点故障 异常隔离不扩散 消息推送路径跟踪及快速故障诊断 服务质量实时监测 易运维 支持C5000K高并发

服务器 20.0.0.206 10.0.0.206 bs-hk-hk01 高可用负载均衡节点 2c2g 20.0.0.207 10.0.0.207 bs-hk-hk02 高可用负载均衡节点 2c2g 软件版本 Keepalived 2.0.20 haproxy 2.1.2 Keepalived 安装配置 两个节点都安装 以bs-hk-hk01为例 #安装依赖包 [root@bs-hk-hk01 tools]#yum -y install gcc openssl-devel libnl3-devel pcre-devel [root@bs-hk-hk01 tools]# ls haproxy-2.1.2.tar.gz keepalived-2.0.20.tar.gz [root@bs-hk-hk01 tools]# tar -zvxf keepalived-2.0.20.tar.gz [root@bs-hk-hk01 keepalived-2.0.20]# ./configure --prefix=/usr/local/keepalived-2.0.20 [root@bs-hk-hk01 keepalived-2.0.20]# echo $? 0 [root@bs-hk-hk01 keepalived-2.0.20]# make && make install [root@bs-hk