k8s(二)

​ 其实本章原来名为k8s，后来感觉云的概念/应用太多了，远远不止一个k8s，所以就以云为开始

技术名词概念

VNC与noVNC

VNC (Virtual Network Console)是虚拟网络控制台的缩写，分为server端和client端两部分，分别部署完成后在server端简单的配置即可使用，基于TCP的通信。noVNC项目是通过取消VNC Client的安装，直接通过浏览器访问noVNC，然后由noVNC间接访问VNC server来达到client web化。从上面部署方式看到，VNC server仍然保留且没有任何修改，处理的始终是TCP流量，但是浏览器和noVNC之间是在http基础上使用WebSocket交互，由于VNC server 无法处理websocket流量，因此引入了 websockify ，noVNC的姐妹项目，负责把WebSocket流量转换为普通的TCP流，使VNC server正常工作。noVNC其实是一个HTML形式的APP，websockify并充当了一个mini web server的角色，当浏览器访问时，会通过网络加载运行noVNC。

noVNC 作为一个高性能，开源的项目，被集成到众多公司，项目的控制面板功能当中，例如VMware 的VM console, PVE 等，当然你也可以集成到任何个人的web项目中，来增加基于web的远程控制的功能。

安装vnc server

vncserver是用来实现远程桌面连接的，比如说你由两台机器PC1：192.168.1.101和PC2：192.168.1.102，如果你想在PC1上访问PC2的桌面，就需要在PC2上安装vncserver，然后在PC1上通过vncviewer或noVNC访问PC2。下面以tigervnc-server为例来介绍一下vncserver的安装和使用。

安装

yum -y install tigervnc-server

安装完后，查看vncserver的配置文件：

[root@mycentos liushaolin]# rpm -qc tigervnc-server
/etc/sysconfig/vncservers

启动vnc server

vncserver
或
vncserver :n

这里的n就是sessionnumber，不指定的话默认为1，第一次启动时会提示输入密码，以后也可以使用vncpasswd命令修改密码。VNC的默认端口号是5900，而远程桌面连接端口号则是5900+n。如果使用“vncserver :1”命令启动VNC Server，那么端口应该是5901。

vncserver -list[root@mycentos liushaolin]# vncserver -list

TigerVNC server sessions:

X DISPLAY #	PROCESS ID
:1		5918
:3		7726

安装noVNC

$git clone https://github.com/kanaka/noVNC
$cd noVNC
$./utils/launch.sh --vnc localhost:5901

启动launch脚本，会输出如下信息：

WebSocket server settings:
  - Listen on :6080
  - Flash security policy server
  - Web server. Web root: /root/noVNC
  - No SSL/TLS support (no cert file)
  - proxying from :6080 to localhost:5901


Navigate to this URL:

    http://localhost:6080/vnc.html?host=localhost&port=6080

这时，访问http://localhost:6080/vnc.html?host=localhost&port=6080或http://localhost:6080/vnc.html，然后输入Host地址，端口号，密码，token，其中密码和token有的话需要输入，然后连接即可。当然你可以从PC1的浏览器中输入PC2的IP地址访问。

https://vosamo.github.io/2016/07/noVNC%E7%9A%84%E4%BD%BF%E7%94%A8%E4%B9%8B%E4%B8%80/

https://github.com/novnc/noVNC

VPC

Vagrant

Vagrant 是一个对虚拟环境管理的工具，必须借助virtualbox／vm 才能使用。vagrant 英译流浪汉，可以方便的把某个虚拟开发环境搬运到另外一台机器中

假设已经用virtualbox建了一个开发环境。比如LAMP。现在想要在另外一台机器上重新建立一个一模一样的开发环境

初始化vagrant

vagrant init

生成Vagrantfile，Vagrantfile是一个配置文件，可以配置登录虚拟机方式password／ssh，虚拟机ip，将要执行的容器文件box等信息

把当前实例化了的虚拟环境导出成box-name.box, 这个box可能有几十G，这是已经压缩过的容器盒子，手动压缩也差不多大小

导出之后Vagrantfile将会有配置config.vm.box = "box-name"

vagrant package --output box-name.box

开发人员拷贝box及Vagrantfile到本地，本地需要已经安装vm，在Vagrantfile所在目录下运行vagrant up即可在本地生成刚才的虚拟机环境。需要等待几分钟

vagrant up

登陆虚拟机

vagrant ssh

## 重启虚拟机
vagrant reload

## 关闭虚拟机，并退出
vagrant halt

## 销毁虚拟机实例，实例化的虚拟环境占内存很大，经常不用可以销毁。
vagrant destory

如果本地有多个box，修改Vagrantfile中绑定的box，vagrant up 可以随时进入另外一个虚拟机环境，比如LNMP

vagrant box add box_name path-to-box

从公有的仓库中直接拉取box，然后启动环境。比如把ubuntu14.04拉取到本地。 修改Vagrantfile

Vagrant.configure("2") do |config|
  config.vm.box = "ubuntu/trusty64"
end

与docker的区别

简单来说，Docker比Vagrant强大很多，docker包含vagrant的功能，docker也可以做容器实例导出的工作，但是docker可以导出镜像文件到本地，通过镜像文件生成虚拟容器实例。镜像文件可能也就几十兆，Docker更加轻量级，Docker不依赖vm。把线上环境安装在vm里面是不现实的。docker参数多，更加灵活，在线上部署服务器集群也是很方便的。 比如docker 启动一个ubuntu18的镜像。

vagrant简单易上手，命令简单，也非常适用于小团队内部开发。但是依赖vm，vagrant 打包镜像文件一般必须包含系统镜像，否则难迁移运行。打包文件比较大

https://developer.hashicorp.com/vagrant/tutorials/getting-started/getting-started-index

隔离技术与故障域

故障域指的是当一个区域出现故障以后，它的受影响范围。例如在设计双活数据中心的时候，我们要设置故障域，那个故障域是A站点，哪个是B站点。A站点出现断电，受影响的最大范围只限于本站点，那么A站点就是一个故障域。当然，硬件层面的故障域还可以分得更细：比如一个数据中心内部，不同楼层是不同的故障域；同一个楼层，不同的机架也是不同的故障域。在故障域这个问题上，关键是看故障的类型如何定义

而隔离技术就是限制故障域的。当然，应用级别的隔离术比硬件的隔离更为细致。其中包括

1.线程隔离

线程隔离主要指的是线程池隔离。根据前端的请求不同，把需求转发到不同的线程池中。

2.进程隔离

我们知道，交易和论坛都是电商系统很重要的两部分。在以前，一个电商系统如果不被拆分的情况下，交易请求和论坛请求都会访问同一个应用（一个或多个实例）。当系统拆分以后，论坛系统和交易系统是不同的应用，这样不仅做到了进程隔离，也提高了整体性能

3.集群隔离

集群隔离指的是，当电商系统某一个功能模块，单实例应用无法满足需求的时候，需要部署多个服务形成服务集群。

4.机房隔离

机房隔离是为了满足应用高可用的要求。每个机房的前端，可以通过DNS/负载均衡进行分流。或者在客户端的请求中，指明机房的分组标签。机房隔离是比较传统的隔离技术。

5.读写隔离

读写隔离又称读写分离。读写分为通常指的是数据库，如传统的RDBMS：Oracle DB、MySQL/Maria DB，以及缓存如：redis（key-value）、memcached（key-value）等。读写分离除了可以提高性能，还有一个好处是，当主集群出现问题的时候，如果没法写入数据，但用户客户从备集群读取数据。

6.动静隔离

大家都有网购的经历。网购的页面，有的是静态页面，有的是动态页面。例如：服装的图片是静态的，而附件界面是动态的。为了保证性能，电商通常将动态内容与静态资源分离，而一般静态资源放在CDN上

7.爬虫隔离

网络爬虫，大家可以理解为在网络上爬行的一直蜘蛛，互联网就比作一张大网，而爬虫便是在这张网上爬来爬去的蜘蛛咯，如果它遇到资源，那么它就会抓取下来。比如它在抓取一个网页，在这个网中他发现了一条道路，其实就是指向网页的超链接，那么它就可以爬到另一张网上来获取数据。这样，整个连在一起的大网对这之蜘蛛来说触手可及.

在用户浏览网页的过程中，我们可能会看到许多好看的图片，我们会看到几张的图片以及百度搜索框，这个过程其实就是用户输入网址之后，经过 DNS 服务器，找到服务器主机，向服务器发出一个请求，服务器经过解析之后，发送给用户的浏览器 HTML、JS、CSS 等文件，浏览器解析出来，用户便可以看到形形色色的图片了.

根据统计，很多网站的流程和正常流量访问比率可高达5:1，这种情况下，可以将爬虫路由到单独的集群

8.热点隔离

抢购、秒杀、开门红等业务，都属于热点。对于这种系统，应该造成独立的系统进行隔离，底层使用配置较高的硬件服务器、更好的网络带宽，并且加入多级缓存。

9.资源隔离

资源隔离是比较好理解发的。如CPU、内存、IO的隔离。这同样属于传统硬件隔离范畴。基本原则是，按照业务特点，业务区域。如CPU密集型的应用，底层服务器多配置主频高的处理器，大内存访问的应用，配置内存高的服务器。另外，对于到多数I/O访问量高的应用，通常使用SSD磁盘

以一个电商的架构为例

从最外端的Web UI开始，这是一个用node.js写的微服务。用于对外提供访问，接受用户的请求。接下来是CoolStore的GW,其实就是这套微服务的API Gateway，Spring boot书写。指向到CoolStore的GW的Hystrix和Turbine负责微服务的熔断。

接下来的六个微服务，从左右往右：Rating Service、Review Service、Inventory Service、Catelog Service、Cart Service、Pricing Service。则是我们网购的时候，调用后端的微服务。其实也就是网购具体的应用。

• Catelog Service，也就是目录服务 - JBoss 的Java应用程序，为零售产品提供产品和价格.
• Cart Service,也就是购物车服务 - 在每个客户管理购物车的JDK上运行的Spring Boot应用程序
• Inventory Service，也就是库存服务 - 在JBoss EAP 7和PostgreSQL上运行的Java EE应用程序，为零售产品提供库存和可用性数据
• Pricing Service，也就是定价服务 - JBoss BRMS产品定价业务规则应用
• Review Service，也就是审查服务 - 在JDK上运行的WildFly Swarm服务，用于撰写和显示产品评论
• Rating Service，也就是评级服务 - 在JDK上运行的Vert.x服务用于评级产品
• Coolstore API网关 - 在JDK上运行的Spring Boot + Camel应用程序作为后端服务的API网关。
• Web UI - 在Node.js容器中运行的基于AngularJS和PatternFly的前端。也就是客户访问电商的界面展示。

Rating Service、Review Service、Inventory Service、Catelog Service这四个微服务，都有自己的数据库。这其实正是符合微服务的share as little as possible原则。即说微服务应该尽量设计成边界清晰不重叠，数据独享不共享。实现所谓的“高内聚、低耦合”。这样有助于实现独立可部署

在这个案例中，前文提到的：线程隔离、进程隔离、集群隔离、读写隔离、爬虫隔离、机房隔离、热点隔离、资源隔离都已经可以实现。而动静隔离只要前面增加CDN即可。

线程隔离：客户端发起不同的请求，CoolStore的网关根据请求的类型，查分发送到不同的微服务。如有的用户是浏览购物记录，有的是查价格，有的看评论等等。

进程隔离：各个后台微服务之间，就是进程隔离。

集群隔离：每个后台的微服务都是一个service，每个service都可以有多个Pod，也就是多个应用实例，组成应用集群。

读写隔离：将微服务后端的数据库按照读写分离的方式部署到容器中即可。

爬虫隔离：可以将其作为微服务进行部署。

机房隔离：PaaS架构搭建的时候，可以跨机房。对不同机房的物理服务器打label即可。这样部署容器的时候，就可以将一个应用不同的容器实例跨机房。

热点隔离：电商里，web-ui、评论等容易出现热点的微服务，可以通过打标签的方式，部署到配置高的服务器上。

资源隔离：与机房隔离类似，通过对服务器打标签，在部署微服务的时候，可以将不同的服务部署到不同的物理服务器上，实现资源隔离。

所以说，微服务很适合互联网架构，而容器很适合微服务。在容器化的微服务中，API网关是个很重要的角色。在微服务中，API网关很多时候需要引入hystrix这个熔断器。

容灾与容错

容灾：是指系统冗余部署，当一处由于意外停止工作，整个系统应用还可以正常工作。

容错：是指在运行中出现错误（如上下游故障或概率性失败）仍可正常提供服务。

可用性：描述的是系统可提供服务的时间长短。用公式来说就是A=MTBF/(MTBF+MTTR)，即正常工作时间/(正常工作时间+故障时间)。

可靠性：描述的是系统指定时间单位内无故障的次数。比如：一年365天，以天为单位来衡量。有天发生了故障，哪怕只有1秒，这天算不可靠。其他没有故障的是可靠的。

稳定性：这个业界没有明确的定义，我的理解是：在受到各种干扰时仍然能够提供符合预期的服务的能力。

从要求的严格程度上：可用性<可靠性<稳定性。

可用性和可靠性更侧重于容灾，而对稳定性同时包含容灾和容错。

服务容错的难点在于存在未知和不可预测。所以对服务容错要处理两个问题：发现和解决。

服务发现

假设我们写的代码会调用 REST API 或者 Thrift API 的服务。为了完成一次请求，代码需要知道服务实例的网络位置（IP 地址和端口）。

运行在物理硬件上的传统应用中，服务实例的网络位置是相对固定的，代码能从一个偶尔更新的配置文件中读取网络位置。

对于基于云端的、现代化的微服务应用而言，这却是一大难题。将容器应用部署到集群时，其服务地址是由集群系统动态分配的。那么，当我们需要访问这个服务时，如何确定它的地址呢？这时就需要服务发现（Service Discovery）了

服务分服务提供者（Service Provider）和服务消费者（Service Consumer），如果要提供海量服务能力，单一的服务实例显然是不够的，如果要提供成千上万种服务，则需要有一个地方记录服务名到服务实例列表的映射，所以，有必要引入一个新的角色：服务中介，服务中介维护一个服务注册表（Service Registry），可以把注册表理解为服务字典，key是服务名，value是服务提供实例列表；服务注册表是联系服务提供者和服务消费者的桥梁，它维护服务提供者的最新网络位置等信息，也是服务发现最核心的部分。

服务发现有两大模式：客户端发现模式和服务端发现模式。

客户端发现模式

使用客户端发现模式时，客户端决定相应服务实例的网络位置，并且对请求实现负载均衡。客户端查询服务注册表，后者是一个可用服务实例的数据库；然后使用负载均衡算法从中选择一个实例，并发出请求。

服务实例的网络位置在启动时被记录到服务注册表，等实例终止时被删除。服务实例的注册信息通常使用心跳机制来定期刷新。

客户端发现模式优缺点兼有。

• 这一模式相对直接，除了服务注册外，其它部分无需变动。此外，由于客户端知晓可用的服务实例，能针对特定应用实现智能负载均衡，比如使用哈希一致性。
• 这种模式的一大缺点就是客户端与服务注册绑定，要针对服务端用到的每个编程语言和框架，实现客户端的服务发现逻辑。

服务端发现模式

客户端通过负载均衡器向某个服务提出请求，负载均衡器查询服务注册表，并将请求转发到可用的服务实例。

Kubernetes 和 Marathon 这样的部署环境会在每个集群上运行一个代理，将代理用作服务端发现的负载均衡器。客户端使用主机 IP 地址和分配的端口通过代理将请求路由出去，向服务发送请求。代理将请求透明地转发到集群中可用的服务实例。

服务端发现模式兼具优缺点。

• 它最大的优点是客户端无需关注发现的细节，只需要简单地向负载均衡器发送请求，这减少了编程语言框架需要完成的发现逻辑。并且如上文所述，某些部署环境免费提供这一功能。
• 这种模式也有缺点。除非负载均衡器由部署环境提供，否则会成为一个需要配置和管理的高可用系统组件。

对比客户端发现模式，使用服务端发现模式的客户端本地不保存服务实例列表，客户端不做负载均衡，这个负载均衡器既承担了服务发现的角色，又承担了网关的角色，所以经常叫API网关服务器。

因为负载均衡器是中心式的，所以它也必须是一个集群，单个实例不足以支撑高并发访问，针对负载均衡器本身的服务发现和负载均衡通常借助DNS。

Http服务器，Nginx、Nginx Plus就是此类服务端发现模式的负载均衡器。

优点

• 服务发现对于服务消费者是透明的，服务消费者与注册表解耦，服务发现功能的更新对客户端无感知。
• 服务消费者只需要向负载均衡器发送请求，不需要为每种服务消费者的编程语言和框架，开发服务发现逻辑SDK。

缺点

• 由于所有请求都要经负载均衡器转发，所以负载均衡器有可能成为新的性能瓶颈。
• 负载均衡器（服务网关）是中心式的，而中心式的架构会有稳定性的隐忧。
• 因为负载均衡器转发请求，所以RT会比客户端直连模式高。

LUN

LUN 的全称是 Logical Unit Number，也就是逻辑单元号。我们知道 SCSI 总线上可挂接的设备数量是有限的，一般为 6 个或者 15 个，我们可以用 Target ID (也有称为 SCSI ID 的) 来描述这些设备，设备只要一加入系统，就有一个 ID，我们在区别设备的时候，只要说几号几号 ID 就 ok 了。

而实际上我们需要用来描述的对象，是远远超过 16，于是我们引进了 LUN 的概念，也就是说 LUN ID 的作用就是扩充了 Target ID。

每个 Target 下都可以有多个 LUN Device，我们通常简称 LUN Device 为 LUN，这样设备的描述由 Target x 变成 Target x LUN y，显而易见的，我们可以描述更多的设备了。

LUN ID 不等于某个设备，只是个号码而已，不代表任何实体属性，在我们的实际环境里，我们碰到的 LUN 可能是磁盘空间，可能是磁带机，或者是 media changer 等等

LUN 的神秘之处在于，它很多时候不是什么可见的实体，而是一些虚拟的对象。

比如一个阵列柜，主机那边看作是一个 Target Device。

为了某些特殊需要，我们要将 磁盘阵列柜的磁盘空间划分成若干个小的单元，于是就产生了比 Target Device 级别更低的逻辑对象（逻辑驱动器），习惯称之为 LUN0、LUN1、LUN2…。

而操作系统的机制使然，操作系统识别的最小存储对象级别就是 LUN Device，这是一个逻辑对象，所以很多时候被称为 Logical Device。

有人说，我的 Windows 里，就认到一个磁盘呀，没看到什么 LUN 的说法，是不是 LUN=Physical Disk 呢？回答是否定的，只要你注意，磁盘的属性里就可以看到有一个 LUN 的值，只是因为你的 Disk 没有被划分为多个存储资源对象，而将整个磁盘当作 一个 LUN 来用，LUN ID 默认为零，如此而已。

还要说明的地方是，在有些厂商和有些产品的概念里，LUN ID 被绑定到了具体的 Device 上，比如 IBM 的一些带库，整个带库只有一个 Target ID，然后 changer,tape drive 被分别分配为 LUN0、LUN1、LUN2…，但是我们要注意到，这只是产品做了特别设计，也是少数情况

©著作权归作者所有：来自51CTO博客作者bandaoyu的原创作品，请联系作者获取转载授权，否则将追究法律责任 【存储】存储基本概念（lun,volume,HBA,DAS,NAS,SAN,iSCSI,IPSAN、存储池和存储卷)LUN （Target ID不够用，用LUN扩充） https://blog.51cto.com/liangchaoxi/5618103

Volume

LUN 是对存储设备而言的，volume 是对主机而言的。

 选择存储设备上的多个硬盘形成一个 RAID 组，再在 RAID 组的基础上创建一个或多个 LUN（一般创建一个 LUN）。许多厂商的存储设备只支持一个 RAID 组上创一个 LUN。此时 LUN 相对于存储设备是一个逻辑设备。当网络中的主机连接到存储设备时，就可以识别到存储设备上逻辑设备 LUN，此时 LUN 相对于主机来讲就是一个 “物理硬盘”，与 C 盘 D 盘所在 IDC 或 SCSI 硬盘的性属是相同的。在该 “物理硬盘” 上创建一个或多个分区，再创建文件系统，才可以得到一个 VOLUME。

此时 VOLUME 相对于主机是一个逻辑设备。

从容量大小方面比较 VOLUME，分区、LUN、RAID 的关系如下：

VOLUME = 分区 ≤ 主机设备管理器中的磁盘 = LUN ≤ RAID ≤ 存储设备中硬盘的总容量。

上述只是针对一般情况，VOLUME 也只是针对主机来讲。个别厂商对 LUN 和 VOLUME 定义与普通厂商的定义不同，甚至会起一些奇怪的名称，这些名称即使是存储行业的资深人士也不一定全明白。不过只要你能分清楚其实质就行

HBA(总线适配器)

ISCSI

iSCSI 是由 IBM 发明的基于以太网的存储协议，该协议与 SUN 的 NFS 协议都是为了解决存储资源共享问题的解决方案。两者意图一致，只不过两者是不同的实现方式，前者在客户机上呈现的是一个块设备，而后者则是一个目录树

概括的说，iSCSI 是一种存储设备远程映射技术，它可以将一个远程服务器上的存储设备映射到本地，并呈现为一个块设备（大白话就是磁盘）。从普通用户的角度，映射过来的磁盘与本地安装的磁盘毫无差异

这种映射方式基于是基于 SCSI 协议的，SCSI 协议是计算机与外围设备（例如硬盘、光盘等）通信的协议。而 iSCSI 则是通过 TCP 协议对 SCSI 进行封装的一种协议，也就是通过以太网传输 SCSI 协议的内容

iSCSI 其实也是一种典型的客户端服务器架构（CS 架构），其中访问存储系统的计算机成为客户端，其中负责连接的软件成为启动器。而提供存储服务的计算机成为服务端，其中的软件成为目标器。

由于 iSCSI 是基于 TCP 协议的，因此启动器和目标器可以是纯软件实现，也可以基于硬件实现。如果是硬件实现，硬件实现主要是对 SCSI 命令封装和解析等，这样可以释放 CPU 资源。目前在 Linux 下面，启动器和目标器都有纯软件的实现，比如启动器的实现 Open-iSCSI，目标器的实现 LIO、SCST 和 TGT 等

双活数据中心

主备数据中心之间一般有热备、冷备、双活三种备份方式。

热备

热备的情况下，只有主数据中心承担用户的业务，此时备数据中心对主数据中心进行实时的备份，当主数据中心挂掉以后，备数据中心可以自动接管主数据中心的业务，用户的业务不会中断，所以也感觉不到数据中心的切换。

冷备

冷备的情况下，也是只有主数据中心承担业务，但是备用数据中心不会对主数据中心进行实时备份，这时可能是周期性的进行备份或者干脆不进行备份，如果主数据中心挂掉了，用户的业务就会中断。

双活

双活是觉得备用数据中心只做备份太浪费了，所以让主备两个数据中心都同时承担用户的业务，此时，主备两个数据中心互为备份，并且进行实时备份。一般来说，主数据中心的负载可能会多一些，比如分担 60~70% 的业务，备数据中心只分担 40%~30% 的业务。

A—P

AP 双活通过将业务分类，部分业务以数据中心 A 为主，数据中心 B 为热备，而部分业务则以数据中心 B 为主，数据中心 B 为热备，以达到近似双活的效果。

A—A

AA 双活则是真正的双活，同一个双活 LUN 的所有 I/O 路径均可同时访问，业务负载均衡，故障时可无缝切换。

双数据中心同时对外提供业务生产服务的双活模式，两个数据中心是对等的、不分主从、并可同时部署业务，可极大的提高资源的利用率和系统的工作效率、性能，让客户从容灾系统中获得最大的价值。

a. 两个生产中心部署相同的业务系统，结合网络层、主机层或应用的负载均衡技术，实现业务系统在两个数据中心并行工作和负载分担。

b. 两个生产中心部署不同的业务系统，互相实时灾备接管。

数据中心双活又分为：同城双活、异地双活。

传统主备模式的缺点

出于灾备（Disaster Recovery）的目的，一般都会建设 2 个（或多个）数据中心。一个是主数据中心用于承担用户的业务，一个是备份数据中心用于备份主数据中心的数据、配置、业务等。

主备数据中心之间一般有热备、冷备、双活三种备份方式。

● 热备的情况下，只有主数据中心承担用户的业务，此时备数据中心对主数据中心进行实时的备份，当主数据中心挂掉以后，备数据中心可以自动接管主数据中心的业务，用户的业务不会中断，所以也感觉不到数据中心的切换。

● 冷备的情况下，也是只有主数据中心承担业务，但是备用数据中心不会对主数据中心进行实时备份，这时可能是周期性的进行备份或者干脆不进行备份，如果主数据中心挂掉了，用户的业务就会中断。

● 双活是觉得备用数据中心只做备份太浪费了，所以让主备两个数据中心都同时承担用户的业务，此时，主备两个数据中心互为备份，并且进行实时备份。一般来说，主数据中心的负载可能会多一些，比如分担 6070% 的业务，备数据中心只分担 40%30% 的业务。

传统主备模式是一个业务只在一个数据中心运行，企业结合灾备等级需求和业务需求，在备份中心部署了大量的备份服务器，但备份中心仅为该业务提供灾备服务，只有当灾难发生、生产数据中心瘫痪时，灾备中心的业务系统才启动这些服务器，造成备份中心服务器资源浪费，广域网链路也无法得到充分的利用。

双活数据中心优点

充分利用资源，避免了一个数据中心常年处于闲置状态而造成浪费。通过资源整合，“双活” 数据中心的服务能力是双倍的。

双活数据中心如果断了一个数据中心，另外一个数据中心还在运行，对用户来说是不可感知的。

而一个灾备中心的模式，如果生产数据中心瘫痪，需要半个小时、甚至两个小时、甚至更长时间才能启动灾备中心，在启动灾备中心的时间里，用户交易会严重受损。

双活数据中心的最大优势是有效利用资源。灾备中心建设的投资巨大及每年运维成本极高，如果资源处于闲置状态，资源是相当浪费的，有了虚拟化，能够把闲置的资源整合，服务能力会提高一倍。银行系统中很多资源都是弹性需求，如基金、贵金属交易、电子支付、和网银交易，在交易火爆时一天交易量可能达到全年交易量总和。故银行系统容量规划时是充分考虑到交易峰值的，但这样在正常时间就有很大的交易浪费，以淘宝 “双十一” 活动为例，交易量在几分钟内就可能达到全年交易量的总和，需要系统服务能力提高十倍，这时双活数据中心和灵活快速的资源调度就充分发挥出了作用。云计算技术，让 IT 系统有了资源整合的能力，让系统有了充分的弹性，随时可以调度十台机器来提高服务能力，来保证交易的突发需求，以及各种突发因素造成的交易量猛增。

有了云计算技术，不代表投入会更少，但是资源利用率会更高，系统但抗冲击能力会更强，自由调度能力会更强。

自动化是 “双活” 与 “云计算” 必不可少的前提条件

云计算需要自动化手段来帮助系统维护人员进行自动的资源调配。比如，通过虚拟化技术虚拟出了上万台虚拟机器，白天需要 50 台机器给网银系统提供 web 服务，晚上网银交易少了，贵金属交易多了，这 50 台机器要调配到另一个系统上。这五十台不可能一个人一台台调配，那可能配一晚上都配不完，就需要自动化的软件来自动调整资源分配。

异地 “双活” 难度大

当然，部署 “双活” 数据中心的难度也非常大，尤其是异地 “双活”，涉及到数据同步效率问题。如果数据同步效率达不到要求，在灾难发生时就会造成一段时间的交易丢失。在异地 “双活” 的模式中，两地数据中心同时接纳交易，技术难度很大，需要更改众多底层程序。

双活数据中心的建设三个条件 双活数据中心的建设首先要满足三个条件，第一个是应用双活，也就是说数据库一定要实现双活，第二个是网络要双活，业务网络要保证能够同时联通两个数据中心，第三个是数据要双活，两边的数据要能够实现被独立使用。

双活数据中心解决方案缺点

虽然双活容灾解决方案对于集中式管理的数据中心更大限度的保证了业务生产的在线性及有效的防御了灾难性事件恢复业务生产的能力。但是双活数据中心的容灾方案还是存在一定的不足之处，理想与现实总存在一定的距离。

1. 脑裂现象

双活数据中心方案实现了站点级的冗余的容灾解决方案，但是受限于当前的技术等因素，在建设过程中解决了企业当前面临的业务连续性问题，同时也产生了新的问题，就是双活解决方案普遍存在的脑裂现象，在意外事件发生时，若监测技术不到位、系统平台不健康、两数据中网络波动性中断等因素的发生，使得两个数据中心一体化的业务系统会分裂成两个独立的数据中心。使用户很难取舍那一个是唯一的生产数据，那一个是将要废掉的非生产数据。这就是早年 veritas VVR 解决方案退出灾备舞台的原因之一。

2. 非 “零丢失”，不具备软错误的保障

双活容灾解决方案的优势强调在健康的运行平台下，大型灾难事件发生是的 “零” 数据丢失，但是若双活平台本身不健康或者遭遇逻辑故障时，并不能保障数据零丢失。这种故障发生的数据恢复或渐变式灾难发生的情况下，还需借助备份系统的数据恢复手段或方法。因此，双活容灾方案大多数情况下不具备解决软错误的保障，而恰恰这种事件发生的概率远远超过站点级的灾难及硬件故障事件。在 2012 年时，某省政府部门的业务系统已建设容灾系统，但是在业务系统进行升级时出错，导致业务宕机一周多时间，而这期间的大部分时间是查找依据恢复数据。

3. 需容忍高可靠性及性能的下降

双活容灾解决方案虽然提升了站点级的冗余保护，但是，在实际中确除低了整体业务平台的可靠性及性能。在可靠性方案，双活容灾解决方案就是把本地的双机双柜的硬件冗余方案跨站点建设，无论是传统的集群系统、虚拟化主机平台 Vmware, 还是 Oracle RAC 等，跨站点建设都会无形中在业务平台中增添几分不稳定的因素，我想从现在流行的一体机解决方案更能说明这方面的问题，即系统越简单越稳定。在性能方案，站点间的监测、业务会话的同步确认等的网络延迟数，加上数据同步双写的光纤延迟，都或多或少的影响了整体业务处理的性能。距离越远影响越明显，如果距离较近，也会失去建设双活容灾数据中心的意义。

4. 运营维护并不简单

双活容灾解决方案灾难切换方面变的较为简单，但在实际的维护方面并不简单，除了要求企业用户提升自己的维护能力，还需双活容灾解决方案提供商的售后服务能力。

a. 企业自身人员的维护能力必须加强，才具备能力维护跨站点的双活系统，也就是需企业用户自身人维护人员必须从维护设备的能力转变为具备维护双活系统架构的能力，才能维稳系统的正常运行，让双活系统实现该有的效果。

b. 提供商的服务能力也直接影响双活容灾系统部署后的效果，在已有的案例中，我们经常看到提供商的 800 电话，除了收集日志还是收集日志，除了正在后台诊断还是后台诊断，经常让一个小小问题需有好多层、次的沟通才能解决，这样的方式如何保障双活容灾系统的稳定？如保达到用户对双活系统在线性要求的期望？

5. 性价比并不会太高

我们经常会听到双活容灾方案可以让生产中心和容灾中心都 “活” 起来，有效的利用资源，面临灾难性事件时，最大化业务系统的在线性，解除原有灾备系统有灾无备等等的不足之处。但是，当我们认真考虑建设双活容灾系统时发现，如果自身 IT 人员的维护能力不足，很难达到我们期望的效果。在现实案例中，很多用户一次性的费用建设的系统，后续的维保经费很难申请，这种情况很难有效的保障我们的信息系统的健康运行。宁夏银行就是在没有后续维保经费支撑的情况下，硬件出故障，自身 IT 人员修复过程中出现人为错误而引起的重大事故。因此，建设双活容灾系统的同时，必须要保障后续的维护经费。使得双活容灾系统向高大上偏移。

一般国内的 IDC, 金融业务会考虑两地三中心，非金融业务会考虑主备 IDC 或双活 IDC，如果是全球的业务，一般会分区域在全球建立全球 IDC，并一个区域至少建立 2 个节点做主备或双活。

NFS

NFS 文件系统是 Sun 公司开发的网络文件系统，也称为分布式文件系统，其基本原理是将某个设备本地文件系统通过以太网的方式共享给其它计算节点使用。也就是说，计算机节点通过 NFS 存储的数据是通过网络存储在另外一个设备，而不是存储在本地磁盘

网络文件系统最大的特点是可以实现多个计算节点对同一个存储设备的访问，从而提升存储的利用率，并简化存储管理难度。NFS 分布式文件系统本身是客户端服务器架构模式

基于CentOS安装NFS服务安装配置

首先安装nfs-utils

sudo yum install nfs-utils

如果期望在操作系统启动的时候可以自动启动 NFS 服务，因此我们这里需要设置一下 NFS 服务开机启动，具体命令如下

$ sudo systemctl enable rpcbind

$ sudo systemctl enable nfs

软件安装后服务可能没有启动，这时需要手动启动一下 NFS 服务。如果已经启动了就不需要执行该步操作了

$ sudo systemctl start rpcbind

$ sudo systemctl start nfs

配置共享目录

完成上述操作后，NFS 服务已经正常工作了，但是我们在客户端仍然没有办法访问该服务。这是因为此时 NFS 服务还没有配置导出的资源。接下来我们在服务端配置一个共享目录，也就是要导出的资源。首先要创建一个目录，并且修改该目录的权限

$ sudo mkdir /data

$ sudo chmod 755 /data

至此，我们已经完成 nfsd 服务的安装，重启一下 nfs 服务就可以使用了。为了确认是否安装成功，可以通过如下命令进行确认

https://www.zhihu.com/people/zhang-shu-zhu-69/posts?page=3

云端IDE

传统上，软件开发是（而且在很大程度上仍然是）在个人机器上使用集成开发环境（IDE）工具，如 VSCode、JetBrains、Eclipse 等完成。虽然这种 “离线” 开发的模式在早期运作得非常好，但人们很快就注意到，这种方法并非完美。

首先，合作起来很麻烦，因为写好的代码必须上传到网上供进一步审查。这样写出来的代码的可移植性也并不总是有保证，因为有各种各样的操作系统和其他限制条件，需要它来实现最佳的功能。

正如开发者和技术记者 Owen Williams 去年 在他的博客 Charged 上写道：“在设备之间同步你的文档和照片是微不足道的…… 这样你就可以在任何地方把它们调出来，但开发者工具仍然停留在过去 —— 每台笔记本电脑或 PC 都要单独配置，使你的环境设置得恰到好处。”

随着大流行期间越来越多的分布式团队和更多的敏捷工作方式，引入能够让开发人员在任何地方保持生产力的工具变得至关重要。这为什么会有 Gitpod、GitHub Codespaces、Replit 等基于云端 IDE 出现。

云端IDE的优点：

使用云端 IDE 无需担心配置

由于开发环境完全在浏览器上运行，因此不再需要梳理安装页面和弄清楚需要安装哪个软件包。

硬件的选择并不重要

基于云的集成开发环境消除了（好吧，几乎是！）开始进行网络开发的障碍。在任何支持现代网络浏览器都可以运行，你甚至不需要在不同的机器上从头开始重新配置一切。

在任何地方工作和协作都很容易

这些工具具有高度可定制的工作空间，可以在团队 / 个人层面上进行优化，它们不仅促进了更好的合作，而且完全消除了 “在我的机器上可以运行 " 这种太过普遍的情况。鉴于这些主要的优点，很明显基于云的 IDE 已经获得了发展势头。

于云的 IDE 的许多缺点都与扩展问题有关，因为这些工具仍然处于成熟的早期阶段。以下是早期采用者可能会遇到的一些关键问题。

性能可能是不平衡的

由于云上的资源是由需求不稳定的消费者共享的，因此肯定有机会出现性能不一致的情况，特别是在对网络延迟、容量或整体产品的故障造成问题的情况下，更是如此。

故障的来源可能很难识别和解决

当你不知道根本原因时，很难修复一个问题，总的来说，这可能会导致此类产品的早期采用者有一个令人沮丧的体验。

大项目可能更适合使用离线 IDE

到今天为止，已经观察到一些初期问题，用户抱怨平均负载过高。对于大型开发项目，所需的数据传输和处理量将是巨大的。虽然它可能不会扼杀基于云的 IDE 的资源，但由于其实用性，在这种情况下，离线替代方案肯定是更佳选择。

供应商锁定会限制工具的可用性

另一个需要考虑的方面是当涉及到基于云端 IDE 时，工具包的可用性。大量的工具可以在本地与 IDE 配对使用。但是，对于基于云端 IDE，开发者被限制在供应商提供的集成选择上，这对于那些需要更广泛工具包的人来说可能是限制性的。

云端 IDE 需要 WiFi

最后一点往往被忽略，基于云的 IDE 在与真正强大的桌面 IDE 相媲美之前还有很长的路要走，这些 IDE 允许降低对 WiFi 等外部因素的依赖性。即使正在实施各种变通办法，其可靠性水平也远远不能与桌面 IDE 提供的离线体验相比。

云工具

腾讯HiFlow：https://hiflow.tencent.com/

云原生资源

国内云原生社区： https://cloudnative.to/

国外云原生社区：cncf