当微服务撞上区块链

OS Proof of Stake）方式，是一种通过业务规则达成共识的方式；实用拜占庭容错（PBFT  Practical Byzantine Fault Tolerance）方式，是一种通过技术规则达成共识的机制。在公有链上，工作量证明（POW）还是一种最主要的共识方式，不容易取代，但在联盟链上，完全可以根据自己的情况，创造出新的共识方式出来。我们就根据这一想法，在特定业务中创造过共识算法，解决分布式数据存储的一致性问题。

点对点可靠传输：可靠消息与P2P

区块链技术是一组技术的组合，既然是一个分布式的记账簿，就要解决数据可靠传输问题。包括记账节点（信任节点）之间、非记账节点（非信任节点）、客户端与记账节点（信任节点）之间的数据传输。在以前我们的方案中，往往通过可靠消息或者P2P方式解决数据传输问题，这些技术也被用于区块链技术中。但必须说明的是，在真实业务场景下，不可能把所有的数据都记录在记账簿中，部分业务数据还是要保存在自己的系统中，这就还需要在技术框架上做到本地业务数据与区块链的记账簿保持一致，后文会具体阐述，总之，区块链平台只能保证自身数据之间的一致，业务不能完全依赖区块链平台保证数据一致性。

 

智能合约：触发器与存储过程

智能合约是指当一定条件满足的情况下，可以被自动执行的数字化合约。实现这一特性，在数据库中就是由触发器和存储过程完成的。虽然在目前流行的应用架构中，都不建议把逻辑写在存储过程中，但触发器和存储过程还是常用的工具，尤其在数据迁移相关的运维活动中。区块链技术中智能合约就是触发器和存储过程，他是一个在沙箱中运行的脚本，用于执行区块链业务中的业务逻辑，也可以用于各种检查。举个例子，A产生一笔支付时，可以通过智能合约在数据链上进行检查，如果发现A的余额无法支付这笔交易，就可以中止这笔交易。和存储过程相比，智能合约运行在沙箱之中，不能对外部 API 做调用。这也比较好理解，如果允许外部调用，就可能无法保证自身的数据一致性，后面我们会讲到这种缺陷如何弥补。美中不足的是目前的智能合约并不支持 SQL 语法。

数据安全：用业务手段达成妥协

交易数据是透明的，但不是全部透明，而是相对透明，这是区块链技术的一个难点，关键有二：（1）如何保护隐私，仅仅能看到自己可见的数据；（2）密钥分配问题，例如新加入链中的一个节点会被分配一个新的密钥，如何用这个密钥解读以前链中存储的信息。可见与不可见，这是一个矛盾，理论上没有一个完美的方案，这里我不对区块链技术如何加密、如何做密钥管理、如何同态加密等方式做解读，而是讲讲如何通过业务方法而不是技术手段规避这一问题。举个例子，在一个小企业支付的联盟链中，核心企业包括某银行、企业A，为A的上下游企业提供信贷业务，对于所有交易的数据，银行和核心企业A都是可见的，他们拥有记账节点，对于其他加盟企业，只拥有非记账节点，他们虽然也有全部的数据，但是只能看到自己相关的数据。很明显，加盟企业放弃了自己的部分隐私权，但也得到了生意的机会，这种方式加盟企业是可以接受的，就好比贷款企业要向银行提供经营数据一样。数据安全问题，在技术上很难解决，但通过业务手段是可以规避的，这也是我们看好联盟链的重要原因。

为分布式应用而生的微服务，与区块链技术是天生的一对

最后说说区块链技术与微服务架构的关系。大家知道，微服务架构是一个分布式的应用技术架构，目的是有效的对应用进行拆分，实现敏捷开发、快速演化、便捷容错与弹性伸缩。

微服务的一个核心概念是API网关，由于服务的颗粒变细，网关承担着安全与访问认证等诸多职能。而在现有的大多数微服务架构中，大家都更多的在谈接入网关的概念，实际上按照信息的流向，除接入网关外，微服务还应该有接出网关的概念。

前面说到，区块链技术本质上就是分布式数据库，微服务架构与区块链技术的结合，并不能简单的看成是微服务与数据库的结合，而应该把区块链平台做为一个第三方应用进行交互，这也是微服务架构很好发挥作用的地方。上图中红圈所示的就是微服务与区块链平台进行交互的方式。而微服务的接出网关，就应该起到区块链网关的作用。
 

虽然目前的区块链平台一般都有SDK和REST服务两种方式，按照上述的原则，一般不要使用 SDK，而是远程调用方式，采用微服务的设计原则，使用区块链网关，把微服务与区块链平台集成的功能集中到网关中，见下图：

微服务通过区块链网关与区块链平台交互，区块链网关主要功能包括通讯网关、事件监听，同时配合微服务应用框架，完成数据一致性、对账功能。与区块链网关集成的能力，是微服务架构天生具备的。所以我们说微服务与区块链，天生是一对。

通讯网关：处理微服务发起的对区块链平台的调用

由于区块链平台的服务能力（每秒交易数 TPS）有限，为保证区块链平台的可用性，区块链网关采用了异步处理模式，实现限流、隔离、服务升降级等能力。

网关在微服务应用与区块链平台之间建立了隔离，避免平台与微服务之间互相影响，这是一种 MiddleBox 的集成方式，用一个独立的基础设施做集成。微服务之间的集成往往采用 MiddlePipe 的模式，但是区块链平台做为一个第三方应用，采用 MiddleBox 方式比较好，统一管理与运维比较方便。

由于区块链平台提供的接口各有不同，区块链网关在接受请求后记录交易流水，把区块链平台提供的服务模拟为幂等服务，调用者可以多次调用区块链网关，而区块链网关仅仅调用区块链平台一次。为方便运维，我们可以为区块链平台提供的服务定义SLA，根据这些定义灵活的进行调用的控制。

区块链网关的内部实现是一个 SEDA 架构（分阶段事件驱动架构），把接入、接出和处理分开（处理主要是记录流水、报文打解包、安全效验等功能），三阶段之间用队列连接，采用异步模拟同步的方式，这是一个用于集成的基础架构。

接入、处理、接出三个阶段可处理资源是可以调配的，资源主要包括处理线程和接入接出的连接，根据不同业务可以有不同的资源为之服务，这样升降级、限流等特性就比较容易实现。

为了方便运维，需要对业务有分组的能力，可以根据分组进行批量的运维管理。

事件监听：Hook与轮询模式

如果记账簿发生了改变，如何通知微服务呢，这就是区块链网关中事件监听发挥的作用。目前很多区块链平台并没有提供事件接口，即使未来有也很难统一，前面也说过，智能合约运行在沙箱中，为保证数据一致性不可能支持对外部服务的调用，也不能做为事件监听的回调，这样就需要在区块链网关中进行处理。

微服务可以注册对某一类交易进行监听，区块链网关定时通过区块链平台的查询接口检索，发现数据变更时通知微服务。这是一个效率不高的方法，但区块链平台本身性能也不高，时延主要由共识机制造成，轮询的做法并不会有太大影响，这也是期待区块链平台本身提升的地方。

数据一致性：可靠事件模式是首选

不能把所有数据都存储在区块链平台中，而是将交易数据存储在区块链平台，这样就有了本地数据库的数据与区块链交易数据的一致性问题。

一般来说，我们不能依赖区块链平台支持事务的回滚，因为这个分布式的记账簿一旦记账就是不可更改的，我们甚至不能指望区块链平台实时给应用反馈记账是否成功，因为有可能返回超时错误，不清楚是否记账成功。于是，区块链网关需要和微服务配合保证数据的一致性。

一般情况下微服务中的业务处理采用异步模式，发出记账申请后处于等待状态，区块链网关将记账申请转发给区块链平台。如果区块链平台返回接受Accept或者拒绝Reject，将结果通知微服务；如果区块链平台返回超时或者不可确定错误，即开始定时轮询，得到结果后通知微服务。同时，微服务本身需要具备事务补偿的模式，如果记账失败进行反交易处理。这种数据一致性处理的方式，是微服务多种处理方式中的一种，我们一般使用服务编排的方式降低这种模式的开发复杂度。

下面是一个示例：

这是一个可靠事件与区块链交互的流程：

1）应用框架接到请求后首先记录业务流水，然后执行业务逻辑，记录业务数据，最后在事件表中留下对区块链平台调用的记录，事务完成
2）事件处理轮询事件记录，有更新时通过区块链网关调用区块链平台，如果调用成功，改变事件状态，如果失败就要调用业务补偿的机制了

对账

既然数据有本地存放，也有区块链平台存放，就有不一致