编者按：本文来自万向区块链，Odaily星球日报经授权转载。大家晚上好，今天分享的主题是区块链+云原生，为链插上云的翅膀。今天的分享内容主要分为四部分：联盟链传统解决方案介绍；实际案例及问题分析；云原生与联盟链的对比；云原生联盟链解决方案。联盟链传统解决方案介绍
我先简单介绍下联盟链出现的初衷。区块链最早是比特币，后来也出现以太坊等公链。区块链刚开始的时候，尤其是以太坊出现之后，因为有EVM虚拟机，可以有编程能力，所以很早就有人想把现有的商业场景，像支付、电商、信用卡等这样的传统商业场景搬到区块链上来。但是有几个问题：更高的TPS。我们都知道比特币和以太坊的TPS都非常低，根本无法支撑商业应用。更低的能耗。之前的供应链大部分都是用POW算法，能耗耗电非常多，运维一条链的成本非常高。更简单的治理。传统公链里面有矿工、开发者以及其他各方势力，一旦公链上线之后如果想再做新功能开发或者修复bug，都是需要做分叉，这就需要协调各方面，时间会非常长，所以治理是比较复杂的。联盟的初衷大家应该都知道，把共识算法换成基于PBFT之类的共识算法，这样效率就很高，现在基本上像CITA能够做到1.5万以上的TPS。因为是基于投票也不需要耗电去挖矿，所以能耗也降下来了，整个运维一条链的成本也非常低。治理的话，联盟链可以认为是一种实名制的参与方，它都是企业，而且大家都是相互知道有合作的场景，所以才会加到一个联盟链里，所以治理起来会简单很多。在应用方面，现有的联盟链解决方案，包括CITA，基本上都沿袭了以太坊的思路，就是所谓的智能合约DApp。如果想开发应用，就用solidity智能合约语言去写出合约来实现业务逻辑。客户端会提供各种语言的SDK，包括区块链浏览器，还有各种钱包，比如说电脑、手机等移动端的钱包。整个链其实定位是作为平台，就像现在的以太坊，有多个Dapp都在一条链上。实际案例及问题分析
案例一：我们与宁波移动一起做了个停车场的场景。停车场的场景比较简单，这里面有几个参与方，一个是停车场的业主，比如说一栋大楼的业主方。还有就是停车场的运维方，因为停车场都不是业主方自己去运维，会找专门的运维公司来做。还有一些设备，比如说停车场有车过来之后抬杆的闸机，这设备一般是由专门的厂商来提供。这牵涉到几方的合作，停车场收到钱之后就要按照事先商定好的比例去分账，这时候一般还会有银行、金融机构进来，可能还会有监管节点。这个场景中，业主方会担心停车场运营方少报账，因为少报账之后相当于这钱它自己拿了，不用和其他参与方去分。这里面做的事情很简单，就说停车场有车过来之后一抬杆，直接通过设备就把账户信息发送到链上去，做一个存证，当然停车场运营方也会出一个账单，会把链上账单和传统运营平台上的账单做对比，来保证信息是无误的。
里面涉及到的系统，其实还是比较复杂的，最底下的终端设备比如说闸机、网络，闸机里面会有SIM卡，通过移动互联网和服务器或者其他系统通信。链是部署在中国移动的BSN上。再上面可能就是停车场的一些管理，例如计费、优惠券、导航等，跟这些业务再结合起来。这个场景是比较简单，但是衍生出来的东西是非常有想象力的。案例二：存证，这应该是区块链最简单、最经典的场景。政链通电子数据存证管理系统，这个地方链其实做的事情非常简单，会有各个不同的部门，比如说电子招投标，招标方先发布招标信息，投标方会去制作电子标书，然后把标书提交过去，可能后面还有各种各样的流程，会有电子文件在不同的参与方之间相互传递。链在这里起的作用非常简单，就是把电子的文件算一下Hash，把文件的Hash值上链。文件本身还是靠传统的下载、邮件方式去传输，作用就是发送的文件接收方能够做一个确认，收到文件之后在区块链上看到已经放入Hash上了，再做一次Hash，和链上做对比，就知道文件确实是你发的，而且中间没有被人篡改过。从链上来说也是非常简单的，但其实它上面可以做的东西也非常多，除了电子招投标，比如说电子档案、数据交换、电子凭证等各种各样的业务。总结一下：解决企业间数据可信的问题。这也是一开始提到的CITA科技是基于区块链来做的系统，解决的就是企业间数据传输可信。业务系统复杂。像刚才举的两个例子，除了链在其中是非常薄的一层或者说占比非常小，它上面、下面可能都有更加复杂的业务系统来做支撑。私有化部署。传统的联盟链解决方案的定位还是在平台中，希望很多应用都来共用同一条链，但在实际实施过程中基本上都是私有化部署的，联盟链的运维其实成本非常低，用几台服务器可以了，系统配置要求也不是很高。基本上一个应用一条链。看了这些场景的特点之后，就可以看到传统的联盟链解决方案在其中有几个问题。1、切换成本太高。这个可能和公链还不太一样，公链面向的更多是2C，或者说面临的场景是一种之前没有出现过的新场景，所以说并没有很多的历史成本。但对于企业市场来说，企业已经在传统的IT系统上投入非常大，而且可能持续了很多年。如果你想让它迁移到区块链上来，把业务系统抛掉，用智能合约solidity把业务逻辑再重新实现一遍，这对企业用户来说是不可接受的。2、生态不成熟。虽然说以太坊在众多区块链项目里算做的比较好，但和传统的IT系统，尤其企业领域的IT系统相比来说成熟度还是差很多。3、平台定位不成立。在具体实施部署的时候基本上都是一个应用一条链，大家不会说要再去共用一个之前的链。云原生与联盟链的对比
云原生是基于容器编排、微服务这样一些技术兴起之后出现的，有CNCF基金会，孵化了很多项目推动了整个生态的发展。当然这里讲的就是K8S，云原生里面最基础也是最重要的系统。
可以先看一下右边的架构图，可以跟区块链的应用架构做对比，它这个etcd也是分布式的系统，可以有多个节点，相互之间会做备份，当然主要是为了高可用性，保存了整个集群的状态。APIserver，所有其他的系统都不能直接访问etcd，都是通过APIserver去访问，所以说APIserver有点像联盟链里的JsonRPC的位置。剩下的都可以把它看成是业务系统，如果把K8S看成业务系统，它的业务就是做集群资源调度，比如说Controller、Scheduler，我们都把它视为具体的业务系统。区块链或者说etcd在整个系统里面的作用其实只是保存元信息，其他的业务系统通过监控元信息的变化，比如写入或者更新来驱动业务系统去做具体业务的事情。k8s有一个非常独特的特点，就是“声明式”，比如说我想部署一个网站，如果只有一个实例，它挂掉之后网站就无法访问。其实通过APIserver只要声明要起一个应用，它的镜像是什么，要起几个实例，系统会把信息记在etcd里面，其他的组件会监控etcd元信息。比如说看到创建了一条记录之后，就开始往work节点上的Kubelet发消息，去创建相应的容器。从整体架构来讲，K8S和联盟链是有相似的地方，接下来会做更详细的对比。首先，不管是etcd还是联盟链，都可以视为分布式的系统，所以它们都用到了分布式的技术。在分布式技术里etcd用的一致性算法是Raft；像联盟链一般都是用PBFT之类的共识算法。区别是BFT即拜占庭容错算法，能容忍其中有一部分节点是恶意的。而Raft只能解决机器宕机的场景。在etcd中使用一致性算法主要是为了高可用的目的。联盟链使用拜占庭容错的共识算法，是因为系统里会有不同的参与方，而且参与方面是不同的企业，没有人能够约束其他人不作恶。面临的场景不一样，所以选择了不同的技术。对外表现来说“信任的边界”，对传统的etcd、K8S这样的分布式系统，主要还是在一个企业内部起多个节点和备份，只是为了高可用，所以他们之间相互是信任的，你发送给我什么数据，我直接接收了，信任边界是在外面的，可能在机房最外用防火墙、密码、登录服务等各种技术，只要把外围守好，整个系统就没问题了。但是对于像联盟链这样的去中心化系统，节点之间都是相互不信任的，信任边界在节点周围，而不是在系统外面，所以不能用用户名密码、防火墙来解决安全问题，联盟链要用公私钥来做账户，发消息需要签名，收到消息之后要验签名，证明是你发的而且没有经过篡改。这是信任边界的不同。联盟链沿袭了以太坊的思路，要做扩展开发Dapp就好了，Dapp基本是智能合约+客户端，就像以太猫，在链上部署一个合约，在网页把合约里的数据进行图形化的展示，提供给用户交互的手段，这是联盟链的做法。K8S也有非常好的扩展性，K8S里面一个基础的名词叫“资源resource”，它本身提供一些resource类型，比如说Pod、Deployment、Storage、PV等等。还允许开发者自定义资源类型。就像刚才讲的etcd里只是记录了资源的源信息，具体资源怎么创建、怎么销毁是由Controller来做，Controller会监控etcd里存储的资源的元信息，一旦发生变动之后，监控到了就会做相应的处理。这其实跟联盟链的做法是非常类似的，因为etcd没有像以太坊的EVM，是不具备编程能力的，所以CustomResource自定义资源类型，相当于合约除了逻辑外的数据结构部分。传统的智能合约里的逻辑业务处理的代码和客户端代码都在Controller里。举个例子，比如说Statefulset，这也是K8S里自带的。假如说K8S里没有Statefulset资源类型，是我们自己实现的。自定义资源类型相关的信息是存在etcd里的，Controller要我们自己开发，其实就是应用，通过APIServer去监控etcd里我关心的类型的资源变化。比如通过命令行工具创建资源，这边就能监控到，处理就是生成三个Pod，然后会调Docker创建相关的容器。K8S是平台化的定位，现在很多PaaS平台都是基于K8S来做的，搭一个系统有很多人同时来用，就是所谓的“多租户”，所以有Namespace机制，能把不同的资源隔离开，大家相互看不到。当然还有基于角色的权限控制系统RBAC，能给不同的角色赋予不同的权限，比方说你不能访问别人创建的东西。也有节点管理，etcd也是分布式系统，可以增加/删除节点。因为是基于投票，所以也有投票节点和普通的同步节点的区别。你可以把一个节点从同步节点提升为投票节点，也可以反过来。K8S的治理手段联盟链都有，CITA也实现了基于角色的权限控制系统，节点管理联盟链肯定是有的，能够动态地增加删除共识节点。除此之外，联盟链还有一些比较特别的治理功能。账户系统刚才已经提到过了，联盟链账户系统是基于公钥体系的账户系统。联盟链有各种系统管理功能，比方说像增加/删除共识节点，这样的事情必须要超级管理员账户来做的，普通用户是没有系统管理的权限。CITA的超级管理员不一定是一个单独的账户，也可以是一个合约。如果合约是多签的合约，就能实现委员会式的系统管理。比如说增加共识节点，事先定好了几个委员会的成员，他们来投票，比如达到二分之一以上才通过，才去执行增加节点的操作，这些都是可以实现的。联盟链可以进行非常精确的经济激励。比如在链上想给早期用户一些补贴，假设链上是有Token的，我们可以设置，早期用户也是要花Token去玩游戏，但可以给你返利，返百分之多少，或者前几天返多少，后面返的更少，这都是可以很灵活设置的，这是联盟链治理方面的优势。融合方案——联盟链
经过刚才的介绍大家可以看到联盟链和元原生的K8S从整体架构上是非常相似的，可以认为它是一种分布式系统的模式，分布式系统只管理元信息，具体的工作还是靠传统的IT系统去执行去实现这样一种模式。联盟链和云原生的融合方案，融合肯定需要对两方面都是有好处的。对于联盟链来说，融合能解决运维问题，K8S在运维方面确实做的非常好。可以增强软件栈。最早关注到云原生社区也是看到有很多需要的功能，比如说分布式存储，比如说解决复杂网络场景的各种网络插件，这在云原生社区里做了很多，并且很多都已经成熟的，能够对联盟链软件栈进行非常有益的补充。对于云原生来说，联盟链融合进来以后能给云原生提供什么呢？去中心化场景。K8S还是传统的以高可用为目的的分布式系统，但是联盟链是去中心化的分布式系统，能够把系统边界扩展到企业间。像K8S原本只能在一个企业内部，融合了联盟链之后有可能把原有的应用扩展到企业间去。不知道现在的网友还知不知道浩方电竞平台？在以前没有网络游戏的时候，有很多游戏有局域网对战，比如说像《CS》、《魔兽争霸》都是有局域网对战功能的。不像现在网络可以在公网上运行，比如说一个人在北京，一个人在杭州玩游戏。浩方做了一个事情，通过模拟的方式让游戏认为这两个机器是在局域网里的，这样就把局域网对战的游戏变成了网络游戏。联盟链加入之后也起到这样的作用，能把传统的IT系统边界扩展到企业间。零信任安全。这也是最近比较火的概念。简单来说就是系统内部不同部分之间是不信任的，一定要通过签名等各种方式来证明数据确实是你发的。从描述中可以看到，联盟链是天然符合零信任安全的，因为本身就不信任其他的节点。融合之后能够给传统IT系统带来更高的安全性。可信计算环境。可信计算有非常多的实现方案，比如说基于硬件英特尔的SGX，也有一些基于密码学的。大家可以看到，联盟链、区块链就是一种软件可信计算环境。原理非常简单，区块链所有的节点都是副本，比如说调一个合约，是所有的共识节点都做执行，执行完了结果之后会算到Stateroot里做共识。大家算的都一样，就认为结果是正确的，是可信的。区块链是一种非常低成本，非常简单粗暴的可信计算方案，对传统IT系统是非常有益的补充。密码学。区块链相对于传统软件来说最独特的是涉及到非常多密码学的东西，这是传统软件里很少涉及到的。区块链也推动了密码学进展，比如说零知识证明，各种隐私方案。如果将来云原生面临去中心化的场景，联盟链除了零信任安全、可信计算之外还有像零知识证明的密码学方案能在实际的场景中得到应用。今天的分享就到这里，感谢大家。互动问答
问题一：宁老师可以给大家介绍一下云原生和云计算的本质区别吗？宁志伟：云原生的出现是因为容器技术的出现，像Docker出现之后，应用的部署运维和Docker出现之前有非常大的变化，尤其机器多了以后，又要在机器上部署很多应用，之前是非常麻烦的事情，但是容器技术出现之后可以很方便地管理很多机器、很多应用。K8S就是一个容器编排、集群调度的系统。IaaS层技术成熟了以后有了云，能以统一的方式管理非常多的机器资源。云原生会稍微更偏上层一些，关注的是偏开发和运维方面的东西。像K8S就是容器编排系统，在开发过程中跟现在流行的微服务架构也非常契合。大家有兴趣深入了解话，可以参考一下云原生技术方面的优秀书籍。问题二：谢谢宁老师，对于合约虚拟机的发展您是怎么看的？宁志伟：现在用的最多的是以太坊的EVM，因为生态已经起来了，包括CITA虽然是完全重新实现的，但为了兼容以太坊的Dapp和智能合约生态，我们也用了EVM。现在区块链有一种趋势，大家都在重复造轮子，可能一个链搞一个新的VM、新的智能合约编程语言。至少对企业场景来说是不太好的，用户开发的时候切换成本会非常高，学习成本会非常高。用户更希望用熟悉通用的编程语言，JAVA、GO、C++这种语言来写智能合约。在CITA-Cloud里目前为止是没有智能合约语言和VM的，有点像是K8S这种，直接写类似于Controller应用，来监控链上信息做相应的业务处理。可能将来还是会兼容EVM的，把EVM封装成Controller就可以了。智能合约在轻量化开发，或者比较小的应用上还是非常有优势的，写脚本就可以了。以太坊相当于云原生里的Serverless技术，对云、对平台做了非常高层次的抽象，不用开发业务系统，就写个脚本，系统会动态地分配机器资源，做运算，之后给个结果就可以了。
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。