記得Martin大叔在《企業(yè)應(yīng)用架構(gòu)模式》中特別強調(diào)：“能夠不分布式的應(yīng)用就不要分布式”，這句話沒什么問題，尤其對于做過分布式應(yīng)用的人而言，就更會有深刻的體會了，但這個世界偏偏就沒有那么簡單，大多數(shù)人都會碰到分布式應(yīng)用的場景，尤其是對于大型應(yīng)用而言，從集中式步入分布式是不可避免的，只是也許是小型分布式的，也許是大型分布式的;也許是有高性能要求的，也許是沒有的，在這篇blog中我們來看看java應(yīng)用從集中式步入分布式后到底會帶來些什么挑戰(zhàn)。

　　blog按照應(yīng)用從集中式演變?yōu)榇笮颓腋咝阅艿膽?yīng)用的過程來敘述，這也是因為這幾類應(yīng)用對于設(shè)計、開發(fā)人員的要求也是從低到高的。

　　Level 1：小型分布式應(yīng)用

　　對于做習(xí)慣了集中式應(yīng)用的同學(xué)而言，當碰到小型分布式應(yīng)用場景時，最明顯的問題就是如何和遠程的系統(tǒng)通訊，如何發(fā)消息給遠程的系統(tǒng)，告訴它做什么事情，并且得到事情處理的結(jié)果，對于java開發(fā)人員而言，更習(xí)慣的考慮方式也許是如何去調(diào)用遠程系統(tǒng)提供的接口，在集中式的應(yīng)用中可以采用A a=new AImpl();這樣的方式調(diào)用，但遠程就沒辦法這么調(diào)用了。

　　在小型分布式應(yīng)用中，最需要解決的就是上面所說的遠程系統(tǒng)通訊以及遠程系統(tǒng)調(diào)用的問題了，為此就得學(xué)習(xí)相關(guān)的知識體系。

　　對于遠程系統(tǒng)通訊而言，至少應(yīng)該知道下TCP/IP、UDP/IP是個大概什么樣的概念，BIO/NIO是什么概念，另外就是需要知道下基于java如何去實現(xiàn)tcp/ip+BIO(NIO)、udp/ip+BIO(NIO)的通訊，相應(yīng)的會需要了解下Java序列化、服務(wù)器端采用線程池方式處理等知識，在掌握了這些知識后，基本上做一個小型的java遠程通訊的應(yīng)用不會有什么太大的問題。

　　對于通過遠程系統(tǒng)調(diào)用就可實現(xiàn)的小型分布式應(yīng)用而言，也許更為簡單，可以只掌握怎么用spring-remoting、axis或hessian這類的框架就可以了，直接就可實現(xiàn)，當然，如果能了解下rmi、webservice是什么機制就更好了，另外，畢竟遠程調(diào)用很難做到完全和本地調(diào)用一樣，盡管所有的遠程調(diào)用框架都想做到完全透明，但遠程調(diào)用時僅僅異常就比本地調(diào)用會多出好幾種來，例如網(wǎng)絡(luò)異常、超時異常等，因此在調(diào)用遠程系統(tǒng)時，需要明確的了解這些異常的區(qū)分，當然，或者可以認為都是同樣的遠程業(yè)務(wù)異常，但在追查錯誤時，則需要明確區(qū)分。

　　從上面這些知識點可以看出，應(yīng)用即使是從集中式應(yīng)用步入小型分布式應(yīng)用，無論是對于開發(fā)、部署還是測試而言，都復(fù)雜了很多。

　　Level 2：高性能分布式應(yīng)用

　　對于高性能分布式應(yīng)用而言，要求就高很多了，因為要做到高性能，僅了解怎么用是不夠的，通訊和調(diào)用方面的技術(shù)都需要了解到底層的具體機制和實現(xiàn)。

　　對于遠程通訊方式的分布式應(yīng)用而言，需要了解BIO/NIO具體有什么不同，具體機制是怎么樣的，以及使用或參考目前主流的通訊框架，像mina、grizzly等，看看它們在做NIO實現(xiàn)時有什么高超的技巧，除了了解這些外，還需要掌握線程池應(yīng)如何配置;長連、短連什么概念，如何實現(xiàn);連接怎么管理;序列化如何優(yōu)化等等。

　　對于遠程調(diào)用的分布式應(yīng)用而言，則在上面的基礎(chǔ)上，還需要了解rmi、webservice等的實現(xiàn)機制是怎么樣的，另外就是spring-remoting、hessian、axis的實現(xiàn)機制是怎么樣的，有什么可改進的地方，在明確了可改進的地方后需要自己選擇相應(yīng)的方案去實現(xiàn)。

　　從上面這些知識點可以看出，要寫出高性能的分布式應(yīng)用真的不是蓋的，確實挺困難的。

　　Level 3：大型高性能分布式應(yīng)用

　　對于大型高性能分布式應(yīng)用而言，難度就較之之前兩個level更大很多，它面臨的問題非常的多：

　　1、穩(wěn)定性的問題

　　對于大型分布式應(yīng)用而言，保持穩(wěn)定是其重點，要做到穩(wěn)定，就必須對整個應(yīng)用的通訊過程的實現(xiàn)技術(shù)有全面的了解，以能夠做到在使用時盡量的正確，另外就是當出現(xiàn)問題時能夠盡快的查明原因。

　　2、統(tǒng)一、標準通訊的問題

　　大型分布式應(yīng)用必然會涉及到很多種不同的應(yīng)用，應(yīng)該能夠做到對于任何的應(yīng)用都采用同樣的方式進行通訊或調(diào)用，這樣才能確保使用的簡單。

　　3、分布式事務(wù)的問題

　　當應(yīng)用變成大型分布式應(yīng)用后，分布式事務(wù)的問題會不可避免的出現(xiàn)，而且這個時候還要求做到高性能，因此通常是不能用傳統(tǒng)的數(shù)據(jù)庫事務(wù)來實現(xiàn)的，目前對于大型應(yīng)用的分布式事務(wù)而言，流行的有BASE和CAP策略，和傳統(tǒng)的ACID策略不同。

　　4、如何管理這些應(yīng)用的問題

　　大型分布式應(yīng)用，意味著應(yīng)用非常的多，在這樣的場景下，怎么樣管理好這么多的應(yīng)用呢，例如這些應(yīng)用之間的依賴關(guān)系是怎么樣的，應(yīng)用運行期的狀況是怎么樣的等等。

　　還有很多各種各樣的問題，因此，我們更要說，要做個能支撐大型高性能的分布式應(yīng)用真的非常非常的不容易，對于實現(xiàn)大型分布式應(yīng)用而言，目前SOA是個可參考的思想，但其具體如何實現(xiàn)就需要各位架構(gòu)師根據(jù)情況來做出具體的選擇了。

　　從以上簡單的描述來看，可以看出，分布式應(yīng)用比集中式應(yīng)用真的難很多，至少它是在原有的集中式應(yīng)用的基礎(chǔ)上增加了更多的挑戰(zhàn)和對于知識體系的更高的要求，當然，對于大型應(yīng)用而言，它帶來的好處也是非常明顯的，因此就讓我們痛并快樂著吧。