⑴ 什麼是分布式系統作用是什麼好處是什麼
分布式系統是相較於傳統拼接處理器而言，分布式輸入和輸出節點設備分開布署，通過IP網路互聯，分布式布署在軟體商集中管控的拼接控制系統。所以相對於集中式而言，分布式系統擁有低成本、高性能、擴容簡便等優點。舉例世界地圖吧。如果網路上的世界地圖，全部儲存在一個伺服器里，那麼面對來自全世界龐大的訪問量，主機勢必宕機。但如果地圖信息是存放在世界各地的伺服器里，大家通過網路交互去訪問，就不會出現這樣的問題。而且就算某個區域的伺服器宕機，那需要修復的也只是這一台伺服器而已。分布式工作的原理和優點就是這樣。目前而言，分布式處理器國內做得比較好的，你可以去查查一家叫晨馭科技的。分布式目前經常被用在音視頻技術領域，比如大屏拼接啊，投影融合啊，KVM坐席之類的項目里。KVM就是大型可視化坐席協作管理平台，新聞里那些火箭發射指揮中心，用的都是這樣一套系統。
⑵ java分布式伺服器之間怎麼調用
基本原理 要實現網路機器間的通訊，首先得來看看計算機系統網路通信的基本原理，在底層層面去看，網路通信需要做的就是將流從一台計算機傳輸到另外一台計算機，基於傳輸協議和網路 IO 來實現，其中傳輸協議比較出名的有 http、tcp、 udp 等等，http、tcp、udp 都是在基於Socket 概念上為某類應用場景而擴展出的傳輸協議，網路IO，主要有bio、nio、aio 三種方式，所有的分布式應用通訊都基於這個原理而實現，只是為了應用的易用，各種語言通常都會提供一些更為貼近應用易用的應用層協議。 應用級協議 遠程服務通訊，需要達到的目標是在一台計算機發起請求，另外一台機器在接收到請求後進行相應的處理並將結果返回給請求端，這其中又會有諸如 onewayrequest、同步請求、非同步請求等等請求方式，按照網路通信原理，需要實現這個需要做的就是將請求轉換成流，通過傳輸協議傳輸至遠端，遠端計算機在接收到請求的流後進行處理，處理完畢後將結果轉化為流，並通過傳輸協議返回給調用端。原理是這樣的，但為了應用的方便，業界推出了很多基於此原理之上的應用級的協議，使得大家可以不用去直接操作這么底層的東西，通常應用級的遠程通信協議會提供: 1.為了避免直接做流操作這么麻煩，提供一種更加易用或貼合語言的標准傳輸格式;2.網路通信機制的實現，就是替你完成了將傳輸格式轉化為流，通過某種傳輸協議傳輸至遠端計算機，遠端計算機在接收到流後轉化為傳輸格式，並進行存儲或以某種方式通知遠端計算機。 所以在學習應用級的遠程通信協議時，我們可以帶著這幾個問題進行學習: 1.傳輸的標准格式是什麼?2.怎麼樣將請求轉化為傳輸的流?3.怎麼接收和處理流?4.傳輸協議是? 不過應用級的遠程通信協議並不會在傳輸協議上做什麼多大的改進，主要是在流操作方面，讓應用層生成流和處理流的這個過程更加的貼合所使用的語言或標准，至於傳輸協議則通常都是可選的，在java 領域中知名的有:RMI、 XML-RPC、Binary-RPC、SOAP、CORBA、JMS，來具體的看看這些遠程通信的應用級協議: RMIRMI 是個典型的為java 定製的遠程通信協議，我們都知道，在 singlevm 中，我們可以通過直接調用javaobjectinstance 來實現通信，那麼在遠程通信時，如果也能按照這種方式當然是最好了，這種遠程通信的機製成為RPC(RemoteProcereCall)，RMI 正是朝著這個目標而誕生的。 來看下基於RMI 的一次完整的遠程通信過程的原理: 1.客戶端發起請求，請求轉交至RMI 客戶端的stub 類;2.stub 類將請求的介面、方法、參數等信息進行序列化;3.基於socket 將序列化後的流傳輸至伺服器端;4.伺服器端接收到流後轉發至相應的skelton 類;5.skelton 類將請求的信息反序列化後調用實際的處理類;6.處理類處理完畢後將結果返回給 skelton 類;7.Skelton 類將結果序列化，通過socket 將流傳送給客戶端的 stub;8.stub 在接收到流後反序列化，將反序列化後的JavaObject 返回給調用者。 根據原理來回答下之前學習應用級協議帶著的幾個問題: 1.傳輸的標准格式是什麼?是JavaObjectStream。2.怎麼樣將請求轉化為傳輸的流?基於Java 串列化機制將請求的javaobject 信息轉化為流。3.怎麼接收和處理流?根據採用的協議啟動相應的監聽埠，當有流進入後基於Java 串列化機制將流進行反序列化，並根據RMI 協議獲取到相應的處理對象信息，進行調用並處理，處理完畢後的結果同樣基於java 串列化機制進行返回。4.傳輸協議是?Socket。 XML-RPCXML-RPC 也是一種和RMI 類似的遠程調用的協議，它和RMI 的不同之處在於它以標準的 xml 格式來定義請求的信息(請求的對象、方法、參數等)，這樣的好處是什麼呢，就是在跨語言通訊的時候也可以使用。 來看下XML-RPC 協議的一次遠程通信過程: 1.客戶端發起請求，按照XML-RPC 協議將請求信息進行填充;2.填充完畢後將xml 轉化為流，通過傳輸協議進行傳輸;3.接收到在接收到流後轉換為xml，按照XML-RPC 協議獲取請求的信息並進行處理;4.處理完畢後將結果按照XML- RPC 協議寫入xml 中並返回。 同樣來回答問題: 1.傳輸的標准格式是?標准格式的XML。2.怎麼樣將請求轉化為傳輸的流? 將XML 轉化為流。3.怎麼接收和處理流?通過監聽的埠獲取到請求的流，轉化為XML，並根據協議獲取請求的信息，進行處理並將結果寫入XML 中返回。4. 傳輸協議是?Http。 Binary-RPCBinary-RPC 看名字就知道和XML-RPC 是差不多的了，不同之處僅在於傳輸的標准格式由XML 轉為了二進制的格式。 同樣來回答問題: 1.傳輸的標准格式是?標准格式的二進制文件。2.怎麼樣將請求轉化為傳輸的流?將二進制格式文件轉化為流。3.怎麼接收和處理流?通過監聽的埠獲取到請求的流，轉化為二進制文件，根據協議獲取請求的信息，進行處理並將結果寫入XML 中返回。4.傳輸協議是?Http。 SOAPSOAP 原意為SimpleObjectAccessProtocol，是一個用於分布式環境的、輕量級的、基於XML 進行信息交換的通信協議，可以認為SOAP 是XMLRPC 的高級版，兩者的原理完全相同，都是http+XML，不同的僅在於兩者定義的XML 規范不同，SOAP 也是Webservice 採用的服務調用協議標准，因此在此就不多加闡述了。 (公用對象請求代理[調度]程序體系結構)，是一組用來定義"分布式對象系統"的標准，由 OMG(ObjectMenagementGroup)作為發起和標准制定單位。CORBA 的目的是定義一套協議，符合這個協議的對象可以互相交互，不論它們是用什麼樣的語言寫的，不論它們運行於什麼樣的機器和操作系統。CORBA 在我看來是個類似於SOA 的體系架構，涵蓋可選的遠程通信協議，但其本身不能列入通信協議這里來講，而且CORBA 基本淘汰，再加上對CORBA 也不怎麼懂，在此就不進行闡述了。 JMSJMS 呢，是實現java 領域遠程通信的一種手段和方法，基於JMS 實現遠程通信時和RPC 是不同的，雖然可以做到RPC 的效果，但因為不是從協議級別定義的，因此我們不認為JMS 是個RPC 協議，但它確實是個遠程通信協議，在其他的語言體系中也存在著類似JMS 的東西，可以統一的將這類機制稱為消息機制，而消息機制呢，通常是高並發、分布式領域推薦的一種通信機制，這里的主要一個問題是容錯(詳細見ErLang 論文)。 來看JMS 中的一次遠程通信的過程: 1.客戶端將請求轉化為符合JMS 規定的Message;2.通過JMSAPI 將Message 放入JMSQueue 或Topic 中;3.如為JMSQueue，則發送中相應的目標Queue 中，如為Topic，則發送給訂閱了此Topic 的JMSQueue。4.處理端則通過輪訓 JMSQueue，來獲取消息，接收到消息後根據JMS 協議來解析Message 並處理。 回答問題: 1.傳輸的標准格式是?JMS 規定的Message。2.怎麼樣將請求轉化為傳輸的流?將參數信息放入Message 中即可。3.怎麼接收和處理流?輪訓JMSQueue 來接收Message，接收到後進行處理，處理完畢後仍然是以Message 的方式放入 Queue 中發送或Multicast。4.傳輸協議是?不限。 基於JMS 也是常用的實現遠程非同步調用的方法之一。
⑶ 什麼是分布式
分布式也就是微服務中的一種體系結構，那麼提到分布式、就要先說說單機和集群
一、單機結構
單機就是所有業務全部寫在一個項目中，部署服務到一台伺服器上，所有請求業務都由這台伺服器處理，顯示，當業務增長到一定程度的時候，伺服器的硬體會無法滿足業務需求，自然而然的想到一個程序步行就部署多個。
二、集群
集群就是單機的多實例，在多個伺服器上部署多個服務，每個服務就是一個節點，部署N個節點，處理業務的能力就提升N倍，這些節點的結合就叫做集群。
負載均衡：協調群里的每個節點均衡地接收業務請求。通俗的講就是服務A和服務B相同時間段內處理的同類業務請求數量是相似的
集群的特點：
擴展性好：集群只是單機的多個復制，沒有改變單機的原有的代碼結構，每次部署新節點只需要復制部署即可。
單個節點業務耦合度高、資源浪費：節點是多個業務處理集合（耦合度高），每個具體業務的訪問量可能差異很大，比如JD上賬戶管理模塊的訪問量肯定低於訂單模塊。
然而賬戶管理模塊和訂單模塊的部署數量是一樣的（因為每個節點里獨有這兩個模塊），相對於訂單模塊來說，部署同樣多的賬戶管理模塊就是浪費。
那就把單機節點不同的業務處理模塊拆開，這就是分布式了。
三、分布式（微服務）
分布式結構就是一個完整的系統，按照業務功能，拆分成一個個獨立的子系統，在分布式結構中，每個子系統就被稱為「服務」。這些子系統能夠獨立運行在Web容器中，他們之間通過RPC方式通信。
舉個例子，假如需要開發一個在線商城。按照微服務的思想，我們需要按照功能模塊拆分成多個獨立的服務，如：用戶服務、產品服務、訂單服務、後台管理服務、數據分析服務等。
這一個個服務都是一個個獨立的項目，可以獨立運行。如果服務之間有依賴關系，那麼通過RPC方式調用。
分布式的優點：
系統之間的耦合度大大降低，可以獨立開發、獨立部署、獨立測試，系統與系統之間的邊界非常明確，排錯也變得相當於容易，開發效率大大提升。
系統之間的耦合性降低，從而系統更易於擴展，我們可以針對性地擴展某些服務，就是對子系統集群。例如：雙十一時，訂單子系統、支持子系統需要集群，賬號管理子系統不需要集群。
服務的復用性更高，比如：我們將用戶系統作為單獨的服務後，該公司所有的產品都可以使用該系統作為用戶系統，無需重復開發。
四、分布式與集群的區別
將一套系統拆分成不同子系統部署在不同伺服器上（這叫分布式）
署多個相同的子系統在不同的伺服器上（這叫集群）
部署在不同伺服器上的同一個子系統應做負載均衡。
分布式：一個業務拆分為多個子業務，部署在多個伺服器上 。
集群：同一個業務，部署在多個伺服器上 。
⑷ 如何自己開發一套伺服器管理系統
轉載表面上看，是一套基於B/S方式實現的分布式管理系統，但其實背後的架構是基於C/S完成的。你以為他是一隻鞋嗎？其實他是一個吹風機。作為界面化的系統，瀏覽器框架是不可或缺的，但更加重要的東西在Socket上面。
一、需要解決中央控制端到各節點伺服器之間的通信。
這個其實牽扯到一個通信協議的問題，各語言都有自己的socket，thread的庫，直接調用即可。但是這個通信協議就需要自己來完成了。既不能太簡單，太簡單了，明碼傳輸，如果別人獲知了這個介面，就很容易執行一些令人討厭的操作。也不能太復雜，太復雜了等於是給自己找麻煩，所以簡單的數據包編解碼的工作或者用token驗證的方式是需要的。通信協議起碼要兩種，一種是傳輸命令執行的協議，一種是傳輸文件的協議。
二、跨語言的socket通信
為什麼要跨語言，主控端和代理端通信，用什麼語言開發其實無所謂。但是為了給自己省事，盡可能使用伺服器上已經有了的默認語言巧彎世，Ambari前期採用phppuppet的方式管理集群，這不是不可以，puppet自己解決了socket通信協議和文件傳輸鬧消的問題，可你需要為了puppet在每台伺服器上都安裝ruby。我是個有點伺服器和代碼潔癖的人。光是為了一個puppet就裝個ruby，我覺得心裡特對不起伺服器的資源。所以我自己寫了一個python的代理端。python是不管哪個linux系統在安裝的時候就都會有了。然後主控端的通信，可以用python實現，也可以用php實現，但是考慮到對於更多的使用者來說，改php可能要比改tornado簡單許多，所以就沒用python開發。hadoop分支版本眾多，發布出去，用戶要自己修改成安裝適合自己的hadoop發行版，就勢必要改源碼，會php的明顯比會python的多。php裡面的model封裝了所有的操作，而python只是個操作代理人的角色而已。
所以也延伸出一個問題，什麼語言用來做這種分布式管理系統的代理端比較合適，我自己覺得，也就是python比較合適了，操作系統自帶，原生的package功能基本夠用。用java和php也可以寫agent，但是你勢必在各節點預先就鋪設好jre或者php運行環境。這就跟為什麼用python和java寫mapred的人最多是一樣的。沒人攔著你用nodejs寫mapred，也可以寫，就是你得在每個節點都裝v8的解釋引擎，不嫌麻煩完全可以這樣干。原理參看map/rece論文，不解釋。perl也是操作系統原生帶的，但是perl的可維護性太差了，還是算了吧。
所以這就牽扯到一個跨語言的socket問題，理論上來說，這不存在什麼問題。但這是理論上的，實際開發過程中確實存在問題，比如socket長連接，通信數據包在底層的封裝方式不同。我沒有使用xml-rpc的原因之一就是我聽說php的xmlrpc跟其他語言的xmlrpc有不同的地方，需要修改才能用,我就沒有用這種辦法。最早是自己定義的操作協議，這時就遇到了這些問題，所以後來直接採用了thrift方式。就基本不存在跨語言的socket通信問題了。
三、代理端執行結果的獲取
無論命令還是文件是否在代理端執行成功，都需要獲取到執行結果返回給中央端。所以這里也涉及一個讀取節點上的stdout和stderr的問題。這個總體來說不是很難，都有現成的包。當然這個時候你需要的是阻塞執行，而不能搞非同步回調。
還有個問題是，我要盡可能使用python默認就帶的包，而盡量不讓伺服器去訪問internet下載第三方的包。
還有代理端最重要的一點，就是python的版本兼容性。centos5用python2.4，centos6用python2.6，ubuntu基本默認都是2.7。所以一定要最大限度的保證語言的跨版本兼容性，要是每個操作系統和每一個版本我都寫一個代理，我一個人就累死了。
四、瀏覽器端的model，view，controller
這裡面你要封裝好所有的通信協議，以及需要在節點上面執行的腳本。發送文件的操作和資料庫孝肢操作也要在model裡面完成。
如果對tcl/tk很熟，也可以寫基於操作系統界面方式的管理，不用瀏覽器就是了。
view對我來說是最痛苦的事，都是現學的jQuery怎麼用，前端的工作太可怕了。關於這方面，沒有太多可描述的，html和js帶給我的只有痛苦的回憶，萬惡的undefined。
五、跨操作系統的安裝文件封裝。
要適應不同的操作系統也是個很麻煩的事情，需要用agent提前獲知操作系統的發行分支，版本號。然後去找到對應的安裝文件去執行。你不能保證一個分布式系統的集群中所有的節點都可以訪問internet，更多的情況是這些節點都存在在一個安全的內網中。只有個別幾個節點是可以訪問外網的。所以，我勢必要把所有的安裝文件以及他們的依賴盡可能集中起來。我不確定安裝操作系統的lzo，yum或者apt-get會去下什麼鬼東西，甚至無論是yum還是apt-get，裡面都沒有hadoop-lzo的庫文件。所以，最好的辦法是自己編譯打包rpm和deb包。直接安裝就好了，別去找repo下載什麼。
這就是第五步工作，把需要的依賴的東西自己編譯打包成rpm和deb。
deb包很好解決，但是rpm就沒那麼好辦了，需要學習rpm的編譯文件如何編寫，這塊是挺麻煩的，但是這玩意用好了還是挺不錯的。現在我自製的安裝包裡面就已經包含了自己編譯的lzo和snappy兩種壓縮庫，以及hadoop-gpl-packaging的rpm和deb。下一個發布的easyhadoop將直接支持centos5,6，suse，以及ubuntu/debian的系統上安裝hadoop。已經自帶了lzo和snappy以及lzop和snzip。
六、把這些所有東西，整合到一個系統裡面。
關聯這些所有事情間的聯系，整合到一個瀏覽器界面裡面去。寫一個分布式的管理腳本不難，寫一個界面也不難，但是也許是我的水平不行，這兩件事結合起來讓他們協同工作還是有點難度的。對我來說，寫界面的工作可能更難一點。
Cloudera可能是十來個人在寫Manager的東西，ambari也是放到github和apachesvn上面，apache基金會的各種committer在寫。easyhadoop沒他們功能那麼強大，一年來只有我一個人設計架構，功能，各種語言的編碼，測試，發布。Fortheloveofgod,WhathaveIdone(英文部分請站在山頂仰天長嘯)?T_T。從前台到後台，到hadoop和生態系統以及他們的依賴軟體的單獨patch、編譯打包。(系統yum或者apt-get的包不如自己打的好使。)
從時間上來看，全球第一款開源的hadoop部署管理系統應該還是屬於ambari，2011年8月開始寫的，2012年9月底進入apache的incubator。我是大概2012年8月開始寫的easyhadoop，全球第一沒趕上，估計國內第一個開源的hadoop管理系統還是可以排上的。