1. 如何用java 建立一個分布式系統
分布式架構的演進
系統架構演化歷程-初始階段架構
初始階段 的小型系統 應用程序、資料庫、文件等所有的資源都在一台伺服器上通俗稱為LAMP
特徵：
應用程序、資料庫、文件等所有的資源都在一台伺服器上。
描述：
通常伺服器操作系統使用Linux，應用程序使用PHP開發，然後部署在Apache上，資料庫使用MySQL，匯集各種免費開源軟體以及一台廉價伺服器就可以開始系統的發展之路了。
系統架構演化歷程-應用服務和數據服務分離
好景不長，發現隨著系統訪問量的再度增加，webserver機器的壓力在高峰期會上升到比較高，這個時候開始考慮增加一台webserver
特徵：
應用程序、資料庫、文件分別部署在獨立的資源上。
描述：
數據量增加，單台伺服器性能及存儲空間不足，需要將應用和數據分離，並發處理能力和數據存儲空間得到了很大改善。
系統架構演化歷程-使用緩存改善性能
特徵：
資料庫中訪問較集中的一小部分數據存儲在緩存伺服器中，減少資料庫的訪問次數，降低資料庫的訪問壓力。
描述：
系統訪問特點遵循二八定律，即80%的業務訪問集中在20%的數據上。
緩存分為本地緩存和遠程分布式緩存，本地緩存訪問速度更快但緩存數據量有限，同時存在與應用程序爭用內存的情況。
系統架構演化歷程-使用應用伺服器集群
在做完分庫分表這些工作後，資料庫上的壓力已經降到比較低了，又開始過著每天看著訪問量暴增的幸福生活了，突然有一天，發現系統的訪問又開始有變慢的趨勢了，這個時候首先查看資料庫，壓力一切正常，之後查看webserver，發現apache阻塞了很多的請求，而應用伺服器對每個請求也是比較快的，看來 是請求數太高導致需要排隊等待，響應速度變慢
特徵：
多台伺服器通過負載均衡同時向外部提供服務，解決單台伺服器處理能力和存儲空間上限的問題。
描述：
使用集群是系統解決高並發、海量數據問題的常用手段。通過向集群中追加資源，提升系統的並發處理能力，使得伺服器的負載壓力不再成為整個系統的瓶頸。
系統架構演化歷程-資料庫讀寫分離
享受了一段時間的系統訪問量高速增長的幸福後，發現系統又開始變慢了，這次又是什麼狀況呢，經過查找，發現資料庫寫入、更新的這些操作的部分資料庫連接的資源競爭非常激烈，導致了系統變慢
特徵：
多台伺服器通過負載均衡同時向外部提供服務，解決單台伺服器處理能力和存儲空間上限的問題。
描述：
使用集群是系統解決高並發、海量數據問題的常用手段。通過向集群中追加資源，使得伺服器的負載壓力不在成為整個系統的瓶頸。
系統架構演化歷程-反向代理和CDN加速
特徵：
採用CDN和反向代理加快系統的 訪問速度。
描述：
為了應付復雜的網路環境和不同地區用戶的訪問，通過CDN和反向代理加快用戶訪問的速度，同時減輕後端伺服器的負載壓力。CDN與反向代理的基本原理都是緩存。
系統架構演化歷程-分布式文件系統和分布式資料庫
隨著系統的不斷運行，數據量開始大幅度增長，這個時候發現分庫後查詢仍然會有些慢，於是按照分庫的思想開始做分表的工作
特徵：
資料庫採用分布式資料庫，文件系統採用分布式文件系統。
描述：
任何強大的單一伺服器都滿足不了大型系統持續增長的業務需求，資料庫讀寫分離隨著業務的發展最終也將無法滿足需求，需要使用分布式資料庫及分布式文件系統來支撐。
分布式資料庫是系統資料庫拆分的最後方法，只有在單表數據規模非常龐大的時候才使用，更常用的資料庫拆分手段是業務分庫，將不同的業務資料庫部署在不同的物理伺服器上。
系統架構演化歷程-使用NoSQL和搜索引擎
特徵：
系統引入NoSQL資料庫及搜索引擎。
描述：
隨著業務越來越復雜，對數據存儲和檢索的需求也越來越復雜，系統需要採用一些非關系型資料庫如NoSQL和分資料庫查詢技術如搜索引擎。應用伺服器通過統一數據訪問模塊訪問各種數據，減輕應用程序管理諸多數據源的麻煩。
系統架構演化歷程-業務拆分
特徵：
系統上按照業務進行拆分改造，應用伺服器按照業務區分進行分別部署。
描述：
為了應對日益復雜的業務場景，通常使用分而治之的手段將整個系統業務分成不同的產品線，應用之間通過超鏈接建立關系，也可以通過消息隊列進行數據分發，當然更多的還是通過訪問同一個數據存儲系統來構成一個關聯的完整系統。
縱向拆分：
將一個大應用拆分為多個小應用，如果新業務較為獨立，那麼就直接將其設計部署為一個獨立的Web應用系統
縱向拆分相對較為簡單，通過梳理業務，將較少相關的業務剝離即可。
橫向拆分：將復用的業務拆分出來，獨立部署為分布式服務，新增業務只需要調用這些分布式服務
橫向拆分需要識別可復用的業務，設計服務介面，規范服務依賴關系。
系統架構演化歷程-分布式服務
特徵：
公共的應用模塊被提取出來，部署在分布式伺服器上供應用伺服器調用。
描述：
隨著業務越拆越小，應用系統整體復雜程度呈指數級上升，由於所有應用要和所有資料庫系統連接，最終導致資料庫連接資源不足，拒絕服務。
Q：分布式服務應用會面臨哪些問題？
A：
(1) 當服務越來越多時，服務URL配置管理變得非常困難，F5硬體負載均衡器的單點壓力也越來越大。
(2) 當進一步發展，服務間依賴關系變得錯蹤復雜，甚至分不清哪個應用要在哪個應用之前啟動，架構師都不能完整的描述應用的架構關系。
(3) 接著，服務的調用量越來越大，服務的容量問題就暴露出來，這個服務需要多少機器支撐？什麼時候該加機器？
(4) 服務多了，溝通成本也開始上升，調某個服務失敗該找誰？服務的參數都有什麼約定？
(5) 一個服務有多個業務消費者，如何確保服務質量？
(6) 隨著服務的不停升級，總有些意想不到的事發生，比如cache寫錯了導致內存溢出，故障不可避免，每次核心服務一掛，影響一大片，人心慌慌，如何控制故障的影響面？服務是否可以功能降級？或者資源劣化？
Java分布式應用技術基礎
分布式服務下的關鍵技術：消息隊列架構
消息對列通過消息對象分解系統耦合性，不同子系統處理同一個消息
分布式服務下的關鍵技術：消息隊列原理
分布式服務下的關鍵技術：服務框架架構
服務框架通過介面分解系統耦合性，不同子系統通過相同的介面描述進行服務啟用
服務框架是一個點對點模型
服務框架面向同構系統
適合：移動應用、互聯網應用、外部系統
分布式服務下的關鍵技術：服務框架原理
分布式服務下的關鍵技術：服務匯流排架構
服務匯流排同服務框架一樣，均是通過介面分解系統耦合性，不同子系統通過相同的介面描述進行服務啟用
服務匯流排是一個匯流排式的模型
服務匯流排面向同構、異構系統
適合：內部系統
分布式服務下的關鍵技術：服務匯流排原理
分布式架構下系統間交互的5種通信模式
request/response模式（同步模式）：客戶端發起請求一直阻塞到服務端返回請求為止。
Callback（非同步模式）：客戶端發送一個RPC請求給伺服器，服務端處理後再發送一個消息給消息發送端提供的callback端點，此類情況非常合適以下場景：A組件發送RPC請求給B，B處理完成後，需要通知A組件做後續處理。
Future模式：客戶端發送完請求後，繼續做自己的事情，返回一個包含消息結果的Future對象。客戶端需要使用返回結果時，使用Future對象的.get(),如果此時沒有結果返回的話，會一直阻塞到有結果返回為止。
Oneway模式：客戶端調用完繼續執行，不管接收端是否成功。
Reliable模式：為保證通信可靠，將藉助於消息中心來實現消息的可靠送達，請求將做持久化存儲，在接收方在線時做送達，並由消息中心保證異常重試。
五種通信模式的實現方式-同步點對點服務模式
五種通信模式的實現方式-非同步點對點消息模式1
五種通信模式的實現方式-非同步點對點消息模式2
五種通信模式的實現方式-非同步廣播消息模式
分布式架構下的服務治理
服務治理是服務框架/服務匯流排的核心功能。所謂服務治理，是指服務的提供方和消費方達成一致的約定，保證服務的高質量。服務治理功能可以解決將某些特定流量引入某一批機器，以及限制某些非法消費者的惡意訪問，並在提供者處理量達到一定程度是，拒絕接受新的訪問。
基於服務框架Dubbo的服務治理-服務管理
可以知道你的系統，對外提供了多少服務，可以對服務進行升級、降級、停用、權重調整等操作
可以知道你提供的服務，誰在使用，因業務需求，可以對該消費者實施屏蔽、停用等操作
基於服務框架Dubbo的服務治理-服務監控
可以統計服務的每秒請求數、平均響應時間、調用量、峰值時間等，作為服務集群規劃、性能調優的參考指標。
基於服務框架Dubbo的服務治理-服務路由
基於服務框架Dubbo的服務治理-服務保護
基於服務匯流排OSB的服務治理-功能介紹
基於服務匯流排OSB的服務治理
Q：Dubbo到底是神馬？
A：
淘寶開源的高性能和透明化的RPC遠程調用服務框架
SOA服務治理方案
Q：Dubbo原理是？
A：
-結束-
2. 如何在恆訊雲伺服器上搭建個人IPFS分布式存儲文件系統
我們從恆訊雲了解到，全球雲服務市場正在迅猛增長，
有數據預計到2024年，全球雲服務市場規模將增長至2840億美元，約合人民幣2萬億元
恆訊雲松鼠礦機
這時，有人做了這樣一個假設，如若IPFS的市值未來能等同於這2萬億元的雲服務市場，Filecoin總共發行的20億FIL，每個FIL的未來價值不可限量，
因為全球各個商家及用戶購買IPFS的服務，唯一籌碼便是Filecoin，而我們便可以在各個交易所兌換成法幣。
一個很好的形容就是，如今的IPFS&Filecoin市場很像是白晝前的黎明，
市場在資本、散戶等參與者的不斷進場下，熱度愈發上漲。
互聯網因中心化存儲帶來的痛點你我都不陌生，
如傳輸速度慢、數據易丟失、無法永久存儲數據、帶寬有限等。
而IPFS就是為了改變這些而誕生。
數字經濟時代的到來，讓人們有了越來越多的數據需要去記錄和存儲，
5G、大數據、雲計算、人工智慧等蓬勃發展後，數據存儲需求也爆發式增長。
恆訊雲松鼠礦機
根據恆訊雲預測，到2025年，全球數據將增長至175ZB。
對比已知的2018年32ZB的數字，即將增長近6倍，現行網路限於中心化協議的弊端愈發凸顯，不得不投向分布式存儲，
有數據顯示，2018年，全球公有雲市場規模達到 1363 億美元，增速 23.01%。
未來幾年市場平均增長率在 20% 左右，預計到 2022 年市場規模將超過 2700 億美元。
恆訊雲數據也曾預測，到2023年，實時數據將佔全球數據圈24.5%的份額。
許多企業場景下，實時的數據採集、存儲和分析的要求變得越來越嚴苛，企業的IT供應商需要提供更好的存儲介質，以確保響應速度滿足未來數據實時性。
3. 創建使用分布式文件系統
當微軟公司最初介紹分布式文件系統(Distributed File System，簡稱DFS)的時候，它把終端用戶希望讓事情變得簡單一些的注意力都集中在自己身上。這種技術的思路是用戶本身並不需要知道哪些伺服器資源是真正存在的。他們只要簡單地通過一個特殊的共享就可以訪問到文件系統，而且還可以訪問到所有他們所需要的數據，無論這些數據是集中存儲在本地還是分散存儲在許多不同的伺服器中。
盡管在用戶端把把事情變得簡單總是好處多多，但是我認為DFS的用途要比僅僅用於負載平衡與容錯要多得多。DFS可以用來把用戶的工作量分配到多個含有文件副本的伺服器中。除此之外，如果一個副本的伺服器失效，或者管理員需要對一台伺服器進行離線維護，那麼通過使用DFS，用戶仍然可以不間斷地持續訪問副本伺服器。(在第二部分中，我將會更為詳細地討論負載平衡與容錯問題。)
在第一部分中，現在我將要向你介紹如何在Windows 2003 server中創建一個分布式文件系統。
第一步:創建控制台
開始這個過程首先要在「運行」命令中輸入Microsoft Management Console(管理控制台，MMC)命令。當你輸入之後，Windows將會載入一個空的管理控制台。現在，你要在控制台的「文件」菜單中選擇「添加或移除管理單元(Snap-In)」命令。Windows隨後會顯示出添加或移除管理單元的屬性菜單。在這個時候，要點擊基於屬性菜單中「Standalone」標簽下的「添加」按鈕，以便顯示出所有可用管理單元的表列。從表列中選擇分布式文件系統選項，並點擊「添加」按鈕，接下來點擊「關閉」和「確認」按鈕。
第二步:創建DFS根
「根」就是DFS層級結構的最頂層。一個根當中包含了多個共享文件夾。要在目前含有你的一些數據的伺服器中創建根，你需要在控制台中用滑鼠右鍵點擊「分布式文件系統容器(container)」，然後從快捷菜單中選擇「新的根」命令。這樣做能夠使Windows載入新的根安裝向導程序。點擊「下一步」越過安裝向導的歡迎界面。這時向導會詢問你是要創建一個獨立的根還是創建一個域的根。域的根只存在於Windows Server 2003中。它們支持自動的數據復制。對於本文的目的而言，應該選擇域的根選項，然後點擊「下一步」。
向導的下一個界面是詢問你哪一個域作為你所創建的根的主域。選擇合適的域，然後點擊「下一步」。現在，你必須輸入將要做為新創建的根的主機的伺服器的名稱。這個伺服器必須是你在上一步所選擇的域的一個成員。輸入完全符合域的要求的伺服器名稱，然後點擊「下一步」。
第三步:給根命名
向導的下一個界面要求你輸入你所創建的根的名稱。Windows將會創建一個與你所輸入的根的名稱一致的共享名稱。我還推薦你應該輸入一些描述文字，以便幫助你記住這個根是做什麼用的。點擊「下一步」來繼續我們的工作。
第四步:文件夾選擇
在這個界面中，向導將會要求你指定一個Windows能夠把共享文件分配到其中的文件夾。我推薦你選擇一個已經包含了你的數據的文件夾。點擊「下一步」，接下來點擊「完成」，結束根的創建。
你的DFS共享現在應該是被激活的。為了確認根是有效的，可以用滑鼠右鍵點擊它，然後快捷菜單中選擇「檢查狀態」命令。正確的狀態應該顯示為「聯機」。
如何創建副本伺服器
這是為本系列的第二部分所進行的准備，我希望向你介紹如何創建一個副本伺服器的方法。
要開始這個過程，首先要進入你希望創建為副本的伺服器中，並且要選擇一個可用磁碟空間充足的卷。做完這個步驟之後，在這個卷上創建一個文件夾，用來存儲你將要向該伺服器中復制的數據。
創建了文件夾之後，你需要把該文件夾設成共享，並使用與你指定給DFS根一樣的共享名稱。我建議在共享級別上對任何人都給予完全的控制權，並使用NTFS許可來保護數據，而不是依賴於共享級別的許可。在設置了共享之後，你需要等待15分鍾，以便網路能夠對該共享進行識別。在你等待的過程中，打開「服務」控制台，並啟動分布式文件系統服務。
現在回到DFS控制台，用滑鼠右鍵點擊你先前所創建的DFS根，並在快捷菜單中選擇「新的根目標」命令。現在，你將會被提示在你希望創建的根目標處輸入伺服器的名稱。在我的系統中，我需要輸入伺服器的NetBIOS名稱，而不是其完全符合域的要求的名稱，這樣做是為了讓Windows識別伺服器。這里你需要做出你自己的選擇，然後點擊「下一步」。等待一會兒之後，你將會看到一個通知你已經完成了該向導的界面。點擊「完成」，然後繼續下面的工作。
這個時候你的DFS根應該是打開而且處於運行狀態。現在你應該對復制過程進行初始化。你可以用滑鼠右鍵點擊DFS根，然後在快捷菜單中選擇「設置復制」命令。Windows將會載入設置復制向導。點擊「下一步」越過向導的歡迎界面，然後你會被提示選擇初始化主文件。選擇目前包含數據的共享文件，然後點擊「下一步」。在你看到的下一個界面中，向導會要求你選擇一個復制的拓撲結構。我推薦你使用完全網狀拓撲結構。點擊「完成」。隨後，你可能會看到一條信息，提示你文件需要在副本伺服器上將復制服務(File Replication Service)設置成自動啟動。如果出現了這條信息，那麼就要使用伺服器上的「服務」控制台來把文件復制服務的啟動方式改變成自動啟動。啟動服務，然後點擊「是」來重試復制設置。
4. 如何在海量數據環境下，搭建分布式資料庫系統
如果做分布式的話，首先需要對數據做個有效的劃分， 可以通過地區屬性或者其他類似屬性做水平擴展，把不同地域的數據放在不同資料庫上。 但是這種水平分割應當盡量避免跨區的訪問。或者設計一個數據中心，把各個區中和報表相關的匯總數據抽取到倉庫裡面去，提供報表。
這樣的做法在聯機游戲中非常常見，比如魔獸世界，fifa on line等
或者做垂直分割，根據時間或者類似屬性把數據分割到不同資料庫上去，基本架構是一台在用伺服器支持讀寫操作，幾台歷史伺服器提供數據查詢，一些轉儲腳本定期把數據從在用伺服器遷移到歷史伺服器上去...
5. 如何構建一個現代分布式架構
你如何有效地構建一個分布式企業架構?這是一個艱巨的，並且有點模糊的問題，類似於問別人你如何建立一個房子?答案取決於你要建什麼樣的住宅。同樣，你如何決定構建你的分布式系統，將在很大程度上取決於可用的資源和業務需求。分布式架構有許多方面和很多選擇，每個都有它自己的目的，優缺點，以及用例。這里有一些關鍵元素概述：客戶端和伺服器客戶端/伺服器分布和客戶本身的性質(最終用戶設備)，就是在理解分布式架構的重要因素。如果客戶端只是提供一個用戶界面，那麼伺服器幾乎將要做所有的工作。如果客戶端託管一部分或全部應用程序，甚至一些數據(例如瘦或者胖客戶端)，那麼它代表了架構的一個重要部分。一台台式電腦通常有很多自己的內存空間和處理能力，來託管和運行應用程序，只是偶爾才從伺服器更新。相比之下，移動設備(甚至是很多智能手機)沒有大量資源，要嚴重依賴伺服器來處理大部分的工作負載。在某些情況下，這似乎是一個胖客戶端的安排，而實際上是一個瘦客戶端。例如，一個遠程桌面應用程序可能是託管在一個伺服器或虛擬PC上，這樣可以輕松地在本地通過用戶界面來使用PC。這張前景圖上缺少了什麼?顯然，上述示例遺漏了現代分布式架構一個非常重要組件——中間層。網路是最明顯的例子，它使用一個多層次的設計。web伺服器負責通過瀏覽器將靜態或動態內容顯示給終端用戶。應用程序伺服器託管實際應用程序，這些應用是通過瀏覽器來訪問的。資料庫伺服器存儲所有通過應用交付的、使用的和收集到的數據。(記住，每一層之間的連接和溝通作為架構的一個部分，和他們層次本身同樣重要)。企業想向公司以外的終端用戶公開應用程序，如客戶、合作夥伴和供應商，通常用這種方式選擇基於web的分布式架構。當然，企業數據本身可能被進一步分布到多個資料庫，創建一個更不同的架構。一些數據可能位於一個傳統的關系型SQL資料庫中。非結構化數據可以駐留在一個或多個NoSQL資料庫中，在數據管理領域相對較新的選擇方案。《理解NoSQL(Making Sense of NoSQL)》一書的作者，Dan McCreary(與Ann Kelly合著)指出，大數據不僅僅改變資料庫的表面。它也會慢慢影響到企業軟體。「我們在管理大型數據集方面已經有了巨大的創新,並且這能夠使開發人員更敏捷。我想接下來的10年，在公司構建軟體的方式上，會有很大的影響。」當一個不夠時使用基於網路的「即服務」模式，一部分或所有這些伺服器和資料庫可能位於雲端。這將把我們帶入下一個分布式計算主要方面中去——使用多個伺服器。使用多個伺服器的最大好處是沒有單點故障。在 「點對點」的分布式架構中，每台機器可以處理所有任務(雖然沒有一台機器可以一次處理所有的任務)。工作量負載隨著需求在伺服器之間進行分配和重新平衡。這種方法使得資源利用率最大化，並且如果一個節點宕掉了，允許故障轉移到其他仍在運行的伺服器上。數據，計算工作量和溝通都是分布式的，降低影響性能瓶頸的發病率。這是一個創建分布式系統高度可擴展的方法。它比使用單一的大型伺服器使用更少的昂貴設備，並且為應用程序的持續可用性提供了大量的冗餘。當需要多個伺服器時，他們可能會在本地或數據中心中提供。許多企業現在在因為他們分布式架構的不同方麵包括軟體、平台或基礎設施，使用私有雲或混合雲。分布式架構框架和協議構建一個分布式系統涉及很多很多不同的組件，包括從API和資料庫到伺服器以及通信網路。在非常放大的層面，你需要一個框架，用於實現和管理這些組件，比如當前流行的Hadoop框架。在縮小層面，你需要方法和規則，從而在事務處理層確實的把事情做好。這往往是SOA(面向服務架構)及其相關協議發揮作用之處。Nice Systems公司的架構總監Arnon Rotem-Gal-Oz這樣說，「SOA僅僅是我們用來構建分布式系統的一個好的方法。當你正在通過框架，比如.net，構建一個系統時，你會發現一種不錯的方式來模塊化和組件化你的系統，當在SOA原則基礎上建議靈活性時。」他指出,實際上將SOA部署在框架(比如hadoop)的頂部來獲得雙方的利益是可行的。你可能會說，分布式架構「房子」的藍圖一直以來變得越來越復雜。然而，盡管功能可能改變，潛在的好處對於企業保持驚人的一致：更多的計算能力、更好的可擴展性、更多的一致性、更多的可用性、更高的速度和更少的開銷。責編：羅信
6. 如何搭建分布式網站伺服器
需要建立IIS 還由DNS WIN 伺服器的 還有更改主機名 很麻煩的 不多說了。。。
7. 如何搭建分布式web伺服器
太簡單了，所有文件共享，session共享或者改寫，然後外邊就可以簡單的套一層負載均衡了
負載均衡後端web伺服器數量就可以隨意調整了