分布式架构有哪些技术

Ⅰ 网站分布式技术有哪些

分布式软件系统(Distributed Software Systems)是支持分布式处理的软件系统,是在由通信网络互联的多处理机体系结构上执行任务的系统。它包括分布式操作系统、分布式程序设计语言及其编译(解释)系统、分布式文件系统和分布式数据库系统等。

分布式操作系统负责管理分布式处理系统资源和控制分布式程序运行。它和集中式操作系统的区别在于资源管理、进程通信和系统结构等方面。也可以利用nicebox来进行。

分布式程序设计语言用于编写运行于分布式计算机系统上的分布式程序。一个分布式程序由若干个可以独立执行的程序模块组成,它们分布于一个分布式处理系统的多台计算机上被同时执行。它与集中式的程序设计语言相比有三个特点：分布性、通信性和稳健性。

分布式文件系统具有执行远程文件存取的能力,并以透明方式对分布在网络上的文件进行管理和存取。

Ⅱ 分布式存储技术有哪些

中央存储技术现已发展非常成熟。但是同时，新的问题也出现了，中心化的网络很容易拥挤，数据很容易被滥用。传统的数据传输方式是由客户端向云服务器传输，由服务器向客户端下载。而分布式存储系统QKFile是从客户端传送到 N个节点，然后从这些节点就近下载到客户端内部，因此传输速度非常快。对比中心协议的特点是上传、下载速度快，能够有效地聚集空闲存储资源，并能大大降低存储成本。

在节点数量不断增加的情况下，QKFile市场趋势开始突出，未来用户数量将呈指数增长。分布式存储在未来会有很多应用场景，如数据存储，文件传输，网络视频，社会媒体和去中心化交易等。因特网的控制权越来越集中在少数几个大型技术公司的手中，它的网络被去中心化，就像分布式存储一样，总是以社区为中心，面向用户，而分布式存储就是实现信息技术和未来因特网功能的远景。有了分布式存储，我们可以创造出更加自由、创新和民主的网络体验。是时候把因特网推向新阶段了。

作为今年非常受欢迎的明星项目，关于QKFile的未来发展会推动互联网的进步，给整个市场带来巨大好处。分布式存储是基于因特网的基础结构产生的，区块链分布式存储与人工智能、大数据等有叠加作用。对今天的中心存储是一个巨大的补充，分布式时代的到来并不是要取代现在的中心互联网，而是要使未来的数据存储发展得更好，给整个市场生态带来不可想象的活力。先看共识，后看应用，QKFile创建了一个基础设施平台，就像阿里云，阿里云上面是做游戏的做电商的视频网站，这就叫应用层，现阶段，在性能上，坦白说，与传统的云存储相比，没有什么竞争力。不过另一方面来说，一个新型的去中心化存储的信任环境式非常重要的，在此环境下，自然可以衍生出许多相关应用，市场潜力非常大。

虽然QKFile离真正的商用还有很大的距离，首先QKFile的经济模型还没有定论，其次QKFile需要集中精力发展分布式存储、商业逻辑和 web3.0，只有打通分布式存储赛道，才有实力引领整个行业发展，人们认识到了中心化存储的弊端，还有许多企业开始接受分布式存储模式，即分布式存储 DAPP应用触达用户。所以QKFile将来肯定会有更多的商业应用。创建超本地高效存储方式的能力。当用户希望将数据存储在QKFile网络上时，他们就可以摆脱巨大的集中存储和地理位置的限制，用户可以看到在线存储的矿工及其市场价格，矿工之间相互竞争以赢得存储合约。使用者挑选有竞争力的矿工，交易完成，用户发送数据，然后矿工存储数据，矿工必须证明数据的正确存储才能得到QKFile奖励。在网络中，通过密码证明来验证数据的存储安全性。采矿者通过新区块链向网络提交其储存证明。通过网络发布的新区块链验证，只有正确的区块链才能被接受，经过一段时间，矿工们就可以获得交易存储费用，并有机会得到区块链奖励。数据就在更需要它的地方传播了，旋转数据就在地球范围内流动了，数据的获取就不断优化了，从小的矿机到大的数据中心，所有人都可以通过共同努力，为人类信息社会的建设奠定新的基础，并从中获益。

Ⅲ 搭建分布式架构需要什么技术

SOA本身就是一个组件模型

Ⅳ 分布式架构的详细说明

一、分布式计算技术的形成
CORBA (Common Object Request Broker Architecture) 是在1992年由OMG(Open Management Group) 组织提出的。那时的分布式应用环境都采用Client/Server架构，CORBA的应用很大程度的提高了分布式应用软件的开发效率。
当时的另一种分布式系统开发工具是Microsoft的DCOM(Distributed Common Object Model)。Microsoft为了使在Windows平台上开发的各种应用软件产品的功能能够在运行时(Runtime)相互调用(比如在Microsoft Word中直接编辑Excel文件)，实现了OLE(Linked and Embedded Object)技术，后来这个技术衍生为COM(Common Object Model)。
随着Internet的普及和网络服务(Web Services)的广泛应用, Browser/Server架构的模式逐渐体现出它的优势。 于是，Sun公司在其Java技术的基础上推出了应用于B/S架构的J2EE的开发和应用平台;Microsoft也在其DCOM技术的基础上推出了主要面向B/S应用的.NET开发和应用平台。
二、使用的协议
.NET中涵盖的DCOM技术和CORBA一样，在网络传输层都采用TCP/IP协议;也都有自己的IDL规范。所不同的是，在TCP/IP之上，CORBA采用GIOP/IIOP协议，所有CORBA服务器以IIOP通信，形成了ORB软件通道;J2EE的RMI曾经采用独立的通信协议，目前已经改为RMI/IIOP，体现了J2EE的开放性;DCOM也有自己的通信协议(TCP在135端口的服务)，但微软没有公开这个协议的规范;同样，CORBA的IDL采用类C++的定义，是公开的规范;DCOM的IDL的文件虽然是文本形式的，微软没有正式公布它的规范，在使用中，.NET的IDL是由开发工具生成的。
三、应用的环境
关于.NET，比尔盖茨这样说:“简单地说，.NET是以微软的各种产品为开发工具和应用平台， 实现基于XML的网络服务。”由此也可以看出，.NET在Microsoft的世界里功能强大，但对于Unix和Linux这些在服务器市场占主要份额的系统，.NET显得束手无策。
因此，J2EE显示了它跨平台的优势，为网络服务商提供了很好的面向前端(front-end)的开发和应用平台, 随着网络服务进一步广泛应用和服务集成度的提高, 在网络服务提供商的后台会形成越来越庞大的分布式计算环境, CORBA模块结构更适合后台(back-end)的多种服务, 例如网络服务的计费程序等. 因此可以看出, J2EE和CORBA技术在网络服务(Web Services)这片蓝天下, 各自有自己的海洋和陆地。如果在前端(front-end)使用了.NET开发平台，那么在后端(back-end)的分布式结构中，DCOM就是理想的选择。
J2EE是纯Java技术，很多测试显示RMI(Java)服务器的响应速度远远低于非Java的CORBA服务器。因此，在一些对数据处理速度和响应时间要求较高的系统开发中，要对RMI和CORBA的性能进行测试对比后再做选择。
四、应用软件的开发和维护
从应用软件的开发过程的角度看, J2EE是完全开放式的平台, 体现为既面向设计人员, 也面向开发人员的规范; CORBA也是一种规范, 但更多体现为中间产品, CORBA产品的提供商才是这种规范的真正执行者, 对应用开发的程序员而言, 只要了解IDL语言的规范, 不必详细知道ORB/GIOP/IIOP的协议细节。.NET作为Microsoft在网络环境的主打, 体现为一系列产品化的开发工具, 比如C#, C++, 等。这些开发工具是直接针对应用开发人员的。其实Sun公司提供的J2EE也是由许多软件包(应用API)来面对开发人员的。
从软件开发成本与周期以及软件的维护角度看，J2EE比CORBA有以上优势。
五、应用前景
对于分布式计算技术的架构，不能绝对地说哪一个更好，只能说哪一个更合适。针对不同的软件项目需求，具体分析才是明智的选择。
从宏观市场看，CORBA产品的销售并没有想象那样给CORBA产品提供商带来可观的利润;而J2EE的呼声也高于.NET; 随着J2EE中RMI/IIOP与CORBA接口的完善，再加上开发费用的考虑和使用的方便性，J2EE一揽子开放的环境会是人们首先考虑的选择;但CORBA标准的强壮的兼容性，也使这种技术在大型系统开发中会占有一席之地。
关于作者
周斌 北京时力永联科技公司业务咨询和软件外包服务部经理，曾执教于复旦大学计算机科学系, 1994年赴美国Oracle总部参加合作项目, 后就读于加拿大哥伦比亚大学

Ⅳ J2EE中用于分布式架构的技术有哪些他们的不同之处

java EE标准的分布式方案：EJB
异构系统通用的方案：Webservice
Java轻量级的方案（基于远程调用）：Spring Remoting( Http , Hessian, RMI, Webservice)

EJB适用于企业内部，通常跟特定的中间件产品绑定（比如weblogic，websphere..), 效率高，基于标准，有负载均衡、失败转移、事务传播的能力。
webservice用于异构系统之间的整合，即不同语言开发的系统也可以相互调用，一般用于提供服务接口。
Spring 框架提供的远程调用方案相比EJB比较轻量，仅实现了远程调用的功能，但是对一般应用足矣。好处是简单、快速；

Ⅵ 分布式架构需要哪些技术

我做过50w用户的小型棋牌游戏。 当时使用了20台服务器集群，前段服务器用websocket和客户端连接， 服务器是c++写的。 之后据说被人用nodejs重构了...
大致说一下吧。 分布式有逻辑层和数据层这一分。而且架构也分前端（处理客户端连接和session管理）后端（负责数据， 业务）还有lbs服务器。 一般客户端访问lbs服务器， 会得到一个路由（前段服务器的ip），然后连接到前端上。 前端会生成session以及连接， 用户通过前端的接口来访问后端服务器来完成数据交互，
用到的技术有redis（数据共享以及缓存） mq（解耦合以及服务器之前的消息发送） rpc（服务器之间的数据实时同步） sysstat（子服务器状态监控）nginx（负载均衡。

Ⅶ 分布式常用技术有哪些

这个太多了，大数据方面常用的分布式存储技术为HDFS、HBase，分布式计算技术有MapRece、Spark等等。

Ⅷ java分布式架构有哪些技术

既然是分布式系统，系统间通信的技术就不可避免的要掌握。

首先，我们必须掌握一些基本知识，例如网络通信协议（例如TCP / UDP等），网络IO（Blocking-IO，NonBlocking-IO，Asyn-IO），网卡（多队列等）。 了解有关连接重用，序列化/反序列化，RPC，负载平衡等的信息。

在学习了这些基本知识之后，您基本上可以在分布式系统中编写一个简单的通信模块，但这实际上还远远不够。 现在，您已经进入了分布式字段，您已经对规模有很多要求。 这意味着需要一种通信程序，该程序可以支持大量连接，高并发性和低资源消耗。

大量的连接通常会有两种方式：

大量client连一个server

当前在NonBlocking-IO非常成熟的情况下，支持大量客户端的服务器并不难编写，但是在大规模且通常是长连接的情况下，有一点需要特别注意 ，即服务器挂起时不可能所有客户端都在某个时间点启动重新连接。 那基本上是一场灾难。 我见过一些没有经验的类似案例。 客户端规模扩大后，服务器基本上会在重新启动后立即刷新。 大量传入连接中断（当然，服务器的积压队列首先应设置为稍大一些）。 可以使用的通常方法是在客户端重新连接之前睡眠一段随机的时间。 另外，重连间隔采用避让算法。

一个client连大量的server

有些场景也会出现需要连大量server的现象，在这种情况下，同样要注意的也是不要并发同时去建所有的连接，而是在能力范围内分批去建。

除了建连接外，另外还要注意的地方是并发发送请求也同样，一定要做好限流，否则很容易会因为一些点慢导致内存爆掉。

这些问题在技术风险上得考虑进去，并在设计和代码实现上体现，否则一旦随着规模上去了，问题一时半会还真不太好解。

高并发这个点需要掌握CAS、常见的lock-free算法、读写锁、线程相关知识（例如线程交互、线程池）等，通信层面的高并发在NonBlocking-IO的情况下，最重要的是要注意在整体设计和代码实现上尽量减少对io线程池的时间占用。

低资源消耗这点的话NonBlocking-IO本身基本已经做到。

伸缩性

分布式系统基本上意味着规模不小。 对于此类系统，在设计时必须考虑可伸缩性。 在体系结构图上绘制的任何点，如果请求量或数据量继续增加，该怎么办？ 通过添加机器来解决。 当然，此过程不需要考虑无限的情况。 如果您有经验的建筑师，从相对较小的规模到非常大型的范围，那么优势显然并不小，而且它们也将越来越稀缺。 。

横向可扩展性（Scale Out）是指通过增加服务器数量来提高群集的整体性能。 垂直可伸缩性（Scale Up）是指提高每台服务器的性能以提高集群的整体性能。 纵向可扩展性的上限非常明显，而分布式系统则强调水平可伸缩性。

分布式系统应用服务最好做成无状态的

应用服务的状态是指运行时程序因为处理服务请求而存在内存的数据。分布式应用服务最好是设计成无状态。因为如果应用程序是有状态的，那么一旦服务器宕机就会使得应用服务程序受影响而挂掉，那存在内存的数据也就丢失了，这显然不是高可靠的服务。把应用服务设计成无状态的，让程序把需要保存的数据都保存在专门的存储上(eg. 数据库)，这样应用服务程序可以任意重启而不丢失数据，方便分布式系统在服务器宕机后恢复应用服务。

伸缩性的问题围绕着以下两种场景在解决：

无状态场景

对于无状态场景，要实现随量增长而加机器支撑会比较简单，这种情况下只用解决节点发现的问题，通常只要基于负载均衡就可以搞定，硬件或软件方式都有；

无状态场景通常会把很多状态放在db，当量到一定阶段后会需要引入服务化，去缓解对db连接数太多的情况。

有状态场景

所谓状态其实就是数据，通常采用Sharding来实现伸缩性，Sharding有多种的实现方式，常见的有这么一些：

2.1 规则Sharding

基于一定规则把状态数据进行Sharding，例如分库分表很多时候采用的就是这样的，这种方式支持了伸缩性，但通常也带来了很复杂的管理、状态数据搬迁，甚至业务功能很难实现的问题，例如全局join，跨表事务等。

2.2 一致性Hash

一致性Hash方案会使得加机器代价更低一些，另外就是压力可以更为均衡，例如分布式cache经常采用，和规则Sharding带来的问题基本一样。

2.3 Auto Sharding

Auto Sharding的好处是基本上不用管数据搬迁，而且随着量上涨加机器就OK，但通常Auto Sharding的情况下对如何使用会有比较高的要求，而这个通常也就会造成一些限制，这种方案例如HBase。

2.4 Copy

Copy这种常见于读远多于写的情况，实现起来又会有最终一致的方案和全局一致的方案，最终一致的多数可通过消息机制等，全局一致的例如zookeeper/etcd之类的，既要全局一致又要做到很高的写支撑能力就很难实现了。

即使发展到今天，Sharding方式下的伸缩性问题仍然是很大的挑战，非常不好做。

上面所写的基本都还只是解决的方向，到细节点基本就很容易判断是一个解决过多大规模场景问题的架构师，:)

稳定性

作为分布式系统，必须要考虑清楚整个系统中任何一个点挂掉应该怎么处理（到了一定机器规模，每天挂掉一些机器很正常），同样主要还是分成了无状态和有状态：

无状态场景

对于无状态场景，通常好办，只用节点发现的机制上具备心跳等检测机制就OK，经验上来说无非就是纯粹靠4层的检测对业务不太够，通常得做成7层的，当然，做成7层的就得处理好规模大了后的问题。

有状态场景

对于有状态场景，就比较麻烦了，对数据一致性要求不高的还OK，主备类型的方案基本也可以用，当然，主备方案要做的很好也非常不容易，有各种各样的方案，对于主备方案又觉得不太爽的情况下，例如HBase这样的，就意味着挂掉一台，另外一台接管的话是需要一定时间的，这个对可用性还是有一定影响的；

全局一致类型的场景中，如果一台挂了，就通常意味着得有选举机制来决定其他机器哪台成为主，常见的例如基于paxos的实现。

可维护性

维护性是很容易被遗漏的部分，但对分布式系统来说其实是很重要的部分，例如整个系统环境应该怎么搭建，部署，配套的维护工具、监控点、报警点、问题定位、问题处理策略等等。

Ⅸ 什么是分布式架构

分布式架构是 分布式计算技术的应用和工具，目前成熟的技术包括J2EE, CORBA和.NET(DCOM)。
一、分布式计算技术的形成
CORBA (Common Object Request Broker Architecture) 是在1992年由OMG(Open Management Group) 组织提出的。那时的分布式应用环境都采用Client/Server架构，CORBA的应用很大程度的提高了分布式应用软件的开发效率。
当时的另一种分布式系统开发工具是Microsoft的DCOM(Distributed Common Object Model)。Microsoft为了使在Windows平台上开发的各种应用软件产品的功能能够在运行时(Runtime)相互调用(比如在Microsoft Word中直接编辑Excel文件)，实现了OLE(Linked and Embedded Object)技术，后来这个技术衍生为COM(Common Object Model)。
随着Internet的普及和网络服务(Web Services)的广泛应用, Browser/Server架构的模式逐渐体现出它的优势。 于是，Sun公司在其Java技术的基础上推出了应用于B/S架构的J2EE的开发和应用平台;Microsoft也在其DCOM技术的基础上推出了主要面向B/S应用的.NET开发和应用平台。
二、使用的协议
.NET中涵盖的DCOM技术和CORBA一样，在网络传输层都采用TCP/IP协议;也都有自己的IDL规范。所不同的是，在TCP/IP之上，CORBA采用GIOP/IIOP协议，所有CORBA服务器以IIOP通信，形成了ORB软件通道;J2EE的RMI曾经采用独立的通信协议，目前已经改为RMI/IIOP，体现了J2EE的开放性;DCOM也有自己的通信协议(TCP在135端口的服务)，但微软没有公开这个协议的规范;同样，CORBA的IDL采用类C++的定义，是公开的规范;DCOM的IDL的文件虽然是文本形式的，微软没有正式公布它的规范，在使用中，.NET的IDL是由开发工具生成的。
三、应用的环境
关于.NET，比尔盖茨这样说:“简单地说，.NET是以微软的各种产品为开发工具和应用平台， 实现基于XML的网络服务。”由此也可以看出，.NET在Microsoft的世界里功能强大，但对于Unix和Linux这些在服务器市场占主要份额的系统，.NET显得束手无策。
因此，J2EE显示了它跨平台的优势，为网络服务商提供了很好的面向前端(front-end)的开发和应用平台, 随着网络服务进一步广泛应用和服务集成度的提高, 在网络服务提供商的后台会形成越来越庞大的分布式计算环境, CORBA模块结构更适合后台(back-end)的多种服务, 例如网络服务的计费程序等. 因此可以看出, J2EE和CORBA技术在网络服务(Web Services)这片蓝天下, 各自有自己的海洋和陆地。如果在前端(front-end)使用了.NET开发平台，那么在后端(back-end)的分布式结构中，DCOM就是理想的选择。
J2EE是纯Java技术，很多测试显示RMI(Java)服务器的响应速度远远低于非Java的CORBA服务器。因此，在一些对数据处理速度和响应时间要求较高的系统开发中，要对RMI和CORBA的性能进行测试对比后再做选择。
四、应用软件的开发和维护
从应用软件的开发过程的角度看, J2EE是完全开放式的平台, 体现为既面向设计人员, 也面向开发人员的规范; CORBA也是一种规范, 但更多体现为中间产品, CORBA产品的提供商才是这种规范的真正执行者, 对应用开发的程序员而言, 只要了解IDL语言的规范, 不必详细知道ORB/GIOP/IIOP的协议细节。.NET作为Microsoft在网络环境的主打, 体现为一系列产品化的开发工具, 比如C#, C++, 等。这些开发工具是直接针对应用开发人员的。其实Sun公司提供的J2EE也是由许多软件包(应用API)来面对开发人员的。
从软件开发成本与周期以及软件的维护角度看，J2EE比CORBA有以上优势。
五、应用前景
对于分布式计算技术的架构，不能绝对地说哪一个更好，只能说哪一个更合适。针对不同的软件项目需求，具体分析才是明智的选择。
从宏观市场看，CORBA产品的销售并没有想象那样给CORBA产品提供商带来可观的利润;而J2EE的呼声也高于.NET; 随着J2EE中RMI/IIOP与CORBA接口的完善，再加上开发费用的考虑和使用的方便性，J2EE一揽子开放的环境会是人们首先考虑的选择;但CORBA标准的强壮的兼容性，也使这种技术在大型系统开发中会占有一席之地。

Ⅹ 请问分布式架构主要有哪几种

分布式架构CORBA (Common Object Request Broker Architecture) 是在1992年由OMG(Open Management Group) 组织提出的。那时的分布式应用环境都采用Client/Server架构，CORBA的应用很大程度的提高了分布式应用软件的开发效率。 当时的另一种分布式系统开发工具是Microsoft的DCOM(Distributed Common Object Model)。Microsoft为了使在Windows平台上开发的各种应用软件产品的功能能够在运行时(Runtime)相互调用(比如在Microsoft Word中直接编辑Excel文件)，实现了OLE(Linked and Embedded Object)技术，后来这个技术衍生为COM(Common Object Model)。 瑭锦-TANJURD表示随着Internet的普及和网络服务(Web Services)的广泛应用, Browser/Server架构的模式逐渐体现出它的优势。于是，Sun公司在其Java技术的基础上推出了应用于B/S架构的J2EE的开发和应用平台;Microsoft也在其DCOM技术的基础上推出了主要面向B/S应用的.NET开发和应用平台。