常见的网站架构设计以及总结

目前网站架构通常分红网页缓存层、负载均衡层、 WEB层和数据库层，我其实通常还会多加一层，即文件服务器层，这样咱们在后面的讨论过程当中，咱们能够依次用这五层对网站架构来进行讨论。

网页缓存层 首先说下这个网页缓存层，好比CDN租赁（效果比公司本身部署Squid/Varnish要好，他们专业，价格低廉，好比快网/CC等（价格80元/M/月不到）并且覆盖的城市更多），本身架设squid/Varnish是次选。另外，不少朋友喜欢尝试自建CDN，这个是一个比较吃力不讨好的活儿，未必能达到预期目标，这块系统架构师在架设网站初期就有规划好，不要等到网站流量及压力巨大时才去规划。事实上，这一层有不少优 秀的开源软件都能胜利，好比传统的Squid Cache，另外，后起之秀Nginx和Varnish由于性能优异，愈来愈多的朋友尝试在本身的网站使用他们做为本身的网页缓存，事实上，Nginx已经具有Squid所拥有的Web缓存加速功能，此外，Nginx对多核CPU的利用，赛过Squid很多，如今愈来愈来的架构师都喜欢将Nginx同时做为“负载均衡服务器”与“Web缓存服务器”来使用，你们能够根据本身网站的状况，来决定究竟使用哪一种软件来做为本身网站的网页缓存。

负载均衡层 首先说下负载均衡层，咱们熟悉的硬件/软件技术有F5，LVS/HAProxy，还有Nginx，它们的性能都是很是优异的，F5/LVS如今在全世界范围内的应用，并且淘宝如今升级架构，也将LVS取代了F5，HAProxy可能你们不是特别熟悉，但HAproxy+Keepalived确实在生产环境下表现优异，强大的吞吐能力，稳定性比之 硬件过尤不及，并用淘宝也在大规模的推广使用HAProxy，有兴趣的朋友也能够关注。再说下Nginx，我是将Nginx+Keepalived架构用于了各类生产环境中的，通过长时间的线上观察，发现Nginx做为负载均衡器/反向代理也很稳定，若是并发压力过大，咱们前面能够用F5/LVS做为最前端的负载均衡，而将Nginx做为七层代理，这样的效果其实也不差，因此负载均衡层的压力不能算是特别大。

WEB层 WEB层这块压力比较大的网站如今都换成了Nginx做为WEB应用服务器，事实上，它的抗并发能力确实超过了预期；我如今维护的一家门户网站，高峰期时某台Nginx应用服务器的并发达到了一万以上，但Nginx也很负责和稳定的提供服务，在实际的生产环境中，若是咱们考虑到后端的数据库服务时，一万并发应该也算是一个比较大的数值了。另外，Linux集群有一个优点，就是它的高扩展性，就算咱们的网站的并发有一万以上，咱们后端的WEB服务是Apache，咱们多加几台 Apache服务器便可，在实际的线上维护时，咱们发现，高峰期间，实际上每台WEB的并发并不算是特别大，因此网站的压力在这一层咱们也能经过技术手段加以克服。

文件服务器层 如今你们的生产服务器通常是使用以下四种来做为本身的文件服务器层： 1）单NFS+备份NFS做为文件服务器，这样的好处是维护方便，但存在着单点故障，须要人为手动干预； 2）DRBD+Heartbeat+NFS高可用文件服务器，维护方便，也不存在着单点故障，但随着访问量的增大，后期同样存在着压力过大的状况； 3）分布式文件系统MFS、Gluster，，MFS易用，稳定，对海量小文件很高效，并且新版的MFS解决了 Master Server存在着单点故障的问题， 国内愈来愈多的公司在使用MFS。事实上，分布式文件系统是解决文件服务器压力过大的最终途径，但这个同时也有隐患，网站功能越多，摊子越大，机器越多，维护起来越复杂。 4）若是你们的公司是淘宝和腾记这种巨量级的公司，能够尝试开发本身的分布式文件系统了，你们能够尝试根据本身网站的状况，来决定究竟选择哪种软件来做为本身的文件服务器。

数据库层 数据库层的压力，我以为网站的PV和并发上去之后，数据库这块的压力是最大的，CDN大型广告网站咱们用的是Oacle RAC方案，它保证了数据的高可用性，固然了价格也是很是昂贵的（若是使用高配置的PC服务器，Oracle通常按照CPU个数收费）；那么免费的 MySQL数据库，面对这种并发压力大的状况，这个时候咱们应该怎么办呢？首先，咱们能够在数据库加入memcached数据缓存，在实际线上使用时，咱们也发现memcached功能强大，性能稳定，在数据库频繁读写，压力过大的状况下，增长一台memcached数据缓存服务器的效果能超过咱们的预期。数据库的硬件方面能够考虑投入，磁盘阵列作成RAID10，若是资金充裕，磁盘能够用固定硬盘来代替SAS硬盘，毕竟数据库的压力主要来自于磁盘I/O方面。合理的设计MySQL数据库的架构，事实上，在生产环境下，一主多从、读写分离是靠谱的设计方案，从 MySQL的负载均衡我这里推荐你们使用LVS，这是由于当后面的MySQL机器超过十台时，HAProxy在这方面的性能不如LVS。若是网站的业务量过大，咱们能够采用分库的方法，好比将网站的业务量分红Web、BBS、Blog等几组，每一组均采用主从架构，这样设计的话就避免了单组数据库压力过大的状况。 另外，咱们还应该配合公司的MySQL DBA和开发人员，在数据库参数优化、SQL语句优化、数据切分上多作功夫，避免数据库成为咱们网站的瓶颈。

但愿你们可以经过以上网站的五层分解，结合本身网站的状况，了解每一层在网站设计中的做用和重要性，找出网站瓶颈加以优化，将本身的网站打形成高可用高可扩展性的网站。

总结： 开始的架构设计也是最难的，须要调研同类产品的状况以及技术特征，了解当前世界上对这种产品所能提供的理论支持和技术平台支持，再结合本身项目的特色(须要透彻的系统分析)，才能逐步造成本身项目的架构蓝图。 好比要开发网站引擎系统，就从Yahoo的我的主页生成工具 到虚拟主机商提供的网站自动生成系统，以及IBM Webphere Portal的特色和局限 从而从架构设计角度定立本身产品的位置。

好的设计确定须要通过反复修改，从简单到复杂的循环测试是保证设计正确的一个好办法。

因为在开始选择了正确的方向，后来项目的实现过程也验证了这种选择，但在一些架构设计的细部方面，还须要对方案进行修改，属于那种螺旋上升的方式，显然这是经过测试第一的思想和XP工程方法来实现的。

若是咱们开始的架构设计在技术平台定位具备必定的世界先进水平，那么，项目开发实际有一半至关于作实验，是研发，存在至关的技术风险。

所以，一开始咱们不可能将每一个需求都实现，而是采起一种简单完成架构流程的办法，使用最简单的需求将整个架构都简单的完成一遍(加入人工干 预)，以检验各个技术环节是否能协调配合工做(很是优秀先进的两种技术有时没法在一块儿工做)，同时也能够探知技术的深浅，掌握项目中的技术难易点。这个过 程完成后，咱们就对设计方案作出上面的重大修改，丰富完善了设计方案。

设计模式是支撑架构的重要组件

架构设计也相似一种工做流，它是动态的，这点不象建筑设计那样，一开始就能彻底肯定，架构设计伴随着整个项目的进行过程之中，有两种具体操做保证架构设计的正确完成，那就是设计模式(静态)和工程项目方法(RUP或XP 动态的)。

设计模式是支撑架构的一种重要组件，这与建筑有很相象的地方，一个建筑物创建设计须要建筑架构设计，在具体施工中，有不少建筑方面的规则和模式。

咱们从J2EE蓝图模式分类 http://java.sun.com/blueprints/patterns/catalog.html中就能够很清楚的看到J2EE这样一个框架软件的架构与设计模式的关系。

架构设计是骨架，设计模式就是肉

这样，一个比较丰富的设计方案能够交由程序员进一步完成了，载辅助以适当的工程方法，这样就可保证项目的架构设计能正确快速的完成。

时刻牢记架构设计的目标

因为架构设计是在动态中完成的，所以在把握架构设计的目标上就很重要，所以在整个项目过程当中，甚至每一步咱们都必须牢记咱们架构设计的整体目标，能够归纳下面几点：

1. 最大化的重用：这个重用包括组件重用 和设计模式使用等多个方面。

好比，咱们项目中有用户注册和用户权限系统验证，这实际上是个通用课题，每一个项目只是有其内容和一些细微的差异，若是咱们以前有这方面成功研发经 验，能够直接重用，若是没有，那么咱们就要进行这个子项目的研发，在研发过程当中，不能仅仅看到这个项目的需求，也要以架构的概念去完成这个能够称为组件的 子项目。

2. 尽量的简单明了：咱们解决问题的总方向是将复杂问题简单化，其实这也是中间件或多层体系技术的根本目标。可是在具体实施设计过程当中，咱们可能会将简单问题复杂化，特别是设计模式的运用上很容易范这个错误，所以如何尽量的作到设计的简单明了是不容易的。

我认为落实到每一个类的具体实现上要真正能体现系统事物的本质特征，由于事物的本质特征只有一个，你的代码越接近它，表示你的设计就是简单明了， 越简单明了，你的系统就越可靠。更多状况是，一个类并不能反应事物本质，须要多个类的组合协调，那么可以正确使用合适的设计模式就称为重中之重。

咱们看一个具有好的架构设计的系统代码时，基本看到的都是设计模式，宠物店(pet store)就是这样的例子。或者能够这样说，一个好的架构设计基本是由简单明了的多个设计模式完成的。

3. 最灵活的拓展性：架构设计要具有灵活性 拓展性，这样，用户能够在你的架构上进行二次开发或更加具体的开发。

要具有灵活的拓展性，就要站在理论的高度去进行架构设计，好比如今工做流概念逐步流行，由于咱们具体不少实践项目中都有工做流的影子，工做流中有一个树形结构权限设定的概念就对不少领域比较通用。

树形结构是组织信息的基本形式，咱们如今看到的网站或者ERP前台都是以树形菜单来组织功能的，那么咱们在进行架构设计时，就能够将树形结构和 功能分开设计，他们之间联系能够经过树形结构的节点link在一块儿，就象咱们能够在圣诞树的树枝上挂各类小礼品同样，这些小礼品就是咱们要实现的各类功 能。

有了这个概念，一般比较难实现的用户级别权限控制也有了思路，将具体用户或组也是和树形结构的节点link在一块儿，这样就间接实现了用户对相应功能的权限控制，有了这样的基本设计方案的架构无疑具有很灵活的拓展性。

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)。这样可下降耦合度。

如今咱们谈一下业务稳定存在理由对业务的影响。存在便是合理，在这里固然是正确的。业务因人而存在，因此问业务存在的理由便是问不一样角色的须要这项业务的理由以及喜欢不喜欢当前业务用例的理由，全部这样的角色都应该在系统里预留。

在架构设计中有几个原则能够考虑：

用例尽可能细分 用例尽可能抽象 角色尽可能独立 项测量独立原则 追求简单性 这里未提供相关的例子，例子会在之后的更新时提供。

业务和模式之间的关系

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