本文作者：AIOps智能运维
作者简介
Mason 百度资深研发工程师
负责百度智能运维（Noah）云监控平台的架构设计与研发工作,致力于推进监控能力在公有云及私有云场景落地。
0 1 写在前面
云发展速度快、成长空间大,
监控场景复杂
从2006年AWS正式拉开云计算商用大幕至今,云已经从概念普及进入广泛应用阶段, 云服务 成为水电一样的基础服务已成为行业共识。最新Gartner的报告预测到2019年 公有云市场 将达到2062亿美元,较2018年将会增长17.3%,然而这个规模依然只占全球范围内IT支出的5.4%（据Gartner预测,2019年全球IT支出将达到3.8万亿）。从这些数据可以看出,未来相当长一段时间,云计算业务还将继续处于快速发展阶段,并且有着巨大的增长空间。
随着云服务的快速发展,部署在云上的业务系统越来越多,规模也越来越大,与此同时针对云上业务 系统的监控 也就变得越来越重要。Gartner报告显示,尽管已经有39%的上云企业为其系统定制了监控解决方案,但整体上来说,监控系统的覆盖范围还有很多需要完善的地方,尤其是针对 混合云 业务场景的监控。
0 2 监控愿景
为客户提供完整的
云上系统监控解决方案
调研典型上云客户业务系统发现,中大型客户更倾向于将系统构建在混合云环境之上,并依赖公有云提供的计算、网络、存储等服务,来实现自身业务的 弹性 ,而小型客户则更多的直接将业务系统部署到云上,并且出于运维和研发成本的考虑依赖的云服务种类和数量越来越多。对于一个典型的云系统的监控来说,除了要关注云系统的模块架构组成外,还要关注其依赖的云服务,同时从业务价值的角度出发,还要关注服务的连通性和性能,当故障的时候,需要能够提供对应的手段去定位和分析产生问题的原因。
通过分析,可以得出云上客户对监控的需求如下： 支持云上服务监控 ,如云磁盘、对象存储、数据库、大数据等云服务监控； 支持跨云主机或与用户自建环境组成的混合云场景监控； 支持客户业务系统以及客户业务价值监控,支撑客户日常运维与运营行为； 预留 扩展能力 ,提供相应机制或开放API接口,供其它故障处理系统、变更管理系统感知监控目标的状态变化,并依此构建完整的运维体系。
0 3 实现思路
服务模型屏蔽差异
标准组件提升系统能力
01
构建服务模型屏蔽服务间模型差异
云由服务提供商提供的一系列计算、存储、AI应用类服务组成,每种服务的业务模型都不尽相同。如虚机、块存储的实例模型,数据库、缓存、容器服务的集群模型；语音识别、语音合成、人脸识别服务提供的API或API集合模型。构建在这些云服务资源之上的系统,由于业务场景不同,也会呈献出或繁或简的架构形态。为了应对 结构复杂 、 模型多变 的云上需求,提供可扩展、适应性强的监控能力,就需要定制出一套 标准的模型 出来,对上屏蔽不同云服务资源模型与客户业务系统资源模型的差异,对下支撑标准监控能力建设,这就是 服务管理模型 。服务模型要解决如下两个问题： 抽象实体模型特征 ,针对云服务资源或客户业务系统按功能、结构划分出来的具有一致性功能的实体； 刻画模型间关系 ,用于描述或定义不同类型的实体间层级或关联关系,支撑不同实体间指标数据计算。
02
围绕服务模型构建可伸缩监控能力
由于服务模型屏蔽掉了业务模型的差异,在监控能力建设方面,就可以围绕服务模型构建标准化的采集、计算、存储、异常检测、告警、可视化等能力。通过形式多样的采集手段实现监控对象指标的收集,再通过计算和模型间关系实现业务指标的转换,并将对应结果存储起来,供后续的异常检测分析与可视化使用。
0 4 产品目标
打造从云资源到客户业务系统到终端
用户价值的全栈监控产品
在标准化的监控能力建设完成之后,要做的是细分客户监控场景,并针对性的打造细分场景监控子产品。
用户在使用云系统的整个过程可以简化为上图所示模型。用户通过公共网络连接到服务,对应的用户请求通过入口服务完成转发,由具体的部署在容器、虚机或物理机上应用服务进程完成处理并返回给用户,当然在处理的过程中通常会涉及到不同应用服务进程间调用和对云服务资源的调用。根据监控的场景,将监控的场景细分为以下几个场景： 站点监控 ,监测客户服务的连通性与可用性,监测分布在不同地理位置或网络的用户的访问服务的状态和性能； 应用（系统）监控 ,监控应用或系统的资源使用情况及健康状态,通过进程、日志、脚本、Http、端口、语义等多种手段； 主机监控 ,监测应用进程运行的主机/容器等宿主环境的资源使用情况与健康状态； 云服务监控 ,监测云上业务系统依赖的云服务资源状态和性能； 业务监控 ,从业务价值的角度去分析对应变化以及追踪导致这些变化的可能诱因。
0 5 写在最后
扩展监控生态,护航云上业务
通过云监控提供的实时异常检测机制和可视化效果,不仅可以让客户对自身业务现状、以及支撑业务的系统状态了然于胸,还可以在问题发生时帮助客户快速定位故障,保障业务价值的连续稳定。同时,通过监控系统通过预留的接口可以方便的实现与外部自系统对接,与其它自动化系统共同构建监控运维生态,为云上客户业务系统的稳定保驾护航。
本文介绍了我们云上监控产品的愿景与设计思路,接下来,我们还会深入的介绍如何使用百度云上的监控、运维管理产品来定制构建自己的解决方案,敬请期待！
原文链接地址： https://developer.baidu.com/topic/show/290327
本文作者：AIOps智能运维
作者简介
运小军 百度云资深研发工程师
负责百度智能运维方向大规模日志处理、海量事件数据存储相关设计研发工作,在分布式系统架构、大数据存储计算、高性能网络服务和即时通讯服务有广泛实践经验。
干货概览
前文《面对海量事件数据,我来告诉你怎么办！》中我们介绍了百度线上业务运维场景下海量事件数据存储与计算平台EventDB的系统架构、集群规划及未来发展方向,本文将介绍我们在EventDB高可用方向 面临的问题、建设经验及后续计划 ,希望与业界同行一起交流学习。
问题
作为百度智能运维大数据核心存储平台,其可用性高低直接决定了上游业务系统可用性高低,我们建设可用性之初主要面临如下几个问题： 关键监控指标缺失： 导致无法准确掌握系统状况,排查问题困难； 流量缺乏管控： 一是终端用户直接使用ES API很容易造成接口误用；二是无法防御恶意请求和非预期流量洪峰； 数据规模持续增长： 导致原有存储模型无法满足系统性能和扩展性需要； 参数配置不合理： 默认配置参数没有按业务场景进行优化调整。
可用性建设
为了提升平台可用性,针对上述问题我们做了如下几方面工作：
1 完善监控体系
我们建立了 多层次 监控指标,从机器、容器(Container)、JVM、ElasticSearch内部指标再到业务监控指标,这些监控指标对及时了解系统运行状况、分析定位问题至关重要。 机器、容器： CPU/MEMORY/DISK/NET/FD/PROCESS JVM： Eden/Survivor/Old/Full GC/Young GC/Thread ElasticSearch： Queue/Cache/Search Context/Marvel 业务监控： PV/PVLOST/Response Time/主备数据一致性
其中ElasticSearch内部指标是通过API 实时提供 ,为了图形化展示这些指标并记录历史数据我们使用Marvel插件,Marvel插件通过定期调用ElasticSearch监控API提供更细粒度监控指标,能让我们看到基于每个索引（Index）的监控数据,这个功能在我们定位IO突增问题时发挥了重要作用。
2 统一调用接口
ElasticSearch自身提供了非常丰富的API,从数据操作到参数配置再到集群管理。如果把所有ES API都开放给终端用户会给平台带来非常大风险,一是我们无法预料用户行为,二是每个用户对ElasticSearch掌握程度不同,很容易造成误用。为了加强流量管理能力我们做了两方面工作： 一是由平台提供 统一数据操作API ,使用BigQuery API将所有存储、查询需求通过SQL来表达,用户通过SQL来操作数据,如果SQL有问题或恶意请求会被直接阻止掉； 二是对所有接口进行 配额限流管理 ,超出单位时间配额的请求会被拒绝访问。
3 优化存储模型
ElasticSearch数据存储模型由索引(Index)、类型(Type)、文档(Document)组成,分别对应关系型数据库中库(Database)、表(Table)、行(Row)。设计合理的存储模型不光能满足业务需求,还能极大提升系统 扩展性 和 读写性能 。
分库设计
数据规模小的情况下我们为了简便可以将数据都存放在一个库中,当数据规模越来越大,这种存储方式会带来两方面问题： 一是数据 难以管理维护 ,例如我们想把某类业务数据清理掉,无法通过直接删除索引的方式来清理数据； 二是 影响性能 ,任何读写请求都会影响索引中其他数据读写。
所以平台设计之初就需要我们 合理规划索引 ,一般的做法是按 业务和时间 两个维度来进行分库,不同的业务使用不同的索引,然后依据数据规模按天/月/年来创建索引。
合理设置分片
单个索引该设置几个分片？每个分片大小多少合适？这两个问题是我们在规划设计索引时必须要考虑的问题。 索引分片过小一方面导致ElasticSearch在内存中维护大量索引分片元信息,集群管理负荷增加进而引发 集群不稳定 ；另一方面ElasticSearch在查询时会扫描所有索引分片,分片过多会 影响查询性能 ； 索引分片过大将导致数据过于集中,读写操作在同一分片上的概率增加进而 影响操作性能 。
合理的做法是先 评估索引数据规模 ,按照单个分片不小于1G的原则来设置分片数,这样能避免产生大量小分片；另一个原则是要让分片在集群中 尽量均匀分布 ,实践经验就是分片数最好是数据节点数的1.5~3倍,这样能避免单个分片过大。
过期数据处理
数据价值会随着时间越来越低,任何一个存储系统都不可能永久无限制地保存所有历史数据,因为无论从成本投入、维护难度上都是得不偿失。所以针对不同业务场景我们需要制定清晰的历史数据清理策略,对于过期低价值数据进行 定期清理 ,这对保持集群稳定,提高资源利用率至关重要。
4 优化配置参数
下面这些参数都是我们认为比较重要的参数,在这里只说明其对系统的影响不作具体值建议,大家可以根据各自业务场景自行进行调整。
JVM参数 -Xms -Xmx： 设置Heap大小,建议不超过32G（JVM使用压缩指针用32位地址寻址32G空间）； -XX:+ExitOnOutOfMemoryError： 发生内存溢出时保证JVM进程及时退出,避免节点假死（JVM进程还在但无法正常提供服务） ； backlog： 已建立TCP连接处理队列长度,该队列满时会丢弃TCP连接并抛出Connection Reset异常。JVM默认50,建议适当增大应对流量洪峰。
Elasticsearch参数 index.number_of_shards： 索引分片数,需要依据数据规模来设置,在索引创建时设置,后期无法更改； index.number_of_replicas： 索引分片副本数,需要依据数据重要程度来设置,既能在索引创建时设置,也能后期通过API更改； index.refresh_interval： 内存中数据写入到磁盘间隔,该参数越小数据可查询延迟越小,可靠性越高但性能低；该参数越大数据可查询延迟越大,可靠性越低但性能高；默认1s,建议增大。
ElasticSearch作为高可用集群,单个节点挂掉并不会影响整个集群功能。当故障节点恢复时,为了避免恢复工作对集群造成太多影响（主要是避免过多的I/O消耗）,可以设置如下两个参数： cluster_concurrent_rebalance： 集群中允许多少个分片同时迁移重分配； node_concurrent_recoveries： 一个node上允许多少个分片同时恢复。
成果及计划
经过不懈努力, 事件数据存储平台已扩展到百量级的数据节点,日处理事件大小数百GB,可用性达99.999% 。用户涵盖业务报警、异常分析、根因定位、关联分析、日志追踪,已经成为百度智能运维大数据核心存储平台。
为应对数据规模、流量持续增长的压力,持续保持系统高可用性,我们计划做如下两方面的建设： 冷热数据分离 ： 建设冷热数据分离存储架构,一方面可以有效避免冷热数据互相影响,有效提升热数据读写性能；另一方面可以针对冷热数据进行存储介质优化,例如：使用SSD硬盘来保存热数据,使用SATA硬盘保存冷数据,既能提升读写效率又能降低存储成本；
ES版本升级： 新版本ES在稳定性、易用性、安全性及可维护性上都有很大提升,定期升级版本能避免很多不必要的维护工作。
原文链接地址： https://developer.baidu.com/topic/show/290326
本文作者：AIOps智能运维
作者简介
运小涵 百度云资深研发工程师
负责百度服务管理系统和监控平台架构研发工作。在分布式系统和大规模数据处理、可用性工程方向有广泛的实践经验。
干货概览
近日,百度云资深研发工程师董涵受邀出席由InfoQ主办的QCon北京2018全球软件开发大会,发表了“ 大数据实时计算和存储系统的高可用建设 ”的主题演讲。分享了百度监控后端服务在日均处理万亿级监控数据场景下, 保障服务可用性 方面的运维及开发经验,重点介绍了故障自愈、容量建设等内容,获得了参会人员的广泛关注。
Noah是 百度运维自动化平台 的统称,它涵盖了服务管理、监控、部署、任务调度等一系列产品和能力。而Noah的“眼睛”是 Argus监控系统 。经过多年发展,它已经成为一个功能覆盖全、性能强大的监控体系,它不仅支撑了百度内部所有核心业务的监控需求,还支撑了很多外部用户的运维基础设施建设,是服务高可用的基石。正因为此,监控系统本身的高可用架构建设,一直是运维技术的重中之重。
挑战：如何确保高可用性
如上图所示,百度监控系统具备 业务规模大 、 系统吞吐高 等特点,其自身可用性建设是一个持续性的工程,在服务发展的每个阶段,可用性工作的侧重点也各有不同。
在前期的可用性建设中,百度已经实现了服务的 弹性扩缩容 能力,并且系统已经具备 N+1冗余 ,实现了故障处理流程的自动化。
随着业务量的不断增大和接入用户量的增多,我们遇到了 突发流量过载 和 故障恢复效率低 的问题。一方面,我们支撑了百度数百个业务,每个业务每天都在做着大量的迭代更新,任何非预期的监控配置变化都可能造成监控系统的流量突增甚至过载。另一方面,随着各业务产品自身逐渐实现了故障自愈能力,监控系统已经成为了每个业务产品故障自愈效率的关键一环,这也就迫切需要监控系统自身,提高可用性和故障恢复效率。因此,我们将 容量管理 、 故障自愈 列为重点建设方向,以完善和加强百度监控系统的高可用能力。
容量数据建设：两个阶段
我们的容量数据经历了两个阶段：
最初我们依赖离线压测结果和人工修正,估算系统的负载情况。但这种方式的缺陷是显而易见的。
首先, 线上服务的部署依赖关系复杂、流量大、变动也很频繁 。离线压测一般投入资源很有限,是线上服务的缩水版。其测试结果很难准确反映线上服务的容量,也很难暴露线上大流量场景才能出现的一些问题。例如,某些临界区非法占用导致程序低概率崩溃的问题,属于低概率复现的bug。在线上大流量环境中才能出现。但对存储类应用的影响较大。可能造成反复重启的慢节点,进而影响系统容量。这种问题的提前暴露,对可用性保障有重要意义。
其次, 人工估算修正重度依赖工程师的经验 ,对于每个系统来说,一般只有某些高级开发和运维工程师才能估算出有效的数据。难以归纳为统一的方法并作为工程经验加以传承,是不可持续的。
经过前期的可用性建设,我们的服务都实现了N+1冗余能力,具备线上压测的条件。因此,我们引入了 线上压测 ,使用线上压测的系统服务数据,来作为容量数据。
我们的压测思路：在线上冗余集群, 接入实际线上流量和部分模拟的业务流量 。通过不断增加模拟业务流量,直到服务的核心指标,类似pv、pvlost、平响等指标开始出现异常,说明系统已达到服务能力上限。
这样做的好处是大部分流量是线上流量,更贴近实际线上场景。压测平台需要提供的流量也比较小,降低数据库类型下游处理数据污染的工作量。
我们已经基于这一组容量数据,实现了全局限流能力,可有效拦截全局流量突增造成的系统过载。
过载保护：两种限流方式
我们的服务包含了采集、计算、存储和查询等多个环节,每个环节都或多或少地会受到流量过载的影响。
最初给我们造成比较大影响的是 “查询”操作 的流量,因为监控系统本身就是一次写入、反复查询的业务场景。我们的服务端提供了thrift、http等多种查询接口,这些接口的流量直接受用户业务量和操作方式的影响。例如,用户会查询一个相当长时间范围的监控数据,通过脚本进行批量查询,或请求失败时的反复重试。这些都增加了请求量,给线上服务的稳定性造成了影响。
对于此类场景,我们一方面 优化系统性能 ,通过业务隔离、冷热数据分离、VM参数调优等方式,提升系统吞吐量。另外,我们也提供了 标准化SDK ,统一查询重试策略,增加退避重试、自动重选下游等逻辑。在保障成功率的同时,避免了不规范的用户操作对容量的影响。
当然,上述情况更多是能够规避预期内流量,但随着新业务的不断接入,经常由于配置错误、日志格式变化等造成数据采集端、汇聚计算侧数据量突增的情况。对于这部分流量,我们通过 限流 来解决,核心思想是基于统计信息,在数据流经过的各个环节,参考配额进行限流。
经过权衡实现成本和限流效果,我们选择了两种限流方式, 本地源端限流和全局通路限流 。
本地源端限流主要体现高时效性和低开销,覆盖单实例维度超限/流量超限场景。
全局通路限流可以覆盖全局超限场景,例如某个产品线整体的多维度组合超限。另外,它所有流量都要通过proxy转发,这种方式几乎可以在系统中的任意层次接入,不需要对系统中的模块进行改造。
故障自愈：如何缩短时间
在以前的故障中,由于监控系统本身的复杂度,我们的故障止损时间多在5min以上,最长的甚至达到十数分钟。长时间的故障,轻则造成业务失败率高、趋势图展示失败等,带来用户困扰；重则触发漏报警或误报警,无法让业务感知自身的线上故障,造成业务损失。
因此提升监控系统自身故障的 止损时效性 , 缩短故障时间 ,也是关键一环。
在故障感知层面,为了提升故障感知 召回率和时效性 。我们在系统中使用了多种指标组合,既包含系统监控、业务监控、网络监控,也包含SLI、服务、集群、实例多种维度的指标,同时使用智能异常检测技术,做到高准确和高时效。
另外,就是自愈逻辑,需要针对不同系统的业务特点进行适配。例如,对于存储系统,自动止损需要参考数据完备性指标,只有在数据是完整的情况下,才能将流量切入目标集群。
还有一些场景,受限于成本和业务特性,我们仅能给出降级止损方案。例如我们的事件数据库（EventDB）,由于某些原因,其备集群只保留了部分数据,无法承担全量查询。这种场景下,自愈系统就需要将流量尽可能倾向主集群,在主集群恢复可用状态时,第一时间将流量切回,避免长时间降级。我们通过给集群设置不同的权值实现了这个能力。
此外,我们的自愈操作会定期进行 演练和盲测 ,确保止损预案和自愈效果符合当前系统的设计,并能够满足业务需求。
当前我们的自愈能力已经覆盖了流式计算、时序数据库、事件数据库等核心子系统。上线以来,一共执行过数百次故障自愈操作, 故障召回率达到99%以上,MTTR小于2min ,有效满足了故障恢复效率优化的需求,并降低了运维工程师的人力投入。
总结
分布式系统的高可用设计是一个复杂的课题,我们会持续在架构容错升级、提升故障自愈能力和恢复效率等层面继续探索,将系统的可靠性做到最优。
原文链接地址： https://developer.baidu.com/topic/show/290324
本文作者：AIOps智能运维
作者简介
运小军 百度云资深研发工程师
负责百度智能运维方向大规模日志处理、海量事件数据存储相关设计研发工作,在分布式系统架构、大数据存储计算、高性能网络服务和即时通讯服务有广泛实践经验。
干货概览
百度线上业务运维场景下会产生海量数据,这些数据大体可分成两类：一类是 时序数据 ,例如：CPU、内存、磁盘、网络状态等数据,主要用于反映系统当前及历史运行状态；另一类是 事件数据 ,例如：报警、异常、上线、变更事件,主要用于记录发生事件的详细信息。
如何存储这些海量数据,并提供灵活高效的查询分析能力,一直是我们面临的主要挑战。基于这两种不同类型数据,我们提供了两种不同存储方案： TSDB 作为时序数据存储平台提供了多维度时序数据存储及按维度聚合计算查询能力； EventDB 作为事件存储平台提供了事件/日志数据（半结构、无结构）存储、查询、统计分析功能,是百度智能运维大数据平台核心组成部分,以其海量存储能力及灵活分析能力在故障定位、故障诊断、根因分析、关联分析中发挥着不可替代的作用。
本文主要介绍EventDB系统架构、集群规划以及未来发展方向,希望跟业界同行一起交流学习。
系统架构
EventDB是百度智能运维团队基于ElasticSearch构建的一套海量事件数据存储计算平台,整个平台由两部分组成： 流量接入层 、 存储计算层 ；通过分层将平台核心功能与辅助功能进行隔离,架构上更加便于功能扩展和维护。
流量接入层
一个高可用数据存储平台,需要 流量管控能力 , 单机房容灾能力 以及 流量统计分析能力 ,因此我们引入了统一流量接入层,统一流量接入层基于OpenResty开发,负责接收、转发所有请求和响应,主要包括如下几个部分：
流量管控
平台通过HTTP接口对外提供服务,为了保证平台稳定性和安全性,需要对非法请求进行拒绝,对流量异常突增进行限流,以及对访问接口进行规范统一,具体提供以下几个功能： 流量鉴权 ：每个接入业务方需要申请 访问Token ,只有带合法Token的请求才会被允许访问,能有效防止平台被乱用； 配额限流 ：基于Token分配流量配额,当业务访问流量超过最大配额,该业务后续请求将被拒绝,主要是防止平台被超额使用以及异常流量突增造成平台不稳定； 统一API ：对ElasticSearch提供原生API进行屏蔽封装,提供更加易用的API,降低使用成本和不规范操作带来的稳定性风险。
服务容灾
为了提升平台容灾能力,我们在存储层构建了主备集群,通过流量接入层提供的主备双写和流量快速切换能力,能达到单机房故障时对上层业务无损。 主备双写 ：对于写入请求支持自动主备双写； 流量切换 ：对于查询请求,支持自动主备切换,能根据关键指标异常快速切换查询流量到备集群,大幅降低故障恢复时间。
以上功能实现不需要业务接入方做任何特殊处理,所有处理对业务方完全透明。
流量分析
作为存储平台我们需要各种统计指标来衡量当前集群状态、流量分成、平响以及请求成功/失败率,而存储层无法提供这些指标,需要在流量接入层来实现。 流量统计分析 ：提供基于Token的 流量统计 、 平均响应时间 、 成功/失败请求 等指标统计。
存储计算层
作为最终事件数据存储计算引擎,我们选择使用ElasticSearch来满足海量数据存储及复杂统计分析需求,主要使用ElasticSearch如下功能： 海量存储： 支持TB级海量数据存储； 查询统计 ：支持基于属性、关键字模糊查询等多种查询方式； 分布式/水平扩展 ：支持将数据进行分片后存储到多个节点上,并支持水平扩展； 数据高可用 ：支持数据分片副本,同一个分片可以有多个副本保存到不同节点上。
平台架构图
集群规划
作为百度智能运维大数据核心存储平台,其 可用性 高低直接决定了上游业务系统可用性高低,为了保证高可用性,平台需要具备有效应对不同故障场景的能力：单机故障场景下,平台依赖ElasticSearch自身容错能力,自动移除故障节点并将故障节点上的数据迁移到其他节点；单机房故障场景下,我们通过 主备集群切换 来最大程度保证平台可用性。
双集群
我们建立了两套ElasticSearch集群作为 互备集群 ,由接入层负责主备双写并保证数据最终一致性。当一个集群发生故障,也是由接入层来负责查询流量切换,对终端用户而言就像使用一个集群。 主备双写 ：为了不影响写性能,我们采取同步写主集群异步写备集群的方式,主集群写入成功即代表写入成功,请求立即返回,无需等待备集群也写入成功； 主备一致性 ：上述主备双写策略会导致主备数据不一致,为了降低这种数据不一致对业务造成的影响,前期我们主要通过主备数据不一致监控来发现问题并通过工具来修复,后期我们通过程序进行备集群失败重试,重试多次依然失败的情况下会记录日志,然后程序会定期加载错误日志重试,保证主备数据最终一致性； 流量切换 ：为了降低平均故障恢复时间到达快速止损目的,平台会依据失败请求、平均响应时间等指标是否异常来判断集群是否发生故障,当连续几个决策周期都发现指标异常,会将查询流量自动切到备集群。
部署模式
单个ElasticSearch集群由如下三种不同功能节点构成： Coordinator Node ：协调节点,请求解析/转发,不存储数据； Master Node ：集群管理节点,维护集群节点信息,索引元信息； Data Node ：数据存储节点,处理读写请求。
该部署模式各节点职责清晰,非常便于有 针对性 地优化扩容：存储容量不足扩容Data Node,读写流量增长扩容Coordinator Node,Master Node只负责管理集群；这种部署模式也是ElasticSearch官方推荐的模式。
平台建设初期因为数据量和流量规模不大,我们ElasticSearch集群没有Coordinator Node,由Master Node充当Coordinator Node角色既负责整个集群的管理又负责解析转发用户的读写请求。随着数据量和访问量规模越来越大,Master Node压力越来越大,尤其是当集群中有节点重启时,因为涉及到分片再分配,整个过程耗时一个小时以上,后来调整部署模式加入Coordinator Node之后,Master Node压力骤减整个节点重启恢复耗时不到十分钟。
部署架构图
未来展望
当前我们主要使用ElasticSearch海量存储和简单查询功能,大部分计算分析工作是由各个业务端实现,其实ElasticSearch除了海量存储能力,其在 数值聚合计算 、 关联查询 、 模糊 匹配 方面都有非常好的支持,未来我们期望能更进一步挖掘ElasticSearch在计算分析上的潜力,将大数据存储和分析功能进行整合形成一套统一的大数据存储分析平台,对终端用户而言只需要通过接口表达需求就能直接获得分析结果。
原文链接地址： https://developer.baidu.com/topic/show/290325
本文作者：AIOps智能运维
作者简介
四金 百度高级研发工程师
负责百度智能运维（Noah）监控平台的设计和研发工作,在监控系统的配置管理方向有广泛实践经验。
干货概览
随着软件系统的发展,监控目标场景越来越广泛,对监控系统的能力要求也越来越高。对于监控系统来说,从能力上看基本可以划分为 数据采集、数据计算、数据存储、异常检测、报警处理以及监控可视化 六块。为了更好应对大规模、复杂化的监控业务场景,我们不仅仅需要在具体监控能力上做深、做强,还需要建立对应机制来统筹这些能力一起良好协作。今天的这篇文章就为大家介绍监控系统的神经中枢—— 配置管理与分发系统 ,让我们一起揭开它神秘的面纱吧!
需求
在业务系统发展的初期,由于场景简单,对监控的需求也比较简单,比如仅采集默认的机器监控数据,不需要进行进程、日志等监控能力。同时监控的规模也相对较小,用户的配置数量一般在百或千级别,这时只需定期读取数据库中的配置就可以很好的工作。
随着业务系统的快速发展,业务体量越来越大,业务复杂度越来越高,对监控的需求也越来越高。传统的简单读取数据库配置在 业务扩展性 和 性能 上遇到了挑战。
1 支持不同类型的配置管理
监控指标采集、计算、报警等方面的配置种类越来越多。如物理机的机器资源类指标、应用程序的进程和日志指标的采集配置、站点的连通性采集配置、服务器的宕机检测任务配置、多个实例间指标的计算任务配置、指标数据的异常检测配置、告警信息发送配置等。
2 支持不同场景的配置分发 高并发配置下载场景 ：监控系统中每个物理机部署一个Agent用于对部署在该机器上的应用程序相关指标进行采集。Agent需要下载与主机关联的采集配置,在大规模的监控系统中,Agent的数量达到百万级别,采集配置的更新周期为10s,配置分发系统需要应对高并发查询的压力。 一致性配置下载场景 ：为了应对高可用、大规模的数据计算及报警场景,各个子系统往往使用集群化部署。以报警集群为例,同一机器的数据可能会由报警集群的不同实例进行判断,若配置在集群内不一致,那么报警系统的行为就会变得不可预期。
3 支持故障快速恢复
配置分发系统作为监控的枢纽,关联的模块比较多,系统故障会影响采集、计算、报警子系统工作的正确性以及用户新加监控配置不生效,所以需要相应的方案来保障监控系统的快速恢复或重建能力,来保障监控系统的可用。
图1 配置管理&分发系统交互流程图
方案
梳理完问题、需求,接下来就要针对这些问题进行相应的改造升级。下面我们从技术的角度介绍下如何解决这些问题吧！
一、 支持配置可扩展性
复杂的监控能力意味着监控系统的 配置种类灵活多样 。如果直接将配置分发模型与业务模型对接,意味着业务上的每次改动都需要配置下发系统进行对应的变更。那么如何统一配置的多样性,做到配置下发对上层业务透明呢？答案是： 归类+抽象 。 将不同的配置按照“ 目录 ”进行分类管理,实现统一的配置管理需求。 以 文件 作为载体,所有配置都以文件的形式进行管理。不同的文件内容格式代表着不同类型的配置,原有格式的升级以及新类型的添加统一抽象为文件处理,增强了系统的扩展能力。 通过 代码管理 系统管理文件的方式,实现变更历史追踪。通过对文件系统的定时备份与构建快速故障恢复机制提升系统的可用性与可靠性。
图2 配置归类&抽象
在归类方面,由于不同的能力需要的配置形式不同,我们以此为依据进行分类。对应到实现中则通过目录表达分类的含义,通过子目录来表达配置的层级与归属等关系。这里我们将配置目录的层级分为监控功能层级->用户层级->应用层级三层,在应用目录下将具体配置（如进程监控配置、日志监控配置）写入文件中。
二、 确保一致下发
通过对配置管理方式的抽象与归类整理,配置的一致性下发可以通过构建配置文件内容的一致性机制解决。我们使用“ 版本 ”作为文件内容一致性机制的核心。当用户变更配置时,配置管理系统会生成一个全局唯一的版本描述此次配置变更操作,版本中包含此次变更操作对应的配置文件变更详情。
配置下发时,在各个子系统会定期检测配置版本差异并更新本地配置至最新版本,从而保证配置在每个更新周期内保持一致。
三、 应对高并发压力
大规模的压力则主要体现在采集Agent的配置下发部分。由于Agent只需拿到部署主机所需的监控配置,因此将配置文件按照监控的最小单元进行拆分,并按照规范进行打包。
图3 Agent配置拆分&下载流程
当前的业务部署往往采用 混布方式 ,同一主机中会部署多个不同类型的应用程序。为了支持这种监控场景,主机上部署的采集Agent会查找主机上部署的应用并下载对应的多个应用配置。当业务规模增大时,物理机增多,配置下载请求也会成倍增长,因配置存储的Server端很容易达到 性能瓶颈 。通过可水平扩展的静态文件下载服务来应对高并发下载压力,通过ETag方式检测文件是否变更,只针对变更的配置文件才进行传输以减少下载流量,最终满足了百万级主机、千万级实例的配置下发需求。
四、 故障快速恢复
考虑到配置在监控系统中的重要程度,为了保障业务的可用性,就需要构建监控系统的快速故障恢复机制。
同时,由于监控系统配置集中管理,随着系统的发展,配置的体积也在不断增长,配置文件体积达到数十GB级别,并且全部由小文件组成,文件个数也达到了数百万级别。为了减轻系统压力,在系统中加入“ 快照 ”机制,每隔一段时间便生成当前全量配置的快照,当出现大量更新时,先通过“快照”减少更新量,再通过对应同步机制进行少量的文件更新。
总 结
经过不断的努力和多次改造,目前的配置管理及分发可以满足监控系统的需求。由于能够灵活管理多种配置,并且快速、一致地送至各个系统。在面对故障场景时候,也可以及时撤回配置,避免更大的损失。然而随着监控业务的发展,系统架构的变迁,起着中枢作用的配置管理与分发系统将会面临新的挑战。路漫漫其修远兮,吾将上下而求索！
原文链接地址： https://developer.baidu.com/topic/show/290323
本文作者：AIOps智能运维
作者简介
张洋洋 百度高级研发工程师
负责百度智能运维产品（Noah）的分布式时序数据库和通用配额管理平台的设计研发工作,在分布式存储和配额管理方向有广泛的实践经验。
干货概览
通过百度大规模时序数据存储系列文章的介绍,想必读者对百度智能监控系统Noah的TSDB不再陌生,它主要用来存储Noah监控系统的 时序指标数据 ,包括但不限于硬件和软件的可用性指标、资源使用率指标和性能指标等。如《百度大规模时序数据存储（二）|存储选型及数据模型设计》文章所述, Noah-TSDB是基于HBase为底层存储的基础上自主研发的,其优秀的性能离不开HBase的贡献。今天主要聊聊在百度智能监控场景下的HBase相关实践经验,先简单介绍一下HBase。
HBase架构简介
HBase是一个基于Java、开源的、非关系型的、面向列存储的分布式可扩展的大数据存储数据库。HBase的集群主要由HMater和RegionServer两种角色组成,底层以HDFS作为存储设施,集群由Zookeeper协助管理。其架构如下图所示：
简单介绍一下HBase中相关组件的作用： HMaster
HMaster 是整个集群的 大脑 ,负责数据表的操作、集群的负载均衡和故障恢复等集群管理工作。 RegionServer
HBase 将表以行为单位划分成许多 片段 ,每个片段称为一个 Region。这些Region被分配到RegionServer进行管理。在读写流程中,定位到数据所在RegionServer后,Client与RegionServer直接交互进行数据的读写。 Zookeeper
HBase作为一个大规模的分布式系统,Zookeeper的作用是至关重要的。首先Zookeeper作为HMaster HA解决方案,保证了至少有一个HMaster处于工作状态。其次Zookeeper通过心跳机制探活RegionServer,当RegionServer故障时及时通知HMaster进行故障处理工作。最后Zookeeper保存了维护全局元信息的META表的路径,Client第一次与HBase集群交互时,需要通过META表来获取目标数据所在的RegionServer。
上面简单介绍了HBase的架构和各组件的基本信息,下面和大家分享一下在百度最大规模时序数据库的场景下使用HBase时遇到的几个典型问题和优化方案。
热点问题
大家都知道木桶效应,对于TSDB系统来说,热点Region所在的RegionServer就是影响整个”水桶”容量最短的那块木板。理想情况下HBase 中所有的请求应该均匀的分布在所有RgionServer的所有Region 上,当个别Region收到的读写请求数量大幅超过其它的Region,它所在的Region就有可能成为热点。
Noah-TSDB初期曾遇到监控元数据表设计不合理导致热点的问题。当时研发同学收到Noah-TSDB 写入模块队列堵塞 的业务报警,从Noah监控系统上看到同时间段访问HBase异常明显增长。HBase中的个别RegionServer频繁进行GC,网络 I/O 和磁盘 I/O 密集,操作队列中待执行的请求堆积严重,负载明显高于其它的RegionServer。查看异常RegionServer的日志发现大量请求访问的是同一个Region：”tsdb-meta,*** 1.”。初步定位是由于该Region 负载过高 ,导致它所在的RegionServer成为热点,进而导致系统的吞吐量下降,上游写入模块请求堆积。
tsdb-meta是用来存储监控指标的名称、周期等元信息的表,表中红色填充的行代表其拥有数据量超过正常水平的,表结构如下：
分析上面的存储结构,我们可以知道： 同一个监控对象（namespace）的监控指标元信息将会存储在 HBase 表的同一行。 不同监控对象的指标数量不同,将导致行的大小不均匀。 HBase中数据分片是以行为单位,每行的数据存储在同一个Region中,当某一行存储的监控指标数量远大于正常水平时,该行就有可能成为热点。
综上所述,当个别监控对象拥有的 监控指标个数过多 时,tsdb-meta可能会出现热点问题。同时经我们验证发现,成为热点的监控对象拥有的监控指标的数量大约是正常水平的20倍左右,进一步确认了故障原因。
定位到根因后,我们决定从两个方面来着手解决这个问题。一方面, 定期统计监控对象拥有的指标个数 ,及时发现由于监控配置异常和不合理使用导致的个别监控对象拥有的监控指标过多的问题。第二方面,对tsdb-meta表结构改造,将原来按列分布的数据修改为 按行展开平铺 ,充分打平数据,利用HBase按行自动分片的机制来达到负载均衡的状态。第一方面主要是从业务层面对不合理使用的情况进行人工干预。今天主要着重介绍第二方面。 tsdb-meta表Schema改造
前文大体介绍了表结构改造的思路,避免单行数据过大导致热点问题。我们将监控对象和监控指标的名称信息一起作为行键,只保留一列用于存储指标的其余信息,避免了因单行数据过大导致的热点问题。
预分区
tsdb-meta表优化后,我们发现生产环境存储数据的 tsdb-data表也存在热点问题。tsdb-data是用来存储监控指标数值的表,生产环境是按时间跨度进行分表,每两天的数据存储在一张表中。数据的行键由数据hash后的特征变量ts_uid和时间基准timestamp_base组成,利用HBase存储时按行键的字典顺序排序的特点,将不同的监控指标的数据散列到不同的Region,相同监控对象的指标数据顺序排列,达到优化查询的效果。由于tsdb-data表的日常访问量基数较大,当某个监控对象拥有的指标数量高于平均水平,那么该监控对象的监控指标很大概率会被分配到相同的Region,导致该Region过大,进成为热点,集群会分裂过大的Region来维持负载均衡的状态。频繁的分裂操作会占用大量资源,影响RegionServer的吞吐量。为解决因Region过大导致的热点,我们采用了 对数据表进行预分区 的方法。
在对tsdb-data表进行预分区时,我们发现只通过指定Region数量来实现预分区的效果并不理想,因为会出现实际写入量与槽位分配不均的问题。HBase数据表是按照行键的字节空间均匀划分而不是按照实际存储的数据量进行划分。如下图所示,图中红色方块代表实际存储的数据,白色的方块代表无实际数据的行。
如上图,虽然数据表已经按照行键的字节空间划分成3个Region了,但是明显Region 3中实际存储的数据量远大于Region 1和Region 2。这种情况下Region 3有成为热点的可能性。为了改善这种情况,Noah-TSDB结合了生产环境中的tsdb-data表按等间隔时间跨度分表的特点,决定参照历史表的使用情况对新表进行预分区。根据生产环境实际产生的行键和预期的分区大小计算出Region分界值,然后根据分界值将表划分成实际水位相近的Region,这样虽然每个Region的槽位大小不一样,但是每个Region实际存储的数量是相当的,进一步降低产生热点的风险。
如何合理的设置Region数量
在前文介绍的预分区策略中,除了需要参考生产环境的实际使用情况外还需要根据机器资源和分裂阈值等系统参数来预估合适的Region大小,Region大小确定后,我们可以预估出整体的Region数量。那么如何判断当前集群是否能够承载调整后的Region数量呢？如果Region的 数量不合理 有哪些危害呢？在讨论Region数量对集群的影响之前,我们先了解一些基础知识： 在HBase的数据写入流程中,数据是先写到Memstore（写缓存）排序,然后异步Flush追加到HFile中。一个Region中的多个列族对应多个Memstore,Memstore Flush的最小单位是Region。 当一个RegionServer中所有Memstore的大小总和达到阈值hbase.regionserver.global.memstore.upperLimit * hbase_heapsize会触发Memstore Flush。根据 Memstore从大到小依次Flush,直至MemStore内存使用量低于阈值 hbase_heapsize * hbase.regionserver.global.memstore.lowerLimit。 HBase 会定期Flush Memstore来保障Memstore不会长时间没有持久化。为避免所有的MemStore在同一时间都进行Flush导致的问题,定期的Flush操作有随机延时。
综上可知,一方面由于同一个RegionServer共享Memstore,Region数量过多会导致Memstore Flush的频率变快,产生的HFile变多,HBase持续的进行 Compaction,引发 合并风暴 。另一方面由于HBase定期Flush Memstore,每次执行 Flush需要将每个Region的每个列族对应的Memstore写入文件并存到HDFS, Region数量越多,每次需要一起处理的文件数量就越大,即使存在随机时延机制,短时间内文件的创建和数据的迁移较多也会加大集群负载,可能引起快照超时、客户端超时和批量加载超时,降低TSDB系统性能。因此Region数量过多会降低系统吞吐量。
Region数量过少也会 降低系统性能 。当数据量不变的情况下,由于Region数量过少导致单个Region过大,每个Region处理的写入请求数偏高,当Flush的速度慢慢被写入速度追上并赶超时,就会堵塞写入,影响RPC,进而影响HBase的整体写入和查询,降低系统的吞吐量。
Region数量设置不合理,会降低TSDB系统整体性能与可靠性,一般推荐的单个RegionServer管理的Region数量计算方法如下：
#{Region} = (RS memory)*(total memstore fraction)/((memstore size)*(# {column families}))
举个例子,如果RegionServer的参数如下： Java Heap Size of HBase RegionServer in Bytes设置的是20G hbase.regionserver.global.memstore.upperLimit是0.4 hbase.hregion.memstore.flush.size是128M 多个表的列族个数共2个
那么 #{Region} = 20 * 1024 * 0.4/ (128 * 2) = 32。这个公式是在假设所有的Region都在以相同的速率写的前提下,如果实际只有部分Region在写入数据,结果可以根据比例、结合业务进行调整。例如Noah-TSDB的场景下,数据是按照时间分表,一般两天的数据存在一张数据表中,数据的写入都集中在最近的一张表,因此实际写入活跃的Region数量远小于Region的总数量,所以实际每个RegionServer管理的Region的数量大约是通过上述公式直接计算结果的3倍左右。
预估出整体的Region数量和单个RegionServer管理的Region数量后,就可以合理的进行 容量规划 ,在集群调整的时候预估需要的机器资源。
总 结
上面就是今天介绍的全部内容了,给大家简单分享了一些使用HBase的实践经验。其实在实际使用时我们也发现了HBase过重,运维成本较高等问题,也在持续的进行调研和架构升级,大家有什么好的建议欢迎不吝赐教。另外文中如果有理解不到位或者偏差的地方,欢迎大家指正。
阅读推荐
原文链接地址： https://developer.baidu.com/topic/show/290322
本文作者：AIOps智能运维
作者简介
运小尧 百度高级研发工程师
负责百度运维大数据存储平台的设计和研发,致力于追求大规模存储系统的高性能和高可用。
万亿架构设计
在百度监控系统 TSDB 的常态工作负载下,单机每秒处理 20 多万 数据点,集群每秒处理 数万次 查询,每天有 几万亿 的数据点在 TSDB 中穿梭,这样强悍的性能除了得益于 HBase 本身的性能优势外, 架构层面 的针对性设计同样功不可没。
面对已是万亿级别却仍持续增长的数据规模,我们设计了读/写分离且无状态的 “弹性”架构 ；为了在高负载下仍保证低延迟的写入和查询,我们将数据进行 分层 ,分别存入 Redis、HBase 和 Hadoop；为了不间断地为业务提供可靠的服务,我们设计了具备 分钟级自愈能力 的 异地冗余 架构；为了节约存储成本,我们引入并改进了 Facebook 的时序数据 压缩算法 。
TSDB 的整体架构如图 1 所示。
图1 TSDB 整体架构
可扩展
我们希望通过简单地 增加节点 就使系统的处理能力线性提升,如果节点之间完全对等、互不影响,那么对整个集群而言,增加节点没有额外的资源消耗,就可以使处理能力随着节点数 线性增长 。
根据时序数据 写多读少 的特点,我们将读、写操作分离,设计了无状态的查询模块 Query-engine 和写模块 Saver,使得 Query-engine 或 Saver 的每个实例完全对等,并在上游应用轮询或者一致性哈希进行 负载均衡 。
实例的部署是基于百度内部的容器方案 Matrix ,一则可以合理地分配资源,二则由于写入和查询隔离开来、互不干扰,其各自的性能均得到充分发挥。基于 Matrix 的虚拟化方案也使 TSDB 能够在分钟级完成任意数量的实例扩容。
高性能
在 上一篇文章 中介绍的“水平分表”的策略(图 2)中,存在 HBase 里的数据被按时间划分到了不同的 Slice,老的 Slice 访问压力相对较小,减轻了系统处理这部分数据的负载,然而最新的一个 Slice 仍然会保持很高的热度,相对集中的负载仍然给 HBase 集群带来不小的压力。因此,我们利用内存缓存了部分 热点数据 (查询量相对更多的数据),以空间换取更低的查询响应时间,同时 分流 HBase 的查询压力。
图2 按时间水平分表
缓存能力由百度运维部 DBA 团队的 BDRP 平台提供。但由于数据量太大,缓存一小时的数据需要较多的内存资源,我们在性能和成本之间做了权衡,选择只将 核心指标 数据写入缓存。
在大批量查询历史数据的场景中,查询的频率不高,对数据时效性的要求也较低,其目标数据通常是 冷数据 ,因此我们把这部分数据从 Saver 的流量中复制出来,定期地灌入独立的 Hadoop 集群,将此类查询压力从 HBase 分流出去。
经过 Hadoop 和 Redis 的查询分流,HBase 仍然存储全量的数据,但其只承接常规的趋势图查询请求以及从缓存穿透的请求。
低成本
为了降低数据的 存储成本 ,我们引入了 Facebook 在论文《Gorilla: A Fast, Scalable, In-Memory Time Series Database》中介绍的一种时序数据压缩算法（见图 3）,它能够达到 10 倍的压缩比,我们将其进行改造后应用到了缓存中。
图3 Facebook Gorilla 中的压缩算法示意图
Gorilla 中的压缩算法较容易理解,其核心思想是 增量压缩 ,不仅针对数据点取值进行压缩,且对时间戳应用了一种 Delta-of-Delta 压缩方法。经过压缩的数据点,其存储空间占用可以“bit”计,算法对于周期稳定、取值变化幅度较小的数据的压缩效果尤其好。
然而,这种增量压缩的算法中,后一个数据点的压缩结果依赖前一个数据点的压缩结果,这要求在集群中为每个时间序列维护压缩的状态,论文未对其分布式实现做详细的介绍,我们将数据压缩成 Byte 流 ,以 Key-Value 的方式存储在 Redis 中。此外,论文中的算法仅支持浮点型数值,而我们改造后的算法还支持整数型和统计型数值（即上文提到的 StatisticsValue,每一个具有 max、min、sum、count 四个统计值）。
数据压缩的整体方案在实际使用中为我们节省了 80% 的存储空间,额外的 CPU 消耗不超过 10%。
高可用
冗余是高可用的一大法宝,我们使用了简单有效的 异地互备 的方案,即冗余出一整套集群和数据来实现高可用。写入时,客户端将数据 双写 到两个集群,查询时通过动态路由表或百度名字服务（Baidu Naming Service, BNS）访问到其中一个集群（图 4）,在此基础上我们具备故障自愈机制,可以实现分钟级的单机房故障自愈。
图4 异地互备
总结
近年来,TSDB 在智慧城市、物联网和车联网等等领域都有着十分广泛的应用,更是成为监控场景的标配基础服务。在 《百度大规模时序数据存储》 系列的四篇文章中,我们为读者介绍了大规模 TSDB 从模型到功能再到架构的设计实践,但从实际的需求出发,我们认为 TSDB 的架构设计思路和功能侧重点并不局限于文中所述。
技术上,在大规模的时序数据存储系统中,我们选择了 HBase 作为底层存储,但并不代表 HBase 在任何场景下都是最合适的选择。在应用上,TSDB 也会与分布式计算、数据挖掘、异常检测甚至 AI 技术进行深度结合,将会面临更加复杂和富有挑战的场景。
我们设想将 TSDB 抽象成各种 功能组件 ,能够根据不同场景的特点,灵活地搭配各个功能组件,以满足不同的需求。例如在数据量级较小的时候可以基于 MySQL 进行单机存储；或者作为缓存层直接基于内存存储；或者利用 Elasticsearch 的强大检索能力做多维度聚合分析等等。
目前我们已经进行了一些 组件化 的工作,并在这些工作的基础上实现了对 Cassandra 的支持,后续还将丰富框架和组件,引入新的功能,并逐步实现对 Elasticsearch、MySQL 等存储系统的支持。
限于篇幅,系列文章并未在细节处展开探讨,对于有兴趣参与到 TSDB甚至是其它大规模分布式系统的研发同学,欢迎加入我们。
若您有任何疑问或想进一步了解 百度大规模时序数据存储 问题,欢迎给我们留言！
原文链接地址： https://developer.baidu.com/topic/show/290321
本文作者：AIOps智能运维
作者简介
运小尧 百度高级研发工程师
负责百度运维大数据存储平台的设计和研发,致力于追求大规模存储系统的高性能和高可用。
干货概览
阅读了前面的文章,想必读者对百度大规模 TSDB 的使用场景和技术选型有了基本的了解,本文将着重介绍在 TSDB 中起了重要作用的两个 核心功能 的设计。
一 简介
基本功能方面,我们的 TSDB 在数据的收集上提供了 HTTP、Thrift 等 API；对查询,除了提供 API 之外还提供了命令行工具（CLI Tool）,这些基本功能的设计在不同的 TSDB 中大同小异,因此本文不再赘述。
由于数据规模庞大且出于业务数据隔离和定期清理的需要,我们设计了 分库分表 功能；为了提升历史数据存储和查询效率,同时节省存储成本,我们又设计了 多级降采样 功能。这些针对性的功能设计为支撑万亿级数据写入和高并发查询打下了坚实基础。
二 分库分表
谈及大规模数据库的性能优化,分库分表是一个绕不开的思路,设计得当可以大幅缓解数据库的压力和性能瓶颈,那么分库分表能帮我们解决什么问题？如何解决？
回顾前文提及的挑战,我们的系统需要满足业务数据需要隔离 保存策略 的个性化需求,在单表结构中实现这样的需求相对复杂,维护成本也较高。通过“垂直分库”,可以将不同业务的数据存储在不同的数据库中,每个数据库可以应用不同的数据保存策略（图 1）。
图1 垂直分库
另一方面,由于数据规模增长迅速,单表结构使得在 HBase 执行 Compaction 时会产生可观的 I/O 负载 ,以至于拖累整个系统的性能。通过“水平分表”,按照某种规则将原本较大的数据表中的数据划分到相同结构的较小的表中,如图2,可以一定程度上减小 Compaction 时的 I/O 负载。
图2 水平分表
1 基于HBase的“垂直分库”
在监控系统中我们使用“Product”这个字段作为业务的 唯一标识 （“Product”相当于租户）,并为不同的“Product”建立逻辑上的“Database”,每一个“Database”包含一套 TSDB 所需的完整的表（包含前文提到的数据表和维度索引表）,见图 3。之所以从逻辑上建立数据库的概念,是为了同具体的存储实现解耦,以便在不同的底层存储系统上都能够实现这个机制。
在 HBase 0.9x 版本中尚没有类似“Database”的概念,可以通过约定表的命名规则来实现,比如以前缀来标识不同的“Database”的数据表 ${Product}-data,在数据写入 HBase 之前,根据“Product”字段拼接出对应的表名即可：
图3 按产品线分库
为不同分库对应的数据表设置不同的 TTL,便实现了差异化的数据保存策略。
2 基于HBase的“水平分表”
根据监控时序数据按 时间顺序 以 稳定频率 产生的特点可以知道,相同长度的时间内产生的数据量是近似相等的,据此我们能够轻易地将数据按照时间相对均匀地划分到不同的 时间窗口 内。随着时间的推移,旧的时间窗口内的数据表逐渐被“冷落”,不再承载写入请求,只承载较低频率的访问请求,新的时间窗口内数据表将接力顶替（图 4）。
图4 按时间分表
分表只在某个“Database”内部进行,且只对数据表有效。每个分表是一个“Slice”,同分库一样,在 HBase 中按时间分表也可以通过约定表的 命名规则 来实现,我们以表内数据的起始时间 startTime 作为表名后缀 ${Product}-data-${startTime},相邻分表之间的 startTime 间隔固定的长度,比如 86400 秒（1 天）： Database1: Slice1: product1-data-1510000000 Slice2: product1-data-1510086400 ... Database2: Slice1: product2-data-1510000000 Slice2: product2-data-1510086400 ...
“水平分表”带来的另外一个好处是可以方便地实现 数据批量清除 （即 TTL 的功能）,假如某个“Database”的数据保存一年,那么到期时可以根据 startTime 直接删除其中一年以前的 Slice,干净利落。
三 多级降采样
业务对于监控数据的使用需求多种多样,有查最新数据的异常告警,也有查看一整年指标数据的趋势图展示,数据量越大查询耗时就越久,如果放在浏览器端处理也要耗费大量的内存。这不但对系统造成了很大的压力,也给用户带来了难以忍受的查询体验。鉴于此,我们引入了多级的降采样机制来应对 不同跨度 的数据查询。
降采样（Downsampling）在此是指对时序数据进行降频,将原本较细粒度的数据降频后得到较粗粒度的数据。这样一来可以成倍减少数据规模,使得粗粒度的数据能够以更小的成本保存更长时间。
降采样后的数据点只保留原始数据的一些 统计特征 ,我们保留了四个统计特征,由四个统计特征取值共同构成一个统计值 StatisticsValue
* max ：采样周期内样本值的最大值
* min ：采样周期内样本值的最小值
* sum ：采样周期内样本值的和值
* count ：采样周期内样本数
可见降采样会造成 原始数据失真 ,而不同场景对数据失真的容忍程度不同,在查询一年趋势的场景下,数据只需要大致的趋势正确即可；但在异常检测等一些场景中,则需要细粒度的原始数据来提供更多的信息。
1 预降采样（Pre-downsampling）
预降采样是在数据写入之前就按照预定的周期（Cycle）对其进行降采样,采样后的数据与原始数据同时保留。
在预降采样时将采样固定分为两个 等级 ,包括 Level 1 降采样和 Level 2 降采样,每一级将上一级的数据按照更大的周期求出一个统计值（图 5）。
图5 两级预降采样
预降采样与数据写入并行进行,降采样后的数据定期写入对应表中,不同级别的采样表使用不同粒度的分表策略,表的数据保存时长（TTL）随着降采样级别递增,见图 5（略去了分表的细节）（图 6）。
图6 原始数据表与不同级别的降采样表
2
后降采样（Post-downsampling）
后降采样则是指在查询数据时,实时地根据用户指定的 查询周期 （Period）对查询结果数据进行降采样,与预降采样原理类似且更为灵活,可以按照任意周期进行降采样,但后降采样的结果不会被写回存储。
后降采样通常与预降采样配合使用,可以高效地完成一些原本困难的查询任务。例如,在查询一年的数据趋势图时,可以直接拉取 Level 2 降采样的数据,使得查询结果的数据量级降低数百倍,查询的响应时间也成倍地减少。
总结
本篇为大家介绍了我们 TSDB 中两个重要的功能：分库分表和多级降采样,这使我们从功能的设计上消除了在大规模场景下系统遇到的一些性能瓶颈。在下一篇文章中,我们将介绍 TSDB 在 架构层面 如何设计,以提升系统的性能和保障系统可用性。敬请期待~~
若您有任何疑问或想进一步了解 百度大规模时序数据存储 问题,欢迎给我们留言！
原文链接地址： https://developer.baidu.com/topic/show/290320
本文作者：AIOps智能运维
作者简介
运小尧 百度高级研发工程师
负责百度运维大数据存储平台的设计和研发,致力于追求大规模存储系统的高性能和高可用。
干货概览
在 百度大规模时序数据存储（一）| 监控场景的时序数据 文章中,我们简要地介绍了百度监控场景时序数据的特点,且分析了在每天 万亿级 的数据规模下,时序数据的存储所面临着的诸多挑战。本篇将介绍 TSDB 在 方案选型 和 存储模型 设计上的实践。
一 简介
TSDB （Time Series Database,时间序列数据库）是一种日趋流行的数据库,从 DB-Engines 提供的最近一年各类数据库流行趋势来看,最近一年TSDB 的增长势头强劲,远超其它类型的数据库。
图1 数据库分类流行趋势
二 底层存储选型
为了更好地适应业务需求,我们选择自研 TSDB,由于时序数据的规模很大,我们在底层存储的选型上需要慎重考量。在 百万级 指标的规模下,用 MySQL 来实现就可以满足需求,如开源监控系统 Zabbix 的底层存储方案。
随着业务的快速发展,我们的数据规模也从百万级涨到了千万级以至于现在的 万亿级 ,此时传统关系型数据库愈显乏力。我们尝试过的一些集群方案在读/写延迟上并没有显著的提升,其扩展能力也只是差强人意,这迫使我们寻求新的方案。
重新审视我们对存储系统的核心需求： 高吞吐、低延迟、可扩展 。对于监控场景来说,关系型数据库的强一致模型、事务机制以及联合查询等强项并不是我们关注的重点,单个数据点的丢失并不影响监控指标的整体趋势,数据的偶发延迟也可以接受。
近两年开源的 TSDB 项目不断涌现（见图 2）,许多优秀的项目也成为我们调研和学习的对象,我们发现这些项目在底层存储的选型上各有偏好,这里列举一些： OpenTSDB ：著名的老牌 TSDB,底层存储最初只支持 HBase,后来增加了对 Cassandra 的支持 InfluxDB ：基于自研的 TSM 存储引擎,集群方案未开源 KairosDB ：发源于 OpenTSDB,早期底层选用 HBase,目前主打使用 Cassandra,还支持H2（用于非生产环境） Prometheus ：Google 监控系统 Borgmon 的开源版本,基于 LevelDB和本地存储
图2 TSDB排名变化趋势
然而无论是 HBase、Cassandra、LevelDB 还是 InfluxDB 的 TSM 存储引擎,他们的一个重要共同点就是都基于 LSM-tree 实现（Log-Strutured Merge-tree,日志结构合并树）。如图 3 所示,LSM-tree 这种树形结构可以像打印日志一般,以追加的方式顺序写入数据,并且不断地将较小的数据块合并成更大的块,最终将数据批量地刷写到磁盘。
图3 LSM-tree
使用 LSM-tree 有什么实际的意义？在上一篇文章中我们提到,监控数据的写入量非常大（每秒数千万数据点）,存储时长最长可达数年,从成本角度考虑,廉价的磁盘自然是合适的选择。然而,磁盘的机械结构使得其随机 I/O 性能在面对每秒数千万的写入请求时显得力不从心。LSM-tree正是能够借助内存缓冲将大量的随机写入转化成 批量的顺序写入 ,使得最终磁盘承载的写入次数对数级减少,极大地 提升了写入吞吐量 。
综合来看, NoSQL 数据库 是更合适的选择。在诸多 NoSQL 数据库中,我们选择了基于 LSM 实现的 HBase ,主要出于如下考虑： 高吞吐、低延迟,满足读/写性能需求 数据存储在 HDFS,支持多副本冗余,满足可靠性需求 表格存储,模型简单、业务开发较为方便 支持横向扩展,可线性扩容,能够适应业务增长 成熟的代码、活跃的社区和广泛的应用案例 三 基于HBase的存储设计
HBase Table 中的数据按照 RowKey 的字典序排列,在行的方向上数据可以分布到多个 HRegion中,而 HRegion 可以分布在不同的节点上,因此只要能够使数据均匀地分布在 HRegion 中,就可以实现存储的负载均衡。
图4 HRegion的分布
容易看出,RowKey 的设计是负载均衡的关键。如果 RowKey 设计不好,就容易形成热点HRegion,导致其所在节点负载过重,进而集群的整体性能下降。
接下来重点介绍 TSDB 中最关键的两张表的设计：数据表和维度索引表。前者支撑了所有时序数据的存储和查询,后者是多维度聚合查询的基础。 1 数据表
前文介绍过,监控时间序列构成如下：
时间序列 = 监控对象 + 标签列表 + 监控项 + 数据点
为方便讲解,换一种形式表述：
ts = (object + tags) + metric + [(timestamp, value), (timestamp, value), ...]
可见,由 object + tags + metric + timestamp 可以唯一定位一个数据点的取值。为了充分利用HBase 的特性,我们借鉴了 OpenTSDB 的做法,将 RowKey 设计如下：
RowKey = entity_id + metric_id + timebase
entity_id 是由 object 和 tags 的经过 hash 得到的一个固定长度的值,hash 后原始字符串的自然顺序被打乱,使得 RowKey 能够相对均匀地分布在不同 HRegion 中。
metric_id 为 metric 的字符串 hash 值,同样是固定长度。
timebase 为 Unix 时间戳按照 1 小时（3600 秒）取整得到的数值,固定 4 个字节的长度
这样的设计有如下好处： entity_id 和 metric_id 的散列使得数据相对均匀分布 timebase 置于 RowKey 的字节低位,使得同一个时间序列数据的 RowKey 连续分布,可以高效地按时间进行范围扫描 固定长度的 RowKey 减少了空间浪费,同时前缀式的设计可以充分利用 HBase 的前缀压缩机制,进一步节省 RowKey 所占空间
RowKey 代表的行包含 1 小时的数据,行中数据点按照当前时间在 1 小时内的偏移量进行存储,最终的表结构示意如表 1：
表1 数据表 RowKey 设计
2
维度索引表
在数据表的设计中,tags 被编码进固定长度的 entity_id 中,同时 HBase 并没有对索引的原生支持,这导致无法通过 tag 找到对应的 entity_id,也就无法满足数据的多维度检索聚合需求。为此我们引入了一张索引表,建立从 tag 到 entity_id 的映射,以支持通过 tag 筛选数据。
如图 5 所示,通过指定一个 tag: k1=v1 ,可以查到所有包含这个 tag 的 entity_id1、entity_id2 和entity_id3。
图5 维度索引
RowKey 的构造比较简单：
RowKey = key + value
索引对应的 entity_id 直接作为 Column 的 Qualifier 存储,对应的 Column Value 留空,最终的表结构：
表2 索引表设计
总结
底层存储选型和数据模型设计是 TSDB 设计中的两个重要的基础环节,前者决定了后者的设计思路,后者的设计影响上层功能的设计实现,二者又与集群的架构设计和性能表现息息相关。然而,影响系统性能和可用性的设计环节还有很多,接下来的文章将逐步为读者介绍百度 TSDB 在 功能 和 架构 上的设计实践。敬请期待~~
若您有任何疑问或想进一步了解 百度大规模时序数据存储 问题,欢迎给我们留言！
原文链接地址： https://developer.baidu.com/topic/show/290319
本文作者：AIOps智能运维
作者简介
运小尧 百度高级研发工程师
负责百度运维大数据存储平台的设计和研发,致力于追求大规模存储系统的高性能和高可用。
干货概览
百度运维大数据平台的 时序数据存储系统 （Time Series Database,TSDB）是智能运维团队于 2014 年自研的一套分布式监控数据存储系统。发展至今,经历过几次大的架构更迭,现在 TSDB 作为百度监控系统的底层存储服务,承载了公司诸多核心产品线的监控数据存储和查询需求,日均写入数据点 数以万亿 计,承载 50K QPS 的查询请求。百度大规模时序数据存储系列文章将介绍 TSDB 在监控场景的应用和系统设计实践,本文将介绍 TSDB 在监控场景下的应用以及系统设计面临的技术挑战。
一 监控时序数据
百度的监控时序数据来源于监控系统在全网数十万台服务器上部署的 Agent ,Agent 采集各类监控对象的监控项,并以不同的频率向 TSDB 上报这些监控项的测量值。通过一张 CPU 空闲率趋势图可以直观地看到监控时序数据。
图1 CPU 空闲率趋势图 1 监控对象（Object）
监控对象可以分为三类： 机器级 ：物理机、虚拟机、操作系统等 实例级 ：容器、进程、日志等 服务级 （逻辑对象）：服务、服务组、集群等
图2 监控对象 2 监控项（Metric）
监控对象的一些需要关注的 指标 ,如机器的 CPU 空闲率、内存使用率、网卡带宽以及磁盘 I/O等,称为监控项。除了这些通用的机器监控项以外,根据不同的需求还可以自定义监控项,比如数据服务的缓冲对列长度、查询请求的平均响应时间等。 3 标签（Tag）
标签是一对 Key-Value ,标识了监控对象在某个 维度 （Key）的 特征 （Value）,一个监控对象也可以从多个维度来标识,比如部署在多地域、多运营商的服务可以有地域和运营商两个维度,根据不同的维度取值可以生成不同标签,如 (“机房=杭州”, “运营商=电信”) 和 (“机房=北京”, “运营商=联通”)。 4 时间序列（Time Series）
把监控对象的监控项测量值,按照时间的顺序排列起来就构成了时间序列：
时间序列 = 监控对象 + 标签列表 + 监控项 + 数据点
其中数据点由时间戳和取值构成,每个时间序列对应到趋势图上的一条曲线。
二 监控时序数据的特点 1 数据的使用场景
通过 Web 页面、HTTP API 或命令行工具 ,用户可以方便地从 TSDB 种获取到自己关注的数据： 在日常运维工作中,运维工程师通过 Web 页面人工查看趋势图、同环比报表和热力图等来了解系统的最新或历史状态 一些自动化的服务通过高频、批量地查询时序数据来进行数据分析,进一步地挖掘数据的价值,如异常检测、汇聚计算、根因定位等 2 数据的读写特点
在时序数据的大多数使用场景中,我们更加关注最近一段时间的数据,而这些数据的产生却是 7 *24 小时不间断的,这就导致时间序列的读请求与写请求特征迥异且量级悬殊： 随机写 ：不同的时间序列按照不同频率各自写入数据点 顺序读 ：指定时间范围读取一段连续的数据点 写多读少 ：写入请求量占比达九成以上 3 数据的多维度
前面提到,可以使用标签来从多个维度标识一个监控对象,在获取数据时,也可以通过标签,将监控对象按维度进行筛选聚合。如,对于一个多地域、多运营商部署的服务,获取其在某段时间内、不同地域相同运营商的总流量：
图3 多维度聚合查询
三 面临的挑战 1 高负载和高可用
在百度,有数千万的监控对象,时间序列的总量近 10 亿 。监控项的采集周期通常为 10s,在高时效性要求的场景下要求 5s 的采集周期,这意味着每一秒钟都有数千万个数据点要写入 TSDB,每天产生的数据点规模达到 万亿量级 。与此同时,TSDB 每秒钟还要处理 数万次查询 请求,由于查询有一定的突发性,峰值的查询流量可达到常态流量的数百倍,且根据业务的需求,绝大多数的请求都应该能在 500ms 返回结果给用户。
在处理 7 * 24 小时持续高并发写入的同时,还要应对高并发的查询请求,负载不可谓不重,高吞吐和低延迟是对 TSDB 的基本要求。此外,打铁还需自身硬,作为监控系统自身的基础服务,其可用性必须有所保障,根据业务需求,我们制定的可用性目标至少是 99.99% 。 2 复杂的数据保存策略
前文提到监控时序数据的使用场景有很多,包括汇聚值报警、查看指标的历史趋势图、实时的数据报表（天/周/季/年的同/环比）、趋势异常检测以及历史数据离线分析等,这些场景分别有着独特的查询特点：
场景 时间范围 查询数据量 查询频率 时效性要求
| 汇聚值报警 | 最近数分钟或数小时 | 小 | 高 | 高
异常检测 | 实时报表 | 历史趋势图 | 离线分析
多个时间区间 | 最近数小时或数天 | 自定义时间范围 | 数天、数周或数月
小 | 大 | 小 | 大
高 | 高 | 低 | 低
高 | 低 | 低 | 低 |
|---|
可以看到,每种场景的查询数据量、数据的分布以及对数据时效性的需求不尽相同,TSDB 需要在这些场景下都能够高效地获取数据。 3
不断增长的业务规模
百度的产品线数量、业务规模在不断地增加,相应地,监控系统的体量也随着增长,TSDB 的规模也势必增长,必然会面临容量、成本和可用性的压力。低成本地换取系统容量的增加和可用性的提升,是在系统设计时需要考虑的重点之一。 4
多样化的数据保存需求
不同的业务对监控数据的保存时长有不同的要求,不同的场景对数据的粒度也有不同的要求,例如,想要知道某服务过去一天的总流量相比去年同期的变化,需要数据至少保存一年,但数据的粒度可以是天级；而对于最近一个小时的流量,希望能够支持更细粒度的监控数据,以便能够发现短暂的流量突变。
总结
本文主要介绍了 监控场景时序数据 的特点,以及我们在设计时序数据存储时面临的挑战,对于百度在应对这些挑战时的 设计实践 ,敬请期待下期文章。
若您有任何疑问或想进一步了解 百度大规模时序数据存储 问题,欢迎给我们留言！
原文链接地址： https://developer.baidu.com/topic/show/290318
本文作者：AIOps智能运维
作者简介
饿马摇铃 百度云高级研发工程师
负责百度云智能运维产品（Noah）数据采集和计算方向架构设计和研发工作,对分布式系统架构有一定实践经验。
干货概览
本文是我在实时数据计算系统的设计、开发、运维生涯的一部分经验总结。主要介绍一些设计思路和常见问题的解决方案,不关注具体计算框架的使用。
本人主要致力于 监控系统数据计算 方向,主要业务场景有：监控数据的ETL、数据汇聚、分析、异常检测等。由于监控系统对 时效性 有较高需求,所以我们的计算系统更偏向实时系统,根据业务场景的不同,延迟从数百毫秒到分钟不等。下文提到的计算架构更多是指整个计算处理通路,主要以监控场景下的系统设计为例,相信与其他场景下的架构也有相通之处。
文章从以下几个方面展开。
首先,在第1节,我们简述不同数据规模和场景下,监控系统计算 架构的可选方案 。在公司、业务发展的不同阶段,主要矛盾不同,能够投入人力物力资源不同,需要选择合适的架构方案。
实时计算系统的设计有一个 核心问题 ：如何同时满足高时效性和数据准确性？在现实环境中,高时效性和准确性很难同时达到,第2节中介绍了Watermark机制以实现两者的平衡。
第3节介绍百度监控系统的 实时计算系统架构 ,描述了其基本组成、思路和实现中一些常见问题的解决方案。
最后,简单讨论了实时计算系统 可用性建设 。
监控系统计算架构选型
对于包含数百到千级别节点的小集群,数据规模有限,所有采集、存储、计算逻辑都可以集成在一个模块中实现,这种多为 领域专用系统 。监控系统中,典型的有Prometheus,其采用单服务节点架构,提供简单的HA模式进行容错,这种架构的优点是 部署使用简单 。受限于单机资源,适合部署自治的多个实例,每个实例监控不同服务。大规模集群情况下,要实现全局的监控,需要合并多个监控实例的数据,在配置分发、可用性、容错、自动化部署管理等方面都需要更多的工作。从开发角度考虑,由于 功能耦合严重 ,不利于开发升级。
比起领域专用系统,还有一种架构是使用通用性更强的OLAP系统来实现实时或者近实时的计算功能,如TSDB、ElasticSearch等系统都有一定的聚合计算能力。这些分布式系统都有 水平扩展能力 和 容错能力 ,但难以实现复杂业务计算,同时延迟不可控,复杂查询或大批量数据查询的延迟可能会达到分钟级别。
更多的情况下我们采用 存储计算分离 的方案,以便存储和计算的各自演进和平台化。通常由一个提供精细查询能力的存储服务与一个计算模块组成。计算模块根据计算规则从存储系统中拉取数据并进行计算,这个架构的瓶颈在于存储系统能够支持的查询规模。根据我们的经验,基于精心设计的内存数据库集群,能够承受百万级别的并发查询。这种架构下计算任务多为 周期性调度 ,当查询性能下降时会造成任务的堆积。这个模型不方便处理延迟数据,需要一定机制预测数据完整时间,调度任务进行重算,任务调度的复杂度高。基于索引查询的计算系统的延迟取决于计算轮询的周期,适用于聚合类的涉及时间窗口的运算操作。
在 更高数据量 和计算规则的情况下,流式计算是一个自然的选择,降低了写存储、索引、查询的消耗,计算延迟大幅降低。
当数据量进一步上升,需要的网络吞吐、计算能力骤增,后端的算力难以跟上数据量的增长。这时候可以将计算能力 分散到全链路 ,将计算提前到数据产生端。在监控系统中,通过在采集端进行预计算和ETL操作,提取或整合有用信息,对于实时日志采集,能大幅度降低传输到后端的数据量。放到更大的视角上,这种将算力下放到数据源的思想,是目前大热的边缘计算的一个主要思路。
近年来,以AWS Lambda为首的Serverless计算架构得到了更多的重视。这个模型将计算抽象为事件以及触发的 计算逻辑 ,计算逻辑实际由框架调度、分配资源执行。用户只需要编写计算逻辑,而不用关心可用性、可扩展、负载均衡等后端代码,极大的降低了开发成本。通过 按需调度 ,自动扩缩容,业务运维方不再关心容量规划等问题。私以为当前常见计算框架的Serverless化是一个值得尝试的方向。目前的Serverless框架还存在很多问题,例如调度初始化虚机、容器的成本高,缺乏状态存储等,比较适用于无状态的计算。
一般来说根据场景需求,通常对不同的架构会组合使用。例如百度监控系统内部是以流式计算与近线计算相结合的方式提供服务的,近线计算从时序数据库（TSDB）中拉取数据进行计算。对于Trace、在线数据分析等具有比较复杂查询需求但是相对比较低频的操作,更适合基于索引查询的架构。
准确性与时效性
对于实时系统,我们对时效性有更严格的需求,但是通常高时效性伴随着 低准确度 ,二者不可兼得。在分布式环境下,天然存在长尾的延迟数据,这可能是原始数据自身的延迟,也可能是由采集点异常、网络延迟、网络抖动、数据通路中负载等造成的延迟。数据源越多,分散的越广,这个长尾效应就会越严重,等待数据完整所需要的时间也越长。我们需要在最终数据的准确性和时效性间做折中。
不同场景对两者的需求不一致,通常来说报警、自动止损等操作需要最高的时效性,能够容忍一定的精度缺失,在审计、订单等数据上我们更多的追求准确性,时效性可以适当放宽。解决这个折衷的常用机制是 Watermark 。
Watermark是在数据流中 增加标志信息 ,用以指示一个窗口内的数据已经“完全”到达,可以进行计算。
示例：假设我们要统计10s内到达的事件数目,以事件时间（Event Time,即事件携带的时间,多为事件产生时间）作为时间基准。如下图所示,横线为Wall Time时间线,单位为s。圆球表示事件,圆球里面的数字为事件时间,其虚线指向产生时间,圆球正对的Wall Time时间线上的点为被计算系统处理的时间（Process Time）,两个时间之间的差值为实际延迟。每个事件都或多或少存在延迟,其中数字为45的圆球延迟最大。对于事件时间[40, 50]这个汇聚窗口,假设我们将Watermark线画在53处,则我们认为数据在53之前已经完全到达,已经接收到的那些数据可以参与汇聚,Watermark之后到来的事件则忽略。
具体怎么确定Watermark通常取决于需求,对于数据点数量级比较稳定的场景,可以设置一个到达的数据点的比例,在某一个判断周期内,只要到达的数据点比例满足阈值则可添加Watermark。主流开源计算框架对Watermark的实际定义不尽相同,具体使用参考对应计算框架的定义。
私以为Watermark机制隐含的一个重要思想是 将数据准确性的定义交还给用户 ,让用户决定。产品或者架构上的功能,存在多种方案的情况下,选择最泛化的那个方案,暴露出参数然后让用户来选择,不要自己替用户做决定。当然为了简化实现成本和用户使用成本,可以设置固定的一些选项,并选择一个需求最大的作为默认值。
通常Watermark之后的过期数据点会被丢弃。经常的,除了满足高时效性需求外,我们也需要在之后保证数据的最终准确性,即在一定时间段之后的数据是准确的。常用思路是部署两套计算系统,流式计算用以实现低延迟但是准确性低的需求,批量计算用于补偿计算数据的准确性,这就是Lambda架构。最典型的使用Lambda架构的场景是从日志中统计PV/UV,通常是一个流式采集系统和流式计算框架进行实时的PV/UV计算,同时有一套离线系统,定期拉取原始日志,通过批量计算系统统计准确的PV/UV数值。通常这种架构的缺点是两套系统的资源消耗, 开发运维成本高 。
当前主流计算框架如Spark和Flink对流式和批量计算进行了统一抽象。可以一定程度降低两套系统的开发运维成本,降低了不同框架的开发运维成本,两次计算的的资源消耗依旧存在。
对于满足交换率和结合率的算子,如常见的统计方法(MAX/MIN/SUM/COUNT),在存储侧支持相同运算的情况下,可以将两次运算合并成一次。我们内部称这个方案为多版本,即数据生产一部分就汇聚一部分,每次汇聚产生一个数据版本,由存储在写入时合并,或者在查询时合并。本质上,这是将汇聚的功能迁移了一部分至存储。
百度监控实时计算系统架构
百度监控系统的实时计算系统承担了监控系统数据处理栈的主要计算功能,每天 处理数千亿条 消息。本节在实际系统的基础上,进行了一定的抽象,介绍一个较为通用的系统架构。
如图所示,架构主要包含以下组件： 接入模块： 包括数据拉取和数据接收,前者主动拉取数据,后者接收由上游模块推送的数据。 分发模块： 根据配置的计算规则,过滤订阅的数据,并根据调度策略、集群状态将规则对应的数据分配到一个或多个处理单元进行计算。 处理单元： 包括一个物理计算模块和对应的输入输出消息队列。物理计算模块执行实际的业务计算逻辑,不同处理单元间可以是同构的也可以是异构的,根据不同的业务场景和用户需求,可以使用不同的技术栈。 控制模块： 接收用户提交的计算规则和管理操作,分配调度资源,产生对其他模块的控制信息。 数据推送模块： 拉取计算结果,根据计算规则将数据分发到下游模块。
每个物理计算模块都对应一个输入和输出消息队列,以将数据接入、据输出与计算层隔离,增加一个新的第三方系统的交互不会影响计算功能。升级变更物理框架不会影响其他组件。
由于大数据处理框架,在其数据规模、节点数目达到一定规模时,其处理性能以及异常恢复速度都会下降。我们将一个固定计算能力以及配套的资源（如消息队列）抽象为一个处理单元,每个处理单元处理一部分的数据,取决于计算功能的物理实现,这个处理单元可以对应一个集群或者一个作业。一个处理单元的具体规模取决于具体的 技术选型和硬件条件 。确认处理单元的好处是便于容量规划,可以以一个处理单元作为粒度进行扩缩容。如果需要嫌粒度过大,分层次进行扩缩容,先在一个处理单元内部扩展直到极限,之后启动一个新的处理单元。
实现中需要考虑以下几个点：
1 负载均衡
负载均衡发生在系统的每一个层次。
数据接入层与和分发模块之间的采用随机发送的策略以 均衡分发模块 的压力 。
数据拉取和数据推送模块需要动态平衡每个实例上的拉取或推送任务,常用的策略是一致性哈希,以每个任务的实际数据量作为权重。
计算过程是最需要考虑负载均衡的场景,聚合计算通常会遭遇数据倾斜问题,即某些key的数据量远大于其他,这就造成汇聚该Key的任务OOM。下面提供几种常用解决思路： 对于满足交换率和结合率的计算方法,如MAX/MIN/SUM/COUNT等,可以添加多层预聚合,降低最终聚合的数据量。预聚合层次间可以随机方式,最终汇聚之前按Key哈希。
负载均衡或者说任务调度对应Bin Packing等一系列等价的最优化问题。这些问题是NP-Hard的,可以通过近似算法来逼近,典型的有First Fit算法。实现时一般需要自定义计算框架的分区逻辑,如Spark可以通过自定义Partitioner来实现。
2 控制节点扇入扇出规模
无论是具备状态副本的分布式存储系统、基于DAG的分布式计算系统还是Stateless的接入集群,当集群规模持续增大时,节点间交互会显著增大,最差的情况下全连接,扩容节点会有指数级的连接增长。这会严重影响系统对水平扩容能力,扩容带来的收益跟不上单机资源消耗的增长。
对于分布式系统,通过 控制集群或者作业规模 可以实现一定程度的控制,对于接入模块,可以限制下游连接到上限。
可用性
对于可用性要求高的服务可以多集群热备的方式,在上述架构中,可以通过运行多个并行的处理单元处理相同的数据流来实现。也可以部署整个集群,通过采集端多写的方式复制数据流。最后需要根据输出结果的延迟、准确度等判断策略选择一个计算结果输出。
服务无损升级 ,可以通过启动一个新的计算单元,并行处理数据,待数据“预热”后,进行切换。
在部署时,接入模块尽可能的靠近数据源,保证每个地域一套。系统多地域部署,每个地域内部模块间尽量自治。接入端发送数据时优先发送本地域,异常时尝试其他地域。模块间交互可以打 QoS （服务质量）标签增加网络优先级以降低网络丢包。
监控上,除了基础资源、流量等监控外,最重要的是 全通路时延监控 ,常见方案是构造业务流量,统计在系统中的延迟。这个延迟指标通常是多维度的,根据部署和业务使用情况可能需要关注不同地域,不同业务,不同处理通路的延迟。这些延迟指标,可以指示系统进行流量调度或者资源的重分配。
总 结
本文简单介绍了百度的分布式监控计算系统架构的演进和当前的实时计算架构,并提供了部分常见问题点解决思路。架构是不断在演进的,我们的系统仅仅是“够用”,还有更多的工作需要开展,如架构的轻量化,统一易用的计算表示层,计算的自动优化等。
由于个人水平有限,如果行文中有错误,或者有需要进一步探讨的,请在留言中指出。
原文链接地址： https://developer.baidu.com/topic/show/290317
本文作者：AIOps智能运维
作者简介
运小军 百度高级研发工程师
负责百度运维部大规模日志处理、海量事件数据存储相关设计研发工作,在分布式系统架构、大数据存储计算、高性能网络服务和即时通讯服务有广泛实践经验。
干货概览
本文主要介绍百度运维部监控架构团队在处理 大规模日志计算任务 时,为保证任务分配均匀性和稳定性,对原始 一致性哈希 算法进行改进。新算法在保持原始一致性哈希算法稳定性的同时,通过设置 不均衡因子 来控制分配的不均匀范围,达到负载分配均匀性与稳定性有效兼容。
一
业务场景
分布式系统中我们经常会面对如下业务场景： 计算系统每分钟有大量的定时任务需要及时调度并按时完成,单机在处理能力和时效性上都无法满足要求,需要将任务分配到大量Work节点上进行并行计算,我们如何均匀分配这些任务,并且在任务增减,Work节点退出/加入(伸缩能力)时保持任务分配的稳定性(不会引起大量任务迁移)。 分布式存储系统,海量数据被分片存储,那么如何让每个Data节点上分片更加均匀,并且在Data节点退出/加入时保持数据分片的稳定性。 高并发Web系统中,架构上几乎都是一个或多个反向代理服务器(如Nginx)来做七层负载均衡,后端使用应用服务器集群(如Tomcat)提供服务,这种架构具备水平伸缩能力,那么反向代理如何均匀分配请求,并且尽量保证请求Session粘性。 二 问题分析
上述问题可以抽象为对分配算法如下几个方面的要求： 公平性 ：即算法的结果要尽可能地公平,不能造成分配不均问题,这点在分布式系统中尤其重要,公平性就是要尽可能避免由于负载过重/过轻导致系统出现慢节点/饥饿节点影响系统整体性能和资源利用率。 稳定性 ：分布式系统中,集群节点维护、故障、宕机、重启、扩缩容是非常常见的,稳定性就是要保证计算任务、数据、请求在节点加入/退出时尽可能保持稳定,不引起大量计算任务重分配、数据迁移、请求转移,这对系统整体可靠性、稳定性、高性能至关重要。 可行性 ：算法在工程实践上一定是可行的,具体体现在这两个方面：时间复杂度、空间复杂度,时间复杂度要求一定要快,满足业务场景对响应时间的要求,空间复杂度要求占用资源少,满足业务在资源投入和收益上的平衡。 三 常见算法
面对这些问题我们有很多常见处理方法,例如 轮询(Round-Robin)、取模哈希、一致性哈希、按ID范围分段、自定义分段策略 ,下面我们选择几种常见分配算法,分析它们在公平性,稳定性及可用性方面的能力：
从上面表格对比可知这几种常见算法都无法兼具三种特性,那么有没有一个算法,能同时具备公平性、稳定性以及可行性？接下来介绍的这个算法能在保持原始一致性哈希稳定性的同时还具备可控的均匀性,已经实际应用于我们的分布式近线计算系统中用于分配定时计算任务,目前来看效果还不错。 四
有界负载一致性哈希
有界负载一致性哈希 (Bounded-Load Consistent Hash)算法是对原始一致性哈希算法的改进,相对于原始一致性哈希算法的不均匀问题,新算法能通过设置一个不均衡因子,来控制整个分配的不均衡范围。 算法描述
1. 假设计算节点数为n,任务数为m,则每个计算节点的平均任务数t=⌈m/n⌉(取上界是为了保证t*n >= m,保证所有任务都能被分配执行)；
2. 设置不均衡因子c(取值范围为1 < c < ∞)用于控制最大不均匀范围,则每个节点分配的最大任务数为c*t；
3. 使用一致性哈希算法为任务寻找计算节点,当所选节点已有任务数大于tc时,顺序寻找下一个已有任务数不大于tc的节点,直到找到并将任务分配给该节点；
4. 重复步骤3直到所有任务分配完成；
不均衡因子c越接近1整个分配越均衡(整个分配过程耗时会变长),跟轮询算法效果一样了,c无穷大时跟原始一致性哈希效果一样了。 实现
下面通过Java伪代码对该算法进行实现：
1. public String getTargeNode (String key) { 2. // imbalanceFactor为不均衡因子,取值范围为1 < imbalanceFactor < ∞ 3. // 单节点最大分配任务数
4. maxAssignedSize = ⌈(totalOfSlice / totalOfNode)⌉* imbalanceFactor;
5. // nodes中key是依据node名字产生的hash值,value是node的名字
6. SortedMap tail = nodes.tailMap(hash(key));
7. long indexKey;
8. if (tail.isEmpty()) {
9. indexKey = nodes.firstKey();
10. } else {
11. indexKey = tail.firstKey();
12. }
13. String targetNode= nodes.get(indexKey);
14. //getTask获取该节点已分配任务数
15. if (getTask(targetNode) > maxAssignedSize) {
16. // 该节点超过最大任务数,继续顺序寻找下一个节点.
17. do {
18. SortedMap tailMap = nodes.tailMap(indexKey, false );
19. if (tailMap.isEmpty()) {
20. indexKey = nodes.firstKey();
21. } else {
22. indexKey = tailMap.firstKey();
23. }
24. targetNode = tailMap.get(indexKey);
25. } while (getTask(targetNode) > maxAssignedSize);
26. }
27. return targetNode;
28. }
因为maxAssignedSize*totalOfNode>=totalOfSlice,所以上面的算法不会导致死循环,每次分配必然有一个计算节点能接受这个任务；最终结果就是每个节点分配的任务数都不会超过maxAssignedSize,不均匀问题通过imbalanceFactor参数来控制；当计算节点退出时,其上面的任务迁移也只限于跟它相邻的一个或多个节点,并不会导致大范围重分配。 效果
下面通过对比近线计算分配算法分别选择轮询、一致性哈希、有界负载一致性哈希时的业务指标,从分配均衡性,计算节点加入/退出的稳定性两个方面来衡量这三种算法的效果：
图1 单个计算节点分配任务数(轮询、一致性哈希、有界负载一致性哈希(c=1.1))
图2 节点加入/退出时迁移任务数(轮询、一致性哈希、有界负载一致性哈希(c=1.1))
很明显可以看到,轮询在任务分配上非常均匀,但是当计算节点变动时,导致大量任务重分配,而一致性哈希解决了任务大量重分配问题,但任务分配不均匀而且无法控制这种均匀性,而有界一致性哈希在 任务分配均匀性 和 重分配 都表现非常好,通过不均衡因子来限制不均匀范围,本身一致性哈希又有效避免了大量任务重分配。
总结
分布式近线计算系统的任务分配算法在业务需求驱动下,经历了从最初的均匀轮询(防止分配不均导致慢节点),到使用一致性哈希(防止任务因为计算节点加入/退出导致重分配,为了达到尽可能均匀优化虚拟节点个数),再到有界负载一致性哈希通过参数控制解决原始一致性哈希 分布不均匀问题 ,每次分配算法改进都极大提高了 系统整体稳定性 ；有界负载一致性哈希算法具有通用性,可以有效解决任务分配,数据分片,请求分发等业务场景中分配均匀性与稳定性问题。
原文链接地址： https://developer.baidu.com/topic/show/290316
本文作者：AIOps智能运维
作者简介
运小羴 百度云高级研发工程师
负责百度云Noah智能监控产品数据采集子系统相关研发工作,在分布式监控系统架构、服务器客户端研发等方向有着较为广泛的实践经验。
干货概览
在百度云Noah智能监控产品中,我们提供了多维度数据聚合计算、智能异常检测、数据可视化、智能报警合并、逐级通告等丰富功能。今天,我们追根溯源,讲讲所有这些能力的基础,数据的来源, 监控数据采集（入门篇） 。
不同业务场景下都有着不同的监控需求,比如服务器的运行时信息、服务进程信息、日志信息、网络状态信息以及服务状态信息等。与之对应的,数据采集也需要提供丰富的采集方式来满足这些需求,一般地,针对应用场景的不同,可分别通过 本地客户端采集 和 远程服务采集 的方式来实现。
图1 监控平台架构简化图
本地客户端采集主要负责服务器自身的信息采集以及服务器上运行程序的信息采集,远程服务采集则通过远程发起探测的方式进行域名监控、网络监控、死机探测等,本文也将从这几个方面来阐述。当然,除此之外,还有更高级的数据采集方式,暂不在本文（入门篇）讨论范畴内。
本地客户端采集
本地客户端采集提供 基础的机器信息采集和用户服务信息采集 。机器信息采集主要关注机器硬件信息、机器资源使用、机器负载情况等。服务信息采集则通过插件的形式提供服务,包括进程采集、日志采集、自定义脚本采集、自定义HTTP采集等。
图2 本地客户端架构图 机器数据采集
服务器信息采集我们可提供数百个监控指标,其中大家常用的如CPU、内存、磁盘、网络等指标,一般要提供高频度的采集,比如Noah监控提供了 最细粒度5秒采集频率 , 采集延时小于1秒 的采集能力；对于系统内核等信息,由于不常变化,一般会使用小时级或天级的采集频率。主要指标如下表：
服务数据采集 1 进程采集
服务进程信息采集,最简单粗暴的指标莫过于采集 进程是否存活 ,另外,就要通过进程的资源消耗来一窥服务运行状态。关于进程采集,我们提供了CPU使用、内存使用、FD使用信息、磁盘IO读写信息近30个监控指标,大多数信息都可以从/proc/${pid}/下的各个文件获取并计算得到。
在采集客户端设计研发的过程中,我们发现,很多场景下 FD 资源 会成为一个紧缺资源,因此,部署到所有机器的采集客户端,对于机器资源占用都有着比较严格的要求,通常FD数量占用也不宜过高,避免影响机器其他服务的运行。因此,对于进程的FD使用监控显得尤为重要,为了进一步了解服务使用的FD信息,我们还提供了块设备FD数、字符设备FD数、管道FD数、网络FD数、文件FD数、FD总数、FD上限的监控。
图3 进程采集的数据
图4 进程FD监控 2 日志采集
服务的运行状况通常可以通过 打印日志方式来记录 ,业务的指标也可以通过分析这些日志得到。比如服务流量指标、异常请求指标、响应时间指标等都是服务的重要业务指标,通过客户端提供的日志采集插件可以统统满足。对于基本的流量指标,我们可以用正则匹配等较简单的方式来进行采集,当然还有很多复杂的需求,需要进行多维度数据分析或故障诊断的时候,就需要提供高级版的功能,通过提取日志中的具体字段构成数据的维度信息,从多维度的角度来计算、查看、分析这份数据。 简单的多维度日志数据采集举例
一个最典型的多维度日志数据采集的例子,就是通过提取日志中请求来源IP,来生成各地域、运营商等的流量信息。
通过提取日志中的IP字段,并进一步 反解该IP 所属的省份、运营商信息,便于直观的统计来源请求。当然,要支持海外流量的统计需求,还需要监控系统支持海外的IP国家归属信息查询。
如下图所示,我们可以将日志中各个字段的值进行提取,如关注的URI字段、IDC字段、IP字段等,进一步,还以可将某些字段进行二次解析,例如,将IP字段所属的省份运营商进行解析。
图5 日志维度提取
再进一步,我们将数据按照提取的维度进行 聚合 ,可以查看机房维度的流量信息,如下图所示：
图6 维度数据展示 3 自定义采集
为了应对某些定制化的场景,比如服务的指标并不在日志中体现,那么我们还提供了一些常见自定义采集插件来满足业务需求。包括通过自定义脚本进行数据的采集,以及服务提供的HTTP接口进行数据采集。比如服务的某些信息不适合通过日志的方式采集,那么此时便可以通过自定义脚本或者HTTP接口的形式将该数据吐出来,通过配置自定义监控来采集这些数据便可以方便的查看这些数据以及后续的聚合计算以及报警配置。
一种简单的自定义脚本输出形式：
图7 自定义脚本输出
对应的监控输出如下：
图8 自定义脚本监控
远程服务采集
服务监控
远程探测的形式是从监控机向用户机器发起探测请求,并校验返回的结果,根据返回结果来判断服务是否正常。根据请求内容的类型我们主要提供以下三种功能： 端口监控： 探测目标端口是否存活； 语义监控： 发送请求到目标机器,校验返回的数据是否符合预期,支持各种文本类型的协议,如HTTP/HTTPS； 结构体监控： 对于二进制等文本形式难以描述的服务接口,则通过结构体监控来解决二进制内容的监控。 死机检测
机器故障或者死机是线上的一个常见问题 ,死机检测功能则可以帮助用户及时 发现故障机器 ,进行服务的 迁移 或者 降级 来保障服务可用性。死机检测往往很难通过单一手段来判断,这里,我们通过分别检测本地客户端的 存活状况 、 SSH 等常用端口来判断机器是否故障以及故障的类型。 总结
本文主要介绍了百度云Noah智能监控中的数据采集（入门篇）,数据采集需要针对不同的应用场景,通过不同的方式进行采集。基础的数据采集,可以通过部署本地客户端和远程服务采集两种方式来完成。通用化的服务器信息、进程信息等,可以通过预置方式进行采集,无需用户操心或干预；而针对不同业务的个性化情况,则提供灵活的插件形式进行采集,由用户来灵活配置采集的形式,满足定制化的需求。
原文链接地址： https://developer.baidu.com/topic/show/290315
基本介绍
经常遇到一些开发者问：
1.我们播放的时候,会有黑边怎么处理？尤其是在类似于抖音,直播这样的场景下,如果视频有黑边,很影响画面的视觉效果。而阿里云播放器提供了缩放功能,用来去除黑边,达到视频全屏的效果。
2.直播时摄像头采集经常会遇到反向的问题,就是采集出来的视频画面中的字是反的,对于这种情况怎么处理呢？阿里云播放器提供了镜像的功能,可以水平和垂直镜像,让画面变成你想要的样子。
3.对一些横屏拍摄的视频同时我们提供了旋转功能,可以选择90、270度,旋转之后就可以实现全屏渲染了。
渲染模式设置
Android接口
播放器提供了 setVideoScalingMode 方法提供去改变画面的大小。它可以设置两种方式：
1. VIDEO_SCALING_MODE_SCALE_TO_FIT
按照视频的宽高比,放到SurfaceView（TextureView）中。不会剪裁视频画面,画面的内容是完整的。比如我的SurfaceView是1920:1080的,然后播放一个1280x720的视频,如果使用FIT模式,最终显示的话,播放器把1280x720这个视频按照原始比例放大,直到宽或者高跟SurfaceView的宽或者高一直,最终只有上下有黑边或者左右有黑边。
2. VIDEO_SCALING_MODE_SCALE_TO_FIT_WITH_CROPPING
按照视频的宽高比,将画面铺满SurfaceView（TextureView）中。此时会剪裁视频的画面,可能两边有部分内容不会被显示。crop方式肯定是没有黑边的。 播放器默认的缩放效果为：VIDEO_SCALING_MODE_SCALE_TO_FIT。
VIDEO_SCALING_MODE_SCALE_TO_FIT_WITH_CROPPING 是以牺牲画面的完整性为代价,从而实现了没有黑边。所以,当画面的宽高比与实际的宽高比相差太大时,不太合适使用此配置。
我们来看具体的显示效果,比如播放一个竖屏的视频。
1.设置VIDEO_SCALING_MODE_SCALE_TO_FIT。即按照视频的宽高比,放到SurfaceView（TextureView）中。
if (aliyunVodPlayer != null) { aliyunVodPlayer.setVideoScalingMode(IAliyunVodPlayer.VideoScalingMode.VIDEO_SCALING_MODE_SCALE_TO_FIT); }
可以看到,有明显的黑边,但是画面会被完整的显示出来。
2.设置VIDEO_SCALING_MODE_SCALE_TO_FIT_WITH_CROPPING。即：按照视频的宽高比,将画面铺满SurfaceView（TextureView）中。
if (aliyunVodPlayer != null) { aliyunVodPlayer.setVideoScalingMode(IAliyunVodPlayer.VideoScalingMode.VIDEO_SCALING_MODE_SCALE_TO_FIT_WITH_CROPPING); }
可以看到,黑边没有了,但是画面的部分内容已经看不到了。
iOS接口
iOS提供了一个属性来获取和设置渲染模式
@property(nonatomic, readwrite) ScalingMode scalingMode; enum { scalingModeAspectFit = 0, scalingModeAspectFitWithCropping = 1, }; typedef NSInteger ScalingMode;
和Android类似,scalingModeAspectFit对应Android的VIDEO_SCALING_MODE_SCALE_TO_FIT,scalingModeAspectFitWithCropping对应Android的VIDEO_SCALING_MODE_SCALE_TO_FIT_WITH_CROPPING,具体接口说明和效果和Android一样,在这里不在赘述。
镜像设置
iOS接口
iOS提供了如下接口来实现镜像的设置,支持水平和垂直镜像。
-(void) setRenderMirrorMode:(RenderMirrorMode)mirrorMode; enum { renderMirrorModeNone = 0, renderMirrorHorizonMode, renderMirrorVerticalMode, }; typedef NSInteger RenderMirrorMode;
水平镜像
垂直镜像
Android接口
public void setRenderMirrorMode(VideoMirrorMode mirrorMode); enum VideoMirrorMode { VIDEO_MIRROR_MODE_NONE(0), VIDEO_MIRROR_MODE_HORIZONTAL(1), VIDEO_MIRROR_MODE_VERTICAL(2); }
旋转设置
iOS接口
iOS提供了如下接口来实现旋转的设置,旋转支持0、90、180、270度的旋转。
-(void) setRenderRotate:(RenderRotate)rotate; enum { renderRotate0 = 0, renderRotate90 = 90, renderRotate180 = 180, renderRotate270 = 270, }; typedef NSInteger RenderRotate;
Android接口
public void setRenderRotate(VideoRotate rotate); public static class VideoRotate { public static VideoRotate ROTATE_0 = new VideoRotate(0); public static VideoRotate ROTATE_90 = new VideoRotate(90); public static VideoRotate ROTATE_180 = new VideoRotate(180); public static VideoRotate ROTATE_270 = new VideoRotate(270); }
作者： 隽阜
原文链接
本文为云栖社区原创内容,未经允许不得转载。
本文作者：AIOps智能运维
作者简介
小拳拳 百度云高级研发工程师
负责百度云智能运维Noah外网质量监测平台的系统和策略研发,在网络监控方向有广泛实践经验。
干货概览
在此前介绍百度云智能运维Noah外网质量监测平台文章《百度网络监控实战：猎鹰一战成名（上）》中,我们简要介绍了一种网络异常类型—— 机房侧异常 （百度侧设备/链路异常）。该故障在数据上表现为多个省份访问某个百度机房服务不通畅,因此在猎鹰（百度外网监控平台）外网判障中,可以通过设置访问某机房出现异常的省份比例超过给定阈值,来判定机房侧异常的发生。
在外网故障统计中我们发现,运营商 骨干网链路 出现故障同样会导致多个省份到特定机房访问异常,在现有外网判障框架中,会将骨干网链路异常也判定为机房侧异常。然而,机房侧异常与骨干网链路异常无论是从起因还是数据表现上,都是存在一定差异的,两者的止损方式也不相同。因此,我们需要设计 判障策略 来区分两类异常,以便自动止损系统根据异常类型执行合适的外网止损方案。
在下文中,我们将为大家介绍骨干网链路及其异常表现,以及判障策略的设计思路。
什么是骨干网链路？
骨干网是运营商用来连接多个地域或地区的高速网络,因此骨干网的一个重要作用就是 承载跨地域传输的网络数据 。若干条跨地域连接的骨干网链路,共同组成了完整的运营商骨干网。
图1所示是用于连接南北地域的一条骨干网链路——第二京汉广链路。各省份跨南北地域传输的网络数据,首先会汇聚到该链路上北京、武汉、广州等核心 城市节点 ,然后经由该链路传输至 目的位置 。
图1 第二京汉广链路
当构成这条骨干网链路的 网络设备 ,如交换机、光纤等,出现拥塞、损毁等异常状况时,流经链路故障位置的网络数据会受到影响,通常表现为 丢包 甚至 数据断连 。
骨干网异常对百度外网质量的影响
如图2所示,外网监控系统猎鹰通过在各省份的探测点,实时监控百度各机房的网络连通性状态。
图2 猎鹰外网监控图示
在每个判定周期,每个省份都会上报若干条对百度各机房的探测数据。假设某省份对特定机房的探测,共上报了m条数据,其中n条数据为异常状态,那么 异常率 n/m可以用于衡量省份到机房的外网质量。
骨干网链路发生异常时,会使得百度外网质量受损。具体表现为,用户跨地域访问百度机房时异常率升高,而用户访问同地域的百度机房服务时异常率不受影响。
图3(a)(b)分别展示了某次南北骨干网链路异常发生时,全国各省份访问百度南北两地机房的异常率,其中,不同省份颜色对应的异常率如图中左下角所示。
图3(a) 南北链路异常发生时,全国访问北京机房异常率
图3(b) 南北链路异常发生时,全国访问广州机房异常率
从图3(a)中可以看出,河南-山东线以南的省份,访问百度北京机房普遍出现异常率升高,而以北的省份访问北京机房异常率则较低。图3(b)中各省份访问广州机房也出现了跨南北地域访问异常、同地域访问正常的情况。
骨干网异常与机房侧异常的区别
图4展示了机房侧异常发生时的各省份网络异常率。对比图3和图4可以看出,连接两个地域的骨干网链路异常发生时,异常省份通常聚集于同一地域,并且各省份都会出现访问跨地域的机房异常,访问同地域的机房正常的现象。而机房侧异常发生时,异常省份会分散于全国各地,没有明显的 分布规律 。这个差异是区分两类异常的关键所在。
图4 机房侧异常发生时,全国访问异常机房的异常率
由于两类异常表现不同,因此对应的止损方案也存在差异。对于机房侧异常,可以直接将异常机房的所有流量全部调度至正常机房。而对于骨干网链路异常,由于异常只在跨地域访问时发生,因此需要处理所有 跨地域访问流量 ,可以将所有跨地域的访问流量调度至同地域正常机房。为了使自动止损系统能对骨干网异常执行合适的外网止损方案,为骨干网链路异常设计判障策略是有必要的。
另外,由于运营商的骨干网拓扑主要连接的是南北向各核心城市,骨干网异常也都发生在南北向骨干网链路上,因此后续的策略设计都将围绕 南北骨干网链路 （下文简称南北链路）展开。
判障思路分析
根据南北链路异常的特点以及问题的性质,我们尝试从以下两个思路来考虑解决方案。
1 基于南北划分线进行判定
南北链路异常最显著的特点,就是跨地域访问机房异常率高、同地域访问异常率低,且高异常率与低异常率省份间存在明显的南北划分。根据这个特点,一个直观的想法就是根据历史数据总结出一条 南北划分线 ；通过观察划分线两侧省份异常状况,从而确定异常类型。
然而,通过观察历史上多次南北链路异常我们发现,划分线没有固定的位置。它是随着骨干网链路异常的位置动态变化的,根据划分界线位置的变化,异常省份也存在着差异。如下图所示,(a)与(b)分别是异常链路存在于河北、河南境内时,用户访问百度北京机房的异常率展示。
图5(a) 河北境内链路故障
图5(b) 河南境内链路故障
从图5(a)可以看出,当异常链路位于河北时,河北以南的省份,访问北京机房异常率普遍较高,即划分线位于河北-山东线附近。而图5(b)异常链路位于河南时,划分线纬度则下移至陕西-河南线以下,该线以南的省份异常率较高,异常省份个数也由于划分线位置下移而少于(a)图。
因此,找到一个合适的南北分界线,观察分界线两边省份的异常状态,来判定是否有南北链路异常发生,这个想法难以直接落地。
2 利用分类器模型进行判定
如概览中所说,我们希望对已经判定为机房侧异常的数据做二次处理,正确将机房侧异常与南北链路异常区分开来。显然,这是一个 二分类 问题,利用分类器模型解决也是一个思路。
如果在每个判定周期,都能获得大陆31个省份到各机房的探测数据,那么可以通过积累历史数据,训练一个接受62维特征数据（南北两地机房各自对应的31个省份异常状态）的分类器,用于区分南北链路异常和机房侧异常。
然而由于探测数据回传延迟、回传链路故障、单省份探测点少等原因,难以保证每个判定周期都能拿到31个省份到机房的完整探测数据,即特征数据大概率存在缺失值。另外南北链路故障发生次数较少,可用于训练分类器的数据样本不足,训练出的模型极易过拟合。
根据对这两个思路的分析,可以发现它们由于存在一些问题而难以直接应用。因此,我们综合了这两个思路中有用的部分,设计了骨干网判障策略。
骨干网异常判定策略
综合考虑上述两个方案,我们尝试在判障策略中采用分类器模型,并人为设计特征来减少特征维度,减少模型过拟合的风险。
判障策略的具体步骤如下：
1 确定省份异常状态真值
我们根据各省份异常率以及人为设定的阈值,判定该省份到机房的异常状态,并且以此状态作为省份异常状态的真值。
2 寻找划分线位置
在判定各省份到某机房的异常状态后,对所有省份按照纬度进行排序,并将每个省份都作为可能的划分位置进行遍历,寻找使得“ 划分误差 ”最小的位置,作为划分线位置。
每个可能划分位置都会将省份集合分为划分位置以南的集合与划分位置以北的集合。根据南北链路异常的特点可知,若异常机房为南方机房,则应为正常省份的集合,而应为异常省份的集合。若异常机房为北方机房,则为相反情况。
对于每个省份,若由划分得到的省份状态与省份异常状态真值不符,则认为该省份被划分错误,划分误差可以通过划分错误的省份数/总省份数得到。
如图6示例,假设8个省份被划分,且上半部分为正常省份集合,下半部分为异常省份集合。根据异常状态真值,可计算得到划分误差为2/8=0.25。
图6 划分误差计算示例
在遍历所有可划分位置后,即可得到最小划分误差及对应的划分位置了。
3 特征提取
根据对历史数据的观察得知,南北链路异常对应的划分误差相对较小,且划分线在地图中部位置上下变化。而机房侧异常划分位置和误差没有规律可循。图7展示了两类异常数据的散点图。
图7(a) 线性划分结果
图7(b) 非线性划分结果
从图7(a)与(b)可以看出,仅使用两维特征的情况下,无论是线性分类还是非线性分类,都很难将两类异常数据较好地划分开来。
为了提高分类效果,我们需要引入其他辅助分类的特征,具体如下： 机房位置、异常省份纬度中位数
两者的相对位置关系在南北链路异常时具有明显特征,因此这两维数据的引入增强了南北链路异常的可识别性。例如,南北链路异常发生时,到南方机房异常的省份通常在纬度上远大于机房所在的广东省。取中位数为了消除极端点和噪声带来的影响。 划分位置两边省份异常率均值
机房侧异常发生时,异常省份的分布通常是较为均匀分布于全国各地,因此划分线两边省份的异常率均值差距通常不会很大。因此这两维特征有助于分类器识别机房侧异常。
4 分类器训练
为了区分两类异常类型,我们将训练一个 二分类器 ,训练数据正例为南北链路异常按上述步骤提取到的特征,反例为对机房侧异常提取的特征。在分类器的选取上,我们选择了 支持向量机 （SVM）这一常用的分类器模型,并根据实验回溯效果选择了RBF核函数。
通过以上步骤,我们实现了骨干网链路异常的判定策略。自上线运行以来,取得了极佳的异常判定效果。
总 结
本文从外网异常监控遇到的实际问题出发,介绍了骨干网链路异常以及判定策略的设计思路。该策略有效地解决了骨干网异常与机房侧异常混淆的问题,使得百度云智能运维产品Noah具备了骨干网链路异常的监测能力。
原文链接地址： https://developer.baidu.com/topic/show/290314
本文作者：AIOps智能运维
作者简介
运小海 百度高级研发工程师
从事网络监控、可用性建设相关工作,负责百度外网监控平台 猎鹰 、百度内网监控平台 NetRadar 等系统的研发和优化工作。在网络采集、网络异常检测、系统可用性方面有广泛的实践经验。
干货概览
我们在上一篇文章《 百度网络监控实战：猎鹰一战成名 》（上）中,初步介绍了百度外网质量监控的典型场景与需求,本篇文章将从外网监控的实现原理及系统架构两个方面系统详细介绍百度外网质量监控平台 猎鹰 。
一 外网监控实现原理
通过上一篇文章的需求调研,我们可以知道,业务线运维工程师希望外网监控平台能够真实反映用户到百度IDC（Internet Data Center,互联网数据中心,又称机房）间的网络质量,并能够及时快速地发现机房侧故障、骨干网故障以及单省份故障,这里面有几个关键问题：
1 监控数据反映的是网络质量
对于业务线运维工程师来说,他们关注的是外网质量,因此,需要通过一种探测手段来实时反映网络质量。而探测协议有很多种,比如ICMP、TCP、HTTP,那么哪种协议更适合呢？我们选择了TCP和HTTP来作为探测协议,原因有以下两点：
首先,网络设备在转发请求时,是根据请求的源IP、源端口、目的IP、目的端口、网络协议这五个信息决定请求的Next Hop所经过的链路或者设备。TCP和HTTP协议有请求端口,而ICMP协议只有源IP、目的IP以及网络协议这三个信息。那么对于一个监测点和一个被监测目标来说,由于TCP和HTTP探测请求的源端口可以不断的变化,因此TCP和HTTP探测方式能够比ICMP探测方式够覆盖更多的链路。
其次,用户访问百度服务的请求大多数是基于TCP和HTTP方式的,因此,TCP和HTTP方式更接近于用户的访问方式。
在确定了探测方式之后,我们需要有探测指标来衡量网络质量的好坏,为了更加真实反映用户到百度服务之间的网络质量,我们将网络连接是否建立成功、连接建立的时延作为衡量网络质量的指标。对于HTTP探测方式,我们不关心HTTP Code,只要连接建立成功,即使HTTP Code为500,我们也认为网络正常。
2 监控数据反映用户到百度IDC的网络访问质量
为了能够真实反映用户到百度IDC间的网络质量,需要从用户侧向百度的的VIP（Virtual Internet Address,百度多台服务器形成的一个虚机地址）发起探测。因此,我们在全国三大运营商各个省份部署了若干监测点,用于执行具体的探测任务。
3 能够及时快速地发现网络故障
为了尽可能快地发现网络故障,我们设计了基于数据驱动的网络故障检测模型。已有的故障检测模型大多是固定周期检测模式,比如检测周期是1min,那么检测模型每两次相邻的检测需要间隔1min,这种模式比较适用于流水数据、PV数据的检测。但是对于网络异常检测的场景,实际上每两次相邻的检测并不一定需要间隔1min,看下面这个例子：
假如Tn周期的检测时间点是10:00:00,按照固定周期检测模式,Tn+1周期的检测时间点则是10:01:00,而实际很有可能在10:00:35的时候就已经收集够了相对充足的探测样本,足够判断出当前是否存在网络异常,那么在10:00:35就可以进行故障检测了,这样能够将故障发现时间提前25秒。
因此,在我们的基于数据驱动的网络故障检测模型中,我们对固定周期检测模式进行了改进,加入了探测样本数判断,如果提前收集到了足够的探测样本,则提前进行故障检测,尽可能地加快故障发现速度。
4 能够准确区分网络故障类型
当出现网络故障时,业务线运维工程师需要知道网络故障的类型,以便于采取对应的止损策略进行止损。我们针对机房侧故障、骨干网故障、单省份故障的表现特点分别设计了三种故障发现策略。
图1 外网监控原理示意图
如上所述,我们通过在每个省份部署若干采集点,这些采集点周期性地向百度机房的VIP发起探测请求（HTTP请求和TCP请求）,并将探测结果进行上报,然后对探测结果进行故障判定,得到实时的网络质量和状态（如图1所示）。
二 系统架构
猎鹰 整体系统架构如图2所示,主要包括采集服务、任务分发、数据分析与告警、元数据管理、存储以及可视化展示等六部分。
图2 猎鹰整体架构图
1 元数据管理
元数据管理是整个系统最基础的一部分,它负责不同的实体映射关系维护,主要包括VIP→机房归属关系、机房→VIP的映射列表以及VIP→域名归属关系。
在上一小节中提到, 猎鹰 部署在各个省份的采集点需要周期性地向百度机房的VIP发起探测请求,服务端接收到探测结果之后,需要把每个VIP的探测样本在VIP所属的机房维度进行汇聚计算,得到机房粒度的探测质量数据。因此,我们必须要维护VIP→机房归属关系以及机房→VIP的映射列表。
另外,在检测出故障后,我们需要判断出受损的业务线,因此需要维护VIP→域名归属关系,比如检测出广东机房出现故障,我们根据机房→VIP的映射列表得到所有受到影响的VIP,然后再根据VIP→域名归属关系分析出受影响的域名,从而得到受损的业务线列表。
2 任务分发
任务分发负责将采集任务分发到采集点,这里的采集任务主要指VIP探测列表,采集任务会指定探测目标（即VIP）、探测协议（HTTP or TCP）、探测周期、超时阈值等。
3 采集服务
采集服务在采集点上运行,负责执行具体的采集任务。采集任务包括HTTP探测任务和TCP探测任务两种,在执行完探测之后,会将探测结果上报给上层的数据分析与告警服务,用于后续的数据处理与实时分析。探测结果包括两个指标：失败率和连接时延。
4 数据分析与告警
数据分析与告警是整个系统最核心的部分,包括数据收集、故障判定以及影响分析与告警。
数据收集用于接收采集服务上报的探测结果,并对探测结果进行一些清洗、去噪以及汇聚计算。
故障判定用于对清洗汇聚后的探测结果进行故障判定,通过三种故障发现策略来判断当前是否存在某种网络故障。
影响分析与告警用于进行故障通告和报警,当故障判定判断存在网络故障时,会通过元数据信息分析出受到此次故障影响的业务线,然后给这些业务的运维工程师发送报警。
4 存储
存储包括三部分：指标时序数据存储、异常事件存储以及元数据存储。指标时序数据存储主要存储实时的探测指标（失败率和连接时延）,异常事件存储主要存储网络故障事件,元数据存储主要存储基础的数据归属映射关系。其中指标时序数据存储和异常事件存储使用的是百度通用的数据存储平台,元数据为内存存储。
5 可视化
可视化视图部分的展现非常重要,这个是对用户最直接的呈现。 猎鹰 的可视化视图主要包括三部分：全局网络视图、业务线网络视图、机房视图。
全局网络视图用来展现实时的全局网络状况,图3展示的是全局网络视图,包括故障公告、机房全局概览和产品线概览。故障公告展示的是最近一段内的网络故障通告。机房全局概览展示的是全百度所有机房的网络状况,如果有异常,会进行飘红显示。产品线概览展示的是接入 猎鹰 的所有产品线的网络状况,如果该产品线受到网络故障影响,则会飘红显示。
图3 全局网络视图（示意图）
业务线网络视图展示的是各个业务线的域名以及VIP的网络质量视图,各业务线运维工程师可以很直观地观察到自己所负责的域名和VIP的网络访问质量。图4展示的是百度搜索产品线的域名网络质量视图,主要包括两部分：
图4 业务线网络视图
1 域名网络连通性质量趋势图
展示的是某一段时间内全国所有省份访问某个域名的连通性情况,按运营商维度分别展示。
2 域名分省网络连通性视图
以地图的形态分运营商展示域名在每个省份的网络连通性质量,地图的每个省份的颜色会随着网络质量的好坏而变化,并且如果网络质量持续异常,地图上的省份会有红圈闪动。每个省份鼠标悬浮停留会展示该省份的网络连通性质量,包括探测异常率和响应时间两个指标。
机房视图展示的是全国各个省份到全百度各个机房的详细外网质量数据。这个视图包括两部分：
1 机房网络连通性趋势图
展示某个时间段内全国所有省份到某个机房的网络连通性状况。
2 可视化机房-省份连通性视图
机房-省份连通性视图以地图的形态细致地展现了每个省份到每个机房的外网访问质量,地图的每个省份的颜色会随着网络质量的好坏而变化。同时,地图上的省份可以和趋势图联动,点击地图的某个省份,右边趋势图展示的内容会变成选中的省份到该机房出的网络连通性数据。
图5 机房视图
总结
猎鹰 已经多次帮助发现重大网络故障,及时挽回了数千万可能的PV Loss,在业务线日常运维工作中发挥着越来越重要的作用。接下来我们会继续秉承着“科技改变世界、技术改变生活”的理念将 猎鹰 打造成更加智能化的网络监控平台,让网络问题无处遁形。
若您有任何疑问或想进一步了解 猎鹰 ,欢迎给我们留言！
原文链接地址： https://developer.baidu.com/topic/show/290313
本文作者：AIOps智能运维
从事网络监控、可用性建设相关工作,负责百度外网监控平台 猎鹰 、百度内网监控平台 NetRadar 等系统的研发和优化工作。在网络采集、网络异常检测、系统可用性方面有广泛的实践经验。
干货概览
百度外网质量监控平台 猎鹰 实时监控百度的外网访问质量,已实现分钟级的外网故障发现和告警,保障每日数百次亿次用户请求的响应。《 百度网络监控实战：猎鹰一战成名 》系列文章将详细介绍百度面临的典型外网监控场景、需求及百度实现外网监控的原理和百度外网质量监控平台猎鹰的系统架构、核心功能。
背景介绍
百度服务器每天会收到数百亿次来自用户的请求,这些请求在到达百度服务器之前,需要在百度外的公共网络上经过多层网络设备（如运营商接入交换机等）和链路（如运营商骨干网链路、省网链路等）的转发及传输。公共网络中的设备或者链路故障,会导致部分用户无法正常访问百度的服务,影响用户体验。因此,需要对用户到百度的外网连通性进行实时监控,在故障时引导用户流量绕过故障设备／链路,从而提高用户体验。
猎鹰 作为百度外网质量监控平台,对整个百度的外网访问质量进行实时监测,实现了分钟级的外网故障发现和告警,同时提供丰富的数据可视化展示,为百度服务的可用性保驾护航,成为百度运维工程师日常工作的必备利器之一。
接下来, AIOps智能运维 将分上、下两篇对百度外网质量监控平台 猎鹰 进行介绍,本篇主要介绍外网监控概述、外网故障场景以及相关需求。 一 外网监控概述
在之前的文章《 百度网络监控实战：NetRadar横空出世（上） 》中,运小贝提到百度拥有数十万台服务器,这些服务器分布在不同地理位置的IDC中。当用户访问百度服务的时候,域名解析服务（DNS,Domain Name System）会给用户返回一个VIP地址（Virtual IP Address, 百度多台服务器形成的一个虚机地址）,然后用户的请求会被转发到这个VIP地址上。用户的请求在到达这个VIP地址之前,依次会经过用户本地接入设备（比如ADSL）→用户所在地域的网络运营商接入设备→运营商骨干网链路→百度IDC所在地域的运营商接入设备→百度IDC的VIP,如图1所示：
图1 用户访问百度服务的请求示例
用户请求在到达百度服务器之前,经过的任何一条链路或者设备出现故障,都有可能会导致用户访问百度服务的体验受到影响（如延时变大或者访问失败）。如图1所示,湖北电信访问www.baidu.com时,默认会被DNS解析到南京机房电信入口的VIP地址。如果南京电信运营商接入设备故障,那么湖北电信用户就无法正常访问了。这时,我们可以将www.baidu.com的域名解析映射关系更改到北京机房电信入口的VIP地址上,则可恢复用户的正常访问。
因此,准确快速地发现这些外网故障,对于保证用户访问体验的重要性不言而喻。 二 外网故障场景
我们将用户请求在外部网络途经的设备和链路按照它们所在的位置划分为三级：用户侧链路及设备、骨干网链路及设备、百度侧链路及设备,如图2所示：
图2 外网设备及链路位置划分
用户侧的链路和设备主要负责一个省份的网络通信。而骨干网主要负责若干相邻省份的网络通信,骨干网络与省份的覆盖关系由运营商确定。不同位置的链路/设备的故障会表现出不同的现象,具体如图3所示：
图3 外网故障场景举例 外网故障场景如果用户侧设备/链路出现故障,即用户所在省份的网络设备/链路出现故障,则表现出的现象是该省份到百度机房入口的访问不通畅。 如果骨干网设备/链路出现故障,则表现出的现象是多个省份到百度机房入口的访问不通畅。 如果是百度侧设备/链路故障,则表现出的是全国绝大部分省份到百度机房入口的访问不通畅。
为了便于后文的描述,我们称这三种故障为： 单省份故障（用户侧设备/链路故障） 骨干网故障（骨干网设备/链路故障） 机房侧故障（百度侧设备/链路故障） 三 需求调研
那么对于百度的运维工程师和网络组工程师来说,日常工作中对外网监控系统有哪些通用需求呢？通过对运维工程师和网络组工程师进行相关调研,整理需求如下： 1 真实反映用户到百度IDC间的网络访问质量
对于运维工程师来说,他们真正关注的是会影响到用户访问体验的网络故障,因此,真实反映用户到百度IDC间的网络访问质量是外网监控系统进行网络质量监测的基础。 2 覆盖全国三大运营商的各个省份
百度服务每天会收到数百亿次来自三大运营商各个省份的用户请求,为了尽可能多地发现用户端到百度IDC间的网络问题,监测点应当尽量覆盖三大运营商的各个省份。 3 准确快速地主动告警,确定故障类型及影响范围
当出现网络故障时,需要能够快速检测出故障并进行主动告警,而且需要确定故障类型（机房侧故障 or 骨干网故障 or 单省份故障）,以便于采取何种策略进行止损,并且需要确定故障影响范围（即哪些业务线受到影响了）,没有受到影响的业务线的运维工程师不需要收到故障告警。同时,为了尽可能地缩短服务受网络故障影响的时间,需要尽可能快地检测出故障。 4 支持不同视角的可视化展示
运维工程师通常情况下只关注与其服务相关的网络质量视图,而网络组工程师通常需要关注全局的网络质量视图,因此需要提供多种不同视角的网络质量视图,让运维工程师和网络组工程师都能够快速地获取到其关心的网络质量视图。
总结
本文从宏观上介绍了百度外网质量监控的意义、外网故障场景分类以及百度运维工程师对外网监控系统的需求。在《百度网络监控实战：猎鹰一战成名（下）》中,我们将详细介绍外网监控的实现原理以及猎鹰的系统架构,请持续关注 AIOps智能运维 。
若您有其他问题或者想进一步了解 猎鹰 ,欢迎通过留言与我们交流！
原文链接地址： https://developer.baidu.com/topic/show/290312
本文作者：AIOps智能运维
对于运维可视化,在前面的文章 《运维可视化 | 漫谈内网监控可视化》 中详细介绍了能将内网监控中的异常情况可视化的 事件流图 。本文将从可视化角度继续分析,百度内网监测系统（NetRadar）如何通过可视化手段展示在某个时刻内网中存在哪些异常,从而让运维工程师直观地知道内网的哪些部分受到了异常的影响。
机房连通性可视化
当运维工程师发现自己的系统出现异常,并通过事件流图得知内网存在异常后,他需要进一步得知这些异常影响了内网的哪些部分,从而判断内网的异常是否造成了自己系统的故障。在这种情况下,运维工程师希望能够有一个视图直观地展示异常的影响范围。具体来说影响范围包括： 哪些机房之间的 连通性 有异常 哪些机房的 内部网络 存在异常 连通性异常是否是 地域性 的 备注：一个区域包含多个机房,比如有华北区域包括4个机房,华东区域包括4个机房,华南区域包括3个机房。区域之间通常用跨区域的链路连接。跨区域链路出现故障时,会导致两个区域中的机房互相不能连通。
可视化网络状态的方法包括两种：图（graph）和连通性矩阵。在图中,每个节点代表一个 网络实体 ,比如交换机、路由器、主机等,每条边代表网络实体之间的 链路 。在连通性矩阵中,网络实体对应矩阵的 行和列 ,矩阵中的元素表示所在行和列对应的网络实体之间的链路。根据上述的需求,我们可以看出工程师们主要关注机房之间的连通性情况。如果用图的方式表达,就会形成一个 全连通图 ,图中大量的边不利于工程师掌握网络总体状态。因此,我们决定使用连通性矩阵的可视化方法。
1 连通性矩阵
假设有a1, a2, a3, a4四个机房,可以用一个4行4列连通性矩阵来表示,其中机房ai对应矩阵中的第i行和第i列。矩阵中第i行第j列的元素描述的就是机房ai到机房aj的连通性状态,如下图：
图1 连通性矩阵
我们不妨用bij来表示矩阵中位于第i行第j列的元素。图中存在一个红色的圆点,位于b32,以及一个灰色的三角形,位于b44。
b32的红色的圆点代表机房a3到机房a2的链路出现了异常。在矩阵中,与b32对称的元素b23代表的是机房a2到机房a3的链路状态。b23和b32说的都是机房a2和机房a3之间的链路,只是方向不同,这正好可以表达内网监控系统的探测方向。为了探测网络连通性,监控系统在服务器之间发送 探测包 。比如,服务器x给服务器y发送了一个探测包,y收到探测包后给x发送一个 响应包 。如果x收到了响应包,就认为x到y的链路没有问题。反过来,y也可以给x发送探测包,x发送响应包。这说明内网监控系统的探测是存在方向性的。所以图中b32有红点,b23没有点的意思就是：机房a3的服务器主动发送探测包探测机房a2中的服务器,存在大量丢失响应包或者延迟显著增大的情况,连通性有异常；而机房a2的服务器主动发送探测包探测机房a3中的服务器,响应包基本都能正常到达。两个探测方向结论不一致主要是由机房的网络出口和入口设备不同,并且单一设备出故障导致。
b44的灰色三角形代表的是机房a4的机房内网络存在异常。连通性矩阵的主对角线元素bii都代表机房内网络的状态。为了能够与机房间网络有更直观的区分,我们选择了三角形来表示。
最后,颜色代表了异常的程度,红色代表异常程度比较严重,灰色代表异常程度比较轻微。所以图1中a3到a2的机房间网络存在比较严重的连通性异常,而a4的机房内网络则存在比较轻微的连通性异常。
当连通性矩阵中存在多个异常点时,这些点可以形成 特定的模式 ,分别代表不同的网络问题。下面,我们就来分析几种常见的模式。
2 单机房出/入口链路问题
在连通性矩阵图中,可能会出现整行红色圆点。
图2.1 单机房出口链路问题
图2.1存在三个红色的圆点,分别位于b31, b32, b34位置。这就是整行红色圆点的情况。 每个点的含义如下：b31代表的是a3到a1的链路有异常,b32是a3到a2的链路有异常, b34 表示a3到a4链路有问题, 从这几个链路问题来看,链路都是从a3出来的,所以a3的出口链路出现了故障。
当然有可能出现整列红色圆点的情况,如下图所示：
图2.2 单机房入口链路问题
图2.2的三个红色圆点,分别在b13, b23, b43位置, 同理： b13表示a1到a3的链路有问题, b23说明a2到a3链路有故障, b43呈现a4到a3的链路问题,这一列的链路问题,说明a3的入口链路出现的异常。
是不是有整行,整列的红点情况呢？
图2.3 单机房出入口链路问题
图2.3包含了6个红色圆点,是图2.1与图2.2的集合, 整行与整列的异常代表a3的出/入链路都出现异常。
3 单机房核心设备问题
图2.1,图2.2,图2.3都看到b33这个点是没有状态的,那如果在b33的点的异常情况也加上有表示什么呢？看如下可视化方式：
图3 单机房核心设备问题
图3所示,除了图2.2中的6个红色圆点,还在b33中有个红色的三角, b33位置的三角刚好在矩阵图的主对角线上,代表a3机房内网络出现故障。图3的6个红色圆点说明a3的出/入链路出现网络异常,红色三角说明a3单机房核心设备也出现故障。
4 区域链路问题
通常,网络不是只在某一个区域,有可能同时有华北区域a1, a2, a3, a4四个机房,华东区域b1, b2, b3, b4四个机房,华南区域c1, c2, c3, c4四个机房,如下图所示。
图4.1 区域链路问题
图4.1,我们可以看出机房分别用三个颜色来标识：紫色,蓝色,绿色。这几个颜色在右上角有说明分别代表华北区域,华东区域与华南区域。同时,图中在蓝色区块的华东区域（b1, b2, b3, b4机房）两个区块有大批红点出现,呈现两个矩阵形状的圆点,这说明华东区域的链路问题导致机房互相不能连通。那如果,我们想对区域进行筛选,只查看华北,华南的区域之间的情况呢？如下图所示：
图4.2 区域筛选链路问题
如图4.2中只有一个红色三角与红色圆点,与图4.1相比,这里筛选掉了图4.1华东区域的所有异常, 我们从图4.2中,能看到一个细节问题,鼠标移动到异常点的时候,出现“进入c3-a4机房详情页 ”tooltip信息,点击这个异常点,可以进一步查看这俩机房间的异常事件与相关的指标趋势。如果想要知道a4机房内的详情情况,可以点击这个异常点详情查看,然后我们可以进一步观察a4内部集群之间的网络连通性, 集群的网络连通性跟机房连通性矩阵的方式是一样的,就不详细展开了。 总 结
矩阵图的最大优点在于, 寻找对应元素的交点 很方便,而且不会遗漏, 显示对应元素的关系 也很清楚。所以是一种很好的方式来可视化机房连通性的异常状况。从内网连通性矩阵图来看,可视化能让运维由繁化简,关键是我们如何从业务角度出发,用可视化手段来表达运维数据,在智能运维场景中,我们结合业务,抽象出这些可视化组件,单独看这些可视化组件没那么神奇,如果我们把它们放在一起,就得到了运维通用的解决方案。后面我们还会持续发布可视化相关的文章,请持续关注百度的AIOps智能运维公众号。
原文链接地址： https://developer.baidu.com/topic/show/290311
本文作者：AIOps智能运维
干货概览
运维可视化 ,核心是将所运维的服务、资源、设备的状态和正在发生的事件通过可视化的手段呈现出来,指导运维人员或者产品研发人员做出正确的运维决策。某种程度上,运维与可视化相辅相成, 可视化程度越高,运维就越简单,运维效率也就越高 。
在运维的工作范畴中, 实时监控 对故障的发现和诊断起到至关重要的作用。今天,我们以监控中的一个重点场景－内网监控,来介绍可视化起到的重要作用。内网指的是一个公司的内部网络,包括 机房内部网络和机房间的网络 。
异常事件可视化
当运维工程师发现自己负责的系统出现故障时,检查网络连接是否有异常,是故障排查流程当中的标准步骤。在这个场景中,工程师需要知道自己的系统所在的机房以及所依赖的网络通路是否存在故障,所以希望内网监控系统提供一个 网络故障概览 ,展示在给定的时间段中相关机房的异常事件。
最简单的方式是将所有的网络故障展示在表格当中。如上表所示,每一行代表一个故障事件,第一列表示故障关联的机房,第二列是故障的起止时间,第三列是故障的严重程度。这种展现方式存在以下三个问题： 不能第一眼看出哪些故障严重,哪些故障轻微； 不能直观感受到每个故障的持续时长； 很难知道在某一时刻哪几个机房同时存在故障。
当时间段很长,筛选出的故障事件很多时,表格会变得很长,就更加不利于工程师了解网络状况了。
为解决以上问题,我们需要在 机房、时间、 程度 三个维度上都能直观的展示故障事件。从时间跨度来想,有点事件流的感觉,似乎可以用事件流图来展示。
图1 事件流图
如图1所示,事件流图用一条事件河流来表示事件。河流被横向切分为若干条色带, 每条色带代表一个类别的事件 。色带的高度（河流的宽度）代表在某个时刻,各类别包含事件的个数。事件越多,河流越宽,反之越窄。
这种事件流图适合展示在一段时间内事件群体的统计变化,而我们需要能够展示每个事件的个体信息。因此,我们对事件流图作了几个修改： 每个故障事件用一个矩形条表示,矩形条左右两边的位置对应事件的起止时间； 矩形条的颜色用来区分事件的严重程度,而不是事件的类别； 关联到某一个机房的故障事件矩形条放在河流的同一个高度位置。如果事件在时间上能完全错开,则将矩形条左右放置。如果事件在时间上有重叠,则拓宽机房所占河流的宽度,将矩形条上下放置。
图2 异常事件流图
图2展示了我们的事件流图方案。图中展示了三个机房的异常,其中机房一有一个严重的异常事件（用红色来标识）,这个异常事件是一个时间跨度比较长的严重异常事件,机房二有4个轻度的异常事件（用黄色标识）,这4个异常是时间跨度比较短的轻度异常事件,机房三有12个轻度的异常事件（用黄色标识）,这12个异常事件中也有三个时间跨度比较长的时间。如果鼠标放置在异常事件矩形块上,能查看哪个机房出现异常。通过这个图,工程师可以很方便地看到每个机房的 每个故障事件的详细信息 ,比表格的方式直观得多。
总 结
事件流图, 从机房、时间、异常程度三个维度都能直观的展示故障事件,帮助工程师快速查看异常情况。其实,事件流图还可以用于 展示变更事件 ,甚至可以将变更事件与异常事件组合,让工程师能一眼查看异常事件可能是由哪些变更事件引起的。我们从智能运维场景中抽象出一些可视化组件,比如这里的事件流图组件,再通过前端工程化工具把这些子元素串联起来,构建出前端统一展现层框架, 后面我们会逐一介绍这些可视化组件与框架其他细节,请持续关注我们的AIOps智能运维公众号！
原文链接地址： https://developer.baidu.com/topic/show/290310
作者：Dan Meyer
译者：罗广明
审校：马若飞
英文原文地址： https://www.sdxcentral.com/articles/news/kongs-kuma-service-mesh-climbs-the-kubernetes-wall/2019/09/
转载自： https://www.servicemesher.com/blog/kong-open-sources-kuma-the-universal-service-mesh/
编者按
2019年9月10日,Kong正式宣布开源一款Service Mesh：Kuma。此消息一出,立即在云原生社区引起反响,各大媒体争相报道。让我们跟随SDxCentral的总编辑,一起来看看Kong的CTO如何介绍Kuma这款Service Mesh产品以及对于SMI的看法。关于Kuma的具体功能介绍可以阅读 官网博客 以及 Github 。
翻译一下其Github关于Kuma功能特性的简介如下,方便读者了解： 通用的控制平面 : 易于使用,分布式,可以在任何平台运行。 轻量的数据平面 : 基于Envoy,可处理任意类型流量。 自动化 : 在K8s平台上部署无需任何代码改动,也可在虚拟机上灵活部署。 多租户 : 可在一个集群与同一个控制平面上部署多套服务网格。 网络安全 : 自动mTLS加密。 流量分割 : 灵活的ACL规则。 流量追踪 : 与Zipkin和Jaeger自动集成。 流量指标 : 与Prometheus/Splunk/ELK自动集成。 代理配置模版 : 方便进阶(收费)用户配置Envoy。 标签选择器 : 可应用不同地域的、特定于云的和面向团队的策略。 平台中立 : 支持K8s, 虚拟机和裸机。 强大的APIM Ingress : 与Kong网关集成。
简介
Kong正在将其服务网格平台Kuma打造成一个日益复杂的生态系统,在过去几个月里,许多新加入者和选择涌现出来。
该公司声称Kuma是“一个通用的服务网格”。Kong CTO和联合创始人Marco Palladino解释说,这意味着Kuma不同于市场上的大多数服务网格项目,它的设计初衷是在 Kubernetes 生态系统内部和外部都能工作,这包括虚拟机(VMs)、 容器 、legacy环境以及Kubernetes。
Kuma包括一个基于Envoy服务代理的通用控制平面。它结合了数据平面和进阶的控制平面,允许用户使用本地自定义资源定义(CRDs)或RESTful API设置权限、获取指标和设置路由规则。Palladino解释说,早期第一代的服务网格产品大多缺乏成熟的控制平面,需要大量的二次开发或手工定制。
他解释说：“我们希望90%的 用例 都易于使用,并且能够快速升级。对于另外10%用例的用户,我们有一个允许用户深入使用的策略,”他补充说,尽管Kuma的设计是为了方便使用,“但Kuma是为企业设计的,而不是业余爱好者。”
Kuma的特性包括 software-defined security ,它支持所有四层通信流的 mTLS 身份验证；能够实现追踪(trace)和日志(log)记录,从而更好地分析指标；提供流量控制能力,如断路器和健康检查,以增强四层路由。
Palladino说,Kuma保护底层网络的能力提供了可靠性和更深层次的可观察性,并且无需修改任何代码。
Palladino说：“我们努力为Kuma构建一个非常平滑渐进的学习曲线。它的复杂度不会在早期压垮开发人员,并且也不会阻止开发人员走得更远。我们确实为高级用户提供了一个策略来配置底层代理数据平面。”
Kuma还利用了Kong同名的 开源API网关 。该网关管理组织与部署现代 微服务 的各种方法之间的信息流。
Kuma加入服务网格竞争行列
Kuma加入了服务网格竞争行列,这个群体与日俱增,声称可以更容易地支持微服务的部署。
Palladino说：“每个人都告诉我们,他们想要使用服务网格,但实际上没有一种服务网格易于使用,而且真正适用企业生产环境。许多企业专注于Kubernetes,但对他们来说,这成为了云原生探索之旅的终点。我们提供了一个产品,允许他们拥有一个可以更早实现并支持他们迁移的服务网格。”
一个已经引起广泛注意的服务网格平台是 Istio 。它定位于网络层,使用底层进行微服务开发和维护。这允许将管理运维与应用程序开发分离开来。
Palladino说,Istio帮助照亮了这片天空,但它仍然“非常复杂,有很多活跃的部件”。它在Kubernetes上运行得很好,但并不是所有人都在运行Kubernetes。”
他说,这种关注还会影响Linkerd和Containous等其他服务网格的选择,比如最近推出的 Maesh平台 。
“Maesh、Linkerd和其它控制平面网格都高度关注Kubernetes,”Palladino解释说。“只有当企业采用Kubernetes时,它们才会被采用。我们通过在这一过程的早期建立安全和可观察性,实现了向Kubernetes的过渡。”
还需要努力协调服务网格平台之间的互操作性。其中之一由微软牵头,它在今年早些时候率先推出了服务网格接口 SMI 规范。它的目标是为开发人员提供运行在Kubernetes上的不同服务网格技术的互操作性。
Palladino将这种努力淡化为边缘化服务网格功能。
“我们根本不相信SMI,”他说。“这是将接口标准化的另一种尝试,让它变得平庸而不优秀。它采用整个社区所有服务网格的公分母,从而降低了它们对最终用户的价值。它界限很宽,但并不深入。”
Palladino认为Kuma才真正实现了可以在所有平台进行互操作。
Kong以Mashape的名字成立于2009年。2015年,它将Kong平台发布到 开源 社区,并于去年对旗下所有业务产品 正式启用 了该平台的名称。该公司已通过5轮融资 筹集 了6,910万美元资金,最近一次是在3月份的C轮融资,总额4,300万美元。
编者后记
当Istio因其性能表现疲软之际,会涌现一个又一个的新玩家,给市场带来竞争与多样性,这也是用户喜闻乐见的。Kong涉足服务网格并不算太意外,我们可以了解到除了市面上的传统云厂商打造的和开源的各项服务网格产品,Consul Service Mesh的出现也让人眼前一亮。Consul Service Mesh与Kuma背后的厂商均有其成熟的开源产品做强力支撑：Consul的服务发现与注册产品,Kong的网关产品。他们各自在开源社区拥有一片天下,此时推出服务网格产品自然会有一大批“拥趸”。
Kuma的性能较之Istio以及其它服务网格产品的优劣尚未可知,但是其平台中立的思想还是值得借鉴。当前市场上,K8s并未完全普及,很多公司的产品都是部署在虚机甚至裸机上,如果此时又想尝试下服务网格技术,Kuma的出现不失为一种惊喜。
ServiceMesher 社区是由一群拥有相同价值观和理念的志愿者们共同发起,于 2018 年 4 月正式成立。
社区关注领域有：容器、微服务、Service Mesh、Serverless,拥抱开源和云原生,致力于推动 Service Mesh 在中国的蓬勃发展。
社区官网： https://www.servicemesher.com
最近这几年不知道大家有没有发现,就是传统的PC不在是企业办公时的唯一选择了,有很多的企业开始慢慢的把传统PC换成了更为小巧的 云终端 来进行上网办公的,换成云终端后真的可以达到传统PC一样的使用效果的吗,把传统PC换成云终端后,有怎样的不同体验的。
首先桌面的运算不同,虽然说我们使用云终端登录后系统界面和我们使用传统PC时是一样的,都是我们熟悉的Windows系统界面,但是在使用时我们会发现,登录云终端后系统桌面所显示的配置和云终端本身的配置并不是一样的,桌面性能的强弱更多的是取决于服务器所分配该终端用户所使用虚拟机资源的强弱。
第二数据的存储不同,虽然说有些片子高一点的云终端本身有一定的硬盘容量具备存储数据的功能,但是系统桌面所运行的数据并不是存储在云终端本地的,所有的数据都是存储云端服务器上,通过服务器进行统一的管理和运行,任何人访问重要数据或者想通过云终端来拷贝数据都需要得到授权才可以。
第三外设的支持不同,毫无疑问对于U盘等存储工具和打印机等常用的外设设备,云终端是完全可以支持的,但是对于一些其他的比较特殊或者不常用的外设设备如U盾等一些设备,由于桌面系统使用的是服务器上的虚拟机,所以对于这些外设设备,云终端的支持力度是没有使用传统PC时这么好用的。
第四故障的维护不同,那么传统PC换成云终端后对于故障的维护又有什么不一样的体验的呢？换成云终端后因为使用的都是服务器上分配的虚拟机系统,所以一旦系统出现故障,只需要在服务器上就可以完成系统的维护,而硬件方面由于云终端本地不就行运算和存储,当硬件出现故障后,直接换一个就可以,不用担心因更换设备而担心性能和数据这些问题的。
虽然一直都在说云终端的用户体验和传统的PC基本无差别的,但是真正使用和对比之后会发现,他们两者之间还是有不一样的体验的。
来源禹龙云
本文作者：AIOps智能运维
在之前的系列文章《百度网络监控实战：NetRadar横空出世》中,我们介绍了百度内网质量监测平台NetRadar的原理和架构,其中, 判障算法 是内网监测系统的重要一环,今天我们将详细介绍在NetRadar中实际使用的一种判障算法——基于二项分布的网络判障算法。
业务场景
我们的内网监测系统 NetRadar 实时对百度内网连通性进行探测并根据探测数据判断是否存在网络故障。以探测机房A到机房B的连通性为例,如下图所示,首先从机房A和B中选择n个服务器对 ,机房A中的服务器 去探测机房B中的服务器 ,每次探测有 成功/失败 两种结果。在每个探测周期内,我们会收到n个探测数据,其中m个数据探测成功,(n-m)个数据探测失败。
理论上,在网络状态正常的情况下,m/n=100%。但实际中,由于服务器自身问题（发起探测的服务器负载过高、被探测的服务器重启等）以及一些偶然因素,少量的探测失败是不可避免的,所以需要设定一个判断网络是否故障的 阈值 。
阈值设定
在实际设定阈值的过程中,我们遇到两个问题： 单服务器故障导致产生探测数据的噪声
如前面所述,当服务器a探测服务器b时,如果服务器b自身故障（负载过高或者遇到机器重装、重启等）或遇到其他偶然因素,探测也可能失败,但并不能说明此时存在网络问题,这种情况我们称为 数据噪声 。
虽然单台服务器故障的概率不高,但在大量服务器参与的网络探测中,服务器故障产生数据噪声几乎是常态。 不同探测任务样本数差距大,受噪声影响,小样本的探测任务更难进行准确判障
由于网络结构的多样性,不同探测任务的 样本数 差距很大。例如在机房A到机房B的探测中,样本数与机房内服务器数量相关,如果A机房内服务器数量少,则探测样本也少。实际中,不同任务的样本数变化范围从几十到几千。
对样本量大的探测任务,数据噪声对判障结果影响不大,但 小样本 的探测任务却非常容易受噪声影响。
例如某探测任务有100个样本,某个周期收到60条成功数据,40条失败数据,成功率只有60%,显然,此刻的网络存在故障。但如果另一个探测任务只有5个样本,在某个周期收到3个成功样本,2个失败样本,成功率同样为60%,但我们很难判断这2条数据是探测数据噪声还是真的存在网络问题,所以不能直接使用固定的阈值判断网络故障。
另外,如之前的文章《百度网络监控实战：NetRadar横空出世》所述,NetRadar的探测任务数量很大,判障算法要求是 通用的 、 低开销的 、 高鲁棒性的 。因此,也不能针对具体的探测任务训练专门的阈值,这样会给系统的后期维护增加很大成本。
基于二项分布的网络判障算法
在本文描述的网络判障场景中,每个探测任务每周期收到相互独立的n个成功/失败样本,其中在网络正常的情况下每次探测以一定的概率p返回成功,这正符合概率统计中 二项分布 的定义。
1、二项分布
首先,简单回顾一下概率统计中的二项分布。
二项分布是n个独立的 伯努利试验 中成功次数的 离散概率分布 ,其中每次试验成功的概率为p。
如果随机变量X服从二项分布,那么在n次试验中,恰好得到m次成功的概率为：
其中,
累积分布函数 可以表示为：
2、二项分布在判障中的应用
回到我们的场景中,对于一个探测任务来说,在一个周期内收到n个样本,其中m个成功样本,同时,根据历史数据可以确定在网络正常的情况下,一次探测成功的概率为p（由于服务器本身的问题和其他客观原因,在网络正常的情况下也有可能得到探测失败的样本, p值就是描述在网络正常的情况下探测成功的概率 ）。一个周期内的样本相互独立。很显然探测样本X服从 参数为n和p的二项分布 。
当一个周期内收到的n个样本中包含m个成功样本,如何判断此时网络是正常还是异常呢？我们实际上是 通过判断m是否太小了来确定是否有网络故障 。也就是,可以通过计算累积分布函数 判断：
如果 过低（ ,其中 是我们预先设定的一个概率阈值）,说明在正常的网络状态下,n个样本中收到小于等于m个正常样本的概率很低,可以判断这时网络是异常的。
然而当n很大时, 需要多次计算 ,在每个周期有上百万数据需要计算的情况下,对CPU资源消耗很大。
不过根据 中心极限定理 ,我们知道：
二项分布当n足够大时,
近似服从期望为0,方差为1的正态分布,即 标准正态分布 。
以此为依据,计算 Z-score ：
根据对历史数据的标注和训练可以得到z的阈值,使用阈值进行网络判障。
3、实际效果
实际运行中的一组网络正常和异常时成功率和Z-score分别如下图所示,可以看到,如果在成功率上设置阈值,很难找到一个较好区分网络正常和异常的阈值,但使用二项分布则可以很容易确定区分正常与异常的阈值。
算法的扩展和应用 ：本文介绍的基于二项分布的判障算法,应用场景并不仅限于网络监控,实际上这个算法可以应用于所有的成功率检测,只需针对固定场景确定参数p和阈值。
总结
本文从网络监测中遇到的实际问题出发,介绍了基于二项分布的判障算法,在内网监测系统中有效地解决了不同探测任务样本数差异大且可能存在数据噪声等实际问题,尤其在小样本的判障中表现优异。
若您想进一步了解内网监测问题,欢迎给我们留言！
原文链接地址： https://developer.baidu.com/topic/show/290309
Author: xidianwangtao@gmail.com 摘要：Kubernetes的资源编排调度使用的是静态调度,将Pod Request Resource与Node Allocatable Resource进行比较来决定Node是否有足够资源容纳该Pod。静态调度带来的问题是,集群资源很快被业务容器分配完,但是集群的整体负载非常低,各个节点的负载也不均衡。本文将介绍优化Kubernetes集群负载的多种技术方案。
Kubernetes为什么使用静态调度
静态调度,是指根据容器请求的资源进行装箱调度,而不考虑节点的实际负载。静态调度最大的优点就是调度简单高效、集群资源管理方便,最大的缺点也很明显,就是不管节点实际负载,极容易导致集群负载不高。
Kubernetes为什么会使用静态调度呢？因为要做好通用的动态调度几乎是不可能的,对,是通用的动态调度很难都满足不同企业不同业务的诉求,结果可能适得其反。那是不是我们就没必要去往动态调度做技术尝试呢？未必！平台根据托管的业务属性,可以适当的通过scheduler extender的方式扩展Kubernetes Scheduler来做一定权重的动态调度决策。
集群资源构成
以cpu资源为例,一个大规模Kubernetes集群的资源组成结构大致如下：
由以下几部分组成： 每个节点的预留资源,对应kubelet的system-reserved, kube-reserved, eviction-hard配置的资源之和,Kubernetes计算Node的Allocatable资源时会减去这部分预留资源。 目前我们集群的平均资源碎片大概在5%~10%左右,根据不同规格的CVM机型略有不同。这些资源碎片分散在集群中的各个节点,以1c1g, 2c2g, 3cxg为主,平台提供用户选择的容器规格都很难match到这些碎片,经常存在这这种情况：要调度某个Pod时,发现某个节点上的cpu足够,但是mem不足,或者相反。 剩下的就是可以被业务Pod真正分配使用的资源了,业务在选择容器规格时带有一定的主观性和盲目性,导致业务容器的负载很低,这样的业务占比一大就容易导致集群低负载的情况,但是集群按照Kubernetes静态调度策略又无法再容纳更多的业务容器了。如上图中所示的,集群分配cpu水位线很高,但是实际cpu利用率不高的情况。
提升集群负载的方案
除了借助强大的容器监控数据做一定权重的动态调度决策之外,是否还有其他方案可以用于解决静态调度带来的集群低负载问题呢？下面我将给出一整套技术方案,从多个技术维度来尝试提升Kubernetes集群负载。
Pod分配资源压缩
前面提到,研发同学部署业务选择容器资源规格时,带有一定的盲目性,而且Kubernetes原生也不支持实时无感知的修改容器规格（虽然这可以通过Static VPA方案解决）,导致业务容器负载低。为了解决这个问题,我们可以给Pod Request Resource做一定比例的压缩（Pod Limit Resource不压缩）。注意压缩Pod Request Resource只发生在Pod创建或者重建的时候,比如业务做变更发布之时,对于正常运行中的Pod不能做这一动作,否则可能导致对应Workload Controller重建Pod（取决于Workload的UpdateStrategy）对业务带来影响。
需要注意的是： 每个Workload负载变动规律不同,因此Pod分配资源压缩比例也对应不一样,需要支持每个Workload自定义配置,而且这是对用户无感知的。这个压缩比,我们设置到Workload的Annotation中,比如cpu资源压缩对应Annotation stke.platform/cpu-requests-ratio ； 压缩比,谁去设置？自研组件(Pod-Resource-Compress-Ratio-Reconciler)基于Workload的历史监控数据,动态的/周期性去调整压缩比。比如某Workload连续7d/1M的负载持续很低,那么可以把压缩比设置的更大,以此让集群剩余可分配资源更大,容纳更多的业务容器。当然实际上压缩比的调整策略并不会这么简单,需要更多的监控数据来辅助。 Pod分配压缩特性一定要是可以关闭的和恢复的,通过Workload Annotation stke.platform/enable-resource-compress: "n" 针对Workload级别disable,通过设置压缩比为1进行压缩恢复。 何时通过压缩比去调整Pod Spec中的Request Resource？Kubernetes发展到现阶段,直接改Kubernetes代码是最愚蠢的方式,我们要充分利用Kubernetes的扩展方式。这里,我们通过kube-apiserver的 Mutating Admission Webhook 对Pod的Create事件进行拦截,自研webhook(pod-resource-compress-webhook)检查Pod Annotations中是否enable了压缩特性,并且配置了压缩比,如果配置了,则根据压缩比重新计算该Pod的Request Resource,Patch到APIServer。
Node资源超卖
Pod资源压缩方案,是针对每个Workload级别的资源动态调整方案,优点是细化到每个Workload,能做到有的放矢,缺点是业务不做变更发布,就没有效果,见效慢。
Node资源超卖方案是针对Node级别的资源动态调整方案,根据每个节点的真实历史负载数据,进行不同比例的资源超卖。 每个节点的资源超卖比例,我们设置到Node的Annotation中,比如cpu超卖对应Annotation stke.platform/cpu-oversale-ratio 。 每个节点的超卖比例,谁去设置？自研组件（Node-Resource-Oversale-Ratio-Reconciler）基于节点历史监控数据,动态的/周期性的去调整超卖比例。比如某个Node连续7d/1M持续低负载并且节点已分配资源水位线很高了,那么可以把超卖比例适当调高,以此使Node能容纳更多的业务Pod。 Node超卖特性一定要是可以关闭和还原的,通过Node Annotation stke.platform/mutate: "false" 关闭Node超卖,Node在下一个心跳会完成资源复原。 何时通过压缩比去调整Node Status中的Allocatable&Capacity Resource？同样的,我们通过kube-apiserver的 Mutating Admission Webhook 对Node的Create和Status Update事件进行拦截,自研webhook(node-resource-oversale-webhook)检查Node Annotations中是否enable了超卖并且配置了超卖比,如果配置了,则根据安超卖比重新计算该Node的Allocatable&Capacity Resource,Patch到APIServer。
Node资源超卖,表面上看起来很简单,但实际上要考虑的细节还很多： Kubelet Register Node To ApiServer的详细原理是什么,通过webhook直接Patch Node Status是否可行？ 当节点资源超卖后,Kubernetes对应的Cgroup动态调整机制是否能继续正常工作？ Node status更新太频繁,每次status update都会触发webhook,大规模集群容易对apiserver造成性能问题,怎么解决？ 节点资源超卖对Kubelet Eviction的配置是否也有超配效果,还是仍然按照实际Node配置和负载进行evict? 如果对Evict有影响,又该如解决？ 超卖比例从大往小调低时,存在节点上 Sum (pods' request resource) > node's allocatable 情况出现,这里是否有风险,该如何处理？ 监控系统对Node的监控与Node Allocatable&Capacity Resource有关,超卖后,意味着监控系统对Node的监控不再正确,需要做一定程度的修正,如何让监控系统也能动态的感知超卖比例进行数据和视图的修正？ Node Allocatable和Capacity分别该如何超卖？超卖对节点预留资源的影响是如何的？
这里涉及的Kubernetes技术细节比较多,我将在下一篇文章中详细介绍。
优化AutoScale能力
提起Kubernetes的弹性伸缩,大家比较熟悉的是HPA和HNA,一个对Workload的Pod进行横向伸缩,一个对集群中Node进行横向伸缩。社区中还有一个VPA项目,用来对Pod的资源进行调整,但是需要重建Pod才能生效,VPA存在的意义就是要快速扩容,如果像HPA一样,需要重建Pod启动应用来扩容,其实已经失去了价值。
Kube-controller-manager内置的HPA-Controller存在以下问题： 性能问题：一个goroutine中循环遍历集群中所有的HPA对象,针对每个HPA对象获取对应的Pod监控数据、计算新Replicas,这对于大业务是比较耗时的。 核心配置不支持Workload自定义：HPA伸缩响应时间是每个业务都可能不一样的,有些业务期望能5s进行响应,有些业务觉得60s就够了。而内置HPA Controller在响应时间控制上只能配置全局的启动参数 horizontal-pod-autoscaler-sync-period 。还有每个业务对负载的抖动容忍是不一样的,在内置的HPA Controller中只能通过 horizontal-pod-autoscaler-tolerance 做全局配置,无法提供业务级的自定义。 Kubernetes目前对custom metrics的支持,只能注册一个后端监控服务,如果集群中有些业务通过prometheus来expose应用自定义指标,也有一些业务通过Monitor来监控应用自定义指标,这个时候就做不到All in了,这在for自研上云的场景中,是一定存在的场景。
我们自研了HPAPlus-Controller组件： 每个HPA对象会启动一个goroutine协程专门负责该HPA对象的管理和计算工作,各个协程并行执行,极大的优化了性能。HPAPlus-Controller独立部署,其资源需求可以是集群规模和HPA数量进行合理调整,相比于原内置HPA-Controller有更大的灵活性。 HPAPlus-Controller支持各个HPA对象自定义伸缩响应时间,支持自动感应业务是否在变更发布并决定是否要禁用HPA（某些业务有这样的需求：升级时禁止触发弹性伸缩）,支持基于pod resource limit为基数进行Pod资源利用率计算,从而推导出扩缩容后的期望replicas,这一点对于节点超卖和Pod资源压缩后的集群非常重要。 支持业务级别对负载的抖动容忍度的个性化配置。 支持基于更多维度的监控数据进行Scale决策,比如Pod历史7d/1M的cpu负载。 支持CronHPA,满足规律性扩缩容的业务诉求。 通过Extension APIServer的方式对接公司Monitor监控,保留Prometheus-Adaptor的方式来支持基于Prometheus的应用监控,满足基于多种应用监控系统的custom metrics进行HPA。 注意：HPAPlus-Controller与Kubernetes buit-in HPA-Controller存在功能冲突,上线前需要disable kube-controller-manager的HPA-Controller控制器。
除了HPA的优化和增强之外,我们也在进行 Dynamic VPA 技术研发,后续再单独文章介绍。
其他技术方案
另外,通过scheduler extender的方式开发动态调度器、基于业务级的配额动态管理组件、基于业务优先级和配额管理的在线离线业务混部能力、主动探测节点资源碎片信息并上报到控制器进行Pod的再漂移进行资源碎片管理等方案,也是我们正在进行实践的方向,对应方案及实现复杂度更高,后续再单独文章介绍。
总结
本文介绍了Kubernetes静态调度带来的集群资源分配水位线高但集群实际负载低的问题进行了技术方案上的探讨,详细介绍了Pod资源动态压缩、节点资源动态超卖、优化AutoScale的能力的技术方案,后面会再对动态调度、动态业务配额管理、在线离线业务混部方案进行介绍。所有这些集群负载提升方案,要做到动态,都强依赖于强大的容器监控系统。我们正与腾讯云监控产品团队深入合作,更好的服务于腾讯自研业务上云。
本文作者：HelloDeveloper
HTTPS 常见问题解答
1、前言
百度从 14 年开始对外开放了 https 的访问,并于 3 月初正式对全网用户进行了 https 跳转。
很多用户看到这个新闻都比较好奇,在新闻站点,微博,微信和贴吧,知乎等站点进行了热烈的讨论,这里我们也从一个普通用户容易理解的角度来看看大家的问题。
2、https 是什么？我有没有用到 https ？
https 是 http over ssl(Secure Socket Layer),简单讲就是 http 的安全版本,在 http 的基础上通过传输加密和身份认证保证了传输过程中的安全性。你通常访问的网站大部分都是 http 的,最简单的方法可以看看网址是以 http:// 开头还是 https:// 开头。
以下几个截图就是 chrome,firefox,IE10 在使用 https 时的效果。
注意图中绿色的部分 , 我们后面详细说说。
想进一步了解 HTTPS,可以阅读《大型网站的 HTTPS 实践（一）-- HTTPS 协议和原理》
3、https 为什么比 http 安全 ?https 加密 是不是需要我在电脑上安装证书 / 保存密码 ?
http 不安全,主要是因为它传输的是明文内容 , 也不对传输双方进行身份验证。只要在数据传输路径的任何一个环节上,都能看到传输的内容,甚至对其进行修改。例如一篇文章”攻下隔壁女生路由器后 , 我都做了些什么” 中,很多攻击的环节,都是通过分析 http 的内容来进行。而在现实生活中呢,你很有可能泄露你的论坛高级会员账号 / 密码,游戏 vip 账号 / 密码,隐私的聊天内容,邮件,在线购物信息,等等。
https 之所以安全,是因为他利用 ssl/tls 协议传输。举个简单的例子,电影风语者中,美军发现密码经常被日本窃听和破解,就征召了 29 名印第安纳瓦霍族人作为译电员,因为这语言只有他们族人懂。即使日本人窃听了电文,但是看不懂内容也没用；想伪造命令也无从下手,修改一些内容的话,印第安人看了,肯定会说看（shen）不（me）懂（gui）。看到这里,你肯定发现了,这是基于两边都有懂这个语言（加密解密规则）的人才行啊,那么我的电脑上需要安装什么密钥或者证书吗？一般情况作为普通用户是不用考虑这些的,我们有操作系统,浏览器,数学家,安全和网络工程师等等 , 帮你都做好了 , 放心的打开浏览器用就好啦。
如果你实在好奇,想知道双方不用相同的密钥如何进行加密的,可以搜索下” 公钥加密”（非对称加密）,”RSA”,” DH 密钥交换”, “ssl 原理” “数字证书” 等关键词。
有朋友会想了,不就是加密吗,我 wifi 密码都能破,找个工具分分钟就破解了。这个想法可不对 , 虽然没有绝对的安全,但是可以极大增加破解所需要的成本,https 目前使用的加密方式是需要巨大的计算量（按照目前计算机的计算能力）才可能破解的,你会用世界上最强的超级计算机花费 100 年（只是一个比喻）去解密,看看 100 年前隔壁老王在百度上搜什么吗。
4、 百度为什么要上 https?
我们每天会处理用户投诉,比如说: 页面出现白页 / 出现某些奇怪的东西 返回了 403 的页面 搜索不了东西 搜索 url 带了小尾巴 , 页面总要闪几次 页面弹窗广告 搜索个汽车就有人给我打电话推销 4s 店和保险什么的 …
各种千奇百怪的情况 , 查来查去,很大一部分原因是有些坏人在数据的传输过程中修改百度的页面内容,窃听用户的搜索内容。悄悄告诉你,https 就是能解决这样问题的技术哦 , 赶紧把浏览器首页改成 https://www.baidu.com 吧。
从方向上来说,HTTPS 也是未来的趋势,目前大家使用的 HTTP 还是 1.1/1.0 版本的,新的 HTTP2.0 版本的标准已经发布了。标准中涉及了加密的规范,虽然标准中没有强制使用,但是已经有很多浏览器实现声称他们只会支持基于加密连接的 HTTP2.0( https://http2.github.io/faq/#does-http2-require-encryption)。
5、https 不就是在 http 后面加个 s ,很难么？
难,又不难。
它包含证书,卸载,流量转发,负载均衡,页面适配,浏览器适配,refer 传递等等等等。反正我指头肯定不够数。
对于一个超小型个人站点来说,技术宅 1 天就能搞定从申请证书到改造完成。如果是从零开始建设,会更容易。
但是对于百度搜索这种大胖纸来说,可就难了。 它一开始并不是为 https 设计的 内容丰富（内容本身的表现形式很多：图片,视频,flash,form 等等）,种类丰富 (页面上除了自然结果,有视频,图片,地图,贴吧,百科 , 第三方的内容 , app 等等)。 数据来源复杂,有几十个内部产品线的内容,几百个域名,成千上万个开发者的内容 百度在全国,甚至世界范围都有很多 idc 和 cdn 节点,都得覆盖到。 还不能因此拖慢了百度的速度 (国内使用 https 的银行 , 在线交易的站点,有没有觉得很慢？) 上 https 本来就是为了更好的体验,可不能导致大家使用不稳定。
…
想了解更详细的内容,可以阅读《大型网站的 HTTPS 实践（四）-- 协议层以外的实践 [1]》
Google 部署 https 花费了 1-2 年,13 年将证书从 1024 位升级到 2048 位花了 3 个月。百度也是去年就开放了入口和小流量,但是今年 3 月才进行全量上线,可以想像整体的复杂性。
6、 如何看待百度搜索支持全站 https ？
国外的几个大型站点都 https 化了,这是未来互联网的趋势 (有兴趣的同学可以搜索下’http/2’ )。
对百度自身来说,https 能够保护用户体验,减少劫持 / 隐私泄露对用户的伤害。
很多人会有疑惑,我没有被劫持,百度上 https 有什么作用,反而让我变慢了一些。从我们的第一手数据可以看到,劫持的影响正越来越大,在法制不健全的环境下,它被当成一个产业,很多公司以它为生,不少以此创业的团队还拿到了风投。等它真正伤害到你的时候,你可能又会问我们为什么不做些什么。所以,我们宁愿早一些去面对它。
https 在国内的大型站点目前还只用在部分账户的登陆和支付等环节。百度也是国内第一个全站 https 的大型站点,它的用户非常多,流量也很大。百度能够上线 https 会打消大家的疑虑,对其他国内的站点是很好的示范,这个带头作用会显著加速国内互联网 https 的进程,有助于中国互联网的网络安全建设。百度作为搜索引擎,是流量的入口和分发的渠道,后续如果对 https 的站点内容的抓取,标记,权值倾斜,那么更能引导互联网的网站向 https 进行迁移。
7、https 慢不慢 ?
如果什么优化都不做,https 会明显慢很多。在百度已经进行过很多速度优化的条件下,如果站点本身已经做过常规优化,但是不针对 https 做优化,这种情况下我们实测的结果是 0.2-0.4 秒耗时的增加。如果是没有优化过的站点,慢 1 秒都不是梦。至于现在慢不慢呢,大家已经体验了这么多天了,有感觉吗？
答案：A 慢死了,你们在做啥 ? B 有些慢啊 C 还行 , 基本无感 D 啥 , 我已经用了 https 了？
是不是选的 C 或者 D？喂喂,选 A 的那位 你打开别的网站慢么 , 以前没有上 HTTPS 的时候慢么。。。隔壁老王在蹭你网呢。
所以,不是慢,是没有优化。
8、https 耗性能吗 ?
答案是,握手的时候耗,建好连接之后就不太耗了。按照目前加密强度的计算开销,服务器支撑握手性能会下降 6-8 倍,但是如果建立好连接之后,服务器就几乎可能撑住打满网卡的 https 流量了。所以连接复用率的提升和计算性能的优化都是重点。可以阅读《大型网站的 HTTPS 实践（三）-- 基于协议和配置的优化》
9、 劫持有些什么样的途经 ?
你的电脑,你设置的 dns,你的浏览器,你用的网络,都有可能被劫持。
简单和大家介绍下运营商的内容劫持是如何进行的,运营商会分析你的网络请求,它可以先于网站回包,也能修改数据包的内容。所以它可以让你跳转一次,在网址上加上小尾巴,也能在你访问的页面弹出小广告。
感兴趣的话,还可以通过这篇文章看看你的电脑如何被 lsp 劫持的《暗云木马》
10、https 解决了所有劫持问题吗？
俗话说有终有始,我们来说一说文章开始说的浏览器上的绿色标记。它标志着这个安全连接可信赖的级别。绿色通常是好的,黄色则是说明有些不安全,例如在 https 的页面中加载了 http 的资源,这样 http 的资源还是有被劫持的风险。
其实客户端,局域网的风险也很大,恶意插件,木马可以做很多事情,你使用的路由器,DNS 也比较脆弱。如果某个大型网站被标记为了红色,那你就更要小心了 (当然也可能是某个猴子忘记了续费替换证书,导致证书过期了),你有可能遭受了 ssl 劫持 (中间人攻击的一种),特别是遇到如下图提示的时候（访问一些自己签名的站点也会有类似的提示）。中间人攻击还有其他种类的,比如代理你的通信让你退化 http, 还可以利用注入根证书,可以让你浏览器还是绿色的标记,就问你怕不怕？
还是那句话,没有绝对的安全,但是我们可以尽量降低风险。
https 能够在绝大部分情况下保证互联网访问数据传输的安全,这是目前我们力所能及的工作。
原文链接地址： https://developer.baidu.com/topic/show/290306
本文作者：HelloDeveloper
大型网站的 HTTPS 实践（四） -- 协议层以外的实践
前言
网上介绍 https 的文章并不多,更鲜有分享在大型互联网站点部署 https 的实践经验,我们在考虑部署 https 时也有重重的疑惑。
本文为大家介绍百度 HTTPS 的实践和一些权衡 , 希望以此抛砖引玉。
协议层以外的实践工作
全站覆盖 https 的理由
很多刚接触 https 的会思考,我是不是只要站点的主域名换了 https 就可以？答案是不行。
https 的目的就是保证传输过程的安全,如果只有主域名上了 https,但是主域名加载的资源,比如 js,css,图片没有上 https,会怎么样？
从效果上来说,没有达到保证网站传输过程安全的目的,因为你的 js,css,图片仍然有被劫持的可能性,如果这些内容被篡改 / 嗅探了,那么 https 的意义就失去了。
浏览器在设计上早就考虑的这样的情况,会有相应的提示。具体的实现依赖浏览器,例如地址栏锁形标记从绿色变为黄色 , 阻止这次请求,或者直接弹出非常影响用户体验的提示 (主要是 IE),用户会感觉厌烦,疑惑和担忧安全性。
很多用户看见这个链接会习惯性的点” 是”,这样非 https 的资源就被禁止加载了。非 ie 的浏览器很多也会阻止加载一些危害程度较高的非 https 资源（例如 js）。我们发现移动端浏览器的限制目前会略松一些。
所以这里要是没做好,很多情况连网站的基本功能都没法正常使用。
站点的区别
很多人刚接触 https 的时候,觉得不就是部署证书,让 webserver 支持 https 就行了吗。
实际上对于不同的站点来说,https 的部署方式和难度有很大的区别。对于一个大型站点来说,让 webserver 支持 https,以及对 webserver 在 https 协议特性上做一些优化,在迁移的工作比重上,可能只占到 20%-40%。
我们考虑下以下几种情况下,部署 https 的方案。
简单的个人站点
简单的定义：资源只从本站的主域或者主域的子域名加载。
比如 axyz 的个人 blog,域名是 axyzblog.com。加载主域名下的 js 和图片。
这样的站部署 https,在已有证书且 webserver 支持的情况下,只需要把主域名替换为 https 接入,然后把资源连接修改为 https:// 或者 //。
复杂的个人站点
复杂的定义：资源需要从外部域名加载。
这样就比较麻烦了,主域资源容易适配 https,在 cdn 上加载的资源还需要 cdn 服务商支持 https。目前各大 cdn 的服务商正在逐渐提供 https 的支持,需要迁移的朋友可以看看自己使用的 cdn 是否提供了这项能力。一些 cdn 会对 https 流量额外收费。
Cdn 使用 https 常见的方案有： 网站主提供私钥给 cdn,回源使用 http。 cdn 使用公共域名,公共的证书,这样资源的域名就不能自定义了。回源使用 http。 仅提供动态加速,cdn 进行 tcp 代理,不缓存内容。 CloudFlare 提供了 Keyless SSL 的服务,能够支持不愿意提供私钥 , 不想使用公共的域名和证书却又需要使用 cdn 的站点了。
简单的大型站点
简单的定义: 资源只从本站的主域 , 主域的子域,或者自建 / 可控的 cdn 域名加载,几乎没有第三方资源。如果网站本身的特性就如此,或愿意改造为这样的类型,部署 https 就相对容易。Google Twitter 都是非常好的范例。优点：已经改成这样的站点,替换 https 就比较容易。缺点：如果需要改造,那么要很大的决心,毕竟几乎不能使用多样化的第三方资源了。
复杂,访问速度重要性稍低的大型站点
复杂的定义：从本站的非主域,或者第三方站点的域名有大量的第三方资源需要加载,多出现在一些平台类,或者有复杂内容展现的的网站。
访问速度要求：用户停留时间长或者强需求,用户对访问速度的耐受程度较高。比如门户,视频,在线交易类（比如火车票 机票 商城）网站。
这样的站点,可以努力推动所有相关域名升级为支持 https。我们用下图举例说明下这样修改会导致一个网站的链接发生怎样的改变。
负责流量接入的团队将可控的接入环境改造为 http 和 https 都支持,这样前端工程的工作相对就少一些。大部分时候将链接从 http:// 替换为 // 即可 . 在主域名是 https 的情况下,其它资源就能自动从 https 协议下加载。一些第三方资源怎么办？一般来说只有两种选择,一迁移到自己的 cdn 或者 idc 吧,二强制要求第三方自己能支持 https。
以全站 https 接入的 facebook 举例。第三方厂商想在 facebook 上线一个游戏。facebook：请提供 https 接入吧。第三方想：能赚钱啊,还是提供下 https 接入吧。所以,足够强势,有吸引力,合作方也有提供 https 的能力的话,这是完全可行的。如果你的平台接入的都是一些个人开发者,而且还赚不到多少钱的情况下,这样就行不通了。 优点：前端改动相对简单,不容易出现 https 下还有 http 的资源问题。 缺点：通常这样的实现下,用户的访问速度会变慢,比如从5 秒变为 3 秒,如上述的理由,用户还是能接受的。对第三方要求高。
复杂,访问速度有严格要求的大型站点 复杂的定义：同上。 访问速度要求：停留时间不长,用户对访问速度的心理预期较高。 但是如果用户把网站当作工具使用,需要你很快给出响应的时候,这样的实现就不好了。后续几个部分我们介绍下这些优化的抉择。
域名的选择
域名对访问速度的影响具有两面性：域名多,域名解析和建立连接的时间就多；域名少,下载并发度又不够。
https 下重建连接的时间成本比 http 更高,对于上面提到的简单的大型站点 , 可以只用 1-3 个域名就能满足需求,对于百度这样富展现样式较多的搜索引擎来说,页面可能展示的资源种类太多。而不同类型的资源又是由不同的域名 (不同的产品 或者第三方产品) 提供的服务,换一个词搜索就可能需要重新建立一些资源的 ssl 链接,会让用户感受到卡顿。
如果将域名限制在有限的范围 (一般 2-6 个左右),维持和这些域名的连接,合并一些数据,加上有 spdy,http2.0 来保证并发,是可以满足我们的需求的。我们的现状是：百度搜索有数百个资源域名在加载各类的资源。这就变成了如何解决这样的问题：如何用 2-6 个有限的域名提供数百个域名的服务,这就涉及了下一节,代理接入与 cdn。
代理接入
当域名从数百域名缩减到个位数的时候,就不可避免的需要谈到统一接入,流量转发和调度等内容。通常的站点资源大都是从主域名 +cdn 进行加载,所以我们可以把域名分为这两类,进行替换。
替换后的几个 cdn 域名都指向相同的 cname,这样的话意味着用户访问的途径变为如下的方式。
这样 ssl 的握手只在用户和两类节点之间进行,维持连接相对容易很多,也不需要每个域名都去申请证书,部署 https 接入。
这个方式会遇到域名转换,数据透传,流量调度等一系列的问题,需要进行整体设计架构,对很多细节都需要进行优化,在运维和研发上都有不小的投入。
理想的方式：这样就只需要和 cdn 节点进行 https 握手,大幅缩短了握手的 rtt 时间 (cdn 节点一般广泛的分布在离用户很近的地方,而主域节点一般都比较有限). 这样部署会对 cdn 的运维和研发能力有更高的要求。
大家有没发现,这样的接入就把一个复杂的站点变为简单的站点了？
连接复用
连接复用率可以分为 tcp 和 ssl 等不同的层面,需要分开进行分析和统计。
连接复用的意义
HTTP 协议 (RFC2616) 规定一个域名最多不能建立超过 2 个的 TCP 连接。但是随着互联网的发展,一张网页的元素越来越多,传输内容越来越大,一个域名 2 个连接的限制已经远远不能满足现在网页加载速度的需求。
目前已经没有浏览器遵守这个规定,各浏览器针对单域名建立的 TCP 连接数如下：
表格 1 浏览器单域名建立的最大并发连接数
从上表看出,单个域名的连接数基本上是 6 个。所以只能通过增加域名的方式来增加并发连接数。在 HTTP 场景下,这样的方式没有什么问题。但是在 HTTPS 连接下,由于 TLS 连接建立的成本比较高,增加并发连接数本身就会带来较大的延迟,所以对域名数需要一个谨慎的控制。
特别是 HTTP2 即将大规模应用,而 HTTP2 的最大特性就是多路复用,使用多个域名和多个连接无法有效发挥多路复用和压缩的特性。
那 HTTPS 协议下,一张网页到底该有多少域名呢？这个其实没有定论,取决于网页需要加载元素个数。
预建连接
既然从协议角度无法减少握手对速度的影响,那能不能提前建立连接,减少用户可以感知的握手延迟呢？当然是可以的。思路就是预判当前用户的下一个访问 URL,提前建立连接,当用户发起真实请求时,TCP 及 TLS 握手都已经完成,只需要在连接上发送应用层数据即可。
最简单有效的方式就是在主域下对连接进行预建,可以通过请求一些静态资源的方式。但是这样还是不容易做到极致,因为使用哪个连接,并发多少还是浏览器控制的。例如你对 a 域名请求一个图片,浏览器建立了两个连接,再请求一张图片的时候,浏览器很大概率能够复用连接,但是当 a 域名需要加载 10 个图片的时候,浏览器很可能就会新建连接了。
Spdy 的影响
Spdy 对于连接复用率的提升非常有效,因为它能支持连接上的并发请求,所以浏览器会尽量在这个链接上保持复用。
其它
也可以尝试一些其他发方法,让浏览器在访问你的网站之前就建立过 https 连接,这样 session 能够复用。HSTS 也能有效的减少跳转时间,可惜对于复杂的网站来说,开启需要考虑清楚很多问题。
优化的效果
从百度的优化经验来看看,如果不开启 HSTS,用户在浏览器直接访问主域名,再通过 302 跳转到 HTTPS。增加的时间平均会有 400ms+,其中 302 跳转和 ssl 握手的因素各占一半。但是对于后续的请求,我们做到了对绝大部分用户几乎无感知。
这 400ms+ 还有很多可以优化的空间,我们会持续优化用户的体验。
HTTPS 迁移遇到的一些常见问题。
传递 Referrer
我们可以把自己的网站替换为 https,但是一般的站点都有外链,要让外链都 https 目前还不太现实。很多网站需要从 referrer 中判断流量来源,因此对于搜索引擎这样的网站来说,referer 的传递还是比较重要的。如果不做任何设置,你会发现在 https 站点中点击外链并没有将 referrer 带入到 http 请求的头部中（ http://tools.ietf.org/html/rfc7231#section-5.5.2）。现代的浏览器可以用 meta 标签来传递 refer。( http://w3c.github.io/webappsec/specs/referrer-policy )
传递完整的 url
只传递站点,不包含路径和参数等。
对于不支持 meta 传递 referrer 的浏览器,例如 IE8, 我们怎么办呢？
可以采用再次跳转的方法,既然 HTTPS 下不能给 HTTP 传递 referer,我们可以先从 HTTPS 访问一个可控的 http 站点,把需要传递的内容放到这个 http 站点的 url 中,然后再跳转到目标地址。
form 提交
有时需要将 form 提交到第三方站点,而第三方站点又是 http 的地址,浏览器会有不安全的警告。可以和 referrer 的跳转传递采取相似的逻辑。
但是这样对 referer 和 form 等内容的方案,并不是完美的解决方法,因为这样还是增加了不安全的因素（劫持,隐私泄露等 ）。理想情况需要用户升级符合最新规范的浏览器,以及推进更多的站点迁移至 https。
视频播放
简单来说,如果你使用 http 的协议来播放视频,那么浏览器仍然会有不安全的提示。所以你有两种选择,1 让视频源提供 https。2 使用非 http 的协议,如 rtmp 协议。
用户异常
在 https 迁移的过程中,也会有不少热心的用户向我们反馈遇到的各种问题。 常见的有以下的一些情况： 用户的系统时间设置错误,导致提示证书过期。 用户使用 fiddler 等代理进行调试,但是没有添加这些软件的根证书,导致提示证书非法。 用户使用的 Dns 为公共 dns 或者跨网设置 dns,一些请求被运营商作为跨网流量拦截。 连通性有问题,我们发现一个小运营商的 https 失败率奇高,又没法联系到他们,只能不对他们进行 https 的转换。 慢。有时由于网络环境的因素,用户打开其他网站也慢,ping 哪个网站都要 500-2000ms。这时 https 自然也会很慢。
结束语
对于复杂的大型网站来说,HTTPS 的部署有很多工作要完成。
面对困难和挑战,有充足的动力支持着我们前进：https 上线后,劫持等原因导致的用户功能异常,隐私泄露的反馈大幅减少。
热心的用户经常会向我们反馈遇到的各种问题。在以前,有时即使我们确定了是劫持的问题,能够解决问题的方法也非常有限。每当这种时候,自己总会产生一些无力感。
HTTPS 的全站部署,给我们提供了能解决大部分问题的选项。能让一个做技术的人看到自己的努力解决了用户的问题,这就是最棒的收获。
HTTPS 没有想像中难用和可怕,只是没有经过优化。与大家共勉。
原文链接地址： https://developer.baidu.com/topic/show/290305
本文作者：HelloDeveloper
大型网站的 HTTPS 实践（三） -- 基于协议和配置的优化
前言
上文讲到 HTTPS 对用户访问速度的影响。
本文就为大家介绍 HTTPS 在访问速度,计算性能,安全等方面基于协议和配置的优化。
HTTPS 访问速度优化
Tcp fast open
HTTPS 和 HTTP 使用 TCP 协议进行传输,也就意味着必须通过三次握手建立 TCP 连接,但一个 RTT 的时间内只传输一个 syn 包是不是太浪费？能不能在 syn 包发出的同时捎上应用层的数据？其实是可以的,这也是 tcp fast open 的思路,简称 TFO。具体原理可以参考 rfc7413。
遗憾的是 TFO 需要高版本内核的支持,linux 从 3.7 以后支持 TFO,但是目前的 windows 系统还不支持 TFO,所以只能在公司内部服务器之间发挥作用。
HSTS
前面提到过将用户 HTTP 请求 302 跳转到 HTTPS,这会有两个影响： 不安全,302 跳转不仅暴露了用户的访问站点,也很容易被中间者支持。 降低访问速度,302 跳转不仅需要一个 RTT,浏览器执行跳转也需要执行时间。
由于 302 跳转事实上是由浏览器触发的,服务器无法完全控制,这个需求导致了 HSTS 的诞生：
HSTS(HTTP Strict Transport Security)。服务端返回一个 HSTS 的 http header,浏览器获取到 HSTS 头部之后,在一段时间内,不管用户输入baidu.com还是http://www.baidu.com,都会默认将请求内部跳转成https://www.baidu.com。
Chrome, firefox, ie 都支持了 HSTS（ http://caniuse.com/#feat=stricttransportsecurity）。
Session resume
Session resume 顾名思义就是复用 session,实现简化握手。复用 session 的好处有两个： 减少了 CPU 消耗,因为不需要进行非对称密钥交换的计算。 提升访问速度,不需要进行完全握手阶段二,节省了一个 RTT 和计算耗时。
TLS 协议目前提供两种机制实现 session resume,分别介绍一下。
Session cache
Session cache 的原理是使用 client hello 中的 session id 查询服务端的 session cache, 如果服务端有对应的缓存,则直接使用已有的 session 信息提前完成握手,称为简化握手。
Session cache 有两个缺点： 需要消耗服务端内存来存储 session 内容。 目前的开源软件包括 nginx,apache 只支持单机多进程间共享缓存,不支持多机间分布式缓存,对于百度或者其他大型互联网公司而言,单机 session cache 几乎没有作用。
Session cache 也有一个非常大的优点： session id 是 TLS 协议的标准字段,市面上的浏览器全部都支持 session cache。
百度通过对 TLS 握手协议及服务器端实现的优化,已经支持全局的 session cache,能够明显提升用户的访问速度,节省服务器计算资源。
Session ticket
上节提到了 session cache 的两个缺点,session ticket 能够弥补这些不足。
Session ticket 的原理参考 RFC4507。简述如下：
server 将 session 信息加密成 ticket 发送给浏览器,浏览器后续握手请求时会发送 ticket,server 端如果能成功解密和处理 ticket,就能完成简化握手。
显然,session ticket 的优点是不需要服务端消耗大量资源来存储 session 内容。
Session ticket 的缺点： session ticket 只是 TLS 协议的一个扩展特性,目前的支持率不是很广泛,只有 60% 左右。 session ticket 需要维护一个全局的 key 来加解密,需要考虑 KEY 的安全性和部署效率。
总体来讲,session ticket 的功能特性明显优于 session cache。希望客户端实现优先支持 session ticket。
Ocsp stapling
Ocsp 全称在线证书状态检查协议 (rfc6960),用来向 CA 站点查询证书状态,比如是否撤销。通常情况下,浏览器使用 OCSP 协议发起查询请求,CA 返回证书状态内容,然后浏览器接受证书是否可信的状态。
这个过程非常消耗时间,因为 CA 站点有可能在国外,网络不稳定,RTT 也比较大。那有没有办法不直接向 CA 站点请求 OCSP 内容呢？ocsp stapling 就能实现这个功能。
详细介绍参考 RFC6066 第 8 节。简述原理就是浏览器发起 client hello 时会携带一个 certificate status request 的扩展,服务端看到这个扩展后将 OCSP 内容直接返回给浏览器,完成证书状态检查。
由于浏览器不需要直接向 CA 站点查询证书状态,这个功能对访问速度的提升非常明显。
Nginx 目前已经支持这个 ocsp stapling file,只需要配置 ocsp stapling file 的指令就能开启这个功能：
False start
通常情况下,应用层数据必须等完全握手全部结束之后才能传输。这个其实比较浪费时间,那能不能类似 TFO 一样,在完全握手的第二个阶段将应用数据一起发出来呢？google 提出了 false start 来实现这个功能。详细介绍参考 https://tools.ietf.org/html/draft-bmoeller-tls-falsestart-00。
简单概括 False start 的原理就是在 client_key_exchange 发出时将应用层数据一起发出来,能够节省一个 RTT。
False start 依赖于 PFS（perfect forward secrecy 完美前向加密）,而 PFS 又依赖于 DHE 密钥交换系列算法（DHE_RSA, ECDHE_RSA, DHE_DSS, ECDHE_ECDSA）,所以尽量优先支持 ECDHE 密钥交换算法实现 false start。
使用 SPDY 或者 HTTP2
SPDY 是 google 推出的优化 HTTP 传输效率的协议（ https://www.chromium.org/spdy）,它基本上沿用了 HTTP 协议的语义 , 但是通过使用帧控制实现了多个特性,显著提升了 HTTP 协议的传输效率。
SPDY 最大的特性就是多路复用,能将多个 HTTP 请求在同一个连接上一起发出去,不像目前的 HTTP 协议一样,只能串行地逐个发送请求。Pipeline 虽然支持多个请求一起发送,但是接收时依然得按照顺序接收,本质上无法解决并发的问题。
HTTP2 是 IETF 2015 年 2 月份通过的 HTTP 下一代协议,它以 SPDY 为原型,经过两年多的讨论和完善最终确定。
本文就不过多介绍 SPDY 和 HTTP2 的收益,需要说明两点： SPDY 和 HTTP2 目前的实现默认使用 HTTPS 协议。 SPDY 和 HTTP2 都支持现有的 HTTP 语义和 API,对 WEB 应用几乎是透明的。
Google 宣布 chrome 浏览器 2016 年将放弃 SPDY 协议,全面支持 HTTP2,但是目前国内部分浏览器厂商进度非常慢,不仅不支持 HTTP2,连 SPDY 都没有支持过。
百度服务端和百度手机浏览器现在都已经支持1 协议。
HTTPS 计算性能优化
优先使用 ECC
ECC 椭圆加密算术相比普通的离散对数计算速度性能要强很多。下表是 NIST 推荐的密钥长度对照表。
对称密钥大小 | RSA 和 DH 密钥大小 | ECC 密钥大小
----|------|---- 80|1024|160| 112|2048|224 128|3072|256 192|7680|384 256|15360|521 表格 2 NIST 推荐使用的密钥长度
对于 RSA 算法来讲,目前至少使用 2048 位以上的密钥长度才能保证安全性。ECC 只需要使用 224 位长度的密钥就能实现 RSA2048 位长度的安全强度。在进行相同的模指数运算时速度显然要快很多。
使用最新版的 openssl
一般来讲,新版的 openssl 相比老版的计算速度和安全性都会有提升。比如 openssl1.0.2 采用了 intel 最新的优化成果,椭圆曲线 p256 的计算性能提升了 4 倍。( https://eprint.iacr.org/2013/816.pdf )
Openssl 2014 年就升级了 5 次,基本都是为了修复实现上的 BUG 或者算法上的漏洞而升级的。所以尽量使用最新版本,避免安全上的风险。
硬件加速方案
现在比较常用的 TLS 硬件加速方案主要有两种： SSL 专用加速卡。 GPU SSL 加速。 上述两个方案的主流用法都是将硬件插入到服务器的 PCI 插槽中,由硬件完成最消耗性能的计算。但这样的方案有如下缺点： 支持算法有限。比如不支持 ECC,不支持 GCM 等。 升级成本高。 出现新的加密算法或者协议时,硬件加速方案无法及时升级。 出现比较大的安全漏洞时,部分硬件方案在无法在短期内升级解决。比如 2014 年暴露的 heartbleed 漏洞。 无法充分利用硬件加速性能。硬件加速程序一般都运行在内核态,计算结果传递到应用层需要 IO 和内存拷贝开销,即使硬件计算性能非常好,上层的同步等待和 IO 开销也会导致整体性能达不到预期,无法充分利用硬件加速卡的计算能力。 维护性差。硬件驱动及应用层 API 大部分是由安全厂家提供,出现问题后还需要厂家跟进。用户无法掌握核心代码,比较被动。不像开源的 openssl,不管算法还是协议,用户都能掌握。
TLS 远程代理计算
也正是因为上述原因,百度实现了专用的 SSL 硬件加速集群。基本思路是： 优化 TLS 协议栈,剥离最消耗 CPU 资源的计算,主要有如下部分： RSA 中的加解密计算。 ECC 算法中的公私钥生成。 ECC 算法中的共享密钥生成。 优化硬件计算部分。硬件计算不涉及协议及状态交互,只需要处理大数运算。 Web server 到 TLS 计算集群之间的任务是异步的。即 web server 将待计算内容发送给加速集群后,依然可以继续处理其他请求,整个过程是异步非阻塞的。
HTTPS 安全配置
协议版本选择
SSL2.0 早就被证明是不安全的协议了,统计发现目前已经没有客户端支持 SSL2.0,所以可以放心地在服务端禁用 SSL2.0 协议。
2014 年爆发了 POODLE 攻击,SSL3.0 因此被证明是不安全的。但是统计发现依然有 0.5% 的流量只支持 SSL3.0。所以只能有选择地支持 SSL3.0。
TLS1.1 及 1.2 目前为止没有发现安全漏洞,建议优先支持。
加密套件选择
加密套件包含四个部分： 非对称密钥交换算法。建议优先使用 ECDHE,禁用 DHE,次优先选择 RSA。 证书签名算法。由于部分浏览器及操作系统不支持 ECDSA 签名,目前默认都是使用 RSA 签名,其中 SHA1 签名已经不再安全,chrome 及微软 2016 年开始不再支持 SHA1 签名的证书 ( http://googleonlinesecurity.blogspot.jp/2014/09/gradually-sunsetting-sha-1.html)。 对称加解密算法。优先使用 AES-GCM 算法,针对0 以上协议禁用 RC4（ rfc7465）。 内容一致性校验算法。Md5 和 sha1 都已经不安全,建议使用 sha2 以上的安全哈希函数。
HTTPS 防攻击
防止协议降级攻击
降级攻击一般包括两种：加密套件降级攻击 (cipher suite rollback) 和协议降级攻击（version roll back）。降级攻击的原理就是攻击者伪造或者修改 client hello 消息,使得客户端和服务器之间使用比较弱的加密套件或者协议完成通信。
为了应对降级攻击,现在 server 端和浏览器之间都实现了 SCSV 功能,原理参考 https://tools.ietf.org/html/draft-ietf-tls-downgrade-scsv-00。
一句话解释就是如果客户端想要降级,必须发送 TLS_SCSV 的信号,服务器如果看到 TLS_SCSV,就不会接受比服务端最高协议版本低的协议。
防止重新协商攻击
重新协商（tls renegotiation）分为两种：加密套件重协商 (cipher suite renegotiation) 和协议重协商（protocol renegotiation）。
重新协商会有两个隐患： 重协商后使用弱的安全算法。这样的后果就是传输内容很容易泄露。 重协商过程中不断发起完全握手请求,触发服务端进行高强度计算并引发服务拒绝。 对于重协商,最直接的保护手段就是禁止客户端主动重协商,当然出于特殊场景的需求,应该允许服务端主动发起重协商。
结束语
HTTPS 的实践和优化涉及到了非常多的知识点,由于篇幅关系,本文对很多优化策略只是简单介绍了一下 . 如果想要了解协议背后的原理,还是需要详细阅读 TLS 协议及 PKI 知识。对于大型站点来说,如果希望做到极致,HTTPS 的部署需要结合产品和基础设施的架构来进行详细的考虑,比起部署支持 HTTPS 的接入和对它的优化,在产品和运维层面上花费的功夫会更多。本系列的下一篇文章将进一步进行介绍。
原文链接地址： https://developer.baidu.com/topic/show/290304
本文作者：AIOps智能运维
作者简介
喻友文 百度高级前端研发工程师
负责百度智能运维产品（Noah）的前端研发工作,在前端框架、前端工程化等方向有广泛的实践经验。
干货概览
在前面的文章中为大家介绍了百度智能运维团队研发的各类运维管理平台,包括百度内部的系统监控、 外网质量监控猎鹰 、 内网质量监控NetRadar 、 单机房故障自愈 ,对外开放的 标准运维管理平台NoahEE 、 百度云监控 、 智能异常检测 等产品。这些平台覆盖了故障管理、变更管理、容量管理、服务台等多个运维场景。如此繁多的运维管理平台所涉及的前端开发工作量是特别庞大的,特别是运维管理平台的复杂性还很高,涉及大量的前端业务逻辑开发（如操作交互、数据处理、数据可视化展现等）。那么智能运维前端研发团队是如何在人员有限的情况下开发出完善的覆盖百度内外的各类运维管理平台呢？这主要得益于团队根据多年的实践经验推出的 NoahV运维前端研发框架 。下面我们就来详细介绍下NoahV框架是如何提升运维平台前端研发效率,从而帮助团队快速高效的研发运维管理平台。
从运维业务场景出发,寻找解决方案
通过对大量的运维管理平台调研总结,我们发现虽然运维场景是多种多样的,但对应Web平台展现场景其实是可以 收敛 的。基本可以分为如下两类： 1 运维操作类
运维操作一般包括程序部署上线、监控任务创建、故障Case记录、机器上架管理等,这些场景一般都需要输入一些参数用来确认操作的具体过程以及记录操作的一些概要信息,所以这类展现场景采用最多的是使用 表单 方式,运维操作者根据需要输入或者选择一些信息,最后提交,将操作任务交给程序来执行,从而完成一次运维操作。
如图1所示为变更管理中新建部署任务示例,指定上线内容,上线模块,上线之后运行账户、部署路径等信息,提交之后,部署程序将会根据提交信息执行部署上线操作。
图1 新建部署任务示例 2 数据展示类
除上述运维操作之外,另外一个最常见的运维展现场景是数据展示类,如展示历史上线任务信息、监控任务信息、机器域名等资产信息、最常见的展现方式就是使用 表格 将任务展示出来。如图2所示为监控任务列表页面,通过表格一行一行展示监控任务的概要信息。
图2 监控任务列表
另外像监控业务场景中,常常需要比表格更直观的展现数据形式,通常可以采用 趋势图、柱状图、饼图、事件流图 等数据可视化展现形式。如图3所示为某服务在一段时间内的PV情况,使用趋势图展现可以很清晰地看出数据随时间变化和波动的情况。
图3 可视化数据展示示例
既然展现形式是收敛的,那我们可以将这些收敛的展现形式做成 固定的页面模板 ,针对相同的展现形式我们只需复用同一个页面模板。同时通过简化模板的使用,以达到研发效率提升的目标。
页面模板-简化运维前端研发利器
如图4所示为页面模板的构成示意图,在UI组件的基础上通过添加相应的 业务逻辑处理 将运维场景中高频的展现形式做成页面模板,如表单模板、列表模板、数据可视化模板等。
图4 页面模板构成
一般需要在组件基础上添加如下业务逻辑处理： 数据获取、处理、渲染 ：根据数据请求地址和请求参数,通过异步的方式请求到需要展示的数据,并对数据进行过滤、筛选等处理,最终渲染到模板指定区域。 组件布局控制 ：按照不同模板的 使用场景 对模板中所包含的组件进行合理布局展示。 交互事件处理 ：关联处理不同组件的 交互行为 ,如点击查询或者提交按钮时自动获取表单填写的内容并执行查询更新展示数据等。 配置解析 ：主要解析用户提供的模板配置信息,如表单模板项名称、输入类型（输入框、单选框、多选框、下拉框、时间选择框等）、需要执行的操作类型（提交、重置等）。
经过这些业务逻辑处理之后产出的页面模板,只需提供 JSON配置信息 就能轻松产出我们需要的前端展示页面。 1 列表页面模板使用示例
如图5所示为列表模板的使用示例,只需提供如图6所示JSON数据用来描述需要展示的运维对象,就能生成如下图所示的列表页面,开发者不再需要编写复杂的JS代码来处理繁杂的前端业务逻辑,也不需要关心如何获取表格展示数据,如何获取用户填写的表单内容,也不需要关心分页和数据展示的逻辑,极大降低了运维管理平台开发的难度,提升了运维管理平台的开发效率。
图5 列表页面模板示例
图6 JSON配置数据 2 数据可视化模板示例
针对运维业务中数据可视化展现的需求,我们提供了可以 自定义布局 的可视化页面模板,通过与表单模板、列表模板结合从而构成完整的仪表盘功能。仪表盘主要提供页面布局自定义配置(包括组件位置、大小、排版自定义)、组件基础信息的可视化配置（包括数据来源、外观、交互等）、自定义页面的展示和管理等功能。如图7所示为使用仪表盘创建的一个可视化展示页面。
图7 仪表盘示例 3 使用效果
有了这些页面模板,自定义页面布局,仪表盘模板之后,开发者不再需要编写复杂JS处理逻辑,只需提供对应的 配置数据 就可以很方便快捷地搭建出想要的运维管理平台,极大的降低了研发成本,避免了重复编写相同代码逻辑造成的研发效率低下问题。
通过评估：使用页面模板开发相较于直接使用UI组件开发能 提高2-3倍开发效率 ,当前这些页面模板和仪表盘功能能覆盖大部分运维平台的展示需求,已经应用到了资源管理、部署、监控、故障处理等多个运维场景,落地的运维管理系统达20余个。此外针对少部分不能覆盖的情况,我们也提供了基础UI组件库以及运维业务组件库,可以直接使用这些组件来开发需要的页面。
NoahV框架不仅仅是页面模板
除了上述页面模板和仪表盘之外,NoahV框架还提供了一系列研发辅助工具和其他实用的功能模块,覆盖了从开发、构建、到线上运行的各个阶段。如图8所示为NoahV运维框架架构图：
图8 NoahV运维前端研发框架
通过将常见运维平台中的网站导航功能和常见的页面布局形式加入到框架中,实现提供JSON配置就能生成通用的网站导航和布局。
此外我们也结合丰富的运维前端研发经验沉淀出项目开发的最佳实践,包括项目初始目录结构、页面模板复用、开发调试、前后端协作、前端路由管理、编译构建、线上运行统计分析等,同时也将上述部分功能和实践集成到了 脚手架 中,通过输入简单的命令就能很简单高效的完成项目初始化、页面模板复用、项目开发调试。这些工具和功能通过建立规范的前端工程化体系能在页面模板和仪表盘的基础上再次提升运维前端项目的研发效率。
项目案例-NoahEE
图9 NoahEE部署系统
图10 NoahEE部署系统
图11 NoahEE监控系统
图12 NoahEE仪表盘 总 结
目前NoahV框架在百度内部和云上运维产品已经有了较为广泛的应用,同时也已经开源到了 GitHub ,大家有兴趣可以点击 阅读原文（https://github.com/baidu/NoahV） 访问我们的GitHub主页查看使用文档来试用,使用过程中有任何问题都可以通过GitHub Issue或者直接留言反馈给我们。
原文链接地址： https://developer.baidu.com/topic/show/290302
本文作者：AIOps智能运维
作者简介
运小贝 百度高级研发工程师
负责百度内网质量监测平台（ NetRadar ）的业务端设计及开发工作。在系统和网络监控、时序指标异常检测、智能客服机器人等方向有广泛实践经验。
干货概览
百度内网连接着数十万台服务器,承载着全公司业务的网络通信,其通信质量的重要性不言而喻。而百度内网的质量监测平台 NetRadar （网络雷达）,通过对整个内网“服务器端到端”传输质量进行监测,实现了快速、准确地发现、通告、定位内网问题,为百度业务的正常通信提供了有力保障。
《百度网络监控实战： NetRadar 横空出世》系列文章将分上、下两篇介绍 NetRadar 平台,本文主要介绍内网质量监测的意义、相关需求以及百度原有的内网监测技术,而下篇将从核心功能、设计框架、异常检测策略以及可视化视图等方面对 NetRadar 平台进行系统介绍。
百度内网介绍
百度拥有 数十万台 服务器,分布于全国各地的 几十个 数据中心（又称IDC、机房）。这些 海量的 服务器通过网络分层级互联,构成了统一的“资源池”,对外提供可靠、强大的存储、计算和通信服务。
在软件架构上,百度的大型服务一般都是模块化设计,一次服务需要上下游大量模块共同协作完成。为了提高并发服务能力和容灾能力,这些模块会分布式地部署在不同机房的不同服务器上。为保证服务的正常运行,内网必须保证各模块具有良好的 “端到端” 网络通信能力,一旦出现网络故障并影响了模块间的通信,往往会对服务造成影响,甚至导致服务整体不可用。
为了提供高可靠、高性能的端到端通信能力,网络结构在设计上预留了大量冗余,既有设备的冗余,也有线路的冗余。这样一来,两台服务器间的通信可以同时存在许多条不同的路径,能够在一定程度上抵御网络故障。尽管如此,实际环境中端到端的通信问题依然常见,其原因主要包括： 路由收敛延迟、ToR 交换机单点故障、网络拥塞 等等。另一方面,即便单个设备、网线、服务器发生故障的概率很低,乘上巨大的数量,故障必然是“常态”现象。
在这种“与故障为伴”的环境下,既然无法避免故障,就需要能够及时、准确地监测内网质量,这对于保证服务正常运行来说是至关重要的。
需求调研
在运维实践中,工程师对内网质量监测系统都有什么样的需求呢？我们对各业务线的运维工程师,以及来自网络组的同学进行了调研。为了更好地说明用户需求,图1给出了一个典型的运维场景：
当运维工程师发现服务关键指标异常后,如果怀疑是内网故障导致的,则需要通过回答如下一些问题进行排查：
1）“机房A到机房B的网络有问题吗?”
2）“服务器a到服务器b网络有问题吗?”
如果经过检查确认内网没有问题,就要继续排查其他可能的原因,诸如上线、操作、程序 bug 等原因,以帮助进行有效的止损和恢复决策。而如果确定是内网故障导致服务受损,那么网络工程师为了诊断和修复网络故障,会排查一系列的通信问题来帮助缩小故障范围,比如：“哪些服务器通信有问题?”,“哪条链路有问题?”等。为了回答这些问题,最直接有效地方式就是“进行服务器端到端检测”,比如：
1) 排查 “机房A到机房B网络有问题吗?”
可以测试: 机房A大部分机器到机房B大部分机器间的网络质量
2) 排查 “机房A内部网络有问题吗?”
可以测试: 机房A大部分机器互相访问的网络质量
3) 排查 “服务器a到服务器b网络有问题吗?”
只需测试: 服务器a访问服务器b的网络质量
4) 排查 “哪些服务器通信有问题?”
需要挨个ping或ssh疑似有问题的服务器
5) 排查 “在哪条链路上出的问题?”
需要执行traceroute命令查看路由细节
但是,人工执行上述测试任务费时又费力。如图2所示,为了进行一次端到端的网络质量检测,首先要确定“源-目的”服务器,然后获得服务器的登录权限,之后才能登录到机器上执行各种测试操作,最终分析数据得到测量结果。显然,这种人工测量的方式可扩展性很差,无法应对大规模测量的需求。因此,需要一个平台能够 实时地、自动地 执行测量任务,给出分析结果。
那么,这个平台需要满足什么要求呢? 通过对业务线运维工程师和网络工程师进行调研,整理的需求如下：
1）“端到端”的持续监测
由于百度业务线的程序或模块均部署在服务器上,其网络通信也都是从服务器发起和接收,所以服务器“端到端”的网络质量更能反应内网状况对业务通信的实际影响。所以从业务角度出发,平台应当能够对端到端网络质量进行持续监测。
2）全覆盖的监测
实际中,运维工程师通常知道业务部署在哪些机房,但不清楚具体哪些机器间有网络通信,所以会关注 “这些机房网络是否正常”这种全局性的问题。此外,网络工程师的责任是保证整个内网质量可靠,需要系统地监测整个内网性能,尽可能地发现和修复网络故障,减少隐患。
3）按需下发监测任务
实际工作中常常需要根据现场情况执行特定的监测任务,这导致需要进行额外的、有针对性的测量。所以,监测平台还需支持按需监测。
4）检测结果主动报警
由于网络工程师直接对内网质量负责,因此希望监测平台在测量”端到端”通信性能后,对相关数据进行分析,判断网络是否正常,并在检测到网络异常后及时发送报警,以保证各业务线服务正常。
5）针对产品业务的定制化展示
由于一个产品业务通常只部署在部分机房,依赖部分网络,所以运维工程师往往不关注非其负责的。因此,监测系统需要支持定制化展示,使运维工程师能迅速获取其需要关注的网络状态信息。
那么,百度现有的内网监测技术能否满足以上需求呢？
现有监测技术
其实,百度内部已经应用了一些内网质量监测技术,这些技术利用不同的测量手段获取内网质量数据,并加以分析,进而判断网络是否正常。表1给出了三种现有监测技术的相关信息。
| 编号 | 监控原理 | 不足 |
|---|
| 技术1 | 利用交换机的 Syslog 监测交换机级别故障 | 交换机级别故障无法准确反映业务所感知的网络性能 |
| Syslog无法记录所有交换机故障 |
| 无法检测非交换机故障类网络异常 |
| 技术2 | 部署专用的服务器 探针 来连接各IDC核心交换机,服务器通过互相发包对IDC间网络性能进行主动探测 | IDC内部网络通信监控缺失 |
| 探测到的IDC间网络性能和业务感受到的网络性能有所差别 |
| 资源开销大,不能直接扩展 |
| 技术3 | 在所有线上服务器部署探针,并在各IDC分别设置一个 靶标服务器 ,让所有线上服务器测量到各靶标服务器的网络状态 | 单个靶标服务器存在单点故障问题,不能很好代表机房的网络情况
机房内部的拓扑覆盖不全 | 不支持按需探测功能 |
上述几种技术在内网质量监测和运维中发挥了一定作用,但在使用过程中也发现了一些不足,不能很好满足上述需求。因此,基于以上技术的实战经验,我们开发了新平台 NetRadar （网络雷达）。与以上监测技术相比, NetRadar 具有以下优点：
覆盖广 ： 探测agent在全网linux服务器完成部署,覆盖了百度全部内网机房；
多层级 ： 7*24小时持续监测整个内网的网络质量,包括机房间、机房内集群间、集群内ToR交换机间的网络质量；
指标全 ： 评价网络质量的方式多样,区分QOS队列、协议、统计值,共计27种网络质量监控指标,每个探测周期会产生近百万的监控指标；
检测准 ： 通过自适应异常检测算法对监控指标进行检测,并进一步生成机房、区域级别的网络事件；
除此之外, NetRadar 还支持按需探测,并提供全内网“端到端”探测接口以及故障事件接口,以帮助工程师快速诊断网络问题。
总结
相信通过本文的介绍,您已经对百度内网质量监测有了一些了解。接下来,我们将推出本系列文章的下篇：《百度网络监控实战： NetRadar 横空出世（下）》,系统性地介绍 NetRadar 平台,请持续关注AIOps智能运维！
若您有其他疑问或者想进一步了解 NetRadar 平台,欢迎留言反馈！
智能运维时代,AIOps智能运维与您同行！
原文链接地址： https://developer.baidu.com/topic/show/290301
本文作者：AIOps智能运维
作者简介
运小皮 百度资深运维工程师
负责百度智能运维平台的设计和实施。曾负责网页搜索、移动搜索产品运维和服务高可用、持续部署等技术方向。
干货概览
在本系列的上一篇文章《百度自动化运维的演进（一）：聊聊百度自动化运维》中,百度运维部元老级高工运小皮介绍了他眼中的自动化运维以及百度的自动化运维标准。在本篇文章中运小皮将详细介绍百度三代运维平台,百度运维平台从web化走向开放,最终达到智能的过程。
百度自动化运维标准中能力等级与能力描述对应关系如下：
L0--人工（无自动化）
L1--工具辅助的自动化
L2：部分自动化
L3：有条件的自动化
L4：高度自动化
L5：完全自动化
2008年以前
无运维平台
这段期间,是分散的团队、小组各自为政的时期。开源、自研方案不一,抽象层次不一,自动化层次也不一,可以认为大多数在 L1,部分还依然完全靠人肉（L0）,少量已经踏进了 L2。
2008-2011年
第一代运维平台,Web化
2008 立项开发的第一代运维管理平台（嗯,这就是很多友商经常提起的 Noah 平台）,标志着百度自动化运维全面迈向 L2。这期间我们的主要工作是研发一个统一的运维平台来代替人工执行一系列运维工作,包括资源的管理（增删改）、服务运行状态的采集、服务变更操作等等。
服务树：资源、机器管理
由运维人员管理的资源有哪些？归根到底是三类： 软件、硬件 和 人 ；具体讲主要就是 服务、机器 和 权限 。
2008年,我们第一次以服务为中心来进行组织和管理资源,也即“ 服务树 ”：
首先,通过“公司/部门/产品线”这类客观存在的管理范围,自顶向下地定义树形结构,并且允许通过自定义子树节点的方式来扩展管理多个服务； 其次,机器挂载到服务树的叶子节点上,这样就可以通过服务及其从属关系来管理大量的机器；
最后,将人员归属到一系列角色权限中,并以服务树来定义其作用域。
在统一到服务树这个模型之前,虽然已经有诸多解决方案和工具了,无论形式上到底是命令行还是一些开源平台,但究其本质上都是通过数组结构来管理若干个机器列表。 树形结构 在表达归属、层级、继承等关系上的优势,大大方便了其他运维系统组件的设计和实现。
监控：标准化采集
基于服务树提供的具有层次和继承关系的机器管理方案, 监控系统 就方便多了：只要专注于服务状态的 采集 、 呈现 和 报警策略 即可。
第一代监控系统包含 机器监控 和 服务监控 两大类。机器监控全覆盖地采集机器的基本信息,包括各类硬件资源的使用情况（cpu、内存、磁盘 io、网络带宽等）。服务监控以 探针 （probe）的方式检测服务的健康状态。 探针 支持不同的协议和方式（HTTP、Socket）,并且定义了最简单的自定义数据采集协议（基于 Bash 命令行）。
随着产品服务的迭代,对服务的运行状态需要更精细的掌控,第二代监控系统应运而生。 监控功能不断拓展,增加了 进程级 的资源数据采集、基于 日志匹配 的业务指标统计监控、 报警的汇聚与合并 。与此同时,我们也在实践过程中提炼同类服务间的共同点,提出了第一版的监控规范,赋予数据特定的运维语义（ 存活性 、 资 源消耗 、 业务功能 等等）。
上线系统：自动化部署
Noah 上线（又称 Noah web 上线、 ad-web 上线）系统是第一代的自动化部署系统,其核心设计目标是,实现一个通用的平台来替代运维工程师在上线时的手工操作；所以其基本设计思想是 翻译 上线步骤（备份、下载、替换、重启等文字描述）为一系列标准的操作命令（wget、cp、mv、restart 等）。
2011-2014年
第二代运维平台,开放
随着业务规模的扩张,集群规模也在指数型增长,统一的、Web 化的运维平台也遭遇了瓶颈：
众口难调：和业务特点相关的需求越来越离散（有的重效率,有的看重流程的完备性,有的对易用性要求高）再加上需求方越来越多,功能交付排队积压严重。
性能差：极端情况下,需要提交一个 K 量级机器的操作,平台响应长达数分钟,甚至还有比较高的错误率。
于是,这段时间,我们增强了运维系统的架构能力,使其可以更方便定制和集成,为全面进化到 L3 级自动化做好了准备,且在变更领域开始向 L3 迈进。
BNS：一种更简单、高效的服务发现和管理方案
服务树 的路径,和文件的绝对路径一样,理论上可以作为服务的一个全局、权威的名字,但因为其路径中耦合了组织和管理上的信息,导致这部分的变化带来的协同修改成本非常高,于是 BNS（Baidu Naming Service）应运而生。
BNS 参考 DNS 的解决方案,类似域名。服务名包含如下两大部分
DNS 的解决方案,类似域名。服务名包含如下两大部分：
名字空间只包含两类和服务管理紧密相关的信息,即服务的物理部署（机房）和业务归属（产品线）
在名字空间下只需要保持名字唯一即可
这个名字可以稳定、一致地被用于各个系统之间交换服务实例列表（类似 IP 列表）。 除此之外,它也可以挂载到服务树上,继续满足组织、行政、权限等管理需求,同时这也保持了和服务树原有模型的向前兼容。
进一步,随着 实例标签 （Tag）的支持,我们可以以多维度视图的方式来管理服务,终于打破了树形结构的挚肘。
监控3.0 Argus：高性能、灵活定制的监控解决方案
第三代监控系统 ,基于先前在监控数据应用场景的经验,抽象出来 多维度时序数据 的模型,设计和实现了相应的存储架构（时序数据库 TSDB）、 计算架构 （多维度流式聚合计算）,打开了运维数据分析的新篇章。
与此同时,为了方便集成,监控采集方式更加灵活（采集接口、数据库直推等）,监控配置规则也彻底 DSL 化 ,使监控的设计可以和开发编码阶段的工作流相结合。
大量的数据,带来了大量的辅助分析工具和数据可视化需求,运维平台和业务运维同学紧密配合,合作研发定制化的监控平台实践逐渐成熟。
一键上线Archer：持续部署的瑞士军刀
由于 Noah web 上线只维护当次上线涉及什么文件、什么命令,是典型的“增量”模式,只能看到局部的 diff,不利于服务生命周期内更多场景下的自动化工作开展,诸如：服务迁移、故障处理、测试调研实验等同源环境搭建等。
所以在 2011 年我们推出了它的继任者, Archer 上线,其基本设计原则,来源于当时业界的“ 持续集成/交付 ”和“ DevOps ”思潮：将决定服务运行逻辑的所有代码、配置、数据、运维接口等信息进行同源（仓库）管理并全量发布,基于此简化部署系统的内部设计实现复杂度、提高了二次开发的灵活度,促进了整个构建、测试、上线流水线的自动化。
2014年-当前
第三代运维平台,智能
2014 年是百度智能运维元年,自此之后,异常检测、多维度分析、关联推导等算法策略逐渐应用,感知、决策、执行的工程框架逐渐定型。我们迎来了 L3 自动化的大规模实施,并开始迈向 L4。
总结
从2008年以前至今,百度运维平台经历了web化、开放、智能三次重大变革,期间百度运维部研发了服务树、监控系统、Noah web上线、BNS、监控3.0 Argus、Archer等系统,助力百度运维逐步走向智能化。
接下来,我们将详细介绍百度运维平台中的各个系统,请持续关注AIOps智能运维！
若您有其他疑问或者想进一步了解百度自动化运维,欢迎留言反馈！
原文链接地址： https://developer.baidu.com/topic/show/290300
本文作者：HelloDeveloper
大型网站的 HTTPS 实践（一）-- HTTPS 协议和原理
前言
百度已经于近日上线了全站 HTTPS 的安全搜索,默认会将 HTTP 请求跳转成 HTTPS。本文重点介绍 HTTPS 协议 ,并简单介绍部署全站 HTTPS 的意义。
HTTPS 协议概述
HTTPS 可以认为是 HTTP + TLS。HTTP 协议大家耳熟能详了,目前大部分 WEB 应用和网站都是使用 HTTP 协议传输的。
TLS 是传输层加密协议,它的前身是 SSL 协议,最早由 netscape 公司于 1995 年发布,1999 年经过 IETF 讨论和规范后,改名为 TLS。如果没有特别说明,SSL 和 TLS 说的都是同一个协议。
HTTP 和 TLS 在协议层的位置以及 TLS 协议的组成如下图：
TLS 协议主要有五部分：应用数据层协议,握手协议,报警协议,加密消息确认协议,心跳协议。
TLS 协议本身又是由 record 协议传输的,record 协议的格式如上图最右所示。
目前常用的 HTTP 协议是 HTTP1.1,常用的 TLS 协议版本有如下几个：TLS1.2, TLS1.1, TLS1.0 和 SSL3.0。其中 SSL3.0 由于 POODLE 攻击已经被证明不安全,但统计发现依然有不到 1% 的浏览器使用 SSL3.0。TLS1.0 也存在部分安全漏洞,比如 RC4 和 BEAST 攻击。TLS1.2 和 TLS1.1 暂时没有已知的安全漏洞,比较安全,同时有大量扩展提升速度和性能,推荐大家使用。
需要关注一点的就是 TLS1.3 将会是 TLS 协议一个非常重大的改革。不管是安全性还是用户访问速度都会有质的提升。不过目前没有明确的发布时间。
HTTPS 功能介绍
百度使用 HTTPS 协议主要是为了保护用户隐私,防止流量劫持。HTTP 本身是明文传输的,没有经过任何安全处理。例如用户在百度搜索了一个关键字,比如 “苹果手机”,中间者完全能够查看到这个信息,并且有可能打电话过来骚扰用户。也有一些用户投诉使用百度时,发现首页或者结果页面浮了一个很长很大的广告,这也肯定是中间者往页面插的广告内容。如果劫持技术比较低劣的话,用户甚至无法访问百度。
这里提到的中间者主要指一些网络节点,是用户数据在浏览器和百度服务器中间传输必须要经过的节点。比如 WIFI 热点,路由器,防火墙,反向代理,缓存服务器等。
在 HTTP 协议下,中间者可以随意嗅探用户搜索内容,窃取隐私甚至篡改网页。不过 HTTPS 是这些劫持行为的克星,能够完全有效地防御。总体来说,HTTPS 协议提供了三个强大的功能来对抗上述的劫持行为： 内容加密。浏览器到百度服务器的内容都是以加密形式传输,中间者无法直接查看原始内容。 身份认证。保证用户访问的是百度服务,即使被 DNS 劫持到了第三方站点,也会提醒用户没有访问百度服务,有可能被劫持 数据完整性。防止内容被第三方冒充或者篡改。
那 HTTPS 是如何做到上述三点的呢？下面从原理角度介绍一下。
HTTPS 原理介绍 内容加密
加密算法一般分为两种,对称加密和非对称加密。所谓对称加密（也叫密钥加密）就是指加密和解密使用的是相同的密钥。而非对称加密（也叫公钥加密）就是指加密和解密使用了不同的密钥。
非对称密钥交换
在非对称密钥交换算法出现以前,对称加密一个很大的问题就是不知道如何安全生成和保管密钥。非对称密钥交换过程主要就是为了解决这个问题,使得对称密钥的生成和使用更加安全。
密钥交换算法本身非常复杂,密钥交换过程涉及到随机数生成,模指数运算,空白补齐,加密,签名等操作。
常见的密钥交换算法有 RSA,ECDHE,DH,DHE 等算法。它们的特性如下： RSA：算法实现简单,诞生于 1977 年,历史悠久,经过了长时间的破解测试,安全性高。缺点就是需要比较大的素数（目前常用的是 2048 位）来保证安全强度,很消耗 CPU 运算资源。RSA 是目前唯一一个既能用于密钥交换又能用于证书签名的算法。 DH：diffie-hellman 密钥交换算法,诞生时间比较早（1977 年）,但是 1999 年才公开。缺点是比较消耗 CPU 性能。 ECDHE：使用椭圆曲线（ECC）的 DH 算法,优点是能用较小的素数（256 位）实现 RSA 相同的安全等级。缺点是算法实现复杂,用于密钥交换的历史不长,没有经过长时间的安全攻击测试。 ECDH：不支持 PFS,安全性低,同时无法实现 false start。 DHE：不支持 ECC。非常消耗性能。
百度只支持 RSA 和 ECDH_RSA 密钥交换算法。原因是： ECDHE 支持 ECC 加速,计算速度更快。支持 PFS,更加安全。支持 false start,用户访问速度更快。 目前还有至少 20% 以上的客户端不支持 ECDHE,我们推荐使用 RSA 而不是 DH 或者 DHE,因为 DH 系列算法非常消耗 CPU（相当于要做两次 RSA 计算）。
需要注意通常所说的 ECDHE 密钥交换默认都是指 ECDHE_RSA,使用 ECDHE 生成 DH 算法所需的公私钥,然后使用 RSA 算法进行签名最后再计算得出对称密钥。
非对称加密相比对称加密更加安全,但也存在两个明显缺点： CPU 计算资源消耗非常大。一次完全 TLS 握手,密钥交换时的非对称解密计算量占整个握手过程的 90% 以上。而对称加密的计算量只相当于非对称加密的 0.1%,如果应用层数据也使用非对称加解密,性能开销太大,无法承受。 非对称加密算法对加密内容的长度有限制,不能超过公钥长度。比如现在常用的公钥长度是 2048 位,意味着待加密内容不能超过 256 个字节。
所以公钥加密目前只能用来作密钥交换或者内容签名,不适合用来做应用层传输内容的加解密。
非对称密钥交换算法是整个 HTTPS 得以安全的基石,充分理解非对称密钥交换算法是理解 HTTPS 协议和功能的关键。
下面分别通俗地介绍一下 RSA 和 ECDHE 在密钥交换过程中的应用。 RSA 在密钥交换过程中的应用
RSA 算法的原理是乘法不可逆或者大数因子很难分解。RSA 的推导实现涉及到了欧拉函数和费马定理及模反元素的概念,有兴趣的读者可以自行百度。
RSA 算法是统治世界的最重要算法之一,而且从目前来看,RSA 也是 HTTPS 体系中最重要的算法,没有之一。 下面用一个简单的示例介绍一下 RSA 的神奇妙用。
假设一个网站需要使用 HTTPS 协议,那么它首先就得申请数字证书,申请证书之前需要生成一对公钥和私钥,为了方便说明问题,假设 server 的密钥长度只有 8 位,事实上现在的服务器证书至少是 2048 位长。 随机挑选两个质数 p, q,使得 p q 接近 2 的 8 次方 = 256, 假设 p = 13, q = 19。n = p q = 13*19 = 247。 挑选一个数 e,满足 1< e < (p-1) (q-1) 并且 e 与 (p-1) (q-1) 互质,假设 e = 53。 计算 e 关于 n 的模反元素 , ed≡1 (mod φ(n)), d =
实际应用中,(n,e) 组成了公钥对,（n,d）组成了私钥对。公钥一般都注册到了证书里,任何人都能直接查看,比如百度证书的公钥对如下图,其中最末 6 个数字（010001）换算成 10 进制就是 65537,也就是公钥对中的 e, 取值比较小的原因有两个： 减小 client 端的计算强度,特别是现在移动终端的计算能力比较弱,较小的公钥使得 CPU 计算会更快。 加大 server 端的破解难度。e 比较小,d 必然会非常大。所以 d 的取值空间也会非常大。 ECDHE 算法在密钥交换中的应用
ECDHE 算法实现要复杂很多,依赖的数学原理主要是 ECC 椭圆曲线和离散对数。详细概念不做说明,示例介绍一下。
对称内容加密
非对称密钥交换过程结束之后就得出了本次会话需要使用的对称密钥。对称加密又分为两种模式：流式加密和分组加密。流式加密现在常用的就是 RC4,不过 RC4 已经不再安全,微软也建议网站尽量不要使用 RC4 流式加密。
一种新的替代 RC4 的流式加密算法叫 ChaCha20,它是 google 推出的速度更快,更安全的加密算法。目前已经被 android 和 chrome 采用,也编译进了 google 的开源 openssl 分支---boring ssl,并且 nginx 1.7.4 也支持编译 boringssl。
分组加密以前常用的模式是 AES-CBC,但是 CBC 已经被证明容易遭受 BEAST 和 LUCKY13 攻击。目前建议使用的分组加密模式是 AES-GCM,不过它的缺点是计算量大,性能和电量消耗都比较高,不适用于移动电话和平板电脑。
数据完整性
这部分内容比较好理解,跟平时的 md5 签名类似,只不过安全要求要高很多。openssl 现在使用的完整性校验算法有两种：MD5 或者 SHA。由于 MD5 在实际应用中存在冲突的可能性比较大,所以尽量别采用 MD5 来验证内容一致性。SHA 也不能使用 SHA0 和 SHA1,中国山东大学的王小云教授在 2005 年就宣布破解了 SHA-1 完整版算法。微软和 google 都已经宣布 16 年及 17 年之后不再支持 sha1 签名证书。
身份认证
身份认证主要涉及到 PKI 和数字证书。数字证书有两个作用： 身份授权。确保浏览器访问的网站是经过 CA 验证的可信任的网站。 分发公钥。每个数字证书都包含了注册者生成的公钥。在 SSL 握手时会通过 certificate 消息传输给客户端。
这里简单介绍一下数字证书是如何验证网站身份的,PKI 体系的具体知识不做详细介绍。
证书申请者首先会生成一对密钥,包含公钥和密钥,然后把公钥及域名还有 CU 等资料制作成 CSR 格式的请求发送给 RA,RA 验证完这些内容之后（RA 会请独立的第三方机构和律师团队确认申请者的身份）再将 CSR 发送给 CA,CA 然后制作 X.509 格式的证书。
申请者拿到 CA 的证书并部署在网站服务器端,那浏览器发起握手接收到证书后,如何确认这个证书就是 CA 签发的呢？怎样避免第三方伪造这个证书？
答案就是数字签名（digital signature）。数字签名可以认为是一个证书的防伪标签,目前使用最广泛的 SHA-RSA 数字签名的制作和验证过程如下： 数字签名的签发。首先是使用哈希函数对证书数据哈希,生成消息摘要,然后使用 CA 自己的私钥对证书内容和消息摘要进行加密。 数字签名的校验。使用 CA 的公钥解密签名,然后使用相同的签名函数对证书内容进行签名并和服务端的数字签名里的签名内容进行比较,如果相同就认为校验成功。
这里有几点需要说明： 数字签名签发和校验使用的密钥对是 CA 自己的公私密钥,跟证书申请者提交的公钥没有关系。 数字签名的签发过程跟公钥加密的过程刚好相反,即是用私钥加密,公钥解密。 现在大的 CA 都会有证书链,证书链的好处一是安全,保持根 CA 的私钥离线使用。第二个好处是方便部署和撤销,即如何证书出现问题,只需要撤销相应级别的证书,根证书依然安全。 根 CA 证书都是自签名,即用自己的公钥和私钥完成了签名的制作和验证。而证书链上的证书签名都是使用上一级证书的密钥对完成签名和验证的。 怎样获取根 CA 和多级 CA 的密钥对？它们是否可信？当然可信,因为这些厂商跟浏览器和操作系统都有合作,它们的公钥都默认装到了浏览器或者操作系统环境里。比如 firefox 就自己维护了一个可信任的 CA 列表,而 chrome 和 IE 使用的是操作系统的 CA 列表。
HTTPS 使用成本
HTTPS 目前唯一的问题就是它还没有得到大规模应用,受到的关注和研究都比较少。至于使用成本和额外开销,完全不用太过担心。
一般来讲,使用 HTTPS 前大家可能会非常关注如下问题： 证书费用以及更新维护。大家觉得申请证书很麻烦,证书也很贵,可是证书其实一点都不贵,便宜的一年几十块钱,最多也就几百。而且现在也有了免费的证书机构,比如著名的 mozilla 发起的免费证书项目： let’s encrypt 就支持免费证书安装和自动更新。这个项目将于今年中旬投入正式使用。 数字证书的费用其实也不高,对于中小网站可以使用便宜甚至免费的数字证书服务（可能存在安全隐患）,像著名的 verisign 公司的证书一般也就几千到几万块一年不等。当然如果公司对证书的需求比较大,定制性要求高,可以建立自己的 CA 站点,比如 google,能够随意签发 google 相关证书。 HTTPS 降低用户访问速度。HTTPS 对速度会有一定程度的降低,但是只要经过合理优化和部署,HTTPS 对速度的影响完全可以接受。在很多场景下,HTTPS 速度完全不逊于 HTTP,如果使用 SPDY,HTTPS 的速度甚至还要比 HTTP 快。 大家现在使用百度 HTTPS 安全搜索,有感觉到慢吗？ HTTPS 消耗 CPU 资源,需要增加大量机器。前面介绍过非对称密钥交换,这是消耗 CPU 计算资源的大户,此外,对称加解密,也需要 CPU 的计算。 同样地,只要合理优化,HTTPS 的机器成本也不会明显增加。对于中小网站,完全不需要增加机器也能满足性能需求。
后记
国外的大型互联网公司很多已经启用了全站 HTTPS,这也是未来互联网的趋势。国内的大型互联网并没有全站部署 HTTPS,只是在一些涉及账户或者交易的子页面 / 子请求上启用了 HTTPS。百度搜索首次全站部署 HTTPS,对国内互联网的全站 HTTPS 进程必将有着巨大的推动作用。
目前互联网上关于 HTTPS 的中文资料比较少,本文就着重介绍了 HTTPS 协议涉及到的重要知识点和平时不太容易理解的盲区,希望能对大家理解 HTTPS 协议有帮助。百度 HTTPS 性能优化涉及到大量内容,从前端页面、后端架构、协议特性、加密算法、流量调度、架构和运维、安全等方面都做了大量工作。本系列的文章将一一进行介绍。
原文链接地址： https://developer.baidu.com/topic/show/290299
作者 | 阿里云售后技术专家 声东 导读 ：当我们尝试去理解 K8s 集群工作原理的时候,控制器（Controller）肯定是一个难点。这是因为控制器有很多,具体实现大相径庭；且控制器的实现用到了一些较为晦涩的机制,不易理解。但是,我们又不能绕过控制器,因为它是集群的“大脑”。今天这篇文章,作者通过分析一个简易冰箱的设计过程,来帮助读者深入理解集群控制器的产生,功能以及实现方法。
K8s 集群核心组件大图
下图是 K8s 集群的核心组件,包括数据库 etcd,调度器 Scheduler,集群入口 API Server,控制器 Controller,服务代理 kube-proxy 以及直接管理具体业务容器的 kubelet。
这些组件逻辑上可以被分为三个部分： 核心组件 etc 数据库； 对 etcd 进行直接操作的入口组件 API Server； 其他组件, 这里的“其他组件”之所以可以被划分为一类,是因为它们都可以被看做是集群的控制器。
今天我们要讲的就是集群控制器原理。
控制器原理
虽然控制器是 K8s 集群中比较复杂的组件,但控制器本身对我们来说并不陌生的。我们每天使用的洗衣机、冰箱、空调等,都是依靠控制器才能正常工作。在控制器原理这一节,我们通过思考一个简易冰箱的设计过程,来理解 K8s 集群控制器的原理。
简易的冰箱
这个冰箱包括五个组件：箱体、制冷系统、照明系统、温控器以及门。
冰箱只有两个功能： 当有人打开冰箱门的时候,冰箱内的灯会自动开启； 当有人按下温控器的时候,制冷系统会根据温度设置,调节冰箱内温度。
统一入口
对于上边的冰箱,我们可以简单抽象成两个部分：统一的操作入口和冰箱的所有组件。
在这里,用户只有通过入口,才能操作冰箱。这个入口提供给用户两个接口：开关门和调节温控器。用户执行这两个接口的时候,入口会分别调整冰箱门和温控器的状态。
但是这里有一个问题,就是用户通过这两个接口,既不能让冰箱内部的灯打开,也不能调节冰箱的温度。
控制器
控制器就是为了解决上边的问题产生的。控制器就是用户的操作,和冰箱各个组件的正确状态之间的一座桥梁： 当用户打开门的时候,控制器观察到了门的变化,它替用户打开冰箱内的灯； 当用户按下温控器的时候,控制器观察到了用户设置的温度,它替用户管理制冷系统,调节冰箱内温度。
控制器管理器
冰箱有照明系统和制冷系统,显然相比一个控制器管理着两个组件,我们替每个组件分别实现一个控制器是更为合理的选择。同时我们实现一个控制器管理器来统一维护所有这些控制器,来保证这些控制器在正常工作。
SharedInformer
上边的控制器和控制器管理器,看起来已经相当不错了。但是当冰箱功能增加,势必有很多新的控制器加进来。这些控制器都需要通过冰箱入口,时刻监控自己关心的组件的状态变化。比如照明系统控制器就需要时刻监控冰箱门的状态。当大量控制器不断的和入口通信的时候,就会增加入口的压力。
这个时候,我们把监控冰箱组件状态变化这件事情,交给一个新的模块 SharedInformer 来实现。
SharedInformer 作为控制器的代理,替控制器监控冰箱组件的状态变化,并根据控制器的喜好,把不同组件状态的变化,通知给对应的控制器。通过优化,这样的 SharedInformer 可以极大的缓解冰箱入口的压力。
ListWatcher
SharedInformer 方便了控制器对冰箱组件的监控,而这个机制最核心的功能,当然是主动获取组件状态和被动接收组件状态变化的通知。这两个功能加起来,就是 ListWatcher。
假设 SharedInformer 和冰箱入口通过 http 协议通信的话,那么 http 分块编码（chunked transfer encoding）就是实现 ListWatcher 的一个好的选择。控制器通过 ListWatcher 给冰箱入口发送一个查询然后等待,当冰箱组件有变化的时候,入口通过分块的 http 响应通知控制器。控制器看到 chunked 响应,会认为响应数据还没有发送完成,所以会持续等待。
举例说明
以上我们从一个简易冰箱的进化过程中,了解了控制器产生的意义,扮演的角色,以及实现的方式。现在我们回到K8s 集群。K8s 集群实现了大量的控制器,而且在可以预见的未来,新的功能的控制器会不断出现,而一些旧的控制器也会被逐渐淘汰。
目前来说,我们比较常用的控制器,如 Pod 控制器、Deployment 控制器、Service 控制器、Replicaset 控制器等。这些控制器一部分是由 kube controller manager 这个管理器实现和管理,而像 route 控制器和 service 控制器,则由 cloud controller manager 实现。
之所以会出现 cloud controller manager,是因为在不同的云环境中,一部分控制器的实现,会因为云厂商、云环境的不同,出现很大的差别。这类控制器被划分出来,由云厂商各自基于 cloud controller manager 分别实现。
这里我们以阿里云 K8s 集群 cloud controller manager 实现的 route 控制器和 service 控制器为例,简单说明 K8s 控制器的工作原理。
服务控制器
首先,用户请求 API Server 创建一个 LoadBalancer 类型的服务,API Server 收到请求并把这个服务的详细信息写入 etcd 数据库。而这个变化,被服务控制器观察到了。服务控制器理解 LoadBalancer 类型的服务,除了包括存放在 etcd 内部的服务记录之外,还需要一个 SLB 作为服务入口,以及若干 endpoints 作为服务后端。所以服务控制器分别请求 SLB 的云 openapi 和 API Server,来创建云上 SLB 资源,和集群内 endpoints 资源。
路由控制器
在集群网络一章中,我们提到过,当一个节点加入一个 K8s 集群的时候,集群需要在 VPC 路由表里增加一条路由,来搭建这个新加入节点到 Pod 网络的主干道。而这件事情,就是路由控制器来做的。路由控制器完成这件事情的流程,与上边服务控制器的处理流程非常类似,这里不再赘述。
结束语
基本上来说,K8s 集群的控制器,其实扮演着集群大脑的角色。有了控制器,K8s 集群才有机会摆脱机械和被动,变成一个自动、智能、有大用的系统。
Kubernetes 1.18.0已经正式发布,对于高可用集群也可以直接升级。快速升级（含国内镜像快速下载链接）包括升级kubeadm/kubectl/kubelet版本、拉取镜像、升级Kubernetes集群三个主要步骤。参考《 Ubuntu上软件锁定版本不更新 》安装特定DockerCE版本。 kubeadm upgrade apply v1.18.0
1、升级kubeadm/kubectl/kubelet版本 sudo apt install kubeadm=1.18.0-00 kubectl=1.18.0-00 kubelet=1.18.0-00 设置中国区的软件源,参考： kubernetes for china
查看该版本的容器镜像版本： kubeadm config images list
输出如下： ~ # kubeadm config images list k8s.gcr.io/kube-apiserver:v1.18.0 k8s.gcr.io/kube-controller-manager:v1.18.0 k8s.gcr.io/kube-scheduler:v1.18.0 k8s.gcr.io/kube-proxy:v1.18.0 k8s.gcr.io/pause:3.2 k8s.gcr.io/etcd:3.4.3-0 k8s.gcr.io/coredns:1.6.7
2、拉取容器镜像
原始的kubernetes镜像文件在gcr上,不能直接下载。我给镜像到了阿里云的杭州机房的容器仓库里,拉取还是比较快的。 echo "" echo "==========================================================" echo "Pull Kubernetes v1.18.0 Images from aliyuncs.com ......" echo "==========================================================" echo "" MY_REGISTRY=registry.cn-hangzhou.aliyuncs.com/openthings ## 拉取镜像 docker pull ${MY_REGISTRY} /k8s-gcr-io-kube-apiserver:v1.18.0 docker pull ${MY_REGISTRY} /k8s-gcr-io-kube-controller-manager:v1.18.0 docker pull ${MY_REGISTRY} /k8s-gcr-io-kube-scheduler:v1.18.0 docker pull ${MY_REGISTRY} /k8s-gcr-io-kube-proxy:v1.18.0 docker pull ${MY_REGISTRY} /k8s-gcr-io-etcd:3.4.3-0 docker pull ${MY_REGISTRY} /k8s-gcr-io-pause:3.2 docker pull ${MY_REGISTRY} /k8s-gcr-io-coredns:1.6.7 ## 添加Tag docker tag ${MY_REGISTRY} /k8s-gcr-io-kube-apiserver:v1.18.0 k8s.gcr.io/kube-apiserver:v1.18.0 docker tag ${MY_REGISTRY} /k8s-gcr-io-kube-scheduler:v1.18.0 k8s.gcr.io/kube-scheduler:v1.18.0 docker tag ${MY_REGISTRY} /k8s-gcr-io-kube-controller-manager:v1.18.0 k8s.gcr.io/kube-controller-manager:v1.18.0 docker tag ${MY_REGISTRY} /k8s-gcr-io-kube-proxy:v1.18.0 k8s.gcr.io/kube-proxy:v1.18.0 docker tag ${MY_REGISTRY} /k8s-gcr-io-etcd:3.4.3-0 k8s.gcr.io/etcd:3.4.3-0 docker tag ${MY_REGISTRY} /k8s-gcr-io-pause:3.2 k8s.gcr.io/pause:3.2 docker tag ${MY_REGISTRY} /k8s-gcr-io-coredns:1.6.7 k8s.gcr.io/coredns:1.6.7 echo "" echo "==========================================================" echo "Pull Kubernetes v1.18.0 Images FINISHED." echo "into registry.cn-hangzhou.aliyuncs.com/openthings, " echo " by openthings@https://my.oschina.net/u/2306127." echo "==========================================================" echo ""
保存为shell脚本,然后执行。 或者,下载脚本： https://github.com/openthings/kubernetes-tools/blob/master/kubeadm/2-images/
3、升级Kubernetes集群
全新安装： #指定IP地址,1.18.0版本： sudo kubeadm init --kubernetes-version=v1. 18 . 0 --apiserver-advertise-address= 10.1.1.199 --pod-network-cidr= 10.244.0.0 / 16 使用kubeadm部署高可用Kubernetes 1.17.0
先查看一下需要升级的各个组件的版本。
使用 kubeadm upgrade plan ,输出的版本升级信息如下： Components that must be upgraded manually after you have upgraded the control plane with 'kubeadm upgrade apply' : COMPONENT CURRENT AVAILABLE Kubelet 1 x v1 .17 .2 v1 .18 .0 8 x v1 .17 .2 v1 .18 .0 Upgrade to the latest version in the v1 .18 series: COMPONENT CURRENT AVAILABLE API Server v1 .17 .2 v1 .18 .0 Controller Manager v1 .17 .2 v1 .18 .0 Scheduler v1 .17 .2 v1 .18 .0 Kube Proxy v1 .17 .2 v1 .18 .0 CoreDNS 1.6 .5 1.6 .7 Etcd 3.4 .3 3.4 .3 -0 You can now apply the upgrade by executing the following command: kubeadm upgrade apply v1 .18 .0
确保上面的容器镜像已经下载（如果没有提前下载,可能被网络阻隔导致挂起）,然后执行升级： kubeadm upgrade apply v1 .18 .0
看到下面信息,就OK了。 [upgrade/successful] SUCCESS ! Your cluster was upgraded to " v1 .18 .0 ". Enjoy !
然后,配置当前用户环境： mkdir -p $HOME/.kube sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config sudo chown $(id -u):$(id -g) $HOME/.kube/config
就可以使用 kubectl version 来查看状态和 kubectl cluster-info 查看服务地址。
4、工作节点的升级
每个工作节点需要拉取上面对应版本的镜像,以及安装kubelet的对应版本。
检查版本： ~$ kubectl version
查看Pod信息： kubectl get pod --all-namespaces
完成。
⚠️注意：1.17后版本,如果使用kubeadm安装为高可用模式,所有master节点都可以被升为最新版本（需要提前把k8s的容器镜像放到节点上去）。
更多参考： Kubernetes 1.17.4快速升级 Kubernetes 1.17.2快速升级 Kubernetes 1.17.1快速升级 Kubernetes 1.17.0 已发布 使用kubeadm部署高可用Kubernetes 1.17.0 Kubernetes 1.17.0管理界面Dashboard 2 设置Kubernetes的Master节点运行应用pod Kubernetes pod中systemctl状态探针失败问题 运用Jupyter Notebook进行系统管理 将Jupyter/JupyterHub/JupyterLab运行为系统服务 快速设置JupyterHub for K8s 在JupyterHub for K8s使用GlusterFS存储
本文作者：o****0
英伟达称稍后会放出一个使用 AI 模型 GameGAN 复刻的《吃豆人》游戏,以致敬诞生40周年的街机版《吃豆人》。
根据英伟达发布的研究报告,GameGAN 目标是用神经网络取代游戏引擎。
它不同于以往用 AI 做游戏的例子。之前的谷歌 DeepMind 和 Open AI 还是在现有游戏框架中,被用来“玩游戏”,相当于是智能生成一个游戏对手。比如 OpenAI 被用来在 Dota2 5v5中对战人类,OpenAI 2018年通过学习人类演示,在蒙特祖玛的复仇游戏中刷出了74500分的高分。
GameGAN 则被用来“创作”游戏,是对现有游戏代码的取代。它在训练过程中摄入大量游戏剧本和键盘动作,通过观察场景和玩家的操作动作,预测下一帧游戏画面,而不访问底层游戏逻辑或引擎。 “当玩家按下左键的时候,这个 AI 会猜测画面的变化,并且生成一个“看起来是角色在往左走”的图像。 中间发生的事情,全部都在 AI 的黑盒中。 没人知道 AI 是怎么理解玩家操作的,得到的只有最终的输出结果。”
除了生成下一帧游戏画面,GameGAN 还学习环境的内在动力学,“我们有兴趣训练一个游戏模拟器,它可以模拟环境的确定性和随机性”。
GameGAN包括动力引擎；记忆模块；渲染引擎；对抗性损失、循环损失训练和培训计划。
首先GameGAN要学习环境会如何跟随用户操作变化而改变,这涉及一些基本的规则,比如不能穿过墙壁。同时还要通过访问历史,产生一致性模拟。场景中的长期一致性实现通过记忆模块实现,GameGAN使用内存模块,记住生成的静态元素,如背景,并在需要的时候适当检索。神经渲染引擎负责渲染模拟图像。此外,对抗训练用来完成图像和视频的合成任务,GameGAN用对抗性训练学习环境动力学,并产生真实的时间相关模拟。
这次复刻《吃豆人》,主要训练的细节包括吃豆人的速度和移动能力；鬼魂的运作方式；吃豆人吃下大力丸后的变化；鬼魂与吃豆人相遇的场景。据了解,GameGAN基于PyTorch开发,模型研发已经进行了8个月,关于复刻《吃豆人》只用了4天。
游戏开发商万代南宫梦为此次训练提供了总计几百万帧、50000集的《吃豆人》剧本。该公司的 Koichiro Tsutsumi 表示：“在看到这个结果时,我们都感到震惊,大家都无法相信可以在没有游戏引擎的情况下再现了南梦宫的经典游戏《吃豆人》。这项研究将帮助游戏开发人员加快新关卡、角色甚至游戏的开发。一想到这一点,我们就感到十分兴奋。”
不过,复刻游戏只是开始,英伟达的目标是扩展模型来捕捉更复杂的现实世界环境。英伟达多伦多研究实验室主任 Sanja Fidler 表示：“我们最终将训练出一个 AI,其只需通过观看视频和观察目标在环境中所采取的行动,就能模仿驾驶规则或物理定律。” 而 GameGAN 只是第一步。
Nvidia GameGAN Research：
https://cdn.arstechnica.net/wp-content/uploads/2020/05/Nvidia_GameGAN_Research.pdf
原文链接地址： https://developer.baidu.com/topic/show/291047
导读 ：云原生操作系统进化,详解阿里云 ACK Pro、ASM、ACR EE、ACK @Edge 等四款企业级容器新品。
KubeCon 2020 中国站,阿里云容器服务负责人易立会在《云原生,数字经济技术创新基石》的演讲中,分享阿里云原生如何助力数字技术抗‘疫’,阐述阿里云对云原生操作系统的思考,同时详解阿里云 ACK Pro、ASM、ACR EE、ACK @Edge 四款企业级容器新品。
容器服务 ACK Pro,为企业级大规模生产环境提供增强的可靠性安全性,以及与可赔付标准 SLA,现已开启公测。同时还有三款产品商业化：服务网格 ASM,统一精准管控容器化微服务应用流量；容器镜像服务企业版 ACR EE,公共云首个独享实例形态的容器镜像仓库产品,是支撑阿里巴巴经济体的双十一同款利器,具备如下能力：多维度安全保障、全球镜像分发加速、DevSecOps 交付提效特点,保障企业客户云原生制品的安全托管及高效分发；边缘容器 ACK @Edge 采用非侵入方式增强,提供边缘自治、边缘单元、边缘流量管理、原生运维 API 支持等能力,以原生方式支持边缘计算场景下的应用统一生命周期管理和统一资源调度。
疫情期间,争分夺秒的云原生
云计算是数字时代新基建,而 2020 疫情也为数字化生活按下了快进键。“上班用钉钉,上学云课堂,出门健康码,订菜送到家”成为了日常生活一部分,这背后是一系列云计算、云原生技术支撑的业务创新。
2 小时内支撑了钉钉业务 1 万台云主机的扩容需求,基于阿里云服务器和容器化的应用部署方案,钉钉应用发布扩容效率大大提升,顺利扛住有史以来最大的流量洪峰,为全国用户提供线上工作的流畅体验。
停课不停学,希沃课堂整体业务性能提升 30%、运维成本降低 50%,洋葱学院系统资源利用率提升 60%。
健康码基于云原生大数据平台具备弹性、韧性和安全的特点,平稳支撑每日亿次调用。
盒马通过阿里云边缘容器服务 ACK @Edge ,快速构建人、货、场数字化全链路融合,云、边、端一体化协同的天眼 AI 系统。结合了云原生技术体系良好的资源调度和应用管理能力,与边缘计算就近访问,实时处理的优势,轻松实现全方位的**『降本提效』**,门店计算资源成本节省 50%,新店开服效率提升 70%。
云原生操作系统的诞生与进化
容器技术的发展揭开了云原生计算的序幕,在易立看来, Kubernetes 为基础的云原生计算也已经成为新的操作系统,云原生操作系统的雏形被越来越多的行业和企业采纳并因此受益：容器应用化、容器编排系统和 Istio 服务网格等技术依次解耦了应用与运行环境、资源编排调度与底层基础设施、服务实现与服务治理等传统架构的依赖关系。
阿里云为用户提供了怎样的云原生操作系统？这个云原生操作系统又有哪些突出特点呢？
首先基础设施层是强大的 IaaS 资源,基于第三代神龙架构的计算资源可以更弹性的扩展,以更加优化的成本提供更高的性能；云原生的分布式文件系统,为容器持久化数据而生；云原生网络加速应用交付能力,提供应用型负载均衡与容器网络基础设施。
其次在容器编排层,阿里云容器服务自 2015 年上线来,伴随数千家企业客户,共同实践过各行各业大量生产级场景。越来越多的客户以云原生的方式架构其大部分甚至全量应用,随着业务深入发展,为了满足大中型企业对可靠性、安全性的强烈需求,阿里云推出新品可供赔付 SLA 的容器服务企业版 ACK Pro。
容器服务企业版 ACK Pro 横空出世：全面安全、高性能,支持新一代神龙架构,SLA 可赔付
容器服务企业版 ACK Pro,是在原容器服务 ACK 托管版集群的基础上发展而来,其继承了原托管版集群的所有优势,例如 Master 节点托管和高可用等。同时,相比原托管版进一步提升了集群的可靠性、安全性和调度性能,并且支持赔付标准的 SLA,高达 99.95%,单集群可支持 5000 节点。ACK Pro 非常适合生产环境下有着大规模业务、对稳定性和安全性有高要求的企业客户。
ACK Pro 支持神龙架构,凭借软硬一体的优化设计,可为企业应用提供卓越的性能；支持无损 Terway 容器网络,相比路由网络延迟下降 30%；为企业提供全面安全防护,支持阿里云安全沙箱容器,满足企业客户对应用的安全、隔离需求,性能相比开源提升 30%。此外,ACK Pro 提供了对异构算力和工作负载优化的高效调度,支持智能 CPU 调度优化,在保障 SLA 和密度的前提下,Web 应用 QPS 提升 30%；支持 GPU 算力共享, AI 模型预测成本节省 50% 以上。
阿里云视频云已在全球十多个区域使用容器服务作为服务基础,有效管理全球万级节点的资源,其中 ACK Pro 切实保障基础设施层大规模计算资源的运维效率和高稳定性,使视频云团队可以将更多时间精力聚焦在视频领域从而为客户提供更多价值。
近日, 阿里云容器服务并成为国内首批通过可信云容器安全先进性认证的企业级容器平台,以 49 个满分项目荣获最高级别先进级认证,特别是在最小化攻击面,二进制镜像验签名,密文的 BYOK 加密等能力上国内领先,达到国际先进水平。
容器服务 ACK Pro 现已正式开启公测,非常适用于互联网、大数据计算、金融政府及跨海业务企业等,欢迎各位感兴趣的客户在官网上申请试用。
业内首个全托管 Istio 兼容服务网格 ASM,多种异构应用服务统一治理
在服务网格技术诞生前,应用服务治理的逻辑实现通常都是以代码库的方式嵌入在应用程序中,随着应用复杂度的增长和团队规模的扩大,代码库变更和维护会变地越来越复杂。服务网格通过 Sidecar 代理功能,将服务治理能力与应用程序本身解耦,将服务治理能力标准化、统一化,且更好地支持多种编程语言和技术框架的应用服务。
作为业内首个全托管 Istio 兼容的服务网格产品 ASM,已经正式商业化发布,用户可以在多个地域部署使用。阿里云一开始从架构上就保持了与社区、业界趋势的领先性,控制平面的组件托管在阿里云侧,与数据面侧的用户集群独立。ASM 在托管的控制面侧提供了用于支撑精细化的流量管理和安全管理的组件能力。通过托管模式,解耦了 Istio 组件与所管理的 K8s 集群的生命周期管理,使得架构更加灵活,提升了系统的可伸缩性。
商米科技使用服务网格 ASM 之后,充分享受了 Service Mesh 带来的好处,解决了 GRPC-HTTP2.0 多路复用引起的负载不均衡的问题,得以分离控制平面和数据平面,受益于 ASM 的可视化方式对控制平面进行管理,对规则配置一目了然。同时还无缝结合链路监控（Tracing Analysis）解决服务化体系下调用链排查追踪问题。
作为多种类型计算服务统一管理的基础设施, ASM 提供了统一的流量管理能力、统一的服务安全能力、统一的服务可观测性能力、以及统一的数据面可扩展能力, 并提出了相应的实践之成熟度模型。针对用户不同的场景, 逐步采用, 分别为一键启用、可观测提升、安全加固、多种基础设施的支持以及多集群混合管理。
全球镜像同步加速,ACR EE 保障云原生制品的安全托管及高效分发
容器镜像服务企业版 ACR EE 面向安全及性能需求高,业务多地域大规模部署的企业级客户,提供了公共云首个独享实例模式的企业版服务。
在制品托管部分,ACR EE 除了支持多架构容器镜像,还支持多版本 Helm Chart 等符合 OCI 规范制品托管。在分发及安全治理部分,ACR EE 加强了全球多地域分发和大规模分发支持,提供网络访问控制、安全扫描、安全加签、安全审计等多维度安全保障,助力企业从 DevOps 到 DevSecOps 的升级。目前已有数百家企业线上环境大规模使用,保障企业客户云原生应用制品的安全托管及高效分发。
某国际零售巨头是全球多地域业务形态,存在多地研发协作及多地域部署的场景。采用 ACR EE 之后,客户只需配置实例同步规则,在业务迭代更新容器镜像后,可实现分钟级自动同步至全球指定地域,自动触发 ACK 集群业务部署。完美应对跨海网络链路不稳定、分发不安全的问题,极大提高业务研发迭代效率和部署稳定性,保障企业业务的全球化部署。
除了业务镜像全球自动化部署,也有很多企业通过 ACR EE 的云原生应用交付链功能,通过全链路可追踪、可观测、可自主配置等实践容器化 DevSecOps。
业界首创“云边一体化”理念 ,边缘容器服务 ACK @Edge 正式商业化
与此同时,阿里云深度挖掘了“边缘计算+云原生落地实施”诉求,在去年 KubeCon 上,重磅发布了边缘容器（ACK@Edge）,时隔一年,宣布 ACK@Edge 正式商用。此外,ACK@Edge 也将其核心能力开源,并向社区贡献完整的云原生边缘计算项目——OpenYurt。
在过去短短一年的时间里,该款产品已经应用于音视频直播、云游戏、工业互联网、交通物流、城市大脑等应用场景中,并服务于盒马、优酷、阿里视频云和众多互联网、新零售企业。
YY 使用 ACK@Edge 之后,可以 API 统一管理、统一运维边缘容器集群和中心容器集群,边缘算力快速接入并实现边缘节点自治,同时也可以无缝接入 Prometheus 服务实现监控数据上报,总体上运维效率和资源使用率都得到显著改善。
ACK@Edge 适用于丰富的应用场景, 包括边缘智能、智慧楼宇、智慧工厂、音视频直播、在线教育、CDN。
云原生技术不但可以最大化云的弹性,帮助企业实现降本提效；而且还意味着更多创新的想象空间, 云原生将和 AI, 边缘计算,机密计算等新技术相结合,为数字经济构建智能、互联、信任的创新基础设施。
“新基石、新算力、新生态是容器产品发展策略 ” ,易立称, “云原生技术正成为释放云价值的最短路径,团队会帮助企业更好支撑混合云、云边一体的分布式云架构和全球化应用交付。基于云原生的软硬一体化技术创新,如神龙架构,含光芯片,GPU 共享调度等,阿里云将加速业务智能化升级。同时我们还会通过开放技术生态和全球合作伙伴计划,让更多企业分享云时代技术红利。” “ 阿里巴巴云原生 关注微服务、Serverless、容器、Service Mesh 等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践,做最懂云原生开发者的公众号。”
前言：春节期间因为疫情影响只能在家,正好用来进行网上视频复习,并在1月28日完成CKAD的考试,1月29日拿到通过证书,加上去年底拿到的CKA证书,我已经通过了CNCF的两大认证,即CKA和CKAD。应LF开源软件大学的邀请,写下这篇文章,介绍我为什么考CKA以及我的备考经验,希望可以帮助到有同样想法的同学。
首先为什么要学习云原生？
2011年著名互联网企业家和投资人Marc Andreessen在《华尔街日报》上指出“Software is eating the world”,他指出很多行业的创新领先者（例如广告行业的谷歌,视频行业的netflix）其实都是软件公司。而现在这个趋势越来越明显,即所有的行业都在进行数字化改造,每个行业的创新领先公司都是技术公司,是能充分利用互联网技术优势的互联网化的公司。而互联网公司中,研发是重要的基础部门。互联网研发的两个重要特点：1.是 Agile,即快速的迭代上线；2是scale,即能低成本进行快速弹性伸缩,流量激增的时候能快速扩容扛住,容量减少的时候也能快速缩容来降低成本。能比同行业的竞争对手进行更快的迭代和更低成本的伸缩是他们胜出的关键优势之一。
而要做到agile和scale,快速迭代的研发团队流程,弹性伸缩的基础设施还有易扩展和演进的系统架构,这三者缺一不可。而这三者的演进趋势：研发流程从瀑布到Agile,再到现在的DevOps；系统架构从单体到分层, 再到微服务；基础设施从实体机到虚机,再到容器和容器编排； 都无一不深刻的体现出“唯有更好的支持Agile & Scale,才是研发演进的方向“。而工程师以后不会有开发/测试/运维之分,只会有负责上层业务开发和维护的工程师和负责下层基础设施开发和维护的工程师之分了,而且即使是业务工程师也需要了解和完成部分底层基础设施的一些工作,（虽然严格来说基层技术设施和上层业务是解耦的。）所以每个工程师要在未来的5年内保持竞争力,都需要了解云原生的一些基础知识,了解和使用Docker和Kubernetes技术。
为什么要通过CKA + CKAD考试？
而要学习一门技术,尤其是一门在不断迭代而内容和范围又非常广泛的技术（Kubernetes版本发布很快,每年4个大版本）,如果不从一开始即建立一个大的picture即完整的知识体系,而是从一些细小的地方从源码开始啃起,很容易陷入“只见树木不见森林”的地步,而且学习效率也会偏低。而如何建立起一个大的picture呢？先从外到内,即先会使用,然后了解其原理和机制,必要的时候才去定制。那么如何验证我已经从使用的角度来建立起大的picture呢？感谢CNCF的组织,他们有现成的Kubernetes学习和认证体系,即通过他们的认证,那么可以比较有信心的确认已经建立起一个完整的知识体系,从而为下一步的学习和研究打下很好的基础。而这个CNCF的认证体系就是CKA和CKAD。CKA适合系统管理员,CKAD适合应用开发者,两个考试相同的部分是对Kubernetes的架构和术语都要求熟练了解, 不同的地方是CKA中会有setup cluster,debug 和fix cluster问题的内容,而CKAD会有Pod Design方面的内容。
而我在百度内部编写大纲和教材,召集志愿者作为讲师,并组织完成了10期Kubernetes Bootcamp即入门训练营。每期采用线下授课方式,使用百度云Kubernetes集群作为实际环境,采用边讲边练的方式进行大量的实操,每期5个晚上,共5门课程12个小时。已经有500+工程师参加培训,口碑反馈特别好。而通过CKA和CKAD认证更能验证我组织的大纲和培训方式是有助于学员进行云原生基础知识的学习,为之后进一步业务上云做好思想上和技能上的准备。
准备考试的心得： 首先需要了解考试的特点。CKA和CKAD都是上机考试,没有选择/填空/问答之类的题目,全是上机面对Kubernetes集群的操作,所以记住一定要在Kubernetes集群里多练习,minikube和katacoda提供的单机和网上集群可以多使用。另外因为CKA有Initial setup和TLS bootstrapping的内容,所以去AWS或则Azure上建虚拟机,直接搭建集群也是很有帮助的,而且有些debug的操作是需要在集群的master节点和node节点上ssh进去执行的,所以多自己搭建下是很有必要的。 其次需要了解考试大纲。CKA和CKAD都有自己的大纲,比较详细,需要针对大纲的每一个内容进行有针对性的学习和准备。别觉得目的性太强,要建立起使用者的知识体系,这些大纲对应的内容是必须要掌握的。 最后需要熟悉Kubernetes的官网文档,尤其是Task部分。因为考试时间比较紧张,CKA 3个小时,CKAD2个小时,普遍反应都是时间不够。上机考试环境中是没有时间让你从头来敲键盘输入YAML文件内容的,更多都是找到Task对应的部分,Copy 现成的YAML文件下来,然后快速修改,最后完成指定操作。例如CKA和CKAD都有使用Secret的部分,即创建Secret,然后在Pod中通过环境变量或者Volume的方式来使用。建议比较省时的方法即在kubernetes.io/docs使用“inject+secret”查到第一个结果,即Task中的一个例子,然后把该例子中的YAML 内容Copy到考试使用的终端上,然后再根据题目要求修改下,最后执行,这样能节省大量的时间。 另外别忘了CNCF提供了很优秀的线上视频课程,其中面向管理员的《Kubernetes 基础课程》（LFS258）和面向开发者的《kubernetes开发员课程》（LFS 259）是很有用的。在家封闭的这几天,把这些视频内容快速重温了下,再去通过线上考试就心里有底多了。
后记：
当然呢,通过CKA和CKAD考试,对于某些同学来说增强职场竞争力,甚至作为入职某些云企业的敲门砖是很有用的,但是从我的角度来说,建立起从使用角度的整个知识体系（而这个体系是经过大企业和开源基金会认证和背书 过的）,从而为下一步的更深入学习建立基础,这才是我希望达到的目的,而毫无疑问,CKA和CKAD可以帮助我,确认我已经达到一定水准。
【围观】麒麟芯片遭打压成绝版,华为亿元投入又砸向了哪里？>>>
摘要 ： NAS“日志分析”新功能,旨在帮助用户更好地监控文件系统资源。通过该功能,用户可以方便地跟踪系统性能问题,记录文件系统上的数据操作情况,审计文件删除等相关操作,有效监控各区域内文件系统资源大盘和明细信息,实时报警等
NAS文件存储是阿里云提供给用户的云上高性能文件系统存储服务。数据安全和性能是用户对文件存储服务最关注的两大因素,经常有用户反映以下这些情况：
- 我想查看自己的文件存储服务性能指标（吞吐,iops等等）
- 我想了解自己的文件系统内数据操作分布（读、写、新建、删除）
- 我的文件系统内某某文件怎么没了？（文件误删除）
为了更好地服务用户,让用户清晰地了解到自己的文件系统在云上的运行状况,我们新推出了“NAS日志分析”功能,旨在帮助用户更好地管理文件系统资源。通过该功能,用户可以方便地跟踪系统性能问题,记录文件系统上的数据操作情况,审计文件删除等相关操作,有效监控各区域内文件系统资源大盘和明细信息,实时报警等。
NAS日志分析功能是阿里云文件存储（NAS）和日志服务（SLS）联合研发出的一个内建于NAS控制台内的日志分析功能,该日志分析服务能够实时写入10M/s 的日志数据,并实时分析每秒1000万行的日志记录,计算处理延时在秒级别以内。
1. 如何开通
目前NAS日志分析功能处于上线公测阶段,需要用户主动申请开通服务。
具体步骤如下：
步骤一,申请开通
登录阿里云官网NAS控制台,在控制台首页找到“NAS现已开通用户级监控”一栏,并点击“申请”按钮
步骤二,填写申请信息
填写具体的申请信息后,点击提交
步骤三,等待审批通过
等待阿里云后台运营人员审批通过,在审批通过后,在NAS控制台左侧导航栏中将会显示“日志分析”一栏
步骤四,进行日志授权
“NAS日志分析”功能涉及到使用用户自己的日志存储（由日志服务SLS提供）,需要用户授权NAS服务将日志数据写入日志存储的相关权限。
用户需要如下操作：
点击“日志分析”->“日志管理”一栏,在右侧主页中点击“授权入口”,授权阿里云NAS服务可以写入您的日志存储数据。
在跳转的授权页面中,点击“同意授权”。
步骤五,创建相应文件系统的日志转储
相关授权操作完成后,即可创建您相应文件系统的日志转储,将对应文件系统的运行日志导入您自己的日志存储（Log Store）中,以进行后续的日志分析工作。
至此,您已完成了NAS日志分析功能的完整配置。NAS日志数据已经导入到您自己的日志存储中,日志服务会在后台为您的NAS日志数据进行分析,随后您即可看到相关的日志分析信息。
2. 使用指南
在用户完成上述的服务开通和配置后,用户即可浏览相关的日志分析数据。
2.1 日志管理
登录阿里云官网NAS控制台,在左侧导航栏中点击“日志分析”->“日志管理”一栏,展示NAS日志分析功能的日志管理视图
上图右侧列表中列出的2个文件系统表明已经由用户配置了日志分析功能,可以通过左侧的分析视图查询这2个文件系统相关的日志分析数据。
在列表的右侧有“操作”一栏,其中：
“点击前往”链接去往该日志最终存储的日志服务（SLS）控制台,在那里用户可以进行更细化的日志分析行为；
“停止”可以让用户手动关停某个文件系统的日志分析服务,该文件系统将从日志管理列表中移除,并停止日志数据的采集过程。
2.2 日志视图
用户在对已经配置了日志分析服务的文件系统进行一段时间的数据访问和操作后,系统会产生相关的访问日志,并采集相关日志数据,将其转储到日志服务（SLS）的Log Store中,日志服务对采集到的日志数据进行数据分析,随后,用户就可以通过日志视图查询到相关的分析和统计数据。
如上图左侧红框所示,目前提供了三个维度的文件系统日志分析视图：
总览视图：总览该区域内各个文件系统的总体指标、操作分布、客户端分布等
明细视图：详细展示具体的读写数据流、操作趋势、平均读写大小、异常状态等
审计视图：展示文件系统的创建、删除、读取、写入的审计信息等
2.2.1 总览视图
总览视图展示相应区域内文件系统资源访问的整体情况,包括分析的文件系统个数、总的写入流量和读取流量、最近访问的客户端个数、每个文件系统的客户端分布情况、创建、删除、读写数据的整体分布情况等。
2.2.2 明细视图
明细视图详细展示具体文件系统的数据操作细节。
写 -> 读数据流
展示了每个文件系统数据流入流出的情况,图表左侧表示客户端向文件系统写入数据,右侧表示客户端从文件系统读出数据。
最近访问的文件数量
展示了每个文件系统内最近访问的文件数量
操作趋势
展示了每个文件系统（NFS类型）在操作过程中单位时间内NFS协议的交互次数。
写 / 读操作流量趋势
展示了每个文件系统在读写数据时单位时间内的数据流量统计
平均写 / 读操作大小
展示了每个文件系统在读写数据时单位时间内平均单次IO的读写数据块大小
读写客户端 Top
展示了客户端对相关文件系统操作的分布和热度
操作错误 Top 客户端
展示了客户端在与文件系统的NFS协议交互中返回错误状态的分布情况,这个“错误”不代表服务端异常,而是正常的协议交互错误,比如：客户端ls某个文件,而该文件不存在。
这个指标可以在一定程度上反向指导上层业务是否发生异常或者存在bug,比如,我们曾经遇到过一个客户案例,其有一个后台批处理应用频繁遍历若干不存在的目录,该指标值会瞬间拉升,最终发现是由于批处理进程存在一个遍历目录的bug,将路径拼错,导致业务暂停,造成了一定的损失。通过该指标,再结合相关报警,可以从数据源头感知业务的变化,从而帮助业务系统快速发现问题,解决问题。
热点操作分布
展示了每个文件系统常见操作的分布情况,这些常见操作包括创建目录（mkdir）、读目录（ls,遍历目录下的文件）、写（write）、读（read）、删除（rm）、重命名（rename）、以及其他。
热门文件
展示了每个文件系统内被访问频次较高的文件的分布情况,目前仅分析到文件所在inode,并没有给出文件在文件系统内的全路径,用户可以使用debugfs等相关工具根据文件inode反查pathname
异常操作分布
展示了每个文件系统内异常操作的分布情况,如鉴权失败、网络错误、读写错误等
操作状态分布
展示了每个文件系统内整体操作的分布情况
2.2.3 审计视图
审计视图展示各文件系统内的敏感操作的审计信息和历史记录
创建操作数
展示了每个文件系统在统计时间内的创建文件数量和分布
删除文件数
展示了每个文件系统在统计时间内的删除文件数量和分布
读取文件数
展示了每个文件系统在统计时间内的读取文件数量和分布
写入文件数
展示了每个文件系统在统计时间内的写入文件数量和分布
文件操作趋势图
在时间轴上展示了区域内所有文件系统的常见操作的分布和趋势,常见操作包括读文件、写文件、删除文件、创建文件等。
最近被删除文件列表
展示了该区域内最近发生删除操作的目录的历史列表,列表中包含了被删除文件所在父目录的inode、所在文件系统、执行删除操作的来源IP、挂载文件系统的NFS版本号、该目录下最近删除文件数目等信息
最近创建的文件
展示了该区域内最近发生创建操作的目录的历史列表,列表中包含了被创建文件所在父目录的inode、所在文件系统、执行创建操作的来源IP、挂载文件系统的NFS版本号、该目录下最近创建文件数目等信息
最近写文件 Top
展示了该区域内最近发生写操作的文件Top榜,列表中包含了写操作所在文件系统、写操作文件inode、统计时间内的写数据大小、执行写操作的客户端数量、挂载文件系统的NFS版本号等信息
最近读文件 Top
展示了该区域内最近发生读操作的文件Top榜,列表中包含了读操作所在文件系统、读操作文件inode、统计时间内的读数据大小、执行读操作的客户端数量、挂载文件系统的NFS版本号等信息
2.3 日志字段详解
在用户完成日志配置后,文件系统的访问日志将转储到日志服务（SLS）的Log Store中,通过“日志管理”列表中的操作栏“点击前往”可以进入SLS详情页查看具体的NAS日志数据,其具体日志字段释义如下：
| 字段名 | 字段值 | 字段含义 |
|---|
| ArgIno | 226 | 文件系统inode号 |
| AuthRc | 0 | 授权返回码 |
| NFSProtocolRc | 0 | NFS协议返回码 |
| OpList | null | NFSv4 Procedures编号 |
| Proc | 1 | NFSv3 Procedures编号 |
| RWSize | -1 | 读写大小,单位字节 |
| RequestId | 5ACF5CD506EAC7A508F056DF | 请求ID |
| ResIno | null | lookup的资源inode号 |
| SourceIp | 172.18.159.169 | 客户端IP |
| User | *********** | 用户ID |
| Vers | 3 | NFS协议版本号 |
| Vip | 172.18.158.178 | 服务端IP
Volume | microtime
******** | 1523539157201995
文件系统ID | 请求发生时间,单位微秒 |
3. 注意事项
- 关于日志分析是否跨区域
不跨区域。
NAS日志分析功能目前以区域（Region）划分,如华北1、华北2、华东1、华东2,不同区域产生各自的日志分析视图,同一个区域内的多个文件系统的日志数据做聚合分析,目前暂不支持对跨区域的文件系统做聚合分析。
- 关于文件系统类型的支持
目前NAS日志分析功能仅支持NFS协议类型,后续会支持SMB等其他类型。
- 关于日志分析结果的延迟
正常情况下,NAS日志从被采集到转储,到最终分析出结果,最大延迟在10s以内。
- 关于收费
NAS日志分析功能,目前处于申请公测阶段,在此期间,该功能不会产生任何费用。在公测阶段结束后,NAS可以免费将日志数据开放给用户,但日志存储和日志分析需要使用日志服务（SLS）的相关功能,其计费标准可以参考现行日志服务（SLS）的 计费说明 。
作者： nas-hz
原文链接
本文为云栖社区原创内容,未经允许不得转载。
【围观】麒麟芯片遭打压成绝版,华为亿元投入又砸向了哪里？>>>
摘要： 梨视频大部分的业务都选择了阿里云,其中一个主要原因是阿里云提供基于钉钉群构建的24贴身技术支持,刘隽表示,这种服务模式可以更充分、高效的对接需求,快速得到反馈,这也让梨视频的同学有信心去尝试一些新的方案。
在上海云栖大会视频专场中,梨视频CTO刘隽先生分享了梨视频拍客生产全流程及其背后的技术,同时作为业务使用方,向现场嘉宾阿里云产品的使用实践。
云上拍客梨视频
梨视频是全球第一资讯短视频内容生产和消费平台,拥有5万名全球核心拍客,遍布全球七大洲,覆盖525个国际主要城市和2000多个国内区县。通过报题、派题全流程流转和30分钟响应,实现日均生产1500条资讯短视频,日均全网VV高达10亿。
对于梨视频来说,调度和分发能力至关重要。刘隽表示,在如此大体量的生产强度下,梨视频从上线至今,没有出现一条出现内容偏差,它背后就是靠SPIDER全流程管理系统来支持。整个流程从拍客上传素材开始,后方统筹和拍客主管会进行审核求证,素材剪辑完成后再进行稿件审核与自动化包装。整套流程支持了五万拍客,每天1000条的产量。在传统媒体中,可能需要1500人才能实现同等的产量,成本可能会高10倍。
刘隽表示,我们是在一个特别的时代,在做技术方案调研的时候,就有很成熟的云上的解决方案。梨视频整个技术团队（含测试）只有30个人,用3个月的时间就将APP上线,还包括整个后台系统、大数据平台和智能推荐。所以在他看来,基于云来思考,做技术选型和技术实践,是这么小的团队在如此短的时间做这么多的事情的先决条件。
基于云架构的全套架构实践
梨视频整套的视频点播、直播的方案都是基于阿里视频云构建的,非常少的代码就可以实现视频的转码、存储和分发。
同时,梨视频大数据推荐系统基于阿里云的LogStore和EMR构建,因为有了EMR,五个人的大数据团队就能够实现非常精准、高效的智能推荐的业务。
而自动化包装系统,则是基于阿里云GPU的算力构建,平台编辑只需要去做内容,包装系统负责进行片头、片尾、角标处理等,根据不同平台会有不同的自动化包装方案。
另外,梨视频APP中拍客的采集、上传是基于阿里云的短视频SDK来构建解决的,可以实现手机端的快速视频个性化采集能力,让拍客随时随地记录新闻。
梨视频大部分的业务都选择了阿里云,其中一个主要原因是阿里云提供基于钉钉群构建的24贴身技术支持,刘隽表示,这种服务模式可以更充分、高效的对接需求,快速得到反馈,这也让梨视频的同学有信心去尝试一些新的方案。
在分享的最后,刘隽表示梨视频在未来会基于阿里云等合作伙伴,用技术提升生产效率,让视频的处理更加智能,为用户呈现更多有营养的资讯短视频。
原文链接
本文为云栖社区原创内容,未经允许不得转载。
【围观】麒麟芯片遭打压成绝版,华为亿元投入又砸向了哪里？>>>
摘要： 针对不同数据库间数据实时同步难的问题,日前,阿里云宣布推出混合云数据同步一站式解决方案,便于广大云产品用户实现实时数据同步的混合云支持,更为方便的是,该功能让本地Oracle也能实现与云上数据库的实时同步。
针对不同数据库间数据实时同步难的问题,日前,阿里云宣布推出混合云数据同步一站式解决方案,便于广大云产品用户实现实时数据同步的混合云支持,更为方便的是,该功能让本地Oracle也能实现与云上数据库的实时同步。
目前,很多用户有云下或其他厂商的Oracle、MySQL到阿里云RDS或ECS自建数据库间的数据实时同步需求。DTS混合云数据同步功能,适用于多种用户应用场景,包括：
1、业务灰度切换
业务系统比较复杂时,不能一次性切换到阿里云。此时,业务可以按业务模块、区域或用户等维度逐步切换上云。业务上云过程中,通过DTS进行云上云下或跨云厂商数据同步,当流量切换异常时,可快速回滚业务,有效控制业务迁移风险。
2、数据灾备
即使是最可靠的服务提供商,也可能遇到倒霉的一天,为保证业务连续性,业务可以通过DTS混合云同步功能,在阿里云上快速搭建本地业务中心或其他云厂商的业务中心对应的数据灾备中心,当业务中心出现故障时,快速将业务切换到容灾中心,秒级恢复业务。
3、业务弹性扩展
因为云的灵活性、可扩展性及低成本,业务在大促等突发流量时,可以在阿里云弹性扩容并支持部分业务流量。此时,业务可以使用DTS混合云同步实现云上云下数据同步,保证业务访问本地化,有效提升用户体验。
4、阿里云云BI
阿里云提供一整套低成本、高可靠的大数据产品,用户可以通过DTS混合云同步功能,将线下数据库的业务更新实时同步到阿里云大数据产品,并基于阿里云大数据产品,快速、低成本得搭建自己的大数据应用及平台。
对于云下或云厂商的数据库,阿里云此次发布的解决方案,可以支持通过专线进行数据传输,兼顾了传输性能及数据安全性。包括：
Oracle到MySQL或DRDS的数据实时同步。
Oracle到OLAP（MaxCompute、分析型数据库AnalyticDB）的数据实时同步。
MySQL实例间的单双向数据同步。
MySQL到OLAP（MaxCompute、分析型数据库AnalyticDB、Datahub）的数据实时同步。
数据同步架构图如下：
据了解,目前该功能在国内处于领先位置,而且Oracle数据同步,及数据双向同步功能,目前国内仅有阿里云数据传输服务 DTS支持。
使用也十分方便,仅需三步： 登录数据传输服务DTS购买界面,购买数据同步实例 进入DTS控制台,配置需要同步的源实例及目标实例的连接方式、选择需要同步的库或表
配置完成后,进行启动前的预检查,预检查成功后,DTS自动启动同步实例。
了解更多,欢迎点击
https://www.aliyun.com/product/dts
有话想说？请点击下方【聚能聊话题】参与聊天哦,更有丰富奖品等你拿！
https://yq.aliyun.com/roundtable/65838?spm=a2c4e.11154000.rtmain.2.3bfb7bddeItoiQ
原文链接： http://click.aliyun.com/m/45013/
【围观】麒麟芯片遭打压成绝版,华为亿元投入又砸向了哪里？>>>
ZStack通过逻辑功能,将存储系统抽象成主存储和备份存储。一个主存储是一个存放VM磁盘的存储池；一个备份存储是这么一个存储,用户存储镜像模板、备份的磁盘、快照。主存储和备份存储可以是物理分离的存储系统,也可以是同一个存储系统同时扮演两种角色。存储厂商可以轻松地,通过实现相应的存储插件,在ZStack中加入他们的产品。
概述
云中的存储系统可以以它们的逻辑功能被分为两类。一类作为存储池工作,存储VM的磁盘,并可以被运行中的VM访问；这类存储可以是基于文件系统的,磁盘被作为文件存储；或者基于块存储,磁盘则变成了块设备。在ZStack的术语表中,这类存储被称为 主存储 ,要么可以是网络共享的存储,如NFS、ISCSI：
要么是本地存储,如物理主机的硬盘：
另一类存储系统作为仓库存在,存储含有操作系统的镜像模板,以及备份的磁盘和快照；这类存储可以是基于文件系统的,实体作为文件被存储；或者是基于对象存储的,实体作为对象被存储。在ZStack的术语表中,这类存储被称为 备份存储 ,对VM无法直接访问,只能是网络共享的存储：
这两种存储都是逻辑概念,事实上,它们可以是各自独立的存储系统,使用不同的协议。例如,ISCSI主存储和NFS备份存储。或者同一个存储系统,同时扮演两种角色。例如,ceph,它的块存储部分是用于满足主存储,而它的对象存储部分则扮演了备份存储的角色。存储厂商可以很容易地在ZStack中,同时为主存储和备份存储加入他们的存储系统,通过实现存储插件的方式。
内部实现
主存储和备份存储并不是分开工作的；它们为了执行存储相关的活动,确实需要相互合作。最重要的活动是为了创建一个新的虚拟机。当一个虚拟机是第一次在一个主存储上被创建,它的镜像模板将会被从备份存储下载到主存储的镜像缓存中。由于大多数hypervisor使用称为 链式克隆 的技术,一旦镜像模板被下载,它将为所有的,使用了同样的镜像模板且在同样的主存储中有根磁盘的虚拟机,作为基础磁盘来工作。
在下载镜像之外,主存储也会上传实体,像磁盘、快照,到备份存储；这些上传活动都是备份相关的；例如,当用户备份一个数据磁盘时,数据磁盘的一个副本将会被上传到备份存储,作为一个镜像模板,可以在之后被下载到主存储用于创建新的数据磁盘。
在源代码中,主存储和备份存储在不同的插件中实现。在复杂性方面,备份存储显得更直接,因为只处理自身的事情。备份存储的主要活动是下载、上传和删除。一个备份存储需要定义一些协议,规定主存储怎样下载和上传实体,但它不需要知道主存储的细节,因为这是主存储的责任去使用这些协议来执行这些活动。另外,备份存储必须实现一些协议,这些协议允许镜像服务注册和删除镜像模板。和所有的其他资源类似,备份存储有一个抽象的基类BackupStorageBase,已经实现了大多数通用的业务逻辑,存储厂商只需要实现那些和他们后台存储系统直接相关的操作,通常是通过调用SDK或调用agent。
主存储更加复杂。复杂的根源来自于这么一个事实,即它的业务逻辑不只是依赖于备份存储,也依赖于hypervisor的细节。一个主存储,首先,必须理解备份存储的协议,以下载和上传实体；例如,一个NFS主存储必须知道Sftp备份存储,亚马逊S3备份存储,Swift备份存储的信息,如果它计划支持所有的这些。另一方面,对于同一个备份存储,协议的使用方法也会随着不同的hypervisor而不同；例如,NFS主存储可以调用KVM agent去使用s3tool来从亚马逊S3备份存储下载一个镜像模板；然而,由于VMWare有一个封闭的生态系统,对于NFS主存储来说要做同样事情的唯一方式是通过VMWare的SDK。基于这些事实,主存储的复杂性是M*N,其中M是备份存储的种类,N是它所支持的hypervisor的种类。
正如 ZStack—通用插件系统 一文中所描述的,ZStack是一个插件系统,每一个特性都被做成一个小的插件；一个主存储需要定义两个接口来打破这个复杂性。第一个是一个hypervisor的后端,用于处理只和hypervisor有关的活动；例如,NFS主存储有个定义好的接口：NfsPrimaryStorageBackend,对每一个支持的hypervisor,都会有一个具体的类,类似NfsPrimaryStorageKVMBackend用于KVM。第二个,称之为PrimaryToBackupStorageMediator,是一个 hypervisor到备份存储 的后端,用于处理同时涉及到hypervisor和备份存储的后端；例如,Nfs主存储有一个NfsPrimaryToSftpBackupKVMBackup的实现,用于为KVM支持Sftp备份存储。
这听起来非常糟糕,因为一个主存储必须实现如此多的东西；然而,事实上,一个主存储可能不需要去为所有的hypervisor支持所有的备份存储；例如,为VMWare支持Sftp备份存储是毫无意义的,因为VMWare SDK没有可能允许用scp传输一个文件到它的存储仓（即使可以通过绕过SDK使得这成为可能,我们不把它视为一种可靠的方式）。而且网络共享存储上,流行的协议并不特别多,大多数的使用场景可以被处理,一旦我们把Nfs主存储和Iscsi主存储准备就位。
注意： 在当前的ZStack版本中（0.6）,只有Nfs主存储和Sftp备份存储被实现了。
总结
在这篇文章中,我们演示了ZStack的存储模型。通过以逻辑功能将存储划分成主存储和备份存储,ZStack提供了一个非常棒的灵活性,使得存储厂商可以选择性地以各种意图插入他们的存储系统。而且随着越来越的普遍的存储协议,比如NFS、ISCSI、S3、Swift,将被作为默认插件加入,用户将不需要忧虑他们是否能够为他们现存的存储系统找到合适的组合。
【围观】麒麟芯片遭打压成绝版,华为亿元投入又砸向了哪里？>>>
摘要： 事务消息提交或回滚的实现原理就是根据commitlogOffset找到消息,如果是提交动作,就恢复原消息的主题与队列,再次存入commitlog文件进而转到消息消费队列,供消费者消费,然后将原预处理消息存入一个新的主题RMQ_SYS_TRANS_OP_HALF_TOPIC,代表该消息已被处理；回滚消息与提交事务消息不同的是,提交事务消息会将消息恢复原主题与队列,再次存储在commitlog文件中。
本文将重点分析RocketMQ Broker如何处理事务消息提交、回滚命令,根据前面的介绍,其入口EndTransactionProcessor#processRequest： OperationResult result = new OperationResult(); if (MessageSysFlag.TRANSACTION_COMMIT_TYPE == requestHeader.getCommitOrRollback()) { // @1 result = this.brokerController.getTransactionalMessageService().commitMessage(requestHeader); // @2 if (result.getResponseCode() == ResponseCode.SUCCESS) { // @3 RemotingCommand res = checkPrepareMessage(result.getPrepareMessage(), requestHeader); // @4 if (res.getCode() == ResponseCode.SUCCESS) { MessageExtBrokerInner msgInner = endMessageTransaction(result.getPrepareMessage()); // @5 msgInner.setSysFlag(MessageSysFlag.resetTransactionValue(msgInner.getSysFlag(), requestHeader.getCommitOrRollback())); msgInner.setQueueOffset(requestHeader.getTranStateTableOffset()); msgInner.setPreparedTransactionOffset(requestHeader.getCommitLogOffset()); msgInner.setStoreTimestamp(result.getPrepareMessage().getStoreTimestamp()); // @6 RemotingCommand sendResult = sendFinalMessage(msgInner); // @7 if (sendResult.getCode() == ResponseCode.SUCCESS) { this.brokerController.getTransactionalMessageService().deletePrepareMessage(result.getPrepareMessage()); // @8 } return sendResult; } return res; } }
代码@1：如果请求为提交事务,进入事务消息提交处理流程。
代码@2：提交消息,别被这名字误导了,该方法主要是根据commitLogOffset从commitlog文件中查找消息返回OperationResult实例：
private MessageExt prepareMessage ：消息对象。 private int responseCode：查找结果。 private String responseRemark ：错误提示。
代码@3：如果成功查找到消息,则继续处理,否则返回给客户端,消息未找到错误信息。
代码@4：验证消息必要字段。
验证消息的生产组与请求信息中的生产者组是否一致。
验证消息的队列偏移量（queueOffset）与请求信息中的偏移量是否一致。
验证消息的commitLogOffset与请求信息中的CommitLogOffset是否一致。
代码 @5 :调用endMessageTransaction方法,该方法主要的目的就是恢复事务消息的真实的主题、队列,并设置事务ID。
代码@6：设置消息的相关属性,这一步应该直接在endMessageTransaction中实现就好,统一恢复原消息的数量,特别关注的是取消了事务相关的系统标记。
代码@7：发送最终消息,其实现原理非常简单,调用MessageStore将消息存储在commitlog文件中,此时的消息,会被转发到原消息主题对应的消费队列,被消费者消费。
代码@8：删除预处理消息(prepare),其实是将消息存储在主题为：RMQ_SYS_TRANS_OP_HALF_TOPIC的主题中,代表这些消息已经被处理（提交或回滚）。
上述就是事务消息提交的流程,事务回滚类似,接下来大概分析一下事务消息回滚的流程。 EndTransactionProcessor#processRequest else if (MessageSysFlag.TRANSACTION_ROLLBACK_TYPE == requestHeader.getCommitOrRollback()) { result = this.brokerController.getTransactionalMessageService().rollbackMessage(requestHeader); // @1 if (result.getResponseCode() == ResponseCode.SUCCESS) { RemotingCommand res = checkPrepareMessage(result.getPrepareMessage(), requestHeader); if (res.getCode() == ResponseCode.SUCCESS) { this.brokerController.getTransactionalMessageService().deletePrepareMessage(result.getPrepareMessage()); // @2 } return res; } }
代码@1：回滚消息,其实内部就是根据commitlogOffset查找消息。
代码@2：将消息存储在RMQ_SYS_TRANS_OP_HALF_TOPIC中,代表该消息已被处理,与提交事务消息不同的是,提交事务消息会将消息恢复原主题与队列,再次存储在commitlog文件中。
事务消息在Broker服务端的提交回滚流程就介绍到这了。其核心实现就是根据commitlogOffset找到消息,如果是提交动作,就恢复原消息的主题与队列,再次存入commitlog文件进而转到消息消费队列,供消费者消费,然后将原预处理消息存入一个新的主题RMQ_SYS_TRANS_OP_HALF_TOPIC,代表该消息已被处理；回滚消息与提交事务消息不同的是,提交事务消息会将消息恢复原主题与队列,再次存储在commitlog文件中。
作者： 丁威
原文链接
本文为云栖社区原创内容,未经允许不得转载。
.png)
大数据引擎.png)
大数据应用.png)
大数据底层技术.png)
ForeSpider软件
.png)
采集服务.png)
软件学习.png)
智能分析.png)
特征提取.png)
智能计算.png)
数据可视化.png)
数据分析应用.png)
系统集成服务.png)
代码工具.png)
金融方案.png)
制造业&物流.png)
企业数字化.png)
医疗方案.png)
政务方案.png)
实时监测.png)
智能分析.png)
数据智能挖掘.png)
全网自动采集.png)
场景智慧采集.png)
主题识别采集
022-2345 2937
185 2247 0110
business@forenose.com
022-2345 2937
185 2247 0110
business@forenose.com
前嗅大数据
津公网安备12010102001008号