精华内容
下载资源
问答
  • 架构模型
    千次阅读
    2019-05-23 09:49:34

           我们可以将软件架构归纳成 5 种模型:结构模型、框架模型、动态模型、过程模型和功能模型。最常用的是结构模型和动态模型

    (1)结构模型。这是一个最直观、最普遍的建模方法。这种方法以架构的构件、连接件和其他概念来刻画结构,并力图通过结构来反映系统的重要语义内容,包括系统的配置、约束、隐含的假设条件、风格、性质。研究结构模型的核心是架构描述语言

    (2)框架模型。框架模型与结构模型类似,但它不太侧重描述结构的细节而更侧重于整体的结构。框架模型主要以一些特殊的问题为目标建立只针对和适应该问题的结构。

    (3)动态模型。动态模型是对结构或框架模型的补充,研究系统“大颗粒”的行为性质。例如,描述系统的重新配置或演化。动态可能指系统总体结构的配置、建立或拆除通信通道或计算的过程。

    (4)过程模型。过程模型研究构造系统的步骤和过程。因而结构是遵循某些过程脚本的结果。

    (5)功能模型。该模型认为架构由一组功能构件按层次组成,且下层向上层提供服务。它可以看作是一种特殊的框架模型。

    4+1” 视图模型从 5 个不同的视角包括逻辑视图、进程视图、物理视图、开发视图和场景视图来描述软件架构。每一个视图只关心系统的一个侧面,5 个视图结合在一起才能反映系统的软件架构的全部内。

    (1)逻辑视图:主要支持系统的功能需求,即系统提供给最终用户的服务。在逻辑视图中,系统分解成一系列的功能抽象,这些抽象主要来自问题领域。这种分解不但可以用来进行功能分析,而且可用作标识在整个系统的各个不同部分的通用机制和设计元素。在面向对象技术中,通过抽象、封装和继承,可以用对象模型来代表逻辑视图,用类图来描述逻辑视图。逻辑视图中使用的风格为面向对象的风格,逻辑视图设计中要注意的主要问题是要保持一个单一的、内聚的对象模型贯穿整个系统。

    (3)进程视图:侧重于系统的运行特性,主要关注一些非功能性的需求,例如系统的性能和可用性。进程视图强调并发性、分布性、系统集成性和容错能力,以及逻辑视图中的主要抽象的进程结构。它也定义逻辑视图中的各个类的操作具体是在哪一个线程中被执行的。进程视图可以描述成多层抽象,每个级别分别关注不同的方面。

    (4)物理视图:主要考虑如何把软件映射到硬件上,它通常要考虑到解决系统拓扑结构、系统安装、通信等问题。当软件运行于不同的节点上时,各视图中的构件都直接或间接地对应于系统的不同节点上。因此,从软件到节点的映射要有较高的灵活性,当环境改变时,对系统其他视图的影响最小。

    (5)场景:可以看作是那些重要系统活动的抽象,它使四个视图有机地联系起来,从某种意义上说,场景是最重要的需求抽象。在开发架构时,它可以帮助设计者找到架构的构件和它们之间的作用关系。同时,也可以用场景来分析一个特定的视图,或描述不同视图构件间是如何相互作用的。场景可以用文本表示,也可以用图形表示。

    逻辑视图和开发视图描述系统的静态结构,而进程视图和物理视图描述系统的动态结构。对于不同的软件系统来说,侧重的角度也有所不同。例如,对于管理信息系统来说,比较侧重于从逻辑视图和开发视图来描述系统,而对于实时控制系统来说,则比较注重于从进程视图和物理视图来描述系统。

    更多相关内容
  • 在我的架构思维中,主要可以归类为三种架构模型:3/N层架构、“框架+插件”架构、地域分布式架构。一.三种架构模型1.3/N层架构这是经典的多层架构模型,对于稍微复杂一点或特别复杂的系统,不使用分层架构是很难...
  • xx系统架构模型分享版,写文档的好参考,PM必备。xx系统架构模型分享版,写文档的好参考,PM必备
  • Hadoop架构模型

    千次阅读 2021-11-29 20:19:46
    1.Hadoop的模块组成 1、HDFS:一个高可靠、高吞吐量的分布式文件系统。 2、MapReduce:一个分布式的离线并行计算框架。 3、YARN:作业调度与集群...2.Hadoop的架构模型 Hadoop 1.x架构 Hadoop 2.x架构 ...

    1.Hadoop的模块组成

    1、HDFS:一个高可靠、高吞吐量的分布式文件系统。
    2、MapReduce:一个分布式的离线并行计算框架。
    3、YARN:作业调度与集群资源管理的框架。
    4、Common:支持其他模块的工具模块。

    2.Hadoop的架构模型

    Hadoop 1.x架构

    在这里插入图片描述

    Hadoop 2.x架构

    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述

    展开全文
  • 易语言类架构模型

    2020-07-22 00:45:49
    易语言类架构模型源码,类架构模型,子程序1,方法1
  • 本文将对比分析DDD分层架构、整洁架构、六边形架构。 整洁架构 又名“洋葱架构”(看图就懂),体现了分层思想。 同心圆代表应用软件的不同部分,由内到外依次是 领域模型 领域服务 应用服务 容易变化的内容 比如...

    本文将对比分析DDD分层架构、整洁架构、六边形架构。

    整洁架构

    又名“洋葱架构”(看图就懂),体现了分层思想。

    同心圆代表应用软件的不同部分,由内到外依次是

    • 领域模型
    • 领域服务
    • 应用服务
    • 容易变化的内容
      比如用户接口和基础设施。

    该架构最主要原则:依赖原则,它定义了各层依赖关系,越往内依赖越低,代码级别越高,能力越核心。外圈代码依赖只能指向内圈,内圈无需知道外圈任何情况。

    职能划分

    • 领域模型
      实现领域内核心业务逻辑,封装了企业级业务规则。领域模型的主体是实体(可以是一个带方法的对象,也可以是一个数据结构和方法集合)。
    • 领域服务
      实现涉及多个实体的复杂业务逻辑。
    • 应用服务
      实现与用户操作相关的服务组合与编排,包含了应用特有的业务流程规则,封装和实现了系统所有用例。
    • 最外层
      主要提供适配的能力,分为主动适配和被动适配。
      • 主动适配主要实现外部用户、网页、批处理和自动化测试等对内层业务逻辑访问适配
      • 被动适配主要是实现核心业务逻辑对基础资源访问的适配,如DB、缓存、文件系统和MQ等。

    红圈内的领域模型、领域服务和应用服务一起组成软件核心业务能力。

    六边形架构

    又名“端口适配器架构”。

    • 核心理念
      应用通过端口与外部交互

    红圈内的核心业务逻辑(应用程序和领域模型)与外部资源(包括APP、Web应用以及数据库资源等)完全隔离,仅通过适配器交互。它解决了业务逻辑与用户界面的代码交错问题,很好实现前后端分离。六边形架构各层的依赖关系与整洁架构一样,都是由外向内依赖。

    职能划分

    系统分为内六边形和外六边形:

    • 红圈内六边形
      实现应用的核心业务逻辑
    • 外六边形
      完成外部应用、驱动和基础资源等的交互和访问,对前端应用以API主动适配方式提供服务,对基础资源以依赖反转被动适配的方式实现资源访问

    该架构的一个端口可能对应多个外部系统,不同外部系统也可能使用不同适配器,由适配器负责协议转换。这就使得应用程序能够以一致的方式被用户形式使用。
    现在,很多声称使用分层架构的团队实际上使用的是六边形架构。这是因为 很多项目都使用了某种形式的依赖注入。并不是说依赖注入天生就是六边形架 构,而是说使用依赖注入的架构自然地具有了端口与适配器风格。

    架构模型对比分析

    虽然DDD分层架构、整洁架构、六边形架构的架构模型表现形式不同,但设计思想正是微服务架构高内聚低耦合原则的完美体现,而它们身上闪耀的正是以领域模型为中心的设计思想。

    红色实线边框用于将核心业务逻辑与外部应用、基础资源进行隔离。

    红框内部主要实现核心业务逻辑,但核心业务逻辑也有差异,有属于领域模型,有属于面向用户的用例和流程编排能力。按这种功能差异,在这三种架构划分了应用层和领域层,承担不同业务逻辑。

    领域层实现面向领域模型,实现领域模型的核心业务逻辑,属原子模型,需保持领域模型和业务逻辑稳定,对外提供稳定的细粒度领域服务,所以是架构核心。

    应用层实现面向用户操作相关的用例和流程,对外提供粗粒度API服务。适配前台应用和领域层,接收前台需求,随时做出响应和调整,尽量避免将前台需求传到领域层。应用层作为配速齿轮位于前台应用和领域层间。

    这三种架构都考虑了前端需求的变与领域模型的不变。需求变幻无穷,但变化总是有矩可循的,用户体验、操作习惯、市场环境以及管理流程的变化,往往会导致界面逻辑和流程的多变。但核心领域逻辑基本不大变,领域模型相对稳定,用例和流程则会随外部需求而随时调整。

    架构模型通过分层控制需求变化从外到里对系统影响,从外向里受需求影响逐步减小。面向用户的前端可以快速响应外部需求进行调整和发布,应用层通过服务组合和编排来实现业务流程的快速适配上线,减少传到领域层的需求,使领域层保持长期稳定。

    这样设计的好处,可保证领域层核心业务逻辑不会因外部需求和流程的变动而调整。

    从三种架构模型看中台和微服务设计

    中台本质是领域的子域,它可能是核心域,也可能是通用域或支撑域。通常大家认为阿里的中台对应DDD的通用域,将通用的公共能力沉淀为中台,对外提供通用共享服务。

    中台作为子域还可以继续分解为子子域,在子域分解到合适大小,通过事件风暴划分限界上下文以后,就可定义微服务,微服务用来实现中台能力。

    中台建设要聚焦领域模型

    中台需考虑能力的共享和复用。
    要建立中台内所有限界上下文的领域模型,DDD建模过程中会考虑架构演进和功能的重新组合。领域模型建立的过程会对业务和应用进行清晰的逻辑和物理边界(微服务)划分。领域模型的结果会影响到后续的系统模型、架构模型和代码模型,最终影响到微服务的拆分和项目落地。

    微服务要有合理的架构分层

    微服务设计要有分层思想。
    保证领域层的纯洁和领域逻辑的稳定,避免污染领域模型。不要把领域模型的业务逻辑放在应用层,这样会导致应用层过大,领域模型会失焦。实在无法避免,可以引入防腐层,进行新老系统的适配和转换,过渡期完成后,可直接将防腐层代码抛弃。

    微服务间层次依赖

    。而有的则是某个职责单一的中台微服务,企业级的业务流程需要将多个这样的微服务组合起来才能完成,这是企业级中台微服务。两类微服务由于复杂度不一样,集成方式也会有差异。

    项目级微服务

    可与前端应用集成,一起完成特定业务。
    项目级微服务的内部遵循分层架构模型即可。领域模型的核心逻辑在领域层实现,服务的组合和编排在应用层实现,通过API网关为前台应用提供服务,实现前后端分离。但项目级微服务可能会调用其它微服务,你看在下面这张图中,比如某个项目级微服务B调用认证微服务A,完成登录和权限认证。

    通常项目级微服务之间的集成,发生在微服务的应用层,由应用服务调用其它微服务发布在API网关上的应用服务。你看下图中微服务B中红色框内的应用服务B,它除了可以组合和编排自己的领域服务外,还可以组合和编排外部微服务的应用服务。它只要将编排后的服务发布到API网关供前端调用,这样前端就可以直接访问自己的微服务了。

    企业级中台微服务

    可在中台微服务上增加一层,位于红色边框,负责跨中台微服务的服务组合和编排,以及微服务之间的协调,还可完成前端不同渠道应用的适配。
    再将它的业务范围扩大一些,可做成一个面向不同行业和渠道的服务平台。

    借用BFF(服务于前端的后端,Backend for Frontends)词。BFF微服务与其它微服务存在较大的差异,就是它没有领域模型,因此这个微服务内也不会有领域层。BFF微服务可以承担应用层和用户接口层的主要职能,完成各个中台微服务的服务组合和编排,可适配不同前端和渠道的要求。

    应用和资源的解耦与适配

    传统以数据为中心的设计模式,应用会对数据库、缓存、文件系统等基础资源产生严重依赖。
    一旦更换基础资源就会对应用产生很大的影响,因此需要为应用和资源解耦。
    在微服务架构中,应用层、领域层和基础层解耦是通过仓储模式,采用依赖倒置的设计方法来实现的。在应用设计中,我们会同步考虑和基础资源的代码适配,那么一旦基础设施资源出现变更(比如换数据库),就可以屏蔽资源变更对业务代码的影响,切断业务逻辑对基础资源的依赖,最终降低资源变更对应用的影响。

    总结

    DDD分层架构、整洁架构、六边形架构都是以领域模型为核心,实行分层架构,内部核心业务逻辑与外部应用、资源隔离并解耦。

    展开全文
  • 易语言源码易语言类架构模型源码.rar 易语言源码易语言类架构模型源码.rar 易语言源码易语言类架构模型源码.rar 易语言源码易语言类架构模型源码.rar 易语言源码易语言类架构模型源码.rar 易语言源码易语言类...
  • 区块链的本质和架构模型

    千次阅读 2018-04-08 17:36:30
    区块链的本质和架构模型区块链的定义和本质笔者经过对各种区块链异同点的分析和归纳思考,先给出了一个区块链定义。区块链是在符合现实社会法律法规前提下,可治理的,依赖于密码学算法和博弈经济性设计,基于共识...

    区块链的本质和架构模型
    区块链的定义和本质

    笔者经过对各种区块链异同点的分析和归纳思考,先给出了一个区块链定义。

    区块链是在符合现实社会法律法规前提下,可治理的,依赖于密码学算法和博弈经济性设计,基于共识算法,对发生在主体间的价值创造,价值转移,价值交换,以及涉及到各个价值主体由机器驱动的业务流程,在多个对等的主体间形成的共识,从而达到共享业务状态,共享价值状态,即共享账本,以达到加速社会资源配置和价值流通,最终提高生产力的目的。

    区块链的本质是共识,在互不信任的主体间的共识就形成了公认的价值。区块链的目标是解放和提高整个社会的生产力,手段是将生产关系虚拟化,运用IoT和价值锚定技术将现实世界和虚拟世界无缝连接起来,虚拟化的业务合约可以由机器自动化驱动现实和虚拟社会的资源配置,价值生产和流通,结合大数据智能分析优化虚拟的生产关系,现实和虚拟的法律法规和治理机制为虚拟的区块链社会的稳定发展提供保障。

    区块链的架构模型

    作者从区块链的本质出发,以发展的眼光看待区块链的架构和架构未来的发展,关注于主要业务和技术能力,给出一个全面而高度概括的区块链架构模型。这是一个面向链合约服务的高阶架构模型,体现了未来基于区块链实现高度自动化、智能化、公平守约的虚拟社会生产关系的能力。

    面向链合约服务的高阶层次化架构包括了三大部分:业务合约和账本,区块链平台服务,UI界面和API接口。以下对各个部分进行详细说明。

     这里写图片描述 
    图1 区块链架构模型

    业务合约和账本

    在现实世界,我们每个人都处在各种关系契约中,所有人在契约的约定下参与整个社会的生产和生活。区块链技术最终要能促进生产关系虚拟化,推动生产力的发展,整个区块链生态系统的核心就是要能支持各种契约,即业务合约,并在相关参与者间共享交易账本。

    业务合约大到非常复杂的业务合约流程,这要高于企业各自的流程,是各个企业、组织或个人作为流程主体共同参与制定共同认可的生产关系流程契约。比业务合约流程粒度小的业务合约称为合约服务,合约服务是在语义层面对业务行为进行抽象的最小契约,合约服务由一组合约动作(action)构成。作为抽象的合约服务的具体实现,合约代码可以由不同合约语言编写,合约代码中引用的业务条款和法律条款也都可以有具体的不同实现语言。

    合约流程

    合约流程实现了基于合约服务的一系列固定的,按照既定业务规则和法律条款串联或并联起来的合约动作,通过各个合约动作的完成,实现业务在各个流程参与方的执行,实现由机器流程引擎驱动的价值高速自动创造,自动流转,自动交换。合约流程一旦运行起来就是一个状态机,合约流程在参与方间共享流程状态,也就是共享一致的状态机的状态。

    业务参与各方在阅读具体的业务合约流程业务规则,法律条款后,签定合约流程契约,合约流程生效,流程可以通过时间触发,也可以是链上的事件触发,也可以Oracle事件触发,也可以人工触发。初始化后的流程实例按照后续节点的类型,人工节点或是计算节点,实现通过UI界面或API的外部输入确认的人工执行驱动,或调用合约服务的具体action实现代码的机器计算驱动,形成业务价值交易,流程引擎调用业务条款检查服务和法律条款检查服务,获得业务节点的业务规则状态和法律条款满足状态,按照既定的流程规则,引擎驱动流程判断流向下一(多)个节点。

    业务流程在各个节点流转时,由流程引擎驱动形成一个个的流程流转交易,业务流程合约参与方通过共享流程流转交易实现流程状态共享的目的。流程验证者在本地的沙盒中执行对流程流转交易的验证,实现流程状态机一致的状态流转。

    合约服务

    作为业务合约的主体,定义了业务合约最基本的服务内容,每一个合约服务就是一种最小的完整的概念层面的业务语义定义。合约服务定义了完成业务所需的一个或多个合约动作(action),每个合约动作定义了输入状态和输出状态和要执行的业务逻辑命令。

    合约服务本身和每一个合约动作,以及其中用到的任何合约条款法律条款都需要用人类语言进行清晰明确的描述,必要时提供形式化语义描述以免出现语言理解偏差。每一个合约动作的执行形成一个明确的合约价值交易。合约流程引擎在执行流程节点流转时,按照流程定义的对合约服务动作的调用,自动进行服务动作的执行,从而产生业务价值交易,这是一种内在的合约服务调用。合约服务的调用也可以是外在的,由用户通过UI界面基于外部API接口实现调用。

    合约服务可以是一种组合服务,对现有的合约服务动作进行组合,形成新的服务动作业务语义。合约服务的可组合化有利于基于已有的业务合约定义,通过快速构建新型的业务合约进行生产关系创新,实现不同产业价值服务的零距离整合。为了实现合约服务的自包含化,并支持服务流程的编排,以及服务计算容器化、分布式、可扩展的架构部署要求,合约服务需要定义成无状态的。当签约用户或流程调用合约服务时,合约服务会进行服务路由,基于链服务管理的路由规则,选择特定的合约代码实现来具体验证执行业务价值交易。

    合约代码

    合约服务的每一个合约动作都会产生业务价值交易,业务价值交易会在合约代码实现上进行执行和验证。作为交易验证者,合约服务可以有多种实现,如不同合约语言的实现,不同合约提供商的版本实现,不同利益相关方的合约代码实现,这有利于所有的合约服务参与者去中心化,并在抽象的业务层面就达成共识。

    合约代码实现了合约动作定义的输入状态和输出状态和要执行的一组业务逻辑命令计算,命令是最小的执行单元,可以是调用一个技术服务,如生成zkSNARK证明,也可以是输入和输出状态检查、逻辑计算、法律条款服务检查等。

    经过所有的命令执行,如果输入状态可以确定性地得到输出状态,对于合约服务的发起者就可以形成一个业务价值交易建议,而其他参与者可以对这个业务价值交易建议进行验证。对于合约流程产生的流程流转交易,由流程执行建议者计算出状态迁移交易建议,由流程执行验证者进行本地流程流转验证。

    价值共享账本

    合约流程的流转会产生流程流转交易,合约服务的执行会形成业务价值交易,所有的这些交易日志,被分类按应用按联盟团体组织成区块链或者交易链,形成不可更改和抵赖的数据结构,在各个参与方之间形成一个统一的状态账本。价值共享账本需要以高效、规范的方式进行数据组织,包括交易日志和账本状态,以便于流程状态(状态机)和资产状态数据库的快速更新,也便于对历史交易进行快速查找和回溯。另外,价值共享账本底层还需要有共享的通信机制,如使用各种P2P算法,便于相关方进行基于权限的相关交易数据的快速同步。

    区块链平台服务

    区块链平台服务提供所有区块链平台层面的公共服务,平台服务同具体的业务无关,是可以为所有业务合约所共享的服务。各种平台服务可以是链上的,也可以是链外的,一同构成一个区块链平台不可或缺的能力。主要包括合约合规,安全控制,链上共识,链服务管理,治理(链上、链外),开发运维。

    合约合规

    合约合规服务将那些公共的合规性要求抽取出来,形成各个业务都通用的规则条款检查服务,合约条款验证服务,法律条款验证服务,Oracle服务约定,合约宪法条款约定。

    合约宪法指明了合约纠纷适用的法律,争议解决办法,以及人类可读的合约意图等。一个实际的区块链平台能够同现实社会经济并行运行的一个前提条件就是同现实社会一致的合法合规性。不论是把现实世界中心化的合约去中心化建模成虚拟世界的业务合约,还是基于区块链新型的生产关系新创造的业务合约,合法合规依然是根本。

    法律和规则都可以以最低粒度的条款内容存在,为了支持业务合约的快速搭建和创新,将通用的合约条款,规则条款,法律条款实现为一种服务,基于对条款服务的引用和基于条款服务的组合,可以实现更高粒度的合规合法性验证要求。业务合约可以基于这些合约规则,合约条款,法律条款和组合的合规合法性验证要求自动进行交易的合规性验证。

    对于那些无法由代码实现的验证内容和合约意图,可以通过人类可以理解的方式通过合约宪法指定合约运行所依赖的现实世界法律,指定出现无法在链上解决的争议,在现实世界的解决办法。合约流程和合约服务如果使用现实世界数据输入的,为了达到确定性运行,所有验证人的验证执行都必须依赖相同的Oracle服务或者交易各方都认可的Oracle服务。

    安全控制

    区块链在平台安全层面需要设计隐私模型,权限模型。

    同现实世界人们需要一定的隐私性和匿名性一样,区块链虚拟世界也需要提供相应的隐私保护给用户。对于公有链,出于网络的安全考虑,往往需要交易无关方对交易内容执行验证,必须让用户身份信息同用户的交易信息隔离,使用户身份得到保护,甚至采用零知识证明zkSNARK算法仅向验证者提供一个无需暴露交易内容的证明,验证者就可完成验证,做到绝对的交易身份隐匿。

    许可链由于网络的参与方都是受控的,所以防范网络攻击的安全需求没有公有链那么高,共识机制只需确保技术层面的一致和完备,交易业务层面的验证可以只在交易相关方进行验证,这样可以保证交易无关方看不到任何交易内容,即使是加密的交易内容也看不到。

    公有链是一种开放权限的设计思路,不会显式的设定不同参与人的操作权限,只会采用黑名单机制。而许可链是一种白名单机制,有非常严格的准入机制,只有允许的参与方才可以参与被允许的业务合约。许可链通常采用PKI基础设施通过自身的CA机构,同企业现有的权限管理系统进行集成,如LDAP、AD服务器,进而控制不同的人具有不同的合约操作权限。

    区块链由于采用公私钥机制进行交易,不论采用哪种数据模型,都存在最小粒度的基于私钥的账户概念。区块链存在两种类型的合约账户:合约流程账户(Contract Process Account, CPA)和合约服务账户(Contract Service Account, CSA)。外部用户也会有自己的私钥账户(User Account, UA),外部用户账户会参与到合约流程账户和合约服务账户相关的活动中,而合约流程账户会依赖合约服务账户执行相关的合约动作调用。

    不同的合约流程和合约服务实例化后的相互关系会非常复杂,我们可以把这三种账户按照使用关系和依赖关系组织成树状结构,采用merkle证明的方式进行权限证明验证。

    链上共识

    共识机制是区块链建立信任的基石。不同类型的区块链出于不同的考虑会选择不同的共识算法或者采用共识算法的组合。共识的内容包括账本的规范化(如何组织区块,组织交易链),交易的确定性执行结果,交易的非双花唯一性,交易的顺序完备性,以及其他保证网络安全稳定运行的其他信息(如数据可用性)。

    另一方面,共识机制的运行又不应同账本的规范化和交易的验证紧密绑定在一起,这也遵从关注点分离的架构原则,有利于区块链平台整体的模块化,插件化,容器化,有利于平台的横向扩展性。

    链服务管理

    区块链平台服务一个很重要的能力体现就是对于链上服务的高效可靠的管理,所有区块链的业务合约的正常稳定运行都依赖于这些注册的链服务。这种重要性使得链服务的管理需要遵从区块链治理体制和治理流程规则。链服务包括以下几种类型:

    • 合约流程管理:包括对合约流程的建立,版本升级,退出的管理。一旦某个用户账户绑定在合约流程实例账户上运行,一直要运行到整个合约流程实例完全结束,可以提供退出子流程供中途退出,或者通过治理流程,让所有参与者选举主动结束合约流程实例。
    • 合约服务管理:包括对合约服务的注册,版本升级,退出的管理。每一个合约服务是一个有完整业务意义的抽象的合约规约,其中每一个合约动作都代表了不同利益方共同遵守的价值约定,一旦签约加入合约服务,就从法律意义上确认了这样的价值约定。
    • 链技术服务管理:包括对链技术服务的注册,版本升级,删除操作。合约服务和合约流程运行时所依赖的公共技术服务,如生成链平台的zkSNARK证明,验证签名,如果暴露成链服务的形式,就可以完成基于无状态服务的计算可扩展性,特别适用于计算密集型的技术服务高负载运行时,可最大并行度地支持合约服务的验证执行,也有利于采用特定的硬件加速技术服务。
    • Oracle服务管理:包括Oracle服务的注册,版本升级,删除操作。Oracle服务是虚拟世界同现实世界的桥梁,很多业务合约的运行都离不开来自于现实世界的信息,必须提供统一的Oracle服务,供所有的验证人进行运行时验证,才能保证交易验证的确定性。Oracle服务横跨两个世界,所以必须在两个世界都要设立对其的监督制约机制。虚拟世界的监督机制设计,如存入大额抵押金成为Oracle服务提供方,成立赏金猎人监督机制,一旦被发现非法行为,如提供同实际情况不符的Oracle证明,即被没收所有抵押金,吊销Oracle服务资质,记录征信档案,在现实世界也需要做出相应的惩罚。

    链上治理和链外治理

    任何不同利益主体参与的活动,从长期稳定发展的角度来看,都需要配套的治理策略和机制保障。区块链作为多利益主体参与的动态变化的系统,架构处于不断演进过程中,运行的业务合约也不断发展变化,还面临利益驱使的恶意行为,及有组织的黑客攻击行为,运行的业务合约和交易都存在监管和审计的需求。

    为了让区块链可以平稳安全的运行,特别是对于公有链,需要从公平正义的基本法理出发,预先设计出完整的博弈经济模型和社会化治理机制。博弈经济模型可以保证区块链的参与者都以不同的角色,积极高效自觉地参与和维护区块链的生产、管理和治理,对符合区块链整体利益的行为进行激励,对正义行为进行奖励,对恶意行为进行惩罚,使用经济手段阻断黑客攻击,让攻击行为得不偿失,另外,模仿现实世界对经济活动征收税收,税收用于整个区块链平台的治理。

    为了能高效公平地推进链的治理,可以预先设计出扩展性良好的底层治理机制,如设计底层的链上投票合约,基于这个底层机制可以进行相关平台重大事项的社会化投票公决,如区块链主宪法的更改,链参数的更新,链系统合约的升级,业务合约(合约流程,合约服务,合约代码)以及合约法律的升级。

    对于那些无法通过链上解决的治理问题,或者需要现实世界配合解决的问题,以及那些还无法预见的问题,需要设定链外治理的策略和机制,如对于确认的业务合约中的恶意行为或黑客行为,除了经济手段惩罚,还可以诉诸现实世界法律手段。

    一个稳定运行的区块链系统就形成一个经济和金融体系,离不开对在其中运行的经济交易的持续审计和监管,以杜绝违法合约和交易行为,如反洗钱交易。每一个业务合约的接入方需要负责对客户进行尽职调查,做到KYC监管要求。对于区块链的有效治理,还离不开基于区块链交易数据的大数据智能分析,由于区块链是一个经济系统,可能还需要基于分析结果施加以适应经济规律的宏观政策。

    开发运维

    一个成功的区块链平台就是一个多利益主体参与的生态系统,每一个参与主体(政府、企业、组织、个人)都有可能参与到平台的开发和运维工作中来。

    设计和开发人员可以参与到基础平台层服务的设计开发,也可以实现业务合约的规格制定和开发,这其中会涉及到架构人员,业务人员,法律人员,技术人员,监管人员等各种专业人员。

    对于一个业务合约的设计和开发,首先需要由业务人员,法律人员和架构师完成完整的业务合约规约的制定,不同价值主体可以共同完成或由一方完成后讨论,形成合约共识,制定出完整的合约流程,合约服务规格说明书;再由不同的参与主体自行开发实现或委托实现,可以不断迭代提炼出通用的服务,如法律条款检查服务,通用技术服务,各方在自行开发实现时充分利用平台已有的成熟的通用服务以提高实现效率和服务稳定性,参与各方可以采用不同的语言实现合约服务逻辑,以保证合约服务语义层面的一致性和合约的分布性。可以设计和开发的要件有:合约流程,合约服务,合约代码,技术服务,规则服务,合规服务。

    每一个参与主体特别是验证节点都可以参与到区块链的平台运维中来,运维行为包括对运行节点服务的容器化集群,提供动态扩展能力,安装多语言多VM实现节点,支持多节点并行运行,并行验证。生产运维需要有完善的流程,面对区块链日新月异的变化,可以充分利用DevOps进行持续开发,持续集成的新开发运维体制和自动化测试部署流程。

    对于生产系统需要能够进行监控,进行事件记录,对重要事件发出告警,对于告警错误码需要预先制定处理流程,针对区块链系统和业务,还需要预先制定出正常情况和异常情况下的运维流程。

    UI界面和API接口

    整个区块链服务对外的交互接口,包括提供给人的UI界面和提供给其他信息系统或人工智能代理的API接口。交互的主要内容包括:

    个性化任务列表

    价值主体加入某个合约流程后,如果合约流程的某个业务流程节点需要主体的输入和确认,这就转化成对这个主体的界面交互请求,用户需要在一个业务界面中输入必须的内容,或者确认系统提供的业务信息,并使用主体的业务操作私钥进行签名,以表明主体的操作权限,让业务合约得以继续进行下去。主体可以同时加入多个合约流程,这就会存在一个任务列表,需要主体逐个进行界面操作完成。

    个性化分布式APP

    每一个业务合约都可能是一个App,多个业务合约一起也可以是一个App,用户,用户的IoT智能终端,或者用户的人工智能代理,加入的每一个业务合约(合约流程或合约服务)都是一个业务应用,所以需要为用户提供定制化的分布式App,满足用户的个性化需求。比如设计一个大一统的App基础平台,在其上提供各种插件式的个性化小应用,为用户加入的各个业务合约提供界面,用户自己管理自己身份,不再控制在集中的机构手中,所有小应用的交易和授权都是基于用户各个应用的私钥进行,只由用户本人控制。

    IoT协议适配和价值锚定

    区块链一个大的应用方向就是同物联网的结合,物联网的各种终端要实现智能化自动制造,智能化自主服务,就需要将他们绑定到虚拟世界里,传统的IoT中心化控制架构是无法直接反应社会化生产和服务要求的。

    区块链作为一个虚拟的经济社会,维持了虚拟的经济生产关系,让IoT智能终端参与区块链群体中,参与到具体的区块链合约流程和合约服务中,由社会化的区块链机器自动驱动IoT终端进行自动化的生产和服务,并引入人工智能代理加速人工处理,可以极大提高生产力。区块链需要同IoT的协议进行适配,以确保双向交易的无障碍流通。

    另外,为了在虚拟世界建模现实世界的价值生产,转移和交换,将现实世界真正融入到虚拟世界的生产关系合约中,需要为现实世界生产的产品和服务价值,在虚拟社会分配一个价值锚定标签,就如同虚拟世界拥有了私钥就可以锁定价值一样,在现实世界,也需要有一套可行的方案将虚拟世界的价值锚定标签植入到现实世界的产品和服务中去,不同的产品和服务可能需要不同的锚定机制。通过价值锚定标签,现实世界价值的生产、转移和交换就可以无缝融合进虚拟世界的生产关系合约流程和服务中去。

    人工智能代理

    作为价值主体,可以使用人工智能代理帮助其完成合约流程的自动流转和合约服务动作的自动发起。一个虚拟世界高速运转的生产关系需要这样的角色,随着人工智能的发展,人工智能代理也能够胜任基本的基于规则和用户习惯的操作。另外,结合大数据智能分析,在设定一定的业务目标后,可以由人工智能代理主动发起一些优化的交易,降低人工操作,提高整个合约服务的运行效率,可以预见性地优化资源配置,减少整个社会化生产的资源浪费。

    开放API

    整个区块链平台对于可以开放的或者可以权限开放的接口,都提供标准的API,允许外部系统或人工智能代理进行访问和操作。区块链的各种业务合约(合约流程,合约服务)信息,区块链的各种交易结果,当前流程状态,资产状态,或者区块链的交易发生证明,资产存在证明,链上治理接口,也都可以API的方式向外部系统提供。通过API接口,也可以进行各种业务合约的操作,如人工处理的提交,合约动作交易的提交等。

    业务合约浏览器

    通过业务合约浏览器,用户可以看到权限范围内的所有可参与的业务合约,包括合约具体的规格化内容,如合约流程、合约服务各动作、合约具体规则、合约法律条款、合约宪法、治理规则等。

    区块链浏览器

    区块链浏览器可以浏览所有的区块,以及权限许可的交易内容,可以对可浏览的交易进行回溯查看,可以从不同的维度进行交易、流程和价值资产的审查。

    资产浏览器

    资产浏览器运行用户以统一的视角看待用户关联的所有合约资产。资产浏览器可以同个性化分布式App整合在一起,让用户可以看到当前各个参与合约流程的当前状态,各个合约服务的状态资产,以统一的视图帮助用户进行交易的优化决策。

    区块链跨链本质和跨链模型
    区块链跨链的本质

    把整个现实社会都搬到一个区块链上是不现实的,现实社会本身也是分产业分经济领域进行价值创造的,通过市场实现不同产业和不同经济领域的价值交换。每一个独立区块链维护了自己独立的价值经济体系,跨链区块链是连接独立区块链的中枢,承载了不同价值体系区块链价值交换的功能,商品要能实现交互,需要有价格,价格来源于商品自身的价值,取决于供求关系,而供求关系是靠市场搭建的,所以,为了实现不同区块链“商品”的价值交换,在跨链区块链上会出现各种价值交易市场,跨链区块链上每一个价值交易市场就是一个跨链合约服务。

    价值不会凭空产生也不会凭空消失,跨链设计也必须遵从人类自古以来的经济规律。跨链的本质是价值等价交换,任何违背这个基本原则的设计最终都会失败。

    区块链跨链架构模型

    图2中独立区块链的架构模型已经在上文中说明了,所有独立区块链如果需要支持跨链价值转移或交换,就需要存在外链合约服务,外链合约服务同普通的合约服务没有本质的区别,也是一种合约服务规约,不同之处在于合约的制定者会提供一组公开声明的跨链交易公钥地址,需要进行跨链交易的主体可以把自己拥有的一定数量的价值体转移到跨链合约服务指定的公钥地址上,并指定跨链交易内容,如希望交换另一个区块链上一定数量的价值体,并把交换后的价值体转到自己在另一个区块链上的公钥地址上。 
     

     这里写图片描述 
    图2 区块链跨链架构模型

    这里假定存在两个独立区块链A和B,存在一个主体X和主体Y,他们都拥有两个链上的私钥地址,主体X是区块链A上的价值生产者,如农民生产粮食,主体Y是区块链B上的价值生产者,如工厂生产工业品,主体X希望购买区块链B上的产品或服务,如工业品,主体Y希望购买区块链A上的产品或服务,如粮食。

    跨链区块链主要有两种类型的链组成,一种是主链,跨链主链只有一个,一种是适配子链,适配子链至少存在2个,由跨链主链连接各个适配子链,各个子链之间没有信任关系,而是通过主链进行信任的传递。适配子链和主链按照设定的协议进行交互,以达到信任传递和交易传递的目的。

    跨链区块链本身也需要有同独立区块链一样的区块链平台服务,如合约合规、安全控制、链上共识、链服务管理、链上链外治理、开发运维,这些在上图都做了省略。对于链上共识,主链和子链需要采用比PoW更加高效的算法实现跨链交易交互,如采用BFT共识算法,目前两个跨链平台(Cosmos和Polkadot)设计都是采用PoS+BFT的混合共识算法。

    跨链区块链本身也是个区块链,所以独立区块链所具有的业务合约能力也应具有,但基于跨链区块链构建的业务合约会支持更复杂的业务,实现同不同价值区块链的连接,进行价值交换。每一个跨链业务合约都会形成一个交易市场,不同区块链的不同价值体系在这个交易市场上获得各自的定价,并进行交易,极有可能会形成基于主链代币或者主权加密通货的各种区块链价值体的统一报价和交易市场。

    更高级地通过跨链合约流程,可以实现所有区块链虚拟社会生产关系的组合,假设每个独立区块链是一个独立的经济领域,跨链合约流程就可以串接起独立的经济领域成为一个完整的产业链条。跨链区块链本身也是可以互联的,通过跨链区块链的连接,就串接起了工业、农业、服务业等各行各业,从而构成了整个社会的生产关系。

    生产生活都关联到区块链虚拟社会上,基于区块链提供的合约服务以及基于区块链提供的机器驱动业务流程,结合IoT和人工智能,价值生产、转移和流通会更加快速便捷,人类的生产关系也会更加优化协调,生产力由此可以得到进一步解放。区块链和跨链将整个人类对等地关联在一起,去除了任何的信息不对称性和现实社会的各种屏障,体现了公平公正,个人主体是虚拟社会关系的参与者也是维护者也是受益者。

    跨链价值等价交换过程

    结合上节的跨链架构,我们对跨链价值交换过程进行说明。这里仅以物物交换市场为例,主体X是区块链A上的价值生产者,主体Y是区块链B上的价值生产者,主体X如果要获得区块链B上的价值体,就需要拿区块链A上的价值体通过跨链价值交换合约服务同主体Y实现等价的物物交换。

    首先主体X需要加入A链上的外链合约服务,接受合约服务规定的合约规则和法律条款,主体X还需要加入某个跨链合约服务,如可以实现A↔B交易匹配的一个跨链合约服务,接收跨链交易市场的合约规则和法律条款。然后主体X需按照A链上的外链合约服务的合约规则,把自己拥有的一定数量的A链的价值体转移到外链合约服务指定的公钥地址上,并指定跨链交易内容,如希望交换另一个区块链B上设定数量的价值体,并把交换后的价值体转到自己在另一个区块链上的公钥地址。后续的交易过程如下:

    入①基于LCV的外链交易感知

    适配子链的轻客户端验证(LCV)会不断同步区块链A的区块头,其对于区块链A上的外链合约服务公开的公钥地址敏感,一旦发现存在公钥地址的交易,就认为存在跨链交易请求。

    入②生成和打包跨链交易

    由链适配代码将区块链A上主体X指定的跨链交易请求内容(用链A上一定数量的价值体兑换链B上一定数量的价值体到指定公钥地址上)生成一个子链交易,并且打包进子链区块。

    入③提供子链存在跨链交易证明,发起主链跨链服务调用

    链适配代码基于Merkle树给出一个跨链交易请求在子链上的存在性证明,并按照跨链协议,封装出发往主链的跨链服务调用。

    入④执行主链跨链交易代码

    主链的跨链服务总线,验证交易在子链上的存在性证明,分析主体X的跨链交易请求内容,将跨链服务调用路由给具体的跨链价值交换合约。同样过程,主体Y的跨链交易请求(用链B上一定数量的价值体兑换链A上一定数量的价值体到指定公钥地址上)也被发往相同的跨链价值交换合约。

    入⑤产生交易日志,更新账本状态

    跨链价值交换合约的代码实现,会进行所有的A↔B交易匹配,形成一个A链价值体同B链价值体的买卖市场深度,一旦可以匹配上主体X和主体Y的交易请求,就形成一个匹配交易,用以封装A链和B链价值体在主体X和Y之间达成交换的结果。跨链价值交换合约本质上就是一个场内交易所。

    出①子链路由,提供主链存在跨链交易证明,向适配子链发起外链合约服务调用跨链价值交换合约实现代码,会提供一个交易主体X和Y的跨链匹配交易在主链上的存在性证明,分别向链A和链B的适配器子链发送转账指令交易,一个指示往A链Y主体指定的公钥地址转移一定数量的价值体,一个指示往B链的X主体指定的公钥地址转移一定数量的价值体。

    出②生成和打包跨链交易

    这两个适配子链分别将各自的转账指令交易记录日志,并打包进各自的子链区块。

    出③发起外链合约服务调用

    链适配代码向各自对应的独立区块链上的外链合约服务发起转账指令交易。A链的适配子链会向A链的外链合约服务发送一个转账交易,指示从合约的公开地址上往Y主体指定的公钥地址转移一定数量的价值体。B链的适配子链也会向B链的外链合约服务发送一个转账交易,指示从合约的公开地址上往X主体指定的公钥地址转移一定数量的价值体。

    出④执行外链合约代码

    A链的外链合约服务会执行合约代码,生成交易,把由合约控制的,转账指令要求的一定数量的价值体转移给Y主体指定的公钥地址。B链的外链合约服务会执行合约代码,生成交易,把由合约控制的转账指令要求的一定数量的价值体转移给X主体指定的公钥地址。

    出⑤生成交易日志,更新账本状态

    一旦交易被打包进区块,按照链的交易确认特性,最终主体X获得了B链的价值体控制权,主体Y获得了A链的价值体控制权。

    跨链区块链也会提供用户UI界面和API接口,用户所有在跨链区块链合约服务上执行的交易都可以通过跨链用户界面和API接口获得当前的执行状态,即查看用户在交易所挂单状态和交易市场的买卖深度,甚至可以让用户基于私钥按照市场供求关系重新挂单。

    跨链区块链可以提供基于独立区块链上的外链合约服务的抵押机制,在对应的适配子链上,以换取相同数量的抵押区块链的价值体幻象或筹码,业务主体拿抵押的子链上的价值体幻象参与主链的业务合约流程,这种跨链的生产关系,基于各个主体抵押的各自区块链上的价值体(也可以是现实世界价值锚定),配置生产资料,开展合约生产,最后分配生产产品价值。跨链区块链如果有自己内生的代币,也可以基于交易市场(合约)完成到内生代币的价值兑换,主体拿着跨链代币加入跨链合约流程或跨链合约服务的虚拟生产关系进行生产和价值交换。

    区块链的划分和发展趋势

    为什么在区块链技术上,首先出现的是比特币这种加密货币,而不是以太坊,也不是跨链Cosmos?因为加密货币从业务上更纯粹(数字 vs 合约 vs 市场),从技术上更严密和容易实现(脚本栈 vs 以太坊虚拟机 vs 通用沙箱)。

    以比特币为代表的加密货币称为可编程货币,以太坊可以建模各种代币和基于代币的合约动作,称为可编程金融,实用化的区块链系统会吸取现有区块链的实践教训,从实际可用的目的出发重新设计区块链架构,真正可用于实际社会的区块链建模的不仅仅是虚拟的价值,还担负着社会生产关系虚拟化的重任,在实现现实世界的价值在虚拟世界的锚定基础上,实现现实世界不同契约,不同业务流程在虚拟世界的共识建模,甚至会创造出统一现实世界和虚拟世界的新型生产关系合约服务或合约流程,这可以称之为可编程社会。

    可以看出,区块链的划分不是为了严格区分各种区块链的优劣高下,而是通过划分,区分出不同区块链类型在建模对象和业务处理能力上的不同,以及所要关注解决问题的不同。更重要的是,就如同现实社会,货币是金融的基础,货币和金融是这个社会运行的核心一样,可编程货币是可编程金融和可编程社会的核心和价值交换基础,可编程金融又会是可编程社会围绕的中心。 
     
    

    这里写图片描述 
    图3 区块链划分和功能性要求

    上图主要是想从技术复杂度和业务自由度,两个维度大概说明可编程货币、金融、社会三个代际划分的包含关系。图上列出的几个区块链平台或者未来可能出现的链平台所摆放位置只是示意,不尽准确仅供参考。上图还列出了区块链各代际划分的主要功能需求,这包括可编程货币的货币金额建模能力,可编程社会的状态资产建模,合约建模,合约条款建模,可编程社会的交易内流程建模,治理流程建模,法律法规建模,跨交易链内流程建模,跨交易跨链流程建模。状态、业务、流程、法规、治理是几个区块链功能性能力的考察维度,可能某些能力也是其他代际平台一定程度具有的能力,只是在建模能力的强弱上有所不同。

    基于现有区块链存在的问题,结合区块链社会应有的能力,笔者认为未来的区块链会有如下几个发展趋势:

    建模业务合约流程

    目前的区块链在建模对象上只是状态,而不能建模业务流程状态机,相信由机器驱动的自动化流程,结合IoT和价值锚定,将虚拟社会和现实社会融为一体的生产关系,才能顺应解放生产力的根本要求,所以能够建模业务合约流程的区块链平台将会是演进趋势。

    跨链交易市场形成

    独立区块链完成相关性较高的业务领域的价值生产,要实现社会化商品和价值大流通,就需要跨链交易市场,通过跨链提供的跨链价值交换市场满足价值在不同主体自由等价流通。

    架构的高可扩展性设计

    区块链社会对系统计算能力的要求是巨大的,区块链平台需要有很好的横向可扩展能力,以满足不断扩大的业务合约交易要求。一个没有扩展性的区块链平台是没有实用价值的。随着区块链实验技术的不断经验积累和实用化推进,可扩展的区块链架构平台必然是设计趋势。

    同现实世界的价值锚定

    要实现将现实生产统一到虚拟化的生产关系中,以实现机器按照合约驱动生产的自动化目的,就必须有一套切实可行的方案将虚拟世界的价值锚定标签,植入到现实世界的产品和服务中去。将现实世界的价值同虚拟世界的价值统一起来的价值锚定机制是急需解决的难题。

    同现实世界的法律接驳

    区块链最终会将虚拟社会和现实社会融为一体,形成统一的虚拟生产关系,一个实际的区块链平台能够同现实社会经济并行运行的前提条件就是要有同现实社会一致的合法合规性。符合现实世界法律精神和条款要求是虚拟法律条款合法合规的根本。

    仿现实世界治理机制和体系

    能够建模社会生产关系的区块链就是一个小型的经济社会,不同主体参与,就需要同现实世界类似,设立治理机制和体系,以维护区块链的健康稳定持续发展,以维护区块链社会的公平正义。

    区块链部署架构模型

    从区块链实现虚拟化自动化社会化协作生产的目标出发,基于关注点分离的架构原则和层次化的架构模式给出的区块链架构模型,从设计时就考虑了平台的可用性。以当前的计算架构,采用多台大型主机的银行服务或者采用分布式架构的互联网服务才能支撑得起整个社会范围的交易并发,这还是若干银行、互联网公司共同提供的集中式交易。

    区块链共识就意味着冗余计算,区块链又是建立在密码学上的计算,本身就需要耗费大量的计算能力,要能够提供满足目前银行和互联网服务性能的区块链虚拟计算,就需要目前所有银行主机和分布式服务计算能力的若干倍才可以,如果要实现连接现实社会的自动化流程驱动的生产,整个社会的计算能力还需要有极大的提高。区块链架构要想实现在整个社会范围内的实用化就必须实现功能模块的松耦合,需要能够支持分布式并行计算,支持密码学专用硬件加速,甚至支持连接高性能计算中心的第三方计算。

    这里写图片描述 
    图4 区块链部署架构模型

    目前区块链架构模型设计成验证服务和平台共识服务分离,业务验证服务的合约流程和合约服务以及实现代码分层服务化解耦,业务合约服务同公用的合规合法检查服务,技术服务以服务化的方式解耦,区块链交易日志、状态的规范化逻辑同平台共识服务逻辑分离解耦,所有这些功能逻辑的服务化,无状态化,目的就是为了确保服务的横向分布式部署扩展能力,实现服务容器化按需动态扩展,充分利用当今云计算的发展成果。

    另外,按照参与业务主体紧密程度,业务相关性,业务性能要求,隐私要求的不同,形成多个子链,从链的高度实现分离以提高整个区块链的并行处理能力,也是区块链并行处理交易的方式。

    真正实用的区块链共识节点上要运行大量的应用,需要满足巨量吞吐量要求,并且响应时间也需在实用可接受的范围,共识节点所需要的计算能力不是个人能够承受的,所以未来一个实用的区块链平台一定是运行在多个数据中心上的,个人通过各种分布式App应用参与到链上合约业务。

    数据中心会提供大量容器资源,以动态可扩展的方式为区块链各个功能模块提供服务运行所需的计算资源和存储资源,从前端的分布式APP,到后端的微服务,再到区块链共识服务,账本服务,各种业务合约(合约流程,合约服务)实现的沙盒验证节点,以及各种公共的链上服务节点,如技术服务,合约合法检查服务,规则服务,Oracle服务,分布式存储服务,合约服务路由服务等。

    一个数据中心可能是由一个中心化组织(如公司)运营,也可以是由一个分布式自治组织(DAO或DAC)依据自治合约运行。每一个数据中心对于同一个语义层面规格化的合约服务可能会有自己的代码实现,可能会采用不同的合约编程语言,可能运行在不同的沙盒中验证和执行。每个数据中心都会并行运行多个账本副本和共识节点副本,以保证验证结果的一致性,提高系统可用性,提高出块速度,避免遭受经济惩罚。

    篇后语

    笔者希望通过整体的区块链架构描述,读者能够读懂区块链,认识到区块链的本质是共识,以及基于共识形成的公认价值,认识到区块链跨链的本质是价值的等价交换和交易市场;能够读会区块链,知道区块链的高阶架构模型,区块链不同类型划分和功能性要求,以及发展趋势和实用的部署架构模型,读者可以以高阶架构为蓝本,实际设计和开发实用区块链;相信凭借中国互联网发展在技术和受众上的积累,我们可以更早感受到区块链带给整个社会生产关系和生产力变革的力量。

    展开全文
  • 【RabbitMQ】RabbitMQ架构模型

    千次阅读 2019-08-02 21:01:28
    RabbitMQ架构模型 Producer:生产者 Consumer:消费方 Broker:服务节点 Queue队列: Exchange:交换器 --fanout广播 --topic主题 --direct直连 --headers头交换机 RoutingKey:路由键 BindingKey:绑定 ...
  • 1.x的版本架构模型介绍 文件系统核心模块: NameNode:集群当中的主节点,主要用于管理集群当中的各种数据 secondaryNameNode:主要能用于hadoop当中元数据(后文解释)信息的辅助管理 DataNode:集群当中的从...
  • 区块链基础架构模型

    万次阅读 2018-03-16 00:12:34
    一、简单3层架构 Ref:http://www.8btc.com/ebook-blockchain 二、6层架构 Ref: (1)http://blog.csdn.net/qq_35624642/article/details/78138077 (2)...区块链技术的模型是由...
  • 区块链的架构模型以及核心技术

    千次阅读 2020-02-04 13:48:40
    架构模型 一般说来,区块链系统由数据层、网络层、共识层、激励层、合约层,应用层组成。 数据层: 封装了底层数据区块以及相关的数据加密和时间戳等基础数据和基本算法。 网络层: 则包括分布式组网机制、数据传播...
  • 最经典的三层架构模型(从数据流向看)

    千次阅读 多人点赞 2020-07-27 17:00:35
    处理订单呀,(订单核对呀,订单入库呀,订单递交下一级呀)持久层负责和仓库打交道(按订单要求取出相应的数量、型号的洗衣机) 这个模型是最经典的三层架构模型,是从逻辑层看软件开发的基本思路,这三层分别是...
  • 插件式设计的架构模型与实例

    千次阅读 2018-11-05 12:49:10
    分享一下我老师大神的人工智能教程!零基础,通俗易懂!http://blog.csdn.net/jiangjunshow也欢迎大家转载本...分享知识,造福人民,实现我们中华民族伟大复兴!   ... 插件式设计的架构模型
  • Hadoop的架构模型

    万次阅读 2020-10-06 11:32:52
    Hadoop的架构模型(1.x,2.x的各种架构模型介绍)1.x的版本架构模型介绍2.x的版本架构模型介绍 1.x的版本架构模型介绍 文件系统核心模块: NameNode:集群当中的主节点,主要用于管理集群当中的各种数据 ...
  • Netty高性能架构模型介绍

    千次阅读 2019-12-28 16:27:41
      上一篇我们介绍了Reactor模式,本文我们就来具体分析下Netty中的架构模型到底是怎么样的。 Netty模型介绍 1.工作原理-简单介绍   Netty 主要基于主从 Reactors 多线程模型(如图)做了一定的改进,其中主从 ...
  • 云计算架构参考模型

    2021-01-07 16:41:03
    图 1 所示是美国国家标准与技术研究所(简称 NIST)定义的通用云计算架构参考模型,图中列举了主要的云计算参与者,以及他们各自的分工。 NIST 云计算架构参考模型定义了 5 种角色,分别是云服务消费者、云服务提供...
  • J2EE应用的五层架构模型J2EE应用的五层架构模型J2EE应用的五层架构模型
  • 金蝶K/3 Cloud 开放数据架构模型

    千次阅读 2017-09-01 13:35:10
    金蝶K/3 CLOUD系统是一个开放性很强的ERP,给予了用户足够多的自定义...K/3 Cloud - 数据架构模型 - 基础 http://open.kingdee.com/k3cloud/PDM/BD.htm K/3 Cloud - 数据架构模型 - 财务 http://open.kingdee.
  • 系统分层与架构模型

    千次阅读 2016-05-03 12:35:50
    BS/CS模型、三层管理架构(表现层、应用处理层、数据管理层) 瘦客户机模型(Thin-client model ) 在瘦客户机模型中,所有的应用处理和数据管理都在服务器上执行。 客户机只负责运行表现层软件。 ...
  • DDD 分层架构 整洁架构 整洁架构又名“洋葱架构”。为什么叫它洋葱架构?看看下面这张图你就明白了。整洁架构的层就像洋葱片一样,它体现了分层的设计思想。 整洁架构最主要的原则是依赖原则,它定义了各层的依赖...
  • 典型的集群架构模型

    千次阅读 2015-05-10 07:12:57
    下面介绍三种典型的集群架构模型。 重客户端系 优势: 1、 注册中心作为协调器,客户端和服务端直连,消费者和提供者只在服务启动时或者服务发生变化时才依赖注册中心,其余时间注册中心出现任何问题,服务...
  • 本文档介绍了Simulink搭建模型架构时应该遵循的一些准则,或者标准。方便架构设计和维护,以及代码自动生成
  • 一、架构思维概述 对于架构思维本身仍然是类似系统思维,结构化思维,编程思维等诸多思维模式的一个合集。由于架构的核心作用是在业务现实世界和抽象的IT实现之间建立起一道桥梁,因此架构思维最核心的就是要理解到...
  • 数据架构与数据模型

    千次阅读 2020-06-26 21:12:57
    数据架构与数据模型 数据架构与数据模型两者关系经常是讨论的热点。 因为数据架构里面主要工作和产物就是数据建模和数据模型,那为什么要将两者作为独立的两个过程域。 本文将对此问题进行探讨。 在《数据管理...
  • ETSI MEC — 参考架构模型

    千次阅读 2020-08-04 18:03:53
    目录 文章目录 目录 ETSI MEC 参考架构模型 架构设计原则 分层架构 系统架构 CFS portal UE app User app LCM proxy OSS MEAO MEPM MEP VIM ME Host DP VI ME APP 参考点类型 用户实例化 APP 的流程 ETSI MEC 参考...
  • 三层架构模型

    千次阅读 2022-02-21 22:10:17
    今天我们讲一讲三层架构模型层。 为了让大家能够更好的理解三层架构,我们通过三层架构实现登录功能,让你更全面的理解三层架构和使用。 1、模型层的介绍 模型层主要存储的是模型对象实体,这些实体的组合叫做...
  • 用于软件架构的 C4 模型

    千次阅读 2019-05-05 20:02:16
    第 1 层:系统上下文 第 2 层:容器 第 3 层:组件 第 4 层:代码 ...C4 模型由一系列分层的软件架构图组成,这些架构图用于描述上下文、容器、组件和代码。C4 图的层次结构提供了不同...
  • IT四架构设计模型

    千次阅读 2020-04-06 17:30:29
    业务架构定义了整体业务能力以及各部门、各业务的协作关系,由业务要素模型表达整体业务能力,包括业务职能、业务布局和业务组合形态,由业务流程模型表达各部门、各业务的协作关系;信息架构定义了全局信息资源组织...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 658,325
精华内容 263,330
关键字:

架构模型