javaweb分布式

⑴ 為什麼javaWeb項目要分層

首先讓我們坐著時光機回到n年前的web開發。
那個時候最早都是靜態的html頁面，後來有了資料庫，有了所謂的動態頁面，
然後程序猿在編碼的時候，會把所有的代碼都寫在頁面上，包括資料庫連接，包括事務控制，接收參數，各種校驗，各種邏輯，各種html/js/css代碼等等
怎麼樣？夠亂吧？像一坨那什麼一樣，這個頁面可能有成千上萬行？

那麼好，問題來了，回頭需要修改的時候，你怎麼辦？
你找個東西找半天，好不容易找到了，還不敢改，怕被其他地方用了，改出連帶問題。
頁面一出錯，定位不準到底是哪裡的問題，從頭到尾的挨個排查。
等等等等。

這就是大家常說的什麼叫可維護性，這也是為什麼越來越多的公司的規范要求不能寫復雜sql。

還記得之前在東軟的時候，一哥們寫了一個80多行的大sql來完成一個核心的查詢。
試問這個大sql天天在資料庫里run，還有性能可言？
再試問誰敢改？
後來項目要改需求還是出現bug了，那個sql要改動，寫sql的哥們改了好久才改好，因為時間長他也忘了，
再後來他離職了。。。

有人問，那簡單sql實現不了我的功能呀，怎麼辦？
從資料庫設計層面開始下手，要允許適當的冗餘，把表弄好，就迎刃而解了，這也是資料庫層面的一種解耦吧。

後來。。。
進入第二階段，大家痛定思痛，決定要把頁面和邏輯拆開，頁面只是負責顯示，邏輯都在後台。
這就出現了短暫的，在jsp里使用標簽調用bean的用法。bean里耦合了除了頁面之外的所有東西。

再後來。。。
進入了第三階段，大家又痛定思痛，決定要拆成三部分，就是大名鼎鼎的MVC。

再再後來。。。
衍生出來了類似於struts/springmvc等等的mvc框架
---------------
JavaWeb項目的層有2個維度。

第一個維度是MVC的三層：
M：model，模型層，包括了你的業務邏輯和資料庫操作，封裝好給視圖層使用的。
V：view，視圖層，僅僅做的是展示數據，不包含業務邏輯，主要是jsp/html等等
C：controller，控制層，負責接收請求，調用模型層處理業務邏輯並返回給視圖層。

第二個維度是java代碼里的三層：
controller：控制層，負責接收參數/解析參數/封裝參數，調用serivce，將service方法的返回值進行封裝（如果需要），返回數據/返回頁面，路由。
service：負責業務邏輯，事務控制在這層里做，被controller調用，以及調用。
：持久層，負責資料庫交互，被service調用。

這2個維度別弄混了喲。我今天主要說的是第二個維度的層喲。
我認為，第二個維度是第一個維度的延伸，其實第二個維度再加上一個表現層就完美了，這就為什麼有人說是4層架構。
---------------
前戲結束，步入正題：

有些學生朋友可能會問為什麼要分層呢？我本來可以在一個地方寫完的東西，非要散落在各個層中，都在一起不是挺好的嗎？
開發效率高呀~
跳來跳去的我腦子都暈啦。。。

這就是為什麼有人會把所有的東西都扔在一個層里，比如controller層。。。

其實我們可以在jsp上把所有的邏輯以及資料庫操作,數據展示全部寫在一起，耦合在一起，這樣開發起來貌似更快，
但是維護性非常差，有朝一日想改一個小地方，牽一發而動全一身，隱患很高，無法快速定位問題。
因此我們需要分層。
分層了之後，你理論上改了持久層的東西，邏輯層是不用變動的。

每個Dao類是跟每個表走，Dao的每個方法里就一個個的簡單sql，不包含任何業務邏輯，可以被不同的service復用和調用。

經過抽象後基本上都是通用的，因而我們在定義DAO層的時候可以將相關的方法定義完畢，
這樣的好處是在對Service進行擴展的時候不需要再對DAO層進行修改，提高了程序的可擴展性。

提高了程序的可擴展性。具體什麼時候做這些操作，怎麼做這些操作都由Service來處理。
（就像郭德綱的相聲里的一句話：「行了，你甭管了」）

而Service則不是，一個Service里可以會調用多個不同的，完成特定的業務邏輯，事務控制，
封裝Service層的業務邏輯有利於通用的業務邏輯的獨立性和重復利用性

同時，一個Service的方法也有可能被多個Controller的方法來調用。

邏輯出問題就在Service找問題，資料庫，sql有問題就在Dao層找問題，
參數解析錯誤，跳轉錯誤，就在Controller上找問題。
這樣快速定位問題，互不幹擾。

---------------
分層架構（這里會延伸到更廣闊的架構）：

回頭項目玩大了，怎麼辦？拆！！！

具體可以搜一下：maven分模塊開發，怎麼玩代碼依賴，怎麼玩微服務，怎麼玩SOA，怎麼玩RPC，怎麼玩bbo。

web項目發展有幾個階段啊

第一個階段（單一應用架構）：
所有代碼都耦合在一個項目里，放在一台伺服器上，這種all in one的方式是有好處的。
創業初期，不用什麼架構，走敏捷開發，最快速的實現需求才是王道。
你甭管我有多爛，我至少能跑起來，我至少能在外網上讓你訪問，讓你使用。
當然了，初期的訪問量很少，節省部署和運維成本才是王道呀。
聽阿里的講座，說淘寶的前期的版本用的就是一台PC機作為伺服器，所有的功能耦合在一個項目里，
每次往生產環境上發版本，要上傳一個600mb的包，呵呵。

第二個階段（垂直應用架構）：
哎喲，不錯哦。自己的兒子被越來越多的人訪問，訪問量激增，一台伺服器扛不住了，
沒事，我們可以玩負載均衡，玩集群。
但是！這種性能加速度其實會變得越來越小，因為你的項目是耦合在一起的。
這時，我們需要拆分項目，這里又有2個維度，按層拆，按模塊拆。
將拆好的不同項目分別部署在不同的伺服器上，並且再分不同的小集群。

第三個階段（分布式服務架構）：
唉呀媽呀，訪問量陡增，到這步你創業應該算成功了，開始燒投資人的錢了吧。
經過上面拆成了越來越多的模塊，模塊與模塊交互越來越多，怎麼辦？
這個時候我們需要把核心的業務抽出來，作為獨立的服務，慢慢發展成穩定的服務中心，
用來提升業務復用和整合。
就像阿里的大牛說過，沒有淘寶的積累，天貓能那麼快的出來嗎？
這個時候，你的緩存，資料庫，消息隊列等服務都應該是分布式的。

第四個階段（流動計算架構）
哎呀媽呀，訪問量又上了一個台階，翻了好幾百倍吖，腫么辦？
這個時候服務越來越多，一些容量和資源的浪費問題凸顯出來，
這時我們需要一個調度中心來基於訪問壓力動態的管理集群容量，
提高利用率。

第五個階段（雲計算架構）
抱歉，作者正在學習中，未完待續。

⑵ java的某些項目為什麼要採用分布式開發什麼是分布式開發那們給解釋一下！

java的某些項目為什麼要採用分布式開發，分布式開發

在資料庫應用程序的開發過程中，網路已走到社會的各個角落。從金融行業的銀行聯網、交通行業的售票系統、公安系統的全國戶籍管理等等，這些企業或行業單位之間地理分布性或業務分布性，使得一個企業或行業擁有多個網路伺服器，如何在這種分布式的網路環境下實現高效的資料庫應用程序的開發是一個重要的問題。

分布式應用開發簡單的說，是指將用戶界面、控制台服務、資料庫管理三個層次部署在不同的位置上。其中用戶界面是客戶端實現的功能，控制台服務是一個專門的伺服器，數據管理是在一個專門的資料庫伺服器上實現的。

提示：這里的Web伺服器，都是指軟體（如IIS等Web伺服器軟體），它和Web伺服器應用以及其它程序等，共同存在於伺服器計算機上。

控制台CGI應用：是一個獨立的控制台EXE。它在一個標准輸入設備上接收客戶端的請求信息，在標准輸出設備上將結果返回給伺服器。

⑶ 在javaweb中怎麼寫分布式人工智慧標記語言

通過實現ServletContextListener就可以拿到：
public class wwww implements ServletContextListener{
@Override
public void contextDestroyed(ServletContextEvent sce) {
// TODO Auto-generated method stub

}

@Override
public void contextInitialized(ServletContextEvent sce) {
String path = sce.getServletContext().getRealPath("/");
}
}

//你還得到web.xml裡面配置一下,具體網路

⑷ java分布式web系統如何做分布式事務控制

用過spring沒，用Spring的AOP技術能很好的將事物隔離出來。 Spring聲明式事務讓我們從復雜的事務處理中得到解脫。 使得我們再也無需要去處理獲得連接、關閉連接、事務提交和回滾等這些操作。再也無需要我們在與事務相關的方法中處理大量的try…catch…finally代碼。

⑸ 開發基於Java的分布式WEB應用，你需要什麼樣的框架支持討論第4頁:

Agrael
寫道andot
寫道Agrael
寫道大家一直說EJB重，我不解，EJB到了3.0還重？我看到帖子都只說EJB重，卻不說重在什麼地方。就我個人而言，EJB2.X不談，EJB3.x絕對不重，反而有向輕量發展的趨勢。可能是EJB最初給人留下的印象太差了，以至於現在沒人去關注新的EJB了。我覺得要推廣新的輕量級的EJB，改個名字可能是個好辦法。不過在國外EJB3.x卻很流行。但是在中國卻很少有人用。不僅在國外，大公司對EJB非常重視，程度要高於SSH之類的。

⑹ Java-JAVA中都有哪幾種分布式實現方式，各有什麼優缺點

常用的有EJB、rmi、Web Service，還有Hessian、NIO等，它們的優缺點比較比下：
1：EJB
優勢：可擴展性好，安全性強，支持分布式事務處理。
劣勢：不能跨語言；配置相對復雜，不同J2EE容器之間很難做無縫遷移。
2:rmi
優勢：面向對象的遠程服務模型；基於TCP協議上的服務，執行速度快。
劣勢：不能跨語言；每個遠程對象都要綁定埠，不易維護；不支持分布式事務JTA,RMI框架對於安全性、事務、可擴展性的支持非常有限。
3： Web Service
優勢：跨語言、跨平台，SOA思想的實現；安全性高；可以用來兼容legacy系統的功能
劣勢：性能相對差，不支持兩階段事務
4：Hessian
優勢：使用簡單，速度快；跨語言，跨平台；可以用來兼容legacy系統的功能。
劣勢：安全性的支持不夠強，不支持兩階段事務。
5：NIO(Mina/Netty)
優點：基於TCP通信，效率上高於HTTP的方式，非阻塞IO應對高並發綽綽有餘。根據具體的需要制定數據傳輸的格式，可擴展性強。
缺點：不能跨語言，無法穿透防火牆。

⑺ javaEE和javaweb的區別是什麼

Javaweb與javaee的區別：

通過以上描述我們可以看出，JavaEE包括一些流行框架的使用，比如Spring、SSM、SSH、Struts2等，Java EE運行在一個完整的應用伺服器上，用來開發大規模、分布式、健壯的網路應用，目前呢，像政府、銀行、各大企業都會選擇Java EE進行開發，不僅安全、穩定，應用起來也廣泛。

Java Web，是用Java技術來解決相關web互聯網領域的技百術總和。web包括：web伺服器和web客戶端兩部分。

Java在客戶端的應用有java applet不過現在使用的很少，Java在伺服器端的應用非常的豐富，比如Servlet，JSP，Html和MVC設計模式等等。Java技術對Web領域的發展注入版了強大的動力。

⑻ Java Web如何實現分布式 將網站分成多個功能點在多台伺服器上發布！

調介面傳輸數據，包括用戶信息都可以做各個系統間的映射。當然設計階段就應該做到單點登錄即改一端密碼同步改幾端這種事

⑼ 什麼是分布式感謝分享,百度能搜到的概念性的東西就不要貼了 java開發的web網站怎麼實現分布式

分布式概念還是簡單的吧，主要是理解為什麼要分布式，和分布式主要做什麼。
首先分布式的主要作用有以下幾點：
1、提高應用的可用性：伺服器要保持長時間能夠有效的使用，但是現實情況又是很不穩定的，例如電腦會死機，會斷電，硬體設備會損壞，使用分布式可以一定程度的解決這些問題。
2、分散伺服器運行壓力，這本身也是提高應用可用性的一個方面，例如你的應用功能很多，邏輯很復雜，或者操作的數據量較大，單個應用或者機器難以甚至無法處理你的業務，那麼就需要使用分布式。
分布式的概念其實也很簡單，就是一個應用做不了或者難以做的事情，讓多個應用去做，這就好比讓一個人去完成的事情讓多個人去完成，舉個現實中很簡單的例子，例如造車，造車這個工作本身一個造車廠可以完成這個任務，只是一個工廠造車，成本、技術、人員等等都會提高製作成本，而且因為技術過於駁雜，一個廠能造，但是成本和難度都會增加，但是拆分給多個廠來造車，例如一個廠造發動機，一個廠造底盤，一個廠造外殼，一個廠做電子儀表盤等等，把各個配件分散給不同的廠製作，這樣每個廠專心做自己更專業的事情，這樣既降低了成本，有提高了工作效率。
回到我們的web應用，一般來說，一個系統就是一個應用，系統裡面有各種功能，例如學生信息管理系統，系統裡麵包含各種功能，例如用戶登錄和認證、許可權配置和授權、學生信息的管理、學生的入學管理、學生的畢業管理、校友信息管理等等各種功能，但是當學生的數量特別多，內部業務邏輯特別復雜的時候，一個應用可能不能夠承擔起這個系統的正常運轉，那麼就可以考慮分布式，來使用多個應用完成這個系統的功能，例如做一個應用負責登錄認證模塊，一個應用處理授權的功能，另外一個應用處理學生信息的內容等等。
總結分布式，其實就是一個應用的事情讓多個應用來解決，分布式是應用級別的分工，在一台機器的多個應用，我們叫垂直分布式，在多台機器上的分布式叫水平分布式，在一台機器的分布式實現起來比較簡單，只需要實現應用之間的內存數據共享即可，內存數據共享方式很多，可以使用共享文件等等方式，多台機器的分布式就需要藉助網路通信來共享數據，如果是通語言同技術的應用，可以直接共享內存數據，如果是不同語言的分布式應用，就需要參照一些通用傳輸協議的數據，例如xml json。