模板网站劣势,zhihu网站建设,网络工程属于计算机类吗,电子商务公司管理制度前面已经描述了大型网站系统的特点#xff0c;而对一个大型网站系统#xff0c;其架构也是重要的一个环节。 大型网站技术主要的挑战来自于庞大的用户、高并发以及海量的数据这三个方面。大型网站的形成就像一颗大树的成长#xff0c;历尽长时间的磨练#xff0c;最后枝繁叶… 前面已经描述了大型网站系统的特点而对一个大型网站系统其架构也是重要的一个环节。 大型网站技术主要的挑战来自于庞大的用户、高并发以及海量的数据这三个方面。大型网站的形成就像一颗大树的成长历尽长时间的磨练最后枝繁叶茂服务他人。 初始网站架构结构 起初的网站鉴于用户量、访问量较少只需要一台服务器足以应用程序、数据库、文件等其所有资源放在一太服务器上就已经足够满足此时的需求这时候网站的架构就几个简单组成部分如下图 应用和数据服务分离 随着网站业务需求的发展越来越多的用户进行访问此时一台服务器渐渐不能满足需求数据的存储空间出现屏障。于是应用程序、数据库、文件三者面临分离各自为首分配一台服务器这三台服务器对硬件的要求各取所需应用服务器处理大量的业务逻辑需求更快更大的CPU数据库服务器对数据库的处理需要快速搜索以及缓存需求对内存更大对硬盘读写能力更迅速文件服务器需求放入大量的用户资源对硬盘空间要求更大。此时的网站的架构组成部分展示如下图 使用缓存 网站的架构进一步改进后可以满足了业务的发展但是随着网站知名度提升用户量的进一步增加访问数据相比之前愈加频繁数据库压力急剧上升导致网站访问出现延迟用户的性能体验出现下滑面临此时网站出现的性能问题网站架构设计需要再一次的进化鉴于网站访问也遵循二八定律例如新浪微博只有经常登录的用户才会发微博看微博而这些用户对于总用户数只是冰山一角。既然出现这一现象那么缓存这部分的数据是不是可以解决这现象呢网站缓存可以分为本地缓存和分布式缓存这两种二者的区别是本地缓存速度快但是受服务器内存限制缓存的数量有限而分布式缓存采用的是集群处理理论上是可以避免内存瓶颈。此时网站的架构组成部分如下图 应用服务器集群改善网站并发能力 使用缓存后数据库的压力得到缓解但是在面临网站高峰期时应用服务器处理单一的请求连接出现瓶颈万事都有解决的办法只是看你愿不愿去想愿不愿去尝试做采用集群集群多台应用程序服务器分布原有的应用程序服务器从而实现了系统的可伸缩性网站架构此时演化成这样如下图 数据库读写分离 使用缓存虽然使用户请求数据操作大部分不直接通过数据库但是仍有一部分数据缓存过期、缓存数据没有命中读写操作需要访问数据库面对这部分数据可能出现数据访问负载压力把数据库读写操作分离性能效果理当会如何呢效果无言而喻。 CDN和反向代理加速网站响应 网络覆盖范围地区广泛造就了网络环境复杂从而用户访问网站性能体现也各有差异鉴于这问题网站架构使用CDN和反向代理以技术加速网站响应二者原理都是缓存CDN可以从距离用户最近网络提供点获取数据反向代理则是首先从反向代理服务器中获取数据。 分布式文件、数据库系统 任何单一的服务器最后都是满足不了业务需求发展。虽然前面数据库读写分离能够改善数据库负载压力但是随着业务不断壮大最终还是难以维持此时使用分布式数据库该技术不到不得以建议不使用而对于这个技术解决方案更常用的使用业务拆分将不同的业务数据库部署在不同的物理服务器上。 NoSQL和搜索引擎 该技术对于可伸缩的分布式提供更好的支持减轻应用程序管理诸多数据源的麻烦。 业务拆分 大型网站日益发展壮大业务需求越来越复杂使用分而治之手段分离整个网站的业务变成不同的产品线。具体到技术上将一个网站拆分成许多不同的应用每个应用独立部署而应用与应用之间通过超链接关联不过最多的还是通过访问同一个数据存储来构成一个关联的完整系统。 分布式服务 一个应用系统需要执行相同业务操作那么可以将共同的业务提取出来独立部署由这些可复用的业务连接数据库提供共用业务服务而应用系统只需要管理用户界面通过分布式调用共用业务服务完成具体业务操作。 大型网站结构演化到这里基本上大多数的技术问题都得以解决了但是事物发展到一定的阶段就会摆脱初衷向更强的方向发展。目前许多的大型网站都建立自己的云平台将计算作为一种资源进行出售。 大型网站架构演化历经了长时间磨练才发展如此在过程中也是出现一些易步入的误区 一味的追随大公司解决方案大公司的经验和成功固然重要但是不能盲目的追从要与实际的具体业务需求有所改动 为了技术而技术网站技术是为业务而存在的但是一味的追求新技术可能会导致结构技术之路越走越难 企图用技术解决所有问题技术虽是解决业务问题的但也不是万能钥匙有些业务的问题也是可以通过业务手段解决。 参考资料《大型网站技术架构核心原理与案例分析》转载于:https://www.cnblogs.com/JustOnly/p/4899615.html
