最新Web系统架构图

最新Web系统架构图

Web应用系统架构演进过程

1 系统架构演化历程 -- 初始阶段架构 初始阶段的小型系统,其特征表现为应用程序、数据库、文件等所有的资源都部署在一台服务器上,我们通俗称为LAMP架构。 特征: 应用程序、数据库、文件等所有的资源都在一台服务器上。 描述: 通常服务器操作系统使用Linux,应用程序使用PHP开发,然后部署在Apache上,数据库使用MySQL,汇集各种免费开源软件以及一台廉价服务器就可以开始系统的发展之路了。 2 系统架构演化历程 -- 应用服务和数据服务分离

好景不长,发现随着系统访问量的增加,Web应用服务器器的压力在高峰期会上升到比较高,这个时候开始考虑增加一台Web应用服务器提供系统的访问效率。 特征: 应用程序、数据库、文件分别部署在独立的资源上。 描述: 数据量增加,单台服务器性能及存储空间不足,需要将应用和数据分离,并发处理能力和数据存储空间得到了很大改善。 3 系统架构演化历程 -- 使用缓存改善性能标题

特征: 数据库中访问较集中的一小部分数据存储在缓存服务器中,减少数据库的访问次数,降低数据库的访问压力。 描述: 1. 系统访问特点遵循二八定律,即80%的业务访问集中在20%的数据上; 2. 缓存分为本地缓存和远程分布式缓存,本地缓存访问速度更快但缓存数据量有限,同时存在与应用程序争用内存的情况。 4 系统架构演化历程 -- 使用应用服务器集群

在对应用系统做完分库分表工作后,数据库上的压力已经降到比较低了,又开始过着每天看着访问量暴增的幸福生活了,突然有一天,发现系统的访问又开始有变慢的趋势了,这个时候首先查看数据库,压力一切正常,之后查看Web Server,发现Apache阻塞了很多的请求,而应用服务器对每个请求也是比较快的,发现问题是由于请求数太高导致需要排队等待,响应速度变慢。 特征: 多台服务器通过负载均衡同时向外部提供服务,解决单台服务器处理能力和存储空间上限的问题。 描述: 1. 使用集群是系统解决高并发、海量数据问题的常用手段。 2. 通过向集群中追加资源,提升系统的并发处理能力,使得服务器的负载压力不再成为整个系统的瓶颈。 5 系统架构演化历程 -- 数据库读写分离

Web网站架构详解

Web网站架构详解

前言 俗话说得好,冰冻三尺非一日之寒,滴水穿石非一日之功,罗马也不是一天就建成的,当然对于我们开发人员来说,一个好的架构也不是一蹴而就的。 初始搭建 开始的开始,就是各种框架一搭,然后扔到Tomcat容器中跑就是了,这时候我们的文件、数据库、应用都在一个服务器上。 服务分离

随着系统的的上线,用户量也会逐步上升,很明显一台服务器已经满足不了系统的负载,这时我们就要在服务器还没有超载时,提前做好准备。 由于我们是单体架构,优化架构在短时间内是不现实的,增加机器是一个不错的选择。这时,我们可能要把应用和数据库服务单独部署,如果有条件也可以把文件服务器单独部署。 反向代理

为了提升服务处理能力,我们在Tomcat容器前加一个代理服务器,我一般使用Nginx,当然你如果更熟悉Apache也未尝不可。 用户的请求发送给反向代理,然后反向代理把请求转发到后端的服务器。 严格意义上来说,Nginx是属于Web服务器,一般处理静态HTML、CSS、JS请求,而Tomcat 属于Web容器,专门处理JSP请求,当然Tomcat也是支持html的,只是效果没Nginx 好而已。 反向代理的优势,如下: o隐藏真实后端服务 o负载均衡集群 o高可用集群 o缓存静态内容实现动静分离

o安全限流 o静态文件压缩 o解决多个服务跨域问题 o合并静态请求(HTTP/2.0后已经被弱化) o防火墙 o SSL以及http2 动静分离

基于以上Nginx反向代理,我们还可以实现动静分离,静态请求如HTML、CSS、JS等请求交给Nginx处理,动态请求分发给后端Tomcat处理。 Nginx 升级到1.9.5+可以开启HTTP/2.0时代,加速网站访问。 当然,如果公司不差钱,CDN也是一个不错的选择。 服务拆分 在这分布式微服务已经普遍流行的年代,其实我们没必要踩过多的坑,就很容易进行拆分。市面上已经有相对比较成熟的技术,比如阿里开源的Dubbo(官方明确表示已经开始维护了),Spring家族的Spring Cloud,当然具体如何去实施,无论是技术还是业务方面都要有很好的把控。

Web体系结构

Web体系结构 Web体系结构是非常重要的,了解不难,但是要了解透彻就需要一定的时间和精力去做,学习提升的是自己。我们就Web体系结构和大家详细介绍一下。 传统的Web数据库系统一般实现Web数据库系统的连接和应用可采取两种方法,一种是在Web服务器端提供中间件来连接Web服务器和数据库服务器,另一种是把应用程序下载到客户端并在客户端直接访问数据库。中间件负责管理Web服务器和数据库服务器之间的通信并提供应用程序服务,它能够直接调用外部程序或脚本代码来访问数据库,因此可以提供与数据库相关的动态HTML页面,或执行用户查询,并将查询结果格式化成HTML页面。通过Web服务器返回给Web 浏览器。最基本的中间件技术有通过网关接口CGI和应用程序接口API两种。

公共网关接口 CGI是外部应用程序(CGI程序)与Web服务器之间的接口标准,是WWW服务器运行时外部程序的规范,按照CGI编写的程序可以扩展服务器的功能,完成服务器本身不能完成的工作,外部程序执行时间可以生成HTML文档,并将文档返回WWW服务器。CGI应用程序能够与浏览器进行交互作用,还可以通过数据库的API与数据库服务器等外部数据源进行通信,如一个CGI程序可以从数据库服务器中获取数据,然后格式化为HTML文档后发送给浏览器,也可以将从浏览器获得的数据放到数据库中。几乎使用的服务器软件都支持CGI,开发人员可以使用任何一种WWW服务器内置语言编写CGI,其中包括流行的C、C++、VB和Delphi等。 从体系结构上来看,用户通过Web浏览器输入查询信息,浏览器通过HTTP协议向Web服务器发出带有查询信息的请求,Web服务器按照CGI协议激活外部CGI程序,由该程序向DBMS发出SQL请求并将结果转化为HTML后返回给Web服务器。再由Web服务器返回给Web 浏览器。这种结构体现了客户/服务器方式的三层模型,其中Web服

web三层架构概述

web三层架构概述 web三层架构概述 2009-05-23 10:23 关于 三层架构(3-tier application) 通常意义上的三层架构就是将整个业务应用划分为:表现层(UI)、业务逻辑层(BLL)、数据访问层(DAL)。区分层次的目的即为了“高内聚,低耦合”的思想。 1、表现层(UI):通俗讲就是展现给用户的界面,即用户在使用一个系统的时候他的所见所得。 2、业务逻辑层(BLL):针对具体问题的操作,也可以说是对数据层的操作,对数据业务逻辑处理。 3、数据访问层(DAL):该层所做事务直接操作数据库,针对数据的增、删、改、查。 概述

三层结构原理: 3个层次中,系统主要功能和业务逻辑都在业务逻辑层进行处理。 所谓三层体系结构,是在客户端与数据库之间加入了一个“中间层”,也叫组件层。这里所说的三层体系,不是指物理上的三层,不是简单地放置三台机器就是三层体系结构,也不仅仅有B/S应用才是三层体系结构,三层是指逻辑上的三层,即使这三个层放置到一台机器上。 三层体系的应用程序将业务规则、数据访问、合法性校验等工作放到了中间层进行处理。通常情况下,客户端不直接与数据库进行交互,而是通过COM/DCOM通讯与中间层建立连接,再经由中间层与数据库进行交互。 表示层位于最外层(最上层),离用户最近。用于显示数据和接收用户输入的数据,为用户提供一种交互式操作的界面。 业务逻辑层业务逻辑层(Business Logic Layer)无疑是系统架构中体现核心价值的部分。它的关注点主要集中在业务规则的制定、

业务流程的实现等与业务需求有关的系统设计,也即是说它是与系统所应对的领域(Domain)逻辑有关,很多时候,也将业务逻辑层称为领域层。例如Martin Fowler在《Patterns of Enterprise Application Architecture》一书中,将整个架构分为三个主要的层:表示层、领域层和数据源层。作为领域驱动设计的先驱Eric Evans,对业务逻辑层作了更细致地划分,细分为应用层与领域层,通过分层进一步将领域逻辑与领域逻辑的解决方案分离。 业务逻辑层在体系架构中的位置很关键,它处于数据访问层与表示层中间,起到了数据交换中承上启下的作用。由于层是一种弱耦合结构,层与层之间的依赖是向下的,底层对于上层而言是“无知”的,改变上层的设计对于其调用的底层而言没有任何影响。如果在分层设计时,遵循了面向接口设计的思想,那么这种向下的依赖也应该是一种弱依赖关系。因而在不改变接口定义的前提下,理想的分层式架构,应该是一个支持可抽取、可替换的“抽屉”式架构。正因为如此,业务逻辑层的设计对于一个支持可扩展的架构尤为关键,因为它扮演了两个不同的角色。对于数据访问层而言,它是调用者;对于表示层而言,它却是被调用者。依赖与被依赖的关系都纠结在业务逻辑层上,如何实现依赖关系的解耦,则是除了实现业务逻辑之外留给设计师的任务。

常用的Web架构开发语言

框架是Web架构开发中必不可少的工具,不仅可以提高开发效率,还能让开发项目更成熟,并且可以提升代码的可再用性,Web框架开发离不开相应的开发语言,以下是常用的Web架构开发语言: 1. Node.js Node.js是运行在服务器端的非阻断、异步I/O、事件驱动的JavaScript,是基于Chrome JavaScript 运行时建立的一个平台,可以实现js在服务器端的编译,而且拥有更好的组织代码,提升复用性,非常适合在分布式设备上运行数据密集型的实时应用。 2. PHP PHP是Web架构开发常用语言,PHP开发了很多Web框架,如Zend framework、CakePHP、ThinkPHP等,PHP 独特的语法混合了C、Java、Perl 以及PHP 自创新的语法,可以比CGI或者Perl更快速的执行动态网页,而且功能强大,所有的CGI的功能PHP 都能实现,支持几乎所有流行的数据库以及操作系统,还可以用C、C++进行程序的扩展! 3. JavaScript JavaScript是一种属于网络的脚本语言,被广泛用于Web应用开发,JavaScript是一种运行在浏览器中的解释型的编程语言,可以轻松实现跨平台、跨浏览器驱动网页以及与用

户交互的功能,JavaScript开发很多Web框架,如Angular.js、Ember.js以及Javascript MVC等。 4. Swift Swift是一款易学易用的编程语言,主要用于编写IOS和macOS应用,结合了C和Objective-C 的优点并且不受C兼容性的限制,采用安全的编程模式并添加了很多新特性,这使得编程更简单、灵活,也更加有趣,Swift的设计以安全为出发点,以避免各种常见的编程错误类别。 5. Java Java是一门面向对象的编程语言,在电子商务领域以及网站开发领域占据了重要的地位,开发人员可以运用很多不同的框架来创建Web项目,如SpringMVC,Struts2.0以及frameworks等,即使是简单的servlet、jsp和以struts为基础的网站在政府项目中也经常被用到,疗救护、保险、教育、国防以及其他的不同部门网站也都是以Java为基础来开发的。 6. Python Python是一种解释型的脚本语言,开发效率高,所以非常适合用来做Web开发,Python有上百种Web开发框架,有很多成熟的模板技术,如Django、flask等,选择Python 开发Web应用,不但开发效率高,而且运行速度快。

Web系统架构综述

B/S架构和C/S架构概述 C/S架构和B/S架构是现今软件系统所采用的两种主流架构。 C/S架构的全称是Client/Server,即客户端服务器端架构,其中客户端包括一个或多个需要在用户的电脑上运行的本地程序,服务器端包括数据库服务器端和Socket服务器端。C/S 架构的客户端部署往往比较臃肿。因为绝大多数的业务逻辑和界面展示是在客户端上完成的。在这种架构中,客户端需要较大的压力,因为显示逻辑和事务处理都是由客户端完成的,通过与数据库的交互进行数据的持久化,满足实际项目的需求。 B/S架构的全称是Browser/Server,即浏览器/服务器模式架构。B/S架构是考虑到现今WEB技术如火如荼发展的今天所新兴的一种网络结构模式。它将系统功能实现的核心部分部署在服务器上,用户通过轻量级的浏览器就可以访问并使用系统,也简化了系统的开发和维护。 C/S架构的应用场景主要是面对繁多操作和丰富界面的系统,B/S架构主要运用于交互性强、用户访问频繁且功能偏少的系统。针对电子票务系统,B/S架构不仅能满足其所有功能,而且实施更加方便,用户访问更加快捷。所以本文选定B/S架构作为电子票务系统的表现形式。 JA V A概述 Java是由Sun公司推出的一门面向对象编程语言。Java的出现是为了解决如C、C++等语言所遇到一些问题,如:不能跨平台移植代码、容易出现内存泄漏等。除此以外,Java还内建了对网络编程、数据库连接、多线程等高级程序设计任务的支持,Java具有高质量的编译环境以及庞大的类库可供调用。并且Java语言一直都是开源的,作者希望借着全球程序员的智慧共同推动Java的发展,所以Java有许多相关的开源框架可供开发者选择使用。 Java具有下列几个显而易见的特点: 简单易用:Java语法比C/C++的语法更接近自然语言,这使得大多数程序员的学习和使用成本相对较低。另一方面,它摒弃了C++中容易引起错误的指针、运算符重载、多重继承等特点,对底层结构进行最大程度上的封装。 面向对象:与C++类似,Java是一个纯粹的面向对象语言。并且Java丢弃了C++语法里让人难以理解的多继承,取而代之的是接口实现。

Web架构开发常用编程语言

Web架构开发常用编程语言 如果你是做Web开发的,Web框架一定会很熟悉,框架是Web架构开发中必不可少的工具,不仅可以提高开发效率,还能让开发项目更成熟,并且可以提升代码的可再用性,Web框架开发离不开相应的开发语言,以下是常用的Web架构开发语言: 1. Node.js Node.js是运行在服务器端的非阻断、异步I/O、事件驱动的JavaScript,是基于Chrome JavaScript 运行时建立的一个平台,可以实现js在服务器端的编译,而且拥有更好的组织代码,提升复用性,非常适合在分布式设备上运行数据密集型的实时应用。 2. PHP PHP是Web架构开发常用语言,PHP开发了很多Web框架,如Zend framework、CakePHP、ThinkPHP等,PHP 独特的语法混合了C、Java、Perl 以及 PHP 自创新的语法,可以比CGI或者Perl更快速的执行动态网页,而且功能强大,所有的CGI的功能PHP都能实现,支持几乎所有流行的数据库以及操作系统,还可以用C、C++进行程序的扩展! 3. JavaScript JavaScript是一种属于网络的脚本语言,被广泛用于Web应用开发,JavaScript是一种运行在浏览器中的解释型的编程语言,可以轻松实现跨平台、跨浏览器驱动网页以及与用户交互的功能,JavaScript开发很多Web框架,如Angular.js、Ember.js以及Javascript MVC等。

4. Swift Swift是一款易学易用的编程语言,主要用于编写IOS和macOS应用,结合了C和Objective-C 的优点并且不受C兼容性的限制,采用安全的编程模式并添加了很多新特性,这使得编程更简单、灵活,也更加有趣,Swift的设计以安全为出发点,以避免各种常见的编程错误类别。 5. Java Java是一门面向对象的编程语言,在电子商务领域以及网站开发领域占据了重要的地位,开发人员可以运用很多不同的框架来创建Web项目,如SpringMVC,Struts2.0以及frameworks等,即使是简单的servlet、jsp和以struts为基础的网站在政府项目中也经常被用到,疗救护、保险、教育、国防以及其他的不同部门网站也都是以Java为基础来开发的。 6. Python Python是一种解释型的脚本语言,开发效率高,所以非常适合用来做Web 开发,Python有上百种Web开发框架,有很多成熟的模板技术,如Django、flask 等,选择Python开发Web应用,不但开发效率高,而且运行速度快。 以上是常用的Web架构开发语言,想要更好的进行Web开发,最好是能够熟悉相应框架的开发语言,这样就可以根据实际需求进行框架的二次开发,从而达到自己想要的效果!

Web系统结构调整实例及分析

Web系统结构调整实例及分析 张兆雷 佟秋利 (清华大学计算机与信息管理中心 , 北京 100084) E-mail : zhangzl@cic.tsinghua.edu.cn 摘要基于struts的web项目在开发和维护的过程中,系统结构会逐渐偏离最初的设计,这会影响系统的性能和可维护性,为了保证系统正确运行,需要对系统结构进行修复。本文根据对校园信息化系统的一个web项目进行结构调整的实例,通过分析web系统的特性,提出适用于web系统结构修复的方法,包括实施的原则和流程。这篇文章提出的方法的优势在于通过较少的工作量就可以显著的改善web系统的结构,增强系统的可维护性。 关键字Web; MVC; struts;结构修复 中图分类号: TP311 The Application and Analysis of Web System Architecture Repair Zhang Zhaolei Tong Qiuli (Computer and Information Management Center of Tsinghua University, Beijing 100084) Abstract: As a Web Application which is based struts framework is developed and maintained, its architecture will drift, and this situation will weaken the performance and the maintainability of the system. In order to eliminate the problem, we should do some repair work on the system architecture. The writers have worked on a Web application of Campus-Wide Information Systems (CWISs) and repaired the system architecture successfully. In this paper, we will analyze the characteristic of Web system, and summarize some principle, method and the flow which could be used in the architecture repair of Web system. The highlight of our method is that we could get twice the result with half the effort and improve the system architecture and maintainability remarkably. Keywords: web; mvc; struts; Architecture Repair 0 引言 在进行企业级web开发的过程中,设计架构[5]对开发的效率和成功率的影响越来越大。struts是近些年来众多轻量级设计架构中比较优秀的一个。struts架构采用MVC分层设计思想,将开发项目分为视图(View)、控制(Control)、模型(Model)三个不同功能层次,将业务逻辑处理和数据显示分离[1][6]。采用MVC的分层结构,主要目的是明确web系统的功能分配,减弱各个组件之间的耦合性,进行模块化的开发。模块的组件化和模块之间的低耦合性利于系统的分布式部署、提高系统的性能和可维护性。 struts提出了分层和分模块的思想,但是如何对web项目进行模块划分并没有统一的标准,而且web项目需要大量开发人员和较长时间,不易组织,需求变更频繁,因此,在web项目的开发和维护过程中,结构会逐渐偏离最初的设计。一般情况下,这个问题会影响项目的后期维护和再开发,严重的会降低系统的性能,甚至使系统崩溃。解决这个问题的方

WEB系统架构图

客户端: (1)B/S架构。网页画面可以通过一般浏览器,手机浏览器,平板电脑等进行访问。 网页显示技术除了常规的html画面以外,还包括flash,silverlight等技术。 (2)C/S架构。可以使用C++,JAVA,C#,Delphi等语言实现。 (3)手机应用(Andriod,ios等) (4)Web脚本JavaScript ? HTML DOM ? DHTML ? VBScript ? AJAX ? jQuery ? JSON (5)将传统的POST/GET转换为Ajax请求。优点显而易见,首先减少了不必要的HTML传输, 只请求和渲染页面需要更新的部分,这就相应减少了所需传输的内容加快了内容送达至用户的时间。 服务器端: (1)使用ASP.NET MVC,JAVA Struct,PHP MVC等经典框架进行开发。 (2) 使用ORM框架进行数据库持久化访问。(Hibernate等) (3)服务器操作系统支持windows系列和linux系列。其中JAVA和PHP语言支持跨平台。 (4)分布式缓存系统,在数据库和动态内容之间建立一层缓存区,它可以部署在独立的服务器上,用于加速数据库的读写操作。(5)负载均衡系统。把一些既定的内容生成html静态页,保存到“静态web服务器群”中。用户对这些内容的访问,系统会提供静态页的链接,使用户直接访问静态页。服务器对静态页的处理和动态页处理相比,大大减少了CPU的压力。 另外,生成静态页也减少了缓存的压力,因为一般的静态页用不到复杂的缓存。 (6)“文件服务器群”存储了系统的海量图片、视频等文件,于是这个服务器群需要很大的硬盘存储空间。 用户访问网页,网页会加载其中相应的图片或视频。文件服务器对CPU和网络带宽的要求都相当高, 单独用一个服务器群存储处理文件时,可以为这个服务器群单独加大带宽和CPU速度。 数据库端: (1)使用流行的mysql,oracle,sqlserver数据库。 (2)主从数据库,读写分离。

Web系统开发构架思考

Web系统开发构架思考简述

目前大部分系统的架构图,虽然有些系统采用分布式架构,层与层之间使用了远程调用框架,但是本质上都逃不开上面这个架构设计。这张图是一张比较合理的图,在实际开发里最常发生的事情就是控制层(Control)越过服务层(Service)直接处理下面的资源。 前后端耦合的问题主要发生在控制层(Control),控制层是前端和服务端交互的边界,但是在开发过程中控制层(Control)和服务层(Service)常常混淆不清,这就是前后端耦合度高的重要原因。 因此要前后端解耦,就是要划清控制层的边界,控制层到底该属于前端还是服务端,在MVC模式里控制层作用是调度,控制层不是写业务逻辑的地方,因此将大量业务逻辑写到控制层其实是违背了MVC模式的思想,同时控制层是前端和服务端通讯的桥梁,其实控制层是参入了前端的工作任务,既然控制层要剥离业务操作同时控制层也要参入前端应用的开发,那么将控制层归为前端的一部分是完全合情合理合规的。 前后端分离的终极目标应该是前端和服务端是完全独立的项目,前端项目包含上图里的浏览器和控制层,服务端项目包括服务层、DAO层等等,前端项目和服务端项目以高效的远程调用框架做通讯介质,项目开发时候前端项目做前端的事情,服务项目做服务端的事情,这样就让服务端开发的人员没有机会在控制层乱写代码了,保证了Web前端环境的纯粹性,最后生产发布也要独立部署,这样就达到了前后端真正解耦,但是前后端的沟通机制也是不可或缺的,我觉得它们之间的沟通使用高性能的远程调用框架,前后端相互约定通讯报文格式。.

其实不管服务端还是前端宏观流程无非是输入数据和输出数据处理,但是服务端要把心思花在数据处理上,前端要更多关心的是输入输出数据时候的用户体验操作,服务端开发最大的问题就是违背MVC原则,代码编写的随意性,而前端不管出于安全还是性能考虑,最好是尽量少牵涉业务。前端和后端通讯层的独立,会将前后端进行真正的解耦,前面讲到前后真正问题就是前端和后端技术路线不一致,但是传统Web开发里前后端又要融为一体,这就导致前后端很难做到专业化分工,对于前端应该尽量弱化通讯级别的开发工作,前端通讯编程只要知道调用哪个接口,传什么参数,怎么处理响应信息就行了。这样就能让前端和后端实现真正的专业化。 做到了这些,就不会发生开发时候前后端边界不清的问题了。 专业化分工技术团队 做Web开发也可以说是B/S架构开发,B端和S端从技术体系角度而言异构性很大,换而言之就是B端使用的技术和S端使用的技术不适于同一个体系,这样的结果导致实际开发中,很难做到专业分工,如果项目开发过程中管控不到位,这样的问题可能会影响到整个项目的开发质量,因此前后端分离的目的之一就是要做到专业化分工,提高项目的质量和开发效率。 随着技术的发展,当下的Web开发形势已经和以前有了很大的不同,早期的Web项目是一个封闭的项目,用户从浏览器里看到的页面直到后台数据库都是在一个项目里集成的,而现在Web系统的规模越来越大,中大型的Web系统是一个开放式的系统,开放型的系统用户在浏览器发起的请求可能会转发到外部的系统里进行处理,或者是本地的系统和外部系统一起完成请求的处理,此外有的请求可能不会直接请求数据库,而是请求缓存服务器,这些变化几乎都是发生在Web系统的服务端,前后端耦合度很高的Web系统服务端的复杂度提升必然带来了Web前端的复杂度的提升。因此Web前端从系统架构的角度也需要更加专业的管控,管控的作用之一就是前后端进行分离,降低前端对服务端的依耐性。 富客户端应用的普及导致Web前端技术开发更加专业化,Web前端工程师成为一个独立的技术岗位,Web前端开发技术的难度也越来越高,前后端的分离就是为Web前端开发营造一个良好的开发环境,不要让前端工程师被一些不可控的外在因素所影响(例如:前后端的耦合性),最后导致前端不能专心致志做出更加好的作品。所以,前后端分离是让前后端更加专业化,在技术和管理上将前端角色更加明确,更深入的挖掘前端开发的价值。 让前端的东西项目化,工程化,提升前端技术,它也是需要大量的系统架构,开发规范,自动化压缩混淆,自动化发布,前端监控和分析,前端优化等等 前端组件化开发,不管这个组件是UI层级,还是javascript开发层级,都脱离不了该公司业务产品的模式,其实看看像网易,新浪这样的门户网站的前端应用组件,它们用于做门户很合适,但是用它来做公司应用软件可能就不是太好使用,因此对于组件要有一个清晰的认识,我觉得可以把组件按业务场景分类,这里我可以举个例子,如果这个公司有给门户使用的组件,而这个组件很适合门户,应该把它归为门户组件,如果某些组件适合做网站后台管理的,那么就列为后台管理组件,如果某些组件能跨多了业务场景则标记为通用组件。 做分类的原因是为了理清组件的应用边界,这样我们可以有针对性的积累和完善这些组件,有意识的开发相关的组件,最终形成一个针对某个业务组件的组件仓库,这样等新需求过来,项目产品经理或web前端的技术经理可以通过场景分析该需求需要使用那些现有的技术,

大型WEB站点架构设计文档

1、HTML静态化 其实大家都知道,效率最高、消耗最小的就是纯静态化的html页面,所以我们尽可能使我们的网站上的页面采用静态页面来实现,这个最简单的方法其实也是最有效的方法。但是对于大量内容并且频繁更新的网站,我们无法全部手动去挨个实现,于是出现了我们常见的信息发布系统CMS,像我们常访问的各个门户站点的新闻频道,甚至他们的其他频道,都是通过信息发布系统来管理和实现的,信息发布系统可以实现最简单的信息录入自动生成静态页面,还能具备频道管理、权限管理、自动抓取等功能,对于一个大型网站来说,拥有一套高效、可管理的CMS是必不可少的。 除了门户和信息发布类型的网站,对于交互性要求很高的社区类型网站来说,尽可能的静态化也是提高性能的必要手段,将社区内的帖子、文章进行实时的静态化,有更新的时候再重新静态化也是大量使用的策略,像Mop的大杂烩就是使用了这样的策略,网易社区等也是如此。 同时,html静态化也是某些缓存策略使用的手段,对于系统中频繁使用数据库查询但是内容更新很小的应用,可以考虑使用html静态化来实现,比如论坛中论坛的公用设置信息,这些信息目前的主流论坛都可以进行后台管理并且存储再数据库中,这些信息其实大量被前台程序调用,但是更新频率很小,可以考虑将这部分内容进行后台更新的时候进行静态化,这样避免了大量的数据库访问请求。2、图片服务器分离 大家知道,对于Web服务器来说,不管是Apache、IIS还是其他容器,图片是最消耗资源的,于是我们有必要将图片与页面进行分离,这是基本上大型网站都会采用的策略,他们都有独立的图片服务器,甚至很多台图片服务器。这样的架构可以降低提供页面访问请求的服务器系统压力,并且可以保证系统不会因为图片问题而崩溃,在应用服务器和图片服务器上,可以进行不同的配置优化,比如apache 在配置ContentType的时候可以尽量少支持,尽可能少的LoadModule,保证更高的系统消耗和执行效率。

关于一个大型web系统架构设计和技术选型的讨论摘录概要

关于一个大型web系统架构设计和技术选型的讨论摘录 2007年09月13日星期四上午 09:36 一、 1、数据库压力问题 所有的压力最终都会反映到数据库方面,一定要对数据库有一个整体的规划。 可以按照业务、区域等等特性对数据库进行配置,可以考虑分库、使用rac、分区、分表等等策略,确保数据库能正常的进行交易。 2、事务问题 你采用了两种类型数据库,一个SQL Server、一个oracle,如果一个交易需要在两个数据库中操作,那么必须考虑到分布式事务,你应该仔细的设计你的系统,来避免使用分布式事务,以避免分布式事务带来更多的数据库压力和其它问题。推荐你采用延迟提交的策略(并不保证数据的完整,来避免分布式事务的问题,毕竟commit失败的几率很低。(某个超大型系统,有3套数据库,也是采用的延迟提交策略,避免分布式事务带来的对数据库过大的压力)。 看到了你在应用前端(weblogic EJB采用了F5,我个人不是很赞同这个方案,虽然F5是一个好的L4产品,也能基于第7层做负载均衡和容灾。但是一个有事务交易的EJB,如果采用了这种方案,把不需要使用分布式事务的交易变成了分布式交易,试想,一个web如果在一个请求中,访问了后端两个EJB,那么L4就会有可能把请求分发到不同的服务器上,没有对事务维持在一个服务器中,就不能使用本地事务。同样,一个web,访问后端一个请求,这个请求中需要3个EJB,那么极有可能把这3个请求分发到不同的服务器,又造成了分布式事务。weblogic是一个好的J2EE产品,对这种有事务关联的负载均衡,它会优先考虑采用一个服务器里面的应用,这样就采用了本地事务,提高了响应速度,减小了分布式事务对应用和数据库的压力。 3、web的优化 我个人认为,一个商业的应用,硬件的投资可能不是主要的瓶颈,往往可维护性,可扩展性是最主要的问题。 没有必要采用不成熟的方案,要更多的使用成熟的方案,将静态、图片独立使用不同的服务器,对于常态的静态文件,采用E-TAG或者客户端缓存,google很多就是这样干的。对于热点的功能,考虑使用完全装载到内存,保证绝对的响应速度,对于需要频繁访问的热点数据,采用集中缓存(多个可以采用负载均衡,减轻数据库的压力,比如:很多配置信息,操作员信息等等。 对了,对于几乎除二进制文件,都应该在L4上配置基于硬件的压缩方案,减少网络的流量。提高用户使用的感知。 4、网络问题 你不可能要求所有的使用人员,都和你的服务器在一个运营商的网络内,可以考虑采用镜像、多路网络接入、基于DNS的负载均衡。如果有足够的投资,可以采用CDN(内容分发网,减轻你的服务器压力。 二、F5的负载均衡是必不可少的,他的每秒点击量能达到将近30万,并且它有会话的粘性,只要是同一个ip发过来的请求,它就会把它分到同一台机器的,不用担心分发错误的。现在的问题是apache和tomcat的能力不平衡,动态的内容压力太大,不是数据库的压力,我们的数据库 oracle是RAC群集。性能很好 三、tomcat为什么死掉?当时CPU或者内存的占用率是多少?看看其中JVM占用了多少?有没有OOM的

相关主题
相关文档
最新文档