精华内容
下载资源
问答
  • 一个神奇的大学科目《软件工程》,知识点总结+测试题,包你不挂科
    万次阅读 多人点赞
    2021-04-13 12:37:49

    谁能告诉我这科的理论在哪可以实用呀?搞不懂,只能收藏一下包不挂科

    知识点总结

    第一章:

    软件工程定义

    1968年10月,Fritz Bauer 首次提出了“软件工程”的概念,并将“软件工程”定义为:为了经济地获得能够在实际机器上有效运行的可靠软件,而建立并使用的一系列工程化原则。

    1993年IEEE对软件工程的定义:软件工程是将系统化的、规范化的、可度量的途径应用于软件的开发、运行和维护的过程,即将工程化应用于软件的方法的研究。

    软件工程原则:

    抽象与自顶向下,逐层细化  信息隐蔽和数据封装 模块化 局部化 确定性 一致性和标准化 完备性和可验证性

    瀑布模型:

    开发活动的特征:(1)以上一项活动方产生的工作对象为输入(2)利用这一输入,实施本项活动应完成的内容(3)给出该项活动的工作结果,作为输出传给下一项活动(4)对实施该项活动的工作结果进行评审,若其工作得到确认,则继续进行下一项活动,否则返回前项,甚至更前项的活动进行返工

    瀑布模型的优点:

    (1)可强迫开发人员采用规范化的方法

    (2)严格地规定了每个阶段必须提交的文档

    瀑布模型的缺点

    (1)由于瀑布模型几乎完全依赖于书面的规格说明,很可能导致最终开发出的软件产品不能真正满足用户的需要。如果需求规格说明与用户需求之间有差异,就会发生这种情况(2)瀑布模型只适用于项目开始时需求已确定的情况。总地来说,瀑布模型是一种应付需求变化能力较弱的开发模型,因此,很多在该模型基础上开发出来的软件产品不能够真正满足用户需求

    第二章:

    可行性研究的过程:

    1. 复查系统规模和目标

    复查系统定义,改正含糊或不确切的叙述,清晰地描述对目标系统的一切限制和约束

    1. 研究目前正在使用的系统

    现有的系统是信息的重要来源。若一个软件是对旧系统的改造,那开发新系统时,要充分了解老系统存在的问题,需要增加的功能,新系统实际上是老系统的部分功能加上一些新增功能形成的系统

    1. 导出新系统的高层逻辑模型
    2. 重新定义问题

    新系统的逻辑模型实质上表达了分析员对系统必须做什么的看法,得到新系统的高层逻辑模型之后,可能会发现前面问题定义的范畴过大,分析员还要和用户一起再复查问题定义,对问题进行重新定义和修正。

    1. 导出和评价供选择的解法

    分析员应该从系统逻辑模型出发,研究问题的几个组成部分,细化各功能点,导出若干个较高层次的物理解法供比较和选择

    1. 推荐行动方针
    2. 草拟开发计划

    任务分解 进度规划 财务预算 风险分析及对策

    1. 书写文档提交复查

    第三章:

    一.软件需求的定义:

    以清晰、简单、一致且无二义性的方式,描述用户对目标软件系统在功能、行为、性能、设计约束等方面的期望,是在开发过程中对软件系统的约束。

    二.需求分析的任务

    1. 业务需求:是客户对于软件系统的高层次目标要求,定义了项目的远景和范围
    2. 用户需求:从用户角度描述软件系统的功能需求与非功能需求,通常只涉及系统的外部行为。
    3. 功能需求:功能需求描述软件系统应该提供的功能或务,通常涉及用户或其他外部系统与目标系统之间的交互,不考虑目标系统内部的实现细节
    4. 非功能需求:非功能需求即性能需求,反映了客户对软件系统质量和性能的额外要求
    5. 约束条件: 约束条件是软件系统设计和实现时必须满足的限制条件
    6. 业务规则: 业务规则是对某些功能的可执行性成内部执行速制的一些限定条件
    7. 外部接口需求:    外部接口需求是描述目标系统与外部环境之间的交互接口
    8. 数据定义:当用户描达一个数据项或一个复杂的业务数据结构的格式或缺省值时,正在进行数据定义

    第四章:

    启发规则

    启发规则是软件结构设计优化准则,软件概要设计的任务就是软件结构的设计,为了提高设计的质量,必须根据软件设计原理设计软件,利用启发规则优化软件结构。

    1.改进软件结构提高模块独立性2.模块规模适中3.适当控制深度、宽度、扇出、扇入

    4.模块的作用域应该在控制域之内5.力争降低模块接口的复杂程度

    6.设计单入口单出口的模块7.模块功能可预测

    第五章:

    详细设计的过程

    软作详细设计是软件工程的重要阶段,在详细设计过程中,细化了高层的体系结构设计,将软件结构中的主要部件划分为能独立编码、编译和测试的软件单元,并进行软件单元的设计,同时确定了软件单元和单元之间的外部接口。

    一.详细设计的基本任务

    1. 算法设计:用某种图形、表格、语言等工具将每个模块处理过程的详细算法描述出来
    2. 数据结构设计:对于需求分析,概要设计确定的概念性的数据类型进行确切的定义
    3. 物理设计: 对数据库进行物理设计,即确定数据库的物理结构
    4. 其他设计

    a.代码设计:为了提高数据的输入、分类、存储及检索等操作的效率,对数据库中的某些数据项的值要进行代码设计b.输入/输出格式设计c.人机对话设计

    1. 编写详细设计说明书  6 . 评审:对处理过程的算法和数据库的物理结构要进行评审

    .详细设计方法:

    1. 自顶向下,逐步求精  2.具有单入、单出的控制结构 3. 五种控制结构:顺序结构,选择,先判断型循环结构,后断型循环结构,多选择分支结构

    第七章:

    一.测试用例设计:

    白盒测试是对软件的过程细节做细致的检查。这一方法把测试对象看作 个打开的盒子,允许测试人员利用程序内部的逻辑结构及有关信息设计或选择测试用例,对程序所有逻辑路径进行测试。通过在不同点检查程序的状态,确定实际的状态是否与期望的状态一致。

    覆盖标准

    1. 语句覆盖

    含义:就是选择足够多的测试用例,运行被测程序,使得程序中每条语句至少执行一次。

    1. 判定覆盖

    含义:又称为分支覆盖,在设计测试用例,针对程序中具有分支结构的部分,为了测试所有的可能结果,需要将每个分支都至少执行一次,查看相应的语句执行情况和结果

    (1)a=2,b=0,x=4,覆盖RACBDE

    (2)a=3,b=1,x=1覆盖 RABE

    1. 条件覆盖

    条件覆盖是指设计测试用例时,除了保证每条语句执行一次,还要使判定表达式的每个条件的各种可能取值都至少执行一次,为了实现条件覆盖,保证各种可能的条件都取值,即保证

    第一个判断有以下取值:a>1,a<=1,b=0,b≠0

    第二个判断有以下取值:a=2,a≠2,x>1,x<=1

    选择两组测试用例:

    (1)a=2,b=2,x=2(满足a>1,b≠0,a=2,x>1的条件),执行路径为 RABDE

    (2)a=1,b=0,x=0(满足a<=1,b=0,a≠2,x<=1的条件),执行路径为RABE

    1. 判定/条件覆盖

    单独使用判定覆盖和条件覆盖测试结果都不够全面, 若将两种覆盖结合,就会相互补充,判定/条件覆盖就是设计足够多的测试用例,使得每个判定表达式中的每个条件都取到各种可能的值,并且使每个判断语句的所有判断结果至少出现一次。

    (1)a=2,b=0,x=2(满足a>1,b=0,a=2,x>1的条件),执行路径RACBDE

    (2)a=1,b=1,x=1(满足a<=1,b≠0,a≠2,x<=1的条件),执行路径RABE

    1. 条件组合覆盖

    条件组合覆盖就是设计足够多的测试用例,使得每个判定表达式中条件取值的各种组合都至少出现一次。根据每个判定表达式情况,列出如下条件组合

    (1)a>1,b=0,A表达式为真;(2)a>1,b≠0,A表达式为假;(3)a<=1,b=0,A表达式为假

    (4)a<=1,b≠0,A表达式为假;(5)a=2,x>1,B表达式为真(6)a=2,x<=1,B表达式为真;

    (7)a≠2,x>1,B表达式为真;(8)a≠2,x<=1,B表达式为假。

    选择以下四组测试用例

    选择条件a=2,b=0,x=2,(1)、(5)组合,执行路径 RACBDE

    选择条件a=2,b=1,x=1,(2)、(6)组合,执行路径 RABDE

    选择条件a=1,b=0,x=2,(3)、(7)组合,执行路径 RABDE

    选择条件a=1,b=1,x=1,(4)、(8)组合,执行路径 RABE

    1. 路径覆盖

    就是选取足够多的用例,保证程序的所有路径都至少执行一次,如果存在环形结构,也要保证此环的所有路径都至少执行一次。

    (1)a=1,b=1,x=1(满足a<=1,b≠0,a≠2,x<=1的条件),执行路径为RABE

    (2)a=2,b=0,x=2(满足a>1,b=0,a=2,x>1的条件),执行路径为 RACBDE

    (3)a=2,b=1,x=2(满足a>1,b≠0,a=2,x>1的条件),执行路径为 RABDE;

    (4)a=3,b=0,x=1(满足a>1,b=0,a≠2,x<=1的条件),执行路径为 RACBE

    二.测试的步骤:

    1. 单元测试

    a.单元测试的主要任务

    单元测试针对每个模块,主要解决五个方面的问题:(1)模块接口(2)局部数据结构(3)路径测试 (4)过界条件 (5)出错处理

    b.单元测试的执行过程

    1. 集成测试

    a.非增式集成测试方法 b. 增式集成测试方法

    1. 确认测试

    确认测试的标准  配置审查的内容  Alpha Beta 测试  

    1. 系统测试

    方法:恢复测试方法   安全测试方法  强度  性能

    第八章:

    一.软件维护的概念

    软件维护是指在软件运行或维护阶段对软件产品所进行的修改,这些修改可能是改

    正软件中的错误,也可能是增加新的功能以适应新的需求,但是一般不包括软件系统结

    构上的重大改变。根据软件维护的不同原因,软件维护可以分成四种类型

    (1)改正性维护

    在软件交付使用后,由于开发时测试得不彻底或不完全,在运行阶段会暴露一些开

    发时未能测试出来的错误,为了识别和纠正软件错误,改正软件性能上的缺陷,避免实

    施中的错误使用,应当进行的诊断和改正错误的过程,这就是改正性维护

    (2)适应性维护

    随着计算机技术的飞速发展和更新换代,软件系统所需的外部环境或数据环境可能

    会更新和升级,如操作系统或数据库系统的更换等。为了使软件系统适应这种变化,需

    要对软件进行相应的修改,这种维护活动称为适应性维护

    (3)完善性维护

    在软件的使用过程中,用户往往会对软件提出新的功能与性能要求,为了满足这些

    要求,需要修改或再开发软件,以扩充软件功能、增强软件性能、改进加工效率、提高软件

    的可维护性,这种情况下进行的维护活动叫作完善性维护,完善性维护不一定是救火

    式的紧急维修,而可以是有计划的一种再开发活动

    4)预防性地护

    这类维护是为了提高软件的可维护性,可靠性等,为以后进一步改进软件打下良好

    的基础的维护活动,具体来讲,就是采用先进的软件工程方法对需要维护的软件或软件中的某一部分重新设计、编码和测试的活动。

    二.软件维护的特点

    1.软件维护受开发过程影响大

    2.软件维护困难多

    3.软件维护成本高

    三.软件维护的步骤

    软件维护工作包括建立维护组织、报告与评估维护申请、实施维护流程等步骤。

    在影响分析和版本规划的过程中,不同的维护类型需要采用不同的维护策略

    (1)改正性维护:首先应该评价软件错误的严重程度,对于十分严重的错误,维护

    员应该立即实施维护对于一般性的错误,维护人员可以将有关的维护工作与其他开发

    任务一起进行现划。在有些情况下,有的错误非常严重,以致不得不临时放弃正常的维

    护控制工作程序,既不对修改可能带来的副作用作出评价,也不对文档作相应的更新,而

    是立即进行代码的修改。这是一种救火式的改正性维护,只有在非常紧急的情况下才使

    用,这种维护在全部维护中只占很小的比例。应当说明的是,救火式不是取消,只是推迟

    了维护所需要的控制和评价。一旦危机取消,这些控制和评价活动必须进行,以确保当

    前的修改不会增加更为重要的问题

    (2)适应性维护:首先确定软件维护的优先顺序,再与其他开发任务一起进行规划

    (3)定善性维护,根据商业的需求和软件的发展,有些完善性维护可能不会被接受。对于被接受的维护中请,应该确定其优先次序井现划其开发工作

    第九章

    质量保证

    产品的生命,不论生产何种产品,质量都是极端重要的。软件产品开发周期长,耗费巨大的人力和物力,更必须特别注意保证质量。

    软件质量:概括地说,软件质量就是“软件与明确地和隐含地定义的需求相一致的程度”。更具体地说,软件质量是软件与明确地叙述的功能和性能需求、文档中明确描述的开发标准以及任何专业开发的软件产品都应该具有的隐含特征相一致的程度。

    软件质量因素的定义:

    正确性:系统满足规格说明和用户目标的程度,即,在预定环境下能正确地完成预期功能的程度

    建壮性:在硬件发生故障、输人的数据无效或操作错误等意外环境下,系统能做出适当响应的程度

    完整性(安全性):对未经授权的人使用软件或数据的企图,系统能够控制(禁止)的程度

    效率:为了完成预定的功能,系统需要的计算资源的多少

    可用性:系统在完成预定应该完成的功能时令人满意的程度

    风险:按预定的成本和进度把系统开发出来,并且为用户所满意的概率

    可理解性:理解和使用该系统的容易程度

    可维修性:诊断和改正在运行现场发现的错误所需要的工作量的大小

    灵活性(适应性):修改或改进正在运行的系统需要的工作量的多少

    可测试性:软件容易测试的程度

    可移植性:把程序从一种硬件配置和(或)软件系统环境转移到另一种配置和环境时,需要的工作量多少,有一种定量度量的方法是:用原来程序设计和调试的成本除移植时需用的费用

    可再用性:在其他应用中该程序可以被再次使用的程度(或范围)

    互运行性:把该系统和另一个系统结合起来需要的工作量的多少

    软件质量保证的措施主要有:基于非执行的测试(也称为复审或评审),基于执行的测试(即以前讲过的软件测试)和程序正确性证明。

    复审主要用来保证在编码之前各阶段产生的文档的质量;基于执行的测试需要在程序编写出来之后进行,它是保证软件质量的最后一道防线;程序正确性证明使用数学方法严格验证程序是否与对它的说明完全一致

    技术复审的必要性:

    正式技术复审的显著优点是,能够较早发现软件错误,从而可防止错误被传播到软件过程的后续阶段。

    正式技术复审是软件质量保证措施的一种,包括走查和审查等具体方法。走查的步骤比审查少,而且没有审查正规。

    走查主要有下述两种方式。

    (1) 参与者驱动法。参与者按照事先准备好的列表,提出他们不理解的术语和认为不正确的术语。文档编写组的代表必须回答每个质疑,要么承认确实有错误,要么对质疑做出解释。

    (2) 文档驱动法。文档编写者向走查组成员仔细解释文档。走查组成员在此过程中不时针对事先准备好的问题或解释过程中发现的问题提出质疑。这种方法可能比第一种方法更有效,往往能检测出更多错误。经验表明,使用文档驱动法时许多错误是由文档讲解者自己发现的。

    审查步骤:

    (1) 综述。由负责编写文档的一名成员向审查组综述该文档。在综述会结束时把文档分发给每位与会者。

    (2) 准备。评审员仔细阅读文档。最好列出在审查中发现的错误的类型,并按发生频率把错误类型分级,以辅助审查工作。这些列表有助于评审员们把注意力集中到最常发生错误的区域。

    (3) 审查。评审组仔细走查整个文档。和走查一样,这一步的目的也是发现文档中的错误,而不是改正它们。通常每次审查会不超过90分钟。审查组组长应该在一天之内写出一份关于审查的报告。

    (4) 返工。文档的作者负责解决在审查报告中列出的所有错误及问题。

    (5) 跟踪。组长必须确保所提出的每个问题都得到了圆满的解决(要么修正了文档,要么澄清了被误认为是错误的条目)。必须仔细检查对文档所做的每个修正,以确保没有引入新的错误。如果在审查过程中返工量超过5%,则应该由审查组再对文档全面地审查一遍。

    程序正确性证明:

    测试可以暴露程序中的错误,因此是保证软件可靠性的重要手段;但是,测试只能证明程序中有错误,并不能证明程序中没有错误。因此,对于保证软件可靠性来说,测试是一种不完善的技术,人们自然希望研究出完善的正确性证明技术。

     

     

    软件工程一测

     

    1. 软件工程三要素:______________、_________________、_________________
    2. 获取愿景的三部曲:
    3. 愿景_______(是/否)功能。
    4. 愿景必须指出__________
    5. 迭代与增量的定义
    6. UML静态图包括(4个)
    7. UML动态图包括(5个)
    8. 为什么使用UML语言
    9. ______________是软件成功的基础。

     

     

    答案:

    1. 工具(系统)、方法(技能)、开发过程(框架)
    2. 第一步:找到软件项目的“老大”;第二步:得到“老大”对项目的期望(愿景);第三步:描述出愿景的度量指标。
    3. 度量指标
    4. 迭代是反复求精,增量是逐块建造
    5. 类图、对象图、组件图、部署图
    6. 时序图、协作图、状态图、活动图、用例图
    7. 主要用于交流,有利于清晰,有利于精确
    8. 需求

     

     

    软件工程二测

     

    1. 在项目失败的因素中,与      相关的比例最高。
    2.       是解决需求噩梦的手段。
    3. 简要分析项目开发过程中,公司老板、中层经理、一线员工的需求分别有什么特点。
    4. ICONIX过程从把需求文档变成可运作的代码过程只需四步,需要使用哪四张UML图?
    5. 若某公司设有公司老总、市场总监与财务总监,实现强化客户管理功能、提升财务效率功能、优化公司资源功能的三种软件,“老大”分别是谁?

     

    答案:

    1.需求

    2.需求工程

    3.公司老板:企业战略、开源节流(定于愿景)

      中层经理:简化管理、优化流程(业务建模)

      一线员工:工作简单(用例分析)

    4.用例图、序列图、类图、健壮性图

    5.强化客户管理:市场总监

      提升财务效率:财务总监

      优化公司资源:公司老总

     

     

     

    软件过程三测

     

    1. 业务建模序列图阶段要注意什么?
    2. 业务序列图中,alt表示(           ),loop表示(              ),opt表示(         );
    3. Alt和opt在使用的时候有什么区别?
    4. 业务序列图中,消息的名字表示什么?
    5. 业务序列图中,消息的方向表示什么?
    6. 把(        )看作特殊的业务实体。
    7. 业务建模结果复核目的有两点,分别是什么?

     

     

     

     

    答案:

    1. 本阶段不要考虑要实现什么系统
    2. 分支,循环,可选分支
    3. Alt表示分支,是需要条件的;opt表示可选分支,没有条件,有选择性。
    4. 代表责任和目的
    5. 责任委托,不是数据流动
    6. 时间
    7. 一是完善业务建模成果,寻找是否有遗漏或错误的地方进行修正,如果问题明显,就需要迭代回去继续做业务建模工作;

    二是关键干系人在信息和意见上达成一致,并共同签字确认,作为下一阶段启动的标志。

     

     

     

     

     

     

    软件工程四测

     

    1. 业务建模要求我们把视角从_______,以达到清晰准确地“诊断”,对症“开方”

    答案:软件系统转向客户组织,站在客户角度看问题

    2、业务建模三步骤:

    1、___________2、____________3、____________

    答案:

    1. 明确我们为谁服务(选定愿景要改进的组织)。
    2. 要改进的组织是什么现状(业务用例图、现状业务序列图)。
    3. 我们如何改进(改进业务序列图)。

    3、了解组织现状:

       (1)从外部看:组织是____的集合,用业务用例图来建模

       (2)从内部看:组织是____的集合

    答案:价值、系统

    4、业务用例图帮助我们从______了解组织的______。

    答案:高层次 、业务构成

    5、业务执行者是在业务组织之外,与其交互,享受其价值的_______

    答案:人或组织

    6、业务用例是业务组织为业务执行者提供的______.

    答案:价值

    7、业务序列图帮助我们从______了解组织的______。

    答案:细节上、 业务流程

    8、业务序列图详细描述________、_______、________之间如何交互,以完成某个业务用例的实现流程

    答案:业务执行者、业务工人、业务实体

    9、举个简单的例子并识别其中的业务对象:业务执行者、业务工人、业务实体

    答案:自由发挥

    10、我们如何改进(改进业务序列图)

    答案:了解业务组织现状的目的——发现流程中的改进点:

    • 信息自动流转
    • 封装复杂业务逻辑
    • 职责转移
    • 访问和操作业务对象

    其他……

     

    软件过程五测

    1. 域建模_____不等于_____(等于或不等于)数据模型
    2. ___用例分析________前做域建模
    3. 需求分析的主流分析方法有___原型法____、______用例法_______
    4. 绘制系统用例图的步骤

    1. 确定系统边界

    2. 识别系统执行者

    3. 识别系统用例

    4. 确定用例间的关系

    1. 怎样区别主执行者和辅执行者

      主执行者:

    1.用例发起者;

    2.用例为其实现有价值的目标;

    辅执行者:

    1.用例支持者;

    2.用例的完成需要与其交互,得到其支持

    1. 如何找到执行者

      谁使用该系统?

    • 谁改变系统的数据?

    • 谁从系统获取信息?

    • 谁负责维护、管理并保持系统正常运行?

    • 系统需要应付哪些硬件设备?

    • 系统需要和那些外部系统交互?

    • 谁对系统运行产生的结果感兴趣?

    • 有没有自动发生的事件?

    1. 系统用例是执行者通过系统____达到某个目标______
    2. 用例的关系____泛化____、_____包含_______、______扩展__________
    3. 先发现执行者还是先发现用例?为什么?

       执行者比用例明显。

    • 执行者的个数远比用例的个数少。

    • 找到一个执行者,就可以找到一堆用例。

    • 执行者是系统外部人物的代表,所以当然是要先找到执行者,才能够从执行者的角度去寻找用例。

    1. 用例命名的三个条件是什么?

     用例名称必须是动宾短语。

    • 采用域建模中的名词术语。

    • 慎用弱动词弱名词——会掩盖真正的业务

    1. 用例_____不等于______功能,用例____不等于______步骤

     

    软件过程六测

    1. 每个用例必须对应有___愿景目标______
    2. 用例描述的基本组成__干系人利益_____________、_____基本路径____________、________扩展路径_______、_______业务规则_______________
    3. _________用例_______是干系人利益的平衡点。
    4. 基本路径的书写要求。

      以主动语态、“名词-动词-名词”格式来书写。

      主语只能是执行者或系统。

    1. 基本路径与扩展路径是否要分开。

      要

     

    更多相关内容
  • 复杂业务系统的架构设计思路

    千次阅读 2020-12-13 12:53:55
    明确了这几个问题,可以处理部分日常需求开发,如果是比较复杂的业务系统,就需要拆解的更精细。 比如电商的商品管理、订单交易等系统的开发和重构,业务相对复杂,开发人天在几个月以上,直接开发可能会老虎啃天...

    最近有一些系统设计方面的思考和体会,在这里梳理一下。

     

    做技术方案,核心是下面几个问题:

    • 做什么?- 产品需求

    • 业务上怎么做?- 业务文档

    • 技术上怎么做?- 技术方案

    • 代码怎么实现?- 落地实现

    明确了这几个问题,可以处理大部分日常需求开发,如果是比较复杂的业务系统,就需要拆解的更精细。

    比如电商的商品管理、订单交易等系统的开发和重构,业务相对复杂,开发人天在几个月以上,直接开发可能会老虎啃天,无从下手。

     

    这时候可以通过一个流程化的模板来指导,如果抽象一个通用的流程,可以参考下面的套路:

    • 业务拆解 > 复杂度来源 > 核心挑战点 

    • 领域驱动设计 > 业务过程分析 > 领域模型抽象 > 模型分解

    • 分层组织 > 工程架构 > 模块化 > 组件化

    • 考虑功能复用 > 可选路径 —( 业务身份,能力,扩展点,工作流程,编排)

    • 方案产出 >  整体-模块-流程-细节 > 方案评审 > 最终方案

     

    其中的功能复用环节,是包括阿里在内的大部分业务中台的解决思路,仅供参考。

     

    一、业务拆解

    1.1 复杂度来源

    为什么要关注复杂度?

     

    我认同李运华老师的观点,架构设计的目的是为了解决软件系统的复杂度带来的问题,所以在设计架构时,首先就要分析系统的复杂度。

    只有正确分析出了系统的复杂性,后续的架构设计方案才不会偏离方向;否则,如果对系统的复杂性判断错误,即使后续的架构设计方案再完美再先进,都是南辕北辙,做的越好,错的越多、越离谱。

     

    举个例子,医院管理应用的医疗管理系统(HIS),复杂度在于业务逻辑复杂,系统之间调用不清晰,如果你设计一个QPS几万的高性能架构,就是没有解决系统的核心问题。

    正确的做法是将主要的复杂度问题列出来,然后根据业务、技术、团队等综合情况进行排序,优先解决当前面临的最主要的复杂度问题。

     

    1.2 核心挑战点

     

    射人先射马,擒贼先擒王。

     

    确定了复杂度,也就确定了系统设计的难点,在进行系统设计时,可以把难点列出来,各个击破。 

    以电商促销为例,促销活动最大的复杂度来自营销形态的变化,营销最大的不变就是变,乱花渐欲迷人眼,各类促销方式千变万化。

    每次促销活动都有不同的玩法和定义,促销系统的设计必须对促销模式有所抽象,任何活动或优惠手段都是基于最基本的促销模式而建立的。

    电商营销中心建设难点包括:

    • 底层模型抽象:底层模型抽象可以通过DDD的方式,对领域模型和进行抽象。

    • 促销引擎性能:性能问题如何解决?已经是老生常谈,工程领域有很多经典的解决方案,比如缓存,异步,最终一致性。

    • 关联系统交互:理清和关联系统的交互

     

    二、领域驱动设计

    软件系统的目的反映在业务上,都是来解决一系列问题,例如考试系统完成考试,电商就是卖货,同一个领域的系统都具有相同的核心业务,因为他们要解决的问题的本质是类似的,一个领域本质上可以理解为一个问题域 。

     

    只要确定了系统所属的领域,那么这个系统的核心业务,即要解决的关键问题就基本确定了。

     

    任何一个系统都会属于某个特定的领域,例如论坛系统,核心功能是确定的,比如用户发帖,回帖等基本功能。广义的电商系统也是一个领域,做电商业务,必须要支持的商品,订单,交易,物流等功能。

     

    DDD里有领域专家的概念,领域专家要在这个领域深入研究,只有这样才会遇到非常多的该领域的问题,积累比较更加丰富的经验。

    通常来说,一个领域有且只有一个核心问题,也就是核心子域。在核心子域、通用子域、支撑子域梳理的同时,会定义出子域中的限界上下文及其关系,用它来阐述子域之间的关系 。

     

    以电商营销为例,优惠券、抽奖、套餐等,都是围绕这个促销这个业务范围来进行的,在促销域之外,还有相关的用户、商品、订单、风控、商家等。

     

    图片

     

     

    三、架构分层

    3.1 架构分层

    下图是领域驱动设计中经典的分层架构:

     

    图片

     

    用户界面/展示层:

    • 请求应用层获取用户所需的展示数据;

    • 发送命令给应用层执行用户的命令

    应用层:薄薄的一层,定义软件要完成的任务。对外为展示层提供各种应用功能,对内调用领域层(领域对象或领域服务)完成各种业务逻辑。应用层不包含业务逻辑

     

    领域层:表达业务概念、业务状态信息及业务规则,是业务软件的核心

     

    基础设施层:为其他层提供通用的技术能力,提供了层间通信;为领域层提供持久化机制。

     

    这是一个相对简单的分层架构,其实已经老生常谈,那么问题来了,我们在上面拆解的领域模型,如何映射到工程架构中?

      

    3.2 工程架构

    DDD的核心诉求就是将业务架构映射到系统架构上,在响应业务变化调整业务架构时,也随之变化系统架构。 

    微服务追求业务层面的复用,设计出来的系统架构和业务一致,不过领域模型并不直接反映数据结构,需要明确这一点。

     

    领域驱动设计最后落地到数据存储上,不需要直接参考领域模型,在最后的技术架构上可以自由选择合适的技术架构。

     

     

     

    图片

     

    3.3 模块组织

    Java项目一般是典型的Maven多模块项目,可以使用不同的Module,区分各个层次,进一步,通过Package来控制DDD中的限界上下文。

     

    四、考虑功能复用

    4.1 编程DRY原则

    大家都知道,编写整洁代码,有一个非常重要的原则就是DRY,Don't Repeat Yourself,避免产生重复代码,有经验的程序员都能够意识到这一条约束。

    如果你使用Idea开发,Idea也会识别并且提示你重复的代码,建议你进行抽象。

    DRY的好处更少的代码是好的,它节省了时间和精力,易于维护,并且减少了bug的几率。

    除了在软件开发领域,在业务系统层面,也存在如何避免重复能力建设,考虑业务复用的问题。

     

    图片

     

     

    4.2 业务层面的DRY

    业务系统层面的DRY原则,其实可以总结为一个问题,就是复杂业务系统,如何实现具有共性的业务能力的复用,这个也是很多业务中台关注的问题。

    一般的,大部分业务中台(特指业务中台,不包括数据中台等其他形态)对业务复用的方式,

    都可以通过定义业务身份 ——>  梳理扩展点 ——> 枚举业务能力 ——> 根据不同业务身份编排工作流 ——> 实现业务能力复用,这样的流程来实现。

    可以对比编程中的Pipeline模式,或者责任链模式,只不过每个链条上负责处理输入和输出的,是不同的业务功能。

    业务中台是另一个话题,这部分是发散思考,具体可以参考阿里巴巴 TMF (Trade Mudule Framework)框架的介绍:

    如何实现32.5万笔/秒的交易峰值?阿里交易系统TMF2.0技术揭秘

     

    五、可扩展性和过度设计如何平衡

    好的架构设计一定是扩展简单的。在设计时,要尽量封装可能的变化,在业务流程发生一些调整时,能够比较方便地修改系统程序模块或组件间的调用关系而实现新的需求,也就是我们常说的可扩展性。

    但是可扩展性本身也是系统设计的复杂度来源之一,这就涉及到一个问题,如何平衡可扩展和过度设计。

     

    5.1 区分确定性和变化

    好的架构一定是扩展简单,运行平稳的。

    系统架构最开始可以从一个通用的流程开始,case-by-case,然后将「变化少」的部分沉淀下来为架构,将「变化多」的沉淀为扩展或者配置,梳理清楚,将这两者结合起来,最后完成系统架构设计。

     

    5.2 用容量规划的方式来处理扩展程度

    可以使用容量规划的思想,来处理可扩展性设计。

    在做技术方案时,容量规划是一个特别重要的环节,要预估未来几年的增长量,进行数据库和缓存的容量规划。

    我觉得这个方式也可以应用在扩展性设计上,对业务变化进行预期,考虑技术方案能够支持的业务发展时间。

     

    六、方案评审

    好的技术方案很难一蹴而就,大部分时候要经过反复的调整,就是需要关联的各方参与方案的评审和修改,最终确定最终技术方案。

     

    七、总结

    最后再总结一下,关于复杂业务系统开发的一些体会:

    1. 熟悉业务,抽象产品需求,分析相关测试用例,了解各种用户角色和其使用的场景

    2. 自顶向下进行方案设计,对于比较复杂的业务系统,比较好的方式是先关注顶层模型,避免在一开始就陷入技术和业务细节中去

    3. 从整体设计,到模块局部规划,设计好部署架构、分层和分模块、API设计、数据库设计等

    4. 可以参考成熟的解决方案,比如将开源软件,改造,变成适合自己业务需求的架构

    5. 验证和优化架构设计方案,完整的架构设计方案,需要有多次的评审,充分收集各方面的反馈,反复修改后确定

    6. 合理进行扩展,考虑架构预期能满足多长时间的业务增长,比如未来一年的业务变化

     

    展开全文
  • 这可能最全的操作系统面试题

    万次阅读 多人点赞 2021-04-13 09:30:37
    文章目录操作系统简介篇解释一下什么是操作系统操作系统的主要功能软件访问硬件的几种方式解释一下操作系统的主要目的是什么操作系统的种类有哪些为什么 Linux 系统下的应用程序不能直接在 Windows 下运行操作系统...

    文章目录


    大家好,我是 cxuan,我之前汇总了一下关于操作系统的面试题,最近又重新翻阅了一下发现不是很全,现在也到了面试季了,所以我又花了一周的时间修订整理了一下这份面试题,这份面试题可以吊打市面上所有的操作系统面试题了,不是我说,是因为我系统查过,如果有不相信的大佬,欢迎狠狠的打我脸。

    欢迎各位大佬访问我的 github ,跪求 star
    成为最好的 Java 程序员

    这份面试题有 43 道题,囊括了校招面试和社招面试,看完这一篇文章,保准你能和面试官侃侃而谈,增加进入大厂的几率!

    话不多说,下面我们直接进入面试题。

    操作系统简介篇

    解释一下什么是操作系统

    操作系统是管理硬件和软件的一种应用程序。操作系统是运行在计算机上最重要的一种软件,它管理计算机的资源和进程以及所有的硬件和软件。它为计算机硬件和软件提供了一种中间层,使应用软件和硬件进行分离,让我们无需关注硬件的实现,把关注点更多放在软件应用上。

    通常情况下,计算机上会运行着许多应用程序,它们都需要对内存和 CPU 进行交互,操作系统的目的就是为了保证这些访问和交互能够准确无误的进行。

    操作系统的主要功能

    一般来说,现代操作系统主要提供下面几种功能

    • 进程管理: 进程管理的主要作用就是任务调度,在单核处理器下,操作系统会为每个进程分配一个任务,进程管理的工作十分简单;而在多核处理器下,操作系统除了要为进程分配任务外,还要解决处理器的调度、分配和回收等问题
    • 内存管理:内存管理主要是操作系统负责管理内存的分配、回收,在进程需要时分配内存以及在进程完成时回收内存,协调内存资源,通过合理的页面置换算法进行页面的换入换出
    • 设备管理:根据确定的设备分配原则对设备进行分配,使设备与主机能够并行工作,为用户提供良好的设备使用界面。
    • 文件管理:有效地管理文件的存储空间,合理地组织和管理文件系统,为文件访问和文件保护提供更有效的方法及手段。
    • 提供用户接口:操作系统提供了访问应用程序和硬件的接口,使用户能够通过应用程序发起系统调用从而操纵硬件,实现想要的功能。

    软件访问硬件的几种方式

    软件访问硬件其实就是一种 IO 操作,软件访问硬件的方式,也就是 I/O 操作的方式有哪些。

    硬件在 I/O 上大致分为并行和串行,同时也对应串行接口和并行接口。

    随着计算机技术的发展,I/O 控制方式也在不断发展。选择和衡量 I/O 控制方式有如下三条原则

    (1) 数据传送速度足够快,能满足用户的需求但又不丢失数据;

    (2) 系统开销小,所需的处理控制程序少;

    (3) 能充分发挥硬件资源的能力,使 I/O 设备尽可能忙,而 CPU 等待时间尽可能少。

    根据以上控制原则,I/O 操作可以分为四类

    • 直接访问:直接访问由用户进程直接控制主存或 CPU 和外围设备之间的信息传送。直接程序控制方式又称为忙/等待方式。
    • 中断驱动:为了减少程序直接控制方式下 CPU 的等待时间以及提高系统的并行程度,系统引入了中断机制。中断机制引入后,外围设备仅当操作正常结束或异常结束时才向 CPU 发出中断请求。在 I/O 设备输入每个数据的过程中,由于无需 CPU 的干预,一定程度上实现了 CPU 与 I/O 设备的并行工作。

    上述两种方法的特点都是以 CPU 为中心,数据传送通过一段程序来实现,软件的传送手段限制了数据传送的速度。接下来介绍的这两种 I/O 控制方式采用硬件的方法来显示 I/O 的控制

    • DMA 直接内存访问:为了进一步减少 CPU 对 I/O 操作的干预,防止因并行操作设备过多使 CPU 来不及处理或因速度不匹配而造成的数据丢失现象,引入了 DMA 控制方式。
    • 通道控制方式:通道,独立于 CPU 的专门负责输入输出控制的处理机,它控制设备与内存直接进行数据交换。有自己的通道指令,这些指令由 CPU 启动,并在操作结束时向 CPU 发出中断信号。

    解释一下操作系统的主要目的是什么

    操作系统是一种软件,它的主要目的有三种

    • 管理计算机资源,这些资源包括 CPU、内存、磁盘驱动器、打印机等。
    • 提供一种图形界面,就像我们前面描述的那样,它提供了用户和计算机之间的桥梁。
    • 为其他软件提供服务,操作系统与软件进行交互,以便为其分配运行所需的任何必要资源。

    操作系统的种类有哪些

    操作系统通常预装在你购买计算机之前。大部分用户都会使用默认的操作系统,但是你也可以升级甚至更改操作系统。但是一般常见的操作系统只有三种:Windows、macOS 和 Linux

    为什么 Linux 系统下的应用程序不能直接在 Windows 下运行

    这是一个老生常谈的问题了,在这里给出具体的回答。

    其中一点是因为 Linux 系统和 Windows 系统的格式不同,格式就是协议,就是在固定位置有意义的数据。Linux 下的可执行程序文件格式是 elf,可以使用 readelf 命令查看 elf 文件头。

    而 Windows 下的可执行程序是 PE 格式,它是一种可移植的可执行文件。

    还有一点是因为 Linux 系统和 Windows 系统的 API 不同,这个 API 指的就是操作系统的 API,Linux 中的 API 被称为系统调用,是通过 int 0x80 这个软中断实现的。而 Windows 中的 API 是放在动态链接库文件中的,也就是 Windows 开发人员所说的 DLL ,这是一个库,里面包含代码和数据。Linux 中的可执行程序获得系统资源的方法和 Windows 不一样,所以显然是不能在 Windows 中运行的。

    操作系统结构

    单体系统

    在大多数系统中,整个系统在内核态以单一程序的方式运行。整个操作系统是以程序集合来编写的,链接在一块形成一个大的二进制可执行程序,这种系统称为单体系统。

    在单体系统中构造实际目标程序时,会首先编译所有单个过程(或包含这些过程的文件),然后使用系统链接器将它们全部绑定到一个可执行文件中

    在单体系统中,对于每个系统调用都会有一个服务程序来保障和运行。需要一组实用程序来弥补服务程序需要的功能,例如从用户程序中获取数据。可将各种过程划分为一个三层模型

    除了在计算机初启动时所装载的核心操作系统外,许多操作系统还支持额外的扩展。比如 I/O 设备驱动和文件系统。这些部件可以按需装载。在 UNIX 中把它们叫做 共享库(shared library),在 Windows 中则被称为 动态链接库(Dynamic Link Library,DLL)。他们的扩展名为 .dll,在 C:\Windows\system32 目录下存在 1000 多个 DLL 文件,所以不要轻易删除 C 盘文件,否则可能就炸了哦。

    分层系统

    分层系统使用层来分隔不同的功能单元。每一层只与该层的上层和下层通信。每一层都使用下面的层来执行其功能。层之间的通信通过预定义的固定接口通信。

    微内核

    为了实现高可靠性,将操作系统划分成小的、层级之间能够更好定义的模块是很有必要的,只有一个模块 — 微内核 — 运行在内核态,其余模块可以作为普通用户进程运行。由于把每个设备驱动和文件系统分别作为普通用户进程,这些模块中的错误虽然会使这些模块崩溃,但是不会使整个系统死机。

    MINIX 3 是微内核的代表作,它的具体结构如下

    在内核的外部,系统的构造有三层,它们都在用户态下运行,最底层是设备驱动器。由于它们都在用户态下运行,所以不能物理的访问 I/O 端口空间,也不能直接发出 I/O 命令。相反,为了能够对 I/O 设备编程,驱动器构建一个结构,指明哪个参数值写到哪个 I/O 端口,并声称一个内核调用,这样就完成了一次调用过程。

    客户-服务器模式

    微内核思想的策略是把进程划分为两类:服务器,每个服务器用来提供服务;客户端,使用这些服务。这个模式就是所谓的 客户-服务器模式。

    客户-服务器模式会有两种载体,一种情况是一台计算机既是客户又是服务器,在这种方式下,操作系统会有某种优化;但是普遍情况下是客户端和服务器在不同的机器上,它们通过局域网或广域网连接。

    客户通过发送消息与服务器通信,客户端并不需要知道这些消息是在本地机器上处理,还是通过网络被送到远程机器上处理。对于客户端而言,这两种情形是一样的:都是发送请求并得到回应。

    为什么称为陷入内核

    如果把软件结构进行分层说明的话,应该是这个样子的,最外层是应用程序,里面是操作系统内核。

    应用程序处于特权级 3,操作系统内核处于特权级 0 。如果用户程序想要访问操作系统资源时,会发起系统调用,陷入内核,这样 CPU 就进入了内核态,执行内核代码。至于为什么是陷入,我们看图,内核是一个凹陷的构造,有陷下去的感觉,所以称为陷入。

    什么是用户态和内核态

    用户态和内核态是操作系统的两种运行状态。

    • 内核态:处于内核态的 CPU 可以访问任意的数据,包括外围设备,比如网卡、硬盘等,处于内核态的 CPU 可以从一个程序切换到另外一个程序,并且占用 CPU 不会发生抢占情况,一般处于特权级 0 的状态我们称之为内核态。

    • 用户态:处于用户态的 CPU 只能受限的访问内存,并且不允许访问外围设备,用户态下的 CPU 不允许独占,也就是说 CPU 能够被其他程序获取。

    那么为什么要有用户态和内核态呢?

    这个主要是访问能力的限制的考量,计算机中有一些比较危险的操作,比如设置时钟、内存清理,这些都需要在内核态下完成,如果随意进行这些操作,那你的系统得崩溃多少次。

    用户态和内核态是如何切换的?

    所有的用户进程都是运行在用户态的,但是我们上面也说了,用户程序的访问能力有限,一些比较重要的比如从硬盘读取数据,从键盘获取数据的操作则是内核态才能做的事情,而这些数据却又对用户程序来说非常重要。所以就涉及到两种模式下的转换,即用户态 -> 内核态 -> 用户态,而唯一能够做这些操作的只有 系统调用,而能够执行系统调用的就只有 操作系统

    一般用户态 -> 内核态的转换我们都称之为 trap 进内核,也被称之为 陷阱指令(trap instruction)

    他们的工作流程如下:

    • 首先用户程序会调用 glibc 库,glibc 是一个标准库,同时也是一套核心库,库中定义了很多关键 API。
    • glibc 库知道针对不同体系结构调用系统调用的正确方法,它会根据体系结构应用程序的二进制接口设置用户进程传递的参数,来准备系统调用。
    • 然后,glibc 库调用软件中断指令(SWI) ,这个指令通过更新 CPSR 寄存器将模式改为超级用户模式,然后跳转到地址 0x08 处。
    • 到目前为止,整个过程仍处于用户态下,在执行 SWI 指令后,允许进程执行内核代码,MMU 现在允许内核虚拟内存访问
    • 从地址 0x08 开始,进程执行加载并跳转到中断处理程序,这个程序就是 ARM 中的 vector_swi()
    • 在 vector_swi() 处,从 SWI 指令中提取系统调用号 SCNO,然后使用 SCNO 作为系统调用表 sys_call_table 的索引,调转到系统调用函数。
    • 执行系统调用完成后,将还原用户模式寄存器,然后再以用户模式执行。

    什么是内核

    在计算机中,内核是一个计算机程序,它是操作系统的核心,可以控制操作系统中所有的内容。内核通常是在 boot loader 装载程序之前加载的第一个程序。

    这里还需要了解一下什么是 boot loader

    boot loader 又被称为引导加载程序,能够将计算机的操作系统放入内存中。在电源通电或者计算机重启时,BIOS 会执行一些初始测试,然后将控制权转移到引导加载程序所在的主引导记录(MBR)

    什么是实时系统

    实时操作系统对时间做出了严格的要求,实时操作系统分为两种:硬实时和软实时

    硬实时操作系统规定某个动作必须在规定的时刻内完成或发生,比如汽车生产车间,焊接机器必须在某一时刻内完成焊接,焊接的太早或者太晚都会对汽车造成永久性伤害。

    软实时操作系统虽然不希望偶尔违反最终的时限要求,但是仍然可以接受。并且不会引起任何永久性伤害。比如数字音频、多媒体、手机都是属于软实时操作系统。

    你可以简单理解硬实时和软实时的两个指标:是否在时刻内必须完成以及是否造成严重损害

    Linux 操作系统的启动过程

    当计算机电源通电后,BIOS会进行开机自检(Power-On-Self-Test, POST),对硬件进行检测和初始化。因为操作系统的启动会使用到磁盘、屏幕、键盘、鼠标等设备。下一步,磁盘中的第一个分区,也被称为 MBR(Master Boot Record) 主引导记录,被读入到一个固定的内存区域并执行。这个分区中有一个非常小的,只有 512 字节的程序。程序从磁盘中调入 boot 独立程序,boot 程序将自身复制到高位地址的内存从而为操作系统释放低位地址的内存。

    复制完成后,boot 程序读取启动设备的根目录。boot 程序要理解文件系统和目录格式。然后 boot 程序被调入内核,把控制权移交给内核。直到这里,boot 完成了它的工作。系统内核开始运行。

    内核启动代码是使用汇编语言完成的,主要包括创建内核堆栈、识别 CPU 类型、计算内存、禁用中断、启动内存管理单元等,然后调用 C 语言的 main 函数执行操作系统部分。

    这部分也会做很多事情,首先会分配一个消息缓冲区来存放调试出现的问题,调试信息会写入缓冲区。如果调试出现错误,这些信息可以通过诊断程序调出来。

    然后操作系统会进行自动配置,检测设备,加载配置文件,被检测设备如果做出响应,就会被添加到已链接的设备表中,如果没有相应,就归为未连接直接忽略。

    配置完所有硬件后,接下来要做的就是仔细手工处理进程0,设置其堆栈,然后运行它,执行初始化、配置时钟、挂载文件系统。创建 init 进程(进程 1 )守护进程(进程 2)

    init 进程会检测它的标志以确定它是否为单用户还是多用户服务。在前一种情况中,它会调用 fork 函数创建一个 shell 进程,并且等待这个进程结束。后一种情况调用 fork 函数创建一个运行系统初始化的 shell 脚本(即 /etc/rc)的进程,这个进程可以进行文件系统一致性检测、挂载文件系统、开启守护进程等。

    然后 /etc/rc 这个进程会从 /etc/ttys 中读取数据,/etc/ttys 列出了所有的终端和属性。对于每一个启用的终端,这个进程调用 fork 函数创建一个自身的副本,进行内部处理并运行一个名为 getty 的程序。

    getty 程序会在终端上输入

    login:
    

    等待用户输入用户名,在输入用户名后,getty 程序结束,登陆程序 /bin/login 开始运行。login 程序需要输入密码,并与保存在 /etc/passwd 中的密码进行对比,如果输入正确,login 程序以用户 shell 程序替换自身,等待第一个命令。如果不正确,login 程序要求输入另一个用户名。

    整个系统启动过程如下

    进程和线程篇

    多处理系统的优势

    随着处理器的不断增加,我们的计算机系统由单机系统变为了多处理系统,多处理系统的吞吐量比较高,多处理系统拥有多个并行的处理器,这些处理器共享时钟、内存、总线、外围设备等。

    多处理系统由于可以共享资源,因此可以开源节流,省钱。整个系统的可靠性也随之提高。

    什么是进程和进程表

    进程就是正在执行程序的实例,比如说 Web 程序就是一个进程,shell 也是一个进程,文章编辑器 typora 也是一个进程。

    操作系统负责管理所有正在运行的进程,操作系统会为每个进程分配特定的时间来占用 CPU,操作系统还会为每个进程分配特定的资源。

    操作系统为了跟踪每个进程的活动状态,维护了一个进程表。在进程表的内部,列出了每个进程的状态以及每个进程使用的资源等。

    什么是线程,线程和进程的区别

    这又是一道老生常谈的问题了,从操作系统的角度来回答一下吧。

    我们上面说到进程是正在运行的程序的实例,而线程其实就是进程中的单条流向,因为线程具有进程中的某些属性,所以线程又被称为轻量级的进程。浏览器如果是一个进程的话,那么浏览器下面的每个 tab 页可以看作是一个个的线程。

    下面是线程和进程持有资源的区别

    线程不像进程那样具有很强的独立性,线程之间会共享数据

    创建线程的开销要比进程小很多,因为创建线程仅仅需要堆栈指针程序计数器就可以了,而创建进程需要操作系统分配新的地址空间,数据资源等,这个开销比较大。

    什么是上下文切换

    对于单核单线程 CPU 而言,在某一时刻只能执行一条 CPU 指令。上下文切换 (Context Switch) 是一种 将 CPU 资源从一个进程分配给另一个进程的机制。从用户角度看,计算机能够并行运行多个进程,这恰恰是操作系统通过快速上下文切换造成的结果。在切换的过程中,操作系统需要先存储当前进程的状态 (包括内存空间的指针,当前执行完的指令等等),再读入下一个进程的状态,然后执行此进程。

    使用多线程的好处是什么

    多线程是程序员不得不知的基本素养之一,所以,下面我们给出一些多线程编程的好处

    • 能够提高对用户的响应顺序
    • 在流程中的资源共享
    • 比较经济适用
    • 能够对多线程架构有深入的理解

    进程终止的方式

    进程的终止

    进程在创建之后,它就开始运行并做完成任务。然而,没有什么事儿是永不停歇的,包括进程也一样。进程早晚会发生终止,但是通常是由于以下情况触发的

    • 正常退出(自愿的)
    • 错误退出(自愿的)
    • 严重错误(非自愿的)
    • 被其他进程杀死(非自愿的)

    正常退出

    多数进程是由于完成了工作而终止。当编译器完成了所给定程序的编译之后,编译器会执行一个系统调用告诉操作系统它完成了工作。这个调用在 UNIX 中是 exit ,在 Windows 中是 ExitProcess。面向屏幕中的软件也支持自愿终止操作。字处理软件、Internet 浏览器和类似的程序中总有一个供用户点击的图标或菜单项,用来通知进程删除它锁打开的任何临时文件,然后终止。

    错误退出

    进程发生终止的第二个原因是发现严重错误,例如,如果用户执行如下命令

    cc foo.c	
    

    为了能够编译 foo.c 但是该文件不存在,于是编译器就会发出声明并退出。在给出了错误参数时,面向屏幕的交互式进程通常并不会直接退出,因为这从用户的角度来说并不合理,用户需要知道发生了什么并想要进行重试,所以这时候应用程序通常会弹出一个对话框告知用户发生了系统错误,是需要重试还是退出。

    严重错误

    进程终止的第三个原因是由进程引起的错误,通常是由于程序中的错误所导致的。例如,执行了一条非法指令,引用不存在的内存,或者除数是 0 等。在有些系统比如 UNIX 中,进程可以通知操作系统,它希望自行处理某种类型的错误,在这类错误中,进程会收到信号(中断),而不是在这类错误出现时直接终止进程。

    被其他进程杀死

    第四个终止进程的原因是,某个进程执行系统调用告诉操作系统杀死某个进程。在 UNIX 中,这个系统调用是 kill。在 Win32 中对应的函数是 TerminateProcess(注意不是系统调用)。

    进程间的通信方式

    进程间的通信方式比较多,首先你需要理解下面这几个概念

    • 竞态条件:即两个或多个线程同时对一共享数据进行修改,从而影响程序运行的正确性时,这种就被称为竞态条件(race condition)

    • 临界区:不仅共享资源会造成竞态条件,事实上共享文件、共享内存也会造成竞态条件、那么该如何避免呢?或许一句话可以概括说明:禁止一个或多个进程在同一时刻对共享资源(包括共享内存、共享文件等)进行读写。换句话说,我们需要一种 互斥(mutual exclusion) 条件,这也就是说,如果一个进程在某种方式下使用共享变量和文件的话,除该进程之外的其他进程就禁止做这种事(访问统一资源)。

      一个好的解决方案,应该包含下面四种条件

      1. 任何时候两个进程不能同时处于临界区
      2. 不应对 CPU 的速度和数量做任何假设
      3. 位于临界区外的进程不得阻塞其他进程
      4. 不能使任何进程无限等待进入临界区

    • 忙等互斥:当一个进程在对资源进行修改时,其他进程必须进行等待,进程之间要具有互斥性,我们讨论的解决方案其实都是基于忙等互斥提出的。

    进程间的通信用专业一点的术语来表示就是 Inter Process Communication,IPC,它主要有下面 7。种通信方式

    • 消息传递:消息传递是进程间实现通信和同步等待的机制,使用消息传递,进程间的交流不需要共享变量,直接就可以进行通信;消息传递分为发送方和接收方
    • 先进先出队列:先进先出队列指的是两个不相关联进程间的通信,两个进程之间可以彼此相互进程通信,这是一种全双工通信方式
    • 管道:管道用于两个相关进程之间的通信,这是一种半双工的通信方式,如果需要全双工,需要另外一个管道。
    • 直接通信:在这种进程通信的方式中,进程与进程之间只存在一条链接,进程间要明确通信双方的命名。
    • 间接通信:间接通信是通信双方不会直接建立连接,而是找到一个中介者,这个中介者可能是个对象等等,进程可以在其中放置消息,并且可以从中删除消息,以此达到进程间通信的目的。
    • 消息队列:消息队列是内核中存储消息的链表,它由消息队列标识符进行标识,这种方式能够在不同的进程之间提供全双工的通信连接。
    • 共享内存:共享内存是使用所有进程之间的内存来建立连接,这种类型需要同步进程访问来相互保护。

    进程间状态模型

    进程的三态模型

    当一个进程开始运行时,它可能会经历下面这几种状态

    图中会涉及三种状态

    1. 运行态:运行态指的就是进程实际占用 CPU 时间片运行时
    2. 就绪态:就绪态指的是可运行,但因为其他进程正在运行而处于就绪状态
    3. 阻塞态:阻塞态又被称为睡眠态,它指的是进程不具备运行条件,正在等待被 CPU 调度。

    逻辑上来说,运行态和就绪态是很相似的。这两种情况下都表示进程可运行,但是第二种情况没有获得 CPU 时间分片。第三种状态与前两种状态不同的原因是这个进程不能运行,CPU 空闲时也不能运行。

    三种状态会涉及四种状态间的切换,在操作系统发现进程不能继续执行时会发生状态1的轮转,在某些系统中进程执行系统调用,例如 pause,来获取一个阻塞的状态。在其他系统中包括 UNIX,当进程从管道或特殊文件(例如终端)中读取没有可用的输入时,该进程会被自动终止。

    转换 2 和转换 3 都是由进程调度程序(操作系统的一部分)引起的,进程本身不知道调度程序的存在。转换 2 的出现说明进程调度器认定当前进程已经运行了足够长的时间,是时候让其他进程运行 CPU 时间片了。当所有其他进程都运行过后,这时候该是让第一个进程重新获得 CPU 时间片的时候了,就会发生转换 3。

    程序调度指的是,决定哪个进程优先被运行和运行多久,这是很重要的一点。已经设计出许多算法来尝试平衡系统整体效率与各个流程之间的竞争需求。

    当进程等待的一个外部事件发生时(如从外部输入一些数据后),则发生转换 4。如果此时没有其他进程在运行,则立刻触发转换 3,该进程便开始运行,否则该进程会处于就绪阶段,等待 CPU 空闲后再轮到它运行。

    进程的五态模型

    在三态模型的基础上,增加了两个状态,即 新建终止 状态。

    • 新建态:进程的新建态就是进程刚创建出来的时候

    创建进程需要两个步骤:即为新进程分配所需要的资源和空间,设置进程为就绪态,并等待调度执行。

    • 终止态:进程的终止态就是指进程执行完毕,到达结束点,或者因为错误而不得不中止进程。

    终止一个进程需要两个步骤:

    1. 先等待操作系统或相关的进程进行善后处理。

    2. 然后回收占用的资源并被系统删除。

    调度算法都有哪些

    调度算法分为三大类:批处理中的调度、交互系统中的调度、实时系统中的调度

    批处理中的调度

    先来先服务

    很像是先到先得。。。可能最简单的非抢占式调度算法的设计就是 先来先服务(first-come,first-serverd)。使用此算法,将按照请求顺序为进程分配 CPU。最基本的,会有一个就绪进程的等待队列。当第一个任务从外部进入系统时,将会立即启动并允许运行任意长的时间。它不会因为运行时间太长而中断。当其他作业进入时,它们排到就绪队列尾部。当正在运行的进程阻塞,处于等待队列的第一个进程就开始运行。当一个阻塞的进程重新处于就绪态时,它会像一个新到达的任务,会排在队列的末尾,即排在所有进程最后。

    这个算法的强大之处在于易于理解和编程,在这个算法中,一个单链表记录了所有就绪进程。要选取一个进程运行,只要从该队列的头部移走一个进程即可;要添加一个新的作业或者阻塞一个进程,只要把这个作业或进程附加在队列的末尾即可。这是很简单的一种实现。

    不过,先来先服务也是有缺点的,那就是没有优先级的关系,试想一下,如果有 100 个 I/O 进程正在排队,第 101 个是一个 CPU 密集型进程,那岂不是需要等 100 个 I/O 进程运行完毕才会等到一个 CPU 密集型进程运行,这在实际情况下根本不可能,所以需要优先级或者抢占式进程的出现来优先选择重要的进程运行。

    最短作业优先

    批处理中,第二种调度算法是 最短作业优先(Shortest Job First),我们假设运行时间已知。例如,一家保险公司,因为每天要做类似的工作,所以人们可以相当精确地预测处理 1000 个索赔的一批作业需要多长时间。当输入队列中有若干个同等重要的作业被启动时,调度程序应使用最短优先作业算法

    如上图 a 所示,这里有 4 个作业 A、B、C、D ,运行时间分别为 8、4、4、4 分钟。若按图中的次序运行,则 A 的周转时间为 8 分钟,B 为 12 分钟,C 为 16 分钟,D 为 20 分钟,平均时间内为 14 分钟。

    现在考虑使用最短作业优先算法运行 4 个作业,如上图 b 所示,目前的周转时间分别为 4、8、12、20,平均为 11 分钟,可以证明最短作业优先是最优的。考虑有 4 个作业的情况,其运行时间分别为 a、b、c、d。第一个作业在时间 a 结束,第二个在时间 a + b 结束,以此类推。平均周转时间为 (4a + 3b + 2c + d) / 4 。显然 a 对平均值的影响最大,所以 a 应该是最短优先作业,其次是 b,然后是 c ,最后是 d 它就只能影响自己的周转时间了。

    需要注意的是,在所有的进程都可以运行的情况下,最短作业优先的算法才是最优的。

    最短剩余时间优先

    最短作业优先的抢占式版本被称作为 最短剩余时间优先(Shortest Remaining Time Next) 算法。使用这个算法,调度程序总是选择剩余运行时间最短的那个进程运行。当一个新作业到达时,其整个时间同当前进程的剩余时间做比较。如果新的进程比当前运行进程需要更少的时间,当前进程就被挂起,而运行新的进程。这种方式能够使短期作业获得良好的服务。

    交互式系统中的调度

    交互式系统中在个人计算机、服务器和其他系统中都是很常用的,所以有必要来探讨一下交互式调度

    轮询调度

    一种最古老、最简单、最公平并且最广泛使用的算法就是 轮询算法(round-robin)。每个进程都会被分配一个时间段,称为时间片(quantum),在这个时间片内允许进程运行。如果时间片结束时进程还在运行的话,则抢占一个 CPU 并将其分配给另一个进程。如果进程在时间片结束前阻塞或结束,则 CPU 立即进行切换。轮询算法比较容易实现。调度程序所做的就是维护一个可运行进程的列表,就像下图中的 a,当一个进程用完时间片后就被移到队列的末尾,就像下图的 b。

    优先级调度

    事实情况是不是所有的进程都是优先级相等的。例如,在一所大学中的等级制度,首先是院长,然后是教授、秘书、后勤人员,最后是学生。这种将外部情况考虑在内就实现了优先级调度(priority scheduling)

    它的基本思想很明确,每个进程都被赋予一个优先级,优先级高的进程优先运行。

    但是也不意味着高优先级的进程能够永远一直运行下去,调度程序会在每个时钟中断期间降低当前运行进程的优先级。如果此操作导致其优先级降低到下一个最高进程的优先级以下,则会发生进程切换。或者,可以为每个进程分配允许运行的最大时间间隔。当时间间隔用完后,下一个高优先级的进程会得到运行的机会。

    最短进程优先

    对于批处理系统而言,由于最短作业优先常常伴随着最短响应时间,一种方式是根据进程过去的行为进行推测,并执行估计运行时间最短的那一个。假设每个终端上每条命令的预估运行时间为 T0,现在假设测量到其下一次运行时间为 T1,可以用两个值的加权来改进估计时间,即aT0+ (1- 1)T1。通过选择 a 的值,可以决定是尽快忘掉老的运行时间,还是在一段长时间内始终记住它们。当 a = 1/2 时,可以得到下面这个序列

    可以看到,在三轮过后,T0 在新的估计值中所占比重下降至 1/8。

    有时把这种通过当前测量值和先前估计值进行加权平均从而得到下一个估计值的技术称作 老化(aging)。这种方法会使用很多预测值基于当前值的情况。

    彩票调度

    有一种既可以给出预测结果而又有一种比较简单的实现方式的算法,就是 彩票调度(lottery scheduling)算法。他的基本思想为进程提供各种系统资源的彩票。当做出一个调度决策的时候,就随机抽出一张彩票,拥有彩票的进程将获得资源。比如在 CPU 进行调度时,系统可以每秒持有 50 次抽奖,每个中奖进程会获得额外运行时间的奖励。

    可以把彩票理解为 buff,这个 buff 有 15% 的几率能让你产生 速度之靴 的效果。

    公平分享调度

    如果用户 1 启动了 9 个进程,而用户 2 启动了一个进程,使用轮转或相同优先级调度算法,那么用户 1 将得到 90 % 的 CPU 时间,而用户 2 将之得到 10 % 的 CPU 时间。

    为了阻止这种情况的出现,一些系统在调度前会把进程的拥有者考虑在内。在这种模型下,每个用户都会分配一些CPU 时间,而调度程序会选择进程并强制执行。因此如果两个用户每个都会有 50% 的 CPU 时间片保证,那么无论一个用户有多少个进程,都将获得相同的 CPU 份额。

    影响调度程序的指标是什么

    会有下面几个因素决定调度程序的好坏

    • CPU 使用率:

    CPU 正在执行任务(即不处于空闲状态)的时间百分比。

    • 等待时间

    这是进程轮流执行的时间,也就是进程切换的时间

    • 吞吐量

    单位时间内完成进程的数量

    • 响应时间

    这是从提交流程到获得有用输出所经过的时间。

    • 周转时间

    从提交流程到完成流程所经过的时间。

    什么是 RR 调度算法

    RR(round-robin) 调度算法主要针对分时系统,RR 的调度算法会把时间片以相同的部分并循环的分配给每个进程,RR 调度算法没有优先级的概念。这种算法的实现比较简单,而且每个线程都会占有时间片,并不存在线程饥饿的问题。

    内存管理篇

    什么是按需分页

    在操作系统中,进程是以页为单位加载到内存中的,按需分页是一种虚拟内存的管理方式。在使用请求分页的系统中,只有在尝试访问页面所在的磁盘并且该页面尚未在内存中时,也就发生了缺页异常,操作系统才会将磁盘页面复制到内存中。

    什么是虚拟内存

    虚拟内存是一种内存分配方案,是一项可以用来辅助内存分配的机制。我们知道,应用程序是按页装载进内存中的。但并不是所有的页都会装载到内存中,计算机中的硬件和软件会将数据从 RAM 临时传输到磁盘中来弥补内存的不足。如果没有虚拟内存的话,一旦你将计算机内存填满后,计算机会对你说

    呃,不,对不起,您无法再加载任何应用程序,请关闭另一个应用程序以加载新的应用程序。对于虚拟内存,计算机可以执行操作是查看内存中最近未使用过的区域,然后将其复制到硬盘上。虚拟内存通过复制技术实现了 妹子,你快来看哥哥能装这么多程序 的资本。复制是自动进行的,你无法感知到它的存在。

    虚拟内存的实现方式

    虚拟内存中,允许将一个作业分多次调入内存。釆用连续分配方式时,会使相当一部分内存空间都处于暂时或永久的空闲状态,造成内存资源的严重浪费,而且也无法从逻辑上扩大内存容量。因此,虚拟内存的实需要建立在离散分配的内存管理方式的基础上。虚拟内存的实现有以下三种方式:

    • 请求分页存储管理。
    • 请求分段存储管理。
    • 请求段页式存储管理。

    不管哪种方式,都需要有一定的硬件支持。一般需要的支持有以下几个方面:

    • 一定容量的内存和外存。
    • 页表机制(或段表机制),作为主要的数据结构。
    • 中断机构,当用户程序要访问的部分尚未调入内存,则产生中断。
    • 地址变换机构,逻辑地址到物理地址的变换。

    内存为什么要分段

    内存是随机访问设备,对于内存来说,不需要从头开始查找,只需要直接给出地址即可。内存的分段是从 8086 CPU 开始的,8086 的 CPU 还是 16 位的寄存器宽,16 位的寄存器可以存储的数字范围是 2 的 16 次方,即 64 KB,8086 的 CPU 还没有 虚拟地址,只有物理地址,也就是说,如果两个相同的程序编译出来的地址相同,那么这两个程序是无法同时运行的。为了解决这个问题,操作系统设计人员提出了让 CPU 使用 段基址 + 段内偏移 的方式来访问任意内存。这样的好处是让程序可以 重定位这也是内存为什么要分段的第一个原因

    那么什么是重定位呢?

    简单来说就是将程序中的指令地址改为另一个地址,地址处存储的内容还是原来的。

    CPU 采用段基址 + 段内偏移地址的形式访问内存,就需要提供专门的寄存器,这些专门的寄存器就是 CS、DS、ES 等,如果你对寄存器不熟悉,可以看我的这一篇文章。

    爱了爱了,这篇寄存器讲的有点意思

    也就是说,程序中需要用到哪块内存,就需要先加载合适的段到段基址寄存器中,再给出相对于该段基址的段偏移地址即可。CPU 中的地址加法器会将这两个地址进行合并,从地址总线送入内存。

    8086 的 CPU 有 20 根地址总线,最大的寻址能力是 1MB,而段基址所在的寄存器宽度只有 16 位,最大为你 64 KB 的寻址能力,64 KB 显然不能满足 1MB 的最大寻址范围,所以就要把内存分段,每个段的最大寻址能力是 64KB,但是仍旧不能达到最大 1 MB 的寻址能力,所以这时候就需要 偏移地址的辅助,偏移地址也存入寄存器,同样为 64 KB 的寻址能力,这么一看还是不能满足 1MB 的寻址,所以 CPU 的设计者对地址单元动了手脚,将段基址左移 4 位,然后再和 16 位的段内偏移地址相加,就达到了 1MB 的寻址能力。所以内存分段的第二个目的就是能够访问到所有内存

    物理地址、逻辑地址、有效地址、线性地址、虚拟地址的区别

    物理地址就是内存中真正的地址,它就相当于是你家的门牌号,你家就肯定有这个门牌号,具有唯一性。不管哪种地址,最终都会映射为物理地址

    实模式下,段基址 + 段内偏移经过地址加法器的处理,经过地址总线传输,最终也会转换为物理地址

    但是在保护模式下,段基址 + 段内偏移被称为线性地址,不过此时的段基址不能称为真正的地址,而是会被称作为一个选择子的东西,选择子就是个索引,相当于数组的下标,通过这个索引能够在 GDT 中找到相应的段描述符,段描述符记录了段的起始、段的大小等信息,这样便得到了基地址。如果此时没有开启内存分页功能,那么这个线性地址可以直接当做物理地址来使用,直接访问内存。如果开启了分页功能,那么这个线性地址又多了一个名字,这个名字就是虚拟地址

    不论在实模式还是保护模式下,段内偏移地址都叫做有效地址。有效抵制也是逻辑地址。

    线性地址可以看作是虚拟地址,虚拟地址不是真正的物理地址,但是虚拟地址会最终被映射为物理地址。下面是虚拟地址 -> 物理地址的映射。

    空闲内存管理的方式

    操作系统在动态分配内存时(malloc,new),需要对空间内存进行管理。一般采用了两种方式:位图和空闲链表。

    使用位图进行管理

    使用位图方法时,内存可能被划分为小到几个字或大到几千字节的分配单元。每个分配单元对应于位图中的一位,0 表示空闲, 1 表示占用(或者相反)。一块内存区域和其对应的位图如下

    图 a 表示一段有 5 个进程和 3 个空闲区的内存,刻度为内存分配单元,阴影区表示空闲(在位图中用 0 表示);图 b 表示对应的位图;图 c 表示用链表表示同样的信息

    分配单元的大小是一个重要的设计因素,分配单位越小,位图越大。然而,即使只有 4 字节的分配单元,32 位的内存也仅仅只需要位图中的 1 位。32n 位的内存需要 n 位的位图,所以1 个位图只占用了 1/32 的内存。如果选择更大的内存单元,位图应该要更小。如果进程的大小不是分配单元的整数倍,那么在最后一个分配单元中会有大量的内存被浪费。

    位图提供了一种简单的方法在固定大小的内存中跟踪内存的使用情况,因为位图的大小取决于内存和分配单元的大小。这种方法有一个问题,当决定为把具有 k 个分配单元的进程放入内存时,内容管理器(memory manager) 必须搜索位图,在位图中找出能够运行 k 个连续 0 位的串。在位图中找出制定长度的连续 0 串是一个很耗时的操作,这是位图的缺点。(可以简单理解为在杂乱无章的数组中,找出具有一大长串空闲的数组单元)

    使用空闲链表

    另一种记录内存使用情况的方法是,维护一个记录已分配内存段和空闲内存段的链表,段会包含进程或者是两个进程的空闲区域。可用上面的图 c 来表示内存的使用情况。链表中的每一项都可以代表一个 空闲区(H) 或者是进程(P)的起始标志,长度和下一个链表项的位置。

    在这个例子中,段链表(segment list)是按照地址排序的。这种方式的优点是,当进程终止或被交换时,更新列表很简单。一个终止进程通常有两个邻居(除了内存的顶部和底部外)。相邻的可能是进程也可能是空闲区,它们有四种组合方式。

    当按照地址顺序在链表中存放进程和空闲区时,有几种算法可以为创建的进程(或者从磁盘中换入的进程)分配内存。

    • 首次适配算法:在链表中进行搜索,直到找到最初的一个足够大的空闲区,将其分配。除非进程大小和空间区大小恰好相同,否则会将空闲区分为两部分,一部分为进程使用,一部分成为新的空闲区。该方法是速度很快的算法,因为索引链表结点的个数较少。
    • 下次适配算法:工作方式与首次适配算法相同,但每次找到新的空闲区位置后都记录当前位置,下次寻找空闲区从上次结束的地方开始搜索,而不是与首次适配放一样从头开始;
    • 最佳适配算法:搜索整个链表,找出能够容纳进程分配的最小的空闲区。这样存在的问题是,尽管可以保证为进程找到一个最为合适的空闲区进行分配,但大多数情况下,这样的空闲区被分为两部分,一部分用于进程分配,一部分会生成很小的空闲区,而这样的空闲区很难再被进行利用。
    • 最差适配算法:与最佳适配算法相反,每次分配搜索最大的空闲区进行分配,从而可以使得空闲区拆分得到的新的空闲区可以更好的被进行利用。

    页面置换算法都有哪些

    在地址映射过程中,如果在页面中发现所要访问的页面不在内存中,那么就会产生一条缺页中断。当发生缺页中断时,如果操作系统内存中没有空闲页面,那么操作系统必须在内存选择一个页面将其移出内存,以便为即将调入的页面让出空间。而用来选择淘汰哪一页的规则叫做页面置换算法。

    下面我汇总的这些页面置换算法比较齐全,只给出简单介绍,算法具体的实现和原理读者可以自行了解。

    • 最优算法在当前页面中置换最后要访问的页面。不幸的是,没有办法来判定哪个页面是最后一个要访问的,因此实际上该算法不能使用。然而,它可以作为衡量其他算法的标准。
    • NRU 算法根据 R 位和 M 位的状态将页面氛围四类。从编号最小的类别中随机选择一个页面。NRU 算法易于实现,但是性能不是很好。存在更好的算法。
    • FIFO 会跟踪页面加载进入内存中的顺序,并把页面放入一个链表中。有可能删除存在时间最长但是还在使用的页面,因此这个算法也不是一个很好的选择。
    • 第二次机会算法是对 FIFO 的一个修改,它会在删除页面之前检查这个页面是否仍在使用。如果页面正在使用,就会进行保留。这个改进大大提高了性能。
    • 时钟 算法是第二次机会算法的另外一种实现形式,时钟算法和第二次算法的性能差不多,但是会花费更少的时间来执行算法。
    • LRU 算法是一个非常优秀的算法,但是没有特殊的硬件(TLB)很难实现。如果没有硬件,就不能使用 LRU 算法。
    • NFU 算法是一种近似于 LRU 的算法,它的性能不是非常好。
    • 老化 算法是一种更接近 LRU 算法的实现,并且可以更好的实现,因此是一个很好的选择
    • 最后两种算法都使用了工作集算法。工作集算法提供了合理的性能开销,但是它的实现比较复杂。WSClock 是另外一种变体,它不仅能够提供良好的性能,而且可以高效地实现。

    最好的算法是老化算法和WSClock算法。他们分别是基于 LRU 和工作集算法。他们都具有良好的性能并且能够被有效的实现。还存在其他一些好的算法,但实际上这两个可能是最重要的。

    文件系统篇

    提高文件系统性能的方式

    访问磁盘的效率要比内存慢很多,是时候又祭出这张图了

    所以磁盘优化是很有必要的,下面我们会讨论几种优化方式

    高速缓存

    最常用的减少磁盘访问次数的技术是使用 块高速缓存(block cache) 或者 缓冲区高速缓存(buffer cache)。高速缓存指的是一系列的块,它们在逻辑上属于磁盘,但实际上基于性能的考虑被保存在内存中。

    管理高速缓存有不同的算法,常用的算法是:检查全部的读请求,查看在高速缓存中是否有所需要的块。如果存在,可执行读操作而无须访问磁盘。如果检查块不再高速缓存中,那么首先把它读入高速缓存,再复制到所需的地方。之后,对同一个块的请求都通过高速缓存来完成。

    高速缓存的操作如下图所示

    由于在高速缓存中有许多块,所以需要某种方法快速确定所需的块是否存在。常用方法是将设备和磁盘地址进行散列操作。然后在散列表中查找结果。具有相同散列值的块在一个链表中连接在一起(这个数据结构是不是很像 HashMap?),这样就可以沿着冲突链查找其他块。

    如果高速缓存已满,此时需要调入新的块,则要把原来的某一块调出高速缓存,如果要调出的块在上次调入后已经被修改过,则需要把它写回磁盘。这种情况与分页非常相似。

    块提前读

    第二个明显提高文件系统的性能是在需要用到块之前试图提前将其写入高速缓存从而提高命中率。许多文件都是顺序读取。如果请求文件系统在某个文件中生成块 k,文件系统执行相关操作并且在完成之后,会检查高速缓存,以便确定块 k + 1 是否已经在高速缓存。如果不在,文件系统会为 k + 1 安排一个预读取,因为文件希望在用到该块的时候能够直接从高速缓存中读取。

    当然,块提前读取策略只适用于实际顺序读取的文件。对随机访问的文件,提前读丝毫不起作用。甚至还会造成阻碍。

    减少磁盘臂运动

    高速缓存和块提前读并不是提高文件系统性能的唯一方法。另一种重要的技术是把有可能顺序访问的块放在一起,当然最好是在同一个柱面上,从而减少磁盘臂的移动次数。当写一个输出文件时,文件系统就必须按照要求一次一次地分配磁盘块。如果用位图来记录空闲块,并且整个位图在内存中,那么选择与前一块最近的空闲块是很容易的。如果用空闲表,并且链表的一部分存在磁盘上,要分配紧邻的空闲块就会困难很多。

    不过,即使采用空闲表,也可以使用 块簇 技术。即不用块而用连续块簇来跟踪磁盘存储区。如果一个扇区有 512 个字节,有可能系统采用 1 KB 的块(2 个扇区),但却按每 2 块(4 个扇区)一个单位来分配磁盘存储区。这和 2 KB 的磁盘块并不相同,因为在高速缓存中它仍然使用 1 KB 的块,磁盘与内存数据之间传送也是以 1 KB 进行,但在一个空闲的系统上顺序读取这些文件,寻道的次数可以减少一半,从而使文件系统的性能大大改善。若考虑旋转定位则可以得到这类方法的变体。在分配块时,系统尽量把一个文件中的连续块存放在同一个柱面上。

    在使用 inode 或任何类似 inode 的系统中,另一个性能瓶颈是,读取一个很短的文件也需要两次磁盘访问:一次是访问 inode,一次是访问块。通常情况下,inode 的放置如下图所示

    其中,全部 inode 放在靠近磁盘开始位置,所以 inode 和它所指向的块之间的平均距离是柱面组的一半,这将会需要较长时间的寻道时间。

    一个简单的改进方法是,在磁盘中部而不是开始处存放 inode ,此时,在 inode 和第一个块之间的寻道时间减为原来的一半。另一种做法是:将磁盘分成多个柱面组,每个柱面组有自己的 inode,数据块和空闲表,如上图 b 所示。

    当然,只有在磁盘中装有磁盘臂的情况下,讨论寻道时间和旋转时间才是有意义的。现在越来越多的电脑使用 固态硬盘(SSD),对于这些硬盘,由于采用了和闪存同样的制造技术,使得随机访问和顺序访问在传输速度上已经较为相近,传统硬盘的许多问题就消失了。但是也引发了新的问题。

    磁盘碎片整理

    在初始安装操作系统后,文件就会被不断的创建和清除,于是磁盘会产生很多的碎片,在创建一个文件时,它使用的块会散布在整个磁盘上,降低性能。删除文件后,回收磁盘块,可能会造成空穴。

    磁盘性能可以通过如下方式恢复:移动文件使它们相互挨着,并把所有的至少是大部分的空闲空间放在一个或多个大的连续区域内。Windows 有一个程序 defrag 就是做这个事儿的。Windows 用户会经常使用它,SSD 除外。

    磁盘碎片整理程序会在让文件系统上很好地运行。Linux 文件系统(特别是 ext2 和 ext3)由于其选择磁盘块的方式,在磁盘碎片整理上一般不会像 Windows 一样困难,因此很少需要手动的磁盘碎片整理。而且,固态硬盘并不受磁盘碎片的影响,事实上,在固态硬盘上做磁盘碎片整理反倒是多此一举,不仅没有提高性能,反而磨损了固态硬盘。所以碎片整理只会缩短固态硬盘的寿命。

    磁盘臂调度算法

    一般情况下,影响磁盘快读写的时间由下面几个因素决定

    • 寻道时间 - 寻道时间指的就是将磁盘臂移动到需要读取磁盘块上的时间
    • 旋转延迟 - 等待合适的扇区旋转到磁头下所需的时间
    • 实际数据的读取或者写入时间

    这三种时间参数也是磁盘寻道的过程。一般情况下,寻道时间对总时间的影响最大,所以,有效的降低寻道时间能够提高磁盘的读取速度。

    如果磁盘驱动程序每次接收一个请求并按照接收顺序完成请求,这种处理方式也就是 先来先服务(First-Come, First-served, FCFS) ,这种方式很难优化寻道时间。因为每次都会按照顺序处理,不管顺序如何,有可能这次读完后需要等待一个磁盘旋转一周才能继续读取,而其他柱面能够马上进行读取,这种情况下每次请求也会排队。

    通常情况下,磁盘在进行寻道时,其他进程会产生其他的磁盘请求。磁盘驱动程序会维护一张表,表中会记录着柱面号当作索引,每个柱面未完成的请求会形成链表,链表头存放在表的相应表项中。

    一种对先来先服务的算法改良的方案是使用 最短路径优先(SSF) 算法,下面描述了这个算法。

    假如我们在对磁道 6 号进行寻址时,同时发生了对 11 , 2 , 4, 14, 8, 15, 3 的请求,如果采用先来先服务的原则,如下图所示

    我们可以计算一下磁盘臂所跨越的磁盘数量为 5 + 9 + 2 + 10 + 6 + 7 + 12 = 51,相当于是跨越了 51 次盘面,如果使用最短路径优先,我们来计算一下跨越的盘面

    跨越的磁盘数量为 4 + 1 + 1 + 4 + 3 + 3 + 1 = 17 ,相比 51 足足省了两倍的时间。

    但是,最短路径优先的算法也不是完美无缺的,这种算法照样存在问题,那就是优先级 问题,

    这里有一个原型可以参考就是我们日常生活中的电梯,电梯使用一种电梯算法(elevator algorithm) 来进行调度,从而满足协调效率和公平性这两个相互冲突的目标。电梯一般会保持向一个方向移动,直到在那个方向上没有请求为止,然后改变方向。

    电梯算法需要维护一个二进制位,也就是当前的方向位:UP(向上)或者是 DOWN(向下)。当一个请求处理完成后,磁盘或电梯的驱动程序会检查该位,如果此位是 UP 位,磁盘臂或者电梯仓移到下一个更高跌未完成的请求。如果高位没有未完成的请求,则取相反方向。当方向位是 DOWN时,同时存在一个低位的请求,磁盘臂会转向该点。如果不存在的话,那么它只是停止并等待。

    我们举个例子来描述一下电梯算法,比如各个柱面得到服务的顺序是 4,7,10,14,9,6,3,1 ,那么它的流程图如下

    所以电梯算法需要跨越的盘面数量是 3 + 3 + 4 + 5 + 3 + 3 + 1 = 22

    电梯算法通常情况下不如 SSF 算法。

    一些磁盘控制器为软件提供了一种检查磁头下方当前扇区号的方法,使用这样的控制器,能够进行另一种优化。如果对一个相同的柱面有两个或者多个请求正等待处理,驱动程序可以发出请求读写下一次要通过磁头的扇区。

    这里需要注意一点,当一个柱面有多条磁道时,相继的请求可能针对不同的磁道,这种选择没有代价,因为选择磁头不需要移动磁盘臂也没有旋转延迟。

    对于磁盘来说,最影响性能的就是寻道时间和旋转延迟,所以一次只读取一个或两个扇区的效率是非常低的。出于这个原因,许多磁盘控制器总是读出多个扇区并进行高速缓存,即使只请求一个扇区时也是这样。一般情况下读取一个扇区的同时会读取该扇区所在的磁道或者是所有剩余的扇区被读出,读出扇区的数量取决于控制器的高速缓存中有多少可用的空间。

    磁盘控制器的高速缓存和操作系统的高速缓存有一些不同,磁盘控制器的高速缓存用于缓存没有实际被请求的块,而操作系统维护的高速缓存由显示地读出的块组成,并且操作系统会认为这些块在近期仍然会频繁使用。

    当同一个控制器上有多个驱动器时,操作系统应该为每个驱动器都单独的维护一个未完成的请求表。一旦有某个驱动器闲置时,就应该发出一个寻道请求来将磁盘臂移到下一个被请求的柱面。如果下一个寻道请求到来时恰好没有磁盘臂处于正确的位置,那么驱动程序会在刚刚完成传输的驱动器上发出一个新的寻道命令并等待,等待下一次中断到来时检查哪个驱动器处于闲置状态。

    RAID 的不同级别

    RAID 称为 磁盘冗余阵列,简称 磁盘阵列。利用虚拟化技术把多个硬盘结合在一起,成为一个或多个磁盘阵列组,目的是提升性能或数据冗余。

    RAID 有不同的级别

    • RAID 0 - 无容错的条带化磁盘阵列
    • RAID 1 - 镜像和双工
    • RAID 2 - 内存式纠错码
    • RAID 3 - 比特交错奇偶校验
    • RAID 4 - 块交错奇偶校验
    • RAID 5 - 块交错分布式奇偶校验
    • RAID 6 - P + Q冗余

    IO 篇

    操作系统中的时钟是什么

    时钟(Clocks) 也被称为定时器(timers),时钟/定时器对任何程序系统来说都是必不可少的。时钟负责维护时间、防止一个进程长期占用 CPU 时间等其他功能。时钟软件(clock software) 也是一种设备驱动的方式。下面我们就来对时钟进行介绍,一般都是先讨论硬件再介绍软件,采用由下到上的方式,也是告诉你,底层是最重要的。

    时钟硬件

    在计算机中有两种类型的时钟,这些时钟与现实生活中使用的时钟完全不一样。

    • 比较简单的一种时钟被连接到 110 V 或 220 V 的电源线上,这样每个电压周期会产生一个中断,大概是 50 - 60 HZ。这些时钟过去一直占据支配地位。
    • 另外的一种时钟由晶体振荡器、计数器和寄存器组成,示意图如下所示

    这种时钟称为可编程时钟 ,可编程时钟有两种模式,一种是 一键式(one-shot mode),当时钟启动时,会把存储器中的值复制到计数器中,然后,每次晶体的振荡器的脉冲都会使计数器 -1。当计数器变为 0 时,会产生一个中断,并停止工作,直到软件再一次显示启动。还有一种模式时 方波(square-wave mode) 模式,在这种模式下,当计数器变为 0 并产生中断后,存储寄存器的值会自动复制到计数器中,这种周期性的中断称为一个时钟周期。

    设备控制器的主要功能

    设备控制器是一个可编址的设备,当它仅控制一个设备时,它只有一个唯一的设备地址;如果设备控制器控制多个可连接设备时,则应含有多个设备地址,并使每一个设备地址对应一个设备。

    设备控制器主要分为两种:字符设备和块设备

    设备控制器的主要功能有下面这些

    • 接收和识别命令:设备控制器可以接受来自 CPU 的指令,并进行识别。设备控制器内部也会有寄存器,用来存放指令和参数
    • 进行数据交换:CPU、控制器和设备之间会进行数据的交换,CPU 通过总线把指令发送给控制器,或从控制器中并行地读出数据;控制器将数据写入指定设备。
    • 地址识别:每个硬件设备都有自己的地址,设备控制器能够识别这些不同的地址,来达到控制硬件的目的,此外,为使 CPU 能向寄存器中写入或者读取数据,这些寄存器都应具有唯一的地址。
    • 差错检测:设备控制器还具有对设备传递过来的数据进行检测的功能。

    中断处理过程

    中断处理方案有很多种,下面是 《ARM System Developer’s Guide

    Designing and Optimizing System Software》列出来的一些方案

    • 非嵌套的中断处理程序按照顺序处理各个中断,非嵌套的中断处理程序也是最简单的中断处理
    • 嵌套的中断处理程序会处理多个中断而无需分配优先级
    • 可重入的中断处理程序可使用优先级处理多个中断
    • 简单优先级中断处理程序可处理简单的中断
    • 标准优先级中断处理程序比低优先级的中断处理程序在更短的时间能够处理优先级更高的中断
    • 高优先级 中断处理程序在短时间能够处理优先级更高的任务,并直接进入特定的服务例程。
    • 优先级分组中断处理程序能够处理不同优先级的中断任务

    下面是一些通用的中断处理程序的步骤,不同的操作系统实现细节不一样

    • 保存所有没有被中断硬件保存的寄存器
    • 为中断服务程序设置上下文环境,可能包括设置 TLBMMU 和页表,如果不太了解这三个概念,请参考另外一篇文章
    • 为中断服务程序设置栈
    • 对中断控制器作出响应,如果不存在集中的中断控制器,则继续响应中断
    • 把寄存器从保存它的地方拷贝到进程表中
    • 运行中断服务程序,它会从发出中断的设备控制器的寄存器中提取信息
    • 操作系统会选择一个合适的进程来运行。如果中断造成了一些优先级更高的进程变为就绪态,则选择运行这些优先级高的进程
    • 为进程设置 MMU 上下文,可能也会需要 TLB,根据实际情况决定
    • 加载进程的寄存器,包括 PSW 寄存器
    • 开始运行新的进程

    上面我们罗列了一些大致的中断步骤,不同性质的操作系统和中断处理程序能够处理的中断步骤和细节也不尽相同,下面是一个嵌套中断的具体运行步骤

    什么是设备驱动程序

    在计算机中,设备驱动程序是一种计算机程序,它能够控制或者操作连接到计算机的特定设备。驱动程序提供了与硬件进行交互的软件接口,使操作系统和其他计算机程序能够访问特定设备,不用需要了解其硬件的具体构造。

    什么是 DMA

    DMA 的中文名称是直接内存访问,它意味着 CPU 授予 I/O 模块权限在不涉及 CPU 的情况下读取或写入内存。也就是 DMA 可以不需要 CPU 的参与。这个过程由称为 DMA 控制器(DMAC)的芯片管理。由于 DMA 设备可以直接在内存之间传输数据,而不是使用 CPU 作为中介,因此可以缓解总线上的拥塞。DMA 通过允许 CPU 执行任务,同时 DMA 系统通过系统和内存总线传输数据来提高系统并发性。

    直接内存访问的特点

    DMA 方式有如下特点:

    • 数据传送以数据块为基本单位

    • 所传送的数据从设备直接送入主存,或者从主存直接输出到设备上

    • 仅在传送一个或多个数据块的开始和结束时才需 CPU 的干预,而整块数据的传送则是在控制器的控制下完成。

    DMA 方式和中断驱动控制方式相比,减少了 CPU 对 I/O 操作的干预,进一步提高了 CPU 与 I/O 设备的并行操作程度。

    DMA 方式的线路简单、价格低廉,适合高速设备与主存之间的成批数据传送,小型、微型机中的快速设备均采用这种方式,但其功能较差,不能满足复杂的 I/O 要求。

    死锁篇

    什么是僵尸进程

    僵尸进程是已完成且处于终止状态,但在进程表中却仍然存在的进程。僵尸进程通常发生在父子关系的进程中,由于父进程仍需要读取其子进程的退出状态所造成的。

    死锁产生的原因

    死锁产生的原因大致有两个:资源竞争和程序执行顺序不当

    死锁产生的必要条件

    资源死锁可能出现的情况主要有

    • 互斥条件:每个资源都被分配给了一个进程或者资源是可用的
    • 保持和等待条件:已经获取资源的进程被认为能够获取新的资源
    • 不可抢占条件:分配给一个进程的资源不能强制的从其他进程抢占资源,它只能由占有它的进程显示释放
    • 循环等待:死锁发生时,系统中一定有两个或者两个以上的进程组成一个循环,循环中的每个进程都在等待下一个进程释放的资源。

    死锁的恢复方式

    所以针对检测出来的死锁,我们要对其进行恢复,下面我们会探讨几种死锁的恢复方式

    通过抢占进行恢复

    在某些情况下,可能会临时将某个资源从它的持有者转移到另一个进程。比如在不通知原进程的情况下,将某个资源从进程中强制取走给其他进程使用,使用完后又送回。这种恢复方式一般比较困难而且有些简单粗暴,并不可取。

    通过回滚进行恢复

    如果系统设计者和机器操作员知道有可能发生死锁,那么就可以定期检查流程。进程的检测点意味着进程的状态可以被写入到文件以便后面进行恢复。检测点不仅包含存储映像(memory image),还包含资源状态(resource state)。一种更有效的解决方式是不要覆盖原有的检测点,而是每出现一个检测点都要把它写入到文件中,这样当进程执行时,就会有一系列的检查点文件被累积起来。

    为了进行恢复,要从上一个较早的检查点上开始,这样所需要资源的进程会回滚到上一个时间点,在这个时间点上,死锁进程还没有获取所需要的资源,可以在此时对其进行资源分配。

    杀死进程恢复

    最简单有效的解决方案是直接杀死一个死锁进程。但是杀死一个进程可能照样行不通,这时候就需要杀死别的资源进行恢复。

    另外一种方式是选择一个环外的进程作为牺牲品来释放进程资源。

    如何破坏死锁

    和死锁产生的必要条件一样,如果要破坏死锁,也是从下面四种方式进行破坏。

    破坏互斥条件

    我们首先考虑的就是破坏互斥使用条件。如果资源不被一个进程独占,那么死锁肯定不会产生。如果两个打印机同时使用一个资源会造成混乱,打印机的解决方式是使用 假脱机打印机(spooling printer) ,这项技术可以允许多个进程同时产生输出,在这种模型中,实际请求打印机的唯一进程是打印机守护进程,也称为后台进程。后台进程不会请求其他资源。我们可以消除打印机的死锁。

    后台进程通常被编写为能够输出完整的文件后才能打印,假如两个进程都占用了假脱机空间的一半,而这两个进程都没有完成全部的输出,就会导致死锁。

    因此,尽量做到尽可能少的进程可以请求资源。

    破坏保持等待的条件

    第二种方式是如果我们能阻止持有资源的进程请求其他资源,我们就能够消除死锁。一种实现方式是让所有的进程开始执行前请求全部的资源。如果所需的资源可用,进程会完成资源的分配并运行到结束。如果有任何一个资源处于频繁分配的情况,那么没有分配到资源的进程就会等待。

    很多进程无法在执行完成前就知道到底需要多少资源,如果知道的话,就可以使用银行家算法;还有一个问题是这样无法合理有效利用资源

    还有一种方式是进程在请求其他资源时,先释放所占用的资源,然后再尝试一次获取全部的资源。

    破坏不可抢占条件

    破坏不可抢占条件也是可以的。可以通过虚拟化的方式来避免这种情况。

    破坏循环等待条件

    现在就剩最后一个条件了,循环等待条件可以通过多种方法来破坏。一种方式是制定一个标准,一个进程在任何时候只能使用一种资源。如果需要另外一种资源,必须释放当前资源。

    另一种方式是将所有的资源统一编号,如下图所示

    进程可以在任何时间提出请求,但是所有的请求都必须按照资源的顺序提出。如果按照此分配规则的话,那么资源分配之间不会出现环。

    死锁类型

    两阶段加锁

    虽然很多情况下死锁的避免和预防都能处理,但是效果并不好。随着时间的推移,提出了很多优秀的算法用来处理死锁。例如在数据库系统中,一个经常发生的操作是请求锁住一些记录,然后更新所有锁定的记录。当同时有多个进程运行时,就会有死锁的风险。

    一种解决方式是使用 两阶段提交(two-phase locking)。顾名思义分为两个阶段,一阶段是进程尝试一次锁定它需要的所有记录。如果成功后,才会开始第二阶段,第二阶段是执行更新并释放锁。第一阶段并不做真正有意义的工作。

    如果在第一阶段某个进程所需要的记录已经被加锁,那么该进程会释放所有锁定的记录并重新开始第一阶段。从某种意义上来说,这种方法类似于预先请求所有必需的资源或者是在进行一些不可逆的操作之前请求所有的资源。

    不过在一般的应用场景中,两阶段加锁的策略并不通用。如果一个进程缺少资源就会半途中断并重新开始的方式是不可接受的。

    通信死锁

    我们上面一直讨论的是资源死锁,资源死锁是一种死锁类型,但并不是唯一类型,还有通信死锁,也就是两个或多个进程在发送消息时出现的死锁。进程 A 给进程 B 发了一条消息,然后进程 A 阻塞直到进程 B 返回响应。假设请求消息丢失了,那么进程 A 在一直等着回复,进程 B 也会阻塞等待请求消息到来,这时候就产生死锁

    尽管会产生死锁,但是这并不是一个资源死锁,因为 A 并没有占据 B 的资源。事实上,通信死锁并没有完全可见的资源。根据死锁的定义来说:每个进程因为等待其他进程引起的事件而产生阻塞,这就是一种死锁。相较于最常见的通信死锁,我们把上面这种情况称为通信死锁(communication deadlock)

    通信死锁不能通过调度的方式来避免,但是可以使用通信中一个非常重要的概念来避免:超时(timeout)。在通信过程中,只要一个信息被发出后,发送者就会启动一个定时器,定时器会记录消息的超时时间,如果超时时间到了但是消息还没有返回,就会认为消息已经丢失并重新发送,通过这种方式,可以避免通信死锁。

    但是并非所有网络通信发生的死锁都是通信死锁,也存在资源死锁,下面就是一个典型的资源死锁。

    当一个数据包从主机进入路由器时,会被放入一个缓冲区,然后再传输到另外一个路由器,再到另一个,以此类推直到目的地。缓冲区都是资源并且数量有限。如下图所示,每个路由器都有 10 个缓冲区(实际上有很多)。

    假如路由器 A 的所有数据需要发送到 B ,B 的所有数据包需要发送到 D,然后 D 的所有数据包需要发送到 A 。没有数据包可以移动,因为在另一端没有缓冲区可用,这就是一个典型的资源死锁。

    活锁

    某些情况下,当进程意识到它不能获取所需要的下一个锁时,就会尝试礼貌的释放已经获得的锁,然后等待非常短的时间再次尝试获取。可以想像一下这个场景:当两个人在狭路相逢的时候,都想给对方让路,相同的步调会导致双方都无法前进。

    现在假想有一对并行的进程用到了两个资源。它们分别尝试获取另一个锁失败后,两个进程都会释放自己持有的锁,再次进行尝试,这个过程会一直进行重复。很明显,这个过程中没有进程阻塞,但是进程仍然不会向下执行,这种状况我们称之为 活锁(livelock)

    饥饿

    与死锁和活锁的一个非常相似的问题是 饥饿(starvvation)。想象一下你什么时候会饿?一段时间不吃东西是不是会饿?对于进程来讲,最重要的就是资源,如果一段时间没有获得资源,那么进程会产生饥饿,这些进程会永远得不到服务。

    我们假设打印机的分配方案是每次都会分配给最小文件的进程,那么要打印大文件的进程会永远得不到服务,导致进程饥饿,进程会无限制的推后,虽然它没有阻塞。

    后记

    这篇文章到这里就结束了,后面我会继续写关于计算机网络、计算机基础、Java 相关、Java 架构相关的面试题。

    最后,你的支持是我继续肝文的动力。希望你能顺利进入大厂,加油!

    如果这篇文章对你有用,欢迎给我的 CSDN 账号点赞 + 关注哦!!!

    我自己肝了六本 PDF,全网传播超过10w+ ,你需要关注一下我的 CSDN 账号,私信回复 cxuan ,领取全部 PDF,这些 PDF 如下

    在这里插入图片描述

    展开全文
  • 目前apm监控一般都遵循Google公司发布的Dapper规范,特转载一篇,供广大网友交流概述当代的互联网的服务,通常都是用复杂的、规模分布式集群来实现的。互联网应用构建在不同的软件模块集上,这些软件模块,有可能...

    目前apm监控一般都遵循Google公司发布的Dapper规范,特转载一篇,供广大网友交流

    概述

    当代的互联网的服务,通常都是用复杂的、大规模分布式集群来实现的。互联网应用构建在不同的软件模块集上,这些软件模块,有可能是由不同的团队开发、可能使用不同的编程语言来实现、有可能布在了几千台服务器,横跨多个不同的数据中心。因此,就需要一些可以帮助理解系统行为、用于分析性能问题的工具。

    Dapper--Google生产环境下的分布式跟踪系统,应运而生。那么我们就来介绍一个大规模集群的跟踪系统,它是如何满足一个低损耗、应用透明的、大范围部署这三个需求的。当然Dapper设计之初,参考了一些其他分布式系统的理念,尤其是Magpie和X-Trace,但是我们之所以能成功应用在生产环境上,还需要一些画龙点睛之笔,例如采样率的使用以及把代码植入限制在一小部分公共库的改造上。

    自从Dapper发展成为一流的监控系统之后,给其他应用的开发者和运维团队帮了大忙,所以我们今天才发表这篇论文,来汇报一下这两年来,Dapper是怎么构建和部署的。Dapper最初只是作为一个自给自足的监控工具起步的,但最终进化成一个监控平台,这个监控平台促生出多种多样的监控工具,有些甚至已经不是由Dapper团队开发的了。下面我们会介绍一些使用Dapper搭建的分析工具,分享一下这些工具在google内部使用的统计数据,展现一些使用场景,最后会讨论一下我们迄今为止从Dapper收获了些什么。

    1. 介绍

    我们开发Dapper是为了收集更多的复杂分布式系统的行为信息,然后呈现给Google的开发者们。这样的分布式系统有一个特殊的好处,因为那些大规模的低端服务器,作为互联网服务的载体,是一个特殊的经济划算的平台。想要在这个上下文中理解分布式系统的行为,就需要监控那些横跨了不同的应用、不同的服务器之间的关联动作。

    下面举一个跟搜索相关的例子,这个例子阐述了Dapper可以应对哪些挑战。比如一个前段服务可能对上百台查询服务器发起了一个Web查询,每一个查询都有自己的Index。这个查询可能会被发送到多个的子系统,这些子系统分别用来处理广告、进行拼写检查或是查找一些像图片、视频或新闻这样的特殊结果。根据每个子系统的查询结果进行筛选,得到最终结果,最后汇总到页面上。我们把这种搜索模型称为“全局搜索”(universal search)。总的来说,这一次全局搜索有可能调用上千台服务器,涉及各种服务。而且,用户对搜索的耗时是很敏感的,而任何一个子系统的低效都导致导致最终的搜索耗时。如果一个工程师只能知道这个查询耗时不正常,但是他无从知晓这个问题到底是由哪个服务调用造成的,或者为什么这个调用性能差强人意。首先,这个工程师可能无法准确的定位到这次全局搜索是调用了哪些服务,因为新的服务、乃至服务上的某个片段,都有可能在任何时间上过线或修改过,有可能是面向用户功能,也有可能是一些例如针对性能或安全认证方面的功能改进。其次,你不能苛求这个工程师对所有参与这次全局搜索的服务都了如指掌,每一个服务都有可能是由不同的团队开发或维护的。再次,这些暴露出来的服务或服务器有可能同时还被其他客户端使用着,所以这次全局搜索的性能问题甚至有可能是由其他应用造成的。举个例子,一个后台服务可能要应付各种各样的请求类型,而一个使用效率很高的存储系统,比如Bigtable,有可能正被反复读写着,因为上面跑着各种各样的应用。

    上面这个案例中我们可以看到,对Dapper我们只有两点要求:无所不在的部署,持续的监控。无所不在的重要性不言而喻,因为在使用跟踪系统的进行监控时,即便只有一小部分没被监控到,那么人们对这个系统是不是值得信任都会产生巨大的质疑。另外,监控应该是7x24小时的,毕竟,系统异常或是那些重要的系统行为有可能出现过一次,就很难甚至不太可能重现。那么,根据这两个明确的需求,我们可以直接推出三个具体的设计目标:

    1.低消耗:跟踪系统对在线服务的影响应该做到足够小。在一些高度优化过的服务,即使一点点损耗也会很容易察觉到,而且有可能迫使在线服务的部署团队不得不将跟踪系统关停。

    2.应用级的透明:对于应用的程序员来说,是不需要知道有跟踪系统这回事的。如果一个跟踪系统想生效,就必须需要依赖应用的开发者主动配合,那么这个跟踪系统也太脆弱了,往往由于跟踪系统在应用中植入代码的bug或疏忽导致应用出问题,这样才是无法满足对跟踪系统“无所不在的部署”这个需求。面对当下想Google这样的快节奏的开发环境来说,尤其重要。

    3.延展性:Google至少在未来几年的服务和集群的规模,监控系统都应该能完全把控住。

    一个额外的设计目标是为跟踪数据产生之后,进行分析的速度要快,理想情况是数据存入跟踪仓库后一分钟内就能统计出来。尽管跟踪系统对一小时前的旧数据进行统计也是相当有价值的,但如果跟踪系统能提供足够快的信息反馈,就可以对生产环境下的异常状况做出快速反应。

    做到真正的应用级别的透明,这应该是当下面临的最挑战性的设计目标,我们把核心跟踪代码做的很轻巧,然后把它植入到那些无所不在的公共组件种,比如线程调用、控制流以及RPC库。使用自适应的采样率可以使跟踪系统变得可伸缩,并降低性能损耗,这些内容将在第4.4节中提及。结果展示的相关系统也需要包含一些用来收集跟踪数据的代码,用来图形化的工具,以及用来分析大规模跟踪数据的库和API。虽然单独使用Dapper有时就足够让开发人员查明异常的来源,但是Dapper的初衷不是要取代所有其他监控的工具。我们发现,Dapper的数据往往侧重性能方面的调查,所以其他监控工具也有他们各自的用处。

    1.1 文献的总结

    分布式系统跟踪工具的设计空间已经被一些优秀文章探索过了,其中的Pinpoint[9]、Magpie[3]和X-Trace[12]和Dapper最为相近。这些系统在其发展过程的早期倾向于写入研究报告中,即便他们还没来得及清楚地评估系统当中一些设计的重要性。相比之下,由于Dapper已经在大规模生产环境中摸爬滚打了多年,经过这么多生产环境的验证之后,我们认为这篇论文最适合重点阐述在部署Dapper的过程中我们有那些收获,我们的设计思想是如何决定的,以及以什么样的方式实现它才会最有用。Dappe作为一个平台,承载基于Dapper开发的性能分析工具,以及Dapper自身的监测工具,它的价值在于我们可以在回顾评估中找出一些意想不到的结果。

    虽然Dapper在许多高阶的设计思想上吸取了Pinpoint和Magpie的研究成果,但在分布式跟踪这个领域中,Dapper的实现包含了许多新的贡献。例如,我们想实现低损耗的话,特别是在高度优化的而且趋于极端延迟敏感的Web服务中,采样率是很必要的。或许更令人惊讶的是,我们发现即便是1/1000的采样率,对于跟踪数据的通用使用层面上,也可以提供足够多的信息。

    我们的系统的另一个重要的特征,就是我们能实现的应用级的透明。我们的组件对应用的侵入被先限制在足够低的水平上,即使想Google网页搜索这么大规模的分布式系统,也可以直接进行跟踪而无需加入额外的标注(Annotation)。虽然由于我们的部署系统有幸是一定程度的同质化的,所以更容易做到对应用层的透明这点,但是我们证明了这是实现这种程度的透明性的充分条件。

    2. Dapper的分布式跟踪

    图1:这个路径由用户的X请求发起,穿过一个简单的服务系统。用字母标识的节点代表分布式系统中的不同处理过程。

    分布式服务的跟踪系统需要记录在一次特定的请求后系统中完成的所有工作的信息。举个例子,图1展现的是一个和5台服务器相关的一个服务,包括:前端(A),两个中间层(B和C),以及两个后端(D和E)。当一个用户(这个用例的发起人)发起一个请求时,首先到达前端,然后发送两个RPC到服务器B和C。B会马上做出反应,但是C需要和后端的D和E交互之后再返还给A,由A来响应最初的请求。对于这样一个请求,简单实用的分布式跟踪的实现,就是为服务器上每一次你发送和接收动作来收集跟踪标识符(message identifiers)和时间戳(timestamped events)。

    为了将所有记录条目与一个给定的发起者(例如,图1中的RequestX)关联上并记录所有信息,现在有两种解决方案,黑盒(black-box)和基于标注(annotation-based)的监控方案。黑盒方案[1,15,2]假定需要跟踪的除了上述信息之外没有额外的信息,这样使用统计回归技术来推断两者之间的关系。基于标注的方案[3,12,9,16]依赖于应用程序或中间件明确地标记一个全局ID,从而连接每一条记录和发起者的请求。虽然黑盒方案比标注方案更轻便,他们需要更多的数据,以获得足够的精度,因为他们依赖于统计推论。基于标注的方案最主要的缺点是,很明显,需要代码植入。在我们的生产环境中,因为所有的应用程序都使用相同的线程模型,控制流和RPC系统,我们发现,可以把代码植入限制在一个很小的通用组件库中,从而实现了监测系统的应用对开发人员是有效地透明。

    我们倾向于认为,Dapper的跟踪架构像是内嵌在RPC调用的树形结构。然而,我们的核心数据模型不只局限于我们的特定的RPC框架,我们还能跟踪其他行为,例如Gmail的SMTP会话,外界的HTTP请求,和外部对SQL服务器的查询等。从形式上看,我们的Dapper跟踪模型使用的树形结构,Span以及Annotation。

    2.1 跟踪树和span

    在Dapper跟踪树结构中,树节点是整个架构的基本单元,而每一个节点又是对span的引用。节点之间的连线表示的span和它的父span直接的关系。虽然span在日志文件中只是简单的代表span的开始和结束时间,他们在整个树形结构中却是相对独立的,任何RPC相关的时间数据、零个或多个特定应用程序的Annotation的相关内容会在2.3节中讨论。

    图2:5个span在Dapper跟踪树种短暂的关联关系

    在图2中说明了span在一个大的跟踪过程中是什么样的。Dapper记录了span名称,以及每个span的ID和父ID,以重建在一次追踪过程中不同span之间的关系。如果一个span没有父ID被称为root span。所有span都挂在一个特定的跟踪上,也共用一个跟踪id(在图中未示出)。所有这些ID用全局唯一的64位整数标示。在一个典型的Dapper跟踪中,我们希望为每一个RPC对应到一个单一的span上,而且每一个额外的组件层都对应一个跟踪树型结构的层级。

    图3:在图2中所示的一个单独的span的细节图

    图3给出了一个更详细的典型的Dapper跟踪span的记录点的视图。在图2中这种某个span表述了两个“Helper.Call”的RPC(分别为server端和client端)。span的开始时间和结束时间,以及任何RPC的时间信息都通过Dapper在RPC组件库的植入记录下来。如果应用程序开发者选择在跟踪中增加他们自己的注释(如图中“foo”的注释)(业务数据),这些信息也会和其他span信息一样记录下来。

    记住,任何一个span可以包含来自不同的主机信息,这些也要记录下来。事实上,每一个RPC span可以包含客户端和服务器两个过程的注释,使得链接两个主机的span会成为模型中所说的span。由于客户端和服务器上的时间戳来自不同的主机,我们必须考虑到时间偏差。在我们的分析工具,我们利用了这个事实:RPC客户端发送一个请求之后,服务器端才能接收到,对于响应也是一样的(服务器先响应,然后客户端才能接收到这个响应)。这样一来,服务器端的RPC就有一个时间戳的一个上限和下限。

    2.2 植入点

    Dapper可以以对应用开发者近乎零浸入的成本对分布式控制路径进行跟踪,几乎完全依赖于基于少量通用组件库的改造。如下:

    • 当一个线程在处理跟踪控制路径的过程中,Dapper把这次跟踪的上下文的在ThreadLocal中进行存储。追踪上下文是一个小而且容易复制的容器,其中承载了Scan的属性比如跟踪ID和span ID。
    • 当计算过程是延迟调用的或是异步的,大多数Google开发者通过线程池或其他执行器,使用一个通用的控制流库来回调。Dapper确保所有这样的回调可以存储这次跟踪的上下文,而当回调函数被触发时,这次跟踪的上下文会与适当的线程关联上。在这种方式下,Dapper可以使用trace ID和span ID来辅助构建异步调用的路径。
    • 几乎所有的Google的进程间通信是建立在一个用C++和Java开发的RPC框架上。我们把跟踪植入该框架来定义RPC中所有的span。span的ID和跟踪的ID会从客户端发送到服务端。像那样的基于RPC的系统被广泛使用在Google中,这是一个重要的植入点。当那些非RPC通信框架发展成熟并找到了自己的用户群之后,我们会计划对RPC通信框架进行植入。

    Dapper的跟踪数据是独立于语言的,很多在生产环境中的跟踪结合了用C++和Java写的进程的数据。在3.2节中,我们讨论应用程序的透明度时我们会把这些理论的是如何实践的进行讨论。

    2.3 Annotation

    上述植入点足够推导出复杂的分布式系统的跟踪细节,使得Dapper的核心功能在不改动Google应用的情况下可用。然而,Dapper还允许应用程序开发人员在Dapper跟踪的过程中添加额外的信息,以监控更高级别的系统行为,或帮助调试问题。我们允许用户通过一个简单的API定义带时间戳的Annotation,核心的示例代码入图4所示。这些Annotation可以添加任意内容。为了保护Dapper的用户意外的过分热衷于日志的记录,每一个跟踪span有一个可配置的总Annotation量的上限。但是,应用程序级的Annotation是不能替代用于表示span结构的信息和记录着RPC相关的信息。

    除了简单的文本Annotation,Dapper也支持的key-value映射的 Annotation,提供给开发人员更强的跟踪能力,如持续的计数器,二进制消息记录和在一个进程上跑着的任意的用户数据。键值对的Annotation方式用来在分布式追踪的上下文中定义某个特定应用程序的相关类型。

    2.4 采样率

    低损耗的是Dapper的一个关键的设计目标,因为如果这个工具价值未被证实但又对性能有影响的话,你可以理解服务运营人员为什么不愿意部署它。况且,我们想让开发人员使用Annotation的API,而不用担心额外的开销。我们还发现,某些类型的Web服务对植入带来的性能损耗确实非常敏感。因此,除了把Dapper的收集工作对基本组件的性能损耗限制的尽可能小之外,我们还有进一步控制损耗的办法,那就是遇到大量请求时只记录其中的一小部分。我们将在4.4节中讨论跟踪的采样率方案的更多细节。

    图5:Dapper收集管道的总览

    2.5 跟踪的收集

    Dapper的跟踪记录和收集管道的过程分为三个阶段(参见图5)。首先,span数据写入(1)本地日志文件中。然后Dapper的守护进程和收集组件把这些数据从生产环境的主机中拉出来(2),最终写到(3)Dapper的Bigtable仓库中。一次跟踪被设计成Bigtable中的一行,每一列相当于一个span。Bigtable的支持稀疏表格布局正适合这种情况,因为每一次跟踪可以有任意多个span。跟踪数据收集(即从应用中的二进制数据传输到中央仓库所花费的时间)的延迟中位数少于15秒。第98百分位的延迟(The 98th percentile latency)往往随着时间的推移呈现双峰型;大约75%的时间,第98百分位的延迟时间小于2分钟,但是另外大约25%的时间,它可以增涨到几个小时。

    Dapper还提供了一个API来简化访问我们仓库中的跟踪数据。 Google的开发人员用这个API,以构建通用和特定应用程序的分析工具。第5.1节包含更多如何使用它的信息。

    2.5.1 带外数据跟踪收集

    tip1:带外数据:传输层协议使用带外数据(out-of-band,OOB)来发送一些重要的数据,如果通信一方有重要的数据需要通知对方时,协议能够将这些数据快速地发送到对方。为了发送这些数据,协议一般不使用与普通数据相同的通道,而是使用另外的通道。

    tip2:这里指的in-band策略是把跟踪数据随着调用链进行传送,out-of-band是通过其他的链路进行跟踪数据的收集,Dapper的写日志然后进行日志采集的方式就属于out-of-band策略

    Dapper系统请求树树自身进行跟踪记录和收集带外数据。这样做是为两个不相关的原因。首先,带内收集方案--这里跟踪数据会以RPC响应头的形式被返回--会影响应用程序网络动态。在Google里的许多规模较大的系统中,一次跟踪成千上万的span并不少见。然而,RPC回应大小--甚至是接近大型分布式的跟踪的根节点的这种情况下-- 仍然是比较小的:通常小于10K。在这种情况下,带内Dapper的跟踪数据会让应用程序数据和倾向于使用后续分析结果的数据量相形见绌。其次,带内收集方案假定所有的RPC是完美嵌套的。我们发现,在所有的后端的系统返回的最终结果之前,有许多中间件会把结果返回给他们的调用者。带内收集系统是无法解释这种非嵌套的分布式执行模式的。

    2.6 安全和隐私考虑

    记录一定量的RPC有效负载信息将丰富Dapper的跟踪能力,因为分析工具能够在有效载荷数据(方法传递的参数)中找到相关的样例,这些样例可以解释被监控系统的为何表现异常。然而,有些情况下,有效载荷数据可能包含的一些不应该透露给未经授权用户(包括正在debug的工程师)的内部信息。

    由于安全和隐私问题是不可忽略的,dapper中的虽然存储RPC方法的名称,但在这个时候不记录任何有效载荷数据。相反,应用程序级别的Annotation提供了一个方便的可选机制:应用程序开发人员可以在span中选择关联那些为以后分析提供价值的数据。

    Dapper还提供了一些安全上的便利,是它的设计者事先没有预料到的。通过跟踪公开的安全协议参数,Dapper可以通过相应级别的认证或加密,来监视应用程序是否满足安全策略。例如。Dapper还可以提供信息,以基于策略的的隔离系统按预期执行,例如支撑敏感数据的应用程序不与未经授权的系统组件进行了交互。这样的测算提供了比源码审核更强大的保障。

    3. Dapper部署状况

    Dapper作为我们生产环境下的跟踪系统已经超过两年。在本节中,我们会汇报系统状态,把重点放在Dapper如何满足了我们的目标——无处不在的部署和应用级的透明。

    3.1 Dapper运行库

    也许Dapper代码中中最关键的部分,就是对基础RPC、线程控制和流程控制的组件库的植入,其中包括span的创建,采样率的设置,以及把日志写入本地磁盘。除了做到轻量级,植入的代码更需要稳定和健壮,因为它与海量的应用对接,维护和bug修复变得困难。植入的核心代码是由未超过1000行的C++和不超过800行Java代码组成。为了支持键值对的Annotation还添加了额外的500行代码。

    3.2 生产环境下的涵盖面

    Dapper的渗透可以总结为两个方面:一方面是可以创建Dapper跟踪的过程(与Dapper植入的组件库相关),和生产环境下的服务器上在运行Dapper跟踪收集守护进程。Dapper的守护进程的分布相当于我们服务器的简单的拓扑图,它存在于Google几乎所有的服务器上。这很难确定精确的Dapper-ready进程部分,因为过程即便不产生跟踪信息Dapper也是无从知晓的。尽管如此,考虑到无处不在Dapper组件的植入库,我们估计几乎每一个Google的生产进程都是支持跟踪的。

    在某些情况下Dapper的是不能正确的跟踪控制路径的。这些通常源于使用非标准的控制流,或是Dapper的错误的把路径关联归到不相关的事件上。Dapper提供了一个简单的库来帮助开发者手动控制跟踪传播作为一种变通方法。目前有40个C++应用程序和33个Java应用程序需要一些手动控制的追踪传播,不过这只是上千个的跟踪中的一小部分。也有非常小的一部分程序使用的非组件性质的通信库(比如原生的TCP Socket或SOAP RPC),因此不能直接支持Dapper的跟踪。但是这些应用可以单独接入到Dapper中,如果需要的话。

    考虑到生产环境的安全,Dapper的跟踪也可以关闭。事实上,它在部署的早起就是默认关闭的,直到我们对Dapper的稳定性和低损耗有了足够的信心之后才把它开启。Dapper的团队偶尔会执行审查寻找跟踪配置的变化,来看看那些服务关闭了Dapper的跟踪。但这种情况不多见,而且通常是源于对监控对性能消耗的担忧。经过了对实际性能消耗的进一步调查和测量,所有这些关闭Dapper跟踪都已经恢复开启了,不过这些已经不重要了。

    3.3 跟踪Annotation的使用

    程序员倾向于使用特定应用程序的Annotation,无论是作为一种分布式调试日志文件,还是通过一些应用程序特定的功能对跟踪进行分类。例如,所有的Bigtable的请求会把被访问的表名也记录到Annotation中。目前,70%的Dapper span和90%的所有Dapper跟踪都至少有一个特殊应用的Annotation。

    41个Java应用和68个C++应用中都添加自定义的Annotation为了更好地理解应用程序中的span在他们的服务中的行为。值得注意的是,迄今为止我们的Java开发者比C++开发者更多的在每一个跟踪span上采用Annotation的API。这可能是因为我们的Java应用的作用域往往是更接近最终用户(C++偏底层);这些类型的应用程序经常处理更广泛的请求组合,因此具有比较复杂的控制路径。

    4. 处理跟踪损耗

    跟踪系统的成本由两部分组成:1.正在被监控的系统在生成追踪和收集追踪数据的消耗导致系统性能下降,2。需要使用一部分资源来存储和分析跟踪数据。虽然你可以说一个有价值的组件植入跟踪带来一部分性能损耗是值得的,我们相信如果基本损耗能达到可以忽略的程度,那么对跟踪系统最初的推广会有极大的帮助。

    在本节中,我们会展现一下三个方面:Dapper组件操作的消耗,跟踪收集的消耗,以及Dapper对生产环境负载的影响。我们还介绍了Dapper可调节的采样率机制如何帮我们处理低损耗和跟踪代表性之间的平衡和取舍。

    4.1 生成跟踪的损耗

    生成跟踪的开销是Dapper性能影响中最关键的部分,因为收集和分析可以更容易在紧急情况下被关闭。Dapper运行库中最重要的跟踪生成消耗在于创建和销毁span和annotation,并记录到本地磁盘供后续的收集。根span的创建和销毁需要损耗平均204纳秒的时间,而同样的操作在其他span上需要消耗176纳秒。时间上的差别主要在于需要在跟span上给这次跟踪分配一个全局唯一的ID。

    如果一个span没有被采样的话,那么这个额外的span下创建annotation的成本几乎可以忽略不计,他由在Dapper运行期对ThreadLocal查找操作构成,这平均只消耗9纳秒。如果这个span被计入采样的话,会用一个用字符串进行标注--在图4中有展现--平均需要消耗40纳秒。这些数据都是在2.2GHz的x86服务器上采集的。

    在Dapper运行期写入到本地磁盘是最昂贵的操作,但是他们的可见损耗大大减少,因为写入日志文件和操作相对于被跟踪的应用系统来说都是异步的。不过,日志写入的操作如果在大流量的情况,尤其是每一个请求都被跟踪的情况下就会变得可以察觉到。我们记录了在4.3节展示了一次Web搜索的负载下的性能消耗。

    4.2 跟踪收集的消耗

    读出跟踪数据也会对正在被监控的负载产生干扰。表1展示的是最坏情况下,Dapper收集日志的守护进程在高于实际情况的负载基准下进行测试时的cpu使用率。在生产环境下,跟踪数据处理中,这个守护进程从来没有超过0.3%的单核cpu使用率,而且只有很少量的内存使用(以及堆碎片的噪音)。我们还限制了Dapper守护进程为内核scheduler最低的优先级,以防在一台高负载的服务器上发生cpu竞争。

    Dapper也是一个带宽资源的轻量级的消费者,每一个span在我们的仓库中传输只占用了平均426的byte。作为网络行为中的极小部分,Dapper的数据收集在Google的生产环境中的只占用了0.01%的网络资源。

    表1:Dapper守护进程在负载测试时的CPU资源使用率

    4.3 在生产环境下对负载的影响

    每个请求都会利用到大量的服务器的高吞吐量的线上服务,这是对有效跟踪最主要的需求之一;这种情况需要生成大量的跟踪数据,并且他们对性能的影响是最敏感的。在表2中我们用集群下的网络搜索服务作为例子,我们通过调整采样率,来衡量Dapper在延迟和吞吐量方面对性能的影响。

    表2:网络搜索集群中,对不同采样率对网络延迟和吞吐的影响。延迟和吞吐的实验误差分别是2.5%和0.15%。

    我们看到,虽然对吞吐量的影响不是很明显,但为了避免明显的延迟,跟踪的采样还是必要的。然而,延迟和吞吐量的带来的损失在把采样率调整到小于1/16之后就全部在实验误差范围内。在实践中,我们发现即便采样率调整到1/1024仍然是有足够量的跟踪数据的用来跟踪大量的服务。保持Dapper的性能损耗基线在一个非常低的水平是很重要的,因为它为那些应用提供了一个宽松的环境使用完整的Annotation API而无惧性能损失。使用较低的采样率还有额外的好处,可以让持久化到硬盘中的跟踪数据在垃圾回收机制处理之前保留更长的时间,这样为Dapper的收集组件给了更多的灵活性。

    4.4 可变采样

    任何给定进程的Dapper的消耗和每个进程单位时间的跟踪的采样率成正比。Dapper的第一个生产版本在Google内部的所有进程上使用统一的采样率,为1/1024。这个简单的方案是对我们的高吞吐量的线上服务来说是非常有用,因为那些感兴趣的事件(在大吞吐量的情况下)仍然很有可能经常出现,并且通常足以被捕捉到。

    然而,在较低的采样率和较低的传输负载下可能会导致错过重要事件,而想用较高的采样率就需要能接受的性能损耗。对于这样的系统的解决方案就是覆盖默认的采样率,这需要手动干预的,这种情况是我们试图避免在dapper中出现的。

    我们在部署可变采样的过程中,参数化配置采样率时,不是使用一个统一的采样方案,而是使用一个采样期望率来标识单位时间内采样的追踪。这样一来,低流量低负载自动提高采样率,而在高流量高负载的情况下会降低采样率,使损耗一直保持在控制之下。实际使用的采样率会随着跟踪本身记录下来,这有利于从Dapper的跟踪数据中准确的分析。

    4.5 应对积极采样(Coping with aggressive sampling)

    新的Dapper用户往往觉得低采样率--在高吞吐量的服务下经常低至0.01%--将会不利于他们的分析。我们在Google的经验使我们相信,对于高吞吐量服务,积极采样(aggressive sampling)并不妨碍最重要的分析。如果一个显着的操作在系统中出现一次,他就会出现上千次。低吞吐量的服务--也许是每秒请求几十次,而不是几十万--可以负担得起跟踪每一个请求,这是促使我们下决心使用自适应采样率的原因。

    4.6 在收集过程中额外的采样

    上述采样机制被设计为尽量减少与Dapper运行库协作的应用程序中明显的性能损耗。Dapper的团队还需要控制写入中央资料库的数据的总规模,因此为达到这个目的,我们结合了二级采样。

    目前我们的生产集群每天产生超过1TB的采样跟踪数据。Dapper的用户希望生产环境下的进程的跟踪数据从被记录之后能保存至少两周的时间。逐渐增长的追踪数据的密度必须和Dapper中央仓库所消耗的服务器及硬盘存储进行权衡。对请求的高采样率还使得Dapper收集器接近写入吞吐量的上限。

    为了维持物质资源的需求和渐增的Bigtable的吞吐之间的灵活性,我们在收集系统自身上增加了额外的采样率的支持。我们充分利用所有span都来自一个特定的跟踪并分享同一个跟踪ID这个事实,虽然这些span有可能横跨了数千个主机。对于在收集系统中的每一个span,我们用hash算法把跟踪ID转成一个标量Z,这里0<=Z<=1。如果Z比我们收集系统中的系数低的话,我们就保留这个span信息,并写入到Bigtable中。反之,我们就抛弃他。通过在采样决策中的跟踪ID,我们要么保存、要么抛弃整个跟踪,而不是单独处理跟踪内的span。我们发现,有了这个额外的配置参数使管理我们的收集管道变得简单多了,因为我们可以很容易地在配置文件中调整我们的全局写入率这个参数。

    如果整个跟踪过程和收集系统只使用一个采样率参数确实会简单一些,但是这就不能应对快速调整在所有部署的节点上的运行期采样率配置的这个要求。我们选择了运行期采样率,这样就可以优雅的去掉我们无法写入到仓库中的多余数据,我们还可以通过调节收集系统中的二级采样率系数来调整这个运行期采样率。Dapper的管道维护变得更容易,因为我们就可以通过修改我们的二级采样率的配置,直接增加或减少我们的全局覆盖率和写入速度。

    5. 通用的Dapper工具

    几年前,当Dapper还只是个原型的时候,它只能在Dapper开发者耐心的支持下使用。从那时起,我们逐渐迭代的建立了收集组件,编程接口,和基于Web的交互式用户界面,帮助Dapper的用户独立解决自己的问题。在本节中,我们会总结一下哪些的方法有用,哪些用处不大,我们还提供关于这些通用的分析工具的基本的使用信息。

    5.1 Dapper Depot API

    Dapper的“Depot API”或称作DAPI,提供在Dapper的区域仓库中对分布式跟踪数据一个直接访问。DAPI和Dapper跟踪仓库被设计成串联的,而且DAPI意味着对Dapper仓库中的元数据暴露一个干净和直观的的接口。我们使用了以下推荐的三种方式去暴露这样的接口:

    • 通过跟踪ID来访问:DAPI可以通过他的全局唯一的跟踪ID读取任何一次跟踪信息。
    • 批量访问:DAPI可以利用的MapReduce提供对上亿条Dapper跟踪数据的并行读取。用户重写一个虚拟函数,它接受一个Dapper的跟踪信息作为其唯一的参数,该框架将在用户指定的时间窗口中调用每一次收集到的跟踪信息。
    • 索引访问:Dapper的仓库支持一个符合我们通用调用模板的唯一索引。该索引根据通用请求跟踪特性(commonly-requested trace features)进行绘制来识别Dapper的跟踪信息。因为跟踪ID是根据伪随机的规则创建的,这是最好的办法去访问跟某个服务或主机相关的跟踪数据。

    所有这三种访问模式把用户指向不同的Dapper跟踪记录。正如第2.1节所述的,Dapper的由span组成的跟踪数据是用树形结构建模的,因此,跟踪数据的数据结构,也是一个简单的由span组成遍历树。Span就相当于RPC调用,在这种情况下,RPC的时间信息是可用的。带时间戳的特殊的应用标注也是可以通过这个span结构来访问的。

    选择一个合适的自定义索引是DAPI设计中最具挑战性的部分。压缩存储要求在跟踪数据种建立一个索引的情况只比实际数据小26%,所以消耗是巨大的。最初,我们部署了两个索引:第一个是主机索引,另一个是服务名的索引。然而,我们并没有找到主机索引和存储成本之间的利害关系。当用户对每一台主机感兴趣的时候,他们也会对特定的服务感兴趣,所以我们最终选择把两者相结合,成为一个组合索引,它允许以服务名称,主机,和时间戳的顺序进行有效的查找。

    5.1.1 DAPI在Google内部的使用

    DAPI在谷歌的使用有三类:使利用DAPI的持续的线上Web应用,维护良好的可以在控制台上调用的基于DAPI的工具,可以被写入,运行、不过大部分已经被忘记了的一次性分析工具。我们知道的有3个持久性的基于DAPI的应用程序,8个额外的按需定制的基于DAPI分析工具,以及使用DAPI框架构建的约15~20一次性的分析工具。在这之后的工具就这是很难说明了,因为开发者可以构建、运行和丢弃这些项目,而不需要Dapper团队的技术支持。

    5.2 Dapper的用户接口

    绝大多数用户使用发生在基于web的用户交互接口。篇幅有限,我们不能列出每一个特点,而只能把典型的用户工作流在图6中展示。

    图6

    1. 用户描述的他们关心的服务和时间,和其他任何他们可以用来区分跟踪模板的信息(比如,span的名称)。他们还可以指定与他们的搜索最相关的成本度量(cost metric)(比如,服务响应时间)。
    2. 一个关于性能概要的大表格,对应确定的服务关联的所有分布式处理图表。用户可以把这些执行图标排序成他们想要的,并选择一种直方图去展现出更多的细节。
    3. 一旦某个单一的分布式执行部分被选中后,用户能看到关于执行部分的的图形化描述。被选中的服务被高亮展示在该图的中心。
    4. 在生成与步骤1中选中的成本度量(cost metric)维度相关的统计信息之后,Dapper的用户界面会提供了一个简单的直方图。在这个例子中,我们可以看到一个大致的所选中部分的分布式响应时间分布图。用户还会看到一个关于具体的跟踪信息的列表,展现跟踪信息在直方图中被划分为的不同区域。在这个例子中,用户点击列表种第二个跟踪信息实例时,会在下方看到这个跟踪信息的详细视图(步骤5)。
    5. 绝大多数Dapper的使用者最终的会检查某个跟踪的情况,希望能收集一些信息去了解系统行为的根源所在。我们没有足够的空间来做跟踪视图的审查,但我们使用由一个全局时间轴(在上方可以看到),并能够展开和折叠树形结构的交互方式,这也很有特点。分布式跟踪树的连续层用内嵌的不同颜色的矩形表示。每一个RPC的span被从时间上分解为一个服务器进程中的消耗(绿色部分)和在网络上的消耗(蓝色部分)。用户Annotation没有显示在这个截图中,但他们可以选择性的以span的形式包含在全局时间轴上。

    为了让用户查询实时数据,Dapper的用户界面能够直接与Dapper每一台生产环境下的服务器上的守护进程进行交互。在该模式下,不可能指望能看到上面所说的系统级的图表展示,但仍然可以很容易基于性能和网络特性选取一个特定的跟踪。在这种模式下,可在几秒钟内查到实时的数据。

    根据我们的记录,大约有200个不同的Google工程师在一天内使用的Dapper的UI;在一周的过程中,大约有750-1000不同的用户。这些用户数,在新功能的内部通告上,是按月连续的。通常用户会发送特定跟踪的连接,这将不可避免地在查询跟踪情况时中产生很多一次性的,持续时间较短的交互。

    6. 经验

    Dapper在Google被广泛应用,一部分直接通过Dapper的用户界面,另一部分间接地通过对Dapper API的二次开发或者建立在基于api的应用上。在本节中,我们并不打算罗列出每一种已知的Dapper使用方式,而是试图覆盖Dapper使用方式的“基本向量”,并努力来说明什么样的应用是最成功的。

    6.1 在开发中使用Dapper

    Google AdWords系统是围绕一个大型的关键词定位准则和相关文字广告的数据库搭建的。当新的关键字或广告被插入或修改时,它们必须通过服务策略术语的检查(如检查不恰当的语言,这个过程如果使用自动复查系统来做的话会更加有效)。

    当轮到从头重新设计一个广告审查服务时,这个团队迭代的从第一个系统原型开始使用Dapper,并且,最终用Dapper一直维护着他们的系统。Dapper帮助他们从以下几个方面改进了他们的服务:

    • 性能:开发人员针对请求延迟的目标进行跟踪,并对容易优化的地方进行定位。Dapper也被用来确定在关键路径上不必要的串行请求--通常来源于不是开发者自己开发的子系统--并促使团队持续修复他们。
    • 正确性:广告审查服务围绕大型数据库系统搭建。系统同时具有只读副本策略(数据访问廉价)和读写的主策略(访问代价高)。Dapper被用来在很多种情况中确定,哪些查询是无需通过主策略访问而可以采用副本策略访问。Dapper现在可以负责监控哪些主策略被直接访问,并对重要的系统常量进行保障。
    • 理解性:广告审查查询跨越了各种类型的系统,包括BigTable—之前提到的那个数据库,多维索引服务,以及其他各种C++和Java后端服务。Dapper的跟踪用来评估总查询成本,促进重新对业务的设计,用以在他们的系统依赖上减少负载。
    • 测试:新的代码版本会经过一个使用Dapper进行跟踪的QA过程,用来验证正确的系统行为和性能。在跑测试的过程中能发现很多问题,这些问题来自广告审查系统自身的代码或是他的依赖包。

    广告审查团队广泛使用了Dapper Annotation API。Guice[13]开源的AOP框架用来在重要的软件组件上标注“@Traced”。这些跟踪信息可以进一步被标注,包含:重要子路径的输入输出大小、基础信息、其他调试信息,所有这些信息将会额外发送到日志文件中。

    同时,我们也发现了一些广告审查小组在使用方面的不足。比如:他们想根据他们所有跟踪的Annotation信息,在一个交互时间段内进行搜索,然而这就必须跑一个自定义的MapReduce或进行每一个跟踪的手动检查。另外,在Google还有一些其他的系统在也从通用调试日志中收集和集中信息,把那些系统的海量数据和Dapper仓库整合也是有价值的。

    总的来说,即便如此,广告审查团队仍然对Dapper的作用进行了以下评估,通过使用Dapper的跟踪平台的数据分析,他们的服务延迟性已经优化了两个数量级。

    6.1.1 与异常监控的集成

    Google维护了一个从运行进程中不断收集并集中异常信息报告的服务。如果这些异常发生在Dapper跟踪采样的上下文中,那么相应的跟踪ID和span的ID也会作为元数据记录在异常报告中。异常监测服务的前端会提供一个链接,从特定的异常信息的报告直接导向到他们各自的分布式跟踪。广告审查团队使用这个功能可以了解bug发生的更大范围的上下文。通过暴露基于简单的唯一ID构建的接口,Dapper平台被集成到其他事件监测系统会相对容易。

    6.2 解决延迟的长尾效应

    考虑到移动部件的数量、代码库的规模、部署的范围,调试一个像全文搜索那样服务(第1节里提到过)是非常具有挑战性的。在这节,我们描述了我们在减轻全文搜索的延迟分布的长尾效应上做的各种努力。Dapper能够验证端到端的延迟的假设,更具体地说,Dapper能够验证对于搜索请求的关键路径。当一个系统不仅涉及数个子系统,而是几十个开发团队的涉及到的系统的情况下,端到端性能较差的根本原因到底在哪,这个问题即使是我们最好的和最有经验的工程师也无法正确回答。在这种情况下,Dapper可以提供急需的数据,而且可以对许多重要的性能问题得出结论。

    图7:全局搜索的跟踪片段,在不常遇到高网络延迟的情况下,在沿着关键路径的端到端的请求延迟,如图所示。

    在调试延迟长尾效应的过程中,工程师可以建立一个小型库,这个小型库可以根据DAPI跟踪对象来推断关键路径的层级结构。这些关键路径的结构可以被用来诊断问题,并且为全文搜索提供可优先处理的预期的性能改进。Dapper的这项工作导致了下列发现:

    • 在关键路径上的短暂的网络性能退化不影响系统的吞吐量,但它可能会对延迟异常值产生极大的影响。在图7中可以看出,大部分的全局搜索的缓慢的跟踪都来源于关键路径的网络性能退化。
    • 许多问题和代价很高的查询模式来源于一些意想不到的服务之间的交互。一旦发现,往往容易纠正它们,但是Dapper出现之前想找出这些问题是相当困难的。
    • 通用的查询从Dapper之外的安全日志仓库中收取,并使用Dapper唯一的跟踪ID,与Dapper的仓库做关联。然后,该映射用来建立关于在全局搜索中的每一个独立子系统都很慢的实例查询的列表。

    6.3 推断服务依赖

    在任何给定的时间内,Google内部的一个典型的计算集群是一个汇集了成千上万个逻辑“任务”的主机,一套的处理器在执行一个通用的方法。Google维护着许多这样的集群,当然,事实上,我们发现在一个集群上计算着的这些任务通常依赖于其他的集群上的任务。由于任务们之间的依赖是动态改变的,所以不可能仅从配置信息上推断出所有这些服务之间的依赖关系。不过,除了其他方面的原因之外,在公司内部的各个流程需要准确的服务依赖关系信息,以确定瓶颈所在,以及计划服务的迁移。Google的可称为“Service Dependencies”的项目是通过使用跟踪Annotation和DAPI MapReduce接口来实现自动化确定服务依赖归属的。

    Dapper核心组件与Dapper跟踪Annotation一并使用的情况下,“Service Dependencies”项目能够推算出任务各自之间的依赖,以及任务和其他软件组件之间的依赖。比如,所有的BigTable的操作会加上与受影响的表名称相关的标记。运用Dapper的平台,Service Dependencies团队就可以自动的推算出依赖于命名的不同资源的服务粒度。

    6.4 不同服务的网络使用率

    Google投入了大量的人力和物力资源在他的网络结构上。从前网络管理员可能只关注独立的硬件信息、常用工具及以及搭建出的各种全局网络鸟瞰图的dashboard上的信息。网络管理员确实可以一览整个网络的健康状况,但是,当遇到问题时,他们很少有能够准确查找网络负载的工具,用来定位应用程序级别的罪魁祸首。

    虽然Dapper不是设计用来做链路级的监控的,但是我们发现,它是非常适合去做集群之间网络活动性的应用级任务的分析。Google能够利用Dapper这个平台,建立一个不断更新的控制台,来显示集群之间最活跃的网络流量的应用级的热点。此外,使用Dapper我们能够为昂贵的网络请求提供指出的构成原因的跟踪,而不是面对不同服务器之间的信息孤岛而无所适从。建立一个基于Dapper API的dashboard总共没花超过2周的时间。

    6.5 分层和共享存储系统

    在Google的许多存储系统是由多重独立复杂层级的分布式基础设备组成的。例如,Google的App Engine[5]就是搭建在一个可扩展的实体存储系统上的。该实体存储系统在基于BigTable上公开某些RDBMS功能。 BigTable的同时使用Chubby[7](分布式锁系统)及GFS。再者,像BigTable这样的系统简化了部署,并更好的利用了计算资源。

    在这种分层的系统,并不总是很容易确定最终用户资源的消费模式。例如,来自于一个给定的BigTable单元格的GFS大信息量主要来自于一个用户或是由多个用户产生,但是在GFS层面,这两种明显的使用场景是很难界定。而且,如果缺乏一个像Dapper一样的工具的情况下,对共享服务的竞争可能会同样难于调试。

    第5.2节中所示的Dapper的用户界面可以聚合那些调用任意公共服务的多个客户端的跟踪的性能信息。这就很容易让提供这些服务的源从多个维度给他们的用户排名。(例如,入站的网络负载,出站的网络负载,或服务请求的总时间)

    6.6 Dapper的救火能力(Firefighting)

    对于一些“救火”任务,Dapper可以处理其中的一部分。“救火”任务在这里是指一些有风险很高的在分布式系统上的操作。通常情况下,Dapper用户当正在进行“救火”任务时需要使用新的数据,并且没有时间写新的DAPI代码或等待周期性的报告运行。

    对于那些高延迟,不,可能更糟糕的那些在正常负载下都会响应超时的服务,Dapper用户界面通常会把这些延迟瓶颈的位置隔离出来。通过与Dapper守护进程的直接通信,那些特定的高延迟的跟踪数据轻易的收集到。当出现灾难性故障时,通常是没有必要去看统计数据以确定根本原因,只查看示例跟踪就足够了(因为前文提到过从Dapper守护进程中几乎可以立即获得跟踪数据)。

    但是,如在6.5节中描述的共享的存储服务,要求当用户活动过程中突然中断时能尽可能快的汇总信息。对于事件发生之后,共享服务仍然可以利用汇总的的Dapper数据,但是,除非收集到的Dapper数据的批量分析能在问题出现10分钟之内完成,否则Dapper面对与共享存储服务相关的“救火”任务就很难按预想的那般顺利完成。

    7. 其他收获

    虽然迄今为止,我们在Dapper上的经验已经大致符合我们的预期,但是也出现了一些积极的方面是我们没有充分预料到的。首先,我们获得了超出预期的Dapper使用用例的数量,对此我们可谓欢心鼓舞。另外,在除了几个的在第6节使用经验中提到过的一些用例之外,还包括资源核算系统,对指定的通讯模式敏感的服务的检查工具,以及一种对RPC压缩策略的分析器,等等。我们认为这些意想不到的用例一定程度上是由于我们向开发者以一种简单的编程接口的方式开放了跟踪数据存储的缘故,这使得我们能够充分利用这个大的多的社区的创造力。除此之外,Dapper对旧的负载的支持也比预期的要简单,只需要在程序中引入一个用新版本的重新编译过的公共组件库(包含常规的线程使用,控制流和RPC框架)即可。

    Dapper在Google内部的广泛使用还为我们在Dapper的局限性上提供了宝贵的反馈意见。下面我们将介绍一些我们已知的最重要的Dapper的不足:

    • 合并的影响:我们的模型隐含的前提是不同的子系统在处理的都是来自同一个被跟踪的请求。在某些情况下,缓冲一部分请求,然后一次性操作一个请求集会更加有效。(比如,磁盘上的一次合并写入操作)。在这种情况下,一个被跟踪的请求可以看似是一个大型工作单元。此外,当有多个追踪请求被收集在一起,他们当中只有一个会用来生成那个唯一的跟踪ID,用来给其他span使用,所以就无法跟踪下去了。我们正在考虑的解决方案,希望在可以识别这种情况的前提下,用尽可能少的记录来解决这个问题。
    • 跟踪批处理负载:Dapper的设计,主要是针对在线服务系统,最初的目标是了解一个用户请求产生的系统行为。然而,离线的密集型负载,例如符合MapReduce[10]模型的情况,也可以受益于性能挖潜。在这种情况下,我们需要把跟踪ID与一些其他的有意义的工作单元做关联,诸如输入数据中的键值(或键值的范围),或是一个MapReduce shard。
    • 寻找根源:Dapper可以有效地确定系统中的哪一部分致使系统整个速度变慢,但并不总是能够找出问题的根源。例如,一个请求很慢有可能不是因为它自己的行为,而是由于队列中其他排在它前面的(queued ahead of)请求还没处理完。程序可以使用应用级的annotation把队列的大小或过载情况写入跟踪系统。此外,如果这种情况屡见不鲜,那么在ProfileMe[11]中提到的成对的采样技术可以解决这个问题。它由两个时间重叠的采样率组成,并观察它们在整个系统中的相对延迟。
    • 记录内核级的信息:一些内核可见的事件的详细信息有时对确定问题根源是很有用的。我们有一些工具,能够跟踪或以其他方式描述内核的执行,但是,想用通用的或是不那么突兀的方式,是很难把这些信息到捆绑到用户级别的跟踪上下文中。我们正在研究一种妥协的解决方案,我们在用户层面上把一些内核级的活动参数做快照,然后绑定他们到一个活动的span上。

    8. 相关产品

    在分布式系统跟踪领域,有一套完整的体系,一部分系统主要关注定位到故障位置,其他的目标是针对性能进行优化。 Dapper确实被用于发现系统问题,但它更通常用于探查性能不足,以及提高全面大规模的工作负载下的系统行为的理解。

    与Dapper相关的黑盒监控系统,比如Project5[1],WAP5[15]和Sherlock[2],可以说不依赖运行库的情况下,黑盒监控系统能够实现更高的应用级透明。黑盒的缺点是一定程度上不够精确,并可能在统计推断关键路径时带来更大的系统损耗。

    对于分布式系统监控来说,基于Annotation的中间件或应用自身是一个可能是更受欢迎的解决办法.拿Pip[14]和Webmon[16]系统举例,他们更依赖于应用级的Annotation,而X-Trace[12],Pinpoint[9]和Magpie[3]大多集中在对库和中间件的修改。Dapper更接近后者。像Pinpoint,X-Trace,和早期版本的Magpie一样,Dapper采用了全局标识符把分布式系统中各部分相关的事件联系在一起。和这些系统类似,Dapper尝试避免使用应用级Annotation,而是把的植入隐藏在通用组件模块内。Magpie放弃使用全局ID,仍然试图正确的完成请求的正确传播,他通过采用应用系统各自写入的事件策略,最终也能精确描述不同事件之间关系。但是目前还不清楚Magpie在实际环境中实现透明性这些策略到底多么有效。 X-Trace的核心Annotation比Dapper更有野心一些,因为X-Trace系统对于跟踪的收集,不仅在跟踪节点层面上,而且在节点内部不同的软件层也会进行跟踪。而我们对于组件的低性能损耗的要求迫使我们不能采用X-Trace这样的模型,而是朝着把一个请求连接起来完整跟踪所能做到的最小代价而努力。而Dapper的跟踪仍然可以从可选的应用级Annotation中获益。

    9. 总结

    在本文中,我们介绍Dapper这个Google的生产环境下的分布式系统跟踪平台,并汇报了我们开发和使用它的相关经验。 Dapper几乎在部署在所有的Google系统上,并可以在不需要应用级修改的情况下进行跟踪,而且没有明显的性能影响。Dapper对于开发人员和运维团队带来的好处,可以从我们主要的跟踪用户界面的广泛使用上看出来,另外我们还列举了一些Dapper的使用用例来说明Dapper的作用,这些用例有些甚至都没有Dapper开发团队参与,而是被应用的开发者开发出来的。

    据我们所知,这是第一篇汇报生产环境下分布式系统跟踪框架的论文。事实上,我们的主要贡献源于这个事实:论文中回顾的这个系统已经运行两年之久。我们发现,结合对开发人员提供简单API和对应用系统完全透明来增强跟踪的这个决定,是非常值得的。

    我们相信,Dapper比以前的基于Annotation的分布式跟踪达到更高的应用透明度,这一点已经通过只需要少量人工干预的工作量得以证明。虽然一定程度上得益于我们的系统的同质性,但它本身仍然是一个重大的挑战。最重要的是,我们的设计提出了一些实现应用级透明性的充分条件,对此我们希望能够对更错杂环境下的解决方案的开发有所帮助。

    最后,通过开放Dapper跟踪仓库给内部开发者,我们促使更多的基于跟踪仓库的分析工具的产生,而仅仅由Dapper团队默默的在信息孤岛中埋头苦干的结果远达不到现在这么大的规模,这个决定促使了设计和实施的展开。

    Acknowledgments

    We thank Mahesh Palekar, Cliff Biffle, Thomas Kotzmann, Kevin Gibbs, Yonatan Zunger, Michael Kleber, and Toby Smith for their experimental data and feedback about Dapper experiences. We also thank Silvius Rus for his assistance with load testing. Most importantly, though, we thank the outstanding team of engineers who have continued to develop and improve Dapper over the years; in order of appearance, Sharon Perl, Dick Sites, Rob von Behren, Tony DeWitt, Don Pazel, Ofer Zajicek, Anthony Zana, Hyang-Ah Kim, Joshua MacDonald, Dan Sturman, Glenn Willen, Alex Kehlenbeck, Brian McBarron, Michael Kleber, Chris Povirk, Bradley White, Toby Smith, Todd Derr, Michael De Rosa, and Athicha Muthitacharoen. They have all done a tremendous amount of work to make Dapper a day-to-day reality at Google.

    References

    [1] M. K. Aguilera, J. C. Mogul, J. L. Wiener, P. Reynolds, and A. Muthitacharoen. Performance Debugging for Distributed Systems of Black Boxes. In Proceedings of the 19th ACM Symposium on Operating Systems Principles, December 2003.

    [2] P. Bahl, R. Chandra, A. Greenberg, S. Kandula, D. A. Maltz, and M. Zhang. Towards Highly Reliable Enterprise Network Services Via Inference of Multi-level Dependencies. In Proceedings of SIGCOMM, 2007.

    [3] P. Barham, R. Isaacs, R. Mortier, and D. Narayanan. Magpie: online modelling and performance-aware systems. In Proceedings of USENIX HotOS IX, 2003.

    [4] L. A. Barroso, J. Dean, and U. Holzle. Web Search for a Planet: The Google Cluster Architecture. IEEE Micro, 23(2):22–28, March/April 2003.

    [5] T. O. G. Blog. Developers, start your engines. http://googleblog.blogspot.com/2008/04/developers-start-your-engines.html,2007.

    [6] T. O. G. Blog. Universal search: The best answer is still the best answer. http://googleblog.blogspot.com/2007/05/universal-search-best-answer-is-still.html, 2007.

    [7] M. Burrows. The Chubby lock service for loosely-coupled distributed systems. In Proceedings of the 7th USENIX Symposium on Operating Systems Design and Implementation, pages 335 – 350, 2006.

    [8] F. Chang, J. Dean, S. Ghemawat, W. C. Hsieh, D. A. Wallach, M. Burrows, T. Chandra, A. Fikes, and R. E. Gruber. Bigtable: A Distributed Storage System for Structured Data. In Proceedings of the 7th USENIX Symposium on Operating Systems Design and Implementation (OSDI’06), November 2006.

    [9] M. Y. Chen, E. Kiciman, E. Fratkin, A. fox, and E. Brewer. Pinpoint: Problem Determination in Large, Dynamic Internet Services. In Proceedings of ACM International Conference on Dependable Systems and Networks, 2002.

    [10] J. Dean and S. Ghemawat. MapReduce: Simplified Data Processing on Large Clusters. In Proceedings of the 6th USENIX Symposium on Operating Systems Design and Implementation (OSDI’04), pages 137 – 150, December 2004.

    [11] J. Dean, J. E. Hicks, C. A. Waldspurger, W. E. Weihl, and G. Chrysos. ProfileMe: Hardware Support for Instruction-Level Profiling on Out-of-Order Processors. In Proceedings of the IEEE/ACM International Symposium on Microarchitecture, 1997.

    [12] R. Fonseca, G. Porter, R. H. Katz, S. Shenker, and I. Stoica. X-Trace: A Pervasive Network Tracing Framework. In Proceedings of USENIX NSDI, 2007.

    [13] B. Lee and K. Bourrillion. The Guice Project Home Page. http://code.google.com/p/google-guice/, 2007.

    [14] P. Reynolds, C. Killian, J. L. Wiener, J. C. Mogul, M. A. Shah, and A. Vahdat. Pip: Detecting the Unexpected in Distributed Systems. In Proceedings of USENIX NSDI, 2006.

    [15] P. Reynolds, J. L. Wiener, J. C. Mogul, M. K. Aguilera, and A. Vahdat. WAP5: Black Box Performance Debugging for Wide-Area Systems. In Proceedings of the 15th International World Wide Web Conference, 2006.

    [16] P. K. G. T. Gschwind, K. Eshghi and K. Wurster. WebMon: A Performance Profiler for Web Transactions. In E-Commerce Workshop, 2002.



    转载自:http://bigbully.github.io/Dapper-translation/

    展开全文
  • 关键技术及创新点 智能手环功能的实现以及创新是其作为一个产品的特殊符号,下表是智能手环创新点以及关键技术: 表五 关键技术及创新点 9.总结与展望 智能手环的设计充分体现出了科技与人生活的互联,移动可穿戴...
  • 写给忙人看的操作系统

    万次阅读 多人点赞 2020-02-28 12:34:12
    现代计算机系统由一个或多个处理器、主存、打印机、键盘、鼠标、显示器、网络接口以及各种输入/输出设备构成。 然而,程序员不会直接和这些硬件打交道,而且每位程序员不可能会掌握所有计算机系统的细节,这样我们...
  • 《地理信息系统概论》课后习题全部答案_黄杏元

    千次阅读 多人点赞 2020-08-14 18:11:56
    第一章 地理信息系统导论 1、什么是地理信息系统(GIS)?它与一般计算机应用系统有哪些异同点? 答:地理信息系统:是由计算机硬件、软件和不同的方法组成的系统,该系统设计支持空间数据的采集、管理、处理、...
  • 本次Odoo13更新的模块有:Odoo会计模块、Odoo活动项目模块、Odoo13审批模块、Odoo评价、客户关系管理(CRM)、讨论模块、文件管理模块、Odoo13电子商务模块、电子邮件营销模块、员工管理模块、事件管理、消费管理模块...
  • 系统分析师学习笔记(十四)

    千次阅读 2021-05-07 11:57:48
    概要设计主要任务是将系统功能需求分配给软件模块,确定每个模块功能和调用关系,形成软件的模块结构图,即系统结构图。在概要设计中,将系统开发的总任务分解成许多个基本的、具体的任务,为每个具体任务选择...
  • 操作系统课程设计报告(文件系统)

    千次阅读 多人点赞 2020-01-11 10:13:52
    随着计算机技术的快速发展,在计算机操作系统中,如何优化任务处理效率成为一难题。通过一个简单多用户文件系统设计,加深对文件系统的理解及内部实现。运用多线程的调度尽可能的优化其效率,解决实际问题。 1.1...
  • 第九章:mmp功能模块

    千次阅读 2018-05-14 00:26:12
     第一部分:初始化sys部分的变量,sys也就是mpp中的变量填充,如VB结构体里面的数据  第二部分:初始化mpp系统  第三部分:启动VI部分(设备和通道),然后采集图像(和摄像头相关部分)  第四部分:启动VPSS...
  • 在计算机产业发展的70年时间里,每一次的 IT 革命,无不带来:更低廉的价格、更完善的功能、更便捷的使用、更广阔的市场! 大数据经过10年发展,现在已经到了一个重要的分水岭阶段:通用性和兼容性能力成为大数据...
  • 本系列文章为哈尔滨工业大学刘宏伟计算机组成原理学习笔记,前面的系列文章链接如下: 计算机组成原理:P1-计算机系统概述 计算机组成原理:P2-系统总线 ...输入输出系统是计算机系统当中种类最多、功能最多、结构最复
  • 中国大学mooc操作系统答案

    万次阅读 多人点赞 2020-08-19 22:20:25
    1.1 什么是操作系统随堂测验 1、操作系统的核心目标是()。 A、管理硬件 B、运行程序 C、让用户方便使用 D、提高CPU利用率 答案:B 2、从设备到本地缓冲之间传输数据由()完成。 A、I/O控制器 B、CPU C、设备机械...
  • 操作系统习题

    万次阅读 多人点赞 2017-12-22 21:08:55
    它是这样一些程序模块的集合:它们能有效地组织和管理计算机系统中的硬件及软件资源,合理地组织计算机工作流程,控制程序的执行,并向用户提供各种服务功能,使得用户能够灵活、方便和有效地使用计算机,使整个...
  • 软件测试基础——功能测试

    千次阅读 多人点赞 2021-09-22 15:39:50
    尽早地发现软件程序、系统或产品中所有的问题。 督促和协助开发人员尽快地解决程序中的缺陷。 帮助项目管理人员制定合理的开发和测试计划。 对缺陷进行跟踪、分析和分类总结,以便让项目的管理人员和相关的负责人...
  • matlab从无到有系列():高级图形处理功能(多窗口绘图以及花瓶绘制) matlab从无到有系列(七):GUI程序设计 matlab从无到有系列(八):M文件及函数的编写 Simulink 中的“Simu”一词表示可用于计算机仿真,而...
  • 系统安全及应用

    千次阅读 2022-04-06 14:20:16
    文章目录前言一、账号安全控制1、系统账号清理2、密码安全控制3、命令历史限制bash配置文件读取4、终端自动注销二、系统引导和登录控制1、使用su命令切换用户1.1用途及用法1.1.2密码验证1.1.3限制使用su命令的用户...
  • 常见的操作系统有哪些?

    万次阅读 2019-12-26 19:33:42
    一、常见的操作系统有哪些? 1、Windows操作系统 应用比较广泛。 2、Linux操作系统 免费使用,类UNIX 3、Unix操作系统 无界面,使用命令操作,一般安装在服务器上面。 4、Mac操作系统 苹果公司开发的,一般...
  • 牛逼!Java 从入门到精通,超全汇总版

    万次阅读 多人点赞 2021-05-06 19:40:33
    本书从六大设计原则入手,警示我们在日常开发过程中需要注意代码的编写原则。同时,本书列举了大量生动形象的例子,在遇到相关业务场景时可以把代码写得非常漂亮。原则既是规范,也是日常开发过程中要遵守的约定;...
  • 操作系统期末复习

    千次阅读 2021-12-13 13:19:36
    下面的内容基本都是来自西安电子科技大学出版社的《计算机操作系统》(第四版) 一书。 最初是在幕布上编辑的,但是因为没法直接从幕布导出md文件,所以下面的排版可能会不太好看,想看排版好的可以移步操作系统复习...
  • 深入浅出Python——Python基础语法全解

    万次阅读 多人点赞 2020-07-24 20:31:37
    可扩展:如果你需要一段运行很快的关键代码,或者是想要编写一些不愿开放的算法,你可以使用C或C++完成那部分程序,然后从你的Python程序中调用。 数据库:Python提供所有主要的商业数据库的接口。 GUI编程:Python...
  • 操作系统MOOC课后习题答案

    千次阅读 2021-03-25 18:35:21
    1.1 什么是操作系统随堂测验 1、操作系统的核心目标是()。 A、管理硬件 B、运行程序 C、让用户方便使用 D、提高CPU利用率 答案:B 2、从设备到本地缓冲之间传输数据由()完成。 A、I/O控制器 B、CPU C、设备机械...
  • 操作系统实验一到实验九合集(哈工大李治军)

    千次阅读 多人点赞 2022-01-01 16:06:50
    操作系统实验一到实验九合集(哈工大李治军) 有详细代码及注释,程序已在本地测试,均能跑通
  • 知识图谱关键技术与应用案例

    万次阅读 多人点赞 2018-11-06 11:50:18
    本课程从知识图谱的历史...以及达观在各行业领域系统中的产品开发和系统应用。 报名地址: https://edu.csdn.net/huiyiCourse/detail/844 作者简介:桂洪冠,达观数据联合创始人,中国计算机学会 CCF 会员,自然...
  • 4、信息系统6特点:目的性;可嵌套性;稳定性;开放性;脆弱性;健壮性。 5、信息系统由硬件、软件、数据库、网络、存储设备、感知设备、外设、人员把数据处理成信息的规程等。 6、信息系统生命周期可简化为:①
  • 阿里云ACE备考题库241-400

    千次阅读 2021-09-26 23:18:00
    240关于 MQ 的使用场景,以下描述...所在的传媒公司明天将会再自己的新闻网站上搞个新闻,预计会有大量网友前来围观,你预计资源很有可能被撑爆,为了防止这种问题,你该如何使用DNS将其故障转移到静态的网页上?’’ C.
  • 这些操作系统的概念,保你没听过!

    千次阅读 多人点赞 2020-02-10 12:40:45
    部分操作系统提供了特定的基础概念和抽象,例如进程、地址空间、文件等,它们是需要理解的核心内容。下面我们会简要介绍一些基本概念,为了说明这些概念,我们会不时的从 UNIX 中提出示例,相同的示例也会存在于...
  • SAS(二)SAS基本数据类型及SAS基本模块的介绍 SAS基本介绍 SAS 是英文Statistical Analysis System的缩写,翻译成汉语是统计分析系统,最初由美国北卡罗来纳州立大学两名研究生研制,1976 年创立SAS公司, 2006年...
  • 系统架构图

    万次阅读 2018-08-03 11:48:57
    常规企业应用中,传统关系型数据仍然是主流,但是no-sql经过这几年发展,技术也日渐成熟了,一些非关键数据可以适当采用no-sql数据库,比如:系统日志、报文历史记录这类相对比较独立,而且增长迅速的数据,可以考虑...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 23,539
精华内容 9,415
关键字:

列控系统的六大关键功能模块