运维必知6-架构图
架构一。
以机房服务器为例，而不是以云主机为例。在机房里面，我们只要多于一台服务器，我们就要自己带交换机过去，机房是不会给你提供交换机的。你的最前端是交换机，交换机一般是放在机柜的最上边。因为这样让线自然下垂，好走线，不要把交换机放在下边，不然线都堆在地上，就不好走线。如果服务器比较多的话，你的交换机可以串联起来。如果特别多的话，你可以买一个三层交换机，下面带几个二层交换机，这样可以划分vlan。我们在机房里面，你买了带宽之后，实际上她就给你一个**口，这个口接到你的交换机上面，然后你就可以在交换机上插服务器了。服务器一般来讲都是2-4个网卡，一般1u的两块,2u的四块网卡。对于集群架构来讲，后面还有交换机，前面的交换机称之为外网，后边的称之为内网。这两组交换机在物理上没有直接的连通，就是没有串联。当然它们也是可以串联的，但是不安全。有的小企业就一台交换机，也是一堆服务器，逻辑上每台服务器都设置了一个内网，一个外网，但连接在一个交换机上，只是配的网段不同。外网口都配外网网段，内网口都配内网网段。几台服务器内外网都配在一个交换机上面， 只能说服务器少的时候凑合，但实际上这是不规范的。她们之间的数据可能会有影响。
对于小企业来讲，负载均衡服务器主要就是haproxy和nginx。目前从企业看，用nginx的多一些。所以nginx的反向代理一定要熟悉。通过location ，upstream来实现，通过location基于url的控制 ，useragent,扩展名，目录等等，都要控制好。还有一些限速，限制并发连接等。从物理上讲，你的负载均衡器和其他的机器都是接在一个交换机上的。由于nginx的反向代理模式，他的web服务器不需要有外网ip，这个时候尽可能的web服务器不要有外网ip，这也可以作为nginx的一个优化点，尽可能不让你的web服务器不要有外网ip。 像监控服务器zabbix,nagios也是不需要外网ip的。所以整个架构中只有负载均衡服务器有外网ip，甚至如果这里流量不大的话可以配置vpn，有两台负载均衡器，可以选择备的做vpn等等。这样你的所有的服务器相当于跑到后台去了
客户端的域名请求会解析到负载均衡器的vip上，所以用户请求域名就会找到对应的负载均衡器。在负载均衡器里面就是虚拟主机，一个server标签。在server标签里面通过location，proxypass抛给upstream，upstream里面有server，通过内网交换机到达web服务器。如果我有bbs,blog多个，那就为每一个做解析，解析到一个vip，在nginx里配多个server主机。
然后web服务如果要访问数据，就通过内网交换机找到公共的mysql服务器。读写分离可以是依靠开发在web服务器写的程序实现，也可以用amoeba,atlas,mysqlproxy,但是这些不太稳定，大公司基本上靠开发来实现。读服务器有两台还可以做负载均衡，这个负载均衡就不要启lvs负载均衡服务器了，太浪费。所以一般来讲你可以在nginx负载均衡器上配一组lvs ，代理后面的两台读服务器。mysql的负载均衡一般不用nginx做，nginx主要是http的反向代理，而mysql是tcp的负载均衡，可以用haproxy和lvs。 （那么haproxy和nginx的区别是什么？nginx主要是web服务器，缓存服务器，http的反向代理，邮件的反向代理，haproxy支持tcp的负载均衡，支持http的负载均衡，它是一个专业的负载均衡软件，它自身不支持web服务器）。从并发来讲，他俩是差不多的。相对来讲haproxy更专业一些。lvs是四层的负载均衡，只能做tcp的。这种基于uri，扩展名，agent，目录啊，lvs是做不到的。但haproxy和nginx都能实现。
如果web服务器访问存储，那它通过内网交换机找nfs，如果存储第一个宕了，第二个还能接管，这是一个热备的形式。这个热备在这个架构中是手工切换。 也可以用定时脚本，比如在web服务器上ping(建文件)，如果Ping第一台不通了，就卸载掉第一台并挂载第二台。工作中还可以用keepalived，把它俩做成高可用。它俩之间肯定要用inotify或drbd同步了。如果用keepalived做了高可用了，那么web挂载要用vip，光挂载VIP还不行。一旦挂载上第一台机器后，切换到第二台后，虽然还是挂载的同一个vip，但是短时间内它挂不上第二台存储，可能要持续5分钟左右，web服务器才能挂到新的存储上。这有两种解决办法。一是把新的nfs做一次重启，二是可以在新的nfs上通过ssh连上web服务器，做一个自动的卸载和挂载。由nfs存储切换去触发连到web服务器重挂。三是在web服务器写脚本判断存储的切换来重新挂载。 假设有人问nfs性能不行，能撑住吗？有几种情况能说现阶段跑的挺好的，没问题。一是前边有缓存服务器替它减压，二是前边有cdn.也就是说你的图片，附件之类的都会在前边有缓存。
我的web服务器所有的会话信息，一般来讲我会放在session共享里边， 第一台服务器登录了，把会话放到memcahed里边。轮询到第二台服务器上，它还来找这个共享的位置。
如果数据库压力大了怎么办？数据库前边也可以用缓存memcache。所有的互联网公司最大的架构的瓶颈就是两个，一个是数据库，一个是存储。相对来讲数据库瓶颈更大，存储七次。
对于nfs的瓶颈还有一种方法，就是弃用nfs。将存储服务器数据在推送到web服务器本地，由一个上传服务器写到主存储上，再把主上的数据用inotify推送到web服务器本地。这样web服务器读就读本地，只有写在存储上写。这就是弃用nfs。但这种情况只适合数据量不太大的情况，几个t以内都可以。
解决存储的鸭梨，缓存，cdn。解决数据库的压力。一是读写分离，二是分库分表，分库分表怎么做呢？开发做，dba做。三是加缓存memcahe，四是流量再变大的时候，把一部分数据转到类似redis，但这不意味只用nosql了，只是把并发很大，适合nosql存储的数据放在nosql里边
企业有多少数据多少弱数据要调查的，给memcache2-4g内存，一般不要给太大。适合redis存储的一般是投票啊，统计啊，好友关注啊这类的业务都可以放在nosql里边。redis支持多种类型数据，如keyvalue,集合，hash等等
反向代理的原理：用户请求代理，由代理根据用户的意愿再向后去请求，它和lvs的转发是不一样的，转发是用户把业务抛给我了，我直接抛给别人。
MySQL keepalived实现双主，用户写入数据写在一个主，当主挂了，另一个接管，从库必须用vip来做主从。这样有个问题，当访问量大时会导致数据不同步，因为挂了的主是突然挂的，所以现在的主备可能不在一个位置点，这就需要人工做好监控，做好处理，但是你的主是实现了高可用的。写数据最好不要写双主。
第二套架构
第二套架构和第一套架构的区别就是用lvs来实现。lvs是支持四层的负载均衡，tcp的负载均衡，前面解析到vip。请求域名到达lvs，使用lvs首选dr模式。dr模式它是服务器返回的时候是直接给用户，所以这种场景下，web服务器最好有外网ip.这样他返还给用户的数据就不用自己搭网关了。 这种效率是最高的。假设web服务器没有外网网线，那就必须为web做一个网关，或者在lvs上做网关。或者找一台机子做网关，但是这样每个请求返回时都经过新建的网关，肯定效率低。所以lvs最好给web设置外网ip.假如是做数据库的负载均衡，可以不用外网ip，因为数据库的业务跟外网没关系。它的接入模式一样，前面是一组外网交换机，你的外网网线接到这上面，后面是一组或多组内网交换机
架构优缺点，一是可以支持大并发，但是中小企业并发并不大，所以它的优点体现不出来。二是它是基于四层的负载均衡，nginx和haproxy基于uri的转发做不到，三是它的配置更复杂，还要在web上绑定vip，抑制arp。四是能更改mac地址，但不能更改端口。五是必须在同一个局域网内，必须是lan模式，而且web服务有外网ip相对不安全
架构3
综合第一二套架构
用户请求lvs，lvs不直接把请求抛给web服务器，而是把请求抛给反向代理，再由反向代理去请求后边的web服务器。这个模式的优点是lvs可以支撑大并发，代理由于是七层的，他可以解决基于uri,动静分离等的问题
，可以横向扩展一百多台，第一套架构扩展不了，只能主备，对于一个业务来讲，也是一主一备。对于另外一个业务，这边是主，另一边是备。
比如说，请求www.sychzs.cn,到达lvs,再到代理，代理不需要高可用，所以不用ｖｉｐ，只用物理网卡的ｉｐ就可以了，它里面的ｕｐｓｔｒｅａｍ就是物理ｉｐ向后转。你如果业务多的话，比如你ｌｖｓ有多实例
。比如bbs是一组，blog是一组，那代理就得用vip了，但这个vip不是为了漂移用的，是为了拆分业务用的。lvs可以支持几十万并发，代理又可以做很多台。比如128台，一台支持5000并发，128台也可以做60、70万并发，所以它俩的瓶颈没问题。就像两根管子，一粗一细，那流水量肯定以细的为主了。所以前面为lvs，比如说30万并发，后面一台nginx代理并发很小，那可以多台，加起来也能达到30万。这样他们的瓶颈就抵消了。
一个公司的业务是非常复杂的，像淘宝，有几百种产品，要。放在服务器上跑，产品线特别复杂。它有些产品线就必须要七层转发。比如说，图片静态，已经独立出域名了，不需要做七层uri的功能了，这种业务只要把 VIP配到lvs下面就行了，作为一个实例存在。这个实例不再走七层了，它直接走图片服务器就行了。相当于它俩公用一个lvs，但是是不同的实例。 由于这个业务不需要七层代理，我非要挂到七层代理的下边，性能就降低了。多了一层负载均衡层，它的网络是有开销，所以它的性能是有降低的。也就是说中小企业，单台服务器比集群要快的。就是说你的请求很少的时候。单台最快的。做集群网络之间都是有开销的，当什么情况下单台没有集群好呢。当你的并发一台服务器撑不住的时候，单台就没有集群快了。每天就几百个pv，或者就几万个pv，一台服务器是最快的。所以有为什么做了集群反而慢了，就是因为流量小，网络有开销所以变慢了。当你单台服务器撑不住的时候，你再做你就会发现区别。
有些流量比较小，比如说一个域名就需要七层代理的功能，并且你的流量不是很大，就可以直接挂到ngnix反向代理上，它也是一个单独的实例，只需在期中选两台就可以了，至少两台并做keepalived。当它挂载lvs上的时候
架构4
DAL层的软件实现，一个是程序实现（php,java等，开发的事），二是软件实现（amoeba，mysql-proxy）。它能实现读写分离和负载均衡的功能，select语句查从库，写查主库。高可用主主reP同步,keepalived，二是mmm。三是ha+drbd+mysql，四是mha，五是mysql cluster。你既用了nosql数据库，有用了mc缓存，在这个基础上，并发还很大的情况下，就可以做后边的架构了。或者说，并发不大，要求不能宕机，那就要
架构5
前端加了web缓存（nginx，squid）。缓存不一定要挂在haproxy，如果你的缓存不需要七层缓存直接挂在lvs负载均衡组。这样效率更高一些。公司如果用域名把图片分开了，就是说开发把程序改了，能做图片分离。
公司一个域名，要想把业务分开。比如图片，web,上传三种web服务器，假设每种都有两台，程序不做改变，要实现其分离。实现的方法是前面用七层代理（nginx，haproxy）。三种web服务器要配置一样，包括目录结构。甚至三种服务器中间可以相互切换的。特点：1，目录一样，2，lnmp环境一样。
在这个前提下，由于图片是静态的，所以图片web服务器的php不用开启。 没有.php抛给自己的fastcgi，配置文件里也不设置抛给.php（用注释的方法，预防以后默认走的web服务器挂掉后可以切换过来） ，这样它就是静态的。怎么让用户请求找这两台机子呢，在代理上设置，只要扩展名符合.jpg png等 ，甚至.css，.js等抛给图片这个静态web服务器
默认情况下抛给web服务器，web给全功能，可以跑图片等静态的，可以跑上传，有完整的lnmp环境并全部开启 ，
假设uri有upload就抛给上传web服务器，这样就实现了动静及其它业务的拆分。如果没有独立出域名，就可以按照上面的做法，
发博文时，先找到web服务器 插入图片就找到带有upload的目录 ，所以上传图片就转向到了upload的web服务器并存储到存储服务器，当发布博文后浏览的时候他就会找图片服务器了。而博文就是有动态的web服务器处理的。这时，默认走的web服务器就可以不用挂载存储了，只有静态的图片以及上传服务器挂载存储。如果upload全挂，就把代理端upload以及upload web服务器去掉。再把默认走的web挂载上。假如图片的web全挂就在代理端去掉，并将默认的web挂载上存储。三种web的代码都是一样的只是功能开启的不同。并发大了，这样做的业务拆分在安全和性能上都得到了提高
做授权，web上用户和组root root 目录755 文件644 ，这样别人就动不了web服务器了。来一个木马放不了，放图片web服务器上解析不了，只能放在上传web服务器上，一点上传这样做的上传地址是隐藏的，用户是看不见的，跳转回来就是web服务器。
代码不要往存储上，因为存储压力比较大。做代码上线的时候，有一台代码上线服务器，由它往6台web进行分发，程序员自己写的代码不放在存储上，只是用户上传的东西放在存储上，数据库由两太默认走的web去读取，这叫分发服务器批量上线。比如ssh key saltstack ansible
如果存储还有压力，那么就把存储数据推送到处理访问存储的web服务器，让web服务器访问本地存储。这是弃用nfs方案。
用户的请求都是在代理上就被分开了，就像车间流水线一样，分拣装置。
公司有域名img，www，upload。 四种web服务器，每种两个，分别是图片，web，移动端，上传。php web服务器 jpg等 图片 上传 上传服务器
手机（根据user_agent） 移动端
插入到编辑器的时候，它的域名就要改了，为img的。只要把图片插入进去，它的域名就已经变了，程序实现。浏览的时候主要是请求php，
