精华内容
下载资源
问答
  • 去中心化是区块链的一个重要的特征,它并不是什么新词,其实就是...过去几年里,人们区块链的最大误解可能就是去中心化”这个词的理解,按字面含义,去中心化就是节点的分散,数据的分散,矿工的分散,开发者...

                      

            爱奇艺20180515150322.png



    去中心化是区块链的一个重要的特征,它并不是什么新词,其实就是亚当•斯密的那只看不见的手:市场的自由竞争。算力集中本身就是市场的结果,任何一个开放系统在自由竞争下,都会形成专业化分工,这就好比生物有机体的组织分化。



    过去几年里,人们对区块链的最大误解可能就是对“去中心化”这个词的理解,按字面含义,去中心化就是节点的分散,数据的分散,矿工的分散,开发者的分散……甚至有人认为,矿工的分散(人人都能用个人电脑挖矿)是中本聪的初心,中本聪支持“一CPU一票”,即每个用户通过个人电脑、手机就能挖矿。还有人试图通过算法的改进,阻抗ASIC芯片的研发,避免算力的中心化,当然,这些努力都是掩耳盗铃,算法只能延缓专业化挖矿芯片的诞生,而不是阻止。 需要指出的是,“人人都能用个人电脑挖矿”恰好是中本聪所反对的“一IP一票制”,这是因为每位矿工的电脑都贡献为一个全节点,相当于网络节点的所有IP都拥有相等的权力。那么,那些拥有分配大量IP地址权力的人,比如僵尸网络就可能主宰比特币网络。僵尸网络中最多可包含数十万台机器,如暴风木马拥有25万个节点,远远大于比特币全网节点数(6000~8000个),暴风木马控制的僵尸网络可以轻而易举地发起51%攻击。



    中本聪所言“一CPU一票”实际是说一个计算单位代表着一个权力单位,拥有的计算力更高,即意味着更高的权力,这是工作量证明“计算即权力”思想的形象化表达。 每个人都能通过自己的个人电脑、手机挖矿,这看起来是更公平、更去中心化的理想社会,可为什么区块链的安全性反而降低了呢?原因很简单,去中心化并不是一个描述状态的词,而是一个描述过程的词,状态的去中心化并不意味着过程的去中心化,僵尸网络的节点在状态上是分散的,但在行为模式上具有高度一致性。去中心化的本意是指,每个人参与共识的自由度。他有参与的权力,他也有退出的权力。在代码开源、信息对称的前提下,参与和决策的自由度,即意味着公平。



    我们可以从资产配置的角度来理解去中心化,资产配置也同样有着分散风险、分散资产的需求。早在数百年前,莎士比亚《威尼斯商人》中的安东尼奥说道:“我的买卖的成败,并不完全寄托在一艘船上,更不是依赖着一处地方;我的全部财产,也不会因为一年的盈亏而受到影响。”也就是人们常说的“不把鸡蛋放在同一个篮子”策略。 但是,如果篮子里的资产具有相关性,那么,不管资产配置是多么分散,它都不能起到分散风险的作用。如果一个市场整体处于下跌通道,且市场中的绝大多数资产具有相关性,你的资产配置越分散,即意味着越稳定的资产损失。这个时候,反而不如赌徒式的孤注一掷,把所有资金配置在一个与多数资产不具相关性或具反相关性的资产之上。 如果这些资产的相关性是个未知数,那么按最大熵原理 (注1),应该假设这些资产拥有最大随机性。对于区块链来说,就应该假设这些节点都有绝对的自由决策权,而不应赋予开发者或一部分人更高的权力,授信或委托他们来记账。



    正如普林斯顿比特币公开课所指出的:“比特币的共识算法十分依赖随机化。它摒弃了发生共识的特定的开始时间和结束时间,取而代之的是随着时间的推进,你认为的某些区块将被共识的几率会越来越高,观点分歧的几率则会以指数级下降。这些模型中的区别正是比特币能够绕过传统的对于分布式共识算法的不可能结果的关键所在。”比如Bitfinex交易所虽然使用了多重签名,但由于Bitgo所保管的那把私钥,对所有来自Bitfinex服务器的请求都自动签名,两把私钥实际上仅相当于一把私钥。不管是使用多少把私钥的多重签名,不管这些私钥的保管是多么分散,只要这些私钥的行为模式具有一致性,那么这个多重签名方案就是不安全的。 相反,在挖矿激励机制下,虽然造成了表面上的算力中心化局面(实质上也是分散的,只不过少数人拥有的算力远远大于其他人),但并没有人可以阻止你去参与挖矿,研发矿机,这完全是个自由竞争的去中心化过程。这就好比选举投票,人人拥有选票的民主制度虽然也会选出小布什,表面上看是家族“世袭”,但选举过程是去中心化的,那么这些选举就是合法的。



    在竞争机制下,算力的集中并不是什么可怕的问题,一方面,由于高昂的计算力成本,矿池、矿工发起51%攻击不符合理性经济人的前提;另一方面,即使存在不可理喻的疯子,比如拥有大量算力份额的矿池,他们的攻击也不可持续,因为矿池的算力并不真正属于他们自己,且随时面临新加入的算力、新玩家的挑战。算力集中本身就是市场的结果,任何一个开放系统在自由竞争下,都会形成专业化分工,这就好比生物有机体的组织分化。专业化的矿工,专业化的支付钱包,专业化的区块链数据服务商……这正是区块链去中心化的结果,而不是我们处心积虑要避免的后果。



    注1:最大熵原理是在1957 年由E.T.Jaynes 提出的,其主要思想是,在只掌握关于未知分布的部分知识时,应该选取符合这些知识但熵值最大的概率分布。



    链视界,以推动区块链行业发展为目的,集媒体、社区、咨询、培训、基金为一体的区块链创业平台。(链视界ID:lsj_btc)


    展开全文
  • 理解的区块链

    2018-06-06 15:35:48
    涉及到技术:分布式存储系统,点点网络,去中心化的共识机制,密码学数据加密和签名算法中心化系统:各国中央银行货币发行,银行账务+支付系统,支付宝,拉卡拉,股票交易系统,保险系统,彩票发...

    大家好,下面给大家用非常科普的语言说一说什么是区块链,和我理解的区块链是什么样的。
    区块链:一种保证陌生人之间或陌生组织之间可自动建立信任的技术,这种信任是值得的信任,是真实的信任,是不可能被辜负的信任。
    涉及到的技术:分布式存储系统,点对点网络,去中心化的共识机制,密码学数据加密和签名算法
    中心化的系统:各国中央银行货币发行,银行账务+支付系统,支付宝,拉卡拉,股票交易系统,保险系统,彩票发行与摇奖系统,知识产权登记交易管理系统,国家房屋产权登记交易机构的系统,各种中介系统等等,像以上这些系统都是掌握在具体的组织或机构的手中,这些组织对自己掌握的系统中的数据有增删改查的绝对权限。
    在中心化系统中:陌生人之间的交易,靠的是国家政府的信用背书,比如人民币和美元等法币,是国家强制推行的,你必须相信国家和政府,必须使用他来交换商品或服务,大家也都相信法币,认为可以使用法币来换取商品和服务。支付宝和微信里的数字为什么可以换取商品和服务,因为第一,这些数字是用法币换来的,第二,你相信支付宝和微信,大家都相信。这就是共识,很多认认为这个东西有价值,它就真的有价值,这就是共识。而中心化的系统有它的弊端,需要高额的成本来维护,庞大的计算机系统集群,需要专业的人力物力来长期做这件事,还需要豪华的办公场所。比如各大商业银行的营业厅,哪个不是建立在寸土寸金的地方,还有在里面处理业务的人员;证券交易所大楼,专业交易员,系统维护运营团队的工资成本。另外,中心化的系统,游戏规则掌握在发行者和运营方少数人手里,这些人为了某种利益有可能随时更改游戏规则,比如货币超发,比如支付系统修改数据等等。毕竟记账权掌握在中心化机构和组织的手里,普通人连查账的权限都没有。
    去中心化系统:区块链技术实现了去中心化的交易模式,不再需要中心化的数据库和和中介机构和组织去运营维护,而是所有参与方通过点对点的网络维护同一个账本,每个人都有这个账本,而且每一个人的账本数据是高度一致的,大家通过个某种共识机制(POW,POS,DPOS),谁都有权记账(不是同时记账,而是一笔一笔的轮流记账,上一笔A记,下一笔B记...),但最关键的是你记的帐有没有效,是要靠大家一起来验证,超过三分之二的人验证你记账的结果是正确的,才能通过,如果大多数人验证你记的帐是错误的,你记的帐就通不过。记账就是把一段时间的交易流水打包成一定格式的数据块(区块),写在系统链表里,形成了区块链,俗称“挖矿”,记账者是有实实在在的奖励的。参与者对账务数据的验证就是使用密码学中的数据加解密和签名算法,对数据制造者的身份进行验证,对数据有没有被非法篡改进行验证和确认。
    这样的系统就是去中心化系统,或叫去中介化系统,使用的是区块链技术。
    区块链,一个典型的应用就是比特币。不过并不能简单的说比特币就等同于区块链,区块链和比特币的关系是这样的,区块链是一种技术,比特币是区块链技术的某一个应用,比如人工智能是一种技术,人脸识别是人工智能的一方面的应用,你不能说人工智能就是人脸识别。同样你不能说区块链就是比特币,或者比特币就是区块链。区块链是比特币的技术支撑和基础架构,比特币是区块链的典型应用,就这么简单。区块链的应用范围还很广泛,绝不是简简单单的就是一个数字货币的发行,更加能发挥其作用的行业有:供应链金融,可信存证,知识产权登记和交易,保险合同,证券确权、交易,个人和企业征信,商品溯源等等。
    目前区块链技术还很新,还没有大量的落地应用,而是被投机者在发行数字货币的领域大肆应用,造就了一大批的数字货币,还有一些空气币。甚至有一些骗子打着区块链的旗号搞传销币,进行诈骗,骗子只是打着个区块链的幌子,而并没有一点点的区块链技术应用。
    目前区块链的发展经历了,比特币(中本聪提出和研发),大家都说是区块链v1.0版本,以太坊(俄罗斯计算机天才号称 V神创建),大家公认的区块链v2.0,因为以太坊已经是一个小平台了,在以太坊的区块链系统上,可以通过写简单代码,来运行ERC20协议的智能合约应用,以太坊上发行了很多数字货币,但以太坊的性能和运行速度还不行,而且还收费。bm团队研发的EOS应该是当之无愧的区块链v3.0了。应为EOS平台上可以跑大量智能合约应用,而且速度极快,性能优越,还免费,我本人比较看好EOS。

    展开全文
  • 每天都在谈SOA和微服务,但你真的理解什么是服务吗? 服务的技术架构之争 服务应该版本,不管是微服务还是SOA 任何架构的调整只是拆了东墙补西墙,无法解决效率问题 先厘清服务治理与组织架构的关系,再来...

    每天都在谈SOA和微服务,但你真的理解什么是服务吗?

    服务的技术架构之争

    服务应该去版本化,不管是微服务还是SOA

    任何架构的调整只是拆了东墙补西墙,无法解决效率问题

    先厘清服务治理与组织架构的关系,再来谈微服务吧

    由于我们一直从事的是传统企业的架构改造工作,所以对新兴的互联网企业如何实施微服务架构并没有实践过。在写这一章之前,我在架构群里和曾经实施过微服务架构的互联网企业的架构师进行了交流,结果是深深的失望。我看到互联网企业为了快而失去的那些我觉得必不可少的能力,看到了以“简单即美”为借口的粗糙。

    为此,我重写了这一章。在这之前的章节是将整个架构割裂开来,分别孤立的来探讨分析。这一章我希望能尽我所能融合传统服务体系与微服务于一体,构造一个平衡的、安全的、易于扩展的、易于维护的、高效的企业内服务架构。

    企业内的集成架构

    企业内部对待新建系统和存量系统在技术上的需求是不同的,往往已经建好的系统希望尽可能的稳定不进行大的架构和技术改变,同时还希望这些存量系统能够尽可能的发挥作用;而新建的系统则希望在稳定可靠的基础上尽可能的采用先进的技术和架构,以适应未来的发展不会很快落后过时。这样的一种策略,必然的造成企业内部系统都是异构的,所以从长期看我们关注异构系统之间的应用集成架构,从短期看我们关注当期的新建系统的统一应用开发架构。

    去中心架构不适合应用集成

    企业内部的应用集成架构的需求是将现存的所有异构服务系统通过非侵入的适配技术手段进行整合,并对服务的消费者按需的提供接口。应用集成架构的这种需求决定了去中心架构不能适用。

    去中心架构在集成架构中并无实际的意义,因为传统的应用在没有集成之前就已经是去中心架构的点对点网状连接,正是这种异构系统之间杂乱的点对点网状连接才催生了集成架构的出现。如果强行的将集成适配器分散到每一个应用形成应用前置的话,相当于为每一个应用独立的部署了一套ESB,这样做除了增加开销之外完全看不出有什么实际的价值。

    即便我们不考虑实际的价值,去中心的集成架构还是需要一个物理上的调度中心用以实现可能需要的服务组合。因为在任何一个应用的适配前置上都不具备实现组合的合理性(虽然应用架构师可以强行的选择在某个或某几个前置上实现)。

    系统安全对去中心架构的限制

    我们在第四章讨论本征服务的时候给出了一个本征化后的微服务架构图,如下:

    我说看着细细的蓝线条觉得不够优雅,这里我们来看看传统企业的部署架构示意图:

    其实,我是鼓足了勇气来质疑这一件事情,在写这篇文章之前我咨询了做互联网的朋友们,确信了在互联网企业中是没有DMZ区的,所有的应用都是混杂在一个区的,包括数据库(当然,由于作者没有互联网公司的从业经验,而通常互联网公司都是自己做架构设计,所以我也没有机会参与互联网公司的架构设计,这一切只是道听途说)。DMZ的具体作用相信大家都明白,当然不明白的可以去找一下相关的资料。因为安全原因一般WEBUI层都是部署在DMZ区的,我不想为了微服务而打破这一优良的设计,所以第四章的图就变成这样:

    这幅图里为了方便我把网关和组合服务容器放到了一起,其实他们可以分开部署(这不重要),重要的是这个架构已经回归了ESB中心交换模式。其实传统的SOA架构最终在企业内部也是这样的,因为客户数据的安全性永远是第一位的。

    那么我们担心的淘宝级交易量怎么解决?我想说的是,牺牲客户数据安全性来换取效率是绝对不可取得,几千个应用部署在一个区内,怎么也无法保证每个应用都是坚固可靠、无懈可击的,一旦肉机被攻破那么灾难就来了,甚至恶意的程序员可以人为的制造肉机,这根本就防不住的。

    如果无法提高算法效率,又无法通过削弱安全指标来提升效率,那么就只能拿资源来换了。为了保证客户的利益,钱是要舍得花的,要么就别做这个业务。

    通过分区多中心来降低集中负载

    上图中,通过将业务按条线进行不同的分区,每个分区用独立的ESB集群进行集成。这样,每个前端系统调用后台服务的时候,就可以把访问压力分散到不同的分中心上,从而通过增加资源来提高访问效率。

    通过数据冗余来提高查询类服务效率

    通常,一个优秀的商业ESB产品可以产生从几毫秒到十几毫秒的系统延迟,对于大多数应用几十到几百毫秒的业务处理时间来说影响是微小的。但是当应用的处理时间缩短到几毫秒、同时又要求海量的并发能力的时候(比如简单查询),集成架构带来的延迟就变得无法忍受了(除非科技进步导致微秒级别的ESB成为现实)。

    传统的应用架构下通过数据集成的方式形成ODS、数据仓库和数据集市来解决数据的查询、报表和在线分析等实时或非实时数据类请求对业务系统带来的压力;互联网模式采用读写分离的方式来解决类似的实时数据查询的问题。所以,在上述架构中我们也提到短路的方式可以用数据集成架构来替代。

    用ODS的方式解决实时数据的查询相比较于用读写分离的方式来说,具有明显的缺陷:

    1、ODS存储的数据范围过大,而读写分离针对的是有海量查询需求的数据,所以数据的命中率更高,这样在利用冗余来提高效率方面比ODS的性价比更高。

    2、ODS方式需要应用改变查询逻辑从而增加系统间的耦合度,大多数应用只会关注自己的数据库,如果在应用内部采用访问ODS的方式来提高查询效率的话,会造成应用依赖于外部的数据库,从而造成从开发到运行整个应用生命周期内的效率降低。

    造成前后台大量交互问题的根源在于”前端展现系统需要后台服务系统的数据”。为什么会这样呢?其实,这是OOAD给我们带来的误区。传统的面向对象的方法告诉我们,我们会把属性和方法封装成一个对象,以便于针对对象的一致性操作,于是我们会给“客户”这个对象封装上创建和查询两个方法,这非常符合直观的逻辑。但是,这样做真的合理吗?

    从面向服务的方法来看,查询客户信息这样的服务真的不一定要客户信息系统来实现,实际上任何一个系统来实现这个服务都是可能的。在现实社会中,每个人的信息在各个地方都存在不同的副本,比如在派出所存在,在人才中心存在,在你所在的公司也存在,其实当有人需要查询你的个人信息的时候,基本会采用就近查询的原则。面向对象的方法给我们造成一个误区,这个误区就是所有的行为都是和实体封装绑定的,所以我们实现服务的时候也是将行为依附于实体。

    其实,现实社会的做法是,(信息)行为会更靠近需求者和使用者。换句话说,我们应该在前端应用里建立要展现数据的副本,并在前端系统中提供查询服务,因为只有前端系统才会更加频繁的使用这些服务,简单的说你们公司会给你建立个人信息副本,否则就要不断的去户籍所去查询你的信息,我确信这不是开玩笑。如下图,在前端系统建立对象经裁剪的的副本,就消除了系统间海量查询的需求。

    不过需要注意的是,由于WEB层都在DMZ区,将查询库放在DMZ区带来数据安全的风险,这个我们前面已经讲到了。所以,通过这种方法只能解决非关键数据的查询效率问题。

    企业内分布式多中心架构

     

    上图是保险行业某大型企业的真实案例,在架构改造的咨询过程中,我们根据客户的现状和未来的发展方向,提出了以能力建设和消费为主要业务目标的分布式架构。

    通过分布式服务中心,将企业的内部业务能力、传统合作伙伴提供的能力、数据能力以及互联网整合的第三方能力统一起来,建立全新的互联网生态圈,使得无论是内部的、外部的、合作伙伴的还是来自互联网的开发者都能够方便的了解和使用这些能力,帮助企业生态圈的快速建设和扩展。

    在运行时,原本相互孤立的互联网区、外联区和内网区存在的服务可以通过全局路由的形式被方便的访问,在逻辑上成为一个整体;在管理和治理上,所有的服务都按照统一的流程在一套管理平台上进行管理和治理。

    能力中心的基本逻辑结构

    逻辑上,能力聚合中心分为三个主要的部分,各部分通过队列进行异步通信:

    Out:服务(接出)容器

    Out是服务实体或服务适配器的部署容器,可以认为是服务的实现者。在全局,逻辑上一个服务只有一个实现者(多个实现者可以认为是服务的集群方式)。

    In:服务(接入)容器

    In是服务API(适配器)的部署容器,为了实现S++的服务访问位置和协议透明,在Out容器中的服务实体是无法被中心外部的物理消费者直接访问的,Out中的服务通过在In中发布多种不同的API,来适应采用不同的访问协议的服务消费者。

    为了实现服务访问地址透明,每个中心的In容器(如有必要)既可以发布本中心部署的服务API,也可以发布其他中心部署的服务的API,所以无论消费者从任何一个中心的渠道接入,都可以透明的访问全局所有的服务。

    Router:服务路由器

    为了实现服务访问地址对消费者透明,能力中心必须实现消费者无论从那个渠道接入,都可以透明的访问全局任何一个服务,所以全局路由器必须维持全局服务的路由地址表,将In接入的服务请求正确的路由到服务所部署的Out容器。

    基本上,每个中心都是由这样的逻辑组件作为基础运行平台的。除了基础运行平台外,每个中心会根据自己的业务需求,增加其他的组件,比如外联平台会有一整套完备安全组件;互联网开放平台提供自服务的开发者门户、主数据交换中心提供数据准实时同步能力等等。

    互联网开放平台

    开放平台用于向互联网应用开放企业内部的服务,以及引入互联网上的第三方服务,系统应能抵御互联网各类网络攻击,建立应用授权认证机制和隔离机制,具备完善的故障隔离机制,保证系统平稳运行。开放平台是基于云架构进行构建,主要包括以下功能模块:

    开发者门户:平台提供开发者门户,作为开发自服务的界面,包含开发者注册、社区、应用和服务的管理等;

    服务网关:提供针对服务的路由,协议转换、流量控制、日志流水等管理。

    OAuth授权:提供对用户访问资源的的开放授权协议。

    运维监控平台:平台提供统一的管理监控平台,完成平台相关参数的设计,各类申请的审核以及服务、应用的监控和统计分析。

    我们在互联网开放平台中引入了微服务,微服务应用会被部署在PaaS私有云中实现应用的动态扩展。所有的微应用都会挂接到API网关上,并由API网关对内对外提供微服务的路由,这个架构与我们前面提出的理论架构是基本一致的。

    理论上,所有的应用都可以部署到PaaS云上,但为什么实际上不这么做呢?因为传统应用过于庞大,不利于PaaS的动态响应,同时由于传统应用提供不了本征化的服务,会导致云环境伸缩策略过于复杂,并降低云环境的可靠性。本文的最后一个章节,我们会去讨论PaaS云的问题。

    其余各中心能力简介

    外联能力中心主要提供企业与传统合作伙伴互联互通的能力,通常都是通过专有的通信渠道进行链接,使用各自不同的安全协议和报文格式。

    主数据能力中心主要对内外部应用提供主数据发布和同步能力,采用服务主题订阅的模式,保证异步送达到数据消费者系统。消费者在本地形成数据副本,从而减小对业务系统和网络的压力,并提高查询效率。

    组合服务中心提供基于业务服务的全局和局部组合能力,并将组合后的流程作为新的服务发布出来供渠道调用。组合服务中心并不一定是一个真实的物理中心,他可以内嵌于各个物理中心内部。

    小结

    本章用一个实际的案例,介绍了分布式多中心架构,限于篇幅原因很多设计和实现细节无法展开来讲。

    分布式多中心架构是一个非常灵活的架构,可以根据客户的实际情况进行任意的裁剪。为适应客户不同的组织架构,服务治理采用可现场定制的治理流程,能同时适应注册制和核准制两种模式。并且,S++与分布式多中心架构的结合,赋予了微服务新的特性和更广阔的前景:

    1、微服务本征化,彻底实现微应用解耦,并大大简化微服务开发和运维的难度。

    2、S++服务组合容器使得基于服务的流程编排更简单、易于维护,甚至业务人员可以直接使用。

    3、S++的彻底的业务与技术分离,使得微服务的治理更加简单,从而实现真正的业务敏捷。

    4、S++并行组合的理论,将赋予微服务更高的性能和事务一致性保障,从而使得微服务可以更广泛的应用于各个领域。

    5、分布式多中心的架构与S++的结合,不但避免了去中心架构难以管理的问题,更保证了系统的安全性和效率。

    最后,我们将在最后一章节探讨S++化的微服务如何帮助PaaS环境实现基于服务质量的高灵敏度动态伸缩能力,从而能够快速的响应突发网络并发的冲击。

    展开全文
  • 每天都在谈SOA和微服务,但你真的理解什么是服务吗? 服务的技术架构之争 服务应该版本,不管是微服务还是SOA 任何架构的调整只是拆了东墙补西墙,无法解决效率问题 先厘清服务治理与组织架构的关系,再来...

    每天都在谈SOA和微服务,但你真的理解什么是服务吗?

    服务的技术架构之争

    服务应该去版本化,不管是微服务还是SOA

    任何架构的调整只是拆了东墙补西墙,无法解决效率问题

    先厘清服务治理与组织架构的关系,再来谈微服务吧

    由于我们一直从事的是传统企业的架构改造工作,所以对新兴的互联网企业如何实施微服务架构并没有实践过。在写这一章之前,我在架构群里和曾经实施过微服务架构的互联网企业的架构师进行了交流,结果是深深的失望。我看到互联网企业为了快而失去的那些我觉得必不可少的能力,看到了以“简单即美”为借口的粗糙。

    为此,我重写了这一章。在这之前的章节是将整个架构割裂开来,分别孤立的来探讨分析。这一章我希望能尽我所能融合传统服务体系与微服务于一体,构造一个平衡的、安全的、易于扩展的、易于维护的、高效的企业内服务架构。

    企业内的集成架构

    企业内部对待新建系统和存量系统在技术上的需求是不同的,往往已经建好的系统希望尽可能的稳定不进行大的架构和技术改变,同时还希望这些存量系统能够尽可能的发挥作用;而新建的系统则希望在稳定可靠的基础上尽可能的采用先进的技术和架构,以适应未来的发展不会很快落后过时。这样的一种策略,必然的造成企业内部系统都是异构的,所以从长期看我们关注异构系统之间的应用集成架构,从短期看我们关注当期的新建系统的统一应用开发架构。

    去中心架构不适合应用集成

    企业内部的应用集成架构的需求是将现存的所有异构服务系统通过非侵入的适配技术手段进行整合,并对服务的消费者按需的提供接口。应用集成架构的这种需求决定了去中心架构不能适用。

     

     

    去中心架构在集成架构中并无实际的意义,因为传统的应用在没有集成之前就已经是去中心架构的点对点网状连接,正是这种异构系统之间杂乱的点对点网状连接才催生了集成架构的出现。如果强行的将集成适配器分散到每一个应用形成应用前置的话,相当于为每一个应用独立的部署了一套ESB,这样做除了增加开销之外完全看不出有什么实际的价值。

    即便我们不考虑实际的价值,去中心的集成架构还是需要一个物理上的调度中心用以实现可能需要的服务组合。因为在任何一个应用的适配前置上都不具备实现组合的合理性(虽然应用架构师可以强行的选择在某个或某几个前置上实现)。

    系统安全对去中心架构的限制

    我们在第四章讨论本征服务的时候给出了一个本征化后的微服务架构图,如下:

     

     

    我说看着细细的蓝线条觉得不够优雅,这里我们来看看传统企业的部署架构示意图:

     

     

    其实,我是鼓足了勇气来质疑这一件事情,在写这篇文章之前我咨询了做互联网的朋友们,确信了在互联网企业中是没有DMZ区的,所有的应用都是混杂在一个区的,包括数据库(当然,由于作者没有互联网公司的从业经验,而通常互联网公司都是自己做架构设计,所以我也没有机会参与互联网公司的架构设计,这一切只是道听途说)。DMZ的具体作用相信大家都明白,当然不明白的可以去找一下相关的资料。因为安全原因一般WEBUI层都是部署在DMZ区的,我不想为了微服务而打破这一优良的设计,所以第四章的图就变成这样:

     

     

    这幅图里为了方便我把网关和组合服务容器放到了一起,其实他们可以分开部署(这不重要),重要的是这个架构已经回归了ESB中心交换模式。其实传统的SOA架构最终在企业内部也是这样的,因为客户数据的安全性永远是第一位的。

    那么我们担心的淘宝级交易量怎么解决?我想说的是,牺牲客户数据安全性来换取效率是绝对不可取得,几千个应用部署在一个区内,怎么也无法保证每个应用都是坚固可靠、无懈可击的,一旦肉机被攻破那么灾难就来了,甚至恶意的程序员可以人为的制造肉机,这根本就防不住的。

    如果无法提高算法效率,又无法通过削弱安全指标来提升效率,那么就只能拿资源来换了。为了保证客户的利益,钱是要舍得花的,要么就别做这个业务。

    通过分区多中心来降低集中负载

     

     

    上图中,通过将业务按条线进行不同的分区,每个分区用独立的ESB集群进行集成。这样,每个前端系统调用后台服务的时候,就可以把访问压力分散到不同的分中心上,从而通过增加资源来提高访问效率。

    通过数据冗余来提高查询类服务效率

    通常,一个优秀的商业ESB产品可以产生从几毫秒到十几毫秒的系统延迟,对于大多数应用几十到几百毫秒的业务处理时间来说影响是微小的。但是当应用的处理时间缩短到几毫秒、同时又要求海量的并发能力的时候(比如简单查询),集成架构带来的延迟就变得无法忍受了(除非科技进步导致微秒级别的ESB成为现实)。

    传统的应用架构下通过数据集成的方式形成ODS、数据仓库和数据集市来解决数据的查询、报表和在线分析等实时或非实时数据类请求对业务系统带来的压力;互联网模式采用读写分离的方式来解决类似的实时数据查询的问题。所以,在上述架构中我们也提到短路的方式可以用数据集成架构来替代。

    用ODS的方式解决实时数据的查询相比较于用读写分离的方式来说,具有明显的缺陷:

    1、ODS存储的数据范围过大,而读写分离针对的是有海量查询需求的数据,所以数据的命中率更高,这样在利用冗余来提高效率方面比ODS的性价比更高。

    2、ODS方式需要应用改变查询逻辑从而增加系统间的耦合度,大多数应用只会关注自己的数据库,如果在应用内部采用访问ODS的方式来提高查询效率的话,会造成应用依赖于外部的数据库,从而造成从开发到运行整个应用生命周期内的效率降低。

    造成前后台大量交互问题的根源在于”前端展现系统需要后台服务系统的数据”。为什么会这样呢?其实,这是OOAD给我们带来的误区。传统的面向对象的方法告诉我们,我们会把属性和方法封装成一个对象,以便于针对对象的一致性操作,于是我们会给“客户”这个对象封装上创建和查询两个方法,这非常符合直观的逻辑。但是,这样做真的合理吗?

    从面向服务的方法来看,查询客户信息这样的服务真的不一定要客户信息系统来实现,实际上任何一个系统来实现这个服务都是可能的。在现实社会中,每个人的信息在各个地方都存在不同的副本,比如在派出所存在,在人才中心存在,在你所在的公司也存在,其实当有人需要查询你的个人信息的时候,基本会采用就近查询的原则。面向对象的方法给我们造成一个误区,这个误区就是所有的行为都是和实体封装绑定的,所以我们实现服务的时候也是将行为依附于实体。在这里顺便给大家推荐一个架构交流群:617434785,里面会分享一些资深架构师录制的视频录像:有Spring,MyBatis,Netty源码分析,高并发、高性能、分布式、微服务架构的原理,JVM性能优化这些成为架构师必备的知识体系。还能领取免费的学习资源。相信对于已经工作和遇到技术瓶颈的码友,在这个群里会有你需要的内容。

    其实,现实社会的做法是,(信息)行为会更靠近需求者和使用者。换句话说,我们应该在前端应用里建立要展现数据的副本,并在前端系统中提供查询服务,因为只有前端系统才会更加频繁的使用这些服务,简单的说你们公司会给你建立个人信息副本,否则就要不断的去户籍所去查询你的信息,我确信这不是开玩笑。如下图,在前端系统建立对象经裁剪的的副本,就消除了系统间海量查询的需求。

     

     

    不过需要注意的是,由于WEB层都在DMZ区,将查询库放在DMZ区带来数据安全的风险,这个我们前面已经讲到了。所以,通过这种方法只能解决非关键数据的查询效率问题。

    企业内分布式多中心架构

     

     

    上图是保险行业某大型企业的真实案例,在架构改造的咨询过程中,我们根据客户的现状和未来的发展方向,提出了以能力建设和消费为主要业务目标的分布式架构。

    通过分布式服务中心,将企业的内部业务能力、传统合作伙伴提供的能力、数据能力以及互联网整合的第三方能力统一起来,建立全新的互联网生态圈,使得无论是内部的、外部的、合作伙伴的还是来自互联网的开发者都能够方便的了解和使用这些能力,帮助企业生态圈的快速建设和扩展。

    在运行时,原本相互孤立的互联网区、外联区和内网区存在的服务可以通过全局路由的形式被方便的访问,在逻辑上成为一个整体;在管理和治理上,所有的服务都按照统一的流程在一套管理平台上进行管理和治理。

    能力中心的基本逻辑结构

     

     

    逻辑上,能力聚合中心分为三个主要的部分,各部分通过队列进行异步通信:

    Out:服务(接出)容器

    Out是服务实体或服务适配器的部署容器,可以认为是服务的实现者。在全局,逻辑上一个服务只有一个实现者(多个实现者可以认为是服务的集群方式)。

    In:服务(接入)容器

    In是服务API(适配器)的部署容器,为了实现S++的服务访问位置和协议透明,在Out容器中的服务实体是无法被中心外部的物理消费者直接访问的,Out中的服务通过在In中发布多种不同的API,来适应采用不同的访问协议的服务消费者。

    为了实现服务访问地址透明,每个中心的In容器(如有必要)既可以发布本中心部署的服务API,也可以发布其他中心部署的服务的API,所以无论消费者从任何一个中心的渠道接入,都可以透明的访问全局所有的服务。

    Router:服务路由器

    为了实现服务访问地址对消费者透明,能力中心必须实现消费者无论从那个渠道接入,都可以透明的访问全局任何一个服务,所以全局路由器必须维持全局服务的路由地址表,将In接入的服务请求正确的路由到服务所部署的Out容器。

    基本上,每个中心都是由这样的逻辑组件作为基础运行平台的。除了基础运行平台外,每个中心会根据自己的业务需求,增加其他的组件,比如外联平台会有一整套完备安全组件;互联网开放平台提供自服务的开发者门户、主数据交换中心提供数据准实时同步能力等等。

    互联网开放平台

     

     

    开放平台用于向互联网应用开放企业内部的服务,以及引入互联网上的第三方服务,系统应能抵御互联网各类网络攻击,建立应用授权认证机制和隔离机制,具备完善的故障隔离机制,保证系统平稳运行。开放平台是基于云架构进行构建,主要包括以下功能模块:

    开发者门户:平台提供开发者门户,作为开发自服务的界面,包含开发者注册、社区、应用和服务的管理等;

    服务网关:提供针对服务的路由,协议转换、流量控制、日志流水等管理。

    OAuth授权:提供对用户访问资源的的开放授权协议。

    运维监控平台:平台提供统一的管理监控平台,完成平台相关参数的设计,各类申请的审核以及服务、应用的监控和统计分析。

    我们在互联网开放平台中引入了微服务,微服务应用会被部署在PaaS私有云中实现应用的动态扩展。所有的微应用都会挂接到API网关上,并由API网关对内对外提供微服务的路由,这个架构与我们前面提出的理论架构是基本一致的。

    理论上,所有的应用都可以部署到PaaS云上,但为什么实际上不这么做呢?因为传统应用过于庞大,不利于PaaS的动态响应,同时由于传统应用提供不了本征化的服务,会导致云环境伸缩策略过于复杂,并降低云环境的可靠性。本文的最后一个章节,我们会去讨论PaaS云的问题。

    其余各中心能力简介

    外联能力中心主要提供企业与传统合作伙伴互联互通的能力,通常都是通过专有的通信渠道进行链接,使用各自不同的安全协议和报文格式。

    主数据能力中心主要对内外部应用提供主数据发布和同步能力,采用服务主题订阅的模式,保证异步送达到数据消费者系统。消费者在本地形成数据副本,从而减小对业务系统和网络的压力,并提高查询效率。

    组合服务中心提供基于业务服务的全局和局部组合能力,并将组合后的流程作为新的服务发布出来供渠道调用。组合服务中心并不一定是一个真实的物理中心,他可以内嵌于各个物理中心内部。

    小结

    本章用一个实际的案例,介绍了分布式多中心架构,限于篇幅原因很多设计和实现细节无法展开来讲。

    分布式多中心架构是一个非常灵活的架构,可以根据客户的实际情况进行任意的裁剪。为适应客户不同的组织架构,服务治理采用可现场定制的治理流程,能同时适应注册制和核准制两种模式。并且,S++与分布式多中心架构的结合,赋予了微服务新的特性和更广阔的前景:

    1、微服务本征化,彻底实现微应用解耦,并大大简化微服务开发和运维的难度。

    2、S++服务组合容器使得基于服务的流程编排更简单、易于维护,甚至业务人员可以直接使用。

    3、S++的彻底的业务与技术分离,使得微服务的治理更加简单,从而实现真正的业务敏捷。

    4、S++并行组合的理论,将赋予微服务更高的性能和事务一致性保障,从而使得微服务可以更广泛的应用于各个领域。

    5、分布式多中心的架构与S++的结合,不但避免了去中心架构难以管理的问题,更保证了系统的安全性和效率。

    最后,我们将在最后一章节探讨S++化的微服务如何帮助PaaS环境实现基于服务质量的高灵敏度动态伸缩能力,从而能够快速的响应突发网络并发的冲击。

    展开全文
  • 从历史角度看,区块链意义是什么? 区块链真会颠覆公司制度吗? 区块链时代如何布局? 区块链技术是一场社会革命,浪潮席卷全球,重新...人类文明史是一部去中心化的历史 市场经济是一份智能合约 区块链...
  • 每天都在谈SOA和微服务,但你真的理解什么是服务吗? 服务的技术架构之争 服务应该版本,不管是微服务还是SOA 任何架构的调整只是拆了东墙补西墙,无法解决效率问题 先厘清服务治理与组织架构的关系,再来...
  • 区块链安全咨询公司 曲速未来 表示:“经济是技术表达”,当一个新技术出现,往往会现有经济带来冲击和重构。...“去中心化”值得做深入、广泛探讨,它也是区块链一直以来争议颇多核心内容。当年...
  • springCloud(理论多)

    2021-01-28 15:51:57
    微服务架构风格是,开发一组小型服务来完成一个独立应用系统,其中每个小型服务都运行在自己独立进程中,并经常采用HTTP资源API这种轻量级方式通信。这些服务围绕业务功能来构建,并且有...6、去中心化数据..
  • 7.5.3 非结构数据过度使用 325 7.6 总结 326 7.7 回顾与展望 326 第8章 数据访问安全 328 8.1 安全主体与安全对象 329 8.2 数据库安全概述 330 8.2.1 模拟 331 8.2.2 权限 333 8.2.3 控制对象访问 334...
  • Comunion 是一个去中心化组织(DAO)协作网络 这是当我被问起 Comunion 是什么时候,最官方一种回答。然而这样回答对于那些区块链以及 DAO 并不熟知人来说依然存在理解屏障。 解释 Comunion 是什么,可以...
  • UML重点知识总结

    2019-02-23 22:09:52
    UML即统一建模语言,建模就是用一种抽象的方法表征事物以获得事物本身的理解,然后把这种理解概念,然后将这些逻辑性的概念组织结合在一起,构成所观察事物的内部结构和工作原理的便于理解的表达。...
  • 走进zeronet

    2021-01-20 13:16:36
    zeronet是一个利用bt加密技术和比特币技术开发的去中心化网络,今天让我们走进zeronet,看看他我们有什么用处 走进zeronet 初见 简介 zeronet我们可以把它理解为一个网络组织,由所有使用软件用户共同维护,期间...

空空如也

空空如也

1 2 3 4 5
收藏数 81
精华内容 32
关键字:

对去中心化组织的理解