网站架构

前言 网上有很多文章类似于我今天要分享的课程，有架构师写的，有运维写的，还有开发些的，偏重点都不同，今天我以咱们运维角度全面讲解。 一个成熟的网站架构并不是一开始设计就具备高可用、高伸缩、高性能等特性的，它是随着用户量和业务线不断增加，基础架构才逐渐健壮的。在发展初期，一般都是从0到1，不会一上来就整一些大而全的架构，也很少人这么任性。 说明 适用业务： 电商/门户/招聘网站 开发语言： PHP和JAVA Web服务： Nginx/Tomcat8 数据库： MySQL 操作系统： CentOS 物理服务器： Dell R730/R430 一、单台服务器部署 项目开发完成上线，用户访问量寥寥无几。 二、WEB与数据库独立部署 有一定用户访问量，单台服务器性能有些吃力，想提高并发能力，增加一台服务器，将HTTP请求与SQL操作负载分散不同服务器。 三、动静分离-初期 什么是动静分离？静态页面与动态页面分离部署。 四、数据库主从与查询缓存 RedisCache 使用Redis缓存数据库查询结果，将热数据放到内存中，提高查询速度，减少数据库请求。 MySQL主从 基于binlog异步复制。 HA MySQL：Keepalived 怎么保证Redis缓存时效性？ a) 增加中间件，在主从同步延迟时间内，中间件将SQL读操作还路由到主。 b) 主从同步延迟时间后，再异步发起一次淘汰Cache。

1、HTML静态化 其实大家都知道，效率最高、消耗最小的就是纯静态化的html页面，所以我们尽可能使我们的网站上的页面采 用静态页面来实现，这个最简单的方法其实也是最有效的方法。但是对于大量内容并且频繁更新的网站，我们无法全部手动去挨个实现，于是出现了我们常见的信息 发布系统CMS，像我们常访问的各个门户站点的新闻频道，甚至他们的其他频道，都是通过信息发布系统来管理和实现的，信息发布系统可以实现最简单的信息录 入自动生成静态页面，还能具备频道管理、权限管理、自动抓取等功能，对于一个大型网站来说，拥有一套高效、可管理的CMS是必不可少的。 除了门户和信息发布类型的网站，对于交互性要求很高的社区类型网站来说，尽可能的静态化也是提高性能的必要手段，将社区内的帖子、文章进行实时的静态化，有更新的时候再重新静态化也是大量使用的策略，像Mop的大杂烩就是使用了这样的策略，网易社区等也是如此。 同 时，html静态化也是某些缓存策略使用的手段，对于系统中频繁使用 数据库 查询但是内容更新很小的应用，可以考虑使用html静态化来实现，比如论坛中论 坛的公用设置信息，这些信息目前的主流论坛都可以进行后台管理并且存储再数据库中，这些信息其实大量被前台程序调用，但是更新频率很小，可以考虑将这部分 内容进行后台更新的时候进行静态化，这样避免了大量的数据库访问请求。 2、图片服务器分离 大家知道

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 目前网站架构一般分成网页缓存层、负载均衡层、 WEB层和数据库层，我其实一般还会多加一层，即文件服务器层，这样我们在后面的讨论过程中，我们可以依次用这五层对网站架构来进行讨论。 网页缓存层 首先说下这个网页缓存层，比如CDN租赁（效果比公司自己部署Squid/Varnish要好，他们专业，价格低廉，比如快网/CC等（价格80元/M/月不到）而且覆盖的城市更多），自己架设squid/Varnish是次选。另外，很多朋友喜欢尝试自建CDN，这个是一个比较吃力不讨好的活儿，未必能达到预期目标，这块系统架构师在架设网站初期就有规划好，不要等到网站流量及压力巨大时才去规划。事实上，这一层有很多优 秀的开源软件都能胜利，比如传统的Squid Cache，另外，后起之秀Nginx和Varnish因为性能优异，越来越多的朋友尝试在自己的网站使用他们作为自己的网页缓存，事实上，Nginx已经具备Squid所拥有的Web缓存加速功能，此外，Nginx对多核CPU的利用，胜过Squid不少，现在越来越来的架构师都喜欢将Nginx同时作为“负载均衡服务器”与“Web缓存服务器”来使用，大家可以根据自己网站的情况，来决定究竟使用哪种软件来作为自己网站的网页缓存。 负载均衡层 首先说下负载均衡层，我们熟悉的硬件/软件技术有F5，LVS

LAMP网站架构方案解剖 2011-03-18 10:46 月光 网络转载 字号： T | T 网站架构是比较考研技术的一件事，所以要对一种好用的工具，那么网站架构就会事半功倍，LAMP具有通用、跨平台、高性能、低价格的优势，因此LAMP无论是性能、质量还是价格都是企业搭建网站的首选平台。 AD： 2014WOT全球软件技术峰会北京站 课程视频发布 LAMP 用 LAMP 进行 网站架构 是非常容易的。 对于大流量、大并发量的网站系统架构来说，除了硬件上使用高性能的服务器、负载均衡、CDN等之外，在软件架构上需要重点关注下面几个环节：使用高性能的操作系统(OS)、高性能的网页服务器(Web Server)、高性能的数据库(Databse)、高效率的编程语言等。下面我将从这几点对其一一讨论。 一、操作系统 Linux操作系统有很多个不同的发行版，如Red Hat Enterprise Linux、SUSE Linux Enterprice、Debian、Ubuntu、CentOS等，每一个发行版都有自己的特色，比如RHEL的稳定，Ubuntu的易用，基于稳定性和性能的考虑，操作系统选择CentOS(Community ENTerprise Operating System)是一个理想的方案。 CentOS(Community ENTerprise Operating System

负载均衡 （Load Balancing） 负载均衡建立在现有网络结构之上，它提供了一种廉价有效透明的方法扩展网络设备和服务器的带宽、增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性。 大型网站负载均衡的利器 全局负载均衡系统（GSLB） 内容缓存系统（CDN） 服务器负载均衡系统（SLB） DNS域名解析的基本过程 最初的负载均衡解决方案（DNS轮询） 优点 基本上无成本，因为往往域名注册商的这种解析都是免费的； 部署方便，除了网络拓扑的简单扩增，新增的Web服务器只要增加一个公网IP即可 缺点 健康检查，如果某台服务器宕机，DNS服务器是无法知晓的，仍旧会将访问分配到此服务器。修改DNS记录全部生效起码要3-4小时，甚至更久； 分配不均，如果几台Web服务器之间的配置不同，能够承受的压力也就不同，但是DNS解析分配的访问却是均匀分配的。用户群的分配不均衡导致DNS解析的不均衡。 会话保持，如果是需要身份验证的网站，在不修改软件构架的情况下，这点是比较致命的，因为DNS解析无法将验证用户的访问持久分配到同一服务器。虽然有一定的本地DNS缓存，但是很难保证在用户访问期间，本地DNS不过期，而重新查询服务器并指向新的服务器，那么原服务器保存的用户信息是无法被带到新服务器的，而且可能要求被重新认证身份，来回切换时间长了各台服务器都保存有用户不同的信息，对服务器资源也是一种浪费

消息队列需要考虑点 消息产生失败处理 1.根据消息产品是否有重试次数，达到重试次数未成功，则会通知生产失败。 2.对于不能容忍生产失败的场景来说，要做好后期的数据处理，譬如，数据持久化，添加日志，报警等。 消息重复接收处理 1.对于消息重复问题，特别是分布式消息队列，需要在业务层面做防重处理。 来源： CSDN 作者： 奔跑的蜗牛kei 链接： https://blog.csdn.net/weixin_46021767/article/details/103536955

一、LNMP架构及应用部署 众所周知，LAMP平台时目前应用最为广泛的网站服务器架构，其中的“A”对应着web服务软件的Apache HTTP Server ，随着Nginx在工作环境中的使用越来越多，LNMP（或LEMP）架构也受到越来越多的Linux运维工程师的青睐。 就像构建LAMP平台一样，构建LNMP平台也需要Linux服务器、MySQL数据库、PHP解析环境，区别主义在于Nginx与PHP的协作配置上。 准备工作 Centos 7操作系统一台； Windows 客户端一台； 案例所需镜像及软件包请访问： https://pan.baidu.com/s/10wFG1YQaY2FTJKgMp1x0kw 提取码：rl3i 二、构建LNMP网站平台 部署前准备 ①挂载Linux光盘，拷贝nginx依赖程序到/usr/src/目录 [root@centos02 ~]# mount /dev/cdrom /mnt/ mount: /dev/sr0 写保护，将以只读方式挂载 [root@centos02 ~]# cp /mnt/nginx-1.6.0.tar.gz /usr/src/ ②切换LAMP光盘，将mnt目录下所有数据拷贝到/usr/src/目录 [root@centos02 ~]# umount /mnt/ [root@centos02 ~]# mount /dev

今天讲点关于我们公司技术架构演化历程，本人在公司还没正式成立的时候就来了，在此期间有幸经历并参与了公司技术架构的多次升级的改造工作，也很高兴能见证一个公司的发展历程，从中也学到了很多东西。好了废话不说了，开喷： 一、初始阶段 ：网站发展初期，我们的架构是什么样子的呢？下面用一张图还说明： 看着图来介绍下，我们初始阶段的网站技术架构，当然看着也不错了，开始阶段就用了这么多技术思想，感觉挺不错吧，用了反向代理、用了集群、用了分布式缓存、用了独立的文件服务器和独立的数据服务器，架构看起来貌似不错。但是随着用户访问量的增加，逐渐发现流量高峰期的时候我们的响应时间总是很慢，甚至有几次直接挂了，主要是访问数据库过于频繁，因为读写操作都是操作一个库，而我们只有一个库，之后呢，我们做了数据库读写分离，写请求走主库，读请求走读库，解决了数据库连接数不足的问题。 二、发展中期：网站发展中期，随着用户访问量的不断递增，我的技术架构发展成什么样子了呢？入下图所示： 随着流量的增大，发现读写分离已经不能满足我们的要求，写库，逐渐出现瓶颈，读库也因为越来越多的人操作，从而也开始变慢；然后我们开始升级我们的架构，先是按业务功能拆分代码，独立部署，然后抽出公共服务，做分布式部署，即所谓的soa服务化；因为服务化之后呢，不同业务使用不同的数据库，即所谓的垂直分库，后来呢 针对部分业务，我们又做了分库、分表技术

豆瓣网CTO洪强宁讲述网站架构变迁 罗马不是一天建成的，豆瓣的技术架构也是随着用户规模的增长一直在持续变化中。洪强宁，2002年毕业于清华大学，现任北京豆瓣互动科技有限公司首席架构师。洪强宁和他带领的技术团队致力于用技术改善人们的文化和生活品质，在网站架构、性能、可伸缩性上进行深入研究。豆瓣网曾获软件中国2006年度最佳技术应用网站。 校内网CTO黄晶讲述网站架构变迁 每个网站的发展都会按照一个大致相同的路线去完成，当然这里说的是每个相对成功的网站。 第一阶段： 这一阶段没有太大的访问量，甚至只有一台服务器就搞定了所有的访问。 DB 和前端的代码全都在一起，压力不高。忆者注：我觉得在 alexa 没进五万的时候，只要不是特殊的应用，基本都在此列吧。 第二阶段： 网站初具规模，DB压力大增，单独的一台DB已经满足不了现在的访问量，开始考虑读写分离的 Master-slave 库，使用三个及以上的服务器。忆者注：这时网站的alexa基本上会在1-3万的位置，每天的ip在5-10w的样子，当然，DB我们都认为是MySql。 第三阶段： 访问量继续增加，增加到了DB的压力在Master的机器上非常的明显了，Master开始出现吃不消的情况，出现写耗尽。主从也已经不能满足要求，需要进一步解决负载问题，此时要引入Mysql Proxy 程序，进行中间层代理，实现负载均衡，易于扩展。忆者注

#0 系列目录# 大型分布式网站架构 大型分布式网站架构技术总结 本文是学习大型分布式网站架构的技术总结。对架构一个高性能，高可用，可伸缩，可扩展的分布式网站进行了概要性描述，并给出一个架构参考。一部分为读书笔记，一部分是个人经验总结。对大型分布式网站架构有很好的参考价值。 #1 大型网站的特点# 用户多，分布广泛 大流量，高并发 海量数据，服务高可用 安全环境恶劣，易受网络攻击 功能多，变更快，频繁发布 从小到大，渐进发展 以用户为中心 免费服务，付费体验 #2 大型网站架构目标# 高性能：提供快速的访问体验。 高可用：网站服务一直可以正常访问。 可伸缩：通过硬件增加/减少，提高/降低处理能力。 安全性：提供网站安全访问和数据加密，安全存储等策略。 扩展性：方便的通过新增/移除方式，增加/减少新的功能/模块。 敏捷性：随需应变，快速响应； #3 大型网站架构模式# 分层：一般可分为，应用层，服务层，数据层，管理层，分析层； 分割：一般按照业务/模块/功能特点进行划分，比如应用层分为首页，用户中心。 分布式：将应用分开部署（比如多台物理机），通过远程调用协同工作。 集群：一个应用/模块/功能部署多份（如：多台物理机），通过负载均衡共同提供对外访问。 缓存：将数据放在距离应用或用户最近的位置，加快访问速度。 异步：将同步的操作异步化。客户端发出请求，不等待服务端响应