原文:
annas-archive.org/md5/6b2697194400cac9f70f257dcd39ad77
译者:飞龙
第六章:构建大数据应用程序
在本章中,我们将学习构建大数据应用程序,分析传统端到端数据工作流生命周期,并按类似的线路逐步构建大数据应用程序。我们将涵盖大数据流程–发现、摄入、可视化和治理。重点将放在 Spark 平台和数据科学预测模型上。随后章节将探讨 DevOps 应用于大数据各个阶段。
-
传统数据平台
-
大数据平台核心原则
-
大数据生命周期:
-
数据发现
-
数据质量
-
数据摄入
-
数据分析
-
Spark 平台
-
数据可视化
-
数据治理
-
-
构建企业应用程序
-
数据科学–预测模型
传统企业架构
传统上,企业数据仓库(EDW)系统被视为商业智能环境的核心组件。数据仓库系统是通过集成来自多个不同源系统的数据构建的中央存储库,用于满足企业的数据分析和报告需求。
让我们回顾传统系统端到端数据生命周期组件:
-
数据发现阶段是探索和分析源系统中相关数据和数据结构的阶段。如果分析的数据有效、正确且可用,则将其摄入数据仓库系统。例如,如果我们需要客户 ID 信息,则应连接并从正确的列和表中提取数据。
-
数据质量确保摄入的数据是可接受和可用的。一个简单的例子是名字格式的第一个名和姓氏惯例,应该遵守,并根据需要为一些记录进行纠正。
-
数据转换是根据业务逻辑应用数据操作规则的阶段。例如,每个员工的年薪从多个系统计算并保存在系统中。
-
提取、转换和加载(ETL)是所有前述阶段(数据发现、数据质量和数据转换)的集合参考常用术语。
-
数据暂存是您系统中从源系统收集数据的着陆区域。
-
数据血缘追溯数据摄入到系统中的来源和可信度,以确保只有真实、可信和授权的数据被引入系统。
-
元数据是关于数据的数据。例如,销售收据是记录的起源,包含交易详情,从中提取我们计算所需数据的位置。从销售收据中提取商店 ID、销售金额、商品 ID、交易日期等详细信息。
-
数据仓库是存储层,将转换后的数据加载为汇总副本。它具有时间变体、一致性和读取密集性。
-
数据集市是专门用于某一类别的数据服务仓库,如客户数据、产品数据、员工数据等。
-
数据分析是指为满足所有业务需求而进行的分析。其构建的查询解决业务需求,例如上个月新增了多少客户,或者本周哪些产品的销售超过了目标。
-
语义层——其业务接口使用商业智能工具在数据库上构建查询,隐藏复杂的数据表格,使业务用户无需接触。
-
报告——报告是供业务使用的,例如展示上个月在某州销售的所有产品。
-
仪表盘提供重要关键绩效指标的快速整合视图。一个类比是汽车仪表盘,显示速度、电池、电量剩余等信息。
-
数据可视化——仅仅根据 Excel 报告找到关键的业务表现趋势可能是一项艰巨的任务。将其以可视化形式呈现非常具有吸引力,例如将其表示为图表、直方图和饼图。
构建大数据企业应用的原则
大数据平台和应用程序管理、集成、分析和保护对多种数据类型的分析,不仅涵盖企业内部数据,还包括外部数据。它们实时集成多个数据源,考虑到数据的体积、速度和种类。该平台可以构建为企业知识库的存储库,存储组织的集体数据资产。
一些构建这些平台的显著特点已经讨论过,正如我们所见,DevOps 非常适合,并且是增强每个阶段价值的工具,比如用于构建算法、数据模型的版本控制系统,使用虚拟机构建可扩展的可复现平台,正如前一章所见:
-
灵活的数据建模:大数据系统集成了来自多个数据源的多种不同形式的数据。与其采用预定义的固定行列结构,数据架构应动态定义,并且数据建模需反映如何同化信息。为了反映现实世界中的实体,它也可以灵活地指定为具有关系的对象图。
-
知识管理:带有版本控制的知识库,包含组织积累的洞察力,可以作为企业资产加以利用。
-
隐私和安全控制:该平台设计用于数据血缘、多级安全和审计合规。平台中集成的每个对象都可以追溯到其原始数据源,并且设置了访问限制,包括授权和认证。
-
数据处理算法:这些是大量的数据集,需要使用内置的机器学习算法进行编译和分析,以增强人工用户通过识别数据模式理解大规模数据的能力。
-
可扩展平台:这些平台通过可扩展的架构与联合数据存储相结合,处理 PB 级别的数据,以存储大量非结构化数据,如文档、电子邮件、音频、视频、图像等。这些平台被设计为开放平台,可以在堆栈的每一层进行扩展。需要考虑高效的数据发现、数据血缘关系和弹性搜索工具的提供。
-
协作:该平台使多个用户能够在组织内外无缝、安全地协作,实时分析相同的数据,从低级数据集成、导入管道定制到构建自定义用户界面。已集成的数据可以通过 API 作为对象访问,或导出供其他框架和工具使用。
-
在模型上构建模型:简单的模型可以作为更复杂模型的构建模块,构建精细的分析并将其流线化为模块化过程。可以使用内置的丰富可重用统计和数学操作库来构建模型。
-
数据可视化:这是一个互动用户界面,提供一个无缝的整体视图,展示所有集成数据的丰富可视化形式,如表格、散点图和图表。这些可视化图表实时与源数据保持同步,使得用户始终能够在任何给定时刻查看最准确和最新的信息。
大数据系统生命周期
大数据系统是根据数据生命周期模型构建的,通常可以分为以下几个阶段:
-
数据发现
-
数据质量
-
将数据导入系统
-
将数据持久化存储
-
对数据进行分析
-
数据治理
-
可视化结果
我们将在接下来详细学习它们。
数据导入系统
数据发现,像传统过程一样,从多个源系统中摄取原始数据;然而,在将其转化为商业洞察时,数据的体积、种类和速度将会有所不同。通过利用大数据的力量,数据发现过程使得数据清洗和数据丰富成为可能,促进将数据集组合以重建新的视角和互动的可视化分析。一个互动的数据目录有助于引导搜索功能,帮助我们彻底分析和理解数据质量。成熟而强大的数据发现过程确保可能的数据关联,它让用户定义基于属性的规则、数据源之间的关系,协调数据源并基于数据集市创建丰富的数据。
为了拓展传统商业智能系统的边界,充分利用大数据的潜力是企业成功的关键。这有助于有效地解锁来自新信息源的洞察力。随着新型数字信息源的不断涌现,组织有潜力访问到丰富的知识,并能得当挖掘这些知识。
使用大数据工具和技术进行数据发现,有助于深入探索组织内外的数据,从而清晰地看到商业表现。企业可以探索新的维度,改变商业分析系统的构建和使用方式,使其更高效。通过结合各种数据源,数据发现允许快速、直观地探索和分析信息;它为业务提供了更深层次的洞察力,并带来了更高效率的机会。它建立了重新定义商业与 IT 之间角色的新关系,同时增设了新的角色、新的领导力,并对数据治理的方式进行了修订。
许多组织已经更新了商业智能决策系统,以基于现有数据和系统来提升商业表现,帮助理解和监控数据。如今,绝大多数数据增长来源于传统商业智能环境无法触及的系统,例如网站、社交媒体、内容管理系统、电子邮件、文档、传感器数据、外部数据库等。因此,需要采用新时代的数据发现工具,同时也要考虑到这些多样化和变化的数据正在呈指数级增长。在发现阶段需要处理的数据类型多种多样,从结构化的数据库表格,到包含数字和自由格式文本的半结构化形式,再到完全非结构化的文档。
数据量和种类的多样性,以及其不确定的价值,是最大的挑战之一。互联网文化的普及和消费者与企业商业软件的互动,特别是通过移动和网页应用程序,催生了迅速探索相关信息的迫切需求,以发现新的业务洞察力并做出决策。
数据化是将所有类型来源、所有类型格式的数据量化的过程。数据化使得信息能够被收集、整理和分析,从而使信息的潜在用途仅受技能熟练的商业用户的创造力限制。数据的真正价值就像浮在海洋中的冰山。最初,只有一小部分是可见的,而大部分则隐藏在水面下。那些理解这一点的创新公司能够提取隐藏的价值,获得潜在的巨大收益。
企业级数据发现系统能够快速、直观地探索和分析来自多种结构化和非结构化来源的数据。它们使组织能够利用现有投资,将商业分析能力扩展到新的、多样化的来源组合,包括社交媒体、网站、内容系统、电子邮件和数据库文本,为数据和业务流程提供新的可见性,节省时间和成本,并帮助做出更好的商业决策。此方法的一些优势包括:
-
通过为用户提供更深入的见解和可见性,帮助他们找到自己想要分析的数据,从而深入了解业务。
-
通过访问更新的信息,可以实现近实时的数据和内容传递,帮助人们根据最当前的信息做出决策。
-
增加资产的重用。你可以重用信息资产,并消除重新创建这些资产的成本。
-
为 BI 专业人员提供开发和交付适合商业专业人员使用的分析型消费级应用的便利,进而提高采用率、降低培训成本并加快价值实现的速度。
数据发现阶段
数据发现过程涉及原型设计、可视化、桥接、复制和转化等阶段。将这些概念在数据发现的背景下并行应用,可以从大数据中获得价值:
- 原型设计:通常,在任何商业环境中,项目总是面临压力,并受限于时间和预算等资源。在复杂项目中,原型设计是当面临紧迫、苛刻、看似困难且时间有限的挑战时,推动进展的有效方式。原型设计是在没有找到答案之前采取行动,在没有经过验证的公式或已知解决问题的方法的情况下冒险。原型设计让我们能够测试假设并探索替代方法,通过构建小模块来获取整体视图。DevOps 加快了原型设计过程,使其成为一个持续的开发循环。
数据发现让人们能够在数据中自由探索,尝试新的数据源组合、筛选和精炼分析,发现先前隐藏的模式,或者如果第一次尝试没有得到有价值的见解,可以跳转到另一个实验线程。一个关键的挑战是如何实时同步源系统的数据模式变更与暂存和开发系统;可以采用 DevOps 方法和流程来解决这一问题。
通过数据发现的实验包括三个主要任务——提出新问题、观察新模式和添加新数据。这些步骤构成了一个连续的过程,是迭代的,并且会根据用户在任何给定时刻所看到或假设的内容流动到任何方向。与数据发现阶段集成的 DevOps,使得这一过程从源系统识别到数据摄取,再到暂存系统的过程自动化。
-
可视化:数据可视化帮助数据分析师快速反馈他们的假设,因为图形化更便于在定量信息中发现模式。实时查看经验性业务分析的结果,使数据分析师能够确定哪些细化或进一步的搜索可能导致对绩效差距或市场机会的更深理解。通过快速可视化分析结果来增强有效的数据发现,帮助经验丰富的数据分析师以及非技术性的业务用户。数据可视化技术,如拖放式仪表板、快速生成的图表、易用的向导以及类似消费者风格的导航,加速了对数据模式及其行为特征的理解。
-
桥接:通过数据发现过程,业务与 IT 之间可以建立更加高效的合作关系。在传统环境中,业务和 IT 分别扮演提供者和用户的角色,进行数据发现阶段的独立活动。这使得他们可以作为一个团队合作,汇聚力量共同探索和学习。IT 分析师帮助业务合作伙伴,向他们展示如何添加数据源、完善搜索,并探索新的问题,逐步了解软件的功能。他们还可以直接与业务方合作,如何实时构建发现应用程序,并如何在分析可能性时变得自给自足。传统的提取需求、编写复杂规范,以及经过漫长的开发和部署过程,通常在时间和精力上都非常繁琐。IT 通过绕过大部分 SDLC 流程并赋能业务用户自助服务数据,从而大大提高了效率。
-
系统化:随着数据探索与深度洞察技能的不断提升,在某些情况下,某一条调查路径可能会重复几次。这也可能带来超越单次情景的宝贵见解,更有效地抓住业务问题的一部分,并不断重复和追踪结果。一旦通过用于描述关键业务流程的度量标准和维度将业务查询和响应建立起来,就可以考虑将分析和度量整合到组织的企业 BI 系统中。商业智能平台通过让用户对标准数据集执行标准化查询来回答已知问题,从而表现出色。
数据发现与商业智能系统互为补充,数据发现擅长解决未知问题,而 BI 则专注于系统化分析,如下图所示:
DevOps 将标准化数据模型、仪表板和可视化报告的维护过程,并将其自动化测试和部署,从开发系统到 QA 和生产环境,形成持续集成和部署模型。
- 转型:数据发现过程能够帮助探索无限多的新途径,解决业务问题并发现之前隐藏在数据中的新机会。通过实验过程揭示这些新维度,能够发现有价值的新洞察,为转型铺平道路。然而,对于标准已知领域,企业仍将继续使用现有的 BI 系统,并利用数据发现探索为新问题和问题提供洞察的方法。因此,数据发现通过易于探索多样数据的方式,展现了其价值,帮助揭示推动收入和生产力显著增长的洞察,同时改善了业务与 IT 的对齐和关系。它推动了商业分析世界的转型。
大数据发现领域有多种工具,如 Apache PIG、Oracle Big Data Discovery、Zoomdata、Exasol、Revolution、GridGain 等。
传统的商业智能(BI)工具,如 Tableau、QlikView、Microstrategy、Informatica 等,也在为大数据提供广泛的数据发现功能。
数据质量
其中一个最大的挑战是确保数据质量和准确性,这说起来容易做起来难。DevOps 将增强数据质量过程,确保从脚本到整个验证过程的自动化循环。我们来看看一些挑战:
-
数据多样性:来自移动设备、Web 技术、传感器数据、社交媒体等各种数据源的数据,带来了多种复杂的数据类型和数据结构,增加了数据集成的难度。这些数据源生成了例如文档、视频、音频等形式的非结构化数据,以及软件包、模块、电子表格、财务报告等形式的半结构化数据和结构化数据。所获得的有价值洞察依赖于收集、存储和验证的数据。由于这些数据来自如此多的不同来源,且依赖于集成过程的有效性,因此至关重要。在处理生命科学等数据密集型且敏感的行业时,这一过程必须是万无一失的。
-
数据复杂性:数据变得复杂,涉及多个属性,例如来自不同来源的原始数据,这些来源包括消费者、销售人员、运营部门以及组织内的其他来源。数据的时效性至关重要;你需要实时收集所需数据,或实时处理数据需求,否则数据可能会变得陈旧、过时和无效。基于这些数据的处理分析将产生无用或误导性的信息和结论,从而误导决策系统。
-
确保数据安全:有许多技术有助于通过移动、网络和 ERP 等应用程序跨多个渠道进行通信,这增加了维持数据安全的复杂性。云、大数据和移动等新兴技术正迅速扩展其应用范围并变得越来越流行。然而,数据安全的需求和挑战比以往更加复杂。
确保数据质量的一般指南如下:
-
数据可用性:大数据系统所需的数据应根据预期用途适当提供。数据应是及时的,可以通过实时流式传输或批处理模式获取。数据应通过可用的 API 接口进行访问,并且数据应被授权用于使用。
-
数据适当性:数据应具有可信度,否则目标将无法实现。数据溯源过程追溯数据的来源。数据定义应适当,并且在数据的新鲜度和定期更新方面应是可以接受的。数据文档和元数据应在可接受的值范围内经过审计以确保其正确性。
-
数据准确性:数据应可靠;数据值应真实反映源信息的状态,数据不应含糊不清,应是事实的单一版本。数据应在预定时间内保持一致并可验证。数据应完整并且可审计。
-
数据完整性:数据格式应清晰,并符合一致性的结构和内容标准。数据的完整性应保持完好。数据应相关并符合所需的用途,且在各方面完整,适合用于其预定目的。
-
呈现质量:数据的内容和格式应清晰易懂。数据描述、分类和编码内容应易于理解,并符合既定目标和规范。
有许多开源大数据工具提供多种数据质量特性,例如 Talend、AB Initio、Data Manager、Datamartist 和 iManage Data。
在数据摄取过程中,原始数据来自多个数据源并被加入系统。根据源系统的数据格式和质量,以及目标数据处理状态的需求,这一过程可能会非常复杂。数据摄取到大数据系统的方式多种多样,具体取决于摄取的数据类型。为了准备原始数据供系统使用,通常在摄取过程中需要进行某些程度的分析、排序和标记。从传统的遗留数据仓库过程扩展出来的,包含提取、转换和加载(ETL 过程)。一些相同的概念也适用于进入大数据系统的数据。
数据摄取过程涉及对输入数据进行格式化、分类和标记的处理。数据结构应遵循预定义标准,通过剔除不需要的数据来确保符合要求。因此,从多个源系统捕获的大量数据将用于进一步处理。它以原始格式存储在数据湖中。
批处理
批处理作业,顾名思义,是那些数据集作业,这些作业对时间不敏感,并且在大型数据集中以批量方式处理。批处理作业的处理可以以多种模式进行,下面将描述这些模式。
从 RDBMS 到 NoSQL
存储在关系型数据库(RDBMS)中的大部分遗留数据可以使用 Sqoop 导入到 HDFS 上的 NoSQL 数据库中,DevOps 可以为 Sqoop 脚本的基准提供支持,自动化数据导入和导出的过程,存储和计算系统的可扩展性,数据完整性的测试自动化,以及自动部署。数据迁移过程如下所述:
-
Sqoop 是一个命令行界面应用程序,用于在关系型数据库和 Hadoop 之间传输数据。它支持增量加载单个表或自由格式的 SQL 查询,以及可以多次运行的保存作业,以导入自上次导入以来对数据库所做的更新。导入还可以用于填充 Hive 或 HBase 中的表。
-
Oozie 可以用于调度和创建数据导入/导出的流程。
-
在 Sqoop/Oozie 中可以配置全量和增量导入。
-
我们可以直接导入并创建 Hive 表,但如果构建分层架构,建议将数据导入到暂存区。
-
例如–
sqoop import -connect jdbc:mysql://:/ -username -password --table --target-dir
。
Flume
对于其他批处理数据源,我们可以部署 Flume。它会监控新的源文件并将数据推送到 HDFS。
-
Flume 在将大量日志数据传输到分布式系统、收集并根据业务需求汇总数据方面非常有效和可靠。
-
架构简单且灵活,能够满足传入流数据流的需求。
-
Flume 具有强大的容错性和可定制性,拥有高级功能,如故障转移和恢复机制等。
-
一个简单且可扩展的数据模型支持在线分析应用程序
流处理
流处理,顾名思义,是对实时数据的计算,这些数据通常具有时效性,且通常带有高速度的度量。分析通常在流数据被摄取时进行,以便进行质量检查等。
实时
如果数据以流的形式存在,例如应用日志、程序输出(如网页抓取器)、传感器、地理位置或社交媒体,这些可以通过 Kafka 实时收集。
-
Kafka 是一个开源消息代理项目,旨在提供一个统一的、高吞吐量、低延迟的平台,用于处理实时数据流。它本质上是一个大规模可扩展的发布/订阅消息队列,构建为分布式事务日志,使其在企业基础设施中处理流数据时具有极高的价值。
-
Kafka 可以轻松扩展,以支持更多的数据源和不断增长的数据量。
-
Kafka 还支持与 Spark 的直接连接。
-
每个输入数据源对应一个主题,每个消费者组对应一个主题。
-
每个主题的分区数量将取决于数据的大小。
除了 Sqoop 和 Kafka,还有一些其他专门的数据摄取工具,用于导入和聚合服务器及应用日志,这些工具包括 Apache Flume 和 Apache Chukwa。Gobblin也提供了一个数据摄取框架,用于聚合和规范化数据。
Lambda 架构
当批处理和流数据同时导入系统时,Lambda 架构非常有效,如下图所示:
数据存储层
持久化大数据有多种存储选项,例如数据湖和数据仓库;云技术对数据存储的支持大大增强了大数据存储系统的需求,这些系统能够通过简单的存储设备和虚拟机扩展至 TB 和 PB 级别。本书详细讨论了 DevOps 作为管理可扩展数据存储的有效解决方案,使用基础设施即代码。
-
数据湖:数据湖与水湖同义,水湖储存水并供许多人使用。数据湖是原始数据的存储库。收集到的数据可能是非结构化的,并且经常变化,因此,最初这些数据会被集中存储在大存储库中,以便用户根据其预定需求进行使用。
-
数据仓库:数据仓库是一个有序的数据存储库,用于存储大量数据以供分析和报告使用。数据仓库中的数据通常是经过清洗的、组织良好的,并且与其他数据源进行了集成。它在传统系统中通常更为显著。
摄取过程确保进入的数据根据业务需求被处理,并可靠地持久化到存储磁盘。摄取过程可能很复杂,取决于来自源系统的数据的量和多样性。分布式存储系统的可用性通过 Apache Hadoop 的 HDFS 文件系统实现。通过 HDFS,大量原始数据可以同时写入多个节点,并具备冗余性。
Ceph 和 GlusterFS 是提供所有这些功能的其他文件系统。
分布式数据库,如 NoSQL,适合导入数据以便进行更结构化的访问。它们具备容错功能,并能够摄取异构数据格式。根据组织的业务需求,可以从多种可用选择中选择适当的数据库。
数据存储 - 为了更好的组织和效率的最佳实践
着陆
着陆区是初始数据从不同源系统以原始状态进入存储系统的地方。
-
着陆区是存储进入数据的地方
-
所有的输入验证应该在此进行
-
文件夹结构可以是
<source>/<type of data>/<yyyymmddhhisss>
-
应该同时应用归档机制(按天/周/月)
-
访问应仅限于处理用户,而非最终用户
原始
一旦数据进入着陆区,就会进行适当性、格式和质量的完整性检查;在符合要求的情况下,它会以原始数据的形式存储。
-
这是存储原始数据的地方,数据保持其原始格式
-
来自着陆层的经过验证的输入数据存储在这里
-
目录结构由摄取框架管理
-
只有选定的超级用户和系统用户能够访问这些数据
-
应应用 Snappy/LZO 压缩
-
应该应用数据分类器(热数据、冷数据),并设置归档策略
-
文件夹结构可以是
<base dir>/<system type>/<dataset Source Name>/<Source Type>
工作
工作区存储已识别的清洁数据,用于业务目的
-
这是临时工作区,清理应该在相关任务完成后进行,除非任务需要数据用于调试
-
Spark 流式处理的检查点位置也会位于这里
黄金
黄金数据是经过转换、分区,并分类为主数据的有价值数据。
-
这是存储转换后数据的位置
-
在这一层,分区是非常重要的,应该根据最常访问的列来进行分区
-
应对非常热、热、冷和非常冷的数据进行分类
-
非常冷的数据应该归档到 Blob 存储(或任何其他便宜的存储)
-
文件夹结构可以是
<base dir>/<system type>/<dataset Source Name>/<Source Type>/<Job ID>
隔离
这是保存不需要的、过时的数据的地方,这些数据当前没有活跃的即时用途。
-
来自不同步骤的所有被拒绝的文件将存储在这里,如摄取、转换以及验证异常记录
-
应对非常热、热、冷和非常冷的数据进行分类
- 非常冷的数据应该归档到 blob 存储(或任何其他廉价存储)
业务
业务数据是客户特定详情的主数据,如地址、产品偏好等。
-
这一层将包含应用程序/客户端特定的数据
-
所有数据必须以 parquet 格式存储,因为此阶段的所有数据将是结构化的
输出
输出数据是将要与外部实体共享的数据,例如供应商、卖方或第三方 API。
-
这是可以与外部应用程序共享数据的位置
-
文件在复制后需要被归档
-
客户端可以拥有临时或永久访问权限
一个良好的易用备份和灾难恢复解决方案提供了 Hadoop 集群之间的集成数据同步。它通过复制存储在 HDFS 平台中的数据并跨数据中心进行同步,从而实现数据保护。
计算和分析数据
从前面的过程生成的数据可以被分析,以发掘实际的信息价值。计算层执行各种功能,其中数据通常通过组合工具进行迭代处理。为了满足不同的业务需求,提取的各种洞察力通过量身定制的做法得以实现,而这些做法因组织而异。
批处理是对大数据集进行计算的一种方法,其中数据以批处理模式进行摄取,可以是每日或每小时。Apache Hadoop 的 MapReduce 是最突出和强大的批处理引擎,它被称为分布式 MapReduce 算法;它采用以下策略,在处理需要大量计算的非常大数据集时最为有效:
-
拆分:在这个过程中,工作被划分为更小的部分
-
映射:这是将每个数据块调度到单独机器上的过程
-
洗牌:基于中间结果重新洗牌数据
-
减少:处理每组输出数据
-
组装:最终结果被组合在一起
MapReduce 框架形成了计算节点,而 HDFS 文件系统则形成了数据节点。通常,在 Hadoop 生态系统架构中,数据节点和计算节点执行相似的角色。MapReduce 组件的委托任务由两个守护进程执行,Job Tracker 和 Task Tracker,它们的活动如下图所示:
接下来讨论的是批处理、实时处理和流处理中的数据处理。DevOps 是大数据系统中不可或缺的一部分,涉及从源系统发现到基础设施的可扩展性,以支持存储需求的高容量数据处理。
-
批处理:在处理大量数据时非常高效。数据被导入系统、处理,然后以批次形式生成结果。系统的计算能力是根据处理的数据大小设计的。系统配置为无需人工干预即可自动运行。该系统可以快速扩展,以适应大量数据文件的计算分析。根据处理的数据量和定义的系统计算能力,输出时间线可能会有显著变化。
-
实时/流处理:虽然批处理适用于某些类型的数据和计算,但其他工作负载则需要更低延迟的响应。有一些实时系统需要在处理信息时做出实时响应,并在持续吸收新信息的同时,使分析或可视化结果迅速呈现给业务方。这些系统称为流处理系统,它们基于连续的数据流进行工作,这些数据流由独立的数据项组成。实时处理系统或流处理系统,利用内存引擎的实时处理能力;计算分析是在集群的内存中执行的,从而避免像传统的基于磁盘的持久系统那样必须写回磁盘。实时处理最适用于分析较小的数据块,这些数据正在快速变化或被添加到系统中。
有许多平台和工具可以实现实时处理,如 Apache Storm、Apache Flink 和 Apache Spark。每个平台都设计为实现实时或接近实时处理的不同方式。除了这些列出的计算框架外,还有许多其他手段可以在大数据生态系统中分析数据或执行计算。这些工具常常与前述框架集成,并提供额外的接口与底层层次进行交互。我们在前一章已经讨论了它们在不同场景中的适用性以及每个问题的最佳应用,但我们将在此再次回顾一些工具:
-
Apache Hive 提供了 Hadoop 的数据仓库接口
-
Apache Pig 提供了一个高级查询接口
-
Apache Drill、Apache Impala、Apache Spark SQL、Presto 等,提供类似 SQL 的数据交互
-
R 和 Python 是常见的简单分析编程语言选择
-
Apache SystemML、Apache Mahout 和 Apache Spark 的 MLlib 提供机器学习库的预测模型构建功能
Apache Spark 分析平台
Apache Spark 是一个下一代内存中开源平台,集成了批处理、流处理和交互式分析。Spark 提供了易于使用的功能,能够快速编写应用程序,并具有内置的操作符和 API,此外还提供更快的性能和实现。
Spark 提供了一个更快、更通用的数据处理平台,内存中运行的程序比 Hadoop 快最多 100 倍,磁盘上运行的程序比 Hadoop 快最多 10 倍,具备极速的集群计算能力。Spark 框架建立在 Hadoop 集群之上,用于处理来自结构化系统(如 Hive)的数据,并从 Flume 和 Kafka 流式传输数据。它具有许多先进功能,并支持多种编程语言,包括 Java、Python 和 Scala。它拥有广泛的分析功能、开箱即用的算法、机器学习、交互式查询和复杂功能分析。
Spark 的流行度源于其许多优点,包括:
-
Spark 是 Hadoop 生态系统的一个子集。它与生态系统中的可靠且安全的存储平台 HDFS 良好集成,且与其他数据源兼容,如 Amazon S3、Hive、HBase 和 Cassandra。它可以在 Hadoop YARN 或 Apache Mesos 管理的集群上运行,也可以作为独立模式运行。
-
Spark 是一项用于大规模数据处理的快速技术。该框架提供基于 Java、Scala 和 Python 的高级 API,并为流处理和机器学习提供丰富的数据存储。虽然主要 API 是为 Scala、Java 和 Python 设计的,但也支持 R 等语言。
-
Spark 确保数据的并行处理,并与 Hadoop/HDFS 进行良好的集成以进行数据存储,同时支持多种文件系统和数据库。
-
Spark 的机器学习能力被证明是流处理的优秀解决方案。通过 Spark REPL,编写代码更容易、更快捷,内置了高级(80 个)操作符。Spark 的读取评估打印循环(REPL)是交互式的(开箱即用)Shell,是 Scala 交互式 REPL 的修改版。使用 REPL 时,无需编译和执行代码。用户的表达式会被评估,并且 REPL 将显示该表达式的结果。读取将表达式作为输入,解析并以内部数据结构存储在内存中。评估遍历数据结构,评估调用的函数。打印显示结果,并具有打印功能。循环迭代返回读取状态,在退出时终止循环。REPL 加快了周转时间,并支持临时数据查询分析。
-
Spark 更加灵活,特别适合大数据分析。其基于自身流处理 API 的持续微批处理和集成的先进分析功能对开发者友好。
-
与 MapReduce 相比,Spark 的效率更高。对于相同的处理过程,它比 MapReduce 快 100 倍。
-
Hadoop 的流行批处理作业引擎 MapReduce,由于其批处理模式响应的高延迟,面临着巨大的挑战,且由于其架构设计和代码的固有低效性,维护起来非常困难。Spark 的主要组件是 Spark Core Engine,它还配有一套强大的、更高级的库,这些库可以无缝地在同一应用程序中使用:
-
Spark SQL 是一个强大的查询语言,内置 DataFrames。
-
Spark Streaming 引擎用于数据流处理
-
Spark MLlib 用于机器学习以及机器学习管道模型
-
GraphX 与 GraphFrames 将实体之间的关系存储为图形表示。
-
Spark 核心引擎
Spark 核心引擎是 Spark 进行大规模并行和分布式数据处理的基础引擎。它执行以下功能:
-
容错和基于恢复的内存管理
-
集群作业调度、分发和监控
-
存储设备系统接口
Spark 是基于不可变的、容错的、分布式的对象集合构建的,称为弹性分布式数据集(RDD),可以并行操作。对象通过加载外部数据集或从内部驱动程序分发来创建。通过 RDD 执行的操作是转换。
转换操作包括 map、filter、join 和 union,执行在 RDD 上并产生新的结果。
动作操作包括 reduce、count、first,它们在对 RDD 进行计算后返回一个值。
Spark 引擎设计高效。转换操作实际上是在调用动作时计算,并将结果返回给驱动程序。转换是惰性操作,不会立即计算结果;然而,它们会记住要执行的任务和数据集(例如文件),以执行操作。转换后的 RDD 可以为下一个转换重新计算。其优点是避免了不必要的变更和计算。所有这些都通过内存引擎实现,数据会在 RDD 对象上持久化并缓存。Spark 会将元素保存在集群缓存内存中,以便下次查询时能够更快地访问。
Spark SQL
Spark 组件 Spark SQL 支持通过 SQL 或 Hive 查询语言查询数据。Spark SQL 与 Spark 堆栈集成,提供对各种数据源的支持。它允许你将 SQL 查询与代码转换结合,使其成为一个非常强大的工具。
Spark Streaming
Spark Streaming 是一个强大的基于内存技术的功能。Spark Streaming API 与 Spark 核心引擎兼容。它支持批处理和流式数据处理,能够实时处理来自 Web 服务器日志文件、基于 Twitter 的社交媒体数据等系统的数据。Spark 还与其他工具(如 Kafka)接口,用于各种消息队列。
Spark Streaming 从上游系统接收输入数据,如 Apache Flume、Kafka 等,并将数据划分为批次,通过 Spark 引擎处理这些批次数据,并生成最终的结果流批次,将其存储在 HDFS/S3 等位置。
MLlib 是一组库函数,提供各种机器学习算法,如分类、回归、聚类和协同过滤。Apache Mahout(一个用于 Hadoop 的机器学习库)已经集成到 Spark MLlib 中。一些算法,如线性回归或 K-means 聚类,也支持流数据,并设计为在集群上扩展。
GraphX 提供了 ETL 功能、探索性分析和迭代图计算。它提供了一个用于操作图形和执行图并行操作的库,支持常见图算法,如PageRank。
Spark 非常适合简化复杂且计算密集型的任务,用于高容量实时数据处理,无论是流数据还是归档数据,结构化和非结构化数据都能轻松处理,同时无缝集成相关复杂功能,如机器学习和图算法。
一些挑战包括操作复杂性和开发管理应用所需的高技能水平。Spark 与 Hadoop 配合良好,能充分利用 Hadoop 的 HDFS。两个系统的性能调优至关重要,否则,Spark 的细微差别可能会导致内存溢出错误和内存滞后问题,特别是在作业未经过良好调优时。
大数据系统中的可视化
我们都熟知“垃圾进,垃圾出”这句话。识别和了解数据随着时间的变化、趋势、波动和变化通常比单纯的数据分析更为重要,而数据可视化则是不可避免的步骤。由于大数据系统处理的信息复杂性,数据可视化成为发现趋势并从大量数据点中提取有意义洞察的最重要和最有用的方法之一。
我们将在这里讨论一些实时处理工具:
-
Prometheus:用于实时处理应用和服务器指标,数据流作为时序数据库,进行可视化。系统的健康状况通过频繁的数据变化来衡量,指标的大幅波动通常表示重要的关键绩效指标(KPI)。
-
Elastic Stack:它在大数据系统可视化中非常流行,用于以视觉方式展示计算结果或原始指标。它也被称为 ELK Stack,由 Logstash(用于数据收集)、Elasticsearch(用于数据索引)和 Kibana(用于可视化)组成。
-
SILK:它是一个类似的堆栈,通过使用 Apache Solr 进行索引和一个名为 Banana 的 Kibana 分支来实现可视化。
-
Jupyter Notebook 和 Apache Zeppelin 提供了交互式数据探索和可视化的界面,数据呈现格式便于共享、展示或协作。这项技术通常用于交互式数据科学工作,并被称为数据 笔记本。
数据治理
数据治理是对企业数据进行分类,并为适当的角色和人员提供正确的访问权限和特权的过程。它指的是管理组织中数据资产的可用性、可用性、完整性和安全性的整体过程。成熟的数据治理模型是一套明确定义的策略,包含一个治理小组以及一个协调有序的计划来执行这些程序。
采用开源软件开发方法来进行平台/产品开发将带来许多优势,例如:
-
在组织内部跨不同技术团队的无缝协作
-
在组织内 leverage 和重用现有的软件和知识资产
-
它确保解决地区、客户和国家特定需求
这种软件开发方法有助于建立治理机制,以确保避免重复工作并按照统一的标准框架实现透明化。
数据治理应定义必要的最小规则,而不是成为负担。它还应在以下方面进行平衡:
-
规则与公众(人人可用)
-
人员与流程
-
授权与指引
开源治理基于三个支柱:
-
透明度
-
设置治理参数
-
更快地交付每个团队和每个成员的成果
实践透明度、鼓励积极参与并认可所有成员贡献的开源社区,更有可能繁荣、迭代并增强前景。开源社区开发模型中的治理原则可以通过描述以下图示中的七个支柱来更好地展示:
根据 DevOps 核心概念的人员与协作
技术由人驱动,因此技术的成功依赖于几个属性——它应该易于被人们采纳,应该具有灵活性,易于学习,并且便于协作。我们将在这里讨论这些:
-
确立过程示例代码、提交和审查过程的所有权
-
一个通用的仪表盘,用于查看任何组件的状态、已做更改、审查状态、测试、受影响的组件等
-
采用论坛讨论而非电子邮件、Yammer 小组等,来解决问题和解答疑问
-
定期(每周、每两周)全员部署会议,讨论组件变化和路线图
环境管理
信息技术中环境管理是一个复杂且至关重要的职能。
-
维护开发的并行环境,例如当前程序和其他生产修复
-
定义组件与数据库交互的访问限制
-
定义每个组件/程序的资源分配(磁盘空间、线程/映射器等)
文档
对正在进行的工作进行文档记录,对于项目的生命周期、功能升级以及作为操作手册的支持和维护都非常重要
-
核心组件、业务/装配线使用、治理等的全面文档。这对于跨团队合作、新成员的加入等非常重要
-
用于帮助每个团队成员的文档可以定期修订,添加更细化的细节:
-
主架构参考文档——按照 TOGAF 建议的格式创建,以便使用统一的语言交流
-
开发者指南
-
治理指南
-
部署指南
-
架构委员会
架构委员会负责企业的长期规划,并确保架构符合业务目标,例如面向服务的架构、使用符合安全指南的组件、开放源代码工具使用比例作为路线图等。
-
架构评审委员会 (ARB) 是定义和参与门控(或里程碑)规划的权威机构
-
定义每个程序高层设计的门控里程碑
-
预算每个程序的重构工作量,并在门控会议中批准
-
集中化设计审批决策
-
用于门控和评审的审查清单
开发和构建最佳实践
开发最佳实践包括采用编码标准、适当的文档、同行评审、代码质量等,以确保代码和性能的高质量。构建是一个复杂的任务,涉及许多接口。遵循适当的指南将使其根据组织需求更为健壮和高效。
-
自动化构建与自动化测试流程
-
基于示例的源代码同行评审
-
通用 IDE、代码审查工具(PMD、check style 等)、构建工具(Hudson 和 Maven)
-
标准化的构建推广程序和时间表
-
每周通过持续集成和测试发布环境稳定性
-
定义测试环境和回归套件以执行受影响的模块
版本控制
版本控制将确保代码变更得到良好的跟踪,便于可追溯性和问责
所有组织团队使用企业标准工具进行版本控制是理想状态。版本控制治理具有以下特点:
-
每次检查提交时,自动向受控的主管邮件列表发送电子邮件
-
定义每个程序组件的贡献者,并限制对组件的访问
-
定期审计检查提交,并获得组件所有者的批准
发布管理
一个成熟的发布管理过程是组织向客户及时交付高质量可靠产品的重要资产
-
集中化发布管理
-
跨程序和功能定义的共同优先级
-
使用微服务/增量部署——支持独立部署的架构
使用 Spark 构建企业应用程序
对于企业应用程序的成功来说,仔细定义数据访问、处理和治理框架是非常重要的。
客户端服务展示层
这个图形用户界面将由一组 API 支持,帮助新用户入驻。支持的功能如下:
-
管理客户端数据源、文件格式、交付频率、验证规则、联接条件(如果有多个数据集)等
-
验证和转换数据集
-
管理数据集访问权限
-
Eureka 的附加数据传输要求
数据目录服务
这个图形用户界面将由一组 API 支持,提供与数据相关的服务。支持的功能如下:
-
类似于 Google 搜索的方式,在数据湖中搜索任何数据集/数据
-
浏览(带分页的预览)搜索结果
-
显示所选数据集的血统和数据概况
工作流目录
这个图形用户界面将允许你为应用程序定义工作流并安排执行。主要功能包括:
-
为应用程序创建工作流并安排执行
-
显示工作流的执行状态、所用时间,以及涉及的的数据集和血统
-
在失败或从任何给定点恢复时,能够重新启动处理过程
-
配置状态更新、通知和警报
使用和跟踪
这个图形用户界面将用于 Sentry 和 Navigator,跟踪整个集群中数据集的使用情况。其主要功能包括
-
数据集的有效使用跟踪:数据集被访问了多少次,以及由谁访问
-
无效使用跟踪:谁尝试访问他们没有权限的数据集
-
处理跟踪,了解哪些用户在运行什么处理过程以及消耗了哪些资源
-
需要根据运营团队的要求定义仪表板
安全目录
这个图形用户界面将由 REST API 支持,用于配置用户组的访问控制。包括的功能如下:
-
管理用户和用户组
-
管理用户对集群中各种数据集和能够在数据湖中运行的应用程序的访问
处理框架
这里是所有数据转换和处理的发生地。处理可以是批量的,也可以是实时的,支持各种框架,如 Spark 和 MapReduce,以及查询引擎,如 Hive 和 Impala。
数据摄取服务
数据可以通过多种来源进行摄取,从批处理到实时流,使用如 Sqoop、Flume、Kafka 和 SFTP 等工具。
-
数据摄取将由元数据驱动
-
为了摄取新的数据源,只要使用支持的摄取方法(如 Kafka、Flume、Sqoop 等),就不需要新代码
-
我们应该能够注册数据集,并在数据摄取后立即将它们开始进行目录化
获取的数据可以以多种形式使用:存储、持久化到设备、发布到外部供应商。它可以通过 API 被其他第三方程序访问。
-
存储层:为了保持数据完整性和隔离性,我们可以将数据分布在多个 HDFS 层中,以便每个层定义从获取原始数据到生成洞察之间的某个阶段。
-
发布:该服务将用于将数据发布到外部用户和订阅者,以及应用程序,作为数据湖的外部推送。
-
批量 API:该服务将用于通过异步 API 从系统中下载数据。用户将发出数据检索请求,并在数据集准备好时收到通知。数据的交付可以通过多种方式提供:
-
下载链接。
-
推送到 SFTP 位置。
-
内部用户的 HDFS 位置(同一集群或另一个集群)。
-
需要定义 API 合同。
-
-
数据访问 API:该 API 类似于批量 API,但仅支持频繁同步的小型数据集,例如信用评分。
-
笔记本:这些可以包括诸如 Apache Zeppelin 或 Hue 数据科学工作台等界面,为用户提供图形界面,以便访问集群中的数据集并使用 Impala、Spark、R 等进行查询。
数据科学
数据科学作为一个领域有许多维度和应用。正如我们都熟悉通过制定可重用和已建立的公式来理解科学,我们理解特征、行为模式和有意义的洞察。同样,通过工程和统计方法从相关数据中,我们也能理解行为模式和有意义的洞察。因此,它也被视为数据加科学,数据科学的科学。
数据科学在各行各业已经使用了几十年。许多算法已经开发并在各行业中使用,包括:
-
K 均值聚类
-
关联规则挖掘
-
线性回归
-
逻辑回归
-
天真贝叶斯分类器
-
决策树
-
时间序列分析
-
文本分析
-
大数据处理
-
可视化工作流
-
Apriori
-
神经网络
前述算法的组合用于解决流行的商业问题,例如以下问题,并且新的商业机会不断涌现:
交叉销售 | 查找客户特征之间的关系将营销活动与潜在客户匹配 |
---|---|
产品产量分析 | 分类产品缺陷 |
直接营销 | 分类客户将营销活动与潜在客户匹配 |
流失分析 | 预测流失趋势争取挽回客户 |
交叉销售 | 查找交易中产品的关系 |
分割分析 | 分类客户将营销活动与潜在客户匹配 |
库存分析 | 查找交易中产品的关系做出补货决策 |
产品组合分析 | 分类客户将营销活动与潜在客户匹配估算产品组合的收入 |
欺诈检测 | 分类客户检测异常活动 |
信用评级 | 分类客户信用评级客户 |
例如,在数据分类中,我们可以实施以下三种模型,以获得一个精炼且准确的模型:
- 随机森林:随机森林或随机决策森林是一种集成学习方法,用于分类、回归和其他任务。它们通过在训练时构建多个决策树,并输出类别的众数(分类)或个别树的平均预测值(回归)。随机决策森林可以纠正决策树过拟合训练集的问题。
请查看以下链接:en.wikipedia.org/wiki/Naive_Bayes_classifier
。
-
朴素贝叶斯:朴素贝叶斯分类器是一类简单的概率分类器,基于在特征之间做出强独立假设的贝叶斯定理。朴素贝叶斯分类器具有很高的可扩展性,要求学习问题中的变量(特征/预测变量)数目与参数数量之间呈线性关系。
-
支持向量机:支持向量机是有监督的学习模型,配有相关的学习算法,用于分类和回归分析。给定一组标记为属于两个类别之一的训练样本,SVM 训练算法构建一个模型,将新样本分配到其中一个类别,从而成为一种非概率的二分类线性分类器。
以下是构建预测模型以解决业务问题的步骤:
-
定义具体的业务目标是最重要的标准。不同利益相关方对数据科学问题协议的业务价值和目的达成一致是最关键的步骤。
-
来自关键利益相关方的资助和支持对于项目的成功至关重要。
-
数据工程师和数据科学家之间的协作至关重要;否则,孤立作业将无法实现项目的成功。
-
数据湖是一个汇集来自不同源系统的有用数据的存储库,这些数据是为了解决业务问题所需的适当、有效、有意义、有用且历史的数据。建立数据湖时,应考虑初始数据的容量规划以及未来增长的考虑。
-
根据质量标准清理数据,以确保仅使用有效和适当的数据,避免脏数据或过时数据进入系统。
-
特征工程是数据科学项目的核心工程,旨在从原始数据中提取有意义的见解(特征)。
-
特征选择是消除不相关、冗余或高度相关的特征。
-
通过遵循适当的验证方法(例如 K 折交叉验证或 70:30 模型)来测试预测模型。
-
确定模型结果。与任何项目一样,结果准确性的重复验证模型的有效性。
-
通过使用新数据进行持续迭代改进,并进行微调来优化模型。
市场上有许多受欢迎的统计建模工具,例如:
-
SPSS 建模工具
-
KNIME
-
Microsoft Revolution Analytics
-
RapidMiner
-
SAP 预测分析
-
SAS Enterprise Miner
-
Oracle 高级分析(Oracle 数据挖掘,Oracle R 高级分析)
一些流行的开源工具提供与商业统计软件包相当的全部功能:
-
R
-
Python
-
Scala
-
MatLab
-
Julia
近期低成本技术(如 Hadoop 生态系统、云计算、大数据和开源工具)的普及,已促使从小型企业到大型巨头的各行各业大规模采用。
数据科学方法
数据科学解决方案的方法包括以下几个阶段:
数据集中的知识挖掘(发现)是一个交互式和迭代的过程,涉及多个步骤,用于识别数据中的有效、有用和可理解的模式。
-
数据处理:数据清洗将原始数据预处理成易于使用的格式;相关任务包括:
-
抽样,即从大量数据中选择具有代表性的子集
-
去除噪声
-
对不完整行进行缺失数据处理
-
数据标准化
-
特征提取:提取在特定上下文中有用的数据
-
-
数据转换:通过缺失数据处理方法确保数据的可用性,例如:
-
仅使用包含相关数据的行
-
值替代:
-
使用特定属性的均值
-
使用相似案例的历史值进行回归替代
-
使用匹配插补、相似属性关联的案例
-
最大似然法、EM 算法等
-
-
-
数据挖掘:通过方法如:
-
关联规则
-
序列和路径分析
-
聚类分析:
- 根据一些共同属性将数据集划分为聚类或子集
-
分类方法:
-
将样本划分为类别
-
使用经过训练的集合作为之前标注过的数据
-
-
回归模型
-
基于过去数据的推断预测新值
-
基于少量其他测量属性计算因变量的新值
-
-
可视化模式
-
分类类似于聚类,但需要提前定义类别:
-
基于输入标签的分类器返回的分类结果
-
概率分类是指分类器返回可能的值,将它们分配到一个类别中。
-
采用特定标准,如数据超过 90%,以避免成本高昂的错误
-
根据概率限制(如超过 40%)将对象分配到类别中
-
-
回归与预测
-
数据表统计相关性:
-
基于先验假设的功能形式中的数据分布
-
基于机器学习的算法
-
-
曲线拟合:
-
探索数据背后定义良好且已知的函数
-
理论和专业知识为基础
-
-
-
机器学习:
-
监督学习:
-
输入和期望结果都作为训练数据的一部分
-
模型训练过程的输入基于已知的正确目标和结果
-
适当的训练、验证和测试集构建至关重要
-
快速且准确的结果
-
泛化能力,新的数据应能在没有目标先验知识的情况下得出正确结果
-
泛化意味着能够为训练过程中未出现的输入产生有效的输出
-
-
无监督学习:
-
在训练过程中不会提供正确的结果给模型
-
输入数据根据其统计特性仅按类别进行聚类
-
聚类和标签的重要性
-
即使是少量的代表性对象,也可以应用于所需的类别和标签
-
-
-
曲线拟合
-
通过使用适当的子集和早期停止实现
-
基于数据学习,而不仅仅是底层函数
-
用于训练的数据在面对新数据时应表现良好
-
-
-
-
数据集:
-
训练集:用于学习,其中目标值是已知的。
-
验证集:用于调优分类器架构,以估计误差。
-
测试集:仅评估分类器的性能;在训练过程中从未使用。测试集的误差应提供无偏的泛化误差估计。
-
-
-
-
-
数据选择:垃圾进,垃圾出,底层模型表示应包括训练、验证和测试数据。
-
不平衡数据集:
-
网络最小化总体误差,因此数据集中各类型数据的比例至关重要
-
损失矩阵包含
-
不同情况的均衡表示是解读网络决策的最佳方法
-
-
-
学习过程:
-
反向传播:
-
输出值与目标值进行比较,以计算预定义的误差函数
-
误差反馈到网络中
-
使用这些输入,算法调整每个连接的权重,以减少误差函数的值。
-
网络将在经过足够次数的训练周期后收敛
-
-
-
-
-
结果:
- 混淆矩阵:X 轴上的预测结果与 Y 轴上的目标值进行比较。行表示真实类别,列表示预测类别。
-
-
-
完整性和污染
-
分类器的性能根据以下标准进行评估,例如在两个类别之间:
-
完整性:正确分类的 A 类对象的百分比
-
污染:A 类对象被错误分类为 B 类对象的百分比
-
分类率:正确分类的对象的整体百分比
-
-
-
监督学习模型
-
神经网络
-
多层感知器
-
决策树
神经网络
它是一个结构化的流程,由神经元的输入层和输出层组成,中间有一个或多个隐藏层。
神经元通过选择激活函数与相邻层之间建立了良好的连接,尽管它们位于不同的拓扑结构中,权重是根据各种类型和架构的连接的函数值分配的。
人工神经网络:受生物神经系统过程的启发。人工神经网络是一种信息处理机制。
大量高度互联的简单处理神经元元素协同工作,解决特定问题。
一个简单的人工神经元:
节点或单元是一个基本的计算元素,接收来自其他单元或外部源的输入。
为了模拟突触学习,每个输入都与相关的权重 w 一起考虑。
该单元的输入加权和通过一个函数进行计算:
神经网络的不同类型有:
-
前馈:自适应线性神经元 (ADALINE),RBF,单层感知器
-
自组织:SOM(科霍宁映射)
-
递归:简单递归网络,霍普菲尔德网络
-
随机:玻尔兹曼机,RBM
-
模块化:关联神经网络 (ASNN),机器委员会
-
其他:神经模糊,级联,PPS,GTM,脉冲(SNN),即时训练
多层感知器
这是最流行的监督模型,通常由多个计算单元层组成,单元层之间通过前馈方式互联。每一层的神经元通过直接连接与后续层的神经元相连。
决策树
这是一种分类方法,基于一组简单的规则;它们是非参数的,不需要对每个类中变量的分布做任何假设。
例如,决策树如下所示:
无监督模型
-
聚类
-
距离
-
归一化
-
K 均值
-
自组织映射
聚类
聚类是层次化的,它使用先前分配的聚类来查找连续的聚类,采用自下而上(凝聚性)或自上而下(分裂性)以及分区类型的聚类,如下图右侧和左侧所示。
距离
用于确定两个聚类之间的相似性和聚类的形状。
归一化
-
VAR:对于每个属性的变换数据集,均值被减少到零;这是通过从每个属性的值中减去该属性的均值,并将结果除以该属性的标准差来实现的。
-
范围(最小-最大归一化):它从每个属性的值中减去该属性的最小值,然后将差值除以属性的范围。其优点是准确地保持数据中的所有关系,不引入任何偏差。
-
Softmax:它是一种减少数据中极端值或离群值影响的方法,而无需将它们从数据集中删除。当你有离群值数据且希望将其包含在数据集中,同时仍然保留在均值标准差内的数据的显著性时,这种方法非常有用。
K-means
K-means 是流行的模型,因为它快速且简单;然而,每次运行的结果可能不同。
-
根据特征将数据划分为 K 个簇。
-
每个簇由其质心表示,质心是簇中点的中心。
-
每个点被分配到最近的簇。
-
目标是最小化簇内方差或数据与对应簇质心之间距离的平方和。
-
计算均值点——质心。
通过将每个点与最近的质心关联来构建新的划分。计算每个数据集的均值点或质心。
近年来,低成本技术的涌现,如 Hadoop 生态系统、云计算、大数据和开源工具,已导致从小型企业到大型巨头的广泛采用。数据科学的渗透也遍及各行各业,生态系统得到了普及。
总结
在本章中,我们介绍了构建大数据应用程序的关键概念,涵盖了数据发现、质量和摄取的工具。我们讨论了 Spark Stream 内存引擎及其多功能性;还讨论了适用于各种行业解决方案的数据科学模型。
第七章:DevOps - 持续集成与交付
在本章中,我们将学习实施 DevOps 核心流程,如源代码仓库、代码审查、工件仓库、持续测试、持续开发、持续集成。如前面关于大数据和云的章节所讨论的,这些过程在每个阶段都非常有价值。我们将重点关注一些流行的工具,如 Git、Jenkins、Maven、Gerrit、Nexus、Selenium 等。
-
持续集成(CI)
-
持续交付(CD)
-
Jenkins 工具设置
-
配置管理 - Jenkins
-
源代码管理 - Git
-
构建管理 - Maven
-
源代码审查 - Gerrit
-
仓库管理 - Nexus
-
测试自动化 - Selenium
-
持续部署 - 管道
-
Jenkins 客户端设置
-
Jenkins 安全
-
Jenkins 指标
持续集成和持续交付是确保高质量和及时软件交付的流行且有价值的流程。持续集成是一个集成的软件开发过程,其中多个开发人员遵循敏捷方法,并将其调整为以下最佳实践:
-
确保所有开发代码都受版本控制系统的管理
-
包含适当的代码审查流程
-
代码更改快速集成、测试和构建
-
构建过程集成以运行单元测试并自动化
-
立即处理构建错误,快速调整
-
构建结果和仓库管理的跟踪与指标
-
透明度和用户友好的构建过程
持续交付是扩展持续集成的过程。
-
软件的最新版本随时可用
-
从技术和质量的角度来看,经过测试周期的更改已准备好部署
-
自动化发货和部署过程
持续集成过程如下图所示:
持续集成过程的详细步骤如下:
-
开发者环境:开发者在本地工作区使用集成开发环境运行时和安装在 PC 上的构建工具,或基于云的(Web IDE)创建代码更改。他们进行单元级测试、数据验证、代码性能检查等。开发者进行的代码更改被推送到源代码管理系统。
-
典型的持续集成和持续部署周期包括设置 CI/CD 基础设施和流程,如下所示:
-
源代码版本和仓库管理系统
-
启动编排管道的过程调度器
-
管理代码构建和计划测试的构建过程
-
执行构建的构建节点
-
在已识别的测试节点上进行自动化测试的测试过程
-
构建结果工件仓库
-
用于存储构建结果的工件仓库
-
测试节点上的场景和验收测试
-
使用部署工具将应用程序安装到运行时系统
-
部署在运行时系统上的应用程序的验收测试
-
质量经理将批准验收测试,以同意部署测试系统。
交付经理将批准应用程序部署到生产环境。
CI/CD 的最佳实践
-
使用版本控制:在协作开发环境中进行同时开发将面临多个挑战:
- 源代码管理系统在将代码置于版本控制系统下之后,定义了代码的单一真实来源。通过有效地采用合并流程进行主线开发,并在系统中使用回路修复等方式,源代码将是可重现的。Git 是一个流行的源代码管理系统,而 GitHub 作为一种软件即服务(SaaS)模式是其云版本:
-
自动化构建:标准化的自动化构建流程将稳定构建过程,产生可靠的结果。成熟的构建流程必须包含构建描述以及执行构建所需的所有依赖项,并使用标准化的构建工具安装。Jenkins 是最通用的构建调度工具;它提供便捷的用户界面,并且有许多插件集成了大多数流行的持续集成工具。
-
构建中的测试:需要执行一些测试,以验证代码的有效性和适应性,超越代码的语法正确性,如下所示:
-
单元测试直接作用于构建结果
-
在开发者提交代码前对源代码进行静态检查。可以使用 Git 提交前触发器或 CI 系统来设置门控或非门控检查
-
新构建应用程序的场景测试,确保其能够安装并启动
-
代码的功能性能:
-
单元测试框架在像 JUnit 这样的源代码技术中非常流行。Selenium 框架提供图形用户界面和浏览器行为。
作为构建的一部分,尽早在开发者的工作站上执行这些测试,可以节省时间和精力,避免在开发过程后期发现的错误。
-
尽早且频繁地提交代码:在多个项目的分布式开发环境中,每个团队或开发者都打算将自己的代码与主线集成。同时,特性分支也会发生变化并集成到主线中。最佳实践是尽早且快速地集成代码。新更改与主线合并之间的时间延迟越大,产品不稳定的风险、所需时间以及随着主线从基线发展而产生的复杂性也会增加。因此,每个在特性分支上工作的开发者应该每天至少提交一次代码。对于主分支上不活跃的项目,在实施之前必须评估不断变基所需的高昂努力。
-
每次更改都需要构建:开发者的更改需要并入主线,但它们有可能会破坏主线的稳定性,影响依赖主线的开发者的工作。
持续集成通过持续构建任何提交的代码变更来解决这个问题。任何构建失败都需要立即处理,因为构建失败会阻塞主分支的整个演进,而且根据提交的频率和此类问题的存在,修复这些问题可能会非常昂贵。通过强制执行分支级别的构建,可以最大限度地减少这些问题。
在 Gerrit 中推送进行审查或在 GitHub 中发起拉取请求是有效的机制,用于提出变更并检查变更质量,通过在推送到主分支之前识别问题,避免返工。
-
快速解决构建错误:在每个变更的分支级别进行构建的最佳实践将使相应的开发人员立即解决其代码构建问题,而不是将其传播到主分支。这形成了一个持续的变更-提交-构建-修复循环,发生在每个相应的分支级别。
-
快速构建:自动化过程快速返回构建结果和测试应该成为开发者工作流的重要输入;短暂的等待时间有助于提升持续集成过程的整体效率。
这是在将新变更安全地集成到主分支的同时,进行构建、验证和场景测试的平衡行为。有时,可能会出现相互冲突的目标,因此需要在不同级别的接受标准之间取得折衷,考虑到主分支的质量最为重要。标准包括语法正确性、单元测试和针对所做变更的快速场景测试。
- 生产前运行:在生产流水线的不同阶段,多个设置和环境会导致错误。这适用于开发者环境、分支级别的构建配置和中央主构建环境。因此,进行场景测试的机器应与主生产系统相似,并具有相当的配置。
手动遵循相同配置是一项艰巨的任务;这正是 DevOps 增值和核心价值主张的体现,并将基础设施设置和配置视为类似于编写代码的过程。所有机器的软件和配置都被定义为源文件,这些文件使得你能够重建相同的系统;我们将在第八章中详细讨论此内容,DevOps 持续部署。
-
构建过程是透明的:构建状态和最后变更的记录必须对所有人可用,以便确认构建的质量。Gerrit 是一个变更审查工具,可以有效地用来记录和跟踪代码变更、构建状态和相关评论。Jenkins 流程插件为构建团队和开发人员提供了一个完整的端到端概览,涵盖源代码管理工具、构建调度器、测试环境、工件库等相关内容。
-
自动化部署:以自动化方式将应用程序安装到运行时系统中,称为部署,并有多种方式可以完成此操作。
-
自动化场景测试应成为变更接受过程的一部分。这些测试可以通过构建触发,以确保产品质量。
-
设置多个运行时系统,如 JEE 服务器,以避免单实例瓶颈,序列化测试请求并能够运行并行的测试查询。使用单一系统也会带来重建环境的开销,每次测试用例都需要更改环境,导致性能退化。
-
使用 Docker 或容器技术按需安装并启动运行时系统,在预定义的状态下运行,之后可以删除(我们将在第九章,容器、物联网和微服务中深入讨论容器技术)。
-
自动化测试用例,由于新评论的验证频率和时间在大多数情况下不可预测,因此安排每天在指定时间执行作业是一种可探索的选项,构建将部署到测试系统,并在成功部署后发送通知。
-
部署到生产环境是一个手动且经过深思熟虑的决策,确保符合所有质量标准,并确保该更改适合部署到生产环境。如果也能自信地自动化执行,这也是自动化持续部署的最高成就。
-
持续交付意味着对任何集成的更改都要进行充分验证,以便准备好部署到生产环境。这并不要求每次更改都必须自动部署到生产环境。
Jenkins 设置
我们将从 Jenkins 开始,因为它是持续集成过程的核心组件。Jenkins 流程工作流如下所示:
参见 Jenkins 首页:jenkins.io/index.html
,如下所示:
安装 Jenkins 的先决条件
Jenkins 安装和配置要求应根据以下参数,参考 Jenkins 首页的建议进行规划:
-
操作系统——Ubuntu/Debian、Red Hat/Fedora/CentOS、openSUSE、FreeBSD、OpenBSD、Gentoo、Windows、macOS X 的 Linux 版本
-
JDK 版本
-
内存
-
硬盘空间
-
Java 容器——Jenkins 的 WAR 文件可以在任何支持 Servlet 的引擎上运行,如 Tomcat 或 Glassfish 应用服务器。
Jenkins 可以根据其用途以不同模式安装:
-
独立运行:Jenkins 可以在其自己的进程中独立运行,使用内置的 Web 服务器(Jetty)进行实验和小型项目。
-
基于 Servlet:它也可以作为一个 Servlet 框架运行,适用于开发项目。
-
用于预发布或生产环境的多节点设置:分布式客户端-服务器设置;建议使用 Jenkins 高级安装程序。
独立安装
建议的独立安装就像名字所暗示的那样,是在单台机器上独立完成的(与用于不同任务的多个系统相对):
-
独立安装需要在系统上安装 JDK。
-
下载
Jenkins.war
文件 -
打开命令提示符,并在
Jenkins.war
文件的位置运行以下命令:
C:>Java -jar Jenkins.war
在初始化过程中,将运行几个任务,并在安装过程中出现以下屏幕:
- 初始屏幕页面将询问插件选项:
- 插件将根据前述选项中选择的配置安装:
- 成功安装后,以下管理员凭据创建页面将弹出:
- 访问 Jenkins:成功安装后,可以通过本地计算机的 web 浏览器访问 Jenkins,如下所示:
http://localhost:8080
- Jenkins 仪表板将在此链接处打开:
- 仪表板中的“管理 Jenkins”选项将提供各种配置各种参数的选项:
- 仪表板中的“管理插件”选项是一个重要选项,提供了与源代码系统、认证系统、各种开发平台等集成的广泛选择。
在 Servlet 引擎上安装 Jenkins 需要安装 Tomcat 或 Glassfish。
-
将
Jenkins.war
文件复制到tomcat
文件夹中的 web 应用程序文件夹。 -
从 Tomcat
bin
目录启动 Tomcat 服务器。 -
http://localhost:8080/Jenkins
–在 Tomcat 服务器上访问 Jenkins。
在 Ubuntu 上安装 Linux 系统
-
登录服务器并更新:
sudo apt-get -y update
。 -
安装 Java:
sudo apt-get install -y default-jdk
。 -
使用
wget
命令从Jenkins-ci.org
站点下载 Ubuntu 版本:wget http://pkg.jenkins-ci.org/debian-rc/binary/jenkins_2.0_all.deb
。 -
包安装–
sudodpkg - i Jenkins.zip
。 -
通过
sudo apt - get -f install
解决依赖关系。 -
在端口
http://localhost:8080/Jenkins
上访问 Jenkins。 -
继续按照前面图示中列出的步骤进行。
-
要在启动时初始化 Jenkins,请在
/etc/rc.local
文件中添加命令/etc/init.d/jenkins start
。
Git(SCM)与 Jenkins 的集成
Git 是最流行的源代码管理系统,提供了广泛的好处,例如:
-
版本控制允许您为不同目的维护代码的多个版本
-
需要一个代码存储库来将所有项目相关的代码放在一个地方
-
用户之间的协作和调试目的的干预
可从 git-scm.com/downloads
下载 Git:
提供 Linux、Windows 等多个平台版本,支持桌面和网页版本。
存在多种类型的仓库:
-
在 GitHub 上创建的公共仓库可以让所有人读取访问权限,但写入或提交访问权限仅授予指定的个人或团队。
-
私有仓库允许合作者参与,并且是 GitHub 的付费订阅服务。
-
本地仓库是无需互联网连接的桌面版本。
-
远程仓库是一个基于 Web 的仓库,提供扩展功能,如问题管理和拉取请求。
GitHub 提供选项以同步来自单台计算机或多台计算机的代码更改。
拉取更改将同步来自桌面的代码更改与在线仓库,而克隆选项将创建仓库的全新副本到计算机中。
执行这些任务使我们能够在基于云的 SaaS 系统上维护源代码。
-
在 GitHub 上创建一个登录帐户。
-
创建一个项目仓库,用于组织与你的项目相关的代码。
将 GitHub 与 Jenkins 集成
要将 GitHub 仓库与 Jenkins 集成,请按照以下步骤操作:
-
在管理插件中,搜索 Git 插件并安装它,位于筛选器部分。
-
如果是默认安装,我们可以在已安装标签下找到它,如下所示:
- 在 Jenkins 重启后,创建新项目时将显示如下界面:
- 选择一个工作名称,下一屏幕将显示 Git 选项,如下所示,在源代码管理标签下。你可以以类似的方式添加其他 SCM 工具,如 CVS、Subversion 等:
- 在前面仓库 URL 占位符中输入本地计算机的 Git 仓库地址或一个网页链接,以便将 Git 配置与 Jenkins 集成。
Maven(构建)工具与 Jenkins 集成
- 从
maven.apache.org/download.cgi
下载 Maven;这是二进制文件的最新版本:
-
将下载的 Maven 文件提取到一个文件夹中。
-
打开管理 Jenkins:
- 选择 Maven 插件,如下所示,并安装它们,不选择重启选项。
- 监控插件进度,如下所示:
- 在配置工具下,添加 Maven,并提供仓库位置:
- 使用 Maven 项目选项创建一个新的项目任务:
- 构建环境中的 Maven 选项如下所示:
- 项目创建如下:
使用 Jenkins 构建任务
- 一个简单的应用程序构建并运行该程序:
- 以下列出了源代码仓库的选项:
- 我们可以指定需要构建的文件位置,这些文件可以来自源 Git 代码仓库,也可以来自 GitHub 上的 URL:
- 可以使用多种选项、命令模式和 Maven 等执行构建:
- 命令行程序可以按如下方式执行:
- 保存后,可以看到构建选项,历史记录也可用:
- 可以看到构建进度,并且可以访问仓库,如下所示:
源代码审查 - Gerrit
代码审查是软件开发框架中的一个重要功能。像 Gerrit 这样好的协作工具,非常适合且需要在代码审查过程中使用。Gerrit 启动基于拉取的工作流来发起变更请求,其中即使是源代码的评论也会被包括在内,以便通过工作流过程将变更合并到代码仓库中。Gerrit 维护着一个本地仓库,包含镜像的 Git 项目仓库和参考仓库。Gerrit 从主分支创建另一个维护分支,以跟踪对代码的审查;它为提交消息创建一个变更 ID 标识符,用于跟踪代码审查中的每一个变更。
Gerrit 允许进行代码变更比较,审阅者可以给出五个评分中的一个:
-
+2: 看起来不错,已批准
-
+1: 看起来不错,但需要额外批准
-
0: 无评论
-
-1: 建议不提交
-
-2: 阻止提交
Gerrit 安装
-
从
www.gerritcodereview.com/
下载 Gerrit。 -
根据平台选项按照安装说明操作,并通过以下方式访问 Gerrit,在
8080
端口上创建用户和项目:
- 在 Jenkins 中通过“管理插件”配置 Gerrit:
在第三章中列出的版本控制工具,DevOps 框架,例如基于 Web 的代码审查界面 Gerrit,允许在线审查变更,从任何 git 客户端推送变更,然后将其自动合并到主分支;它也可以配置为远程 git 仓库。
Gerrit 的配置包括用户创建,安全外壳(SSH)设置,用于与 Gerrit 服务器交换数据。配置文件/etc/gerrit.config
有许多参数,需要根据配置要求进行设置。
仓库管理
维护多个构建版本工件是仓库管理的关键特性,而 Nexus 是一个流行的仓库管理器。它可以从www.sonatype.org/nexus/downloads/
下载。
安装后,可以通过http://<nexus host>:8081/nexus
访问:
Nexus 可以通过插件进行 Jenkins 集成配置:
使用 Jenkins 进行测试
Jenkins 提供了许多开箱即用的功能和插件来进行测试。网站wiki.jenkins.io/display/JENKINS/xUnit+Plugin
提供了这些插件:
可用的测试插件列表如下所示:
-
JUnit 本身
-
AUnit
-
MSTest(从 MSTest 插件导入)
-
NUnit(从 NUnit 插件导入)
-
UnitTest++
-
Boost 测试库
-
PHPUnit
-
Free Pascal 单元
-
CppUnit
-
MbUnit
-
Google 测试
-
EmbUnit
-
gtester/glib
-
QTestLib
设置单元测试
- 选择我们已经设置好的项目:
- 选择构建选项:
- 选择一个高级选项:
- 输入
build.xml
的位置:
- 选择后构建选项,并选择 -
发布 JUnit 测试结果报告
:
- 在测试
reports.xml
中,输入我们项目中创建报告的文件夹,以便 Jenkins 自动识别运行 JUnit 测试用例后生成的 XML 文件:
我们可以选择构建并深入查看测试结果。
自动化测试套件
持续集成是验证构建的过程,用于客观评估其准备好进入下一个阶段的程度;这通过自动化测试实现。因此,构建工件设置为自动测试;Selenium 是最流行的框架。
可以从以下网站下载:
- 在 Jenkins 下,选择插件管理器中的 Selenium 插件并安装,安装后重启以启动:
- 配置 selenium 服务器 JAR 文件:
- 配置我们创建的项目,使其适用于此自动化框架:
- 在构建过程中,添加选项
SeleniumHQhtmlSuite Run
:
- Selenium IDE 将生成 TestSuite,启用 Selenium 测试时,通过启动 selenium 驱动程序并使用 SuiteFile:
持续交付 - 构建流水线
持续交付是从软件开发到部署构建一个健壮流水线的过程。
- 按照以下步骤从“管理插件”安装构建管道插件:
- 要设置构建管道,点击仪表盘中“All”标签旁边的“+”符号:
- 选择构建管道视图并为管道选择一个名称:
- 选择选项和创建的项目:
- 交付管道视图根据项目每个阶段的状态创建。
Jenkins 特性
-
客户端-服务器
-
安全性
-
报告
较大的项目需要配置多个机器,而不是在一台机器上进行集中构建。此外,还有对多个不同环境的测试构建要求。使用从属机器可以有效地将负载从主服务器转移。
它们需要通过 TCP/IP 套接字从主机到从属的双向通信链接,只需要从属代理而不是完整的 Jenkins 包或已编译的二进制文件。
- 要在 Jenkins 中设置从属节点/节点,配置并选择“管理节点”选项,创建一个新节点:
- 选择名称和“傻瓜从属”选项。
- 从属节点的详细信息需要提供,然后选择让 Jenkins 将 Windows 从属视为 Windows 服务。需要提供机器的名称节点和登录凭据等详细信息。
- 从属机器将如以下方式可用;可以配置新作业在此从属机器上运行。
Jenkins 中的安全性
具有相关权限的用户可以通过安全配置进行设置:
- 在“管理 Jenkins”下,选择“配置全局安全性”,并选择启用安全选项:
- 一旦保存选项,将提示您输入管理员用户。
-
在 Jenkins 管理设置下,选择“管理用户选项”以创建用户,并设置执行作业所需的基于矩阵的安全性授权:
-
可以安装报告选项、度量选项和报告插件。
-
有许多可用的度量指标,如构建历史度量插件:
-
平均故障时间 (MTTF)
-
平均恢复时间 (MTTR)
-
构建时间的标准差
-
-
可以在“管理插件”中安装,通过选择“构建历史度量插件”,上述度量指标将在作业页面上显示。
-
要查看图形化表示,请在“管理插件”下使用 Hudson global-build-stats 和 Global Build Stats 插件。设置选项、初始化统计信息、创建新图表选项,所有现有的构建记录将显示出来。
摘要
在这一章中,我们学习了实现持续集成和持续部署的流程和工具。
使用仓库管理、代码审查和测试自动化来实现开发、持续集成和持续部署。
在下一章中,我们将讨论将基础设施配置管理作为代码来进行持续部署的话题,使用的工具包括 Chef、Puppet 和 Ansible。同时,我们将讨论使用工具 Splunk 和 Nagios 进行持续监控的过程。
第八章:DevOps 持续部署
DevOps 持续部署使得变更可以快速地从开发迁移到生产环境。基础设施和自动化在实现持续部署中起着关键作用。在本章中,我们将学习配置自动化和基础设施自动化(基础设施即代码)的实现,使用的工具包括 Chef 和 Ansible。我们还将讨论使用工具 Splunk 和 Nagios 进行持续监控的过程:
-
持续部署
-
Chef
-
组件
-
术语
-
架构
-
-
Ansible
-
组件
-
术语
-
架构
-
-
持续监控
-
Splunk
-
Nagios
正如我们在前几章中讨论的,下面的图示展示了持续集成、持续部署和持续交付的对齐过程。
持续集成(CI)是将开发、单元测试和构建过程进行持续化处理,而不是分阶段(逐步)的过程。在 CI 过程中,每个开发者将他们的代码更改合并到中央版本控制系统,每次提交都会触发自动化构建。因此,最新的版本始终可用在代码库中,构建出来的可执行文件也来自最新的代码。
持续交付(CD)是持续集成过程的下一步,旨在通过短周期的测试和更频繁的软件发布,使软件工程能更快速和频繁地交付。自动化测试过程确保软件可以随时可靠地发布。
持续部署是通过减少开发新代码和代码在生产环境中可用之间的时间间隔(也就是“前置时间”)的过程。为了实现这一目标,持续部署依赖于自动化的基础设施,自动化执行各种步骤,确保每次成功的代码集成符合发布标准,最终导致部署,并且实时应用程序会更新为新代码。
传统上,新机器是由管理员和系统工程师根据文档和定制脚本等构建的。通过手动程序(如自定义脚本、黄金镜像配置等)管理基础设施既耗时又容易出错。寻求更快速和成熟部署的组织采用基础设施配置自动化,这意味着像管理软件代码一样管理基础设施,以实现可重复的结果,因此它也被称为基础设施即代码。
就像 SDLC 过程一样,基础设施也可以使用类似的工具和流程进行管理,如版本控制、持续集成、代码审查和自动化测试,扩展为使基础设施的配置变更更加强大和自动化。基础设施代码和配置更改会在从开发到 QA 测试系统,再到生产的所有环境中一致地进行测试、共享和推广,更加容易、快速、安全和可靠,并附有详细的变更审计日志。通过基础设施代码作为服务,新机器的配置可以像代码一样编写,并同时设置多个机器。通过利用云的弹性,这种可扩展模型更加高效。采用 DevOps 到基础设施即代码的转换等,不仅仅是简单的基础设施自动化,还能带来以下多种好处:
-
确保无误的自动化脚本是可重复的
-
可在多个服务器上重新部署
-
在出现问题时具有回滚能力
-
可以有效执行基础设施代码的测试标准,如单元测试、功能测试和集成测试
-
由于机器的文档化状态以代码形式维护并保持最新,因此避免了书面文档
-
使开发和运维团队在基础设施配置和供应上进行协作,将基础设施代码作为变更管理的一部分
我们将从流行工具功能和前述图中列出的功能角度讨论持续部署。
Chef
Chef 是一个突出的配置管理和基础设施自动化平台;它提供了一整套企业级功能,如工作流、可视化和合规性。它支持从开发到生产的基础设施和应用程序的持续部署。基础设施配置自动化作为代码由 Chef 编写、测试、部署和管理,适用于云环境、本地环境或混合环境,并提供全面的 24/7 支持服务。例如,客户端系统、安全补丁可以通过主服务器写入配置作为一组指令,并在多个节点上同时执行。
如下图所示,Chef 平台支持多个环境,如亚马逊 Web 服务(AWS)、Azure、VMware、OpenStack、谷歌云等。Windows、Linux、VMware 等平台也可用。所有流行的持续集成工具,如 Bitbucket、Jenkins、GitHub、CircleCI 等,都支持工作流集成。运行时环境可在 Kubernetes、Docker 和 Swarm 上运行。
Chef 平台组件
Chef landscape 包括 Chef 的各个元素,如节点、服务器和工作站,以及它们之间的关系,如下图所示。我们将讨论每个组件、术语及其在生态系统中的角色,以使 Chef 客户端能够执行分配的任务。Chef 术语类似于食品准备。食谱是制作菜肴的配方,而配方则是原料。
Chef 的组成部分包括:
-
Chef 服务器
-
Chef 客户端
-
Chef 工作站
-
Chef 仓库
Chef 服务器
Chef 服务器是用于维护网络中配置数据的中心,存储食谱、将策略应用于节点,并由 Chef 客户端管理每个注册节点的详细元数据。Chef 服务器通过安装在相应节点上的 Chef 客户端提供配置细节,如配方、模板和文件分发。因此,Chef 客户端在其节点上实现配置,减轻了 Chef 服务器的处理任务负担。该模型具有可扩展性,可以在整个组织内一致地应用配置。
Chef 服务器的特性
具有管理控制台和搜索功能的 Web 启用用户界面。
-
Chef 服务器上的管理控制台是一个基于 Web 的界面,用于管理多个功能,如:
-
网络中的节点
-
食谱和配方
-
分配的角色
-
数据包——JSON 数据存储,可能包含加密数据
-
环境详情
-
索引数据的搜索功能
-
管理用户账户和 Chef 服务器访问数据
-
-
搜索功能方便查询任何在 Chef 服务器上索引的数据类型,如节点、角色、平台、环境、数据包等。Apache Solr 搜索引擎是基础搜索引擎,并扩展了所有功能,如精确匹配、通配符、范围搜索和模糊搜索等。可以在食谱、命令行、管理控制台搜索功能等中运行完整的索引搜索,具有不同选项。
-
数据包位于 Chef 服务器上的安全子区域中;它们存储敏感数据,如密码、用户账户数据和其他机密类型的数据。只有通过 Chef 服务器验证的具有有效 SSL 证书的节点才能访问它们。数据包通过 Chef 服务器以其存储在 JSON 格式中的全局变量进行访问。可以通过食谱进行搜索和访问并加载。
-
策略定义了如何在业务和操作需求、流程及生产工作流中实施角色、环境和食谱版本:
-
角色是基于在组织中执行的特定功能、模式和流程来分配任务的一种方式,例如权限用户或业务用户等。每个节点、Web 或数据库服务器都有独特的属性,并根据角色分配运行列表。当节点要执行任务时,它会将其属性列表与执行该功能所需的属性进行比较。Chef 客户端确保属性和运行列表与服务器上的保持一致。
-
环境反映了组织的实际需求,例如开发、测试或生产系统,每个环境都维护有对应版本的 cookbook。
-
Cookbook 维护着特定组织的配置政策。不同版本的 cookbook 会进行版本控制,并维护关联的环境、元数据以及满足不同需求的运行列表;它们被上传到 Chef 服务器,并由 Chef 客户端在配置节点时应用。Cookbook 定义了一个场景,并包含支持该场景所需的一切,例如:
-
指定使用哪些资源及其顺序的食谱(Recipes)
-
属性值
-
文件分发
-
模板
-
Chef 扩展,例如自定义资源和库
-
-
运行列表(Run-list)包含所有 Chef 配置节点到目标状态所需的信息。它是一个有序的角色和食谱列表,按照执行顺序排列,用于将节点配置到预期的状态。每个节点的运行列表都是定制的,并作为节点对象的一部分存储在 Chef 服务器上。它可以通过 knife 命令或通过工作站上的 Chef 管理控制台进行维护,并上传到 Chef 服务器。
-
节点上的 Chef 客户端
Chef 客户端可以安装在不同类型的节点上——物理节点、虚拟节点、云节点、网络设备等,这些节点都已注册到 Chef 服务器。
-
节点类型:
-
物理节点是一个活动设备(系统或虚拟机),它连接到一个网络,安装了 Chef 客户端,用于与 Chef 服务器通信。
-
云节点是托管在外部云环境中的节点,如 AWS、Microsoft Azure OpenStack、Google Compute Engine 或 Rackspace。Knife 配合插件支持外部云服务,并创建实例来部署、配置和维护这些实例。
-
虚拟节点是一个像软件实现一样运行的系统,不需要直接访问物理机器。
-
网络节点,如交换机,可以通过 Chef 进行配置,并自动化物理和逻辑以太网链路属性及 VLAN 配置。网络设备的示例包括 Juniper Networks、Arista、Cisco 和 F5。
-
容器是运行各自配置的虚拟系统,多个容器共享同一操作系统。容器在管理分布式和可扩展的应用程序与服务时非常有效。
-
-
Chef 客户端:
-
Chef 客户端执行实际的配置。它定期联系 Chef 服务器,获取最新的 cookbook,并根据 cookbook 指令更新节点的当前状态(如果需要)。这一迭代过程由业务策略强制执行,以确保网络符合预期的目标状态。
-
Chef 客户端是安装并运行在每个注册到 Chef 服务器上的节点上的本地代理,用于确保节点处于预期状态。Chef 客户端承担大部分计算工作。它通常是虚拟机、容器实例或物理服务器。
-
Chef 客户端与 Chef 服务器之间的认证通过 RSA 公钥/密钥对进行,针对每个交易请求进行身份验证。Chef 服务器上存储的数据在注册节点身份验证后共享,避免任何未经授权的数据访问。
-
安装 Chef 客户端后,节点成为基础设施上的计算资源,由 Chef 管理,用于执行如下任务:
-
将节点注册到 Chef 服务器
-
认证服务
-
创建节点对象
-
与 Chef 服务器同步 cookbook
-
所需的 cookbook(包括食谱、属性和所有其他依赖项)被编译并加载
-
根据需求配置节点
-
异常处理和通知
-
-
Ohai
Ohai 是 Chef 客户端运行的一个工具,用于收集系统配置和度量数据,具有许多内置插件,可以确定系统状态以供 cookbook 使用。Ohai 收集的度量数据包括:
-
操作系统
-
内核
-
主机名
-
完全限定域名
-
虚拟化
-
云服务提供商元数据
-
网络
-
内存
-
磁盘
-
CPU
Ohai 收集的属性会被 Chef 客户端自动使用,以确保这些属性与服务器上的定义保持一致。
工作站
工作站使用户能够编写、测试和维护 cookbook,并与 Chef 服务器和节点进行交互。Chef 开发工具包也会安装并配置在工作站上。Chef 开发工具包是一个软件包,包含一组规定的工具,包括 Chef、命令行工具、Test Kitchen、ChefSpec、Berkshelf 等。用户通过工作站进行:
-
开发 cookbook 和测试食谱
-
在不同环境中测试 Chef 代码
-
版本源控制与 Chef 仓库同步
-
定义和配置角色、环境和组织政策
-
强制数据包用于存储关键信息
-
在节点上执行引导操作
Cookbook 是存放文件、模板、食谱、属性、库、定制资源、测试和元数据的存储库。Chef 客户端通过 cookbook 和食谱配置组织中的每个节点,配置的基本单位是 cookbook,它为食谱提供结构。基础设施状态被定义为文件、模板或包,按照所需场景在策略分发中进行配置。
Chef cookbook 使用 Ruby 编程语言,这是一种完整的编程语言,具有语法定义。食谱是配置特定项(如软件包、文件、服务、模板和用户)的简单模式,其中包含定义属性和值的块,这些属性和值与其对应项相匹配。食谱是 cookbook 中的基本配置元素。Chef 食谱是一个文件,它将相关资源组合在一起,例如配置 Web 服务器、数据库服务器或负载均衡器所需的所有内容。食谱存储在 cookbook 中,并且可以依赖于其他食谱。
Chef 仓库
Chef 仓库,顾名思义,是用于编写、测试和维护 cookbooks 的存储库制品。Chef 仓库像源代码一样进行管理,并与版本控制系统(如 GitHub、Bitbucket 等)同步。Chef 仓库的目录结构可以包含每个 cookbook 的 Chef 仓库,或者将所有 cookbooks 存放在一个 Chef 仓库中。
knife
是一个命令接口,用于从工作站与 Chef 服务器通信并上传 cookbooks。为了指定配置细节,使用 knife.rb
文件,knife
帮助管理:
-
节点引导
-
配方和 cookbooks
-
环境、角色和数据包
-
各种云环境资源
-
Chef 客户端安装到节点
-
Chef 服务器索引数据搜索功能
与 Chef 配合使用的工具和实用程序包称为 Chef 开发工具包(Chef DK)。它包括与 Chef 交互的命令行工具,例如 knife
Chef 服务器和 Chef 客户端,以及本地 Chef 代码库(chef-repo
)。Chef DK 的组件如下:
-
Chef 客户端
-
Chef 和
knife
命令行工具 -
Test Kitchen、Cookstyle 和 Foodcritic 作为测试工具
-
使用 InSpec 作为可执行代码的合规性和安全性要求
-
为上传到 Chef 服务器而编写的 cookbooks
-
数据包项的加密和解密使用 Chef-Vault,并使用已注册节点的公钥
-
Cookbooks 依赖管理工具
-
工作流工具 Chef
-
单元测试框架 Chef Specto 在本地测试资源
-
用于编写干净的 cookbooks 风格检查的 Rubocop 基于工具 Cookstyle
-
Chef Automate 服务器上的持续交付工作流,还提供命令行工具来设置和执行
-
用于配方代码静态分析的工具是 Foodcritic
-
它用于跨平台测试 cookbooks,集成测试框架工具是 Test Kitchen
-
为了快速进行 cookbook 测试和容器开发,
kitchen-dokken
是一个带有驱动程序、传输工具和提供者的test-kitchen
插件,用于在 Docker 和 Chef 中使用 -
用于 Vagrant 的 Kitchen 驱动程序是
`kitchen-vagrant`
-
人们在同一个
chef-repo
和 Chef 服务器中协作,knife
工作流插件是knife-spork
-
Chef 的首选语言是 Ruby
配方是资源的集合,通过资源名称、属性值对和操作等模式定义。它是读取并以可预测的方式执行的基本配置元素,并用 Ruby 编程语言编写。
一些属性如下:
-
包括配置系统所需的所有内容
-
存储在 cookbook 中
-
要使用 Chef 客户端,必须将其添加到运行列表中
-
它按照运行列表中列出的相同顺序执行
-
Chef 客户端仅在指示时运行配方
-
可以包含在另一个配方中
-
可能会读取数据包的内容(加密的数据包)
-
可能会输入搜索查询的结果
-
可能依赖于其他配方
-
通过标记节点来促进任意分组的创建
-
如果配方是常量,则重复执行时不会发生任何变化。
配方 DSL 是一种 Ruby DSL,用于声明资源,主要来自配方内。它还有助于确保配方按预期方式与节点(和节点属性)交互。大多数配方 DSL 方法会找到特定的参数,指导 Chef 客户端根据节点参数采取相应的操作。
资源是一种配置策略声明,说明:
-
描述所需配置项的期望状态
-
声明所需的步骤,以使项达到期望状态
-
资源类型被指定,例如包、模板或服务
-
列出额外的资源属性
-
被分组为配方,描述工作配置
Chef 具有内置资源,覆盖常见平台上的常见操作,并且可以构建以处理任何定制的情况。
通过不同版本的烹饪书,管理多个生产、预发布、开发/测试环境。
烹饪书模板资源用于添加到配方中,以动态生成静态文本文件。
为了管理配置文件,使用 嵌入式 Ruby(ERB)模板。
烹饪书/模板目录包含带有 Ruby 表达式和语句的 ERB 模板文件。
烹饪书按照标准一致编写,并进行相应的测试。
通过单元和集成测试,验证烹饪书配方,测试代码质量也叫做 语法测试。
Test Kitchen、ChefSpec、Foodcritic 等是用于测试 Chef 配方的工具。
属性文件的执行顺序与在烹饪书中定义的顺序相同。
Chef 基于 Ruby 构建,它是一个轻量级的领域特定语言(DSL),具有内建的分类法,用于满足组织的定制需求。
为了管理环境、烹饪书、数据包,并为用户和组配置基于角色的访问,属性、运行列表、角色等,Chef 服务器用户界面是 Chef 管理控制台。
Chef 超市是一个社区平台,用于共享和管理。任何 Chef 用户或组织都可以使用烹饪书。
Chef 的扩展功能
它是一个强大的自动化平台,将基础设施转化为在云端、本地或混合环境中运行的代码。通过 Chef Automate,基础设施可以在网络中跨组织规模进行配置、部署和管理。Chef Automate 的核心部分包括 Chef、Habitat 和 InSpec。
以下图片显示了三个开源、强大的引擎:
Chef 是基础设施自动化的核心引擎。Habitat 是一个应用程序自动化工具,模拟容器和微服务的概念。InSpec 通过指定可执行代码来确保合规性和安全性要求。
Habitat
Habitat 提供了一种预定义的应用程序自动化打包格式;Habitat 管理员和应用程序依赖项被打包并作为一个单元进行部署。Habitat 包格式定义了如何结构化,它们是隔离的、不可变执行的,适用于任何类型的运行时环境,如容器、裸金属或 PaaS。Habitat 管理员管理包的同级关系、升级策略和安全政策,这些都可以审计。
InSpec
InSpec 是一个开源工具,用于测试是否符合安全策略。它是一个框架,用于指定合规性、安全性和政策要求,以便自动测试基础设施中的任何节点。合规性可以通过代码表示,并集成到部署管道中:
-
使用 Compliance DSL,InSpec 使你能够快速轻松地编写审计规则。
-
InSpec 检查基础设施节点,以便在本地或远程运行测试。
-
安全性、合规性或政策问题的不合规情况会被记录。
InSpec 审计资源框架与 Chef Compliance 完全兼容。
它可以在多个平台上运行,使用 SSH 等远程命令或使用 Docker API,除了通过 API 确保合规性外,它还可以访问数据库、检查并限制服务或协议的使用,以及虚拟机的配置。例如,可以限制客户端或服务器机器上的 Telnetd 或 FTP 服务。
持续部署全栈管道是 Chef Automate。它包括自动化的合规性和安全性测试。该工作流提供了应用程序和基础设施的可见性,同时在开发和生产过程中的更改会传播整个管道。
Chef 高级架构组件包括 Chef DK、Chef Server 和客户端:
Chef 服务器扮演多个角色,充当配置数据的中心。它存储 cookbook,并根据基础设施应用政策到系统,按照每个系统定义的元数据进行操作。
Cookbook 开发工作流由 Chef 开发工具包规定,如下所示:
-
骨架 cookbook 创建:一个包含 Chef 开发工具包标准文件的 cookbook,Berkshelf 是帮助管理 cookbook 和相关依赖项的包管理器。
-
使用 Test Kitchen 创建虚拟机环境:该环境用于开发包含位置详细信息的 cookbook,以便在开发过程中进行自动化测试和调试。
-
准备和调试 cookbook 的配方:一个迭代过程,用于开发和测试 cookbook、修复 bug 并进行测试,直到它们达到预期目标。Cookbook 可以使用任何文本编辑器编写,例如 Sublime Text、vim、TextMate、EditPad 等。
-
执行验收测试:这些测试是在完整的 Chef 服务器上进行的,使用接近生产环境的环境,而不是开发环境。
-
通过所有验收测试的 cookbooks 以期望的方式部署到生产环境。
Chef Automate 工作流
Chef Automate 管道是基础设施和应用程序的全栈连续交付方法。它为任何应用程序的安全部署提供支持,支持高速度的变更,并与基础设施变更相关联。
Chef Automate 管道质量门控自动将开发者的工作站中的变更从部署推送到生产环境。提议的变更经过团队审批后,接受测试通过并发布到相应的工件中进行生产交付。
此图显示了 Chef 代码的开发、测试和部署工作流:
工件在验收阶段之后通过管道,进入质量保证的联合阶段、彩排(预生产)阶段,并最终交付到生产环境。
Chef Automate 图形用户界面提供了操作和工作流事件的视图。其数据仓库收集来自 Chef、Habitat、Automate 工作流和合规性的输入。仪表盘跟踪每个变更状态通过管道,并且可以使用查询语言自定义仪表盘。
合规性
可以通过创建自定义报告,使用 InSpec 中的合规规则,识别合规问题、安全风险和过时的软件。内置的配置文件包含针对安全框架(如 Centre for Internet Security(CIS)基准)的预定义规则集等。合规报告可以是独立的,也可以是集成的。同时,Chef Automate 服务器提供高可用性和容错能力,提供有关基础设施的实时数据,并确保一致的搜索结果。
Chef Compliance 服务器促进了基础设施合规性的集中管理,执行以下任务:
-
创建和管理规则配置文件
-
根据组织的安全管理生命周期定期测试节点
-
扫描完全远程执行;节点上不会安装任何足迹
-
合规报告确保基础设施满足安全要求
-
节点合规性审计统计信息已提供
Chef 合规报告详细列出了多个参数,如按节点划分的补丁和合规性,以下为示例:
来自 Automate 的 Chef 合规报告视图。
Chef Automate 提供分析合规报告的能力,可以根据节点、节点平台、环境或配置文件来调取数据,并深入挖掘相关信息。
Chef Automate 合规控制状态报告提供了关于主要、次要、关键、补丁级别等的全面仪表盘。
Ansible
Ansible 是一个流行且强大的自动化框架,专为持续交付而设计,其特点和优点在以下主题中列出:
突出功能
Ansible 提供以下功能:
-
现代化
-
自动化现有的部署过程
-
管理遗留系统和流程,像 DevOps 一样更新
-
-
迁移
- 定义应用一次并可在任何地方重新部署
-
DevOps
- 模拟所有内容,持续部署
Ansible 的优点
使用 Ansible 提供了以下列出的多个优势:
-
简单易用
-
不需要特殊的编码技能
-
任务按顺序执行
-
快速提高生产力
-
自动化易于理解
-
-
功能强大
-
应用部署
-
配置管理
-
工作流编排
-
应用生命周期编排
-
-
无代理
-
无代理架构
-
使用 OpenSSH 和 WinRM
-
无需代理进行利用或更新
-
更高效且更安全
-
Ansible 是一个多维度的 IT 自动化引擎,它简化了云资源配置、服务间编排、配置管理、应用部署及其他许多 IT 功能的自动化。
Ansible 通过规定系统间的相互关系来模拟 IT 基础设施,支持多层级的部署,而非单独管理每个系统。
如前所述,Ansible 没有客户端代理,也不需要额外的自定义安全基础设施。通过使用一种称为 YAML 的普通英语语言描述自动化任务,并以 Ansible 剧本的形式,使得部署非常简单。
Ansible 架构如下所示:
Ansible 术语、关键概念、工作流和使用方法
Ansible Tower 是一个基于 Web 的企业自动化框架解决方案,旨在成为控制、保护和管理 Ansible 环境的中心,提供用户界面和 RESTful API。它提供以下丰富的功能:
-
访问控制基于角色,以确保环境的安全,并有效管理——允许共享 SSH 凭据但不传输
-
通过一键部署访问,即使是非特权用户也可以通过即时访问安全地部署整个应用
-
确保完整的审计和合规性,因为所有 Ansible 自动化任务都集中记录
-
拥有各种云源的库存,可以通过图形界面管理或同步
-
它基于强大的 REST API,能够与 LDAP 集成,并记录所有任务
-
可与持续集成工具 Jenkins 轻松集成,提供命令行工具选项
-
支持通过配置回调来进行自动扩展拓扑
-
Ansible Tower 使用 Ansible 剧本进行安装
CMDB
Ansible 配置管理数据库(CMDB)在数据库中维护企业的所有配置信息,并支持多种格式的云创建选项,适用于不同的供应商。
剧本
剧本是用 YAML 编写的配置程序,用于自动化系统。Ansible 能够精细地编排多个基础设施拓扑实例,并对许多机器进行非常详细的控制。Ansible 的编排方法是通过简单的 YAML 语法或功能来管理精细调度的自动化代码。
Ansible 剧本描述了一项策略,以便在远程系统上执行配置和部署,强制执行一般的 IT 流程遵循步骤。
一个简单的类比是,主机库存是原材料,说明书是剧本,Ansible 模块是车间里的工具。
要管理部署到远程机器的配置,可以在基本层面使用剧本(playbook)。在更高级的层面,它们可以控制多层次的滚动更新,涉及到与监控服务器和负载均衡器的交互,并将操作委托给其他主机。
剧本是用一种基本的文本语言开发的,旨在便于人类阅读。剧本和文件的组织可以有多种方式。
一个简单的剧本示例**:**
- hosts: webservers
serial: 6 # update 6 machines at a time
roles:
- common
- webapp
- hosts: content_servers
roles:
- common
- content
模块
Ansible 模块可以控制系统资源,如服务、软件包或文件,用于处理和执行系统命令。这些资源模块由 Ansible 推送到节点,配置它们为所需的系统状态。这些 Ansible 模块通过 SSH(安全外壳)在目标节点上执行,任务完成后会被移除。模块库默认随多个模块一起提供,这些模块可以通过剧本或直接在远程主机上执行。模块可以驻留在任何机器上,不需要维护服务器、守护进程或数据库的概念。模块和库是可定制的,通常使用任何终端程序和文本编辑器创建,并通过版本控制系统来有效地跟踪内容的变化。
库存
Ansible 库存是一个资源列表:
-
主机和组
-
主机变量
-
组变量
-
组和组变量
-
默认组
-
拆分组和主机以及特定数据
-
库存行为参数列表
-
非 SSH 连接类型
Ansible 通过库存列表,能够同时在多个系统上操作基础设施。动态库存机制允许多个库存文件通过库存插件灵活且可定制。库存列表可以位于默认位置,或者从动态或云源(如 EC2、Rackspace、OpenStack 等)指定库存文件的位置,支持不同格式。
下面是一个纯文本库存文件的示例:
[webservers]
www1.example.com
www2.example.com
[dbservers]
db0.example.com
db1.example.com
插件
Ansible 的核心功能通过一系列便捷的插件得到增强,并且可以用 JSON(Ruby、Python、Bash 等)进行自定义。插件可以连接到任何数据源,扩展 SSH 以外的其他传输连接类型,回调日志,甚至增加新的服务器端行为。
Ansible Tower
提供多个功能,例如:
-
可以连接 LDAP、AD、SAML 和其他目录
-
基于角色的访问控制引擎
-
无暴露存储的凭据
-
对首次使用者友好
-
启用智能搜索的信息查找
-
在运行时配置自动化
-
基于 REST API 的与流程和工具的集成
-
扩展容量的 Tower 集群
Ansible Tower 可以调用多 playbook 工作流,链接任意数量的 playbook,使用不同的清单,以不同用户身份运行,批量运行,或使用不同的凭证。
Ansible Tower 工作流促进了许多复杂操作,可以构建工作流来配置机器、应用系统的基本配置,并由不同团队维护不同的 playbook 来部署应用程序。可以为 CI/CD 构建工作流,构建一个应用程序,将其部署到测试环境,运行测试,并根据测试结果自动提升应用程序。Ansible Tower 直观的工作流编辑器可以轻松地将不同的 playbook 设为备用,在先前的工作流 playbook 成功或失败时进行替代执行。
一个典型的工作流可能如下所示,它可以快速在多个系统上有效使用,而不会将其基础设施下线。为了实现持续部署,自动化 QA 对成熟到此水平至关重要:
-
脚本自动化以部署本地开发虚拟机
-
CI 系统,如 Jenkins,每次代码更改时部署到暂存环境
-
部署作业执行构建时的测试脚本,通过每次部署的 pass/fail 结果
-
在部署作业成功后,同一个 playbook 会对生产环境清单进行运行
Ansible Tower 工作流带来了以下功能:
-
作业调度
-
内置通知,通知团队
-
稳定的 API 可与现有工具和流程连接
-
新的工作流以建模整个过程
Ansible Tower 仪表板(参见图片)提供以下功能:
-
仪表板和实时自动化更新
-
图形化库存管理
-
集成的 RBAC 和凭据管理
Ansible Vault
Ansible Vault 是一个将敏感数据以加密形式存储的功能,例如密码或密钥,而不是将其作为纯文本保存在角色或 playbook 中。这些 Vault 文件可以放在源代码管理中,或者分发到多个位置。数据文件,如 Ansible 任务、处理程序、任意文件,甚至二进制文件也可以使用 Vault 加密。这些文件在目标主机上解密。
Ansible Galaxy
Ansible Galaxy 是一个开源网站,旨在为社区提供信息,并协作构建 IT 自动化解决方案,汇聚管理员和开发者。网站提供了预配置的角色,可以通过 Galaxy 搜索索引下载并快速启动自动化项目。这些角色也可以与 GitHub 账户一起使用。
使用 Ansible 的测试策略
尽管测试是一个非常组织化和站点特定的概念,但 Ansible 集成测试与 Ansible playbook 一起设计为一个有序的、快速失败的系统。它通过基于推送的机制,方便地将测试嵌入到 Ansible playbook 中。
Ansible playbook 是系统的期望状态模型,它将确保声明的事项,如要启动的服务和已安装的软件包,符合声明性声明。Ansible 是一个基于命令的系统,处理未处理的错误时,主机会立即失败并防止该主机进一步配置,并在 Ansible 执行结束时以摘要形式显示它们。Ansible 是一个多层次的编排系统,可以将测试嵌入到 playbook 执行中,作为任务或角色。
在工作流中进行基础设施集成测试的应用程序测试,将有效检查代码质量和性能,确保其在进入生产系统之前得到验证。由于是基于推送的,工作流中的检查和平衡机制,甚至升级,都很容易在本地主机或测试服务器上维护。
监控
企业监控是一个主要活动,它将监控开发里程碑、应用日志、服务器健康状况、操作、基础设施、漏洞、部署和用户活动进行分类。这些通过以下方式完成:
-
收集和关键信息
-
成熟的监控工具
-
避免基于不确定性做出判断和决策
-
参与式监控与评估
-
选择并使用正确的指标
-
在业务背景下解读指标结果
-
实时数据收集
-
管理数据和信息
开发里程碑:监控开发里程碑是衡量 DevOps 采纳策略是否有效的指标,通过深入了解实际过程和团队的表现来进行评估。一些度量标准包括冲刺范围变化、现场修复的 bug 数量、以及承诺与交付功能的比例。这些指标驱动团队效率和按时完成任务的遵守情况,此监控作为敏捷插件集成于问题追踪中。
代码漏洞:监控应用程序代码中的漏洞,列出不安全编码实践引入的顶层代码弱点。这些可以通过定期进行代码审查或更改第三方依赖关系等方式加以解决。
部署:部署监控是配置构建服务器,使其在过程中内建一些监控,通知团队。具有通知功能的持续集成服务器与聊天服务器通信,迅速提醒团队构建和部署失败。
应用日志输出:如果服务分布式部署,应计划将应用日志输出到集中式日志记录,以便充分利用,实时提供错误和异常的价值。能够以可搜索的格式追踪错误代码生成的通知,在生产之前带来收益。
服务器健康:监控可用资源的正常运行时间和性能,包括停机或过度利用的服务器。入侵检测和健康监控系统与同一通知管道集成,将提供额外的价值。
活动监控:用户活动监控既包括功能开发,也包括基础设施扩展。同时监控开发里程碑和数据量。
集中存储应用日志、用户活动监控、项目历史等合并日志数据,为检测和分析提供价值,能够在全球范围内关联不同的日志源,以了解应用和项目的状态。
Splunk
Splunk 是一个流行的应用监控工具,可帮助实时监控由 DevOps 驱动的应用交付,支持持续交付或持续集成,帮助快速从概念转向生产。Splunk 企业版通过提升速度和质量,帮助提高应用交付对业务的影响。
Splunk 通过以下优势提升代码质量:
-
在客户看到问题之前解决代码问题。
-
更快速地检测和修复与生产相关的问题。
-
可以通过客观指标确保代码正常运行并满足质量服务水平协议(SLA)。
Splunk 是一个平台,能够捕捉并记录客户、机器数据、用户、事务、应用、服务器、网络和移动设备的所有活动和行为。
Splunk 平台通过集成从应用开发到测试再到生产监控的实时洞察,增强了其业务影响力。它提供了跨所有交付生命周期阶段的统一视图,而非离散的发布组件。
为业务和 DevOps 领导者提供实时可见的与业务相关的数据,包括应用性能、使用情况、收入系统、购物车履行和注册数据,帮助更好地规划库存、报告并改善客户体验。
支持开发生命周期集成和跨多种支持的阶段及应用的可视化:
支持操作生命周期的集成和跨多种支持的阶段及应用的可视化。使用分析可以更快地交付应用:
-
跨每个 DevOps 交付工具链组件实现端到端的可见性
-
在应用交付生命周期中,相关的洞察可以更快迭代
-
测量和基准化发布贡献,提升 DevOps 团队效率
Splunk 通过为业务领导者提供反馈循环,帮助组织评估代码更改对客户的实际影响。持续的互动有助于建立关于机器行为和深入资产模型的更多智能。
这些好处反映了应用交付对业务的影响:
-
通过将业务指标与代码更改相关联,获得新的业务洞察
-
通过交付表现更好的代码提升用户体验
-
提供更安全、更合规的代码有助于提升声誉
Nagios 基础设施监控工具
有多个 Nagios 开源工具的变体,用于监控特定操作系统上每个细分领域的关键基础设施组件:
-
网络监控软件
-
网络流量监控
-
服务器(Linux、Windows)监控
-
应用监控工具
-
Web 应用监控
-
监控核心引擎和基础 Web 界面
-
Nagios 核心插件包及附加组件
-
Nagios 日志服务器安全威胁与审计系统
Nagios 有助于监控网络中的问题,如过载的数据链路、网络连接、路由器、交换机、由于服务器过载或崩溃造成的问题等。
Nagios 可以通过多种可视化方式和报告提供度量结果,以监控网络中每个节点的可用性、运行时间和响应时间,并支持基于代理和无代理的监控。
使用 Nagios 进行有效的应用监控能够使组织快速发现应用程序、服务或进程的问题,并采取纠正措施,以防止应用用户的停机。
Nagios 应用程序和应用状态监控工具扩展到 Windows 应用程序、Linux 应用程序、Unix 应用程序和 Web 应用程序。它拥有一个活跃的社区协作网络。
路由器监控功能提供了诸如在机器无响应时立即通知、通过检测网络中断和协议故障提前预警、提高服务器、服务和应用程序的可用性等好处。
使用 Nagios 进行 Windows 监控可以提高服务器、服务和应用程序的可用性,快速检测网络中断、服务失败、进程故障、批处理任务和协议故障等问题。系统度量、事件日志、应用程序(如 IIS、Exchange 等)、服务(如 Active Directory、DHCP、服务状态、进程状态、性能计数器等)等广泛的指标将被收集。
Nagios——企业级服务器和网络监控软件
内置的高级功能包括:
-
提供全面仪表板,集成概览源、检查、网络流量数据等
-
通过安全性和可靠性网络分析仪的警报,检测可疑的网络活动。
-
提供网络流量、带宽、整体网络健康状况等的深度洞察与分析选项,并具有先进的可视化功能。
-
监控特定应用的网络使用情况,提供自定义应用监控、自定义查询、视图和报告。
-
通过专门视图展示的历史网络流量数据与网络流量信息的子集。
-
异常活动警报与自动警报系统示例,如带宽使用超过指定阈值。
-
集成的网络分析仪服务器负载与硬盘空间可用性度量
集成的网络分析、监控和带宽仪表盘。
Nagios 仪表盘提供多种监控选项,如源组、服务器 CPU、磁盘使用情况等,可以根据业务需求扩展和自定义更多选择。
总结
在下一章中,我们将讨论可视化的高级话题、多个供应商提供的容器、编排选项、物联网、微服务等。
第九章:容器、物联网与微服务
在本章中,我们将学习容器、虚拟化、Kubernetes、物联网、微服务等概念。
-
虚拟化:
-
半虚拟化
-
基于容器的虚拟化
-
-
容器简介:
-
容器类型
-
Docker
-
Java 容器服务
-
亚马逊容器服务
-
关键容器服务
-
Google 容器服务
-
-
容器编排:
-
Kubernetes
-
Docker Swarm
-
Mesosphere
-
-
物联网
-
微服务
虚拟化
这是一种逻辑上将大型计算机系统划分的方式,使多个应用程序能够同时并行运行。裸机应用无法跟上资源如服务器处理能力和容量改进的进步。这为设计虚拟机(VMs)铺平了道路,通过在物理服务器上运行专门的软件来仿真一种底层硬件系统。
同一物理服务器可以承载多个虚拟机,每个虚拟机都可以运行不同的操作系统。每个虚拟机都运行一个独特的操作系统以及它支持的二进制文件/库和应用程序。虚拟机可能会非常大,达到几个 GB。服务器虚拟化的好处包括将应用程序整合到单一系统中,减少服务器占地空间,加快服务器配置速度,改善灾难恢复和节省成本。
虚拟机管理程序
虚拟机管理程序是创建并运行虚拟机的软件、固件或硬件,也称为虚拟机监控器。它是操作系统和硬件之间的一层,用于虚拟化服务器。
虚拟机管理程序(Hypervisor)创建虚拟环境以承载客户机虚拟机(VM)。它监管客户机系统,并根据需要分配资源。虚拟机管理程序仿真主机操作系统上的操作,并在物理机和虚拟机之间为虚拟机提供虚拟化服务:
随着云计算的迅速发展,虚拟化技术变得越来越流行,使用像 Xen、VMware Player、KVM 等虚拟机管理程序,并在普通处理器中集成硬件支持,如 Intel VT 和 AMD-V。
虚拟化类型
虚拟化类型根据它如何模拟硬件以支持客户操作系统,并仿真客户操作环境进行分类。
主要有三种虚拟化类型:
-
仿真
-
半虚拟化
-
基于容器的虚拟化
仿真
模拟是完全的虚拟化,它通过软件在虚拟机中完全运行操作系统内核。这种类型的虚拟机管理程序被称为类型 2 虚拟机管理程序,它安装在主机操作系统上方,将来宾操作系统内核代码转换为软件指令。没有硬件的参与,翻译完全在软件层进行。通过模拟支持底层环境的任何操作系统,然而,由于额外的系统资源开销,与其他虚拟化类型相比,性能有所下降。
以下示意图展示了一些示例,包括 VMware Player、VirtualBox、QEMU、Bochs、Parallels 等:
半虚拟化
半虚拟化,也称为类型 1 虚拟机管理程序,直接运行在裸金属硬件上,为运行在其上的虚拟机提供虚拟化服务。它支持操作系统、虚拟化硬件和裸金属硬件之间的协作,以实现最佳性能。这些虚拟机管理程序不需要大量资源,通常可以在小型系统上运行。
以下是一些示例,包括 Xen、KVM 等:
基于容器的虚拟化
基于容器的虚拟化也称为操作系统级虚拟化;在单个操作系统内核中,它支持多个隔离环境的执行。这个隔离的虚拟执行环境称为容器管理,其中包含一组进程。它提供了高性能和动态资源管理等特点和优势:
容器
IT 中容器的概念与运输行业中容器的概念相同。容器的基本目的是从源点到目的地运送物品。
类比地,IT 中的容器在基本用途上起着将软件从一台服务器安全迁移到另一台服务器的作用。将应用程序从开发服务器迁移到 QA(测试)服务器,再到生产服务器,通常涉及多个复杂问题,如准备基础设施环境检查清单、验证编译器、库、运行时依赖关系等。容器的概念确保它将所需的生态系统一同携带,以便应用程序能够从一个裸金属系统运行到另一个裸金属系统。从这个意义上来说,容器是自给自足的,具备所有必要的组件,并且为应用程序提供了可以在任何服务器上运行的环境。容器镜像是一个独立的可执行包,它抽象了应用层的代码和依赖项;它们占用较少的空间,并在分配的资源内运行。
容器是一种逻辑打包机制,将应用程序与其实际运行的底层环境进行抽象。基于容器的应用程序由于解耦的特性,可以轻松且一致地在各种目标环境中部署,从私有数据中心到公共云,或个人笔记本电脑。容器化将角色、责任和关注点分离;这使得开发人员可以专注于应用程序逻辑和依赖关系。IT 运维团队可以在不深入了解特定软件版本和配置的情况下,专注于纯粹的部署和管理:
容器的特点使其成为一个非常受欢迎的选择:
-
轻量级:这些容器使用更少的资源并能立即启动;多个容器可以共享操作系统内核,使用更少的资源。它们共享公共文件,镜像是从文件系统层构建的,以最小化磁盘消耗并加快镜像下线速度。
-
互操作性:容器应基于开放标准运行,并能在不同平台之间移植,包括 Linux 发行版(Debian、Ubuntu 和 CentOs)、虚拟机和 Windows。
-
安全性:容器通过将应用程序与底层基础设施隔离和分离,提供了较高的安全性。与应用程序相关的问题应仅限于容器内,既不会影响其他应用程序,也不会影响整个机器。
多租户:容器通过独特的挂载进程共享公共内核(系统资源)。对于每个容器,共享的组件是可写的,而它们则具有只读访问权限。由于这种共享概念,容器带来了以下好处:
-
异常轻量
-
快速启动时间
-
在各种云部署中的可移植性,包括公有云、私有云等
-
通过快速组装(打包)带有依赖关系的应用程序,开发和测试阶段得以加速
-
管理工作量减少,相比于管理多个服务器,管理单个系统的工作量更小,打补丁和升级的工作量也降低
-
客户操作系统和宿主操作系统应兼容,因此两者应匹配,如 Linux,不能在 Windows 上运行,反之亦然:
-
容器安全性:Linux 内核中的命名空间特性促成了容器概念的创建。为全局命名空间创建了独立的实例;其工作原理是,为每个进程,容器添加一个唯一的 ID,并且每个系统调用时,都添加新的访问控制检查。这些作为隔离的容器,其中外部对象既无法访问也无法查看容器内运行的进程。尽管共享底层内核,每个容器都被单独对待;例如,每个容器的根用户仅限于各自容器,增强了安全性。
-
容器管理:公共内核在多个容器之间具有完全的可见性,因此必须限制资源分配给容器。这是通过 Linux 控制组(cgroups)子系统进行资源分配和调度实现的。容器虚拟化是通过将进程分组来管理它们的总体资源消耗,从而限制内存和 CPU 消耗。用于限制 Linux 容器资源分配的管理工具包括 LXC、LXD、Linux-VServer、OpenVZ、Docker、systemd-nspawn、lmctfy、Warden 等。
-
可扩展性:集群管理基础设施支持可扩展性,能够根据资源需求和可用性在集群中安装、操作并调度容器化应用程序。它支持从单个实例扩展到多个实例的能力,并且在管理应用程序、批处理作业或微服务时无需额外的复杂性,抽象了基础设施的复杂性。
-
任务定义:任务通过声明性 JSON 模板定义,称为任务定义。任务所需的多个容器在任务定义中指定,包括 Docker 仓库/镜像、CPU、内存和共享数据卷。容器之间的链接方式可以作为一个单一的任务定义文件的一部分,注册到服务中。应用程序规范的版本控制也是任务定义的一部分。
-
编程控制:容器服务提供 API,用于集成和扩展服务,如集群的创建和删除、Docker 容器的注册和注销,包括启动和终止任务,并提供有关集群状态和其实例的详细信息。
-
调度:应用程序、批处理作业和服务通过调度器进行管理,按照指定的方式运行。调度器根据可用性要求和资源需求(如内存或 CPU)将容器放置到集群中。提供自定义调度器的配置,并集成第三方调度器、容器管理和编排支持与开源项目。
-
容器自动恢复:容器自动恢复不健康的容器,以确保以所需数量的容器支持应用程序。
-
容器部署:通过上传更新版的应用任务定义,调度器会自动停止旧版本的容器,并启动新版本的容器。通过方便的注册和注销容器,可以轻松地将容器更新为新版本。
-
负载均衡:通过弹性负载均衡器(ELB)分配流量到容器中,可以在任务定义中指定将容器添加到 ELB 或从 ELB 中移除容器。在任务定义中,动态端口分配会在容器调度时为其提供未使用的端口;要共享多个服务,基于路径的 ELB 路由也是一种选择。
-
本地开发:Docker Compose 是一个开源工具,用于定义和运行多容器应用程序;这可以扩展到工作机器和生产服务器。
-
监控:集群和容器运行任务,按任务定义、服务或集群分组的 CPU 和内存利用率的平均值和汇总值,提供设置警报的功能,以便在容器需要扩展或缩减时发出警告。
-
日志记录:捕获代理日志、API 调用和 Docker 日志的详细信息,用于问题诊断,包括 API 调用的时间、API 调用源 IP 地址、请求参数、响应元素、安全分析、合规性、审计和资源变更跟踪。
-
仓库支持:容器服务支持第三方、私有 Docker 注册表或 Docker hub 镜像仓库访问,以检索适当的镜像。
-
安全性:内置功能可以获得对角色和访问权限的可见性,在任务级别管理实例角色和任务角色,并通过最小权限策略进行分离。
如我们所见,容器是标准化的软件开发单元,涵盖了作为代码的所有内容,包括运行时、系统工具和系统库,以便软件应用程序运行。镜像是一个只读模板,用于创建容器。应用组件必须被架构化以便在容器中部署和运行。
容器在数字技术中变得越来越流行,并且被许多供应商提供。Docker 是一个流行的容器选择,因此其他供应商自然也会采用和支持它:
-
Docker
-
Java 容器服务
-
亚马逊
-
Pivotal
-
Azure
-
谷歌
-
IBM Bluemix 容器服务
Docker 容器
Docker 容器平台分为社区版(CE)和企业版(EE),并为各种基础设施提供了优化的安装程序:
Docker 容器服务的特点如下:
-
通用打包:将任何编程语言或服务的应用打包成容器进行移植,避免了不兼容或版本冲突的风险。
-
开发者工具包:Docker 商店中提供的现成容器包含构建、测试和运行多容器应用所需的一切,适用于任何编程语言。
-
内建容器编排:通过内建的集群功能,具备复杂的调度能力,监控、构建高可用性和容错服务,运行应用程序。
-
高度安全:开箱即用的安全性,包括相互 TLS、证书轮换、容器隔离和镜像签名,使得容器应用运行时既安全又易于使用。
-
面向应用的网络:容器通过软件定义的网络连接在一起,智能路由并负载均衡流量。容器定义的网络抽象了配置,从底层网络基础设施部署应用程序。
-
可扩展架构:与第三方系统集成,支持开放 API、插件和驱动程序,便于在最小或不需要代码更改的情况下更改存储和网络后端。
Java EE 容器作为 Java EE 的一部分
精简客户端的多层应用程序来处理事务和状态管理、多线程、资源池化及其他复杂的低级细节,这些都涉及许多行复杂的代码和难以维护的 Java EE 架构。Java EE 是基于组件的、平台独立的,确保了 Java EE 应用程序的便捷性,因为业务逻辑被组织成可重用的组件,并为每种组件类型提供容器形式的底层服务。与其投入开发这些服务,不如专注于解决当前的业务问题。
Java 容器是组件与支持该组件的低级平台特定功能之间的接口。对于 Web 服务,企业 Beans、应用客户端组件必须组装成一个 Java EE 模块,并部署到其容器中执行。
对于组装过程,为 Java EE 应用程序的每个组件以及 Java EE 应用程序本身指定容器设置。容器设置可以通过 Java EE 服务器的底层功能进行自定义,如事务管理、Java 命名和目录接口(JNDI)查找、安全性和远程连接。
一些功能包括:
-
Java EE 安全模型——授权用户被配置为访问 Web 组件或企业。
-
Java EE 事务模型将一个事务中的所有方法视为一个单元,通过指定方法之间的关系,将它们归类为单一事务。
-
JNDI 查找服务帮助应用组件访问企业中的统一接口,支持多个命名和目录服务。
-
Java EE 远程连接模型通过调用方法来管理客户端之间的低级通信,模拟虚拟机(VM),在企业 Beans 创建后进行管理。
Java EE 架构具有可配置服务和内部应用组件,可以提供不同的功能,如安全设置、访问数据库数据的权限级别,针对每个生产环境的定制。Java EE 容器提供不可配置的服务,如企业 Bean 和 servlet 生命周期、数据持久化、数据库连接、资源池和对 Java EE 平台 API 的访问。
Java EE 服务器和容器
Java EE 应用程序组件中的容器类型包括:
-
Java EE 服务器:这是 Java EE 的运行时环境,提供 EJB 和 Web 容器。
-
企业 JavaBeans(EJB)容器:它是 Java EE 服务器的一部分,负责执行 Java EE 应用程序中的企业 Bean。
-
Web 容器:它们是 Java EE 服务器的一部分,负责管理 JSP 页面和 servlet 组件的执行,适用于 Java EE 应用程序。Web 组件及其容器运行在 Java EE 服务器上。
-
应用客户端容器:用于托管应用客户端及其容器的执行。
-
小程序容器:负责小程序的执行,并将 Web 浏览器和 Java 插件托管在一起,在客户端运行。
Amazon ECS 容器服务
Amazon ECS 具有以下多种功能:
-
高度可扩展、快速的容器管理服务。
-
管理 Docker 容器可以轻松地在Amazon Elastic Compute Cloud(Amazon EC2)实例集群上运行和停止。
-
基于容器的应用通过简单的 API 调用启动和停止。
-
集中式服务用于监控集群的状态,并提供对许多熟悉的 Amazon EC2 功能的访问。
-
根据资源需求、隔离策略和可用性要求,安排容器在集群中的位置。
-
一致的部署和构建体验,管理规模提取-转换-加载(ETL)和批量工作负载。
-
构建复杂的微服务和基于模型的应用架构。
-
提供更细粒度的控制,并访问更多的使用案例,因此相比 AWS Elastic Beanstalk 更受欢迎。
Amazon ECS 也具有高度可用性,支持在多个可用区运行应用容器的概念。容器镜像存储在容器注册表中,并可以从中拉取(无论是在 AWS 内还是外)。任务定义和服务被定义以指定 Docker 容器镜像在相应集群上运行的对齐方式:
Amazon ECS 多区架构组件将在后文进一步讨论。
容器和镜像
应用组件必须被设计为在容器中运行,才能部署到 ECS。标准化单元是 Docker 容器,用于软件开发,包含运行代码所需的应用程序需求、运行时、系统工具、系统库等。镜像模板用于创建容器,并指定所有作为容器一部分的组件。通常,它是一个只读格式的文件,来自一个普通文本的 Dockerfile,存储在注册表中以供下载并在容器实例上运行:
任务定义
任务定义为应用程序在 ECS 上运行做准备,作为应用程序的蓝图,是一个 JSON 格式的文本文件。它通过各种参数描述应用程序的使用方式,包括要使用的容器、需要打开的相应端口、要定位的仓库以及与容器一起使用的数据卷,这些都是 Web 服务器(如 Nginx)上任务的一部分。
任务和调度
使用任务定义,可以指定任务的数量,以便在集群内的容器实例上进行实例化。任务调度程序负责同时将任务放置和调度到容器实例上:
集群
集群是用于运行任务的实例的逻辑分组。容器镜像从指定的注册表中下载,以便在集群内的容器实例上运行它们。
容器代理
容器代理在集群内的每个实例上运行。它将实例的信息,如当前运行的任务和资源使用情况,传递出去,并根据请求启动和停止任务:
Amazon ECS 的功能可以通过额外的服务进行增强:
-
身份与访问管理:IAM 是一项 Web 服务,用于通过认证控制对资源的访问,安全地控制用户如何使用资源和授权如何访问资源。通过使用 IAM 角色控制容器实例级别的访问权限,并且任务级别的访问权限也得到管理。
-
自动扩展:自动扩展是一项 Web 服务,用于扩展和缩减容器实例,自动启动或终止 EC2 实例。它可以在用户定义的策略、健康状态检查和计划中进行定义。
-
弹性负载均衡:ELB 通过自动将传入的应用程序流量分发到多个 EC2 实例和集群中的服务,实现应用程序的高故障容忍能力。
-
EC2 容器注册表:Docker 注册表服务是安全的、可扩展的且可靠的。通过 IAM 启用基于资源的权限,允许访问 Docker 私有注册表中的仓库和镜像。可以使用 Docker CLI 推送、拉取和管理镜像。
-
AWS Cloud Formation:AWS Cloud Formation 是一种方便的方式,用于创建、管理、配置和更新一组相关的 AWS 资源。Cloud Formation 脚本可以帮助以有序且可预测的方式定义 AWS 中的集群、任务定义和服务。
-
Amazon ECS CLI:Amazon ECS CLI 使用来自本地开发环境的 Docker Compose。它提供了高层次的命令,用于创建、更新和监控集群和任务。
-
AWS SDKs:SDK 支持多种编程语言,并自动处理以下任务:
-
对服务请求进行加密签名
-
重试请求
-
错误响应处理
-
Pivotal 容器服务
Pivotal 技术提供具有以下核心特性的容器服务:
-
容器化工作负载可以可靠地在私有云和公有云之间部署和运行。
-
容器编排内置高可用性、自动健康检查、监控等功能。
-
适用于需要访问基础设施原语的 Spark 和 Elasticsearch 工作负载。
-
适用于需要特定容器实例共址的应用,以及需要多个端口绑定的情况。
-
为 Kubernetes 和开源 Kubernetes 提供高效的操作性能,采用最新稳定的 OSS 版本,没有专有扩展。
-
通过 BOSH 按需配置,BOSH 是一个强大的发布工程工具链,在任何云环境中提供可靠一致的操作体验。
-
多云灵活性,能够在本地通过 vSphere 部署并使用 Kubernetes,或者在公有云中使用。
-
网络管理与安全性,通过编程方式管理基于软件的虚拟网络,提供 vSphere 和 VMC 上的开箱即用的网络虚拟化。
-
完全自动化的运维能够在没有停机的情况下部署、扩展、修补和升级系统,包括 Kubernetes 集群。
-
与 VMware 工具(如 vRealize Operations Manager、vSAN 网络存储和 Wavefront)轻松集成,实现功能齐全的本地部署。
-
Harbor,企业级容器注册服务器,是 PKS 的一部分。Harbor 扩展了开源 Docker 的功能,如漏洞扫描、身份管理以及对多个注册表的支持。
-
与 PCF 服务目录集成,轻松添加 APM 工具、数据库服务和服务代理 API。通过不断扩展的附加服务库扩展 PKS。
-
与 GKE 保持持续兼容,可以轻松将工作负载迁移到(或从)GKE。
-
PKS 构建于 Kubo 之上,这是一个由 Cloud Foundry Foundation 管理的开源项目。
Google 容器服务
Google 容器服务是一个受欢迎的选择,具有如下所列的特性:
-
Google 容器化应用管理提供多项高级功能和灵活性
-
容器引擎为容器化应用提供了一个托管环境,用于在容器集群上部署、管理和扩展。
-
Kubernetes 开源集群管理系统驱动容器集群引擎
-
提供工具和接口执行管理任务,管理、部署应用程序并设置策略
-
监控应用程序容器的状态,检查已部署工作负载的健康情况
-
计算引擎实例的负载均衡
-
集群中的节点池作为附加的灵活性子集
-
集群节点实例的自动扩展
-
集群节点软件版本的自动升级
-
节点的自动修复,以保持节点的健康和可用性
-
Stackdriver 日志记录和监控,让你能更清晰地了解集群的情况
-
集群的主节点和节点架构
-
IP 别名、身份访问管理 (IAM)、基于角色的访问等
-
IP 轮换和 IP 伪装代理
容器编排
容器编排是自动化部署多个容器以优化方式实现应用程序的过程。随着容器和主机数量日益增长,这一点显得尤为重要。编排意味着该过程的自动化,并包括多个特性:
-
主机配置
-
容器实例化集合
-
失败的容器重新调度
-
容器通过接口互相连接
-
将集群外的服务暴露给机器
-
通过增加或移除容器来扩展集群
编排工具
这里列出了一些流行的编排工具:
-
Mesos
-
Kubernetes
-
CorCos Tectonic
-
Docker Swarm
以下图像展示了按使用情况排列的仓库的流行度:
在选择编排工具时,组织需要考虑的三个关键差异化因素是:
-
抽象级别:支持基于容器的容器或服务
-
工具:编排管理及与其他服务的集成
-
架构:它如何支持可扩展性并从故障中恢复?
我们将详细讨论以下流行工具:
-
Kubernetes
-
Docker Swarm
-
Mesosphere
每个编排平台都有相较于其他平台的优势。有多个评估因素需要考虑,比如:
-
企业 DevOps 框架和编排方法论,以及 APIs
-
主机数量超过数千台物理机器
- Mesos 可以用于大型农场
-
容器是基于裸机、私有虚拟机,还是云中的?
- 对于云部署,Kubernetes 很受欢迎
-
对自动化高可用性的需求
-
Kubernetes 失败的 Pods/容器将会被复制控制器自动重新调度
-
在 Mesos 应用程序框架中,代码执行该角色,实现自动化的高可用性
-
-
服务的分组和负载均衡需求
- Kubernetes 提供了这个功能,但 Mesos 应用程序框架代码执行了这个功能
-
组织技能
-
Mesos 允许应用程序以框架的方式通过编程运行,并支持自定义编码
-
Kubernetes 更加声明式
-
-
设置编排框架的基础设施可能会面临挑战
Kubernetes
Kubernetes 是由 Google 创建的,现在与 Cloud Native Computing Foundation(CNCF)共同维护。它的概念是为容器部署跨多个领域的公共云到混合部署建立编排。
Kubernetes 使得应用程序的部署和管理更加简便,自动化了容器化应用程序的部署、扩展和管理。Kubernetes 提供了更高层次的功能,如负载均衡、通过故障转移(重新调度)实现高可用性和弹性扩展,具体如下:
-
对服务进行自动健康检查
-
自我修复,重新启动失败或停滞的容器
-
横向扩展,根据使用情况上下调整服务的规模
-
服务发现和负载均衡
-
版本控制的自动化发布与回滚
-
秘密和配置管理
-
存储编排,仅运行所需的资源
-
批量执行,声明式管理你的集群
构成 Kubernetes 的关键组件有:
-
集群是由多个节点组成的集合,这些节点可以是裸金属服务器或虚拟机,提供运行一个或多个应用程序所需的资源。
-
Pod 是在同一主机组上共存的资源,例如容器和卷。基于 Pod 的容器共享相同的网络命名空间,并使用 localhost 进行通信。Pod 是基本的调度单元,是临时的,不是为持久存在设计的实体。
-
标签是可以将它们作为一组进行管理的标签。像是分配给容器等实体,以便将其暴露为对外服务。
-
服务是基本的负载均衡器,并提供将其暴露给外部世界和其他容器的引用。
-
副本控制器负责管理 Pod 在集群中的调度。
Docker 编排工具
这里描述了 Docker 编排最常见的工具:
-
Docker Swarm:它是最易于使用的编排工具之一,仅需几条命令。它让你像启动第一个容器一样启动你的第一个集群。
-
Docker Engine:它是用于运行 Docker 容器的轻量级运行时和工具引擎。
-
Docker Machine:它负责为主机提供配置,并在其上安装 Docker 引擎软件。
-
Docker Swarm:通过将多个 Docker 主机聚集在一起,生成一个虚拟的 Docker 主机。它使得 Docker API 能够与兼容单一 Docker 主机的工具进行集成。
-
Docker Compose:适用于开发、测试和预生产环境。通过一个定义多容器应用程序及其依赖关系的文件创建部署所需的容器。
-
Apache Mesos:它被大型企业如 Twitter、Airbnb 和 Apple 采纳,因为它设计上能够扩展到数万个物理机器。Mesos 中的框架是运行在一个或多个容器上的应用程序。每个框架都可以接受 Mesos 提供的资源。与 Kubernetes 相比,Mesos 的功能较少,涉及额外的集成工作,更具程序化,定义服务或批处理作业。Mesos 还支持在 Kubernetes 节点集群中进行细粒度的资源分配:
Mesos 已被证明是高效的,其中应用与 Hadoop、Kafka 和 Spark 等其他服务协同工作。Mesos 是以下几个分布式系统的基础:
-
Apache Aurora:一个高度可扩展的调度服务,适用于长时间运行的服务和定时任务,如添加滚动更新、服务注册和资源配额
-
Chronos:一个容错的服务调度器,用于在 Mesos 中编排定时任务,作为 Cron 的替代品
-
Marathon:一个易于使用的服务调度器;通过同时运行两个 Chronos 实例,它增强了 Mesos 和 Chronos 的性能
物联网(IoT)
物联网将传感数据、大数据、网络、机器人技术和人工智能技术集成到一个先进的自动化和分析系统中。当物联网应用于任何行业或系统时,可以带来更高的透明度、控制力和性能,以交付完整的产品或服务。
物联网系统跨越多个行业,使用智能设备并启用强大的技术来增强数据收集、分析,实现更深层次的自动化、运营和通过适合任何环境的应用进行整合。
物联网的好处跨越多个业务领域,甚至生活方式,提供了改善客户参与度、技术优化、减少浪费、增强数据收集等优势。
IoT 感知的挑战如下:
-
安全性:一个由不断连接的设备组成的生态系统,通过网络进行通信,即便有安全措施,仍然是脆弱的
-
隐私:大量个人数据在用户未主动参与的情况下被捕获
-
复杂性:设计、部署和维护集成多种技术的物联网系统是一个复杂的系统
-
灵活性:拥有多个接口和锁定系统的物联网系统是紧密耦合的
-
合规性:当标准软件合规性以遵守规定为挑战时,物联网的复杂性使得监管合规问题更加棘手
物联网的最重要特性包括连接性、传感器、主动参与,以及小型设备与人工智能的结合:
-
连接性:在系统设备之间,尤其是物联网网络在更小且更廉价的规模上,新型的启用技术无需专门依赖主要供应商。
-
传感器:物联网的功能依赖于传感器,这些传感器将物联网从一个标准的被动设备网络转变为一个互动的集成系统,以应对现实世界的需求
-
主动参与:物联网引入了与连接技术的实时互动,形成了内容、产品和服务参与的新范式
-
小型设备:专门设计的小型设备扩展了物联网的功能,提供精确性、可扩展性和多功能性,且成本低廉,适合大众使用
-
人工智能:物联网本质上通过数据收集和分析与人工智能算法的结合,提升生活的各个方面
物联网 - 生态系统
物联网系统通过硬件设备(如远程仪表板、控制设备、传感器、服务器和路由桥设备)捕获数据。通过这些设备管理的关键任务和功能可以扩展到系统激活、安全、通信、动作和检测。
不同功能的多个设备传感器包括:
-
加速度计
-
磁力计
-
陀螺仪
-
声学传感器
-
压力传感器
-
湿度传感器
-
温度传感器
-
接近传感器
-
图像传感器
-
光传感器
-
气体 RFID 传感器
标准设备
标准设备,如桌面、平板电脑和手机,也与物联网集成,提供命令接口和远程管理功能。
桌面和平板电脑能够为系统及其设置提供最高级别的控制。
手机也可以提供远程功能,修改一些设置或配置。
路由器和交换机是标准的网络设备,是连接设备的关键。
数据合成
物联网系统的有效性通过数据收集、设备集成、实时分析、网络连接和通过平台、嵌入式系统、合作伙伴系统和中间件采取行动来实现。这些单个和主应用程序负责与关键业务系统的集成,如订单系统、机器人技术和物联网网络中的调度。
数据收集
数据收集软件收集并最终将所有收集到的数据传输到中央服务器。它收集各种数据,如传感器数据、测量数据,应用数据过滤、数据安全和数据聚合。通过协议,来自多个设备和传感器的数据实时连接到机器对机器网络。它还可以将分发数据反向传输回设备。
设备集成
通过依赖关系和关系集成所有连接的系统设备,构建物联网生态系统。它确保必要的合作来管理各个设备的各种应用、协议和限制,以便设备之间进行通信和稳定的网络连接。
实时分析
分析应用收集来自各种设备的实时数据输入,并将其转化为清晰的模式,供人类分析和可行的行动。信息分析和可视化技术可以扩展到特定行业需求的自动化相关任务。
应用和过程扩展
这些物联网应用集成了预定义的设备,扩展现有系统的覆盖范围,如允许某些移动设备或工程仪器访问软件,从而实现更广泛、更有效的系统,提高生产力并收集和分析更精确的数据。
技术和协议
除了标准的网络协议,物联网技术还包括 RFID、NFC、低能耗无线电协议、低能耗蓝牙、低能耗无线、LTE-A 和 WiFi-Direct,这些都支持物联网系统所需的特定网络功能。我们将回顾这些技术。
射频识别(RFID)和近场通信(NFC)是简单的低能耗连接启动和支付选项,用于身份和访问令牌。
更多关于物联网技术和协议的信息,请访问:www.tutorialspoint.com/internet_of_things/internet_of_things_quick_guide.htm
物联网 - 多领域应用
以下是物联网在多个领域的应用:
-
可穿戴电子设备:物联网智能可穿戴设备的渗透率,如头盔、手表、鞋子和眼镜
-
制造和工程行业:动态响应市场需求、设备故障、配电网络问题、客户需求、不合格产品、降低成本、优化资源利用和减少浪费
-
产品安全:避免故障、不合格产品和其他危险,避免召回,并控制不合格产品或市场上的产品分发
-
医疗应用:通过物联网应用,偏远地区的医疗保健可以得到扩展,提供与发达地区相同水平的医疗援助,支持移动诊所
-
住房、环境、健康与安全应用:也利用物联网来提升其生产力,为改善生活质量带来好处
-
交通运输应用:扩展至公路上的商用车辆、列车、无人机,提供改进的通信、控制和数据分发
-
商业农业:利用先进的生物技术,物联网实现更深入的自动化和分析
物联网开发平台
有许多物联网开发平台,集成了开发工具,支持连接性和分析,以快速开发和部署智能连接设备:
-
PTC 的 ThingWorx
-
Cisco 的虚拟化数据包核心
-
Electric Imp- Salesforce
-
GE 的 Predix
-
Eclipse 物联网
-
Contiki 是开源的
ThingWorx
提供快速开发的接口和嵌入式工具,如 Vuforia、Kepware、Composer、Mashup 构建器、存储、协作和连接性的搜索引擎:
-
Vuforia 用于现实开发
-
Kepware 用于单点数据分发,促进互操作性对齐
-
ThingWorx 代理用于工业连接
-
Composer 是设计测试的建模环境
-
Mashup 构建器是用于构建组件的仪表盘
-
SQUEL 是搜索引擎,扩展意味着搜索、查询和分析;用于数据分析和过滤
-
数据形状描述自定义事件、信息表、流和数据表的数据结构
-
Thing 模板允许新设备在大型物联网系统中继承属性
-
Thing 形状定义模板、属性或执行服务,允许开发人员避免重复定义设备属性
虚拟化数据包核心(VPC)
VPC 技术为 4G、3G、2G、Wi-Fi 和小型蜂窝网络提供核心服务,具有数据包核心服务整合、动态扩展和系统灵活性等关键特性。网络功能以虚拟化服务的形式提供,具有更大的可扩展性和更快的部署速度,同时降低了新服务的成本。它分发和管理数据包核心功能,无论是虚拟的还是物理的,覆盖所有资源:
VPC 应用更突出的是网络功能虚拟化、软件定义网络(SDN)以及通过支持低功耗、高流量的网络和广泛的小型设备的简单部署来实现快速的网络系统部署。VPC 引入了通过标准网络进行的直接通信、增强的自动化监控、通过智能标志的自动数据更新,以及原生 IP 网络和以太网供电(PoE)技术,改善了所有设备的整体安全性和服务质量。
Electric Imp
Salesforce Electric Imp 平台用于快速将设备连接到云,并通过一种名为 Squirrel 语言的高级、面向对象、轻量级脚本语言开发应用程序。应用程序由两个模块组成:
-
设备模块运行在设备上
-
代理模块运行在 Electric Imp 云端
Electric Imp 平台通过模块间的简单调用,确保安全的通信消息传递,并为设备交互、监控和响应提供标准的 Web 应用开发代码,语法简单易学。
Predix
通用电气 (GE) Predix 是一个工业仪器的软件平台。它是基于云的 平台即服务 (PasS),数据收集平台用于支持工业级分析。它以简单的方式连接工厂数据、个人和设备,以优化操作和性能管理。Predix 生态系统由英特尔 Edison 处理器模块、双核板和树莓派板组成。开发人员提供 IP 地址、以太网连接和电源,自动建立连接,注册到中央 Predix 系统,传输来自传感器的数据。
Eclipse IoT
基于开源技术的 Eclipse IoT 是一个由行业和学术界等实体组成的生态系统,创建开源框架和服务,用于 IoT 解决方案,开发 IoT 开发人员使用的工具,开源实现 IoT 标准技术。以下是一些实用工具:
智能家居
Eclipse IoT 的主要服务智能家居是构建智能家居解决方案的框架,集成了多种协议和标准,适用于异构环境。它通过统一的设备和信息访问促进设备之间的交互,包含部署在 OSGi 运行时中的 OSGi 服务的 OSGi 捆绑包。OSGi 捆绑包是包含文件内容、增强类行为的服务以及作为组件的聚合特性等信息的 Java 类组及其他资源的 manifest 文件。
Eclipse SCADA
Eclipse 最先进的开源 SCADA 系统旨在通过共享通信系统将各种工业仪器连接起来,以进行数据后处理。所采用的技术包括 Shell 应用程序、JDBC、Modbus TCP 和 RTU、Simatic S7 PLC、OPC 和 SNMP。该 SCADA 系统具备通信服务、监控系统、档案存储和数据可视化功能,用于开发定制解决方案。
Contiki
开源操作系统 Contiki 提供了用于小型 IoT 设备的功能,用于管理程序、进程、资源、内存和通信。其生态系统包括操作系统、网页浏览器、Web 服务器、计算器、Shell、Telnet 客户端和守护进程、电子邮件客户端、VNC 查看器和 FTP。
它在学术界、组织研究人员和专业人员中非常受欢迎,因其非常轻量化,十分适合内存、功耗、带宽和处理能力有限的设备,运行所需空间仅需几千字节,且占用空间不超过 30 KB。
Contiki 通信
Contiki 支持的标准协议,以及为 IoT 启用的协议包括:
-
uIP (针对 IPv4):此 TCP/IP 支持 8 位和 16 位微控制器。
-
uIPv6 (针对 IPv6):uIP 的扩展是完全符合 IPv6 标准的。
-
Rime:此工具集为低功耗系统提供一组原语,并在 IPv4 或 IPv6 不适用时提供替代协议栈。
-
6LoWPAN:这是低功耗无线个人局域网上的 IPv6。它是一种低数据速率的无线压缩技术,支持具有有限资源的设备。
-
RPL:这种距离矢量 IPv6 协议可以在 LLNs(低功耗和丢包网络)复杂网络中找到最适合的路径,以适应不同能力的设备。
-
CoAP:这种协议适用于需要重度远程监督的简单设备。
动态模块加载
动态模块加载器加载、重定位并链接 ELF 文件,以便在运行时加载和链接,支持环境以支持部署后应用行为的变化。
Cooja 网络模拟器
Cooja Contiki 网络模拟器生成用于工作 Contiki 和通过 Cooja 模拟器控制系统的编译。
IoT 设备、安全性、合规性和维护是采用时必须彻底考虑的重要特性。
微服务
这是一种架构模式,通过将业务能力实现为松耦合的服务来组织结构,使组织能够在持续交付/部署大型复杂应用的过程中发展其技术栈。
微服务核心模式
微服务架构是与单体架构相比的核心区别。
单体架构基于构建服务器端企业应用的独特需求。它必须支持多种客户端,例如桌面和移动浏览器,向第三方公开,并通过 Web 服务或消息代理与其他应用程序集成。业务逻辑通过处理 HTTP 请求和消息与数据库交互,并返回 HTML/JSON/XML 响应:
与这种架构相关的挑战包括:
-
大型单体代码库难以维护,模块化随着时间推移而逐渐崩溃,因为没有明确的模块边界;因此,随着时间的推移,实现更改变得繁琐。
-
过载的 IDE:IDE 的响应速度越慢,代码库越大,生产力就越低。
-
过载的 Web 容器:应用程序越大,容器启动的时间就越长,部署也会降低开发者的生产力。
-
持续部署是困难的:大型单体应用程序频繁部署更新是一个挑战。用户界面需要进行迭代开发并频繁重新部署,重新部署的风险也在增加。
-
扩展应用程序可能很困难:单体架构只能通过运行更多副本来在一个维度上扩展,以应对增加的事务量,动态调整实例数量以应对负载。然而,当数据量增加时,架构无法扩展。每个应用实例副本将访问所有数据,导致缓存效率降低,内存消耗和 I/O 流量增加。在单体架构扩展中,针对不同资源需求(如 CPU 密集型和可能的内存密集型)的每个组件独立扩展将面临挑战。
-
开发扩展的障碍:单体应用程序阻止团队独立工作,因此 UI 团队、财务团队、库存团队等之间必须进行协调开发。一旦应用程序达到一定规模,涉及多个团队的开发将成为扩展的障碍。
-
长期承诺技术栈:单体架构可能会绑定到某个技术栈,当使用更新的技术框架进行升级时会变得繁琐。如果平台框架随后变得过时,那么采用新的平台框架并重写整个应用程序可能会是一个风险较大的提案。
微服务架构
微服务是一组松散耦合的协作服务,是应用程序的构建模块。每个服务实现一组狭义相关的功能,如订单管理和客户管理服务。这些服务通过同步协议(如 HTTP/REST)或异步协议(如 AMQP)进行通信。服务是独立开发和部署的,每个服务都有自己的数据库,与其他服务解耦,确保数据一致性。
微服务架构的推动因素有:
-
快速构建应用程序,易于理解、维护和持续部署。
-
可扩展性和可用性,能够在多台机器上运行,多个应用副本
-
采用新兴技术,如框架、编程语言等
基于这种架构构建的应用程序可能包含多个组件,例如 StoreFrontU 实现用户界面、后端服务检查信用、维护库存和发货订单。这些组件能够接收客户订单、检查库存、信用可用性并发货:
该解决方案具有多个优势:
-
每个微服务相对容易理解,可以更快速地构建和部署;集成开发环境(IDE)更加高效和生产力更高
-
每个服务可以由各自的团队开发,并且可以独立部署其他服务
-
新版本的频繁部署变得更容易
-
改进的故障隔离,任何服务的内存泄漏只会影响该服务,其他服务将继续处理请求,不受影响
-
灵活地采用新的技术栈
基于微服务的解决方案面临的挑战包括:
-
创建分布式系统的复杂性,涉及多个服务事务。
-
IDE 支持和测试困难,包括协调多个服务之间的团队间通信机制。
-
部署/运维复杂性,管理一个由多种不同服务类型组成的系统。
-
增加的内存使用:微服务架构运行其自己的虚拟机以隔离实例。如果有 M 个实例,就会有 M 倍的虚拟机,从而增加了开销。
微服务决策
微服务架构更适合规模较大、复杂的应用,而不是适用于小型或初创应用程序,在这些应用中,单体架构更为合适。微服务架构将应用结构化为一组松散耦合的服务,从而通过实现持续交付/部署来加速软件开发。
微服务决策基于以下原则:
-
基于业务能力的微服务
-
基于子域的微服务
-
面向对象设计(OOD)
-
单一责任原则(SRP)
-
公共封闭原则(CCP)
微服务架构——服务必须经过充分规划,以便由小团队开发并且易于测试。单一责任原则(SRP)是服务设计的基础,用于定义类的责任以及触发更改的原因。它创造了服务的内聚设计,并实现了一小组紧密相关的功能。公共封闭原则(CCP)意味着因相同原因而变化的类应该放在同一个包中。如果两个类在不同方面实现了相同的业务规则,那么任何业务规则的更改只需对代码做出少量修改即可适应。
微服务应该对应于业务能力/业务对象,以产生价值:
-
库存管理
-
订单管理
-
交付管理
对应的微服务架构将把服务与这些能力对齐。遵循这种模式有以下优点:
-
业务能力相对稳定,因此架构也是如此。
-
开发团队基于跨职能、自治和组织方式交付业务价值,而非技术特性。
-
服务松耦合且内聚
识别业务能力,因此识别服务需要对业务有深入了解。通过分析组织的目标、业务流程、结构和专长领域,识别组织的业务能力和服务。
组织结构可以基于领域驱动设计(DDD)的子域或业务能力组。DDD 与应用程序的问题空间相关,作为领域标准;例如,按地区、领域、位置等基础组织的业务组。
一个域由多个子域组成。业务的不同部分对应子域,如:
-
核心子域:关键的业务差异化,是应用程序中最重要的部分
-
支持:不是关键的业务差异化,可以内部实现或外包
-
通用:非业务特定,使用现成软件实现
在线商店应用程序的子域可以如下:
-
产品目录
-
库存管理
-
订单管理
-
交付管理
相应的微服务架构将有与以下子域对应的服务:
微服务部署模式
服务的指导原则如下:
-
可以为服务使用各种语言、框架和框架版本
-
每个服务有多个服务实例,以提高吞吐量和可用性
-
独立部署和可扩展的服务
-
服务实例之间相互隔离
-
更快的构建和部署能力
-
服务消耗的资源(CPU 和内存)应该受到限制
-
每个服务实例应该对监控行为透明
-
服务的可靠且具成本效益的部署
-
应用程序度量和健康检查 API
-
审计日志和合规性
-
分布式追踪和管理
-
异常跟踪和管理
-
日志聚合、日志部署和变化
-
服务组件测试和服务集成契约测试
-
UI 组成(服务器端页面片段,客户端 UI)
-
安全性——基于 JSON Web Token 的访问令牌,安全地识别请求方到各个服务
分布模式
-
每个主机的多个服务实例,如在物理或虚拟主机机器上运行的不同服务的多个实例
-
在共享主机上部署服务实例
-
将每个服务实例部署为一个 JVM 进程,每个服务实例对应一个进程
-
在同一 JVM 中部署多个服务实例
-
避免资源要求或依赖版本冲突
-
每个虚拟机的服务实例
-
服务实例与每个容器关联
-
服务器无关的部署选项如下:
-
AWS Lambda
-
Google Cloud Functions
-
Azure Functions
-
微服务底盘
-
外部化配置,用于凭证管理和外部服务(如数据库和消息代理)的网络位置
-
日志记录:使用如 log4j 或 logback 等日志框架
-
健康检查:通过基于 URL 的监控服务确定应用程序的健康状况
-
度量:应用性能的测量和洞察
-
分布式追踪:通过带有仪器代码的服务追踪服务之间的唯一标识符
例如:
-
Java:
-
Spring Boot 和 Spring Cloud
-
Dropwizard
-
-
Go:
-
小工具
-
微服务
-
Go kit
-
通信模式
微服务中使用的各种通信类型如下:
-
远程过程调用(Remote Procedure Invocation),用于服务间通信,客户端请求通过以下服务进行列出:
-
REST
-
gRPC
-
Apache Thrift
-
-
通过以下通道以异步模式传递来自客户端的消息请求:
-
Apache Kafka
-
RabbitMQ
-
-
特定领域协议:
-
用于电子邮件的协议,如 SMTP 和 IMAP
-
用于媒体流传输的协议,如 RTMP、HLS 和 HDS
-
数据管理选项
用于微服务的数据管理过程的各种模式列举如下:
-
每个服务使用单独数据库确保服务松耦合,每个服务可以选择最适合的数据库类型。
-
共享数据库有助于开发人员使用 ACID 事务来确保数据一致性,开发者对此非常熟悉且直观。
-
事件溯源将业务实体的状态持久化为一系列更改状态的事件。当业务实体的状态发生变化时,一个新事件会附加到事件列表中。
-
事务日志尾随。
-
数据库触发器将事件插入到 EVENTS 表中,供一个单独的进程轮询并发布这些事件。
-
应用事件。
API 接口
微服务中使用的不同 API 如下:
-
桌面和移动浏览器的用户界面基于 HTML5/JavaScript
-
服务器端 web 应用程序生成 HTML
-
原生 Android 和 iPhone 客户端通过 REST API 与服务器交互
-
通过 REST API 在线暴露细节的第三方应用程序
应用程序编程接口(API)网关协议的使用
下图展示了后端为前端 API 的使用:
服务发现
微服务应用程序的设计是,服务的实例数量及其位置会动态变化,在虚拟化容器环境中运行,因此与服务发现相关的典型问题在这里展示:
客户端发现通过特定位置(主机和端口)暴露远程 API,如 HTTP/REST 或 Thrift,每个服务实例都有一个位置:
服务器端发现通过路由器(即负载均衡器)向服务发出请求,路由器运行在一个已知位置(如服务注册中心),该路由器查询并将请求转发到可用的服务实例:
总结
本章涵盖了不同供应商提供的容器和版本相关话题,
虚拟化方法、容器编排、物联网以及微服务应用程序和架构。