导读：从 0 到 1，魅族 络架构经历了四个时代，也部署到异地多机房，并成功服务几千万用户。将全国响应速度控制到 30ms， 络架构改造演进过程中积累的经验和教训 络的监控是每个团队关心问题，看魅族做了哪四大监控优化来解决基础 络可用性问题p>
络设备数量：200+
服务器数量：2000+
虚拟子机数量：2500+
互联 带宽：4G+
专线带宽：400M+
CND 带宽：100G+
运维问题
在传统手机制造业向互联 方向转型，以及业务爆发式增长，基础 络运维遇到过什么问题、困难呢p>
伴随着魅族官 、 区、商城、Flyme 官 、云服务的发展，业务驱动诞生了魅族 络架构 V1.0 版本，主要特点：
络架构：传统二层 STP 络架构，链路资源利用率低、可靠性性低、维护成本大；
硬件设备：性能和稳定性不足，核心设备经常会出现 CPU 负载过高导致重启。
典型机房代表：广州亚太 IDC ，已于 2015 年 12 月完成了裁撤。
三、不屈白银（2014 年）： 络架构 V2.0
“不屈白银，大多数玩家都处在这个位置当中。”
伴随着互联 业务的爆发性发展，传统的“人肉运维模式”已经无法支撑千万级用户，于是标准化驱动诞生了魅族 络架构 V3.0 版本.
什么叫标准化简单例子：商鞅变法前，秦国各地度量衡不统一。为了保证国家的赋税收入，商鞅制造了标准的度量衡器，意义：全国上下有了标准的度量准则，为人们从事经济文化交流活动提供了便利的条件。
我们是怎么做的呢通过架构设计、 络设备选型、IP规划、 络连接规划、 络配置脚本等制订一套标准规范。
3.0 版本 络架构除标准化外，其它主要特点：
1）三 分离：
a) 结构逻辑清晰；
b) 安全分级：内外 物理隔离，提高内 的安全级别，降低安全风险；
c) 提高 络可用性、吞吐能力；
d) 管理 带外管理，提高运维排错能力。
2）流量可视化：
a) 外 流量特性固定，基本是直上直下的南北流量；
b) 内 流量复杂，属于东西南北穿透。
内外 流量分开便于 络流量管控可视化。
3）单组 TOR 升级：一组 TOR 容量提升 50% 以上。原来 V2.0 一组接入层交换机仅能覆盖 2 个机架（24 台服务器），而 V3.0 版本一组接入层交换机可以覆盖 3 个机架（36 台服务器起）
4）逻辑分区：普通区、LVS 区、大流量区、安全管控区。
5）安全方面：
a) DDOS 流量清洗购买了 BAT 的云盾（腾讯叫宙斯盾）服务；
b) 自研 WAF 平台；
c) 出口 ACL 白名单
V3.0 络架构版本另外一个突出特点是 LVS 引入了 FULLNAT 模式，逐步淘汰 DR 模式，从而提高了数据中心的扩展性、健壮性。
五、华贵铂金（2016 年后）： 络架构 V4.0
测试及进行中，请留意进展。
六、DCI 络架构介绍
前面所提到的都是单个 IDC 的 络架构，大家都还记得 2013 年 7 月及 2015 年 5 月一些同行的光纤被挖断故障房会存在扩展难、无法容灾、无就近接入等问题。针对单机房问题，我们的应对措施：
制定运营商、代理商服务 SLA 协议标准，比如 99.9%；
多线 IDC + 分布式数据中心部署，提高业务部署冗余性，提高业务部署冗余性。
接下来将分享我们的 DCI 络架构：
先简单概述我们多机房业务的部署，目前我们通过 GSLB 已经实现了用户就近接入，提高了用户体验，即华东片区用户访问华东 IDC，华南片区用户访问华南 IDC。 关于异地多活的方案，我们正在演练阶段，计划今年将会实现。
我们先来看看 VPN 平面，节点之间是建立电信、联通链路两条 VPN，路由协议跑的是 IPSEC + EBGP，BGP 具有灵活、稳定的特点，设备选型是 FT 的 1000D，VPN 吞吐量高达 30Gbps 以上，可用性相比 2015 年之前，有了一定的提升.
七、办公 与 IDC 解耦
数据中心的大概分享到这里，接下来将简单介绍一下办公 以及跟数据中心的互联互访。
曾经踩过的坑：2015 年 7 月珠海总部办公大楼掉电，影响中断华南 IDC—华东 IDC 机房间 络的通讯。
办公 与 IDC 解耦，IDC ? FW ? OA：通过 OA 边界墙实现办公 与 IDC 的隔离，默认只放通运维相关的端口，策略申请需要安全部门评估审批。
络监控的 4 大优化
面对千万级用户的异地多点 络架构，魅族的 络监控是怎么支撑的呢p>
监控痛点
我们监控曾经遇到痛点：
监控系统可读性差；
监控项告警重叠；
告警无法定位问题；
业务产品带宽使用。
监控架构总体视图
先来看看监控总体视图：
优化后：
对设备的监控配置进行了标准化，比如：什么类型的设备用什么样的监控模板，模板需要包含什么内容，甚至是模板的命名也进行了标准化
（ 点击图片可以全屏缩放）
每日会收到超过 100 条的短信和邮件的告警，很多是一些没有实际意义的告警，严重的干扰了正常的工作，经过对告警信息的分析，主要存在几个问题：1、告警的准确性；2、重复告警；3、通知类告警太多。
优化后：
（ 点击图片可以全屏缩放）
优化前：
我们 IDC 经过二级运营商接入至一级运营商的 络，专线 络也是同样的情况，当发生故障时，我们只知道整条访问路径有问题，但不知道故障具体发生在哪个节点
优化后：
为了解决这个问题，我们把接入运营商 络时经过的所有关键节点（二级运营商机房的边界、一级运营商 络边界）均纳入到我们的监控系统中，在我们的监控系统中可以非常直观的看到某个运营商整条访问路径的链路质量。
对于专线 络也是同样的做法，我们联合线路供应商，在线路的关键节点上配置了监控地址，整体链路的质量情况也尽在掌握当中。
Q&A
问题1：为什么要做标准化 络架构实现strong>
1、传统的“人肉运维模式”已经无法支撑千万级用户；
2、IDC 络架构版本设计标准不统一，不利于公司互联 业务快速发展 ；
3、业务的高速增长。
我们的标准化方案：我们通过 络架构规划设计、 络设备选型、全 IP 规划、 络连接规划、 络配置脚本等制订一套标准规范。
问题2：如何实现办公 与数据中心的互联互访strong>
我们将办公 与 IDC 解耦，即 IDC ? FW ? OA：消除了过去以珠海总部为集中单一的混合核心节点，通过 OA 边界墙实现办公 与 IDC 的隔离，安全策略默认只放通运维相关的端口，策略申请需要安全部门评估审批。
问题3：为什么要做多机房架构应对单机房、运营商问题strong>
单机房会存在扩展难、无法容灾、无就近接入等问题。我们的应对措施：1、制定运营商、代理商服务 SLA 协议标准，比如 99.9%；2、多线 IDC + 分布式数据中心部署，提高业务部署冗余性，提高业务部署冗余性。
问题4：异地多点 DCI 络架构如何保障基础 络的高可用bsp;
我们 DCI 经过半年多的优化整改，已经实现如下效果：DCI 由专线平面 A 、VPN平面 B 双平面组成 ，其中专线平面为主，VPN 平面为备，当专线平面瘫痪后，流量会自动切换到 VPN 平面上。
问题5： 络架构改造演进过程中积累的经验和教训bsp;
1、 架构： 络架构脆弱，故障不定时爆发。比如单点架构：IDC 与办公共用办公 珠海总部节点为中心，办公大楼的基础设施可靠性远不如数据中心，当办公 中心节点需电力等维护或故障时，将影响IDC节点可用性等；
我们的应对措施： 络架构整改，搭建魅族的 DCI 络、以及推出标准化的 V3.0 络架构。
2、硬件：硬件性能瓶颈，高峰期 CPU 高达 99%。比如早期的广域 使用低端路由器跑公 DMVPN，经常会在晚上高峰期 CPU 经常会高达 99% 左右，产生丢包影响；
我们的应对措施：引入数据中心级高密交换机或路由器、防火墙，稳定支撑承载互联 业务。
3、 监控：监控覆盖率低，故障无法跟踪定位。比如机房内、机房间、公 的质量情况等等；
我们的应对措施：1）监控模板标准化；2）告警收敛；3）提高监控覆盖率至99%以上；4）公 /专线线路质量监控；5）带宽可视化。
4、运营商：运营商复杂，公 质量无法保障。比如公 链路丢包等。
我们的应对措施：1、制定运营商、代理商服务 SLA 协议标准，比如 99.9%；2、多线 IDC + 分布式数据中心部署，提高业务部署冗余性，提高业务部署冗余性。
问题6：对公 和 DCI 络是如何监控的strong>
1、我们把公 线路和专线线路经过的所有关键节点纳入到监控系统中，实现整条路径的丢包、延时 络质量监测；2、通过基调、博睿等第三方对监控 IDC 至全国各城市的 络质量
问题7：基于什么原因引入 SDN 架构方案strong>
1、DCI 流量智能调度 ； 2、云平台的租户隔离 ；3、 络配置自动下发； 4、云业务的快速更变。
高可用架构
改变互联 的构建方式
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！