java大型网站架构

❶ java怎样架构大项目

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网站都一般采用什么架构

系统大了，架构就和java无关，一般是多语言开发的。

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

其实，java网站架构倒不分什么大公司小公司，

主要看你的需求是怎样的，以及运营维护方式

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

1、web框架

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

2、数据库

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

3、rpc架构

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

4、数据平台和处理

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

5、消息中间件

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

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

❺ 采用java开发大型网站或B/S架构的企业管理软件用什么框架合适各种框架的优缺点是什么

用Struts2 spring hibernate
这是比较常用的开源框架

数据库的话 可以用mysql 或者 oracle

服务可以用weblogic整合

❻ 前端的全栈模式是什么架构，node.js做中间端，JAVA或者其他语言做后端，该怎么理解

前端的全栈模式其数拆实就是我们现在说的“大前端”概念。

老一辈的程序员应该都有印象，以前我们说的前端更多就是静态页面的布局和页面交互的实现，用到的技术主要就是：DIV+CSS、JavaScript、Ajax。

那时候的“前后端分离”也不是完全的分薯伍枣离！前端做好页面后是要交给后端开发人员进行整合的，更多的是种“模板”思想，前端做的只是“模板”，而模板里的数据填充还是要靠后端来处理。

而当下的“前后端分离”较之前要彻底一些！现在的前端不是传统的前端了，也涉及以前后端的一些技术，比如我们也可以把PHP划分到前端领域，用PHP来实现数据的渲染。

对于大型网站架构橘升，现在一般是这样的：

PHP/NodeJS渲染页面>Vue调用数据>JavaAPI>数据库

这种架构模式的优点主要有以下：

实现了前后端的完全分离，前端各类终端（Web、H5、APP、TV等）的页面风格展示方式不同，但不影响后端API的统一化；

术有专攻，便于控制；

并行开发，提升了开发效率。

❼ 现代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应用软件中

结论

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

大型互联网公司的网站一般都采用自研激察或自己内部薯衫定制的架构，不会完全照搬开源框架。

对于大型互联网公司来说，没有万能的架构，他们的技术选型和框架设计是完全根据实际业务来决定的，因此些许的业务差异就会造成两明手茄个看起来相似的公司采用了完全不同的架构设计，比如天猫和京东，美团和饿了么，其架构细节千差万别。

❾ 网站的基本架构是什么

网站架构按照制作步骤分为硬架构和软架构。

一、硬架构

1、机房：在选择机房的时候，根据网站用户的地域分布，可以选择网通、电信等单机房或双机房。

2、带宽：预估网站每天的访问量，根据访问量选择合适的带宽，计算带宽大小主要涉及峰值流量和页面大小两个指标。

3、服务器：选择需要的服务器，如图片服务器，页面服务器，数据库服务器，应用服务器，日志服务器，对于访问量大点的网站而言，分离单独的图片服务器和页面服务器相当必要。

二、软架构

1、网站的框架：现在的PHP框架有很多选择，比如：CakePHP，Symfony，Zend Framework，根据创作团队对各个框架熟悉程度选择。

2、逻辑的分层

1）表现层：所有和表现相关的逻辑都应该被纳入表现层的范畴。

2）应用层：主要作用是定义用户可以做什么，并把操作结果反馈给表现层。

3）领域层：包含领域逻辑的层，就是告诉用户具体的操作流程的。

4）持久层：即数据库，保存领域模型保存到数据库，包含网站的架构和逻辑关系等。

(9)java大型网站架构扩展阅读

网站的分类

1、根据网站所用编程语言分类：例如asp网站、php网站、jsp网站、Asp. net网站等；

2、根据网站的用途分类：例如门户网站（综合网站）、行业网站、娱乐网站等；

3、根据网站的功能分类：例如单一网站（企业网站）、多功能网站（网络商城）等等。

4、根据网站的持有者分类：例如个人网站、商业网站、政府网站、教育网站等。

5、根据网站的商业目的分类：营利型网站（行业网站、论坛）、非营利性型网站（企业网站、政府网站、教育网站）。

❿ 要成为一个Java架构师要怎么做

架构师，我想很多人都知道，其实该职位头衔在最早的IT领域是没有的，它是近些年来由互联网的发展所引发的需求，因为现阶段的数据量及高并发的活跃好动，引起了不少传统的技术人员的力不从心，企业愈发关注到了系统架构的重要性，所以不同行业开始招募架构技术人员，架构师就诞生了。

架构设计的条件

以下三个条件不适合做架构设计

对架构不感兴趣，但又迫于需求；

入IT行业，年限小于4年的；

主观能动性弱，又安于现状的；

架构设计的优势

更好的梳理业务的结构体系；

更好的拓展、维护及性能优化；

更好的适应企业业务灵活的推进；

更好的适应大数据的冲洗和应对；

更好的稳定性、低成本及快速迭代；

架构设计时候需要注意的地方

架构设计需要注意的地方，不是怎么把架构搭建起来，而是必须根据业务需求，严格分析，实现该需求需要什么技术会更好及更长远发展的考虑；

另外，构建好的架构陆察哪虽然可以运行，但是性能需要跟起来，否则架构设计会适得其反，增加不必要的工作量，那么下面就详细介绍下架构设计的策略。

平台的需求

客户需求

在线购物、在线支付或货到付款；

购买商品后，客户可以与客服沟通；

购买商品过程，物流的管理及跟踪；

收取到商品后，商品、物流评价打分；

客户的需求为最高，也代表了企业的核心需求，当然，企业需求还包括其它很多非功能性需求，具体请查看需求梳理部分。

平台的业务架构

根据业务的需求进行子系统模块划分，可以划分为商品子系统、购物子系统、支付子系统、物流子系统、客服子系统、评论子系统；而非核心需求可拆分出客服子系统、评论子系统及接口子系统。另外，根据各个子系统的核心等级，可拆分出核心子系统和非核心子没隐系统，前者包括商品子系统、购物子系统、支付子系统及物流子系统；后者，则包括评论子系统、客服子系统及接口子系统。需要注意的是一般大型电商平台的物流系统是单独分离出来的系统（入库、出库、库存管理、配送管理及货品管理），而这里划分为子系统的主要目的是为演示核心架构，本架构中物流子系统一般作为对接和管理独立子系统的对接模块哦。

1、业务拆分目早码的

为了解决各个模块子系统间的耦合、维护及拓展性；

方便单独部署子系统，避免集中部署导致一个出问题，全部不能用；

分配专门的团队，负责具体的子系统，最大化工作效率安排；

应对大数据，高压力时，保护核心子系统正常使用；

2、业务的架构图

在上面的业务架构图中，将核心和非核心业务进行拆分，同时每个系统都要独立部署实现，做到大数据量压下，各个系统独立运作，提高可用性，必要时可以暂停掉非核心系统的资源开销，保证核心业务正常为用户服务。

平台的技术架构

在上面业务架构图基础上，我们需要一个技术架构的演变过程，一切只为满足用户的体验和支撑为前提，所以技术架构的搭建不是一蹴而就的，而是随着业务的不断衍变，系统的架构会逐渐完善更新，以实现应对业务数据量的冲击。

1、基本的架构设计

记得很早的时候，很多中小企业所采用的架构设计十分简单，基本使用一台服务器来满足一切需求部署，比如：一台服务器同时用作应用部署、数据库存储以及图片存储等，不料的是待用户数据达到50万以上，系统出现很多性能问题，尽管对数据库和程序做个各种性能优化，结果仍无明显改善，架构如下：

后来，IT程序猿发现图片的读写严重影响了系统性能，并将图片单独存放在独立服务器中，并且在架构中引入了Cache中间件，比如：Memcache，这种做法是可取的，而且比原来性能提高了1-2个性能级别，架构设计如下：

2、初级的架构设计

前几年，一般的电商网站的做法是选用三台服务器，一台部署应用，一台部署数据库，一台部署NFS文件系统，做到将各个规模庞大并耗用性能的部分剥离到不同服务器设备，再配备必要的缓存中间件，基本可以满足近1000万的数据量，具体的架构图如下：

但是，目前主流使用的网站架构已经不同，大多采用集群的方式来实现负载均衡和高可用性，架构可以是下面的样子：

注意：

如果涉及到多台网站服务器的话，就会存在Session如何同步的问题，一般也是最为常用的做法，就是使用Cache中间件来存储和管理Session信息。

3、优化的架构设计

这里为解决高并发，高可用的大型电商网站的架构设计方案，主要采用了分布式、集群、负载均衡、反向代理、消息队列及多级缓存技术。该架构设计方案，是现今比较流程的大型电商网站采用的架构模式，比如：淘宝、京东等，也许会有细微不同的地方，但大同小异哦！具体的架构图方案如下：

平台架构的总结

这里主要总结的是优化架构，架构按层次结构罗列组织，共分为四层，层次分工明确，高拓展，低耦合，负载均衡、集群、分布式及缓存等技术的使用，架构如下：

好了，电商平台的架构设计就介绍到这里，本篇主要是介绍架构设计的思路及应用的核心技术，供在架构设计的同学参考借鉴哦！有想了解更多的可以关注我