数据专栏

智能大数据搬运工,你想要的我们都有

数据资讯

数据学院

数据百科

本文作者: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
来源:OSCHINA
发布时间:2019-09-12 17:18:00
本文作者: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
来源:OSCHINA
发布时间:2019-09-12 17:17:00
本文作者: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
来源:OSCHINA
发布时间:2019-09-12 17:17:00
本文作者: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
来源:OSCHINA
发布时间:2019-09-12 17:16:00
本文作者: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
来源:OSCHINA
发布时间:2019-09-12 17:16:00
本文作者: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
来源:OSCHINA
发布时间:2019-09-12 17:07:00
本文作者: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
来源:OSCHINA
发布时间:2019-09-12 17:06:00
基本介绍 经常遇到一些开发者问: 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); } 作者: 隽阜 原文链接 本文为云栖社区原创内容,未经允许不得转载。
来源:OSCHINA
发布时间:2019-03-05 15:32:00
本文作者: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
来源:OSCHINA
发布时间:2019-09-12 17:04:00
本文作者: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
来源:OSCHINA
发布时间:2019-09-12 17:04:00
本文作者: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
来源:OSCHINA
发布时间:2019-09-12 17:03:00
本文作者: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
来源:OSCHINA
发布时间:2019-09-12 17:01:00
本文作者:AIOps智能运维 干货概览 运维可视化 ,核心是将所运维的服务、资源、设备的状态和正在发生的事件通过可视化的手段呈现出来,指导运维人员或者产品研发人员做出正确的运维决策。某种程度上,运维与可视化相辅相成, 可视化程度越高,运维就越简单,运维效率也就越高 。 在运维的工作范畴中, 实时监控 对故障的发现和诊断起到至关重要的作用。今天,我们以监控中的一个重点场景-内网监控,来介绍可视化起到的重要作用。内网指的是一个公司的内部网络,包括 机房内部网络和机房间的网络 。 异常事件可视化 当运维工程师发现自己负责的系统出现故障时,检查网络连接是否有异常,是故障排查流程当中的标准步骤。在这个场景中,工程师需要知道自己的系统所在的机房以及所依赖的网络通路是否存在故障,所以希望内网监控系统提供一个 网络故障概览 ,展示在给定的时间段中相关机房的异常事件。 最简单的方式是将所有的网络故障展示在表格当中。如上表所示,每一行代表一个故障事件,第一列表示故障关联的机房,第二列是故障的起止时间,第三列是故障的严重程度。这种展现方式存在以下三个问题: 不能第一眼看出哪些故障严重,哪些故障轻微; 不能直观感受到每个故障的持续时长; 很难知道在某一时刻哪几个机房同时存在故障。 当时间段很长,筛选出的故障事件很多时,表格会变得很长,就更加不利于工程师了解网络状况了。 为解决以上问题,我们需要在 机房、时间、 程度 三个维度上都能直观的展示故障事件。从时间跨度来想,有点事件流的感觉,似乎可以用事件流图来展示。 图1 事件流图 如图1所示,事件流图用一条事件河流来表示事件。河流被横向切分为若干条色带, 每条色带代表一个类别的事件 。色带的高度(河流的宽度)代表在某个时刻,各类别包含事件的个数。事件越多,河流越宽,反之越窄。 这种事件流图适合展示在一段时间内事件群体的统计变化,而我们需要能够展示每个事件的个体信息。因此,我们对事件流图作了几个修改: 每个故障事件用一个矩形条表示,矩形条左右两边的位置对应事件的起止时间; 矩形条的颜色用来区分事件的严重程度,而不是事件的类别; 关联到某一个机房的故障事件矩形条放在河流的同一个高度位置。如果事件在时间上能完全错开,则将矩形条左右放置。如果事件在时间上有重叠,则拓宽机房所占河流的宽度,将矩形条上下放置。 图2 异常事件流图 图2展示了我们的事件流图方案。图中展示了三个机房的异常,其中机房一有一个严重的异常事件(用红色来标识),这个异常事件是一个时间跨度比较长的严重异常事件,机房二有4个轻度的异常事件(用黄色标识),这4个异常是时间跨度比较短的轻度异常事件,机房三有12个轻度的异常事件(用黄色标识),这12个异常事件中也有三个时间跨度比较长的时间。如果鼠标放置在异常事件矩形块上,能查看哪个机房出现异常。通过这个图,工程师可以很方便地看到每个机房的 每个故障事件的详细信息 ,比表格的方式直观得多。 总 结 事件流图, 从机房、时间、异常程度三个维度都能直观的展示故障事件,帮助工程师快速查看异常情况。其实,事件流图还可以用于 展示变更事件 ,甚至可以将变更事件与异常事件组合,让工程师能一眼查看异常事件可能是由哪些变更事件引起的。我们从智能运维场景中抽象出一些可视化组件,比如这里的事件流图组件,再通过前端工程化工具把这些子元素串联起来,构建出前端统一展现层框架, 后面我们会逐一介绍这些可视化组件与框架其他细节,请持续关注我们的AIOps智能运维公众号! 原文链接地址: https://developer.baidu.com/topic/show/290310
来源:OSCHINA
发布时间:2019-09-12 17:00:00
作者: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
来源:OSCHINA
发布时间:2019-09-12 16:37:00
最近这几年不知道大家有没有发现,就是传统的PC不在是企业办公时的唯一选择了,有很多的企业开始慢慢的把传统PC换成了更为小巧的 云终端 来进行上网办公的,换成云终端后真的可以达到传统PC一样的使用效果的吗,把传统PC换成云终端后,有怎样的不同体验的。 首先桌面的运算不同,虽然说我们使用云终端登录后系统界面和我们使用传统PC时是一样的,都是我们熟悉的Windows系统界面,但是在使用时我们会发现,登录云终端后系统桌面所显示的配置和云终端本身的配置并不是一样的,桌面性能的强弱更多的是取决于服务器所分配该终端用户所使用虚拟机资源的强弱。 第二数据的存储不同,虽然说有些片子高一点的云终端本身有一定的硬盘容量具备存储数据的功能,但是系统桌面所运行的数据并不是存储在云终端本地的,所有的数据都是存储云端服务器上,通过服务器进行统一的管理和运行,任何人访问重要数据或者想通过云终端来拷贝数据都需要得到授权才可以。 第三外设的支持不同,毫无疑问对于U盘等存储工具和打印机等常用的外设设备,云终端是完全可以支持的,但是对于一些其他的比较特殊或者不常用的外设设备如U盾等一些设备,由于桌面系统使用的是服务器上的虚拟机,所以对于这些外设设备,云终端的支持力度是没有使用传统PC时这么好用的。 第四故障的维护不同,那么传统PC换成云终端后对于故障的维护又有什么不一样的体验的呢?换成云终端后因为使用的都是服务器上分配的虚拟机系统,所以一旦系统出现故障,只需要在服务器上就可以完成系统的维护,而硬件方面由于云终端本地不就行运算和存储,当硬件出现故障后,直接换一个就可以,不用担心因更换设备而担心性能和数据这些问题的。 虽然一直都在说云终端的用户体验和传统的PC基本无差别的,但是真正使用和对比之后会发现,他们两者之间还是有不一样的体验的。 来源禹龙云
来源:OSCHINA
发布时间:2019-09-12 16:22:00
本文作者: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
来源:OSCHINA
发布时间:2019-09-12 15:59:00
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的能力的技术方案,后面会再对动态调度、动态业务配额管理、在线离线业务混部方案进行介绍。所有这些集群负载提升方案,要做到动态,都强依赖于强大的容器监控系统。我们正与腾讯云监控产品团队深入合作,更好的服务于腾讯自研业务上云。
来源:OSCHINA
发布时间:2019-09-12 10:49:00
本文作者: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
来源:OSCHINA
发布时间:2019-09-11 20:53:00
本文作者: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
来源:OSCHINA
发布时间:2019-09-11 20:38:00
本文作者: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
来源:OSCHINA
发布时间:2019-09-11 20:37:00
本文作者: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
来源:OSCHINA
发布时间:2019-09-11 20:32:04
本文作者: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
来源:OSCHINA
发布时间:2019-09-11 20:31:00
本文作者: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
来源:OSCHINA
发布时间:2019-09-11 20:28:00
本文作者: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
来源:OSCHINA
发布时间:2019-09-11 20:23:00
作者 | 阿里云售后技术专家 声东 导读 :当我们尝试去理解 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 集群才有机会摆脱机械和被动,变成一个自动、智能、有大用的系统。
来源:OSCHINA
发布时间:2019-09-11 18:41:00
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存储
来源:OSCHINA
发布时间:2020-03-30 08:56:00
本文作者: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
来源:OSCHINA
发布时间:2020-07-31 15:43:00
导读 :云原生操作系统进化,详解阿里云 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 等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践,做最懂云原生开发者的公众号。”
来源:OSCHINA
发布时间:2020-08-03 14:37:00
前言:春节期间因为疫情影响只能在家,正好用来进行网上视频复习,并在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可以帮助我,确认我已经达到一定水准。
来源:OSCHINA
发布时间:2020-02-13 14:10:00
PBR 渲染参数非常少 主要 albedo normal metalic smooth ao heightmap Unity 渲染管线 核心函数 fragForwardInternal Unity shader的PBR渲染 核心函数 UNITY_PBS_SHADE 支持三种函数类型 disney PBS 迪士尼 minialist micro 模型 Normal 模型 PBR渲染 参数 主要光参数是 直接光 UnityLight 和 UnityIndirect 间接光 间接光 包括 diffuse 和 specular 直接光主要是 光颜色和朝向 通过ImageBasedLight可以通过 HDR环境贴图 生成 间接光的 diffuse cubeMap 和 specular 的cubeMap 可以通过 IBL Baker 工具生成对应的环境光贴图 Unity中的 Probe 和 Reflection Probe 有类似的效果 但是没有HDR 的 贴图信息丰富, 不好创建丰富 细腻的环境光效果
来源:OSCHINA
发布时间:2020-05-18 19:51:00
用游戏服务器,注意事项 游戏为我们和生活带来了更多的趣味和精彩,很多游戏网站的站长在挑选租用游戏服务器时,主要看游戏服务器的什么方面,结合实际生活的各方面,注意游戏服务器提供商的信誉实力售后支持、服务器本身就看稳定性、带宽价格这些事项。 1.游戏服务器的提供商信誉实力 信誉实力在各行各业中都是最重要的,是现实中的保证。看一个游戏服务器服务商的信誉实力,可以从企业上传到网站的信誉之星,服务之星等一些证书进行查询。正规的游戏服务器运营商会形成一定的规模,如果有时间的话,为了以后各方面保障,直接去游戏服务器服务商那些考检他们的公司,从公司的大小,员工数量,工作态度,服务器信息相关交流等这些就可以大概有个了解。 2.游戏服务器稳定性 稳定是游戏服务器的前提,影响到稳定的有游戏服务器配置情况、今后的扩展、安全性能。游戏的质量越来越高,对各方面的要求也变大的。在配置方面,操作系统、应用软件、网卡、硬盘、内存、CPU等都选高一点,但也不要选得太离谱,以自己是什么游戏去定。游戏的更新也是很快的,为了可以适应游戏的变化,扩展性强的游戏服务器先看。至于安全性能,网络上的病毒、木马等种类很多,谁都不想在玩游戏时,经常被影响,所以有没有实时监控防护措施服务这也要注意。 3.游戏服务器所用带宽 无论是游戏服务器是用在大型单机下载,还是网络游戏,为了不造成传输时,带宽堵塞。宽带尽量大点,美国服务器所用一般100M、1G国际带宽可以满足传输要求。 4.游戏服务器租用价格 现在市面上游戏服务器的价格,在配置的不同、服务的不同,价格也完全不同。在游戏服务器价格上的定位,一定要理性对待。先选好提供商,然后根据游戏网站需要游戏服务器怎样的支持,进行服务器间比较,再决定。如 服务器。 5.游戏服务器售后支持 游戏服务器与其它服务器一样,当工作久了,肯定会偶尔出现故障。因此,随时都有服务技术支持和快速故障解决,这是游戏服务器最基本应该具备的。
来源:OSCHINA
发布时间:2020-05-18 14:17:00
客户端–发送带有 SYN 标志的数据包–一次握手–服务端 服务端–发送带有 SYN/ACK 标志的数据包–二次握手–客户端 客户端–发送带有带有 ACK 标志的数据包–三次握手–服务端 为什么要三次握手? 三次握手的目的是建立可靠的通信信道,说到通讯,简单来说就是数据的发送与接收,而三次握手最主要的目的就是双方确认自己与对方的发送与接收是正常的。 第一次握手:Client 什么都不能确认;Server 确认了对方发送正常 第二次握手:Client 确认了:自己发送、接收正常,对方发送、接收正常;Server 确认了:自己接收正常,对方发送正常 第三次握手:Client 确认了:自己发送、接收正常,对方发送、接收正常;Server 确认了:自己发送、接收正常, 对方发送接收正常 所以三次握手就能确认双发收发功能都正常,缺一不可。 为什么要传回SYN 接收端传回发送端所发送的 SYN 是为了告诉发送端,我接收到的信息确实就是你所发送的信号了。 传了SYN为什么还要传ACK 双方通信无误必须是两者互相发送信息都无误。传了 SYN,证明发送方到接收方的通道没有问题,但是接收方到发送 方的通道还需要 ACK 信号来进行验证。 断开一个 TCP 连接则需要“四次挥手”: 客户端-发送一个 FIN,用来关闭客户端到服务器的数据传送 服务器-收到这个 FIN,它发回一 个 ACK,确认序号为收到的序号加1 。和 SYN 一样,一个 FIN 将占用一个序号 服务器-关闭与客户端的连接,发送一个FIN给客户端 客户端-发回 ACK 报文确认,并将确认序号设置为收到序号加1 为什么要四次挥手 任何一方都可以在数据传送结束后发出连接释放的通知,待对方确认后进入半关闭状态。当另一方也没有数据再发送的时候,则发出连接释放通知,对方确认后就完全关闭了TCP连接。 举个例子:A 和 B 打电话,通话即将结束后,A 说“我没啥要说的了”,B回答“我知道了”,但是 B 可能还会有要说的 话,A 不能要求 B 跟着自己的节奏结束通话,于是 B 可能又巴拉巴拉说了一通,后 B 说“我说完了”,A 回答“知道了”,这样通话才算结束
来源:OSCHINA
发布时间:2020-06-03 11:27:00
在HTTP/1.0中默认使用短连接。 也就是说,客户端和服务器每进行一次HTTP操作,就建立一次连接,任务结束就中断连接。 当客户端浏览器访问的某个HTML或其他类型的Web页中包含有其他的Web资源(如JavaScript文件、图像 文件、CSS文件等),每遇到这样一个Web资源,浏览器就会重新建立一个HTTP会话。 而从HTTP/1.1起,默认使用长连接,用以保持连接特性。使用长连接的HTTP协议,会在响应头加入这行代码: Connection:keep-alive 在使用长连接的情况下,当一个网页打开完成后,客户端和服务器之间用于传输HTTP数据的TCP连接不会关闭,客户端再次访问这个服务器时,会继续使用这一条已经建立的连接。Keep-Alive不会永久保持连接,它有一个保持时间,可以在不同的服务器软件(如Apache)中设定这个时间。 实现长连接需要客户端和服务端都支持长连接。HTTP协议的长连接和短连接,实质上是TCP协议的长连接和短连接。
来源:OSCHINA
发布时间:2020-06-03 11:19:00
总体来说分为以下几个过程: DNS解析 TCP连接 发送HTTP请求 服务器处理请求并返回HTTP报文 浏览器解析渲染页面 连接结束
来源:OSCHINA
发布时间:2020-06-03 11:12:00
TCP更加可靠,因为TCP是面向连接的服务 TCP是字节流传输,UDP是数据报文段 TCP更慢,UDP更快,因为TCP要建立连接释放连接 TCP一般是文件传输,远程登录的应用场景,UDP一般是视频、直播等应用场景
来源:OSCHINA
发布时间:2020-06-03 11:09:00
记录下搭建rocketmq过程中遇到的坑:(集群机子代号这里列为:mq-a,mq-b,mq-a-s, mq-b-s) rocketmq搭建的是 双主双从 模式。三台机器,机器 a 、b 分别安装 双主 ,机器c 安装 双从 。 启动三个 nameserver,双主broker-master,双从broker-slave 服务器 rocketmq 是4.7.0版本 1. 第一个坑 - 项目rokcetmq 版本和服务器rocketmq版本没对上 :rocketmq 双主双从 搭建完,从 github 上下载的 rocketmq管理后台,本地跑起来,能成功连上rocketmq。然后自己写了的一个demo,发下报错,报错信息如下: 后来发现是 demo项目于中 pom的 rocketmq 依赖是 4.3.0, 和服务器4.7.0 对不上,然后我项目改成了 4.7.0的版本依赖。然后就ok了 附上 provider生产者的 demo代码 和 consumer消费者 的 demo 代码: ========>>>> provider 生产者代码: public class TestProvider { public static void main(String[] args) { try { //Instantiate with a producer group name. DefaultMQProducer producer = new DefaultMQProducer("p1"); // Specify name server addresses. producer.setNamesrvAddr("43.230.143.17:9876;58.82.250.253:9876;58.82.208.238:9876"); //Launch the instance. producer.start(); for (int i = 0; i < 10; i++) { //Create a message instance, specifying topic, tag and message body. Message msg = new Message( "testTopic" /* Topic */, "TagA" /* Tag */, ("Hello RocketMQ " + i).getBytes(RemotingHelper.DEFAULT_CHARSET) /* Message body */ ); //Call send message to deliver message to one of brokers. SendResult sendResult = producer.send(msg); System.out.printf("%s%n", sendResult); Thread.sleep(1000); } //Shut down once the producer instance is not longer in use. producer.shutdown(); } catch (Exception e) { e.printStackTrace(); } } } ========>>>> consumer 消费者代码: public class TestConsumer { public static void main(String[] args) { try { // Instantiate with specified consumer group name. DefaultMQPushConsumer consumer = new DefaultMQPushConsumer("c1"); // Specify name server addresses. consumer.setNamesrvAddr("58.82.250.253:9876;43.230.143.17:9876;58.82.208.238:9876"); // Subscribe one more more topics to consume. consumer.subscribe("testTopic", "*"); // Register callback to execute on arrival of messages fetched from brokers. consumer.registerMessageListener((MessageListenerConcurrently)(msgs, context) -> { // System.out.printf("%s Receive New Messages: %s %n", Thread.currentThread().getName(), msgs.toString()); System.out.println(" Receive New Messages: " + Arrays.toString(msgs.toArray())); return ConsumeConcurrentlyStatus.CONSUME_SUCCESS; }); //Launch the consumer instance. consumer.start(); System.out.printf("Consumer Started.%n"); } catch (Exception e) { e.printStackTrace(); } } }
来源:OSCHINA
发布时间:2020-06-03 10:45:00
互联网行业数据仓库/数据平台的架构 互联网行业数据仓库、数据平台的用途 1) 整合公司所有业务数据,建立统一的数据中心; 2) 提供各种报表,有给高层的,有给各个业务的; 3) 为网站或 APP 运营提供运营上的数据支持,就是通过数据,让运营及时了解网站和产品的运营效果; 4) 为各个业务提供线上或线下的数据支持,成为公司统一的数据交换与提供平台; 5) 分析用户行为数据,通过数据挖掘来降低投入成本,提高投入效果;比如广告定向精准投放、用户个性化推荐等; 6) 开发数据产品,直接或间接为公司盈利; 7) 建设开放数据平台,开放公司数据; 上面列出的内容看上去和传统行业数据仓库用途差不多,并且都要求数据仓库 / 数据平台有很好的稳定性、可靠性; 但在互联网行业,除了数据量大之外,越来越多的业务要求时效性,甚至很多是要求实时的 ,另外,互联网行业的业务变化非常快,不可能像传统行业一样,可以使用自顶向下的方法建立数据仓库,一劳永逸,它要求新的业务很快能融入数据仓库中来,老的下线的业务,能很方便的从现有的数据仓库中下线;其实,互联网行业的数据仓库就是所谓的敏捷数据仓库,不但要求能快速的响应数据,也要求能快速的响应业务; 建设敏捷数据仓库,除了对架构技术上的要求之外,还有一个很重要的方面,就是数据建模, 如果一上来就想着建立一套能兼容所有数据和业务的数据模型,那就又回到传统数据仓库的建设上了,很难满足对业务变化的快速响应。应对这种情况,一般是先将核心的持久化的业务进行深度建模(比如:基于网站日志建立的网站统计分析模型和用户浏览轨迹模型;基于公司核心用户数据建立的用户模型), 其它的业务一般都采用维度 + 宽表的方式来建立数据模型。 整体架构 逻辑上,一般都有数据采集层、数据存储与分析层、数据共享层、数据应用层。可能叫法有所不同,本质上的角色都大同小异。 我们从下往上看 数据采集 数据采集层的任务就是把数据从各种数据源中采集和存储到数据存储上,期间有可能会做一些简单的清洗。 数据源的种类比较多: 网站日志: 作为互联网行业,网站日志占的份额最大,网站日志存储在多台网站日志服务器上, 一般是在每台网站日志服务器上部署 flume agent ,实时的收集网站日志并存储到 HDFS 上; 业务数据库: 业务数据库的种类也是多种多样,有 Mysql 、 Oracle 、 SqlServer 等,这时候,我们迫切的需要一种能从各种数据库中将数据同步到 HDFS 上的工具, Sqoop 是一种,但是 Sqoop 太过繁重,而且不管数据量大小,都需要启动 MapReduce 来执行,而且需要 Hadoop 集群的每台机器都能访问业务数据库;应对此场景,淘宝开源的 DataX ,是一个很好的解决方案有资源的话,可以基于 DataX 之上做二次开发,就能非常好的解决。 当然, Flume 通过配置与开发,也可以实时的从数据库中同步数据到 HDFS 。 来自于 Ftp/Http 的数据源: 有可能一些合作伙伴提供的数据,需要通过 Ftp/Http 等定时获取, DataX 也可以满足该需求; 其他数据源: 比如一些手工录入的数据,只需要提供一个接口或小程序,即可完成; 数据存储于分析 毋庸置疑, HDFS 是大数据环境下数据仓库 / 数据平台最完美的数据存储解决方案。 离线数据分析与计算,也就是对实时性要求不高的部分,在我看来, Hive 还是首当其冲的选择,丰富的数据类型、内置函数;压缩比非常高的 ORC 文件存储格式;非常方便的 SQL 支持,使得 Hive 在基于结构化数据上的统计分析远远比 MapReduce 要高效的多,一句 SQL 可以完成的需求,开发 MR 可能需要上百行代码; 当然,使用 Hadoop 框架自然而然也提供了 MapReduce 接口,如果真的很乐意开发 Java ,或者对 SQL 不熟,那么也可以使用 MapReduce 来做分析与计算; 数据共享 这里的数据共享,其实指的是前面数据分析与计算后的结果存放的地方,其实就是关系型数据库和 NOSQL 数据库; 前面使用 Hive 、 MR 、 Spark 、 SparkSQL 分析和计算的结果,还是在 HDFS 上,但大多业务和应用不可能直接从 HDFS 上获取数据,那么就需要一个数据共享的地方,使得各业务和产品能方便的获取数据; 和数据采集层到 HDFS 刚好相反,这里需要一个从 HDFS 将数据同步至其他目标数据源的工具,同样, Sqoop,DataX 也可以满足。 另外,一些实时计算的结果数据可能由实时计算模块直接写入数据共享。 数据应用 业务产品 业务产品所使用的数据,已经存在于数据共享层,他们直接从数据共享层访问即可; 报表 同业务产品,报表所使用的数据,一般也是已经统计汇总好的,存放于数据共享层; 即席查询 即席查询的用户有很多,有可能是数据开发人员、网站和产品运营人员、数据分析人员、甚至是部门老大,他们都有即席查询数据的需求; 这种即席查询通常是现有的报表和数据共享层的数据并不能满足他们的需求,需要从数据存储层直接查询。 即席查询一般是通过 SQL 完成,最大的难度在于响应速度上,使用 Hive 有点慢,目前解决方案是 SparkSQL, Impala ,它的响应速度较 Hive 快很多,而且能很好的与 Hive 兼容。 OLAP 目前,很多的 OLAP 工具不能很好的支持从 HDFS 上直接获取数据,都是通过将需要的数据同步到关系型数据库中做 OLAP ,但如果数据量巨大的话,关系型数据库显然不行; 这时候,需要做相应的开发,从 HDFS 或者 HBase 中获取数据,完成 OLAP 的功能; 比如:根据用户在界面上选择的不定的维度和指标,通过开发接口,从 HBase 中获取数据来展示。 其它数据接口 这种接口有通用的,有定制的。比如:一个从 Redis 中获取用户属性的接口是通用的,所有的业务都可以调用这个接口来获取用户属性。 实时计算 现在业务对数据仓库实时性的需求越来越多,比如:实时的了解网站的整体流量;实时的获取一个广告的曝光和点击;在海量数据下,依靠传统数据库和传统实现方法基本完成不了,需要的是一种分布式的、高吞吐量的、延时低的、高可靠的实时计算框架; Storm, JStorm ,Spark Streaming 等实时框架已经非常成熟了。 常见思路由 scribe 、 chukwa 、 kafka 、 flume 等开源框架在前端日志服务器上收集网站日志和广告日志,实时的发送给 Storm, JStorm ,Spark Streaming ,由实时计算框架完成统计,将数据存储至 Redis ,业务通过访问 Redis 实时获取。 任务调度与监控 在数据仓库 / 数据平台中,有各种各样非常多的程序和任务,比如:数据采集任务、数据同步任务、数据分析任务等; 这些任务除了定时调度,还存在非常复杂的任务依赖关系,比如:数据分析任务必须等相应的数据采集任务完成后才能开始;数据同步任务需要等数据分析任务完成后才能开始; 这就需要一个非常完善的任务调度与监控系统,它作为数据仓库 / 数据平台的中枢,负责调度和监控所有任务的分配与运行。 元数据管理 技术元数据与业务数据,开发元数据系统。
来源:OSCHINA
发布时间:2020-05-17 02:15:00
DragonBonesPro制作补间动画、龙骨动画 一、开场动画 二、小丑盒子 三、跑步的人 四、跳跳羊 一、开场动画 效果 : 1.导入素材 2.将素材拖入到舞台并调整位置 3.调整图层位置 4.设置关键帧,创建补间动画 二、小丑盒子 效果 : 1.导入素材 2.将素材拖入到舞台,调整层级 3.创建骨骼 4.创建补间动画 三、跑步的人 效果 : 1.导入.json文件 2.创建手臂和腿的骨骼,层级 3.创建头部和身体的骨骼,层级(lowerbody- upperbody-head) 4.整体骨骼绑定效果 5.添加动作(run) 同理创建其他状态的动作(jump,idle,alert) 四、跳跳羊 效果 : 1.导入.json文件到舞台 2.给跳跳羊创建骨骼,层级如下图 3.选择网格模式,对跳跳羊创建网格 添加边线 添加顶点 4.制作补间动画
来源:OSCHINA
发布时间:2020-05-16 11:26:00
开发工具:DragonBonesPro 1.开场动画 2.小丑盒子 3.跑步的人 4.跳跳羊 一.开场动画 1.导入素材 2.将素材拖入舞台内,并调整位置以及图层 3.设置关键帧,创建补间动画 4.运行结果 二.小丑盒子动画 1.导入素材 2.将素材拖入舞台,并调整层级 3.创建骨骼,并调整场景树 4.设置关键帧,创建补间动画 5.运行结果 三.跑步的人 1.导入.json文件 2.创建手臂和腿的骨骼 3、创建头部和身体的骨骼 4.整体骨骼绑定效果和所有场景树 5.制作补间动画 最低位姿态第0帧: 最高位姿态第2帧: 第二个最低位姿态第4帧: 把第0帧的所有关键帧复制到第8帧完成剩下半步。 6.同理创建其他动作: 7.运行结果 四.跳跳羊 1.导入json素材 2.给跳跳羊创建骨骼,场景树和层级如下 3.选择网格模式,对跳跳羊创建网格,添加边线和顶点 4.添加关键帧,创建补间动画 5.运行结果
来源:OSCHINA
发布时间:2020-05-16 10:46:00
用DragonBonesPro制作补间动画、龙骨动画 动画补间 导入素材 整理素材位置并安排时间轴 调整关系以及创建补间动画 小丑惊吓盒 导入素材以及调整关系 创建骨骼以及创造补间动画 跑步精灵 导入数据到项目 创建骨骼 手脚部以及头和身体 建立整体从属关系 跑步动画补间 跳跃 跳跳山羊 导入素材 创建山羊骨骼以及网格 创建补间动画
来源:OSCHINA
发布时间:2020-05-15 20:18:00