今天打算写写关于 IM 去中心化涉及的架构模型变化和设计思路，去中心化的概念就是说用户的访问不是集中在一个数据中心，这里的去中心是针对数据中心而言的。

站在这个角度而言，实际上并非所有的业务都能做去中心化设计，对于一致性要求越高的业务去中心化越难做。比如电商领域的库存就是一个对一致性要求很高的业务，不能超卖也不能少卖，这在单中心容易实现，但多中心纯从技术层面感觉无解，可能需要从业务和技术层面一起去做个折衷。

反过来看 IM 的业务场景是非常适合做去中心化设计的，因为其业务场景都是弱一致性需求。打开你的微信或 QQ 仔细观察下，对大部分人来说与你联系最频繁的实际多是在地域上离你最近的人，人与人之间的心理距离和物理距离会随着时间渐趋保持一致。所以根据这个特点，按地域来分布数据中心和聚合人群是比较合适的。

在进入去中心化 IM 架构模型之前，我们先看看中心化架构是怎样的，分析其关键设计再来看如果要去中心化需要做哪些变化？

中心化

IM 的中心化架构并不意味着只有一个数据中心，它也可以是多数据中心的，如下图。

之所以说它是中心化架构，关键特征是其存在共享的数据存储。部署在两个数据中心的应用需要共享访问统一的数据存储，而这种共享访问实际是依赖数据中心之间的专线连通，这样的架构也限制了能选取的数据中心地理位置的距离。而实现去中心架构的关键点就在于规避跨数据中心的共享存储访问，使得应用在其自身数据中心实现访问闭环。

我们这里只分析下实现 IM 消息互通这个最重要场景下共享数据存储里需要存些什么数据呢？一个是用户上线后的「座标」，主要指用户本次在线接入了哪台机器的哪根连接，这个「座标」用于在线消息投递。而另一方面若用户离线时，别人给它发消息，这些消息也需要存储下来，一般称为用户的「离线消息」，下次用户上线就可以自动收取自己的离线消息。

中心化架构实际能做到的极致就是把读实现自有数据中心闭环，而写依然需要向主数据中心所在的存储写入。而 IM 的写入场景还不算是一个低频操作，那么要实现去中心化架构关键点就在如何解决写的问题上。

去中心化

在设计 IM 的去中心化架构之前，希望去实现这个架构并编写代码时，不需要去考虑最终部署到底是去中心的还是中心的。编码时就像开发中心化架构一样去实现场景的功能，而去中心化的能力做为纯基础的技术能力，通过附加的方式来获得，先看看架构图的变化，如下。

这里的变化是为「座标」增加一个「数据中心」纬度，当按通用的方式去本地存储定位用户时，发现一个非本地的座标时消息该怎么投递？这里可以在每个本地数据中心额外添加一个消息网关程序，注册到本地存储中，并负责接收所有非本地座标的消息，这有点像路由网络中的边界网关。

消息网关统一接收应当发往其他数据中心的消息，以实现跨数据中心的消息流转。这里有个疑问是其他数据中心的「座标」是怎么跑到本地来的？离线消息的场景又该如何处理呢？关于这两个问题，就涉及到我们解决跨数据中心同步数据的关键技术了。

关键技术

结合 IM 的业务场景，实际它对同步的延时具有一定的容忍度。所以我觉得基于 Gossip 协议的小道消息传播特性就能很好的满足这个同步场景。

关于 Gossip 我是在新近的 NoSQL 数据库 Cassandra 上听说的，后来 Redis Cluster 也利用了该协议来实现无中心化集群架构。但 Gossip 协议可不是什么新东西，实际关于它的诞生可以追溯到好几十年前的施乐研究中心，就是为了解决数据库同步问题被我们的前前前辈想出来的。

这个协议的灵感来自于办公室小道消息的传播路径，当一个人知道了一条小道消息，他碰到一个朋友并随口告诉了他，朋友又告诉了朋友的朋友，没多久整个办公室都知道了，也就完成了信息的同步。借用这个模型，实际上我们需要同步的信息就是用户的在线「座标」和「离线消息」。

因为 Gossip 自好几十年前已经有很多论文证明并公开发表，而且近年也有 Cassandra 和 Redis 的成功工程实践，所以我就先不用去怀疑其可行性，而是直接利用其结论了。根据其特性，分析 IM 的去中心场景在引入 Gossip 后有些什么可供观察的变化和值得注意的方面。

在一个稍具规模的 IM 场景下，用户总是在上上下下，消息也在不停的在「在线」和「离线」之间变化，所以需要通过 Gossip 同步的信息是时时存在的。所以假设我们在某个时刻去拍一个快照（实际做不到），得到的结果是多个数据中心的数据肯定是不一致的，几乎不存在所谓的全局最终一致性的某一时刻。在这样的客观环境下，对 IM 的业务场景有多大影响？

当用户A在 IDC#1 在线，用户B 在 IDC#2 刚上线，这里存在一个同步时差，那么此时用户A给用户B发消息，在本地没有用户B的座标，所以进入离线消息池。用户B此时不能立刻收到用户A的消息，但离线消息池会在随后通过 Gossip 协议同步到用户B所在的 IDC#2，用户B此时就可以通过离线消息收取用户A的消息。

上面描述了一种临界场景，在这种临界场景下，用户收消息存在延时。而这种临界场景实际上并不是常态，而且 IM 用户实际对这种刚上线的消息延时存在很高的容忍度。这一点我想大家用 QQ 可能体会过，有时一上线都一分钟了，还会收到之前的离线消息，我不知道这是有意的延时还是真有这么长的系统延时。

那么使用 Gossip 协议从理论上来估算下会产生多久的延时？假设我们在全国东西南北中各部署一个数据中心，一共五个。五个数据中心之间无专线，走公网互通，网络延时最大 200 ms。使用 Gossip 完成在五个数据中心的最终一致性同步最大需要多长时间？这里我直接引用 Gossip 论文结论：

Cycles = log(N) + ln(N) + O(1)

当 N=5 时，完成全部同步，需要节点间私下传播的次数，套用公式得到 3.3 次，取整得 4 次。按最大网络延时 200 ms，每次 Gossip 交换信息间隔 100 ms，那么协议本身固有延时大约 4x200 + 4x100 = 1.2s，而再算上程序开销，这个延时很可能在数秒内波动，这个量级的延时对于少数的临界场景是完全可以接受的。

第一节 简介

用以太坊开发构建一个去中心化电商DApp！我们将用区块链、星际文件系统（IPFS）、Node.js和MongoDB来构建电商平台类似淘宝的在线电商应用，卖家可以*地出售商品，买家可以*地购物：

去中心化： 和淘宝或eBay不同，我们把所有的商业逻辑和核心数据都放在以太坊区块链上，这使 得它成为一个完全去中心化的应用。和淘宝这样中心化的电商平台相比，一个去中心化的P2P电商应用显然有其独特的价值——至少你不用担心被平台封账户了。

IPFS： 在以太坊上存储用于商品展示的图片和描述超文本十分昂贵，由于以太坊虚拟机的限制， 有时甚至是不可行的。为了解决这个问题，我们将会把商品图片和商品描述信息存储在同样去中心化的星际文件系统（IPFS)中，而仅仅在链上保存这些数据的ID。

商品拍卖： 对于卖家而言，拍卖显然是一种非常好的提升商品利润空间的销售手段。因此我们在课程项目中将实现去中心化环境下的维科瑞（Vickery）拍卖 —— 这非常类似于eBay的自动竞价系统，而不是简单地对商品进行固定标价。

资金托管：中心化的平台有一个优点在于它天然提供了买卖双方之间的信任中介。在去中心化的环境中，我们将使用一个多方托管合约来应对买卖双方可能的风险，托管合约采用投票机制来决定买家货款的最终流向。

链下数据存储： 不要被去中心化限制我们的思维，传统的技术依然有其强大之处。我们将使用MongoDB在链下做一个同步的数据备份，以便实现单纯用区块链很难实现的功能：灵活的商品查询。

第二节 去中心化，why？

在开始构建我们的应用之前，非常值得花一分钟时间，来理解为什么要在像以太坊这样的去中心化平台上搭建在线卖场。

eBay或淘宝这样的C2C电商平台已经获得了巨大成功，因为它使得买卖双方都相当便利：

在互联网成为主流之前，人们只能在小范围内、或者在邻里之间买卖商品。当越来越多的人使用互联网， 出现了像eBay这样的平台，无论来自世界的任何一个地方，你都可以在网上买卖商品。无论是商家还 是消费者，这样的平台都有其价值。

尽管eBay这样的平台方便了大家，也改善了贸易和经济，但它也存在一些缺点：

被平台束缚。参与的商家受制于拥有平台的企业。在任何时候，平台拥有者可以自行决定在是否对某个商家进行封号处理，而如果商家严重依赖于平台，那么账号被封就是一个巨大的打击。

商家费用高。商家上架商品要交费，售出商品也要交佣金。收费本身并没有错，毕竟eBay这样的平台提供了服务。但是，上架费有时太高了，这导致商家最后盈利很少，或是将成本转嫁到消费者身上。

数据失控。商家或消费者都无法拥有本应属于自己的数据。评论、购买历史等等所有数据都为平台拥有者所有。比如，如果一个商家想要换一个提供商，或者想要导出商品评论或是其他数据都非常不容易，甚至不可能。

在以太坊上构建的去中心化电商平台就解决了这些问题：商家的账户不会被封；数据也是公开的，所以很容易导出数据；相对于中心化的平台，交易佣金也会低得多。

第三节 初步的功能特性

现在你应该已经理解了为什么要构建去中心化的电商应用，也了解了我们要构建的应用是什么，现在让我们来大致看一下，在这个项目中将要实现的主要功能特性：

商品上架：应用应该支持卖家上架商品进行销售。我们将实现让任何人*上架商品的功能。

商品浏览与搜索：应用应该支持买家方便地浏览商品列表。我们会实现浏览商品的功能，以及基于商品类别、拍卖时间等条件进行查询的功能。

商品拍卖：跟eBay一样，我们会实现维科瑞拍卖方式的商品竞价销售。由于以太坊上的一切交易都是公开的，因此我们的实现将会与中心化环境下有所不同。

资金托管：一旦出价结束，商品拍卖有了赢家以后，我们会创建由胜出的买方、卖方和任意第三方参与的托管合约，由托管合约来管理交易资金。

托管资金保护：为了保护托管资金，我们将采用多重签名（2/3）来实现防欺诈保护，即三个参与者有两个同意时，才会将托管资金释放给卖方，或是将托管资金返还给买方。

为了便于查询，我们会将商品数据同时存在链上和链下（数据库）；同时，为了避免图片等数据占用昂贵的链上存储，我们将把图片和商品描述信息上传到同样去中心化的IPFS网络。

第四节 基础知识要求

为了顺利地完成本课程的学习，你应该对以下语言/技术有一些了解：

Solidity/Truffle：课程将会深入使用solidity来编写合约。如果你还没有学过，建议你先学习一下以太坊开发DApp入门教程，这样至少写过一两个简单的合约。同时，对truffle开发框架的基本了解也会十分有助于完成本课程。

HTML/CSS/JavaScript：相比入门课程，本课程将会有更多的HTML和CSS代码。你应该对使用HTML/CSS构建前端有基本的了解。同时，我们将会进一步使用JavaScript。它会在服务端将数据保存到数据库，查询数据库并将结果返回给前端。web3.js用于前端与区块链的交互。为了适用各种背景的学习者，我们已经保持JavaScript代码尽可能地简单。

Database：我们会用MongoDB在链下保存产品信息。无须特别了解MongoDB，但是基本的数据库知识有助于你顺利完成本课程的。

第五节 系统架构

在开始着手具体的实现之前，先来看一下在本课程我们将要构建的去中心化电商DApp的架构。

Web前端：web前端使用HTML/CSS/JavaScript开发，其中大量使用了web3js来访问区块链。用户将会通过这个前端应用来访问以太坊、IPFS和NodeJS服务器。

以太坊区块链：这是去中心化应用的核心，所有的代码（电商合约、资金托管合约）和交易都存储在链上，这包括所有的商品信息、买家的出价信息、商品竞价结果、资金流向投票结果等。

MongoDB：尽管核心数据存储在区块链上，但是为了方便买家对商品的检索和查询，例如只显示某一类的商品，或者显示即将过期的商品等等，我们会用MongoDB数据库来同步地存储和检索商品信息。

NodeJS服务器：这是后端服务器，我们会利用它给前端提供REST风格的API来查询商品， 同时，也利用它来响应对前端静态页面的请求。

IPFS: 当卖家上架一个商品时，前端会商品图片文件和介绍文本上传到IPFS，并将所上传文件的哈希值存到链上。

第六节 理解架构的作用

为了帮助理解上一节谈到的那些组件的作用，让我们来看看一下卖家上架一个商品的流程：

(1)前端使用一个HTML表单来采集用户输入的商品细节，例如起拍价、商品图片、描述信息等。

(2)(3) 前端将商品图片和介绍文本上传到IPFS，并返回所上传内容对应的链接（哈希）。

(4)(5) 然后，web前端会调用电商合约将商品信息和IPFS链接存储到链上。当合约成功地将商品存入区块链后，就会触发一个事件，该事件中包含了商品所有的信息。

(6)(7)(8)NodeJS服务器监听区块链事件，当事件被电商合约触发时，服务器读取事件内容并将商品信息插入到MongoDB数据库中。

当开始具体实现商品上架这一特性时，我们将重温这一流程。

第七节 敏捷开发

我们将采用敏捷开发的思想来实现去中心化电商DApp：

我们将全部的产品特性分别列入8个迭代周期，通过每一次的冲刺（sprint），我们都将得到一个可以发布的版本：

前两个冲刺主要集中在使用solidity和truffle框架实现电商合约方面，这包括合约的设计、开发 、编译、部署与测试：

sprint-1：实现电商合约的商品上架和展示方法。

sprint-2：实现电商合约的商品竞价和出价揭示方法。

在电商合约基本实现之后，接下来的三个冲刺主要集中在前端用户界面的构建方面，这包括使用web3 与合约的交互，以及通过ipfs的开发接口上传图片等数据交互，当然，还有必不可少的DOM操作：

sprint-3：为买家提供商品浏览界面。

sprint-4：为卖家提供商品上架操作界面。

sprint-5：为买家提供商品详情界面、竞价表单以及出价揭示表单。在接下来的两个冲刺里，我们将首先实现资金托管合约，用来管理竞价结束后胜出买家的资金；然后实现相应的用户操作界面。

sprint-6：实现资金托管合约。

sprint-7：基于资金托管合约，为参与托管各方提供操作界面。最后，为了便于商品的查询检索，我们将使用MongoDB来实现商品数据的链下存储。

sprint-8：实现链下数据的同步与数据查询