高可用

对 很多创业公司而言，随着业务的增长，网站的流量也会经历不同的阶段。从十万流量到一百万流量，再从一百万流量跨越到一千万甚至上亿的流量，网站的架构需要 经历哪些变化？我们一起听听 58 同城的技术委员会执行主席沈剑在 OneAPM 技术公开课上的回答（以下演讲整理）： 本场演讲我主要阐述一下，58同城从小流量、中等规模流量、大流量，到更大的流量过程中，架构是怎么演进的？遇到了哪些问题？以及如何解决这些问题？ 好的架构不是设计出来的而是演进出来的 对很多创业公司而言，在初期的时候，我们很难在初期就预估到流量十倍以后、百倍以后、一千倍以后网站的架构会变成什么样。当然，如果在最初的时期，就设计一个千万级并发的流量架构，那样的话，成本是也是非常之高的，估计很难有公司会这样做。 所以，我们主要来讲架构是如何进行演化的。我们在每个阶段，找到对应该阶段网站架构所面临的问题，然后在不断解决这些问题的过程中，整个战略的架构就是在不断的演进了。 其实，在 58 同城建立之初，站点的流量非常小，可能也就是是十万级别，这也就意味着，平均每秒钟也就是几次的访问。此时网站架构的特点：请求量是比较低，数据量比较小，代码量也比较小。可能找几个工程师，很容易就做一个这样的站点，根本没什么「架构」可言。 其实，这也是很多创业公司初期面临的问题，最开始58同城的站点架构用一个词概括就是「ALL IN ONE」，如下图所示

对很多创业公司而言，很难在初期就预估到流量十倍、百倍以及千倍以后网站架构会是什么样的一个状况。同时，如果系统初期就设计一个千万级并发的流量架构，很难有公司可以支撑这个成本。 因此，这里主要会关注架构的眼花。在每个阶段，找到对应该阶段网站架构所面临的问题，然后在不断解决这些问题，在这个过程中整个架构会一直演进。 在58同城建立之初，站点的流量非常小，可能也就是十万级别，这也就意味着，平均每秒钟也就是几次的访问，此时网站架构的特点是：请求量比较低，数据量比较小，代码量也比较小。这个时候的站点可以被几个工程师轻易搞定，因此根本没什么“架构”可言。 其实这也是很多创业公司初期面临的问题，最开始58同城的站点架构用一个词概括就是“ALL IN ONE”，如下图所示： 就像一个单机系统，所有的东西都部署在一台机器上，包括站点、数据库、文件等等。而工程师每天的核心工作就是CURD，前端传过来一些数据，然后业务逻辑层拼装成一些CURD访问数据库，数据库返回数据，数据拼装成页面，最终返回到浏览器。相信很多创业团队初期都面临一个与之类似的情况，每天写代码，写SQL、接口参数、访问数据等等。 这里需要说明一个问题，大家都知道最初58同城使用的是Windows、iis、SQL-Sever、C#这条路。现在很多创业公司可能就不会这么做。 如果可以重来？那么会选择LAMP 很多创业的同学可能会想

airflow 安装配置 airflow 相关软件安装 python 3.6.5 安装 安装依赖程序 ； [root@node01 ~]# yum -y install zlib zlib-devel bzip2 bzip2-devel ncurses ncurses-devel readline readline-devel openssl openssl-devel openssl-static xz lzma xz-devel sqlite sqlite-devel gdbm gdbm-devel tk tk-devel gcc 下载python ； 可以前往 https://www.python.org/ftp/python/查看Python各个版本，这里，我们选择安装Python-3.6.5.tgz版本。通过如下命令下载Python源码压缩包 ： [root@node01 ~]# wget https://www.python.org/ftp/python/3.6.5/Python-3.6.5.tgz 解压Python源码压缩包 ； [root@node01 ~]# tar -zxvf Python-3.6.5.tgz [root@node01 ~]# cd Python-3.6.5 安装python ； [root@node01 Python-3.6.5]# .

在微服务架构这样的分布式环境中，我们需要充分考虑发生故障的情况， 所以在生产 环境中必须对各个组件进行高可用部署， 对于微服务如此， 对于服务注册中心也一样。 但 是到本节为止，我们一直都在使用单节点的服务注册中心，这在生产环境中显然并不合适， 我们需要构建高可用的服务注册中心以增强系统的可用性。 Eureka Server的设计一开始就考虑了高可用问题， 在Eureka的服务治理设计中， 所有 节点即是服务提供方， 也是服务消费方， 服务注册中心也不例外。 是否还记得在单节点的 配置中，我们设置过下面这两个参数， 让服务注册中心不注册自己： eureka.client.register-with-eureka=false eureka.client.fetch-registry=false Eureka Server的高可用实际上就是将自己作为服务向其他服务注册中心注册自己，这 样就可以形成一组互相注册的服务注册中心， 以实现服务清单的互相同步， 达到高可用的 效果。 下面我们就来尝试搭建高可用服务注册中心的集群。 目录结构 在etc/hosts文件中添加对peerl和peer2的转换， 让上面配置的host形式的 serviceUrl能在本地正确访间到； Windows系统路径为C:\Windows\System32\ drivers\etc\hosts。 127.0.0.1

第四章：服务注册中心 Eureka 4-1. Eureka 注册中心高可用集群概述 在微服务架构的这种分布式系统中，我们要充分考虑各个微服务组件的高可用性 问题，不能有单点故障，由于注册中心 eureka 本身也是一个服务，如果它只有 一个节点，那么它有可能发生故障，这样我们就不能注册与查询服务了，所以我 们需要一个高可用的服务注册中心，这就需要通过注册中心集群来解决。 eureka 服务注册中心它本身也是一个服务，它也可以看做是一个提供者，又可 以看做是一个消费者，我们之前通过配置： eureka.client.register-with-eureka=false 让注册中心不注册自己，但是我们 可以向其他注册中心注册自己； Eureka Server 的高可用实际上就是将自己作为服务向其他服务注册中心注册 自己，这样就会形成一组互相注册的服务注册中心，进而实现服务清单的互相同 步，往注册中心 A 上注册的服务，可以被复制同步到注册中心 B 上，所以从任 何一台注册中心上都能查询到已经注册的服务，从而达到高可用的效果。 4-2. Eureka 注册中心高可用集群搭建 我们知道，Eureka 注册中心高可用集群就是各个注册中心相互注册，所以：(可以在新建一个项目作为注册中心，但是这里为了方便，采用多环境配置方法启动两个Eureka注册中心) 1.在 8761 的配置文件中，让它的

TiDB 是 PingCAP 公司研发的开源分布式关系型数据库，结合了传统的 RDBMS 和 NoSQL 的最佳特性。TiDB 兼容 MySQL，具备「分布式强一致性事务、在线弹性水平扩展、故障自恢复的高可用、跨数据中心多活」等核心特性，是大数据时代理想的数据库集群和云数据库解决方案。 UCloud 于今年 8 月 将 TiDB 公有云化并推出 UCloud TiDB Service，当前使用的 TiDB 版本为 3.0.5 。UCloud TiDB Service 相比裸机部署性能并无损耗，提供跨可用区高可用，对监控和 Binlog 等做了改造增强，使用户可获得一键创建、按需付费、灵活扩缩容的 TiDB 服务。 UCloud TiDB Service 为什么叫 UCloud TiDB Service？这里强调 Service 是因为从公有云用户的角度来看，TiDB 运行在公有云平台上，其实是以服务的形式呈现而不是一个物理资源。 UCloud TiDB Service 是一个支持原生 MySQL 协议的，高性能、跨可用区高可用、高可扩展的，面向 Serverless 的分布式数据库服务。 兼容原生 MySQL 协议 大多数情况下，无需修改代码即可从 MySQL 轻松迁移至 TiDB，分库分表后的 MySQL 集群亦可通过 TiDB 工具进行实时迁移。 跨可用区高可用 TiDB

1.1 什么是负载均衡高可用 nginx作为负载均衡器，所有请求都到了nginx，可见nginx处于非常重点的位置，如果nginx服务器宕机后端web服务将无法提供服务，影响严重。 为了屏蔽负载均衡服务器的宕机，需要建立一个备份机。主服务器和备份机上都运行高可用（High Availability）监控程序，通过传送诸如“I am alive”这样的信息来监控对方的运行状况。当备份机不能在一定的时间内收到这样的信息时，它就接管主服务器的服务IP并继续提供负载均衡服务；当备份管理器又从主管理器收到“I am alive”这样的信息时，它就释放服务IP地址，这样的主服务器就开始再次提供负载均衡服务。 1.2 keepalived+nginx实现主备 1.2.1 什么是keepalived keepalived是集群管理中保证集群高可用的一个服务软件，用来防止单点故障。 Keepalived的作用是检测web服务器的状态，如果有一台web服务器死机，或工作出现故障，Keepalived将检测到，并将有故障的web服务器从系统中剔除，当web服务器工作正常后Keepalived自动将web服务器加入到服务器群中，这些工作全部自动完成，不需要人工干涉，需要人工做的只是修复故障的web服务器。 1.2.2 keepalived工作原理 keepalived是以VRRP协议为实现基础的

1. Nginx负载均衡高可用 　　首先介绍一下Keepalived，它是一个高性能的服务器高可用或热备解决方案，Keepalived主要来防止服务器单点故障的发生问题，可以通过其与Nginx的配合实现web服务端的高可用。 Keepalived以VRRP协议为实现基础，用VRRP协议来实现高可用性（HA）.VRRP (Virtual Router Redundancy Protocol)协议是用于实现路由器冗余的协议，VRRP协议将两台或多台路由器设备虚拟成一个设备，对外提供虚拟路由器IP（一个或多个），如下图所示： 这张图的意思是，我们使用keepalived来管理两台设备的Nginx，并虚拟出一个IP，我们现在两台装有Nginx的设备分别是192.168.101.3和192.168.101.4，那么我们可以虚拟出一个192.168.156.xx的IP，外界请求直接访问虚拟IP而不是真正的Nginx，让虚拟IP去访问提供服务的Nginx（注意：高可用是指同一时间提供服务的只有一台设备，提供服务的设备挂掉之后，备份服务器便开始提供服务），然后再由Nginx去访问tomcat。 要实现nginx的高可用，需要实现 备份机 。 我们拿两台虚拟机来搭建nginx高可用环境，这两台设备分别是192.168.101.3（主机名是nginx1）和192.168.101.4

1. Nginx负载均衡高可用 首先介绍一下Keepalived，它是一个高性能的服务器高可用或热备解决方案，Keepalived主要来防止服务器单点故障的发生问题，可以通过其与Nginx的配合实现web服务端的高可用。 Keepalived以VRRP协议为实现基础，用VRRP协议来实现高可用性（HA）.VRRP (Virtual Router Redundancy Protocol)协议是用于实现路由器冗余的协议，VRRP协议将两台或多台路由器设备虚拟成一个设备，对外提供虚拟路由器IP（一个或多个），如下图所示： 这张图的意思是，我们使用keepalived来管理两台设备的Nginx，并虚拟出一个IP，我们现在两台装有Nginx的设备分别是192.168.101.3和192.168.101.4，那么我们可以虚拟出一个192.168.156.xx的IP，外界请求直接访问虚拟IP而不是真正的Nginx，让虚拟IP去访问提供服务的Nginx（注意：高可用是指同一时间提供服务的只有一台设备，提供服务的设备挂掉之后，备份服务器便开始提供服务），然后再由Nginx去访问tomcat。 要实现nginx的高可用，需要实现备份机。 我们拿两台虚拟机来搭建nginx高可用环境，这两台设备分别是192.168.101.3（主机名是nginx1）和192.168.101.4（主机名是nginx2）。

HA高可用配置 一、简述 ------------------- high availability,高可用. 两个名称节点，一个active(激活态)，一个是standby(slave待命),slave节点维护足够多状态以便于容灾。 和客户端交互的active节点,standby不交互. 两个节点都和JN守护进程构成组的进行通信。 数据节点配置两个名称节点，分别报告各自的信息。 同一时刻只能有一个激活态名称节点。 脑裂:两个节点都是激活态。 为防止脑裂，JNs只允许同一时刻只有一个节点向其写数据。容灾发生时，成为active节点的namenode接管 向jn的写入工作。 二、硬件资源 -------------- 名称节点: 硬件配置相同。 JN节点 : 轻量级进程，至少3个节点,允许挂掉的节点数 (n - 1) / 2. 不需要再运行辅助名称节点。 三、配置细节 --------------- 0.centos001和centos006具有完全一致的配置，尤其是.ssh（免密登陆） 1.配置nameservice [hdfs-site.xml] <property> <name>dfs.nameservices</name> <value>mycluster</value> </property> 2.dfs.ha.namenodes.[nameservice ID]