网易即时通信云平台99.99%可靠性的运维经验谈

网易即时通信云平台99.99%可靠性的运维经验谈

 

转载自：http://mp.weixin.qq.com/s?__biz=MzIzNjUxMzk2NQ==&mid=2247483968&idx=1&sn=fc9dfd261da9206271a557e113870196&chksm=e8d7fd82dfa074945c2e9fdcbc846802356c4597affe147fbb842a96a1171edff840dc08cd8f#rd

原创 2016-11-14 田浩然、周梁伟 高效开发运维
本文源自11月10日『高效开发运维』微信群的在线分享活动总结，转载请在文章开头注明来自『高效开发运维』公众号。加群学习请关注『高效开发运维』公众号，并点击菜单中的“加群学习”或直接回复“加群”。

一句话背景介绍：网易即时通信云平台，即网易云信，是网易集16年IM经验打造的即时通信云服务（PaaS）。




运维解决方案及最终效果

一: 怎样作到99.99%，确保稳定性

在网易云信，运维工程师的主要职责包括但不限于软硬件部署、网络管理、应用代码维护、安全漏洞修复、容量规划、故障处理、性能优化等。

网易云信做为即时通信云平台，核心功能保证99.99%的可靠性，也就是说一年不可用时长要小于52分钟，为什么作到？归纳为两个方面：第一，咱们的开发团队有很高的运维意识，在开发设计时就注重应用的可用性和扩展性；第二，咱们的运维团队很懂开发，经过专业的运维能力帮助开发规避风险；运维和开发相互合做，打造了云信的稳定。下面我和你们一块儿分析下网易云信的稳定性保障策略。

运维工程师们很相信一个神圣的定律——墨菲定律（Anything that can go wrong will go wrong）。根据墨菲定律的推论，任何一个环节都不是100%靠谱的；所以容灾是必不可少的，须要把容灾作到方方面面。

首先，硬件资源都是冗余的，主要包括如下几点：

1)    服务器：双电源，双网卡bonding，系统盘raid10

2)    机柜：双电路接入，电源容量充足

3)    交换机：接入交换机堆叠而且单个交换机网卡bonding

4)    网络：核心路由器/核心交换机冗余

5)    IDC：到各ISP的光纤要大于等于两条

6)    运维人员：应用运维、系统运维、DBA全部角色一主一备。

其次，整个应用架构的容灾，主要包含如下几个层次：

1）接入层：云信使用了ospf+Nginx作为了前端接入集群的负载均衡，全部Nginx机器配置统一，upstream配置里添加了到后端服务器（大于1个）的健康检查。

2）应用层：各集群服务器无单点，而且保证服务器分布在不一样机柜，不一样交换机。

3）中间件：HBase自己就是分布式系统，其余中间件云信也作了高可用改造。

4）数据库：作为架构中最核心的一环，数据库的容灾设计也是最完善的。数据库支持主从同步，主库挂了以后，能够1分钟内自动切到从库，而且可以保证数据一致性。

最后，万一IDC机房挂了怎么办？

咱们业务基建稳定，多机房多活架构，而且作到业务无感知。

作为运维人员，如何能够作到业务运行情况了如指掌？这个时候，就须要一个强大、好用的监控系统了，监控是稳定性建设的基石；网易IM云使用网易自研的哨兵监控系统，意指向哨兵同样迅速发现并相应异常状态。咱们使用哨兵作了如下几个维度的监控：

1）在监控完整性方面，自上而下作了业务监控、应用监控、基础监控，相关监控项类型以下

如某业务指标的监控趋势图：

2）在监控有效性方面，经过哨兵监控系统，报警有效性达到90%以上

•    监控数据采集、数据上报有效：数据采集失败、数据不能上报监控agent的监控采集器天天以报表形式发送到运维负责人，运维负责人进行修改

•    报警发送方式（短信、邮件等）、报警接收人有效：天天统计短信、邮件及其余渠道的报警发送量，有异常变化（突增或者为0）以报表通知到运维负责人修改

•    报警1分钟内到达：对自身发送器进行监控，消息堆积时及时处理解决

3）最后是哨兵的报警收敛功能。哨兵经过增长报警重试次数，集群报警合并等手段进行报警收敛，有效的避免了服务器数量级达到必定程度后，过多的报警会让人麻痹，进而忽略掉了真正有效的报警。

4）然而，虽然作了以上的工做来预防故障、快速发现故障，但故障的发生仍是在所不免的，一个合适的故障处理流程可以有效的缩短故障处理时长。

网易云信的故障处理流程：

为了不在遇到故障时，故障处理人员手忙脚乱、相关人员配合不到位等缘由形成的故障时长加长现象，咱们会按期进行故障演练；验证业务容灾能力，监控报警是否可达，人员应急处理能力。

二：运维标准化，提高效率

下面谈一下咱们产品的运维标准化之路。一个产品随着业务的日益复杂，应用系统会变的错综复杂。有人会问，1我的运维10台服务器和运维1000台服务器，哪一个更难一些？若是监控方式、部署方式无任何规律，1我的要支撑10台服务器就已经疲于应付；相反，若是全部的服务，都是一样的监控方式、部署方式，那么1我的运维1000台服务器，也是轻松愉快的。因此当IM云的服务器数量达到必定规模时，为了提升运维效率，解决运维管理混乱的难题，咱们制定了线上运维规范，包括但不限于如下几个方面：

1) 应用部署规范：一台机器只部署一个应用；规范文件与目录结构，咱们全部应用代码都在不一样服务器的同一目录下，下降因为文件数量众多带来的运维风险，保证生产服务环境的整洁。

2）日志运维规范：对日志输出目录、命名、格式、分割和归档进行了规范性约束。应用相关的日志统一存放在当前应用目录结构下面的logs目录。可以方便而有效地进行应用服务的多维度监控、应用日志分析，以及提高故障发现率。

3）代码发布规范：为减小代码上线引起的事故，提升代码上线效率。代码有固定的发布窗口，发布前必须进行发布审核，而且有完善且可执行的回滚方案。

4）监控和报警规范：云信全部应用包含基础监控和应用监控；以及云信自身的业务指标监控。报警内容清晰明确，报警接收人有效且保证在两人以上。

5）帐号和权限规范：系统管理员使用root权限；代码发布使用公共帐号权限；普通开发人员使用我的帐号权限，我的帐号权限不能在服务器上执行除家目录以外的写操做。

普适的运维方案和推荐工具

普通研发团队有什么方案和工具能帮助开发者达到大厂80%的效果？
为了减小运维管理的成本，必定要作应用部署的隔离，有运维团队的公司会选择传统的虚拟化技术（KVM，LXC）对物理机进行初始化，如今业界比较流行的是物理机上运行Docker容器对服务进行隔离；也能够选择直接使用云计算公司提供的服务器资源。

服务器的帐号权限配置，软件环境配置等配置管理可使用Puppet来管理；

代码部署方面可使用GitLab+pipeline替代方案；

监控系统业界比较经常使用的是开源的Zabbix；

持续集成一般使用Jenkins；

自动化运维工具比较流行的是使用Ansible；

提升应用的故障容错能力可以使用Netflix Hystrix。

以上部分工具，网易目前也一样在使用，并且很好用；关于工具的使用方式，Google有比较成熟的文档，你们能够按需调研学习。

系统设计及实现须顾及后期运维

以上是云信部分运维工做的介绍，但须要特别提一句，一个可运维、方便运维的产品，开发同窗的投入功不可没。

1. 良好的系统架构是顺利开展运维工做的前提

在作系统架构设计时须要充分考虑功能模块的耦合性，尽可能作到业务功能的独立解耦，下降互相之间的依赖；最差的状况就是全部的服务功能集中在一个进程中，一个挂，所有挂，一个升级所有受影响，这种系统设计对运维工做来讲就是灾难；作好功能模块的划分和隔离，能够下降故障的影响范围，在升级等平常运维工做中也能够作更好的规划；

 2. 架构设计时将HA做为必须知足的非功能性指标

任何一个系统都会存在故障的可能，程序猿写的代码即时再好也有出bug的时候，即时程序不出bug，也仍是逃不过机器宕机后者断电断网等各类意外状况的发生；因此设计者须要善于找到系统中存在的单点，并解决这些单点；高可用的特性并非说要求程序必定不能挂，而是说从架构上容许故障的发生，任何一个节点的故障只能影响系统的总体处理性能，可是不会形成业务不可用；具体来讲，若是是Web类的应用，可使用Nginx等反向代理工具来搭建多个后端的业务集群，并在出口上作Keepalived等高可用的方案，对于通常的应用，设计时须要保证多实例可同时服务，多实例功能相互对等，任何一个实例的停服，其业务请求能够被其余实例来分担；作好了HA架构，咱们在运维工做时才能更加从容，由于当运维报警发生时，咱们知道当前业务处理能力虽然降低了，可是整个业务并非不可用的状态，对用户来讲不会产生直接的影响，运维人员能够从容得恢复故障节点便可；同时良好的HA架构也有助于业务扩张时的加强系统扩展性；

3. 业务系统给运维系统提供更加友好的接口

运维平台的一个重要工做是从业务系统中提取到准确的指标，并针对这些指标来作线上的监控和预警；更加了解业务系统的仍是开发人员，而非运维人员，因此开发人员须要在设计功能时同时兼顾到运维的需求，充分设计哪些指标须要被暴露出来，常见的好比当前系统的TPS(每秒的处理能力)，MRT(平均响应时间），系统的能力上限等，再结合如JVM内存使用状况，GC状况等基础数据，运维平台就能作出更加合理的监控支持，有了这些监控数据以后再制定更加科学的预警，能够在故障实际发生以前就作出预警（好比TPS达到系统容量的80%了），让运维人员提早作出扩容等应对，而不是等到功能不可用了才报警；从技术实现上来讲，业务系统向外暴露接口的方式就很是多了，好比Java程序能够经过JMX来实现，通用的进程可使用隐藏的Http接口等方式来实现；若是运维平台使用的是Ganglia等开源平台，也可使用对应的客户端Agent来向运维平台暴露数据；

4. 规范的日志输出

不少开发者在实现业务系统的时候每每会忽略日志的做用，或者只把日志当作偶尔查查问问的工具，日志的输出内容每每是只有人来读取的非格式化内容；其实除了定位问题以外，日志还能够帮助咱们作更多的事情，咱们能够设计一个程序友好的日志格式，好比输出JSON格式的日志来记录每一个业务请求的执行状况，如请求参数，处理时间和响应码，失败信息等；有了规范的日志以后，能够经过脚本的方式将日志中的信息提取成指标输入到运维平台中，能够对业务系统当前处理的成功率，响应时间等作更加细粒度监控和报警；

5. 善于利用功能测试框架

不少公司对开发人员的代码质量要求都很高，会要求在QA测试以前作到单元测试等工做，有些QA部门也会利用一些标准化的工具对线上流程作回归测试，好比Junit或者TestNG等；其实咱们也能够充分利用这些资源来作线上的运维监控；咱们退一万步来讲，若是一个系统没有任何运维预警，那么若是线上发现问题的会是谁？这必定是用户，那么能不能有一个机器人用户来帮咱们提早发现问题呢？这里咱们就能够利用功能测试的成果了，将用做线上回归的TestNG代码用程序自动化的方式按期执行起来，并解析执行的结果，若是回归测试失败就马上发报警出来，这种看起来很土的方法在实际操做中。

群友&嘉宾的问答实录



Q：很是感谢两位专家的分享。请问单元测试网易云信是作到什么程度，所有采用仍是部分采用呢？        

A：单元测试对于保证线上服务的质量是很是重要的，咱们对开发人员的要求是总体单元测试的代码覆盖率要达到80%以上，核心模块的覆盖率要100%，在每一个版本的迭代中，都须要使用单元测试对老功能作回归。

Q：云信运维人员是否还会负责其余产品？好比同时负责云笔记、云信等B2C产品，又负责云笔记、云信大数据平台建设？

A：云信运维人员同时也会负责其余运维产品，好比我在负责网易云信的同时也会负责网易七鱼，个人同事在负责网易云音乐的同时会负责网易新闻客户端；虽然是不一样产品，但架构大致是相同的，这个时候就体现出了运维标准化建设的重要性，不然运维成本将会很高

Q：代码发布频率达到一天一次？几天一次？仍是一天屡次？

A：网易云信的发布频率是一月一次，bug修复除外；发布次数主要看业务类型吧，好比金融类业务以稳定为主，发布频率较低；电商类业务会配合较多的运营活动，发布频率比较高；我认为无论什么业务，合理发布窗口和完善的发布回滚流程均可以有效的下降故障的发生

Q：请问两位老师 1.「通用的进程可使用隐藏的Http接口等方式来实现」这个怎么理解？ 2.能简单说说发布过程及回滚方案是怎么样吗？ 谢谢。        

A： 1. 好比你的应用是一个web类的应用，前端确定会有nginx之类的接口来控制可访问的接口范围，你能够把暴露监控指标的请求路径在nginx上作控制，对外不可见，仅对内网环境开放；这类接口对外部用户来讲就是“隐藏”的；若是不是web类的应用，能够在进程中内置jetty等小型的web容器，来暴露一些控制和采集指标的接口； 2. 发布的过程须要制定详细的发布计划，控制涉及到的模块范围，作好回滚方案，这些也须要QA部门全程参与，由于QA须要针对升级的内容制定线上回归的用例；在升级操做时，须要作好线上业务的流量切换，对web类应用也能够在nginx等前端代理上有意识地切断心跳检查，使线上流量从即将升级的目标服务器上切走，再对这个目标节点升级，这种方式能够作到线上升级不停服的效果；

Q：raid10 /raid 5 如何进行选择？

A：网易目前通常用raid10，选择raid的类型主要从恢复成本、性能、经济成本几方面来考虑；从产品运维的角度来看，我以为应用自己作好容灾，重要数据按期备份比纠结raid的选型更重要

Q：报警指标，频次，对象的选择，如何把握正确的度

A：我认为报警的完整性、有效性、及时性缺一不可，报警的频率取决于被添加应用的重要程度，好比云信的发消息最重要，那我认为1分钟发一次报警，而且为了防止漏接，使用电话报警是颇有必要的；而对于一些后台应用，我认为频率三分钟1次，甚至更低也ok

Q：网易云信是使用了Docker吗？若是是的话，何时开始的，效率提高了多少？        

A：网易云旗下的IaaS产品叫蜂巢，就是Docker类云服务。这个服务在网易内部产品中已经获得了很普遍的应用，云信业务中也使用了蜂巢来承载一些业务功能；带来的好处就是经过节点复制等方式能快速实现业务扩容，提高运维的便捷性；另外一个明显的好处就是极大提升了硬件资源的利用率，这也是云计算带来的最大的好处，我想你们对此都有至关的认识了，不用细说了；至于你说的效率提高了多少，不少是表如今人力的解放上面；好比原来咱们运维人员须要花5个小时作的部署工做，如今也许半个小时就能够搞定了；

Q：对于错误解决方面，可否实现简单的自动解决模块，尽量的减小人为动做了？

A：网易云信目前采用的方式是和监控系统联动来解决，当监控采集器触发报警表达式的时候，会调自动化工具来进行自动化处理，若是自动化处理失败，才会发报警出来，如删除日志等，具体看自动化工具是否强大

Q：贵公司在运维开发方面，是怎样实践的？ 好比哨兵监控系统，运维人员参与了多少？

A：我了解到的业界互联网公司的监控系统最初所有都是运维人员开发的，最起码也是运维人员参与设计的。由于监控系统最主要的使用者是运维人员，要想用的爽，仍是要本身动手的。

Q：对于传统的系统，有cs架构和IIS 的web监控有什么建议吗？

A：对于cs的架构的系统，s端的监控是重点，监控的方法其实和bs的server端相似，而对于c端的监控，通常能够经过心跳的方式来实现，在s端检查c端心跳超时，再上报预警系统；IIS的web和其余的web也相似，基础的指标，如内存占用，cpu使用率等能够从操做系统层面来作采集和监控，而业务层的指标也可使用对外暴露接口或者暴露日志来采集监控数据；

关于两位嘉宾

田浩然，网易云信运维负责人

2015年加入网易，参与网易杭研院核心产品监控方案的设计，监控有效性以及监控完整性的提升；参与网易云容灾架构设计；现做为云信运维负责人负责稳定性保障、成本控制、运维效率提高工做。2011年时就任阿里巴巴，负责阿里巴巴国际业务的运维工做，参与双十一活动的运维保障；参与国际业务异地多活架构设计。


周梁伟 网易云信首席架构师

2011年加入网易，涉猎范围包括：通用服务器后端开发，大数据统计分析，IM系统设计开发等方面。前后参与云存储系统开发；通用日志采集平台Datastream的设计和研发；通用网站数据分析平台；易信产品的服务器研发，易信WEB版长链接服务器；HBase集群搭建和运维；目前做为云信系统首席架构师负责平台的架构设计和服务器研发团队。

网易云信

云信是网易公司集16年IM经验打造的即时通信云服务（PaaS），开发者经过集成客户端SDK和云端OPEN API，便可快速实现强大的IM功能，做为PaaS服务模式的网易云信全面支持Android、iOS、Web、PC等多平台。

还提供了高级通信功能，包括实时音视频、互动直播、教学白板、专线电话、短信、专属云在内的独家功能以及更多其余服务。网易云信知足包括游戏、协同办公、在线医疗、在线客服、在线教育、娱乐、咨询、生活服务、物流、旅游、金融等各行业各类产品的即时通信服务需求。