网络安全人员需要了解的网站技术架构

来源：xybaby cnblogs.com/xybaby/p/8907880.html

花了几个晚上看完了《大型网站技术架构》（）这本书，个人感觉这本书的广度还行，深度还有些欠缺（毕竟只有200页左右）。但是作为一个缺乏大型网站技术的IT民工，看完一遍还是很有收获的，至少对一个网站的技术演进、需要解决的问题有了一个全面的认识。文中也有一些作者个人的心得、感悟、总结，我觉得还是很中肯的。

在网上一搜，这本书的读书笔记还是很多的，而我自己还是决定写一篇读书笔记，主要是为了避免自己忘得太快。笔记的内容并不完全按照原书的内容，主要记录的是我自己感兴趣的部分。

一个网站的进化史

作者反复在文中提到一个观点：大型网站是根据业务需求逐步演化而来的，而不是设计出来的。

不得不承认，互联网行业发展到了今天，大鱼吃小鱼还是很普遍的，大公司的微创新能力分分钟就能干死一个小的项目，所以小公司需要足够快的发展，不停的快速迭代与试错。

下面是是一个演化的过程，图片来自网络。

初始阶段的网站架构

img

在初始阶段，访问量并不大，所以应用程序、数据库、文件等所有的资源都在一台服务器上。

应用服务和数据服务分离

img

随着业务的发展，就会发现一台服务器抗不过来了，所以将应用服务器与数据（文件、数据库）服务器分离。三台服务器对硬件资源的要求各不相同：应用服务器需要更快的CPU，文件服务器需要更大的磁盘和带宽，数据库服务器需要更快速的磁盘和更大的内存。分离之后，三个服务器各司其职，也方便针对性的优化。

使用缓存改善网站性能

img

“世界上没有什么问题是加一级缓存解决不了的，如果有那就再加一级缓存”

缓存的使用无处不在，缓存的根本目的是加快访问速度。当数据库的访问压力过大的时候，就可以考虑使用缓存了。网站使用的缓存可以分为两种: 缓存在应用服务器上的本地缓存和缓存在专门的分布式缓存服务器上的远程缓存。

使用应用服务器集群改善网站的并发处理能力

img

随着业务的发展，单个应用服务器一定会成为瓶颈，应用服务器实现集群是网站可伸缩集群架构设计中较为简单成熟的一种。后面也会提到，将应用服务器设计为无状态的（没有需要保存的上下文信息），就可以通过增加机器，使用负载均衡来scale out。

数据库读写分离

img

即使使用了缓存，但在缓存未命中、或者缓存服务时效的情况下，还是需要访问数据库，这个时候就需要数据库的读写分离：主库提供写操作，从库提供读服务。注意，在上图中增加了一个数据访问模块，可以对应用层透明数据库的主从分离信息。

使用反向代理和CDN 加速网站晌应

img

CDN和反向代理其实都是缓存，区别在于CDN 部署在网络提供商的机房；而反向代理则部署在网站的中心机房。使用CDN 和反向代理的目的都是尽旱返回数据给用户， 一方面加快用户访问速度，另一方面也减轻后端服务器的负载压力。

使用分布式文件系统和分布式数据库系统

img

单个物理机的磁盘是有限的，单个关系数据库的处理能力也是有上限的，所以需要分布式文件存储与分布式数据库。当然，也需要”统一数据访问模块“，使得应用层不用关心文件、数据的具体位置。值得一提的事，关系型数据库自身并没有很好的水平扩展方案，因此一般都需要一个数据库代理层，如cobar、mycat。

使用NoSQL 和搜索引擎

img

web2.0的很多应用并一定适合用关系数据库存储，更加灵活的NoSql能更加方便的解决一些问题，而且NoSQL天然就支持分布式。专门的搜索引擎在提供更优质服务的同时，也大大减轻了数据库的压力。

业务拆分

img

将一个网站拆分成许多不同的应用网站安全架构， 每个应用独立部署维护。应用之间可以通过一个超链接建立关系(在首页上的导航链接每个都指向不同的应用地址) ，也可以通过消息队列进行数据分发， 当然最多的还是通过访问同一个数据存储系统来构成一个关联的完整系统

分布式服务

img

既然每一个应用系统都需要执行许多相同的业务操作， 比如用户管理、商品管理等，那么可以将这些共用的业务提取出来，独立部署。

通过服务的分布式，各个应用能更好的独立发展，实现了从依赖模块到依赖服务的过渡。将通用的公共服务独立出来，也方便做服务管控，比如对各个应用的服务请求进行监控，在高峰时期限制、关闭某些应用的访问等。

大型网站架构模式与核心要素

这一部分是说大型网站需要解决的核心问题，以及解决这些问题的常规思路。

核心要素

五个要点：性能，可用性，伸缩性，扩展性，安全

作者指出，很多时候大家都混淆了伸缩性（Scalability）与扩展性（Extensibility）。我以前也是把Scalability称之为扩展性，不过想想，在我们讲代码质量的时候，扩展性也是指Extensibility，以后还是直接说这两个英文单词好了。

这几点后面会详细介绍。

网站架构模式

对模式的定义，书中描述得很好：

" 每一个模式描述了一个在我们周围不断重复发生的问题及该问题解决方案的核心。这样， 你就能一次又一次地使用该方案而不必做重复工作" 。模式的关键在于模式的可重复性， 问题与场景的可重复性带来解决方案的可重复使用。

用我自己的话来说，模式就是套路。这些模式，都是为了达成上面提到的核心要素。那么，有哪些模式呢

分层

分层是企业应用系统中最常见的一种架构模式，将系统在横向维度上切分成几个部分，每个部分负责一部分相对比较单一的职责， 然后通过上层对下层的依赖和调用组成一个完整的系统。

在大型网站架构中也采用分层结构，将网主占软件系统分为应用层、服务层、数据层。

分层的好处在于：解耦合，独立发展，伸缩性，可扩展性。上面网站的进化史也凸出了分层的重要性。

但是分层架构也有一些挑战， 就是必须合理规划层次边界和接口，在开发过程中，严格遵循分层架构的约束， 禁止跨层次的调用( 应用层直接调用数据层)及逆向调用(数据层调用服务层， 或者服务层调用应用层)。

分割

分层强调的是横向切分，而分割是纵向切分， 上面网站进化史部分的业务拆分就包含了分割。

分割的目标是高内聚、低耦合的模块单元

分布式

分层和分割的一个主要目的是分布式部署，但分布式也有自己的问题：网络通信带来的性能问题，可用性，一致性与分布式事务，系统维护管理复杂度。

集群

一个机器解决不了的问题，就用几个机器来解决，当服务无状态的时候，通过往集群增加机器就能解决大部分问题。对应网站进化史中“使用应用服务器集群改善网站的并发处理能力”

缓存

缓存就是将数据存放在距离计算最近的位置以加快处理速度，同时大大减轻了数据提供者的压力

大型网站架构设计在很多方面都使用了缓存设计：CDN、反向代理、本地缓存、分布式缓存

异步

异步是解耦合的一个重要手段，常见的生产者-消费者模型就是一个异步模式。

出了解耦合，异步还能提高系统可用性、加快响应速度、流量削峰

冗余

冗余是系统可用性的重要保障，也是数据可靠性的重要手段

自动化

凡人总是会出这样那样的错误，能自动话的就要自动化。自动化大大解放了程序员、运维人员的生产力！

发布过程自动化、自动化代码管理、自动化测试、自动化安全检测、自动化部署、自动化监控、自动化报警、自动化失效转移、自动化失效恢复、自动化降级。

性能

奥运精神：更快、更高、更强

img

技术人员对于性能的追求是无止境的。

性能，站在不同的角度，衡量指标是不一样的：

常见的衡量标准包括：响应时间、吞吐量、并发量。关于这些衡量标准，文中有一个很好的比喻：

系统吞吐量和系统并发数， 以及响应时间的关系可以形象地理解为高速公路的通行状况: 吞吐量是每天通过收费站的车辆数目(可以换算成收费站收取的高速费) ， 并发数是高速公路上的正在行驶的车辆数目，响应时间是车速。车辆很少时， 车速很快， 但是收到的高速费也相应较少; 随着高速公路上车辆数目的增多，车速略受影响，但是收到的高速费增加很快; 随着车辆的继续增加，车速变得越来越慢，高速公路越来越堵，收费不增反降; 如果车流量继续增加，超过某个极限后，任何偶然因素都会导致高速全部瘫痪， 车走不动，费当然也收不着，而高速公路成了停车场(资源耗尽)。

web前端性能优化

（编辑：南京站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!