精华内容
下载资源
问答
  • 福建省福州市第一中学 余林韵 11121 11121 2006200720082009 化归 就是转化和归结 问题甲 比较容易解决的问题乙 化归方法的要素 化归对象 即对什么东西进行化归 化归目标 即化归到何处去 化归途径 即如何进行化归 ...
  • 浅谈数学中的化归原则 摘要: 能力比知识更重要;数学教育中使学生掌握数学思想方法,对于促进他们能力的发展至关重要;化归原则是数学中一种很重要的思想方法;本文将简要介绍在中学数学中化归原则的具体应用。 ...

    浅谈数学中的化归原则

    泸职院信息工程学院 华卫(1999.6.6)

    摘要: 能力比知识更重要;数学教育中使学生掌握数学思想方法,对于促进他们能力的发展至关重要;化归原则是数学中一种很重要的思想方法;本文将简要介绍在中学数学中化归原则的具体应用。
    关键词: 数学教育、思想方法、化归原则

    一、引言

    数学思想方法是形成能力的重要因素;美籍匈牙利著名数学教育家波利亚奉行的教育宗旨就是“ 教 会 青 年 人 思 考 ‾ \underline{教会青年人思考}

    展开全文
  • 化归.归纳.类比.联想

    2009-12-12 20:13:00
    本内容源于书籍《化归与归纳.类比.联想》 1. 一般与特殊 1.1 特殊与一般的关系 特殊与一般之间存在着如下关系 : 若命题 P 在一般条件...

    EDITOR: KJ021320

    BLOG:http://blog.csdn.net/kj021320

     

    本内容源于书籍《化归与归纳.类比.联想》

    1.       一般与特殊

    1.1       特殊与一般的关系

    特殊与一般之间存在着如下关系 :

    若命题 P 在一般条件下面为真 , 则在特殊条件下面 P 也真 , 我们把这种的关系叫做关系 A.

    为了方便计 , 我们把关系 A 的逆命题陈述如下 , 并称之为关系 B:

    若命题 P 在一般条件下为假 , 则在一般条件下 P 亦为假 .

    凭借关系 B, 我们就可以利用 特殊 而否定 一般 . 从而实现化归 .

     

     

    1.2       特殊化与简单化

    一个使用最普通而又较为简单易行的化归途径 , 乃是把所给问题的形式向特殊的或简单的形式转化 . 因为特殊的事物常常比较简单 , 而简单的事物又往往比较容易解决 .

    简单与啊 , 是按照概念发展的阶段来区分的 , 而且是相对而言 . 概念发展的低级阶段的形式与高级阶段的形式相比较 , 我们把前者称为简单形式 , 后者称为复杂形式 .

    由于简单形式中常包含着特殊形式 , 特殊形式往往比较简单 , 所以我们把 特殊化 简单化 合并在一起讨论 .

     

    1.3       命题中之特殊因素的挖掘

    所谓 特殊因素 ”, 乃指命题结构中的那些特殊的图形 , 数量和关系结构等 .

    任何数学命题的结构总可以从如下两个方面加以考虑 . 其一是量性对象 , 即如集合之元素及其个数 ( 或基数 ), 方程的系数和次数 , 边缘的取值范围 , 平面或空间的几何元素 , 如点 , 线 , 面等等 . 其次是关系结构 , 即如集合的性质 , 图形的位置关系 , 符号的联结方式 , 条件与结论的关系等等 .

    数学命题结构中的那些量性对象和关系结构统称为命题结构中的因素

     

    1.4       一般化

    我们对特殊形式比较熟悉时 , 我们就沿着特殊化的途径去实现化归 , 但若我们对一般形式比较熟悉时 , 那么就应该反过来 , 沿着一般化的途径去实现化归 . 这两条途径是相反相成的 . 两者和谐地统一在一起 , 使化归方法更为完善 .

     

    2.       分解与组合

    2.1       分解的对象

    在用分解和组合去实现化归过程中 , 对待处理的问题 , 通常有如下四个方法被作为分解对象 :

    2.1.1          问题本身 ( 把问题本身作为被分解的对象 )

    将整体分解为局部之和的形式 .

    将局部分解为整体与另一局部之差的形式 .

     

    2.1.2          问题的条件 ( 针对问题条件的分解 )

    问题条件被分解的功能在于能暂时解除他们之间的制约关系 , 使我们能更自由的分别探求只满足部分条件的对象的集合 . 当然 , 为了求得问题的解决 , 我们还须进行分解后的重新组合 , 也就是说我们还应该回过头来再次利用制约关系 , 往求上述那些满足部门条件的对象的集合

    对条件之间的制约关系比较复杂的问题 , 特别要注意条件的分解 . 因为通过条件分解 , 可以使制约关系变得清晰明朗和便于运用 .

     

    2.1.3          问题的外延 ( 问题外延的分解 )

    外延的分解即相当于逻辑学中的所谓 划分 ”. 但从化归的角度讲 , 我们强调分解问题的外延 , 主要目的是为了弄清求解问题时应从哪几个方面入手 . 在分解之前首先要确定一个恰到好处的区分标准 , 分解的时候还应该注意不重复 , 不遗漏

     

    2.1.4          实现目标的过程 ( 对实现目标的过程进行分解 )

    我们把这种分解方式称为台阶式分解 . 因为通过这种分解 ,” 过程 即被分为几个阶段 , 每一个阶段都有一个小目标 , 每个小目标即形成一个台阶 , 使得我们以沿着这个台阶一步一步地去逼近问题获解的总目标 . 显然 , 台阶下层的小目标应比上层的小目标容易实现一些 .

     

    2.2       局部变动法

    局部变动法是一种特殊而重要的分解方法 . 它常被用来实现可变因素较多的问题的化归过程 .

    数学中的局部变动法也是如此 , 其处理方法是暂时固定问题中的一些可变因素 , 使之不变 , 先研究另一些可变因素对求解问题的影响 , 取得局部的成果后 , 再从原先保持不变的因素里取出一些继续研究 , 直到问题全部获解 .

     

    2.3       补集法

    把所说的 整体 理解为全集 I, 又把 局部 理解为该全集 I 的子集 A, 那么原问题的结论就是 A 的补集 A   . I A 都已为我们所熟悉 , 或者比较简单而易求时 , 那么通过 I A 去求得 A 就成了一条简单而易行的路子 .

    从思维形式来说 , 补集法是一种逆向思维 , 由于他常在 顺向 思维受阻时发挥作用 , 因此会给人一种感觉 : 用补集法给出的解往往是优美而直截了当的 .

     

     

     

    3.       归纳 , 类比 , 联想及其在化归中的作用

    无论是一个成熟的数学分支 , 或者是一个已经获解的数学问题 , 都是通过演绎展开的 . 但无论是考察某一数学分支的生成与发展过程 , 还是分析一个问题求解的过程 , 演绎推理主要是在人们抓住真理之后 , 再补行的论证手续 , 因而演绎推理并不是发现和创新的重要手段 . 对于寻找真理 , 发现真理和探索求解方案而言 , 更重要的是实验 , 观察 , 归纳 , 类比 联想 等思想方法

     

    3.1       归纳的意义及其在化归中的作用

    3.1.1          完全归纳 ( 完全归纳推理 )

    根据某类事物中之每一事物都具有某种性质 P, 推理出该类中全部事物都具有该性质 P 的归纳推理方法

    完全归纳法前提必须包括某类事物中的一切对象 , 无一遗漏 , 而且作为前提的判断也必须是真实的 , 所以完全归纳得出的结论是真实可靠的 .

    3.1.2          不完全归纳 ( 经验归纳 )

    通过对一类事物的部分对象的考虑 , 从中作出有关这类食物的一般性结论的猜想的方法 ( 观察 , 实践 -> 推广 -> 猜想一般性结论 )

    3.1.2.1    枚举归纳

    以某个对象 , 公式的多次重复作为判断依据 ( 可靠性大有问题 )

    3.1.2.2    因果归纳

    因果归纳是把一类事物中部分对象的因果关系作出判断的前提而做出一般性猜想的推理方法

    3.1.3          用不完全归纳法发现问题的结论

    有两种形式

    A 由特殊事物直接猜测结论

    B 根据规律猜测一个递推关系 , 然后凭借递推关系去发现结论

    不论哪一种形式所得的结论 , 都必须要补行严格的证明手续

     

    3.1.4          用不完全归纳法发现解决问题的途径

    用不完全归纳法从特殊问题的处理方法中国那出一半问题的处理方法 , 即发现解决问题的途径

     

    3.2       类比的意义及其在化归中的作用

    3.2.1          类比的意义

    类比推理是根据两个不同的对象 , 在某些方面 ( 如特征 , 属性 , 关系等 ) 的类同之处 , 猜测这两个对象在其他方面也可能有类同之处 , 并作出某种判断的推理方法 .

    A.      类比意义中所说的 " 类同 " , 既可通过表面形式的观察而得到 , 也通过仔细的分析而获得 . 当然 , 后者更为重要

    B.      由类比而产生的联想 , 必须 " 合情 ", 也就是说 , 联想必须兼顾类同点和相异点所反映的关系

    C.      类比于归纳一样 , 也是一种 " 合情 " 推理 , 其结论之正确与否 , 必须经过严格的证明 .

     

    3.2.2          类比于归纳的关系

    类比于归纳在意义上差比是很明显的 . 然而在发现真理 , 或者在确定化归方法的过程中 , 要截然吧二者的作用区分开来 , 却是不大容易 . 原因在于他们常常交融在一起 , 协同完成寻找和发现真理的任务 .

    要用好类比推理 , 必须要有丰富的知识与联想的能力 . 知识与想象力越丰富 , 可供类比的题材就越少 , 形式新命题 , 发现新的方法机会也越多 .

    3.2.3          类比在归纳中的作用

    类比推理他是一种创造性较强而可靠性较弱的推理方法 . 我们应最大限度地发挥其创造性作用 , 而用严格论证的方法克服其可靠性较弱的缺点 .

    类比推理的创造性作用体现以下两点

    A.      发现新的命题 , 直至发现新的数学领域

    B.      发现解决问题的途径

    类比可以十分有效的使人们接受新知识 , 同时 , 类比可以帮助人们梳理与巩固知识的常用方法 .

    实现化归的主要困难在于如何确定化归的方向 , 而化归方向的确定又主要体现在确定未知目标与确定解题途径这两点上 . 试把这两点与上述类比的创造性作用相对照 , 即可知类比推理恰是确定化归方向的一把钥匙 . 也就是说 , 类比推理之于化归 , 一可以帮助我们去确定未知目标 , 二可帮助我们寻找解决问题的途径 . 当然 , 我们这样讲 , 丝毫没有贬低前节中所说的归纳和下节所要讨论之联想对于化归的作用 . 相反地 , 正式归纳 , 类比和联想的有机结合 , 使化归更为完善 .

    3.2.3.1    运用类比法预测未知目标从而实现化归
    用类比法预测未知目标的关键是寻找或模拟一个比原问题简单或熟悉的类比对象 . 我们可以通过对类比对象的未知目标的研究 , 来猜测原来问题的未知目标 . 未知目标一旦被确定 , 化归的途径也就大致确定了 .

    3.2.3.2    运用类比法寻求解决问题的途径和方法

    大家都知道 " 触类旁通 " 的含义 , 意思基本上也就是用类比法去寻求解决问题的途径和方法 . 也就是说 , 当我们直接思考某个问题而难于找到正确解决途径时 , 不妨从原来的思路中解脱出来 , 从旁思考一些与之类似的问题 , 看看能否由此受到一些启发 .

     

    3.3       联想的意义及其在化归中的作用

    3.3.1          联想的意义

    联想是有某种概念而引起其他相关概念的思维形式 , 他与归纳类比一样 , 也是一种寻找真理和发现真理的重要手段 .

    一般来说 , 联想推理有 3 个组成部分 , 或称联想 3 要素 :

    其一是上面所说的 " 某种概念 ", 它是联想的触发点 , 是产生联想的起因 , 我们称为联想因素 .

    其二是上述之 " 相关概念 ", 它是联想的结果 , 我们常据此作出某种演算或判断 . 我们把 " 相关概念 " 及据此作出的判断合称为联想效应 .

    其三是联想因素与联想效应的相关性 , 这是由此及彼的线路 . 这样的线路是客观存在的 , 不过要靠知识和想象力才能被发现 , 才能通行 , 我们称为联想线路 .

    数学联想中的联想因素和联想效应 , 除有少数例外情形之外 , 一般都是数学的对象 , 关系结构及数学方法 , 而联想线路则是这些数学知识之间的客观联系 .联想因素产生对问题的审视 . 所谓审视 , 他不同于一般的观察了解 , 而是在观察了解基础上的分析与探究 , 诸如对数学对象的探究 , 对数学关系结构的探究等 . 至于联想线路 , 则是在只是的纵横联系 , 因果分析等过程中被发现的 .

     

    3.3.2          联想与类比的关系

    联想与类比在意义上的区别是明显的 , 类比偏重于对两类对象性质上的相同或相似因素的比较 , 并据此进行类推 . 而联想 , 则虽也是由一个对象相到另一个对象的思维形式 , 但它并不受两类对象性质相似或不相似的限制 . 但是联想与类比又有密切的关系 , 他们往往交织在一起共同探索和发现解决问题的方法 .

     

    3.3.3          联想在化归中的作用

    3.3.3.1    简单联想的问题

    简单联想的联想因素产生于对数学对象和关系结构的审视 , 而联想线路的发现则依赖于知识间的纵横联系 , 因果分析和丰富的想象力 . 所以在运用联想法探索化归途径时 , 我们应该有意识和有目的地致力于审视与联系 , 而且还要敢于想象 .

     

    3.3.3.2    复杂联想的问题

    复杂联想是一种与其他思维形式交织在一起的联想形式

     

     

     

     

     

     

     

    转载于:https://www.cnblogs.com/springside-example/archive/2009/12/12/2529911.html

    展开全文
  • 全渠道零售中台与数字转型(1)-中台的前世今身

    千次阅读 多人点赞 2019-06-25 15:37:59
    本系列博客的目标是计划使用近半年时间创造: ... 全渠道零售中台与数字转型(2)-中台给企业业务带来什么实际的价值 全渠道零售中台与数字转型(3)-中台给企业技术带来什么实际的价值? 全渠...

    本系列博客的目标是计划使用近半年时间创造:

    • 国内唯一一部从业务场景到技术设计,从企业战略考虑到技术细节落地的大全;
    • 全文贯穿了企业架构、SOA、微服务,纵横业务与技术之间説透“全渠道”中台;
    • 全渠道零售中台与数字化转型(1)-中台的前世今身
    • 全渠道零售中台与数字化转型(2)-中台给企业业务带来什么实际的价值
    • 全渠道零售中台与数字化转型(3)-中台给企业技术带来什么实际的价值?
    • 全渠道零售中台与数字化转型(4)-作为甲方如何选择中台-产品还是开发?数据中台还是业务中台的多重考虑
    • 全渠道零售中台与数字化转型(5)-中台的架构设计
    • 全渠道零售中台与数字化转型(6)-基于微服务的组件设计
    • 全渠道零售中台与数字化转型(7)-中台核心框架代码实现
    • 全渠道零售中台与数字化转型(8)-中台的延伸

    楔子

    零售战鼓隆,各家齐斗法

    云溪论剑后,江湖出宝典

    古有葵花经,现有“大中台”

    没有“两个亿”,别想做中台

    技术道业务道,自求条正道

    各家纷説自己好

    谁曾想,旧日零售江湖间现己变成了血海滔滔

    你也説中台,我也説中台,到底什么是中台?

    现如今随着“新零售”这三个字一再被提及,整个零售界都在提一个“神密的东西”,那就是中台。甚至中台被上升到了“推进企业数字化变形”的乃至直接促成企业数字化转型能否成功的地位了。

    那么中台它到底是个什么样的东西呢?在人们眼中中台似乎犹如月球的背面一般神密。

    在人们眼中的中台无外乎于上述类似的组件图,类似的图一再被各大零售商或者是不少知名软件商一再的提及。

    它似乎有着“华丽的外表,沉渔落雁的面容,婀娜多姿的身段”。。。but。。。

    它只是利用了2009年TOGAF设计规范从顶向下的设计方法论把业务模块进行了LEVEL3级别的一个分解的功能图而己,它只要业务架构师手绘一些功能甚至公司的一个BA用Excel做一个功能列表然后让稍微资深点的UI做一下布局在一天内即可以得出的一个picture而己

    多少甲方为了这么一张外面报价800-1,000块钱制作费的首图化了近千万、甚至上亿的代价了?甚至笔者在几个展会听到不少的开发商豪言“你要做中台?你公司干什么的?每年至少2个亿销售额有吧。。。。。。没有?那您也别做中台了”。

     

    中台的诞生

    中台这个东西我明确告诉大家:它一点不神密,它也不是近3年的什么高科技的产物,早在2012年这个东西就已经有了。同时我本人在13年也已经用“中台”的理念制作了一套类似的东西我们在当时把它称为“SMART PLATFORM”,这套东西的代码我会在后面的章节涉及到设计和实现的时候公开它的核心源码、数据库表结构与设计思路,这个是属于我个人的也是没有问题的,各位也可以放心使用。

    这种一体化全渠道平台的出现最早是在银行、金融界,在那个时候银行、金融、保险界的一些大公司面对着繁杂的legacy systems需要开始迈入“手机端、无线办公”端的时代,于是当时的人们想到把这么多的legacy systems是不是可以做成一个“大后台”。

    在这个大后台中,把所有的业务功能进行整合,所有的数据使用一个或者是一套数据库以此来打通各个业务、解决掉数据孤岛问题、提高性能、降低不同系统间交互、接口转换、以及支持不同系统间数据交互的事务一致性时带来的昂贵的开发、网络延时与开销以及不必要的开发工作量。

    但是,业界在根据这个指导思想进行开发时发觉问题来了!

    如果仅仅是把所有的东西打包在一个“大后台”并不能真正解决IT的痛点,因为必竟它是一个IT系统。IT系统要考虑的东西除了业务功能,更重要和更有价值的地方在于:

    • 性能
    • 安全
    • 可以快速响应业务的创新或者説甚至可以“加速业务创新”并以此来为业务赋能

    以上説的神乎几神,我们中国人现在讲究的是“效率、实干”,要“落地”,要“接地气”,因此下面我们就用接地气的话来把上面这一段中台出现的背景、历史上经历的痛点来着重的讲一下吧。

     

    直接使用零售场景来描述中台的诞生与过程

    一个顾客在传统的零售场所的消费体验可以用下图描述出主要的“零售体验核心环节”

    以上这个图,它出现在20-25年前的零售大卖场内,支持它的系统也是20甚至25年前的“作品”。这边需要着重説一句的是:截止作者写此稿时,现有大部分的大型商超竟然用的还是20-25年前的IT系统。这也正是近来各大厂商、业界宣了沸沸扬扬的“新零售”,“数字化转型”的原动力与由来(改造需要money, money,没有money没有利益何来原动力)。

    因为。。。这么土的东西,直到现在终于有机会推翻它了。

    言归正传,解读上图!

    当一个顾客来到了大超市内,我们知道传统的大超市还会分不同的品牌,把化妆品还放到不同的位置甚至独立的橱柜,这就导致了客户要买什么东西,他会记得去问各个“导购”或者去服务台询问。

    “哎呀,请问会员怎么办?”,导购人员会告诉他!

    “哎呀,请问会员积分哪里积怎么积?”,导购人员会告诉他!

    “哎呀,请问印花是怎么得到?”,导购人员还是会告诉他!

    客户问错了人,比如説他去问“收银员”这把刀不是説买一把送一块肥皂吗?收银员通过话务机于是叫来了导购,但是导购也不知道,就又通过商场广播叫来了“促销人员”,促销人员当然知道买什么可以送什么或者打几折这些事喽。

    于是,靠着不同的、严格的岗位、职责的区分,我们的商场尚且还可以运作。并且要知道那是20年前,国人的消费能力有小部分已经开始起色而市场上商品的供应还不如现在的“百花齐放”。因此一些国外的大型商超明显在当时是属于“朝南坐”、“躺着挣钱的”

    因此,大型商超在当时对于IT系统的定位是次要中的次要的(很悲哀),而货物、商品甚至不乏国外进口商超内的商品在那时才是真正深深吸引国人的主要因素。

    于是过了大约10年,这也是零售业黄金的10年,随着国人消费能力的越来越高,随着IPHONE4、微信、淘宝的兴起,零商开始迈向了电商时代。

    于是这些大型商超、大型零售超市想当然的认为其实电商就是把原来站在各个服务前的一个个人肉导购啦、促销啦、专柜啦的这些个人取代成一个个的手机应用APP,于是,在当时的大型零售商眼里的电商也是类似下面这样的一个图

    先有了想法

    通过“想法”有了下面的系统“架构”

    零售电商1.0模式

    转型1.0模式

    不要笑,当时一堆一堆的零售(在当时还算是比较有钱)设计出来的系统就是这样的。

    “喏,要数字化,我把人变成了一个个的APP了,这不就是数字化!”

    所以大家直到现在也能看到类似的案例:一些传统的快销、零售商用微信、用APP、用微信小程序哪怕只是做出了一个会员登记系统也会把它当成“公司内部巨大的创新”,也是基于这样的想法。因为IT不重要吗,哈哈!

    可是,它依旧没有从根本上解决客户的问题。为什么呢?中国客户的电商使用习惯是什么?
     

    中国人的电商使用习惯

    中国,人多的很、市场大的很,我们説我们是世界第2电商大国,这个世界上没人敢説它是世界第1。

    那么多APP、那么多小程序、那么多微信公众号,而你只有一个企业实体却要做成“为了一个服务就放一个APP”的模式,比如説:我为了来一次“某干发”大超市、“某得福”网上超市购物你要我去下不止一个APP才能完成“会员、认证、购物、积分”本就应该集中在一个APP中的“功能”,甚至客户做一些兑换还要让我打开一个不知道什么地方的网页去登录一个网址才能完成兑换?你是不是觉得我们客户的时间太“无用了”?

    张小龙説过:哪个APP可以每天占用客户30分钟,这个APP就是巨大的成功

    在百花齐放、百家争鸣的数字化时代况且在当时淘宝连续使用4次双11打折活动打造了中国客户的使用电商APP的习惯后,你这边突然来了一个,有几个功能就要有几个网址、几个APP或者就算你是APP混合微信好来,你觉得中国的顾客会买你的帐?

    下载APP的时间是很宝贵的!

    在当时,APP与微信间还没做到数据共享,因为背后的legacy systems还是孤立的那么客户一些登记、购买行为、数据、历史消费记录都要我们的中国客户重复的操作2遍、操作3遍。。。。。。

    对不起,中国顾客对于这种重复操作2次以上而做的事是在完成同一件事的APP的使用不会超过1次,1次就删掉你!甚至拉黑你!并且还会去朋友圈把你数落一顿。这就是中国人的电商使用习惯。

    中国人喜欢 “一键式”,喜欢 “快速定位”,喜欢“3步操作内就完成一件事”。

    所以,大型零售商们错失了第一次电商黄金发展阶段即培养顾客消费习惯的这个阶段,那么这些大型零售商也意识到了问题:

    哦,这个问题出在后面的系统本来在打造的时候就是CS架构、本来就是一个个孤立的而导致的。

    在此时,大型零售商还是没有意识到自己的危机因为这时阿里淘宝还没有完全起势,大家都认为阿里脑子有水了,连续4次的双11。再説了,他们卖的东西不如我们的有“品牌”,对吧?

    那么现在大量的客户反馈説,你们的几个APP要变成一个APP才好用,所以大家就不约而同的想到了把后面的系统集成在一起,使得每一个系统不是孤立的对外服务了。

    同时,业内不乏I.O.E体系等造势宣称SOA,于是乎在“SOA可能是未来20年仅有的发财机会”这句口号的带领下,零售系统的改造进入了“集成1.5时代”。

     

    零售电商1.5模式-集成模式

    2007~2012年是“集成模式”概念被抛出率最高的年代,它有一个名字叫“SOA”,SOA就是那个时代的“全渠道中台”。

    以I.O.E为首尤其是IBM对SOA进行了系统化、理论化甚至到了产品化的密集布局与宣传,人们提起SOA一定会想到IBM或者是Oracle。

    嘿嘿!

    笔者突然想起2000年初时,有关于互联网的一个笑话:説人人都説这座山上有金子,于是所有人上山挖金子。结果挖金子的人没有发财,倒是山下那个“卖铲子的人”发了财

    系统集成就由如上图一样,复杂无比。

    一堆的Legacy,几十个Legacy,每个接口不同,要把它们集成光开发人员的付出就需要花费大量的时间与精力,很多企业为了不必要的自己去养开发团队为了图快于是使用了各种商业级别的、恶狠狠的集成工具(SOA开发环境)乃至付出了小型机的代价来集成一堆的Legacy。

    这些恶狠狠的工具的使用、错综复杂的系统间如蜘蛛网的连线的一切目的就是为了一个“one app can integrate all function”,一个APP所有功能。

    看似是这么一回事,可是,这次一些“巨头甲方”们却付出了惨重的代价!!!

    上面説了,集成这些Legacy本身是一件很复杂的事,因此需要使用不少在当时被称为“RAD-快速应用开发工具”来做这样的集成,这样的工具基本出自I.O.E体系,动辄几千万RMB一套,甚至还要用上百万的小型机去部署。

    钱花了,如果东西出来了倒也成了,关键是SOA还有一整套完整的“系统集成”体系化的概念。所以经历过SOA集成的都领教过所谓的“流程”。

    大家知道,所谓流程是一套best practice,它是用来帮助我们更好的更有条理的在一个如此宠大繁杂的、多达十几个几十个legacy系统集成中遵循的一条最佳途径,它并不是条条框框的死板的理论。

    至于流程是否我们真的学到了、消化了同时是否运用得当这是后话不会在本章展开,后面的章节我们会来讨论,我们就先説用SOA没有用好拿它集成完了的东西带来了什么样的噩梦吧。

    好,下面是一个运行SOA系统集成理念集成好的东西,当年国内很多大公司就是这么干的!

    这是后台用SOA理念集成好的东西,但是它在面临中国市场时又被打得体无完肤了。为什么呢?

    因为在I.O.E准备恶狠狠的、用昂贵的SOA的RAD套件进行密集推销时,我们国内的电商已经开始面临百万、千万甚至亿万级的流量了。什么东西到了中国一来,都会使用到各种高技术,国外对这点非常想不通!为什么呢?其实事情很简单,因为中国的人多,人多那么数字化流量也一定大么!中国人已经在开始思考解决大并发大流量的时候而国外还在考虑如何把“昂贵的铲子”去卖给大型零售商。于是,差距开始造成了!

    一个欧州国家的人口甚至整个欧州人口加在一起都不一定有我们的一个门户级网站的流量的人口多,势必这些国外的“高大上”会遇到水土不服,于是。。。买完了铲子,更可怕的噩梦发生了。

    频繁的CR带来的系统开发维扩成本急剧上升

    大家都知道,一个系统、一段代码它一定会经历“分析、设计、编码、测试、部署”几个阶段。如果这段代码有任何修改,它要再进行bug fix后再需要走一遍“分析、设计、编码、测试、部署”这几个阶段。

    大家知道吧,很多供应商有时为了进入一家企业做项目,它们在一开始可以跳水价、可以大甩买甚至可以0元进入,那么它挣的是什么钱呢?CR!

    对,有任何一个CR,如果再加上它是一个高大上的国外的所谓著名品牌,那么它的man day的费用会很高。比如説国内的人天单价在2,000~3,000,国外可能起板要收你4,000~6,000元的人天单价,其实人天单价6,000也已经算便宜的啦 ,你们真的没尝过8,000~1万、4万的人天单价呢!!!

    那么对于这样的公司来説,它最开心的就是甲方给他做CR,最好你依赖它,改个接口都要靠它。接口一个收8万,爽啊!!!

    好,一个复杂的系统集成完了,稍稍有任何改动,它牵连的可不只是它自己这一块代码,它会牵连到其它相关的代码,这种问题我们把它称为regression bug,为了做好regression bug的控制我们就要做regression test来保证我的这次改动不会影响到其它无关的功能。

    要知道,系统集成和"系统融和”是完全不一样的。系统集成的内部就是一团“乱麻”,业务层代码咬合在了一起,改一个功能就会引发一系列连锁反映。

    我举个例子来説,国外的系统集成或者説是很多国内软件供应商并未真正把SOA的理念吃透、甚至在瞎用,它们的手法就有点像“把一个人放在病床上,然后为了给这个病人安装一根假手指而需要把这个病人的整条手臂先卸下来,装上手指后再把这个手给病人安上”。

    它就由如下图哪怕是新增一个功能它要动到的也是一系列的“翻原代码”的行为,加上国内IT从12年后发展越来越快、整体行业较浮燥,导致国内程序员水平普遍很低。缺乏整体数据流、业务串联的能力,那么这样的改动引起的连锁反应会更大。

    拿我司曾发生过的一个案例来説,要在原有系统上做一个大闸蟹打折活动,这种设计的做法就是:

    • 设计数据库底层
    • 制作DAO
    • 制作SERVICE
    • 制作Controller
    • 制作页面

    然后有任何bug,bug的修复会把整个软件开发生命周期从头到尾再来一遍,这样的事不断的again, again, again。

    于是,一个活动做个80多人天,花掉10几万20万很正常。如果碰到“高大上”的外企来给你集成,那么把80人天剩4,000,6,000...那么做一个活动用掉个50万,80万,很合理呀。这就是我们很多国内的一 些大型零售企业在系统集成时碰到过的大血坑。

    钱,花了很多,效率又低,质量又差。

    这次的赫兹花了2亿做电商做砸了正是碰到这样的一个血坑。

    如果只是钱的问题还可以容忍,关键在这样的系统集成来到了国内碰上的最坑爹的是“系统并发”问题。

    前面説了,国内的人多,数字化流量高,这样的一种其本身后台legacy system还未经过改造只是遵照着SOA理念去做的系统集成出来的东西是根本挡不了大规模的“并发”的,国内动不动就来个十万级、百万级并发。。。。。。

    这种后台实际上充满着“单体”应用的电商应用APP,实际上是一个连千级并发都撑不住的东西,于是花了钱又做不好事,好了。。。很多企业没有死在“业务领域的竞争”中而是死在了“在国内上了电商系统”后死这个原因上了。

    成就了一上电商就死,电商领域成了一个“95%的电商项目都失败”这么一个“炼狱”了。

    于是基于“系统集成1.5”后又诞生了“系统集成2.0”模式,这次,卖铲子的又没有错过挣钱的好机会于是它提出了SOA2.0模式。

    SOA2.0模式

    这是I.O.E相关的体系们提出的SOA2.0模式,它很理论。但是它在2012~2014年间在其理论框架的指导下诞生了不少衍生技术。

    比如説它的“松耦合,高内聚,组件间无状态,外部模块间需要使用引用,强调系统整体监控、性能上的governance”,等衍生出了轻量级的Nginx、JSON API,ELK,NOSQL等一系列概念和组件甚至优化改造过了一系列之前的时代没有出现过的组件。

    可是当I.O.E体系还只停留在提出这些理念和这些组件的时侯,而我们国内的电商正在发生着巨变。历尽4次双11消费习惯培养后阿里完成了40亿到百亿规模的转变,此时它开始做一件事,那就叫去I.O.E。不要你那些动不动几百、几千万的软硬件了,我们国人一切靠自己来还比你们做了好!

    阿里去I.O.E引起了一股mySQL浪潮。而此时的I.O.E体系也已经日落西山了,IBM在惨败苏宁案例后退出了中国,很多SOA的精华其实从未被真正落地过,同时它被很多国内的开发商错误的理解和使用了,使用的目的也只是为了炒概念、卖高价。在当时,国内有超过90%的开发商认为:NGINX去代Apache,轻TOMCAT,JSON API,ELK,mySQL的组合就可以做电商了。

    OH...MY...GOD!

    首先理念错误、理解不透彻加上整体IT环境浮燥、只求实现不求精的风貌导致了又出现了一个API时代的怪胎,我们説API是一个好东西,可是它造出的怪胎更诡异!

    先从开发团队来错误的理解SOA2.0理念开始分析,下面是一个标准的在当时直到现在还有很多开发团队是这么认为的一种项目分工上的划分模式。

    我们拿JAVA项目来説,把系统划分成这么多子模块,再分别开发和打包以及分布式部署,这就是SOA!

    一切看似那么的自然。。。。。。那么的应该。。。。。。那么的。。。最后在面临国内十万、百万、千万级并发时死得那么的惨

    • 淘宝惨烈过
    • JD也惨烈过

    要不然怎么会出现“JD老刘的两把菜刀”的故事呢?以前去深圳学习JD618保卫战时还听説这个“两把菜刀”是真事呢!!!

    我们来看看工程项目上折的细又小、看似专业实际没有深入理解SOA2.0时代的精髓而只学到了表面的东西导致在当年产出的是一种什么样的怪胎吧。让我们直接从系统层面入手分析

    两个架构,先説一下其实都是“怪胎”;

    尚且不説第二个“看似专业设计架构”很多国内的供应商、软件开发团队还未达到只达到了前一种“通用设计架构”的水平,第二种架构再怎么説也比第一种要好一点,我们把它称为怪胎1.0和怪胎2.0版吧。

    怪在哪呢?下面来分析怪胎2.0版。

    场景发生在某大促的当天,在平时怪胎架构一点问题都不会发生,一切看似相当的正常和完美。而当大促这天一到,抢券、秒杀、折上折一开始:

    1. Web层汹涌压力扑面而来,这时的反映就是用户手机APP端卡死、白屏、卡顿、没反映;
    2. 于是运维一看Zabbix,哇~所有Web服务器标红,业务老板在屁股后面催的紧“快点搞定”,于是乎运维紧急增加Web服务器;
    3. 好,Web流量进来了,tomcat层吃不消了,zabbix频频告警,老板在屁股后面又开始催了“怎么还没搞定?”。于是我们增加tomcat服务器;
    4. tomcat扩了N个自以为没事了,加完后整个DB挂了,CPU飙升到100%以上,内存使用率高达95%以上,一堆的死锁,APP还是卡、白屏,这时已经距离活动开始过去了1小时了,业务老板破口大骂:“你们有没有做过电商呀,你们到底懂不懂,搞不定,滚”
    5. 这时运维傻了。。。介个问题。。。需要研发来帮忙了
    6. 好吧,活动第一天,失败。老板组织了研发、运维浩浩荡荡一大批开了个总结大会来研究第二天的方案,研发终于提出了靠谱的方案。很多内容可以走缓存,我们不该走DB的。于是大家开始了不要命的熬夜改造DAO层代码,把一些通用的都移到缓存;
    7. 此时,离第二天还剩4个半小时左右了,抓紧睡一觉吧,很多开发睡觉时还在做美梦,梦到第二天因为开发团队的给力付出我们终于顶下了流量,老板重点表扬开发;
    8. 第二天活动开始了,哇~一开始30秒时整个流量似乎比昨天大了2-3倍,这个很正常呀因为系统放开了吃流量肯定这个量超过昨天的量,然后30秒过了没多久,整个APP卡死、白屏。哈哈哈,再一看,缓存爆了,缓存爆了后流量落到DB,DB又来了一个CPU飙升到100%以上,内存使用率高达95%以上。。。。。。
    9. 再加DB,DB加完后发觉第三天量更大了,再加Web,Web加完后Tomcat中间群被压跨了,再回到以上第3点

    多少企业经历了上述的过程?我告诉大家一个值,超过90%的企业都有过上述的大血坑。

    这个大血坑会造成不少创业型公司秒死、见光死,也造成很多大企业一整批IT被干掉,也造就了那传説中的“两把菜刀”。

    这样的系统和设计它其实是由如下面的这样的一个怪胎的长相:

    脑袋小,脖子细的要命,肚子大,下盘小。吃饭吃多了他就呕,走路一快他就摔!这么样的一个怪胎!

    那么我们説系统性能没有做好?业务功能就一定做好了吗?

    嘿嘿嘿,我们回看I.O.E体系们在SOA2.0时代提出的一个概念图,再来看一遍这个图

    然后我们结合以下的一个场景再来考虑一下:

    小龙虾节活动,从数据库设计->存取层->服务层->控制层。从头到尾做了一遍,用掉了80多人天的价格。

    来了一个阳澄湖大闸蟹打折活动,从数据库设计->存取层->服务层->控制层。从头到尾做了一遍,又用掉了80多人天的价格。

    嘿嘿嘿,我们把以上深奥的理论,抽像成以下一个这样的业务场景大家看一下,是不是就可以理解为什么上述两个都同样是打折活动的业务场景分别都要用80多人天呢?

    上图已经可以很好的说明我们的程序员是如何沦落到程序猿、码农的了。

    性能达不到、加速业务、快速响应多变的由其是中国大陆市场几乎每天都在变动的业务也做不到,这是2005~2015年这10年国人特别是国内很多知名500强在电商领域经历的痛苦的10年,各种抱怨IT不给力。

    IT各种想办法找I.O.E相关体系来做企业整体解决方案,钱出了一大波,然并卵,各种继续不给力、抱怨。。。。。。again,again and again!!!

    而这10年,阿里和一些走在比较前沿或者説曾经在那10年内没有“死”的一些民营体制、特别接中国地气的企业他们已经开始深刻得总结、反省、并且依靠着自身之前学习到那些外资高大上的一些理论、知识、方法论后把它们再“本土化”并结合了中国自身特色,继而打造出来了一个新的产物,这个新的产物就是“全渠道零售中台”。

     

    回过头来看中台,什么是中台

    也有画成下面这样风格的图

    其实第2张图和第1张无非就是第一张的level3级别功能扩充了比较丰富点,第二张呢颜色鲜明一些。

    That's it,仅次而己!

    然后很多外资包括国内的一些甲方型企业拿着这样的图説“这就是中台”。。。。。。现在知道错在哪了吧。

    我上面列举的1.0,1.5,2.0时代的任何一种架构,其实都可以做成这样的“业务功能图”。

    这只是业务功能图而己,它不是代表"我“做出来的就一定是中台。

    我们看事务不能光看“外表”,我们需要看事物的“本质”,遵循着本质的那些公司都成功了,如阿里、苏宁、保洁、立白、海尔、华为。。。。。。有很多不再多叙。

    那么中台的本质到底在什么?而且是一个全渠道中台,也有人管它叫云中台它必须具备以下几样东西

    从业务功能上来分

    1. 全渠道订单中心,它必须是一个全渠道的订单中心,订单属性拥有线上、线下、O+2、第三方等各种渠道的特性;
    2. 全渠道商品管理中心,可以管理线上、线下甚至是虚拟商品;
    3. 全渠道会员中心,这个会员中心一分为2,一个合格的中台需要具备其中的CRM Foundation即会员中心基础功能,另一个叫“营销中心”,对,整个会员中心由“基础功能+营销中心”两部分构成,而很多好的中台不一定包括这个“营销中心”,因为营销中心可以诞生出另一个全渠道的产品,叫SCRM。我们不要求一个全渠道的零售中台内必须包括全渠道营销中心,必竟术业要有专精;
    4. 全渠道的促销中心,促销和营销很多人会搞起来,促销中心和营销中心在功能上是有相近的,有人把促销归为营销也有人把促销和营销进行分离,分离的条件就是“以会员为中心”和根据一个企业内的业务组织架构来决定的。这一定一定是一个全渠道的促销中心,它可以对线上线下同时促销,説白了就是你在手机APP商城内使用的券同时也可以使用在自助机、扫码购、微信小程序甚至在同一个零售企业门店POS结帐时使用,让客户无论是在线上还是在线下消费时“无缝/无差别”体验,这就叫全渠道。不管你什么活动、打折、促销,它还都是可以支持图形化界面可配置的;
    5. 内容中心,它又被称为CMS即Content Management System。它可以把手机、微信小程序、Web网站通过图形化类似于Photoshop或者説它比较接近于以前的DreamWeaver或者是FrontPage的一种“傻瓜”界面把这些活动给配置出来,它在配置的时候是可以通过结合前面的促销中心去做“协同工作”的;
    6. 财务共享中心-支付渠道啦、支付中心啦,支持各种支付,接入支付渠道时它也是可配置或者説是“半可配置”来完成一个支付渠道的接入的;
    7. 物流库存中心,支持全渠道的物流和库存,不管是自营、O+O、第三方还是自提,全部支持;
    8. 多租户管理中心,咦。。。。。。这是什么东西?唉呀,很简单!都上全渠道中台了,你这个电商不可能只是面向垂直单一名牌吧?一定是类似于“天猫店”那种多商户玩法吧?也有人管它叫B2B2C或者干脆简称成BBC功能;

    从技术上来分(月球的背面到底是什么)

    我们前面説了,业务功能它的表现出给到大众的一面很美丽、很灿烂。可是它不是本质,它不代表全渠道中台,我们需要了解月球的背后到底是什么?是不是真的有ET?喂。。。老婆,出来看上帝啊!

    从技术上来説一个全渠道必须具备如下几大功能,缺一不可,对。。。缺一不可!

    1. 微服务总线,这是必须要有的,真正的微服务讲究的是什么哈?我们先不説微服务所有的细节功能单説涉及到我们性能的那么几个功能吧:1)平峰削谷 2)服务自发现 3)服务升级降级 4)可弹性扩充,只説这4个点,有这4个点绝大多数的零售电商网站够用了,除非你能达到淘宝的量,我们后面章节会把微服务功能逐个剖析、亲自动手设计、乃至实现
    2. 各业务模块可纵向扩展,横向扩展是很简单的事,什么叫业务模块纵向扩展?比如説订单的写入和读都可以作分开的部署
    3. 可弹性的分布式的并且是多样化的缓存群
    4. 异步消息队列-MQ,必不可少
    5. 规则引擎,你当促销中心是怎么实现的?嘿
    6. HTTP请求级别缓存,这个缓存可和后台的那个分布式缓存群是不一样的东西哦,它缓存的是用户请求,相当于一个CDN功能但是和CDN又不一样,因为CDN只能缓存绝对静态的内容
    7. 分布式批处理任务-类似于网络计算,它比网格计算更轻、小
    8. 标准的安全认证登录接口,支持最常用的如:JWT,OAUTH2等协议
    9. 支持分步式数据库,此处可不只是一个数据库,你要有钱可以去烧Oracle RAC,阿里在20~40亿时为什么它要去I.O.E?那么用开源的数据库你需要怎么去实现原来的Oracle RAC的功能呢?当然你雇了一堆的架构师自己也是可以去打造这样的分布式数据库的结构应用的,只是一个产品如果它的原生就支持分布式数据库、分布式事务、可折表折库(此处指的可是纵向折哦),横向谁不会无非就是加slavers:)
    10. 成熟的性能监控
    11. 成熟的CI(持续集成)组件
    12. 配置中心,一个全渠道中台,组件少的有10多个模块,每个模块至少2-3个服务器,多的几十个模块,oh my god,全部写在properties文件里?Are you kidding me?

    所以,月球的背面长的是个什么样的呢?即什么是真正的全渠道零售中台?

    全渠道零售中台的“真容”

    我用下面的这张图来解析全渠道零售中台的技术的面长成个什么样!

    把我这篇文章的第1张图配合着全文最后一张图来看,那么你看的才是一个真正的全渠道中台!

    这两张图:

    1. 只看第1张,你会被人忽悠的体无完肤,出了钱买不到好东西;
    2. 只看第2张而不看第1张的结果是,你可能买到的不是一个产品级的解决方案而只是一个技术框架,一切业务功能需要从头开发,这是巨大的工作量和成本的付出;

    但是,不代表你把上述2张图结合起来看了就一定可以找中你“命中的中台”,还有很多、很多其它因素需要考虑。

     

    最后説一下为什么叫中台这个“中”字呢

    从业务层面解析为什么叫“中”台

    中台,我们的国人为了解决“TO C端业务的快速多变”,使用的是诸多非功能性需求如CMS+规则引擎+图形化编程,其实説白了就是把TO C端的前端的逻辑“下沉”,下沉到了这个中台系统中而不是停留在APP端 ,把APP端的功能做成了可以通过后台配出来,我之前的博客説过,所谓IT上口头説的“业务业务”,指的就是用户端功能,而不是让你去考上岗证。

    中国人做的这种高度一体化方案是基于可以彻底抛弃ERP的思想来做的,做什么legacy system的改造呢?这些功能在中台里已经有了,把你原来企业那10几个legacy system的数据做一次性的迁移,然后系统一刀切掉就好了,这是中国人的思路!但是中台在推出不久后它又要兼顾着中国人自古的“包容”精神,即我又要可以支撑原有legacy system和我的集成。那么,把原有后台legacy system的功能也放到这个中台系统中,因此它是后台业务功能的“上浮”。

    一个TO C端业务的下沉;

    一个后台业务功能的上浮;

    而中台它处于当中这一块地位,因此它就叫“中”台!

    而不是很多人认为,它处于后台和APP手机端应用的当中因此才叫中台的,不是的。这个理解太表面了没有真正理解中台的中到底为什么要叫中的背后的原理,中台的“中”是我上述这一段总结,这是业界真正公认的“中”。

    因此我这一系列文章才不仅仅只是写业务(解决方案)或者写技术,还要写数字化变形、写管理、写策略。。。。。。后面我们还会有更多精彩!

    先预告一些下一章内容吧:

    下一章我会对全渠道零售中台中的业务功能、技术组件一个个折开来、揉碎了和大家讲解!

    展开全文
  • 虚拟技术的分类及介绍

    万次阅读 多人点赞 2019-01-03 19:45:06
    虚拟技术的分类及介绍   摘要 虚拟是云计算系统中的一种基础技术,可以说当前一个云计算服务必定是构建在虚拟的基础上的。本文首先介绍了不同抽象层次的虚拟技术,之后对应用广泛的系统级虚拟和操作...

    虚拟化技术的分类及介绍

     

    摘要

    虚拟化是云计算系统中的一种基础技术,可以说当前一个云计算服务必定是构建在虚拟化的基础上的。本文首先介绍了不同抽象层次的虚拟化技术,之后对应用广泛的系统级虚拟化和操作系统级虚拟化进行了更详细的分类和描述,最后介绍了各种典型虚拟化方案的具体实现。

     

    目录

    摘要 1

    目录 1

    1 引言 2

    2 虚拟化技术的分类 2

    2.1 不同抽象层次的虚拟化技术 3

    2.1.1 硬件抽象层上的虚拟化 3

    2.1.2 操作系统层上的虚拟化 3

    2.1.3 库函数层上的虚拟化 3

    2.1.4 编程语言层上的虚拟化 4

    2.2 系统级虚拟化 4

    2.2.1 可虚拟化架构和不可虚拟化架构 4

    2.2.2 按照实现方法分类 5

    2.2.3 按照实现结构分类 6

    2.3 操作系统级虚拟化 7

    3 典型虚拟化技术实现及其特点 8

    3.1 系统级虚拟化实现 8

    3.1.1 VMware 8

    3.1.2 Microsoft 9

    3.1.3 Xen 9

    3.1.4 KVM 10

    3.1.5 Oracle VM VirtualBox 10

    3.1.6 Bochs 10

    3.1.7 QEMU 10

    3.2 操作系统级虚拟化实现 10

    3.2.1 chroot 10

    3.2.2 LXC 11

    3.2.3 Docker 11

    3.2.4 Linux VServer 11

    3.2.5 Virtuozzo/OpenVZ 11

    参考文献 11

     

    1 引言

    虚拟化是计算机系统中的一个重要概念,基本上每个计算机系统都提供一个给上层软件的界面,从处理器提供的基本指令集到很多中间件系统提供的巨大的应用程序界面集。虚拟化本质上是扩展或替换一个现存界面来模仿另一个系统的行为,其对计算机系统的重要性主要体现在以下几个方面。

    相比高层软件(比如中间件和应用软件),硬件和底层系统软件变化得比较快,也就是说,我们面对的一种情况是旧有软件的维护跟不上下层平台更新的步伐。通过移植旧有软件的底层接口到新平台,可使得一大类的现有软件可以立刻在新平台上工作。

    在服务器机器上,一个组织为它提供的每个服务都分配一台虚拟机,接着,将虚拟机以最佳方式分配到物理服务器上。与进程不同,虚拟机能很简单地迁移到其他物理机器上,这增加了管理服务器基础设施的灵活性。这个方法能潜在地减少服务器计算机的投资并减少能量消耗,后者是大型服务器中心的关键问题。

    虚拟化技术和云计算的提供极为相关。云计算采用了这样一个模型,即作为一个服务,提供云上创建的存储、计算和高层对象。所提供的服务覆盖从诸如物理体系结构等的底层方面(基础设施即服务IaaS)到诸如软件平台(平台即服务PaaS),再到任意应用层次的服务(软件即服务SaaS)。云服务的提供被虚拟化技术直接驱动,允许为云的用户提供一个或多个虚拟机,供用户自己使用。

    分布式应用的需求也激发虚拟化解决方案的开发者去以很少的开销创建和销毁虚拟机。在可能需要动态地请求资源的应用中,这是必要的。例如对于多人在线游戏或分布式多媒体应用,通过采用合适的资源分配策略满足虚拟机服务质量需求,能提升对这样的应用的支持度。

    另一个好处是,在单台计算机上提供对几个不同操作系统环境的便利访问,虚拟化可用于在一种物理体系结构上提供多种操作系统类型。

    虚拟化技术起始于IBM370体系结构,它的VM操作系统能为运行在同一计算机上的不同程序提供几个完整的虚拟机。最近,人们对虚拟化的兴趣大增,有许多研究项目和商业系统为商用PC、服务器和云基础设施提供虚拟化解决方案。

     

    2 虚拟化技术的分类

    现代计算机系统是一个庞大的整体,整个系统的复杂性是不言而喻的。因而,整个计算机系统被分成了多个自下而上的层次,每一个层次都向上一层次呈现一个抽象,并且每一层只需知道下层抽象的接口,而不需要了解其内部运作机制。这样以层的方式抽象资源的好处是每一层只需要考虑本层设计以及与相邻层间的相互交互,从而大大降低了系统设计的复杂性,提高了软件的移植性。

    本质上,虚拟化就是由位于下层的软件模块,通过向上一层软件模块提供一个与它原先所期待的运行环境完全一致的接口的方法,抽象出一个虚拟的软件或硬件接口,使得上层软件可以直接运行在虚拟的环境上。虚拟化可以发生在现代计算机系统的各个层次上,不同层次的虚拟化会带来不同的虚拟化概念。

    如前文所述,虚拟化技术起源于上世纪70年代的IBM370体系,经过四十余年的发展,当前存在诸多实现在不同层次的虚拟化技术,原理不尽相同,且每一种技术都相当复杂。在本文中,将通过不同的角度对目前存在的较流行的虚拟化技术进行分类,并对其原理进行初步介绍,旨在对纷繁复杂的虚拟化技术有个整体认识及厘清不同虚拟化技术之间的相互关系。

     

    2.1 不同抽象层次的虚拟化技术

    在介绍各种虚拟化概念之前,先介绍虚拟化中的两个重要名词。在虚拟化中,物理资源通常有一个定语称为宿主(Host),而虚拟出来的资源通常有一个定语称为客户(Guest)。

    在计算机系统中,从底层至高层依次可分为:硬件层、操作系统层、函数库层、应用程序层,在对某层实施虚拟化时,该层和上一层之间的接口不发生变化,而只变化该层的实现方式。从使用虚拟资源的Guest的角度来看,虚拟化可发生在上述四层中的任一层。应当注意,在对Guest的某一层进行虚拟化时,并未对Host在哪一层实现它作出要求,这一点是时常引起混淆的地方。

     

    2.1.1 硬件抽象层上的虚拟化

    硬件抽象层上的虚拟化是指通过虚拟硬件抽象层来实现虚拟机,为客户机操作系统呈现和物理硬件相同或相近的硬件抽象层,又称为指令集级虚拟化,实现在此层的虚拟化粒度是最小的。

    实现在此层的虚拟化技术可以对整个计算机系统进行虚拟,即可将一台物理计算机系统虚拟化为一台或多台虚拟计算机系统,故又可称作系统级虚拟化。每个虚拟计算机系统(简称为虚拟机)都拥有自己的虚拟硬件(如CPU、内存和设备等),来提供一个独立的虚拟机执行环境。每个虚拟机中的操作系统可以完全不同,并且它们的执行环境是完全独立的。由于客户机操作系统所能看到的是硬件抽象层,因此,客户机操作系统的行为和在物理平台上没有什么区别。

     

    2.1.2 操作系统层上的虚拟化

    操作系统层上的虚拟化是指操作系统的内核可以提供多个互相隔离的用户态实例。这些用户态实例(经常被称为容器)对于它的用户来说就像是一台真实的计算机,有自己独立的文件系统、网络、系统设置和库函数等。

    由于这是操作系统内核主动提供的虚拟化,因此操作系统层上的虚拟化通常非常高效,它的虚拟化资源和性能开销非常小,也不需要有硬件的特殊支持。但它的灵活性相对较小,每个容器中的操作系统通常必须是同一种操作系统。另外,操作系统层上的虚拟化虽然为用户态实例间提供了比较强的隔离性,但其粒度是比较粗的。

     

    2.1.3 库函数层上的虚拟化

    操作系统通常会通过应用级的库函数提供给应用程序一组服务,例如文件操作服务、时间操作服务等。这些库函数可以隐藏操作系统内部的一些细节,使得应用程序编程更为简单。不同的操作系统库函数有着不同的服务接口,例如Linux的服务接口是不同于Windows的。库函数层上的虚拟化就是通过虚拟化操作系统的应用级库函数的服务接口,使得应用程序不需要修改,就可以在不同的操作系统中无缝运行,从而提高系统间的互操作性。

    例如,Wine就是在Linux上模拟了Windows的库函数接口,使得一个Windows应用程序能够在Linux上正常运行。

     

    2.1.4 编程语言层上的虚拟化

    另一大类编程语言层上的虚拟机称为语言级虚拟机,例如JVM(Java Virtual Machine)和微软的CLR(Common Language Runtime)。这一类虚拟机运行的是进程级的作业,所不同的是这些程序所针对的不是一个硬件上存在的体系结构,而是一个虚拟体系结构。这些程序的代码首先被编译为针对其虚拟体系结构的中间代码,再由虚拟机的运行时支持系统翻译为硬件的机器语言进行执行。

     

    2.2 系统级虚拟化

    系统级虚拟化即硬件抽象层上的虚拟化、指令集级虚拟化,是最早被提出和研究的一种虚拟化技术,当前存在多种此种技术的具体实现方案,在介绍它们之前,有必要先了解实现系统级虚拟化可采取的途径。

    在每台虚拟机中都有属于它的虚拟硬件,通过虚拟化层的模拟,虚拟机中的操作系统认为自己仍然是独占一个系统在运行,这个虚拟化层被称为虚拟机监控器(Virtual Machine Monitor,VMM)。VMM对物理资源的虚拟可以归结为三个主要任务:处理器虚拟化、内存虚拟化和I/O虚拟化。其中,处理器虚拟化是VMM中最核心的部分,因为访问内存或进行I/O本身就是通过一些指令来实现的。

     

    2.2.1 可虚拟化架构和不可虚拟化架构

    在系统级虚拟化中,虚拟计算机系统和物理计算机系统可以是两个完全不同ISA(Instruction Set Architecture,指令集架构)的系统,例如,可以在一个x86的物理计算机上运行一个安腾的虚拟计算机。但是,不同的ISA使得虚拟机的每一条指令都需要在物理机上模拟执行,从而造成性能上的极大下降。

    显然,相同体系结构的系统虚拟化通常会有比较好的性能,并且VMM实现起来也会比较简单。这种情况下虚拟机的大部分指令可以在处理器上直接运行,只有那些与硬件资源关系密切的敏感指令才会由VMM进行处理。此时面前的一个问题是,要能将这些敏感指令很好地筛选出来。但事实上,某些处理器在设计之初并没有充分考虑虚拟化的需求,导致没有办法识别出所有的敏感指令,因而不具备一个完备的可虚拟化结构。

    大多数的现代计算机体系结构都有两个或两个以上的特权级,用来分隔系统软件和应用软件。系统中有一些操作和管理关键系统资源的指令会被定为特权指令,这些指令只有在最高特权级上才能够正确执行。如果在非最高特权级上运行,特权指令会引发一个异常,处理器会陷入到最高特权级,交由系统软件来处理。

    在x86架构中,所有的特权指令都是敏感指令,然而并不是所有的敏感指令都是特权指令。

    为了VMM可以完全控制系统资源,它不允许虚拟机上操作系统直接执行敏感指令。如果一个系统上所有敏感指令都是特权指令,则能够用一个很简单的方法来实现一个虚拟环境:将VMM运行在系统的最高特权级上,而将客户机操作系统运行在非最高特权级上,当客户机操作系统因执行敏感指令而陷入到VMM时,VMM模拟执行引起异常的敏感指令,这种方法被称为“陷入再模拟”。

    总而言之,判断一个架构是否可虚拟化,其核心就在于该结构对敏感指令的支持上。如果一个架构中所有敏感指令都是特权指令,则称其为可虚拟化架构,否则称为不可虚拟化架构。

     

    2.2.2 按照实现方法分类

    系统级虚拟化有许多不同的具体实现方案,按照实现方法的不同,可划分为如下几个类别。

    (1)仿真(Emulation)

    我们已经知道,通过陷入再模拟敏感指令的执行来实现虚拟机的方法是有前提条件的:所有的敏感指令必须都是特权指令。如果一个体系结构上存在敏感指令不属于特权指令,那么其就存在虚拟化漏洞,可以采用一些方法来填补或避免这些漏洞。最简单直接的方法是,所有指令都采用模拟来实现,就是取一条指令,就模拟出这条指令执行的效果。这种方法称作仿真。

    仿真是最复杂的虚拟化实现技术,使用仿真方法,可以在一个x86处理器上运行为PowerPC设计的操作系统,这在其它的虚拟化方案中是无法实现的。甚至可以运行多个虚拟机,每个虚拟机仿真一个不同的处理器。此外,这种方法不需要对宿主操作系统的特殊支持,虚拟机可以完全作为应用层程序运行。

    正如前面提到的,使用仿真方法的主要问题是速度会非常慢。由于每条指令都必须在底层硬件上进行仿真,因此速度减慢100倍的情况也并不稀奇。若要实现高度保真的仿真,包括周期精度、CPU的缓存行为等,实际速度差距甚至可能会达到1000倍之多。

    使用这种方式的典型实现是Bochs。

    (2)完全虚拟化(Full Virtualization)

    在客户操作系统看来,完全虚拟化的虚拟平台和现实平台是一样的,客户机操作系统察觉不到是运行在一个虚拟平台上,这样的虚拟平台可以运行现有的操作系统,无须对操作系统进行任何修改,因此这种方式被称为完全虚拟化。

    进一步说,客户机的行为是通过执行反映出来的,因此VMM需要能够正确处理所有可能的指令。在实现方式上,以x86架构为例,完全虚拟化经历了两个阶段:软件辅助的完全虚拟化和硬件辅助的完全虚拟化。

    ①软件实现的完全虚拟化

    在x86虚拟化技术的早期,没有在硬件层次上对虚拟化提供支持,因此完全虚拟化只能通过软件实现。一个典型的做法是二进制代码翻译(Binary Translation)。

    二进制代码翻译的思想是,通过扫描并修改客户机的二进制代码,将难以虚拟化的指令转化为支持虚拟化的指令。VMM通常会对操作系统的二进制代码进行扫描,一旦发现需要处理的指令,就将其翻译成为支持虚拟化的指令块(Cache Block)。这些指令块可以与VMM合作访问受限的虚拟资源,或者显式地触发异常让VMM进一步处理。

    这种技术虽然能够实现完全虚拟化,但很难在架构上保证其完整性。因此,x86厂商在硬件上加入了对虚拟化的支持,从而在硬件架构上实现了虚拟化。

    ②硬件辅助完全虚拟化

    可以预料,如果硬件本身加入足够的虚拟化功能,可以截获操作系统对敏感指令的执行或者对敏感资源的访问,从而通过异常的方式报告给VMM,这样就解决了虚拟化的问题。硬件虚拟化时一种完备的虚拟化方法,因而内存和外设的访问本身也是由指令来承载,对处理器指令级别的截获就意味着VMM可以模拟一个与真实主机完全一样的环境。

    Intel的VT-x和AMD的AMD-V是这一方向的代表。以VT-x为例,其在处理器上引入了一个新的执行模式用于运行虚拟机,当虚拟机执行在这个特殊模式中时,它仍然面对的是一套完整的处理器寄存器集合和执行环境,只是任何敏感操作都会被处理器截获并报告给VMM。

    在当前的系统级虚拟化解决方案中,全虚拟化应用得非常普遍,典型的有知名的产品有VirtualBox、KVM、VMware Workstation和VMware ESX(它在其4.0版,被改名为VMware vSphere)、Xen(也支持全虚拟化)。

    (3)类虚拟化(Para-Virtualization)

    这样的虚拟平台需要对所运行的客户机操作系统进行或多或少的修改使之适应虚拟环境,因此客户机操作系统知道其运行在虚拟平台上,并且会去主动适应。这种方式被称为类虚拟化,有时也称作半虚拟化。另外,值得指出的是,一个VMM可以既提供完全虚拟化的虚拟平台,又提供类虚拟化的虚拟平台。

    类虚拟化是通过在源代码级别修改指令以回避虚拟化漏洞的方式来使VMM 能够对物理资源实现虚拟化。上面谈到x86 存在一些难以虚拟化的指令,完全虚拟化通过Binary Translation在二进制代码级别上来避免虚拟化漏洞。类虚拟化采取的是另一种思路,即修改操作系统内核的代码,使得操作系统内核完全避免这些难以虚拟化的指令。

    既然内核代码已经需要修改,类虚拟化进一步可以被用于优化I/O。也就是说,类虚拟化不是去模拟真实世界中的设备,因为太多的寄存器模拟会降低性能.相反,类虚拟化可以自定义出高度优化的协议I/O。这种I/O协议完全基于事务,可以达到近似物理机的速度。

    这种虚拟技术以Xen为代表,微软的Hyper-V所采用技术和Xen类似,也可以把Hyper-V归属于半虚拟化。

     

    2.2.3 按照实现结构分类

    在系统级虚拟化的实现中,VMM是一个关键角色,前面已介绍过VMM的组成部分。从Host实现VMM的角度出发,还可以将当前主流的虚拟化技术按照实现结构分为如下三类。

    1. Hypervisor模型

    Hypervisor这个术语是在 20 世纪 70 年代出现的,在早期计算机界,操作系统被称为Supervisor,因而能够在其他操作系统上运行的操作系统被称为 Hypervisor。

    在Hypervisor模型中,VMM首先可以被看做是一个完备的操作系统,不过和传统操作系统不同的是,VMM是为虚拟化而设计的,因此还具备虚拟化功能。从架构上来看,首先,所有的物理资源如处理器、内存和I/O设备等都归VMM所有,因此,VMM承担着管理物理资源的责任;其次,VMM需要向上提供虚拟机用于运行客户机操作系统,因此,VMM还负责虚拟环境的创建和管理。

    由于VMM同时具备物理资源的管理功能和虚拟化功能,因此,物理资源虚拟化的效率会更高一些。在安全方面,虚拟机的安全只依赖于VMM的安全。Hypervisor模型在拥有虚拟化高效率的同时也有其缺点。由于VMM完全拥有物理资源,因此,VMM需要进行物理资源的管理,包括设备的驱动。我们知道,设备驱动开发的工作量是很大的。因此,对于Hypervisor模型来说这是个很大的挑战。事实上,在实际的产品中,基于Hypervisor模型的VMM通常会根据产品定位,有选择地挑选一些I/O设备来支持,而不是支持所有的I/O设备。

    采用这种模型的典型是面向企业级应用的VMware vSphere。

     

    1. 宿主模型

    与Hypervisor模型不同。在宿主模型中,物理资源由宿主机操作系统管理。宿主机操作系统是传统操作系统,如Windows 、Linux等,这些传统操作系统并不是为虚拟化而设计的,因此本身并不具备虚拟化功能,实际的虚拟化功能由VMM来提供。VMM通常是宿主机操作系统独立的内核模块,有些实现中还包括用户态进程,如负责I/O虚拟化的用户态设备模型。 VMM通过调用宿主机操作系统的服务来获得资源, 实现处理器、内存和I/O设备的虚拟化。VMM创建出虚拟机之后,通常将虚拟机作为宿主机操作系统的一个进程参与调度。

    宿主模型的优缺点和Hypervisor模型恰好相反。宿主模型最大的优点是可以充分利用现有操作系统的设备驱动程序,VMM无须为各类I/O设备重新实现驱动程序,可以专注于物理资源的虚拟化。考虑到I/O设备种类繁多,千变万化, 设备驱动程序开发的工作量非常大,因此,这个优点意义重大。此外,宿主模型也可以利用宿主机操作系统的其他功能,例如调度和电源管理等,这些都不需要VMM重新实现就可以直接使用。

    宿主模型当然也有缺点,由于物理资源由宿主机操作系统控制,VMM得要调用宿主机操作系统的服务来获取资源进行虚拟化,而那些系统服务在设计开发之初并没有考虑虚拟化的支持,因此,VMM虚拟化的效率和功能会受到一定影响。此外,在安全方面,由于VMM是宿主机操作系统内核的一部分,因此,如果宿主机操作系统内核是不安全的,那么,VMM也是不安全的,相应地运行在虚拟机之上的客户机操作系统也是不安全的。换言之,虚拟机的安全不仅依赖于VMM的安全,也依赖于宿主机操作系统的安全。

    采用这种模型的典型是KVM、VirtualBox和VMware Workstation。

    1. 混合模型

    混合模型是上述两种模式的汇合体。VMM依然位于最低层,拥有所有的物理资源。与Hypervisor模式不同的是,VMM 会主动让出大部分I/O设备的控制权,将它们交由一个运行在特权虚拟机中的特权操作系统控制。相应地,VMM 虚拟化的职责也被分担.处理器和内存的虚拟化依然由VMM来完成,而I/O的虚拟化则由VMM和特权操作系统共同合作来完成。

    I/O设备虚拟化由VMM和特权操作系统共同完成,因此,设备模型模块位于特权操作系统中,并且通过相应的通信机制与VMM合作。

    混合模型集中了上述两种模型的优点。 VMM可以利用现有操作系统的I/O设备驱动程序,不需要另外开发。VMM直接控制处理器、内存等物理资源,虚拟化的效率也比较高。

    在安全方面,如果对特权操作系统的权限控制得当,虚拟机的安全性只依赖于VMM。当然,混合模型也存在缺点。由于特权操作系统运行在虚拟机上,当需要特权操作系统提供服务时,VMM需要切换到特权操作系统,这里面就产生上下文切换的开销。当切换比较频繁时,上下文切换的开销会造成性能的明显下降。出于性能方面的考虑,很多功能还是必须在VMM 中实现,如调度程序和电源管理等。

    采用这种模型的典型是Xen。

     

    2.3 操作系统级虚拟化

    在操作系统虚拟化技术中,每个节点上只有唯一的系统内核,不虚拟任何硬件设备。通过使用操作系统提供的功能,多个虚拟环境之间可以相互隔离。通常所说的容器(Container)技术,如目前为止最流行的容器系统Docker,即属于操作系统级虚拟化。此外,在不同的场景中,隔离出的虚拟环境也被称作虚拟环境(即VE,Virtual Environment)或虚拟专用服务器(即VPS,Virtual Private Server)。

    以容器技术为例,它有自己独特的优点,它的出现,一方面解决了传统操作系统所忽视和缺乏的应用程序间的独立性问题,另一方面,它避免了相对笨重的系统级虚拟化,是一种轻量级的虚拟化解决方案。

    操作系统领域一直以来面临的一个主要挑战来自于应用程序间存在的相互独立性和资源互操作性之间的矛盾,即每个应用程序都希望能运行在一个相对独立的系统环境下,不受到其他程序的干扰,同时又能以方便快捷的方式与其他程序交换和共享系统资源。当前通用操作系统更强调程序间的互操作性,而缺乏对程序间相对独立性的有效支持,然而对于许多分布式系统如Web服务、数据库、游戏平台等应用领域,提供高效的资源互操作同保持程序间的相对独立性具有同等重要的意义。

    主流虚拟化产品VMware和Xen等均采用Hypervisor模型(Xen采用的混合模型与Hypervisor模型差别不大,可统称为Hypervisor模型)。该模型通过将应用程序运行在多个不同虚拟机内,实现对上层应用程序的隔离。但由于Hypervisor 模型倾向于每个虚拟机都拥有一份相对独立的系统资源,以提供更为完全的独立性,这种策略造成处于不同虚拟机内的应用程序间实现互操作非常困难。例如, 即使是运行在同一台物理机器上,如果处于不同虚拟机内,那么应用程序间仍然只能通过网络进行数据交换,而非共享内存或者文件。而如果使用容器技术,由于各容器共享同一个宿主操作系统,能够在满足基本的独立性需求的同时提供高效的系统资源共享支持。

    容器技术还可以更高效地使用系统资源,由于容器不需要进行硬件虚拟以及运行完整操作系统等额外开销,相比虚拟机技术,一个相同配置的主机,往往可以运行更多数量的应用。此外,容器还具有更快速的启动时间,传统的虚拟机技术启动应用服务往往需要数分钟,而对于容器由于,直接运行于宿主内核,无需启动完整的操作系统,因此可以做到秒级、甚至毫秒级的启动时间,大大的节约了应用开发、测试、部署的时间。

     

    3 典型虚拟化技术实现及其特点

    3.1 系统级虚拟化实现

    3.1.1 VMware

    VMware是x86 虚拟化软件的主流广商之一。VMware的5位创始人中的3位曾在斯坦福大学研究操作系统虚拟化,项目包括SimOS系统模拟器和Disco虚拟机监控器。1998年,他们与另外两位创始人共同创建了VMware 公司,总部位于美国加州Palo Alto。

    VMware提供一系列的虚拟化产品,产品的应用领域从服务器到桌面。下面是VMware主要产品的简介,包括VMware ESX、VMware Server和VMware Workstation。

    VMware ESX Server是VMware的旗舰产品,后续版本改称VMware vSphere。ESX Server基于Hypervisor模型,在性能和安全性方面都得到了优化,是一款面向企业级应用的产品。VMware ESX Server支持完全虚拟化,可以运行Windows 、Linux、Solaris和Novell Netware等客户机操作系统。VMware ESX Server也支持类虚拟化,可以运行Linux 2. 6. 21 以上的客户机操作系统。ESX Server的早期版本采用软件虚拟化的方式,基于Binary Translation技术。自ESX Server 3开始采用硬件虚拟化的技术,支持Intel VT技术和AMD-V技术。

    VMware Server之前叫VMware GSX Server,是VMware面向服务器端的入门级产品。VMware Server采用了宿主模型,宿主机操作系统可以是Windows或者Linux。VMware Server的功能与ESX Server类似,但是在性能和安全性上与ESX Server有所差距。VMware Server也有自己的优点,由于采用了宿主模型,因此VMware Server支持的硬件种类要比ESX Server多。

    VMware Workstation是VMware面向桌面的主打产品。与VMware Server类似,VMware Workstation也是基于宿主模型,宿主机操作系统可以是Windows或者Linux。VMware Workstation也支持完全虚拟化,可以运行Windows、Linux、Solaris、Novell Netware和FreeBSD等客户机操作系统。与VMware Server不同, VMware Workstation专门针对桌面应用做了优化,如为虚拟机分配USB设备,为虚拟机显卡进行3D加速等。

     

    3.1.2 Microsoft

    微软在虚拟化产品方面起步比VMware晚,但是在认识到虚拟化的重要性之后,微软通过外部收购和内部开发,推出了一系列虚拟化产品,目前已经形成了比较完整的虚拟化产品线。微软的虚拟化产品涵盖了服务器虚拟化(Hyper-V)和桌面虚拟化(Virtual PC)。

    Virtual PC是而向桌面的虚拟化产品,最早由Connectix公司开发,后来该产品被微软公司收购。Virtual PC是基于宿主模型的虚拟机产品,宿主机操作系统是Windows。早期版本也采用软件虚拟化方式,基于Binary Translation技术。之后版本已经支持硬件虚拟化技术。

    Windows Server 2008是微软推出的服务器操作系统,其中一项重要的新功能是虚拟化功能。其虚拟化架构采用的是混合模型,重要组件之一Hyper-V作为Hypervisor运行在最底层,Server 2008本身作为特权操作系统运行在Hyper-V之上。Server 2008采用硬件虚拟化技术,必须运行在支持Intel VT技术或者AMD-V 技术的处理器上。

     

    3.1.3 Xen

    Xen是一款基于GPL授权方式的开源虚拟机软件。Xen起源于英国剑桥大学Ian Pratt领导的一个研究项目,之后,Xen独立出来成为一个社区驱动的开源软件项目。Xen社区吸引了许多公司和科研院所的开发者加入,发展非常迅速。之后,Ian成立了XenSource公司进行Xen的商业化应用,并且推出了基于Xen的产品Xen Server。2007年,Ctrix公司收购了XenSource公司,继续推广Xen的商业化应用,Xen开源项目本身则被独立到www.xen.org。

    从技术角度来说,Xen基于混合模型,特权操作系统( 在Xen中称作Domain 0)可以是Linux、Solaris以及NetBSD,理论上,其他操作系统也可以移植作为Xen的特权操作系统。Xen最初的虚拟化思路是类虚拟化,通过修改Linux内核,实现处理器和内存的虚拟化,通过引入I/O的前端驱动/后端驱动(front / backend)架构实现设备的类虚拟化。之后也支持了完全虚拟化和硬件虚拟化技术。

     

    3.1.4 KVM

    KVM(Kernel-based Virtual Machine)也是一款基于GPL授权方式的开源虚拟机软件。KVM 最早由Qumranet公司开发,在2006年出现在Linux内核的邮件列表上,并于2007年被集成到了Linux 2.6.20内核中,成为内核的一部分。

    KVM支持硬件虚拟化方法,并结合QEMU来提供设备虚拟化。KVM的特点在于和Linux内核结合得非常好,而且和Xen一样,作为开源软件,KVM的移植性也很好。

     

    3.1.5 Oracle VM VirtualBox

    VirtualBox是一款开源虚拟机软件,类似于VMware Workstation。VirtualBox 是由德国Innotek公司开发,由Sun Microsystems公司出品的软件,使用Qt编写,在 Sun 被 Oracle 收购后正式更名成 Oracle VM VirtualBox。Innotek 以 GNU General Public License (GPL) 释出 VirtualBox。用户可以在VirtualBox上安装并且执行Solaris、Windows、DOS、Linux、BSD等系统作为客户端操作系统。现在由甲骨文公司进行开发,是甲骨文公司VM虚拟化平台技术的一部分。

     

    3.1.6 Bochs

        Bochs 是一个 x86 计算机仿真器,它在很多平台上(包括 x86、PowerPC、Alpha、SPARC 和 MIPS)都可以移植和运行。使 Bochs 不仅可以对处理器进行仿真,还可以对整个计算机进行仿真,包括计算机的外围设备,比如键盘、鼠标、视频图像硬件、网卡(NIC)等。

    Bochs 可以配置作为一个老式的 Intel® 386 或其后继处理器使用,例如 486、Pentium、Pentium Pro 或 64 位处理器。它甚至还可以对一些可选的图形指令进行仿真,例如 MMX 和 3DNow。

     

    3.1.7 QEMU

        QEMU是一套由Fabrice Bellard所编写的模拟处理器的自由软件。它与Bochs,PearPC近似,但其具有某些后两者所不具备的特性,如高速度及跨平台的特性,qemu可以虚拟出不同架构的虚拟机,如在x86平台上可以虚拟出power机器。kqemu为qemu的加速器,经由kqemu这个开源的加速器,QEMU能模拟至接近真实电脑的速度。

    QEMU本身可以不依赖于KVM,但是如果有 KVM的存在并且硬件(处理器)支持比如Intel VT功能,那么QEMU在对处理器虚拟化这一块可以利用KVM提供的功能来提升性能。换言之,KVM缺乏设备虚拟化以及相应的用户空间管理虚拟机的工具,所以它借用了QEMU的代码并加以精简,连同KVM一起构成了一个完整的虚拟化解决方案,不妨称之为:KVM+QEMU。

     

    3.2 操作系统级虚拟化实现

    3.2.1 chroot

    容器的概念始于 1979 年的 UNIX chroot,它是一个 UNIX 操作系统上的系统调用,用于将一个进程及其子进程的根目录改变到文件系统中的一个新位置,让这些进程只能访问到该目录。这个功能的想法是为每个进程提供独立的磁盘空间。其后在 1982年,它被加入到了 BSD 系统中。

     

    3.2.2 LXC

    LXC 的意思是 LinuX Containers,它是第一个最完善的 Linux 容器管理器的实现方案,是通过 cgroups 和 Linux 名字空间namespace实现的。LXC 存在于 liblxc 库中,提供了各种编程语言的 API 实现,包括 Python3、Python2、Lua、Go、Ruby 和 Haskell 等。与其它容器技术不同的是, LXC 可以工作在普通的 Linux 内核上,而不需要增加补丁。现在 LXC project 是由 Canonical 公司赞助并托管的。

     

    3.2.3 Docker

    Docker 是到现在为止最流行和使用广泛的容器管理系统。它最初是一个叫做 dotCloud 的 PaaS 服务公司的内部项目,后来该公司改名为 Docker。Docker 开始阶段使用的也是 LXC ,之后采用自己开发的 libcontainer 替代了它。不像其它的容器平台,Docker 引入了一整个管理容器的生态系统,这包括高效、分层的容器镜像模型、全局和本地的容器注册库、清晰的 REST API、命令行等等。稍后的阶段, Docker 推动实现了一个叫做 Docker Swarm 的容器集群管理方案。

     

    3.2.4 Linux VServer

        Linux-VServer 也是一个操作系统级虚拟化解决方案。Linux-VServer 对 Linux 内核进行虚拟化,这样多个用户空间环境—又称为 Virtual Private Server(VPS) 就可以单独运行,而不需要互相了解。Linux-VServer 通过修改 Linux 内核实现用户空间的隔离。

    Linux-VServer 也使用了 chroot 来为每个 VPS 隔离 root 目录。虽然 chroot 允许指定新 root 目录,但还是需要其他一些功能(称为 Chroot-Barrier)来限制 VPS 脱离其隔离的 root 目录回到上级目录。给定一个隔离的 root 目录之后,每个 VPS 就可以拥有自己的用户列表和 root 密码。

    2.4 和 2.6 版本的 Linux 内核支持 Linux-VServer,它可以运行于很多平台之上,包括 x86、x86-64、SPARC、MIPS、ARM 和 PowerPC。

     

    3.2.5 Virtuozzo/OpenVZ

    Virtuozzo是SWsoft公司(目前SWsoft已经改名为Parallels)的操作系统虚拟化软件的命名,Virtuozzo是商业解决方案,而OpenVZ是以Virtuozzo为基础的开源项目,它们采用的也是操作系统级虚拟化技术。OpenVZ 类似于 Linux-VServer,它通过对 Linux 内核进行补丁来提供虚拟化、隔离、资源管理和状态检查。每个 OpenVZ 容器都有一套隔离的文件系统、用户及用户组等。

     

    参考文献

    • 1 ] 金海, 廖小飞. 面向计算系统的虚拟化技术J]. 中国基础科学, 2008, 10(6):12-18.
    • 2 ] 英特尔开源软件技术中心. 系统虚拟化M]. 清华大学出版社, 2009.
    • 3 ] GeorgeCoulouris, 库鲁里斯, 金蓓弘,等. 分布式系统:分布式系统概念与设计M]. 机械工业出版社, 2013
    • 4 ] Andrew S. Tanenbaum, Maarten van Steen. 分布式系统原理与范型M]. 清华大学出版社, 2004.
    • 5 ] Barham P, Dragovic B, Fraser K, et al. Virtual machine monitors: Xen and the art of virtualizationJ]. Symposium on Operating System Principles, 2003, 36(August):164--177.
    • 6 ] Qumranet A K, Qumranet Y K, Qumranet D L, et al. kvm: the Linux virtual machine monitorJ]. Proc Linux Symposium, 2007.
    • 7 ]  Adams K, Agesen O. A comparison of software and hardware techniques for x86 virtualizationC]// ACM, 2006:2-13.
    • 8 ] Uhlig R, Neiger G, Rodgers D, et al. Intel virtualization technologyJ]. Computer, 2005, 38(5):48-56.
    • 9 ]  Garfinkel T, Rosenblum M. A Virtual Machine Introspection Based Architecture for Intrusion DetectionJ]. Proceedings of the Network & Distributed Systems Security Symposium, 2003:191--206.
    展开全文
  • 可视如何选择合适的图表类型

    千次阅读 2019-08-28 14:39:09
    数据可视主要是借助图形的方法,清晰有效的展示数据,让关系繁杂的数据变得一目了然,数据趋势变得明显,数据内在关系变得明确。 数据可视的第一步就是选择选择合适的图表类型。 为了确保我们正确的使用了图表...
  • 虚拟技术

    2020-12-26 11:18:54
    虚拟技术前言一、虚拟技术简介1、虚拟技术的概念2.虚拟技术的分类1.引入库2.读入数据总结 前言 近年来,计算机硬件与软件的性能比以往有了椰大的发展与进步,计算机硬件的入反为人们提供了极其强大的计算...
  • 虚拟技术简介

    千次阅读 2020-05-15 17:39:23
    虚拟技术的分类2.1 硬件抽象层上的虚拟2.2 操作系统层上的虚拟2.3 库函数层上的虚拟2.4 编程语言层上的虚拟3.系统级虚拟3.1 按照实现方法分类3.2 按照实现结构分类4.操作系统级虚拟5.典型虚拟技术...
  • 使用威尔逊扭曲质量费米子获得两个晶格间距的重一化参数,以及在非局部算子中获得威尔逊线的不同离散参数。 使用这些参数,我们显示了重一化对具有约370 MeV介子质量的核子矩阵元素的影响,并比较了两个晶格...
  • 乡村笔记 老龄社会云调研项目调研报告主要面向的主题为智慧养老领域。我们主要聚焦于人工智能机器人的时代背景下对于智慧养老,辅助医疗康养复的思考。中国养老产业之大,绝非简单的机器人技术,人工智能就可以...
  • 同时随着人工智能技术飞速发展,机器学习与量化投资研究间擦起火花,因此本文针对量化选股问题,将机器学习与技术分析结合,构建了决策树模型,获得排名前十的股票投资组合,并通过可视界面进行实证检验,分别获得...
  • 1.无处不在的数据可视 提到数据可视,大家可能脑海里就会出现里各种图表、绚丽大屏、或者科幻电影里酷炫仪表。其实,日常生活里面,到处都有数据可视的影子。 手表就是数据可视的例子,最少只需要3个...
  • 个性推荐算法总结

    万次阅读 多人点赞 2019-04-11 23:24:58
    读书笔记 |《推荐系统实践》- 个性推荐系统总结 对于推荐系统,本文总结内容,如下图所示: 一、什么是推荐系统 1. 为什么需要推荐系统 为了解决互联网时代下的信息超载问题。 2. 搜索引擎与推荐系统 ...
  • 外卖客户端容器架构的演进

    千次阅读 2020-09-30 20:01:48
    总第413篇2020年 第37篇好的架构要不断演变,进而去适应业务的发展。美团在移动端上的架构,也经历了组件、平台、RN混合,到现在开始向容器变迁。容器架构充分地利用了现在的跨...
  • xp 自动安全配置 让我们从安全角度考虑自动管道。 管道可以成为安全推动因素。 开发人员机器中的安全代码可能会导致生产中运行的代码不安全。 特别是在此过程中需要人工干预时。 自动管道可以减轻这种风险。 ...
  • 无论是马云所说”数字经济体“又或者马化腾所说的”产业互联网“,根究底是使用自身云计算的能力去影响或者去重构传统行业,带来产业融合的新创新价值。 ”信息技术改革“一触即发,云计算不是一门技术,是一种”...
  • android组件

    2018-01-19 16:03:20
    而在android工程中如何实施,目前有两种途径,也是两大流派,一个是组件,一个是插件。上面的图看上去比较清晰,其实容易导致一些误解,有下面几个小问题,图中可能说的不太清楚:组件是一个整体吗?去了头和
  • 文章转载自微信公众号中地数码MapGIS,版权原作者及刊载媒体所有。伴随着人们探索空间的过程,信息的获取范围也从局部地面、全球地表、地球各个圈层扩展到地球内外的整个空间,从原有的二维平...
  • 01社会导向 扎克伯格表示,Facebook将会“积极”增聘远程工作的员工,并将“慎重地”为现有员工开创永久性远程工作岗位。不久前,Twitter CEO 杰克·多尔西甚至宣布员工在不影响工作的情况下,可以无限期在家办公...
  • 首先,第一个问题,什么是图像风格(Neural Style Transfer)? 简单来讲,图像风格是将一张照片渲染成有艺术风格的画作。图像风格算法的输入有二,分别是内容图和风格图,输出有一个,为风格迁移后的结果图...
  • 其中,前5个环节品牌商,后5 个环节零售商。 我们认为: 一节甘蔗的长短在短期内是可以发生变化的,但长期来说是固定的。如何在固定的利润水平上发掘更大的价值?最为简单直接的方法就是“吃掉更多的甘蔗节数...
  • 结构思想和面向对象思想虽都产生于20世纪60年代,但它们却存在根本差别。结构方法承袭了传统的编程思想与编程方法,以计算机的计算功能为前提。编写程序的主要目的是数值计算、问题求解。模块是结构编程的基本...
  • 原本只知道博士可以提供信息得到认证,知乎也会给予其回答更好的显示途径,使其更容易成长为大V,以此作为对高学历人群、优质用户的奖励。 此次抓取的100+关注4.1w+条数据中有208条认证信息。...
  • 程序员必备的思维能力:结构思维

    千次阅读 多人点赞 2021-05-08 13:47:53
    这些都是典型的缺少结构思维的表现,导致我们在写作(包括写代码)、沟通、表达的时候,思维混乱,逻辑不清。 结构思维是一种从无序到有序、从混乱到清晰的思维能力,可以帮助我们快速加工处理繁杂的信息,提炼...
  • 6.2 如何对比特币去匿名

    千次阅读 2018-09-12 14:01:42
    这事实上就是比特币钱包实现匿名性的最好途径。 图6.1 维基解密的捐款页面的一个片段 注:请注意那个在比特币地址旁边的刷新按钮。维基解密遵循了为每一笔捐款生成一个新接收地址的比特币匿名的最佳实践。 你可能...
  • 第20节 信息基础知识

    千次阅读 2019-08-27 17:03:34
    第20节 信息基础知识 信息基础知识 1[单项选择题]以下对信息系统集成的描述不正确的是( )。 A信息系统集成包括总体策划、设计、开发、实施、服务及保障 B信息系统集成主要包括设备系统集成和应用系统集成 C...
  • iOS崩溃堆栈信息的符号解析

    千次阅读 2018-05-28 17:29:05
    最近一段时间,在iOS开发调试过程中以及上线之后,程序经常会出现崩溃的问题。简单的崩溃还好说,复杂的崩溃就...现在网上有很多关于解析崩溃堆栈信息的符号的博客,但是大多质量参差不齐,或者有些细节没有注...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 8,688
精华内容 3,475
关键字:

化归的途径