大型网站架构之系列

 我们知道一个网站都是随着业务的发展,逐渐演变成几万服务器,几亿用户数的大型网站,经历了若干年,甚至上十年的

发展成为大型网站,然而真正亲身经历这个发展过程的人已经不多了,这种人也是拿着公司股票,赶都赶不走的人,所以正因

为很多人没有亲身经历过,所以对架构的演变没有深刻的了解,包括我自己在内,不过没吃过猪肉,也看过猪跑。。。

 

一:第一代架构

  这年头创业大多都是从穷屌丝开始的,奔着 “快好省”的原则建立网站,将“应用程序”,“文件”,“数据库”通通放在一台服务

器上,匆匆的就走上了网站架构之路。

我们知道业务的发展对技术会有更高的要求,业务的创新会触动技术的创新,当业务逐渐发展起来的时候,最容易出现的问题就是

”存储空间“和通用的”性能低下“,这个时候就需要做到”应用程序“和”数据“的分离。

 

二:第二代架构

   随着业务规模的扩大,需要将”应用程序“,”文件“,”数据库“进行分离,用更强大的cpu处理服务器来承载应用程序,记得在上一

家用的cpu就是16核,”文件“的话则需要更大的磁盘空间的服务器,”数据库“的话需要更大的磁盘和超大内存的服务器,我们知道

sqlserver还是很吃内存的,记得用过最大的是120g的内存。

随着业务规模不断扩大,访问人数逐渐增多,我们也开心了,起码挣到钱了,然后我们会发现数据库开始出现瓶颈了,大量的读写操作让

数据库出现访问延迟以及死锁现象的发生,继而影响用户体验。

 

三:第三代架构

     既然大量的读写操作让数据库出现瓶颈了,这个时候就要从两个方面优化读写操作

1. 读操作

 

    我们知道任何东西都是遵守二八原则,也就是网站上经常访问的东西也就那么多,对于这种命中率非常高的东西就需要用缓存来处理,

  减少读的次数,在携程里面的memcache就做了“数据热度”的操作,对于热度低的数据会自动从缓存中踢掉。

 

2. 写操作

    这个有分及时写和非及时写,对于非及时写的数据,我们可以采用 “消息队列”来对写操作节流,从而缓解数据库写入时的瞬时压力。

这时候数据库的读写操作得到了很大的缓解,随着业务规模的继续扩大,用户人数的再次暴增,我们会发现”应用程序服务器“的CPU

经常高烧不退,被玩爆的次数越来越多。

 

四:第四代架构

      既然被爆表了,这时候必须再拉一个应用程序服务器来分摊前端访问带来的压力,做了集群之后,需要再配一台”负载均衡调度器“,

不过屌丝公司用的比较多的还是nginx,高大上的公司都是动辄几十万的硬件负载均衡,比如携程用的就是A10,还有市场上几十万F5

等等产品。

 

好了,先大概这么说了,睡觉时间到了,明天继续往下扯。



 这篇文章本来准备前几天就得写的,谁也没想到这段时间公司的RC太多了,含酸苦逼的加班,加班。。。所以在大一点的公司上班,

写代码的责任心一定要强,或许就因为你的一些小bug,给公司带来不少损失。。。这在以前公司真的没多大体会的。

  好了,继续说说架构的演变,从第四代架构中可以看到,我们通过做应用程序层的负载均衡可以比较完美的解决了在整个架构中让应

用程序层不再成为瓶颈,通过A10,我们可以让用户的访问请求分发到集群中的任何一台服务器上,当访问量继续膨胀的时候,我们就可

以继续在集群中增加服务器来解决负载的压力,达到系统的可伸缩性,现在我们的业务规模像滚雪球一样越来越大,用户数暴增。。。这

时候我们缓存中的数据也越来越多,虽然我们用了缓存,但是大量的“缓存过期重新读取”和“缓存不命中",导致数据库压力非常大,这时候

数据库的压力成为了我们架构中的瓶颈。

 

五: 第五代架构

   既然数据库成为了我们第四代架构的瓶颈,这时候必须解决数据库的压力问题,最常见的做法也就是“读写分离”,将写和读的库进行拆

分来缓解数据库的压力。

  

现在我们做了多个库,写的时候进主库,然后数据库分发到从库中,然后应用程序在从库中读取,这里为了让数据库对应用程序更加

透明,我们通常加一个“数据访问层”,在携程里面就是在企业库上进行了一层封装以及安全性采用了all in one 模式,可以看到第五代

架构对数据库的压力有了很大的缓解。

   经过几个月业务喷井式的发展之后,我们会发现数据库检索越来越慢,单表数据量已经差不多爆炸了。。。已经严重影响到系统性能,

用户抱怨不断,这时候“数据检索”成为了我们系统的严重瓶颈。

 

六:第六代架构

  既然检索成了瓶颈,我们必须对数据库进行拆分,尽可能的减少检索中的数据量规模以及尽可能的优化算法。

  1:业务分库

      我们将不同的业务分摊到不同的业务服务器上,而不是将其耦合在一个数据库里面,从而建立起数据库集群,分流应用层对数

  据库的压力。

  2:分表

  可以采用时间划分,将三个月之后的数据放入到历史表里面,当前表只保存三个月之内的数据,而从极大提供单表的检索能力。

  3:采用nosql

    nosql就是为了web而生,分词,系统日志等等,一样都让不少nosql,而且nosql有其天生的负载均衡。

  4:优化算法

     栈,队列,二叉树,哈希 等等变换和非变换的数据结构在这种大数据的场景下可以得到灵活运用,这也是区分高级程序员和低等

   码农的一条参考标准。

      当你的架构到这个程度的时候,差不到公司的人数也过千了,这时候我们的业务会分成很多产品线的,比如:机票事业部,酒店

事业部,旅游度假事业部,攻略社区事业部,每个事业部只会负责自己的产品架构,从而将我们的架构再次细分,从技术角度看,这些

事业部又可以提炼出公共的部门,比如登录模块,订单处理等等这些可复用的模块,可以相应的成立公共平台事业部和框架架构部,当

这个架构继续往下发展的话,就有了现在的各种云,也就成了各种变钱的工具了,就比如现在的博客园托管在阿里云之上。。。

 

     终于在今天,结束了高层重视的IVR项目的所有事情,最后祭奠一下,自从猪猪侠拿到那些所谓的数据,导致我们连续加班的日日夜夜。


资源下载链接为: https://pan.quark.cn/s/1bfadf00ae14 “STC单片机电压测量”是一个以STC系列单片机为基础的电压检测应用案例,它涵盖了硬件电路设计、软件编程以及数据处理等核心知识点。STC单片机凭借其低功耗、高性价比和丰富的I/O接口,在电子工程领域得到了广泛应用。 STC是Specialized Technology Corporation的缩写,该公司的单片机基于8051内核,具备内部振荡器、高速运算能力、ISP(在系统编程)和IAP(在应用编程)功能,非常适合用于各种嵌入式控制系统。 在源代码方面,“浅雪”风格的代码通常简洁易懂,非常适合初学者学习。其中,“main.c”文件是程序的入口,包含了电压测量的核心逻辑;“STARTUP.A51”是启动代码,负责初始化单片机的硬件环境;“电压测量_uvopt.bak”和“电压测量_uvproj.bak”可能是Keil编译器的配置文件备份,用于设置编译选项和项目配置。 对于3S锂电池电压测量,3S锂电池由三节锂离子电池串联而成,标称电压为11.1V。测量时需要考虑电池的串联特性,通过分压电路将高电压转换为单片机可接受的范围,并实时监控,防止过充或过放,以确保电池的安全和寿命。 在电压测量电路设计中,“电压测量.lnp”文件可能包含电路布局信息,而“.hex”文件是编译后的机器码,用于烧录到单片机中。电路中通常会使用ADC(模拟数字转换器)将模拟电压信号转换为数字信号供单片机处理。 在软件编程方面,“StringData.h”文件可能包含程序中使用的字符串常量和数据结构定义。处理电压数据时,可能涉及浮点数运算,需要了解STC单片机对浮点数的支持情况,以及如何高效地存储和显示电压值。 用户界面方面,“电压测量.uvgui.kidd”可能是用户界面的配置文件,用于显示测量结果。在嵌入式系统中,用
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值