网站架构方案应包括哪些方面 网站架构方案应包括如下几个方面：网络管理系统：包括网络结构、服务器架构与有关硬件设备部署的整合设计。应用管理系统：包括web服务、数据库服务、应用服务、邮件服务的整合设计；业务管理系统：包括网站内容管理、社区论坛、资源管理、视频点播、短信娱乐、广告管理等业务内容的整合设计；网络安全系统：包括数据存储备份恢复、系统监控、流量分析、应用审计等网络安全的整合设计；文档目录可以划分为：一、概　　述 5二、需求分析 52.1 异构系统 62.2 异构应用 82.3 异构数据 82.4 网站结构 92.5 内容海量 102.6 内容深度 102.7 服务深度 102.8 发布系统 112.9 网络安全 112.10 信息安全 11三、方案整体规划 113．1设计目标 113．2实施规划 12四、网络解决方案 134.1 拓扑结构图 144.2 硬件选型、分布与规划 144.2.1 数据库服务器 144.2.2 web发布服务器 154.2.3 cgi服务器 154.2.4 内容管理发布服务器 154.2.5 内容管理生成服务器 154.2.6 数据存储设备 154.2.7 安全设备 164.2.8 防病毒 164.2.9 原有服务器与置换服务器比较 164.3 新增硬件配置清单 18五、软件解决方案 185.1系统架构 185.2系统软件整合 195.3 网站内容管理系统 205.3.1网站内容管理系统介绍 205.3.2网站后台管理系统 215.3.3网站采编应用系统 225.3.4网站调查投票子系统 255.3.5站点内容全文检索子系统 265.3.6文章评论系统 265.3.7网站论坛、聊天室子系统 265.3.8网站会员认证管理子系统 315.3.9网站广告发布子系统 32六、网站音视频管理系统 326.1用户需求分析 326.2 产品概述 336.3技术特点 336.4基础构架和运行环境 346.5 功能描述 344.3.6 拓扑结构图 394.3.7音视频系统组成 39七、项目实施进度安排 427.1项目领导小组 427.2 项目实施小组 427.3质量监督小组 437.4系统集成实施进度计划及工作日程表 43八、培训、支持和服务 448.1 培训服务 448.1.1 基本操作培训 448.1.2 系统管理培训 448.1.3 培训安排 458.1.4 培训内容 458.2 技术支持服务 458.2.1 硬件平台技术支持 458.2.2 应用软件平台技术支持 458.3 售后服务 46九、小结 46附录 47硬件产品说明 47hp dl 580 47hp dl 380 49

网站架构设计原则-小规模低性能低流量 到处都是什么大规模啊，高流量啊，高性能之类的网站架构设计，这类文章一是满足人们好奇心，但看过之后也就看过了，实际收益可能并不大；另外一个副作用是容易让人心潮澎湃，没学走先学跑，在很多条件仍不具备的情况下，过度设计、过度扩展(高德纳大爷也说过，”过早优化是万恶之源”)，所以，这里反弹琵琶，讨论一下小规模、低性能、低流量的网站该如何搞法。如果站点起步阶段可能就是一台机器(或是一台虚拟机，比如 JobsDigg.com )，这个时候，去关注什么数据拆分啊，负载均衡啊，都是没影子的事情。很多大站点的经验绝不能照搬，辩证的参考才是硬道理。拥抱熟知的技术动手构建站点的时候，不要到处去问别人该用什么，什么熟悉用什么，如果用自己不擅长的技术手段来写网站，等你写完，黄花菜可能都凉了。所以，有现成的软件组件可用，就不要自己重新发明轮子。人家说 Python 牛，但自己只懂 PHP ，那就 PHP 好了，如果熟悉 .net ?，那也不错。用烂技术不是丢人的事情，把好技术用烂才丢人。架构层次清晰化起步的阶段应该清楚的确定下来架构的层次。如果都搅和在一起，业务一旦扩增开来，如果原有的一堆东西拆不开就是非常痛苦的事情。Web Server <–> (AppServer)<–>Cache(eg. Memcached)<–>DB层次清晰化的一个体现是(以 LAMP 架构为例)：即使只有一台机器，也应该起个 Memcached 的实例，效果的确非常好–一般人儿我不告诉他…不要把什么都压到 DB 上，DB 一旦 I/O 压力走到磁盘上，问题要暴露出来是很快的。没错，DB 本身也会利用自己的 Cache，但 DB 的Cache 和 Memcached 设计出发点毕竟不一样。数据冗余? 有必要很多人并不是数据库设计专家，如果应用要自己设计表结构什么的，基本都是临时抱佛脚，但三个范式很多人倒是记得牢，这是大多数小型 Web 站点遇到的一个头疼事儿，一个小小的应用搞了几十个表… 忘掉范式这个玩意儿! 记住，尽可能的冗余数据，你在数据层陷入的时间越多，你在产品上投入的就会越少。用户更关心的是产品的设计。前端优化很重要因为流量低，访客可能也不多，这时候值得注意的是页面不要太大，多数流量低的站点吃亏就在于一个页面动辄几兆(我前两天看到一个Startup的首页有4M之大,可谓惊人)，用户看个页面半分钟都打不开，你说咋发展? 先把基本的条件满足，再去研究前端优化。功能增加要谨慎不是有个 80/20 原则么? 把最重要的精力放在最能给你带来商业价值的地方。有些花里胡哨的功能带来很大的开销，反而收效甚微。记住，小站点，最有价值的是业务模式，而不是你的技术有多牛。技术是为业务服务的，不要炫技。有些网站不停的添加功能，恰恰是把这些新功能变成了压死自己的稻草。从开始考虑性能这一点是可选的，但也重要。设计应用的时候在开始就应考虑 Profile 这件事情。一套应用能否在后期进行有效优化和扩展，很大的程度限制在是否有比较合适的 Profile 机制上。需要补充的是，对性能的考虑必然要把有关的历史数据考虑进来。另请参见网站运维之道的容量规划以及其它小帖子。好架构不是设计出来的这是最后要补充的一点。好的架构和最初的设计有关系，但最重要的是发展中的演化：发展–>发现问题–>反馈–>解决问题(执行力)–> 改进->进化到下一阶段–新问题出现(循环)有些站点到了某个阶段停足不前，可能卡在执行力这个地方，来自用户的反馈意见上来了之后，没有驱动力去做改进。最后也是死猪不怕开水烫了。最怕听到的就是”业务不允许”的托词，试想如果不改进业务都没了，那业务还允许么? 其实就是一层心理障碍。这篇文章有浓重的山寨风格，所以，你不要太认真。如果在用短、平、快的方式构建某些山寨网站的话，可参考其中对你有益的点，不赞同的地方可以直接忽视掉，就没必要费力留言进行争论了。作者: Fenng 网址: http://www.dbanotes.net/arch/small_site_arch.html