【聚禄鼎】一站式企业服务平台近期我所分管的网站之一收录有异常情况，利用周末空闲时间，讲一讲诊断的全过程。这个故障是由服务器架构引起的。核心问题主要表现在两个方面，服务器架构及网站程序架构造成；一是由于网站程序架构造成的，二是由于服务器软件本身引起的。本文只分享服务器架构造成收录不正常。在这里，我将重点讲解服务器架构导致的站点收录异常
首先，自我介绍一下。我现在主要负责一家中小型企业网站的维护与升级。我在成都的一家公司工作，在乙方的外包公司混了很久，大家都知道，seo外包公司接手的绝大多数都是小企业网站，这类网站所进行的关键词通常也只是改一个TDK来完成排序的任务。所以对于服务器架构方面并不熟悉
外加，目前，绝大多数中小站点结构单一，开源CMS+单一云服务器（虚拟主机）+CDN（这还是有点运维能力公司）。所以在实际应用中，我们经常会碰到服务器负载过大或者性能下降等问题，而造成服务器负载过大时又无法恢复，甚至影响系统稳定性。针对上述体会，致使我根本不知道服务器架构上也会有毛病。所以，笔者将根据自己多年从事网站维护管理的经验对服务器架构上遇到的一些常见问题进行分析总结并提出解决方案，希望能够帮助大家提高服务器架构质量
一、收录异常的发现
从（图1）可以和明显地看出，3月中，下旬收录偏于正常，问题发生在3.31日-4.25日的浮动上，即，该区间肯定是由于站点有问题造成的收录异常。所以我想知道原因所在，希望能找到解决这些故障的办法
本人开始按常规方法排查，具体而言，服务器日志中的某些参数并不排除被关注的可能性，以致导致问题的发现，主要表现在以下几个方面:
1.1、站长平台仿真爬虫抓取正常进行。如果网站被黑或者恶意攻击时，我们可以通过搜索页面来查看网页的相关内容和链接情况，但不能直接看到被黑或攻击过的站点信息
1.2、搜索引擎爬虫的抓取次数不断增加且趋于正常。现在的情况就是搜索速度加快，但是搜索结果不稳定，而且出现了大量伪伪网站。下面是异常情况，检查伪蜘蛛爬虫正在捕捉资料，现实中的百度爬虫也的确是越来越多了。这是因为网站更新速度快，搜索结果比较集中
1.3、核心关键词名次上浮，但是偏向和上升趋势都是有的，当前的核心大词排名前五，属于正常情况。此现象主要是因为核心大词频增加导致，建议加大搜索力度并及时更新页面信息，避免频繁切换页面
1.4、服务器日志分析等，爬虫所对应request_uri（相对地址）值暂时处于正常状态，详见下表。如果我们发现了一个新的网站，我们首先应该关注它的域名是否为合法站点
1.5、服务器日志是阿里云的日志，http请求，7.18日、7.19日、7.20日以及7.26日出现小面积服务器500访问错误；如果不是很严重的话，可以通过修改系统来解决。但是最多也只会在限定时间内出现异常收录，不至于被大面积的没有收录。如果服务器日志出现异常，则说明该系统存在缺陷或漏洞，需及时修复并恢复
在分析服务器访问日志时，通常要关注项目有:爬虫的抓取时间值，爬虫网页URL值的确定、爬虫抓取网页的次序，时爬虫的抓取次数，另一种说法是蜘蛛IP值的权重有高有低（我没有把握，所以没有借鉴）
页URL值:通常服务器日志为相对地址，我在诊断中出了一个问题，就是忽视了host的数值，真实抓取的URL应是，host加上request_uri值的组合。如果你想了解网站是否正常运行的话，可以通过对该站点进行扫描和解析来获得
网页抓取顺序:可以测试网站架构是否爬行，大概就能了解爬虫爬网站页面的顺序了，可协助利用爬虫软件或开发经典爬虫软件（PY，PHP等）爬行情况，以供参考
时爬虫的抓取次数:考察网站页面总量与时间段抓取量比例之间关系，评判网站是否受欢迎。如果没有统计的话，则可以根据这个比例来推测用户在某一段时间是否对该网页感兴趣
讲到这里，交待了该站服务器架构:
使用负载均衡，文档服务器+数据服务器+前端服务器，数据服务器的所有数据通过API接口进行连接、GET方式前端和app使用，网站URL就是一个相对地址。客户端与后台通过网络进行通信。服务器间天然地使用了同样的内网通讯。我们需要注意的就是在进行分析时，如果你发现有错误的话，要马上更正
总之，也许我们也看到了一些被忽视的参数，就是1.4所述日志的host值，由于是相对地址，host加上request_uri，就是一个完整的抓取地址。为什么不直接把这两个参数放在前面呢？一直忽略的Host值，原来是API的二级域名（图2）
说到这里，人们也许已基本能肯定了解其中的缘由。那么为什么要这样做呢？
是百度完全不抓取真实页面URL，其实抓到API域名加request_uri，
即假设数据库服务器API向前端渲染的数据路径为api.name.c_m，走内网IP，
抓取的页面URL为:https://api.name.c_m/post/1.html
真实应该是外网IP的URL:https://www.name.c_m/post/1.html
既然核心问题已把握30%，接下来自然要用数据来论证，主要是从以下几点出发的。第一是数据来源和访问方式，第二是数据内容与格式，第三是采集设备及时间间隔
1、翻开发日志记录
2、4月前后的服务器日志整理对比
从1中发觉，4.13号载平衡数据服务器api撤销代理，这导致的结果就是前端直接从host主机上抓取值api域名下面的数据，并将其渲染到前端，由于直接利用了内网IP没有通过代理，与此同时，api的二级域名是host主机的值。这个结果导致整个系统崩溃，所以必须对客户端进行修改
从2中发现，4月左右日志host主机值发生变化，从www.name.c_m到api.name.c_m。这意味着在整个网站运行过程中内网端和外网端均需要进行代理服务
最后，问题出现在host主机为api的网站上，不使用代理，即只需将api站点由代理转换为www二级站点进行渲染。如不用代理，百度GET回传网页为内网IP，抓取到的也就是https://api.name.c_m/post/1.html这个URL。那么，这样做是不是可以解决这个问题呢？
解决方案:
1、负载均衡数据服务器api接口采用代理
方式
2、Head区增加标签
3、前端渲染HTML使用绝对路径
4、开发一个API接口来推送数据
这篇文章就结束了。全系统测试通过后将进行部署和上线试运行，并对整个项目中出现的问题及时总结与解决。考虑到我只是一个SEO，运维能力受限，单机服务器组态下一站即可，负载均衡只稍微听了一下，如果在运维中有不对的地方，敬请谅解。在此我将对以上几个问题做一个简单介绍并给出解决方案
出处:卢松松博主:成都传奇
