理解 OpenStack + Ceph （4）：Ceph 的基础数据结构 [Pool, Image, Snapshot, Clone]-低调大师

理解 OpenStack + Ceph （4）：Ceph 的基础数据结构 [Pool, Image, Snapshot, Clone]

2017-11-12 714

本系列文章会深入研究 Ceph 以及 Ceph 和 OpenStack 的集成：

（1）安装和部署

（2）Ceph RBD 接口和工具

（3）Ceph 物理和逻辑结构

（4）Ceph 的基础数据结构

（5）Ceph 与 OpenStack 集成的实现

（6）QEMU-KVM 和 Ceph RBD 的缓存机制总结

（7）Ceph 的基本操作和常见故障排除方法

1 Pool（池）

Pool 的概念前面讲过了，Ceph 支持丰富的对 Pool 的操作，主要的包括：

列表、创建和删除 pool
ceph osd pool create {pool-name} {pg-num} [{pgp-num}] [replicated] [crush-ruleset-name]
ceph osd pool create {pool-name} {pg-num} {pgp-num} erasure [erasure-code-profile] [crush-ruleset-name]
ceph osd pool delete {pool-name} [{pool-name} --yes-i-really-really-mean-it]
QoS 支持：
ceph osd pool set-quota {pool-name} [max_objects {obj-count}] [max_bytes {bytes}]
快照创建和删除：
ceph osd pool mksnap {pool-name} {snap-name}
ceph osd pool rmsnap {pool-name} {snap-name}
元数据修改
ceph osd pool set {pool-name} {key} {value}
设置对象拷贝份数（注意该份数包括对象自身）
ceph osd pool set {poolname} size {num-replicas}
在 degraded 模式下的拷贝份数
ceph osd pool set data min_size 2

2 卷（image）

2.1 image 之用户所见

Image 对应于 LVM 的 Logical Volume，它将被条带化为 N 个子数据块，每个数据块将会被以对象（object）形式保存在 RADOS 对象存储中的简单块设备（simple block devicees）。比如：

#创建 100 MB 大小的名字为 ‘myimage’ 的 RBD Image，默认情况下，它被条带化为 4MB 大小的 25 个对象 （注意 rdb create 命令的 size 参数的单位为 MB）
rbd create mypool/myimage --size 100

#同样是 100MB 大小的 RBD Image，但是它被被条带化为 8MB 大小的13 个对象
rbd create mypool/myimage --size 100 --order 23


#将 image mount 到linux 主机称为一个 deivce /dev/rbd1

rbd map mypool/myimage


#向 /dev/rbd1 写入数据

dd if=/dev/zero of=/dev/rbd1 bs=1047586 count=4

#删除 image
rbd rm mypool/myimage

2.2 image 之 ceph 系统所见

接下来我们来看看 image 的一些内部信息。

（1）创建新的对象

首先在一个空的 pool 中创建一个 100 GB 的 image

root@ceph1:~# rbd create -p pool100 image1 --size 102400 --image-format 2
root@ceph1:~# rbd list pool100
image1

这时候在 pool 中看到多了一些对象：

root@ceph1:~# rados -p pool100 ls
rbd_directory
rbd_id.image1
rbd_header.a89c2ae8944a

从名字也能看出来，这些 object 存放的不是 image 的数据，而是 ID，header 之类的元数据信息。其中，rbd_directory 中保存了pool内所有image的 ID 和 name 信息：

root@ceph1:~# rados -p pool100 listomapvals rbd_directory
id_a89c2ae8944a
value: (10 bytes) :
0000 : 06 00 00 00 69 6d 61 67 65 31                   : ....image1

name_image1
value: (16 bytes) :
0000 : 0c 00 00 00 61 38 39 63 32 61 65 38 39 34 34 61 : ....a89c2ae8944a

而 rbd_header 保存的是一个 RBD 镜像的元数据：

root@ceph1:~# rados -p pool100 listomapvals rbd_header.a89c2ae8944a
features
value: (8 bytes) :
0000 : 01 00 00 00 00 00 00 00                         : ........

object_prefix
value: (25 bytes) :
0000 : 15 00 00 00 72 62 64 5f 64 61 74 61 2e 61 38 39 : ....rbd_data.a89
0010 : 63 32 61 65 38 39 34 34 61 : c2ae8944a order value: (1 bytes) : 0000 : 16 : . size value: (8 bytes) : 0000 : 00 00 00 00 19 00 00 00 : ........ snap_seq value: (8 bytes) : 0000 : 00 00 00 00 00 00 00 00 : ........

这些信息正是下面命令的信息来源：

root@ceph1:~# rbd -p pool100 info image1
rbd image 'image1':
    size 102400 MB in 25600 objects
    order 22 (4096 kB objects)
    block_name_prefix: rbd_data.a89c2ae8944a
    format: 2 features: layering

同时还能看出来，该 image 的数据对象的名称前缀是 rbd_header.a89c2ae8944a。而对于一个新建的 image，因为没有数据对象，其实际占用的存储空间只是元数据对象所占的非常小的空间。

（2）向该对象中写入数据 8MB 的数据（该 pool 中一个 object 是 4MB）

root@ceph1:~# rbd map pool100/image1
root@ceph1:~# rbd showmapped
id pool    image  snap device    
1  pool100 image1 -    /dev/rbd1 
root@ceph1:~# dd if=/dev/zero of=/dev/rbd1 bs=1048576 count=8
8+0 records in
8+0 records out
8388608 bytes (8.4 MB) copied, 0.316369 s, 26.5 MB/s

在来看看 pool 中的对象：

root@ceph1:~# rados -p pool100 ls
rbd_directory
rbd_id.image1
rbd_data.a89c2ae8944a.0000000000000000
rbd_data.a89c2ae8944a.0000000000000001
rbd_header.a89c2ae8944a

可以看出来多了 2 个 4MB 的 object。继续看第一个对象所在的 OSD：

root@ceph1:~# ceph osd map pool100 rbd_data.a89c2ae8944a.0000000000000000
osdmap e81 pool 'pool100' (7) object 'rbd_data.a89c2ae8944a.0000000000000000' -> pg 7.df059252 (7.52) -> up ([8,6,7], p8) acting ([8,6,7], p8)

PG 的 ID 是 7.52，主 OSD 是 8，从 OSD 是 6 和 7。从 OSD 树中可以获知 OSD 8 所在的节点为 ceph3：

root@ceph3:/data/osd2/current/7.52_head# ceph osd tree
# id    weight    type name    up/down    reweight
-1    0.1399    root default    
-4    0.03998        host ceph3
5    0.01999            osd.5    up    1    
8    0.01999            osd.8    up    1

root@ceph3:/var/lib/ceph/osd# ls -l
total 0
lrwxrwxrwx 1 root root  9 Sep 18 02:59 ceph-5 -> /data/osd
lrwxrwxrwx 1 root root 10 Sep 18 08:22 ceph-8 -> /data/osd2

查看 7.52 开头的目录，可以看到两个数据文件：

root@ceph3:/data/osd2/current# find . -name '*a89c2ae8944a*'
./7.5c_head/rbd\uheader.a89c2ae8944a__head_36B2DADC__7
./7.52_head/rbd\udata.a89c2ae8944a.0000000000000001__head_9C6139D2__7
./7.52_head/rbd\udata.a89c2ae8944a.0000000000000000__head_DF059252__7

可见：

（1）RBD image 是简单的块设备，可以直接被 mount 到主机，成为一个 device，用户可以直接写入二进制数据。

（2）image 的数据被保存为若干在 RADOS 对象存储中的对象。

（3）image 的数据空间是 thin provision 的，意味着ceph 不预分配空间，而是等到实际写入数据时按照 object 分配空间。

（4）每个 data object 被保存为多份。

（5）pool 将 RBD 镜像的ID和name等基本信息保存在 rbd_directory 中，这样，rbd ls 命令就可以快速返回一个pool中所有的 RBD 镜像了。

（6）每个 RBD 镜像的元数据将保存在一个对象中，命名为 rbd_header.<image id>。

（7）RBD 镜像保存在多个对象中，这些对象的命名为 rbd_data.<image id>.<顺序编号序列>。

（8）RADOS 对象以 OSD 文件系统上的文件形式被保存，其文件名为 udata<image id>.<顺序编号序列>.<其它字符串>。

3 快照（snapshot）

3.1 snapshot 之用户所见

RBD image 的快照（snapshot）是该 image 在特定时刻的状态的一份只读拷贝（A snapshot is a read-only copy of the state of an image at a particular point in time.）。需要注意的是，在做 snapshot 之前，需要停止 I/O；如果 image 中包含文件系统，系统确保文件系统是处于连续状态。

用户可以使用 rbd 工具或者其它 API 操作 snapshot：

rbd create -p pool101 --size 102400 image1 --format 2 #创建 image
rbd snap create pool101/image1@snap1 #创建snapshot
rbd snap ls pool101/image1 #列表
rbd snap protect pool101/image1@snap1 #保护
rbd snap unprotect pool101/image1@snap1 #去保护
rbd snap rollback pool101/image1@snap1 #回滚snapshot 到 image。注意这是个耗时操作，rbd 会显示进度条
rbd snap rm pool101/image1@snap1 #删除

rbd snap purge pool101/image1 #删除 image 的所有snapshot

rbd clone pool101/image1@snap1 image1snap1clone1 #创建 clone

rbd children pool101/image1@snap1 #列表它的所有 clone

3.2 snapshot 之 Ceph 系统所见

我们也来看看 snapshot 的内部原理。

（1）创建 image1，写入 4MB 的数据，然后创建一个 snapshot: rbd snap create pool100/image1@snap1

（2）Ceph 在该 pool 中没有创建新的的对象，也就是说这时候并没有分配存储空间来给 snap1 创建 data objects。

  
 
root@ceph1:~# rbd map pool101/image1
 root@ceph1:~# rbd showmapped
 id pool image snap device
 1 pool100 image1 - /dev/rbd1
 2 pool101 image1 - /dev/rbd2
root@ceph1:~# dd if=/dev/sda1 of=/dev/rbd2 bs=1048576 count=4
 4+0 records in
 4+0 records out
 4194304 bytes (4.2 MB) copied, 0.123617 s, 33.9 MB/s
 root@ceph1:~# rados -p pool101 ls
 rbd_directory
 rb.0.fc9d.238e1f29.000000000000
 image1.rbd
root@ceph1:~# rbd snap create pool101/image1@snap1
root@ceph1:~# rbd snap ls pool101/image1
 SNAPID NAME SIZE
 10 snap1 102400 MB
root@ceph1:~# rados -p pool101 ls
 rbd_directory
 rb.0.fc9d.238e1f29.000000000000
 image1.rbd

  
 

（3）Ceph 而是将 snapshot 的信息增加到了 rbd_header.{image_id} 对象中

  
 
root@ceph1:~# rados -p pool101 listomapvals rbd_header.a9262ae8944a
 snapshot_0000000000000006
value: (74 bytes) :
 0000 : 03 01 44 00 00 00 06 00 00 00 00 00 00 00 05 00 : ..D.............
 0010 : 00 00 73 6e 61 70 31 00 00 00 00 19 00 00 00 01 : ..snap1.........
 0020 : 00 00 00 00 00 00 00 01 01 1c 00 00 00 ff ff ff : ................
 0030 : ff ff ff ff ff 00 00 00 00 fe ff ff ff ff ff ff : ................
 0040 : ff 00 00 00 00 00 00 00 00 00 : ..........

  
 

（4）再向 image1 中写入 4MB 数据（其实是覆盖第一个 object 中的数据），发现数据目录中多了一个 4MB 的文件：

root@ceph3:/data/osd2/current/8.2c_head# ls /data/osd/current/8.3e_head/ -l
 total 8200
 -rw-r--r-- 1 root root 4194304 Sep 28 03:25 rb.0.fc9d.238e1f29.000000000000__a_AE14D5BE__8
 -rw-r--r-- 1 root root 4194304 Sep 28 03:25 rb.0.fc9d.238e1f29.000000000000__head_AE14D5BE__8

可见 Ceph 使用 COW （copy on write）方式实现 snapshot：在写入object 之前，将其拷贝出来，作为 snapshot 的 data object，然后继续修改 object 中的数据。

（5）再执行命令 dd if=/dev/sda1 of=/dev/rdb1 bs=1048576 seek=4 count=4 向 image 写入 [4MB，8MB）的数据。该操作创建了第二个 data object。因为这是在做 snapshot 之后创建的，所有它和 snapshot 没有关系。

（6）再创建一个snapshot，然后修改第二个 data object，这时候第二个 data object 所在的文件夹中多出了 snapshot 的一个 data object 文件：

root@ceph3:/data/osd2/current/8.2c_head# ls /data/osd/current/8.a_head/ -l
total 4100
-rw-r--r-- 1 root root 4194304 Sep 28 03:31 rb.0.fc9d.238e1f29.000000000001__head_9C84738A__8
root@ceph3:/data/osd2/current/8.2c_head# ls /data/osd/current/8.a_head/ -l
total 8200
-rw-r--r-- 1 root root 4194304 Sep 28 03:35 rb.0.fc9d.238e1f29.000000000001__b_9C84738A__8
-rw-r--r-- 1 root root 4194304 Sep 28 03:35 rb.0.fc9d.238e1f29.000000000001__head_9C84738A__8

因此，

（1）snapshot 的 data objects 是和 image 的 data objects 保存在同一个目录中。

（2）snapshot 的粒度不是整个 image，而是RADOS 中的 data object。

（3）当 snapshot 创建时，只是在 image 的元数据对象中增加少量字节的元数据；当 image 的 data objects 被修改（write）时，变修改的 objects 会被拷贝（copy）出来，作为 snapshot 的 data objects。这就是 COW 的含义。

4 克隆（clone）

创建 Clone 是将 image 的某一个 Snapshot 的状态复制变成一个 image。如 imageA 有一个 Snapshot-1，clone 是根据 ImageA 的 Snapshot-1 克隆得到 imageB。imageB 此时的状态与Snapshot-1完全一致，并且拥有 image 的相应能力，其区别在于 ImageB 此时可写。

4.1 Clone 之用户所见

从用户角度来看，一个 clone 和别的 RBD image 完全一样。你可以对它做 snapshot、读/写、改变大小等等，总之从用户角度来说没什么限制。同时，创建速度很快，这是因为 Ceph 只允许从 snapshot 创建 clone，而 snapshot 一直是只读的。

rbd clone pool101/image1@snap1 image1snap1clon3
root@ceph1:~# rbd info image1snap1clon3
rbd image 'image1snap1clon3':
        size 102400 MB in 25600 objects
        order 22 (4096 kB objects)
        block_name_prefix: rbd_data.a8f63d1b58ba
        format: 2 features: layering parent: pool101/image1@snap1 overlap: 102400 MB

4.2 Clone 之 Ceph 系统所见

从系统角度，clone 也是使用 COW 技术，现在来通过下面的步骤具体了解一下：

（1）创建一个 clone （创建之前，需要 protect snapshot）。你会发现 RADOS 中多了三个object：

  
 
root@ceph1:~# rbd clone pool101/image1@snap1 pool101/image1snap1clone1
 root@ceph1:~# rbd ls -p pool101
 image1
 image1snap1clone1
 root@ceph1:~# rados -p pool101 ls
 rbd_header.89903d1b58ba
 rbd_directory
 rbd_id.image1snap1clone1
 rbd_id.image1
 rbd_children
 rbd_header.a9532ae8944a
 rbd_data.a9532ae8944a.0000000000000000

  
 

其中，rbd_children 记录了父子关系：

  
root@ceph1:~# rados -p pool101 listomapvals rbd_children
 key: (32 bytes):
 0000 : 08 00 00 00 00 00 00 00 0c 00 00 00 61 39 35 33 : ............a953
 0010 : 32 61 65 38 39 34 34 61 0e 00 00 00 00 00 00 00 : 2ae8944a........
value: (20 bytes) :
 0000 : 01 00 00 00 0c 00 00 00 38 39 39 30 33 64 31 62 : ........89903d1b
 0010 : 35 38 62 61 : 58ba

相比 rbd_header.a9532ae8944a，rbd_header.89903d1b58ba 只是多了 partent 信息：

  
parent
 value: (46 bytes) :
 0000 : 01 01 28 00 00 00 08 00 00 00 00 00 00 00 0c 00 : ..(.............
 0010 : 00 00 61 39 35 33 32 61 65 38 39 34 34 61 0e 00 : ..a9532ae8944a..
 0020 : 00 00 00 00 00 00 00 00 00 00 19 00 00 00 : ..............

这里父子关系和 rbd children 结果的来源：

root@ceph1:~# rbd children pool101/image1@snap1
pool101/image1snap1clone1

可见，Clone 也是对 snapshot 使用 COW 方式实现的。

（2）从 clone 读数据

从本质上是 clone 的 RBD image 中读数据，对于不是它自己的 data objects，ceph 会从它的 parent snapshot 上读，如果它也没有，继续找它的parent image，直到一个 data object 存在。从这个过程也看得出来，该过程是缺乏效率的。

（3）向 clone 中的 object 写数据

Ceph 会首先检查该 clone image 上的 data object 是否存在。如果不存在，则从 parent snapshot 或者 image 上拷贝该 data object，然后执行数据写入操作。这时候，clone 就有自己的 data object 了。

root@ceph2:/data/osd3/current/8.32_head# ls -l
total 4100
-rw-r--r-- 1 root root 4194304 Sep 28 05:14 rbd\udata.89903d1b58ba.0000000000000000__head_CEDDC1B2__8

这是增加了 clone 后的各对象之间的关系：

4.3 Flatten clone

从上面的分析我们知道，克隆操作本质上复制了一个 metadata object，而 data objects 是不存在的。因此在每次读操作时会先向本卷可能的 data object 访问。在返回对象不存在错误后会向父卷访问对应的对象最终决定这块数据是否存在。因此当存在多个层级的克隆链后，读操作需要更多的损耗去读上级卷的 data objects。只有当本卷的 data object 存在后(也就是写操作后)，才不需要访问上级卷。

为了防止父子层数过多，Ceph 提供了 flattern 函数将 clone 与 parent snapshot 共享的 data objects 复制到 clone，并删除父子关系。

rbd 工具的 flatten 方法：

rbd flatten <image-name>： fill clone （image-name） with data of parent (make it independent)
如果一个 image 是个 clone，从它的 parent snapshot 拷贝所有共享的 blocks （data objects），删除与其 parent 的依赖关系。此时，其 parent snapshot 可以被去保护（unprotected），如果没有其它的 clone 的话，它是允许被删除的。 该功能要求 image 为 format 2 格式。

注意这是一个非常耗时的操作。Flatten 之后，clone 与原来的父 snapshot 之间也不再有关系了，真正成为一个独立的 image：

root@ceph1:~# rbd flatten image1snap1clon2
Image flatten: 100% complete...done.
root@ceph1:~# rbd info image1snap1clon2
rbd image 'image1snap1clon2':
        size 102400 MB in 25600 objects
        order 22 (4096 kB objects) block_name_prefix: rbd_data.fb173d1b58ba format: 2 features: layering

令人奇怪的是，该操作在parent image 和 clone 产生的 image 的目录中产生了大量空的文件：

root@ceph1:/data/osd/current# ls /data/osd/current/8.7f_head/ -l
total 788
-rw-r--r-- 1 root root 0 Sep 28 05:33 rbd\udata.89903d1b58ba.000000000000014f__head_17C7607F__8
-rw-r--r-- 1 root root 0 Sep 28 05:33 rbd\udata.89903d1b58ba.0000000000000232__head_96D143FF__8
-rw-r--r-- 1 root root 0 Sep 28 05:33 rbd\udata.89903d1b58ba.0000000000000399__head_4D4E557F__8
-rw-r--r-- 1 root root 0 Sep 28 05:33 rbd\udata.89903d1b58ba.00000000000003ae__head_CE165DFF__8
-rw-r--r-- 1 root root 0 Sep 28 05:33 rbd\udata.89903d1b58ba.00000000000003e1__head_42EA8A7F__8 -rw-r--r-- 1 root root 0 Sep 28 05:33 rbd\udata.89903d1b58ba.0000000000000445__head_701607FF__8

判断父子关系层数，达到一定数目后 flatten clone，在删除 snapshot 的伪代码：

img = self.rbd.Image(client.ioctx, img_name) #根据输入的 img_name 获得其 RBD Image 对象

_pool, parent, snap = self._get_clone_info(img_name) #当 name 为 img_name 的 RBD image 是个 clone 时，通过递归，获取它的 parent image 和 parent snapshot
img.flatten() # 将 parent snapshot 的 data 拷贝到该 clone 中
parent_volume = self.rbd.Image(client.ioctx, parent) #获取 parent image
parent_volume.unprotect_snap(snap) #将 snap 去保护
parent_volume.remove_snap(snap) #如果snapshot 没有其它的 clone，将其删除

5. 小结

RBD image 的 head，object，snapshot 以及与 client 和 parent 之间的关系：

参考链接：

http://www.wzxue.com/ceph-librbd-block-library/

http://docs.ceph.com/docs/master/architecture/

https://www.ustack.com/blog/ceph_infra/

https://hustcat.github.io/rbd-image-internal-in-ceph/

http://www.wzxue.com/category/ceph-2/

本文转自SammyLiu博客园博客，原文链接：http://www.cnblogs.com/sammyliu/p/4843812.html，如需转载请自行联系原作者

微信关注我们

原文链接：https://yq.aliyun.com/articles/377907

转载内容版权归作者及来源网站所有！

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

理解 OpenStack + Ceph （5）：OpenStack 与 Ceph 之间的集成 [OpenStack Integration ...

理解 OpenStack + Ceph 系列文章：（1）安装和部署（2）Ceph RBD 接口和工具（3）Ceph 物理和逻辑结构（4）Ceph 的基础数据结构（5）Ceph 与 OpenStack 集成的实现（6）QEMU-KVM 和 Ceph RBD 的缓存机制总结（7）Ceph 的基本操作和常见故障排除方法 1. Glance 与 Ceph RBD 集成 1.1 代码 Kilo 版本中，glance-store 代码被从 glance 代码中分离出来了，地址在https://github.com/openstack/glance_store。 Glance 中与 Ceph 相关的配置项：配置项含义默认值 rbd_pool 保存rbd 卷的ceph pool 名称 images rbd_user rbd user id，仅仅在使用 cephx 认证时使用 none。让 librados 根据 ceph 配置文件决定 rbd_ceph_conf Ceph 配置文件的完整路径 /etc/ceph/ceph.conf rbd_store_chunk_size 卷会被...

2017-11-12

777

理解 OpenStack + Ceph （2）：Ceph 的物理和逻辑结构 [Ceph Architecture]

本系列文章会深入研究 Ceph 以及 Ceph 和 OpenStack 的集成：（1）安装和部署（2）Ceph RBD 接口和工具（3）Ceph 物理和逻辑结构（4）Ceph 的基础数据结构（5）Ceph 与 OpenStack 集成的实现（6）QEMU-KVM 和 Ceph RBD 的缓存机制总结（7）Ceph 的基本操作和常见故障排除方法 1.Ceph 集群的物理结构 1.1 Ceph 内部集群从前一篇文章我们知道，从物理上来讲，一个 Ceph 集群内部其实有几个子集群存在：（1）MON（Montior）集群：MON 集群有由少量的、数目为奇数个的 Monitor 守护进程（Daemon）组成，它们负责通过维护 Ceph Cluster map 的一个主拷贝（master copy of Cluster map）来维护整 Ceph 集群的全局状态。理论上来讲，一个 MON 就可以完成这个任务，之所以需要一个多个守护进程组成的集群的原因是保证高可靠性。每个 Ceph node 上最多只能有一个 Monitor Daemon。 root@ceph1:~# ps -e...

2017-11-12

709

发表评论

资源下载

更多资源

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长，特征是大鼻子、头戴帽子、身穿背带裤，还留着胡子。与他的双胞胎兄弟路易基一起，长年担任任天堂的招牌角色。

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题，腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构，目前腾讯云软件源站支持公网访问和内网访问。

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称，一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

WebStorm

WebStorm 是jetbrains公司旗下一款JavaScript 开发工具。目前已经被广大中国JS开发者誉为“Web前端开发神器”、“最强大的HTML5编辑器”、“最智能的JavaScript IDE”等。与IntelliJ IDEA同源，继承了IntelliJ IDEA强大的JS部分的功能。