其实本章原来名为k8s，后来感觉云的概念/应用太多了，远远不止一个k8s，所以就以云为开始
# 技术名词概念
# 隔离技术与故障域
故障域指的是当一个区域出现故障以后，它的受影响范围。例如在设计双活数据中心的时候，我们要设置故障域，那个故障域是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 服务器 (opens new window)，找到服务器主机，向服务器发出一个请求，服务器经过解析之后，发送给用户的浏览器 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网关 (opens new window) - 在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架构搭建的时候，可以跨机房。对不同机房的物理服务器 (opens new window)打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 等
# NFS
NFS 文件系统是 Sun 公司开发的网络文件系统，也称为分布式文件系统，其基本原理是将某个设备本地文件系统通过以太网的方式共享给其它计算节点使用。也就是说，计算机节点通过 NFS 存储的数据是通过网络存储在另外一个设备，而不是存储在本地磁盘
网络文件系统最大的特点是可以实现多个计算节点对同一个存储设备的访问，从而提升存储的利用率，并简化存储管理难度。NFS 分布式文件系统本身是客户端服务器架构模式
基于CentOS安装NFS服务安装配置
首先安装nfs-utils
sudo yum install nfs-utils
如果期望在操作系统启动的时候可以自动启动 NFS 服务，因此我们这里需要设置一下 NFS 服务开机启动，具体命令如下
$ sudo systemctl enable rpcbind
$ sudo systemctl enable nfs
2
3
软件安装后服务可能没有启动，这时需要手动启动一下 NFS 服务。如果已经启动了就不需要执行该步操作了
$ sudo systemctl start rpcbind
$ sudo systemctl start nfs
2
3
配置共享目录
完成上述操作后，NFS 服务已经正常工作了，但是我们在客户端仍然没有办法访问该服务。这是因为此时 NFS 服务还没有配置导出的资源。接下来我们在服务端配置一个共享目录，也就是要导出的资源。首先要创建一个目录，并且修改该目录的权限
$ sudo mkdir /data
$ sudo chmod 755 /data
2
3
至此，我们已经完成 nfsd 服务的安装，重启一下 nfs 服务就可以使用了。为了确认是否安装成功，可以通过如下命令进行确认
https://www.zhihu.com/people/zhang-shu-zhu-69/posts?page=3
# 云端IDE
传统上，软件开发 (opens new window)是（而且在很大程度上仍然是）在个人机器上使用集成开发环境（IDE）工具，如 VSCode、JetBrains、Eclipse 等完成。虽然这种 “离线” 开发的模式在早期运作得非常好，但人们很快就注意到，这种方法并非完美。
首先，合作起来很麻烦，因为写好的代码必须上传到网上供进一步审查。这样写出来的代码的可移植性也并不总是有保证，因为有各种各样的操作系统和其他限制条件，需要它来实现最佳的功能。
正如开发者和技术记者 Owen Williams (opens new window) 去年 在他的博客 Charged 上 (opens new window)写道：“在设备之间同步你的文档和照片是微不足道的…… 这样你就可以在任何地方把它们调出来，但开发者工具仍然停留在过去 —— 每台笔记本电脑或 PC 都要单独配置，使你的环境设置得恰到好处。”
随着大流行期间越来越多的分布式团队和更多的敏捷工作方式，引入能够让开发人员在任何地方保持生产力的工具变得至关重要。这为什么会有 Gitpod (opens new window)、GitHub Codespaces (opens new window)、Replit 等基于云端 IDE 出现。
云端IDE的优点：
使用云端 IDE 无需担心配置
由于开发环境完全在浏览器上运行，因此不再需要梳理安装页面和弄清楚需要安装哪个软件包。
硬件的选择并不重要
基于云的集成开发环境消除了（好吧，几乎是！）开始进行网络开发的障碍。在任何支持现代网络浏览器都可以运行，你甚至不需要在不同的机器上从头开始重新配置一切。
在任何地方工作和协作都很容易
这些工具具有高度可定制的工作空间，可以在团队 / 个人层面上进行优化，它们不仅促进了更好的合作，而且完全消除了 “在我的机器上可以运行 " 这种太过普遍的情况。鉴于这些主要的优点，很明显基于云的 IDE 已经获得了发展势头。
于云的 IDE 的许多缺点都与扩展问题有关，因为这些工具仍然处于成熟的早期阶段。以下是早期采用者可能会遇到的一些关键问题。
性能可能是不平衡的
由于云上的资源是由需求不稳定的消费者共享的，因此肯定有机会出现性能不一致的情况，特别是在对网络延迟、容量或整体产品的故障造成问题的情况下，更是如此。
故障的来源可能很难识别和解决
当你不知道根本原因时，很难修复一个问题，总的来说，这可能会导致此类产品的早期采用者有一个令人沮丧的体验。
大项目可能更适合使用离线 IDE
到今天为止，已经观察到一些初期问题，用户抱怨平均负载过高 (opens new window)。对于大型开发项目，所需的数据传输和处理量将是巨大的。虽然它可能不会扼杀基于云的 IDE 的资源，但由于其实用性，在这种情况下，离线替代方案肯定是更佳选择。
供应商锁定会限制工具的可用性
另一个需要考虑的方面是当涉及到基于云端 IDE 时，工具包的可用性。大量的工具可以在本地与 IDE 配对使用。但是，对于基于云端 IDE，开发者被限制在供应商提供的集成选择上，这对于那些需要更广泛工具包的人来说可能是限制性的。
云端 IDE 需要 WiFi
最后一点往往被忽略，基于云的 IDE 在与真正强大的桌面 IDE 相媲美之前还有很长的路要走，这些 IDE 允许降低对 WiFi 等外部因素的依赖性。即使正在实施各种变通办法，其可靠性水平也远远不能与桌面 IDE 提供的离线体验相比。
# 云工具
腾讯HiFlow：https://hiflow.tencent.com/
# 云原生资源
国内云原生社区： https://cloudnative.to/
国外云原生社区：cncf