A. java的框架有哪些

Java框架可以來簡化開發難自度，更便於我們開發程序。所以學好Java框架還是比較重要的。
Java的框架主要有：SpringMVC、Spring、Mybatis、Dubbo、Maven、RabbitMQ、Log4j、Ehcache、Redis、Shiro。
不過這十個我們不需要都學會，只要學會其中四五個比較常用的就可以。
第一個，SpringMVC。Spring MVC是一種基於Java地實現了Web MVC設計模式的請求驅動類型的輕量級Web框架，主要是幫助我們簡化日常的Web開發;
第二個，Mybatis。MyBatis 是支持普通 SQL查詢，存儲過程和高級映射的優秀持久層框架;
第三個，Spring。Spring深得企業的青睞;
第四個，Maven。越來越多的開發人員開始使用maven。
掌握以上四種框架，你在找工作的時候就會比較吃香。

B. 什麼是java架構

問題有點大，不知從何入手。
我就以我個人觀點瞎說吧。

一、語法的構成，java和c、c++沒啥太大的差別
在程序的控制方面：
循環（for,while），分歧（if,whish），頭文件（改成引入包），預處理指令貌似是取消了，
內存控制方面：
java與c最大的不同是無法直接操作指針，使得java程序更安全，
java採用了資源回收機制，自動清理內存中被丟棄的碎片，
模塊關系：
java是單向繼承，這樣防止了程序模塊之間的關系過於復雜。
java廣泛採用介面，超級介面，超級父類來規范和擴展程序功能。

二、從執行環境來看：
眾所周知，java程序是依託於虛擬機來執行的，這樣編譯過的java代碼不是真正意義的可以運行的代碼，而是一個介於兩者之間的中立體，這樣就可以在任何平台上互補沖突的執行而不犯錯誤這也是java最大的特點之一。

三、API以及擴展
java基本功能都依賴於核心函數庫（類庫，方法庫）來執行。所有基本方法和類，都可以在api文檔中查看，並且為了功能擴展，java支持導入新的api

C. java的架構有哪些

Java架構：

軟體架構作為一個概念，體現在技術和業務兩個方面。
從技術角度來說：軟體架構隨著技術的革新不斷地更新其內容，軟體架構建立於當前技術和一些基本原則的基礎之上。
先說一些基本原則：
分層原則：分層是為了降低軟體深度復雜性而使用的關鍵思想，就像社會有了階級一樣，軟體有了層次結構。
模塊化原則：模塊化是化解軟體廣度復雜的必然手段，模塊化的目的就是讓軟體分工。
介面實現分離原則隨著軟體模塊化的不斷深入改進，面向介面編程而不是面向實現編程可以讓復雜度日趨增高的軟體降低模塊之間的耦合度，從而讓各模塊更輕松改進。從這個原則出發，軟體也從微觀進行了細致的規范化。
還有兩個比較小但很重要的原則：
細節隱藏原則很顯然把復雜問題簡化，把難看的細節隱去，能讓軟體結構更清晰。其實這個原則使用很普遍，java/c++語言中的封裝原則以及設計模式中的Facade（外觀）模式就很能體現這個原則的精神。
依賴倒置原則隨著軟體結構的進一步發展,層與層之間、模塊與模塊之間的依賴逐漸加深，而層、模塊的動態可插拔要求不端增大。依賴倒置原則可看視為介面實現分離原則的深化，根據此原則的精神，軟體進入了工具時代。這個原則有點類似於知名的好萊塢法則：Don't call us, we'll call you。

以上這些原則奠定了我們的軟體架構的價值指標。但軟體架構畢竟是建立在當前技術之上的。而每一代技術都有架構模式。過去的不再說了，讓我們現在就來看一下當前流行的技術，以及當前我們能採用的架構。

因為面向對象是當前最流行開發技術，且設計模式的大量使用使面向對象的走向成熟，而資料庫是當前最有效的存儲結構、web界面是當前最流行的用戶介面，所以當前最典型的三層次架構就架構在以上幾項技術的基礎之上，用資料庫作存儲層、用面向對象來實現業務層、用web來作為用戶介面層。我們從三層次架構談起：
因為面向對象技術和資料庫技術不適配，所以在標准三層次架構的基礎上，我們增加了數據持久層，來管理O-R雙向映射，但目前一直沒有最理想的實現技術。cmp和entity bean技術因為其實現復雜，功能前景有限，已接近被淘汰的邊緣。JDO及hibernate作為o-r映射的後期之秀，尤其是hibernate，功能相當完備。推薦作為持久層的首選
在業務層,因為當前業務日趨負載，且變動頻繁，所以我們必須有足夠敏捷的技術來保證我們的適應變化的能力，在標准j2ee系統中session bean負責業務處理，且有不錯的性能表現，但採用ejb系統對業務架構模式改變太大，且其復雜而昂貴，業務代碼移植性差。而spring 作為一個bean配置的輕量級架構，漂亮的IOC模式實現，對業務架構影響小，所以推薦作為中間層業務框架。
在用戶結構層,雖然servlet/jsp/jstl/javaBean 能夠實現MVC架構,但終究過於粗糙。struts對MVC架構的實現就比較完美，Taperstry也極好地實現MVC架構，且採用基於事件的方式，非常誘人，惜其不夠成熟，我們仍舊推薦struts作為用戶介面層基礎架構。
因為業務層是三層次架構中最有決定意義的，所以讓我們回到業務層細致地分析一下，在復雜的業務我們常常需要以下基礎服務的一種或幾種：事務一致性服務acid(tool:jta/jts)、並發加鎖服務concurrent&&lock、池化管理服務cache、訪問控制服務(tool:jaas)、流程式控制制服務workflow、動態實現服務IOC，串列化消息服務(tool:jms)、負載平衡服務blance等。如果我們不採用重量級應用伺服器(如weblogic,websphere,jboss等)及重量級組件(EJB)，我們必須自己實現其中一些服務。雖然我們大多情況下，不需要所有這些服務，但實現起來卻非易事。幸運的是我們有大量的開源實現代碼,但採用開源代碼卻常常是件不輕松的事。

隨著xml作為結構化信息傳輸和存儲地位日漸重要,一些xml文檔操作工具(DOM,Digester,SAX等)的使用愈發重要,而隨著xml schema的java binding工具(jaxb,xmlbean等)工具的成熟，採用xml schema來設計xml文檔格式,然後採用java binding來生成java bean 會成為主要編程模式,而這又進一步使數據中心向xml轉移,使在中小數據量上,愈發傾向於以xquery為查詢語言的xml資料庫。最近還有一個趨勢,microsoft,ibm等紛紛大量開發中間軟體如(microsoft office之infopath)，可以直接從xml schema 生成 錄入頁面等非常實用的功能。還有web service 的廣泛應用，都將對軟體的架構有非常重大的影響。至於面向服務架構(SOA)前景如何，三層次架構什麼時候走入歷史，現在還很難定論。

aop的發展也會對軟體架構有很深的影響，但在面向對象架構里，無論aspectJ還是jboss-aop抑是aspectWerks、nanning都有其自身的嚴重問題:維護性很差,所以說它將很難走遠。也許作為一個很好的思想，它將在web service里大展身手。

rdf,owl作為w3c語義模型的標志性的語言,也很難想像能在當前業務架構發揮太大影響。但如果真如它所聲稱那樣，廣泛地改變著信息的結構。那麼對軟體架構也會有深遠影響。

有關架構設計的一些忠告：
盡量建立完整的持久對象層.可獲得高回報
盡量將各功能分層,分塊,每一模塊均依賴假定的其它模塊的外觀
不能依賴靜態數據來實現IOC模式，應該依賴數據特徵介面，靜態數據僅是數據特徵介面實現方式之一
架構設計時xml是支持而不是依賴.但可以提供單一的xml版本的實現

從業務角度說：軟體架構應是深刻體現業務內部規則的業務架構，但因為業務變化頻紝，所以軟體架構很難保持恆定不變，但業務的頻繁變化不應是軟體架構大規模頻繁變化的原因，軟體架構應是基於變化的架構。
一種業務有其在一段時間內穩定存在的理由(暫且不談)，業務內部有許多用例，每一種用例都有固定的規則，每一規則都有一些可供判定的項，每一項從某一維度來觀察都是可測量的，我們的架構首先必須保證完美適應每一項每一種測量方式，很多失敗的架構都是因為很多項的測量方式都發生變更這種微觀變化中。

每個用例都有規則，我們在作業務用例分析，常常假定一些規則是先驗的，持久穩定的，然而後來的業務改變常常又證明這種看法是錯誤的，然而常常我們的架構已經為之付出了不可挽回的代價。大量事實證明：規則的變化常常用例變化的根本原因。所以我們的架構要盡可能適應規則的變化，盡可能建立規則模版。

每個用例都關系著不同的角色。每一個用例的產生都必然是因為角色的變更（注意：不是替換，而是增強或減弱），所以注意角色的各種可能情況，對架構的設計有舉足輕重的意義。在我們當前的三層架構里，角色完美地對應介面概念。

在一個系統里很多用例都相互關聯,考慮到每個用例均有可能有不同的特例，所以在架構設計中，盡量採用依賴倒置原則。如架構許可可採用消息通信模式(JMS)。這樣可降低耦合度。

現在我們談一下業務穩定存在理由對業務的影響。存在即是合理，在這里當然是正確的。業務因人而存在，所以問業務存在的理由即是問不同角色的需要這項業務的理由以及喜歡不喜歡當前業務用例的理由，所有這樣的角色都應該在系統里預留。《待續》
在架構設計中有幾個原則可以考慮：
用例盡量細分
用例盡量抽象
角色盡量獨立
項測量獨立原則
追求簡單性
這里未提供相關的例子，例子會在以後的更新時提供。

業務和模式之間的關系
業務中的一些用例之間的關系常常和一些常規的模式很相似。但隨著時間的演化，慢慢地和先前的模式有了分歧。這是個正常的現象。但這對系統架構卻要求非常高，要求系統架構能適應一些模式的更替。在這里我們盡可能早地注意到用例之間的相互角色變化，為架構更新做好准備.

D. java的三大框架是什麼,功能各是什麼

常說的三大框架指：SSH，即：Spring、Struts、Hibernate。

Spring：功能強大的組件粘合濟，能夠將你的所有的java功能模塊用配置文件的方式組合起來成為一個完成的應用。Spring是一個解決了許多在J2EE開發中常見的問題的強大框架。Spring提供了唯一的數據訪問抽象，包括簡單和有效率的JDBC框架，極大的改進了效率並且減少了可能的錯誤。Spring的數據訪問架構還集成了Hibernate和其他O/R mapping解決方案。Spring還提供了唯一的事務管理抽象，它能夠在各種底層事務管理技術。

Struts：把Servlet、JSP、自定義標簽和信息資源(message resources)整合到一個統一的框架中，開發人員利用其進行開發時不用再自己編碼實現全套MVC模式，極大的節省了時間，所以說它是大名鼎鼎的功能強大的MVC架構。

Java由四方面組成：Java編程語言，即語法。Java文件格式，即各種文件夾、文件的後綴。Java虛擬機(JVM)，即處理*.class文件的解釋器。Java應用程序介面(Java API)。

E. JAVA的框架都有哪些

Spring Struts Hibernate（也就是SSH框架）來 Ibatis(持久層框架) JSF(事件驅動自 國內真實項目使用並不多 國外比較流行) WebWork(Struts2已經與其進行集成) JDon(第一個國產框架 已收入JAVA網站) Terasoluna(日本NTTDATA框架,基於Struts 同時還有Finaruna 用於商務系統業務開發)
我主要使用這些 JAVA框架很多 你可以根據自己喜好 選一個很好的來學習 不必要全部學精通
使用最多的應該是Struts 但並不是說他好 只是 他的學習度低 開發成本低 當然Struts2已經比1有很大提高

F. java架構有哪些

主流框架還是MVC框架技術
1：+servlet+javaben適用於比較小的項目
2：strut+spring+hibnate
目前這是主流框架技術組合在一起就是ssh了
適用於要求可維護性強的框架技術
3：ejb jsf等重量級框架技術比較過時
WebWork 【Java開源 Web框架】
WebWork 是由OpenSymphony組織開發的，致力於組件化和代碼重用的拉出式MVC模式J2EE Web框架。WebWork目前最新版本是2.1，現在的WebWork2.x前身是Rickard Oberg開發的WebWork，但現在WebWork已經被拆分成了Xwork1和WebWork2兩個項目。 Xwork簡潔、靈活功能強大，它是一個標準的Command模式實現，並且完全從web層脫離出來。 Xwork提供了很多核心功能：前端攔截機（interceptor），運行時表單屬性驗證，類型轉換，強大的表達式語言（OGNL – the Object Graph Notation Language），IoC（Inversion of Control倒置控制）容器等。 WebWork2建立在Xwork之上，處理HTTP的響應和請求。WebWork2使用ServletDispatcher將HTTP請求的變成 Action(業務層Action類), session（會話）application（應用程序）范圍的映射，request請求參數映射。WebWork2支持多視圖表示，視圖部分可以使用 JSP, Velocity, FreeMarker, JasperReports，XML等。在WebWork2.2中添加了對AJAX的支持，這支持是構建在DWR與Dojo這兩個框架的基礎之上.【EclipseWork：用於WebWork輔助開發的一個Eclipse插件】
Struts 【Java開源 Web框架】
Struts 是一個基於Sun J2EE平台的MVC框架，主要是採用Servlet和JSP技術來實現的。由於Struts能充分滿足應用開發的需求，簡單易用，敏捷迅速，在過去的一年中頗受關注。Struts把Servlet、JSP、自定義標簽和信息資源(message resources)整合到一個統一的框架中，開發人員利用其進行開發時不用再自己編碼實現全套MVC模式，極大的節省了時間，所以說Struts是一個非常不錯的應用框架。【StrutsIDE：用於Struts輔助開發的一個Eclipse插件】
Hibernate 【Java開源 持久層框架】
Hibernate 是一個開放源代碼的對象關系映射框架，它對JDBC進行了非常輕量級的對象封裝，使得Java程序員可以隨心所欲的使用對象編程思維來操縱資料庫。 Hibernate可以應用在任何使用JDBC的場合，既可以在Java的客戶端程序實用，也可以在Servlet/JSP的Web應用中使用，最具革命意義的是，Hibernate可以在應用EJB的J2EE架構中取代CMP，完成數據持久化的重任。Eclipse平台下的Hibernate輔助開發工具:【Hibernate Synchronizer】【MiddlegenIDE】
Quartz 【Java開源 Job調度】
Quartz 是OpenSymphony開源組織在Job scheling領域又一個開源項目,它可以與J2EE與J2SE應用程序相結合也可以單獨使用。Quartz可以用來創建簡單或為運行十個，百個，甚至是好幾萬個Jobs這樣復雜的日程序表。Jobs可以做成標準的Java組件或 EJBs。Quartz的最新版本為Quartz 1.5.0。
Velocity 【Java開源 模板引擎】
Velocity 是一個基於java的模板引擎（template engine）。它允許任何人僅僅簡單的使用模板語言（template language）來引用由java代碼定義的對象。當Velocity應用於web開發時，界面設計人員可以和java程序開發人員同步開發一個遵循MVC架構的web站點，也就是說，頁面設計人員可以只關注頁面的顯示效果，而由java程序開發人員關注業務邏輯編碼。Velocity將java代碼從web頁面中分離出來，這樣為web站點的長期維護提供了便利，同時也為我們在JSP和PHP之外又提供了一種可選的方案。 Velocity的能力遠不止web站點開發這個領域，例如，它可以從模板（template）產生SQL和PostScript、XML，它也可以被當作一個獨立工具來產生源代碼和報告，或者作為其他系統的集成組件使用。Velocity也可以為Turbine web開發架構提供模板服務（template service）。Velocity+Turbine提供一個模板服務的方式允許一個web應用以一個真正的MVC模型進行開發。 【VeloEclipse ：Velocity在Eclipse平台下的一個輔助開發插件】
IBATIS 【Java開源 持久層框架】
使用ibatis 提供的ORM機制，對業務邏輯實現人員而言，面對的是純粹的Java對象， 這一層與通過Hibernate 實現ORM 而言基本一致，而對於具體的數據操作，Hibernate 會自動生成SQL 語句，而ibatis 則要求開發者編寫具體的SQL 語句。相對Hibernate等 「全自動」ORM機制而言，ibatis 以SQL開發的工作量和資料庫移植性上的讓步，為系統設計提供了更大的自由空間。作為「全自動」ORM 實現的一種有益補充，ibatis 的出現顯 得別具意義。

G. 介紹下Java程序的結構

Java語言是面向對象的程序設計語言，Java程序的基本組成單元是類，類體中又可包括屬性與方法兩部分。而每一個應用程序都必須包含一個main（）方法，含有main（）方法的類稱之為主類。


一： Java程序的主類及其格式

作為一個可以獨立運行的Java程序，在它的眾多類中必須要有一個類作為程序的起始類，為了方便，本書把這個類稱為主類。當需要執行一個程序時，人們在java命令後面輸入的便是這個主類的文件名（也是主類名），因此主類文件是Java運行環境建立起來之後第一個被裝入虛擬機的用戶文件。為了使虛擬機可以找到程序運行的起始入口，主類必須為public類，並含有一個在格式上符合約定的入口方法main（），其格式如下：

public static void main（String[] args）{

…

}

其中各參數含義如下。

main:入口方法名稱。

args:命令行參數，這是一個String對象數組。

static:修飾字，說明main（）是一個靜態方法（類方法）。

public:修飾字，說明main（）具有公有訪問屬性。

於是，主類框架的源代碼如下：

public class 主類名{

…

public static void main（String[] args）{

…

}

}

Java程序的主類常常使熟悉C/C++的讀者感到迷惑：main（）方法不就相當於C/C++程序中的主函數嗎，為什麼非得把它放到一個類里，難道它有什麼不同嗎？

沒錯，Java類中main（）方法就相當於C/C++程序中的主函數，是一個入口函數。之所以把它封裝到一個類里，而不像C/C++那樣單獨作為一個函數來處理，就本書作者的理解，大概Java的設計者們有如下幾個方面的考慮。

1）Java既然把所有事物都看成了對象，那麼就沒有理由不把程序也看成對象，因為程序也是一種事物。既然是對象，那麼它就應該屬於某個類並以程序名來命名。既然程序是一種類，那麼main（）就應該是這個類的一個方法，只不過它有些特殊，它是一個入口方法，並且對它有些特殊規定，例如其名稱必須為main（），必須是公有靜態方法，有命令行參數等。

2）如果把程序封裝成了類，那麼包括本程序在內的任何程序就都可以根據需要，隨時創建這個類的對象，並通過該對象使用這個類中的資源，這樣就便於資源共享，從而提高程序的靈活性。

3）Java程序是一種以類為基本單位的模塊化程序，程序被編譯後，每一個類會對應生成一個二進制位元組碼類文件。如果把程序也封裝成類，那麼它的文件就與其他類文件統一起來，而不會產生其他類型的文件，因而便於管理。

4）之所以把入口方法封裝到類中，其根本目的就是要盡可能平等地看待所有的類。因為Java的最終目的是要以類為基本模塊來實現可裝配軟體，如果把main（）方法封裝到了一個類中，那麼就意味著main（）與類的其他方法沒什麼本質區別，只不過是分工不同而已。下面很快就會看到，Java的所有類都可以含有一個入口方法而成為主類。也就是說，在Java程序中根本就沒有主類、次類之分，這里之所以把帶有main（）方法的類稱為主類，是為了表達方便。


二： JAVA源程序在命令行下的運行

classBank{
publicvoidinit（）{
System.out.println（"Yes,Ican"）；
}
publicstaticvoidmain（Stringargs[]）{
BankAccountba1=newBankAccount（100.00）；
System.out.print（"Beforetransactions,"）；
ba1.display（）；
ba1.deposit（74.35）；
ba1.withdraw（20.00）；
System.out.print（"Aftertransactions,"）；
ba1.display（）；
Bankb=newBank（）；
b.init（）；
}
}
classBankAccount{
privatedoublebalance;
publicBankAccount（doubleopeningBalance）{
balance=openingBalance;
}
publicvoiddeposit（doubleamount）{
balance+=amount;
}
publicvoidwithdraw（doubleamount）{
balance-=amount;
}
publicvoiddisplay（）{
System.out.println（"balance="+balance）；
}
}

三：完整的java源程序應該包括下列部分

package語句；

import語句；

public classDefinition; // 公共的類定義部分，至多隻有一個公共類的定義

// java語言規定該java源程序的文件名必須與該公共類名完全一致

classDefinition; // 類定義部分，可以有0個或多個

interfaceDefinition; // 介面定義部分，可以有0個或多個

package:java編譯器為每個類生成一個位元組碼文件，且文件名與類名相同，這就會帶來一個問題：同名的類會發生沖突。package便可管理類命名空間。

一般地，具有相同功能的類放在一個package中。

一個java源程序至多隻能有一個公共類的定義。

若java源程序有一個公共類的定義，則該源文件名字必須與該公共類的名字完全相同。

若源程序中不包含公共類的定義，則該文件名可以任意取名。

若一個源程序中有多個類定義，則在編譯時將為每個類生成一個。class文件。

三。java編程規范

包名：全小寫的名詞，中間可由點分割，eg:java.awt.event

類名：首字母大寫，多個單詞合成，每個單詞首字母也要大寫，eg: class HelloWorldApp

介面名： 同類名，eg: interface Collection

方法名： 由多個單詞合成，第一個單詞通常為動詞，首字母小寫，中間的每個單詞的首字母都要大寫，eg: balanceAccount, isButtonPressed

變數名： 全小寫，一般為名詞，eg: length

常量名： 基本數據類型的常量名為全大寫，如果由多個單詞構成，可以用下劃線隔開，eg: int YEAR, int WEEK_OF_MONTH

對象類型的常量，則是小寫混合，由大寫字母把單詞隔開

H. Java的技術架構有哪些

服務分離

隨著系統的的上線，用戶量也會逐步上升，很明顯一台伺服器已經滿足不了系統的負載，這時候，我們就要在伺服器還沒有超載的時候，提前做好准備。

由於我們是單體架構，優化架構在短時間內是不現實的，增加機器是一個不錯的選擇。這時候，我們可能要把應用和資料庫服務單獨部署，如果有條件也可以把文件伺服器單獨部署。

反向代理

為了提升服務處理能力，我們在Tomcat容器前加一個代理伺服器，我一般使用Nginx，當然你如果更熟悉apache也未嘗不可。

用戶的請求發送給反向代理，然後反向代理把請求轉發到後端的伺服器。

嚴格意義上來說，Nginx是屬於web伺服器，一般處理靜態html、css、js請求，而Tomcat屬於web容器，專門處理JSP請求，當然Tomcat也是支持html的，只是效果沒Nginx好而已。

反向代理的優勢，如下：

  • 隱藏真實後端服務

  • 負載均衡集群

  • 高可用集群

  • 緩存靜態內容實現動靜分離

  • 安全限流

  • 靜態文件壓縮

  • 解決多個服務跨域問題

  • 合並靜態請求(HTTP/2.0後已經被弱化)

  • 防火牆

  • SSL以及http2

    • 動靜分離

    基於以上Nginx反向代理，我們還可以實現動靜分離，靜態請求如html、css、js等請求交給Nginx處理，動態請求分發給後端Tomcat處理。

    Nginx 升級到1.9.5+可以開啟HTTP/2.0時代，加速網站訪問。

    當然，如果公司不差錢，CDN也是一個不錯的選擇。

    服務拆分

    在這分布式微服務已經普遍流行的年代，其實我們沒必要踩過多的坑，就很容易進行拆分。市面上已經有相對比較成熟的技術，比如阿里開源的Dubbo(官方明確表示已經開始維護了)，spring家族的spring cloud，當然具體如何去實施，無論是技術還是業務方面都要有很好的把控。

    Dubbo

    SpringCloud

  • 服務發現——Netflix Eureka

  • 客服端負載均衡——Netflix Ribbon

  • 斷路器——Netflix Hystrix

  • 服務網關——Netflix Zuul

  • 分布式配置——Spring Cloud Config

    • 微服務與輕量級通信

  • 同步通信和非同步通信

  • 遠程調用RPC

  • REST

  • 消息隊列

    • 持續集成部署

    服務拆分以後，隨著而來的就是持續集成部署，你可能會用到以下工具。

    Docker、Jenkins、Git、Maven

    圖片源於網路，基本拓撲結構如下所示：

    整個持續集成平台架構演進到如下圖所示：

    服務集群

    Linux集群主要分成三大類( 高可用集群， 負載均衡集群，科學計算集群)。其實，我們最常見的也是生產中最常接觸到的就是負載均衡集群。

    負載均衡實現

  • DNS負載均衡，一般域名注冊商的dns伺服器不支持，但博主用的阿里雲解析已經支持

  • 四層負載均衡(F5、LVS)，工作在TCP協議下

  • 七層負載均衡(Nginx、haproxy)，工作在Http協議下

    • 分布式session

    大家都知道，服務一般分為有狀態和無狀態，而分布式sessoion就是針對有狀態的服務。

    分布式Session的幾種實現方式

  • 基於資料庫的Session共享

  • 基於resin/tomcat web容器本身的session復制機制

  • 基於oscache/Redis/memcached 進行 session 共享。

  • 基於cookie 進行session共享

    • 分布式Session的幾種管理方式

  • Session Replication 方式管理 (即session復制)
    簡介：將一台機器上的Session數據廣播復制到集群中其餘機器上
    使用場景：機器較少，網路流量較小
    優點：實現簡單、配置較少、當網路中有機器Down掉時不影響用戶訪問
    缺點：廣播式復制到其餘機器有一定廷時，帶來一定網路開銷

  • Session Sticky 方式管理
    簡介：即粘性Session、當用戶訪問集群中某台機器後，強制指定後續所有請求均落到此機器上
    使用場景：機器數適中、對穩定性要求不是非常苛刻
    優點：實現簡單、配置方便、沒有額外網路開銷
    缺點：網路中有機器Down掉時、用戶Session會丟失、容易造成單點故障

  • 緩存集中式管理
    簡介：將Session存入分布式緩存集群中的某台機器上，當用戶訪問不同節點時先從緩存中拿Session信息
    使用場景：集群中機器數多、網路環境復雜
    優點：可靠性好
    缺點：實現復雜、穩定性依賴於緩存的穩定性、Session信息放入緩存時要有合理的策略寫入

I. java軟體開發的架構設計

軟體架構作為一個概念，體現在技術和業務兩個方面。
從技術角度來說：軟體架構隨著技術的革新不斷地更新其內容，軟體架構建立於當前技術和一些基本原則的基礎之上。
先說一些基本原則：
分層原則：分層是為了降低軟體深度復雜性而使用的關鍵思想，就像社會有了階級一樣，軟體有了層次結構。
模塊化原則：模塊化是化解軟體廣度復雜的必然手段，模塊化的目的就是讓軟體分工。
介面實現分離原則隨著軟體模塊化的不斷深入改進，面向介面編程而不是面向實現編程可以讓復雜度日趨增高的軟體降低模塊之間的耦合度，從而讓各模塊更輕松改進。從這個原則出發，軟體也從微觀進行了細致的規范化。
還有兩個比較小但很重要的原則：
細節隱藏原則很顯然把復雜問題簡化，把難看的細節隱去，能讓軟體結構更清晰。其實這個原則使用很普遍，java/c++語言中的封裝原則以及設計模式中的Facade(外觀)模式就很能體現這個原則的精神。
依賴倒置原則隨著軟體結構的進一步發展,層與層之間、模塊與模塊之間的依賴逐漸加深，而層、模塊的動態可插拔要求不端增大。依賴倒置原則可看視為介面實現分離原則的深化，根據此原則的精神，軟體進入了工具時代。這個原則有點類似於知名的好萊塢法則：Don't call us, we'll call you。
以上這些原則奠定了我們的軟體架構的價值指標。但軟體架構畢竟是建立在當前技術之上的。而每一代技術都有架構模式。過去的不再說了，讓我們就來看一下當前流行的技術，以及當前我們能採用的架構。
因為面向對象是當前最流行開發技術，且設計模式的大量使用使面向對象的走向成熟，而資料庫是當前最有效的存儲結構、web界面是當前最流行的用戶介面，所以當前最典型的三層次架構就架構在以上幾項技術的基礎之上，用資料庫作存儲層、用面向對象來實現業務層、用web來作為用戶介面層。我們從三層次架構談起：
因為面向對象技術和資料庫技術不適配，所以在標准三層次架構的基礎上，我們增加了數據持久層，來管理O-R雙向映射，但目前一直沒有最理想的實現技術。cmp和entity bean技術因為其實現復雜，功能前景有限，已接近被淘汰的邊緣。JDO及hibernate作為o-r映射的後期之秀，尤其是hibernate，功能相當完備。推薦作為持久層的首選
在業務層，因為當前業務日趨負載，且變動頻繁，所以我們必須有足夠敏捷的技術來保證我們的適應變化的能力，在標准j2ee系統中session bean負責業務處理，且有不錯的性能表現，但採用ejb系統對業務架構模式改變太大，且其復雜而昂貴，業務代碼移植性差。而spring 作為一個bean配置的輕量級架構，漂亮的IOC模式實現，對業務架構影響小，所以推薦作為中間層業務框架。
在用戶結構層,雖然servlet/jsp/jstl/javaBean 能夠實現MVC架構，但終究過於粗糙。struts對MVC架構的實現就比較完美，Taperstry也極好地實現MVC架構，且採用基於事件的方式，非常誘人，惜其不夠成熟，我們仍舊推薦struts作為用戶介面層基礎架構。
因為業務層是三層次架構中最有決定意義的，所以讓我們回到業務層細致地分析一下，在復雜的業務我們常常需要以下基礎服務的一種或幾種：事務一致 性服務acid(tool:jta/jts)、並發加鎖服務concurrent&&lock、池化管理服務cache、訪問控制服務(tool:jaas)、流程式控制制服務workflow、動態實現服務IOC，串列化消息服務(tool:jms)、負載平衡服務blance等。如果我們不採用重量級應用伺服器(如weblogic,websphere,jboss等)及重量級組件(EJB)，我們必須自己實現其中一些服務。雖然我們大 多情況下，不需要所有這些服務，但實現起來卻非易事。幸運的是我們有大量的開源實現代碼，但採用開源代碼卻常常是件不輕松的事。
隨著xml作為結構化信息傳輸和存儲地位日漸重要,一些xml文檔操作工具(DOM,Digester,SAX等)的使用愈發重要，而隨著 xml schema的java binding工具(jaxb,xmlbean等)工具的成熟，採用xml schema來設計xml文檔格式，然後採用java binding來生成java bean 會成為主要編程模式,而這又進一步使數據中心向xml轉移，使在中小數據量上,愈發傾向於以xquery為查詢語言的xml資料庫。現還有一個趨勢， microsoft,ibm等紛紛大量開發中間軟體如(microsoft office之infopath)，可以直接從xml schema 生成錄入頁面等非常實用的功能。還有web service 的廣泛應用，都將對軟體的架構有非常重大的影響。至於面向服務架構(SOA)前景如何，三層次架構什麼時候走入歷史，現還很難定論。
aop的發展也會對軟體架構有很深的影響，但在面向對象架構里，無論aspectJ還是jboss-aop抑是aspectWerks、 nanning都有其自身的嚴重問題：維護性很差，所以說它將很難走遠。也許作為一個很好的思想，它將在web service里大展身手。
rdf,owl作為w3c語義模型的標志性的語言，也很難想像能在當前業務架構發揮太大影響。但如果真如它所聲稱那樣，廣泛地改變著信息的結構。那麼對軟體架構也會有深遠影響。