e4 技术白皮书
John Arthorne, IBM Canada Inc.
Last modified July 29, 2009
译者：天马1.概述
Eclipse平台的初衷是构建一个可扩展的IDE组件框架，但它现在已经发展成为一个构建可扩展的任何软件应用的通用平台。目前，Eclipse应用出现在了各种部署环境中，比如Web服务器，Web浏览器，嵌入式客户端，以及传统的富桌面应用。
E4平台的设计是为了简化软件组件以及基于组件的应用的开发，以满足当前不断变化的计算场景的需求。本文主要介绍e4的架构和编程模型。
2.什么是e4
E4是一组相关技术的集合，这些技术主要用于构建可扩展的、基于组件的应用。E4将一组新的技术融入现有的eclipse平台，而不是对eclipse平台的大规模替换。目的就是使eclipse组件更易于编写，更可配置，并更易于在不同的运行时环境中复用。
第一代Eclipse平台（1.0到2.1）主要是一个集成平台，其主要功能是将不同作者开发的插件集成为一个一通用应用，并使最终用户有一个一致、内聚的体验。
第二代Eclipse平台（3.x）开始构建于OSGI运行时之上，这使Ecliplse成为一个更加强大的、通用的、基于组件的应用框架。第二代平台可用于很小的嵌入式应用、RCP应用、以及Web服务器。然而，每个组件（插件）通常难以在特定环境（组件的设计和测试环境）以外复用。为系统添加或删除组件很容易，但将一个为某应用或运行时环境设计的组件复用到一个完全不同的应用或环境中，将非常困难。
E4的愿景是使开发在多种应用和环境中都可复用和可定制的组件变得更容易。有两种途径达到这个目的：减少组件的外部依赖；增加可无缝集成到Eclipse运行时中的语言和技术。这两种方法都被Eclipse采用了：
1)面向服务的编程模型，基于OSGI，把软件组件更好地从外围环境中分离；
2)GUI被描述为统一的模型，此模型可被查询、操作、做工具、扩展，还可在很少或无需编码的情况
下快速的设计和定制用户界面；
3)使用Web样式技术（CSS），无需修改应用代码，即可任意修改UI展现；
4)把Eclipse运行时技术融入到JavaScipt世界，允许JavaScript写的软件在Eclipse运行时上执行；
5)声明式地定义SWT应用的设计和结构，摒除了重复的公式化的SWT代码，这降低了开发成本，提
高了UI一致性，并且允许定制应用发布；
6)SWT新的移植，称为“浏览器版本”，允许现有的SWT应用在像ActionScript/Flash 一样Web平台
上运行；
7)在开发工具方面，更灵活的资源模型为复杂的工程结构提供了更好的支持。
本文的后续章节将更详细的介绍这些新技术。
3.编程模型
E4编程模型开始于现有的Eclipse编程原则：
1)应用由模块化的，被称为插件或bundle的松耦合的组件组成。Bundle可用Java或其它语言来编写，
还可以包括文档和源代码等资源；
2)Bundle可以通过扩展点声明它可被定制或扩展的地方，还可以通过定义扩展来定制或扩展其它
bundle；
3)一次可以安装大量bundle，但只有实际使用的bundle才被加载并消耗系统资源。
E4区别于这种传统Eclipse编程模型的地方在于，bundle怎样在扩展注册表机制以外彼此交互。Bundle 经常以不适于Eclipse扩展注册表的方式为其它bundle提供数据和服务。最常用的实现方式是，bundle通过直接引用API中定义的方法和常量来与其它bundle通信。为了获得服务的单实例，bundle一般会定义入口点（比如Platform,IDE, ResourcesPlugin, JavaCoret等这些类）。这种行为会导致使用服务的bundle和提供服务的bundle间存在紧密偶合，这种单实例访问的流行，将使其它供选择的服务实现很难或不可能被采用，多个实现也很难或不可能在同一时间存在。结果bundle将难以在不同的环境中重新装配或复用，而这些环境可能需要不同的或多个服务实现。
服务编程模型定义了三个不同的参与者：服务提供者、服务消费者和一个代理或容器（绑定服务提供者到消费者）。此编程模型的基本实现，比如OSGI服务API或Eclipse扩展注册表，出色地将服务提供者与消费者解耦，但经常需要服务提供者和消费者显式地知道特定容器和服务代理。
图1 简单服务架构
E4编程模型通过减少或消除服务提供者与消费者显式的对特定服务代理技术的依赖，进一步将这些参与者解耦。这种新的灵活性将在下面的介绍中给出详细解释。
1)上下文（context）：服务代理（the service broker）
E4引入“上下文”的概念，作为存储查找服务并将这些服务提供给消费者的通用机制。从这个基本功能来说，e4上下文看起来很像存储键值对的Java Map，客户可以向此Map里存值或取值。这个Map还可以存储，在客户请求上下文值时，可懒计算这些值的上下文函数。当客户请求了一个上下文中不存在的值时，请求将被委托给父上下文。这允许服务和数据存储在一个中心位置，被多个客户消费。上下文还有一个可插拔的查找策略，来允许外部参与者教上下文怎样获取特定种类的值。此查找策略使e4上下文和其它服务代理（如OSGI服务注册表）间的互操作性成为可能。这种灵活性意味着，各种不同的服务查找方法和代理系统都可以集成到e4上下文机制中。创建上下文层次结构以及插入服务查找策略的能力，可使上下文适用于从非常简单的类似map的服务注册与查找，到高度复杂的动态服务仲裁机制。
2)注入（Injection）：服务消费者（service consumers）
目前服务编程模型的最佳实践，是消费者通过依赖注入来得到依赖的内容。这理论上可使应用代码完全消除对特定容器技术的依赖，从而保证了更大的复用。E4直接支持并鼓励把依赖注入作为向客户提供服务的手段，并支持构造函数注入、方法注入、以及字段注入。在客户代码中标识注入点的方式，可以是命名规范或Java注解。对于不太理解控制反转，而且喜欢代码清晰胜于框架独立（prefer code clarity over framework independence）的客户，还可以直接使用e4上下文（service locator设计模式）。
3)服务提供者
Bundle提供的服务和数据多种多样。有些服务非常轻量，可被使用或丢弃成千上万次，然而其它一些重量级服务可能要“活”很长一段时间。这些服务的生命周期也各不相同，有些依赖于特定UI控件的存在而存在，而有些可能贯穿于某bundle的整个生命周期。正是由于这些多样性，所以没有哪种服务发布方法可以适合于所有的服务提供者。
通常，e4中发布的服务使用OSGI服务机制。服务的注册和删除，可以通过编程，还可以通过OSGI声明式服务。声明式服务允许服务直到被请求时才实例化。当然，有很多种辅助框架可用于发布OSGI服务，比如，Spring DM, iPOJO, Peaberry等等。这些模型使用OSGI服务作为服务发布的基础，可以与e4无缝集成。
大多数客户代码将使用服务，创建上下文的框架可以直接简单地向上下文中添加服务。比如，一个关联到某控件的服务，可能要注册到控件构造函数中的上下文，并在控件销毁时撤消服务。手工注册可使服务仅在特定上下文中才变得可用，而通过OSGI服务，可使服务一直可用。最后要提到的是，上下文支持通过字段或访问方法注出（outjection，反注入）服务回至上下文。
最终，我们有了一个完整的模型：服务消费者不知道谁提供服务，也不知道用什么代理获取服务。通过分离服务配置数据和服务实现，服务提供者可与服务代理大大解耦。这可以使用声明式机制，如DS、注出，或者简单地从服务实现中分离框架相关的注册代码。下图说明了这个模型。
图2 e4服务架构
4)Eclipse应用服务
为支持这种解耦的服务编程模型，Eclipse API要变成可用的服务，而不是以前那种单实例访问器模型（Platform、ResourcesPlugin等）。然而，多年来Eclipse平台已经积累了大量的API，但很多组件仅使用这些API中的一小部分。仅这些API的广度就使基于Eclipse进行应用开发成为一个挑战，陡峭的学习曲线增加了学习成本，阻碍了新手的开发。e4将通过定义一组核心服务获取大量有用的平台功能来解决这些问题。目的是开发人员应该可以仅使用这些核心bundle，就能很好的构建完整的e4 bundle。这些核心服务还为把其它编程语言集成到eclipse平台定义了好的起点，后面JavaScript集成相关章节将进一步讨论这个话题。
4.基于模型的UI
上一代Eclipse平台UI（称为workbench）复杂而且难以维护。虽然多年来它已经变得稍更灵活，但它仍然坚持着workbench结构和布局的严格、硬编码的模型：一个workbench包含多个workbench window，一个workbench window包含一个或多个workbench page，每个page又包括一个editor area、一组view stack，以及一些硬编码的修剪元素（透视图切换按钮，进度指示器等）。应用设计者在定制eclipse应用的结构时有一些严格的限制。
E4 workbench为应用设计者大大提高了灵活性，因为它提供了一个正式的workbench组成元素的模型。应用可以重新装配或扩展这个模型来实现各种不同的应用展现，而无需编码。将workbench结构标准化为一个定义明确的模型有一个额外的好处，就是使workbench代码更加简单，而且更少有潜在的错误。最重要的是，这使一些非常不同的workbench UI布局成为可能，比如视图或编辑器脱离透视图，对话框中放视图或编辑器，以及其它一些老eclipse平台不允许的设计。有了模型，还可以为应用设计者提供更加高级的工具，比如可视化设计工具。可以在运行时操作e4 workbench模型，模型将立即反应到UI上。这开始了脚本式操作workbench结构和状态的历史，就像JavaScript操作web浏览器中的dom一样。下面图3中，我们可以看到定制正在运行的应用的模型编辑器，这个例子中，正在改变传统eclipse 问题视图的name和tootip。
图3 e4 模型编辑器
E4 workbench模型被翻译器翻译成小部件。Workbench自带一个默认的将模型翻译成SWT小部件的翻译器，其它翻译器也可以为模型元素提供不同的翻译。这可用于为某部件提供细微变化，甚至翻译成完全不同的部件库或类似web浏览器的运行时环境。翻译器是在单个模型元素的级别提供的，而不是为整个应用提供一个整体的翻译器。单个翻译器可以为一个或多个模型元素提供翻译，或者相反，多个翻译器也可以为单个模型元素提供翻译。这种精细的可扩展性允许客户用他们自己的元素扩展workbench模型，然后提供自定义的翻译器来以一种特别的方式翻译这些元素。
5.声明式样式
Workbench模型到小部件的基本翻译是由翻译器完成的，可插拔的样式引擎则用于定制部件的字体、颜色、以及等其他方面。我们知道，web展现技术中分离文档结构（html）和样式（CSS），保证了多个文档可以有一致的用户体验，而且也很容易在单个地方变化样式。基于模型的UI对E4样式引擎是透明的，事实上这个引擎可以完全独立的运行到早期版本的eclipse中。具体的部件和样式数据做为引擎的输入，将样式应用于部件实例上就生成了样式结果。下面图4显示了一个完成流程：模型通过一个多个翻译器变成了部件，然后通过样式引擎和声明式样式数据（CSS文件）产生了最终结果。
图4 翻译器和样式数据流
e4中的声明式样式是基于标准CSS语法的，支持HTML CSS中的大部分属性名和类型格式，比如字体、边距、颜色等。此外，e4还有自定义的属性以及eclipse部件特有的伪选择器（pseudo selectors）。CSS中你可以使用类型选择器，e4中你可以使用部件类名做为选择器。E4还支持CSS class选择器和ID，所以同一个部件可以有不同的样式。同样，e4用CSS 伪类（pseudo-classes）来基于部件状态选择样式规则，这让你可以为被选的tab设置不同的字体颜色。比如，下面的片段为普通的tab folder指定一种颜色，为被选择的编辑器指定了一个不同颜色：
CTabFolder {
background-color: rgb(241, 240, 245);
font: normal;
}
CTabFolder.editors:selected {
background-color: rgb(255, 255, 255) rgb(255, 247, 229);
}
CSS类和伪类的使用，使workbench部件（视图，编辑器）以及特定状态部件的样式高度可定制。比如，正在运行后台任务的视图可以标记为忙，样式则可以描述怎样展现这个状态：不同的字体，改变的边距，如甚至没有样式。最终将使应用更容易被用户理解和使用。
6.Web到桌面
过去的几年中，浏览器应用和桌面应用的界限已经变得模糊。应用中的浏览器、部件、和语言框架的复杂性也在接近桌面操作系统。与此同时，桌面应用正变得web化，也在采用一些web应用的用户交互方式和样式标记。一段时间内，桌面应用和浏览器应用的需求都将存在，而且使软件组件能同时用在两种环境的需求正越来越多。在面向组件的软件（如eclipse）中，我们不再选择目标平台，然后从头到尾的构建整个软件。我们基于大量的可用组件，然后将他们组织一起来构建一个符合我们需求的应用。如果我们能在多个运行时环境中复用同一组件，将大大减少开发和维护成本。
E4正在以多种方式探索在多个目标平台和技术间复用组件。其中一种是用JavaScript写Eclipse组件。作为客户端浏览器编程语言的事实标准，JavaScript对于那些寻求编写可在多种运行时环境中运行的组件的人，是一个好的选择。为此，e4正在研究将eclipse的优势（模块化、可扩展性、制作工具）带入到JavaScript 世界，并将JavaScript组件融入到eclipse桌面环境中。虽然目前e4的焦点在JavaScript上，但这项工作的意图更加广泛：把用多种不同语言编写eclipse组件变得更简单。
虽然JavaScript被长期用于浏览器脚本语言，但很少用于构建类似于我们在Java世界中看到的大型应用。它的一个弱点是缺少模块化机制。没有定义和访问命名空间以及表示JavaScript代码段依赖的机制，也没有以一种可扩展的方式查询和消费其它组件定义的服务的机制。在java和eclipse中，我们有强大和成熟的OSGI 模块化系统，可以满足这些需求。
为了解决这些限制，e4在OSGI基础上引入一个模块化框架，用于JavaScript应用。它允许创建模块，创建大规模纯JavaScript应用，甚至把JavaScript bundle集成到传统的基于Java的OSGI运行时中。图5 说明了e4 JavaScript框架构架，以及它和纯JavaScript bundle、标准java bundle间的关系。
图5 e4 JavaScript框架
e4 JavaScript框架是用java写的，运行为一个纯OSGI bundle。它负责解析JavaScript bundle的描述文件（manifests），并分析JavaScript bundle间的依赖。JavaScript bundle以及它们的依赖关系对OSGI框架是透明的：JavaScript框架本质上完全是一个OSGI实例中嵌套的框架。JavaScript bundle间的依赖关系可表示在bundle级别（就像OSGI 头信息中的Require-Bundle），或者在单个脚本文件级别（类似OSGI 头信息中的Import-Package）。这些依赖表示在JavaScript manifest中（一个JSON文件）。下面是一个简单JavaScript bundle manifest例子：
{
"Bundle-SymbolicName":"sample.jsbundle",
"Bundle-Version":"1.0",
"Bundle-ScriptPath":"script.js",
"Import-Package":"a.resource;version=[1.0.0,2.0.0)",
"Export-Package":"sample.resource;version=1.0.0",
"Require-Bundle:"some.other.bundle",
}
J avaScript bundle可用编程的方式定义或安装到框架中，还可在标准OSGI bundle中，用额外的manifest header声明JavaScript bundle的存在：
JavaScript-Bundle: scripts/manifest.json
虽然JavaScript bundle和javabundle可通过直接调用来交互，但推荐的方式是通过OSGI服务注册表，或是eclipse扩展注册表。比如，JavaScript bundle可以声明为一个标准OSGI bundle，然后编程式地或使用类似OSGI DS的声明式机制向OSGI服务注册表贡献服务。标准OSGI bundle就可以消费这些服务，而根本不知道这些服务的实现是用JavaScript写的。
同样，e4 JavaScript框架提供eclipse扩展工厂来实例化纯JavaScript 写的eclipse扩展。JavaScript bundle 可以简单的声明一个plugin.xml文件来记录向扩展注册表的扩展，而不需要写一行java代码。Java写的bundle 就可以消费这些扩展而不知道他们是用另一种语言写的。相反，JavaScript bundle可以用一些相应的java API 声明一个扩展点，这些API可被java bundle实现，然后加载并用JavaScript代码向这个扩展点提供扩展。这些JavaScript bundle和java bundle间的交互在图5中可以看到。E4 JavaScript框架本身用java和JavaScript 定义API。这样纯javabundle可以查询或操作JavaScript框架（比如安装一个新的JavaScript bundle），JavaScript 写的bundle可以通过框架的JavaScript API与框架交互。图5中e4 JavaScript框架块同时扩展java和JavaScript 说明了这一点。
E4编辑模型还简化了集成用其它语言实现的组件。通过组件间基于服务的交互、依赖注入，组件不必知道服务用哪种语言实现，也不必知道用什么语言消费它们暴露的服务。类似地，消减后的eclipse应用服务可以暴露为其它语言的API，所以eclipse平台的大量功能可被其它语言实现的bundle使用。用于与这些核心e4服务交互的少量JavaScript API现在已经可用，它们定义在org.eclipse.e4.ui.web bundle中。作为概念的证明，e4包含了一个用纯JavaScript 实现的PDE update site编辑器（见图6）。这个编辑器可在web浏览器中运行，还可以无缝集成到eclipse平台UI中。
图6 e4 JavaScript site编辑器
7.桌面到Web
我们已经展示了web组件怎样集成到eclipse平台中。然而，用传统java语言实现的桌面应用也可以移植到web平台。E4中有两个研究方向与此有关：新的SWT移植版本、Eclipse Rich Ajax Platform (RAP)。
Eclipse SWT为桌面图形应用（可跨多个操作系统）提供了通用API。它允许开发者只写一次，即可得到多个目标平台上的高性能、具有本地化外观的应用。同样，web浏览器编程有多种语言和部件工具包。Web 技术变化迅速，由于担心过时，应用开发者都不愿只掌握一种技术。E4中SWT的新移植版本（称为SWT 浏览器版本，SWT/BE）旨在为web UI 编程提供一个通用平台，就像它已经为桌面应用编程所做的那样。这潜在的允许已有的SWT应用运行在Web上，并允许开发者构建web UI应用而不必锁定在某个web技术中。
SWT/BE现在支持ActionScript/Flex 做为此项技术的原型样例，但移植到其它web平台，比如JavaScript/Dojo、Silverlight、Java FX等，也是可能的。图7显示了运行在Adobe Flex 上的SWT控件样例，它包括所有SWT主要部件。
图7 Flex上的SWT 控件样例
Eclipse Rich Ajax Platform (RAP)提供了运行在Web上的SWT、JFace、Workbench UI实现。类似SWT/BE，RAP为同一个应用运行即运行在桌面又运行在web上提供了可能。然而，原始的RAP实现需要一些eclipse 平台代码来支持web目标环境。特别地，Web应用通常必须支持在一个应用实例中存在多个并发的用户会话，由于大量使用单实例，eclipse workbench通常不支持这个。
图8 RAP构架
E4编程模型由于它面向服务注入的编程方式，使得它更有适于多并发会话。早期实验中在RAP运行时上运行的e4应用已经预示，workbench仅需要较少的变化即可运行在RAP上。RAP集成工作为e4的目标（支持多种运行时环境是可以实现的）提供了验证。在类似RAP的目标平台上运行e4应用的工作，有助于保证e4架构和编程模型的持续灵活性和开放性。
8.声明式控件
基于模型的e4 workbench为workbench本身提供了一个抽象展现：windows、pages、perspectives、view 等。此模型用翻译器可翻译成SWT，可用声明式样式引擎进行定制。然而，在单个workbench视图内，UI 仍然用普通的SWT来创建。这些SWT代码通常重复，而且样式被硬编码。为了解决这些问题，e4正在探索将模型/翻译器概念应用于SWT的所有方面。目前这个探索有两个方向：基于XML的小部件和基于模型的小部件。
1)XWT：基于XML的声明式控件
XML UI for SWT (XWT)，是一个框架，可将SWT小部件声明在xml中。XWT中，应用的所有结构、小部件的层次、小部件到特定底层应用模型的绑定，以及小部件到实现小部件行为的java回调的绑定都是声明式的。
XWT以声明式的UI数据作为输入，与应用模型一起生成小部件。XWT包含一个符合javabean规范（简单数据访问器和setter方法）的类的简单模型。其它方法可以通过扩展点向XWT扩展。XWT UI 生成器组合声明式UI数据和模型定义，生成运行时SWT/JFace控件。图9展示了XWT的架构。
图9 XWT 架构
2)TM：基于EMF的声明式控件
Toolkit Model（TM）是UI元素的抽象EMF模型。在应用运行时，此模型被绑定到一组具体的小部件(比如SWT)上，TM构建器在这个模型与小部件间双向传播变化，以保持它们的同步。应用在运行时通常与TM 而不是具体的小部件交互，这让应用开发者面对一个更简单的抽象来工作。
这个更高级的部件抽象使改变具体部件实现成为可能，可以以精细的方式改变，也可以是根本改变，比如与运行在不同进程或不同物理机器上的小部件实例进行交互。举例来说，一个运行在web服务器上的应用可以操作此服务器上的toolkit模型，并且TM运行时可以透明的用运行在不同机器上的小部件实现这个模型，比如一个web浏览器客户端。
Toolkit模型中的事件由JavaScript实现的事件处理器来处理，也可以用java实现。JavaScript与toolkit 模型交互的方式与JavaScript与操作html DOM类似。由于有图形工具可用于构建或操作EMF模型，这种EMF 和JavaScript的组合可以进行应用的快速原型设计。
图9展示了TM架构。构建器负责创建小部件并把它们绑定到模型上，这是通过为每一种创建的小部件找到一个合适的绑定器实现的。绑定器创建具体的小部件，并在创建后管理小部件和模型元素间的同步。每种小部件有一个绑定器，而不是每个部件实例一个绑定器。JavaScript代码为模型提供动态行为，包括部件事件的回调和其它应用行为。
图10 TM构架
9.灵活的资源模型
开发工具仍在eclipse生态系统中保持着重要角色。许多IDE开发者都希望以前版本的eclipse支持更复杂的工程结构。由于eclipse严格的资源模型限制，一些开发工具的用户很难把已经规划好的源码及其它资源的结构应用在基于eclipse的IDE中。E4引入了新的增强的资源模型，以更好的支持在workspace导入和管理更复杂的工程结构。这些增强包括：
1)可以在工程级别定义路径变量，并创建相对于这些变量的链接资源。这使得移动那些包含复杂链接
结构的工程时，不会破坏链接。
2)称为组的新的虚拟文件夹。组不存在于文件系统中，但它们可用于创建任意复杂的、包含资源链接
的虚拟工程树。
3)支持工程和文件夹的过滤，可从eclipse workspace树中排除特定资源或符合某模式的资源。过滤器允
许eclipse工程包含持有大量元素的文件夹，但仅有一小部分元素在工程中，排除的资源将不占用内存。
4)通过拖拽来创建和管理链接资源。从eclipse外拖拽一个文件树时，你可以把这个树作为包含链接和
组的虚拟树放到eclipse workspace中，而不是作为一个具体的文件系统树。
5)允许编辑已有链接资源的位置，或把链接在绝对路径和相对于变量的路径之间回来转换。
这些增强综合起来可以让用户在workspace中快速搭建复杂的工程结构，并与其他用户共享这些工程，而虚拟工程结构保持完好。
10.结论
E4工程引入了很多新技术使eclipse平台的架构和设计原则更加现代。这些变化使平台更加开放，支持更多的编程语言和目标运行时环境，从而使eclipse平台的未来更加美好。E4组件将更容易定制、配置并在不同的应用中复用，而无需修改。从应用逻辑中分离样式和展现逻辑，可使eclipse应用以一致的方式方便的更换皮肤。遵守e4设计原则的开发者，在构建组件和应用时，将与底层操作系统和web浏览器的技术变化更加隔离。
数据中心交换机 buffer 需求分析白皮书
目录 1引言 (3) 1.1DC 的网络性能要求 (3) 1.2国内OTT 厂商对设备Buffer 的困惑 (4) 1.3白皮书的目标 (4) 2Buffer 需求的经典理论 (5) 2.11BDP 理论 (5) 2.2Nick Mckeown 理论 (6) 2.3经典理论的适用性 (6) 3基于尾丢弃的buffer 需求 (9) 3.1丢包的影响 (9) 3.1.2丢包对带宽利用率的影响 (9) 3.1.3丢包对FCT 的影响 (12) 3.2大buffer 的作用 (13) 3.2.1吸收突发，减少丢包，保护吞吐 (13) 3.2.2带宽分配均匀 (14) 3.2.3优化FCT (15) 3.3DC 内哪需要大buffer (15) 3.4需要多大buffer (17) 3.5带宽升级后，buffer 需求的变化 (19) 3.6 小结 (19) 4基于ECN 的buffer 需求 (21) 4.1ECN 的作用 (21) 4.2ECN 水线设置 (23) 4.3基于ECN 的buffer 需要多大 (24) 5基于大小流区分调度的buffer 需求 (27) 5.1大小流差异化调度 (27) 5.2大小流差异化调度如何实现大buffer 相当甚至更优的性能 (27) 5.3基于大小流差异化调度的buffer 需要多大 (28) 6 总结 (28) 7 缩略语 (29)
1 引言 1.1DC 的网络性能要求 近几年，大数据、云计算、社交网络、物联网等应用和服务高速发展，DC 已经成为承 载这些服务的重要基础设施。 随着信息化水平的提高，移动互联网产业快速发展，尤其是视频、网络直播、游戏等行业的爆 发式增长，用户对访问体验提出了更高的要求；云计算技术的广泛应用带动数据存储规模、 计算能力以及网络流量的大幅增加；此外，物联网、智慧城市以及人工智能的发展也都对DC 提出了更多的诉求。 为了满足不断增长的网络需求，DC 内的网络性能要求主要体现在： ?低时延。随着深度学习、分布式计算等技术的兴起和发展，人工智能、高性能计算等时延敏感型业务增长迅速。计算机硬件的快速发展，使得这些应用的瓶颈已经逐渐由计 算能力转移到网络，低时延已经成为影响集群计算性能的关键指标。因此，时延敏感型 应用对DC 网络时延提出了更高的要求。目前DC 内，端到端5-10 微秒时延已经成为 主流的目标要求。 ?高带宽高吞吐。数据时代的到来，产生了海量的数据，如图1-1。基于数据的应用（如图像识别）的推广，使得网络数据呈爆发式增长，小带宽已经无法满足应用对传输 速率的需求。部分应用场景下，带宽成为制约用户体验的瓶颈。高带宽高吞吐对于提升大 数据量传输的应用性能有着至关重要的影响。为了应对大数据量传输的 应用需求，目前，百度、腾讯、阿里巴巴等互联网企业的DC 都已经全面部署100GE 网络，阿里巴巴更是规划2020 年部署400GE 网络。 图1-1 数据中心内存储的实际数据 数据来源：中国IDC 圈
以太环网解决方案技术白皮书 关键词：RRPP 摘要：以太环网解决方案主要以RRPP为核心的成本低高可靠性的解决方案。 缩略语清单： 1介绍 在数据通信的二层网络中，一般采用生成树(STP)协议来对网络的拓扑进行保护。STP协议族是由IEEE实现了标准化，主要包括STP、RSTP和MSTP等几种协议。STP最初发明的是目的是为了避免网络中形成环路，出现广播风暴而导致网络不可用，并没有对网络出现拓扑变化时候的业务收敛时间做出很高的要求。实践经验表明，采用STP协议作为拓扑保护的网络，业务收敛时间在几十秒的数量级；后来的RSTP对STP机制进行了改进，业务收敛时间在理想情况下可以控制在秒级左右；MSTP主要是RSTP的多实例化，网络收敛时间与RSTP基本相同。 近几年，随着以太网技术在企业LAN网络里面得到广泛应用的同时，以太网技术开始在运营商城域网络发展；特别是在数据，语音，视频等业务向IP融合的趋势下，增强以太网本身的可靠性，缩短网络的故障收敛时间，对语音业务，视频等业务提供满意的用户体验，无论对运营商客户，还是对于广大的企业用户，都是一个根本的需求。 为了缩短网络故障收敛时间，H3C推出了革新性的以太环网技术——RRPP（Rapid Ring Protection Protocol，快速环网保护协议）。RRPP技术是一种专门应用于以太网环的链路层协议，它在以太网环中能够防止数据环路引起的广播风暴，当以太网环上链路或设备故障时，能迅速切换到备份链路，保证业务快速恢复。与STP协议相比，RRPP协议具有算法简单、拓扑收敛速度快和收敛时间与环网上节点数无关等显著优势。 H3C基于RRPP的以太环网解决方案可对数据，语音，视频等业务做出快速的保护倒换，协同高中低端交换机推出整体的环网解决方案，为不同的应用场景提供不同的解决方案。 2技术应用背景 当前多数现有网络中采用星形或双归属组网模型，多会存在缺乏有效保护和浪费网络资源等诸多问题，如下图所示：
智慧科技-计划管理系统 技术白皮书 1产品定位 各级科委目前对科技计划的管理主要采用电子文档化的管理模式。随着业务工作发展与政府服务职能的深化，业务信息的数据量也不断积累和扩大，现有的管理方式对业务工作的支撑力度开始显得不足，主要体现在信息记录的格式缺乏统一性、信息由多人管理较为分散、对信息的查阅和利用不够便捷等。因此，建设科技计划管理系统，利用更为有效的信息化管理手段变得十分必要。 计划管理系统的建设将以实际业务需求为导向，实现科技计划的全生命周期管理，通过信息化手段规范计划管理业务的管理要素和日常工作，并对收集到的各类要素信息进行更为有效的分析利用，为业务人员在计划管理中的综合处理、高效配置、科学决策提供更为有效的支撑。 凭借多年在信息化系统建设领域的丰富实践经验，我们在方案总体设计方面，周密考虑，充分部署，力争在方案的总体架构方面体现先进性、扩展性和实用性。 一方面，根据各级科委具体需求，采用BS应用结构作为整体应用架构，实现安全的信息交换与业务处理； 其次，采用模块化设计的思想，将各个管理环节标准化和规范化，实现业务开展过程的全面推进； 第三，通过完善的后台管理功能，提供灵活的定制服务，满足业务处理的需求。 整个系统设计在考虑了现有信息系统的使用特点以及现阶段的业务需求的同时，还充分考虑了系统的潜在需求，具有先进性和较高的可扩展性。 系统总体框架如下图：
2主要功能 ●计划可研 计划可行性研究阶段，根据计划指南，部门推荐，完成计划科研报告编写(Word和在线），在计划申报系统中进行填报。 可研报告包含企业信息，计划可研书要求的信息等 ●立项管理： 计划管理最关键过程，根据可研报告，进行立项管理过程。 计划立项审查，和全省市计划库中原有计划进行对比，从计划名称、计划建设内容、考核指标、承担单位、计划负责人等各个方面进行比对， 形成相应的客观报告。 专家根据立项审查结果，进行再次审核，最终形成结果，专家随机取自专家系统库，同时各自打分可以网上网下结合进行，保证其公平透明。 ●计划申报： 计划可研和立项管理结束后，将发放计划正式立项通知书。
LINGHANG TECHNOLOGIES CO.,LTD 中科分布式存储系统技术白皮书 北京领航科技 2014年04
目录 1、产品介绍 (3) 1.1 云时代的政府/企业烦恼 (3) 1.2 产品服务与定位 (3) 2、中科分布式存储应用场景 (4) 2.1 目标用户 (4) 2.2 产品模式 (4) 2.2.1高性能应用的底层存储 (4) 2.2.2企业级海量数据存储平台 (5) 2.2.3容灾备份平台 (5) 2.3 使用场景 (5) 2.3.1企业级数据存储 (5) 2.3.2私有云计算 (6) 2.3.3海量数据存储 (6) 2.3.4大数据分析 (7) 2.3.5 容灾备份 (7) 3、中科分布式存储核心理念 (8) 4、中科分布式存储功能服务 (9) 4.1 存储系统功能介绍 (9) 4.2 WEB监控管理端功能介绍 (11) 5、系统技术架构 (12) 5.1 系统总体架构 (12) 5.2 系统架构性特点 (12) 5.3 技术指标要求 (14) 5.4 系统软硬件环境 (15)
1、产品介绍 1.1云时代的政府/企业烦恼 ?政府、企事业单位每天产生的大量视频、语音、图片、文档等资料，存在 哪里？ ?政府、企事业单位各个部门、各个子系统之间强烈的数据共享需求如何满 足？ ?大数据如何高效处理以达到统一存取、实时互动、价值传播、长期沉淀？ ?您是否为单位电子邮箱充斥大量冗余数据还要不断扩容而烦恼？ ?政府、企事业单位的私有云平台为什么操作和数据存取这么慢？ ?政府、企事业单位的存储平台数据量已接近临界值需要扩容，但上面有重 要业务在运行，如何能在线扩展存储空间？ ?公司的每一个子公司都有重要客户数据，要是所在的任何一个城市发生大 规模灾难（比如地震）数据怎么办？ ?政府、企事业单位有一些历史数据平时比较少用到,但又不能丢掉，占用 了大量的高速存储资源，能否移到更廉价的存储设备上去？ 1.2产品服务与定位 大数据时代已经来临！ 面对数据资源的爆炸性增长，政府、企事业单位每天产生的海量视频、语音、图片、文档和重要客户数据等资料如何有效存取？政府多个部门之间、公司和子公司之间、公司各个部门之间强烈的数据共享需求如何满足？如果
社会医疗保险数据中心管理平台 技术白皮书 创智和宇
目录 1简介 (4) 1.1应用背景 (4) 1.2范围 (4) 1.3参考资料 (4) 2系统概述 (5) 2.1医疗保险数据中心管理平台概述 (5) 2.2总体结构图 (5) 2.2.1医疗保险数据中心管理平台的的总体结构 (6) 2.2.2医疗保险数据中心管理平台的逻辑结构 (6) 2.2.3医疗保险数据中心管理平台的的网络拓扑结构 (7) 2.3.1数据库内部组成 (7) 2.3.2生产库定义（地市级） (7) 2.3.3交换库定义（地市级） (7) 2.3.4决策分析库（地市级） (8) 2.3.5决策分析库（省级） (8) 2.4 医疗保险数据中心管理平台与其他系统关系 (8) 2.4.1与本公司开发的社保产品关系及实现接口 (8) 2.4.2与其它公司开发的社保产品关系及实现接口 (8) 2.4.3与全国联网软件关系 (9) 3业务逻辑的总体设计 (9) 3.1数据抽取建立交换数据库 (9) 3.2数据分析与决策 (9) 3.3数据交换服务 (10) 4系统采用的关键技术 (11) 4.1数据抽取 (11) 4.2增量更新 (11) 4.2.1增量更新实现步骤 (11) 4.2.3 历史数据变化情况记录 (12) 4.3数据展现 (12) 4.4数据传输 (12) 4.4.1数据传输涉及的三大元素及关系 (12) 4.4.2数据传输策略总体设计思路. (12) 4.4.3数据传输策略总体设计方案图 (12) 4.4.4数据传输策略实现概要. (14) 4.4.5打包数据的来源 (14) 4.4.6传输策略的维护 (14) 5系统开发平台和运行平台 (14) 5.1开发平台 (14) 5.2运行平台 (14) 6医疗保险数据中心管理平台功能介绍 (15) 6.1参保情况管理 (16)
附件二十九：产品方案技术白皮书 一、背景概述 (2) 1、研发背景 (2) 2、产品定位 (2) 二、产品方案功能介绍 (2) 1、设计理念 (2) 2、系统拓扑图 (2) 3、系统构架描述 (2) 4、系统功能介绍 (2) 5、产品方案规格 (2) 四、产品方案应用介绍 (3) 1、应用模式 (3) 2、应用流程 (3) 3、应用环境 (3) 五、产品方案特性介绍 (3) 1、技术特性 (3) 2、应用特性 (3) 3、系统特性 (3) 六、产品方案技术介绍 (3) 1、相关技术 (3) 2、技术指标 (4) 七、产品方案测评数据 (4) 八、实施运维方式说明 (4) 4.................................................................................................................. . 九、售后服务方式说明 一、背景概述 1、研发背景 介绍用户需求背景、该产品所在行业信息化建设背景、产品所涉及的相关政策简述等，以说明该产品的研发背景，以及满足的客户需求。 2、产品定位 为了满足客户以上需求，该产品具有什么功能，能够解决什么问题。 二、产品方案功能介绍 1、设计理念 该产品方案的设计思路。 2、系统拓扑图 使用统一的图标，制作系统拓扑图。 3、系统构架描述 按照系统的构成，分类对系统进行描述。 4、系统功能介绍
详细阐述系统的主要功能。 5、产品方案规格 产品方案不同的规格介绍，或者对产品方案技术规格的介绍。． 四、产品方案应用介绍 1、应用模式 该产品方案包括的应用模式类型，或者针对不同类型客户的解决方案。 2、应用流程 该产品方案的应用流程。 3、应用环境 描述该产品所运行的应用环境。 五、产品方案特性介绍 1、技术特性 主要是性能先进性、功能齐全性、系统兼容性、技术稳定性等。 2、应用特性 主要是部署灵活性、可扩展性、管理方便性、易用性等。 3、系统特性 对系统的主要特性进行描述，根据产品不同和竞争优势的不同而不同。 六、产品方案技术介绍 1、相关技术 主要应用技术的介绍，以及该技术的优势。． 2、技术指标 针对技术参数进行描述。 七、产品方案测评数据 产品方案主要测评数据，可以是内部测评数据，也可以是第三方的测评数据。 八、实施运维方式说明 该产品方案的实施运营方式，以及实施运营需要注意问题的说明。 九、售后服务方式说明 该产品方案的售后服务方式、服务标准、服务内容说明，以及不同服务方式的报价。．
车辆管理系统技术白皮书 (Version 2.8.1.9.1) 2019 年 11 月
目录 第一章南航大车辆管理系统概述 (3) 1.1南航大车辆管理系统概述 (3) 1.2南航大车辆管理系统解决方案 (3) 第二章系统构架 (4) 2.1系统架构 (4) 2.2系统体系结构 (4) 第三章南航大车辆管理系统模块组成 (5) 3.1PC端 (5) 3.1.1 用户管理中心 (5) 3.1.2 基础数据管理 (6) 3.1.3 通行证管理 (7) 3.1.4 违章管理 (7) 3.1.5 大数据中心 (8) 3.1.6 外来车辆管理 (8) 3.1.7 信息管理中心 (8) 3.1.8 黑名单管理 (8) 3.2移动端 (9) 3.2.1 车主角色部分 (9) 3.2.2 管理员角色部分 (10) 第四章系统部署要求 (11) 4.1系统要求 (11)
第一章南航大车辆管理系统概述 1.1 南航大车辆管理系统概述 南航大车辆管理系统是一套便捷的校园车辆管理系统。该系统同时满足了校内教职工、学生与校外人员车辆通行证办理的需求，用户只需打开手机访问系统即可完成通行证的办理。管理人员可以通过移动端和PC端完成在线审核，该系统与校内原有抬杆系统无缝对接，最大限度保留老系统。 1.2 南航大车辆管理系统解决方案 系统有PC端和移动端两个入口。PC端只允许管理员登录；移动端管理员与用户都可以登录。管理员可以在PC端对各项基础数据进行维护、在线审核通行证办理申请、审核违章等，亦可在移动端查看、审核通行证办理申请；用户在移动端完成通行证的申请、违章上报、非机动车辆信息登记、查看个人信息等操作。 用户包括校内教职工、学生与社会人员，教职工可凭个人账号直接登录；社会人员可以通过手机号在线注册使用，二者互不影响。?无缝对接学校原有系统，降低改造门槛 为了保证用户通行证数据能在学校原有的抬杆系统中使用，该项目中额外增加了一个数据交换系统。通过该它完成新老系统的数据交换，用户无需对现有设备、系统进行升级改造，使原有系统能够继续使用。
华为F u s i o n S p h e r e6.0 云套件安全技术白皮书(云 数据中心) -标准化文件发布号：（9456-EUATWK-MWUB-WUNN-INNUL-DDQTY-KII
华为FusionSphere 云套件 安全技术白皮书（云数据中心） 文档版本 发布日期 2016-04-30 华为技术有限公司
华为FusionSphere 云套件安全技术白皮书 (云数据中心) Doc Number:OFFE00019187_PMD966ZH Revision:A 拟制/Prepared by: chenfujun ; 评审/Reviewed by: huangdenghui 00283052;zouxiaowei 00348656;pengzhao jun 00286002;youwenwei 00176512;yanzhongwei 00232184 批准/Approved by: youwenwei 00176512 2015-12-29 Huawei Technologies Co., Ltd. 华为技术有限公司 All rights reserved 版权所有侵权必究
版权所有 ?华为技术有限公司 2016。保留一切权利。 非经本公司书面许可，任何单位和个人不得擅自摘抄、复制本文档内容的部分或全部，并不得以任何形式传播。 商标声明 和其他华为商标均为华为技术有限公司的商标。 本文档提及的其他所有商标或注册商标，由各自的所有人拥有。 注意 您购买的产品、服务或特性等应受华为公司商业合同和条款的约束，本文档中描述的全部或部分产品、服务或特性可能不在您的购买或使用范围之内。除非合同另有约定，华为公司对本文档内容不做任何明示或暗示的声明或保证。 由于产品版本升级或其他原因，本文档内容会不定期进行更新。除非另有约定，本文档仅作为使用指导，本文档中的所有陈述、信息和建议不构成任何明示或暗示的担保。 华为技术有限公司 地址：深圳市龙岗区坂田华为总部办公楼邮编：518129 网址：
一、背景概述 (2) 1、研发背景 (2) 2、产品定位 (2) 二、产品方案功能介绍 (2) 1、设计理念 (2) 2、系统拓扑图 (2) 3、系统构架描述 (2) 4、系统功能介绍 (2) 5、产品方案规格 (2) 四、产品方案应用介绍 (3) 1、应用模式 (3) 2、应用流程 (3) 3、应用环境 (3) 五、产品方案特性介绍 (3) 1、技术特性 (3) 2、应用特性 (3) 3、系统特性 (3) 六、产品方案技术介绍 (3) 1、相关技术 (3) 2、技术指标 (4) 七、产品方案测评数据 (4) 八、实施运维方式说明 (4) 九、售后服务方式说明 (4)
一、背景概述 1、研发背景 介绍用户需求背景、该产品所在行业信息化建设背景、产品所涉及的相关政策简述等，以说明该产品的研发背景，以及满足的客户需求。 2、产品定位 为了满足客户以上需求，该产品具有什么功能，能够解决什么问题。 二、产品方案功能介绍 1、设计理念 该产品方案的设计思路。 2、系统拓扑图 使用统一的图标，制作系统拓扑图。 3、系统构架描述 按照系统的构成，分类对系统进行描述。 4、系统功能介绍 详细阐述系统的主要功能。 5、产品方案规格 产品方案不同的规格介绍，或者对产品方案技术规格的介绍。
四、产品方案应用介绍 1、应用模式 该产品方案包括的应用模式类型，或者针对不同类型客户的解决方案。 2、应用流程 该产品方案的应用流程。 3、应用环境 描述该产品所运行的应用环境。 五、产品方案特性介绍 1、技术特性 主要是性能先进性、功能齐全性、系统兼容性、技术稳定性等。 2、应用特性 主要是部署灵活性、可扩展性、管理方便性、易用性等。 3、系统特性 对系统的主要特性进行描述，根据产品不同和竞争优势的不同而不同。 六、产品方案技术介绍 1、相关技术 主要应用技术的介绍，以及该技术的优势。
此处是Logo 数据库审计系统 技术白皮书 地址： 电话： 传真： 邮编：
■版权声明 本文中出现的任何文字叙述、文档格式、插图、照片、方法、过程等内容，除另有特别注明，版权均属北京所有，受到有关产权及版权法保护。任何个人、机构未经北京的书面授权许可，不得以任何方式复制或引用本文的任何内容。 ■适用性声明 文档用于撰写XX公司产品介绍、项目方案、解决方案、商业计划书等。
目录 一.产品概述 (1) 二.应用背景 (1) 2.1现状与问题 (1) 2.1.1现状 (1) 2.1.2问题 (1) 2.2需求分析 (3) 2.2.1政策需求 (3) 2.2.1.1《信息系统安全等级保护基本要求》 (3) 2.2.1.2《商业银行信息科技风险管理指引》 (3) 2.2.2技术需求 (4) 2.2.3管理需求 (4) 2.2.4性能需求 (4) 2.2.5环境与兼容性需求 (5) 2.2.6需求汇总 (5) 三.产品介绍 (5) 3.1目标 (5) 3.2产品功能 (6) 3.2.1数据库访问行为记录 (6) 3.2.2违规操作告警响应 (6) 3.2.3集中存储访问记录 (6) 3.2.4访问记录查询 (7) 3.2.5数据库安全审计报表 (7) 3.3产品部署 (7) 3.3.1旁路部署 (7) 3.3.2分布式部署 (8) 3.4产品特性 (9) 3.4.1安全便捷的部署方式 (9) 3.4.2日志检索能力 (9) 3.4.3灵活的日志查询条件 (10) 3.4.4灵活的数据库审计配置策略 (10) 3.4.5数据库入侵检测能力 (10) 3.4.6符合审计需求设计 (11) 四.用户收益 (11) 4.1对企业带来的价值 (11) 4.2全生命周期日志管理 (12) 4.3日常安全运维工作的有力工具 (12)
协同办公(OA)系统技术白皮书 石河子开发区汇业信息技术有限责任公司 2013年1月28日 版权声明：本文档及相关附件的版权属于石河子开发区汇业信息技术有限责任公司，任何组织或个人未经许可，不得擅自修改、拷贝、分发或以其它方式使用本文档中的内容。
目录 1. 文档描述 (1) 2. 产品概述 (1) 2.1 系统用例 (1) 2.2 系统结构 (2) 3. 系统功能 (3) 3.1 基础功能 (3) 3.2 高级功能 (3) 3.3 定制接口 (3) 4. 产品特点 (3) 4.1 可用性 (3) 4.2 安全与保密性 (4) 4.3 可维护性 (4) 4.4 可移植性 (4) 4.5 技术特点 (4) 5. 系统运行环境 (5) 5.1 服务器环境 (5) 5.2 客户端环境 (5) 6. 成功案例 (6)
1. 文档描述 该文档主要描述协同办公(OA)系统的整体方案与技术实现方式，帮助使用者了解产品功能与技术特性及应用环境需求，具体的功能与操作方式描述请参见以下文档：《协同办公（OA）系统操作手册》、《协同办公（OA）系统用户手册》等。 2. 产品概述 协同办公(OA)系统是采用Internet/Intranet通信基础，以客户端Web浏览器为展现方式、以“工作流”为引擎、以“知识文档”为容器、以“信息门户”为窗口，使企事业单位内部人员方便快捷地共享信息，高效地协同工作；改变过去复杂、低效的手工办公方式，实现迅速、全方位的信息传递、知识采集、文档处理，为企业的管理和决策提供科学的依据。在传统OA的基础应用上，可供企事业机构自行灵活的定义符合自身需求的管理工作流程、知识目录架构、信息门户框架，以更便捷、更简单、更灵活、更开放的满足日常办公需求。并可根据实际需要定制开放接口实现其他系统与本系统间共享数据或调用本系统相关功能生成业务数据。 2.1 系统用例 本系统为企事业单位提供信息交流、文件传递、流程审批、知识文档共享的多功能平台，可以实现邮件、文件柜、信息公告、单位新闻等基础信息交流功能，并可实现电子审批(出差、上报文件、申请)的归档管理与经验总结、学习分享的无形财富管理功能。
互联网数据中心交换网络的设计 1 引言 互联网数据中心(internet data center，IDC)是指拥有包括高速宽带互联网接入、高性能局域网络、提供安全可靠的机房环境的设备系统、专业化管理和完善的应用级服务的服务平台。在这个平台上，IDC服务商为企业、ISP、ICP和ASP等客户提供互联网基础平台服务以及各种增值服务。 作为业务承载与分发的基础网络系统，就成为IDC平台的动脉。随着中国IDC产业不断发展和业务需求多样化，基础网络逐步发展出一套相对比较通用和开放的方案架构。 2 当前主要的IDC基础网络架构 虽然各IDC机房各有度身定制的业务需求，网络设计也有各自的关于带宽、规模、安全和投资的考虑因素，但最基本的关注点仍然集中在高可靠、高性能、高安全和可扩展性上。 2.1 通用的IDC架构 在整体设计上，层次化和模块化是IDC架构的特征，如图1，这种架构设计带来了整体网络安全和服务部署的灵活性，给上层应用系统的部署也提供了良好的支撑。 图1IDC层次化&模块化设计架构 分区结构采用模块化的设计方法，它将数据中心划分为不同的功能区域，用于部署不同的应用，使得整个数据中心的架构具备可伸缩性、灵活性和高可用性。数据中心的服务器根据用户的访问特性和核心应用功能，分成不同组，并部署在不同的区域中。由于整个数据中心的很多服务是统一提供的，例如数据备份和系统管理，因此为保持架构的统一性，避免不必要的资源浪费，功能相似的服务将统一部署在特定的功能区域内，例如与管理相关的服务器将被部署在管理区。 分区结构另一个特点是以IDC的客户群为单位进行划分，将具体客户应用集中在一个物理或逻辑范围内，便于以区域模块为单位，提供管理和其它增值服务。 层次化是将IDC具体功能分布到相应网络层、计算层和存储层，分为数据中心前端网络和后端管理等。网络本身根据不同的IDC规模，可以有接入层、汇聚层和核心层。一般情况下，数据中心网络分成标准的核心层、汇聚层和接入层三层结构。1）核心层：提供多个数据中心汇聚模块互联，并连接园区网核心；要求其具有高交换能力和突发流量适应能力；大型数据中心核心要求多汇聚模块扩展能力，中小型数据中心共用园区核心；当前以10G 接口为主，高性能的将要求4到8个10GE端口捆绑。2）汇聚层：为服务器群（server farm）提供高带宽出口；要求提供大密度GE/10GE 端口，实现接入层互联；具有较多槽位数提供增值业务模块部署。3）接入层：支持高密度千兆接入和万兆接入；接入总带宽和上行带宽存在收敛比和线速两种模式；基于机架考虑，1RU 更具灵活部署能力；支持堆叠，更具扩展能力；上行双链路冗余能力。
EVPN解决方案技术白皮书关键词：EVPN ，VTEP， L3VNI，IRB 摘要：本文介绍了EVPN的基本技术和典型应用。 缩略语：
目录 1 概述 (3) 2 EVPN技术 (4) 2.1 概念介绍 (4) 2.2 EVPN控制面 (5) 2.2.1 自动建立隧道、关联隧道 (5) 2.2.2 地址同步 (6) 2.2.3 外部路由同步 (7) 2.2.4 VM迁移 (8) 2.2.5 ARP抑制 (9) 2.3 EVPN数据面 (10) 2.3.1 VXLAN报文： (10) 2.3.2 EVPN组网模型 (10) 2.3.3 二层转发 (12) 2.3.4 三层转发 (14) 3 EVPN部署 (19) 3.1 EVPN组网应用模型 (19) 3.1.1 EVPN方案主推组网： (19) 3.1.2 EVPN方案可选组网： (20) 3.1.3 EVPN组网配置 (22) 4总结 (27)
1 概述 随着企业业务的快速扩展需求，IT作为基础设施，快速部署和减少投入成为主要需求，云计算可以提供可用的、便捷的、按需的资源提供，成为当前企业IT建设的常规形态，而在云计算中大量采用和部署的计算虚拟化几乎成为一个基本的技术模式。部署虚机需要在网络中无限制地迁移到目的物理位置，虚机增长的快速性以及虚机迁移成为一个常态性业务。 VxLAN网络技术是在传统物理网络基础上构建了逻辑的二层网络，是网络支持云业务发展的理想选择，是传统网络向网络虚拟化的深度延伸，提供了网络资源池化的最佳解决方式。它克服了基于 VLAN 的传统限制，可为处于任何位置的用户带 来最高的可扩展性和灵活性、以及优化的性能。 传统自学习方式构建VxLAN需要人工手动配置隧道，配置复杂。地址同步需要依赖数据报文泛洪方式实现，产生大量泛洪报文，不适合大规模组网。EVPN通过 MP-BGP自动建立VxLAN隧道，自动同步MAC和IP地址，很好的解决了这些问 题。EVPN（Ethernet Virtual Private Network，以太网虚拟专用网络）是一种二层VPN技术，控制平面采用MP-BGP通告EVPN路由信息，数据平面支持采用VxLAN 封装方式转发报文。租户的物理站点分散在不同位置时，EVPN可以基于已有的服 务提供商或企业IP网络，为同一租户的相同子网提供二层互联；通过EVPN网关为 同一租户的不同子网提供三层互联，并为其提供与外部网络的三层互联。 当前EVPN有正式的RFC以及相关草案，基于MPLS架构的已经有RFC7432。 EVPN定义了一套通用的控制面，但数据面可以使用不同的封装技术，他们的关系 如下图： EVPN不仅继承了MP-BGP和VxLAN的优势，还提供了新的功能。EVPN具有如下 特点：
EPS档案信息管理系统V3.0 技术白皮书 南京科海智博信息技术有限公司 2013年
目录 1.产品简介 (4) 1.1 文档信息化发展趋势 (4) 1.2 产品研发背景 (4) 1.3系统特点 (5) 2.总体架构 (5) 2.1 产品技术架构 (5) 2.2 产品业务架构 (6) 3.运行环境 (6) 3.1 硬件环境 (6) 3.1.1 服务器配置 (6) 3.1.2客户端配置 (6) 3.1.3存储设备 (7) 3.1.4网络环境 (7) 3.2软件环境 (7) 3.2.1 数据库支持 (7) 3.2.2中间件支持 (7) 3.2.3浏览器支持 (7) 3.2.4 容灾支持 (7) 4.基本功能 (7) 4.1系统管理 (8) 4.2业务管理 (13) 4.3文件收集 (13) 4.4文件整编 (14) 4.5档案管理 (15) 4.6库房管理 (16) 4.7统计信息 (16) 4.8档案利用 (17) 4.9档案编研 (18) 4.10光盘打包 (18)
5.扩展功能 (19) 5.1 企业档案门户集成 (19) 5.2企业年鉴展示 (19) 5.3照片档案展示 (20) 5.4 数据安全控制 (20) 5.5数据一体化接口 (20) 5.6信息提醒接口 (20) 6.技术创新 (21) 6.1文档安全控制 (21) 6.2 全文检索技术 (22) 6.3 光盘打包技术 (23) 6.4工作流技术 (23) 6.5 海量存储技术 (24) 6.6异构数据接口 (24) 6.7系统的可扩展性 (24) 6.8档案管理平台综合业务管理 (24) 7.公司简介 (24)
数据中心空调系统节能技术白皮书目录 1. 自然冷却节能应用 3 概述 3 直接自然冷却 3 中国一些城市可用于直接自然冷却的气候数据: 8间接自然冷却 8 中国一些城市可用于间接自然冷却的气候数据: 16 2. 机房空调节能设计 17 动态部件 17 压缩机 17 风机 18 节流部件 19 加湿器 19 结构设计 21 冷冻水下送风机组超大面积盘管设计 21 DX型下送风机组高效后背板设计 22 控制节能 22
主备智能管理 22 EC风机转速控制 23 压差控制管理 23 冷水机组节能控制管理 26 1.自然冷却节能应用 概述 随着数据中心规模的不断扩大，服务器热密度的不断增大，数据中心的能耗在能源消耗中所占的比例不断增加。制冷系统在数据中心的能耗高达40%，而制冷系统中压缩机能耗的比例高达50%。因此将自然冷却技术引入到数据中心应用，可大幅降低制冷能耗。 自然冷却技术根据应用冷源的方式有可以分为直接自然冷却和间接自然冷却。直接自然冷却又称为新风自然冷却，直接利用室外低温冷风，作为冷源，引入室内，为数据中心提供免费的冷量；间接自然冷却，利用水（乙二醇水溶液）为媒介，用水泵作为动力，利用水的循环，将数据中心的热量带出到室外侧。 自然冷却技术科根据数据中心规模、所在地理位置、气候条件、周围环境、建筑结构等选择自然冷却方式。 直接自然冷却 直接自然冷却系统根据风箱的结构，一般可分为简易新风自然冷却新风系统和新风自然冷却系统。 简易新风直接自然冷却系统主要由普通下送风室内机组和新风自然冷却节能风帽模块组成。节能风帽配置有外部空气过滤器，过滤器上应装配有压差开关，并可以传递信号至控制器，当过滤器发生阻塞时，开关会提示过滤器报警。该节能风帽应具备新风阀及回风阀，可比例调节风阀开度，调节新风比例。 该系统根据检测到的室外温度、室内温度以及系统设定等控制自然冷却的启动与停止。
终端安全配置管理系统 技术白皮书 国家信息中心
目录 第一章终端安全配置管理系统简介 (1) 1.1 为什么要做终端安全配置 (1) 1.2 机构如何实现机构高效的终端安全配置管理 (2) 1.3 终端安全配置管理系统技术优势 (3) 第二章终端安全配置管理系统逻辑结构 (5) 第三章终端安全配置管理系统功能 (7) 第四章终端安全配置基线介绍 (9) 4.1 基线概述 (9) 4.2 终端硬件安全配置 (9) 4.3 终端软件安全配置 (10) 4.4 终端核心安全配置 (11) 第五章系统应用方案 (14) 5.1 应用架构 (14) 5.2 实施流程 (16) 5.3 运行环境要求 (16) 第六章技术支持服务 (18) 附录一W INDOW7操作系统安全配置清单（示例） (19) 附录二国家信息中心简介 (24) i
第一章终端安全配置管理系统简介 1.1 为什么要做终端安全配置 在构成信息系统的网络、服务器和终端三要素中，对终端的攻击和利用终端实施的窃密事件急剧增多，终端安全问题日益突显。攻击和窃密是终端安全的外部原因，计算机系统存在缺陷或漏洞、系统配置不当是终端安全的内部原因。外因通过内因起作用，内因是决定因素。据调查，针对系统核心的攻击中，5%是零日攻击，30%是没有打补丁，65%是由于错误的配置。因此正确的安全配置才是保障终端安全性的必要条件。 计算机终端核心配置最早由美国联邦政府提出，称为联邦桌面核心配置计划（FDCC）。该计划由美国联邦预算管理办公室（OMB）负责推动，旨在提高美国联邦政府计算机终端的安全性，并实现计算机管理的统一化和标准化。美国空军最先实施桌面标准配置并取得了良好的应用效果。2007年，美国联邦政府强制规定所有使用Windows的计算机必须符合FDCC的配置要求。 近年来，我国逐步认识到终端安全配置管理对于加强计算机终端安全保障工作的重要作用，对美国联邦政府实施的桌面核心配置进行了跟踪研究，并开展了我国终端安全配置标准的研制工作。多家科研院所和安全厂商参与了相关研究工作，其中，国家信息中心是国内最早开展终端安全配置研究的单位之一，目前已编制完成政务终端安全核心配置标准草案，并开发出一整套标准应用支撑工具—终端安全配置管理系统。该系统在各地方的试点应用取得了明显的成效。 终端安全配置分为硬件安全配置、软件安全配置和核心安全配置，如图1所示。分别介绍如下： 硬件安全配置：根据计算机硬件列装的安全要求，仅可安装符合规定的硬件和外联设备，关闭存在安全隐患的接口以及驱动，以满足政府机构和大型企业对硬件环境的安全需求。包括计算机部件清单、外联设备清单、外联接口安全配置和硬件驱动安全配置； 软件安全配置：根据计算机软件安装的安全要求，仅可安装符合规定的操作系统和软件，禁止非法软件安装，以满足政府机构和大型机构对软件环境的安全需求。包括应安装软件列表、可安装软件列表和禁止安装软件列表； 核心安全配置：对终端操作系统、办公软件和浏览器、邮件系统软件、其它常用软件等与安全有关的可选项进行参数设置，限制或禁止存在安全隐患或漏洞的功能，启用
多媒体信息发布系统 技 术 白 皮 书
目录 一、系统概述 (5) 二、体系架构 (6) 2.1设计目标和理念 (6) 2.2系统架构 (6) 2.3软硬件部署 (7) 三、技术特点 (8) 3.1丰富的显示效果 (8) 3.1.1 灵活的自定义布局 (8) 3.1.2 各种基本控件 (10) 3.1.3 布局切换 (10) 3.2操作流程 (10) 3.2.1 通俗易懂的概念 (10) 3.2.2 常规流程 (10) 3.2.3 所见即所得的模板编辑 (12) 3.2.4 资源更新后显示效果自动更新 (12) 3.3可维护性 (12) 3.3.1 管理平台对终端的管理 (12) 3.3.2 终端的自我维护 (13) 3.4可扩展性 (14) 3.4.1 系统规模的扩展 (14) 3.4.2 行业应用的定制 (14) 3.4.3 支持多种终端设备 (15) 四、技术指标 (16) 4.1硬件指标 (16) 4.2软件指标 (17) 4.3系统指标 (17) 五、多媒体系统设计思想和工作原理 (18) 六、多媒体系统主要特点 (21)
七、带宽估算 (22) 7.1需求分析 (22) 7.2网络基本拓扑图： (22) 7.3基本服务器 (22) 7.4IDC服务器带宽估算： (23)
一、系统概述 信息时代，人们在接受信息的同时更需要发布信息。政府部门需要向公众发布政策、法规；企业需要向消费者宣传自己的产品与品牌；医院要向病人传递卫生健康的知识与建议等等。 为了实现面向公众的信息传递，人们采用了大幅的宣传画、电子广告牌、一体式广告机等等方式。但这些宣传方式，存在着内容单一、信息量有限、不能集中管理、内容更换困难等缺陷。 正是基于对市场的理解，结合先进的计算机视频网络技术，我们推出了新一代公众信息平台——“多媒体信息发布系统”，借助这套系统，管理人员在信息中心就可以将制作好的宣传信息随时传递到分布在任意地点的显示终端（显示器、电视机），并随时能控制任意终端播放的内容和播放形式。 图1-1信息发布系统示意图
实用标准文档 全渠道运营 解决方案 白皮书
目录 1. 背景 (3) 2. 现状 (3) 3. 业务概述（核心业务场景介绍） (4) 4. 方案介绍（方案落地的方法论，体系组成的特点） (5) 5. 方案架构（产品组成图，总体架构，技术体系等） (8) 5.1 总体架构 (8) 5.2 产品组成 (8) 5.3 技术体系 (10) 6. 方案特性和价值 (12)
1. 背景 背景一：移动互联网环境下的消费行为模型转变 背景二：品牌企业运营模式及管理要求的转变 单纯以渠道批发为主的运营模式正在产生深刻变革，批发流通转向零售运营的格局正在进一步深化，从面对渠道到面对消费者，品牌企业需要更多的了解商品的销售情况，更好的收集需求，更好服务于最终用户。 背景三：全渠道运营模式被越来越多的企业重视并开始实施 企业变革加剧，线上线下融合进一步加强，全渠道运营模式被越来越多的企业重视并开始实施，企业泛渠道经营成为重要的销售抓手。 全渠道运营就是批发转零售的转型，即以商品为中心的批发运作流程转为以消费者为中心的零售运作流程。顾客决定着商品的设计与流动，决定着渠道的拓展，决定着品牌的定位与发展。 2. 现状 传统的分销零售系统就是为批发模式而生的，它无法承载现在要为消费者提供全方位服务的职能，同时库存无法在线下线上渠道自由共享流通，导致货品不能货通天下，无法快速去库存，消费者需要的商品无法迅速通过内部自由调拨满足消费者的及时需求，补单不能在有效时间内迅速生产并供给门店消费者。 随着技术和行业业务的不断发展，品牌企业的零售系统在建设、运营和管理等方面不断发展并走向成熟和完善，主要呈现以下发展趋势： 批发转零售，零售渠道融合，让品牌企业为渠道服务，为会员服务。 通过变革赢得消费者，提高效率，获得更高的盈利能力。 快速供应链，提升周转率，降低库存成本，提升资金盈利能力。 品牌企业提升自身管理能力，完善全渠道基础设施平台： 1. 向下管控能力更强。各个品牌公司定制开发或购买产品软件，通过无偿推广给自己 的渠道商使用软件，通过软件全面收集终端数据，为实时决策打下基础。通过零售系统的搭建，强化对渠道和终端的支持和管控。 传统消费模型（AIDMA ） 注意（A ） 兴趣（I ） 需求（D ） 记住（M ） 行动（A ） 移动互联网消费模型（SICAS ） 感知（S ） 兴趣（I ） 联系（C ） 行动（A ） 分享（S ）
机房线路管理系统 -CVMS 一、当前现状 机房线路及设备管理现状 ?采用手工记录管理现有线缆标识、线路连接关系 ?缺乏统一的资料管理平台 ?网络物理线路查询困难 ?人员变更交接资料繁琐 ?缺乏规范的管理流程 ?无法清楚的了解网络设备的配置和资源使用状况 ?维护效率低，增加维护成本 为什么我们推出软件形式的机房线路管理系统？ ?提高企业/政府/教育/金融IT管理部门的效 率 ?解脱繁琐的传统文档管理工序 ?迅速诊断和定位网络问题 ?提升内部安全性能 ?极为合理的投资成本 ?实现管理图形化和数字化 ?纯软件系统对线路及网络硬件没有任何不良影响 智邦（知微?）机房线路管理系统是对机房系统中设备的维护信息和连接信息进行图形化管理，把图形、数据和连接关系三种对象紧密的结合，为管理员提供一个直观、易用的图形化管理平台。
二、系统特点 CVMS 是一套专业的机房线路管理软件，通过创建“可视化数据库”，将信息和图形有机结合，能帮助企业更好地规划、管理和维护其物理网络、通信、视频、监控及布线基础设施。 基于B/S（浏览器/服务器）结构模型，客户端以浏览器的web 页面形式运行； 系统后台采用SQL Server数据库； 纯软件架构，不需要对现有的网络和硬件进行任何改动； 管理界面友好、精美、简单、功能强大、操作灵活； 可实行跨地域管理和分工管理； 数据和图形相结合； 图形定位快捷； 设备、线缆、终端链路关联处理； 文档、设备、线路连接统一管理，建立完整的技术管理平台； 通过操作日志、管理权限、角色管理来实现对操作人员的管理； 线缆线标的管理使您的管理能精确到每一根线缆； 通过派工单管理，规范机房线路系统的维护工作流程。 三、应用范围 广泛应用于政府、军队、金融、税务、烟草、交通、教育、医疗、能源、电信、广电、司法、电力等多个行业 四、功能模块 1．数据采集 该模块的主要功能是对整个项目的内容进行录入，建立项目数据库。 模块特点： 以目录树的形式自上而下对项目内容进行逐步录入 上传楼层或区域平面图，使每个端口或信息点都可以在楼层平面图上的准确物理位 置以闪烁的形式标明 由机柜信息自动生成机柜和设备模拟图，并确定设备在机柜中的位置 定义信息点、终端设备的类型和内容 建立设备之间的连接关系，生成链路关系模拟图 支持数据批量录入，支持多人同时分工录入 支持线缆线标的批量录入