部署指南
因为采用微服务架构，相比单体软件来说，运维部署比较复杂。
例如：微服务之间如何相互调用；启动顺序如何保证；配置项如何管理等等。
所幸微服务架构已经非常流行，相应的基础设施也已经非常成熟。其中最重要的一点就是云原生技术的发展，它大大简化了微服务架构的应用在运维部署，配置管理方面的工作。
运行环境
CITA-Cloud推荐的运行环境为k8s集群。
对于开发，可以是
minikube等单机版本的k8s集群。对于测试，可以是几台机器搭建的简单的
k8s集群。对于生产环境，推荐有专人维护的高可用
k8s集群，或者云厂商提供的容器云方案。
其优点是：
不同环境的操作方式是统一的。
功能灵活，强大。可以实现各种复杂的配置，自动化运维等。
生态繁荣。基于云原生社区，有非常多成熟的配套工具和解决方案。
部署一条CITA-Cloud产生的链，除了准备好运行环境，还需要事先进行持久化存储和网络的设置。
持久化存储
链的节点是有状态的服务，需要挂载持久化存储保存数据。
为了方便对接不同类型的存储服务，我们使用了k8s中的PV/PVC概念对存储进行了抽象。
建议由运维人员配置StorageClass，对PV/PVC实行动态绑定。
对于开发环境，可以使用简单的
hostPath，在宿主机本地存储。对于测试环境，可以使用
NFS，由单独一台磁盘比较大的机器提供存储。对于生产环境，推荐使用各种成熟的云存储，分布式存储，
NAS等专业存储系统。
网络
网络方面，需要微服务之间，以及节点之间可以通过网络相互访问。
目前推荐的部署方式是，一个节点一个Pod，里面包含6个微服务的容器。
微服务之间可以直接通过本地环回网络通信。
节点间的网络通信，如果所有节点都在一个k8s集群内部，可以通过k8s的Service来暴露节点的网络端口。如果是跨集群的情况，则需要使用NodePort或者LoaderBalancer等服务对外暴露节点的网络端口。
工具
配置工具
当前的配置工具为cloud-config，用于生成一条链多个节点，以及每个节点内多个微服务的配置文件。
该配置工具支持常用的大部分组件；适用于各种场景，开发或是生产，单集群或者多集群；支持多种配置模式，集中式，去中心化方式。
具体使用方法，请参考代码仓库中的README。
Chart工程
为了简化部署工作，按照云原生的指导原则，提供了Charts工程。
使用Helm工具，可以实现一条命令完成一条链的部署。
注意：
该
Charts工程已经包含了配置功能，无需再单独使用配置工具。该
Charts工程支持多种场景和环境，单集群/多集群，开发环境/公有云环境。
具体使用方法，请参考代码仓库中的README。
Operator
区块链类似于数据库，但与数据库又有一些不同的地方。相同的是都是有状态的服务，不同的是区块链在备份，迁移，升级，扩容等运维操作时都有特殊的要求。
对于备份来说，区块链每个节点都是一个副本，相当于自带热备方案。冷备也跟数据库不一样，不是按时间（比如每天备份），而是要考虑区块高度。
对于迁移和升级来说，区块链的节点是有身份的，因此不能先部署新的节点，再停老的节点，而是要反过来。
对于扩容来说，增加节点并不能提升区块链的性能，反而会造成反效果，只能扩容
cpu，内存。存储也必须所有节点一起扩充。
因此，比较简单的配置部署工作，Charts工程就足以支撑。一旦涉及到比较复杂的运维操作，则需要一些定制开发。而Operator在k8s领域就是用来扩展自定义功能的。
我们的Operator以CRD的形式自定义了Account/Chain/Node等高层的资源类型，并提供了对这些自定义资源的操作方法。进一步简化了配置部署工作，同时也为将来提供复杂的运维功能打下了坚实的基础。
基于Operator的工具有以下几个部分：
Operator本身cita-cloud-operator。代理服务端operator-proxy。
代理客户端
cco-cli。
注意：
Operator已经包含了配置功能，无需再单独使用配置工具。cita-cloud-operator作为一个标准的
Operator可以单独使用。代理服务端和客户端
cco-cli进一步降低了操作难度，无需用户编写yaml文件。
具体使用方法，请参考代码仓库中的README。