共计 3489 个字符，预计需要花费 9 分钟才能阅读完成。
本篇是基于柏链教育公司、上贸大钻研核心团队、柏链教育系外面成员、以及我在 FISCO BCOS 上进行的联盟链方向摸索的教训分享总结，心愿给大家带来启发及借鉴作用。
这次分享的主题分为 4 个局部：第一是谈谈分布式体系架构特点及差别，第二是谈谈如何进行链上与链下的设计，第三是谈谈如何对服务端与客户端进行设计，第四是总结咱们目前在实际过程中遇到过的分布式体系。
在传统应用软件零碎的开发里，经常会提到最佳实际。对传统软件系统来说，通过多年的倒退，其能够说是最佳实际，但对区块链技术来说，包含咱们在内的所有人，其实都还处于摸索的阶段。
当初的区块链行业相当于 90 年代的计算机行业，正处于我称之为绝对最佳实际。欢送大家一起退出，独特就零碎设计进行深入探讨。
分布式体系架构与传统架构的差别
传统思路下的证书零碎设计
传统思路下设计的是中心化的证书零碎，该零碎蕴含三个必要局部，别离是前端、后端和数据库。
前后端可能会包含许多服务，这些服务均被主体所掌控，即中心化零碎。这个中心化零碎指的是服务治理主体上的中心化，从技术上来说一个传统中心化零碎也能够是分布式架构。
在中心化零碎里，咱们定义三类角色，别离是权威发行者、用户和验证方。
权威发行者，比方一所大学，它能够给学生发放证书；用户不仅能够接管权威发行方所发行的证书，还能够向验证方提交他所领有的证书；验证方在收到用户提交的证书后，能够验证证书的有效性。
传统思路下的证书零碎具备如下特点：
首先，数据库中的 ID 具备唯一性，而唯一性是有限度范畴的，它的应用范畴不会超出所在的数据库。
其次，权威发行方、用户和验证方之间的交互都要通过中心化零碎。比方，权威发行方无奈绕开中心化零碎给用户发行证书，验证方也不能绕开中心化系统验证用户发的证书。一旦中心化零碎呈现问题，所有的角色将面临无奈应用。
区块链思路下的证书零碎设计
在区块链思路下，设计证书零碎可能用的是现成的区块链网络，也可能是特意创立的区块链网络。为了不便传统开发者了解，咱们很多时候将区块链视为具备凋谢个性的由许多节点保护的公共数据库。
因为公共数据库的存在，服务能够不再限定某一家公司部署，比方证书发放服务 A 由柏链教育提供服务，同时另一家公司也想提供服务，于是在开源根底上对系统进行优化革新。它也具备节点的拜访权限，这两个公布服务的数据都会流向公共数据库。之后具备权限的第三方也能够拜访公共数据库。
所有的服务并不禁一个主体来发行，这种设计一方面减少了服务的复杂性，但同时也带来了许多设想空间。
全链惟一数字身份
咱们在设计一般利用时，ID 的作用域是整个利用，所以只有确保全利用惟一就行了。
在区块链利用中，用户的 ID 能够间接与区块链网络相连，它能够领有全链惟一的 ID，即 Weldentity 数字身份（DID）。这个改变意味着当初 ID 扩充了范畴，是全链惟一。
分布式架构与传统架构之间的差别
理解以上信息，咱们再将分布式体系下的证书零碎与传统的证书零碎进行比拟，次要差异体现在：
第一，软件的生命周期。 在传统体系下，服务的生命周期通常小于公司的生命周期；而在区块链思路下，生命周期体现出简单的个性。区块链的生命周期取决于所有参与者。
此外，这些服务之间的生命周期也存在差别，例如证书验证服务是由集体开发的，如果我独自写证书验证服务连贯到数据库中，那么即便提供服务的公司都开张了，我的证书验证服务仍然能够用。所以不同主体所部署的服务，其生命周期是互相独立的。
第二，提供更多的抉择。 传统零碎下，咱们的抉择就是中心化零碎，它是否降级齐全取决于中心化零碎主体的志愿。而在分布式系统下，服务之间存在着竞争关系。假如联盟链中有 A、B、C 三家公司独特提供服务，大家天然会偏向于抉择提供更好服务的公司。
因此在参加主体足够多的状况下，新的零碎外部其实存在着竞争机制，人们在多个服务提供商之间进行抉择，激励大家去提供更优质的服务，促成整个证书零碎市场化倒退。
第三，不同的数据处理形式。 在传统零碎里，即便数据库应用分布式系统里的分片，但从实质上来看它依然是繁多数据库，咱们不须要思考数据在哪。而在区块链零碎下，咱们就须要思考不同的数据到底需存在哪个数据库里，哪些数据须要进行上链解决之类的问题。
第四，交互方式不同。 传统思路下，所有的参与方如果想要和另外的人员进行交互必须通过中心化零碎。然而在新的证书零碎下，用户只有在提交给验证方之前取得了权威发行方的公钥，就能够去验证证书，单方之间实现点对点交互。
如何进行链上与链下设计
在进行链上设计时，首先要善用 CNS 对合约进行版本治理。不同的版本之间，咱们会用不同的版本名称来辨别，例如 1.0、2.0。这样既能使合约更加直观，也能缩小在此过程中呈现 bug 的可能性。
其次，要对合约进行分层，将数据层和数据操作层进行拆散。合约须要优化时，如果所有代码都写在一个文件里，那降级时可能还得对过来的数据进行迁徙。但当初合约分层当前，存储的数据不必改变，也不必去做数据迁徙，咱们就能够间接对合约进行降级。
除了 CNS 和合约分层以外，还要保持“胖链下、瘦链上”和“形象链上、具象链下”的准则。因为链上其实是很重的，咱们把数据存在链上，也在链上进行计算操作。例如，当咱们在链上计算“1+6”，那么链上的每个节点都要执行一次，比起链下运行，累赘减轻了很多。
在区块链上进行数据存储，有多少节点就存储多少次，存储的负载就是节点的数量；在区块链上进行计算操作，所有节点都须要计算一次。
因而，咱们要精简链上合约的逻辑，在设计合约时要全面思考关键问题—— 操作是不是必须要在链上进行执行，数据是不是必须要在链上进行存储，开发者得计算出存储和计算成本最小的合约。
像“1+6”这样的日常计算，这类操作即无需放在链上执行。另外，存证时有时会写太多具体的业务字段，这其实是违反了“形象链上、具象链下”的准则。因而，咱们在设计合约时，会提出合约要具备更高通用性的要求。
那么，存证就应该是哈希上链吗？事实上，这种说法存在肯定的果断性。在理论的业务操作中，它取决于具体目标。
如果咱们做的是司法存证这种业务场景，哈希上链就很正当，因为司法存证的目标是要查看原始数据是否与链上哈希值统一。
但如果是出于其它目标，例如咱们想要将经营数据实在地存储在链上，业务操作中会将 json 转换成 string 再去存储在链上，而应用哈希则达不到目标。
如何对服务端与客户端设计
第一种，纯服务端。这是比拟轻松的抉择，因为它与传统的思路极其类似。譬如咱们要做区块链版的知乎，简略、取巧的形式就是去做领取网站，而后拜访的时候只有客户端。这种形式比拟激进，也不容易出错，适宜于做最开始的尝试。
第二种，轻客户端加服务端的模式。本地如要获取、存储用户的私钥，在服务端传来未签名的交易时，请客户端签名后再发送回给服务端。这样的设计其实是在第一步的根底之上，审慎地迈出分布式的新尝试。
第三种，重客户端加轻服务端的模式。如果要设计数字身份钱包，基于 Weldentity 的零碎其实就能够采取客户端的模式，而新的服务端就仅起到转发作用。
这样的模式会比拟大胆，因为它把更多的性能转移到了客户端这边，这种形式的采纳取决于理论业务需要。就教训而言，一开始还是不要做过于翻新的设计，因为很容易呈现问题，审慎为好。
分布式体系中的架构总结
第一个例子是基于 Weldentity 的证书零碎。能够有两种抉择，一是用户调用服务器端的证书治理服务；二是本地下载了客户端，客户端有专属治理的业务。
这其实是很有意思的一种玩法，用户的证书治理服务既能够是在本人的电脑上，也能够应用某个机构在云商部署的证书治理服务。
第二是基于 WeBASE 的设计。咱们能够把 WeBASE 作为节点前置的一套组件进行区块链接入，把私钥托管在这下面。通过这种形式咱们能够节俭很多事件，能够利用 WeBASE 高效地实现区块链利用。
第三是区块链存证零碎。咱们在 WeBASE 前加了链下中间件，对于存证的内容进行格局验证。这些 Application 提供的存证内容，须要验证通过能力上链。
还有公开查问服务。事实上，很多区块链零碎都有这样的需要，须要提供局部数据的公开查问服务。
具体操作演示，欢送点击观看演示操作：
https://www.qq.com/video/f326…
《超话区块链》
《超话区块链》是由 FISCO BCOS 开源社区推出的直播流动，每周四晚 8 点，社区邀请一位技术极客或利用先锋，做客直播间分享开发实际或利用心得。作为社区固定栏目，《超话区块链》已举办近百场，从技术研究到产业利用均有触达，欢送大家自荐或举荐敌人到直播间分享。加【小助手】入群观看直播。