2018年春节期间，组件运维团队运维设备4万余台，单人运维设备2万余台。我们在海量服务运维过程中面临哪些挑战？我司组件运维团队职责范围：??负责整个SNG接入和逻辑层业务的运维，18000个域名，3000个业务模块，40000台设备，单人操作20000多台设备和维护。在大范围内，我们面临五个主要挑战。第一个挑战是中国幅员辽阔，跨越5个时区，有30多个省级单位。我们的机房分布在上海、天津、深圳。上万个域名如何就近访问？我问你一个问题，江西离上海近还是离深圳近？答案是江西北部靠近上海，南部靠近深圳。我们招O&M的时候，还要求O&M能够把天文地理都做好，这显然是不靠谱的。中国有三大运营商，中国电信、中国联通、中国移动，还有许多较小的运营商。中国有句话，世界上最远的距离不是天涯海角，而是你在电信，我在联通。相信大家都有非常深刻的运维经验，所以尽量避免交叉算子。第二个挑战是，自从苹果推出ATS安全规范后，域名支持https访问已经成为标准。https证书有有效期，需要不断扫描、更新、更新。如何高效统一维护上万个域名的HTTPS访问，如何通过运维彻底解决这个问题，是我们面临的第二个挑战。第三个挑战是，当一个人运维超过10000台服务器时，你会发现你名下的几台设备每天宕机是很正常的。前面说了，不能一躺到床上就马上起来，运维也是人来做的。怎么保证宕机是在没有运维介入的情况下自动处理的，不会对业务造成损害。第四个挑战，网上有个说法，上线容易，维护难。互联网服务的运维周期比研发周期长。一个产品的研发周期只能开发几个月。但运维时间往往是数年甚至十几年，很容易进入长尾死而不僵的状态，因此对运维也存在挑战。第五个挑战是大规模扩展和缩放。例如，春节、元旦等节假日，用户喜欢在QQ空间发表感想，在QQ群里发祝福。社交网络也会趁势火上浇油，逢年过节都会组织一些活动，每年都会发QQ红包。就这样，大家愉快的假期变成了我们运维艰难的一天，因为涉及到大量的设备上线和模块扩容。这就是我们面临的第五个挑战，如何应对大规模扩容和缩放。本文从以下三个方面阐述如何应对挑战：海量服务基础设施运维实践中总结的几条原则支持大型活动的实用技巧海量服务基础设施过程中坚持的一些原则和支持大型活动的技能三个方面来解释我们如何应对上述挑战。先来看腾讯SNG的基础设施。用户请求过来后，任何访问首先是DNS查询，通过查询得到TGW和STGW的网关IP。这个TGW类似于业界开源的LVS和商用的F5。请求经过网关的负载均衡，到web层服务器，再到逻辑层和存储层。图中中间的智云路由是内网的负载均衡系统。我们整个访问链路做到了三个基本点：确保名称服务中没有不能调整的流量，对于运维来说是非常重要的。容错保证没有不能down的设备，也就是没有不能死的设备。我们在网上看到一些笑话，运维请师傅来机房保佑宕机，其实求佛不如求己。统一的框架提高了研发运维的效率，保证了基本的服务质量，对运维意义重大，后面会重点介绍。牛顿说，如果我比别人看得更远，那是因为我站在巨人的肩膀上。如果我们能运维10000台服务器，那是因为我们站在巨人的肩膀上，踮起脚尖，放眼1.8米。巨人的肩膀：GSLBGSLB是腾讯自主研发的DNS服务。通过识别LocalDNSexportIP的国家+省份+ISP属性，然后将对应的IP返回对应的请求，实现就近访问。北京、上海、天津每个区域都是3大运营商+中小运营商出口CAP，然后加上香港。所有通过香港的海外接入方式均按运营商调度。这是为了避免交叉操作；二是实现运营商网络出口故障的快速切换，依托GSLB的这两点：GSLB拥有强大的基础数据库，拥有全面准确的IP地址数据库，国家和运营商的信息准确率100%，各省信息准确率达98%。我们利用亚洲网络中心和中国网络中心的数据、运营商路由数据等，通过一些算法验证得到IP地址数据库的数据。我们有各个IDC机房用户覆盖质量的实时数据，这些数据是通过机房拨号测试和前端页面的一些js采样报告得到的。巨人的肩膀：TGWTGW是腾讯的网关系统。2012年之前，腾讯也用过LVS隧道模式，但腾讯的业务发展太快，尤其是游戏很快就面临问题，外网资源枯竭。在此背景下，TEG的基础设施部门推出了TGW系统。它最大的特点是可以汇聚外网IP，只需要一个外网IP，所有数据包进出都通过TGW，对真正的后端服务器没有外网需求。LD本身的VIP如何做到高可用呢？通过OSPF路由一致性协议，一般4个LD组成一个cluster，共享这个VIP。任何LD挂掉后，该VIP不受影响。此外，TGW还实现了多通道接入。每个机房都有三大运营商的网点和CAP网点。我们部署的服务器对运营商机房没有要求。电信机房也有三网+CAP网点。以前在使用LVS隧道模式时，电信的容量必须依赖于电信机房的服务器，所以对服务器机房的限制比较多。除了外网IP汇聚，TGW还支持Layer4/7，尤其是Layer7，数百个域名可以在外网共享一个VIP。强大的。巨人的肩膀：STGW关于STGW，你可以认为它类似于TGW。它在TGW的基础上只支持https。自从苹果推出ATS安全规范后，新上线的域名都会默认支持https访问，因为你说你的网站不支持https，就不好跟别人打招呼了。我们面临的情况是域名太多了。在STGW之前，对于https的支持方式，开发或者运维，都是自己上传证书到服务器，放在自己想要的路径下。每个人都有不同的风格。没有统一的管理。一旦人员流动，他做的这些东西在生产环境中就会烂掉，所以就会出现很多因为没有及时更新更新证书而导致的故障。痛定思痛后，我们将全网域名升级为STGW，所有证书统一部署在STGW平台。申请、更新、更新等操作均由组件运维团队完成。通过域名逐个扫描证书是否过期，可靠性比较低。如果是STGW托管的，我们直接从服务端读取证书的过期时间。不可能出错，证书安装和更新的环境更纯净。改变的风险要小得多。巨人的肩膀：智云路由智云路由定位为内网名称服务系统。就是我们的用户请求通过TGW到内网后，从接入层到逻辑层，从逻辑层到存储层的寻址系统。有的企业也用F5做内网负载均衡，我们为什么不用呢？是差钱吗？我们一点都不缺钱。我们为什么不呢？因为我们的路由是强嵌入的，所以对用户的主调有要求。这里有两个功能。界面非常简单。首先通过GetRoute获取IP端口，然后访问。然后，你访问我是成功还是失败。上报APIRouteResultUpdate并统计上报数据后，做负载均衡决策。我们的智云路由器和业内大家熟悉的组件有什么区别？刚才说了，我们不缺钱，为什么要用智云路由呢？因为我们有细粒度服务治理的需求，所以它是一套细粒度服务治理的解决方案。它唯一的缺点是在使用门槛上需要业务调用API代码，但这也带来了好处。相比于F5、LVS的非侵入方式，基于调用者向智云路由的报告，实现了后台服务质量的精细化管理。智云路由成功率是SNG后台服务质量的考核标准。以此提升后台服务质量。.二是负载均衡。过载保护能力根据业务上报的成功率设置。当后台能力不够时，会拒绝多余的请求，只给出成功的请求。与其把所有的请求都发到后端，把后端压死，还不如告诉你，前端拿到IP+端口就超载了，不要请求了，把请求发到后端的极限可以承受。三是容错。F5和LVS的容错只能检测端口的连通性，而智云路由可以自定义容错场景。第四，相对于F5和LVS的四层代理，被调用服务获取主调用IP会非常困难。跟踪服务问题是一个很大的门槛，但智云路由不会造成这种麻烦。巨人的肩膀：逻辑层统一框架SPP后台框架对运维意义重大。SPP由三部分组成：Proxy、Worker和Controller。通过编写一个健壮的高端后端服务器，开发可以非常简单，并且控制器具有监控Workers和Proxies的能力。如果Worker和Proxy有问题，就会重启。也可以通过配置Worker进程数来控制程序的并发。统一运维架构的意义：跨业务统一运维策略。网络框架和业务逻辑SO分开管理，运维具备快速升级框架的能力。有很多统一的框架，是和业务程序集成在一起，打包在一起，编译进去的，当框架引入新的优化，想要在全网普及时，所有的业务系统都要重新编译发布。但是，我们的框架和SO是分开管理的。框架由运维统一部署，SO由业务部署。当框架有好的特性或者紧急需要升级的bug时，运维可以快速升级框架，无需重新编译即可完成。提升运维专业化水平。众所周知，铁的生意，兵的流动，人员的流动是非常快的。我们统一了框架之后，可以让运维有更强的问题定位能力，专业性得到了很大的提升。框架数据包的流程非常清晰。运维比开发更懂他写的程序。当然，除了业务逻辑之外，运维的大部分环节都比开发更专业。Controller具有监控和启停Proxy和Worker的能力。C语言后台程序经常有coredump，如果指针使用不当，core就会掉线。Controller使得Worker进程即使挂掉也能快速恢复。运维实践中总结的几个原则说完了巨人的肩膀，再说说1.8米踮起脚尖的视野。如何让运维更高效？名称服务的原理前面提到过，名称服务非常重要，我们必须保证系统中的任何一个地址都有名称服务。我们每年移除数以万计的设备。没有IP就不能移动。所有IP都可以更改。近10万台设备，每天有几台设备宕机很正常。名称服务和容错是自动化运维的基础之一。我也提到了很多关于它们的重要性。所以这里分享一下运维是如何影响研发端的，实现名称服务的原理。我们从三个方面来做：联合QA，建立质量评估体系。我们梳理了访问关系，将其与名称服务的访问关系进行对比，找出哪些调用没有使用名称服务，从名称服务的覆盖率和QA推动所有研发。这是中策，毕竟推广不是那么容易的。后台框架支持RPC，封装路由寻址调用，让调用者在不知不觉中使用了名称服务，服务提供者可以具备快速切换流量的能力。为扩展名称服务的场景，智云路由支持根据UIN进行状态寻址和一致性哈希寻址，同时支持DNS协议，降低接入门槛，让我们的名称服务得到普及。一致性原则我们的SNG服务按照模块进行管理，包括智云CMDB模块入口包、名称ID、配置文件、权限等资源。您需要检查输入的资源是否与现网使用的相同。因此，我们在运行过程中也遇到了一致性问题。我们收集了封装的权限，由组件运维端统一管控。为了实现模块下所有设备包的统一管理，有些机器不能安装，有些机器不安装，会给现网带来运营风险。配置文件方面，如果通过配置系统发送到现网，有人篡改，系统注册的配置与现网使用的配置不一致。只要动了这个配置，就会出问题。所以我们开始改造，开启强一致性功能，将现网机器上的配置文件与配置中心的配置文件进行对比，发现不一致就强制修改。同时我们也在思考，为什么配置管理要以文件的形式进行，而不是像Key-value这样的内存键值对呢？使用Key-value，不需要读取本地文件，有的是服务热重启，有的不支持。更改配置文件重启必然会有影响。Key-value模式自然不需要重启。这个解决方案有很多实现。以后我们会主要推广key-value的方式，让生效的时间和影响力得到优化。在权限方面，一开始我们是按照IP来管理的，后来发现IP模块归属的变化带来了冗余，每次扩容都需要为新的IP单独申请权限，这是一个很大的缺憾。所以我们绑定到模块，而不是IP。按照模块管理，只要模块有这个权限，这个管理就比IP管理好。某种程度上，根据模块的管理维度，我们智云，你的模块绑定了哪些名字，这个模块的IP是否连接了这些服务，有的没连接，有的连接，为你减少capacity有时候会有风险，会有踢出某个名字的风险。因此，我们会定期进行比对，一旦发现问题，我们会发单处理，并保持模块下IP和服务访问名的一致性。无数据原则非常重要。对于我们的接入层和逻辑层来说，一个人维护两万台设备是非常关键的基础。我们要求所有的访问和逻辑层设备都是无数据的。首先，对于上报超时等假死状态的告警，因为它没有数据，所以整个处理过程变得很简单，需要考虑的点也比较少。如果有告警，我们先判断是否是接入层和逻辑层设备。如果是这样，那么你可以直接重启。刚才说了，我们的智云路由是有流量自动恢复的，在设备故障后发现端口连通性恢复后，会自动恢复流量。如果重启无法修复，就看现场能否修复。现场无法修复的，将报废。如果现场可以修复，则可以继续服务。这个简单粗暴靠谱。第二无数据也带来了对设备要求的简化，没有raid，硬盘故障后直接换盘重装。第三个无数据需求是实现磁盘的自动清理，同时尽可能多的保存日志。我们一步步缩短日志保存时间，直到磁盘不再警告，骚扰对我们来说就会变得很小。统一原则我们有统一的后台框架、统一的名称服务、统一的配置中心、统一的数据上报通道、统一的包发布系统。这些都是自动化平台的基础，因为统一带来了维护对象的减少和上层调用系统的简单化，可以大大提高上层自动化系统的可靠性。我们有一句话，不要在沙盘上盖高楼，地基打不好，自动化程度就很难提高。支持大型活动的实用技巧我们为社交商务活动和节假日做的更个性化。我们在大型活动中面临的挑战：扩容设备量大，模块多，扩容状态跟进难。一个人扩展一个模块还好，如果要扩展几十个、几百个模块，就很难跟进流程状态了。留给扩容部署的时间也很紧迫。在刚刚过去的2018春节红包活动中，组件运维团队扩容641次，涉及模块535个，设备15701台。扩建作业要求在设备交付后一周内完成。看一下春节扩容的大致流程：先是资源申请，资源合理性PK，然后是采购和资源投放。之后，会有一个虚拟化的过程。设备生产和产能扩张将部署在智云。灰度验证和全面上线会涉及智云路由（通过智云路由进行流量调度）和监控系统（通过监控系统检查新扩容IP的服务质量）。活动结束后需要下线，必须进行设备隔离。整个资源的归还必须在资源管理系统中完成。我们面临着与不同部门的各个团队的沟通，单独运营每个系统的成本是非常高的。打个简单的比方，当你分配了15000个设备时，你需要将它们分配给相应的模块。如果不使用工具来做，人肉操作起来要两三天，而且很容易出错。.智云对单个服务的自动化部署有四个流程：部署准备、检查一致性、检查设备连通性、获取资源、阻塞告警。发布部署、申请权限、安装程序包、分发配置、同步文件。发布自测，启动软件包，处理端口扫描，运行测试工具。灰度在线，一个灰度10%，调用改体检，全量接入。我们有能力对单个服务进行自动化部署，但是我们同时扩展上百个模块的能力是不够的。在此基础上，我们构建了批量部署系统。每个系统都具有对外接口其功能的能力，对外提供http接口。那么批处理系统就可以将各个系统的这些操作串联起来。批量部署系统：集中展示和管理，每一步都封装成一个原子接口，在统一接口上操作。与各个系统的对接，比如哪个模块扩展了多少，在资源申请表中录入。批量系统根据资源申请表自动生产设备，将设备分配到相应的模块，在智云上批量发起扩容流程。规模效应，数百个业务模块批量运行。状态自动跟进。我们记录所有关键节点的状态，并在统一的页面上展示。这样才能知道这上百个模块的扩容情况如何，完成了多少，哪些在进行中，哪些失败了，更容易关注那些扩容有问题的模块。我们最终实现的是，我们能够在一周内完成15701台设备的600多次扩展。春节期间，组件团队在单人最多的时候运维了2万多台设备。SNG组件运维团队负责人张黎明拥有八年运维经验。参与了国内社交平台QQ、QQ空间的开发和成熟，也参与了SNG系统标准化、大规模组件化运营推广、自动化运维等项目。本人在海量服务运维方面有一些经验，今天分享给大家。让我们来看看实战。
