IT这种大规模分布式网络软件设计和实践，与当下流行的IT的Cloud Native的设计理念高度吻合：无状态：业务处理（应用）和存储（后台数据库）分离，将业务状态和会话数据从业务处理单元中分离出来，并存储在独立的数据库中，实现业务处理单元的无状态设计，使得业务处理单元可以任意弹性伸缩，从而可以应对突发的大流量。同时如果处理逻辑单元故障，则可以通过数据服务快速获取会话的数据/状态，包括正在进行的会话，从而不影响应用对外提供服务，保证业务的连续性。分布式存储: 简单来说，就是通过内部协议约定，将要求保存的文件同时写入到多台机器中，这样文件也有了多个备份，再也不怕一台机器出故障，数据就丢失的情况。通过分布式存储，利用多台存储服务器分担存储负荷，不但提高了系统的可靠性、可用性和存取效率，还易于扩展。（微）服务解耦：例如业务a将会员、商品、交易、个性化服务等进行功能解耦拆分，拆分之后的每个系统可以单独部署，业务简单，方便扩容，同时通过模块灵活组合来完成新业务快速上线。轻量虚拟化（容器）：在上述关键技术特征下，原有的单体应用被解构成多个小型的服务化模块，在虚拟化环境下，这些模块的资源载体相应地需要更轻量化，才能在大流量时进行快速部署，快速扩容。相对于传统的虚拟技术，容器技术不需要进行硬件虚拟以及运行完整操作系统等额外开销，所以容器对系统资源的利用率更高，并且启动速度更快。传统的虚拟机技术启动应用服务往往需要数分钟，而容器应用，由于直接运行于宿主内核，无需启动完整的操作系统，因此可以做到秒级、甚至毫秒级的启动时间。大大的节约了开发、测试、部署的时间。

主机：Taishan 200 2280虚拟化平台：FusionCompute 8问题描述：创建虚拟机安装Linux操作系统，在不选择计算资源的时候，支持各种发行版的Linux，但是一旦选择了计算资源，就只支持很少的版本了，连常用的Ubuntu都不支持。这种情况下如何安装自己想要的操作系统？从资料上看，鲲鹏芯片应该是支持Ubuntu的不选择计算资源：选择计算资源后，操作系统版本号里面不再有Ubuntu：

Taishan 200 2280安装FusionCompute 8，单节点。登录管理平台，创建虚拟机，安装CenOS 7失败，在选择Install CentOS 7后，就无法出现图形化安装界面，导致安装过程无法进行。安装日志见附件。ISO镜像已经在其他几台物理机上正常安装过，本次安装本地方式和文件方式两种挂载方式都尝试过。虚拟机配置：8核，8G内存，80G硬盘可以出现grub界面回车后稍等片刻出现如下界面这个界面以后就一直是下面这样，等了一个晚上都还是一样日志中有如下内容，详细内容可以见附件

Hypervisor是一种运行在物理服务器和操作系统之间的中间软件层，可允许多个操作系统和应用共享一套基础物理硬件。它可以协调访问服务器上的所有物理设备和虚拟机，也叫虚拟机监视器（Vrtual Machine Monitor：VMM）Hypervisor的基本功能：非中断地支持多工作负载迁移能力。当服务器启动并执行Hypervisor时，它会给每一台虚拟机分配适量的内存、CPU、网络和磁盘，并加载所有虚拟机的客户操作系统。什么是虚拟机：从虚拟化管理程序的角度看，虚拟机是一组离散的文件。VMM(虚拟机监视器)/HypervisorCPU: VMM负责VCPU在物理处理单元上的调度内存: VMM负责维护虚拟地址到物理地址的映射关系I/O网络、存储：VMM通过I/O虚拟化来复用有限的外设资源,通过截获Guest OS对I/O设备的访问请求,通过软件模拟真实的硬件

## 一、 场景和问题 树结构，多级嵌套（不确定几级），使用递归方式实现，数据量上万情况下，页面加载很慢。 数据结构：十个父级节点，每个父节点有10000个子节点，父子是嵌套关系 #### 代码：  #### 页面加载：  此时页面渲染需要13.5s ## 二、问题解决 #### 2.1 树数据结构扁平化  从performance工具定位问题：调用栈createChildren被疯狂调用，在vue源码中，createChildren做的是创建Vue实例这件事。创建Vue实例包括依赖收集、响应式监听、数据事件绑定、编译模板等等。 如果能将数据结构扁平化，就只会有一个tree组件，createChildren只执行进行一次。 扁平化数据还有个好处就是： + 减少栈的读取，递归的本质是栈的读取，栈的读取是由解析器做的，扁平化可以减少V8引擎的开销。 + 扁平化数据可以减少dom 的数量。  扁平化后优化到6.5s，我们觉得6.5s还是远远不够 #### 2.2 虚拟长列表 我们可以用懒加载解决海量数据一次性加载的问题，但是最终dom数量还是很大，容易造成页面卡顿。 所以我们使用虚拟长列表解决这个问题：  通过虚拟长列表，我们就控制住了DOM数量。 #### 2.3 其他优化思考 滚动事件加防抖，但要保证滚动的平滑度，使我们需要去权衡的。样式直接在数据中输出，不通过计算：树结构缩进padding距离不通过层级计算，而是在数据中直接给出样式，避免每个节点都计算一次样式的性能问题。

MEP管理面： 特性简介MEP管理面提供应用的生命周期管理，通过支持管理多个边缘计算平台。支持基于虚拟机的应用部署，同时也支持基于Docker的应用部署。在部署过程中，可以同步MEP应用商店的应用包到平台，然后通过MEP管理面分发到边缘，进行部署。 客户价值● 方便管理应用的增删改查。● 方便查看边缘节点的资源使用情况。● 方便管理边缘节点的MEP平台。特性描述同时支持容器化和基于虚拟机的应用管理MEP管理面基于kubernetes 进行应用管理，可以支持Helm和Kubernetes deployment两种部署方式，同时通过Kubevirt可以支持基于Kubernetes的虚拟机管理。节点管理MEP管理面通过集成Grafna可以支持对每个Edge节点进行监控，同时MEP管理面也可以分节点进行所有资源的查看，包括MEP，APP，以及Kubernetes自身进行监控。CatalogMEP管理面的Catalog管理MECM从MEP应用商店同步过来的APP Package。并且可以通过注册系统，将APP Package提前分发到边缘计算节点，节省了MEP管理面在部署过程中需要提前下载相关镜像的时间。

虚拟设备模拟器中输入“00193C0064”，出现[IoCM]Datareport servicetype notfound. No serviceType corresponding to serviceId was found on the platform, serviceId:RawData的错误。应用模拟器中没收到任何的数据。但是在应用模拟器中选择命令进行发送，设备模拟器是可以收到数据的。所以感觉应该没有定义错误才对，但为什么会出现这种单向数据可以接收的情况。

ETSI MEC 架构参考模型ETSI（欧洲电信标准化组织）在 2014 年率先启动 MEC 标准化参考模型项目。这一项目组旨在移动网络边缘为 （自己、合作伙伴或第三方）应用开发商与内容提供商 搭建一个云化计算与 IT 环境的服务平台，并通过该平台开放无线侧网络信息，实现高带宽、低时延业务支撑与本地管理。MEC 标准化的内容主要包括以下内容：研究 MEC 需求、平台架构、编排管理、接口规范、应用场景研究等。在 2017 年底，ETSI MEC 标准化组织已经完成了 Phase I 第一阶段基于传统 4G 网络架构部署，定义边缘计算系统应用场景、参考架构、边缘计算平台应用支撑 API、应用生命周期管理与运维框架、以及无线侧能力服务 API（RNIS/定位/带宽管理）。ETSI MEC 架构抽象模型宏观来讲，MEC 基本架构中不同的功能实体可分为三个层级：移动边缘系统层（Mobile Edge System Level）：负责对 MEC 系统进行全局掌控。移动边缘主机层（Mobile Edge Host Level）：包含了移动边缘主机（ME host）和移动边缘主机层管理实体（ME host-level management entity）；其中，移动边缘主机又可以进一步划分为移动边缘平台（ME platform）、移动边缘应用（ME application）和虚拟化基础设施（IaaS）。网络层（Networks Level）：包含了 3GPP 蜂窝网络、本地网络和外部网络等相关的外部实体。该层主要表示了 MEC 工作系统与局域网、蜂窝移动网或者外部网络的接入情况。ETSI MEC 架构参考模型ME 主机（移动边缘主机） 由 ME 平台、ME 应用和虚拟化基础设施组成。虚拟化基础设施可以为 ME 应用提供计算、存储和网络资源，并且可以为 ME 应用提供持续的存储和时间相关的信息，它包含一个数据转发平面来为从 ME 平台接收到的数据执行转发规则，并在各种应用、服务和网络之间进行流量的路由。ME 平台（移动边缘平台，MEP） 从 ME 平台管理器、ME 应用或 ME 服务处接收流量转发规则，并且基于转发规则向转发平面下发指令。另外，ME 平台还支持本地域名系统（DNS）、代理服务器的配置，可以将数据流量重定向到对应的应用和服务。ME 平台还可以通过 Mp3 参考点与其他的 ME 平台进行通信，在分布式 MEC 系统的协作机制中，Mp3 参考点可以作为不同 ME 平台互联的基础。ME 应用（移动边缘应用，ME APP） 是运行在 ME 虚拟化基础设施上的虚拟机实例，这些应用通过 Mp1 参考点与 ME 平台相互通信。Mp1 参考点还可提供标识应用可用性、发生 ME 切换时为用户准备或重定位应用状态等额外功能。ME 平台管理器（ME platform manager，移动边缘平台管理器，MEPM） 具有 ME 平台元素管理、ME 应用生命周期管理以及 ME 应用规则和需求管理等功能。ME 平台和 MEPM 之间使用 Mm5 参考点，该参考点实现平台和流量过滤规则的配置，并且负责管理应用的重定位和支持应用的生命周期程序。Mm2 是操作支持系统（OSS）和 MEPM 之间的参考点，负责 ME 平台的配置和性能管理。Mm3 是 MEO 和 MEPM 之间的参考点，负责为应用的生命周期管理和应用相关的策略提供支持，同时为 ME 的可用服务提供时间相关的信息。ME 应用生命周期管理包括 ME 应用程序的创建和终止，并且为 ME 编排器（ME orchestrator，MEO，移动边缘编排器）提供应用相关事件的指示消息。ME 应用规则和需求管理包括认证、流量规则、DNS 配置和冲突协调等。ME 编排器（ME orchestrator，MEO，移动边缘编排器） 是 ME 提供的核心功能，MEO 宏观掌控 ME 网络的资源和容量，包括所有已经部署好的 ME 主机和服务、每个主机中的可用资源、已经被实例化的应用以及网络的拓扑等。在为用户选择接入的目标 ME 主机时，MEO 衡量用户需求和每个主机的可用资源，为其选择最为合适的 ME 主机，如果用户需要进行 ME 主机的切换，则由 MEO 来触发切换程序。MEO 与OSS 之间通过 Mm1 参考点来触发 ME 应用的实例化和终止。MEO 与虚拟化基础设施管理器（VIM）之间通过 Mm4 参考点来管理虚拟化资源和应用的虚拟机映像，同时维持可用资源的状态信息。从 ME 系统的角度来看，OSS（Operations Support System 操作支持系统） 是支持系统运行的最高水平的管理实体。OSS 从面向用户服务（Customer-Facing Service，CFS）门户和用户终端（UE）接收实例化或终止 ME 应用的请求，检查应用数据分组和请求的完整性和授权信息。经过 OSS 认证授权的请求数据分组会通过 Mm1 参考点被转发到 MEO 进行进一步处理。面向用户服务门户（Customer-Facing Service Portal，CFS Portal） 实体相当于第三方接入点，开发商使用该接口将自己开发的各种应用接入运营商的 ME 系统中，企业或者个人用户也可以通过该接口选择其感兴趣的应用，并指定其使用的时间和地点。CFS 通过 Mx1 参考点与 OSS 实现通信。用户终端应用（User app，UEAPP）用户应用生命周期代理（user app LCM proxy，UEAPPLCM proxy） 是供 ME 用户使用来请求应用相关的实例化和终止等服务的实体。该实体可以实现外部云和 ME 系统之间的应用重定位，负责对所有来自外部云的请求进行认证，然后分别通过 Mm8 和 Mm9 参考点发送给 OSS 和 MEO 做进一步处理。值得注意的是，LCM 只能通过移动网络接入，Mx2 参考点提供了 UE 与 LCM 相互通信的基础。虚拟化基础设施管理器（VIM） 用于管理 ME 应用的虚拟资源，管理任务包括虚拟计算、存储和网络资源的分配和释放，软件映像也可以存储在 VIM 上以供应用的快速实例化。同时，VIM 还负责收集虚拟资源的信息，并通过 Mm4 参考点和 Mm6 参考点分别上报给MEO 和 MEPM 等上层管理实体。MEC 与 UPFMEC 在 ETSI 的定义里面包括了用户数据平面功能（UPF）以及边缘计算平台功能，而 3GPP 的 5G 架构里面主要是定义了 UPF 网元，UPF 作为核心网的用户面下沉网元，更多是网络功能。目前两大组织也在考虑 MEC 与 UPF 的融合，一般认为 5G 网络下 MEC 与 UPF 的关系如下图所示：UPF 是 MEC 系统的一个组成网元，MEC 系统还包括 ME C平台、MEC 平台管理、MEC 服务、MEC 应用、边缘云基础设施以及 MEC 编排（其中 MEC 平台、MEC 服务和 MEC 应用均是面向 MEC 业务服务提供，我们统称为 MEC 业务系统)，UPF 负责将边缘网络的流量分发导流到 MEC 业务系统，逻辑上 UPF 与 MEC 业务系统是分离、松耦合的，实际建设时对于 MEC 与 UPF 是否合设集成部署与统一承载存在以下多种方案：MEC 与 UPF 集成部署，基于 ICT 综合边缘云统一承载。MEC 与 UPF 分离部署，基于不同的边缘云各自承载。MEC 与 UPF 部分共享部署。ETSI MEC & NFV 架构参考模型Phase II 第二阶段的标准化于 2018 年 9 月底完成，主要聚焦在包括 5G/Wi-Fi/固网在内的多接入边缘计算系统，重点覆盖 MEC in NFV 参考架构、端到端边缘应用移动性、网络切片支撑、合法监听、基于容器的应用部署、V2X 支撑、Wi-Fi 与固网能力开放等研究项目，从而更好地支撑 MEC 商业化部署与固移融合需求，之前完成，同期将开启第三阶段的标准维护和标准新增阶段。ETSI MEC017 协议于 2018 年 2 月发布，重点描述了 MEC 在 NFV 环境下的部署。MEC 作为与生俱来的带有 NFV 属性的一套生态，MEC017 协议可以认为是 MEC003 协议的进一步的扩展，更加面向实际部署和落地。整个架构遵循以下原则：已有的电信网 NFV 架构网元部分尽可能的重用，MEC 模块可调用 NFV 部分功能，MEC 内部功能模块之间的信令不受 NFVO 控制，MEC 同 NFV 之间的接口要重新定义。NFV 参考架构MEC 在 NFV 中的参考架构以 ME APP、MEP、MEPM-V、VNFM（MEPLCM）、DataPlane、CFSPortal、UEAPP、UEAPPLCM proxy、OSS、MEAO 为组合，被 MEC 参考点（MEC reference points）所连接的网元，是 MEC 原有架构部分，这部分已经在 MEC003 中定义和说明过。这些功能模块是属于 MEC 特有的网元，是基于 NFV 基础上，根据 MEC 业务特性和业务需求所设定的全新的功能模块架构。由于 NFV 的网元大多是面向电信网的网元，而 MEC 则更加偏向第三方 APP 和业务，业务种类也比 NFV 更加多样，如：定位、分流、IoT、视频编解码等等。所以，基于 MEC 业务种类繁多的特性，有必要在 NFV 的基础上增加若干个功能不一的模块来协助 MEP 实现更多的功能。这里需要说明一点，MEC 需要虚拟化资源和管理，因此，MEC 重用了 NFVI 和 VIM 的部分，可直接调用而无需二次开发。MEC 模块同 NFV 网元之间的接口，也存在着重新开发和定义的问题。以 NFVI、VIM、OSS 为组合，可视为 MEC 和 NFV 重用的网元部分。这些网元在进行电信网 NFV 开发和部署的时候就已经建设完成了，MEC 相关业务在运行时也需要他们的支持，因此直接重用即可。我们知道 NFV（网络功能虚拟化）指的是解耦传统电信设备的软硬件，并将软件功能运行于 x86 通用服务器硬件上，以降低成本，缩短部署周期和激发服务创新。与 NFV 一样，MEC 也强调功能软件化和平台开放化，以提升网络敏捷性，灵活性，加快部署和创新。在标准构架上，MEC 和 NFV 看起来不无二致，但它们是有区别的。区别主要在应用服务平台和相关服务上，MEC 根据 RAN 环境对 NFV 进行了优化，它将移动接入网与互联网业务深度融合，并将云计算和云存储下沉到边缘数据中心，加速内容分发和下载，且向第三方提供开放接口以驱动创新。有了 MEC，PGW-U/SGW-U 的用户面就下沉到了移动边缘节点，且由 NFV VIM（虚拟基础设施管理）、SDN 和 Orchestrator（编排器）控制管理。第三方 APP 的管理模式APP 的管理对 MEC 来说是重要的部分，对 APP 的管理方式其背后代表了未来计算平台的运维模式和管理策略。ME APP 既受控于有 MEC 背景的 MEPM-V，也受控于有 NFV 架构背景的 VNFM（ME APP LCM），其本质在于 ME APP 是否与 MEP 有交互，是否使用了 ME service 或获取平台能力进行优化。ME APP 受控于 MEPM-V 模式。这种方式表明了 ME APP 部署在 NFVI 上，同时经由 Mp1 接口，连接到 MEP 平台，并可能使用 ME service，遵从 MEPM-V 的管理。由于 MEPM-V 中包含了 ME APP 规则和需求管理，因此这种方式就默认了 ME APP 要受到 MEP 平台的管理。通常 MEP 可以是运营商自建也可以是设备商的集成设备。总之，这种管理方式就意味着第三方 APP 部署在 MEP 上时必须受到平台的管理，这种管理方式的好处显而易见，有利用边缘生态中 APP 的管理和调度，但是未来可能存在一个问题，如果 ME APP 只是想用这些 NFVI 的资源，而对 MEP 上的 ME service 不感兴趣，那么这种管理就使得第三方 APP 难以接受，因为目前 Mp1 接口定义的还不够充分，第三方也需要围绕MEP进行定制化开发，这些都加重了第三方的工作量，需要考虑第三方的需求和想法。但是作为 MEC 构建生态的想法，我们更倾向于提供第三方 APP 足够的 PaaS 能力。ME APP 受控于 VNFM（ME APP LCM）模式。这种管理方式，即 ME APP 仅受到 NFV 网元的管理，也就是只是对 ME APP 的生存周期进行管理。这种方式表明第三方的 APP 仅仅是租用了边缘数据中心的 NFVI，进行部署，但是不使用任何 MEP 中的 service 和平台能力，因此 ME APP 仅仅从资源层面受到管理。这种商业模式其实就是租赁机房资源、租赁机架、租赁硬件资源、租赁虚拟机的商业模式，从实现来讲受益更加直接，第三方直接获取资源自行开发相应服务，运营商也无需在 MEC 平台层面做过多的开发。但是这种方式并不是在营造 MEC 生态，因为这一管理方式彻底抛弃了 APP 同 MEP 之间的关联， Mp1 接口完全废弃，那么 MEP 也没有了存在的价值，因此这种方式只可在早期不成熟的时候采用，长期发展对 MEC 生态和建设非常不利。ME APP 同时受控于 MEPM-V 和 VNFM（MEAPP LCM）模式。这种方式结合了 MEC 中 APP 管理和 NFV 中的 APP 管理。NFV 仅对 APP 的生存周期和虚拟化资源进行管理，而 MEC 则对 ME APP 规则和需求进行管理，分工明确职责不同。同时定义好 Mp1 接口，提供ME APP 使用 MEP 中 ME service 的途径，借助边缘云平台能力可以进行 APP 的定制优化。这种方式一方面迎合了 APP 和 MEC 平台搭建方的各方需求，同时也是未来比较合适的管理方式。转载自：《5G 与 MEC边缘计算》https://www.cnblogs.com/jmilkfan-fanguiju/p/11825026.html

1 说明ManageOne运维侧中虚拟机分为管理虚拟机和租户虚拟机（又叫弹性云服务器），二者属于不同的资源模型，查询时使用的接口也是不同的，租户虚拟机的查询，请参考https://bbs.huaweicloud.com/forum/thread-35471-1-1.html；这里说明如何查询管理虚拟机列表和详情。2 管理虚拟机模型结构在ManageOne运维侧，管理虚拟机的对象名称是SYS_VM，包含多个子对象，我们需要查询管理虚拟机关联的子对象详情，从而获得管理虚拟机的详细信息，如下表所示：父对象类型子对象类型（名称）可获得的关键信息父子对象关系名SYS_VM（管理虚拟机）SYS_Flavor（规格）虚拟机的vCPU、内存大小M_VMUsesFlavorSYS_Volume（虚拟机磁盘）虚拟机关联的磁盘，磁盘容量M_VMAttachedToVolumeSYS_vNIC（网卡）虚拟机IP地址，MAC地址M_VMConsistsOfvNICSYS_Image（镜像）虚拟机所使用的操作系统版本M_VMUsesImage3 接口清单&准备工作序号                                               URL                       说明1【PUT】/rest/plat/smapp/v1/oauth/token获取token2【GET】/rest/cmdb/v1/instances/{className}查询指定类型系统资源列表，此处className取值范围为第2章中所给出的父、子对象名称3【GET】/rest/cmdb/v1/instances/relations/{relationName}查询某类型关系的所有实例，此处relationName取值为第2章中所给出的父子对象关系名4【GET】/rest/cmdb/v1/instances/{className}/{instanceId}查询单个资源实例，此处className取值范围为第2章中所给出的父、子对象名称，instanceId为具体对象的资源ID正式调用接口前，需要获取账号，域名，请参考：https://bbs.huaweicloud.com/forum/thread-35466-1-1.html4 查询步骤查询管理虚拟机详情，整体流程为：查询管理虚拟机列表-->查询管理虚拟机与子对象的关系-->查询子对象详情，这里管理虚拟机有多个子对象，需要分别查询，具体步骤如下：步骤1 获取token调用方法：PUT调用URL：https://{运维侧对外访问域名}/rest/plat/smapp/v1/oauth/token请求头：Accept:application/json Content-Type:application/json;charset=UTF-8请求body:{     "grantType": "password",     "userName": "XXX",     "value": "***" }响应示例：{ "accessSession": "xxxxxxxxxxxxx", "roaRand": "xxxxxxxxxxxxx", "expires": 1800, "additionalInfo": null }accessSession的值即为token值步骤2 查询管理虚拟机列表调用方法：GET调用URL：https://{运维侧对外访问域名}/rest/cmdb/v1/instances/SYS_VM（该接口支持分页，分页参数为pageSize（每页大小），pageNo（页码数），二者均为大于等于1的整数）请求头：Accept:application/json Content-Type:application/json;charset=UTF-8 X-Auth-Token:xxxxxxxxxxxxx响应示例：{     "objList": [         {             "ownerType": "compute",             "extraSpecs": "{\"cloud_image_nativeId\":\"ed646e01-1055-4256-ad61-0934efb64505\",\"cloud_image_osVersion\":\"Euler Linux 1.4 64bit\",\"ips\":\"@192.168.65.100@\",\"cpuCoreNum\":2,\"cloud_image_name\":\"EulerOS_Cloudinit\",\"cloud_image_osType\":\"Linux\"}",             "azoneName": "manage-az",             "privateIps": "@192.168.65.100@",             "regionName": "Global",             "flavorId": "B4CE5F4320EE3AB48F9BF4799BDF31DA",             "clusterId": "CC30CD2C5BF33828B8C6B17BD98D2489",             "ownerId": "B85415D3F5C43B14B7F041CA8C3E4318",             "ramSize": "4096",             "deviceName": "activiti6",             "ownerName": "nova_az0.dc1_FUSION_CLOUD_dg-dg-1",             "clusterName": "manage-aggr",             "osType": "Linux",             "confirmStatus": "unconfirmed",             "vcpuSize": "2",             "id": "FB72F89FCC963E3EA885B0966575D56B",             "last_Modified": 1587471291521,             "podNativeId": "pod_manage-az",             "podId": "8F32491527EF3DC1ABD083CDBFB3719C",             "bizRegionId": "B998E09832BA34B4BF3A4C649C421F3C",             "imageId": "AAA42F14944139AD8A5DEBA932387ABB",             "originalState": "ACTIVE",             "ipAddress": "192.168.65.100",             "hostId": "99837AEF2D9B32D3A51DA09A8BE47F82",             "hypervisorType": "unconfirmed",             "resId": "FB72F89FCC963E3EA885B0966575D56B",  //记录此ID             "resourcePoolName": "OpenStack_dg-dg-1",             "keystoneId": "04C1343644D03924B9A957B059A689E4",             "tags": "[]",             "is_Local": true,             "class_Name": "SYS_VM",             "azoneId": "074D197A30B331A1A24DF9B76E16570C",             "regionId": "C4CA4238A0B933828DCC509A6F75849B",             "createTime": "2020-04-21T12:13:07Z",             "resourcePoolId": "E9CF706003FB3361BE20264F271000D9",             "name": "activiti6",             "isVirtual": true,             "nativeId": "b045e75c-fbdb-4a80-b97d-13d6040c2832",             "category": "VM",             "projectId": "51ec40deb84b4a279a422393d431feba",             "bizRegionName": "东莞",             "status": "active",             "resourcePoolType": "FUSION_CLOUD"         }     ],     "totalNum": 68,     "pageSize": 1,     "totalPageNo": 68,     "currentPage": 1 }这里我们可以获取管理虚拟机的资源ID，即resId。步骤3 查询管理虚拟机与子对象的关系调用方法：GET调用URL：https://{运维侧对外访问域名}/rest/cmdb/v1/instances/relations/{relationName}（relationName取值范围为第2章中的父子对象关系名，此处查询管理虚拟机与规格的关系，取值为M_VMUsesFlavor）此外，我们需要添加过滤条件，以便查询出指定租户虚拟机的规格，过滤条件书写方法为：condition=[{"simple":{"name":"source_Instance_Id","value":"FB72F89FCC963E3EA885B0966575D56B"}}]（vlaue的值为步骤2中获得的管理虚拟机的资源ID），需要注意的是该查询条件需要经过URL编码（编码格式为UTF-8），即完整的请求链接为：https://{运维侧对外访问域名}/rest/cmdb/v1/instances/relations/M_VMUsesFlavor?condition=%5b%7b%22simple%22%3a%7b%22name%22%3a%22source_Instance_Id%22%2c%22value%22%3a%22FB72F89FCC963E3EA885B0966575D56B%22%7d%7d%5d请求头：Accept:application/json Content-Type:application/json;charset=UTF-8 X-Auth-Token:xxxxxxxxxxxxx响应示例：{     "objList": [         {             "source_Instance_Id": "FB72F89FCC963E3EA885B0966575D56B",             "target_Instance_Id": "B4CE5F4320EE3AB48F9BF4799BDF31DA",  //代表子对象的资源ID，即规格的资源ID             "relation_Name": "M_VMUsesFlavor",             "id": "FB72F89FCC963E3EA885B0966575D56B",             "last_Modified": 1587471291521,             "relation_Id": 1036         }     ],     "totalNum": 1,     "pageSize": 20,     "totalPageNo": 1,     "currentPage": 1 }这里我们获得了管理虚拟机所关联的规格的资源ID（target_Instance_Id即为子对象的资源ID），按照同样的方法，可以查询得到管理虚拟机关联的镜像，网卡，磁盘的资源ID，示例如下：查询管理虚拟机与镜像关系：https://{运维侧对外访问域名}/rest/cmdb/v1/instances/relations/M_VMUsesImage?condition=%5b%7b%22simple%22%3a%7b%22name%22%3a%22source_Instance_Id%22%2c%22value%22%3a%22FB72F89FCC963E3EA885B0966575D56B%22%7d%7d%5d查询管理虚拟机与磁盘关系（注意：查询磁盘关系时，使用的过滤条件略有区别，格式为：condition=[{"simple":{"name":"vmId","value":"FB72F89FCC963E3EA885B0966575D56B"}}]）：https://{运维侧对外访问域名}/rest/cmdb/v1/instances/relations/M_VMAttachedToVolume?condition=%5b%7b%22simple%22%3a%7b%22name%22%3a%22vmId%22%2c%22value%22%3a%22FB72F89FCC963E3EA885B0966575D56B%22%7d%7d%5d查询管理虚拟机与网卡关系：https://{运维侧对外访问域名}/rest/cmdb/v1/instances/relations/M_VMConsistsOfvNIC?condition=%5b%7b%22simple%22%3a%7b%22name%22%3a%22source_Instance_Id%22%2c%22value%22%3a%22FB72F89FCC963E3EA885B0966575D56B%22%7d%7d%5d步骤 4 查询子对象详情调用方法：GET调用URL：https://{运维侧对外访问域名}/rest/cmdb/v1/instances/{className}/{instanceId}（此处className取值范围为第2章中所给出的子对象名称，即，SYS_Flavor、SYS_Volume、SYS_vNIC、SYS_Image，instanceId为子对象的资源ID，从步骤3的响应体中获取）此处以查询规格详情为例：完成的请求URL为：https://{运维侧对外访问域名}/rest/cmdb/v1/instances/SYS_Flavor/B4CE5F4320EE3AB48F9BF4799BDF31DA请求头：Accept:application/json Content-Type:application/json;charset=UTF-8 X-Auth-Token:xxxxxxxxxxxxx响应示例：{     "ownerType": "compute",     "extraSpecs": "{\"ecs:performancetype\":\"normal\",\"ecs:virtualization_env_types\":\"CloudCompute\",\"hw:cpu_mode\":\"aggregate\",\"hw:cpu_model\":\"\",\"resource_type\":\"<all-in-list> IOoptimized\",\"capabilities:cpu_info:arch\":\"x86_64\",\"huawei:extBootType\":\"Volume\",\"trust:trusted_host\":\"false\"}",     "regionName": "Global",     "ephemeral": "0",     "ramSize": 4096,     "ownerId": "B85415D3F5C43B14B7F041CA8C3E4318",     "diskSize": 0,     "ownerName": "nova_az0.dc1_FUSION_CLOUD_dg-dg-1",     "isPublic": "true",     "vcpuSize": 2,     "confirmStatus": "unconfirmed",     "disabled": "false",     "id": "B4CE5F4320EE3AB48F9BF4799BDF31DA",     "last_Modified": 1585903613086,     "bizRegionId": "B998E09832BA34B4BF3A4C649C421F3C",     "class_Id": 1049,     "resourcePoolName": "OpenStack_dg-dg-1",     "resId": "B4CE5F4320EE3AB48F9BF4799BDF31DA",     "is_Local": true,     "class_Name": "CLOUD_FLAVOR",     "regionId": "C4CA4238A0B933828DCC509A6F75849B",     "resourcePoolId": "E9CF706003FB3361BE20264F271000D9",     "name": "2U4G",     "nativeId": "599fb5b8-e04a-4db1-8535-8fa586c1ae63",     "bizRegionName": "东莞" }由此我们获得了管理虚拟机的规格信息，类似的我们可以获得管理虚拟机的镜像，网卡，磁盘详情，URL示例如下：https://{运维侧对外访问域名}/rest/cmdb/v1/instances/SYS_Image/{image_resId}https://{运维侧对外访问域名}/rest/cmdb/v1/instances/SYS_vNIC/{vNIC_resId}https://{运维侧对外访问域名}/rest/cmdb/v1/instances/SYS_Volume/{volume_resId}查询完所有子对象的详情后，我们就可以获得管理虚拟机的详细信息了

华为的老师们好因公司电脑需加域管理，我们现在的开发环境配置均为在windows上配置Ubuntu 16.04虚拟机。调试电脑的ip为10.13.112.86，现配置/home/mdc/conf/viz_address.conf文件为虚拟机以NAT模式共享主机ip连接外网，且配置由主机端口8000转发至虚拟机上mviz默认侦听的7000端口。配置如下使用例程viz_demo调试结果为虚拟机上的mviz可正常接收部署在host侧的viz_demo发布的可视化元素数据，并能转换成Rviz支持的可视化元素，发布到Rviz上。现MDC接入Entron摄像头后，按《MDC 300（F）AUTOSAR Adaptive Platform配置指南》配置相应arxml后，编写相应的程序用于发现camera服务实例及接收由hi3559发送给host并由host发布的camera数据，程序在host上可以正常执行并成功接收到camera数据，如下图。 并将接收到的camera的h265格式的rawdata直接发布或按照I-P-P-P…的形式组包成待发布的data，按照mviz的数据格式及使用相应接口发布给mviz，但mviz在接收到相应数据后报解编码错误。错误信息如下：如文档所述，mviz可以支持对h265格式的数据解编码并重新打包成标准数据发布，host侧app发布给mviz的数据需要做什么样处理吗？我处理成I-P-P-P...格式仍然无法正常解编码。平台软件版本如下：麻烦华为的老师们帮忙解答一下，谢谢！

云主机的本质就是一组集群主机上虚拟出多个类似独立主机的部分，通过云方案拟出资源池，提供按需使用的功能和加强主机的可靠性。而这个云主机的优点同时又称为了一块硬伤。以往云主机之所以使用率比不上虚拟主机，是因为大多数人认为建立网站的资源只需要高质量的虚拟主机就可以支撑了，而云主机却显得大材小用。而实际上是人们对云主机以及云计算的不了解而产生的误会，而云主机也没有大家想象中的那么万能，还有好大一段进步空间。但最近，国内云服务商都出现了相似的现象。在这几个月期间先后推出一款“精致”的云主机，配置为1核/512内存/50G硬盘/1M带宽。其实这一款云主机并不是新推出的，只要经过按需配置就可以出来。为什么一些知名的云服务商这么迫不及待走低端价格路线呢?其理由有三：1迫于国外云服务的压力，国内云主机服务商产生了危机意识与动力;2因为公有云服务的客户群体都是中小企业，他们对虚拟主机、带宽的价格指标都非常敏感，各家都希望先用低廉价格抢占公有云市场;3为后续的产品战略作铺垫。

随着移动互联网的不断发展，越来越多用户使用手机、平板等移动端进行上网娱乐和办公，所以响应式网站自然而然成为了近年来建站的主流。那么响应式网站到底是什么呢？简单来说，就是网站效果可以随着屏幕尺寸大小而自适应，不会发生变形、内容缺失的现象。不管你是在使用手机、iPad，还是电脑，页面都能自动切换分辨率、图片尺寸及相关脚本功能等，兼容多个终端，而不是每个终端做一个特定的版本。这样就能够为建站者节约大量成本和精力，建站者不必专门为新设备做设计和开发。现在想要建设响应式网站的企业和商家越来越多。好马配好鞍，一个好的响应式网站也要搭配一个好的网站空间，不然用户访问不稳定，体验不佳会丢失大量潜在客户，搜索引擎蜘蛛无法第一时间爬过你网站的内容，更是不利于网站进行收录排名。这也就有了一个疑问，我们做响应式网站应该怎样去挑选虚拟主机？1、支持主流建站开发语言 你首先要了解，网站采用哪种开发语言，常用的开发语言有ASP， .NET或PHP;2、足够大的磁盘空间响应式网站对图片质量要求非常严格，加上图片本来就比较占磁盘空间，要是随着业务需求的发展可能会上传更多的文件，安装更多的软件应用，这对虚拟主机的磁盘空间是一个很大的挑战，所以建议选择虚拟主机时拥有足够大的磁盘空间。3、具备独立IP地址做响应式网站的目的，是为了方便用户从不同的客户端访问网站，从而更好的推广网站，发展业务，使用独立IP的虚拟主机，能够更安全稳定的运营网站，并且还有助于搜索引擎优化，这也是从侧面帮助网站更好的推广和发展。目前主流的响应式网站，虚拟主机是真的可以完全hold住，满足需求的同时，还降低了运营成本。此外，选用虚拟主机，会与服务商产生密切的关系。比如像流量统计功能、可能耗用系统资源的论坛程序等一些功能受到服务商的限制。网站设计要考虑服务商提供的功能支持，比如数据库类型、操作系统等。

2020年华为全球分析师大会上，华为云CTO张宇昕介绍了华为云最新推出的华为云擎天架构，并发布由擎天架构加持的业界首家“零损耗”裸金属容器解决方案，引领云基础设施升级。Gartner最新报告显示，2019年华为云在中国IaaS市场排名前三，在全球排名上升至第六，全球增速最快。（延伸阅读：华为云全球增速最快：IaaS市场排名中国前三、全球前六）华为云CTO张宇昕表示：“ 历经八年技术积淀的擎天架构，正是驱动华为云稳健增长的关键动力源之一。基于擎天架构的云基础设施，实现了全场景的一致体验与生态，为客户提供最优算力、极致效能、稳定可靠的云。华为云通过持续不断的技术创新，成为政企智能升级的首选，智能世界的黑土地。”华为云CTO张宇昕解读华为云擎天架构云边端全场景，擎天架构全搞定擎天架构由华为历时八年打造，从2012年启动预研，2014年构建软硬协同系统，2017年应用于华为云，由500+专利加持、10万+节点打磨，实现了“业界最早支持共享存储的裸金属服务器”、“业界首个千万级PPS转发实例”、“业界首家40G带宽裸金属服务器 ”等多项创新突破，持续业界领先。大会现场，张宇昕进一步分享了擎天架构的最新实践——业界首发基于擎天架构的“零损耗”裸金属容器解决方案，网络性能提升40%、用户成本降低30%，致力为社交资讯、视频、基因等行业提供最高性价比选择。 华为云擎天架构包含数据面“软硬协同系统”和管控面“智慧云脑”两部分。其中，数据面从极简数据中心、多样性算力、擎天系列卡、极速引擎、极简虚拟化五个维度进行软硬协同创新，实现计算、存储、网络、安全的全卸载与加速能力，并已全面支持虚拟机、裸机与容器；智慧云脑作为面向云、AI、5G时代的分布式云操作系统，依托全域调度能力实现云边端的协同与治理。立地擎天，引领云基础设施升级基于擎天架构带来的云基础设施升级，主要体现在四个方面：01稳如预期、性能超群性能“零”损耗、管理资源“零”开销、客户业务“零”抖动，并提供低至100μs存储时延、10μs网络时延；02多样性算力，智能化匹配擎天架构可快速实现将多样性算力于云端释放，并为业务负载智能推荐最佳算力；03极致效能，尽享潜能擎天架构让算力100%可使用，且虚拟机、裸机、容器共资源池的能力，可帮助客户在华为云Stack场景大幅提升资产利用率；04云边端协同，全场景一致体验基于擎天架构，华为云提供业界最完整的边缘解决方案，覆盖现场、近场边缘，让算力无处不在，为应用提供极致的时延。未来，华为云将继续发挥全栈数据中心级技术创新，与伙伴一起使能千行百业，助力实现数字化转型和智能化升级。

1       软硬件配置类别子项版本 硬件CPU鲲鹏920网络1822网卡存储SATA 4T内存--OSCentOS7.7Kernel4.18.0-80.7.2.el7.aarch64   2       组网配置不涉及                                    3       问题3.1       问题描述：编译安装qemu-4.2.0后，使用qemu安装OS时，使能--enable-kvm后卡主，不使能--enable-kvm则能正常进入安装界面1）使能--enable-kvm的安装命令，安装后卡主：qemu-system-aarch64  -bios /home/QEMU_EFI.bios -M virt -m   8G  -cpu host --enable-kvm  -cdrom   /home/OS/CentOS-7-aarch64-Everything-1810.iso –nographic –curses2）不使能--enable-kvm的安装命令，安装后能正常进入安装界面：qemu-system-aarch64 -bios QEMU_EFI.bios   -M virt -m 8G -cpu cortex-a57 -cdrom   home/OS/CentOS-7-aarch64-Everything-1810.iso -nographic -curses编译qemu-4.2.0wget   https://download.qemu.org/qemu-4.2.0.tar.xztar -xf qemu-4.2.0.tar.xzcd qemu-4.2.0./configure –prefix=/usr/local/qemu-4.2.0make -j 16 && make install 3.2       问题分析：1.尝试在启动命令中添加串口输出-serial file:/tmp/serial.out，发现串口无任何输出，串口参数设置参考：http://blog.sina.com.cn/s/blog_a1e6528101019xmm.html2.换到CentOS7.6操作系统执行同样命令，发现有coredump报错:qemu-system-aarch64: PMU: KVM_SET_DEVICE_ATTR: Invalid argumentqemu-system-aarch64: failed to set irq for PMUAborted (core dumped)找到解决办法https://vanducuy.wordpress.com/2019/09/09/qemu-install-fedora-28-on-aarch64-failed/，需要添加-machine gic-version=33. 换到CentOS7.7上添加-machine gic-version=3，成功进入安装界面，问题解决3.3       问题结论：CentOS7.7上进程无法coredump，在CetnOS7.6上执行coredump，根据报错发现需要指定GICV3的版本，添加-machine gic-version=3选项后解决。

1      软硬件配置类别子项版本 硬件CPU鲲鹏920网络Ethernet-GE存储SATA 4T内存--OSCentOS7.6Kernel4.14.0-115.el7a.0.1.aarch64软件virt-manager--qemu--libvirt--2      组网配置不涉及                                     3      问题3.1      问题描述：执行virt-manager 拉起qemu-kvm图形管理界面，执行命令后没有任何反应，也没有报错 3.2      问题分析：1）执行virt-manager -h查看帮助选项 2）执行virt-manager -debug查看打印，发现有错误Gtk:ERROR:gtkiconhelper.c:494:ensure_surface_for_gicon:   assertion failed (error == NULL): Failed to load   /usr/share/icons/Adwaita/24x24/status/image-missing.png: Fatal error reading   PNG image file: Not enough compressed data (gdk-pixbuf-error-quark,   0) 3）Not enough compressed data压缩这块有问题，排查系统之前有编译安装zlib源码，进入zlib编译安装目录执行make uninstall卸载后，再次执行virt-manager恢复正常 3.3      问题结论：通过virt-manager -debug查看错误打印定位到压缩有问题，排查系统之前有编译安装zlib源码，进入zlib编译安装目录执行make uninstall卸载后，再次执行virt-manager恢复正常。