网站架构

一、小型公司网络架构 狗子是某大学计算机专业本科应届毕业生，由于自己的技术不错，再加上互联网产业的巨大利润的驱使，狗子决定走上创业这条路，于是，狗子联合了同学二黑，鸡子，狗蛋等人花费了几个月的时间写出了一套网站，是关于足球资讯的pc端网站加上手机APP客户端。现在产品测试成功了，准备发布了，狗子想到了两个问题： 1.网站需要服务器 狗子之前所有的代码测试都是在本地服务器或者局域网上进行的，现在需要把产品发布到外网上，让所有的人都能访问，因此再用自己的电脑当服务器显然很不现实，于是，狗子去买了一台服务器，在上面装了jdk,tomcat，mysql等必备环境，把网站搭了起来，又经过了很多测试，运行毫无问题了，通过网站的ip可以访问并且实现功能了，而且app的后台也在服务器上测试成功了，目前公司的架构如图所示： 那么问题又来了： 2.网站需要域名 显然，如果让各地的用户需要记住你服务器的ip地址才能访问你的网站的话，那是会被用户拿刀追着砍的。因此，狗子需要一个便于记住的域名，以后在浏览器输入这个域名就能够访问这个网站，所以，狗子拿着申请下来的各种资质，找到了域名贩卖商，一般是腾讯阿里巴巴这种代理贩卖商，花了一笔钱，从它们的手上购买了域名，彻底实现了网站通过域名就能访问的功能。这里需要讲解一下通过域名访问的原理： 域名访问原理 通过ip访问相当于用户直接访问输入的ip所指向的服务器

从8月26到10月7日，一个多月的时间，把这本书看完，并摘录一些重要的内容。 基本上自己是先看一遍，然后将觉得应该多看几遍的地方写进博客。 很明显，自己需要掌握的很多，所以才有这么多篇。 收获颇多，将原文的内容理解，并敲一遍摘录，比光是看要吸收的多一点。后面需要不断地利用空闲时间翻阅。 书中不仅谈技术，还谈人生价值观。 认识到，架构师是什么样的人？主要的工作是什么？具体每项工作的关注点和解决思路？ 书中关于架构原理的是第一篇和第二篇。阅读之后，对高性能、高可用、伸缩性、可扩展性、安全会有个清晰的认知。 第三篇讲架构案例的，我没有做过多摘录，只是读了一遍，并在书中做了笔记。 最后是将架构师这个职业的，有关于职场、如何领导，做了一些阐述，让我对架构师这个岗位有更加感性的认识。 也让成为一个什么样的架构师更清晰。 来源： https://www.cnblogs.com/wozixiaoyao/p/11637750.html

##2.1 网站架构模式## 为了解决大型网站面临的高并发访问，海量数据处理，高可靠运行等一系列问题与挑战，大型互联网公司在实践中提出了许多解决方案，以实现网站高性能，高可用，易伸缩，可扩展，安全等各种技术架构目标。这些解决方案又被更多网站重复使用，从而逐渐形成大型网站架构模式。 ###2.1.1 分层### 分层是企业应用系统中最常见的一种架构模式，将系统在 横向维度 上切分成几个部分，每个部分负责一部分相对比较单一的职责，然后通过上层对下层的依赖和调用组成一个完整的系统。 分层结构在计算机世界中无处不在， 网络的7层通信协议 是一种分层结构；计算机硬件，操作系统，应用软件也可以看作是一种分层结构。在大型网站中也采用分层结构，将网站软件系统分为 应用层 ， 服务层 ， 数据层 ，如下： 应用层 ：负责具体业务和视图展示，如网站首页及搜索输入和结果展示； 服务层 ：为应用层提供服务支持，如用户管理服务，购物车服务等； 数据层 ：提供数据存储访问服务，如数据库，缓存，文件，搜索引擎等； 通过分层，可以更好地将一个庞大的软件系统切分成不同的部分，便于分工合作开发和维护；各层之间具有一定的独立性，只要维持调用接口不变，各层可以根据具体问题独立演化发展而不需要其他层必须做出相应调整。 但是分层架构也有一些挑战，就是 必须合理规划层次边界和接口 ，在开发过程中，严格遵循分层架构的约束

很多没有实际项目经验的小伙伴，对消息队列系统非常陌生，看着很多架构的介绍中，都提到消息队列。但是，不知道为什么要用消息队列？什么是消息队列？常见的消息队列产品有哪些？ 通过阅读本文，帮你解开以上的疑惑。 1.为什么要用消息队列？ 假设一个老大，接到一个任务要处理完。在处理这个任务时，把这个任务分解为几个小任务，只要分别完成了这几个小任务，整个任务也就完成了。 做到某个小任务时，发现这个小任务需要花很多时间完成，而且这个小任务迟点完成也不影响整个任务的完成进度。于是，老大把这个小任务交个一个小弟去做，自己去接着完成其他的任务。 在上面的例子中，老大就是后台系统，小弟就是消息队列系统，当后台系统发现完成某些小任务需要花很多时间，而且迟点完成也不影响整个任务的，就会把这些小任务交给消息队列系统。 在实际的app后端中，发送邮件，发送短信，推送等这些任务，都非常适合在消息队列系统中做的。大家想想，这些任务是不是都需要花比较多的时间，而且迟点完成也不影响的。把这些任务放在队列中，可加快请求的响应时间。 2.消息队列是怎么工作？ 消息队列系统，一般都包含3个角色：队列服务端，队列的生产者，队列的消费者。 消息队列系统类似于这个场景：有一条信息传送带不停地运转。在传送带的起点，工人a不断地把信息放在一个盒子，把盒子放到传送带上，盒子被传送带传送到终点。在终点上，工人b把盒子上的信息取出来

1.nginx开启目录浏览，提供下载功能 默认情况下，网站返回index指定的主页，但如果该网站不存在主页，则会将请求交给autoindex模块，如果开启autoindex模块，则提供一个下载页面，如果没有开启autoindex,则会报错403 [root@web01 centos]# cat /etc/nginx/conf.d/mirror.oldxu.com.conf server { listen 80; server_name mirror.oldxu.com; charset utf8; #字符集 location / { root /code; index index.html; autoindex on; #开启目录索引,提供下载 autoindex_exact_size off; #以人性化方式显示大小 autoindex_localtime on; #与本地时间保持一致 } } 2.nginx实现访问控制，基于来源ip控制，基于用户名密码控制 例一:允许特定的IP访问，其他全部拒绝 [root@web01 ~]# cat /etc/nginx/conf.d/mirror.oldxu.com.conf server { listen 80; server_name mirror.oldxu.com; root /code; charset utf8;

经典的Django项目源码目录结构 Django在一个项目的目录结构划分方面缺乏必要的规范。在Django的官方文档中并没有给出大型项目的代码建议目录结构，网上的文章也是根据项目的不同结构也有适当的变化。 样式一 ：强调模块化设计 参见参考文章二 ··管理项目的依赖文件requirements文件夹，列出项目中需要的依赖的文件，比如项目使用的所有python包。 ··分离应用文件和库文件（apps ,libs）新建apps和libs用来保存application和library ··创建完善的setting模块 优势：模块化设计适合规模较大的项目 缺点：这种布局结构没有说明static文件的放置路径。 $ tree . . ├── djangolicious │ ├── apps │ │ ├── blog │ │ │ ├── __init__.py │ │ │ ├── models.py │ │ │ ├── tests.py │ │ │ └── views.py │ │ ├── __init__.py │ │ ├── news │ │ │ ├── __init__.py │ │ │ ├── models.py │ │ │ ├── tests.py │ │ │ └── views.py │ │ └── reader │ │ ├── __init__.py │ │ ├── models

架构的本质 一个软件系统随着功能越来越多，调用量急剧增长，整个系统逐渐碎片化，越来越无序，最 终无法维护和扩展，所以系统在一段时间的野蛮生长后，也需要及时干预，避免越来越无序。 架构的本质就是对系统进行有序化重构，使系统不断进化 那架构是如何实现无序到有序的呢？ 基本的手段就是分和合，先把系统打散，然后重新组合。 分的过程是把系统拆分为各个子系统 / 模块 / 组件，拆的时候，首先要解决每个组件的定 位问题，然后才能划分彼此的边界，实现合理的拆分。合就是根据最终要求，把各个分离的 组件有机整合在一起，相对来说，第一步的拆分更难。 拆分的结果使开发人员能够做到业务聚焦、技能聚焦，实现开发敏捷，合的结果是系统变得 柔性，可以因需而变，实现业务敏捷 架构的分类 架构一般可分业务架构、应用架构、技术架构 1. 业务架构从概念层面帮助开发人员更好的理解系统，比如业务流程、业务模块、输入输出、 业务域 2. 应用架构从逻辑层面帮助开发落地系统，如数据交互关系、应用形式、交互方式，是的整 个系统逻辑上更容易理解，步入大家熟知的 SOA 就属于应用架构的范畴 3. 技术架构主要解决技术平台选型、如操作系统、中间件、设备、多机房、水平扩展、高可 用等问题 需要注意的是，系统或者架构首先都是为人服务的，系统的有序度高，用用逻辑合理，业务 概念清晰是第一位。现在大家讨论更多的是技术架构，如高并发设计

前言 题目有点大，所以不可能说得非常具体，笔者也不能驾驭全部。 前面介绍过 网站发展过程中架构的演化过程 ,本文主要针对网站架构各个方面的建设进行简单介绍。 架构模式 先来说说模式： 每一个模式描述了一个在我们周围不断重复发生的问题及该问题解决方案的核心。这样，你就能一次又一次地用该方案而不必做重复工作 。 先来说说常见的网站架构模式。这里没有涉及具体实现过程，只是简单介绍其思想和原理，方便日后有用到再深入了解。 分层 分层是企业应用系统中最常见的一种架构模式，将系统在 横向维度 上切分成几个部分，每个部分负责一部分相对比较单一的职责，然后 通过上层对下层的依赖和调用 组成一个完整的系统。 分层 功能 应用层 负责具体业务和视图展示，如网站首页以及搜索输入和结果展示 服务层 为应用层提供服务支持，如用户管理服务，购物车服务 数据层 提供数据存储访问服务，如数据库、缓存、文件、搜索引擎等 分层架构 还可以细分下去 ，比如说应用层可以细分为视图层和业务逻辑层。服务层可以细分为数据接口层和逻辑处理层。 分层结构对网站支持高并发向分布式发展至关重要，所以 在网站规模很小的时候就应该采用分层的架构，这样将来网站做大时才能有更好地应对 。 所以说我们在设计一个新项目的架构时，就需要考虑到分层。不能等到日后项目做大了，再重构就耗时耗力了。 分割 上面的分层是将软件在横向方面进行切分，而分割是在

大型站点高并发架构技术 高并发: 高并发主要是由于网站PV访问量大，单台服务器涌承载大量访问所带来的压力，所以会采用多台服务器进行分流，采用服务器集群技术，对于每个访问会被发送到哪台服务器，我们采取负载均衡策略，常见的技术有LVS，由于网站中有大量的静态页面，所以采用缓存服务器和反向代理技术，包括HAPROXY，REDIS,数据库可以采用数据库集群，进行读写分离，缓解数据库压力。 大型站点高并发架构就是利用负载均衡技术、反向代理技术、数据库集群、web服务器集群、Nosql技术等，以实现单台数据器不能达到的并发量，换句话说就是用一群屌丝代替一个高富帅。 1.大型站点高并发架构是为了解决百万千万级PV带来的性能瓶颈。 2.出现高并发架构的原因是大型网站发现在巨量pv下买更多更好的服务器已经无法简单的解决问题，只能从架构 上想办法来，充分发挥设备的效能。 3. 高可用解决方案（corosync,pacemaker,KeepAlived）负载均衡（LVS）缓存服务（Varnish）反向代理（haproxy）web服务器（Apache，Nginx，Tomcat）站点架构（Lamp，Lnmp） 什么是大型站点 大型站点高并发架构。首先，什么是大型站点，大型站点至少有两个特点（1）访问量大，淘宝的每日PV有几十亿（2）后台服务器多，淘宝后台服务器据说有十多万台。然后，大型网站的高并发架构

概述 本文是学习大型分布式网站架构的技术总结。对架构一个高性能、高可用、可伸缩及可扩展的分布式网站进行了概要性描述，并给出一个架构参考。文中一部分为读书笔记，一部分是个人经验总结，对大型分布式网站架构有较好的参考价值。 作者简介 烂皮猪，十余年工作经验，曾在Google等外企工作过几年，精通Java、分布式架构，微服务架构以及数据库，最近正在研究大数据以及区块链，希望能够突破到更高的境界 一、大型分布式网站架构技术 1、大型网站的特点 用户多，分布广泛 大流量，高并发 海量数据，服务高可用 安全环境恶劣，易受网络攻击 功能多，变更快，频繁发布 从小到大，渐进发展 以用户为中心 免费服务，付费体验 2、大型网站架构目标 高性能：提供快速的访问体验。 高可用：网站服务一直可以正常访问。 可伸缩：通过硬件增加/减少，提高/降低处理能力。 安全性：提供网站安全访问和数据加密、安全存储等策略。 扩展性：方便地通过新增/移除方式，增加/减少新的功能/模块。 敏捷性：随需应变，快速响应； 3、大型网站架构模式 分层：一般可分为应用层、服务层、数据层、管理层与分析层； 分割：一般按照业务/模块/功能特点进行划分，比如应用层分为首页、用户中心。 分布式：将应用分开部署（比如多台物理机），通过远程调用协同工作。 集群：一个应用/模块/功能部署多份（如：多台物理机），通过负载均衡共同提供对外访问。 缓存