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语义模型的标志性的语言，也很难想象能在当前业务架构发挥太大影响。但如果真如它所声称那样，广泛地改变着信息的结构。那么对软件架构也会有深远影响。