本文分享自华为云社区《
GaussDB(分布式)实例故障处理
》，作者：subverter。

一、说明

GaussDB Kernel实例出现故障时，可以按照本节的办法进行实例快速修复。

1、执行gs_om -t status --detail查看集群状态，cluster_state为Normal，balanced为No，请重置实例状态。

2、执行gs_om -t status --detail查看集群状态，cluster_state为Degraded，表示有实例异常，但是集群依然可以正常对外提供服务。此时，虽然不影响业务运行，但是主备实例切换将加重某些节点上的工作负载，时间久了，可能带来这些对应节点上的资源耗尽，进而影响业务运行。因此集群处于Degraded状态时，建议尽快定位，使集群恢复至Normal状态。GaussDB Kernel提供了如下办法，协助用户在操作系统和硬件正常时的实例快速修复。

3、CN实例异常，优先通过删除CN和增加CN进行实例恢复。

4、各类实例异常的通用办法——修改HOSTNAME、IP和端口号。

二、重置实例状态

1、操作场景

集群在运行过程中，如果发生了主机或某些实例故障，集群管理模块会自动将备实例提升为主实例继续提供服务；或是由于数据库集群管理人员手工进行过主备切换操作后，使当前集群各主机上运行的主实例（GTM，DN）数不均等，造成集群负载不均衡，即集群“balanced”状态为"No"。这种情况下可以通过集群管理命令将集群中的数据库实例恢复为初始配置的主备状态。

存在实例异常时，需要先将实例修复后，才能进行重置。

2、处理方法

1.以操作系统用户omm登录数据库集群任一主机。

2.查询并确认集群运行状态及“balanced”状态。

“cluster_state”为“Normal”表示集群运行正常。“balanced”状态为“No”表示集群实例发生过主备切换。

gs_om -t status --detail

3.使用如下命令查看集群状态确认是哪些节点上的实例发生过主备切换。

gs_om -t status --detail

例如下面示例中，node2节点上的主dn2发生过主备切换。该DN原始为主DN（“state”中的字母“P”代表其初始为Primary DN），当前切换成了备DN（“state ”状态变成了“Standby Normal”）。

4.使用如下命令将集群中发生切换的实例恢复为初始配置的主备状态。

gs_om -t switch --reset --time-out=300

300为切换的等待时间，单位为s。切换后集群的“balanced”状态变为“Yes”。

3、示例

查询当前发生过切换的实例。

gs_om -t switchOperation: Switch query.

[     GTM State     ]



node                   instance             state--------------------------------------------------------------------(no need to switchover gtm)



[  Datanode State   ]



node     node_ip         instance            state| node     node_ip        instance                      state            |node     node_ip        instance                       state--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------AZ11  plat1 192.168.0.11    6001 /gaussdb/data/data_dn1 P Standby Normal | 2  plat2 192.168.0.12   6002 /gaussdb/data/data_dnS1  S Primary Normal | 3  plat1 192.168.0.13   3002 /gaussdb/data/data_dnDS1  R Secondary Normal

Operation succeeded: Switch query.

若实例未发生过主备切换，则查询结果中会显示“no need to switchover xxx”。否则，则有实例发生过主备切换。例如，上例中通过查询发现有一组主备DN都发生过切换。将发生切换的实例恢复为初始配置的主备状态。

gs_om -t switch --reset --time-out=300Operating: Switch reset.

cm_ctl: cmserverisrebalancing the cluster automatically.

......

cm_ctl: switchover successfully.

Operation succeeded: Switch reset.

4、错误排查

如果重置实例状态失败，请根据日志文件中的日志信息排查错误。

如果指定的超时时间到达后，仍然有某些实例没有完成状态切换，可以根据提示，执行3查看切换实例的当前状态，然后设置更长的时间再次执行或者通过log查看切换失败的原因。重置操作的默认超时时间为300s。

三、处理CN异常

集群部署多个CN同时对外提供服务，CN的角色是对等的，即执行DML语句时连接到任何一个CN都可以得到一致的结果。而DDL语句需要在所有CN上都执行完成，以保持数据库对象定义一致。如果其中一个CN发生故障，整个集群将无法执行DDL语句，直到故障CN被修复或剔除。

如果只有CN异常，使用gs_replace工具可以快速将故障CN替换为正常CN。具体请参见修复故障实例。

如果因网络无法连接、硬件故障造成操作系统无法登录等，短时间内无法恢复CN，又希望集群尽快恢复DDL执行能力，可以先手动删除故障CN。待DDL业务完成后，再通过增加CN功能将CN加回。

GaussDB Kernel也提供了CN自动剔除功能，此功能默认开启，开启和关闭方式请参见自动剔除故障CN。通过设置coordinator_heartbeat_timeout为具体的时间值，则CN故障超过此时间值后GaussDB Kernel将自动剔除故障CN。

多AZ多集群部署结构下：

• AZ的拓扑结构应当保持相同（由运维人员保证），应当对所有集群进行同样的增删CN操作，成功后集群再开始同步操作。
• CN部署结构变化，可能将引起Roach做全量同步，具体以Roach的约束为准
• 增删CN开始时，会自动停止Roach的自动同步操作，完成或者回滚后，需要用户手动恢复自动同步配置。

1、删除CN

1.1 操作场景

在集群运行过程中，CN发生故障后，整个集群将无法执行DDL操作。因此，如果CN发生故障且无法快速修复时，可以使用gs_om中的managecn把故障CN从数据库集群中删掉，从而使集群可以快速恢复正常工作。

1.2 注意事项

• “cluster_state”为“Unavailable”时，将无法执行删除CN操作。
• 一次仅允许删除一个CN。
• 如果因CN故障造成集群处于Degraded状态，此时如果执行删除CN操作，必须先删除因故障被剔除的CN，之后才能删除其他CN。
• 若已开启CN自动剔除功能，CM会自动将故障CN剔除，即从pgxc_node中删掉，这样DDL可以正常执行。CN被自动剔除后，不会再被拉起，必须删除CN或通过实例替换、节点替换、温备修复，才能进行扩容、升级等其他操作。
• 删除CN前不能锁定集群，不能执行其他运维及变更类操作。
• 删除完成后集群中至少剩余一个正常的CN。
• 数据库安装用户有足够的权限将新xml文件分发到所有主机的相同目录下。
• 在执行删除CN操作时，建议不要进行数据增删改等DML操作以及DDL操作，以避免数据的丢失。
• 在删除CN操作时，执行删除命令的节点不能是要删除的CN节点。
• 单CN的集群不支持继续缩容操作。
• 3CN以下的集群不建议进行缩容操作，避免缩容过程中或结束后因为CN故障导致集群功能不可用。
• 部署kerberos情况下，同时缩容kerberos server主备ip所在的cn会导致集群异常。

1.3 处理方法

1.以操作系统用户omm登录数据库集群任一主机。

如果所登录的主机因网络或操作系统等故障无法登录，请更换为登录另一集群主机。

2.修改集群XML配置文件clusterconfig.xml。

请将要删除CN对应主机上的cooNum值从1改为0。

<!-- cn -->
<PARAM name="cooNum" value="0"/>
<PARAM name="cooPortBase" value="8000"/>
<PARAM name="cooDir1" value="/gaussdb/data/coordinator"/>

3.使用gs_om工具脚本执行删除CN操作。

gs_om -t managecn -m delete -X /opt/software/GaussDB_Kernel/clusterconfig.xml

1.4 示例

删除集群内部节点上的CN实例。

gs_om -t managecn -m delete -X /opt/software/GaussDB_Kernel/clusterconfig.xml

Checking the cluster configuration difference.

Successfullycheckedthe cluster configuration difference.

Checking the cluster status.

Successfullycheckedthe cluster status.

Distributing the XML configuration file to all nodes.

Successfully distributed the XML configuration file.

Creating backup directory.

Successfully created backup directory.

Backing up cluster configuration.

Successfully backed up cluster configuration.

Modifyingstaticconfiguration files.

Static configuration file's modification is completed.
Locking cluster.

Successfully locked cluster.

Dropping pgxc_node catalog.

Successfully dropped pgxc_node catalog.

Configuring pg_hba on all nodes.

Unlocking cluster.

Successfully unlock cluster.

Waitingforcluster status to become Normal or Degraded.

.

The cluster statusisNormal.

Deleting the CN instance.

Successfully cleaned CN instance.

集群运行过程中，某个含有CN的节点损坏短时间内无法修复（网络无法连接、硬件故障造成操作系统无法登录等），此时会造成其他CN无法执行业务，造成业务中断。此时，可以选择进行节点替换，但耗时较长，为了尽可能的快速恢复业务，可以执行对该节点上的CN删除。以故障节点为SIA1000022048为例：

gs_om -t managecn -m delete -X /opt/software/GaussDB_Kernel/clusterconfig.xml

Checking the cluster configuration difference.

Successfullycheckedthe cluster configuration difference.

Warning: Failed to connect to the node SIA1000022048.

Checking the cluster status.

Successfullycheckedthe cluster status.

Distributing the XML configuration file to all nodes.

Successfully distributed the XML configuration file.

Creating backup directory.

Successfully created backup directory.

Backing up cluster configuration.

Successfully backed up cluster configuration.

Modifyingstaticconfiguration files.

Static configuration file's modification is completed.
Locking cluster.

Successfully locked cluster.

Dropping pgxc_node catalog.

Successfully dropped pgxc_node catalog.

Configuring pg_hba on all nodes.

Successfully configured pg_hba on all nodes.

Unlocking cluster.

Successfully unlock cluster.

Waitingforcluster status to become Normal or Degraded.

...........

The cluster statusisDegraded.

Manage CNis completed.

如果执行完删除节点SIA1000022048的CN后，该节点又从故障中恢复，此时该节点上记录的集群信息为删除CN前的，造成该节点与真实的集群信息不相同，因此需要对该节点执行如下操作，以保障集群信息的统一。

调用gs_om -t generateconf -X /opt/software/GaussDB_Kernel/clusterconfig.xml ，用最新的集群配置文件重新生成各节点的静态配置文件，并覆盖此节点上的静态配置文件。

调用gs_om-t stop -h SIA1000022048和gs_om -t start -h SIA1000022048对该节点进行重启，使得新的集群配置信息生效。

手动删除节点SIA1000022048上的CN数据目录（选做）。

2、增加CN

2.1 操作场景

当集群中的CN数量无法承载业务运行压力时，可以通过gs_om的managecn功能给集群增加CN。同时，如果CN因故障被删除后，可以使用增加CN功能将其加回。

2.2 前提条件

• 增加CN需要集群处于Normal状态。
• 在已有主机上增加CN，需要提前创建CN的数据目录、日志目录。
• 在新增主机上增加CN，需要在配置文件中新增新主机的CM路径并使用gs_preinstall工具准备好新主机的环境。
• 需要在一个状态正常的主机上执行操作。

2.3 注意事项

• 一次仅允许增加一个CN。
• 增加CN前不能锁定集群，不能执行引起集群状态或结构变化的其他运维操作。
• 数据库安装用户有足够的权限将新xml文件分发到所有主机的相同目录下。
• 增加CN过程中集群可以执行业务，特别说明：由于过程中会短暂锁集群，锁集群后用户下发的包含显式启动事务的DDL语句会出现等待，集群解锁后会报错或等待时间超过20分钟会报错。如包含创建临时表操作，在集群解锁后会报错（Don’t support temp table when need reconnect pooler）。
• 增加、删除CN过程中系统将关闭“自动剔除故障CN”功能，在完成后系统再次打开该功能。

2.4 处理方法

1.以操作系统用户omm登录数据库集群任一主机。

2.修改集群XML配置文件clusterconfig.xml。

在已有主机上新增CN，请将要增加CN对应主机上的cooNum值从0改为1。

<!-- cn -->
<PARAM name="cooNum" value="1"/>
<PARAM name="cooPortBase" value="8000"/>
<PARAM name="cooDir1" value="/gaussdb/data/coordinator"/>

在新增主机上增加CN，要求该主机上只能配有CN，不能包含DN、GTM、CM Server及ETCD。如下以增加集群外的主机SIA1000056772上的CN为例：

<!-- SIA1000056772的实例部署信息 -->
  <DEVICE sn="1000002">
   <PARAM name="name" value="SIA1000056772"/>
   <PARAM name="backIp1" value="10.180.122.136"/>
   <PARAM name="sshIp1" value="10.180.122.136"/>

   <!--cmserver-->
   <PARAM name="cmsNum" value="0"/>
   <PARAM name="cmServerPortBase" value="28601"/>
   <PARAM name="cmServerPortStandby" value="28611"/>
   <PARAM name="cmServerlevel" value="1"/>
   <PARAM name="cmDir" value="/data_rt/bigcluster_rt/cmserver"/>
   <PARAM name="cmServerRelation" value="SIA1000056772,SIA1000056672"/>

   <!-- cn -->
   <PARAM name="cooNum" value="1"/>
   <PARAM name="cooPortBase" value="8000"/>
   <PARAM name="cooDir1" value="/gaussdb/data/coordinator"/>

   <!-- gtm -->
   <PARAM name="gtmNum" value="0"/>
   <PARAM name="gtmPortBase" value="6000"/>
   <PARAM name="gtmPortStandby" value="6500"/>
   <PARAM name="gtmDir1" value="/data_rt/bigcluster_rt/gtm,SIA1000056672,/data_rt/bigcluster_rt/gtm"/>
   <PARAM name="gtmRelation" value="SIA1000056772,SIA1000056672"/>

  </DEVICE> 

3.进入安装包解压出的script目录下，执行下面命令为增加CN准备好前置环境。

./gs_preinstall -U  -G dbgrp -L -X /opt/software/GaussDB_Kernel/clusterconfig.xml --alarm-type=5

4.使用gs_om工具脚本进行增加CN操作。

gs_om -t managecn -m add -X /opt/software/GaussDB_Kernel/clusterconfig.xml

5.（可选）如果增加CN前修改过CN的GUC参数：log_dir，listen_addresses，local_bind_address，port，pgxc_node_name，pooler_port，log_directory和audit_directory。增加CN成功后，新CN无法同步先前的修改。请使用gs_guc工具以reload方式修改重新修改CN上的这些GUC参数。

2.5 示例

增加集群内部节点上的CN实例。

gs_om -t managecn -m add -X /opt/software/GaussDB_Kernel/clusterconfig.xml

Checking the cluster configuration difference.

Successfullycheckedthe cluster configuration difference.

Checking the cluster status.

Successfullycheckedthe cluster status.

Distributing the XML configuration file to all nodes.

Successfully distributed the XML configuration file.

Creating backup directory.

Successfully created backup directory.

Backing up cluster configuration.

Successfully backed up cluster configuration.

Modifyingstaticconfiguration files.

Static configuration file's modification is completed.
Locking cluster.

Successfully locked cluster.

Building CN instance.

Successfully built CN instance.

Creating pgxc_node catalog.

Successfully created pgxc_node catalog.

Configuring pg_hba on all nodes.

Unlocking cluster.

Successfully unlock cluster.

Waitingforcluster status to become Normal or Degraded.

.

The cluster statusis Normal.

gs_om -t managecn -m add -X /opt/software/GaussDB_Kernel/clusterconfig.xml

Checking the cluster configuration difference.

Successfullycheckedthe cluster configuration difference.

Checking the cluster status.

Successfullycheckedthe cluster status.

Distributing the XML configuration file to all nodes.

Successfully distributed the XML configuration file.

Creating backup directory.

Successfully created backup directory.

Installing GaussDB Kernel on thenewnode.

Checking installation environment onthisnode (SIA1000062209).

Installing applications onthisnode (SIA1000062209).

Synchronizing libcgroup configuration tothisnode (SIA1000062209).

Successfully installed GaussDB Kernel on thenewnode.

Backing up cluster configuration.

Successfully backed up cluster configuration.

Modifyingstaticconfiguration files.

Static configuration file's modification is completed.
Locking cluster.

Successfully locked cluster.

Building CN instance.

Successfully built CN instance.

Creating pgxc_node catalog.

Successfully created pgxc_node catalog.

Configuring pg_hba on all nodes.

Unlocking cluster.

Successfully unlock cluster.

Waitingforcluster status to become Normal or Degraded.

.

The cluster statusis Normal.

gs_guc set -Z cmserver -N all -I all -c "coordinator_heartbeat_timeout=25"

gs_guc set -Z cmserver -N all -I all -c "coordinator_heartbeat_timeout=0"

cm_ctl disable -n node_id -D data_path

node_id为CN所在节点的ID，data_path为CN的数据目录路径，可通过cm_ctl query-Cvd查询。

gs_replace -t config -h hostname

gs_replace -t start -h hostname

(if [ -f $PGHOST/GaussReplace.dat ];then rm $PGHOST/GaussReplace.dat;fi)

gs_replace -t config -h plat1, plat2

gs_replace -t start -h plat1 , plat2

gs_om -t switch --reset

gs_om -t status

cm_ctl query -Cvd

CN :

node             instance                     state-----------------------------------------------------
1  lfgp000710736 5001 /data1/mpp/coordinator1 Normal2  lfgp000710735 5002 /data1/mpp/coordinator2 Normal3  lfgp000710734 5003 /data1/mpp/coordinator3 Normal

3  lfgp000710734 6017 /data1/mpp/data1/master09 P Down    Disk damaged | 1  lfgp000710736 6018 /data1/mpp/data1/slave09  S Down    Unknown | 2  lfgp000710735 3010 /data1/mpp/data1/dummy09  R Secondary Normal

cm_ctl stop -n nodenumber -D CN所在目录

cm_ctl stop-n nodenumber -D DN所在目录

cm_ctl stop -n 1 -D /data1/mpp/coordinator1

cm_ctl stop-n 2 -D /data1/mpp/coordinator2

cm_ctl stop-n 3 -D /data1/mpp/coordinator3

cm_ctl stop-n 1 -D /data1/mpp/data1/slave09

cm_ctl stop-n 2 -D /data1/mpp/data1/dummy09

gs_ctl restore -D /data1/mpp/data1/slave09

cm_ctl start -n 2 -D /data1/mpp/data1/dummy09

cm_ctl start -n 3 -D /data1/mpp/data1/master09

cm_ctl start -n 1 -D /data1/mpp/coordinator1

cm_ctl start-n 2 -D /data1/mpp/coordinator2

cm_ctl start-n 3 -D /data1/mpp/coordinator3

cm_ctl query –Cvd

cd /opt/software/GaussDB_Kernel/script

./gs_preinstall -U omm -G dbgrp -X ../clusterconfig.xml --alarm-type=5

su - omm

gs_om -t changeip -X clusterconfig.xml

clusterconfig.xml为修改后的配置文件。

gs_om -t changeip -X clusterconfig.xml --rollback

一、检查点的方式有哪些:

主要是python 内置的assert 断言（自动断言）还有locust 中的catch_response 断言（手动断言）；那么这两者之间有什么区别呢？

其实主要区别在与生成locust 报告上面，手动断言失败，我们在locust上面可以清楚的看到报错信息，如果通过内置断言，即使断言失败

我们也看不到错误信息

二、**手动断言**

代码实现

@task
def login(self):
with self.client.post('/login', json={'username': 'admin', 'password': '<PASSWORD>'},name='登录',catch_response=True)as response:
if json.loads(response.text)['status'] == 'success':
response.success()
else:
response.failure("登录失败")

三、**自动断言（assert)**

在 golang中，想要并发安全的操作map，可以使用sync.Map结构，sync.Map 是一个适合读多写少的数据结构，今天我们来看看它的设计思想，来看看为什么说它适合读多写少的场景。

如下，是golang 中sync.Map的数据结构，其中 属性read 是 只读的 map，dirty 是负责写入的map，
sync.Map中的键值对value值本质上都是entry指针类型，entry中的p才指向了实际存储的value值
。

// sync.Map的核心数据结构
type Map struct {
    mu Mutex                        // 对 dirty 加锁保护，线程安全
    read atomic.Value                 // read 只读的 map，充当缓存层
    dirty map[interface{}]*entry     // 负责写操作的 map，当misses = len(dirty)时，将其赋值给read
    misses int                        // 未命中 read 时的累加计数，每次+1
}
// 上面read字段的数据结构
type readOnly struct {
    m  map[interface{}]*entry // 
    amended bool // Map.dirty的数据和这里read中 m 的数据不一样时，为true
}

// 上面m字段中的entry类型
type entry struct {
    // value是个指针类型
    p unsafe.Pointer // *interface{}
}

我们从一个
sync.Map的数据写入和数据查询
两个过程来分析这两个map中数据的变化。

我将不展示具体的代码，仅仅讲述数据的流动，相信懂了这个以后再去看代码应该不难。

步骤一:
首先是一个初始的sync.Map 结构，我们往其中写入数据，数据会写到dirty中，同时，由于sync.Map 刚刚创建，所以read map还不存在，所以这里会先初始化一个read map 。
amended
是read map中的一个属性，为true代表 dirty 和read中数据不一致。

步骤二:
接着，如果后续再继续写入新数据，
在read map没有从dirty 同步数据之前，即
amended
变为false之前，再写入新键值对都只会往dirty里写。

步骤三:
如果有读操作，sync.Map 都会尽可能的让其先读read map，read map读取不到并且
amended
为true，即read 和dirty 数据不一致时，会去读dirty，读dirty的过程是上锁的。

步骤四:
当读取read map中miss次数大于等于dirty数组的长度时，会触发dirty map整体更新为readOnly map，并且这个过程是阻塞的。更新完成后，原先dirty会被置为空，
amended
为false，代表read map同步了之前所有的数据
。如下图所示，

整体更新的逻辑是直接替换变量的值，并非挨个复制，

func (m *Map) missLocked() {
    m.misses++
    if m.misses < len(m.dirty) {
        return
    }
    
    // 将dirty置给read，因为穿透概率太大了(原子操作，耗时很小)
    m.read.Store(readOnly{m: m.dirty})
    m.dirty = nil
    m.misses = 0
}

步骤五:
如果后续sync.Map 不再插入新数据
，那么读取时就可以一直读取read map中的数据了，直接读取read map 中的key是十分高效的，只需要用atomic.Load 操作 取到readOnly map结构体，然后从中取出特定的key就行。

如果读miss了，因为没有插入新数据，
read.amended=false
代表read 是保存了所有的k，v键值对，读miss后，也不会再去读取dirty了，也就不会有读dirty加锁的过程。

// 上面read字段的数据结构
type readOnly struct {
    m  map[interface{}]*entry // 
    amended bool // Map.dirty的数据和这里read中 m 的数据不一样时，为true
}

func (m *Map) Load(key interface{}) (value interface{}, ok bool) {
    // 因read只读，线程安全，优先读取
    read, _ := m.read.Load().(readOnly)
    e, ok := read.m[key]
    
    // 如果read没有，并且dirty有新数据，那么去dirty中查找（read.amended=true：dirty和read数据不一致）
    // 暂时省略 后续代码
    .......
	
    }

上面的获取key对应的value过程甚至比RWMutex 读锁下获取map中的value还要高效，毕竟RWmutex 读取时还需要加上读锁，其底层是用
atomic.AddInt32
操作，而sync.Map 则是用
atomic.load
获取map，
atomic.AddInt32
的开销比
atomic.load
的开销要大。

最近在开发基于golang下的cqrs框架
https://github.com/berkaroad/squat
（陆续开发中，最近断了半年，懒了。。。）。这个框架依赖ioc框架，因为之前写了一个ioc，所以借此完善下，主要从灵活性、易用性、性能角度进行了优化。顺带也支持了go mod，并将源码文件合并为单文件，方便有直接移植源码的人（license信息请保留，尊重著作权）。

先来个直观的调用端对比（v1.2.0为新版，v0.1.1为旧版）：

var container = ioc.NewContainer() // v0.1.1
var container = ioc.New() // v1.2.0，非必需，可以直接使用ioc.XXX 即使用内置全局Container

// register service to *struct
container.Register(&Class2{Name: "Jerry Bai"}, ioc.Singleton) // v0.1.1
ioc.AddSingleton[*Class2](&Class2{Name: "Jerry Bai"}) // v1.2.0
container.Register(&Class1{}, ioc.Transient) // v0.1.1，调用函数InitFunc()获取初始化函数来完成初始化
ioc.AddTransient[*Class1](func() *Class1 { // v1.2.0，直接通过传入的函数来完成
    var svc Class1
    // inject to *struct
    ioc.Inject(&svc) // v1.2.0，支持注入到结构体
}

// register service to interface.
container.RegisterTo(&Class2{Name: "Jerry Bai"}, (*Interface2)(nil), ioc.Singleton) // v0.1.1
ioc.AddSingleton[Interface2](&Class2{Name: "Jerry Bai"}) // v1.2.0
container.RegisterTo(&Class1{}, (*Interface1)(nil), ioc.Transient) // v0.1.1，调用函数InitFunc()获取初始化函数来完成初始化
ioc.AddTransient[Interface1](func() Interface1 { // v1.2.0，直接通过传入的函数来完成
    var svc Class1
    // inject to *struct
    ioc.Inject(&svc) // v1.2.0，支持注入到结构体
}

// inject to function
ioc.Inject(func(c1 *Class1, c2 *Class2, i1 Interface1, i2 Interface2, resolver ioc.Resolver) { // v1.2.0
    println("c1.C2Name=", c1.C2.Name)
    println("c2.Name=", c2.Name)
    println("i1.GetC2Name=()", i1.GetC2Name())
    println("i2.GetName=()", i2.GetName())
})
container.Invoke(func(c1 *Class1, c2 *Class2, i1 Interface1, i2 Interface2, roContainer ioc.ReadonlyContainer) { // v0.1.1
    println("c1.C2Name=", c1.C2Name)
    println("c2.Name=", c2.Name)
    println("i1.GetC2Name=()", i1.GetC2Name())
    println("i2.GetName=()", i2.GetName())
})

新版本，从功能角度，增加支持了结构体注入、泛型方式获取服务实例、替换已存在的服务。

// get service from ioc（go1.18开始支持泛型）
c1 := ioc.GetService[*Class1]
c2 := ioc.GetService[*Class2]
i1 := ioc.GetService[Interface1]
i2 := ioc.GetService[Interface2]

// override exists service（一般用于覆盖默认注入的对象）
c := ioc.New()
ioc.SetParent(c)
ioc.AddSingletonToC[Interface3](c, &Class3{Name: "Jerry Bai"}) // add service to parent's container
i3 := ioc.GetService[Interface3]() // *Class3, 'Interface3' only exists in parent's container
ioc.AddSingleton[Interface3](&Class4{Name: "Jerry Bai"}) // add service to global's container
i3 = ioc.GetService[Interface3]() // *Class4, 'Interface3' exists in both global and parent's container

对结构体初始化的函数定义（模拟构造函数），从固定获取函数的接口
interface{InitFunc() interface{}}
改为按函数名获取（默认为
Initialize
）。

type Class2 struct {
    Name     string
    resolver ioc.Resolver
}

func (c *Class2) Initialize(resolver ioc.Resolver) string {
    c.resolver = resolver
    return c.Name
}

type Class3 struct {
    Name     string
    resolver ioc.Resolver
}

// specific custom initialize method name
func (c *Class3) InitializeMethodName() string {
    return "MyInitialize"
}

// custom initialize method
func (c *Class3) MyInitialize(resolver ioc.Resolver) string {
    c.resolver = resolver
    return c.Name
}

以下是新版本的性能测试。带 “Native” 的为原生调用，具体测试代码，参见源码：
https://github.com/berkaroad/ioc/blob/master/benchmark_test.go

go test -run=none -count=1 -benchtime=1000000x -benchmem -bench=. ./...

goos: linux
goarch: amd64
pkg: github.com/berkaroad/ioc
cpu: AMD Ryzen 7 5800H with Radeon Graphics         
BenchmarkGetSingletonService-4           1000000                26.16 ns/op            0 B/op          0 allocs/op
BenchmarkGetTransientService-4           1000000               370.9 ns/op            48 B/op          1 allocs/op
BenchmarkGetTransientServiceNative-4     1000000               131.9 ns/op            48 B/op          1 allocs/op
BenchmarkInjectToFunc-4                  1000000               659.5 ns/op           144 B/op          5 allocs/op
BenchmarkInjectToFuncNative-4            1000000                89.26 ns/op            0 B/op          0 allocs/op
BenchmarkInjectToStruct-4                1000000               311.7 ns/op             0 B/op          0 allocs/op
BenchmarkInjectToStructNative-4          1000000                87.64 ns/op            0 B/op          0 allocs/op
PASS
ok      github.com/berkaroad/ioc        1.686s

---------------------------------分割线-------------------------------------------------------------

我的
ioc项目
，已经挂在github上，有兴趣的可以去了解下。
https://github.com/berkaroad/ioc

使用中有何问题，欢迎在github上给我提issue，谢谢！

本文为从零开始写 Docker 系列第七篇，实现类似 docker commit 的功能，把运行状态的容器存储成镜像保存下来。

完整代码见：
https://github.com/lixd/mydocker
欢迎 Star

推荐阅读以下文章对 docker 基本实现有一个大致认识：

• 核心原理
  ：
  深入理解 Docker 核心原理：Namespace、Cgroups 和 Rootfs
• 基于 namespace 的视图隔离
  ：
  探索 Linux Namespace：Docker 隔离的神奇背后
• 基于 cgroups 的资源限制
  
  • 初探 Linux Cgroups：资源控制的奇妙世界
  • 深入剖析 Linux Cgroups 子系统：资源精细管理
  • Docker 与 Linux Cgroups：资源隔离的魔法之旅
• 基于 overlayfs 的文件系统
  ：
  Docker 魔法解密：探索 UnionFS 与 OverlayFS
• 基于 veth pair、bridge、iptables 等等技术的 Docker 网络
  ：
  揭秘 Docker 网络：手动实现 Docker 桥接网络

开发环境如下：

root@mydocker:~# lsb_release -a
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 20.04.2 LTS
Release:	20.04
Codename:	focal
root@mydocker:~# uname -r
5.4.0-74-generic

注意：需要使用 root 用户

1. 概述

由于之前使用 pivotRoot + overlayfs 技术 将
/root/merged
目录作为容器的 rootfs，因此容器中的所有改动都发生在该目录下。

这里我们的
mydocker commit
命令只需要把该目录保存下来即可，因此简单实现为 使用 tar 命令将
/root/merged
目录打成 tar 包

2. 实现

具体流程

整个打包流程如下图所示：

commitCommand

在 main_ command.go 文件中实现 commitCommand 命令,从用户的输入获取image name。

var commitCommand = cli.Command{
	Name:  "commit",
	Usage: "commit container to image",
	Action: func(context *cli.Context) error {
		if len(context.Args()) < 1 {
			return fmt.Errorf("missing image name")
		}
		imageName := context.Args().Get(0)
		commitContainer(imageName)
		return nil
	},
}

然后在 main 方法中添加 commit 命令：

func main() {
    app := cli.NewApp()
    app.Name = "mydocker"
    app.Usage = usage

    app.Commands = []cli.Command{
       initCommand,
       runCommand,
       commitCommand,
    }
    // 省略其他
}

commitContainer

添加 commit.go文件，通过 commitContainer 函数实现将容器文件系统打包成
$ {imagename}.tar
文件。

func commitContainer(imageName string) {
	mntPath := "/root/merged"
	imageTar := "/root/" + imageName + ".tar"
	fmt.Println("commitContainer imageTar:", imageTar)
	if _, err := exec.Command("tar", "-czf", imageTar, "-C", mntPath, ".").CombinedOutput(); err != nil {
		log.Errorf("tar folder %s error %v", mntPath, err)
	}
}

3. 测试

测试流程如下：

• 1）启动容器
• 2）创建新文件
• 3）新终端中将容器打包为镜像
• 4）解压该镜像，查看 2 中的内容是否存在

首先，启动容器

root@mydocker:~/feat-commit/mydocker# ./mydocker run -it /bin/sh
{"level":"info","msg":"resConf:\u0026{ 0  }","time":"2024-01-19T16:18:24+08:00"}
{"level":"info","msg":"busybox:/root/busybox busybox.tar:/root/busybox.tar","time":"2024-01-19T16:18:24+08:00"}
{"level":"info","msg":"mount overlayfs: [/usr/bin/mount -t overlay overlay -o lowerdir=/root/busybox,upperdir=/root/upper,workdir=/root/work /root/merged]","time":"2024-01-19T16:18:24+08:00"}
{"level":"info","msg":"command all is /bin/sh","time":"2024-01-19T16:18:24+08:00"}
{"level":"info","msg":"init come on","time":"2024-01-19T16:18:24+08:00"}
{"level":"info","msg":"Current location is /root/merged","time":"2024-01-19T16:18:24+08:00"}
{"level":"info","msg":"Find path /bin/sh","time":"2024-01-19T16:18:24+08:00"}

创建一个文件

/ # echo KubeExplorer > tmp/hello.txt
/ # cat /tmp/hello.txt
KubeExplorer

接着另外打开 terminal 执行 mydocker commit 命令，将当前容器提交为镜像

root@mydocker:~/feat-commit/mydocker# ./mydocker commit myimage
commitContainer imageTar: /root/myimage.tar

再次查看／root 目录的内容，多了 myimage.tar 文件，这个就是我们的镜像文件了

root@mydocker:~# ls
busybox  busybox.tar merged  myimage.tar  upper  volume  work

查看 myimage.tar 中内容：

root@mydocker:~# tar -tf myimage.tar |grep hello.txt
./tmp/hello.txt

可以看到，前面在容器中创建的 hello.txt 是存在的。

4. 总结

本篇 mydocker commit 比较简单，就是使用 tar 命令将 rootfs 直接进行打包，没有太多需要注意的地方。

镜像构造部分到此就基本完成了，总结一下：

• 1）首先使用 busybox 作为基础镜像创建了一个容器，理解了什么是 rootfs，以及如何使用 rootfs 来打造容器的基本运行环境。

• 2）然后，使用 overlayfs 来构建了一个拥有二层模式的镜像，对于最上层可写层的修改不会影响到基础层。这里就基本解释了镜像分层存储的原理。

• 3）之后使用 -v 参数做了一个 volume 挂载的例子，介绍了如何将容器外部的文件系统挂载到容器中，并且让它可以访问。

• 4）最后（本文）实现了一个简单版本的容器镜像打包。

这一章主要针对镜像的存储及文件系统做了基本的原理性介绍，通过这几个例子，可以很好地理解镜像是如何构建的，后续会基于这些基础做更多的扩展。

【从零开始写 Docker 系列】
持续更新中，搜索公众号【
探索云原生
】订阅，阅读更多文章。

完整代码见：
https://github.com/lixd/mydocker
欢迎 Star

相关代码见
feat-volume
分支,测试脚本如下：

需要提前在 /root 目录准备好 busybox.tar 文件，具体见第四篇第二节。

# 克隆代码
git clone -b feat-commit https://github.com/lixd/mydocker.git
cd mydocker
# 拉取依赖并编译
go mod tidy
go build .
# 测试 
./mydocker run -it  /bin/ls
./mydocker commit