为了更好地帮助大家理解的维度，本文先从一个通用的网站架构开始谈起，然后讲一讲 58 集团是怎么在横向和纵向两个维度覆盖各种类型的。
为了更好地帮助大家理解的维度，本文先从一个通用的网站架构开始谈起，然后讲一讲 58 集团是怎么在横向和纵向两个维度覆盖各种类型的。
对于大多数的技术人员来说，最熟悉的就是业务集群，我们在业务集群上实现业务逻辑，由 Nginx 将流量分发到这些业务集群上。
如上图所示，是相关的架构，这部分大家都比较熟悉，我们就不展开了。下面详细说一下大型网站在机房外部和机房内部的流量接入端的架构。
拿一个典型页面举例，通过浏览器中的开发者工具，我们可以看到加载和渲染这个页面需要加载很多页面资源。
不但加载了很多文档类型的资源，例如 HTML；也加载了很多静态资源，例如 CSS、JS 和图片文件。
我们将前一种划分为动态内容，将后一种划分为静态资源。如果我们在全国只有一个机房，那么全国各地的用户都需要跨越多个区域、多个运营商的网络才能访问到网站，如下图所示，这样访问速度一定不是很快。
怎么解决这个问题呢？最简单的方法就是让用户就近访问页面资源，在全国各区域、各运营商用户数量比较多的网络内建立节点，让用户就近访问。
对于动态请求的优化思也是类似，前面提到的是只有一个机房提供动态请求响应的情况，南方用户的动态请求响应速度是较慢的。
如下图所示，如果在华东、华南等区域部署机房，可以更好地对华东、华南的用户进行覆盖，提升动态内容的访问速度。
如下图所示，用户在向域名解析服务器发起域名解析请求的时候，DNS 服务器返回了离该用户最近的 CDN 节点的 IP，从而实现了用户的就近访问。
如上图，在经过域名解析阶段后，动态的请求会直接访问机房（也可以做动态内容的加速），静态资源在无缓存时也会回源（去机房获取资源文件），这两种情况都会访问机房的 VIP。
分别经过四层负载均衡和七层负载均衡集群后，流量被分发到业务集群。业务集群之间也会存在互相调用的情况。
对每一个关键集群来说都存在主备，主集群出现问题则切换到备集群；也可以主备集群同时提供服务，每个集群都预留承担全部流量的资源。
每个集群内部都包含多台服务器，少量服务器出现异常不影响集群提供服务。机房网络出口提供备份链，主链出现问题可以自动切换到备链。
当遇到极端情况，两条链都中断的情况，可以切换域名的解析结果和 CDN 的回源 IP 到备份机房的 VIP，然后通过机房之间的专线将流量导入。如果有多个机房，那么直接将流量切到其他正常的机房即可。
系统的底层模块基于 Open-Falcon，上层做了很多深度的二次开发，整体系统架构图维基解密黄菊如下：
横向实现了从外到内各层级的，包括用户端、机房网络出口端、流量接入端、业务端等，如下图所示：
在管理层面通过配置不同的模板，给不同集群、不同角色的用户发送不同的告警，例如：对于数据库主库宕机发送语音告警，其它架构层面支持自动剔除故障机器的宕机发送短信告警即可。
服务器硬件，通过在 Agent 上部署插件，可以很好地支持多种多样的硬件，也非常便于对硬件进行适配。对硬件的覆盖程度视业务需求而定。
对于一个中大型互联网公司，业务比较复杂，服务器根据用途被划分为不同的集群，由不同的运维和开发人员负责管理。
那么添加这些对于技术人员来说是较大的工作量，且只依靠人去添加很难的覆盖率。我们的思是尽可能自动化地添加基础的。
我们对各个业务在系统层面的需求进行归纳，确定了一些核心的指标、异常判断条件、告警方式等，生成一个默认的模板。
我们的 CMDB 系统包含最基础的服务器资产数据，包括集群的名称、集群中的服务器列表、集群的运维和研发负责人等信息。
这样就可以从 CMDB 中同步这些信息，在系统中自动添加每个集群的基础系统，也就是自动添加集群、自动创建模板（继承了基础模板），告警按需求发给运维和研发负责人。
通过这种方式在短时间内做到了所有集群基础的 100% 覆盖，起码能做到服务器宕机和系统资源使用率问题导致的异常都能够有效的发出告警，迅速解决了初始建设阶段的核心痛点。
对于某些集群，由于业务的特殊性，基础的模板不能满足他的需求，可以继承父模板的指标，然后进行告警条件、告警方式的修改。
应用用来部署的应用程序是否正常，包括：端口，进程，功能（页面或接口），QPS，连接数等指标。
一般来说，让运维和开发人员去创建模板、关联到集群、配置告警接收人等工作有一定的工作量，而且也有一定的难度。一些情况下，由于配置的问题会导致和告警不能生效。
用户可以通过帮助文档页面下载多种语言（Java、PHP、Python，Shell等）的插件模板，然后进行简单修改，采集到被指标后可以方便的接入系统。
由于业务和具体的业务相关，不能采用通用的方式进行，所以采用自定义插件的方式。
所有可以采集到的指标都可以添加和告警；将数据以 Json 格式发给 Agent 即完成数据。
采集的数据包括用户端可用性、首屏时间、全部资源下载时间、全部资源字节数、基础 HTML 页面下载时间等数据，如下图所示：
另外，还可以对 DNS 劫持、链劫持、访问出错、访问速度较慢的问题进行告警，以 DNS 劫持数据的展示举例：
既可以在网络设备上采集流量，也可以在四层负载均衡上采集流量。并可分别对网络的连通性、进出流量、进出包数等关键指标进行。
这些都是对机房出口的 VIP 发起请求，流量经过负载均衡服务分发到后端业务集群，业务集群内有少量服务器出现异常，负载均衡服务会自动到另一台服务器重试，异常不会给外部用户。
页面：对页面的基础页面（即 HTML）进行探测，连续一段时间发现状态码与预期不一致、响应时间过长、找不到匹配的关键词、页面长度较短等情况，会发出告警。
接口：对接口进行探测，连续一段时间发现状态码与预期不一致、响应时间过长，接口返回的消息体中业务状态码不符合预期或数据长度较短等情况，会发出告警。
一般的网站可以使用 LVS 提供四层负载均衡服务，技术实力雄厚的公司可以使用自己定制开发的四层负载均衡服务。
七层负载均衡端是流量接入端的重要服务，处于用户流量接入的咽喉要道，重要性不言而喻，所以要有完善的。
一般七层的负载均衡服务使用 Nginx，除了基础的服务器、系统、应用层的，还可以实现更多的。
在流量接入端已经能够对业务集群的可用性、响应时间等关键指标进行和告警，对业务集群还可以按照纵向各层级添加指标。
为了便于提升服务器的资源利用率，及时发现系统性能瓶颈，为服务器申请提供数据支持，基于系统的数据，我们开发了容量管理系统。
第一步先实现集群的基本容量评估，通过几项主要的系统负载参数（CPU、内存、磁盘空间、磁盘 IO、网卡出入流量使用率）对集群负载进行分析。后续可以加入更多的业务指标来对容量进行管理。
龚诚，58 集团技术工程平台部高级经理，曾任职于百度、新浪微博等公司，负责运维及自动化团队的技术和管理工作；拥有丰富的网站稳定性建设、网站优化等经验。
本文由 325游戏（m.325games.com）整理发布