CITA-Cloud的设计理念是尽量复用现有软件或者库来搭建区块链系统。
但是区块链系统和传统的软件一个非常显著的区别是，区块系统是一个对等网络，而传统软件一般都是C/S或者Master/Slave形态。
所以在区块链设计中就有一个常见的模式，把非对等形态的软件变为对等形态。
比较简单的做法就是所有节点都是Server，同时又是其他节点的Client。
比如，CITA-Cloud网络微服务的实现 GitHub - cita-cloud/network_direct。以及现有的CITA的早期的直连网络实现也是如此。
可以认为是把系统自带的网络库提供的Server/Client形态的功能转换为对等网络。
这个方案实现上其实比较简单，麻烦的是生成配置文件，以及后续增加删除节点时修改配置文件。
生成配置文件可以参见CITA-Cloud中生成网络的配置文件：
runner_k8s/create_k8s_config.py at master · cita-cloud/runner_k8s · GitHub
前提是需要提供已知的所有节点的ip和port信息。
遍历所有的peers，为每个peer生成一个net_config。
port是本节点的监听端口，用于启动Server。
peers是除自己之外的其他节点的信息，用于本节点作为Client去连接其他节点。
因为需要所有节点信息才能生成对应的配置文件，所以需要集中统一生成，但是对于联盟链来说问题不大，这些信息可以认为是对内公开的。
同样，增加删除节点的时候，也涉及到所有配置文件的修改，需要集中修改，生成新的配置文件，然后下发到所有的节点。
另外一个例子是 GitHub - cita-cloud/controller_poc，其中的同步模块使用了Syncthing。
Syncthing是一个文件同步工具，默认情况下是Master/Slave形态。
也是通过类似的方式，实现了一个对等模式的同步网络，任何一个节点增加的文件都会同步到其他节点去。
生成配置文件的代码参见
runner_k8s/create_k8s_config.py at master · cita-cloud/runner_k8s · GitHub
如果要解决这种集中生成/修改配置文件的情况，网络部分就需要P2P网络库。
其本质是跟上述解决方案类似，只是节点之间会相互转发配置信息。这样新增或者删除节点，只要发送相应的配置命令到任意一个节点上，该节点就会将相应的变动转发给其他节点。
一开始搭建网络的时候有多个初始节点的情况，也可以转换为初始只有一个节点，其他节点都视为是动态新增的方案。
这个对于公链这样的无权限区块链系统来说非常有必要。但是对于联盟链这样有权限的区块链系统来说，必要性没那么强。因为即便可以方便的动态增加删除节点，依然需要一个中心化的地方来修改相应的鉴权信息。比如用证书来实现节点网络的准入，那么增加/删除节点肯定需要在对应的CA处先颁发或者吊销相应节点的证书。