区块链技术与微服务架构的关系

每一项新技术的出现和发展都会与已有的技术和实践相关联。 例如，微服务作为一种技术架构，实际上是基于SOA架构、JavaEE等分布式架构，进一步明确了服务实现的方式和规则。

区块链技术诞生于比特币。 作为一种多方可信交易和技术模型，受到了包括国家、政府、监管机构在内的众多商业方的关注。 反而让技术从业者有些摸不着头脑。 这是什么技术？ 它解决了什么问题，可以在哪里使用？ 朴元科技近年来持续对微服务和区块链技术进行研究。 在这里，我想与大家分享一下研究结果。 我们的研究主要集中在以下几个方面：

区块链技术适用的应用场景有哪些，该技术带来了哪些价值？

区块链技术由哪些技术组成，与现有技术有什么关系？

采用区块链技术后，应用技术架构如何，与微服务架构的关系，现有应用如何迁移？

区块链的商业价值

区块链技术始于比特币，由中本聪于2008年提出，引发了比特币热潮。 然而，在比特币热潮消退之后，比特币提出的问题和解决方案吸引了我们。 2014年前后，区块链逐渐从比特币中分离出来。 作为自主技术开发，进入2.0时代。 它用数字资产解决商业信任问题，同时用数字化手段提高商业效率。 业内已有尝试。

区块链作为一项独立的技术发展，分为公链、联盟链、私有链三个方向。 从商业角度看，区块链的核心价值在于通过数据共享建立多方信任机制。

多方业务产生的信任问题是采用区块链技术的驱动力

信任问题一直是个大问题。 为了解决信任问题，人类投入了大量的时间和金钱。 尤其是涉及多方的业务，信任成本更高。 这里我举一个复杂的例子：信用证业务（见下图）。 信用证是指开证行应开证人（买方）的要求，按照其指示，向受益人开具的载有一定金额，并在一定期限内与所需文件。 信用证是国际贸易中最重要、最常用的支付方式（此段摘自百度百科）。

之所以举这个例子是因为区块链技术适用的场景往往是复杂的业务场景。 简单的例子很容易被误解。 这里我通俗易懂的解释一下。 在国际贸易活动中，买卖双方往往互不信任。 、进口商（买方）担心出口商（卖方）预付款后不发货； 只能在当地低价出售，此时买家会去买底），典型的麻棒怕两端。 于是，双方各找一家银行作为担保人，两家银行出具​​凭证，代理进出口商之间的业务往来。 条件满足后，由银行支付货款，降低进出口商的风险。 这是信用。 证书业务。 即便如此，信用证诈骗案仍然不少。 银行为了规避风险，需要各种书面证明，反复确认……业务办理周期会很长。

上图中信用证业务的参与方包括出口商、进口商、开证行、通知行、发送行/通知行、运输公司。 它是典型的多方业务，但通常这些参与者只是一部分，可能会有海关、保险公司、评级机构等机构加入交易链条。

多方业务解决了信任问题。 现有方案的高成本在哪里？

现在通过建立第三方机构来解决多方参与业务的信任问题。 例如，上述信用证业务就是通过SWIFT组织（环球银行金融电信协会）的SWIFT系统开立信用证。 银行等金融机构 金融交易是通过与同行交换短信完成的，通过SWIFT进行跨行转发。

SWIFT只解决了部分问题，还很遥远，例如：

必须要注意的是，为了把业务讲清楚，我简化了很多内容，比如如何进行跨行清算，如何进行支付等等。 总之，建立第三方机构来解决信任问题，无论是在业务上还是在技术上都非常复杂。

区块链技术通过数据共享降低信任成本

如果有分布式账簿： （1）参与人核算后有不少份，不再是家庭意见； (2) 提交的交易必须有记录； (3) 保证记账不可逆，不可篡改； (4) 参与者的交易记录相对透明，新的交易可以通过这些记录进行验证。

如果一个组织建立了这样一个账本，交易中的每个参与方都通过这个账本进行交互，保证发生的每一笔交易都必须可靠记录，不可篡改，因此不需要重复确认。 不用担心技术问题导致的业务流程变更，不用做应急系统，成本低很多。

通过分布式记账实现数据共享，从而降低信任成本，这就是区块链技术的价值所在。

联盟链是区块链技术应用的首选方向

既然区块链是分布式账本，谁来建立这个账本？ 这是本技术应用的核心问题。 目前有3种创建账簿的方式：

公链和互联网一样，是一个开放的网络基础设施，对任何人开放，任何人都可以自由加入。

私有链，建立在组织内部，可以帮助组织完成组织内部的审计等工作。

联盟链由相关核心企业针对特定业务建立，采用多中心（每个核心企业为一个中心）的方式，其他上下游企业加入。

公有链建立困难，业务场景不够精准，分布式存储带来的低性能阻碍了可用的应用场景，而私有链脱离了区块链的商业价值，只利用区块链作为一个技术组件。 . 在目前的应用场景中，大部分都可以通过联盟链来解决，联盟链在商业上的建立相对容易，性能也远高于公链。

从上面的描述可以理解，公链太理想化了，私链处理的问题完全可以用传统架构来解决。 而企业联盟针对具体业务建立的联盟链，应用方向更明确，商业价值更明确。 图片是一个联盟链的例子：

区块链技术的数据共享方式必须满足（1）多份副本，（2）可靠记录，（3）不可篡改，（4）多方透明等特点。 总结了以上特点。 采用区块链技术后，应用技术架构如上图所示。 可见，区块链技术是应用的分布式数据库。

本质是分布式数据库

与区块链技术相比，分布式数据库的概念显然更容易理解。 我们可以从分布式数据库的一些基本概念入手，了解区块链的技术实现。 这些概念包括数据存储、点对点可靠传输、存储过程和触发器（智能合约）、数据安全。

分布式数据存储：链式存储和共识机制

区块链技术的数据共享是分布式账本，交易记录是多副本的，首先要解决分布式数据存储的问题。

1、区块链存储的基本单位是区块，区块采用链式结构，即新加入的区块（类似于数据库中的一行记录）知道上一个区块（上一行记录）是什么是的，并且可以追溯到。 对根来说，区块的标识就是区块的哈希值。 同时，链式结构保留了业务生成的轨迹。 添加新交易时可以根据之前的记录进行验证，确保区块内容不易被篡改。

这种模式在传统的数据库设计中也有使用，比如下图中的拉链表的形式。 每次更新数据，都采用追加（Insert instead of Update）方式，有开始时间、过期时间和是否有效。 , 以保留整个交易历史记录。

区块链将其转化为底层固有模型，加入了哈希、时间戳等机制，从技术上保证了链的正确性，因此非常有价值。

2、由于是分布式、多中心的存储方式，存储时需要解决分布式一致性问题。 在区块链的前身比特币应用中，解决这个问题的方法是工作量证明（POW，Proof-Of-Work）方法，即通过工作获得指定的结果，并用结果来证明所做的努力。

这也是我接触区块链技术第一个迷茫的地方。 为什么一定要用工作量来证明呢？ 还有别的办法吗？ 区块链技术独立于比特币之后，大家把这个问题归结为共识问题。 工作量证明是一种达成共识的方式，这更加清晰。 于是出现了权益证明（POS，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架构（staged event-driven architecture），将访问、访问、处理分离（处理主要包括记录流向、数据包解包、安全验证等功能）。 与队列互联，采用异步模拟同步的方式，这是一个集成的基础设施。

可以分配访问、处理、访问三个阶段的处理资源。 资源主要包括处理线程和访问输出连接。 根据不同的业务，可以使用不同的资源为其服务，比如升级升级、限流等，特性更容易实现。

为了方便运维，需要具备对业务进行分组的能力，可以按照分组进行批量运维管理。

事件监听：Hook和轮询方式

如果账本发生变化，如何通知微服务，这就是区块链网关中事件监听的作用。 目前很多区块链平台都没有提供事件接口。 以后就算有，也很难统一。 如前所述，智能合约在沙箱中运行。 为了保证数据的一致性，不可能支持调用外部服务，也不能做事件监听的回调，所以需要在区块链网关中处理。

微服务可以注册监控某类交易，区块链网关通过区块链平台的查询接口定时检索，发现数据变化时通知微服务。 这是一种低效的方法，但区块链平台本身的性能并不高。 延迟主要是共识机制造成的，轮询方式不会有太大影响。 这也有望改善区块链平台本身。 地方。

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

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

一般来说，我们不能依赖区块链平台来支持交易的回滚，因为分布式账本一旦记录下来，就无法更改。 我们更不能指望区块链平台实时反馈给应用是否记账成功。 因为有可能返回超时错误，不清楚是否计费成功。 因此，区块链网关需要配合微服务来保证数据的一致性。

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

这是一个例子：

以下是与区块链交互的可靠事件流：

应用框架收到请求后，首先记录业务流程，然后执行业务逻辑，记录业务数据，最后在事件表中留下区块链平台调用的记录，交易完成。

事件处理 轮询事件记录区块链技术与比特币的关系，有更新时通过区块链网关调用区块链平台，调用成功则改变事件状态，失败则调用业务补偿机制。

和解

由于数据存储在本地，也存储在区块链平台上，存在不一致的可能，因此需要对账。 传统对账有两种模式：以自我为中心和以他人为中心。 这里我们只能关注他和区块链平台。 由于区块链技术需要根据交易的特点来存储结构，利用已有的时间戳和交易序列可以使对账更加容易。

基本对账流程如下：

区块链平台和企业应用的记录必须有一个关联的id（可以是多个元素的组合）

区块链平台和企业应用都必须保证生成的对账文件的详细记录的连续性

对于“日常账户”需要仔细检查

总结与反思

区块链是一项新兴技术。 它的本质是一个具有业务特性的分布式数据库。 通过对区块链技术的研究，我们找到了一种将业务与区块链技术相结合的方式，提出了微服务应用架构，融合了区块链的技术模型。

1、区块链的商业价值在于通过数据共享降低信任成本。

区块链建立一个记账本，每个参与者在交易中都通过这个记账本进行交互，确保发生的每一笔交易都必须可靠记录，不可篡改。 无需反复确认，无需担心。 技术问题引起的业务流程变更不需要应急系统，从而降低信任成本。

2、区块链技术的本质是分布式数据库。

区块链技术的数据共享方式必须满足（1）多份副本，（2）可靠记录，（3）不可篡改，（4）多方透明等特点。 分布式数据库对应于（1）分布式存储，（2）点对点可靠传输，（3）存储过程和（4）分布式数据库的数据安全方面。

3、分布式应用微服务与区块链技术天生一对。

微服务通过区块链网关与区块链平台交互。 区块链网关的主要功能包括通信网关和事件监控。 同时配合微服务应用框架完成数据一致性和对账功能。 与区块链网关集成的能力是微服务架构中固有的。

以上是对我们研究成果的简要介绍。 未来，我们将详细分析区块链技术的使用细节，与您共同探讨。

认识区块链的几个困惑

从刚接触区块链技术时的迷茫，到概念的逐渐清晰，再到区块链应用的开发，我经历了很多迷茫。 以下是一些常见的混淆：

困惑一：比特币是区块链技术的应用，比特币应用的所有内容都不能归于区块链技术

上文提到，区块链技术独立于比特币是在2014年左右，在此之前，区块链的每一个案例都被引用为比特币，这给区块链技术的应用造成了很多误解。 我建议先了解区块链技术，再了解比特币，先了解联盟链的业务场景，再了解公链的业务场景。 公链算是联盟链的大规模延伸，可以少走一些弯路。

困惑二：数据存储在公链的情况下性能不高，但是联盟链的性能可以远高于公链，可以满足大部分场景的需求

数据一致性问题是分布式存储最大的问题，并发越高，发生冲突的概率就越大。 区块链技术之所以能够支持低每秒交易数（TPS），主要是因为共识机制比较复杂，或者说共识机制是为了降低并发性，降低数据冲突的概率而刻意设计的。 在公链上，这是一个无法逾越的难题，只能从事对实时性要求不敏感的业务。 但是在联盟链中，由于链上的参与者不多，每个节点都不需要记账，所以可以采用一些性能更高的共识机制，比如上面提到的PBFT。 我们已经尝试了一种可以支持更高性能的全对等算法。

困惑三：区块链技术的应用不一定需要矿工挖矿

刚开始接触区块链技术的时候，矿工/挖矿这个概念很费解：（1）我们为什么要挖矿？ （2）为什么要给记账成功的节点奖励比特币来鼓励记账？ (3) 如何鼓励非比特币业务记账？ 归根结底，这种混淆是混淆了区块链和比特币造成的。 如前所述，挖矿是一种通过工作量证明（POW）的共识机制。 挖矿能力越强，记录权越强大。 更重要的是比特币的货币属性。 货币由国家信用（如纸币）或稀缺资源（如黄金）发行。 为了防止垃圾邮件，比特币需要将算力作为一种稀缺资源来使用。 这样一来，比特币实际上是用挖矿来解决共识算法、货币属性、鼓励记账。 这个想法真的很微妙。 但是在不同业务规则的联盟链中就不一样了。 除了其他更高效的共识算法之外，不需要稀缺资源，也不需要专门鼓励记账，因为记账已经是核心企业了。 The contract can ensure data synchronization through technical means, support auditing and other capabilities, and naturally there is no need for mining.

Confusion 4: The current application of blockchain technology is not decentralized, but multi-centered

Going to the center is an ideal, and people often ask (1) why go to the center? What are the benefits of going to the center? (2) Can I really go to the center? Later, when I studied the scenarios of the alliance chain in depth, I found that most of the actual business scenarios are multi-centered (this is the fault of Bitcoin again, he really wants to go to the center), such as the above-mentioned enterprise alliance method, several alliance-building Core enterprises are polycenters, and together they become a new center. The traditional way to establish a new center is often through the establishment of a clearing institution, and blockchain technology reduces the cost of establishing a center.

Confusion 5: Not all blockchain nodes are accounting nodes, many nodes are only used for data synchronization

Multi-center means that not every node needs to keep accounts. It is enough for several central nodes to be responsible for the bookkeeping work. There is a data synchronization relationship between other nodes and bookkeeping nodes, that is, all non-bookkeeping nodes also have data. The non-bookkeeping nodes in the alliance chain are generally located in the franchised enterprises. Due to the requirement of data visibility, the data in the non-bookkeeping nodes are not all visible, but this copy can be used as a legal basis, which increases the risk of tampering with data. 成本。

From the perspective of data, the blockchain is essentially a distributed database. The "distributed" here means that the blockchain technology uses a chain storage structure to not only solve the problem of distributed data storage, but also solve the problem of storage. Distributed consistency problem. Blockchain technology uses distributed accounting books to ensure reliable data transmission and access, and uses automatically executable smart contracts to program and manipulate data. Therefore, I think that understanding the blockchain based on distributed databases and recognizing some common confusion and misunderstandings in blockchain technology can give everyone a more correct understanding of blockchain.

About the author: Jiao Lieyan, who joined Puyuan Information in 2001, is currently CTO. He is fully responsible for the operation of Puyuan Information technology and products, and is an important decision-maker for the company's technology development strategy.

Jiao Lieyan has more than 20 years of experience in the research of enterprise technology architecture, and has long been committed to the research and practice of enterprise computing in distributed environments, SOA and cloud computing technology. After joining Puyuan Information, he organized and completed the research and development of a series of core products, including SOA application platform, business integration platform with BPM &/ESB as the core, and big data platform with complex event processing/data governance/job scheduling as the core. He presided over the planning and research and development of the technology platforms of many large-scale enterprises such as Industrial and Commercial Bank of China and China Construction Bank. He is the author of the book "SOA China Roadmap - Implementation Edition".