「java网站架构」javaweb架构设计

本篇文章给大家谈谈java网站架构，以及javaweb架构设计对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。

本文目录一览：

• 1、Java的技术架构有哪些
• 2、现代Java Web开发架构分析
• 3、类似和58同城那样的网站，用Java是个怎么的架构
• 4、Java网上商城系统的Java简介
• 5、java架构有哪些
• 6、大公司网站java网站都一般采用什么架构？

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信息放入缓存时要有合理的策略写入

现代Java Web开发架构分析

在本文中 我将集中讨论现代的Java开发框架 分析它们的特征和各自的使用优点 另外 我还想比较目前流行的生产质量框架 例如Struts Spring和Hibernate 并详细讨论其基本相似性及有关基本概念

我将简短分析被用于支持这些框架的企业开发环境或工具箱 例如Borland JBuilder Eclipse以及BEA Workbench 请记住 市场上有许多有关这些开发框架的图书;然而 在任何一篇文章中 要对它们进行深入描述是不可能的 不过 我将尽力讨论最广泛地使用的概念

共同点

几乎所有现代的网络开发框架都遵循了模型 视图 控制(MVC)设计模式 商业逻辑和描述被分开 由一个逻辑流控制器来协调来自客户端的请求和服务器上将采取的行动 这条途径成为了网络开发的事实上的标准 每个框架的内在的机制当然是不同的 但是开发者们使用来设计和实现他们的Web应用软件的API是很类似的 差别还存在于每个框架提供的扩展方面 例如标签库 JavaServer Faces或JavaBean包装器等

所有的框架使用不同的技术来协调在Web应用程序之内的导航 例如XML配制文件 java属性文件或定制属性 所有的框架在控制器模块实现的方法方面也存在明显的不同 例如 EJB可能实例化在每个请求中需要的类或使用Java反射动态地调用一个适当的行动(Action)类 另外 不同框架在各自引入的概念上也有所不同 例如 一个框架可能定义用户请求和反应(以及错误)场所 而另外一个框架可能仅仅定义一个完整的流 从一个请求到多个响答和随后的再请求……

各种Java框架在它们组织数据流的方法方面是很类似的 在请求发出后 在应用程序服务器上产生一些行动;而作为响应 一些可能包含对象集的数据总是被发送到JSP层 然后 从那些对象 可能是有setter和getter方法的简单类 javabeans 值对象 或者一些集合对象 中提取数据 现代的Java框架还想方设法简化开发者的开发任务 如通过使用简易的API 数据库连接池 甚至数据库调用包等提供自动化的追踪方式来实现 一些框架或者能够钩进(hooked into)另外的J EE技术中 例如JMS(Java消息服务)或JMX 或把这些技术集成到一起 服务器数据持续性和日志也有可能成为框架的一部分

企业开发环境

一些框架在Web开发者社区和企业发展领域变得相当流行 随着这些框架的日渐成熟并开始发行稳定的版本 商业的IDE(集成发展环境)开始为这些框架提供支持并把他们纳入到自己的产品中 一些IDE甚至基于框架的概念开发出整个的产品 例如 BEA WebLogic Workshop就是基于Struts框架建立起来的

Borland Jbuilder为Struts提供了内建的支持 也支持JSF和JSTL

Eclipse平台已成为一个很流行的开发工具 部分因为它是基于插件的 部分因为它对于Web框架的支持 现在 出现了众多的Eclipse插件 甚至完整的基于Eclipse的IDE 许多插件被设计适合于Struts框架开发 例如MyEclipse()或M

大多数IDE都具有图形化的流程和可视化对象(类代理) 例如 下面是一个JBuilder的行动(Action)设计器 用于规划Web应用程序的页面顺序

WebLogic Workshop引入Java页面流程技术 它扩展了Struts框架而提供了一个简化的开发模型并增加了另外一些特性 Workshop使用页面流(Page Flows) 实现轻易地把用户接口与导航和商业逻辑分离开来 页面流由JSP页组成 这些页面包含用户接口元素和一个控制器文件(JPF) 它包含由用户提供的数据将怎样被处理的指令以及下一步什么页面将被返回到用户的信息 页面流动提供给开发者一个可视化的Web应用程序总体轮廓 它让开发者能够看到直观地分析不同的JSP页彼此相关联 并实现Web应用程序整体结构的快速建立

MyEclipse提供类似的特征 并带有更多吸引人的代价标签

Apache Struts框架

Struts框架是一开源产品 基于模型 视图 控制器(MVC)设计范例来开发Web应用软件 它使用并且扩展了Java Servlet API 最初由Craig McClanahan创建 在 年 月 它被捐赠到Apache Foundation Struts框架展示了一个强有力的定制标签库 平铺显示 表单检验和I N(国际化) 另外 Struts支持许多描述层 包括JSP XML/XSLT JavaServerFaces(JSF)和Velocity;还支持一些模型层 包括JavaBeans和EJB

Spring框架

Spring框架是一个分层的Java/J EE应用程序框架 基于Expert One on One J EE设计和发行的代码 Spring框架提供一种简单的开发技术 用于自动化处理工程中大量的属性文件和助理类

Spring框架包括的主要特色有:

  强有力的基于JavaBeans的配置管理 使用Inversion of Control(IoC)原则   一个核心bean工厂 可用在任何环境 从applets到J EE容器程序   通用的抽象层适合于数据库事务管理 允许可插入的事务管理器 并且不需要处理低层次的问题就可容易地划分各事务的界限   一个很有意义的异常处理的JDBC抽象层   与Hibernate集成到一起 DAO实现支持以及事务策略

Hibernate框架

Hibernate是一适合于Java语言的对象 关系映射(ORM)解决方案 它也是开源软件 类似Struts 并且在LGPL保护下发布 Hibernate被一群来自世界各地的Java软件开发者所共同开发 它提供一个易用的框架来实现把一个面向对象的域模型映射到一传统的关系数据库 它不仅负责从Java类到数据库表格(以及来自Java数据类型的SQL数据类型)的映射 而且还提供数据查询和检索能力 并能大大减少花在SQL和JDBC手工数据处理上的开发时间

Hibernate的目标是减轻开发者的与大量普通的数据持续性相联系的编程任务 Hibernate还能够适应开发进程 无论它是刚开始设计还是来自一现成的数据库 Hibernate可以自动生成SQL 使开发者摆脱了手工处理结果集和进行对象转化的繁琐任务 并能使应用程序移植到所有的SQL数据库 它还能提供透明的持续性 对持续性类的唯一的要求的是实现一个无参数的构造器

这个框架典型地使用在JavaSwing应用软件 基于Servlet的Java应用软件和使用EJBsession beans的J EE应用软件中

结论

lishixinzhi/Article/program/Java/hx/201311/26488

类似和58同城那样的网站，用Java是个怎么的架构

这种网站数据量比较大，一般数据库会用oracle，服务器就不一定了，可能是tomcat可能是weblogic等等。技术框架的话像java一般ssh和ssm用得较多。前端也有很多种选择，看公司选择了。

Java网上商城系统的Java简介

java语言相对于成本较低的PHP语言，存在较大的优势，java语言的二次开发更为便捷，拓展性更强，经过对java语言源码的二次开发，系统源码的易用性和实用性方面会有很大的改善。同时，使用java语言开发的商城系统具有更安全、高效、强大的特点。

一、java商城系统架构的高效性

电商网站开发架构是一个商城系统的骨架，不同的语言有不同的架构建立方式。java使用面向对象的设计方法，java开源商城系统运用MVC模式设计，实现多层的网络架构，使系统具有更加高效、合理的系统架构。java语言应用在商城系统中也会使系统在可拓展性、需求应变性上有更加强大。java商城系统远不止于运用在建设PC端的商城网站，同时还可以应用在移动端，编译成java手机商城系统。除了单用户商城系统外，java程序设计语言还能运用在多用户商城系统上，可以应用在不同行业的不同应用场景。

二、java商城系统的安全性

网上商城的安全性是用户最为关注的，电商网站系统商城开发的安全性问题应该放在首位。Java系统在安全性方面有绝大的优势，其他语言的开源特点导致其安全性没有java系统那么高，程序员在拿到其他语言源代码后，可以较容易的进行修改，java程序代码是一些编译好的类，在安全性更值得信赖。在java商城系统不提供源代码或源代码注释的情况下，普通程序员可能需要几年时间才能破解java系统源代码。所以在预算充足的情况下，java商城系统是大中型企业的首选。

三、开源商城系统数据库的通用性

数据库是一个网上商城系统不可缺少的部分。其他语言可编译成具有与许多数据库相连接的函数，可以编写外围函数对数据库进行存取，但提供的数据库接口支持彼此不统一，所以其他商城系统数据库访问代码的通用性不强。但java是通过JDBC来访问数据库的，访问数据库接口比较统一，可以访问不同数据库厂商提供的数据库驱动。在进行数据迁移时，java商城系统就具有很大的优势。

四、java开源商城系统的价格

Java电子商务网站制作费用方面，所需要的费用是比其他要高出很多，体现在java技术员薪资、服务器购买、以及一些维护费用。java商城系统建设比较适合一些中大型的企业使用，便于中大型企业以后对商城系统进行二次开发。

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)、并发加锁服务concurrentlock、池化管理服务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)。这样可降低耦合度。

现在我们谈一下业务稳定存在理由对业务的影响。存在即是合理，在这里当然是正确的。业务因人而存在，所以问业务存在的理由即是问不同角色的需要这项业务的理由以及喜欢不喜欢当前业务用例的理由，所有这样的角色都应该在系统里预留。《待续》

在架构设计中有几个原则可以考虑：

用例尽量细分

用例尽量抽象

角色尽量独立

项测量独立原则

追求简单性

这里未提供相关的例子，例子会在以后的更新时提供。

业务和模式之间的关系

业务中的一些用例之间的关系常常和一些常规的模式很相似。但随着时间的演化，慢慢地和先前的模式有了分歧。这是个正常的现象。但这对系统架构却要求非常高，要求系统架构能适应一些模式的更替。在这里我们尽可能早地注意到用例之间的相互角色变化，为架构更新做好准备.

大公司网站java网站都一般采用什么架构？

其实，java网站架构倒不分什么大公司小公司，主要看你的需求是怎样的，以及运营维护方式。

其实，java的架构还是比较固定的，主要就分为下面这五种，我来为大家简单介绍一下。

1、web框架

rose，基于spring mvc，采用"约定优先于配置"的思想，编写起来还是挺快的。

2、数据库

jade，实现了数据库读写分离，分库分表等，一句简单的sql就可以实现对数据库的需求。

3、rpc架构

第一代rpc框架网络层采用netty，序列化层是json，基于http自定义协议。第二代框架就是完全基于thrift，thrift解决了上面的语言兼容性。

4、数据平台和处理

没在这个组呆过，只是了解一些。基本和各大公司的大数据处理一样，离线计算hive/pig，流式计算storm/Presto，内存计算spark，以此来满足各个业务对数据的不同需求。

5、消息中间件

我们使用过kafka，主要用于log统计和一些不太重要的异步处理。kafka的优点就是吞吐量很高，但是不能保证消息可靠性消费，这些可以在消费端自己做一些定制化处理。

总结

网络发展速度之快超出想象，网站也像是水面上的船，也趁势飞速发展，相信之后会有更好地工具、模式，发展前景也是不可限量的。

java网站架构的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于javaweb架构设计、java网站架构的信息别忘了在本站进行查找喔。