很多Web架构的文章都在谈大规模,高流量,高性能之类的网站架构设计,这类文章一是满足人们好奇心,但看过之后也就看过了,实际收益可能并不大;另外一个副作用是容易让人心潮澎湃,没学走先学跑,在很多条件仍不具备的情况下,过度设计、过度扩展(高德纳也说过,"过早优化是万恶之源"),所以,这里反弹琵琶,讨论一下小规模、低性能、低流量的网站该如何架构。
如果站点起步阶段可能就是一台机器(或是一台虚拟机),这个时候,去关注什么数据拆分啊,负载均衡啊,都是没影子的事情。很多大站点的经验绝不能照搬,辩证的参考才是硬道理。
拥抱熟知的技术
动手构建站点的时候,不要到处去问别人该用什么,什么熟悉用什么,如果用自己不擅长的技术手段来写网站,等你写完,黄花菜可能都凉了。所以,有现成的软件组件可用,就不要自己重新发明轮子。人家说 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 机制上。需要补充的是,对性能的考虑必然要把有关的历史数据考虑进来。另请参见网站运维之道的容量规划以及其它小帖子。
好架构不是设计出来的
这是最后要补充的一点。好的架构和最初的设计有关系,但最重要的是发展中的演化:
发展-->发现问题-->反馈-->解决问题(执行力)--> 改进->进化到下一阶段--新问题出现(循环)有些站点到了某个阶段停足不前,可能卡在执行力这个地方,来自用户的反馈意见上来了之后,没有驱动力去做改进。最后也是死猪不怕开水烫了。最怕听到的就是"业务不允许"的托词,试想如果不改进业务都没了,那业务还允许么? 其实就是一层心理障碍。
分享到:
相关推荐
总的来说,《亿级流量网站架构核心技术》这本书涵盖了从架构设计到运维实践的诸多方面,旨在帮助读者理解和掌握处理大规模流量网站的技术与策略。无论你是初入互联网行业的开发者,还是已经在业界有一定经验的技术...
### WEB2.0高并发高流量网站架构分析 #### 一、硬架构 **1. 机房的选择** 在选择机房时,需考虑的主要因素是目标用户群体的地理位置分布。例如,如果用户主要分布在南方,则可以选择电信机房;若用户主要位于北方...
《面向大规模可伸缩网站基础设施的 MySQL 参考架构》白皮书提供了针对不同规模网站的MySQL设计架构,从小型到超大型网站,确保数据库的高效运行和可伸缩性。以下是各类型网站的参考架构及其特点: 1. **小型(Small)...
在现代互联网技术中,随着用户量和数据量的急速增长,传统的单体架构已经难以满足高效处理大规模流量和数据的需求。因此,分布式系统的设计与实现成为了当今软件开发的重要议题。本文将基于日语资料“分散アプリケー...
随着网站规模的扩大,从单体架构到微服务架构的演进是必然趋势。单体架构在初期便于开发和维护,但随着业务复杂度增加,会出现维护困难、部署缓慢等问题。微服务架构将大系统拆分为小的服务单元,每个服务独立部署,...
通过静态化架构设计,可以实现更高的响应速度和更低的延迟,从而更好地支持大规模的用户访问。 #### 六、结论 对于高并发高负载的网站系统而言,通过实施静态化架构设计不仅可以有效提高系统的性能,还能增强系统...
在架构初期,简单的架构就能满足初创企业或流量较小的平台需求。前端通常使用Apache或Nginx,后端应用服务器采用Java环境如Tomcat,数据库选用MySQL,备份服务器保存配置、代码和数据库备份。这种架构简单且成本较低...
微服务架构的设计原则包括将应用划分成一系列小服务,每个服务可以围绕业务功能组织,可以独立开发、部署和扩展,并且服务治理、数据管理、基础设施自动化、容错和设计都是微服务架构中的关键部分。 OCTO是美团点评...
题目中的错误选项指出“不同的产品业务之间的耦合度很小”并非服务伸缩性的关键特性,实际上低耦合度恰恰是设计伸缩性架构的重要考虑因素。 #### 大数据分布式事务处理 - **事务处理方式**:分布式事务处理常用的...
在构建大型视频网站架构时,带宽和码率的管理是至关重要的,因为它们直接影响到用户的观看体验和服务的稳定性。本文将深入探讨这两个概念以及它们之间的关系。 首先,带宽是指网络连接的数据传输速率,即在单位时间...
综上所述,《架构真经-互联网技术架构的设计原则》全面覆盖了互联网架构设计的各个方面,包括模块化、服务化、高可用性、数据存储、性能优化、安全策略以及DevOps实践。这本书对于想要深入理解互联网技术架构的人来...
包括表现层(PCWeb、APP、小程序、H5)、业务层(在线教育平台、教学竞赛平台、智慧大脑、大数据平台、人工智能平台)、服务层(用户&鉴权服务、内容服务、交易服务、数据服务)和资源层(流量服务器、存储、计算、...
高性能高并发服务器架构是互联网行业中一个至关重要的领域,它涉及到如何设计和构建能够处理大量并发请求,同时保持高效响应速度的系统。对于初创网站或正在发展壮大的在线服务来说,理解并实施这样的架构至关重要,...
在构建大型电子商务网站如eBay时,架构设计是至关重要的,因为它需要应对大规模的数据、流量、用户以及持续增长的需求。eBay的架构设计原则、策略和模式为其他类似规模的平台提供了宝贵的指导。 首先,我们要关注的...
在系统设计中,当单机性能不足以应对流量时,通过增加低性能机器组成集群,共同处理请求。然而,这种方法会带来诸如节点故障处理、状态一致性及动态扩展等复杂问题,需要后续深入学习。 2. **Scale-up(纵向扩展)*...
Netflix的架构设计强调弹性,通过自动扩展和自我修复能力,系统能够在面对高流量或硬件故障时保持稳定。 7. 可扩展性 微服务架构使得Netflix能够轻松地添加新服务或扩展现有服务,以应对不断变化的业务需求和用户...
由于业务规模较小,这样的架构能够满足基本需求,但随着流量增长,其局限性会逐渐显现。 当流量达到百万级别,数据库往往会成为性能瓶颈。这时,可能需要引入分布式数据库、缓存系统(如Redis或Memcached)来缓解...
本文由张玛丽发表,探讨了大规模网站分布式架构的研究与应用,旨在为网站信息化建设提供专业指导。 首先,文章强调了大规模网站系统的安全性。在硬件层面,服务器的物理安全至关重要,包括防火防盗、电源备份和硬件...
【八种架构设计模式及其优缺点】文档详细阐述了软件架构设计中常见的八种模式,每种模式都有其独特的作用和适用场景。首先,我们理解架构就像人类身体的骨架,为软件提供稳定的基础支撑,而设计模式则是经过实践检验...