只要你有过在生产环境中实际运行过分布式系统的经历，你就应该清楚，各种不可预期的突发事件一定会发生。分布式系统天生包含大量的交互、依赖点，可以出错的地方数不胜数。硬盘故障、网络不通、流量激增压垮某些组件，我们可以一直列举下去。这都是每天要面临的常事儿，处理不好就会导致业务停滞，性能低下，或者是其他各种无法预期的异常行为。
在复杂的分布式系统中，人力并不能够阻止这些故障的发生，我们应该致力于在这些异常行为被触发之前，尽可能多地识别出会导致这些异常的，在系统中脆弱的，易出故障的环节。当我们识别出这些风险，我们就可以有针对性地进行加固，防范，从而避免故障发生时所带来的严重后果。我们能够在不断打造更具弹性（弹性：系统应对故障、从故障中恢复的能力）系统的同时，树立运行高可用分布式系统的信心。
Kubernetes 以其超前的设计理念和优秀的技术架构，在容器编排领域拔得头筹。越来越多的公司开始在生产环境部署实践 Kubernetes，在阿里巴巴和蚂蚁金服 Kubernetes 已被大规模用于生产环境。Kubernetes 的出现使得广大开发同学也能运维复杂的分布式系统，它大幅降低了容器化应用部署的门槛，但运维和管理一个生产级的高可用 Kubernetes 集群仍十分困难。本文将分享蚂蚁金服是如何有效可靠地管理大规模 Kubernetes 集群的，并会详细介绍集群管理系统核心组件的设计。
Kubernetes 集群管理系统需要具备便捷的集群生命周期管理能力，完成集群的创建、升级和工作节点的管理。在大规模场景下，集群变更的可控性直接关系到集群的稳定性，因此管理系统可监控、可灰度、可回滚的能力是系统设计的重点之一。除此之外，超大规模集群中，节点数量已经达到 10K 量级，节点硬件故障、组件异常等问题会常态出现。面向大规模集群的管理系统在设计之初就需要充分考虑这些异常场景，并能够从这些异常场景中自恢复。
当应用上线以后，运维面临的一大挑战是如何能够在不影响已上线业务的情况下进行升级。做过产品的同学都清楚，不管在发布前做过多么完备的自动化和人工测试，在发布后都会出现或多或少的故障。根据墨菲定律，可能会出错的版本发布一定会出错。
“ANYTHING THAN CAN GO WRONG WILL GO WRONG”
—— MURPHY’S LAW
因此我们不能寄希望于在线下测试时发现所有潜在故障。在无法百分百避免版本升级故障的情况下，需要通过一种方式进行可控的版本发布，把故障影响控制在可以接受的范围内，并可以快速回退。
可以通过灰度发布（又名金丝雀发布）来实现业务从老版本到新版本的平滑过渡，并避免升级过程中出现的问题对用户造成的影响。
集群中的应用服务器（节点）通常被设计成无状态，用户可以请求任何一个节点。
负载均衡器会根据集群中每个节点的负载情况，将用户请求转发到合适的节点上。
负载均衡器可以用来实现高可用以及伸缩性：
负载均衡器运行过程包含两个部分：
1、什么是LVS？
首先简单介绍一下LVS (Linux Virtual Server)到底是什么东西，其实它是一种集群(Cluster)技术，采用IP负载均衡技术和基于内容请求分发技术。调度器具有很好的吞吐率，将请求均衡地转移到不同的服务器上执行，且调度器自动屏蔽掉服务器的故障，从而将一组服务器构成一个高性能的、高可用的虚拟服务器。整个服务器集群的结构对客户是透明的，而且无需修改客户端和服务器端的程序。
为此，在设计时需要考虑系统的透明性、可伸缩性、高可用性和易管理性。一般来说，LVS集群采用三层结构，其体系结构如图所示：
LVS集群的体系结构
微服务是否银弹，如何实施，甚至是否使用微服务都是个问题，这里既要防止过度设计，又要充分考虑到人的因素。本文参考Linkflow运维开发负责人对其产品与项目交付上线过程的描述来看一看小团队是如何微服务化的。
微服务的好处是什么？
通常来说， Web应用一般是三层结构：Web Server====》 Application=====》 DB Server
主流的 Web server 一个巴掌就能数出来，Apache，Lighttpd，Nginx，IIS等。 Application,中文名叫做应用服务，就是你基于某个web framework写的应用代码；DB server 泛指存储服务，web开发中用mysql比较多，最近几年因为网站规模扩大，memcache，redis这种key-value等存储也流行开来。
放在最前面的web server有3个功能：
实际上，市面上有部分web framework由于内置了支持epoll/kqueue 等高效网络库，而具备了处理高并发的能力，比如说 python的tornado，java系的tomcat,jetty等等，有人就去掉前端的web server，直接裸奔，但是在部署公网应用时候，最好别这样做，因为前面提到的1,2两个原因，用户brower到web server的网络状况是千奇百怪，你无法想象的。
当我们开始推行敏捷时，还没有容器和 Kubernetes。但是它们改变了过去最困难的部分：将敏捷性从小团队应用到整个组织。
— Matt Hicks（作者）
负载均衡建立在现有网络结构之上，它提供了一种廉价有效透明的方法扩展网络设备和服务器的带宽、增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性。
负载均衡（LoadBalance）其意思就是分摊到多个操作单元上进行执行，例如Web服务器、FTP服务器、企业关键应用服务器和其它关键任务服务器等，从而共同完成工作任务。
2-1、一致性哈希与Key的选取
一致性Hash算法是现代系统架构中的最关键算法之一，在分布式计算系统、分布式存储系统、数据分析等众多领域中广泛应用。
Kubernetes自从2012年开源以来便以不可阻挡之势成为容器领域调度和编排的领头羊，Kubernetes是Google Borg系统的开源实现，于此对应Prometheus则是Google BorgMon的开源实现。Prometheus是由SoundCloud开发的开源监控报警系统和时序列数据库。从字面上理解，Prometheus由两个部分组成，一个是监控报警系统，另一个是自带的时序数据库（TSDB）。
2016年，由Google发起的Linux基金会旗下的原生云基金会（Cloud Native Computing Foundation）将Prometheus纳入其第二大开源项目。Prometheus在开源社区也十分活跃，在GitHub上拥有两万多Star，并且系统每隔一两周就会有一个小版本的更新。
数字化转型大潮中，常常说到DevOps，但是其并不是数字化转型所特有的。从一个高度及敏捷的研发团队的角度，其是必要的技术组成部分，甚至不在于是否用不用敏捷。并随着大数据的特有应用，衍生出DataOps；同时由于互联网相关应用等的大规模分布式的使用，及虚拟化、容器化等等的海量集群的应用，AIOps也被冠名了。
IDC即是Internet Data Center，是基于INTERNET网络，为集中式收集、存储、处理和发送数据的设备提供运行维护的设施基地并提供相关的服务。
IDC提供的主要业务包括主机托管(机位、机架)、资源出租(如虚拟主机业务、数据存储服务)、系统维护(系统配置、数据备份、故障排除服务)、管理服务(如带宽管理、流量分析、负载均衡、入侵检测、系统漏洞诊断)，以及其他支撑、运行服务等。
对于IDC的概念，目前还没有一个统一的标准，但从概念上可以将其理解为公共的商业化的Internet机房，同时它也是一种IT专业服务，是IT工业的重要基础设施。
让我们来一起回到过去：
这里只是列出来了几家大公司所涉及到的光缆被挖事故，其余还包括什么广电光缆被挖，社保局光缆被挖就不列了，感兴趣的自己去百度。
好，我们发现“公司再大，也怕施工队”，那么这种事故能怪施工队吗？个人觉得不能把责任都推给施工队，当然我们这里不讨论这些，我们做为大公司，我们以后怎么预防这种现象呢？
这个我们可以来看下支付宝的解决办法，毕竟它老人家在2015年就经历过这种惨况了。
2018年9月20日，杭州云栖大会ATEC主论坛现场上演了一场特别的技术秀。蚂蚁金服副CTO胡喜现场模拟挖断支付宝近一半服务器的光缆。结果只过了26秒，模拟环境中的支付宝就完全恢复了正常。
这种解决办法就是“三地五中心”，这是一种机房架构，即在三座城市部署五个机房，一旦其中一个或两个机房发生故障，依靠技术可以将故障城市的流量全部切换到运行正常的机房。
那么在“三地五中心”之前还存在很多其他架构，我们一一来看一下他们的特点。
矛盾是事物发展的源泉和动力。运维中的矛盾无处不在，既有来自业务与技术的矛盾，也有来自开发和运维的矛盾，还有来自数据中心内部的矛盾，解决这些矛盾只能靠发展。
数据中心的主要职责是安全生产，围绕着安全生产有三个目标：
当下Docker容器化的架构备受欢迎，越来越多的企业开始利用容器来构建自己的基础架构。通常是自己建立了Docker注册表，部署在服务器上安装Docker，安装Jenkins通过Docker插件Jenkins CI管道管理Docker容器。更大一点规模的则会使用K8S或者Swarm编排集群。对一个企业而言有开始尝试使用容器到逐渐深入，扩大规模要经历一系列的问题和踩坑的过程，那么如何规范化、安全的实施容器化，如何尽最大避免踩坑呢？本文虫虫给列出企业尝试容器化架构需要考虑的各方各面问题，希望可以对大家有所帮助。
Docker服务都需要一个注册表（可不是我们常说的windows注册表），Docker注册表是Docker镜像的存储和在线（Web）版本仓库（类似于代码的github仓库）。有很多公有云自有容器注册表服务，比如Docker官方的Docker Hub，很多公有云都提供自己Docker注册表服务：
除了这些公开的注册表，基于安全、网络访问速度、规范化等考虑企业维护一个自建的Docker注册表（Docker私服）也是必须的。构建Docker私服可以使用Docker官方的Distribution，它是Docker官方推出的Docker Registry 2开源产品，使用Golang开发，极大提高了安全和性能。
数据产品经理是让数据产生价值（决策、增长、收入）的设计者、实现者和推行者。如何理解这样的定位呢？
首先，最基础的是要熟悉数据工具平台与产品业务，其次，要学会逐步建立产品完整的数据指标体系，最后，是能够通过数据分析解读驱动业务发展。
具体拆解来看，主要包含：
（1）数据层面
（2）产品层面
根据基础数据体系，数据产品的工作基本上需要涵盖从数据源到最终数据应用、访问层的各个环节。做好产品上线前数据指标的统计埋点工作，以及产品上线后的版本分析，侧重点主要在于：数据应用层面（规划和设计项目核心指标，满足各业务方的数据需求）；数据访问层面（做好数据分析与解读，对上线数据进行监测以及效果分析）对数据源的处理、数据加工及数据仓库，本文暂不展开说明。
纵观我们部署在基础设施当中并始终保持运作的全部测量机制，监控系统无疑是重要性最高的机制之一，建立一套坚实的监控系统来针对可能发生的灾难加以警示，我们就有机会迅速启动灾难响应方案或者着手排除复杂的性能故障，这对于任何规模的企业而言都极具巨大的实际价值。
纵观国内，我们常使用的监测技术平台包括开源与商用运维两类（国外商用运维软件太贵，就不考虑了）
一、开源工具介绍
二、商用运维监控系统篇
这里不是讨论这些开源工具或者平台如何如何，这不是重点，这些都是非常成熟化的产品，更重要的是公司发展到一定程度之后，不但对IT运维提出更强需求，越来越多的是对业务监控的需求，以前了解过一些CAT，但很遗憾没有在公司推行起来，整理一下相关资料，也算是对这件事情有个交待。
最近终于有些闲暇的时间，便利用阿里云搭建了集群环境来准备做些Hadoop和K8S方面的验证与了解。在折腾了两天之后，终于全部安装启动成功，凌晨三点钟刚才睡醒便被阿里云邮的不断消息提醒给弄醒，睡意全无。我去，事隔多年之后，居然自己的Linux服务器被病毒感染了。于懊恼之中多了一点兴奋。随记记录下自己短暂的杀毒过程。
后来查阅资料才知道这是一款Linux和Windows通吃的病毒，起名为DDG挖矿病毒，目的是利用被侵入的计算机的资源协助自己挖矿，获取虚拟货币。本次服务器的感染是利用了Hadoop上Yarn的已知漏洞，同时加上.ssh免密登录的方便迅速地感染了自己的三台服务器。
下面就记述下病毒的发现、清理和认识过程，一路下来可以给我们的Linux命令学习提供很多知识点。这里面大部分操作都在生信宝典的Linux系列教程有提及，也是我们常用的提高效率的方式。
在微服务横行的时代，服务化思维逐渐成为了程序员的基本思维模式，但是，由于绝大部分项目只是一味地增加服务，并没有对其妥善管理，当接口出现问题时，很难从错综复杂的服务调用网络中找到问题根源，从而错失了止损的黄金时机。
而链路追踪的出现正是为了解决这种问题，它可以在复杂的服务调用中定位问题，还可以在新人加入后台团队之后，让其清楚地知道自己所负责的服务在哪一环。
除此之外，如果某个接口突然耗时增加，也不必再逐个服务查询耗时情况，我们可以直观地分析出服务的性能瓶颈，方便在流量激增的情况下精准合理地扩容。
链路追踪
“链路追踪”一词是在2010年提出的，当时谷歌发布了一篇Dapper论文，介绍了谷歌自研的分布式链路追踪的实现原理，还介绍了他们是怎么低成本实现对应用透明的。
前言
每当我们在生产环境服务器上执行rm命令时，总是提心吊胆的，因为一不小心执行了误删，然后就要准备跑路了，毕竟人不是机器，更何况机器也有bug，呵呵。
那么如果真的删除了不该删除的文件，比如数据库、日志或执行文件，该怎么解决？
模拟场景
1. 删除
误删除服务器目录/root/selenium/Spider下的MySql.Data.dll文件：
> rm -f /root/selenium/Spider/MySql.Data.dll > ll /root/selenium/Spider/MySql.Data.dll ls: cannot access /root/selenium/Spider/MySql.Data.dll: No such file or directory
K歌亭是唱吧的一条新业务线，旨在提供线下便捷的快餐式K歌方式，用户可以在一个电话亭大小的空间里完成K歌体验。K歌亭在客户端有VOD、微信和Web共三个交互入口，业务复杂度较高，如长连接池服务、用户系统服务、商户系统、增量更新服务、ERP等。对于服务端的稳定性要求也很高，因为K歌亭摆放地点不固定，很多场所的运营活动会造成突发流量。
为了快速开发上线，K歌亭项目最初采用的是传统的单体式架构，但是随着时间的推移，需求的迭代速度变得很快，代码冗余变多，经常会出现牵一发动全身的改动。重构不但会花费大量的时间，而且对运维和稳定性也会造成很大的压力；此外，代码的耦合度高，新人上手较困难，往往需要通读大量代码才不会踩进坑里。
鉴于上述弊端，我们决定接下来的版本里采用微服务的架构模型。从单体式结构转向微服务架构中会持续碰到服务边界划分的问题：比如，我们有user服务来提供用户的基础信息，那么用户的头像和图片等是应该单独划分为一个新的service更好还是应该合并到user服务里呢？如果服务的粒度划分的过粗，那就回到了单体式的老路；如果过细，那服务间调用的开销就变得不可忽视了，管理难度也会指数级增加。目前为止还没有一个可以称之为服务边界划分的标准，只能根据不同的业务系统加以调节，目前K歌亭拆分的大原则是当一块业务不依赖或极少依赖其它服务，有独立的业务语义，为超过2个的其他服务或客户端提供数据，那么它就应该被拆分成一个独立的服务模块。
在采用了微服务架构之后，我们就可以动态调节服务的资源分配从而应对压力、服务自治、可独立部署、服务间解耦。开发人员可以自由选择自己开发服务的语言和存储结构等，目前整体上使用PHP做基础的Web服务和接口层，使用Go语言来做长连接池等其他核心服务，服务间采用thrift来做RPC交互。
一、限流的作用
由于API接口无法控制调用方的行为，因此当遇到瞬时请求量激增时，会导致接口占用过多服务器资源，使得其他请求响应速度降低或是超时，更有甚者可能导致服务器宕机。
限流(Rate limiting)指对应用服务的请求进行限制，例如某一接口的请求限制为100个每秒,对超过限制的请求则进行快速失败或丢弃。
限流可以应对：
因此，对于公开的接口最好采取限流措施。
境内度假是一个低频、与节假日典型相关的业务，流量在节假日较平日会上涨五到十几倍，会给生产系统带来非常大的风险。因此，在2018年春节前，我们把整个境内度假业务接入了全链路压测，来系统性地评估容量和发现隐患，最终确保了春节期间系统的稳定。
在整个过程中，我们意识到，全链路压测在整个系统稳定性建设中占有核心重要的位置，也是最有效的方案。结合实际业务节假日的频率（基本平均一个月一次），如果能够把它作为稳定性保障的常规手段，我们的系统质量也能够得到很好的保障。同时，为了解决周期常态化压测过程中人力成本高、多个团队重复工作、压测安全不可控，风险高等痛点，我们提出了全链路压测自动化的设想。
通过对压测实施的具体动作做统一的梳理，在压测各个阶段推进标准化和自动化，尽力提升全流程的执行效率，最终达到常态化的目标，如下图1所示：
工程师主要面对的是技术挑战，更关注技术层面的目标。研发团队的管理者则会把实现项目成果和业务需求作为核心目标。实际项目中，研发团队所需资源（比如物理机器、内存、硬盘、网络带宽等）的成本，很容易被忽略，或者在很晚才考虑。
在一般情况下，如果要满足更多的技术指标如并发量和复杂度等，或者满足峰值业务的压力，最直接有效的方法就是投入更多的资源。然而，从全局来看，如果资源成本缺乏优化，最终会出现如下图所示的“边际效用递减”现象——技术能力的提升和资源的增幅并不匹配，甚至资源的膨胀速度会超过技术能力的提升，从而使技术项目本身的ROI大打折扣。
从笔者十余年的工作经验来看，资源成本优化宜早不宜迟。很多管理者在业务发展的较前期阶段，可能并没有意识到资源成本膨胀所带来的压力。等到业务到了一定规模，拿到机器账单的时候，惊呼“机器怎么这么费钱”，再想立即降低成本，可能已经错过了最佳时机，因为技术本身是一个相对长期的改造过程。