服务器归分
域名
DNS
必须先先在DNS注册
www.95.com
对应的ip地址是
212.192.9.1
一个域名会对应一个ip地址
浏览器发请求
www.95.com/login.aspx
浏览器根据ip地址加上端口80
根据ip地址加端口通过Sockt发出当前服务器请求
通过Sockt来连接Web服务器
必须要知道 IP+端口Port
比如外网ip：212.192.9.1
Web 服务器
windows 2003 Server + iis6
windows Server2008 +iis7
windows Server2012 +iis8
Linux + Mono + Apache(Nqinx,Jenux)
如果一台服务器搞不定就在加一台
如 外网ip：212.192.9.2
负载均衡
比如 100个服务器请求 一人50个 才是负载均衡
如果服务器硬件好一点就应该多分担一点。
如果服务器多的话 使用 Sockt IP+端口Port 就失效了
有其他2种方法
1.高级一点的DNS就可以做负载均衡
要求两台服务器的网站代码必须一样。
但是它不会均衡10次请求 可能他把8次发给了 1 2次发给了2 这样就达不到自己的目的了
一般公司都是自己来做
212.192.9.1
2.代理服务器
最终你所有的请求都会发到代理服务器
Linux
+
Nginx(用于反向代理软件，实现软负载均衡)
请求发给了代理服务器 它就会原封不动的发给Web服务器
浏览器的一个请求 给 代理服务器 它只需转手给一下什么都不需要干
并且Nginx的处理性能是iis的28倍
如果像淘宝这种网站的话 一台就会直接挂了
需要一层一层的加服务器 当你每一层加到足够量的时候 就是我们所谓的 大型服务器集群
当一个网站足够大的时候就需要花很多钱去运营
当你代理服务器很多的时候就需要一个防火墙
当浏览器发出请求的时候 就有一个硬件防火墙 硬件负载均衡
为什么选择它 因为Linux免费的 Nginx开源的 只需要买一台服务器
当你要用硬件负载均衡F5的时候就需要花钱买
如果当你代理服务器很多的时候就需要买硬件负载均衡
最终先把浏览器请求 教给硬件负载均衡 在由它 随机交给软负载均衡 在由它教给不同的Web服务器
设计思想 一个如果不够用了就一直加
虽然硬件负载均衡很厉害 但是也有极限 如果到了极限也需要加
现在知道了代理服务器 就是使用 Linux+Nginx 来使用负载均衡的
如果有一个上传文件
在本地选择一个文件上传 是需要发给服务器上传 最终是上传到Web服务器的磁盘上
但现在做了负载均衡
现在的请求是上传 经过了代理服务器 选一台之后 到了1 就上传到了1的磁盘上
下次比如有一个查看的请求 但是由于有负载均衡 它的请求就会跑到了2上面去
这样能查询得到吗
这样就查不到了，所以两台服务器必须要有一个同步的操作
1.一般公司使用同步软件 FTP同步软件
在1 装一个FTP 在在2 装一个FTP 两边就会互相通讯 实现同步
2.文件服务器 最终图片不会上传到Web服务器而会上传到
文件服务器的硬盘上
虽然是Web服务器处理但是会存在 文件服务器上
但是文件服务器必须通过一个api来请求
现在浏览器请求的图片流是先到Web服务器
在由Web服务器本来是要存在硬盘上的但是现在硬盘要存到另外一台服务器
现在应该把文件的流发给另外一台服务器所以要开启api接收文件在保存到硬盘
所以很多公司都有一个上传下载组件
如果写多了公司就会让一个人开发一套一个通用的组件
然后打包成dll 如果要用你就需要用就直接引入dll new一个或者点一个方法就好
上传完了肯定要读一个图片 将来请求到了某Web服务器 肯定会去请求文件服务器
才能拿到图片 所以就要有下载的操作 去读它
文件服务器还可以存 js css 等静态资源
可能 同一个网站比较大的 肯定会有相同的js css 在Web服务器都有相同的
将来发布就不会很方便了 比如有一个js改了就要 更新很多Web服务器 如果
很多台的话 就会很麻烦。如果自己操作就可能会有问题
所以将来所有Web服务器上的js css等 都会给文件服务器
所以当你要改的话 只需要改一个地方就全部改了
所以相当与公用一个网站
文件服务器还可以管理 js css 等静态资源
缓存服务器
HttpRuntime.cache
缓存类 操作当前你的网站进程的内存的
把网站所有的数据存在进程里
就相当于 比如有2个Web服务器 他们每一个都有缓存 所以你要清除两次
所以就要使用第三方缓存软件
原来你是用的一个HttpRuntime.cache 现在就需要一个缓存软件
所以就需要一个缓存服务器
第三方的分布式缓存软件
1.memcached
2.Redis
这2个都有各自的特点
万一缓存不够用了 原来的HttpRuntime.cache是在进程内缓存的
就需要搬到服务器上去用
服务器有16 32 64个G
就意味可以用64个G去存
所以就需要用到memcached或Redis
一般是使用memcached
将来比如要访问数据库里的某一张表，第一次访问完了以后
一般按照前面的设计思路是不是先去请求一下缓存服务器里的东西
比如说Web服务器请求缓存服务器 传一个K过去 就告诉它有没有
如果没有 就肯定返回null 如果返回null怎么办
如果返回null就会发出数据库请求 数据库请求返回过来
就会把数据存到缓存里
意味着缓存服务器就有了
现在Web服务器按照我们的逻辑处理
既要处理aspx 又要处理ashx等动态页面
就意味着可能有很多业务写在同一个网站里
但是真正的大型 就比如说 首页 它是一个子系统
就相当于前面写的插件系统 就比如运动区 它又是一个子系统
就意味着 它会把2个系统发布到不同的服务器上去
就一个服务器运行一个子系统
就比如登录系统 一定是一个子系统
还有支付系统一定是一个子系统
就比如京东
正常是www.jd.com
一点登录就发现会跳转到 passport.jd.com
就意味着域名都不一样了 这是跳转到passport.jd.com二级域名
www.jd.com范域名
jd.com顶级域名
就意味着一个顶级域名下很多二级域名
一般是用www作为网站的主要访问
一些子系统就用二级域名去支撑
并且还有支付叫pay.jd.com 大概就是这个意思 你点支付他一定就跑到这里面去了
并且你会发现 前面是请求http 后面一定会请求https 加密 登录是不是很敏感的东西
因为有密码 而pay.jd.com就会设计到金钱的问题所以全部会使用https加密
而passport.jd.com，pay.jd.com属于我们的业务系统
所以我们一般有所谓的 业务服务器或者应用服务器
应用服务器比如说发布 登录系统 支付系统 等业务子系统
比如说现在上面只发布了登录系统就意味着这台服务器只要处理一个单一的逻辑就好就是登录
就比如将来一个系统在庞大 也就只有几个功能用的频繁 就比如 登录 购物车 之类的
所以将来可能最先奔溃的 就可能是登录
所以可能我现在登录顶不住了 我只要扩展应用服务器 在来一台应用服务器发配这个登录
然后做一个负载均衡 那其他的比如说支付系统这些就不需要动了
按照原来设计 你登录是在一个网站 支付也是在一个网站 那将来登录不够用了我要发布
我要扩展 那就要把所有的功能全部发布到一台服务器在去运行那这样的话本来支付系统
一台就可以顶住了那在发布一台就浪费了所以它会把它拆成一个个业务子系统
那一层不行了就给它加 这就是我们的分层思想以及业务子系统的话分
数据库服务器
MSSQL Server2000
MSSQL Server2005
MSSQL Server2008
MSSQL Server2008R2
MSSQL Server2012
MSSQL Server2014
MYSQL
Oracle
在我们的真实环境里 也是这样
浏览器是别人机子的 所以不相关
当浏览器发送请求 到互联网 在互联网有一个防火墙 进入
防火墙以后才进入硬件F5 在进入代理服务器 在进入真正处理
文件服务器一定是在Web服务器后面的 因为要先到达Web服务器
才会到达文件服务器 应用服务器就不一定在Web服务器后面，
它们有可能是并列的，但也有可能会在后面，这就要看你的设计
架构不同摆放的位置就不同而文件服务器也一定是在应用服务器
的后面然后缓存服务器一定是在应用服务器和Web服务器的后面
但是在不在文件服务器的后面
不一定它们可能是并列的
因为和文件服务器没关系缓存服务器只会被 Web服务器和应用服务器请求
最终才是我们的数据库 层级就是从左到右
将来就是 硬件F5 代理服务器 Web服务器 文件服务器和应用服务器可能并列
然后到缓存服务器 最后才是数据库