据上证e互动消息，东软集团(600718.SH)表示，在电信领域，公司基于区块链等新型技术，设计并推出了“微服务”架构。公司在金融领域的区块链业务也有布局和业务进展。
今天我们说一说区块链+微服务。
这期说说区块链技术与微服务架构的关系。大家知道，微服务架构是一个分布式的应用技术架构，目的是有效的对应用进行拆分，实现敏捷开发、快速演化、便捷容错与弹性伸缩。前面说到，区块链技术本质上就是分布式数据库，微服务架构与区块链技术的结合，并不能简单的看成是微服务与数据库的结合，而应该把区块链平台做为一个第三方应用进行交互，这也是微服务架构很好发挥作用的地方。
虽然目前的区块链平台一般都有SDK和REST服务两种方式，按照上述的原则，一般不要使用 SDK，而是远程调用方式，采用微服务的设计原则，使用区块链网关，把微服务与区块链平台集成的功能集中到网关中，见下图：
微服务通过区块链网关与区块链平台交互，区块链网关主要功能包括通讯网关、事件监听，同时配合微服务应用框架，完成数据一致性、对账功能。与区块链网关集成的能力，是微服务架构天生具备的。
何谓微服务？
微服务的核心在于采用“小规模，快反馈”的机制降低软件系统的复杂性并通过虚拟和自动化技术分散风险，从而可以快速面对市场变化带来的各种挑战，并能够快速销售创新，获得市场的反馈。而不仅仅是利用到了时下新兴的语言，编程框架或工具。
微服务架构
1.特征
自动化部署，端点智能化，语言和数据的去中心化控制。
2.架构
一种将一个单一应用程序开发为一组小型服务的方法，每个服务运行在自己的进程中，服务间通信采用轻量级通信机制(通常用HTTP资源API)。可通过全自动部署机制独立部署，共用一个最小型的集中式的管理。服务可用不同的语言开发，使用不同的数据存储技术。
去中心化基础设施
去中心化数据库
3.微服务设计模式
聚合式(推荐)
代理(推荐)
链式
分支
异步消息
微服务落地存在的问题
虽然微服务现在如火如荼，但对其实践其实仍处于探索阶段。很多中小型互联网公司，鉴于经验、技术实力等问题，微服务落地比较困难。如著名架构师Chris Richardson所言，目前存在的主要困难有如下几方面：
1）单体应用拆分为分布式系统后，进程间的通讯机制和故障处理措施变的更加复杂。
2）系统微服务化后，一个看似简单的功能，内部可能需要调用多个服务并操作多个数据库实现，服务调用的分布式事务问题变的非常突出。
3）微服务数量众多，其测试、部署、监控等都变的更加困难。
随着RPC框架的成熟，第一个问题已经逐渐得到解决。例如dubbo可以支持多种通讯协议，springcloud可以非常好的支持restful调用。对于第三个问题，随着docker、devops技术的发展以及各公有云paas平台自动化运维工具的推出，微服务的测试、部署与运维会变得越来越容易。
而对于第二个问题，现在还没有通用方案很好的解决微服务产生的事务问题。分布式事务已经成为微服务落地最大的阻碍，也是最具挑战性的一个技术难题。
不能把所有数据都存储在区块链平台中，而是将交易数据存储在区块链平台，这样就有了本地数据库的数据与区块链交易数据的一致性问题。一般来说，我们不能依赖区块链平台支持事务的回滚，因为这个分布式的记账簿一旦记账就是不可更改的，我们甚至不能指望区块链平台实时给应用反馈记账是否成功，因为有可能返回超时错误，不清楚是否记账成功。
于是，区块链网关需要和微服务配合保证数据的一致性，一般情况下微服务中的业务处理采用异步模式，发出记账申请后处于等待状态，区块链网关将记账申请转发给区块链平台。如果区块链平台返回接受Accept或者拒绝Reject，将结果通知微服务；如果区块链平台返回超时或者不可确定错误，即开始定时轮询，得到结果后通知微服务。
同时，微服务本身需要具备事务补偿的模式，如果记账失败进行反交易处理。这种数据一致性处理的方式，是微服务多种处理方式中的一种，我们一般使用服务编排的方式降低这种模式的开发复杂度。