用户48832393
简述WEB系统的架构原理
这个话题太大了。
一般来说，WEB系统，主要是指后端，前端就是各种浏览器了。
那么简单来讲，只要是能与浏览器通过网络交互的系统，都可以算是WEB系统。
最简洁的就是用NODEJS写一个echo，就是客户端发什么内容，就回什么内容。
而在实际应用中，WEB系统的架构，一般有这么几个部分：负载均衡、授权验证（可选）、静态内容服务、动态内容服务（业务逻辑）、数据库、运维后台。
1）负载均衡是为了改善用户体验、充分利用服务器资源，主要功能是将新的请求转发到不那么忙的服务器进行处理。
2）授权验证，是在对浏览器发起的请求进行授权校验，如果不是合法的请求，就予以拒绝或者重定向至登录页面。
3）静态内容服务，是指图片、CSS等不会根据不同用户而变化的静态内容，将其直接返回给用户。
因为不需要进行逻辑判断，性能主要取决于I/O读写，响应可以非常快。
超大型网站，也会把一部分动态内容，例如对访问量大的新闻页，做静态处理，以提升响应速度。
静态内容服务的典型是CDN。
4）动态内容服务，是根据用户请求的不同，而进行响应的业务逻辑处理。
比如对用户数据的CRUD（增删查改）。
这是绝大多数WEB系统的核心所在，一般会调用数据库和数据缓存。
具体实现会根据业务需要而变化，也可以变得非常复杂。
5）数据库，是数据所在，既有经典的关系型传统数据库系统，也有为了提升访问性能、减轻的内存数据库。
6）运维后台，是为了方便监控运行状态、升级维护系统，不直接参与对外服务。
先写这么多吧。
有具体的问题了，可以再问。
...
软件的架构与设计模式之什么是架构
一个系统通常是由元件组成的，而这些元件如何形成、相互之间如何发生作用，则是关于这个系统本身结构的重要信息。
具体地说，就是要包括架构元件（Architecture Component）、联结器（Connector）、任务流（Task-flow）。
所谓架构元素，也就是组成系统的核心＂砖瓦＂，而联结器则描述这些元件之间通讯的路径、通讯的机制、通讯的预期结果，任务流则描述系统如何使用这些元件和联结器完成某一项需求。
·建造一个系统所作出的最高层次的、以后难以更改的，商业的和技术的决定。
在建造一个系统之前会有很多的重要决定需要事先作出，而一旦系统开始进行具体设计甚至建造，这些决定就很难更改甚至无法更改。
显然，这样的决定必定是有关系统设计成败的最重要决定，必须经过非常慎重的研究和考察。
计算机软件的历史开始于五十年代，历史非常短暂，而相比之下建筑工程则从石器时代就开始了，人类在几千年的建筑设计实践中积累了大量的经验和教训。
建筑设计基本上包含两点，一是建筑风格，二是建筑模式。
独特的建筑风格和恰当选择的建筑模式，可以使一个独一无二。
下面的照片显示了中美洲古代玛雅建筑，Chichen-Itza大金字塔，九个巨大的石级堆垒而上，九十一级台阶（象征着四季的天数）夺路而出，塔顶的神殿耸入云天。
所有的数字都如日历般严谨，风格雄浑。
难以想象这是石器时代的建筑物。
图1、位于墨西哥Chichen-Itza（在玛雅语中chi意为嘴chen意为井）的古玛雅建筑。
（摄影：作者）软件与人类的关系是架构师必须面对的核心问题，也是自从软件进入历史舞台之后就出现的问题。
与此类似地，自从有了建筑以来，建筑与人类的关系就一直是建筑设计师必须面对的核心问题。
英国首相丘吉尔说，我们构造建筑物，然后建筑物构造我们（We shape our buildings, and afterwards our buildings shape us）。
英国下议院的会议厅较狭窄，无法使所有的下议院议员面向同一个方向入座，而必须分成两侧入座。
丘吉尔认为，议员们入座的时候自然会选择与自己政见相同的人同时入座，而这就是英国政党制的起源。
Party这个词的原意就是＂方＂、＂面＂。
政党起源的要害就是建筑物对人的影响。
在软件设计界曾经有很多人认为功能是最为重要的，形式必须服从功能。
与此类似地，在建筑学界，现代主义建筑流派的开创人之一Louis Sullivan也认为形式应当服从于功能（Forms follows function）。
几乎所有的软件设计理念都可以在浩如烟海的建筑学历史中找到更为遥远的历史回响。
最为闻名的，当然就是模式理论和XP理论。
架构的目标是什么正如同软件本身有其要达到的目标一样，架构设计要达到的目标是什么呢？一般而言，软件架构设计要达到如下的目标：·可靠性（Reliable）。
软件系统对于用户的商业经营和治理来说极为重要，因此软件系统必须非常可靠。
·安全行（Secure）。
软件系统所承担的交易的商业价值极高，系统的安全性非常重要。
·可扩展性（Scalable）。
软件必须能够在用户的使用率、用户的数目增加很快的情况下，保持合理的性能。
只有这样，才能适应用户的市场扩展得可能性。
·可定制化（Customizable）。
同样的一套软件，可以根据客户群的不同和市场需求的变化进行调整。
·可扩展性（Extensible）。
在新技术出现的时候，一个软件系统应当答应导入新技术，从而对现有系统进行功能和性能的扩展·可维护性（Maintainable）。
软件系统的维护包括两方面，一是排除现有的错误，二是将新的软件需求反映到现有系统中去。
一个易于维护的系统可以有效地降低技术支持的花费·客户体验（Customer Experience）。
软件系统必须易于使用。
·市场时机（Time to Market）。
软件用户要面临同业竞争，软件提供商也要面临同业竞争。
以最快的速度争夺市场先机非常重要。
架构的种类根据我们关注的角度不同，可以将架构分成三种：·逻辑架构、软件系统中元件之间的关系，比如用户界面，数据库，外部系统接口，商业逻辑元件，等等。
比如下面就是笔者亲身经历过的一个软件系统的逻辑架构图 图2、一个逻辑架构的例子从上面这张图中可以看出，此系统被划分成三个逻辑层次，即表象层次，商业层次和数据持久层次。
每一个层次都含有多个逻辑元件。
比如WEB服务器层次中有Html服务元件、session服务元件、安全服务元件、系统治理元件等。
·物理架构、软件元件是怎样放到硬件上的。
比如下面这张物理架构图描述了一个分布于北京和上海的分布式系统的物理架构，图中所有的元件都是物理设备，包括网络分流器、代理服务器、WEB服务器、应用服务器、报表服务器、整合服务器、存储服务器、主机等等。
图3、一个物理架构的例子·系统架构、系统的非功能性特征，如可扩展性、可靠性、强壮性、灵活性、性能等。
系统架构的设计要求架构师具备软件和硬件的功能和性能的过硬知识，这一工作无疑是架构设计工作中最为困难的工作。
此外，从每一个角度上看，都可以看到架构的两要素：元件划分和设计决定。
首先，一个软件系统中的元件首先是逻辑元件。
这些逻辑元件如何放到硬件上，以及这些元件如何为整...
怎样具备大规模高并发访问的Web应用架构设计和开发经验
理论上经验这个东西是学不来的.说一下我的例子.刚入行的时候，基本就是写了一些增删改查.甚至session都不太理解.随着入行后，你会遇到各种各样的问题.在解决问题的过程中，经验来了.简单说一下所谓大规模高并发访问的web架构吧.其实，对于大规模高并发不外乎两点，第一点是及时相应（尽可能优化io）.第二点是数据安全.这两点控制的好，就没问题的.所以，我们的架构也就围绕在这两点应运而生.第一点，为了尽可能提高应用的io吞吐量.则需要我们把所有耗时的io操作尽可能的优化，比如全局使用很少更改的一些配置，则可以采用nosql来全局共享（注意，这里的全局是指服务器集群.如果涉及到了大规模，肯定是多服务器的）.在其次可以增加服务器缓存.比如2秒钟从上一条的服务器读取配置，存到服务器级别.以提高效率.还有线程缓存.如果业务复杂可能对一个请求需要查询多次数据，不变的，老规矩，放到线程缓存.基本也就差不多了.第二点，因为应用不同，要考虑容错率.这个部分优化，可以考虑分离业务，把必须要数据安全的业务逻辑提取出来，队列执行或者特殊处理.剩下的就是服务器部署与如何分配，比如多少台web服务器，数据库配置，内存服务器配置等.这只能是在实际项目和工作过程中来区别对待了....
什么是系统架构设计？
架构师的职责主要有如下4条：1、确认需求在项目开发过程中，架构师是在需求规格说明书完成后介入的，需求规格说明书必须得到架构师的认可。
架构师需要和分析人员反复交流，以保证自己完整并准确地理解用户需求。
2、系统分解依据用户需求，架构师将系统整体分解为更小的子系统和组件，从而形成不同的逻辑层或服务。
随后，架构师会确定各层的接口，层与层相互之间的关系。
架构师不仅要对整个系统分层，进行“纵向”分解，还要对同一逻辑层分块，进行“横向”分解。
软件架构师的功力基本体现于此，这是一项相对复杂的工作。
3、技术选型架构师通过对系统的一系列的分解，最终形成了软件的整体架构。
技术选择主要取决于软件架构。
Web Server运行在Windows上还是Linux上？数据库采用MSSql、Oracle还是Mysql？需要不需要采用MVC或者Spring等轻量级的框架？前端采用富客户端还是瘦客户端方式？类似的工作，都需要在这个阶段提出，并进行评估。
架构师对产品和技术的选型仅仅限于评估，没有决定权，最终的决定权归项目经理。
架构师提出的技术方案为项目经理提供了重要的参考信息，项目经理会从项目预算、人力资源、时间进度等实际情况进行权衡，最终进行确认。
4、制定技术规格说明架构师在项目开发过程中，是技术权威。
他需要协调所有的开发人员，与开发人员一直保持沟通，始终保证开发者依照它的架构意图去实现各项功能。
架构师不仅要保持与开发者的沟通，也需要与项目经理、需求分析员，甚至与最终用户保持沟通。
所以，对于架构师来讲，不仅有技术方面的要求，还有人际交流方面的要求。
怎样看web项目的系统架构设计
如何选择Web开发框架 开发框架的选择，始终是个仁者见仁、智者见智的事情。
尤其是Web层的开发框架，数量非常多，而且各有特色，如：Struts、WebWork、Spring MVC、Tapestry、JSF、WebPage3.0……等等。
下面先来看看为什么要使用Web开发框架 一 使用框架的必然性 框架，即framework。
其实就是某种应用的半成品，把不同应用程序中有共性的一些东西抽取出来，做成一个半成品程序，这样的半成品就是所谓的程序框架。
软件系统发展到今天已经很复杂了，特别是服务器端软件，涉及到的知识，内容，问题太多。
在某些方面使用别人成熟的框架，就相当于让别人帮你完成一些基础工作，你只需要集中精力完成系统的业务逻辑设计。
这样每次开发就不用白手起家，而是可以在这个基础上开始搭建。
使用框架的最大好处：减少重复开发工作量、缩短开发时间、降低开发成本。
同时还有其它的好处，如：使程序设计更合理、程序运行更稳定等。
基于这些原因，基本上现在在开发中，都会选用某些合适的开发框架，来帮助快速高效的开发应用系统。
了解了使用框架的必然性，下面来看看如何选择，当然我们的话题集中在Web层的开发框架。
在谈这个问题之前，先来看看我们在Web开发中究竟需要做些什么工作：二 Web层开发的工作 在J2EE开发中，分层是基本的思想，3层架构或者多层架构早已深入人心，在这里我们就把目光集中到Web层，看看到底Web层开发做了那些工作：1：数据展示 Web层需要从逻辑层获取需要展示的数据，然后以合理的方式在页面进行展示2：人机交互 用户需要从界面上输入数据，在界面上进行按钮点击，进而触发事件，标准的事件驱动模型，然后跟后台进行数据交换，出现新的界面。
3：收集数据，调用逻辑层接口 Web层收到用户的事件请求，需要调用相应的逻辑层接口来进行处理，Web层是不会有任何逻辑处理的。
调用逻辑层接口，需要传递参数，这时需要收集用户在界面上输入的数据，然后进行组织，组织成为逻辑层接口需要的数据封装形式（通常都是ValueObject）。
4：根据逻辑层的数据来重新展示页面 逻辑层处理完了，需要返回数据或信息到界面上。
这个时候Web层需要根据返回的值选择合适的页面，然后展示这些数据或者信息。
从上面可以看出，Web层开发的主要工作集中在展示上，也就是图形用户界面。
这一部分是用户直观感受应用程序的窗口，也是用户要求最多的地方，其表现形式也是最丰富的。
三 Web层开发的步骤 下面再来总结一下Web层开发的大致步骤（也就是需要开发人员做的工作）：注意：这里讨论的Web层开发，是不使用任何开发框架时候的开发。
1：写页面Html，到底有哪些数据需要在界面上表现2：每个数据的具体表现形式，如：有的需要表现成为下拉列表，有的需要表现成为单选按钮等。
3：界面表现形式的逻辑布局，所谓逻辑布局是指某些数据的表现形式应该放在前面，某些应该放在后面；某些放在上面，某些放在下面。
如：某个请假申请 的业务，有请假开始时间和结束时间，很明显开始时间的表现就应该排在结束时间的前面。
而美工是负责最后页面的美观，一般美工不能动界面的逻辑布局。
4：完成前面3步，页面的表现形式的大致模样就有了，下面需要来做功能性的开发。
第一个就是这些表现形式的值的来源，如：下拉列表显示的值从什么地方来。
值的来源方式很多，有数据库中来、固定值、某断程序运行的中间结果、前面页面传递过来等等，当然典型的还是来自数据库。
好了，确定了值的来源，开发人员就要写代码来获取这些值，然后把这些值赋值到对应的表现形式里面。
5：还有一些比较特殊，也就是真实操作的是一类值，但是在界面上显示的是另一类值，比如：数据库中有用户编号，到了界面上就得显示用户姓名，但是所 有的操作都是要操作用户编号的。
我们把这种情况分做：真实值和表现值，他们有一定的内在联系。
这些都是要开发人员去转化和维护的。
6：接下来就应该开发功能性的事件响应了。
用户点击了某个按钮或者触发了某个事件，首先是客户端：数据检测、客户端事件处理；然后提交到服务端，服务端要获取到客户端提交的数据，然后调用相应的逻辑层接口来响应。
当然如何写逻辑层的实现这里就不去谈论了。
7：逻辑层执行完过后，返回数据和信息到Web层，开发人员还需要写代码去处理，选择哪个页面来显示，如何显示这些数据和信息等。
8：在整个交互的过程中，还必须考虑到如何控制权限，如：某些数据不能显示，某些数据不能编辑等等；同样还需要考虑到消息的配置和国际化等等。
这些功能起源于逻辑层，但是实际的控制要到Web层，这些都需要开发人员来控制。
9：完成了上面的开发步骤，页面基本的功能开发就告一段落，接下来开发人员需要考虑页面美观的问题了。
大家可能会说：“不是有美工吗，还需要开发人 员干什么？”。
事实上美工多半只能出一个静态页面的美化模版，美工对于一推Java代码和Html的混杂物，多半是没有办法的，更不要说还有一些内容是动 态生成的，美工就更不可能搞定了。
还是得开发人员上阵，按照美工给的模版，开...
什么是MVC架构？
MVC架构是交互式应用中广泛使用的架构。
它将对象按功能进行划分，尽可能地最小化对象之间的耦合度。
MVC架构与传统的应用程序架构—输入，处理，输出给用户接口的模型相对应。
它们也与基于域的多层企业级WEB应用相对应。
MVC架构将应用分为三层—模型，视图，控制，并减弱它们各自的责任。
每一层处理特定的任务并对其它层有特殊的责任。
A. 模型存储业务数据和控制访问与修改业务数据的业务逻辑或操作。
表现上看，模型与软件中的函数功能有些相似。
当模型改变时会通知视图并为视图提供了查询模型状态的能力。
它也为控制器提供了访问封装在模型中的应用功能函数的能力。
B. 视图展示模型中的内容。
它访问模型中的数据并完成数据的显示工作。
当模型改变时它会即时更新数据的展示。
视图也完成将用户的输入传递到控制器的功能。
C. 控制器定义了应用程序的行为。
它分派用户的请求然后调用相应的视图来展示。
它解析用户的输入然后与模型中完成相应功能的事件处理相匹配。
在标准的GUI客户端应用中，用户输入包括点击按钮和选择菜单。
在WEB应用中，它们则是WEB层中的HTTP GET和POST请求。
控制器选择相应的视图来显示是基于用户与模型相互交互的结果。
一个典型的应用是所有相关的功能由一个控制器来处理。
一些应用针对不同的客户端类型采用不同的控制器来处理，因为视图的交互与选择可能因客户端类型的不同而有所不同。
web前端与后端有什么区别？
Web前端： 顾名思义是来做Web的前端的。
我们这里所说的前端泛指Web前端，也就是在Web应用中用户可以看得见碰得着的东西。
包括Web页面的结构、Web的外观视觉表现以及Web层面的交互实现。
Web后端：后端更多的是与数据库进行交互以处理相应的业务逻辑。
需要考虑的是如何实现功能、数据的存取、平台的稳定性与性能等。
具体如下：1、web前端开发工程师是负责交互设计的，需要和程序猿进行交互设计的配合。
2、web前端需要掌握的有脚本技术javascript DIV+CSS现下最流行的页面搭建技术，ajax和jquery以及简单的后端程序等。
3、 后端的话可供开发的语言有asp、php、jsp、.NET 这些后端开发语言的话搭建环境都不一样，具体如果你想学的话看是想从事前端部分还是后端程序部分。
4、后端开发如果有一定的条件的话可以转为软件开发。
不过要有一定的语言基础，类似java语言、C++等。
关键是看你的兴趣爱好。
门户网站的技术架构怎样设计方案
架构师的职责主要有如下4条：1、确认需求在项目开发过程中，架构师是在需求规格说明书完成后介入的，需求规格说明书必须得到架构师的认可。
架构师需要和分析人员反复交流，以保证自己完整并准确地理解用户需求。
2、系统分解依据用户需求，架构师将系统整体分解为更小的子系统和组件，从而形成不同的逻辑层或服务。
随后，架构师会确定各层的接口，层与层相互之间的关系。
架构师不仅要对整个系统分层，进行“纵向”分解，还要对同一逻辑层分块，进行“横向”分解。
软件架构师的功力基本体现于此，这是一项相对复杂的工作。
3、技术选型架构师通过对系统的一系列的分解，最终形成了软件的整体架构。
技术选择主要取决于软件架构。
WebServer运行在Windows上还是Linux上？数据库采用MSSql、Oracle还是Mysql？需要不需要采用MVC或者Spring等轻量级的框架？前端采用富客户端还是瘦客户端方式？类似的工作，都需要在这个阶段提出，并进行评估。
架构师对产品和技术的选型仅仅限于评估，没有决定权，最终的决定权归项目经理。
架构师提出的技术方案为项目经理提供了重要的参考信息，项目经理会从项目预算、人力资源、时间进度等实际情况进行权衡，最终进行确认。
4、制定技术规格说明架构师在项目开发过程中，是技术权威。
他需要协调所有的开发人员，与开发人员一直保持沟通，始终保证开发者依照它的架构意图去实现各项功能。
架构师不仅要保持与开发者的沟通，也需要与项目经理、需求分析员，甚至与最终用户保持沟通。
所以，对于架构师来讲，不仅有技术方面的要求，还有人际交流方面的要求。
