联盟链与Kubernetes的比较

联盟链与Kubernetes很多方面都非常类似，但是又存在一些细节上的差异。

分布式技术

Kubernetes中的关键组件etcd使用了Raft一致性算法，跟联盟链常用的PBFT共识算法作用是类似的。

只不过Kubernetes针对的还是中心化场景，使用分布式技术的目的仅仅是为了保持系统的高可用性，因此选择的算法是非拜占庭容错的。而联盟链针对的是去中心化场景，其安全假设是不同的，可能存在恶意节点，因此选择的是拜占庭容错算法。

两种技术比较明显的区别是信任的边界不同。

etcd的节点都在一个机房内，节点间是相互信任的，其安全边界是在整个系统外面。只要通过防火墙等安全措施把入口控制，整个系统的安全问题就解决了。

联盟链的节点分散在不同的机构，节点间是相互不信任的，其安全边界在节点间。无法像中心化系统一样，通过控制入口来解决安全问题，必须使用签名等密码学方案来保证数据的安全，这其实也符合近年来提出的零信任安全。

可扩展性

联盟链一般都拥有图灵完备的虚拟机，用户可以通过智能合约扩展联盟链的功能。

接口方面，联盟链一般采用RPC的方式，只提供少量通用的接口，比如发送交易，调用合约。调用时的参数按照事先约定的格式以二进制发的方式传递，因此少量接口就可以适用于不同的合约。当然客户端就需要针对不同的合约做一些额外的处理，但是一般SDK里都提供了相应的辅助功能，比如根据合约的ABI自动生成调用的代码。

Kubernetes也是高度可扩展的。其中一种方式是Operator模式。一个Operator是由用户自定义资源（CRD）和对应的Controller软件组成的。其中CRD相当于联盟链中智能合约的存储部分，因为etcd只有存储的功能，没有执行代码的功能。对应的Controller软件则相当于智能合约代码部分的链外形式，再加上一些客户端的处理。

接口方面，Kubernetes的apiserver提供的是Restful风格的API。每个资源，都对应一个API对象，对应唯一的URL。针对用户自定义的资源，也可以通过插件的方式扩展apiserver对其进行支持。

辅助工具方面有Kubebuilder之类的工具可以生成代码并提供一些脚手架代码，简化Operator的开发。有点类似于以太坊生态中Truffle之类的框架。

治理

Kubernetes针对的还是中心化场景，只是针对多租户的场景有一些Namespace和权限的功能。etcd针对节点有一些基本的管理功能，比如增加删除节点，提供节点为投票节点等。

联盟链在治理方面的功能要强大得多。CITA针对企业场景提供了基于角色的权限系统，支持动态增加删除共识节点，还有运维相关的紧急制动和数据订正。除此之外，CITA还提供了委员会式的系统管理，每一个系统配置的修改都需要经过委员会成员的投票表决。针对有token的场景，联盟链还可以给节点运维方一些经济激励，给开发者或者早期的终端用户进行定向的补贴。

联盟链与Kubernetes融合

底层融合

随着云原生的推广，Kubernetes也碰到了一些去中心化的场景。比如，客户出于隐私/安全/不想绑定单一云供应商等因素而出现的混合云。比如监控/5G等边缘设备大量部署后出现的边缘计算。以边缘计算比较常见的云边协同场景为例。边缘设备采集数据，在云上调集大量的计算资源训练模型，然后把模型下发到边缘设备进行使用。

在这些场景中，系统的一些组件需要运行在不受控的环境中，因此就出现了零信任安全，可信计算，以及治理方面的需求。

联盟链可以很好的解决这些问题。联盟链的账户系统采用公钥体系，本身就符合零信任安全的要求。联盟链强大的治理功能也能填补Kubernetes在治理方面的缺失。最后联盟链可以视为一种基于多副本的可信计算环境。通过多个节点执行同样的任务，并以哈希的方式对比结果，只有多数节点的结果一致的情况下才能得到认可。再加上链式结构，保证历史是不可篡改的，从而保证结果是可信的。

得益于Kubernetes良好的架构，具体的融合方案都多种方式：

• 最简单粗暴的方式是用联盟链直接替换etcd。

  Kubernetes和etcd在部署上是分开的，替换操作理论上是可行的。但是在功能上Kubernetes跟etcd是深度绑定的，依赖了很多etcd独有的特性，希望Kubernetes后续可以考虑跟etcd解耦。

  这种方式的优点是：联盟链可以拿到集群所有的元信息，未来的发展空间更大；改造后Kubernetes既支持原有的中心化场景，同时也支持去中心化场景，功能几乎不受损失。

• 联盟链作为Controller。

  这种方式类似于一些Kubernetes的跨集群方案。多个集群，每个集群里都安装同一个联盟链的一个节点，相当于在多个集群上面增加一层联盟链。

  这种方式的优点是底层修改比较小，很容易实施，联盟链节点的运维可以受益于Kubernetes的功能。缺点是功能比较受限，对于应用来说，需要增加新的资源类型，应用层需要有些适配。

• 开放服务代理。

  开放服务代理是一种API规范，它能让Kubernetes集群中运行的应用很容易的使用外部托管的的软件服务。这种方式是最简单的，双方都不需要有任何的修改，只需要进行简单的适配，就可以将联盟链的功能提供给集群中的应用，但是功能上也是受限最多的。

业务层融合

云原生以容器技术为基础，在集群资源管理和调度方面取得了巨大的成功。在更进一步的服务网格技术中，使用同样的架构，可以对集群中的应用进行更精细的流量管理。

CNCF通过社区的力量，也积累了大量的扩展组件，基本覆盖了企业应用的方方面面，其中很多已经得到广泛应用。

双方融合的解决方案可以复用云原生的软件栈，会更贴近企业应用，在易用性上优于传统的联盟链解决方案。如果企业已经使用Kubernetes，则可以大大降低企业的切换成本。

在双方融合的视角下，Kubernetes最有价值的是它针对集群调度场景抽象出了Pod，Service等资源类型。这其实对应传统联盟链解决方案中用户在智能合约中对业务进行建模的过程。双方融合之后，配合上联盟链灵活的智能合约能力，可以很容易扩展到更多的应用场景。

同时，借助联盟链去中心化的特点，可以把现有的企业应用的范围从企业内扩展到企业间，为分布式商业打下基础。

联盟链强大的治理功能，也能够将Kubernetes收集的各种度量数据利用起来，在去中心化场景中为企业间服务提供更细粒度的结算能力。

区块链在密码学和可信计算方面也有大量的技术储备，这些技术与集群管理和企业应用的结合也非常有想象空间。

总结

本文提出了将联盟链和Kubernetes深度融合的企业应用解决方案。两者强强联合，在易用性，使用成本，场景适应性方面都优于现有解决方案。

因此，在我们的下一代产品（CITA-Cloud）中，将抛弃原有的联盟链的思路和产品定位，也将抛弃SDK，钱包，区块链浏览器的工具链组合。采用本文所述方案，为企业应用场景提供更好的产品和解决方案，更好的服务企业用户。

同时我们也秉承着开放的态度，积极寻求CNCF社区的合作和交流，希望联盟链和云原生两个社区能够互相取长补短，共同进步。