本文分享自华为云社区《[传统微服务框架接入Istio方案详解](https://bbs.huaweicloud.com/blogs/337177?utm_source=zhihu&utm_medium=bbs-ex&utm_campaign=other&utm_content=content)》，作者：香菜聊游戏 。 # 微服务的概念和原理 ## 微服务带来的问题 **微服务带来的好处：** 解耦了业务，解耦了代码和架构，业务更紧凑，逻辑更单一简单。 **微服务带来的问题：** 在早期的时候，使用单体架构，所有的业务都在一个服务内，没有跨进程和网络上的一些复杂度。 微服务化之后引入的问题包括如何做服务发现，怎么做负载均衡，包括服务间的访问保护，例如熔断，故障定位等等问题。 在故障定位时，在原来单体服务下只需要看下日志，但是微服务化之后需要借助分布式调用链工具，这无形中带来了开发和定位问题的复杂度。  **微服务和lstio网格架构对比**  微服务框架我们了解比较多的Spring cloud 或者国内用的比较多的Dubbo，框架本身就不多介绍了，我想大家都有所了解。 原理就是提供了开发的SDK或者说叫框架，这些框架都是内置了一些解决微服务问题的方案，比如服务发现，负载均衡，服务的熔断和降级，以及调用链路的埋点，动态路由这些事情。 下图是一个典型的用法，也是应用非常广泛的用法  基于网格的治理是近些年应用比较多的，从上图可以看出，虽然基于网格的治理提供的能力和上图的基于sdk的能力一样，但是两者的设计原理，使用场景，设计理念是不同的。 # 详细介绍 ## 服务发现和负载均衡  上图是传统的微服务框架的原理 一般的流程是： • 服务启动的时候向服务中心进行注册 • 调用的时候先从服务中心获取后端服务的地址 • 选择一个实例发送请求，等待回复  服务网格的工作原理： 服务网格一般和k8s结合使用，因为k8s 本身做了服务的endpoint 维护，所以lstio不需要做服务注册，只需要做服务发现。 看下详细的区别  **服务熔断**  服务熔断的机制： 如果一个服务在配置的一段时间内一直不可用，可以通过熔断机制，把服务隔离开，接触不到流量，进入到半熔断状态， 如果在一定的考察时间段能够恢复正常，熔断状态就会关闭，如果还是不能正常，会继续进入到熔断状态。  # 传统微服务框架的问题和基于服务网格的解决方案 **问题1：微服务SDK的多语言问题**  上面这张图示意了微服务的之间的关系，一些大的客户拥护大的系统，系统由多个服务组成，服务可能由多种语言开发。 比如系统中可能有go服务，C++服务，python服务以及spring cloud 服务等等，这是一种比较常见的情况。 在这些服务中想做一个通用的服务发现时，但是Spring cloud或者Dubbo开发的服务，有一套自己的服务发现机制，但是不同语言开发的服务之间发现框架是不同的，比如go服务开发的服务不可能去spring cloud的服务中心注册，这个问题没办法解决。 比较粗暴的解决办法是对其他语言的项目用Java重构，在项目不复杂的情况下是可以接受的，但是在系统业务比较复杂，需要修改的项目比较多的情况下是无法接受的，不仅需要大量的人力，还要花费大量的时间，服务的稳定性没法保证。  服务网格的解决方案下，服务发现是业务解耦的，不管是什么语言开发的服务，因为proxy不需要参与编译，网格之间只需要开放端口，并且保持可以访问，在这种方案下，不需要修改原来代码，减少了开发量，是企业可以接受的。 **问题2：基于sdk的服务在k8s下出现延迟和数据不一致**  在上图这种情况下，Consumer服务原来在pod1 上，后来由于调度问题，导致Consumer服务迁移到pod2 上，正常情况下pod1 需要注销，pod2 进行重新注册，但是如果pod 迁移比较频繁，导致Producer 在访问Consumer服务的时候仍然拿到老的注册地址，就会出现延迟和数据不一致的情况。  **问题3：基于SDK逻辑开发的服务升级必须重新编译**  基于SDK开发的逻辑代码进行升级的时候，必须重新编译所有基于SDK开发的服务，这个升级会带来大量的工作量，SDK的升级过程必须要和业务团队一起升级，非常耗时。产生的需求就是如果业务代码没有改变的情况下不需要重新编译。  使用网格的解决方案下，如果业务没有修改是不需要进行编译和修改的，对开发人员和运维来说是非常友好的，同时降低了运维的风险，毕竟任何改动都是风险。 **问题4：基于SDK开发，统一发现和治理能力，需要全部改造**  如果对一个单体应用进行微服务化，一般是渐进微服务化，比如上图，一般先对svc1进行微服务化，然后再对svc2 进行微服务化，在开发的过程中需要仍然访问互通，但是使用SDK的微服务有时需要使用同一框架，同一版本才能进行通信交互，这就是痛点。  在使用网格的情况下，第一步先对svc1进行微服务化，svc2不改动，在开发的期间仍然不影响原来的访问。 # 传统微服务框架在服务网格中集成的实践详情 **总体思路**  卸载SDK的服务发现和服务治理的功能，将这些功能迁移到基础设施上，让用户从这些中解脱出来，只专注于自己的业务代码。 **解决方案**   传统微服务的发现是注册到注册中心 在使用网格之后，平台同一服务发现，使用kube-proxy进行服务发现和负载均衡，Kube-proxy 直接返回服务的ip和端口，这样的话就消除容器环境下服务发现数据不及时的问题。 在使用k8s做服务发现，再使用网格的能力，服务完全无需修改适配 **Spring cloud项目的改造**  在原来的配置中，取消对注册中心的注册，改为直接使用服务名:端口进行访问，直连的这种方式会被k8s 进行转发，对业务代码无需修改，减少了工作量。 注意：**要和访问的服务保持协议一致。** **移除spring cloud 的项目依赖**  **微服务网关的改进**  情况1：微服务网关有业务逻辑 写了很多自定义的逻辑，比如filter的过滤等等，这种情况下网关可以作为普通的微服务部署在网格内。 情况2：微服务只有通用逻辑能力 直接用Ingress进行替换，进行地址映射，路径映射等基础能力，移除原来的网关。 **集成微服务注册中心到网格** 由于有些项目开发架构自成体系，不太适合直接排除原来的基础能力，在这种情况下想使用网格的能力，需要把原来的注册中心导入。Istio从微服务的注册中心导入注册数据，并且转换格式存储，在这种情况下依然可以配置相同的治理规则。  # 总结 使用k8s和lstio网格进行开发，将服务发现，服务治理留给基础设施，可以将开发人员从复杂的服务中解脱出来，专注于业务开发，是当前来说比较好的解决方案。 视频地址：https://education.huaweicloud.com/courses/course-v1:HuaweiX+CBUCNXI055+Self-paced/courseware/511f6f06d97d4aaf9b90445dca5800d1/c08eb6fa0dd14a34bd617c6beb63a923/

背景：鲲鹏920+ubuntu18.04.1+GPU在获取robox搭建指南后，按照文档操作，发现getprop | grep sys.boot.completed执行与文档中预期不符，且容器无法进行连接，通过ardc远程无画面输出，在咨询ARM原生专家后，通过专家建议，对环境进行如下基本检查：1、检查xorg.conf中的BusID是否正确。2、Xorg是否启动正常。3、环境变量DISPALY是否存在，且与robox脚本中变量设置一致。4、环境变量XDG_RUNTIME_DIR是否存在。5、是否进行转码使能。通过对环境的排查，发现有两个问题：1、转码使能未开启，由于环境为鲲鹏920设备，一定要转码使能之后才可正常启动docker容器2、自行编译的镜像存在问题，导致容器启动失败，通过使用文档中的测试镜像，可正常启动。在处理上述两个问题后，通过robox启动脚本，容器正常启动，getprop | grep sys.boot.completed执行结果与预期一致，宿主机能出画面，但通过ARDC远程连接一直显示waiting for device关于ARDC远程连接一直显示waiting for device的问题，在咨询ARM原生专家后，发现是adb的版本过低，在替换了ARDC高版本后，可正常接出画面

接触AOC以来，我一直很好奇AOC（Agile Open Container）该怎么理解呢？现在终于有些眉目啦，与大家分享~ Agile即敏捷。敏捷顾名思义，就是快速而精准。快速，体现在割接搬迁中，做到三个1。         1个星期原型：AOC内置了主流厂商的设备驱动。         1个月POC（Proof of Completion）：AOC降低了开发的门槛，乐高式编程，快速测试验证。         1个季度交付：业务包可以在线加载，甚至不用重启和升级NCE。精准，体现在网络运维质量的提升。        某公有云现网管理中，涉及10万余台设备，存在几代的存量网络架构，和超过50个软件版本，每天都有上百次设备上线、线路扩容、BGP peer对接等操作。变更风险非常大，质量风险特别高，每天晚上都需要投入20余人参与变更以及相关质量的维护工作。过去，该公有云的变更，主要由python硬编码的方式实现，过程非常复杂，而且需求的传递容易导致错误。与AOC联合打造模型驱动的变更自动化平台后，由AOC负责最核心的模型管理和模型翻译工作，并北向与公有云的编排平台对接，支持公有云的网络工程师以拖拉拽的方式，独立完成变更场景的编排，业务开发效率非常高。同时网络变更自动化过程中自动回退能力，是变更的核心诉求。AOC能基于网络正向配置，自动生成网络回退命令行，避免了人工设计产生错误的可能，大幅提高变更工作的质量。 Open即开放。开放，就是把自主开发、自主定义的可能性，最大限度地开放给客户自己。有能力的客户：AOC支持客户拿着这个系统完全自主编程、自行定义业务需求。有标准的客户：客户定义企标并进行集采，华为来编程，提供敏捷交付。有预算的客户：华为和专业服务一起，ISPA+AOC合作提供开发和集成能力。 Container即容器。AOC由SSP, SND两部分组成。SSP就像夹娃娃机里悬在上空的夹子， SND则对应着各种厂商、各种版本的设备，就像玻璃容器中的众多娃娃。客户业务方面的意图和需求，从SSP这里传递进来，通过Yang+Python+Jinja协作的方式操纵这个夹子，在容器中选择自己想要的模板。在容器中，每个娃娃互相独立。海外多厂商设备共存，multivendor的问题则迎刃而解；设备升级时，不同版本产生的不兼容问题，则通过SND domain id，实现模型隔离，和数据存储隔离。结合业务数据影响分析工具，实现差异屏蔽、平滑升级。

强化学习算法控制核聚变登上Nature：DeepMind让人造太阳向前一大步     DeepMind 和瑞士洛桑联邦理工学院 EPFL 一直在进行一个神秘的项目：用强化学习控制核聚变反应堆内过热的等离子体，如今它已宣告成功。DeepMind研究科学家David Pfau在论文发表后感叹道：「为了分享这个时刻我已经等了很久，这是第一次在核聚变研究设备上进行深度强化学习的演示！」可控核聚变、强人工智能、脑机接口是人类科技发展的几个重要方向，有关它们何时可以实现，科学家们的说法永远是「还需几十年」——面临的挑战太多，手头的方法却很有限。那么用人工智能去控制核聚变，是不是一个有前途的方向？这个问题可能需要由提出 AlphaGo 的 DeepMind 来回答了。最近，EPFL 和 DeepMind 使用深度强化学习控制托卡马克装置等离子体的研究登上了《自然》杂志。首先，我们来思考一个问题：为什么要用人工智能控制核聚变？托卡马克是一种用于容纳核聚变反应的环形容器，其内部呈现出一种特殊的混乱状态。氢原子在极高的温度下被挤压在一起，产生比太阳表面还热的、旋转的、翻滚的等离子体。找到控制和限制等离子体的方法将是释放核聚变潜力的关键，而后者被认为是未来几十年清洁能源的源泉。在这一点上，科学原理似乎是说得通的，剩下的就是工程挑战。参与该研究的瑞士等离子体中心（SPC）主任 Ambrogio Fasoli 表示：我们需要能够加热这个装置，并保持足够长的时间，以便我们从中吸取能量。在同样由聚变驱动的恒星中，仅依靠引力质量就足以将氢原子拉到一起并克服它们的相反电荷。在地球上，科学家们改为使用强大的磁线圈来限制核聚变反应，将其推到所需的位置。这些线圈必须仔细控制，以防止等离子体接触容器本身：这会损坏容器壁并减慢聚变反应。 但每次研究人员想要改变等离子体的配置并尝试不同的形状，以产生更多的能量或更纯净的等离子体时，都需要大量的工程和设计工作。传统的系统是由计算机控制的，基于模型和模拟，但 Fasoli 表示传统方法「复杂且不一定能起到优化的作用」。DeepMind 控制团队负责人 Martin Riedmiller 表示：「人工智能，特别是强化学习，特别适合解决托卡马克中控制等离子体的复杂问题。」DeepMind 在论文中详细介绍了所提的可以自主控制等离子体的 AI。论文地址：https://www.nature.com/articles/s41586-021-04301-9

在KubeCon2021上，中国工商银行软件开发中心云平台架构师沈一帆和华为云云原生开源负责人王泽锋发表了《与Karmada一起航行：海量节点的多集群管理》专题演讲，分享了工商银行多k8s集群管理实践过程。*Karmada项目介绍部分由王泽锋分享，其余部分的分享来自沈一帆工行云平台的建设现状工行目前的业务上云场景是丰富多样的，既有以春节红包等支付线为代表的核心业务类应用，也有以MySQL、Redis为代表的技术支撑类应用，也包含了区块链、人工智能等新技术领域。目前工行云平台也是基于主流的开源项目进行了深度的定制化研发，保证了整体的自主可控性。从建设情况来看，也是同业最大规模的一个容器云，目前数量达到了28万+。典型业务需求及云原生基础设施现状在大规模的云原生基础设施的背景下，工行的业务对我们提出的具体的要求以及目前的现状。典型的业务需求主要包含以下几类：业务需要高可用的部署、应用需要跨集群地进行弹性伸缩以及跨集群的调度，一些业务产品需要对K8s版本有特定的一个依赖。基于以上情况，工行目前的云原生基础现状如下：单集群可靠性要求比较高。我们整体的单集群的节点数量在2000以下，就是为了缩小集群的一个故障率影响范围。资源池随业务快速增长。目前新业务应用是全面上云，存量应用是持续地迁移入云，现在核心应用已经全部入云。业务级异构集群。业务对特定的K8s版本有依赖，并且有大量的异构的CNI、CSI、包括底层一些硬件异构。多地、多中心、多云的建设现状，工行业务上包括总行云、分行云，生态云等。故障域方面是两地三中心的数据中心建设，并且在数据中心内部也有多故障域方面更细粒度的划分。基于此，工行内部的K8s集群数量其实已经达到了100个以上，目前由容器云平台统一纳管管理。但在持续发展的过程中，我们也面临着以下问题：可用性受限，因为K8s集群本身也是一个故障域，目前缺少跨故障域自动恢复。资源受限，整体的应用的调度和弹性伸缩受限于单集群。集群不透明：由于集群目前都打上了异构、故障域等属性，业务团队需要感知底层的集群去自主选择K8s集群，就导致了K8s集群本身是对上层应用是不透明的。重复配置。尽管我们的业务统一在云管平台进行了配置的录入，但具体的配置需要下发到各个集群当中，且各个集群需保证同步。面对这些挑战，我们对多集群的管理拟定了设计目标：在多集群管理平面方面：集群纳管和对集群有整体生命周期管理，并且具有统一标准的API入口。在资源管理方面，需要支持多版本全面的K8s资源，同时也需要多维度的资源Override支持。在跨集群自动调度方面，调度上需要按故障域、资源余量等进行自动调度，并且可跨集群自动伸缩。容灾方面，需要进行跨集群资源的自动恢复，并且管理平面与业务集群需要解耦。兼容性方面，对存量大量的异构集群需要平滑的纳管，同时项目本身需要高扩展性及社区的活跃度。联合创新有了清晰的设计目标，接下来就是如何实施落地了。首先对于商用产品，考虑到单一厂商的绑定和不符合自主可控的要求，首先被我们pass，而调研kubefed之后，发现它使用非原生API，对于我们存量集群来说迁移难度过大，且近期社区活跃度下降。最后我们选择以最贴合我们需求的方式，立足自身进行联合研发，同时工行金融云本身也是基于开源，所以我们也是积极地投入到开源共建，推动社区发展这个良性循环中来，最后选择联合发起karmada项目。那可能有人会问，为什么不在原有KubeFed的基础上继续演进，而是发起一个全新的项目呢？实际上我们在项目的初期考虑的确实是Kubernetes Federation的V3版本，并且很快地完成了原型的开发。然而在后来与许多的社区用户的交流过程中，我们发现其实狭义的Federation的项目范围并不能完整地覆盖大家期望提供的能力版图。除了Federation本身包含的多集群应用负载管理的能力之外，其实我们重点还希望去提供像多集群的资源调度、故障迁移、自动伸缩，以及像多集群的服务发现、数据自动化和多平台支持的集群的生命周期管理等等，为用户真正地去提供开箱即用的多云多集群的开源软件站。因此一个托管于 CNCF的中立的开源项目，会更适合于长期的技术演进和社区发展。Karmada 项目Karmada的核心架构在Karmada的核心架构方面，吸取了多家社区发起单位在多集群管理上的经验和心得，我们把重点放在了K8s原生API支持、以及框架可扩展性上。与K8s单集群架构略有相似：Karmada 的控制面拥有自己独立的APIserver，来提供K8s原生API以及Karmada的扩展API通过Karmada Scheduler，提供针对 [故障域、集群资源、K8s版本及集群开启插件等多维度、多权重的]调度策略支持，并方便用户自定义扩展与member集群的同步方面，Karmada Agent的pull工作模式，可以有效分散控制面压力，实现超大规模多集群资源池的管理。同时，Karmada还支持ExecutionController以及集成KubeEdge方式实现对位于公有云、私有云以及边缘等各种网络环境中K8s集群的直接管理。而借助ExecutionSpace的设计，Karmada实现了不同集群之间的访问权限和资源隔离，来满足多集群场景下的安全性需要。 Karmada 核心概念在Karmada核心概念的设计方面我们把用户输入的一切工作负载相关资源对象定义为Resource Template，这是严格的K8s原生API，支持包括deployment，service，configmap等，以及用户自定义的CRD资源对象。这样，用户无需任何修改，就可以直接使用原有单集群的YAML或者API来创建多集群应用，而原本在K8s之上二次开发的业务平台也不用做任何的修改。针对应用跨多集群的拆分和调度，扩展的Propagation Policy支持被多个应用复用的定义。得益于这种解耦的设计，在像工行这样独立设置平台团队和业务团队的场景中，平台团队可以针对通用的高可用部署模型设置策略，而业务团队则可以继续使用K8s原生的单集群API来管理日常的业务上线和版本升级。下面我用一个例子来说明用户是如何使用Karmada管理他们的业务零改造：使用原生API部署一个3AZ高可用的应用在这个例子中我们可以看到，其实首先是一个Propagation policy。在这个Propagation policy的定义中，平台团队设置了 Resource selector，限定所有的Deployment，如果它带有特殊的Label，HA mode为Multi zone replication，则把这些应用严格地分发到三个Zone里面去。而右边就是我们所熟悉的一个标准的 Deployment的 API的定义。通过组合这两个定义，其实我们可以看到平台团队聚焦在了通用的应用部署的模型的设置上，而业务团队聚焦在了它本身的应用内部的如Image、版本，以及像这些 Container port等等的定义上面。而Karmada负责将两个团队的需求做结合，实现应用的跨区域的高可用。在任何底下集群出现故障的情况下，可以通过动态的调度能力，自动地去补齐缺失的集群或缺失的可用区的应用实例，来实现跨集群的故障迁移。实践心得在Karmada设计研发实践再设计研发的正向循环的过程中，工行也总结了一些它的优势，也可以说是心得。主要分以下四类：资源调度、容灾、集群管理和资源管理。那么其中我认为尤其值得关注的是以下三点，那么在真实落地的过程中也显得尤为得突出。支持多种资源的绑定调度，这保证了业务节点所需的k8s资源能够同时调度，也大大提升了我们资源发放的实时性。支持k8s原生对象，这保证了我们大量的目前的k8s外部客户端几乎无需改造。Karmada目前支持Pull和Push模式分发，适配了多种场景。尤其在我们大规模集群数量的一个场景下，使用Pull模式能大大减轻Karmada控制平面性能压力。后续计划在大规模生产落地方面，我们希望容器云平台将来是作为面向用户的一个平台，底层基于Karmada统一管理多集群的资源和调度，以此去纳管存量包括异构集群在内的100+的k8s集群。在社区贡献方面，我们希望持续地进行社区贡献。主要关注的特性包括存量应用的平滑迁移，能够自动纳入到Karmada联邦化。在跨集群伸缩、应用迁移与数据联动方面，继续持续地进行优化和落地。欢迎大家访问Karmada项目的GitHub，查看Release note和社区文档，了解更多的功能和细节。如果在使用Karmada的过程中有任何建议和反馈，欢迎加入社区群和我们交流与讨论！附：Karmada社区技术交流地址项目地址：https://github.com/karmada-io/karmadaSlack地址：https://karmada-io.slack.com

【功能模块】1.容器化构建——达到充分利用资源。，，这里没有理解2.还有“全局共享缓存”能力，，是指任务成功后可以“构建包下载”吗3.编译构建支持增量构建吗，，是指在源编译构建任务中可继续添加构建原子吗【截图信息】

背景：       容器业务中需要访问到某些静态文件，如鉴权文件、图片、前端静态资源等，直接将静态文件打包至容器中会导致容器臃肿，尤其是多负载需要共享这些资源时，每个容器中都需要配置这些文件，从而降低整体业务迭代更新速度。那CCE中有没有方法可以保持容器轻量化的同时，保证容器业务也能正常运行呢？解决方式：方案一：配置存储类型为HostPath模式       这种方式是一种常见的处理方案，其原理就是将这些静态文件配置在宿主机的某个目录，然后通过k8s中HostPath模式，将宿主机的路径挂载到容器的某个具体的目录下，实现两个目录间资源文件的共享。CCE中也支持这种配置方式，具体配置方式是：1）远程登录CCE Node节点，将静态文件上传至虚拟机的某个文件目录，如/tmp/front。2）起负载，并配置文件的挂载路径，如挂载至容器的/mnt/test目录3）配置亲和性。因为静态资源上传时只上传到了容器的部分节点，需要保证负载启动时运行在静态文件上传的那个宿主机节点，因此需要配置负载和节点的亲和性策略。4）配置完成后，启动容器，即可在容器中访问到这些文件。方案二：配置云端持久化存储       持久化存储是一种共享存储的概念，不仅能实现容器和宿主机之间文件数据的共享，而且能更加完整的保存应用运行的状态数据，便于应用恢复。云端通过插件机制完成共享存储的对接，以对象存储卷为例，看看云端持久化存储如何进行配置。1）首先需要创建对象存储卷。2）将静态文件上传至OBS对象存储桶。文件较大时建议通过OBS Broswer+进行上传。3）上传完成后，在CCE负载中配置挂载持久化存储。在负载中选择更新升级》高级设置》数据存储》云存储，点击天际云存储，选择对象存储，输入挂载至容器中的路径，如/mnt/test4）挂载完成后，点击提交，即可在容器中访问到这些静态文件。两种方案对比：方案一：优点是文件读取的性能较高，配置方式简单；缺点是需要设置节点亲和性；方案二：优点是pod的创建不依赖于某一个固定节点，文件配置、修改都较方便；缺点是通过插件对接了后端的存储服务，存在网络IO的消耗，存在性能问题。

基线已集成设备园区基线预集成的设备IO包含：基线设备IO、连接实验室认证扩展IO。当对应设备接入园区时无需开发任何代码，可直接接入使用。基线设备IO：随基线版本一起安装，订购园区基线后默认安装好，如表1所示。连接实验室认证扩展IO：IO扩展包随基线版本发布，但默认不安装，项目可根据需要选装，如表2所示。扩展IO详情见连接实验室认证扩展IO。基线设备IO这部分设备IO随基线版本一起安装，订购园区基线后默认安装好。表1 基线设备IO条数分类设备IO“统一设备服务”端对应的设备规格1保安系统设备门禁设备IOAccessControl2泄露电缆设备IOLeakyCable3人行闸机设备IOTurnstile4消防系统设备消防烟感设备IOSmokeDetector5消防温感设备IOTemperatureSensor6消防手报设备IOManualFireAlarmActivation7声光报警设备IOAcoustoOpticAlarm8消防栓按钮设备IOFireHydrantButton9可燃气体探测器设备IOCombustibleGasDetector10能耗系统设备水表设备IOWaterMeter11电表设备IOElectricMeter12燃气表设备IOGasMeter13资产管理设备新基点IoT射频识别标签设备IORFID14新基点IoT射频识别读卡器设备IORFIDReader15环境监测设备户外环境监测设备IOOutdoorEnvSensor16室内环境监测设备IOIndoorEnvSensor17建筑BA设备空调机组设备IOAirHandleUnit18新风机组设备IOPreCoolingAirHandlingUnit19送风机设备IOSupplyAirFan20排风机设备IOExhaustAirFan21冷机设备IOChiller22冷冻水泵设备IOChillerWaterPump23冷却水泵设备IOCoolDownWaterPump24冷却塔设备IOCoolingTower25冷源补水箱设备IOColdSourceSupplyTank26冷源补水泵设备IOColdSourceSupplyPump27冷冻水总管设备IOChilledWaterMainPipe28冷却水总管设备IOCoolDownWaterMainPipe29管道设备IOMainPipe30膨胀水箱设备IOExpansionTank31蓄冷罐设备IOColdStorageTank32电热锅炉设备IOElectricBoiler33锅炉热水泵设备IOBoilerHotWaterPump34供热水泵设备IOHeatingWaterPump35排水泵设备IODrainagePump36生活水泵设备IODomesticWaterPump37集水井设备IOSumpPit38生活水箱设备IODomesticWaterTank39减压阀设备IOPressureReliefValve40室内照明控制器设备室内照明控制器设备IOIndoorLightingController41厕位检测设备厕位检测设备IOToiletPositionDetector42工位检测设备工位检测设备IOWorkStationDetector43升降电梯设备升降电梯设备IOElevator44电梯群控器设备电梯群控器设备IOElevatorClusterController连接实验室认证扩展IO这部分设备IO扩展包随基线版本发布，但默认不安装，项目可根据需要选装。表2 连接实验室认证扩展IO条数分类设备IO“统一设备服务”端对应的设备规格1电气火灾监测系统设备故障电弧探测器设备ArcFaultDetectionDevice2电气火灾检测系统探测器设备ElectrFireMonitorSysDetector3消防电源监控系统设备FirePowerMonitorSys4照明系统路灯设备StreetLight5室外景观照明设备OutdoorLandscapeLighting6室内多回路照明控制器设备IndoorMultLoopLightingController7环境空间监测系统震动传感器设备Vibrating8GPS定位器设备GPSLocator9智能手环设备SmartBand10垃圾桶设备Trashcans11擦手纸余量检测设备TissuePaper12厕纸余量检测设备ToiletPaper13客流统计设备PassengerFlow14多媒体点评器设备Evaluator15洗手液余量检测设备SoapDispenser16井盖检测器设备ManholeCoverDetector17路灯显示屏设备StreetLightDisplayScreen18激光探测器设备LaserDetector19应急指示灯设备EmergencyLamp20水文监测系统水位水质监测设备WaterQualityMonitoring21水文监测设备HydrologicalTelemetery22能耗管理系统能耗管理系统设备EnergyConsumption23智能水表设备SmartWaterMeter24热量表设备HeatMeter25冷量表设备CoolCapacityMeter26火灾自动报警系统报警主机设备AlarmHost27入侵报警系统电子围栏设备ElectronicFence28门磁探测器设备ElecLockDetector29报警主机防区设备AlarmHostDefenceArea30环境空间告警系统管线甲烷气体探测器设备PipelineCH4Detector31管线硫化氢气体探测器设备PipelineH2SDetector32管线温湿度探测器设备PipelineTempAndHumidityDetector33管线压力探测器设备PipelinePressureDetector34管线氧气气体探测器设备PipelineO2Detector35紧急按钮设备EmergencyButton36温湿度监测设备TemperatureHumidity37管道流量监测设备PipelineTrafficMonitoring38液压检测设备HydraulicPressureDetector39水浸检测设备WaterImmersion40液位检测设备LiquidLevelDetector41CH探测器设备CH4Detector42红外探测器设备InfraredDetector43一氧化碳探测器设备CODetector44氨气探测器设备AmmoniaDetector45空气质量探测器设备AirAualityDetector46地埋侧循环泵设备BuriedSideCirculatingPump47定压水泵设备ConstantPressurePump48水处理仪设备WaterTreatmentInstrument49地源热泵机组设备GroundSourceHeatPumpUnit50锅炉补水箱设备BoilerSupplyTank51二次水循环泵设备SecondaryCirculationPump52消防监测系统消防栓监测设备HydrantDetector53消防管道监测设备FireControlPipeDetector54BA400V进线设备InLine400V5510kV进线设备InLine10kV56400V出线设备OutLine400V57电力变压器温控器设备TransformerTempController58交流电通断检测器设备ACDetector59空气断路器设备AirCircuitBreaker60电箱温度传感器设备TempDetector61母联设备BusTieSwitch62电容器设备Capacitance6335kV出线设备Capacitance64主变压器设备MainTransformer6510kV出线设备OutLine10kV66站变设备StationTransformer67110kV分段设备Subsection110kV68直流屏设备DirectCurrentPanel69110kV进线间隔设备IncomingLineInterval110kV70双电源转换开关DualPowerSwitch71TV监控设备TVMonitoringDevice72母线保护设备BusbarProtection73光伏发电设备PhotovoltaicGenerator74柴油发电设备DieselGenerator75电动天窗电动天窗设备PowerSunroof76电梯及扶梯扶梯设备Escalator

### 概述  上图即为整个CM的配置逻辑。下面将介绍如何使用拖拽式的画布配置CM通讯。 ------------ ## 场景一：配置一对通讯的收发节点 ### 一、创建拖拽式工程  *图1.1*  *图1.2* 1）按照图1.1的操作即可创建拖拽式工程。 2）展开工程即可看到如图1.2所示，将画布分为四个部分，分别为：应用设计、系统设计、软件部署、服务实例。进入到各个画布即可创建和设计该画布内的autosar元素。 ------------ ### 二、DataType画布  *图2.1*  *图2.2* 1）在该画布内可设计数据结构。如图2.1中1部分所示，可自定义一些基本数据类型。通过第2部分创建结构体（Structure）和结构体内的元素（Element）。第3部分为快捷创建方式，如果工程内已经导入平台提供的基础数据的arxml文件，那么可通过该部分快速地在结构体内创建基础数据类型（会对平台基础数据进行引用）。第4部分可创建枚举类型数据。 2）如对图中MyStructure内的element并未引用任何值。按图2.2操作所示即可完成引用。 ------------ ### 三、ServiceInterface画布  *图3.1*  *图3.2* 1）该画布可完成ServiceInterface的创建，通过属性栏可完成对ServiceInterface的shortName和NameSpace的设定。如图所示，可完成对ServiceInterface的通讯方式的设定，包括：event、field、method。通讯方式中需要设定所传输的数据类型，也就是在DataType中设定的。 ------------ ### 四、SwComponent画布  *图4.1* 1）该画布可创建SwComponent，并在上面创建P/Rport。 2）通过属性栏设定port所引用的ServiceInterface，如果Pport和Rport之间所引用的ServiceInterface相同，则会在两者之间出现连线。 3）当Pport和Rport所引用的ServiceInterface都为空时，采用contract创建两个port之间的连线的时候。会出现弹窗，选择serviceInterface，并设置到两个port上。 4）当Pport上已经设置了serviceInterface，再用contract连接Pport和Rport时，会直接将ServiceInterface设置到Rport上。 5）如图，设定了两个SwC，一个作为服务端（Server）提供Pport，一个作为接收端（Client）提供Rport。分别作为通讯节点的发端和收端。 ------------ ### 五、MachineDesign画布  *图5.1* 1）通过该画布可以创建MachineDesign（Connector、Discovery）和EthernetPhysicalChannel（Endpoint）。并且在Endpoint上完成对ipV4、mask和MulticastIp的设定（单播地址和多播地址）。 ------------ ### 六、ModeDeclarationGroup画布（为SM部分，与CM无关）  *图6.1* 1）通过该画布可完成SM部分的设计，状态的定义，状态之间的转移、依赖和冲突关系。 ------------ ### 七、Machine Manifest画布  *图7.1* 1）在该画布可新建machine，并弹窗选择machineDesign 2）将ModeDeclarationGroup部署到machine上（SM部分） ------------ ### 八、Executable画布  *图8.1* 1）该画布可创建ProcessDesign、Executable、SwComponent和CompositionSwC。并设定Executable与SwC（SwComponent、CompositionSwC）之间的关系；设定ProcessDesign与Executable之间的关系；设定CompositionSwC与SwComponent之间的关系。 2）如图中所示，我们创建了两个ProcessDesign，其中ProcessDesign1代表服务端（发送端），ProcessDesign2代表客户端（接收端）。 ------------ ### 九、ProcessToMachineMapping画布  *图9.1*  *图9.2* 1）如图9.1，在该画布会显示出之前创建的Machine和Process，也可在该画布中创建Process。 2）如图9.2，将Process拖拽到Machine中，意味着将Process部署到Machine中。 ------------ ### 十、Instance画布（DdsDeployment、SomeipDeployment）  *图10.1*  *图10.2*  *图10.3*  *图10.4*  *图10.5*  *图10.6*  *图10.7* 1）如图10.1和10.2所示，通过该画布可创建Dployment（Dds、Someip）。通过上图的操作步骤：新建Deployment；设定Deployment所引用的ServiceInterface；根据ServiceInterface来Synchronize Deployment进而自动生成Deployment下面的子元素。也可手动的通过右边的工具栏创建Deployment下面的子元素。 2）如图10.3所示，在该画布可创建Pinstance和Rinstance。创建的时候会出现弹窗，在其中需要完成Id、Deployment、connector、ProcessDesign和Port的设定，通过这些的选择也就是完成了InstanceToPortMapping和InstanceToMachineMapping的创建和关系设定。值得注意的是Pinstance需要选择Pport，Rinstance需要选择Rport。 3）如图10.4所示，当所创建的Pinstance和Rinstance的InstanceId、DomainId（SomeIpInstance不需要）、Deployment相同时，两者之间会出现连线，表示这两个instance具备通讯的能力。 4）如图10.5所示，也可对instance进行End2EndEventProtectProps和End2EndMethodProtectProps的配置，两者分别保证Event和Method的通讯质量。 5）如图10.6所示，SomeIp画布中可进行SdConfig的创建和参数的设置。 6）如图10.7所示，由于这两张画布的内容比较多，可通过勾选的方式，选择展示哪些内容。

>摘要：云原生浪潮下，容器技术是串联起整个云原生世界的关键一环。本文分享自华为云社区[《左手自研，右手开源，技术揭秘华为云如何领跑容器市场》](https://bbs.huaweicloud.com/blogs/281793?utm_source=csdn&utm_medium=bbs-ex&utm_campaign=other&utm_content=content)，作者：华为云社区精选。  近日，IDC 发布的《PRC SDC Market Overview and Analysis, 2020H2/2020》报告显示，华为云**以24.3%的市场份额，斩获中国容器软件市场第一**。 下面，我们从技术角度分析，华为云为什么能领跑容器软件市场。 # 容器如何成为宠儿？ 容器是什么？ 从字面上看，这是一个用于盛放某种东西的器具，实际也是如此，容器技术可以将软件的程序代码和依赖项打包起来，让其与实际运行的环境隔离，哪里需要搬哪里，比如在数据中心、个人电脑上部署运行。 这个概念有点像老大哥虚拟机，但是两者的相似点仅仅在于：提供独立的环境运行软件。在[基因、容器和上帝](https://bbs.huaweicloud.com/blogs/114535) 中，作者从哲学化的视角谈了程序员创造的虚拟世界，也点出了两者的异曲同工之妙：Docker容器技术和VM虚拟机从技术原理上看，是完全不同的路线，连实现思路都不一样。但是，它们所达成的效果或者说是目标确是惊人的一致：即模拟一台看着像物理机一样的东西。 虽然如此，但两者内在逻辑差别很大。容器可以在操作系统级别进行虚拟化，一个操作系统内核上可以运行多个容器，而虚拟机只是硬件层面的虚拟化。相比较VM，容器更轻巧、启动速度更快、占用的内存微乎其微，[容器与Docker](https://bbs.huaweicloud.com/blogs/203431)详细对比了虚拟机和容器的优缺点。 随着用户对云端应用开发、部署和运维的效率愈加重视，间接促成了容器的盛行。 不过，容器在云服务领域“发光发热“离不开一个关键技术：**Docker**。  Docker是目前应用最多的容器引擎技术，它的logo是一只蓝色的鲸鱼驮着一堆小方块。开发者通过docker可以为任何应用创建容器：应用的流程、库和依赖，甚至整个操作系统的文件系统能被打包成一个简单的可移植的包，这个包就像是鲸鱼背上蓝色的小方块，它可以在任何运行Docker的机器上使用，从根本上解决了开发运行环境不一致的问题，让容器真正实现了一次构建，随处运行。 当应用程序被分解为多个小组件或服务，每个组件或服务都放置在一个容器中，每个容器可能还运行在不同的计算机中，此时就需要对容器进行有序的编排和管理。就像电脑上的操作系统，它可以管理所有应用程序，并规划哪个应用程序何时使用电脑的CPU和其他硬件资源。 脱胎于Google内部集群管理系统Borg的kubernetes逐渐成为业界标准，它可以通过API的方式将多个不同的计算机作为一个资源池进行管理，类似某种集群操作系统，管理整个集群中的容器化应用程序。[ Docker与Kubernetes的兴起](https://bbs.huaweicloud.com/blogs/138949)这篇文章就具体谈到了kubernetes（k8s）如何从三足鼎立的局面中PK掉其他两个对手，在混战中取得胜利。 至此，属于容器的黄金时代大幕正式拉开。 Gartner预测，到2023年，70%的组织将在生产中运行三个或更多容器化应用程序。容器、Kubernetes和微服务应用模式是企业IT创新和数字化转型的三大驱动力。 华为很早就投入了容器的怀抱中，由于一直使用虚拟机封装应用程序，每次启动虚拟机花费了大量的时间，这给管理及部署基于虚机应用程序的高成本和低效率带来了挑战。所以在2015年的时候，华为决定利用Kubernetes技术对自身IT系统进行容器化改造。华为在通过自身的容器化改造实践受益的同时，又将遇到的实际问题不断贡献给社区，与社区成员一同推动Kubernetes的发展。 2018年4月，华为云获得了CNCF基金会的顶级席位——CNCF技术监督委员会席位，全球共9席，华为是亚洲首家进入者。 同时，随着越来越多的企业业务选择容器化，在集群的规模、性能、实时监控与弹性扩缩容等方面都提出了新的要求，当开源社区方案难以解决这些问题的时候，就非常考验各大云服务供应商的技术能力。 # 万丈高楼平地起，建设好云原生基础设施 在[为什么说容器的崛起预示着云原生时代到来？](https://bbs.huaweicloud.com/blogs/200395)中，华为云云原生团队认为，各类现代化的应用都将会运行在K8s之上，不仅仅是当前以互联网App、WebService为代表的无状态应用，还有新型的诸如大数据、AI、分布式数据中间件等等有状态应用，以及边缘应用也将会普遍运行在K8s之上，K8s将完成对各类现有平台的归一化，成为一个统一的应用运行的基础平台。 华为云最早于2018年洞察到了这一技术趋势，在容器全栈产品中构建了Vessel云原生技术平台，主要包括了以**容器引擎iSula、容器网络Yangtse、容器存储Everest**为代表的面向统一资源层的云原生基础设施组件。  下面，我们将逐一为大家揭开华为云的容器技术面纱。 # 容器引擎iSula 基于docker和kubernetes，首先Docker并不是万能药，它在某些场景下也存在不足，比如： - 在资源敏感环境，或需要部署高密度容器节点时，容器对基础设施的资源占用会急剧升高； - 当大规模应用拉起或遇到突发流量时，并发速度可能成为瓶颈。 当主流的 Docker 等容器引擎在特定用例下力不从心时，一些针对某种用例进行过专门优化的容器引擎技术开始崛起。比如说，以 Kata Container 为代表的专门针对容器隔离性不够严格而设计的安全容器技术；以 iSula 为代表的针对资源受限的边缘计算和 IoT 环境设计的轻量级容器技术。 可以看出，iSula是与Docker相对的一种容器引擎，它一方面完全兼容现有容器生态，另一方面相比Docker内存占用下降68%、启动时间缩短35%。 比如相比Golang编写的Docker，iSula使用C/C++实现，具有轻、灵、巧、快的特点，不受硬件规格和架构的限制，底噪开销更小。在严苛的资源要求环境下，轻量模式下的 iSulad 本身占用资源极低（ 15M） 。  2017 年，iSula 技术团队成功将 Kata Containers 集成到 iSula 容器平台，并于 18 年初应用于华为云容器服务，**推出基于iSulad 容器引擎和 Kata Containers 的商用容器服务——华为云容器实例 CCI（Cloud Container Instance），这也是业界首个 Serverless 架构的云容器服务**。 那么，基于iSulad 容器引擎和 Kata Containers 如何打造安全、高性能的CCI？且看 [基于 Kata Containers 与 iSulad 的云容器实践解析](https://bbs.huaweicloud.com/blogs/147030)进一步分析，文中提到真正的 Serverless 容器服务中，集群管理由云服务提供商承担，客户只需要关注每个应用的容器实例即可。在这种情况下，云服务提供商需要考虑如何在统一管理面下保证每个用户的安全。 CCI 服务所属的 Kubernetes 集群直接部署在裸金属服务器之上，底层是 Kata Containers，中间靠 iSula 容器平台连接。其中，依靠 Kata Containers 的强隔离特性，多个租户之间的容器运行环境强隔离，不同租户之间的容器不感知、不可见，做到在同一台裸金属服务器上混合部署而安全无虞。 安全之外，在算力方面，CCI基于iSula提供的GPU直通功能，可以直接在容器中使用各种GPU进行AI计算。再加上CCI无需购买和管理弹性服务器，可直接在华为云上运行容器和pod，也无需创建集群，管理master和work节点，非常适用于批量计算，高性能计算，突发扩容，以及CI/CD测试。 在此，华为云社区推荐一些有趣的案例，可以帮助大家快速上手CCI，比如[云容器实例CCI - 使用Tensorflow训练神经网络](https://support.huaweicloud.com/bestpractice-cci/cci_04_0008.html#toTop) 和[云容器实例CCI – 经典2048数字合成游戏部署指南](https://bbs.huaweicloud.com/forum/thread-17431-1-1.html) ，通过这些简单的实操和小游戏，能够对Serverless 架构的云容器服务有更直观的认识。 # 容器网络Yangtse 大家应该都看过某些明星导致社交媒体平台宕机的新闻，明星事件带来的突发流量触发业务扩容，以前是扩容虚拟机，速度慢还情有可原，现在大部分互联网平台都使用容器了，为什么扩容速度还是跟不上流量增长的节奏呢？ 首先，Kubernetes本身并不负责网络通信，它提供了容器网络接口CNI负责具体的网络通信，开源的CNI插件非常多，像Flannel、Calico等。包括华为云容器引擎CCE也专门为Kubernetes定制了CNI插件，使得Kubernetes可以使用华为云VPC网络。 尽管如此，多个容器集群的网络通信（容器连接到其他容器、主机和外部网络的机制）始终是个复杂的问题。比如大规模节点管理场景下网络性能的瓶颈；网口发放速度如何匹配容器扩容速度等等。最终，对对底层虚拟化网络提出了**密度更高，规模更大，发放更快，调整更频繁**的要求。 容器网络Yangtse深度融合华为云虚拟私有云（VPC）原生网络能力，它采用的VPC-Native组网被称作ENI(Elastic Network Interface)模式，容器直接挂载具有VPC子网地址的ENI，具备完全VPC网络互通能力。容器实例可以在集群VPC网络和与之相连的其他VPC网络中进行原生路由，并且直接使用VPC原生的网络能力如 network policy、ELB、EIP、NAT等。换言之，就是容器地址属于VPC子网，容器独占对应的ENI网口，解决了容器的互通性问题。 而且Yangtse基于华为云擎天架构的软硬协同能力，会把治理和转发逻辑下沉到擎天卡上，实现容器网络主机资源0占用。数据显示，通过硬件直通方式及动态网络队列，网络整体性能提升40%，单容器PPS提升2倍；基于warm pool的能力，1-2秒内完成ENI的发放和网络端到端打通。 至于具体如何实现，大体上可以总结为三点： 1、warm pool 机制可以解决网络资源预热的问题。如果不做预热，容器网络端到端打通时间在一分钟以上，分钟级容器启动时间是不可接受的。 Warm pool机制在裸金属节点上预挂载一定数量ENI（用户可根据服务部署并发量自定义配置），容器随时调度到预热节点上都有即时可用的ENI网卡。经过warm pool的优化，容器网络端到端打通时间缩短为1s-2s。 2、得益于擎天架构的优势，裸金属容器还可以向虚拟机容器扩容，而在虚拟机容器上，容器网络Yangtse使用了Trunkport技术，结合ENI的优势，在保障性能的前提下，单台服务器理论上可为千容器同时提供直通网络能力。 3、当应用业务流量增长触发扩容时，如果ELB直接全量发放分摊的流量请求，海量请求会迅速压垮（overload）新扩的容器，造成扩容失败。 所以新扩容的后端实例需要“慢启动”的过程，但一个节点部署多个容器时，节点的二次分发让ELB无法感知到最终的后端容器，进而无法做到容器级别的流控，也难以保证稳态后的负载均衡。容器网络Yangtse实现了与华为云ELB v3独享型负载均衡实例的直通。 具体技术详解，可以阅读[华为云第二代裸金属容器技术系列：应对海量并发的网络黑科技](https://bbs.huaweicloud.com/blogs/194532) 。 目前，Yangtse已经为华为云CCE/CCI/IEF等容器服务提供了统一的容器网络方案，覆盖虚机、裸金属、Serverless和边缘节点等各种容器运行环境。 其中**最值得注意的是CCE，它是一种托管的Kubernetes服务，可进一步简化基于容器的应用程序部署和管理，深度整合华为云的计算、存储、网络和安全等技术构建高可用Kubernetes集群**。 在CCE中，用户可以直接使用华为云高性能的弹性云服务器、裸金属服务器、GPU加速云服务器等多种异构基础设施，也可以根据业务需要在云容器引擎中快速创建CCE集群、鲲鹏集群、CCE Turbo集群，并通过云容器引擎对创建的集群进行统一管理。 以今年在HDC重磅发布的云容器集群CCE Turbo为例，它主要针对企业大规模业务生产中的高性能、低成本诉求，在计算、网络和调度上全方位加速， [新一代容器解决方案：云容器引擎CCE Turbo集群](https://bbs.huaweicloud.com/blogs/198569)就总结了它在这三个方面的新突破。 >在计算加速方面，业界独家实现容器100%卸载，服务器资源和性能双零损耗。 >在网络加速方面，采用独创的容器直通网络，让两层网络变成一层，端到端连通时间缩短一半，有效支撑业务秒级扩容千容器。 >在调度加速方面，通过感知AI、大数据、WEB业务的不同特征，以及应用模型、网络拓扑等，实现业务混合部署、智能调度，还自动优化任务调度策略，实现1万容器/秒的大规模并发调度能力。 再就是容器存储Everest， 每个POD使用独立VF，读写时延降低50%；将Posix组件卸载，单进程节省30M内存；NAS卷直挂POD容器内，提高请求处理效率30%。 # “查漏补缺”Kuberentes，开源技术解决特殊场景难题 基础设施之外，华为云先后将Vessel的核心组件Volcano和KubeEdge开源，并贡献给云原生计算基金会CNCF，成为社区首个容器智能边缘项目和容器批量计算项目。 # Volcano——批量计算 当有更多的用户希望在Kubernetes上运行大数据、 AI和HPC应用，而它默认调度器又无法满足包括公平调度、优先级、队列等高级调度功能时，就需要一些新的技术解决方案登场了。 考虑到AI、大数据等业务的需求，华为云在Kubernetes调度上做了一个感知上层业务的调度——Volavano，它是基于Kubernetes构建的一个通用批量计算系统，[Volcano架构设计与原理解读](https://bbs.huaweicloud.com/blogs/239645)就Volcano产生的背景、架构设计与原理进行深度解读，用数据证明了Volavano为分布式训练、大数据、HPC场景带来了效率的提高。 [Volcano火山：容器与批量计算的碰撞](https://bbs.huaweicloud.com/blogs/205045)则从并行计算开始说起，详细解释了Volcano的调度框架、调度实现原理。作为调度系统，Volcano通过**作业级的调度**和**多种插件机制**来支持多种作业，其中作业级的调度支持以多种类型的作业为目标进行设计，比如基于时间的、跨队列的等等。Volcano的插件机制有效的支撑了针对不同场景算法的落地，从早期的gang-scheduling/co-scheduling，到后来各个级别的公平调度。  图：总体架构 在华为云今年刚推出的CCE Turbo容器集群中，就采取了多项Volcano关键调度技术，如基于共享资源视图的多调度器、决策复用、应用模型感知、数据位置亲和调度、网络拓扑调度等，从而实现1万容器/秒的大规模并发调度能力。 # KubeEdge——边缘计算 容器天然的轻量化和可移植性，非常适合边缘计算的场景。理想情况下，在边缘部署复杂的应用，Kubernetes 是个很好的选择，现实真相是要想在边缘部署 Kubernetes集群，各种问题层出。 比如很多设备边缘的资源规格有限，特别是 CPU 处理能力较弱，因此无法部署完整的 Kubernetes；Kubernetes 依赖 list/watch 机制，不支持离线运行，而边缘节点的离线又是常态，例如：设备休眠重启；边缘业务通常在私有网络中，无公网IP，云边跨越公网导致延迟高。 为了解决这些问题，KubeEdge应运而生。KubeEdge即Kube+Edge，顾名思义就是依托K8S的容器编排和调度能力，实现云边协同、计算下沉、海量设备的平滑接入。 其架构主要包含三部分，分别是云端、边缘侧和终端。云端负责应用和配置的下发，边缘侧则负责运行边缘应用和管理接入设备。 [KubeEdge架构解读：云原生的边缘计算平台](https://bbs.huaweicloud.com/blogs/241350)从KubeEdge架构设计理念、KubeEdge代码目录概览、KubeEdge集群部署三方面带大家认识KubeEdge。  关于KubeEdge和Volcano的更多技术硬实力体现和落地案例，可以阅读专题[【技术补给站】第5期：从架构和实践，剖析KubeEdge+Volcano技术硬实力](https://bbs.huaweicloud.com/blogs/240234)，在此不再赘述。 # 解决多云容器集群管理，新秀Karmada崛起 批量计算和边缘计算的问题解决后，伴随云原生技术和市场的不断成熟，很多企业都是多云或者混合云的部署，一方面可以避免被单供应商锁定降低风险，另一方面也可以是出于成本的考量。 但是多集群同时也带来了巨大的复杂性，包括如何让应用面向多集群部署分发，并做到多集群之间灵活切换。在今年的HDC上，华为云宣布了**多云容器编排项目Karmada正式开源**，Karmada项目由华为、工商银行、小红书、中国一汽等8家企业联合发起，它可以构建无极可扩展的容器资源池，让开发者像使用单个K8s集群一样使用多云集群。 Karmada是一个 Kubernetes 管理系统，基于 [Kubernetes Federation v1](https://github.com/kubernetes-retired/federation) 和[ v2](https://github.com/kubernetes-sigs/kubefed) 开发，它可以跨多个 Kubernetes 集群和云运行云原生应用程序，直接使用 Kubernetes 原生 API 并提供高级调度功能，实现真正的开放式多云 Kubernetes。 [华为云MCP多云跨云的容器治理与实践](https://bbs.huaweicloud.com/blogs/281796)为我们梳理了Karmada项目诞生的前因后果，以及整个项目的核心价值，比如对K8s原生API兼容 、丰富的多集群调度支持、开箱即用等等。  Karmada的架构设计图 从架构图可以看到，整个控制面板可以分为四大块：提供原生API入口，存放用户yaml和Karmada资源对象的Karmda API Server，和配套存储ETCD；以及资源控制器Karmda Controller Manager、多集群调度器 Karmda Sheduler。其中，最关键的就是API Server，让用户既有的资源配置（yaml）可以借助K8s原生API进行部署。 综上，Karmada 旨在为多云和混合云场景下的多集群应用程序管理提供 turnkey 自动化，其关键功能包括集中式多云管理、高可用性、故障恢复和流量调度。 今年的HDC期间，在线教育平台VIPKID的后端研发高级专家分享了使用 Karmada实现从天到秒的跨云迁移实践。在剖析VIPKID的多场景云原生落地实践后，他对多集群管理提出了一些思考，如下图所示，理想的多集群管理方式是： - 集中管理，但要原生； - 应用在不同集群的差异化管理； - 集群故障自动转移。  对比了多家方案后，VIPKID选择了开源的方案 Karmada。作者表示Karmada的整个设计结构就是按原生k8s开发标准开发的，唯一差别之处是需要管理多个集群不同的 workload信息，所以改写了调度器和控制器，在它们下面对接了多个集群管理起来。这样最大的好处是看起来在控制一个集群，但最终的效果是在控制多个集群。 具体案例情况参见[Karmada | VIPKID在线教育平台从天到秒的跨云迁移实践](https://bbs.huaweicloud.com/blogs/281788)，文章内有现场demo演示用Karmada实现多集群管理。 另一个经典案例是[工商银行多k8s集群管理及容灾实践](https://bbs.huaweicloud.com/blogs/281790)。工商银行的应用平台云容器规模超20万，业务容器占到55,000个左右，整体的一些核心业务都已入容器云内部，包括个人金融体系的账户，快捷支付、线上渠道等。当越来越多的核心业务应用入云之后，最大的挑战是容灾以及高可用。 但既有的运管平台并不能解决这些问题，比如没有整体的跨集群自动伸缩能力、集群对上层用户不透明、没有跨集群的自动调度和迁移等等。对此，他们根据业务场景调研了一些多集群管理平台，最终也选择了社区支持的开源项目Karmada。 Karmada以类k8s的形式部署，对他们来说，改造成本是比较小的，只需在上面部署一个管理集群即可。而且Karmada仅管理资源在集群间的调度，子集群内分配高度自治。在实践中，Karmada的资源调度、容灾、集群管理和资源管理的优势突出。 截止到现在，工行在测试环境中已经用Karmada对存量集群进行一些纳管，未来规划的关键的点是如何和整体云平台进行集成。 项目地址 ：GitHub - karmada-io/karmada: Open, Multi-Cloud, Multi-Cluster Kubernetes Orchestration 总结 围绕Docker和kubernetes，华为云在技术层面做了诸多的优化和新的探索尝试，除此之外，华为云还有端到端的容器运维管理体系，涵盖资源编排、容器应用持续交付、应用生命周期管理、镜像安全扫描以及日常运维监控等。 云原生浪潮下，容器技术是串联起整个云原生世界的关键一环，它的市场之争，正是山雨欲来风满楼，想要占得高地，技术实力、开源生态、合作伙伴，缺一不可。

>摘要：云原生ADN网络的未来，是公有云Internet接入降成本的手段，以及对自建光纤骨干网的补充，有力地支撑 “东数西算”国家新基建布局。本文分享自华为云社区[《华为云顾炯炯：应用传送网络(ADN)，重新定义云原生时代的媒体网络》](https://bbs.huaweicloud.com/blogs/301210?utm_source=zhihu&utm_medium=bbs-ex&utm_campaign=other&utm_content=content)，作者：技术火炬手。 伴随媒体内容逐渐的丰富多彩、引人入胜，媒体内容的生产制作从本地工作室上移至云端成为了必然趋势。媒体内容从生产到消费的全流程，离不开媒体内容的生产者、云端数字内容制作基础设施、平台系统和媒体内容消费者。**而连接这些角色的背后，是一张高质量的精品媒体网络**。 9月24日，华为云举办了主题为“数字内容云上生产，共创影视产业新高地”的主题论坛，**华为云首席架构师顾炯炯**为大家带来了今年华为云在云原生媒体及网络领域的重磅级创新服务：**应用传送网络（Application Delivery Network），简称ADN服务**。 # 云原生应用传送网络ADN: 多级QoS、高可靠、高弹性的媒体服务网络基石 ADN为云原生媒体服务，乃至更广义的云上互联网应用提供了多级QoS，高可靠，高弹性的网络基石，相比基于“尽力而为”传送IP网络路由机制的Internet互联网， ADN 网络是一张叠加在Internet互联网，以及华为云遍及全球的云端及分布式边缘基础设施和专线网络之上的overlay网络。 该网络彻底解决了互联网缺乏QoS保障，局部路由拥塞收敛慢，以及专线成本高，覆盖区域受限的问题，具备软件定义的可编程能力，无需升级改动存量运营商网络，即可支持分钟级新增路由节点及路由变更，使得媒体网络具备了云的“弹性敏捷”的核心特征。从而为媒体业务提供了兼具互联网全域覆盖、低成本及专线的确定性QoS保障优势的基础网络传送服务，并且可支持应用驱动的SLA与QoS。  # 云原生应用传送网络（ADN）架构：应用驱动、软件定义、敏捷智能 整体来看，云原生应用传送网络ADN与内容传送网络CDN的命名相对应，CDN的定位是通过检测Web与视频内容的热点部分，以及进一步通过热点内容的缓存及存储实现带宽成本的降低，以及用户接入时延体验的提升。 ADN的适用范围则相比CDN更为广泛，几乎可覆盖所有分布式互联网应用，突破CDN无法加速动态生产Web内容的Web网页的局限，这也正是ADN名称的来由。  # 1. ADN网络的3层架构：物理层、逻辑层、应用层 ADN的整体技术架构划分为3层，物理层、逻辑层，以及应用层，物理层对应华为云存量的全球云骨干网及各电信运营商的Internet互联网，而ADN网络的核心正是叠加在这2张物理承载网络之上的一张统一的逻辑Overlay网络，也即逻辑层ADN网络内任意2个节点之间的路由，对应物理层节点之间的直达Internet或专线物理路由，或者通过若干跳ADN节点中继转发的多段Internet路由及物理专线路由的拼接组合。 ADN网络内特定任意2节点之间最优路由之所以可能对应非直达的、多段迂回转发的物理路由，原因在于传统物理路由机制，如OSPF、BGP等，采用的是邻居发现算法，因此在遇到部分物理节点拥塞的情况下，无法实现物理层路由的及时快速调整，此时基于ADN Overlay转发节点的物理路由组合，则可能规避该局部拥塞点，给出更优的路径选择。 ADN的应用层即包括上文提到的云原生媒体服务，也即媒体生产、媒体分发，以及媒体应用，也包括运行在云上的泛互联网App，比如游戏、文娱，办公，甚至通过REST API远程交互协同的各类分布式应用，逻辑层的ADN应用传送网络服务通过契约化定义的AND API，与应用层的云原生媒体服务及互联网App进行交互，输入参数包括由应用层指定的ADN路由的起始、终结节点，以及希望起始到终结节点之间路由必须满足的应用层、传输层、网络层的QoS/SLA指标，而API的返回输出参数，则包括含了从ADN起点到终点之间的路由节点的最终序列。 # 2. ADN网络的三大核心技术特征 **广覆盖、高敏捷、全互联的网络拓扑**。 通过无所不在、彼此互联互通，超过2500个ADN节点的全球广泛覆盖，ADN网络实现了最终用户的一跳入网；同时，通过支持ADN节点的分布式容器化部署，实现了分钟级节点增删与网络拓扑更新的高弹性、高敏捷；通过逻辑、物理分层解耦，通过任意ADN节点之间基于Full Mesh的点到点测量，为任意2个ADN节点之间动态最优路径的选择提供了依据和保障。 **多目标驱动智能路由，多样化接入协议传输**。 支持分钟级端到端路由图优化算法，实现智能路由计算；支持单流分多流、多流合并单流，具备多优先级路径的实时选择能力；具备抗弱网协议增强、具备高可靠的传输能力，实现智能拥塞控制；通过华为自研设计的nStack协议栈，DPDK／用户态驱动转发的技术，实现近线速的Overlay转发能力； 提供了TCP/UDP/域名解析，以及SDK模式等灵活多样化的ADN网络接入协议选项。 **应用驱动、软件定义的SLA，租户和业务感知的流量调度**。 在ADN的API定义中，通过应用驱动、软件定义的网络层/传输层/应用层QoS/SLA指标，比如网络层的时延、丢包，以及媒体应用层的抖动、音视频MOS等，描述上层应用App希望ADN网络达成的质量保障水平及目标；在应用感知方面，基于云服务类型感知的网络流量预测，及基于AI、大数据统计的租户应用流量画像 ADN网络进一步支持业务流量的分时错峰调度，以及跨端边云的应用与数据迁移同步能力。 # ADN服务的核心价值：应用和媒体加速、极致敏捷可靠的云接入与云互联 ### 总体而言，ADN服务的最终客户价值体现在2方面：面向互联网应用、媒体内容体验提升与保障的全路径网络加速的能力；面向云租户提供极致敏捷可靠的云接入、云互联服务。 ADN服务支撑企业租户以最优的性价比及敏捷可靠性，从本地IDC数据中心或办公地点接入最近的云数据中心Region或边缘站点，以及解决不同云服务区域之间，云服务区域与边缘站点之间，不同终端用户/边缘站点之间的互联网加速能力问题。 # 1. 应用及媒体传输全路径加速方面，ADN实现了同等于专线的QoS质量，但比专线便宜50% 基于ADN网络的测试统计结果来看，对于大于1000公里的长距离连接，ADN网络相比原生Internet物理网络的平均优化幅度达到20%到40%以上，比如“约翰内斯堡 — 新加坡”，以及“墨西哥城 —上海”的远程连接场景，优化路径分别调整为“约翰内斯堡—香港—新加坡”，以及“墨西哥城—硅谷—上海”， 优化幅度分别达到了42.5%和36.7%，而丢包率方面，ADN即便在基于Internet物理承载的前提下，依然可消除长途Internet网络连接，特别是TCP/HTTP连接协议下，由于丢包所带来的吞吐率的影响，基本可达到与物理专线所持平的零丢包率水平（带宽非瓶颈前提下）。而“墨西哥—昆明”的缺省Internet路由路径，在ADN网络的优化作用下，将其路由调整为“墨西哥—上海—昆明”，从而有效绕过了“墨西哥—昆明”之间缺省Internet物理路由的局部拥塞点，将丢包率从15%降到0，而“东京—北京”的缺省 Internet路径，也动态调整为“东京—郑州—北京”，从而将42%丢包率降低到0。 而通过ADN内部的多路径实时冗余能力、网络与华为云自建的物理HBN（华为骨干网络）之间多平面实时冗余的能力，以及ADN故障后切换到Internet的韧性保护的能力，更是进一步将华为云的广域连接可靠性、鲁棒性提升了1个数量级。 # 2. 网络弹性与敏捷能力方面，ADN通过云原生技术突破了传统广域网在物理设备及地理区域方面制约，使得网络拓扑变化及路由收敛从天级缩短到分钟级 ADN网络的接入及转发节点，可灵活部署在电信运营商城域网，被多租户共享接入；或者部署在企业内部网络，为单个租户提供独占服务；ADN通过基于CCE集群容器及IEF边缘容器部署模式，实现了分钟级的网络拓扑变更，以及转发节点容量的自动按需弹性伸缩；ADN的多目标线性规划的高性能路由算法，则支持分钟级的路由收敛及最优/次优路径选择。 # 3. 公有云结构化降成本方面，ADN通过将中心Region的EIP卸载到边缘站点及CDN，将公有云网络接入成本降低40%以上 通过将面向云服务、云主机、云容器的弹性IP从中心Region下沉到边缘节点，ADN使得云租户可从各运营商的城域网经由静态BGP就近接入到分布式边缘站点，再通过分布式边缘站点经由物理专线连接到主Region服务区的云服务、云主机、云容器实例，由于动态BGP与静态BGP在国内定价差价达近10倍，加之ADN接入节点与CDN共享上下行带宽，使得CDN非忙时阶段的闲置带宽资源得以更为充分的利用，从而进一步大幅降低了租户的总体弹性IP接入成本，使得公有云的网络接入总成本降低达40%以上。 # 展望 云原生ADN网络的未来，其对于华为云的意义将远不止于一张敏捷、弹性、智能的全球精品媒体网络，是公有云Internet接入降成本的手段，以及对自建光纤骨干网的补充。 随着ADN网络建设的日益完备，及其在云网协同方面的运营与运维数据的极大丰富与积累，必将推动其成长为华为分布式云原生架构的“大动脉”与“高速公路”, 使得跨越不同Region云服务区，跨越云边端、跨越遍布全球的华为云、伙伴云及HCS的统一资源调度与统一应用编排部署成为可能，从而有力地支撑 “**东数西算**”**国家新基建布局**，以及**华为云**“**全球一朵云**”、“**全球一张网**” 战略的达成。

XML 文档形成了一种树结构，它从"根部"开始，然后扩展到"枝叶"。一个 XML 文档实例XML 文档使用简单的具有自我描述性的语法：1234567<?xml version="1.0" encoding="UTF-8"?><note><to>Tove</to><from>Jani</from><heading>Reminder</heading><body>Don't forget me this weekend!</body></note>第一行是 XML 声明。它定义 XML 的版本（1.0）和所使用的编码（UTF-8 : 万国码, 可显示各种语言）。下一行描述文档的根元素（像在说："本文档是一个便签"）：<note>接下来 4 行描述根的 4 个子元素（to, from, heading 以及 body）：1234<to>Tove</to><from>Jani</from><heading>Reminder</heading><body>Don't forget me this weekend!</body>最后一行定义根元素的结尾：</note>您可以假设，从这个实例中，XML 文档包含了一张 Jani 写给 Tove 的便签。XML 具有出色的自我描述性，您同意吗？XML 文档形成一种树结构XML 文档必须包含根元素。该元素是所有其他元素的父元素。XML 文档中的元素形成了一棵文档树。这棵树从根部开始，并扩展到树的最底端。所有的元素都可以有子元素：12345<root><child><subchild>.....</subchild></child></root>父、子以及同胞等术语用于描述元素之间的关系。父元素拥有子元素。相同层级上的子元素成为同胞（兄弟或姐妹）。所有的元素都可以有文本内容和属性（类似 HTML 中）。实例：上图表示下面的 XML 中的一本书：XML定义：用于标记电子文件使其具有结构性的标记语言，可以用来标记数据、定义数据类型，是一种允许用户对自己的标记语言进行定义的源语言。XML发展史？简单提一下Markup Language历史：1969：GML（Generalized Markup Language）--(IBMResearch)1968: SGML（Standard Generalized Markup Language）--(ISO)1989：HTML（Hypertext Markup Language）--TimBerners Lee作为SGML的一个实例，它的DTD（一种规则）作为标准被固定下来，因此Html不能定义其他符号化语言的源语言。而XML就可以哦，所以就出现了XML。1998/2：XML（Extensible markup Language）W3C(World WideWeb Consortium)SGML的子集XML（定义数据和元数据），XSL（style sheet 描述，就像CSS于html）SGMLvsXMLvs HTML：SGML：长时间存放电子文件。      使用费用高，大都在MainFrame平台。XML：网页文件语言、数据交换语言、数据处理语言、文件整合语言。应用范围几乎没有限制。HTML：网页呈现语言、超文本语言。 XML包括：文件内容：结构定义：ＤＴＤ（Document TypeDefinitied）XMLSchema(DTD+Datatype)显示：XSLXSLT+XHTML+Xpath+（Xlink） 从html到XML：比较：HTML：html只能提供数据显示功能。浏览器提供单一语言机制。网页搜索不精确。扩充困难。网页逻辑关系，网页分级认证不易建立。web资源受限制，无法让其他应用使用。XML：开放平台。可以做任何程序的输入数据。XML改变了浏览器内部的结构。XML具体应用：XML的一个最主要的应用就是作为系统的配置文件，很多系统的配置文件都是用XML，Spring中application中XML，Hibernate中XML，在这里主要说说ASP.NET中的XML。1、配置文件中。 世间所有的相遇都是久别的重逢，我们曾建无数次的与XML擦肩而过，机房收费系统的配置文件，新闻发布系统的配置文件，以及我们建立每一个应用程序下的配置文件，配置文件的后缀名为.config，而我们的XML文件为.xml后缀，为什么vs中没有直接用Web.xml而是用的Web.config?我想可能是微软想把一个东西封装成知己的，就像箱子里是同样的苹果，我想变成我的，我就要弄好一个包装，并且贴上我的标签，告诉别人，这是我特有的。但事实上呢，网上有这样的回答：config是配置，.xml是软件内置的网页文件。表象：前者:用在web.config或者app.config之类.<appSettings>是系统约定的节点,约定在这个节点下的所有<add />节点会被System.Configuration.ConfigurationManager.AppSetting读到.后者:完全的自定义接点,appSettings表示什么意思,add表示什么意思将在自己写的xml解析方法里指定和使用.简单来说：简单来说,config是xml的一个子集。通常的xml都是只定义基本语法,至于节点的层次,节点格式,节点的含义,节点怎么被解析都是你自己定义.使得你的xml文件能和你的xml解析方法对应。而web.config,app.config这类,是Microsoft和软件作者已经定义好了节点意义，你只需要遵守他的格式和规则，就能达到配置作用。通俗讲：打个可能不太好的比方：xml文件本身是扑克牌.config是斗地主。你用config，就不需要自己制定规则，按照它的规则打就行。很方便，但是你不能违反他的规则。而你自己写xml，还要先制定好规则，规则怎么定都随便你，然后按照这个规则出牌.当然，这些都有一个大前提，都满足xml节点规范，你不能制定扑克牌的规则中放入几个麻将牌....2、ASP.NET控件与XML。在学习ASP.NET的视频的时候，用到很多控件，例如LIstBox，DropDownList常用控件，DataList，GridView等数据控件，ADO.NETDataSet操作XML文件，以及前两篇博客提到的导航控件menu和treeview在进行数据源绑定的时候都可以绑定XML文件。本文全面的初识了XML，让大家从各个方面了解到了XML的定义、XML的发展史、和html的比较等一些知识，希望对大家的学习有所帮助。实例中的根元素是 <bookstore>。文档中的所有 <book> 元素都被包含在 <bookstore> 中。<book> 元素有 4 个子元素：<title>、<author>、<year>、<price>。以上就是简单了解XML 树结构的详细内容

操作前提：获取OC,cloudscope登录信息获取oc域名和账号获取cloudscope域名和op_cdk_sso账号密码步骤一：找到虚拟机入口登录oc页面，选择ServiceOM，点击虚拟机步骤二：获取CDKmaster虚拟机IP在虚拟机页面搜索关键字EICommon-region-master获取到的虚拟机Ip即为CDK master节点ip地址{CDKMasterIP}，步骤三：在cdk中找到dwscontroller服务使用op_cdk_sso用户登录cloudscope页面1）运维服务-->auotodepoy-cdk2）进入HCS802服务管理-->服务升级，HCS03及以上 变更管理--》服务升级3）下拉条件：红色框起来的部分第一行的三个需要选择对应的region第二行：选择ei-dbs-xxx等ei开头的选择dws步骤四：获取Controller的mysql数据库连接信息db.urldb.username db.password在页面进入升级，在搜索框中搜索“db.”获取界面后台mysql数据库连接信息:db.password :获取db节点密码的密文，在步骤七使用AESTool.jar解密db.username :用户    db.driver:驱动，后面不用db.url:连接，获取ip，端口步骤五：登录步骤二获取的ip对应主机 虚拟机密码从华为云账号一览表获取 步骤六：登录运维容器在终端使用root用户登录cdk master节点后，执行以下命令可以进入dws-maintain容器：HCS 811以下：kubectl get pod -n dws-maintain   --查有两个容器，是负载集群，都可以登录kubectl exec -ti {pod name} bash -n dws-maintain    -- pod为查询的容器名HCS 811--HCS 821：kubectl get pod -n  ecf  --查有两个容器，是负载集群，都可以登录kubectl exec -ti {pod name} bash -n ecf    -- pod为查询的容器名cd opsTool    --cd到脚本目录下步骤七：解密步骤四获取的密码密文进入dws-maintain容器后，执行以下命令，解密dws密码：java -jar AESTool.jar2 { dbPasswordEncrypt}步骤八：执行connectTool.sh脚本登录节点进入dws-maintain容器后，可以执行以下命令登录dws实例节点，其中user字段在630及之前版本为root，在930及之后版本为ecf，若需要输入密码，则粘贴步骤七中密码即可：sh connectTool.sh -u{user} -drms -h{db ip} -p7306 -n {instance name} –tStandalone 参数说明：-u   用户名 对应db.username-d   数据库 对应db.url 中“jdbc:mariadb://170.75.4.205:7306/rms?autoReconnect=true”红色部分-h   连接ip  对应db.url 中“jdbc:mariadb://170.75.4.205:7306/rms?autoReconnect=true”红色部分 -p   端口   对应db.url 中“jdbc:mariadb://170.75.4.205:7306/rms?autoReconnect=true”红色部分-n   实例名称 对应mysql库中rds_instance.name       或者虚拟机—实例名     serviceOM 裸金属服务--》裸金属实例名称     oc资源监控---》数仓集群—》实例名称

1.1 Tomcat简介Tomcat 服务器是一个免费的开放源代码的Web 应用服务器，属于轻量级应用服务器，在中小型系统和并发访问用户不是很多的场合下被普遍使用，是开发和调试JSP 程序的首选。1.2 物理机调优方法1.2.1 Tomcat参数调优目的：通过修改tomcat的配置文件，可以有效提高tomcat性能方法：按照如下所示信息，配置/home/apache-tomcat-9.0.20/conf/server.xml的各个参数。<Connector  executor="tomcatThreadPool"    port="10000" protocol="HTTP/1.1"    acceptCount="10000"    maxConnections="10000"    connectionTimeout="20000"    compression="off"    compressionMinSize="2048"    URIEncoding="utf-8"    tcpNoDelay="true"    enableLookups="false"    useURIValidationHack="false"    disableUploadTimeout="false"    connectionUploadTimeout="150000"    keepAliveTimeout="12000"    maxKeepAliveRequests="1000"redirectPort="8443" /> 1.2.2 Tomcat 亲和性设置Tomcat支持cpu绑核，利用cpu亲和性设置，可以使用taskset或numctl工具进行绑核操作方法：taskset -c N ./startup.sh或numactl -C N ./startup.shN表示要指定核的序号，例如 将tomcat进程绑定到0-3core上：taskset -c 0-3  ./startup.sh1.2.3 容器场景调优方法容器与物理机共享网口，在物理机上执行绑核脚本。以4core的http短连接场景的绑核脚本为例，脚本内容如下，如果要修改绑核脚本，只需修改要绑定的网口名eth1，以及要绑定的core，然后在关闭irqbalance.service的情况下使用脚本即可：#!/bin/bashcnt=2eth1=enp3s0ethtool -L $eth1 combined $cntirq1=`cat /proc/interrupts| grep -E ${eth1} | head -1 | awk -F ':' '{print $1}'`irq1=`echo $irq1`i=0while(( $i < 1))do    for cpunum in 2 3    do        echo $cpunum "->" $irq1        echo  $cpunum > /proc/irq/$irq1/smp_affinity_list        let "irq1++"    done   let "i++"done脚本中参数及命令说明参数及命令名称参数及命令解释cnt 网口队列数eth1使用的网口名irq1网口eth1对应的中断号cpunum分配给网口eth1用于处理网卡中断的核ethtool -L $eth1 combined $cnt设置网口队列长度为核数cat /proc/interrupts | grep $eth1 | awk -F ':' '{print $1}'查询网口中断数echo $cpunum > /proc/irq/$irq/smp_affinity_list根据中断号，将每个中断各绑定在一个核上此脚本只是容器场景下网卡调优方法1.3 虚拟机调优方法虚拟机采用网卡直通的模式，每个虚拟机配置一个虚拟网口，在虚拟机内部执行绑核脚本。以4core的http短连接场景的绑核脚本为例，脚本内容如下，若要修改绑核脚本，只需修改要绑定的网口eth1，以及要绑定的core，在关闭irqbalance.service的情况下使用脚本即可。#!/bin/bashcnt=2eth1=enp5s0ethtool -L $eth1 combined $cntirq1=`cat /proc/interrupts| grep -E ${eth1} | head -1 | awk -F ':' '{print $1}'`irq1=`echo $irq1`i=0while(( $i < 2))do    for cpunum in  3    do        echo $cpunum "->" $irq1        echo  $cpunum > /proc/irq/$irq1/smp_affinity_list        let "irq1++"    done  let "i++"done脚本中参数名称及解释参数名称参数解释cnt网口队列数eth1实际使用的网口名irq1网口eth1对应的中断号cpunum分配给网口eth1用于处理网卡中断的核此脚本只是虚拟机场景下的网卡调优，虚拟机场景下的亲和性设置与物理机一致.

1.简述登录DWS服务容器，首先登录COP--》CDK中EI集群的master节点，然后使用k8s命令登录对应的容器2.DWS管控面涉及的服务或容器有命名空间（namespace）为 dwsdms-collectiondms-monitoringdwscontroller命名空间（namespace）为 ecfdbseventdbsinsightDbsmonitorecfclustermanager命名空间（namespace）为 dws-maintaindwsmaintaintool3.登录管控面CDK集群Master节点步骤1 登录ManageOne运维面OC。步骤2 选择该Region的ServiceOM。步骤3 进入计算资源->虚拟机->搜索EICommon。找到EICommon-Region-Master-01机器的地址。步骤4 使用ssh登录opsadmin用户到该机器，并切换到root。root密码为统一密码表查到的。802的默认密码：x86：XXXXXarm：XXXX803的默认密码：XXXX4.登录运维容器密文解密，mysql登录，节点登录步骤1 使用root用户登录Master节点之后(参考（三）)，输入kubectl get pod –n dws-maintain。查看运维容器命名空间下的容器。步骤2 输入kubectl exec –ti {容器名} –n dws-maintain bash。进入容器。5.登录dwscontroller容器定位管控面问题查看服务日志步骤1 使用root用户登录Master节点之后，输入kubectl get pod –n dws。查看运维容器命名空间下的容器。选择dwscontroller前缀步骤2 输入kubectl exec –ti {容器名} –n dws bash。进入容器6.登录dms-monitoring，dms-collection容器定位监控面板问题查看日志步骤1 使用root用户登录Master节点之后，输入kubectl get pod –n dws。查看dws命名空间下的容器。选择dms-monitoring，dms-collection对应的前缀步骤2 输入kubectl exec –ti {容器名} –n dws bash。进入容器7.登录dbsevent，dbsinsight，dbsmonitor，ecfclustermanager容器   定位ecf集群，DWS集群状态，事件管理问题查看日志步骤1 使用root用户登录Master节点之后，输入kubectl get pod –n ecf。查看ecf命名空间下的容器。选择对应容器前缀步骤2 输入kubectl exec –ti {容器名} –n ecf bash。进入容器