• 关于

    多参数控制工作原理

    的搜索结果

回答

  本考核大纲依据汽车装配工《国家职业标准》规定的基础理论知识部分和对高级工、技师、高级技师工作要求(技能要求、相关知识)部分制定。   一、考核内容   一基础理论知识   1.职业道德   (1)诚实守信的基本内涵   (2)企业员工遵纪守法的具体要求   2.质量管理   (1)全面质量管理的基本方法   (2)关键工序的管理   3.汽车材料   (1)汽车常用的金属材料种类(铸铁)   (2)润滑油的牌号,性能与选用   (3)掌握汽车轮胎的牌号,分类,规格及组成   4.机械识图   (1)表面粗糙度   (2)位置公差的定义   (3)识装配图   5.电工基本知识   (1)基尔霍夫定律   (2)半导体三极管的主要参数   6.液压传动知识   (1)液压传动的基本回路   (2)液压油的性质与选用   (3)液压传动在汽车上的应用   二汽车结构   1.发动机   (1)发动机总体结构和工作原理   ①汽油机和柴油机的主要的组成部分   ②发动机的工作循环过程   ③燃料燃烧过程   (2)曲柄连杆机构   ①活塞结构及运动传递   ②曲轴的结构及运动   (3)配气机构   ①配气相位角度的组成和性能特点   ②配气机构的作用及运动过程   ③星形配气机构   (4)燃料供给系   ①燃料供给系的组成及其功能   ②电控汽油喷射系统组成和功能   ③柴油机可燃混合气的形成条件及燃烧性能   (5)冷却系   ①冷却系的组成及工作原理   ②冷却温度对发动机的影响   (6)润滑系   ①润滑油的作用和要求   ②润滑油的油路循环路线   (7)发动机电子控制系统   ①电子控制发动机系统的组成:空气供给系,燃油供给系,电子控制系,点火系统   ②电子控制系统的控制功能   ③电子控制系统的组成:传感器,执行器,控制单元   ④发动机电子控制系统的检测:诊断仪,故障诊断代码   ⑤发动机电子控制系统故障诊断和排除   2.底盘   (1)离合器   ①膜片弹簧离合器的结构和优越性   ②离合器操纵机构的分类和特点   (2)变速器   ①同步器的结构和工作原理   ②自动变速器(AT)种类,组成及工作原理   (3)万向传动装置   ①万向传动装置的等速条件   ②等速万向节的工作原理   (4)驱动桥   ①驱动桥的分类和组成   ②准双曲面齿轮传动的主减速器的结构特点   ③对称式锥齿轮差速器的差速原理   ④转向轮定位参数及其功能   (5)悬架   ①悬架的定义和组成   ②独立悬架的定义和组成及其结构特点   (6)转向系   ①动力转向系统种类   ②转向器传动效率   ③液压动力转向系的分类及结构特点   ④转向传动机构的分类和组成及结构特点   (7)制动系   ①汽车制动系统   ○制动系统组成和工作原理   ○制动总泵的结构   ○真空助力的基本原理   ○鼓式和盘式制动器的结构与性能特点   ○驻车机构的结构与功能   ○制动力,附着力,附着系数,滑移率,减速度相互之间的关系及影响因素   ○制动侧滑的影响因素,制动侧滑与跑偏的关系   ○汽车制动效能的评价指标   ②汽车制动防抱死系统及检测   ○防抱死系统的组成:车速传感器,液压控制单元,控制单元   ○液压控制单元的组成   ○ABS的控制形式   ○防抱死系统的工作过程:制动压力增长阶段,制动压力保持阶段,制动压力降低阶段   ○防抱死系统检测;诊断仪,自诊断系统,故障诊断代码   ○防抱死系统的故障   ○ABS扩展系统有哪些:EBD(EBV),ESP,EDS,ASR   3.汽车电器   (1)汽车电器设备   ①汽车电器设备的组成和特点   ②用电设备的组成及功能   (2)汽车电源系   ①交流发电机的工作特性   ②电压调节器的基本类型及工作原理   ③蓄电池的充电方法及连接方法   (3)汽车起动系   ①直流串励式电动机的特点   ②起动机控制电路的类型和特点   ③起动系故障的诊断和分类   (4)点火系   ①无触点点火系统的组成和工作原理   ②电子控制点火系统的种类、组成和特点   (5)照明信号,仪表及警报系统   ①前照灯的基本要求及其光学结构和调整方法   ②信号系统的组成和要求   ③常规电器仪表的种类和功能   (6)辅助电器设备   ①汽车空调系统的组成和功能   ②汽车空调循环流程   ③双速永磁式电动机工作原理   ④中控门锁的工作原理及作用   ⑤安全气囊的作用及工作原理   ⑥电动玻璃升降机的作用及工作原理   (7)全车电路   ①汽车全车电路主要由哪些系统组成   ②简述识读汽车电路图的基本原则   (8)CAN总线技术   ①CAN总线的作用和特点   ②CAN总线的工作原理   三汽车理论   1.汽车的动力性   (1)汽车动力性指标   (2)汽车行驶阻力种类   (3)汽车行驶的附着条件和驱动条件   (4)汽车的动力性的影响因素   2.汽车燃油的经济性   (1)影响汽车燃油经济性的因素   (2)燃油经济性评价指标   3.汽车制动性   (1)制动性的评价指标   (2)制动时车轮的受力   (3)制动效能及其恒定性   (4)制动时汽车的方向稳定性   (5)前后制动器制动力的比例关系   4.汽车的操纵稳定性   (1)汽车转向特性   (2)轮胎的侧偏特性   5.汽车的平顺性   (1)汽车的平顺性的定义   (2)人对水平、垂直方向振动敏感频率   6.汽车的通过性   (1)汽车通过性的评价指标及几何参数   (2)影响汽车通过性的主要因素   四汽车使用性能与检测技术   1.汽车使用性能   (1)汽车使用性能定义   (2)检测参数标准的类型和组成   (3)汽车检测参数选择原则   2.汽车综合性能检测站基础知识   (1)汽车综合检测站的类型   (2)安全环保检测线的组成和布局   3.汽车动力性能检测   (1) 发动机综合性能分析仪的作用   (2) 汽车底盘测功机的作用   4.汽车燃料经济性与检测   (1)汽车燃料经济性试验的分类   (2)常用汽车油耗计的作用   5.汽车制动性能   (1)汽车制动性能台试检测项目   (2)反力式滚筒试验台的作用   6.汽车的操纵稳定性与检测   (1)影响转向特性的因素   (2)汽车车轮侧滑检验台的结构和工作原理   (3)四轮定位检测仪检测的项目   (4)四轮定位仪的组成和工作原理   (5)动平衡和静平衡的定义   7.汽车车速表检测   (1)汽车车速表允许误差的范围   (2)标准型车速表试验台的作用   8.汽车前照灯检测   (1)前照灯检测的目的   (2)屏幕法检测和检测仪检测的比较   9.汽车公害及检测   (1)汽车排放中的主要成分   (2)汽车噪音的检测方法   五汽车制造装配工艺   1.工件的定位原理   (1)定位基准的概念   (2)工件位置公差的保证方法   (3)工件定位的基本规律   (4)定位误差的分析   (5)加工误差的合成及影响因素   2.尺寸链原理及应用   (1)尺寸链的基本概念   (2)尺寸链计算的基本公式   (3)装配尺寸链的建立   (4)保证装配精度的方法   3.汽车装配工具   ①装配工具种类   ②工具适用范围   二、考试题型及题量   单项选择题(40题)、多项选择题(60题)、判断题(40题)总分100分。   三、考核时间:120分钟   四、推荐教材目录   《汽车构造(上、下)》 陈家瑞主编 机械工业出版社   《汽车使用性能与检测及检测技术》 李军主编 人民交通出版社   《汽车电器设备购造与维修》 周建平主编 人民
马铭芳 2019-12-02 01:16:47 0 浏览量 回答数 0

回答

Kafka 是目前主流的分布式消息引擎及流处理平台,经常用做企业的消息总线、实时数据管道,本文挑选了 Kafka 的几个核心话题,帮助大家快速掌握 Kafka,包括: Kafka 体系架构 Kafka 消息发送机制 Kafka 副本机制 Kafka 控制器 Kafka Rebalance 机制 因为涉及内容较多,本文尽量做到深入浅出,全面的介绍 Kafka 原理及核心组件,不怕你不懂 Kafka。 1. Kafka 快速入门 Kafka 是一个分布式消息引擎与流处理平台,经常用做企业的消息总线、实时数据管道,有的还把它当做存储系统来使用。早期 Kafka 的定位是一个高吞吐的分布式消息系统,目前则演变成了一个成熟的分布式消息引擎,以及流处理平台。 1.1 Kafka 体系架构 Kafka 的设计遵循生产者消费者模式,生产者发送消息到 broker 中某一个 topic 的具体分区里,消费者从一个或多个分区中拉取数据进行消费。拓扑图如下: 目前,Kafka 依靠 Zookeeper 做分布式协调服务,负责存储和管理 Kafka 集群中的元数据信息,包括集群中的 broker 信息、topic 信息、topic 的分区与副本信息等。 ** 1.2 Kafka 术语** 这里整理了 Kafka 的一些关键术语: Producer:生产者,消息产生和发送端。 Broker:Kafka 实例,多个 broker 组成一个 Kafka 集群,通常一台机器部署一个 Kafka 实例,一个实例挂了不影响其他实例。 Consumer:消费者,拉取消息进行消费。 一个 topic 可以让若干个消费者进行消费,若干个消费者组成一个 Consumer Group 即消费组,一条消息只能被消费组中一个 Consumer 消费。 Topic:主题,服务端消息的逻辑存储单元。一个 topic 通常包含若干个 Partition 分区。 Partition:topic 的分区,分布式存储在各个 broker 中, 实现发布与订阅的负载均衡。若干个分区可以被若干个 Consumer 同时消费,达到消费者高吞吐量。一个分区拥有多个副本(Replica),这是Kafka在可靠性和可用性方面的设计,后面会重点介绍。 message:消息,或称日志消息,是 Kafka 服务端实际存储的数据,每一条消息都由一个 key、一个 value 以及消息时间戳 timestamp 组成。 offset:偏移量,分区中的消息位置,由 Kafka 自身维护,Consumer 消费时也要保存一份 offset 以维护消费过的消息位置。 1.3 Kafka 作用与特点 Kafka 主要起到削峰填谷(缓冲)、系统解构以及冗余的作用,主要特点有: 高吞吐、低延时:这是 Kafka 显著的特点,Kafka 能够达到百万级的消息吞吐量,延迟可达毫秒级; 持久化存储:Kafka 的消息最终持久化保存在磁盘之上,提供了顺序读写以保证性能,并且通过 Kafka 的副本机制提高了数据可靠性。 分布式可扩展:Kafka 的数据是分布式存储在不同 broker 节点的,以 topic 组织数据并且按 partition 进行分布式存储,整体的扩展性都非常好。 高容错性:集群中任意一个 broker 节点宕机,Kafka 仍能对外提供服务。 2. Kafka 消息发送机制 Kafka 生产端发送消息的机制非常重要,这也是 Kafka 高吞吐的基础,生产端的基本流程如下图所示: 主要有以下方面的设计: 2.1 异步发送 Kafka 自从 0.8.2 版本就引入了新版本 Producer API,新版 Producer 完全是采用异步方式发送消息。生产端构建的 ProducerRecord 先是经过 keySerializer、valueSerializer 序列化后,再是经过 Partition 分区器处理,决定消息落到 topic 具体某个分区中,最后把消息发送到客户端的消息缓冲池 accumulator 中,交由一个叫作 Sender 的线程发送到 broker 端。 这里缓冲池 accumulator 的最大大小由参数 buffer.memory 控制,默认是 32M,当生产消息的速度过快导致 buffer 满了的时候,将阻塞 max.block.ms 时间,超时抛异常,所以 buffer 的大小可以根据实际的业务情况进行适当调整。 2.2 批量发送 发送到缓冲 buffer 中消息将会被分为一个一个的 batch,分批次的发送到 broker 端,批次大小由参数 batch.size 控制,默认16KB。这就意味着正常情况下消息会攒够 16KB 时才会批量发送到 broker 端,所以一般减小 batch 大小有利于降低消息延时,增加 batch 大小有利于提升吞吐量。 那么生成端消息是不是必须要达到一个 batch 大小时,才会批量发送到服务端呢?答案是否定的,Kafka 生产端提供了另一个重要参数 linger.ms,该参数控制了 batch 最大的空闲时间,超过该时间的 batch 也会被发送到 broker 端。 2.3 消息重试 此外,Kafka 生产端支持重试机制,对于某些原因导致消息发送失败的,比如网络抖动,开启重试后 Producer 会尝试再次发送消息。该功能由参数 retries 控制,参数含义代表重试次数,默认值为 0 表示不重试,建议设置大于 0 比如 3。 3. Kafka 副本机制 前面提及了 Kafka 分区副本(Replica)的概念,副本机制也称 Replication 机制是 Kafka 实现高可靠、高可用的基础。Kafka 中有 leader 和 follower 两类副本。 3.1 Kafka 副本作用 Kafka 默认只会给分区设置一个副本,由 broker 端参数 default.replication.factor 控制,默认值为 1,通常我们会修改该默认值,或者命令行创建 topic 时指定 replication-factor 参数,生产建议设置 3 副本。副本作用主要有两方面: 消息冗余存储,提高 Kafka 数据的可靠性; 提高 Kafka 服务的可用性,follower 副本能够在 leader 副本挂掉或者 broker 宕机的时候参与 leader 选举,继续对外提供读写服务。 3.2 关于读写分离 这里要说明的是 Kafka 并不支持读写分区,生产消费端所有的读写请求都是由 leader 副本处理的,follower 副本的主要工作就是从 leader 副本处异步拉取消息,进行消息数据的同步,并不对外提供读写服务。 Kafka 之所以这样设计,主要是为了保证读写一致性,因为副本同步是一个异步的过程,如果当 follower 副本还没完全和 leader 同步时,从 follower 副本读取数据可能会读不到最新的消息。 3.3 ISR 副本集合 Kafka 为了维护分区副本的同步,引入 ISR(In-Sync Replicas)副本集合的概念,ISR 是分区中正在与 leader 副本进行同步的 replica 列表,且必定包含 leader 副本。 ISR 列表是持久化在 Zookeeper 中的,任何在 ISR 列表中的副本都有资格参与 leader 选举。 ISR 列表是动态变化的,并不是所有的分区副本都在 ISR 列表中,哪些副本会被包含在 ISR 列表中呢?副本被包含在 ISR 列表中的条件是由参数 replica.lag.time.max.ms 控制的,参数含义是副本同步落后于 leader 的最大时间间隔,默认10s,意思就是说如果某一 follower 副本中的消息比 leader 延时超过10s,就会被从 ISR 中排除。Kafka 之所以这样设计,主要是为了减少消息丢失,只有与 leader 副本进行实时同步的 follower 副本才有资格参与 leader 选举,这里指相对实时。 3.4 Unclean leader 选举 既然 ISR 是动态变化的,所以 ISR 列表就有为空的时候,ISR 为空说明 leader 副本也“挂掉”了,此时 Kafka 就要重新选举出新的 leader。但 ISR 为空,怎么进行 leader 选举呢? Kafka 把不在 ISR 列表中的存活副本称为“非同步副本”,这些副本中的消息远远落后于 leader,如果选举这种副本作为 leader 的话就可能造成数据丢失。Kafka broker 端提供了一个参数 unclean.leader.election.enable,用于控制是否允许非同步副本参与 leader 选举;如果开启,则当 ISR 为空时就会从这些副本中选举新的 leader,这个过程称为 Unclean leader 选举。 前面也提及了,如果开启 Unclean leader 选举,可能会造成数据丢失,但保证了始终有一个 leader 副本对外提供服务;如果禁用 Unclean leader 选举,就会避免数据丢失,但这时分区就会不可用。这就是典型的 CAP 理论,即一个系统不可能同时满足一致性(Consistency)、可用性(Availability)和分区容错性(Partition Tolerance)中的两个。所以在这个问题上,Kafka 赋予了我们选择 C 或 A 的权利。 我们可以根据实际的业务场景选择是否开启 Unclean leader选举,这里建议关闭 Unclean leader 选举,因为通常数据的一致性要比可用性重要的多。 4. Kafka 控制器 控制器(Controller)是 Kafka 的核心组件,它的主要作用是在 Zookeeper 的帮助下管理和协调整个 Kafka 集群。集群中任意一个 broker 都能充当控制器的角色,但在运行过程中,只能有一个 broker 成为控制器。 这里先介绍下 Zookeeper,因为控制器的产生依赖于 Zookeeper 的 ZNode 模型和 Watcher 机制。Zookeeper 的数据模型是类似 Unix 操作系统的 ZNode Tree 即 ZNode 树,ZNode 是 Zookeeper 中的数据节点,是 Zookeeper 存储数据的最小单元,每个 ZNode 可以保存数据,也可以挂载子节点,根节点是 /。基本的拓扑图如下: Zookeeper 有两类 ZNode 节点,分别是持久性节点和临时节点。持久性节点是指客户端与 Zookeeper 断开会话后,该节点依旧存在,直到执行删除操作才会清除节点。临时节点的生命周期是和客户端的会话绑定在一起,客户端与 Zookeeper 断开会话后,临时节点就会被自动删除。 Watcher 机制是 Zookeeper 非常重要的特性,它可以在 ZNode 节点上绑定监听事件,比如可以监听节点数据变更、节点删除、子节点状态变更等事件,通过这个事件机制,可以基于 ZooKeeper 实现分布式锁、集群管理等功能。 4.1 控制器选举 当集群中的任意 broker 启动时,都会尝试去 Zookeeper 中创建 /controller 节点,第一个成功创建 /controller 节点的 broker 则会被指定为控制器,其他 broker 则会监听该节点的变化。当运行中的控制器突然宕机或意外终止时,其他 broker 能够快速地感知到,然后再次尝试创建 /controller 节点,创建成功的 broker 会成为新的控制器。 4.2 控制器功能 前面我们也说了,控制器主要作用是管理和协调 Kafka 集群,那么 Kafka 控制器都做了哪些事情呢,具体如下: 主题管理:创建、删除 topic,以及增加 topic 分区等操作都是由控制器执行。 分区重分配:执行 Kafka 的 reassign 脚本对 topic 分区重分配的操作,也是由控制器实现。 Preferred leader 选举:这里有一个概念叫 Preferred replica 即优先副本,表示的是分配副本中的第一个副本。Preferred leader 选举就是指 Kafka 在某些情况下出现 leader 负载不均衡时,会选择 preferred 副本作为新 leader 的一种方案。这也是控制器的职责范围。 集群成员管理:控制器能够监控新 broker 的增加,broker 的主动关闭与被动宕机,进而做其他工作。这里也是利用前面所说的 Zookeeper 的 ZNode 模型和 Watcher 机制,控制器会监听 Zookeeper 中 /brokers/ids 下临时节点的变化。 数据服务:控制器上保存了最全的集群元数据信息,其他所有 broker 会定期接收控制器发来的元数据更新请求,从而更新其内存中的缓存数据。 从上面内容我们大概知道,控制器可以说是 Kafka 的心脏,管理和协调着整个 Kafka 集群,因此控制器自身的性能和稳定性就变得至关重要。 社区在这方面做了大量工作,特别是在 0.11 版本中对控制器进行了重构,其中最大的改进把控制器内部多线程的设计改成了单线程加事件队列的方案,消除了多线程的资源消耗和线程安全问题,另外一个改进是把之前同步操作 Zookeeper 改为了异步操作,消除了 Zookeeper 端的性能瓶颈,大大提升了控制器的稳定性。 5. Kafka 消费端 Rebalance 机制 前面介绍消费者术语时,提到了消费组的概念,一个 topic 可以让若干个消费者进行消费,若干个消费者组成一个 Consumer Group 即消费组 ,一条消息只能被消费组中的一个消费者进行消费。我们用下图表示Kafka的消费模型。 5.1 Rebalance 概念 就 Kafka 消费端而言,有一个难以避免的问题就是消费者的重平衡即 Rebalance。Rebalance 是让一个消费组的所有消费者就如何消费订阅 topic 的所有分区达成共识的过程,在 Rebalance 过程中,所有 Consumer 实例都会停止消费,等待 Rebalance 的完成。因为要停止消费等待重平衡完成,因此 Rebalance 会严重影响消费端的 TPS,是应当尽量避免的。 5.2 Rebalance 发生条件 关于何时会发生 Rebalance,总结起来有三种情况: 消费组的消费者成员数量发生变化 消费主题的数量发生变化 消费主题的分区数量发生变化 其中后两种情况一般是计划内的,比如为了提高消息吞吐量增加 topic 分区数,这些情况一般是不可避免的,后面我们会重点讨论如何避免因为组内消费者成员数发生变化导致的 Rebalance。 5.3 Kafka 协调器 在介绍如何避免 Rebalance 问题之前,先来认识下 Kafka 的协调器 Coordinator,和之前 Kafka 控制器类似,Coordinator 也是 Kafka 的核心组件。 主要有两类 Kafka 协调器: 组协调器(Group Coordinator) 消费者协调器(Consumer Coordinator) Kafka 为了更好的实现消费组成员管理、位移管理,以及 Rebalance 等,broker 服务端引入了组协调器(Group Coordinator),消费端引入了消费者协调器(Consumer Coordinator)。每个 broker 启动的时候,都会创建一个 GroupCoordinator 实例,负责消费组注册、消费者成员记录、offset 等元数据操作,这里也可以看出每个 broker 都有自己的 Coordinator 组件。另外,每个 Consumer 实例化时,同时会创建一个 ConsumerCoordinator 实例,负责消费组下各个消费者和服务端组协调器之前的通信。可以用下图表示协调器原理: 客户端的消费者协调器 Consumer Coordinator 和服务端的组协调器 Group Coordinator 会通过心跳不断保持通信。 5.4 如何避免消费组 Rebalance 接下来我们讨论下如何避免组内消费者成员发生变化导致的 Rebalance。组内成员发生变化无非就两种情况,一种是有新的消费者加入,通常是我们为了提高消费速度增加了消费者数量,比如增加了消费线程或者多部署了一份消费程序,这种情况可以认为是正常的;另一种是有消费者退出,这种情况多是和我们消费端代码有关,是我们要重点避免的。 正常情况下,每个消费者都会定期向组协调器 Group Coordinator 发送心跳,表明自己还在存活,如果消费者不能及时的发送心跳,组协调器会认为该消费者已经“死”了,就会导致消费者离组引发 Rebalance 问题。这里涉及两个消费端参数:session.timeout.ms 和 heartbeat.interval.ms,含义分别是组协调器认为消费组存活的期限,和消费者发送心跳的时间间隔,其中 heartbeat.interval.ms 默认值是3s,session.timeout.ms 在 0.10.1 版本之前默认 30s,之后默认 10s。另外,0.10.1 版本还有两个值得注意的地方: 从该版本开始,Kafka 维护了单独的心跳线程,之前版本中 Kafka 是使用业务主线程发送的心跳。 增加了一个重要的参数 max.poll.interval.ms,表示 Consumer 两次调用 poll 方法拉取数据的最大时间间隔,默认值 5min,对于那些忙于业务逻辑处理导致超过 max.poll.interval.ms 时间的消费者将会离开消费组,此时将发生一次 Rebalance。 此外,如果 Consumer 端频繁 FullGC 也可能会导致消费端长时间停顿,从而引发 Rebalance。因此,我们总结如何避免消费组 Rebalance 问题,主要从以下几方面入手: 合理配置 session.timeout.ms 和 heartbeat.interval.ms,建议 0.10.1 之前适当调大 session 超时时间尽量规避 Rebalance。 根据实际业务调整 max.poll.interval.ms,通常建议调大避免 Rebalance,但注意 0.10.1 版本之前没有该参数。 监控消费端的 GC 情况,避免由于频繁 FullGC 导致线程长时间停顿引发 Rebalance。 合理调整以上参数,可以减少生产环境中 Rebalance 发生的几率,提升 Consumer 端的 TPS 和稳定性。 6.总结 本文总结了 Kafka 体系架构、Kafka 消息发送机制、副本机制,Kafka 控制器、消费端 Rebalance 机制等各方面核心原理,通过本文的介绍,相信你已经对 Kafka 的内核知识有了一定的掌握,更多的 Kafka 原理实践后面有时间再介绍。
剑曼红尘 2020-04-16 18:15:45 0 浏览量 回答数 0

回答

漏洞扫描有以下四种检测技术:   1.基于应用的检测技术。它采用被动的、非破坏性的办法检查应用软件包的设置,发现安全漏洞。   2.基于主机的检测技术。它采用被动的、非破坏性的办法对系统进行检测。通常,它涉及到系统的内核、文件的属性、操作系统的补丁等。这种技术还包括口令解密、把一些简单的口令剔除。因此,这种技术可以非常准确地定位系统的问题,发现系统的漏洞。它的缺点是与平台相关,升级复杂。   3.基于目标的漏洞检测技术。它采用被动的、非破坏性的办法检查系统属性和文件属性,如数据库、注册号等。通过消息文摘算法,对文件的加密数进行检验。这种技术的实现是运行在一个闭环上,不断地处理文件、系统目标、系统目标属性,然后产生检验数,把这些检验数同原来的检验数相比较。一旦发现改变就通知管理员。   4.基于网络的检测技术。它采用积极的、非破坏性的办法来检验系统是否有可能被攻击崩溃。它利用了一系列的脚本模拟对系统进行攻击的行为,然后对结果进行分析。它还针对已知的网络漏洞进行检验。网络检测技术常被用来进行穿透实验和安全审记。这种技术可以发现一系列平台的漏洞,也容易安装。但是,它可能会影响网络的性能。   网络漏洞扫描   在上述四种方式当中,网络漏洞扫描最为适合我们的Web信息系统的风险评估工作,其扫描原理和工作原理为:通过远程检测目标主机TCP/IP不同端口的服务,记录目标的回答。通过这种方法,可以搜集到很多目标主机的各种信息(例如:是否能用匿名登录,是否有可写的FTP目录,是否能用Telnet,httpd是否是用root在运行)。   在获得目标主机TCP/IP端口和其对应的网络访问服务的相关信息后,与网络漏洞扫描系统提供的漏洞库进行匹配,如果满足匹配条件,则视为漏洞存在。此外,通过模拟黑客的进攻手法,对目标主机系统进行攻击性的安全漏洞扫描,如测试弱势口令等,也是扫描模块的实现方法之一。如果模拟攻击成功,则视为漏洞存在。   在匹配原理上,网络漏洞扫描器采用的是基于规则的匹配技术,即根据安全专家对网络系统安全漏洞、黑客攻击案例的分析和系统管理员关于网络系统安全配置的实际经验,形成一套标准的系统漏洞库,然后再在此基础之上构成相应的匹配规则,由程序自动进行系统漏洞扫描的分析工作。   所谓基于规则是基于一套由专家经验事先定义的规则的匹配系统。例如,在对TCP80端口的扫描中,如果发现/cgi-bin/phf/cgi-bin/Count.cgi,根据专家经验以及CGI程序的共享性和标准化,可以推知该WWW服务存在两个CGI漏洞。同时应当说明的是,基于规则的匹配系统有其局限性,因为作为这类系统的基础的推理规则一般都是根据已知的安全漏洞进行安排和策划的,而对网络系统的很多危险的威胁是来自未知的安全漏洞,这一点和PC杀毒很相似。   这种漏洞扫描器是基于浏览器/服务器(B/S)结构。它的工作原理是:当用户通过控制平台发出了扫描命令之后,控制平台即向扫描模块发出相应的扫描请求,扫描模块在接到请求之后立即启动相应的子功能模块,对被扫描主机进行扫描。通过分析被扫描主机返回的信息进行判断,扫描模块将扫描结果返回给控制平台,再由控制平台最终呈现给用户。   另一种结构的扫描器是采用插件程序结构。可以针对某一具体漏洞,编写对应的外部测试脚本。通过调用服务检测插件,检测目标主机TCP/IP不同端口的服务,并将结果保存在信息库中,然后调用相应的插件程序,向远程主机发送构造好的数据,检测结果同样保存于信息库,以给其他的脚本运行提供所需的信息,这样可提高检测效率。如,在针对某FTP服务的攻击中,可以首先查看服务检测插件的返回结果,只有在确认目标主机服务器开启FTP服务时,对应的针对某FTP服务的攻击脚本才能被执行。采用这种插件结构的扫描器,可以让任何人构造自己的攻击测试脚本,而不用去了解太多扫描器的原理。这种扫描器也可以用做模拟黑客攻击的平台。采用这种结构的扫描器具有很强的生命力,如着名的Nessus就是采用这种结构。这种网络漏洞扫描器的结构如图2所示,它是基于客户端/服务器(C/S)结构,其中客户端主要设置服务器端的扫描参数及收集扫描信息。具体扫描工作由服务器来完成。 答案来源于网络
养狐狸的猫 2019-12-02 02:16:47 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 阿里云内容分发网络(Alibaba Cloud Content Delivery Network,简称CDN)将您源站资源缓存至阿里云遍布全球的加速节点上。当终端用户请求访问和获取这些资源时,无需回源,系统将就近调用CDN节点上已经缓存的资源。 在不同区域、不同场景下使用CDN加速您网站内容的分发,将有效分担源站压力,避免网络拥塞,提升用户访问资源的速度和体验。您可以参考快速入门 快速接入阿里云CDN。 工作原理 通过以下案例,您可以清楚地了解CDN的工作原理。 假设您的源站域名为 www.a.com。接入 CDN 开始使用加速服务后,当您的终端用户(北京)发起 HTTP 请求时,实际的处理流程如下: 终端用户(北京) 向 www.a.com下的某资源发起请求,会先向 LDNS 发起域名解析请求。 当 LDNS 解析 www.a.com 时,会发现已经配置了 CNAME www.a.tbcdn.com。 解析请求会发送至阿里云DNS调度系统,并为请求分配最佳节点 IP。 LDNS 获取 DNS 返回的解析 IP。 用户获取解析 IP。 用户向获取的 IP 发起对该资源的访问请求。 若该 IP 对应的节点已经缓存了该资源,则会将数据直接返回给用户(如图中步骤7、8),此时请求结束。 若该节点未缓存该资源,则节点会向业务源站发起对该资源的请求。获取资源后,结合用户自定义配置的缓存策略(可参考产品文档中的 缓存过期配置),将资源缓存至节点(如图:北京节点),并返回给用户,此时请求结束。 相关概念 CNAME:即别名( Canonical Name ),可以用来把一个域名解析到另一个域名。 回源HOST:使用回源HOST,您可以自定义CDN节点回源时所需访问的具体服务器域名。 协议回源:开启该功能后,回源使用协议和客户端访问资源的协议保持一致。 过滤参数:URL请求中,如果携带“?” (半角)和参数,则请求到CDN节点时,CDN节点在收到该请求后是否将该带参数的请求URL请求回源站。 使用CDN 您可以查看CDN学习路径,快速了解并上手CDN。 您可以登录CDN控制台,了解并使用了CDN的全部功能。 您还可以使用CDN的API,更灵活地帮助您的业务。 CDN定价 CDN的定价策略:基础服务和 增值服务。其中,基础服务可以按流量或带宽两种方式计算。 更多CDN定价策略,请参考产品价格。 相关服务 CDN子产品 您可以使用全站加速区分动静态资源,并实现动静态资源分别加速。 您可以使用安全加速SCDN兼顾加速与安全两个业务目标。 您可以使用PCDN显著降低分发成本,并应用在视频点播、直播、大文件下载等业务场景。 相关产品 您可以在对象存储OSS中使用CDN加速,提高网站访问速度,有效降低OSS的外网流量费用。 您可以在视频直播中应用CDN,实现媒资存储、切片转码、访问鉴权、内容分发加速一体化解决方案。 您可以在视频点播中应用CDN,减少缓冲时间,实现高流畅度的播放体验。 您可以借助阿里云云解析提供的强大稳定的解析调度入口,确保顺畅的访问体验。 您可以借助云服务器ECS提高网站可用性,保护服务器源站信息,降低带宽使用成本。 您可以将负载均衡服务器的IP地址设置为回源地址,降低回源带宽压力。
2019-12-01 23:09:50 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 阿里云内容分发网络(Alibaba Cloud Content Delivery Network,简称CDN)将您源站资源缓存至阿里云遍布全球的加速节点上。当终端用户请求访问和获取这些资源时,无需回源,系统将就近调用CDN节点上已经缓存的资源。 在不同区域、不同场景下使用CDN加速您网站内容的分发,将有效分担源站压力,避免网络拥塞,提升用户访问资源的速度和体验。您可以参考快速入门 快速接入阿里云CDN。 工作原理 通过以下案例,您可以清楚地了解CDN的工作原理。 假设您的源站域名为 www.a.com。接入 CDN 开始使用加速服务后,当您的终端用户(北京)发起 HTTP 请求时,实际的处理流程如下: 终端用户(北京) 向 www.a.com下的某资源发起请求,会先向 LDNS 发起域名解析请求。 当 LDNS 解析 www.a.com 时,会发现已经配置了 CNAME www.a.tbcdn.com。 解析请求会发送至阿里云DNS调度系统,并为请求分配最佳节点 IP。 LDNS 获取 DNS 返回的解析 IP。 用户获取解析 IP。 用户向获取的 IP 发起对该资源的访问请求。 若该 IP 对应的节点已经缓存了该资源,则会将数据直接返回给用户(如图中步骤7、8),此时请求结束。 若该节点未缓存该资源,则节点会向业务源站发起对该资源的请求。获取资源后,结合用户自定义配置的缓存策略(可参考产品文档中的 缓存过期配置),将资源缓存至节点(如图:北京节点),并返回给用户,此时请求结束。 相关概念 CNAME:即别名( Canonical Name ),可以用来把一个域名解析到另一个域名。 回源HOST:使用回源HOST,您可以自定义CDN节点回源时所需访问的具体服务器域名。 协议回源:开启该功能后,回源使用协议和客户端访问资源的协议保持一致。 过滤参数:URL请求中,如果携带“?” (半角)和参数,则请求到CDN节点时,CDN节点在收到该请求后是否将该带参数的请求URL请求回源站。 使用CDN 您可以查看CDN学习路径,快速了解并上手CDN。 您可以登录CDN控制台,了解并使用了CDN的全部功能。 您还可以使用CDN的API,更灵活地帮助您的业务。 CDN定价 CDN的定价策略:基础服务和 增值服务。其中,基础服务可以按流量或带宽两种方式计算。 更多CDN定价策略,请参考产品价格。 相关服务 CDN子产品 您可以使用全站加速区分动静态资源,并实现动静态资源分别加速。 您可以使用安全加速SCDN兼顾加速与安全两个业务目标。 您可以使用PCDN显著降低分发成本,并应用在视频点播、直播、大文件下载等业务场景。 相关产品 您可以在对象存储OSS中使用CDN加速,提高网站访问速度,有效降低OSS的外网流量费用。 您可以在视频直播中应用CDN,实现媒资存储、切片转码、访问鉴权、内容分发加速一体化解决方案。 您可以在视频点播中应用CDN,减少缓冲时间,实现高流畅度的播放体验。 您可以借助阿里云云解析提供的强大稳定的解析调度入口,确保顺畅的访问体验。 您可以借助云服务器ECS提高网站可用性,保护服务器源站信息,降低带宽使用成本。 您可以将负载均衡服务器的IP地址设置为回源地址,降低回源带宽压力。
2019-12-01 23:09:50 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 阿里云内容分发网络(Alibaba Cloud Content Delivery Network,简称CDN)将您源站资源缓存至阿里云遍布全球的加速节点上。当终端用户请求访问和获取这些资源时,无需回源,系统将就近调用CDN节点上已经缓存的资源。 在不同区域、不同场景下使用CDN加速您网站内容的分发,将有效分担源站压力,避免网络拥塞,提升用户访问资源的速度和体验。您可以参考快速入门 快速接入阿里云CDN。 工作原理 通过以下案例,您可以清楚地了解CDN的工作原理。 假设您的源站域名为 www.a.com。接入 CDN 开始使用加速服务后,当您的终端用户(北京)发起 HTTP 请求时,实际的处理流程如下: 终端用户(北京) 向 www.a.com下的某资源发起请求,会先向 LDNS 发起域名解析请求。 当 LDNS 解析 www.a.com 时,会发现已经配置了 CNAME www.a.tbcdn.com。 解析请求会发送至阿里云DNS调度系统,并为请求分配最佳节点 IP。 LDNS 获取 DNS 返回的解析 IP。 用户获取解析 IP。 用户向获取的 IP 发起对该资源的访问请求。 若该 IP 对应的节点已经缓存了该资源,则会将数据直接返回给用户(如图中步骤7、8),此时请求结束。 若该节点未缓存该资源,则节点会向业务源站发起对该资源的请求。获取资源后,结合用户自定义配置的缓存策略(可参考产品文档中的 缓存过期配置),将资源缓存至节点(如图:北京节点),并返回给用户,此时请求结束。 相关概念 CNAME:即别名( Canonical Name ),可以用来把一个域名解析到另一个域名。 回源HOST:使用回源HOST,您可以自定义CDN节点回源时所需访问的具体服务器域名。 协议回源:开启该功能后,回源使用协议和客户端访问资源的协议保持一致。 过滤参数:URL请求中,如果携带“?” (半角)和参数,则请求到CDN节点时,CDN节点在收到该请求后是否将该带参数的请求URL请求回源站。 使用CDN 您可以查看CDN学习路径,快速了解并上手CDN。 您可以登录CDN控制台,了解并使用了CDN的全部功能。 您还可以使用CDN的API,更灵活地帮助您的业务。 CDN定价 CDN的定价策略:基础服务和 增值服务。其中,基础服务可以按流量或带宽两种方式计算。 更多CDN定价策略,请参考产品价格。 相关服务 CDN子产品 您可以使用全站加速区分动静态资源,并实现动静态资源分别加速。 您可以使用安全加速SCDN兼顾加速与安全两个业务目标。 您可以使用PCDN显著降低分发成本,并应用在视频点播、直播、大文件下载等业务场景。 相关产品 您可以在对象存储OSS中使用CDN加速,提高网站访问速度,有效降低OSS的外网流量费用。 您可以在视频直播中应用CDN,实现媒资存储、切片转码、访问鉴权、内容分发加速一体化解决方案。 您可以在视频点播中应用CDN,减少缓冲时间,实现高流畅度的播放体验。 您可以借助阿里云云解析提供的强大稳定的解析调度入口,确保顺畅的访问体验。 您可以借助云服务器ECS提高网站可用性,保护服务器源站信息,降低带宽使用成本。 您可以将负载均衡服务器的IP地址设置为回源地址,降低回源带宽压力。
2019-12-01 23:09:49 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 阿里云内容分发网络(Alibaba Cloud Content Delivery Network,简称CDN)将您源站资源缓存至阿里云遍布全球的加速节点上。当终端用户请求访问和获取这些资源时,无需回源,系统将就近调用CDN节点上已经缓存的资源。 在不同区域、不同场景下使用CDN加速您网站内容的分发,将有效分担源站压力,避免网络拥塞,提升用户访问资源的速度和体验。您可以参考快速入门 快速接入阿里云CDN。 工作原理 通过以下案例,您可以清楚地了解CDN的工作原理。 假设您的源站域名为 www.a.com。接入 CDN 开始使用加速服务后,当您的终端用户(北京)发起 HTTP 请求时,实际的处理流程如下: 终端用户(北京) 向 www.a.com下的某资源发起请求,会先向 LDNS 发起域名解析请求。 当 LDNS 解析 www.a.com 时,会发现已经配置了 CNAME www.a.tbcdn.com。 解析请求会发送至阿里云DNS调度系统,并为请求分配最佳节点 IP。 LDNS 获取 DNS 返回的解析 IP。 用户获取解析 IP。 用户向获取的 IP 发起对该资源的访问请求。 若该 IP 对应的节点已经缓存了该资源,则会将数据直接返回给用户(如图中步骤7、8),此时请求结束。 若该节点未缓存该资源,则节点会向业务源站发起对该资源的请求。获取资源后,结合用户自定义配置的缓存策略(可参考产品文档中的 缓存过期配置),将资源缓存至节点(如图:北京节点),并返回给用户,此时请求结束。 相关概念 CNAME:即别名( Canonical Name ),可以用来把一个域名解析到另一个域名。 回源HOST:使用回源HOST,您可以自定义CDN节点回源时所需访问的具体服务器域名。 协议回源:开启该功能后,回源使用协议和客户端访问资源的协议保持一致。 过滤参数:URL请求中,如果携带“?” (半角)和参数,则请求到CDN节点时,CDN节点在收到该请求后是否将该带参数的请求URL请求回源站。 使用CDN 您可以查看CDN学习路径,快速了解并上手CDN。 您可以登录CDN控制台,了解并使用了CDN的全部功能。 您还可以使用CDN的API,更灵活地帮助您的业务。 CDN定价 CDN的定价策略:基础服务和 增值服务。其中,基础服务可以按流量或带宽两种方式计算。 更多CDN定价策略,请参考产品价格。 相关服务 CDN子产品 您可以使用全站加速区分动静态资源,并实现动静态资源分别加速。 您可以使用安全加速SCDN兼顾加速与安全两个业务目标。 您可以使用PCDN显著降低分发成本,并应用在视频点播、直播、大文件下载等业务场景。 相关产品 您可以在对象存储OSS中使用CDN加速,提高网站访问速度,有效降低OSS的外网流量费用。 您可以在视频直播中应用CDN,实现媒资存储、切片转码、访问鉴权、内容分发加速一体化解决方案。 您可以在视频点播中应用CDN,减少缓冲时间,实现高流畅度的播放体验。 您可以借助阿里云云解析提供的强大稳定的解析调度入口,确保顺畅的访问体验。 您可以借助云服务器ECS提高网站可用性,保护服务器源站信息,降低带宽使用成本。 您可以将负载均衡服务器的IP地址设置为回源地址,降低回源带宽压力。
2019-12-01 23:09:50 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 阿里云内容分发网络(Alibaba Cloud Content Delivery Network,简称CDN)将您源站资源缓存至阿里云遍布全球的加速节点上。当终端用户请求访问和获取这些资源时,无需回源,系统将就近调用CDN节点上已经缓存的资源。 在不同区域、不同场景下使用CDN加速您网站内容的分发,将有效分担源站压力,避免网络拥塞,提升用户访问资源的速度和体验。您可以参考快速入门 快速接入阿里云CDN。 工作原理 通过以下案例,您可以清楚地了解CDN的工作原理。 假设您的源站域名为 www.a.com。接入 CDN 开始使用加速服务后,当您的终端用户(北京)发起 HTTP 请求时,实际的处理流程如下: 终端用户(北京) 向 www.a.com下的某资源发起请求,会先向 LDNS 发起域名解析请求。 当 LDNS 解析 www.a.com 时,会发现已经配置了 CNAME www.a.tbcdn.com。 解析请求会发送至阿里云DNS调度系统,并为请求分配最佳节点 IP。 LDNS 获取 DNS 返回的解析 IP。 用户获取解析 IP。 用户向获取的 IP 发起对该资源的访问请求。 若该 IP 对应的节点已经缓存了该资源,则会将数据直接返回给用户(如图中步骤7、8),此时请求结束。 若该节点未缓存该资源,则节点会向业务源站发起对该资源的请求。获取资源后,结合用户自定义配置的缓存策略(可参考产品文档中的 缓存过期配置),将资源缓存至节点(如图:北京节点),并返回给用户,此时请求结束。 相关概念 CNAME:即别名( Canonical Name ),可以用来把一个域名解析到另一个域名。 回源HOST:使用回源HOST,您可以自定义CDN节点回源时所需访问的具体服务器域名。 协议回源:开启该功能后,回源使用协议和客户端访问资源的协议保持一致。 过滤参数:URL请求中,如果携带“?” (半角)和参数,则请求到CDN节点时,CDN节点在收到该请求后是否将该带参数的请求URL请求回源站。 使用CDN 您可以查看CDN学习路径,快速了解并上手CDN。 您可以登录CDN控制台,了解并使用了CDN的全部功能。 您还可以使用CDN的API,更灵活地帮助您的业务。 CDN定价 CDN的定价策略:基础服务和 增值服务。其中,基础服务可以按流量或带宽两种方式计算。 更多CDN定价策略,请参考产品价格。 相关服务 CDN子产品 您可以使用全站加速区分动静态资源,并实现动静态资源分别加速。 您可以使用安全加速SCDN兼顾加速与安全两个业务目标。 您可以使用PCDN显著降低分发成本,并应用在视频点播、直播、大文件下载等业务场景。 相关产品 您可以在对象存储OSS中使用CDN加速,提高网站访问速度,有效降低OSS的外网流量费用。 您可以在视频直播中应用CDN,实现媒资存储、切片转码、访问鉴权、内容分发加速一体化解决方案。 您可以在视频点播中应用CDN,减少缓冲时间,实现高流畅度的播放体验。 您可以借助阿里云云解析提供的强大稳定的解析调度入口,确保顺畅的访问体验。 您可以借助云服务器ECS提高网站可用性,保护服务器源站信息,降低带宽使用成本。 您可以将负载均衡服务器的IP地址设置为回源地址,降低回源带宽压力。
2019-12-01 23:09:51 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 阿里云内容分发网络(Alibaba Cloud Content Delivery Network,简称CDN)将您源站资源缓存至阿里云遍布全球的加速节点上。当终端用户请求访问和获取这些资源时,无需回源,系统将就近调用CDN节点上已经缓存的资源。 在不同区域、不同场景下使用CDN加速您网站内容的分发,将有效分担源站压力,避免网络拥塞,提升用户访问资源的速度和体验。您可以参考快速入门 快速接入阿里云CDN。 工作原理 通过以下案例,您可以清楚地了解CDN的工作原理。 假设您的源站域名为 www.a.com。接入 CDN 开始使用加速服务后,当您的终端用户(北京)发起 HTTP 请求时,实际的处理流程如下: 终端用户(北京) 向 www.a.com下的某资源发起请求,会先向 LDNS 发起域名解析请求。 当 LDNS 解析 www.a.com 时,会发现已经配置了 CNAME www.a.tbcdn.com。 解析请求会发送至阿里云DNS调度系统,并为请求分配最佳节点 IP。 LDNS 获取 DNS 返回的解析 IP。 用户获取解析 IP。 用户向获取的 IP 发起对该资源的访问请求。 若该 IP 对应的节点已经缓存了该资源,则会将数据直接返回给用户(如图中步骤7、8),此时请求结束。 若该节点未缓存该资源,则节点会向业务源站发起对该资源的请求。获取资源后,结合用户自定义配置的缓存策略(可参考产品文档中的 缓存过期配置),将资源缓存至节点(如图:北京节点),并返回给用户,此时请求结束。 相关概念 CNAME:即别名( Canonical Name ),可以用来把一个域名解析到另一个域名。 回源HOST:使用回源HOST,您可以自定义CDN节点回源时所需访问的具体服务器域名。 协议回源:开启该功能后,回源使用协议和客户端访问资源的协议保持一致。 过滤参数:URL请求中,如果携带“?” (半角)和参数,则请求到CDN节点时,CDN节点在收到该请求后是否将该带参数的请求URL请求回源站。 使用CDN 您可以查看CDN学习路径,快速了解并上手CDN。 您可以登录CDN控制台,了解并使用了CDN的全部功能。 您还可以使用CDN的API,更灵活地帮助您的业务。 CDN定价 CDN的定价策略:基础服务和 增值服务。其中,基础服务可以按流量或带宽两种方式计算。 更多CDN定价策略,请参考产品价格。 相关服务 CDN子产品 您可以使用全站加速区分动静态资源,并实现动静态资源分别加速。 您可以使用安全加速SCDN兼顾加速与安全两个业务目标。 您可以使用PCDN显著降低分发成本,并应用在视频点播、直播、大文件下载等业务场景。 相关产品 您可以在对象存储OSS中使用CDN加速,提高网站访问速度,有效降低OSS的外网流量费用。 您可以在视频直播中应用CDN,实现媒资存储、切片转码、访问鉴权、内容分发加速一体化解决方案。 您可以在视频点播中应用CDN,减少缓冲时间,实现高流畅度的播放体验。 您可以借助阿里云云解析提供的强大稳定的解析调度入口,确保顺畅的访问体验。 您可以借助云服务器ECS提高网站可用性,保护服务器源站信息,降低带宽使用成本。 您可以将负载均衡服务器的IP地址设置为回源地址,降低回源带宽压力。
2019-12-01 23:09:50 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 阿里云内容分发网络(Alibaba Cloud Content Delivery Network,简称CDN)将您源站资源缓存至阿里云遍布全球的加速节点上。当终端用户请求访问和获取这些资源时,无需回源,系统将就近调用CDN节点上已经缓存的资源。 在不同区域、不同场景下使用CDN加速您网站内容的分发,将有效分担源站压力,避免网络拥塞,提升用户访问资源的速度和体验。您可以参考快速入门 快速接入阿里云CDN。 工作原理 通过以下案例,您可以清楚地了解CDN的工作原理。 假设您的源站域名为 www.a.com。接入 CDN 开始使用加速服务后,当您的终端用户(北京)发起 HTTP 请求时,实际的处理流程如下: 终端用户(北京) 向 www.a.com下的某资源发起请求,会先向 LDNS 发起域名解析请求。 当 LDNS 解析 www.a.com 时,会发现已经配置了 CNAME www.a.tbcdn.com。 解析请求会发送至阿里云DNS调度系统,并为请求分配最佳节点 IP。 LDNS 获取 DNS 返回的解析 IP。 用户获取解析 IP。 用户向获取的 IP 发起对该资源的访问请求。 若该 IP 对应的节点已经缓存了该资源,则会将数据直接返回给用户(如图中步骤7、8),此时请求结束。 若该节点未缓存该资源,则节点会向业务源站发起对该资源的请求。获取资源后,结合用户自定义配置的缓存策略(可参考产品文档中的 缓存过期配置),将资源缓存至节点(如图:北京节点),并返回给用户,此时请求结束。 相关概念 CNAME:即别名( Canonical Name ),可以用来把一个域名解析到另一个域名。 回源HOST:使用回源HOST,您可以自定义CDN节点回源时所需访问的具体服务器域名。 协议回源:开启该功能后,回源使用协议和客户端访问资源的协议保持一致。 过滤参数:URL请求中,如果携带“?” (半角)和参数,则请求到CDN节点时,CDN节点在收到该请求后是否将该带参数的请求URL请求回源站。 使用CDN 您可以查看CDN学习路径,快速了解并上手CDN。 您可以登录CDN控制台,了解并使用了CDN的全部功能。 您还可以使用CDN的API,更灵活地帮助您的业务。 CDN定价 CDN的定价策略:基础服务和 增值服务。其中,基础服务可以按流量或带宽两种方式计算。 更多CDN定价策略,请参考产品价格。 相关服务 CDN子产品 您可以使用全站加速区分动静态资源,并实现动静态资源分别加速。 您可以使用安全加速SCDN兼顾加速与安全两个业务目标。 您可以使用PCDN显著降低分发成本,并应用在视频点播、直播、大文件下载等业务场景。 相关产品 您可以在对象存储OSS中使用CDN加速,提高网站访问速度,有效降低OSS的外网流量费用。 您可以在视频直播中应用CDN,实现媒资存储、切片转码、访问鉴权、内容分发加速一体化解决方案。 您可以在视频点播中应用CDN,减少缓冲时间,实现高流畅度的播放体验。 您可以借助阿里云云解析提供的强大稳定的解析调度入口,确保顺畅的访问体验。 您可以借助云服务器ECS提高网站可用性,保护服务器源站信息,降低带宽使用成本。 您可以将负载均衡服务器的IP地址设置为回源地址,降低回源带宽压力。
2019-12-01 23:09:50 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 阿里云内容分发网络(Alibaba Cloud Content Delivery Network,简称CDN)将您源站资源缓存至阿里云遍布全球的加速节点上。当终端用户请求访问和获取这些资源时,无需回源,系统将就近调用CDN节点上已经缓存的资源。 在不同区域、不同场景下使用CDN加速您网站内容的分发,将有效分担源站压力,避免网络拥塞,提升用户访问资源的速度和体验。您可以参考快速入门 快速接入阿里云CDN。 工作原理 通过以下案例,您可以清楚地了解CDN的工作原理。 假设您的源站域名为 www.a.com。接入 CDN 开始使用加速服务后,当您的终端用户(北京)发起 HTTP 请求时,实际的处理流程如下: 终端用户(北京) 向 www.a.com下的某资源发起请求,会先向 LDNS 发起域名解析请求。 当 LDNS 解析 www.a.com 时,会发现已经配置了 CNAME www.a.tbcdn.com。 解析请求会发送至阿里云DNS调度系统,并为请求分配最佳节点 IP。 LDNS 获取 DNS 返回的解析 IP。 用户获取解析 IP。 用户向获取的 IP 发起对该资源的访问请求。 若该 IP 对应的节点已经缓存了该资源,则会将数据直接返回给用户(如图中步骤7、8),此时请求结束。 若该节点未缓存该资源,则节点会向业务源站发起对该资源的请求。获取资源后,结合用户自定义配置的缓存策略(可参考产品文档中的 缓存过期配置),将资源缓存至节点(如图:北京节点),并返回给用户,此时请求结束。 相关概念 CNAME:即别名( Canonical Name ),可以用来把一个域名解析到另一个域名。 回源HOST:使用回源HOST,您可以自定义CDN节点回源时所需访问的具体服务器域名。 协议回源:开启该功能后,回源使用协议和客户端访问资源的协议保持一致。 过滤参数:URL请求中,如果携带“?” (半角)和参数,则请求到CDN节点时,CDN节点在收到该请求后是否将该带参数的请求URL请求回源站。 使用CDN 您可以查看CDN学习路径,快速了解并上手CDN。 您可以登录CDN控制台,了解并使用了CDN的全部功能。 您还可以使用CDN的API,更灵活地帮助您的业务。 CDN定价 CDN的定价策略:基础服务和 增值服务。其中,基础服务可以按流量或带宽两种方式计算。 更多CDN定价策略,请参考产品价格。 相关服务 CDN子产品 您可以使用全站加速区分动静态资源,并实现动静态资源分别加速。 您可以使用安全加速SCDN兼顾加速与安全两个业务目标。 您可以使用PCDN显著降低分发成本,并应用在视频点播、直播、大文件下载等业务场景。 相关产品 您可以在对象存储OSS中使用CDN加速,提高网站访问速度,有效降低OSS的外网流量费用。 您可以在视频直播中应用CDN,实现媒资存储、切片转码、访问鉴权、内容分发加速一体化解决方案。 您可以在视频点播中应用CDN,减少缓冲时间,实现高流畅度的播放体验。 您可以借助阿里云云解析提供的强大稳定的解析调度入口,确保顺畅的访问体验。 您可以借助云服务器ECS提高网站可用性,保护服务器源站信息,降低带宽使用成本。 您可以将负载均衡服务器的IP地址设置为回源地址,降低回源带宽压力。
2019-12-01 23:09:51 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 阿里云内容分发网络(Alibaba Cloud Content Delivery Network,简称CDN)将您源站资源缓存至阿里云遍布全球的加速节点上。当终端用户请求访问和获取这些资源时,无需回源,系统将就近调用CDN节点上已经缓存的资源。 在不同区域、不同场景下使用CDN加速您网站内容的分发,将有效分担源站压力,避免网络拥塞,提升用户访问资源的速度和体验。您可以参考快速入门 快速接入阿里云CDN。 工作原理 通过以下案例,您可以清楚地了解CDN的工作原理。 假设您的源站域名为 www.a.com。接入 CDN 开始使用加速服务后,当您的终端用户(北京)发起 HTTP 请求时,实际的处理流程如下: 终端用户(北京) 向 www.a.com下的某资源发起请求,会先向 LDNS 发起域名解析请求。 当 LDNS 解析 www.a.com 时,会发现已经配置了 CNAME www.a.tbcdn.com。 解析请求会发送至阿里云DNS调度系统,并为请求分配最佳节点 IP。 LDNS 获取 DNS 返回的解析 IP。 用户获取解析 IP。 用户向获取的 IP 发起对该资源的访问请求。 若该 IP 对应的节点已经缓存了该资源,则会将数据直接返回给用户(如图中步骤7、8),此时请求结束。 若该节点未缓存该资源,则节点会向业务源站发起对该资源的请求。获取资源后,结合用户自定义配置的缓存策略(可参考产品文档中的 缓存过期配置),将资源缓存至节点(如图:北京节点),并返回给用户,此时请求结束。 相关概念 CNAME:即别名( Canonical Name ),可以用来把一个域名解析到另一个域名。 回源HOST:使用回源HOST,您可以自定义CDN节点回源时所需访问的具体服务器域名。 协议回源:开启该功能后,回源使用协议和客户端访问资源的协议保持一致。 过滤参数:URL请求中,如果携带“?” (半角)和参数,则请求到CDN节点时,CDN节点在收到该请求后是否将该带参数的请求URL请求回源站。 使用CDN 您可以查看CDN学习路径,快速了解并上手CDN。 您可以登录CDN控制台,了解并使用了CDN的全部功能。 您还可以使用CDN的API,更灵活地帮助您的业务。 CDN定价 CDN的定价策略:基础服务和 增值服务。其中,基础服务可以按流量或带宽两种方式计算。 更多CDN定价策略,请参考产品价格。 相关服务 CDN子产品 您可以使用全站加速区分动静态资源,并实现动静态资源分别加速。 您可以使用安全加速SCDN兼顾加速与安全两个业务目标。 您可以使用PCDN显著降低分发成本,并应用在视频点播、直播、大文件下载等业务场景。 相关产品 您可以在对象存储OSS中使用CDN加速,提高网站访问速度,有效降低OSS的外网流量费用。 您可以在视频直播中应用CDN,实现媒资存储、切片转码、访问鉴权、内容分发加速一体化解决方案。 您可以在视频点播中应用CDN,减少缓冲时间,实现高流畅度的播放体验。 您可以借助阿里云云解析提供的强大稳定的解析调度入口,确保顺畅的访问体验。 您可以借助云服务器ECS提高网站可用性,保护服务器源站信息,降低带宽使用成本。 您可以将负载均衡服务器的IP地址设置为回源地址,降低回源带宽压力。
2019-12-01 23:09:50 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 阿里云内容分发网络(Alibaba Cloud Content Delivery Network,简称CDN)将您源站资源缓存至阿里云遍布全球的加速节点上。当终端用户请求访问和获取这些资源时,无需回源,系统将就近调用CDN节点上已经缓存的资源。 在不同区域、不同场景下使用CDN加速您网站内容的分发,将有效分担源站压力,避免网络拥塞,提升用户访问资源的速度和体验。您可以参考快速入门 快速接入阿里云CDN。 工作原理 通过以下案例,您可以清楚地了解CDN的工作原理。 假设您的源站域名为 www.a.com。接入 CDN 开始使用加速服务后,当您的终端用户(北京)发起 HTTP 请求时,实际的处理流程如下: 终端用户(北京) 向 www.a.com下的某资源发起请求,会先向 LDNS 发起域名解析请求。 当 LDNS 解析 www.a.com 时,会发现已经配置了 CNAME www.a.tbcdn.com。 解析请求会发送至阿里云DNS调度系统,并为请求分配最佳节点 IP。 LDNS 获取 DNS 返回的解析 IP。 用户获取解析 IP。 用户向获取的 IP 发起对该资源的访问请求。 若该 IP 对应的节点已经缓存了该资源,则会将数据直接返回给用户(如图中步骤7、8),此时请求结束。 若该节点未缓存该资源,则节点会向业务源站发起对该资源的请求。获取资源后,结合用户自定义配置的缓存策略(可参考产品文档中的 缓存过期配置),将资源缓存至节点(如图:北京节点),并返回给用户,此时请求结束。 相关概念 CNAME:即别名( Canonical Name ),可以用来把一个域名解析到另一个域名。 回源HOST:使用回源HOST,您可以自定义CDN节点回源时所需访问的具体服务器域名。 协议回源:开启该功能后,回源使用协议和客户端访问资源的协议保持一致。 过滤参数:URL请求中,如果携带“?” (半角)和参数,则请求到CDN节点时,CDN节点在收到该请求后是否将该带参数的请求URL请求回源站。 使用CDN 您可以查看CDN学习路径,快速了解并上手CDN。 您可以登录CDN控制台,了解并使用了CDN的全部功能。 您还可以使用CDN的API,更灵活地帮助您的业务。 CDN定价 CDN的定价策略:基础服务和 增值服务。其中,基础服务可以按流量或带宽两种方式计算。 更多CDN定价策略,请参考产品价格。 相关服务 CDN子产品 您可以使用全站加速区分动静态资源,并实现动静态资源分别加速。 您可以使用安全加速SCDN兼顾加速与安全两个业务目标。 您可以使用PCDN显著降低分发成本,并应用在视频点播、直播、大文件下载等业务场景。 相关产品 您可以在对象存储OSS中使用CDN加速,提高网站访问速度,有效降低OSS的外网流量费用。 您可以在视频直播中应用CDN,实现媒资存储、切片转码、访问鉴权、内容分发加速一体化解决方案。 您可以在视频点播中应用CDN,减少缓冲时间,实现高流畅度的播放体验。 您可以借助阿里云云解析提供的强大稳定的解析调度入口,确保顺畅的访问体验。 您可以借助云服务器ECS提高网站可用性,保护服务器源站信息,降低带宽使用成本。 您可以将负载均衡服务器的IP地址设置为回源地址,降低回源带宽压力。
2019-12-01 23:09:51 0 浏览量 回答数 0

问题

磁盘缩容

由于目前云服务器 ECS 不支持系统盘或者数据盘缩容,如果您有磁盘缩容的需求,可用通过 阿里云迁云工具 达成目的。 实现原理 迁云工具的研发初衷是为了平衡阿里云用户的云上及线下业务负载,但是您可...
chenchuan 2019-12-01 21:36:34 624 浏览量 回答数 0

问题

Consumer 最佳实践有哪几种办法?

Consumer Group,与控制台或者 Demo 中见到的 CID、Group ID 表达同一个意思。如果涉及到具体的参数或者代码,均来源于 Kafka Java 客户端,其它语言客户端原理类似...
猫饭先生 2019-12-01 21:15:13 1126 浏览量 回答数 0

问题

IHS性能优化调优建议

HIS配置优化建议 HIS实际上是IBM和Apache合作的一个产物,它基于稳定版的Apache webserver代码树,然后做了一些扩展,优化而来,所以在本质上各个参数和Apa...
夏天的日子 2019-12-01 21:13:24 5138 浏览量 回答数 0

回答

一 容器 在学习k8s前,首先要了解和学习容器概念和工作原理。 什么是容器? 容器是一种轻量级、可移植、自包含的软件打包技术,使应用程序可以在几乎任何地方以相同的方式运行。开发人员在自己笔记本上创建并测试好的容器,无需任何修改就能够在生产系统的虚拟机、物理服务器或公有云主机上运行。 容器的优势 容器使软件具备了超强的可移植能力。 对于开发人员 – Build Once, Run Anywhere 容器意味着环境隔离和可重复性。开发人员只需为应用创建一次运行环境,然后打包成容器便可在其他机器上运行。另外,容器环境与所在的 Host 环境是隔离的,就像虚拟机一样,但更快更简单。 对于运维人员 – Configure Once, Run Anything 只需要配置好标准的 runtime 环境,服务器就可以运行任何容器。这使得运维人员的工作变得更高效,一致和可重复。容器消除了开发、测试、生产环境的不一致性。 Docker概念 “Docker” 一词指代了多个概念,包括开源社区项目、开源项目使用的工具、主导支持此类项目的公司 Docker Inc. 以及该公司官方支持的工具。技术产品和公司使用同一名称,的确让人有点困惑。 我们来简单说明一下: IT 软件中所说的 “Docker” ,是指容器化技术,用于支持创建和使用容器。 开源 Docker 社区致力于改进这类技术,并免费提供给所有用户,使之获益。 Docker Inc. 公司凭借 Docker 社区产品起家,它主要负责提升社区版本的安全性,并将技术进步与广大技术社区分享。此外,它还专门对这些技术产品进行完善和安全固化,以服务于企业客户。 借助 Docker,您可将容器当做轻巧、模块化的虚拟机使用。同时,您还将获得高度的灵活性,从而实现对容器的高效创建、部署及复制,并能将其从一个环境顺利迁移至另一个环境,从而有助于您针对云来优化您的应用。 Docker有三大核心概念: 镜像(Image)是一个特殊的文件系统,提供容器运行时所需的程序、库、配置等,构建后不会改变 容器(Container)实质是进程,拥有自己独立的命名空间。 仓库(Repository)一个仓库可以包含多个标签(Tag),每个标签对应一个镜像 容器工作原理 Docker 技术使用 Linux 内核和内核功能(例如 Cgroups 和 namespaces)来分隔进程,以便各进程相互独立运行。这种独立性正是采用容器的目的所在;它可以独立运行多种进程、多个应用,更加充分地发挥基础设施的作用,同时保持各个独立系统的安全性。 二 Kubernetes入门知识指南 Kubernets的知识都可以在官方文档查询,网址如下: https://kubernetes.io/zh/docs/home/ Kubernetes基础知识 Kubernetes是什么? Kubernetes 是一个可移植的、可扩展的开源平台,用于管理容器化的工作负载和服务,可促进声明式配置和自动化。Kubernetes 拥有一个庞大且快速增长的生态系统。Kubernetes 的服务、支持和工具广泛可用。 为什么需要 Kubernetes 容器是打包和运行应用程序的好方式。在生产环境中,您需要管理运行应用程序的容器,并确保不会停机。例如,如果一个容器发生故障,则需要启动另一个容器。如果由操作系统处理此行为,会不会更容易? Kubernetes 为您提供: 服务发现和负载均衡 Kubernetes 可以使用 DNS 名称或自己的 IP 地址公开容器,如果到容器的流量很大,Kubernetes 可以负载均衡并分配网络流量,从而使部署稳定。 存储编排 Kubernetes 允许您自动挂载您选择的存储系统,例如本地存储、公共云提供商等。 自动部署和回滚 您可以使用 Kubernetes 描述已部署容器的所需状态,它可以以受控的速率将实际状态更改为所需状态。例如,您可以自动化 Kubernetes 来为您的部署创建新容器,删除现有容器并将它们的所有资源用于新容器。 自动二进制打包 Kubernetes 允许您指定每个容器所需 CPU 和内存(RAM)。当容器指定了资源请求时,Kubernetes 可以做出更好的决策来管理容器的资源。 自我修复 Kubernetes 重新启动失败的容器、替换容器、杀死不响应用户定义的运行状况检查的容器,并且在准备好服务之前不将其通告给客户端。 密钥与配置管理 Kubernetes 允许您存储和管理敏感信息,例如密码、OAuth 令牌和 ssh 密钥。您可以在不重建容器镜像的情况下部署和更新密钥和应用程序配置,也无需在堆栈配置中暴露密钥。 Kubernetes 组件 初学者首先要了解Kubernetes的基本概念,包括master、node、pod等。 Master Master是Kubernetes集群的大脑,运行着的守护进程服务包括kube-apiserver、kube-scheduler、kube-controller-manager、etcd和Pod网络等。 kube-apiserver 主节点上负责提供 Kubernetes API 服务的组件;它是 Kubernetes 控制面的前端。 kube-apiserver 在设计上考虑了水平扩缩的需要。 换言之,通过部署多个实例可以实现扩缩。 etcd etcd 是兼具一致性和高可用性的键值数据库,可以作为保存 Kubernetes 所有集群数据的后台数据库。 您的 Kubernetes 集群的 etcd 数据库通常需要有个备份计划。 kube-scheduler 主节点上的组件,该组件监视那些新创建的未指定运行节点的 Pod,并选择节点让 Pod 在上面运行。 调度决策考虑的因素包括单个 Pod 和 Pod 集合的资源需求、硬件/软件/策略约束、亲和性和反亲和性规范、数据位置、工作负载间的干扰和最后时限。 kube-controller-manager 在主节点上运行控制器的组件。 从逻辑上讲,每个控制器都是一个单独的进程,但是为了降低复杂性,它们都被编译到同一个可执行文件,并在一个进程中运行。 这些控制器包括: 节点控制器(Node Controller): 负责在节点出现故障时进行通知和响应。 副本控制器(Replication Controller): 负责为系统中的每个副本控制器对象维护正确数量的 Pod。 端点控制器(Endpoints Controller): 填充端点(Endpoints)对象(即加入 Service 与 Pod)。 服务帐户和令牌控制器(Service Account & Token Controllers): 为新的命名空间创建默认帐户和 API 访问令牌. 云控制器管理器-(cloud-controller-manager) cloud-controller-manager 运行与基础云提供商交互的控制器 cloud-controller-manager 仅运行云提供商特定的控制器循环。您必须在 kube-controller-manager 中禁用这些控制器循环,您可以通过在启动 kube-controller-manager 时将 --cloud-provider 参数设置为 external 来禁用控制器循环。 cloud-controller-manager 允许云供应商的代码和 Kubernetes 代码彼此独立地发展。在以前的版本中,核心的 Kubernetes 代码依赖于特定云提供商的代码来实现功能。在将来的版本中,云供应商专有的代码应由云供应商自己维护,并与运行 Kubernetes 的云控制器管理器相关联。 以下控制器具有云提供商依赖性: 节点控制器(Node Controller): 用于检查云提供商以确定节点是否在云中停止响应后被删除 路由控制器(Route Controller): 用于在底层云基础架构中设置路由 服务控制器(Service Controller): 用于创建、更新和删除云提供商负载均衡器 数据卷控制器(Volume Controller): 用于创建、附加和装载卷、并与云提供商进行交互以编排卷 Node 节点组件在每个节点上运行,维护运行 Pod 并提供 Kubernetes 运行环境。 kubelet 一个在集群中每个节点上运行的代理。它保证容器都运行在 Pod 中。 kubelet 接收一组通过各类机制提供给它的 PodSpecs,确保这些 PodSpecs 中描述的容器处于运行状态且健康。kubelet 不会管理不是由 Kubernetes 创建的容器。 kube-proxy kube-proxy 是集群中每个节点上运行的网络代理,实现 Kubernetes Service 概念的一部分。 kube-proxy 维护节点上的网络规则。这些网络规则允许从集群内部或外部的网络会话与 Pod 进行网络通信。 如果有 kube-proxy 可用,它将使用操作系统数据包过滤层。否则,kube-proxy 会转发流量本身。 容器运行环境(Container Runtime) 容器运行环境是负责运行容器的软件。 Kubernetes 支持多个容器运行环境: Docker、 containerd、cri-o、 rktlet 以及任何实现 Kubernetes CRI (容器运行环境接口)。 Pod 在Kubernetes中,最小的管理元素不是一个个独立的容器,而是Pod。Pod是管理,创建,计划的最小单元. 一个Pod相当于一个共享context的配置组,在同一个context下,应用可能还会有独立的cgroup隔离机制,一个Pod是一个容器环境下的“逻辑主机”,它可能包含一个或者多个紧密相连的应用,这些应用可能是在同一个物理主机或虚拟机上。 Pod 的context可以理解成多个linux命名空间的联合 PID 命名空间(同一个Pod中应用可以看到其它进程) 网络 命名空间(同一个Pod的中的应用对相同的IP地址和端口有权限) IPC 命名空间(同一个Pod中的应用可以通过VPC或者POSIX进行通信) UTS 命名空间(同一个Pod中的应用共享一个主机名称) 同一个Pod中的应用可以共享磁盘,磁盘是Pod级的,应用可以通过文件系统调用。 由于docker的架构,一个Pod是由多个相关的并且共享磁盘的容器组成,Pid的命名空间共享还没有应用到Docker中 和相互独立的容器一样,Pod是一种相对短暂的存在,而不是持久存在的,正如我们在Pod的生命周期中提到的,Pod被安排到结点上,并且保持在这个节点上直到被终止(根据重启的设定)或者被删除,当一个节点死掉之后,上面的所有Pod均会被删除。特殊的Pod永远不会被转移到的其他的节点,作为替代,他们必须被replace. 三 通过kubeadm方式创建一个kubernetes 对kubernetes的概念和组件有所了解以后,就可以通过kubeadm的方式创建一个kubernetes集群。 安装前准备工作 创建虚拟机 创建至少2台虚拟机,可以在本地或者公有云。 下载部署软件 需要下载的软件包括calico、demo-images、docker-ce、kube、kube-images、kubectl、metrics-server 安装部署 具体安装过程参考官网文档: https://kubernetes.io/zh/docs/reference/setup-tools/kubeadm/kubeadm/ 四 安装后的练习 安装后详读官方文档,做下面这些组件的练习操作,要达到非常熟练的程度。 Node Namespace Pod Deployment DaemonSet Service Job Static Pod ConfigMap Secrets Volume Init-containers Affinity and Anti-Affinity Monitor and logs Taints and Tolerations Cordon and Drain Backing up etcd 这些内容都非常熟练以后,基本就达到了入门的水平。
红亮 2020-03-02 11:09:17 0 浏览量 回答数 0

回答

本文介绍如何在混合云备份管理控制台进行VMware虚机迁移。 背景信息 VMware虚机迁移服务主要针对VMware环境的虚拟机提供非侵入式的无代理整机迁移功能,其原理是基于VMware的快照以及磁盘级别的数据读取功能,将虚拟机整机全盘迁移到ECS上。 目前HBR仅支持华北2(北京)、华东2(上海)、华南1(深圳)、华东1(杭州)、华北3(张家口)、中国(香港)、新加坡、美国(硅谷)、印度尼西亚(雅加达)、澳大利亚(悉尼)地域的VMware虚机迁移,其他地域将陆续开放,敬请期待。 前提条件 待迁移虚拟机为Linux系统时,系统引导程序GRUB需为1.99及以上版本。 说明 对于CentOS 5、Red Hat 5和Debian 7等低版本操作系统,需要更新GRUB至1.99及以上版本。 部分系统如Amazon Linux需要更新至2.02及以上版本。 步骤1:创建迁移网关 登录混合云备份管理控制台。 选择数据迁移 > 虚机迁移。 单击右上角的创建迁移网关。 说明 单个地域仅支持创建一个迁移网关。 在创建迁移网关页签,配置参数,然后单击创建。 各参数说明如下: 参数 说明 网关名称 为此迁移网关命名。名称不得超过64个字节。 软件平台 当前仅支持vSphere。 网络类型 专有网络:网关通过专线(阿里云专有网络,VPC)传输迁移数据时,选择此项。 公网:无法使用专有网络的场景下选择此项。 单击下载客户端和下载证书。 说明 客户端安装包用于连接阿里云备份服务,证书用来激活该客户端。您也可以返回客户端列表,在任意时间选择下载。 步骤2:安装客户端 下载客户端和证书后,需要安装该客户端。安装后您可以在客户端上进行迁移任务。安装客户端的具体操作步骤如下: 登录vSphere Web Client。 说明 混合云备份目前仅支持VCenter Server 5.5/6.0/6.5版本。 在左侧导航栏,选中要进行部署的虚拟机,右键选择部署OVF模板。 说明 更多关于如何部署OVF模板,参见部署OVF模板。 在部署OVF模板页面,选择本地文件。单击浏览选择下载好的客户端文件,然后单击下一步。 输入OVF的名称,然后选择部署位置,然后单击下一步。 选择运行已部署模板的位置,然后单击下一步。 验证模板详细信息,然后单击下一步。 根据需要选择虚拟磁盘格式,选择存储已部署模板文件的位置,然后单击下一步。 为每个源网络选择目标网络,然后单击下一步。 自定义该软件解决方案的部署属性,然后单击下一步。 查看配置数据,然后单击完成。 在近期任务中查看任务状态,等待任务完成。 部署完成后,启动使用OVF模板部署的虚拟机。 打开浏览器,在地址栏输入http://hostname:8011。 说明 hostname是您使用OVF模板部署的虚拟一体机的IP地址。 在激活网关页面,输入所需参数,然后单击注册登录混合云备份网关。各参数说明如下: 参数 说明 AccessKey ID 在开通HBR服务的阿里云账户中下载AccessKey ID和AccessKey Secret。详情参见为RAM用户创建AccessKey。 AccessKey Secret 在开通HBR服务的阿里云账户中下载AccessKey ID和AccessKey Secret。详情参见为RAM用户创建AccessKey。 证书文件 选择在控制台下载的证书。证书激活后如果虚机关机超过5天,证书会失效,需要重新下载证书并激活。 激活成功后,单击确定将前往阿里云虚机迁移控制台。 步骤3:添加vCenter 在迁移网关页签,单击操作栏下的查看。 单击右上角的添加vCenter服务器。 在添加vCenter服务器页面,填写服务器网络地址、用户名和密码,然后单击创建。 说明 密码中若包含如下特殊字符(` ^ ~ = ; ! / ( [ ] { } @ $ \ & # % +),可能会添加失败。建议您新建一个专门用于备份的VCenter账号,密码中需包含特殊字符,且特殊字符当前仅支持使用英文句号(.)。 步骤4:迁移VMware虚机 单击操作栏下的迁移。 在迁移计划页签,按照以下说明填写各项参数,然后单击下一步。 plan 参数 说明 迁移计划名称 为该迁移计划命名。可不填,默认名字随机分配。 迁移计划 选择立即迁移或指定时间迁移。 选择指定时间迁移时,需指定迁移开始时间,精确到秒。 强制使用静默快照 勾选:强制使用静默快照备份,如果无法使用静默快照,则备份失败。 不勾选(默认):首先尝试使用静默快照备份,如果无法使用静默快照,则使用普通快照。 是否使用增量迁移 您可以选择是否使用增量迁移。 使用增量迁移时,需要指定增量同步频率间隔,单位为小时、天、周。 说明 如果虚拟机禁止了数据块修改跟踪技术(CBT), 增量迁移将强制转为全量迁移。 增量迁移模式下,HBR将自动创建镜像以支持测试拉起,会产生一定的镜像费用,镜像费用由ECS收取。详情请参见计费概述。 选择待迁移虚机,单击下一步。 在配置云上ECS页签,选择专有网络、交换机、实例类型、实例规格、存储类型、安全组、IP地址类型、是否分配公网IP、是否恢复后启动系统,是否创建系统镜像,选择复制配置到所有虚机或保存配置到当前虚机。 说明 选择安全组时,请确保允许出方向的TCP 80、443端口以及UDP 53端口。 单击创建后,即可启动当前迁移任务。在迁移状态页面,您可以查看迁移进度。syn 如果使用了增量迁移,待虚机迁移完成后,您可以执行以下操作。 单击同步记录,您可以查看增量迁移的数据大小、迁移的状态等信息。syn 单击创建ECS,在弹出框中选择迁移验证或完成迁移。verification 单击迁移验证,即将以最近一次同步(例如,2020-02-21 20:21:31)的数据创建出ECS,用于验证迁移到ECS的虚机是否工作正常。每台虚机最多可以做3次验证,验证不会中断预设的增量同步。确认进行迁移认证,请单击确定,开始创建ECS,待ECS创建完成后,您可以单击继续迁移,将清除已经创建的ECS并继续迁移。continue 单击完成迁移,即将以最近一次同步(例如,2020-02-21 20:21:31)的数据创建迁移完成的ECS,并不再进行同步。您也可以选择完成迁移之前做最后一次增量同步来将上次同步之后的数据更新到迁移完成的ECS中。 说明 最后一次增量同步会增加完成迁移操作所需要的时间。 首次迁移验证或完成迁移操作成功立即收取该虚机的迁移费用,同一台虚机重复验证和完成迁移不再额外计费。 如需获取更多费用信息,请参见价格详情。 单击取消迁移,即取消本次迁移任务。
1934890530796658 2020-03-30 14:39:57 0 浏览量 回答数 0

回答

参考:https://www.iteblog.com/archives/2530.html分布式和去中心化(Distributed and Decentralized)Cassandra 是分布式的,这意味着它可以运行在多台机器上,并呈现给用户一个一致的整体。事实上,在一个节点上运行 Cassandra 是没啥用的,虽然我们可以这么做,并且这可以帮助我们了解它的工作机制,但是你很快就会意识到,需要多个节点才能真正了解 Cassandra 的强大之处。它的很多设计和实现让系统不仅可以在多个节点上运行,更为多机架部署进行了优化,甚至一个 Cassandra 集群可以运行在分散于世界各地的数据中心上。你可以放心地将数据写到集群的任意一台机器上,Cassandra 都会收到数据。对于很多存储系统(比如 MySQL, Bigtable),一旦你开始扩展它,就需要把某些节点设为主节点,其他则作为从节点。但 Cassandra 是无中心的,也就是说每个节点都是一样的。与主从结构相反,Cassandra 的协议是 P2P 的,并使用 gossip 来维护存活或死亡节点的列表。关于 gossip 可以参见《分布式原理:一文了解 Gossip 协议》。去中心化这一事实意味着 Cassandra 不会存在单点失效。Cassandra 集群中的所有节点的功能都完全一样, 所以不存在一个特殊的主机作为主节点来承担协调任务。有时这被叫做服务器对称(server symmetry)。综上所述,Cassandra 是分布式、无中心的,它不会有单点失效,所以支持高可用性。弹性可扩展(Elastic Scalability)可扩展性是指系统架构可以让系统提供更多的服务而不降低使用性能的特性。仅仅通过给现有的机器增加硬件的容量、内存进行垂直扩展,是最简单的达到可扩展性的手段。而水平扩展则需要增加更多机器,每台机器提供全部或部分数据,这样所有主机都不必负担全部业务请求。但软件自己需要有内部机制来保证集群中节点间的数据同步。弹性可扩展是指水平扩展的特性,意即你的集群可以不间断的情况下,方便扩展或缩减服务的规模。这样,你就不需要重新启动进程,不必修改应用的查询,也无需自己手工重新均衡数据分布。在 Cassandra 里,你只要加入新的计算机,Cassandra 就会自动地发现它并让它开始工作。高可用和容错(High Availability and Fault Tolerance)从一般架构的角度来看,系统的可用性是由满足请求的能力来量度的。但计算机可能会有各种各样的故障,从硬件器件故障到网络中断都有可能。如何计算机都可能发生这些情况,所以它们一般都有硬件冗余,并在发生故障事件的情况下会自动响应并进行热切换。对一个需要高可用的系统,它必须由多台联网的计算机构成,并且运行于其上的软件也必须能够在集群条件下工作,有设备能够识别节点故障,并将发生故障的中端的功能在剩余系统上进行恢复。Cassandra 就是高可用的。你可以在不中断系统的情况下替换故障节点,还可以把数据分布到多个数据中心里,从而提供更好的本地访问性能,并且在某一数据中心发生火灾、洪水等不可抗灾难的时候防止系统彻底瘫痪。可调节的一致性(Tuneable Consistency)2000年,加州大学伯克利分校的 Eric Brewer 在 ACM 分布式计算原理会议提出了著名的 CAP 定律。CAP 定律表明,对于任意给定的系统,只能在一致性(Consistency)、可用性(Availability)以及分区容错性(Partition Tolerance)之间选择两个。关于 CAP 定律的详细介绍可参见《分布式系统一致性问题、CAP定律以及 BASE 理论》以及《一篇文章搞清楚什么是分布式系统 CAP 定理》。所以 Cassandra 在设计的时候也不得不考虑这些问题,因为分区容错性这个是每个分布式系统必须考虑的,所以只能在一致性和可用性之间做选择,而 Cassandra 的应用场景更多的是为了满足可用性,所以我们只能牺牲一致性了。但是根据 BASE 理论,我们其实可以通过牺牲强一致性获得可用性。Cassandra 提供了可调节的一致性,允许我们选定需要的一致性水平与可用性水平,在二者间找到平衡点。因为客户端可以控制在更新到达多少个副本之前,必须阻塞系统。这是通过设置副本因子(replication factor)来调节与之相对的一致性级别。通过副本因子(replication factor),你可以决定准备牺牲多少性能来换取一致性。 副本因子是你要求更新在集群中传播到的节点数(注意,更新包括所有增加、删除和更新操作)。客户端每次操作还必须设置一个一致性级别(consistency level)参数,这个参数决定了多少个副本写入成功才可以认定写操作是成功的,或者读取过程中读到多少个副本正确就可以认定是读成功的。这里 Cassandra 把决定一致性程度的权利留给了客户自己。所以,如果需要的话,你可以设定一致性级别和副本因子相等,从而达到一个较高的一致性水平,不过这样就必须付出同步阻塞操作的代价,只有所有节点都被更新完成才能成功返回一次更新。而实际上,Cassandra 一般都不会这么来用,原因显而易见(这样就丧失了可用性目标,影响性能,而且这不是你选择 Cassandra 的初衷)。而如果一个客户端设置一致性级别低于副本因子的话,即使有节点宕机了,仍然可以写成功。总体来说,Cassandra 更倾向于 CP,虽然它也可以通过调节一致性水平达到 AP;但是不推荐你这么设置。面向行(Row-Oriented)Cassandra 经常被看做是一种面向列(Column-Oriented)的数据库,这也并不算错。它的数据结构不是关系型的,而是一个多维稀疏哈希表。稀疏(Sparse)意味着任何一行都可能会有一列或者几列,但每行都不一定(像关系模型那样)和其他行有一样的列。每行都有一个唯一的键值,用于进行数据访问。所以,更确切地说,应该把 Cassandra 看做是一个有索引的、面向行的存储系统。Cassandra 的数据存储结构基本可以看做是一个多维哈希表。这意味着你不必事先精确地决定你的具体数据结构或是你的记录应该包含哪些具体字段。这特别适合处于草创阶段,还在不断增加或修改服务特性的应用。而且也特别适合应用在敏捷开发项目中,不必进行长达数月的预先分析。对于使用 Cassandra 的应用,如果业务发生变化了,只需要在运行中增加或删除某些字段就行了,不会造成服务中断。当然, 这不是说你不需要考虑数据。相反,Cassandra 需要你换个角度看数据。在 RDBMS 里, 你得首先设计一个完整的数据模型, 然后考虑查询方式, 而在 Cassandra 里,你可以首先思考如何查询数据,然后提供这些数据就可以了。灵活的模式(Flexible Schema)Cassandra 的早期版本支持无模式(schema-free)数据模型,可以动态定义新的列。 无模式数据库(如 Bigtable 和 MongoDB)在访问大量数据时具有高度可扩展性和高性能的优势。 无模式数据库的主要缺点是难以确定数据的含义和格式,这限制了执行复杂查询的能力。为了解决这些问题,Cassandra 引入了 Cassandra Query Language(CQL),它提供了一种通过类似于结构化查询语言(SQL)的语法来定义模式。 最初,CQL 是作为 Cassandra 的另一个接口,并且基于 Apache Thrift 项目提供无模式的接口。 在这个过渡阶段,术语“模式可选”(Schema-optional)用于描述数据模型,我们可以使用 CQL 的模式来定义。并且可以通过 Thrift API 实现动态扩展以此添加新的列。 在此期间,基础数据存储模型是基于 Bigtable 的。从 3.0 版本开始,不推荐使用基于 Thrift API 的动态列创建的 API,并且 Cassandra 底层存储已经重新实现了,以更紧密地与 CQL 保持一致。 Cassandra 并没有完全限制动态扩展架构的能力,但它的工作方式却截然不同。 CQL 集合(比如 list、set、尤其是 map)提供了在无结构化的格式里面添加内容的能力,从而能扩展现有的模式。CQL 还提供了改变列的类型的能力,以支持 JSON 格式的文本的存储。因此,描述 Cassandra 当前状态的最佳方式可能是它支持灵活的模式。高性能(High Performance)Cassandra 在设计之初就特别考虑了要充分利用多处理器和多核计算机的性能,并考虑在分布于多个数据中心的大量这类服务器上运行。它可以一致而且无缝地扩展到数百台机器,存储数 TB 的数据。Cassandra 已经显示出了高负载下的良好表现,在一个非常普通的工作站上,Cassandra 也可以提供非常高的写吞吐量。而如果你增加更多的服务器,你还可以继续保持 Cassandra 所有的特性而无需牺牲性能。
封神 2019-12-02 02:00:50 0 浏览量 回答数 0

回答

从业余程序员到职业程序员 程序员刚入行时,我觉得最重要的是把自己培养成职业的程序员。 我的程序员起步比同龄人都晚了很多,更不用说现在的年轻人了。我大学读的是生物专业,在上大学前基本算是完全没接触过计算机。军训的时候因为很无聊,我和室友每天跑去学校的机房玩,我现在还印象很深刻,我第一次走进机房的时候,别人问,你是要玩windows,还是dos,我那是完全的一抹黑。后来就只记得在机房一堆人都是在练习盲打,军训完,盲打倒是练的差不多了,对计算机就这么产生了浓厚的兴趣,大一的时候都是玩组装机,捣鼓了一些,对计算机的硬件有了那么一些了解。 到大二后,买了一些书开始学习当时最火的网页三剑客,学会了手写HTML、PS的基本玩法之类的,课余、暑假也能开始给人做做网站什么的(那个时候做网站真的好赚钱),可能那样过了个一年左右,做静态的网页就不好赚钱了,也不好找实习工作,于是就开始学asp,写些简单的CRUD,做做留言板、论坛这些动态程序,应该算是在这个阶段接触编程了。 毕业后加入了深圳的一家做政府行业软件的公司,一个非常靠谱和给我空间的Leader,使得自己在那几年有了不错的成长,终于成了一个职业的程序员。 通常来说,业余或半职业的程序员,多数是1个人,或者很小的一个团队一起开发,使得在开发流程、协作工具(例如jira、cvs/svn/git等)、测试上通常会有很大的欠缺,而职业的程序员在这方面则会专业很多。另外,通常职业的程序员做的系统都要运行较长的时间,所以在可维护性上会特别注意,这点我是在加入阿里后理解更深的。一个运行10年的系统,和一个写来玩玩的系统显然是有非常大差别的。 这块自己感觉也很难讲清楚,只能说模模糊糊有个这样的概念。通常在有兴趣的基础上,从业余程序员跨越到成为职业程序员我觉得不会太难。 编程能力的成长 作为程序员,最重要的能力始终是编程能力,就我自己的感受而言,我觉得编程能力的成长主要有这么几个部分: 1、编程能力初级:会用 编程,首先都是从学习编程语言的基本知识学起的,不论是什么编程语言,有很多共同的基本知识,例如怎么写第一个Hello World、if/while/for、变量等,因此我比较建议在刚刚开始学一门编程语言的时候,看看编程语言自己的一些文档就好,不要上来就去看一些高阶的书。我当年学Java的时候上来就看Think in Java、Effective Java之类的,真心好难懂。 除了看文档以外,编程是个超级实践的活,所以一定要多写代码,只有这样才能真正熟练起来。这也是为什么我还是觉得在面试的时候让面试者手写代码是很重要的,这个过程是非常容易判断写代码的熟悉程度的。很多人会说由于写代码都是高度依赖IDE的,导致手写很难,但我绝对相信写代码写了很多的人,手写一段不太复杂的、可运行的代码是不难的。即使像我这种三年多没写过代码的人,让我现在手写一段不太复杂的可运行的Java程序,还是没问题的,前面N年的写代码生涯使得很多东西已经深入骨髓了。 我觉得编程能力初级这个阶段对于大部分程序员来说都不会是问题,勤学苦练,是这个阶段的核心。 2、编程能力中级:会查和避免问题 除了初级要掌握的会熟练的使用编程语言去解决问题外,中级我觉得首先是提升查问题的能力。 在写代码的过程中,出问题是非常正常的,怎么去有效且高效的排查问题,是程序员群体中通常能感受到的大家在编程能力上最大的差距。 解决问题能力强的基本很容易在程序员群体里得到很高的认可。在查问题的能力上,首先要掌握的是一些基本的调试技巧,好用的调试工具,在Java里有JDK自带的jstat、jmap、jinfo,不在JDK里的有mat、gperf、btrace等。工欲善其事必先利其器,在查问题上是非常典型的,有些时候大家在查问题时的能力差距,有可能仅仅是因为别人比你多知道一个工具而已。 除了调试技巧和工具外,查问题的更高境界就是懂原理。一个懂原理的程序员在查问题的水平上和其他程序员是有明显差距的。我想很多的同学应该能感受到,有些时候查出问题的原因仅仅是因为有效的工具,知其然不知其所以然。 我给很多阿里的同学培训过Java排查问题的方法,在这个培训里,我经常也会讲到查问题的能力的培养最主要的也是熟练,多尝试给自己写一些会出问题的程序,多积极的看别人是怎么查问题的,多积极的去参与排查问题,很多最后查问题能力强的人多数仅仅是因为“无他,但手熟尔”。 我自己排查问题能力的提升主要是在2009年和2010年。那两年作为淘宝消防队(处理各种问题和故障的虚拟团队)的成员,处理了很多的故障和问题。当时消防队还有阿里最公认的技术大神——多隆,我向他学习到了很多排查问题的技巧。和他比,我排查问题的能力就是初级的那种。 印象最深刻的是一次我们一起查一个应用cpu us高的问题,我们两定位到是一段代码在某种输入参数的时候会造成cpu us高的原因后,我能想到的继续查的方法是去生产环境抓输入参数,然后再用参数来本地debug看是什么原因。但多隆在看了一会那段代码后,给了我一个输入参数,我拿这个参数一运行,果然cpu us很高!这种case不是一次两次。所以我经常和别人说,我是需要有问题场景才能排查出问题的,但多隆是完全有可能直接看代码就能看出问题的,这是本质的差距。 除了查问题外,更厉害的程序员是在写代码的过程就会很好的去避免问题。大家最容易理解的就是在写代码时处理各种异常情况,这里通常也是造成程序员们之间很大的差距的地方。 写一段正向逻辑的代码,大部分情况下即使有差距,也不会太大,但在怎么很好的处理这个过程中有可能出现的异常上,这个时候的功力差距会非常明显。很多时候一段代码里处理异常逻辑的部分都会超过正常逻辑的代码量。 我经常说,一个优秀程序员和普通程序员的差距,很多时候压根就不需要看什么满天飞的架构图,而只用show一小段的代码就可以。 举一个小case大家感受下。当年有一个严重故障,最后查出的原因是输入的参数里有一个是数组,把这个数组里的值作为参数去查数据库,结果前面输入了一个很大的数组,导致从数据库查了大量的数据,内存溢出了,很多程序员现在看都会明白对入参、出参的保护check,但类似这样的case我真的碰到了很多。 在中级这个阶段,我会推荐大家尽可能的多刻意的去培养下自己这两个方面的能力,成为一个能写出高质量代码、有效排查问题的优秀程序员。 3、编程能力高级:懂高级API和原理 就我自己的经历而言,我是在写了多年的Java代码后,才开始真正更细致的学习和掌握Java的一些更高级的API,我相信多数Java程序员也是如此。 我算是从2003年开始用Java写商业系统的代码,但直到在2007年加入淘宝后,才开始非常认真地学习Java的IO通信、并发这些部分的API。尽管以前也学过也写过一些这样的代码,但完全就是皮毛。当然,这些通常来说有很大部分的原因会是工作的相关性,多数的写业务系统的程序员可能基本就不需要用到这些,所以导致会很难懂这些相对高级一些的API,但这些API对真正的理解一门编程语言,我觉得至关重要。 在之前的程序员成长路线的文章里我也讲到了这个部分,在没有场景的情况下,只能靠自己去创造场景来学习好。我觉得只要有足够的兴趣,这个问题还是不大的,毕竟现在有各种开源,这些是可以非常好的帮助自己创造机会学习的,例如学Java NIO,可以自己基于NIO包一个框架,然后对比Netty,看看哪些写的是不如Netty的,这样会非常有助于真正的理解。 在学习高级API的过程中,以及排查问题的过程中,我自己越来越明白懂编程语言的运行原理是非常重要的,因此我到了后面的阶段开始学习Java的编译机制、内存管理、线程机制等。对于我这种非科班出身的而言,学这些会因为缺乏基础更难很多,但这些更原理性的东西学会了后,对自己的编程能力会有质的提升,包括以后学习其他编程语言的能力,学这些原理最好的方法我觉得是先看看一些讲相关知识的书,然后去翻看源码,这样才能真正的更好的掌握,最后是在以后写代码的过程中、查问题的过程中多结合掌握的原理,才能做到即使在N年后也不会忘。 在编程能力的成长上,我觉得没什么捷径。我非常赞同1万小时理论,在中级、高级阶段,如果有人指点或和优秀的程序员们共事,会好非常多。不过我觉得这个和读书也有点像,到了一定阶段后(例如高中),天分会成为最重要的分水岭,不过就和大部分行业一样,大部分的情况下都还没到拼天分的时候,只需要拼勤奋就好。 系统设计能力的成长 除了少数程序员会进入专深的领域,例如Linux Kernel、JVM,其他多数的程序员除了编程能力的成长外,也会越来越需要在系统设计能力上成长。 通常一个编程能力不错的程序员,在一定阶段后就会开始承担一个模块的工作,进而承担一个子系统、系统、跨多领域的更大系统等。 我自己在工作的第三年开始承担一个流程引擎的设计和实现工作,一个不算小的系统,并且也是当时那个项目里的核心部分。那个阶段我学会了一些系统设计的基本知识,例如需要想清楚整个系统的目标、模块的划分和职责、关键的对象设计等,而不是上来就开始写代码。但那个时候由于我是一个人写整个系统,所以其实对设计的感觉并还没有那么强力的感觉。 在那之后的几年也负责过一些系统,但总体感觉好像在系统设计上的成长没那么多,直到在阿里的经历,在系统设计上才有了越来越多的体会。(点击文末阅读原文,查看:我在系统设计上犯过的14个错,可以看到我走的一堆的弯路)。 在阿里有一次做分享,讲到我在系统设计能力方面的成长,主要是因为三段经历,负责专业领域系统的设计 -> 负责跨专业领域的专业系统的设计 -> 负责阿里电商系统架构级改造的设计。 第一段经历,是我负责HSF。HSF是一个从0开始打造的系统,它主要是作为支撑服务化的框架,是个非常专业领域的系统,放在整个淘宝电商的大系统来看,其实它就是一个很小的子系统,这段经历里让我最深刻的有三点: 1).要设计好这种非常专业领域的系统,专业的知识深度是非常重要的。我在最早设计HSF的几个框的时候,是没有设计好服务消费者/提供者要怎么和现有框架结合的,在设计负载均衡这个部分也反复了几次,这个主要是因为自己当时对这个领域掌握不深的原因造成的; 2). 太技术化。在HSF的阶段,出于情怀,在有一个版本里投入了非常大的精力去引进OSGi以及去做动态化,这个后来事实证明是个非常非常错误的决定,从这个点我才真正明白在设计系统时一定要想清楚目标,而目标很重要的是和公司发展阶段结合; 3). 可持续性。作为一个要在生产环境持续运行很多年的系统而言,怎么样让其在未来更可持续的发展,这个对设计阶段来说至关重要。这里最low的例子是最早设计HSF协议的时候,协议头里竟然没有版本号,导致后来升级都特别复杂;最典型的例子是HSF在早期缺乏了缺乏了服务Tracing这方面的设计,导致后面发现了这个地方非常重要后,全部落地花了长达几年的时间;又例如HSF早期缺乏Filter Chain的设计,导致很多扩展、定制化做起来非常不方便。 第二段经历,是做T4。T4是基于LXC的阿里的容器,它和HSF的不同是,它其实是一个跨多领域的系统,包括了单机上的容器引擎,容器管理系统,容器管理系统对外提供API,其他系统或用户通过这个来管理容器。这个系统发展过程也是各种犯错,犯错的主要原因也是因为领域掌握不深。在做T4的日子里,学会到的最重要的是怎么去设计这种跨多个专业领域的系统,怎么更好的划分模块的职责,设计交互逻辑,这段经历对我自己更为重要的意义是我有了做更大一些系统的架构的信心。 第三段经历,是做阿里电商的异地多活。这对我来说是真正的去做一个巨大系统的架构师,尽管我以前做HSF的时候参与了淘宝电商2.0-3.0的重大技术改造,但参与和自己主导是有很大区别的,这个架构改造涉及到了阿里电商众多不同专业领域的技术团队。在这个阶段,我学会的最主要的: 1). 子系统职责划分。在这种超大的技术方案中,很容易出现某些部分的职责重叠和冲突,这个时候怎么去划分子系统,就非常重要了。作为大架构师,这个时候要从团队的职责、团队的可持续性上去选择团队; 2). 大架构师最主要的职责是控制系统风险。对于这种超大系统,一定是多个专业领域的架构师和大架构师共同设计,怎么确保在执行的过程中对于系统而言最重要的风险能够被控制住,这是我真正的理解什么叫系统设计文档里设计原则的部分。 设计原则我自己觉得就是用来确保各个子系统在设计时都会遵循和考虑的,一定不能是虚的东西,例如在异地多活架构里,最重要的是如何控制数据风险,这个需要在原则里写上,最基本的原则是可接受系统不可用,但也要保障数据一致,而我看过更多的系统设计里设计原则只是写写的,或者千篇一律的,设计原则切实的体现了架构师对目标的理解(例如当时异地多活这个其实开始只是个概念,但做到什么程度才叫做到异地多活,这是需要解读的,也要确保在技术层面的设计上是达到了目标的),技术方案层面上的选择原则,并确保在细节的设计方案里有对于设计原则的承接以及执行; 3). 考虑问题的全面性。像异地多活这种大架构改造,涉及业务层面、各种基础技术层面、基础设施层面,对于执行节奏的决定要综合考虑人力投入、机器成本、基础设施布局诉求、稳定性控制等,这会比只是做一个小的系统的设计复杂非常多。 系统设计能力的成长,我自己觉得最重要的一是先在一两个技术领域做到专业,然后尽量扩大自己的知识广度。例如除了自己的代码部分外,还应该知道具体是怎么部署的,部署到哪去了,部署的环境具体是怎么样的,和整个系统的关系是什么样的。 像我自己,是在加入基础设施团队后才更加明白有些时候软件上做的一个决策,会导致基础设施上巨大的硬件、网络或机房的投入,但其实有可能只需要在软件上做些调整就可以避免,做做研发、做做运维可能是比较好的把知识广度扩大的方法。 第二点是练习自己做tradeoff的能力,这个比较难,做tradeoff这事需要综合各种因素做选择,但这也是所有的架构师最关键的,可以回头反思下自己在做各种系统设计时做出的tradeoff是什么。这个最好是亲身经历,听一些有经验的架构师分享他们选择背后的逻辑也会很有帮助,尤其是如果恰好你也在同样的挑战阶段,光听最终的架构结果其实大多数时候帮助有限。 技术Leader我觉得最好是能在架构师的基础上,后续注重成长的方面还是有挺大差别,就不在这篇里写了,后面再专门来写一篇。 程序员金字塔 我认为程序员的价值关键体现在作品上,被打上作品标签是一种很大的荣幸,作品影响程度的大小我觉得决定了金字塔的层次,所以我会这么去理解程序员的金字塔。 当然,要打造一款作品,仅有上面的两点能力是不够的,作品里很重要的一点是对业务、技术趋势的判断。 希望作为程序员的大伙,都能有机会打造一款世界级的作品,去为技术圈的发展做出贡献。 由于目前IT技术更新速度还是很快的,程序员这个行当是特别需要学习能力的。我一直认为,只有对程序员这个职业真正的充满兴趣,保持自驱,才有可能在这个职业上做好,否则的话是很容易淘汰的。 作者简介: 毕玄,2007年加入阿里,十多年来主要从事在软件基础设施领域,先后负责阿里的服务框架、Hbase、Sigma、异地多活等重大的基础技术产品和整体架构改造。
茶什i 2020-01-10 15:19:35 0 浏览量 回答数 0

问题

轻量应用服务器的FTP怎么搭建和使用

简介 FTP 是File Transfer Protocol(文件传输协议)的英文简称,而中文简称为“文传协议”。用于Internet上的控制文件的双向传输。同时,它也是一个应用程...
boxti 2019-12-01 21:52:00 9028 浏览量 回答数 0

问题

最强转码技术揭秘:窄带高清原理解析+用户接入指南

有人说2017年是中国网络视频发展的黄金时期,根据中国互联网信息中心发布的《中国互联网发展状况统计报告》显示,截止2017上半年,网络视频用户规模已经达到5.65 亿,半年增长3.7%...
樰篱 2019-12-01 21:22:07 1909 浏览量 回答数 2

回答

本文主要介绍虚拟节点和ECI,以及如何通过Virtual Node Addon插件部署虚拟节点创建ECI Pod。 虚拟节点和弹性容器实例ECI 阿里云弹性容器实例ECI(Elastic Container Instance)是面向容器的无服务器弹性计算服务,提供免运维、强隔离、快速启动的容器运行环境。使用ECI无需购买和管理底层 ECS 服务器,让用户更加关注在容器应用而底层基础设施的维护工作。用户可按需创建ECI,仅为容器配置的资源付费(按量按秒计费)。 虚拟节点Virtual Node来源于Kubernetes社区的Virtual Kubelet技术,其实现了Kubernetes与弹性容器实例ECI的无缝连接,让 Kubernetes 集群轻松获得极大的弹性能力,而不必受限于集群的节点计算容量。关于Virtual Kubelet的工作原理及其架构,请参见Virtual Kubelet 因为Virtual Node可以轻松支持更高弹性和Pod容量,灵活动态的按需创建ECI Pod,免去集群容量规划的麻烦,所以它非常适合运行在如下多个场景,帮助用户极大降低计算成本,提升计算弹性效率。 在线业务的波峰波谷弹性伸缩:如在线教育、电商等行业有着明显的波峰波谷计算特征。使用虚拟节点可以显著减少固定资源池的维护,降低计算成本。 数据计算:使用虚拟节点承载Spark、Presto等计算场景,有效降低计算成本。 CI/CD Pipeline:Jenkins、Gitlab-Runner。 Job任务:定时任务、AI。 阿里云容器服务基于虚拟节点和ECI提供了多种Serverless Container产品形态,包括Serverless Kubernetes(ASK)和ACK on ECI,充分支撑各种弹性和免节点运维场景的用户诉求。virtual node 在ACK集群中部署虚拟节点Addon 说明 在Serverless Kubernetes集群中我们无需手动部署虚拟节点Addon,用户可以直接创建ECI Pod。托管版或专属版则需要先部署ack-virtual-node addon后才可以创建ECI Pod。 在容器服务Kubernetes版(ACK)集群中部署虚拟节点Addon前, 您需要创建一个 Kubernetes 托管版或者专属版集群。详情请参见创建 Kubernetes 托管版集群。 您需要开通弹性容器实例服务。登录弹性容器实例控制台开通相应的服务。 您需要确认集群所在区域在ECI支持的地域列表内。登录弹性容器实例控制台查看已经支持的地域和可用区。 登录容器服务管理控制台。 在控制台左侧导航栏中,单击市场 > 应用目录,并在右侧选中ack-virtual-node。 在应用目录-ack-virtual-node页面,单击参数,配置虚拟节点参数。 参数 参数含义 获取路径 ECI_REGION 地域名称 您可以在集群基本信息的基本信息区域中,获取地域的值。 说明 例如,华东1:cn-hangzhou ECI_VPC 集群的VPC 您可以在集群基本信息的集群资源区域中,获取虚拟专有网络 VPC的值。 ECI_VSWITCH 虚拟交换机 您可以在节点列表单击某个节点,在实例详情页签的配置信息区域中,获取虚拟交换机的值。 说明 请确认当前交换机在ECI支持的可用区列表中。 虚拟交换机支持多可用区。因此,这里可以填写多个vSwitch,例如ECI_VSWITCH: "vsw-xxxxxxx1, vsw-xxxxxxx2, vsw-xxxxxxx3"。 ECI_SECURITY_GROUP 安全组ID 您可以在节点列表单击某个节点,在本实例安全组页签的安全组列表区域中,获取安全组ID的值。 ECI_ACCESS_KEY 用户AccessKey 请参见如何获取AccessKey。 ECI_SECRET_KEY 用户SecretKey 请参见如何获取AccessKey。 ALIYUN_CLUSTERID 集群ID 您可以在集群基本信息的基本信息区域中,获取集群ID的值。 配置完成后,在右侧的创建页面,选择对应的集群,可以看到命名空间已设定为kube-system,发布名称已设定为ack-virtual-node,单击创建。创建插件 安装完成后,在控制台左侧导航栏中,单击集群 > 节点,在节点列表页面可以看到添加了虚拟节点virtual-node-eci。添加节点 执行以下命令查看virtual-node-controller和virtual-node-admision-controller部署状态。详情请参见在CloudShell上通过kubectl管理Kubernetes集群。 kubectl -n kube-system get statefulset virtual-node-eci NAME READY AGE virtual-node-eci 1/1 1m kubectl -n kube-system get deploy ack-virtual-node-affinity-admission-controller NAME READY UP-TO-DATE AVAILABLE AGE ack-virtual-node-affinity-admission-controller 1/1 1 1 1m kubectl -n kube-system get pod|grep virtual-node-eci virtual-node-eci-0 1/1 Running 0 1m kubectl get no|grep virtual-node-eci virtual-node-eci-0 Ready agent 1m v1.11.2-aliyun-1.0.207 调度Pod到虚拟节点 说明 此操作不适用于Serverless Kubernetes集群。 当集群中存在虚拟节点时,您可以把Pod调度到虚拟节点上,Virtual Node Controller将会创建出相应的ECI Pod。您可以通过以下三种方法操作。 配置Pod的nodeSelector和tolerations。 虚拟节点有特殊的Taints,Pod需要配置nodeSelector和tolerations后才能指定调度到虚拟节点上。示例如下: apiVersion: v1 kind: Pod metadata: name: nginx spec: containers: - image: nginx imagePullPolicy: Always name: nginx nodeSelector: type: virtual-kubelet tolerations: - key: virtual-kubelet.io/provider operator: Exists 配置Pod标签。 基于virtual-node-affinity-admission-controller的webhook,对于有特定label(eci=true)的Pod,webhook会将其自动调度到虚拟节点上。示例如下: kubectl run nginx --image nginx -l eci=true kubectl get pod -o wide|grep virtual-node-eci nginx-7fc9f746b6-r4xgx 0/1 ContainerCreating 0 20s 192.168.1.38 virtual-node-eci-0 配置Namespace标签。 基于virtual-node-affinity-admission-controller的webhook,对于有特定label的namespace(virtual-node-affinity-injection=enabled)中创建的Pod,webhook会将其自动调度到虚拟节点上。示例如下: kubectl create ns vk kubectl label namespace vk virtual-node-affinity-injection=enabled kubectl -n vk run nginx --image nginx kubectl -n vk get pod -o wide|grep virtual-node-eci nginx-6f489b847d-vgj4d 1/1 Running 0 1m 192.168.1.37 virtual-node-eci-0 修改虚拟节点Controller的配置 说明 此操作不适用于Serverless Kubernetes集群。 虚拟节点Controller的配置决定了其调度ECI Pod的行为和ECI运行环境配置,包括vswitch和安全组配置等。我们可以根据需要灵活的修改Controller配置,修改配置后不会影响已经运行的ECI Pod,会立即生效于新建ECI Pod。 修改虚拟节点Controller配置的方法如下。 kubectl -n kube-system edit statefulset virtual-node-eci 常用的变更操作如下。 更新virtual-node controller版本。 当需要使用更新虚拟节点功能时,需要更新virtual-node controller镜像至最新版本。例如支持ECI Pod clusterIP访问的vk镜像版本需要高于v1.0.0.2-aliyun。 修改安全组配置ECI_SECURITY_GROUP。 用户可以修改此环境变量,改变ECI Pod的安全组。 修改vswitch配置ECI_VSWITCH。 用户可以修改此环境变量,改变ECI Pod所在的vswitch。我们建议用户配置多个vswitch支持多可用区,这样当单可用区库存不足时,Controller会选择另外一个可用区创建ECI Pod。 修改kube-proxy配置ECI_KUBE_PROXY。 此环境变量默认值为true,表示ECI Pod默认可以访问集群中的ClusterIP Service。如果ECI Pod无需访问clusterIP service时,例如Job计算场景,用户可以设置此环境变量为false关闭kube-proxy功能。另外在一些规模化场景,例如集群中需要启动大量ECI Pod时,ECI中的kube-proxy和kubernetes apiserver之间的并发连接数也会大量增加,用户同样可以选择关闭kube-proxy功能,减少对apiserver的压力提升可扩展性,改用privatezone方式让ECI Pod访问集群中的service。 创建多个虚拟节点。 我们推荐使用单个虚拟节点支撑3000个ECI Pod,当需要创建更多ECI Pod时,可以创建更多的虚拟节点,这样集群中能够支撑的ECI Pod数量也会相应成倍增长。方法是修改statefulset的副本数量,其数量代表集群中虚拟节点的数量,virtual-node-controller pod与虚拟节点一一对应,分别管理虚拟节点上的ECI Pod,controller之间互不影响。所示如下: kubectl -n kube-system scale statefulset virtual-node-eci --replicas=4 statefulset.apps/virtual-node-eci scaled kubectl get no NAME STATUS ROLES AGE VERSION cn-hangzhou.192.168.1.1 Ready 63d v1.12.6-aliyun.1 cn-hangzhou.192.168.1.2 Ready 63d v1.12.6-aliyun.1 virtual-node-eci-0 Ready agent 6m v1.11.2-aliyun-1.0.207 virtual-node-eci-1 Ready agent 1m v1.11.2-aliyun-1.0.207 virtual-node-eci-2 Ready agent 1m v1.11.2-aliyun-1.0.207 virtual-node-eci-3 Ready agent 1m v1.11.2-aliyun-1.0.207 删除虚拟节点 说明 此操作不适用于Serverless Kubernetes集群。 通常情况下我们无需删除虚拟节点,虚拟节点不同与真实节点,不会占用集群计算资源。如果用户需要删除虚拟节点,我们建议手动先驱逐虚拟节点上的Pod,或者删除所有ECI Pod,然后删除Controller和节点。在ECI Pod存在时删除virtual-node controller可能会导致ECI实例的残留。 kubectl drain virtual-node-eci-0 ... kubectl -n kube-system delete statefulset virtual-node-eci kubectl delete no virtual-node-eci-0 ...
1934890530796658 2020-03-31 20:20:53 0 浏览量 回答数 0

问题

云服务器ECS下的FTP服务的如何安装配置与使用

简介 FTP 是File Transfer Protocol(文件传输协议)的英文简称,而中文简称为“文传协议”。用于Internet上的控制文件的双向传输。同时,它也是一个应用程...
boxti 2019-12-01 21:45:58 5158 浏览量 回答数 2

问题

ES 在数据量很大的情况下(数十亿级别)如何提高查询效率啊?【Java问答学堂】28期

面试官心理分析 这个问题是肯定要问的,说白了,就是看你有没有实际干过 es,因为啥?其实 es 性能并没有你想象中那么好的。很多时候数据量大了,特别是有几亿条数据的时候...
剑曼红尘 2020-05-28 09:45:28 15 浏览量 回答数 1

问题

【精品问答】Python面试题汇总130问(框架篇)

在python语言中,有着特别厉害的三大框架。 这三个框架分别为:Flask框架,Tornado框架,Django框架。本次问答帮助大家整理了框架中常见的面试问题! 1...
珍宝珠 2019-12-01 22:04:22 1524 浏览量 回答数 0

问题

SSH面试题

1.什么是struts2?struts的工作原理? struts2:1)经典的  mvc (Model  View  Controller) 框架                          ...
琴瑟 2019-12-01 21:46:22 3489 浏览量 回答数 0

问题

Vue面试题汇总【精品问答】

是一套用于构建用户界面的渐进式JavaScript框架。与其它大型框架不同的是,Vue 被设计为可以自底向上逐层应用。Vue 的核心库只关注视图层,方便与第三方库或既有项目整合。 从0到1自己构架一个vue项目...
问问小秘 2020-05-25 18:02:28 20475 浏览量 回答数 4

回答

MQTT协议 MQTT(Message Queuing Telemetry Transport,消息队列遥测传输)最早是IBM开发的一个即时通讯协议,MQTT协议是为大量计算能力有限且工作在低带宽、不可靠网络的远程传感器和控制设备通讯而设计的一种协议。 MQTT协议的优势是可以支持所有平台,它几乎可以把所有的联网物品和互联网连接起来。 它具有以下主要的几项特性:1、使用发布/订阅消息模式,提供一对多的消息发布和应用程序之间的解耦;2、消息传输不需要知道负载内容;3、使用 TCP/IP 提供网络连接;4、有三种消息发布的服务质量:QoS 0:“最多一次”,消息发布完全依赖底层 TCP/IP 网络。分发的消息可能丢失或重复。例如,这个等级可用于环境传感器数据,单次的数据丢失没关系,因为不久后还会有第二次发送。QoS 1:“至少一次”,确保消息可以到达,但消息可能会重复。QoS 2:“只有一次”,确保消息只到达一次。例如,这个等级可用在一个计费系统中,这里如果消息重复或丢失会导致不正确的收费。5、小型传输,开销很小(固定长度的头部是 2 字节),协议交换最小化,以降低网络流量;6、使用 Last Will 和 Testament 特性通知有关各方客户端异常中断的机制;在MQTT协议中,一个MQTT数据包由:固定头(Fixed header)、 可变头(Variable header)、 消息体(payload)三部分构成。MQTT的传输格式非常精小,最小的数据包只有2个bit,且无应用消息头。下图是MQTT为可靠传递消息的三种消息发布服务质量 发布/订阅模型允许MQTT客户端以一对一、一对多和多对一方式进行通讯。 下图是MQTT的发布/订阅消息模式 CoAP协议 CoAP是受限制的应用协议(Constrained Application Protocol)的代名词。由于目前物联网中的很多设备都是资源受限型的,所以只有少量的内存空间和有限的计算能力,传统的HTTP协议在物联网应用中就会显得过于庞大而不适用。因此,IETF的CoRE工作组提出了一种基于REST架构、传输层为UDP、网络层为6LowPAN(面向低功耗无线局域网的IPv6)的CoAP协议。 CoAP采用与HTTP协议相同的请求响应工作模式。CoAP协议共有4中不同的消息类型。CON——需要被确认的请求,如果CON请求被发送,那么对方必须做出响应。NON——不需要被确认的请求,如果NON请求被发送,那么对方不必做出回应。ACK——应答消息,接受到CON消息的响应。RST——复位消息,当接收者接受到的消息包含一个错误,接受者解析消息或者不再关心发送者发送的内容,那么复位消息将会被发送。 CoAP消息格式使用简单的二进制格式,最小为4个字节。 一个消息=固定长度的头部header + 可选个数的option + 负载payload。Payload的长度根据数据报长度来计算。 主要是一对一的协议 举个例子: 比如某个设备需要从服务器端查询当前温度信息。 请求消息(CON): GET /temperature , 请求内容会被包在CON消息里面响应消息 (ACK): 2.05 Content “22.5 C” ,响应内容会被放在ACK消息里面 CoAP与MQTT的区别 MQTT和CoAP都是行之有效的物联网协议,但两者还是有很大区别的,比如MQTT协议是基于TCP,而CoAP协议是基于UDP。从应用方向来分析,主要区别有以下几点: 1、MQTT协议不支持带有类型或者其它帮助Clients理解的标签信息,也就是说所有MQTT Clients必须要知道消息格式。而CoAP协议则相反,因为CoAP内置发现支持和内容协商,这样便能允许设备相互窥测以找到数据交换的方式。 2、MQTT是长连接而CoAP是无连接。MQTT Clients与Broker之间保持TCP长连接,这种情形在NAT环境中也不会产生问题。如果在NAT环境下使用CoAP的话,那就需要采取一些NAT穿透性手段。 3、MQTT是多个客户端通过中央代理进行消息传递的多对多协议。它主要通过让客户端发布消息、代理决定消息路由和复制来解耦消费者和生产者。MQTT就是相当于消息传递的实时通讯总线。CoAP基本上就是一个在Server和Client之间传递状态信息的单对单协议。 HTTP协议http的全称是HyperText Transfer Protocol,超文本传输协议,这个协议的提出就是为了提供和接收HTML界面,通过这个协议在互联网上面传出web的界面信息。 HTTP协议的两个过程,Request和Response,两个都有各自的语言格式,我们看下是什么。请求报文格式:(注意这里有个换行) 响应报文格式:(注意这里有个换行) 方法method:       这个很重要,比如说GET和POST方法,这两个是很常用的,GET就是获取什么内容,而POST就是向服务器发送什么数据。当然还有其他的,比如HTTP 1.1中还有:DELETE、PUT、CONNECT、HEAD、OPTIONS、TRACE等一共8个方法(HTTP Method历史:HTTP 0.9 只有GET方法;HTTP 1.0 有GET、POST、HEAD三个方法)。请求URL:       这里填写的URL是不包含IP地址或者域名的,是主机本地文件对应的目录地址,所以我们一般看到的就是“/”。版本version:       格式是HTTP/.这样的格式,比如说HTTP/1.1.这个版本代表的就是我们使用的HTTP协议的版本,现在使用的一般是HTTP/1.1状态码status:       状态码是三个数字,代表的是请求过程中所发生的情况,比如说200代表的是成功,404代表的是找不到文件。原因短语reason-phrase:       是状态码的可读版本,状态码就是一个数字,如果你事先不知道这个数字什么意思,可以先查看一下原因短语。首部header:       注意这里的header我们不是叫做头,而是叫做首部。可能有零个首部也可能有多个首部,每个首部包含一个名字后面跟着一个冒号,然后是一个可选的空格,接着是一个值,然后换行。实体的主体部分entity-body:       实体的主体部分包含一个任意数据组成的数据块,并不是所有的报文都包含实体的主体部分,有时候只是一个空行加换行就结束了。 下面我们举个简单的例子: 请求报文:GET /index.html HTTP/1.1    Accept: text/*Host: www.myweb.com 响应报文:HTTP/1.1 200 OKContent-type: text/plainContent-length: 3  HTTP与CoAP的区别 CoAP是6LowPAN协议栈中的应用层协议,基于REST(表述性状态传递)架构风格,支持与REST进行交互。通常用户可以像使用HTTP协议一样用CoAP协议来访问物联网设备。而且CoAP消息格式使用简单的二进制格式,最小为4个字节。HTTP使用报文格式对于嵌入式设备来说需要传输数据太多,太重,不够灵活。 XMPP协议 XMPP(可扩展通讯和表示协议)是一种基于可扩展标记语言(XML)的协议, 它继承了在XML环境中灵活的发展性。可用于服务类实时通讯、表示和需求响应服务中的XML数据元流式传输。XMPP以Jabber协议为基础,而Jabber是即时通讯中常用的开放式协议。   基本网络结构 XMPP中定义了三个角色,客户端,服务器,网关。通信能够在这三者的任意两个之间双向发生。 服务器同时承担了客户端信息记录,连接管理和信息的路由功能。网关承担着与异构即时通信系统 的互联互通,异构系统可以包括SMS(短信),MSN,ICQ等。基本的网络形式是单客户端通过 TCP/IP连接到单服务器,然后在之上传输XML。 功能 传输的是与即时通讯相关的指令。在以前这些命令要么用2进制的形式发送(比如QQ),要么用纯文本指令加空格加参数加换行符的方式发送(比如MSN)。而XMPP传输的即时通讯指令的逻辑与以往相仿,只是协议的形式变成了XML格式的纯文本。举个例子看看所谓的XML(标准通用标记语言的子集)流是什么样子的?客户端:123456<?xmlversion='1.0'?>to='example_com'xmlns='jabber:client'xmlns:stream='http_etherx_jabber_org/streams'version='1.0'>服务器:1234567<?xmlversion='1.0'?>from='example_com'id='someid'xmlns='jabber:client'xmlns:stream='http_etherx_jabber_org/streams'version='1.0'>工作原理XMPP核心协议通信的基本模式就是先建立一个stream,然后协商一堆安全之类的东西, 中间通信过程就是客户端发送XML Stanza,一个接一个的。服务器根据客户端发送的信息 以及程序的逻辑,发送XML Stanza给客户端。但是这个过程并不是一问一答的,任何时候 都有可能从一方发信给另外一方。通信的最后阶段是关闭流,关闭TCP/IP连接。  网络通信过程中数据冗余率非常高,网络流量中70% 都消耗在 XMPP 协议层了。对于物联网来说,大量计算能力有限且工作在低带宽、不可靠网络的远程传感器和控制设备,省电、省流量是所有底层服务的一个关键技术指标,XMPP协议看起来已经落后了。 SoAP协议 SoAP(简单对象访问协议)是交换数据的一种协议规范,是一种轻量的、简单的、 基于可扩展标记语言(XML)的协议,它被设计成在WEB上交换结构化的和固化的信息。  SOAP 可以和现存的许多因特网协议和格式结合使用,包括超文本传输协议(HTTP), 简单邮件传输协议(SMTP),多用途网际邮件扩充协议(MIME)。它还支持从消息系统到 远程过程调用(RPC)等大量的应用程序。SOAP使用基于XML的数据结构和超文本传输协议 (HTTP)的组合定义了一个标准的方法来使用Internet上各种不同操作环境中的分布式对象。 总结: 从当前物联网应用发展趋势来分析,MQTT协议具有一定的优势。因为目前国内外主要的云计算服务商,比如阿里云、AWS、百度云、Azure以及腾讯云都一概支持MQTT协议。还有一个原因就是MQTT协议比CoAP成熟的要早,所以MQTT具有一定的先发优势。但随着物联网的智能化和多变化的发展,后续物联网应用平台肯定会兼容更多的物联网应用层协议。 作者:HFK_Frank 来源:CSDN 原文:https://blog.csdn.net/acongge2010/article/details/79142380 版权声明:本文为博主原创文章,转载请附上博文链接!
auto_answer 2019-12-02 01:55:21 0 浏览量 回答数 0

回答

微服务 (MicroServices) 架构是当前互联网业界的一个技术热点,圈里有不少同行朋友当前有计划在各自公司开展微服务化体系建设,他们都有相同的疑问:一个微服务架构有哪些技术关注点 (technical concerns)?需要哪些基础框架或组件来支持微服务架构?这些框架或组件该如何选型?笔者之前在两家大型互联网公司参与和主导过大型服务化体系和框架建设,同时在这块也投入了很多时间去学习和研究,有一些经验和学习心得,可以和大家一起分享。 服务注册、发现、负载均衡和健康检查和单块 (Monolithic) 架构不同,微服务架构是由一系列职责单一的细粒度服务构成的分布式网状结构,服务之间通过轻量机制进行通信,这时候必然引入一个服务注册发现问题,也就是说服务提供方要注册通告服务地址,服务的调用方要能发现目标服务,同时服务提供方一般以集群方式提供服务,也就引入了负载均衡和健康检查问题。根据负载均衡 LB 所在位置的不同,目前主要的服务注册、发现和负载均衡方案有三种: 第一种是集中式 LB 方案,如下图 Fig 1,在服务消费者和服务提供者之间有一个独立的 LB,LB 通常是专门的硬件设备如 F5,或者基于软件如 LVS,HAproxy 等实现。LB 上有所有服务的地址映射表,通常由运维配置注册,当服务消费方调用某个目标服务时,它向 LB 发起请求,由 LB 以某种策略(比如 Round-Robin)做负载均衡后将请求转发到目标服务。LB 一般具备健康检查能力,能自动摘除不健康的服务实例。服务消费方如何发现 LB 呢?通常的做法是通过 DNS,运维人员为服务配置一个 DNS 域名,这个域名指向 LB。 Fig 1, 集中式 LB 方案 集中式 LB 方案实现简单,在 LB 上也容易做集中式的访问控制,这一方案目前还是业界主流。集中式 LB 的主要问题是单点问题,所有服务调用流量都经过 LB,当服务数量和调用量大的时候,LB 容易成为瓶颈,且一旦 LB 发生故障对整个系统的影响是灾难性的。另外,LB 在服务消费方和服务提供方之间增加了一跳 (hop),有一定性能开销。 第二种是进程内 LB 方案,针对集中式 LB 的不足,进程内 LB 方案将 LB 的功能以库的形式集成到服务消费方进程里头,该方案也被称为软负载 (Soft Load Balancing) 或者客户端负载方案,下图 Fig 2 展示了这种方案的工作原理。这一方案需要一个服务注册表 (Service Registry) 配合支持服务自注册和自发现,服务提供方启动时,首先将服务地址注册到服务注册表(同时定期报心跳到服务注册表以表明服务的存活状态,相当于健康检查),服务消费方要访问某个服务时,它通过内置的 LB 组件向服务注册表查询(同时缓存并定期刷新)目标服务地址列表,然后以某种负载均衡策略选择一个目标服务地址,最后向目标服务发起请求。这一方案对服务注册表的可用性 (Availability) 要求很高,一般采用能满足高可用分布式一致的组件(例如 Zookeeper, Consul, Etcd 等)来实现。 Fig 2, 进程内 LB 方案 进程内 LB 方案是一种分布式方案,LB 和服务发现能力被分散到每一个服务消费者的进程内部,同时服务消费方和服务提供方之间是直接调用,没有额外开销,性能比较好。但是,该方案以客户库 (Client Library) 的方式集成到服务调用方进程里头,如果企业内有多种不同的语言栈,就要配合开发多种不同的客户端,有一定的研发和维护成本。另外,一旦客户端跟随服务调用方发布到生产环境中,后续如果要对客户库进行升级,势必要求服务调用方修改代码并重新发布,所以该方案的升级推广有不小的阻力。 进程内 LB 的案例是 Netflix 的开源服务框架,对应的组件分别是:Eureka 服务注册表,Karyon 服务端框架支持服务自注册和健康检查,Ribbon 客户端框架支持服务自发现和软路由。另外,阿里开源的服务框架 Dubbo 也是采用类似机制。 第三种是主机独立 LB 进程方案,该方案是针对第二种方案的不足而提出的一种折中方案,原理和第二种方案基本类似,不同之处是,他将 LB 和服务发现功能从进程内移出来,变成主机上的一个独立进程,主机上的一个或者多个服务要访问目标服务时,他们都通过同一主机上的独立 LB 进程做服务发现和负载均衡,见下图 Fig 3。 Fig 3 主机独立 LB 进程方案 该方案也是一种分布式方案,没有单点问题,一个 LB 进程挂了只影响该主机上的服务调用方,服务调用方和 LB 之间是进程内调用,性能好,同时,该方案还简化了服务调用方,不需要为不同语言开发客户库,LB 的升级不需要服务调用方改代码。该方案的不足是部署较复杂,环节多,出错调试排查问题不方便。 该方案的典型案例是 Airbnb 的 SmartStack 服务发现框架,对应组件分别是:Zookeeper 作为服务注册表,Nerve 独立进程负责服务注册和健康检查,Synapse/HAproxy 独立进程负责服务发现和负载均衡。Google 最新推出的基于容器的 PaaS 平台 Kubernetes,其内部服务发现采用类似的机制。 服务前端路由微服务除了内部相互之间调用和通信之外,最终要以某种方式暴露出去,才能让外界系统(例如客户的浏览器、移动设备等等)访问到,这就涉及服务的前端路由,对应的组件是服务网关 (Service Gateway),见图 Fig 4,网关是连接企业内部和外部系统的一道门,有如下关键作用: 服务反向路由,网关要负责将外部请求反向路由到内部具体的微服务,这样虽然企业内部是复杂的分布式微服务结构,但是外部系统从网关上看到的就像是一个统一的完整服务,网关屏蔽了后台服务的复杂性,同时也屏蔽了后台服务的升级和变化。安全认证和防爬虫,所有外部请求必须经过网关,网关可以集中对访问进行安全控制,比如用户认证和授权,同时还可以分析访问模式实现防爬虫功能,网关是连接企业内外系统的安全之门。限流和容错,在流量高峰期,网关可以限制流量,保护后台系统不被大流量冲垮,在内部系统出现故障时,网关可以集中做容错,保持外部良好的用户体验。监控,网关可以集中监控访问量,调用延迟,错误计数和访问模式,为后端的性能优化或者扩容提供数据支持。日志,网关可以收集所有的访问日志,进入后台系统做进一步分析。 Fig 4, 服务网关 除以上基本能力外,网关还可以实现线上引流,线上压测,线上调试 (Surgical debugging),金丝雀测试 (Canary Testing),数据中心双活 (Active-Active HA) 等高级功能。 网关通常工作在 7 层,有一定的计算逻辑,一般以集群方式部署,前置 LB 进行负载均衡。 开源的网关组件有 Netflix 的 Zuul,特点是动态可热部署的过滤器 (filter) 机制,其它如 HAproxy,Nginx 等都可以扩展作为网关使用。 在介绍过服务注册表和网关等组件之后,我们可以通过一个简化的微服务架构图 (Fig 5) 来更加直观地展示整个微服务体系内的服务注册发现和路由机制,该图假定采用进程内 LB 服务发现和负载均衡机制。在下图 Fig 5 的微服务架构中,服务简化为两层,后端通用服务(也称中间层服务 Middle Tier Service)和前端服务(也称边缘服务 Edge Service,前端服务的作用是对后端服务做必要的聚合和裁剪后暴露给外部不同的设备,如 PC,Pad 或者 Phone)。后端服务启动时会将地址信息注册到服务注册表,前端服务通过查询服务注册表就可以发现然后调用后端服务;前端服务启动时也会将地址信息注册到服务注册表,这样网关通过查询服务注册表就可以将请求路由到目标前端服务,这样整个微服务体系的服务自注册自发现和软路由就通过服务注册表和网关串联起来了。如果以面向对象设计模式的视角来看,网关类似 Proxy 代理或者 Façade 门面模式,而服务注册表和服务自注册自发现类似 IoC 依赖注入模式,微服务可以理解为基于网关代理和注册表 IoC 构建的分布式系统。 Fig 5, 简化的微服务架构图 服务容错当企业微服务化以后,服务之间会有错综复杂的依赖关系,例如,一个前端请求一般会依赖于多个后端服务,技术上称为 1 -> N 扇出 (见图 Fig 6)。在实际生产环境中,服务往往不是百分百可靠,服务可能会出错或者产生延迟,如果一个应用不能对其依赖的故障进行容错和隔离,那么该应用本身就处在被拖垮的风险中。在一个高流量的网站中,某个单一后端一旦发生延迟,可能在数秒内导致所有应用资源 (线程,队列等) 被耗尽,造成所谓的雪崩效应 (Cascading Failure,见图 Fig 7),严重时可致整个网站瘫痪。 Fig 6, 服务依赖 Fig 7, 高峰期单个服务延迟致雪崩效应 经过多年的探索和实践,业界在分布式服务容错一块探索出了一套有效的容错模式和最佳实践,主要包括: Fig 8, 弹性电路保护状态图 电路熔断器模式 (Circuit Breaker Patten), 该模式的原理类似于家里的电路熔断器,如果家里的电路发生短路,熔断器能够主动熔断电路,以避免灾难性损失。在分布式系统中应用电路熔断器模式后,当目标服务慢或者大量超时,调用方能够主动熔断,以防止服务被进一步拖垮;如果情况又好转了,电路又能自动恢复,这就是所谓的弹性容错,系统有自恢复能力。下图 Fig 8 是一个典型的具备弹性恢复能力的电路保护器状态图,正常状态下,电路处于关闭状态 (Closed),如果调用持续出错或者超时,电路被打开进入熔断状态 (Open),后续一段时间内的所有调用都会被拒绝 (Fail Fast),一段时间以后,保护器会尝试进入半熔断状态 (Half-Open),允许少量请求进来尝试,如果调用仍然失败,则回到熔断状态,如果调用成功,则回到电路闭合状态。舱壁隔离模式 (Bulkhead Isolation Pattern),顾名思义,该模式像舱壁一样对资源或失败单元进行隔离,如果一个船舱破了进水,只损失一个船舱,其它船舱可以不受影响 。线程隔离 (Thread Isolation) 就是舱壁隔离模式的一个例子,假定一个应用程序 A 调用了 Svc1/Svc2/Svc3 三个服务,且部署 A 的容器一共有 120 个工作线程,采用线程隔离机制,可以给对 Svc1/Svc2/Svc3 的调用各分配 40 个线程,当 Svc2 慢了,给 Svc2 分配的 40 个线程因慢而阻塞并最终耗尽,线程隔离可以保证给 Svc1/Svc3 分配的 80 个线程可以不受影响,如果没有这种隔离机制,当 Svc2 慢的时候,120 个工作线程会很快全部被对 Svc2 的调用吃光,整个应用程序会全部慢下来。限流 (Rate Limiting/Load Shedder),服务总有容量限制,没有限流机制的服务很容易在突发流量 (秒杀,双十一) 时被冲垮。限流通常指对服务限定并发访问量,比如单位时间只允许 100 个并发调用,对超过这个限制的请求要拒绝并回退。回退 (fallback),在熔断或者限流发生的时候,应用程序的后续处理逻辑是什么?回退是系统的弹性恢复能力,常见的处理策略有,直接抛出异常,也称快速失败 (Fail Fast),也可以返回空值或缺省值,还可以返回备份数据,如果主服务熔断了,可以从备份服务获取数据。Netflix 将上述容错模式和最佳实践集成到一个称为 Hystrix 的开源组件中,凡是需要容错的依赖点 (服务,缓存,数据库访问等),开发人员只需要将调用封装在 Hystrix Command 里头,则相关调用就自动置于 Hystrix 的弹性容错保护之下。Hystrix 组件已经在 Netflix 经过多年运维验证,是 Netflix 微服务平台稳定性和弹性的基石,正逐渐被社区接受为标准容错组件。 服务框架微服务化以后,为了让业务开发人员专注于业务逻辑实现,避免冗余和重复劳动,规范研发提升效率,必然要将一些公共关注点推到框架层面。服务框架 (Fig 9) 主要封装公共关注点逻辑,包括: Fig 9, 服务框架 服务注册、发现、负载均衡和健康检查,假定采用进程内 LB 方案,那么服务自注册一般统一做在服务器端框架中,健康检查逻辑由具体业务服务定制,框架层提供调用健康检查逻辑的机制,服务发现和负载均衡则集成在服务客户端框架中。监控日志,框架一方面要记录重要的框架层日志、metrics 和调用链数据,还要将日志、metrics 等接口暴露出来,让业务层能根据需要记录业务日志数据。在运行环境中,所有日志数据一般集中落地到企业后台日志系统,做进一步分析和处理。REST/RPC 和序列化,框架层要支持将业务逻辑以 HTTP/REST 或者 RPC 方式暴露出来,HTTP/REST 是当前主流 API 暴露方式,在性能要求高的场合则可采用 Binary/RPC 方式。针对当前多样化的设备类型 (浏览器、普通 PC、无线设备等),框架层要支持可定制的序列化机制,例如,对浏览器,框架支持输出 Ajax 友好的 JSON 消息格式,而对无线设备上的 Native App,框架支持输出性能高的 Binary 消息格式。配置,除了支持普通配置文件方式的配置,框架层还可集成动态运行时配置,能够在运行时针对不同环境动态调整服务的参数和配置。限流和容错,框架集成限流容错组件,能够在运行时自动限流和容错,保护服务,如果进一步和动态配置相结合,还可以实现动态限流和熔断。管理接口,框架集成管理接口,一方面可以在线查看框架和服务内部状态,同时还可以动态调整内部状态,对调试、监控和管理能提供快速反馈。Spring Boot 微框架的 Actuator 模块就是一个强大的管理接口。统一错误处理,对于框架层和服务的内部异常,如果框架层能够统一处理并记录日志,对服务监控和快速问题定位有很大帮助。安全,安全和访问控制逻辑可以在框架层统一进行封装,可做成插件形式,具体业务服务根据需要加载相关安全插件。文档自动生成,文档的书写和同步一直是一个痛点,框架层如果能支持文档的自动生成和同步,会给使用 API 的开发和测试人员带来极大便利。Swagger 是一种流行 Restful API 的文档方案。当前业界比较成熟的微服务框架有 Netflix 的 Karyon/Ribbon,Spring 的 Spring Boot/Cloud,阿里的 Dubbo 等。 运行期配置管理服务一般有很多依赖配置,例如访问数据库有连接字符串配置,连接池大小和连接超时配置,这些配置在不同环境 (开发 / 测试 / 生产) 一般不同,比如生产环境需要配连接池,而开发测试环境可能不配,另外有些参数配置在运行期可能还要动态调整,例如,运行时根据流量状况动态调整限流和熔断阀值。目前比较常见的做法是搭建一个运行时配置中心支持微服务的动态配置,简化架构如下图 (Fig 10): Fig 10, 服务配置中心 动态配置存放在集中的配置服务器上,用户通过管理界面配置和调整服务配置,具体服务通过定期拉 (Scheduled Pull) 的方式或者服务器推 (Server-side Push) 的方式更新动态配置,拉方式比较可靠,但会有延迟同时有无效网络开销 (假设配置不常更新),服务器推方式能及时更新配置,但是实现较复杂,一般在服务和配置服务器之间要建立长连接。配置中心还要解决配置的版本控制和审计问题,对于大规模服务化环境,配置中心还要考虑分布式和高可用问题。 配置中心比较成熟的开源方案有百度的 Disconf,360 的 QConf,Spring 的 Cloud Config 和阿里的 Diamond 等。 Netflix 的微服务框架Netflix 是一家成功实践微服务架构的互联网公司,几年前,Netflix 就把它的几乎整个微服务框架栈开源贡献给了社区,这些框架和组件包括: Eureka: 服务注册发现框架Zuul: 服务网关Karyon: 服务端框架Ribbon: 客户端框架Hystrix: 服务容错组件Archaius: 服务配置组件Servo: Metrics 组件Blitz4j: 日志组件下图 Fig 11 展示了基于这些组件构建的一个微服务框架体系,来自 recipes-rss。 Fig 11, 基于 Netflix 开源组件的微服务框架 Netflix 的开源框架组件已经在 Netflix 的大规模分布式微服务环境中经过多年的生产实战验证,正逐步被社区接受为构造微服务框架的标准组件。Pivotal 去年推出的 Spring Cloud 开源产品,主要是基于对 Netflix 开源组件的进一步封装,方便 Spring 开发人员构建微服务基础框架。对于一些打算构建微服务框架体系的公司来说,充分利用或参考借鉴 Netflix 的开源微服务组件 (或 Spring Cloud),在此基础上进行必要的企业定制,无疑是通向微服务架构的捷径。 原文地址:https://www.infoq.cn/article/basis-frameworkto-implement-micro-service#anch130564%20%EF%BC%8C
auto_answer 2019-12-02 01:55:22 0 浏览量 回答数 0

云产品推荐

上海奇点人才服务相关的云产品 小程序定制 上海微企信息技术相关的云产品 国内短信套餐包 ECS云服务器安全配置相关的云产品 开发者问答 阿里云建站 自然场景识别相关的云产品 万网 小程序开发制作 视频内容分析 视频集锦 代理记账服务 阿里云AIoT