作者：普元CTO 焦烈焱 更多区块链文章投稿，请邮箱至jingqi@csdn.net 中国云计算技术大会http://cctc.csdn.net，在5月19日背景，将举办全天的区块链技术峰会专场，欢迎大家与区块链专家一起探讨区块链的技术趋势。现在购票还有折扣。
导语
每一种新技术的产生与发展，都会与既有的技术与实践存在着联系，例如微服务作为一种技术架构，实际上是在SOA架构和JavaEE等分布式架构的基础上，进一步明晰了服务实现的方式与规则。区块链技术脱胎于比特币，作为一种多方信任的交易和技术模型，被包括国家、政府、监管机构等诸多业务方所关注，反而是技术从业者有些茫然，这一技术到底是什么，解决什么问题，能够用在哪里普元近年来持续对微服务和区块链技术进行了研究，这里和大家分享一下研究的成果。我们的研究重点放在了如下几个方面：
1. 区块链技术适用的应用场景有哪些，该技术带来的价值是什么？ 2. 区块链技术是由哪些技术组合而成，和现有技术的关系如何？ 3. 采用区块链技术后，应用技术架构是什么，与微服务架构的关系，现有应用如何进行迁移？
区块链技术是从比特币开始的，2008年由中本聪提出开始，造成了一个比特币的热潮。但是，比特币的热潮退去后，比特币提出的问题和解决方式却吸引着我们。2014年左右区块链逐步从比特币中脱离出来，做为一种独立的技术发展，进入了 2.0 时代，以数字资产的方式解决商业的信任问题，同时用数字化手段提高业务的效率，在很多业务中已经有了尝试。
做为一种独立的技术发展，区块链分为公有链、联盟链、私有链三个方向。而从业务角度看，区块链的核心价值在于通过数据共享建立了多方的信任机制。
信任问题，始终是一个大问题，为了解决信任问题，人类投入了大量的时间和金钱。尤其是多个参与方参加的业务，信任的成本更高，这里我举一个复杂的例子：信用证业务（参见下图），信用证是指开证银行应申请人（买方）的要求并按其指示向受益人开立的载有一定金额的、在一定的期限内凭符合规定的单据付款的书面保证文件。信用证是国际贸易中最主要、最常用的支付方式（摘自百度百科）。
之所以举这个例子，是因为区块链技术适用的场景往往是业务比较复杂的情况，简单例子很容易被误解，这里我通俗易懂的解释一下，在国际贸易活动，买卖双方往往互不信任，进口商（买方）担心预付款后，出口商（卖方）不发货；卖方担心发货后买方不付款（类似诈骗经常发生，例如卖方把货运到码头了，买方就是不付余款，于是只能在当地贱卖，这时买方再去抄底），典型的麻杆打狼两头怕。因此双方各找了一家银行作为担保人，由两家银行之间开具凭证，代理进口商、出口商之间业务往来，达到条件后由银行付款，减少进口商、出口商的风险，这就是信用证业务。即使这样，信用证诈骗还是很多，银行为规避风险，需要各种书面的证明，反复各种确认…业务处理周期会非常长。
上图中信用证业务的参与方包括出口商、进口商、开证行、通知行、寄单行/附议行、运输公司，是一个典型的多方参与业务，但通常这些参与方只是一部分，可能还会有海关、保险公司、评级机构等机构加入到交易链条中。
解决多参与方业务的信任问题，现在是通过建立第三方机构完成的，例如上述信用证业务，就是通过SWIFT组织（环球同业银行金融电讯协会）的SWIFT系统开立信用证，银行和其他金融机构通过它与同业交换电文来完成金融交易，由 SWIFT 进行银行间转发。
SWIFT仅仅解决了一部分的问题，还差很远，例如：
业务上：那些没有参加到 SWIFT 的组织无法通过 SWIFT 进行交易，例如一些进口商、出口商、保险公司等等，SWITF也不能做清算，因此银行在办理信用证业务的时候，只有反复通过各种其他方式确认，避免诈骗发生，导致业务非常复杂，流程很长；技术上：多方参与的业务，一旦在处理业务时发生技术故障，处理起来就远比普通业务复杂。为了保证少出问题，技术上的投入会很高，记得用过很多手段，例如曾经给每个参与方做过应急系统，采用过两个不同厂商的SWIFT网关互为备份，安排专人排班管理异常情况，而且每个中心接入的标准和模式也不一致，接入中心机构带来的开发/维护成本都很高。必须说明的是，为了能把业务讲清楚，我还是简化了很多内容，例如如何进行银行间清算、如何进行付款等等。总之，建立一个第三方机构来解决信任问题，无论在业务上、技术上复杂度都很高。如果有一个分布式的记账簿：
参与方在记账之后有相当多的副本存在，不再是一家之言；保证提交的交易一定被记录下来；保证记账不可逆，无法篡改；参与方的交易记录是相对透明的，可以通过这些记录验证新的交易。如果有机构建立了这样一个记账簿，每个参与方在交易中都通过这个记账簿进行交互，保证每一笔发生的交易一定被可靠的记录下来并不可篡改，不就不必再反复确认，不必担心技术问题导致的业务流程变更，不必做应急系统，这样成本就低多了。
通过分布式的记账簿进行数据共享，从而降低信任成本，这就是区块链技术的价值。
既然区块链是一个分布式的记账簿，那这个记账簿由谁来建立呢？这是这一技术应用的核心问题。
目前建立记账簿的方式有三种：
公有链，象互联网一样，做为一种开放的网络基础设施，向任何人公开，任何人自由加入私有链，一个组织内部建立，可以帮助组织内部完成审计等工作建立公有链难度高，业务场景不够精准，分布式存储带来的性能低下问题阻碍了可用的应用场景，而私有链脱离了区块链的商业价值，只是把区块链做为一个技术组件使用。在目前的应用场景中，绝大多数都可以用联盟链解决，商业上相对容易成立，性能远远高于公有链。
从上述描述就可以理解到，公有链太理想，私有链所处理的问题，传统架构完全能解决，而针对特定业务由企业联盟建立的联盟链，应用方向更清晰，业务价值也更加明确，下图是一个联盟链的示例：
从应用的角度看，区块链技术提供的是一个分布式数据库。区块链技术的数据共享方式要满足：（1）多副本、（2）可靠记录、（3）不可篡改、（4）多方透明几个特性，上述特性总结下来，采用区块链技术后，应用技术架构如上图所示，可以看出，区块链技术对应用而言，就是一个分布式数据库。
区块链基于密码学中的椭圆曲线数字签名算法（ECDSA）来实现去中心化的P2P系统设计。当人们在谈论或使用“区块链”这个词时，有时候是指数据结构，有时候是指数据库，有时则是指数据库技术。
和区块链技术比，分布式数据库的概念显然更容易被理解，我就从分布式数据库的一些基本概念出来，理解区块链的技术实现，这些概念包括数据存储、点对点可靠传输、存储过程与触发器（智能合约）、数据安全。
区块链技术的数据共享是一个分布式的记账簿，交易记录具备多个副本，因此首先要解决分布式数据存储的问题。
1、区块链存储的基本单元是区块，区块采用链式结构，即新增的区块（类似数据库一行记录）都知道自己前一个区块（前一行记录）是什么，可以一直追溯到根，区块的标识是区块的哈希值，同时链式结构保留了业务产生的轨迹，可以在新增交易的时候根据前面的记录做校验，保证了区块的内容不容易篡改。
这种模式，我们在传统的数据库设计也会采用，例如下图拉链表的形式，每次对数据的更新都采用追加（ Insert而不是Update）模式，有起始时间、失效时间和是否生效标识，保持全部交易历史。
区块链把这一点变成了一种底层固有模式，加入了哈希、时间戳等机制在技术上保证链条的正确性，因此非常有价值。
2、既然是分布式、多中心的存储方式，就必须解决存储时的分布式一致性问题。在区块链的前身比特币应用中，解决这一问题的方式是工作量证明（POW Proof-Of-Work）方式，即通过工作以获得指定成果，用成果来证明曾经付出的努力。
这也是接触区块链技术时第一个比较迷惑的地方，我为啥一定要用工作量来证明，是不是还有其他方式？区块链技术从比特币中独立出来后，大家把这一问题归结为共识问题，工作量证明是达成共识的一种方式，这样就清晰多了。于是就产生了权益证明（POS Proof of Stake）方式，是一种通过业务规则达成共识的方式；实用拜占庭容错（PBFT Practical Byzantine Fault Tolerance）方式，是一种通过技术规则达成共识的机制。在公有链上，工作量证明（POW）还是一种最主要的共识方式，不容易取代，但在联盟链上，完全可以根据自己的情况，创造出新的共识方式出来。我们就根据这一想法，在特定业务中创造过共识算法，解决分布式数据存储的一致性问题。
区块链技术是一组技术的组合，既然是一个分布式的记账簿，就要解决数据可靠传输问题。包括记账节点（信任节点）之间、非记账节点（非信任节点）、客户端与记账节点（信任节点）之间的数据传输。在以前我们的方案中，往往通过可靠消息或者P2P方式解决数据传输问题，这些技术也被用于区块链技术中。但必须说明的是，在真实业务场景下，不可能把所有的数据都记录在记账簿中，部分业务数据还是要保存在自己的系统中，这就还需要在技术框架上做到本地业务数据与区块链的记账簿保持一致，后文会具体阐述，总之，区块链平台只能保证自身数据之间的一致，业务不能完全依赖区块链平台保证数据一致性。
智能合约是指当一定条件满足的情况下，可以被自动执行的数字化合约。实现这一特性，在数据库中就是由触发器和存储过程完成的。虽然在目前流行的应用架构中，都不建议把逻辑写在存储过程中，但触发器和存储过程还是常用的工具，尤其在数据迁移相关的运维活动中。区块链技术中智能合约就是触发器和存储过程，他是一个在沙箱中运行的脚本，用于执行区块链业务中的业务逻辑，也可以用于各种检查。举个例子，A产生一笔支付时，可以通过智能合约在数据链上进行检查，如果发现A的余额无法支付这笔交易，就可以中止这笔交易。和存储过程相比，智能合约运行在沙箱之中，不能对外部 API 做调用。这也比较好理解，如果允许外部调用，就可能无法保证自身的数据一致性，后面我们会讲到这种缺陷如何弥补。美中不足的是目前的智能合约并不支持 SQL 语法。
交易数据是透明的，但不是全部透明，而是相对透明，这是区块链技术的一个难点，关键有二：（1）如何保护隐私，仅仅能看到自己可见的数据；（2）密钥分配问题，例如新加入链中的一个节点会被分配一个新的密钥，如何用这个密钥解读以前链中存储的信息。可见与不可见，这是一个矛盾，理论上没有一个完美的方案，这里我不对区块链技术如何加密、如何做密钥管理、如何同态加密等方式做解读，而是讲讲如何通过业务方法而不是技术手段规避这一问题。举个例子，在一个小企业支付的联盟链中，核心企业包括某银行、企业A，为A的上下游企业提供信贷业务，对于所有交易的数据，银行和核心企业A都是可见的，他们拥有记账节点，对于其他加盟企业，只拥有非记账节点，他们虽然也有全部的数据，但是只能看到自己相关的数据。很明显，加盟企业放弃了自己的部分隐私权，但也得到了生意的机会，这种方式加盟企业是可以接受的，就好比贷款企业要向银行提供经营数据一样。数据安全问题，在技术上很难解决，但通过业务手段是可以规避的，这也是我们看好联盟链的重要原因。
最后说说区块链技术与微服务架构的关系。大家知道，微服务架构是一个分布式的应用技术架构，目的是有效的对应用进行拆分，实现敏捷开发、快速演化、便捷容错与弹性伸缩。
微服务的一个核心概念是API网关，由于服务的颗粒变细，网关承担着安全与访问认证等诸多职能。而在现有的大多数微服务架构中，大家都更多的在谈接入网关的概念，实际上按照信息的流向，除接入网关外，微服务还应该有接出网关的概念。
前面说到，区块链技术本质上就是分布式数据库，微服务架构与区块链技术的结合，并不能简单的看成是微服务与数据库的结合，而应该把区块链平台做为一个第三方应用进行交互，这也是微服务架构很好发挥作用的地方。上图中红圈所示的就是微服务与区块链平台进行交互的方式。而微服务的接出网关，就应该起到区块链网关的作用。
虽然目前的区块链平台一般都有SDK和REST服务两种方式，按照上述的原则，一般不要使用 SDK，而是远程调用方式，采用微服务的设计原则，使用区块链网关，把微服务与区块链平台集成的功能集中到网关中，见下图：
微服务通过区块链网关与区块链平台交互，区块链网关主要功能包括通讯网关、事件监听，同时配合微服务应用框架，完成数据一致性、对账功能。与区块链网关集成的能力，是微服务架构天生具备的。所以我们说微服务与区块链，天生是一对。
由于区块链平台的服务能力（每秒交易数 TPS）有限，为保证区块链平台的可用性，区块链网关采用了异步处理模式，实现限流、隔离、服务升降级等能力。
网关在微服务应用与区块链平台之间建立了隔离，避免平台与微服务之间互相影响，这是一种 MiddleBox 的集成方式，用一个独立的基础设施做集成。微服务之间的集成往往采用 MiddlePipe 的模式，但是区块链平台做为一个第三方应用，采用 MiddleBox 方式比较好，统一管理与运维比较方便。
由于区块链平台提供的接口各有不同，区块链网关在接受请求后记录交易流水，把区块链平台提供的服务模拟为幂等服务，调用者可以多次调用区块链网关，而区块链网关仅仅调用区块链平台一次。为方便运维，我们可以为区块链平台提供的服务定义SLA，根据这些定义灵活的进行调用的控制。
区块链网关的内部实现是一个 SEDA 架构（分阶段事件驱动架构），把接入、接出和处理分开（处理主要是记录流水、报文打解包、安全效验等功能），三阶段之间用队列连接，采用异步模拟同步的方式，这是一个用于集成的基础架构。
接入、处理、接出三个阶段可处理资源是可以调配的，资源主要包括处理线程和接入接出的连接，根据不同业务可以有不同的资源为之服务，这样升降级、限流等特性就比较容易实现。
为了方便运维，需要对业务有分组的能力，可以根据分组进行批量的运维管理。
如果记账簿发生了改变，如何通知微服务呢，这就是区块链网关中事件监听发挥的作用。目前很多区块链平台并没有提供事件接口，即使未来有也很难统一，前面也说过，智能合约运行在沙箱中，为保证数据一致性不可能支持对外部服务的调用，也不能做为事件监听的回调，这样就需要在区块链网关中进行处理。
微服务可以注册对某一类交易进行监听，区块链网关定时通过区块链平台的查询接口检索，发现数据变更时通知微服务。这是一个效率不高的方法，但区块链平台本身性能也不高，时延主要由共识机制造成，轮询的做法并不会有太大影响，这也是期待区块链平台本身提升的地方。
不能把所有数据都存储在区块链平台中，而是将交易数据存储在区块链平台，这样就有了本地数据库的数据与区块链交易数据的一致性问题。
一般来说，我们不能依赖区块链平台支持事务的回滚，因为这个分布式的记账簿一旦记账就是不可更改的，我们甚至不能指望区块链平台实时给应用反馈记账是否成功，因为有可能返回超时错误，不清楚是否记账成功。于是，区块链网关需要和微服务配合保证数据的一致性。
一般情况下微服务中的业务处理采用异步模式，发出记账申请后处于等待状态，区块链网关将记账申请转发给区块链平台。如果区块链平台返回接受Accept或者拒绝Reject，将结果通知微服务；如果区块链平台返回超时或者不可确定错误，即开始定时轮询，得到结果后通知微服务。同时，微服务本身需要具备事务补偿的模式，如果记账失败进行反交易处理。这种数据一致性处理的方式，是微服务多种处理方式中的一种，我们一般使用服务编排的方式降低这种模式的开发复杂度。
下面是一个示例：
这是一个可靠事件与区块链交互的流程：
1）应用框架接到请求后首先记录业务流水，然后执行业务逻辑，记录业务数据，最后在事件表中留下对区块链平台调用的记录，事务完成 2）事件处理轮询事件记录，有更新时通过区块链网关调用区块链平台，如果调用成功，改变事件状态，如果失败就要调用业务补偿的机制了。
既然数据有本地存放，也有区块链平台存放，就有不一致的可能，就必须对账。传统对账有以我为主、以他为主两种模式。这里就只能以他为主，以区块链平台为主了。由于区块链技术针对交易的特点对存储结构进行了要求，利用已有的时间戳、交易先后次序，可以是对账变得更加容易。
基本的对账处理流程如下
区块链平台和企业应用的记录必须有关联的id（可以是多要素的组合）区块链平台和企业应用都要保证生成的对账文件明细记录的连续性对于“隔日账”需重复核对区块链是一种新兴的技术，他的本质是一种加入业务特性的分布式数据库，通过对区块链技术的研究，我们找到了业务与区块链技术结合的方式，提出了微服务应用架构集成区块链的技术模式。
1、区块链的业务价值是通过数据共享降低信任成本。
区块链建立了一个记账簿，每个参与方在交易中都通过这个记账簿进行交互，保证每一笔发生的交易一定被可靠的记录下来并不可篡改，不必再反复确认，不必担心技术问题导致的业务流程变更，不必做应急系统，从而降低了信任成本。
2、区块链技术的本质是分布式数据库。
区块链技术的数据共享方式要满足（1）多副本、（2）可靠记录、（3）不可篡改、（4）多方透明几个特性，总结下来，区块链技术对应用而言，就是一个分布式数据库，分别对应分布式数据库的（1）分布式存储、（2）点对点可靠传输、（3）存储过程与（4）数据安全几个方面。
3、为分布式应用而生的微服务，与区块链技术是天生的一对。
微服务通过区块链网关与区块链平台交互，区块链网关主要功能包括通讯网关、事件监听，同时配合微服务应用框架，完成数据一致性、对账功能。与区块链网关集成的能力，是微服务架构天生具备的。
以上是对我们研究成果一个简要介绍，后续我们还会对使用区块链技术的细节进行分析，与大家共同探讨。
从刚刚接触区块链技术的一头雾水，到概念的逐步清晰，再到区块链应用的研发，经历很多困惑，这里列出几个常见的困惑：
困惑1：比特币是区块链技术的一个应用，不能把比特币应用的所有内容都归结为区块链技术
上文提到，区块链技术从比特币中独立出来是 2014 年左右的事情，此前每每举出区块链的案例都是比特币，给区块链技术的应用造成了很多误解。我建议先了解区块链技术，再了解比特币，先理解联盟链的业务场景，再了解公有链的业务场景，公有链看作是联盟链的一种大规模延展，，可以少走一些弯路。
困惑2：公有链情况下数据存储性能不高，但联盟链的性能可以远高于公有链，能满足多数场景的要求
数据一致性问题是分布式存储最大的问题，而并发越高，冲突的概率就越大。区块链技术之所以能支持的每秒交易数（TPS）不高，主要是共识机制比较复杂，或者说共识机制就是刻意为了降低并发性，减少数据冲突的概率。在公有链上，这是一个无法逾越的问题，只能从事实时性要求不敏感的业务。但是，在联盟链中，由于链中的参与方并不多，也不需要每个节点都记账，就可以使用一些性能更高的共识机制，例如前面说的PBFT。我们曾经尝试过一种全对等的算法，可以支持更高的性能。
困惑3：应用区块链技术不一定必须有矿工来挖矿
初次接触区块链技术，矿工/挖矿这个概念让人非常费解：（1）为什么一定要挖矿？（2）为什么要给记账成功的节点奖励比特币来鼓励记账？（3）非比特币的业务中如何鼓励记账？这个困惑归根结底还是把区块链和比特币混淆造成的。前面说过，挖矿是通过工作量证明（POW）达成共识的机制，挖矿能力愈强就取得了记录权。更重要的是比特币的货币属性，发行货币要么靠国家信用（例如纸币），要么靠奇缺资源（例如黄金），比特币为了防止滥发，就需要用算力做为一种奇缺资源。这样说来，比特币实际上把共识算法、货币属性、鼓励记账这几件事都用挖矿来解决了，思路确实精妙。但是，在业务规则不同的联盟链中就不一样了，除了有其他更高效的共识算法外，不需要奇缺资源，不需要专门对记账做鼓励，因为必须记账已经是核心企业之间的契约，可以通过技术手段保证数据的同步，支持审计等能力，自然就不需要挖矿了。
困惑4：目前应用区块链技术不是去中心，而是多中心
去中心是一个理想，经常有人问（1）为什么要去中心？去中心有什么好处？（2）真的能去中心吗？后来，我深入研究联盟链的场景时发现，实际的业务场景大多是多中心（这又是比特币惹的祸，他真的想去中心），例如上述的企业联盟方式，几个建立联盟的核心企业就是多中心，他们共同成为一个新的中心。传统方式建立新的中心，往往通过建立清算机构的方式，而区块链技术让建立中心的成本降低了。
困惑5：不是所有的区块链节点都是记账节点，很多节点仅仅用来进行数据同步而已
多中心就意味着不是每个节点都需要记账，记账的工作由几个中心节点负责就可以了，其他节点与记账节点间是数据同步的关系，也就是非记账节点上也有全部数据。联盟链中非记账节点一般处在加盟企业，由于数据可见性的要求，非记账节点中的数据并不是都可见的，但是这一副本可以做为一种法律依据，提高了篡改数据的成本。
从数据的角度来看，区块链本质是一种分布式数据库，这里的“分布式”是指区块链技术利用链式存储结构不仅解决了分布式数据存储问题，也解决了存储时的分布式一致性问题。区块链技术利用分布式记账簿保证数据可靠传输和访问，利用可自动执行的智能合约来编程和操作数据。所以，我认为，基于分布式数据库来理解区块链，认清区块链技术常见的一些困惑和误区，可以让大家对区块链有个比较正确的理解方式。
作者：普元CTO 焦烈焱 更多区块链文章投稿，请邮箱至jingqi@csdn.net 中国云计算技术大会http://cctc.csdn.net，在5月19日背景，将举办全天的区块链技术峰会专场，欢迎大家与区块链专家一起探讨区块链的技术趋势。现在购票还有折扣。
导语
每一种新技术的产生与发展，都会与既有的技术与实践存在着联系，例如微服务作为一种技术架构，实际上是在SOA架构和JavaEE等分布式架构的基础上，进一步明晰了服务实现的方式与规则。区块链技术脱胎于比特币，作为一种多方信任的交易和技术模型，被包括国家、政府、监管机构等诸多业务方所关注，反而是技术从业者有些茫然，这一技术到底是什么，解决什么问题，能够用在哪里普元近年来持续对微服务和区块链技术进行了研究，这里和大家分享一下研究的成果。我们的研究重点放在了如下几个方面：
1. 区块链技术适用的应用场景有哪些，该技术带来的价值是什么？ 2. 区块链技术是由哪些技术组合而成，和现有技术的关系如何？ 3. 采用区块链技术后，应用技术架构是什么，与微服务架构的关系，现有应用如何进行迁移？
区块链技术是从比特币开始的，2008年由中本聪提出开始，造成了一个比特币的热潮。但是，比特币的热潮退去后，比特币提出的问题和解决方式却吸引着我们。2014年左右区块链逐步从比特币中脱离出来，做为一种独立的技术发展，进入了 2.0 时代，以数字资产的方式解决商业的信任问题，同时用数字化手段提高业务的效率，在很多业务中已经有了尝试。
做为一种独立的技术发展，区块链分为公有链、联盟链、私有链三个方向。而从业务角度看，区块链的核心价值在于通过数据共享建立了多方的信任机制。
信任问题，始终是一个大问题，为了解决信任问题，人类投入了大量的时间和金钱。尤其是多个参与方参加的业务，信任的成本更高，这里我举一个复杂的例子：信用证业务（参见下图），信用证是指开证银行应申请人（买方）的要求并按其指示向受益人开立的载有一定金额的、在一定的期限内凭符合规定的单据付款的书面保证文件。信用证是国际贸易中最主要、最常用的支付方式（摘自百度百科）。
之所以举这个例子，是因为区块链技术适用的场景往往是业务比较复杂的情况，简单例子很容易被误解，这里我通俗易懂的解释一下，在国际贸易活动，买卖双方往往互不信任，进口商（买方）担心预付款后，出口商（卖方）不发货；卖方担心发货后买方不付款（类似诈骗经常发生，例如卖方把货运到码头了，买方就是不付余款，于是只能在当地贱卖，这时买方再去抄底），典型的麻杆打狼两头怕。因此双方各找了一家银行作为担保人，由两家银行之间开具凭证，代理进口商、出口商之间业务往来，达到条件后由银行付款，减少进口商、出口商的风险，这就是信用证业务。即使这样，信用证诈骗还是很多，银行为规避风险，需要各种书面的证明，反复各种确认…业务处理周期会非常长。
上图中信用证业务的参与方包括出口商、进口商、开证行、通知行、寄单行/附议行、运输公司，是一个典型的多方参与业务，但通常这些参与方只是一部分，可能还会有海关、保险公司、评级机构等机构加入到交易链条中。
解决多参与方业务的信任问题，现在是通过建立第三方机构完成的，例如上述信用证业务，就是通过SWIFT组织（环球同业银行金融电讯协会）的SWIFT系统开立信用证，银行和其他金融机构通过它与同业交换电文来完成金融交易，由 SWIFT 进行银行间转发。
SWIFT仅仅解决了一部分的问题，还差很远，例如：
业务上：那些没有参加到 SWIFT 的组织无法通过 SWIFT 进行交易，例如一些进口商、出口商、保险公司等等，SWITF也不能做清算，因此银行在办理信用证业务的时候，只有反复通过各种其他方式确认，避免诈骗发生，导致业务非常复杂，流程很长；技术上：多方参与的业务，一旦在处理业务时发生技术故障，处理起来就远比普通业务复杂。为了保证少出问题，技术上的投入会很高，记得用过很多手段，例如曾经给每个参与方做过应急系统，采用过两个不同厂商的SWIFT网关互为备份，安排专人排班管理异常情况，而且每个中心接入的标准和模式也不一致，接入中心机构带来的开发/维护成本都很高。必须说明的是，为了能把业务讲清楚，我还是简化了很多内容，例如如何进行银行间清算、如何进行付款等等。总之，建立一个第三方机构来解决信任问题，无论在业务上、技术上复杂度都很高。如果有一个分布式的记账簿：
参与方在记账之后有相当多的副本存在，不再是一家之言；保证提交的交易一定被记录下来；保证记账不可逆，无法篡改；参与方的交易记录是相对透明的，可以通过这些记录验证新的交易。如果有机构建立了这样一个记账簿，每个参与方在交易中都通过这个记账簿进行交互，保证每一笔发生的交易一定被可靠的记录下来并不可篡改，不就不必再反复确认，不必担心技术问题导致的业务流程变更，不必做应急系统，这样成本就低多了。
通过分布式的记账簿进行数据共享，从而降低信任成本，这就是区块链技术的价值。
既然区块链是一个分布式的记账簿，那这个记账簿由谁来建立呢？这是这一技术应用的核心问题。
目前建立记账簿的方式有三种：
公有链，象互联网一样，做为一种开放的网络基础设施，向任何人公开，任何人自由加入私有链，一个组织内部建立，可以帮助组织内部完成审计等工作建立公有链难度高，业务场景不够精准，分布式存储带来的性能低下问题阻碍了可用的应用场景，而私有链脱离了区块链的商业价值，只是把区块链做为一个技术组件使用。在目前的应用场景中，绝大多数都可以用联盟链解决，商业上相对容易成立，性能远远高于公有链。
从上述描述就可以理解到，公有链太理想，私有链所处理的问题，传统架构完全能解决，而针对特定业务由企业联盟建立的联盟链，应用方向更清晰，业务价值也更加明确，下图是一个联盟链的示例：
从应用的角度看，区块链技术提供的是一个分布式数据库。区块链技术的数据共享方式要满足：（1）多副本、（2）可靠记录、（3）不可篡改、（4）多方透明几个特性，上述特性总结下来，采用区块链技术后，应用技术架构如上图所示，可以看出，区块链技术对应用而言，就是一个分布式数据库。
区块链基于密码学中的椭圆曲线数字签名算法（ECDSA）来实现去中心化的P2P系统设计。当人们在谈论或使用“区块链”这个词时，有时候是指数据结构，有时候是指数据库，有时则是指数据库技术。
和区块链技术比，分布式数据库的概念显然更容易被理解，我就从分布式数据库的一些基本概念出来，理解区块链的技术实现，这些概念包括数据存储、点对点可靠传输、存储过程与触发器（智能合约）、数据安全。
区块链技术的数据共享是一个分布式的记账簿，交易记录具备多个副本，因此首先要解决分布式数据存储的问题。
1、区块链存储的基本单元是区块，区块采用链式结构，即新增的区块（类似数据库一行记录）都知道自己前一个区块（前一行记录）是什么，可以一直追溯到根，区块的标识是区块的哈希值，同时链式结构保留了业务产生的轨迹，可以在新增交易的时候根据前面的记录做校验，保证了区块的内容不容易篡改。
这种模式，我们在传统的数据库设计也会采用，例如下图拉链表的形式，每次对数据的更新都采用追加（ Insert而不是Update）模式，有起始时间、失效时间和是否生效标识，保持全部交易历史。
区块链把这一点变成了一种底层固有模式，加入了哈希、时间戳等机制在技术上保证链条的正确性，因此非常有价值。
2、既然是分布式、多中心的存储方式，就必须解决存储时的分布式一致性问题。在区块链的前身比特币应用中，解决这一问题的方式是工作量证明（POW Proof-Of-Work）方式，即通过工作以获得指定成果，用成果来证明曾经付出的努力。
这也是接触区块链技术时第一个比较迷惑的地方，我为啥一定要用工作量来证明，是不是还有其他方式？区块链技术从比特币中独立出来后，大家把这一问题归结为共识问题，工作量证明是达成共识的一种方式，这样就清晰多了。于是就产生了权益证明（POS Proof of Stake）方式，是一种通过业务规则达成共识的方式；实用拜占庭容错（PBFT Practical Byzantine Fault Tolerance）方式，是一种通过技术规则达成共识的机制。在公有链上，工作量证明（POW）还是一种最主要的共识方式，不容易取代，但在联盟链上，完全可以根据自己的情况，创造出新的共识方式出来。我们就根据这一想法，在特定业务中创造过共识算法，解决分布式数据存储的一致性问题。
区块链技术是一组技术的组合，既然是一个分布式的记账簿，就要解决数据可靠传输问题。包括记账节点（信任节点）之间、非记账节点（非信任节点）、客户端与记账节点（信任节点）之间的数据传输。在以前我们的方案中，往往通过可靠消息或者P2P方式解决数据传输问题，这些技术也被用于区块链技术中。但必须说明的是，在真实业务场景下，不可能把所有的数据都记录在记账簿中，部分业务数据还是要保存在自己的系统中，这就还需要在技术框架上做到本地业务数据与区块链的记账簿保持一致，后文会具体阐述，总之，区块链平台只能保证自身数据之间的一致，业务不能完全依赖区块链平台保证数据一致性。
智能合约是指当一定条件满足的情况下，可以被自动执行的数字化合约。实现这一特性，在数据库中就是由触发器和存储过程完成的。虽然在目前流行的应用架构中，都不建议把逻辑写在存储过程中，但触发器和存储过程还是常用的工具，尤其在数据迁移相关的运维活动中。区块链技术中智能合约就是触发器和存储过程，他是一个在沙箱中运行的脚本，用于执行区块链业务中的业务逻辑，也可以用于各种检查。举个例子，A产生一笔支付时，可以通过智能合约在数据链上进行检查，如果发现A的余额无法支付这笔交易，就可以中止这笔交易。和存储过程相比，智能合约运行在沙箱之中，不能对外部 API 做调用。这也比较好理解，如果允许外部调用，就可能无法保证自身的数据一致性，后面我们会讲到这种缺陷如何弥补。美中不足的是目前的智能合约并不支持 SQL 语法。
交易数据是透明的，但不是全部透明，而是相对透明，这是区块链技术的一个难点，关键有二：（1）如何保护隐私，仅仅能看到自己可见的数据；（2）密钥分配问题，例如新加入链中的一个节点会被分配一个新的密钥，如何用这个密钥解读以前链中存储的信息。可见与不可见，这是一个矛盾，理论上没有一个完美的方案，这里我不对区块链技术如何加密、如何做密钥管理、如何同态加密等方式做解读，而是讲讲如何通过业务方法而不是技术手段规避这一问题。举个例子，在一个小企业支付的联盟链中，核心企业包括某银行、企业A，为A的上下游企业提供信贷业务，对于所有交易的数据，银行和核心企业A都是可见的，他们拥有记账节点，对于其他加盟企业，只拥有非记账节点，他们虽然也有全部的数据，但是只能看到自己相关的数据。很明显，加盟企业放弃了自己的部分隐私权，但也得到了生意的机会，这种方式加盟企业是可以接受的，就好比贷款企业要向银行提供经营数据一样。数据安全问题，在技术上很难解决，但通过业务手段是可以规避的，这也是我们看好联盟链的重要原因。
最后说说区块链技术与微服务架构的关系。大家知道，微服务架构是一个分布式的应用技术架构，目的是有效的对应用进行拆分，实现敏捷开发、快速演化、便捷容错与弹性伸缩。
微服务的一个核心概念是API网关，由于服务的颗粒变细，网关承担着安全与访问认证等诸多职能。而在现有的大多数微服务架构中，大家都更多的在谈接入网关的概念，实际上按照信息的流向，除接入网关外，微服务还应该有接出网关的概念。
前面说到，区块链技术本质上就是分布式数据库，微服务架构与区块链技术的结合，并不能简单的看成是微服务与数据库的结合，而应该把区块链平台做为一个第三方应用进行交互，这也是微服务架构很好发挥作用的地方。上图中红圈所示的就是微服务与区块链平台进行交互的方式。而微服务的接出网关，就应该起到区块链网关的作用。
虽然目前的区块链平台一般都有SDK和REST服务两种方式，按照上述的原则，一般不要使用 SDK，而是远程调用方式，采用微服务的设计原则，使用区块链网关，把微服务与区块链平台集成的功能集中到网关中，见下图：
微服务通过区块链网关与区块链平台交互，区块链网关主要功能包括通讯网关、事件监听，同时配合微服务应用框架，完成数据一致性、对账功能。与区块链网关集成的能力，是微服务架构天生具备的。所以我们说微服务与区块链，天生是一对。
由于区块链平台的服务能力（每秒交易数 TPS）有限，为保证区块链平台的可用性，区块链网关采用了异步处理模式，实现限流、隔离、服务升降级等能力。
网关在微服务应用与区块链平台之间建立了隔离，避免平台与微服务之间互相影响，这是一种 MiddleBox 的集成方式，用一个独立的基础设施做集成。微服务之间的集成往往采用 MiddlePipe 的模式，但是区块链平台做为一个第三方应用，采用 MiddleBox 方式比较好，统一管理与运维比较方便。
由于区块链平台提供的接口各有不同，区块链网关在接受请求后记录交易流水，把区块链平台提供的服务模拟为幂等服务，调用者可以多次调用区块链网关，而区块链网关仅仅调用区块链平台一次。为方便运维，我们可以为区块链平台提供的服务定义SLA，根据这些定义灵活的进行调用的控制。
区块链网关的内部实现是一个 SEDA 架构（分阶段事件驱动架构），把接入、接出和处理分开（处理主要是记录流水、报文打解包、安全效验等功能），三阶段之间用队列连接，采用异步模拟同步的方式，这是一个用于集成的基础架构。
接入、处理、接出三个阶段可处理资源是可以调配的，资源主要包括处理线程和接入接出的连接，根据不同业务可以有不同的资源为之服务，这样升降级、限流等特性就比较容易实现。
为了方便运维，需要对业务有分组的能力，可以根据分组进行批量的运维管理。
如果记账簿发生了改变，如何通知微服务呢，这就是区块链网关中事件监听发挥的作用。目前很多区块链平台并没有提供事件接口，即使未来有也很难统一，前面也说过，智能合约运行在沙箱中，为保证数据一致性不可能支持对外部服务的调用，也不能做为事件监听的回调，这样就需要在区块链网关中进行处理。
微服务可以注册对某一类交易进行监听，区块链网关定时通过区块链平台的查询接口检索，发现数据变更时通知微服务。这是一个效率不高的方法，但区块链平台本身性能也不高，时延主要由共识机制造成，轮询的做法并不会有太大影响，这也是期待区块链平台本身提升的地方。
不能把所有数据都存储在区块链平台中，而是将交易数据存储在区块链平台，这样就有了本地数据库的数据与区块链交易数据的一致性问题。
一般来说，我们不能依赖区块链平台支持事务的回滚，因为这个分布式的记账簿一旦记账就是不可更改的，我们甚至不能指望区块链平台实时给应用反馈记账是否成功，因为有可能返回超时错误，不清楚是否记账成功。于是，区块链网关需要和微服务配合保证数据的一致性。
一般情况下微服务中的业务处理采用异步模式，发出记账申请后处于等待状态，区块链网关将记账申请转发给区块链平台。如果区块链平台返回接受Accept或者拒绝Reject，将结果通知微服务；如果区块链平台返回超时或者不可确定错误，即开始定时轮询，得到结果后通知微服务。同时，微服务本身需要具备事务补偿的模式，如果记账失败进行反交易处理。这种数据一致性处理的方式，是微服务多种处理方式中的一种，我们一般使用服务编排的方式降低这种模式的开发复杂度。
下面是一个示例：
这是一个可靠事件与区块链交互的流程：
1）应用框架接到请求后首先记录业务流水，然后执行业务逻辑，记录业务数据，最后在事件表中留下对区块链平台调用的记录，事务完成 2）事件处理轮询事件记录，有更新时通过区块链网关调用区块链平台，如果调用成功，改变事件状态，如果失败就要调用业务补偿的机制了。
既然数据有本地存放，也有区块链平台存放，就有不一致的可能，就必须对账。传统对账有以我为主、以他为主两种模式。这里就只能以他为主，以区块链平台为主了。由于区块链技术针对交易的特点对存储结构进行了要求，利用已有的时间戳、交易先后次序，可以是对账变得更加容易。
基本的对账处理流程如下
区块链平台和企业应用的记录必须有关联的id（可以是多要素的组合）区块链平台和企业应用都要保证生成的对账文件明细记录的连续性对于“隔日账”需重复核对区块链是一种新兴的技术，他的本质是一种加入业务特性的分布式数据库，通过对区块链技术的研究，我们找到了业务与区块链技术结合的方式，提出了微服务应用架构集成区块链的技术模式。
1、区块链的业务价值是通过数据共享降低信任成本。
区块链建立了一个记账簿，每个参与方在交易中都通过这个记账簿进行交互，保证每一笔发生的交易一定被可靠的记录下来并不可篡改，不必再反复确认，不必担心技术问题导致的业务流程变更，不必做应急系统，从而降低了信任成本。
2、区块链技术的本质是分布式数据库。
区块链技术的数据共享方式要满足（1）多副本、（2）可靠记录、（3）不可篡改、（4）多方透明几个特性，总结下来，区块链技术对应用而言，就是一个分布式数据库，分别对应分布式数据库的（1）分布式存储、（2）点对点可靠传输、（3）存储过程与（4）数据安全几个方面。
3、为分布式应用而生的微服务，与区块链技术是天生的一对。
微服务通过区块链网关与区块链平台交互，区块链网关主要功能包括通讯网关、事件监听，同时配合微服务应用框架，完成数据一致性、对账功能。与区块链网关集成的能力，是微服务架构天生具备的。
以上是对我们研究成果一个简要介绍，后续我们还会对使用区块链技术的细节进行分析，与大家共同探讨。
从刚刚接触区块链技术的一头雾水，到概念的逐步清晰，再到区块链应用的研发，经历很多困惑，这里列出几个常见的困惑：
困惑1：比特币是区块链技术的一个应用，不能把比特币应用的所有内容都归结为区块链技术
上文提到，区块链技术从比特币中独立出来是 2014 年左右的事情，此前每每举出区块链的案例都是比特币，给区块链技术的应用造成了很多误解。我建议先了解区块链技术，再了解比特币，先理解联盟链的业务场景，再了解公有链的业务场景，公有链看作是联盟链的一种大规模延展，，可以少走一些弯路。
困惑2：公有链情况下数据存储性能不高，但联盟链的性能可以远高于公有链，能满足多数场景的要求
数据一致性问题是分布式存储最大的问题，而并发越高，冲突的概率就越大。区块链技术之所以能支持的每秒交易数（TPS）不高，主要是共识机制比较复杂，或者说共识机制就是刻意为了降低并发性，减少数据冲突的概率。在公有链上，这是一个无法逾越的问题，只能从事实时性要求不敏感的业务。但是，在联盟链中，由于链中的参与方并不多，也不需要每个节点都记账，就可以使用一些性能更高的共识机制，例如前面说的PBFT。我们曾经尝试过一种全对等的算法，可以支持更高的性能。
困惑3：应用区块链技术不一定必须有矿工来挖矿
初次接触区块链技术，矿工/挖矿这个概念让人非常费解：（1）为什么一定要挖矿？（2）为什么要给记账成功的节点奖励比特币来鼓励记账？（3）非比特币的业务中如何鼓励记账？这个困惑归根结底还是把区块链和比特币混淆造成的。前面说过，挖矿是通过工作量证明（POW）达成共识的机制，挖矿能力愈强就取得了记录权。更重要的是比特币的货币属性，发行货币要么靠国家信用（例如纸币），要么靠奇缺资源（例如黄金），比特币为了防止滥发，就需要用算力做为一种奇缺资源。这样说来，比特币实际上把共识算法、货币属性、鼓励记账这几件事都用挖矿来解决了，思路确实精妙。但是，在业务规则不同的联盟链中就不一样了，除了有其他更高效的共识算法外，不需要奇缺资源，不需要专门对记账做鼓励，因为必须记账已经是核心企业之间的契约，可以通过技术手段保证数据的同步，支持审计等能力，自然就不需要挖矿了。
困惑4：目前应用区块链技术不是去中心，而是多中心
去中心是一个理想，经常有人问（1）为什么要去中心？去中心有什么好处？（2）真的能去中心吗？后来，我深入研究联盟链的场景时发现，实际的业务场景大多是多中心（这又是比特币惹的祸，他真的想去中心），例如上述的企业联盟方式，几个建立联盟的核心企业就是多中心，他们共同成为一个新的中心。传统方式建立新的中心，往往通过建立清算机构的方式，而区块链技术让建立中心的成本降低了。
困惑5：不是所有的区块链节点都是记账节点，很多节点仅仅用来进行数据同步而已
多中心就意味着不是每个节点都需要记账，记账的工作由几个中心节点负责就可以了，其他节点与记账节点间是数据同步的关系，也就是非记账节点上也有全部数据。联盟链中非记账节点一般处在加盟企业，由于数据可见性的要求，非记账节点中的数据并不是都可见的，但是这一副本可以做为一种法律依据，提高了篡改数据的成本。
从数据的角度来看，区块链本质是一种分布式数据库，这里的“分布式”是指区块链技术利用链式存储结构不仅解决了分布式数据存储问题，也解决了存储时的分布式一致性问题。区块链技术利用分布式记账簿保证数据可靠传输和访问，利用可自动执行的智能合约来编程和操作数据。所以，我认为，基于分布式数据库来理解区块链，认清区块链技术常见的一些困惑和误区，可以让大家对区块链有个比较正确的理解方式。
