分布式架構有哪些技術

Ⅰ 網站分布式技術有哪些

分布式軟體系統(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開發和應用平台。