精华内容
下载资源
问答
  • 内容的可扩展性
    千次阅读
    2016-10-29 12:35:20

    序言——————可扩展性是什么;
    可扩展性高就是当添加新内容时,其他内容不需要随之改变。
    按网上的说法就是;
    可扩展性,新的功能可以很容易的加入到系统中去,这就是可扩展性,突然有一天客户的需求变了,需要增加新的功能,我这项目要增加新的功能,但是我这项目的主结构不变,这叫做可扩展性好

    1,扩展性最低的就是把类都单独拿出来,没有继承什么,都是单个的类来实现作用,这种思维可扩展性最低。因为当添加一个类的时候,调用这个类的方法一定要重新编写,这样就造成扩展性的低下。

    2;就是存在继承,利用父类引用指向子类对象,在调用方法的时候在去instance判断,来调用各自的方法;这样可扩展性提高了一点点,当添加新内容的时候只需要去修改一个那个判断类就ok了。但是可扩展性并不是最高的,为了提高可扩展性,Java引用的多态这一原则,
    在一个方法的参数中定义父类的引用,然后实际当中传入的时候,传的是子类的对象,然后再在实际的方法里去判断属于哪个子类,再去调用其成员方法。

    package text_extendibility;
    /**
     * 父类Animal。
     * @author Administrator
     *
     */
    
    public class Animal {
        public String name;
    
        Animal(String name){
            this.name = name;
        }
    
        public void enjoy(){
            System.out.println("   " + this.name + "叫声");
        }
    }
    
    package text_extendibility;
    /**
     * Cat类继承与animal类,并重写enjoy函数
     * @author Administrator
     *
     */
    public class Cat extends Animal{
        private String fulColor;
    
        Cat(String name, String c) {
            super(name);//引用父类的构造函数
            // TODO Auto-generated constructor stub
            fulColor = c;
        }
    
        public void enjoy(){
            System.out.println(this.name + "   " + this.fulColor + "猫的叫声");
        }
    }
    
    package text_extendibility;
    
    /**
     * Dog类继承Animal类,并重写enjoy函数。
     * @author Administrator
     *
     */
    public class Dog extends Animal{
        private String eyesColor;
    
        Dog(String name, String c) {
            super(name);
            // TODO Auto-generated constructor stub
            eyesColor= c;
        }
    
        public void enjoy(){
            System.out.println(this.name + "    " + this.eyesColor + "狗的叫声");
        }
    }
    
    package text_extendibility;
    
    public class Lady {
        private String name;
        private Animal p;
    
        Lady(String name, Animal p){
            this.name = name;
            this.p = p;
        }
        public void showName(){
            System.out.println(this.name);
        }
        /**
         * 这里的可扩展性可以提高;
         */
        public void myPetEnjoy(){
            if(p instanceof Cat){
                Cat p1 = (Cat)p;
                p1.enjoy();
            }
            else if(p instanceof Dog){
                Dog p1 = (Dog)p;
                p1.enjoy();
            }
        }
    }
    
    package text_extendibility;
    
    /**
     * Main类,创建Dog和Cat对象。
     * 并且创建Lady对象并将Dog,Cat对象传入构造函数中,并调用Lady中myPetEnjoy方法,
     * @author Administrator
     *
     */
    public class Main {
    
        public static void main(String[] args) {
            // TODO Auto-generated method stub
            Dog dog = new Dog("11", "blue");
            Cat cat = new Cat("22", "black"); 
    
            Lady l1 = new Lady("lady1", dog);
            l1.myPetEnjoy();
    
            Lady l2 = new Lady("lady2", cat);
            l2.myPetEnjoy();
        }
    
    }
    

    3;多态才是java的可扩展性达到最高,
    在上面的代码处修改一点点,就达到多态了。多态就是在运行期间进行指向,不需要程序员去指向。这一就大大的提高了Java的可扩展性,多态是Java的核心机制。
    在执行期间,判断所引用对象的实际类型,根据其实际方法,调用其相应的方法。

    将Lady类修改一下,即可。
    package text_extendibility;
    
    public class Lady {
        private String name;
        private Animal p;
    
        Lady(String name, Animal p){
            this.name = name;
            this.p = p;
        }
        public void showName(){
            System.out.println(this.name);
        }
        /**
         * 利用多态,是程序可扩展性达到最高,
         * 即使Animald子类增加,Lady类也不需要做修改。
         */
        public void myPetEnjoy(){
            p.enjoy();
        }
    }
    
    更多相关内容
  • 面试问题:如何实现软件可扩展性

    万次阅读 2018-07-12 11:33:04
    网站的可扩展性架构设计,能够在对现有系统影响最小的情况下,系统功能可以可持续扩展及提升的能力。在此,对容易混为一谈的 “扩展性” 和 “伸缩性” 的概念进行详细说明:扩展性表现为:基础设施不需要经常变更,...

    网站的可扩展性架构设计,能够在对现有系统影响最小的情况下,系统功能可以可持续扩展及提升的能力。

    在此,对容易混为一谈的 “扩展性” 和 “伸缩性” 的概念进行详细说明:

    扩展性

    表现为:基础设施不需要经常变更,应用之间较少依赖或耦合,可以对需求变更快速响应。它对扩展开放,对修改关闭。架构设计会考虑到未来功能的可扩展性,所以当系统增加新功能时,不需要对现有系统的结构和代码进行修改。

    伸缩性

    是指系统通过增加(或减少)自身资源规模的方式增强(或减少)处理业务的能力。如果这种增减是成比例的,就可以称之为线性伸缩性。通常是利用集群的方式增加服务器的数量,以提高系统整体业务吞吐能力。

    1 构建可扩展的网站架构

    度量一个开发框架、设计模式或编程语言优劣的一个重要尺度就是它是否能够让软件开发过程和软件产品更加低耦合。

    因为低耦合的系统更容易扩展,也更容易被复用,而且也会让开发过程和维护变得更加容易。但如何分解系统的各个模块、如何定义各个模块的接口、如何复用、组合不同模块构造一个完整的系统,这是软件设计中最具挑战性的部分。

    软件架构师的最大价值,就在于把一个大系统分解为 N 个低耦合的子模块的能力,这些子模块包含横向的业务模块与纵向的基础技术模块。这种能力来源于专业技术能力与经验、业务场景的理解、对人性的把握以及对世界的认知。

    构建可扩展的网站架构的核心思想是模块化,并在此基础上,降低模块之间的耦合性,提高模块的复用性。

    可以利用分层与分割的方式,把软件分割为若干个低耦合、独立的组件模块,然后在这些组件模块之间以消息传递或依赖调用的方式聚合成一个完整的系统。

    这些模块可以通过分布式部署的方式,部署在独立的服务器上。这种从物理上分离模块之间的耦合关系,可以进一步降低耦合性。

    模块的分布式部署后的聚合方式有: 
    * 分布式消息队列。 
    * 分布式服务。

    1 使用分布式消息队列降低耦合性

    如果模块之间不存在直接调用关系,那么新增或修改模块对其他部分的影响最小,这样的扩展性自然更好。

    1.1 事件驱动架构

    事件驱动架构指的是:在低耦合的模块之间传输事件消息,保持模块之间的松散耦合,通过事件消息来完成模块之间的通信。 事件驱动架构最常见的实现方式就是使用分布式消息队列。

    基于消息队列的事件驱动架构

    消息队列基于发布——订阅模式工作,消息发送者发布消息,一个或多个消息接收者订阅消息。消息发送者把消息发送至分布式消息队列后就处理完毕,然后由消息订阅者从消息队列中获取消息进行处理。对于新增的业务,只要对某个消息感兴趣,就可以订阅该消息,而这对原有的系统和业务没有任何影响,从而实现系统的可扩展性设计。

    消息接收者还可以对收到的消息再构造,定义出一个新的消息类型,然后再把消息发送给订阅了这一新消息类型的接收者。所以基于消息对象的事件驱动架构可以是一系列的流程。

    因为消息发送者无须等待就可以返回,所以系统具有更好的响应时间;而且在访问高峰,消息可以暂存于消息队列中,从而减轻了数据库的存储负载压力。

    1.2 分布式消息队列

    队列是一种先进先出的数据结构,我们可以把消息队列部署到独立的服务器中。应用通过远程访问接口使用消息队列,进行消息的存取操作,从而实现分布式的异步调用:

    分布式消息队列原理

    目前较为流行的分布式消息队列是 Apache ActiveMQ。

    因为消息队列服务器上的数据可以看做是即时处理的,所以在伸缩性上,我们把新服务器加入分布式消息队列集群后,只需要通知生产者服务器更改消息队列的服务器列表就好啦O(∩_∩)O~

    可用性上,如果内存队列满了,要将消息写入磁盘,这样当消息推送模块把内存队列中的消息处理完毕后,就会把磁盘中的消息加载到队列中继续处理。

    为了避免消息队列服务器宕机造成消息丢失,会把消息存储在消息的生产者服务器上,这样等消息确实被消息消费者服务器处理后才会删除。如果消息队列服务器宕机,生产者服务器会选择分布式消息队列服务器集群内的其他服务器发布消息。

    分布式消息队列可以很复杂,比如支持 ESB(企业服务总线)和 SOA(面向服务的架构)等。也可以很简单,比如使用 MySQL 作为分布式消息队列:消息的生产者把消息作为记录写入数据库,消费者查询数据库(按记录写入库表的时间戳排序),这就是一个分布式消息队列啦。再配上成熟的 MySQL 运维手段,也可以达到一个较高的可用性和性能指标哦O(∩_∩)O~

    2 使用分布式服务构建可复用的业务平台

    分布式服务可以通过接口降低系统的耦合性,不同的子系统之间通过相同的接口描述调用服务。

    随着网站功能的日益复杂,系统会逐渐发展成为一个巨无霸,里面聚合了大量的应用和服务组件,这样的一个系统会给开发、维护、部署带来巨大的麻烦: 
    * 编译、部署困难。 
    * 代码分支管理困难:复用的代码模块由多个团队共同维护修改,所以在代码合并时总会发生冲突。 
    * 耗尽数据库连接:假设一个应用设定了 10 个数据库连接,那么一个拥有数百台服务器集群的应用就会在数据库上创建数千个连接。 
    * 新增业务困难。在这样一个剪不断、理还乱的系统中新增业务?开玩笑吧O(∩_∩)O~

    所以我们要做拆分,把模块独立部署,降低系统的耦合性: 
    * 纵向拆分 - 把一个大应用拆分为多个小应用。如果新增的业务较为独立,就直接将其设计并部署为一个独立的 Web 应用。 
    * 横向拆分 - 把复用的业务拆分出来,独立部署为分布式服务,新增的业务只需要调用这些分布式的服务,就可以快速搭建出一个应用系统。即使模块内的业务逻辑发生变化,只要保持接口一致,就不会影响其他模块。

    分布式服务架构

    纵向拆分较简单,通过梳理业务,把关联较少的业务剥离,使其成为独立的 Web 应用。而横向拆分不仅需要识别出可复用的业务、设计服务接口以及规范服务之间的依赖关系,而且还需要一个完善的分布式服务管理框架。

    2.1 Web Service 分布式服务

    Web Service 曾经是企业应用系统在开发领域中最时髦的词汇之一,它用于整合异构系统以及构建分布式系统:

    Web Service 原理

    服务提供者通过 WSDL(Web Services Description Language,Web 服务描述语言)向注册中心(Service Broker)描述自身所能提供的服务接口内容,然后注册中心使用 UDDI(Universal Description, Discovery, and Integration,统一描述、发现和集成)发布服务提供者提供的服务。服务请求者从注册中心检索到服务后,通过 SOAP(Simple Object Access Protocol ,简单对象访问协议)与服务提供者通信,使用该服务。

    Web Service 虽然有成熟的技术规范和实现,但有如下缺点: 
    1. 臃肿的注册、发现机制。 
    2. 低效的 XML 序列化手段。 
    3. 开销较高的 HTTP 远程通信。 
    4. 复杂的部署与维护手段。

    这些问题导致 Web Service 难以满足大型网站对高性能、高可用、易部署与易维护的要求。

    2.2 大型网站分布式服务的要求

    分布式服务框架需要能够支持以下特性: 
    * 负载均衡 - 对于服务请求者能够使用可配置的负载均衡算法来访问热门服务(比如登录或商品服务,这些服务被部署在一个集群上)。 
    *失效转移 - 可复用的服务被多个应用调用,一旦服务不可用,就会影响到很多应用的可用性。所以即使是很少访问的服务,也需要集群部署。分布式服务框架检测到某个服务不可用时,就会切换到其他服务实例上,保证整体高可用。 
    * 高效的远程通信 
    * 整合异构系统 
    * 对应用最小侵入 - 分布式服务框架支持服务(服务模块需要即支持集中式部署,也支持分布式部署)的渐进式演化和反复。 
    * 版本管理 - 网站服务不可中断,所以分布式服务框架需要支持服务的多版本发布,服务提供者升级发布接口新版本的同时,还会继续支持旧版本的服务,直到请求者调用的接口升级后,才会关闭旧版本的服务。 
    * 实时监控 - 监控服务提供者和调用者的各项指标,提供运维与运营的支持。

    2.3 分布式服务框架设计

    大型网站需要更简单、更高效的分布式服务框架构建其 SOA(Service Oriented Architecture ,面向服务的体系结构)。目前国内有较多成功实施案例的开源分布式服务框架是阿里巴巴的 Dubbo。

    Dubbo 架构

    服务消费者通过接口使用服务,接口通过代理加载具体服务,可以是本地的代码,也可以是远程的服务,因此对应用侵入较小。

    客户端模块通过服务注册中心加载服务提供者列表(服务提供者启动后自动向服务注册中心注册自己可以提供的服务接口列表),然后根据配置的负载均衡策略把服务调用请求发送到某台服务提供者的服务器。如果服务调用失败,客户端模块会自动从服务提供者列表中选择一个可以提供同样服务的服务器重新请求,即自动失效转移,保证服务的高可用。

    Dubbo 使用 NIO 通信框架,因此具有较高的网络通信性能。

    4 可扩展的数据结构

    使用 NoSQL 数据库(如 Cassandra)的 ColumnFamily (列族)技术可以做到可扩展的数据结构设计。它是一种面向列族的稀疏矩阵的存储格式。

    只需要指定 ColumnFamily 的名字,即可创建表。字段可以在写入数据时再指定,通过这种方式,一张表可以包含数百万个字段。这就使得应用的数据结构可以随意扩展。只需要指定任意字段名称和值即可查询。

    5 利用开放平台建立生态圈

    用户只有得到他们想要价值,才会愿意使用网站的服务,这样的网站才有存在的意义。但一个网站毕竟不能满足所有用户的需求。

    用户不会为网站提供的价值买单,所以网站必须提供更多的增值服务才能赚钱。根据长尾效应,增值服务的数量越大,种类越多,盈利也就越多。但一个网站能够自己开发的增值服务也是有限的。

    大型网站为了更好地服务用户、为他们开发出更多的增值服务,会把网站内部的服务封装成接口开放出去,供外部第三方开发者使用,这个平台就叫做开放平台。第三方开发者利用这些开放的接口就可以开发应用程序(如 APP)或网站,为用户提供更多的价值。网站、用户、第三方开发者 
    相互依赖,形成一个生态圈。

    开放平台是网站内部和外部交互的接口。外部会面对众多的第三方开发者,内部面对的是网站内众多的业务服务。下面是开放平台的架构:

    开放平台的架构

    • API 接口:暴露给开发者的一组 API,可以是 RESTful、WebService、RPC 等形式。
    • 协议转换:把各种 API 的输入转换为内部服务可识别的形式,并把内部服务的返回信息封装为 API 格式。
    • 安全:除了身份识别、权限控制等手段之外,还要对访问带宽进行分级限制,保证平台资源被第三方应用合理公平地使用,也能保证网站自身的内部服务不会被外部应用拖垮。
    • 审计:监控第三方应用的访问情况并计费。
    • 路由:把开放平台的各种访问路由映射到具体的内部服务。
    • 流程:把一组松散的服务组织成一个上下文相关的新服务,对外提供接口供开发者使用。
    展开全文
  • 简单的说就是在对现有系统影响最小的情况下,系统功能持续扩展及提升的能力,讲扩展性之前,我先讲下扩展性和伸缩性的区别,因为这两个点经常有人会混淆; 扩展性:指对现有系统影响最小的情况下,系统功能持续...

    前言

    续上节大型网站架构核心要素性能之后,我们今天要讲的是第四个要素:扩展性,什么叫扩展性呢?简单的说就是在对现有系统影响最小的情况下,系统功能可持续扩展及提升的能力,讲扩展性之前,我先讲下扩展性和伸缩性的区别,因为这两个点经常有人会混淆;

    扩展性:指对现有系统影响最小的情况下,系统功能可持续扩展或提升的能力,表现在系统基础设施稳定,不需要经常变更,应用之间较少依赖和耦合,对需求变更可以快速敏捷响应。它是系统设计层面的开闭原则(对扩展开放,对修改关闭),架构设计考虑未来功能扩展,当系统增加新功能时,不需要对现有系统的结构和代码进行修改;

    伸缩性:指系统能够通过增加或者减少自身资源规模的方式来增强或者减小自己计算处理事务的能力,如果这种增减是成比例的,那就称作线性伸缩性。在网站架构中,通常指利用集群的方式增加服务器数量、提高系统的整体事务吞吐能力。

    搞清楚扩展性和伸缩性之间的区别之后,那么我们就从下面这几个方面开始讲如何构建可扩展性的架构设计:构建可扩展的网站架构、利用分布式消息队列降低系统耦合性、利用分布式服务打造可复用的业务平台、可扩展的数据结构、利用开放平台建设网站生态圈

     

    构建可扩展的网站架构

    开发低耦合系统是软件设计的终极目标之一,低耦合的系统更容易扩展,低耦合的模块更容易复用,一个低耦合的系统设计也会让开发过程和维护变得更加轻松和容易管理。那么如何分解系统的各个模块,如何定义各个模块的接口、如何复用组合不同的模块构成一个完整系统就成了软件设计中最有挑战的工作;

    设计网站的可扩展性架构的核心思想在于模块化,并在此基础之上,降低模块间的耦合性,提高模块的复用性;上节我们讲到网站通过分层和分割的方式进行架构伸缩,分层和分割也是模块化设计的主要手段,利用分层和分割的方式将软件分为若干个低耦合的独立化组件,这些组件模块以消息传递及依赖调用的方式聚合成一个完整的系统。

    在大型网站中这些模块通过分布式部署的方式,独立的模块部署在独立的服务器(集群)上,从物理上分离模块之间的耦合关系,进一步降低耦合性提高复用性;模块分布式部署以后具体聚合方式主要有分布式消息和分布式服务

     

    利用分布式消息队列降低系统耦合性

    如果模块之间不存在直接调用,那么新增的模块或者修改的模块就对其他模块影响最小,这样系统的可扩展性就会好些;

    • 事件驱动架构:通过在低耦合的模块之间传输事件消息,以保持模块的松散耦合,并借助事件消息的通信完成模块间合作,典型的事件驱动就是生产者消费者模式,在大型网站架构中,具体的实现方式很多,典型的就是分布式消息队列

      消息队列利用发布-订阅模式工作,消息发送者发布消息,一个或者多个消息接收者订阅消息。消息发送者是消息源,在对消息进行处理后将消息发送至分布式消息队列,消息接收者从队列中获取消息进行处理。整个过程中,消息发送者和消息消费者之间没有直接耦合,消息发送者将消息发送给消息队列之后就结束了对消息的处理,而消息接收者只需要从队列去获取消息进行处理就可以,不需要知道消息从何而来,由谁生产。对新增业务,如果需要调用消息,只需要订阅该消息,对原有系统和业务没有任何影响,从而实现了网站业务的可扩展性;

      消息接收者在对此消息进行过滤、处理、包装后,可以构成一个新的消息,继续发送出去,等待其他消息接收者订阅处理该消息;因此基于事件驱动的业务架构可以是一系列流程;

      事件驱动设计优势:由于消息发送者不需要等待消息接收者处理数据就可以直接返回,系统具有更好的响应延迟;同时在网站访问高峰的时候,消息可以暂时存储在消息队列里面,等待接收者根据自身负载处理能力控制消息处理速度,减轻数据库等后端存储的负载压力。

    • 分布式消息队列:队列是一种先进先出的数据结构,之前我们也讲过这点,分布式消息队列可以看作将这种数据结构部署到独立服务器上,应用程序可以通过远程访问接口使用分布式消息队列,进行消息存取操作,进而实现分布式的异步调用,基本原理如下图:

      消息生产者通过远程访问接口将消息推送给消息队列服务器,消息队列服务器将消息写入本地内存队列后立即返回成功响应给消息生产者。消息队列服务器根据消息订阅列表查找订阅该消息的消息消费者应用程序,将消息队列中的消息按先进先出的原则通过远程通信接口发送给消息消费者程序。

      目前开源的分布式消息队列有很多,比如RocketMQ,kafka等等,这些产品除了实现分布式消息队列的一般功能,在可用性,伸缩性,数据一致性,性能和可管理性方面也做了很大改善。

      伸缩性:由于消息队列服务器上的数据可以看作是被即时处理的,因此类似于无状态的服务器,伸缩性设计比较简单,将新服务器加入分布式消息队列集群中,通知生产者服务器更改消息队列服务器列表即可;

      可用性:为了避免消费者进程缓慢,分布式消息队列服务器内存空间不足造成的问题,如果内存队列满了,就会将消息写入磁盘,消息推送模块在将内存队列消息处理完以后,将磁盘内容加载到内存队列继续处理;

      防消息丢失:为了避免消息队列服务器宕机造成消息丢失,会将消息成功发送到消息队列的消息存储在消息生产者服务器上,等消息真正被消费者处理之后才删除消息,在消息队列服务器宕机时,生产者服务器会选择分布式消息队列服务器集群中其他的服务器发布消息;

      分布式消息队列可以很复杂,例如企业总线ESB或者面向服务架构SOA;也可以很简单,例如我们就用MySQL来当做分布式消息队列,生产者将消息存入数据库,消费者按生成时间从数据库取消息消费,这就实现了一个简单的分布式消息队列,而且还有结合MySQL的主从,读写分离手段达到较高的可用性和性能指标。

     

    利用分布式服务打造可复用的业务平台

    使用分布式服务是降低系统耦合性的另一个手段,如果说分布式消息队列通过消息对象分解系统耦合性,不同子系统处理同一个消息;那么分布式服务则是通过接口分解系统耦合性,不同子系统通过相同的接口进行服务器调用。

    随着网站由小变大,表现为整个网站单一应用系统逐步膨胀发展的过程,在这个过程中,网站功能业务日益复杂,整个应该系统逐渐变成一个错综复杂的大系统,如果不使用分布式服务来解耦的话就会带来如下问题:编译部署困难;代码分支管理困难;数据库连接耗尽;新增业务困难。

    解决上述的问题方案就是拆分,将模块独立部署,降低系统耦合性。拆分又分为横向拆分和纵向拆分;

    横向拆分:将复用业务拆分出来,独立部署为分布式服务,新增业务只需要调用这些分布式业务,不需要依赖具体的模块代码,即可快速搭建一个应用系统,而模块内部业务逻辑变化时,只要接口保持一致就不会影响业务程序和其他模块。

    纵向拆分:将一个大应用拆分为多个小应用,如果新增业务较为独立,那就直接将其设计部署为一个独立的web应用系统。

    纵向拆分相对比较简单,通过梳理业务,将较少相关的业务剥离,使其成为独立的web应用,而横向拆分,不但需要识别可复用的业务,设计服务接口,规范服务依赖关系,还需要一个完善的分布式管理框架。

    • 大型网站分布式服务的需求与特点

      • 服务注册与发现:基本上现在都是基于zk来实现的

      • 服务调用:通过SOAP协议实现

      • 负载均衡:对热门服务,需要部署在一个集群上,分布式服务框架要能够支持服务请求者使用可配置的负载均衡算法访问服务,使服务提供者集群实现负载均衡

      • 失效转移:分布式服务框架支持服务者提供的失效转移机制,当某个服务实例不可用,就将访问切换到其他服务实例上,以实现服务整体高可用

      • 高效远程通信:对于大型网站,核心服务每天的调用次数达到数以亿计,如果没有高效的远程通信手段,服务调用就会成为整个系统性能的瓶颈

      • 整合异构系统:由于网站可能会使用不同的语言开发部署在不同的平台上,所以分布式服务框架需要整合这些异构系统

      • 对应用最少侵入:网站技术是为业务服务的,是否使用分布式服务需要根据业务发展规划,分布式服务也需要渐进式的演变,甚至出现反复,即使用了分布式服务后又退回到集中式部署,分布式服务框架需要支持这种渐进式演变和反复,当然服务模块本身也需要支持可集中式部署,也可分布式部署

      • 版本管理:分布式服务框架支持服务多版本发布,服务提供者先升级接口发布新版本服务,并同时提供旧版本的服务供请求者调用,当请求者调用接口升级后才可以关闭旧版本服务

      • 实时监控:没有监控的服务是不可能实现高可用的,分布式服务框架还需要监控服务提供者和调用者的各项指标

    • 分布式服务框架设计:大型网站需要更简单更高效的分布式服务框架构建其SOA,这里以阿里巴巴的Dubbo为例,分析其架构设计,如下图所示:

      流程分析

      服务消费者程序通过服务接口使用服务,而服务接口通过代理加载具体服务,具体服务可以是本地的代码模块,也可以是远程的服务,因此对应用侵入较少(应用程序只需要调用服务接口,服务框架根据配置自动调用本地或者远程实现);

      服务框架客户端模块通过服务注册中心加载服务提供者列表(服务提供者启动后自动向服务注册中心注册自己可提供的服务接口列表),查找需要的服务接口,并根据配置的负载均衡策略将服务调用请求发送到某台服务提供者服务器。如果服务调用失败,客户端模块会自动从服务者列表选择一个可提供同样服务的另一台服务器重新请求服务,实现服务的自动失效转移,保证服务高可用;

      Dubbo的远程服务通信模块支持多种通信协议和数据序列化协议,使用NIO通信框架具有更高的网络通信性能。

     

    可扩展的数据结构

    传统的关系数据库为了保证关系运算(SQL)的正确性,在设计数据库表结构的时候,就需要指定表的schema-字段名称,数据类型等,并要遵循特定的设计范式,这些规范带来的一个问题就是僵硬的数据结构难以面对需求变更带来的挑战,有些应用系统设计者通过预先设计一些冗余字段来应对,但是显然这是很糟糕的设计,难以做到扩展,那么有没有更好的方案呢,无需修改表结构就可以新增字段呢?很多NoSQL数据库使用ColumnFamily(列族)设计就是一种解决方案,这是一种面向列族的稀疏矩阵存储格式,使用ColumnFamily结构的NoSQL数据库,创建表的时候,只需要指定ColumnFamily的名字,无需指定字段(Column),可以在数据写入时在指定,通过这种方式数据表可以包含数百万的字段,使得应用程序的数据结构可以随意扩展,而在查询时,可以通过指定任意字段名称和值进行查询。

     

    利用开放平台建设网站生态圈

    大型网站为了更好的服务自己的用户,开发更多的增值服务,会把网站的服务封装成一些调用接口开放出去,提供开发接入文档,供外部的第三方开发者使用,这个提供开放接口的平台称为开放平台。第三方开发者利用这些开放的接口开发应用程序或者网站,为更多的用户提供价值。网站、用户、第三方开发者互相依赖,形成一个网站的生态圈,既为用户提供更多的价值,也提高了网站和第三方开发者的竞争力和盈利能力。

    开放平台是网站内部和外部交互的接口,外部需要面对众多的第三方开发者,内部需要面对网站内许多的业务服务。开放平台的架构设计大同小异,如下图所示:

     

                         

    API接口:开放平台暴露给开发者使用的一组API,其形式可以是restful,RPC等各种形式;

    协议转换:将各种API输入转换成内部服务可以识别的形式,并将内部服务的返回封装成API的格式;

    安全:除了一般应用需要的身份识别,权限控制等安全手段,开放平台还需要分级的访问带宽限制,保证平台资源被第三方应用公平合理使用,也保护网站内部服务不会被外部应用拖垮;

    审计:记录第三方应用的访问情况,并进行监控。计费等;

    路由:将开放平台的各种访问路由映射到具体的内部服务;

    流程:将一组离散的服务组织成一个上下文相关的新服务,隐藏服务细节,提供统一接口供开发者调用。

    展开全文
  • 比特币成功的秘诀绝不在于它的运算效率或资源消耗方面的可扩展性 。高薪聘请专家来设计专门用于挖矿的比特币硬件,其实仅仅是为了实现单一功能——重复解开一个特定的、被故意设计得非常难的计算难题。这个难题就被...

    介绍

    当下,区块链风头正盛。比特币是其中最大、运行时间最长的区块链。直到今天,在它迄今为止的八年发展史中,比特币从 10,000 个币买一块披萨的价值(在交易所用传统货币给比特币定价之前)上涨到每个比特币值 1,000 美元以上。在撰写本文时,比特币的市值已超过 160 亿美元。比特币连续运行八年,链上几乎没有经济损失,现在已经成为世界上一些重要领域最可靠和最安全的金融网络。

    比特币成功的秘诀绝不在于它的运算效率或资源消耗方面的可扩展性。高薪聘请专家来设计专门用于挖矿的比特币硬件,其实仅仅是为了实现单一功能——重复解开一个特定的、被故意设计得非常难的计算难题。这个难题就被称为工作量证明,因为这个计算难题得到的答案仅仅是一个计算机确实做了大量计算工作的证明。像这样的比特币解题硬件可能要消耗总计 500 兆瓦以上的电力,而这并不是比特币会令工程师或实业家感到无语的唯一特性

    每台运行比特币软件的计算机并不是将协议信息尽可能减少,而是使用大量重复的 Inventory vector 消息淹没互联网,以确保其他的比特币节点能尽可能准确地接收到所有消息。这样设计的结果就是,比特币网络每秒能够处理的交易数根本不可能和传统支付网络(如 PayPal 或 Visa )那样相提并论。比特币伤害了那些追求资源利用最大化和性能极致的工程师和实业家的感情。

    相反,比特币成功的秘诀在于:用大量的资源消耗和差劲的计算扩展性来换取更有价值的东西——社会扩展性。社会扩展性是指制度(一种人们可以反复参与,以习俗、规则或者其他方式约束或激励参与者行为为特点的协作关系或共同努力)上的一种能力,看这个制度能多大程度地克服人类思维的限制,以及制度在激励或约束方面的不足,这种不足体现为制度能限制什么人参与或激励多少人成功参与。

    社会扩展性是指随着组织参与者的多样性和数量增长,参与者能够在何种程度上、以何种方式来考虑行动、响应制度并处理与其他参与者的关系。这里主要是关于人的局限性的讨论,不涉及技术限制或物理资源的限制。

    有一些独立的工程学科,比如计算机科学,用于评估技术本身的物理限制,包括用技术处理更多的用户或达到更高的使用率所需的资源容量。除了与社会扩展性作比较以外,这些工程可扩展性考虑并不是本文的主题。

    社会扩展性是指认知局限和思维差异导致的行为倾向,并不是指机器的物理资源限制,这点很重要,而事实上更重要的是思考和讨论有助于制度发展的社会拓展性的技术。制度技术的社会拓展性取决于该技术如何限制或激励在该制度的参与行为,包括保护参与者和制度本身免受不良参与或攻击。判断制度技术社会拓展性的其中一种方法是计算能从参与该制度行为中获益的人数。

    -认知能力(从物种大脑皮层的相对大小来说)限制了灵长类动物群体的大小。维系动物或人类亲密的群体关系需要大量的情感沟通和关系投资,比如人与人之间见面前的着装打扮、闲聊八卦、开玩笑、讲故事以及其他传统形式的谈话、歌会和唱戏等等。想要打破什么人或多少人可以形成一个制度的人类认知限制(著名的150人左右的“丹巴数”),需要制度和技术创新 [1]。-

    社会拓展性的创新包括制度和技术的改进,将功能从思想转移到书面上或思想转移到机器上,降低认知成本,同时增加思维流动的信息价值,减少安全漏洞,寻找和发现新的互惠参与者。

    阿尔弗雷德·诺思·怀特黑德 [2] 说过:“有一个完全错误的、书中经常重复的、名人在发表演讲时也时常提到的普遍误解: 我们应该培养思考的习惯,多思考我们正在做的事情。而事实却恰恰相反,文明的演进往往是从重大活动的量变中产生的质变,而这些重大活动是我们可以直接执行不需要经过思考的。”

    哈耶克补充道:“我们不断运用我们并不真正理解的公式、符号和规则,通过这些知识的使用,我们获得了知识的帮助,而这些知识本身并不为我们拥有。我们通过在一些已经在自己的领域被证明是正确的、反过来又成为我们所建立的文明基础的习俗和制度之上,发展这些实践和制度。”

    各种各样的创新降低了我们对于参与者、中介和外部人员的隐忧,也因此降低了我们的对他们的关注的必要性,不需要我们以有限的认知能力去担心越来越多的、越来越多样化的人的行为。

    另一类的创新可以促进越来越多的、越来越多样化的参与者之间准确地收集和传递有价值的信息。还有其他的创新也使更多的互利参与者能够发现彼此。

    在人类史前和整个历史进程中,所有这些创新都提高了社会拓展性,甚至可以说这种效果非常明显,使得我们人口庞大的现代文明成为可能。现代信息技术(IT),特别是近代计算机科学的发现,往往可以发现更多互惠的匹配,可以提高信息质量的动机,并且可以减少某些类型的机构交易中对信任的需求,对于数量和种类越来越多的人来说,这些技术和发现以非常重要的方式进一步提高了社会拓展性

    在思维间的流动的信息(也就是我所说的主体间协议 [3])包括口头和书面文字、习俗(传统)、法律内容(规则,习俗和先例)、其他因素(例如在网络评级系统中很常见的“星级”排名)以及市场价格等等。

    信任成本最小化降低了参与者对彼此、对外部人士和中介机构有害行为的漏洞。大多数经历了漫长的文化演变的制度,比如法律(降低暴力、盗窃和欺诈的漏洞)以及安全技术,总体而言,与这些组织和技术演变之前的脆弱性相比,信任在多方面降低了脆弱性。因此,与我们在这些制度和技术发展之前的漏洞相比,我们需要相信我们的人类同胞。

    在大多数情况下,一个可以被信任并且足够值得信赖的机构(比如市场)依赖于其参与者对另一个足够值得信赖的机构(如合同法)的信任(通常是隐性的)。 这些可信赖的机构会反过来实施传统上的会计、法律、安全或其他控制措施,使其更实时、更充分地被信赖,至少通过最大限度地减少其参与者(例如会计师、律师、监管人员和调查人员)的漏洞来促进客户机构的功能。创新只能部分消除某些漏洞,即减少对其他人的信任需求或风险。当然,世界上不存在任何一个完全无需信任的制度或者技术

    即使我们有最强大的安全技术——加密技术,完全无需信任的制度还是不存在的。尽管一些密码协议确实保证了某些特定的数据关系,能以高概率对抗具有极高计算能力的对手,但在考虑到所有参与者的所有可能行为时,密码协议也不能提供绝对的保证。例如,加密技术虽然可以强有力地保护电子邮件免受第三方的直接窃取,但发件人仍然需要信任收件人,他不会直接或间接地将该电子邮件的内容转发出去,或者泄露给任何不应该知道的第三方。

    又如,在我们最强有力的共识协议中,参与者或中间人的某些低于 100% 危害(通过计算能力、利益或个性化和计数来衡量)的行为可能会破坏参与者之间事务或信息流的完整性,从而在总体上损害参与者。近代计算机科学取得的突破,的确可以减少漏洞,且往往效果显著,但这些技术进展远做不到消除一切潜在的漏洞。

    撮合可以促进互利参与者间的相互发现。这可能是互联网最擅长的一种社会扩展性。像 Usenet News,Facebook 和 Twitter 这样的社会网络可以帮助人们发现志同道合的伙伴,互娱互乐,或者保持联系(甚至可能找到未来的配偶!)。在社会网络为人们提供更快发现彼此的可能性之后,接着便可促进不同层次的人际关系投资,人类访问社会网络的频率会从一开始的随便看看转变到频繁访问,最后痴迷其中。克里斯托弗艾伦等人 [4] 对网络游戏和相关社会网络中互动群体的大小和时间进行了有趣而详细的分析。

    eBay,Uber,AirBnB 和在线金融交易所通过交易撮合的大幅增加,带来了社会拓展性:搜索、寻找、汇集和促进互惠商业或零售交易的协商谈判。这些相关服务还有助于促进支付和运输等业务,以及对陌生人在这些交易中承担的其他义务是否已经履行的验证和就此交易的完成质量进行的充分沟通(如“星级评分”系统,Yelp 评论等)。

    互联网对社会拓展性的贡献是撮合,而区块链对社会拓展性的主要贡献在于信任成本的最小化。区块链可以通过锁定一些重要业务(如货币的创建和支付)和重要信息流的完整性(integrity)来降低风险,未来可能减少一些重要撮合功能的完整性(integrity)问题。对私有计算中秘密又任意可变的过程的信任,可以被对基本不可变的公共计算的可验证的信心替代。本文将重点讨论这样的风险降低以及它对有益于广泛潜在对手方的标准交易工具的促进好处,这种工具叫做信任最小化货币。

    货币与市场

    货币和市场通过将互利的买方与卖方相撮合及使用普遍接受的标准化对偿(即货币)方式,使每一项特定交易的参与者都能直接受益。这里的市场指的是亚当·斯密所用的概念:不是作为买卖双方聚集在一起的特定场所或服务(尽管有时可能涉及这些),而是以成对交换为代表的对制造产品的供应链进行协调的活动。

    货币和市场也会激励更准确的价格信号生成,从而降低参与者在其他交换方式中所需的谈判成本、减少失误。可以说,货币与市场的有效结合,使得数量和种类远多的参与者可以有效地协调他们的经济活动,而不像以前依赖的交换机制,它们和竞争性市场相比更类似于双边垄断。

    市场和货币的特点包括交易撮合(把买卖双方带到一起)、降低信任成本(相信利己的动机而不是依赖陌生人的利他动机)、可随参与者数量扩展的执行过程(通过货币,一种广泛接受且可反复用于偿付的媒介) 以及质量信息流(市场价格)

    讨论关于货币和市场最早的思想家是亚当·斯密。在英国工业革命爆发之初,亚当·斯密在“国富论”中指出,即使是最简单的产品,也直接或间接地依赖于大量人的劳动:

    观察一个文明繁荣的国家中最普通的技工或日工的生活用品,你会发现,与日用品生产相关的那些工业(虽然只是一小部分)雇佣来参与生产的人数,多得不可胜数。例如,日班工人穿着的看上去极其粗糙的羊毛外套,却是大量工人的共同劳动的成果。

    牧羊人、拣毛人、梳毛人、染色工、梳理工、纺工、织工、漂白工、缝纫工和许许多多其他的人,需要综合他们不同的手艺才能完成这种很常见的家用产品。除此之外,将原材料在这些住得相隔甚远的工人们间来回运输,需要雇佣多少商人和承运人! 更有甚者,将染色工需要的不同染料(这些染料往往来自世界各地)运输到一个地方,需要多少商业和航运业、多少船工、水手、制帆人、制绳人! 为了生产这些工人所使用的最普通的工具,又需要多少劳动!

    暂且不论像水手工作的船只、漂白工用的水车、织工用的织机这些复杂的器械,只来讨论像牧羊人剪毛时所用的大剪刀这种非常简单的工具,我们又需要多少复杂的劳动才能做成这样的剪刀:必须综合矿工、熔矿炉建造工、伐木工、烧炭工、制砖工、砌砖工、熔炉工、技工、铁匠等等不同角色的工艺才能生产出来。

    同样,要是我们考察一个劳动者的服装和家庭用具,如贴身穿的粗麻衬衣,脚上穿的鞋子,睡觉用的床铺和床铺上的各种寝具,做饭的炉子,由地下采掘出来而且也许需要经过水陆运输才能送到他手边供他烧饭的煤炭,厨房中一切其他用具,餐桌上的一切用具,刀子和叉子,盛放食物和分取食物的陶制和锡蜡制器皿,做面包和酿酒的工人,那种可以散热、透光并能遮蔽风雨的玻璃窗,和那些使北方也能成为极舒适的居住地的发明,这些发明所必须借助的一切知识和技术,以及工人制造这些发明所用的各种工具等等。

    总之,我们如果认真想想这一切东西,考虑一下投在这每样东西上的各种劳动,我们就会发现:一个文明国家里最普通的人想要按照他最普通的(就根据我们所能想象到的简单到不能再简单的)生活方式取得其日用品的供给,如果没有成千上万的人的协作几乎是不可能的。

    这些都发生在 1776 年后发生的一系列工业革命和全球化浪潮出现之前,到今天劳动分工已被多次重新定义、复杂化和扩大了许多倍。与其相信陌生人会做出利他的行为,还不如相信市场和货币可以通过创造许许多多互惠合作激励这个由相互并不关心的人构成的大型网络作出有益于我们的行动:

    在文明社会中,人类随时都需要大量同类的合作和帮助,然而其一生却短暂到只能和少数人建立友谊… 相比起其他动物,人类更会经常遇到需要同胞帮助的情况,然而只期待着别人施恩是不行的。交换这种行为能让我们从其他人那里获得远远更好的所需物品。我们所需的饮食,不是出于屠户、酿酒师或面包师的恩惠,而是出于他们对自身利益的打算。

    斯密继续描述劳动分工以及劳动生产率是在何种程度上,依赖配对交换的网络:“正是因为交换导致了劳动分工,所以分工的程度必然受到交换能力的限制,换句话说,分工受市场的制约。”随着一个国家和全球的交换网络的壮大,越来越多的生产者参与其中,从而提高 了劳动分工和劳动生产率。

    货币则通过增加这种交换的机会来促进社会拓展性。作为被广泛接受的可反复使用的财富存储及转移媒介,货币通过减少交易中的耦合问题(物物交换中买卖双方的双重需求耦合,以及单方转账的需求供给耦合)降低了交易成本,使得交换的商品和服务种类越来越多,涉及的参与者也越来越多样化。

    各种各样的媒介,包括口语、粘土 [5]、纸张、电报、无线电和计算机网络等都曾经被用来传达报价、承诺、实际产生的交易和价格,以及对执行的监督和其他商业沟通内容。对于市场和货币形成的价格网络最有见解的观点之一,在弗里德里希·哈耶克的文章《知识在社会中的运用》 [6] 中出现过:

    在一个相关事实的知识分散在许多人手中的体系里,价格机制能协调不同个体的独立行为……在任何一个多人协作社会中,这种规划,无论是谁做的,它首先以知识为基础,这种知识不是先给规划者的而是给其他人的,其他人再通过某种方式传达给规划者。

    对于任何解释经济过程的理论来说,人们将作为计划基础的知识传达给各方的方式都是至关重要的问题,至于最初分散在所有人中的知识的最佳利用方式是什么的问题,至少是经济政策,或者说是设计高效的经济体系的主要问题之一

    任何商品都只有一个价格(或更确切地说,各地的价格是相互关联的,其差别取决于运输费用等等)这个事实,使得一个掌握所有信息的计划者(仅仅是概念上有可能)也许也能做出回答,但实际上信息分散在与过程相关的所有人手中…

    神奇的是,在诸如某种原料短缺的情况中,无需发出任何指令,也没有多少人知道其中原因,成千上万的人(他们的身份花几个月时间也无法调查清楚)会自发地开始节约用料或找其他替代产品;也就是说,人们会做出正确的选择…

    价格体系正是一种人类偶然发现而且尚未理解的制度(虽然人类还远远没有学会充分利用它)。价格体系不但使劳动分工也使在知识均匀分布基础上的资源协调利用成为可能……方案在只掌握部分信息的人的交互协作中产生。

    (编者注:台湾的夏道平先生将哈耶克此文题译为《散在社会的知识之利用》,“散在”一词,窃以为更切合哈耶克论文主旨。)

    网络安全的社会可扩展性

    很久以前我们仍处于陶器时代,后来进入了纸质时代,而如今我们通过计算机和数据网络上运行的程序和协议实现了我们大部分的商业交易。虽然这极大地改进了交易撮合和信息流动,它却是以更多的有害行为为代价的。

    随着网络的发展,更多对彼此行为习惯和限制并不了解的人加入进来。以对根的信任为基础实现的安全控制,只适用于类似贝尔实验室这样的小型办公室,他们的同事互相熟识,收入和支出都是通过纸质流程而不是在办公室计算机上执行的电子程序得到充分控制。这样的安全机制在组织机构变得更加庞大,组织边界更错综复杂,以及更有价值更集中的资源(如货币)被委托给计算机管理时,变得不再高效,也不再安全。

    接收陌生人电子邮件越多,越有可能收到网络钓鱼攻击或恶意附件。传统的计算机安全系统并不具备很好的社会扩展性。正如我在《可信任计算的黎明》[7] 中描述的一样:

    当我们在蜂窝网络或互联网上使用智能手机或笔记本电脑时,交互的另一端通常运行在其他独立计算机上,例如网络服务器。 实际上,所有这些机器都具有被设计为由单个人或相互了解信任的层级组织中的人员控制的架构体系。从远程网络或应用程序用户的角度来看,这些架构建立在对未知 “root”管理员完全信任的基础上,他们可以控制服务器上发生的所有事情:

    他们可以任意读取、更改、删除或屏蔽该计算机上的任何数据。即使通过网络加密发送的数据,最终也会被一台受控制的计算机解密和完全掌握。通过连接我们现在完全信任的网络服务(实际上在这样的网络里我们很被动很容易被攻击),计算机(或者某个控制计算机的人)会无条件的执行管理员(可能是内部员工或是黑客)的任何命令和付款等行为。如果有人在另一端企图滤掉或者篡改你的网络指令,没有很好的安全措施可以阻止他们,只有一些不靠谱又昂贵的人为制度,而这些制度往往走不出国家的边界。

    很多服务器对于内部人员或外部人员来说没有足够的攻击价值。但是也有越来越多的服务器因为包含有利用价值的资源而招至频繁攻击。基于信任的中心化安全系统难以扩展。随着计算机控制的资源变得越来越有价值和越来越集中,传统的基于对根的信任的安全机制越来越像现实世界中的“寻求警察的帮助”一样效果差。幸运的是,我们现在有区块链技术,我们可以在大部分重要计算场景中做得更好。

    区块链与加密货币

    可扩展的市场和价格需要可扩展的货币。可扩展的货币需要可扩展的安全性,这样更多的和更多样的人可以使用该货币,同时货币不会失效——不能伪造、 不会通胀、也不会被盗。

    2009 年,以中本聪为名的一个或是一群人将比特币带入了互联网。中本聪在货币上的突破是通过信任成本最小化给人们提供了社会可扩展性:减少交易对手和第三方的问题。通过用计算成本高昂但自动化的安全系统替换了原来的计算成本便宜但制度成本高昂的传统安全系统,中本聪的方法非常好的增加了社会扩展性。一系列只需要部分信任的中间机构取代了原本的单一的需要完全信任的中间机构。

    -打了“计算兴奋剂”的金融控制:区块链就像由机器人组成的军队,互相检查彼此的工作。-

    当我们可以通过计算机科学而不是传统会计师、监管人员、调查人员、警察和律师来保障金融网络的最重要的功能时,我们会趋向于一个自动化、全球化和更安全的系统,而不是人肉的、局限于本地的且不一致的安全系统。加密货币,如果正确的在公链上实现,可以用一大批计算机替代大量传统的银行官僚。

    这些维护区块链的计算机将允许我们把互联协议中最关键的部分放在一个更加可靠和安全的基础上,并使我们以前不敢在全球网络上进行的信托交互成为可能。”[8]

    区块链技术中,尤其是比特币中,最有价值的那些特点,例如:

    • 其运行基本独立于现有机构
    • 可无障碍地跨越国界运行

    来自于区块链可以在没有人工干预的情况下仍保持高水准的安全性和可靠性。如果没有高安全性,区块链将只是一种资源利用率极低的分布式数据库技术,依然需要本地制度来保证正常运行。

    -自20世纪中期以来,计算机的效率提高了好几个数量级,但人类的大脑并没有多少变化 。新的计算能力为突破人类的极限创造了许多可能性,而随着人类思维发挥到了极致,基于人类心智设计的制度也已经发挥到了极致。结果就是,人类没有剩余的能力来提升我们现有的制度了。-

    但如果我们用计算机直接代替一些现在是人类发挥作用的地方,社会扩展性依然有很大的改进空间。(重要提示:这个结论取决于上图中斜线的斜率,而不是人类能力线的绝对位置。上面显示的能力线位置是任意的,这取决于我们对人类能力的估算)。

    一个新的中心化金融实体,一个需要信任的第三方,如果不像传统金融机构那样拥有等效于“人工区块链”的制度,会存在成为下一个 Mt. Gox 的极大风险。如果没有官僚制度,它无法成为一个值得信赖的金融中介。

    计算机和网络是很便宜的。扩展计算能力需要的额外资源也很便宜。要想以可靠和安全的方式扩大人类传统制度的协作范围,需要越来越多的会计师、律师、监管人员和警察,随之也给这些制度带来更多的官僚作风、风险和压力。律师费用高昂,监管更是镜花水月。而计算机科学在保障货币安全方面可以比会计师、警察和律师做的好得多。

    在计算机科学中,安全性与性能之间存在根本的权衡。比特币的全自动可靠性源自其运行和资源使用带来的高成本。没有人找到了什么方法可以大幅提高比特币区块链的计算可扩展性,例如它的交易吞吐量,并且保证这种改进不会影响比特币的安全性。

    对于比特币来说,很可能不存在在保持可靠性的同时大幅提高性能的方法,这也许是无法避免的一种权衡。与现有的金融信息技术比较,中本聪做出了有利于安全但不利于性能的一些重要权衡。看似浪费资源的挖矿过程是这些权衡中最为明显的一个,但这不是比特币做出的唯一权衡

    另外一个权衡是它在消息传递中的高度冗余。数学上可证明的可靠性需要将消息在所有节点之间全面广播。比特币无法实现这一点,但即使是实现近似的效果也需要高水平的冗余。 因此,1 MB 的区块消耗的资源远比 1 MB 网页消耗的多,因为它的传输、处理和存储需要更高的冗余度,以实现比特币的自动可靠性。

    这些必要的权衡,即以牺牲性能来实现足以支撑独立运作、无间断全球化和自动化可靠性所必需的安全性,意味着比特币区块链是不可能接近 Visa 的每秒交易次数,同时保持自动可靠性的,而后者为它带来了相对传统金融系统的独特优势。

    相反,我们更需要一个对信任最小化程度相对更低的外围支付网络(如 Lightning [9])来承担大量低价值的以比特币为面值单位的交易,使比特币区块链只需要定期对具有高价值的外围网络交易进行成批的结算。

    虽然比特币支持的交易吞吐量比 Visa 或 PayPal 都低,但它更强的自动化安全性比交易吞吐量更重要。任何满足互联网接入条件并拥有智能手机的人都可以支付 0.20-2 美元的交易费(这远低于当前的汇率手续费)然后在全球的任何地方使用比特币服务。而低费用低价值的交易可以在比特币外围网络上处理。

    当涉及到小写 b 的 bitcoin,也就是把它当作货币时,你可以像使用法定货币一样用比特币去为商品买单,比如使用以比特币计价的信用卡和借记卡,享受和银行信用卡或借记卡一样的秒级交易和请求退款 [10] 功能。

    我在设计 Bitgold 的时候,已经认识到共识无法在保证安全的情况下扩展到高吞吐量的场景中去,所以我把它设计成了两层架构:(1)Bitgold 本身,结算层;(2)Chaumian 数字现金,一个拥有高吞吐量和隐私性(通过 Chaumian 盲签名)的零售级支付外围网络,但这个外围网络像 VISA 一样是需要信任的第三方,因此需要由会计师等角色的组成的“人工区块链”来保证可靠性。

    外围支付网络只涉及小额交易,因此只需要很少的保障制度运行的人力,这样可以避免重演 Mt. Gox 的命运。

    货币要求在保证安全性的基础上具有社会可扩展性。例如,货币必须难以被任何使用者或者中间人伪造(使得供给曲线被稀释导致过度的或意想不到的通货膨胀)。黄金在世界上任何地方都具有价值,而且不会受恶性通货膨胀的影响,因为它的价值并不取决于任何一个中央权威机构。比特币在这些方面同样表现突出并且可以运行在网络上,它能让阿尔巴尼亚的某人在不需要信任第三方因此也无需支付半垄断定价的手续费的情况下,安心地向津巴布韦的某人支付比特币。

    现在“区块链”有着各种各样的定义,但几乎所有的定义都是出于营销炒作的目的。我建议给“区块链”一个可以将其内涵传递给外行人的清晰定义。区块链应该既有区块,也有链。链应该是默克尔树或其他具有不可伪造的完整性功能的密码学结构。此外,受区块链保护的交易和其他数据应该用合理的方式复制下来,对最坏情况下的恶意问题和参与者提供尽可能高的容忍度(一个典型的系统应该可以在有 1/3 到 1/2 的服务器恶意破坏时还能正常运行)。

    -比特币的社会可扩展的安全性是基于计算机科学,而不是警察和律师,所以它允许进行跨国界的支付,例如非洲的客户付款给在中国的供应商。私有区块链难以实现这一壮举,因为它需要可以在这些不同的行政管辖区间中共享的身份验证、数字证书以及公钥基础设施服务。-

    因为这个特点,以及(希望很少)因为可能出现的会导致历史区块无效的软件更新需求(一种叫做硬分叉的危险情况),区块链还是需要一个有政治分裂隐患的人工治理层。最成功的区块链,比特币,一直由有着强烈的数据不可篡改信仰的技术专家们通过去中心化的决策维持着其不可篡改性,这种情况下,只有那些没有任何其他可行方案的最重要和罕见的错误修复和设计改进,可以使用硬分叉。

    在这种治理哲学下,会计或法律上的决定(例如更改账户余额或撤销交易)不会是硬分叉的理由,它们应由系统外(或系统上层)的传统治理机制来完成(例如通过法院禁令迫使比特币用户发送一个新的交易,在效果上撤销旧交易,或没收特定的密钥,从而没收特定用户的特定权限)。

    数据是不可伪造且不可变的,意味着它在被提交到区块链后一旦有所篡改一定会被发现。与一些炒作所说的概念相反,我们没有任何办法保证数据上链之前的来源是否真实,或数据本身是真是假。这需要额外的办法,通常包括高成本的传统制度

    区块链不能保证真相;它们只是把真相和谎言都以无法篡改的方式保留下来,允许后来的人客观地分析这些内容,从而更有信心揭露谎言。日常的计算机是一块算力画板;而区块链则是算力琥珀。重要数据应该尽早地封装进区块链琥珀,最好是由生成数据的设备在签名加密后直接提供,使区块链在保证数据可靠性上的优势最大化。

    -一个包含四笔交易的默克尔树(从 tx 0 到 tx 3)。结合适当的复制和由工作量证明保护的形成链表结构的交易区块,默克尔树可以通过共识使如交易之类的数据变的不可伪造。在比特币中,这些数据会安全的汇总成默克尔树的根哈希,以用于验证在区块中所有交易没有被篡改。-

    我在 1998 年提出的“安全财产权”架构就使用了默克尔树和数据复制机制来容忍任意软件错误或恶意行为,但还没有区块的概念。它展示了我的理论,即你可以保护全球性共享数据和交易的完整性,并用它们来设计一个加密货币(Bitgold)。但 Bitgold 不及比特币高效,也没有像比特币那样具有计算扩展性的区块和分类记账系统。而且它和今天的私有区块链一样,以可安全区分和计数的节点为设计前提。

    由于 51% 算力攻击可以影响一些公有链(如比特币、以太坊)的重要安全目标这一客观事实,我们非常关心拥有最多算力的矿工的身份,并希望回答这个问题:有人能说服和协调 51% 算力攻击吗?

    区块链的安全性有其客观极限,且区块链治理会严重受到 51% 攻击的影响。一次攻击当然不会被攻击者称为“攻击”,相反他们可能会称之为“开明治理”,或者“民主行动”。一些用于修复 bug 或是改善协议的软件更新需要软分叉。另外一些软件更新会需要硬分叉,这会给比特币带来比软分叉更大的安全和持续运行风险。

    比起其他网络协议,区块链虽然已经极大的降低了信任要求,但实际上离完全可信仍然遥远。矿工算是被部分信任的守护人,其实还有一些并不是工程专家或计算机科学家但是投入了大量时间学习区块链设计原理和代码的人,他们必须对开发专家社区有充分的信任,就像一名想要理解一门专业学科的研究成果的非专业人士需要对该专业领域的科学家所做的一样。在硬分叉期间,交易所的影响力也是非常大的,因为它们可以决定自己的市场和交易代号支持哪个分叉。

    公共区块链因此可以相对(但并不绝对)地避开身份难题,且通过在更高的现实或社会层面确认算力最大的矿工身份,这可能比试着将身份这样(基于大脑)的天然模糊的概念映射到协议层更合适,PKI(公钥基础设施)在这方面的艰难尝试正是个例子。

    所以我认为有一些“私有区块链”有资格成为真正的区块链; 其他的则应该归类到更宽泛的“分布式账本”或“共享数据库”等类目下。它们的社会扩展性与公共且无需许可的区块链(比特币和以太坊)完全不同。

    以下方案都有安全识别(可区分和可计算)的服务器身份的要求,而非像公共区块链一样允许匿名身份。换句话说,他们需要一些其他的,通常是社会拓展性远远不如的方案来解决女巫攻击问题

    • 私有链;
    • 侧链的“联合”模式(唉,现在没有人弄清楚了如何在需要更少的信任的情况下来做侧链,尽管之前希望的或者说的挺漂亮)。侧链可以是私有链,二者非常匹配,因为它们在架构上和对外部的依赖(例如PKI)上都非常相似;
    • 基于多重签名的方案,即使是通过基于区块链的智能合约完成的;
    • 基于阈值的将链下数据搬到链上的“预言机”。

    识别服务器身份的主流但通常不是特别具有社会可扩展的方式是基于可信认证机构(CAs)的 PKI 体系。 为了避免受信任的第三方变成安全漏洞,可靠的 CAs 自身就必须是高门槛的劳动密集型官僚机构,这些机构通常会自行或是由其他机构来进行广泛的背景调查(例如商业调查公司Dun&Bradstreet)。(我曾经带领团队设计、打造过这样的 CA)。 CA 也充当守门员的角色,保护这些需要许可的系统。 CAs可以被商业斗争控制成为出问题的单点。 “公有区块链是自动化的、安全的、全球化的,但身份认证是劳动密集的、不安全的、本地的。”

    使用 PKI 的私有链对于银行和大型企业来说是一个不错的选择,因为他们已经有成熟的认证重要交易批准所需的员工、合作伙伴和私有服务器的内部 PKI 系统。银行 PKI 相对可靠。我们也为 Web 服务器提供了半可靠的 CAs,但这一般来说不包括 Web 客户端,即使人们在 Web 发明后一直在尝试解决客户端证书问题:例如,广告商们会希望有更安全的可以替代电话号码和 Cookie 来追踪客户身份的方式。但这还没有实现。

    PKI 可以为少数重要的事情和人员很好地工作,但对于不是那么重要的实体来说,它并不那么好或容易使用。它的社会社会拓展性受其所依赖的传统的身份认证官僚机构所限制

    -上图是在更广泛的比特币生态系统中出现的一些重大的盗窃事件。鉴于比特币区块链可能是现有的最安全的金融网络(事实上比特币必须比远比传统支付网络安全,才能保持其低廉的治理成本和无间断跨境转账的能力),围绕它建立的基于旧的中心化网络服务器的周边服务并不安全。(来源:作者)-

    我们需要更具有社会社会扩展性的方法来可靠的统计节点数量,换句话说,需要更健壮的方法来尽可能的抵抗腐败,评估节点对区块链完整性的贡献大小。 这正是工作量证明和广播复制的关键:大幅度牺牲计算扩展性来提高社会扩展性。

    这就是中本聪的天才权衡。它的天才在于认识到人比计算机昂贵得多,且这种差距每年都在扩大。它的天才在于可以让人们跨越人类的信任边界(例如国界)安全不间断地协作,而不是像 VISA 或 Paypal 使用的“呼叫警察”架构,它们依靠的是昂贵的、容易出错的甚至会有腐败问题的官僚机构正常工作时所提供的一定程度的可靠性

    结论

    随着互联网的兴起,各种网络组织如雨后春笋般崛起,包括社会网络、长尾零售商(例如亚马逊)以及允许小型和分散的买家卖家相互做生意的各种服务商(eBay,优步,AirBnB 等)这些只是对我们新能力的最初级尝试。由于近几十年来信息技术的巨大进步,限制网络组织参与人数和类型的已经不再是计算机和网络,而是还没有充分跟上技术进步的人类思维和制度设计。

    这些古典互联网的努力都是非常中心化的。区块链技术,通过计算机科学而不是“呼叫警察”来实现数据完整性,使得迄今为止信任成本最小的货币(加密货币)成为可能,它也必然为其他金融领域以及主要基于在线数据进行交易的场景带来进步。

    这并不意味着,让我们的制度适应我们的新能力是一件容易的事,或在某些特定情况下困难会少一些。乌托邦的想法在区块链社区非常普遍,但它们不是可行的选择。 对我们高度发展的传统制度进行逆向工程,甚至以新形式重塑一些旧制度,通常比从头开始设计、抛出宏大计划和博弈理论要好得多

    Satoshi 向我们展示了这样一种关键策略——牺牲计算的效率和可扩展性(消耗相对便宜的计算资源)以减少为了实现陌生人之间协作所需要的社会制度(例如市场、大公司和政府)中的人力浪费,更好地利用人这种宝贵资源。


    [1]:http://whatsupnah.com/2009/02/twitter-vs-the-dunbar-number-and-the-rise-of-weak-ties/

    [2]:https://en.wikipedia.org/wiki/Alfred_North_Whitehead

    [3]:http://www.fon.hum.uva.nl/rob/Courses/InformationInSpeech/CDROM/Literature/LOTwinterschool2006/szabo.best.vwh.net/tradition.html

    [4]:http://www.lifewithalacrity.com/previous/2005/10/dunbar_group_co.html

    [5]:https://nakamotoinstitute.org/the-playdough-protocols/

    [6]:https://www.econlib.org/library/Essays/hykKnw.html?chapter_num=1#book-reader

    [7]:https://unenumerated.blogspot.com/2014/12/the-dawn-of-trustworthy-computing.html

    [8]:https://unenumerated.blogspot.com/2014/12/the-dawn-of-trustworthy-computing.html

    [9]:https://lightning.network/lightning-network-paper.pdf

    [10]:https://en.wikipedia.org/wiki/Chargeback


    链接: http://unenumerated.blogspot.com/2017/02/money-blockchains-and-social-scalability.html

    展开全文
  • 网站的可扩展性架构设计,能够在对现有系统影响最小的情况下,系统功能可以可持续扩展及提升的能力。在此,对容易混为一谈的 “扩展性” 和 “伸缩性” 的概念进行详细说明:扩展性表现为:基础设施不需要经常变更,...
  • 文章目录代码可扩展性的几种实施方式基于接口的设计插件架构状态机 代码可扩展性的几种实施方式 《ThePragmaticProgrammer》(Addison-Wesley,1999)一书的作者DaveThomas和AndyHunt曾经说过,所有编程工作都是维护...
  • 当前面的准备工作都已经做好,必要的估算和预期也已经准备妥当后,便可以进一步做详细的设计了——通常来说这意味着需要从系统的可扩展性角度来做。 基础! 首先需要了解和scaling相关的一些概念。知道这些...
  • Apache的做法显然是为高优先级连接的处理进程设定一个高的调度优先级,依然是交给调度器去处理…这种方案显然是不可扩展的,因为Apache的可扩展性受制于调度器的可扩展性。   再看Nginx。和Apache不同,Nginx...
  • 可扩展性被视为当代区块链解决方案所面临的最大挑战。可扩展性挑战不仅限制了区块链技术的主流采用,也是区块链安全攻击主要针对之处。我们主观意识上会将区块链的可扩展计算模型看作“第2层”协议或全新的区块链。...
  • 目的是主要是使程序更加模块化和利于扩展,便于以后的开发,节省时间。 1.一个界面上的数据理论上可以由上一个页面传过来,也可以自己发请求获取。不过尽量后者,这样这个界面的控制类就容易移植到别的代码中。耦合...
  • 不同于其他类似主题的图书主要关注当前技术的实现,本书强调,可扩展性不仅仅是个技术问题,它还涉及组织、流程、架构等方方面面。没有一个顺畅的流程、合理的组织结构或能进行沟通的管理者,再好的技术和想法也会大...
  • 摆在我们面前的,是区块链技术发展到现在终会遇到的一个关键瓶颈——区块链(特别是公链)想要真正做到更深度化的应用和普及,关键就是要解决交易的吞吐量和交易的速度问题,这在区块链中也被称作”可扩展性“。...
  • 可扩展型的数据库设计(转)

    千次阅读 2018-07-23 16:19:07
     (3)ext采用可扩展的字符串协议载体,承载被查询的属性   例如,最开始上线的时候,版本为0,此时只有passwd和nick两个属性,那么数据为: 当产品经理需要扩展属性时,新数据将版本变为...
  • 这篇文章是《集群的可扩展性及其分布式体系结构》的第三篇。主要介绍集群的软硬件结构的层次结构模型、主要的分类方法和决定集群设计的四大要素:HA、SSI、作业管理和通信。笔者旨在通过几个不同切入点的分析,构筑...
  • 它的app的主界面设计的比较有意思,可以通过后台进行设置主界面的显示内容,问了些朋友和自己反编译其代码以后,对其有个猜测(因为,我也没源码)。然后,猜测可能是对相关的界面做封装,然后,在通过Json的解析,...
  • 可扩展性一直是以太坊的一大痛点,以太坊 2.0 的升级计划中关于可扩展性的改进占据了半壁江山。在以太坊 2.0 计划面世半年后的今天,可扩展性问题有所好转了么? 本文主要概述现有以太坊可扩展性解决方案以及这些...
  • 聊聊Dubbo - Dubbo可扩展机制实战

    千次阅读 2018-06-04 18:53:12
    今天我想聊聊Dubbo的另一个很棒的特性, 就是它的可扩展性。1. Dubbo的扩展机制在Dubbo的官网上,Dubbo描述自己是一个高性能的RPC框架。今天我想聊聊Dubbo的另一个很棒的特性, 就是它的可扩展性。 如同罗马不是一天...
  • 那么该如何设计元数据管理的架构,才能最大程度地满足可扩展性?本次公开课将重点为大家讲解元数据架构设计的相关内容。第一部分:如何理解元数据这个比较抽象的概念?1、 如何理解元数据?2、 传统元数据与广义元...
  • 可扩展机器学习——Spark分布式处理

    千次阅读 2015-12-01 13:12:59
    注:这是一份学习笔记,记录的是参考文献中的可扩展机器学习的一些内容,英文的PPT可见参考文献的链接。这个只是自己的学习笔记,对原来教程中的内容进行了梳理,有些图也是引用的原来的教程,若内容上有任何错误,...
  • 架构师不可不知的十大可扩展架构

    千次阅读 2015-12-22 13:14:49
    可扩展性正是如今软件设计领域最值得优先考虑的要素。然而,计算机科学家们还无法了解一套单独的架构如何才能扩展至各类应用环境当中。相反,我们在数量繁多的方案中所设计出的可扩展性架构,往往以业界较为通用的...
  • 拥抱变化—— 可扩展性杂谈

    万次阅读 热门讨论 2011-06-13 22:31:00
    拥抱变化—— 可扩展性杂谈 杨小华作为软件开发人员最担心的就是变化,因为一旦变化,意味着自己的开发任务加重, 轻则修改代码,重则修改框架,如果不用做任何修改,则皆大欢喜,
  • 1.如何选中多行相同的内容,...2.在选中多行相同内容的情况下,我们需要继续往每一行后面扩展选中内容,这部分内容是不一样的情况下,可以用ctrl+shift+右键,如下图: 一开始选中多行的内容是"IF NOT EXISTS",后面
  • 可扩展性需求分析

    千次阅读 2007-01-15 15:31:37
     网络系统的可扩展性需求决定了新设计的网络系统适应用户企业未来发展的能力,也决定了网络系统对用户投资的保护能力。试想一个花了几十万构建的网络系统,可就在使用不到一年,因为公司用户量的小幅增加,或者增加...
  • [架构师之路] 高可扩展表结构系列

    千次阅读 2017-11-28 19:20:28
     2016-12-14 http://chuansong.me/n/1311070246933 这才是真正的表扩展方案 2016-12-15 ... 完整展示了通过 Ext 字段进行无限扩展的方案和实现原理,同时也详解了58同城相关的三大核心组件。
  • 该文件系统提供极佳的性能,可靠性以及扩展性。通过专为不可靠的对象存储设备(Object Storage Device,OSDs)所组成的异构、动态集群而设计的准随机数据分配算法(CRUSH),利用其替代文件分配表,Ceph 将数据与元...
  • 2.1 宏观目标 2.2 微观目标 ❇ 性能指标 ❇ 可用性指标 ❇ 可扩展性指标 03 高并发的实践方案有哪些? 3.1 通用的设计方法 ❇ 纵向扩展(scale-up) ❇ 横向扩展(scale-out) 3.2 具体的实践方案 ❇ 高性能的...
  • 因为很多涉及到 Visual Studio 插件开发相关的文章/博客需要以安装 Visual Studio 插件开发环境为基础,所以本文介绍如何安装 Visual Studio 插件开发环境,以简化那些博客中的内容。 启动 Visual Studio 安装程序 ...
  • 我理解的高扩展性就是在需求变动或新增需求时,开发人员能够基于以前的系统架构做出快速开发。 1.1例子: 项目经理李峰把JAVA EE项目架构搭建好后,实习生张飞就按照工作安排进行A、B、C、D四个模块的开发。由于...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 1,027,330
精华内容 410,932
关键字:

内容的可扩展性