• 关于

    数量控制工作原理

    的搜索结果

回答

1、覆盖范围:北斗导航系统是覆盖中国本土的区域导航系统。覆盖范围东经约70°一140°,北纬5°一55°。GPS是覆盖全球的全天候导航系统。能够确保地球上任何地点、任何时间能同时观测到6-9颗卫星(实际上最多能观测到11颗)。 2、卫星数量和轨道特性:北斗导航系统是在地球赤道平面上设置2颗地球同步卫星颗卫星的赤道角距约60°。GPS是在6个轨道平面上设置24颗卫星,轨道赤道倾角55°,轨道面赤道角距60°。航卫星为准同步轨道,绕地球一周11小时58分。 3、定位原理:北斗导航系统是主动式双向测距二维导航。地面中心控制系统解算,供用户三维定位数据。GPS是被动式伪码单向测距三维导航。由用户设备独立解算自己三维定位数据。"北斗一号"的这种工作原理带来两个方面的问题,一是用户定位的同时失去了无线电隐蔽性,这在军事上相当不利,另一方面由于设备必须包含发射机,因此在体积、重量上、价格和功耗方面处于不利的地位。 4、定位精度:北斗导航系统三维定位精度约几十米,授时精度约100ns。GPS三维定位精度P码目前己由16m提高到6m,C/A码目前己由25-100m提高到12m,授时精度日前约20ns。 5、用户容量:北斗导航系统由于是主动双向测距的询问--应答系统,用户设备与地球同步卫星之间不仅要接收地面中心控制系统的询问信号,还要求用户设备向同步卫星发射应答信号,这样,系统的用户容量取决于用户允许的信道阻塞率、询问信号速率和用户的响应频率。因此,北斗导航系统的用户设备容量是有限的。GPS 是单向测距系统,用户设备只要接收导航卫星发出的导航电文即可进行测距定位,因此GPS的用户设备容量是无限的。 6、生存能力:和所有导航定位卫星系统一样,"北斗一号"基于中心控制系统和卫星的工作,但是"北斗一号"对中心控制系统的依赖性明显要大很多,因为定位解算在那里而不是由用户设备完成的。为了弥补这种系统易损性,GPS正在发展星际横向数据链技术,使万一主控站被毁后GPS卫星可以独立运行。而"北斗一号" 系统从原理上排除了这种可能性,一旦中心控制系统受损,系统就不能继续工作了。 7、实时性:"北斗一号"用户的定位申请要送回中心控制系统,中心控制系统解算出用户的三维位置数据之后再发回用户,其间要经过地球静止卫星走一个来回,再加上卫星转发,中心控制系统的处理,时间延迟就更长了,因此对于高速运动体,就加大了定位的误差。 此外,"北斗一号"卫星导航系统也有一些自身的特点: 1. "北斗"具有定位和通信双重作用,具备的短信通讯功能就是GPS所不具备的。 2. "北斗"定位精度一点二米。 3. "北斗"终端价格两万元左右。 4.采用接收终端不需铺设地面基站。 5.灾难中心的船只一秒钟就可以发出信息。
玄学酱 2019-12-02 01:16:50 0 浏览量 回答数 0

回答

作为我国自行研制的一款全球卫星定位与通信系统,北斗卫星导航系统也是继美国全球定位系统和俄GLONASS之后的第三个成熟的卫星导航系统。系统由空间端、地面端和用户端三部分组成。空间端包括5颗静止轨道卫星和30颗非静止轨道卫星。现在中国已经把16颗导航卫星和4颗实验卫星送入太空,未来10年,将再发射40颗卫星加入该系统。用户端由北斗用户终端以及与美国GPS、俄罗斯“格洛纳斯”(GLONASS)、欧盟“伽利略”(GALILEO)等其他卫星导航系统兼容的终端组成。 1、覆盖范围:北斗导航系统是覆盖中国本土的区域导航系统。覆盖范围东经约70°一140°,北纬5°一55°。GPS是覆盖全球的全天候导航系统。能够确保地球上任何地点、任何时间能同时观测到6-9颗卫星(实际上最多能观测到11颗)。 2、卫星数量和轨道特性:北斗导航系统是在地球赤道平面上设置2颗地球同步卫星颗卫星的赤道角距约60°。GPS是在6个轨道平面上设置24颗卫星,轨道赤道倾角55°,轨道面赤道角距60°。航卫星为准同步轨道,绕地球一周11小时58分。 3、定位原理:北斗导航系统是主动式双向测距二维导航。地面中心控制系统解算,供用户三维定位数据。GPS是被动式伪码单向测距三维导航。由用户设备独立解算自己三维定位数据。"北斗一号"的这种工作原理带来两个方面的问题,一是用户定位的同时失去了无线电隐蔽性,这在军事上相当不利,另一方面由于设备必须包含发射机,因此在体积、重量上、价格和功耗方面处于不利的地位。 4、定位精度:北斗导航系统三维定位精度约几十米,授时精度约100ns。GPS三维定位精度P码目前己由16m提高到6m,C/A码目前己由25-100m提高到12m,授时精度日前约20ns。 5、用户容量:北斗导航系统由于是主动双向测距的询问--应答系统,用户设备与地球同步卫星之间不仅要接收地面中心控制系统的询问信号,还要求用户设备向同步卫星发射应答信号,这样,系统的用户容量取决于用户允许的信道阻塞率、询问信号速率和用户的响应频率。因此,北斗导航系统的用户设备容量是有限的。GPS 是单向测距系统,用户设备只要接收导航卫星发出的导航电文即可进行测距定位,因此GPS的用户设备容量是无限的。  6、生存能力:和所有导航定位卫星系统一样,"北斗一号"基于中心控制系统和卫星的工作,但是"北斗一号"对中心控制系统的依赖性明显要大很多,因为定位解算在那里而不是由用户设备完成的。为了弥补这种系统易损性,GPS正在发展星际横向数据链技术,使万一主控站被毁后GPS卫星可以独立运行。而"北斗一号" 系统从原理上排除了这种可能性,一旦中心控制系统受损,系统就不能继续工作了。  7、实时性:"北斗一号"用户的定位申请要送回中心控制系统,中心控制系统解算出用户的三维位置数据之后再发回用户,其间要经过地球静止卫星走一个来回,再加上卫星转发,中心控制系统的处理,时间延迟就更长了,因此对于高速运动体,就加大了定位的误差。
沉默术士 2019-12-02 01:16:50 0 浏览量 回答数 0

回答

 北斗卫星定位系统是由中国建立的区域导航定位系统。该系统由三颗(两颗工作卫星、一颗备用卫星)北斗定位卫星(北斗一号)、地面控制中心为主的地面部份、北斗用户终端三部分组成。北斗定位系统可向用户提供全天候、二十四小时的即时定位服务,授时精度可达数十纳秒(ns)的同步精度,其定位精度与GPS相当。北斗一号导航定位卫星由中国空间技术研究院研究制造。三颗导航定位卫星的发射时间分别为:2000年10月31日;2000年12月21日;2003年5月25日,第三颗是备用卫星。2008年北京奥运会期间,它将在交通、场馆安全的定位监控方面,和已有的GPS卫星定位系统一起,发挥“双保险”作用。   北斗一号卫星定位系统的英文简称为BD,在ITU(国际电信联合会)登记的无线电频段为L波段(发射)和S波段(接收)。 北斗二代卫星定位系统的英文为Compass(即指南针),在ITU登记的无线电频段为L波段。   北斗一号系统的基本功能包括:定位、通信(短消息)和授时。   北斗二代系统的功能与GPS相同,即定位与授时。 编辑本段系统工作原理   “北斗一号”卫星定位系出用户到第一颗卫星的距离,以及用户到两颗卫星距离之和,从而知道用户处于一个以第一颗卫星为球心的一个球面,和以两颗卫星为焦点的椭球面之间的交线上。另外中心控制系统从存储在计算机内的数字化地形图查寻到用户高程值,又可知道用户出于某一与地球基准椭球面平行的椭球面上。从而中心控制系统可最终计算出用户所在点的三维坐标,这个坐标经加密由出站信号发送给用户。   “北斗一号”的覆盖范围是北纬5°一55°,东经70°一140°之间的心脏地区,上大下小,最宽处在北纬35°左右。其定位精度为水平精度100米(1σ),设立标校站之后为20米(类似差分状态)。工作频率:2491.75MHz。系统能容纳的用户数为每小时540000户。 编辑本段与GPS系统对比   1、覆盖范围:北斗导航系统是覆盖我国本土的区域导航系统。覆盖范围东经约70°一140°,北纬5°一55°。GPS是覆盖全球的全天候导航系统。能够确保地球上任何地点、任何时间能同时观测到6-9颗卫星(实际上最多能观测到11颗)。   2、卫星数量和轨道特性:北斗导航系统是在地球赤道平面上设置2颗地球同步卫星颗卫星的赤道角距约60°。GPS是在6个轨道平面上设置24颗卫星,轨道赤道倾角55°,轨道面赤道角距60°。航卫星为准同步轨道,绕地球一周11小时58分。   3、定位原理:北斗导航系统是主动式双向测距二维导航。地面中心控制系统解算,供用户三维定位数据。GPS是被动式伪码单向测距三维导航。由用户设备独立解算自位解算在那里而不是由用户设备完成的。为了弥补这种系统易损性,GPS正在发展星际横向数据链技术,使万一主控站被毁后GPS卫星可以独立运行。而“北斗一号”系统从原理上排除了这种可能性,一旦中心控制系统受损,系统就不能继续工作了。   4、实时性:“北斗一号”用户的定位申请要送回中心控制系统,中心控制系统解算出用户的三维位置数据之后再发回用户,其间要经过地球静止卫星走一个来回,再加上卫星转发,中心控制系统的处理,时间延迟就更长了,因此对于高速运动体,就加大了定位的误差。此外,“北斗一号”卫星导航系统也有一些自身的特点,其具备的短信通讯功能就是GPS所不具备的。   综上所述,北斗导航系统具有卫星数量少、投资小、用户设备简单价廉、能实现一定区域的导航定位、通讯等多用途,可满足当前我国陆、海、空运输导航定位的需求。缺点是不能覆盖两极地区,赤道附近定位精度差,只能二维主动式定位,且需提供用户高程数据,不能满足高动态和保密的军事用户要求,用户数量受一定限制。但最重要的是,“北斗一号”导航系统是我国独立自主建立的卫星导少的初步起步系统。此外,该系统并不排斥国内民用市场对GPS的广泛使用。相反,在此基础上还将建立中国的GPS广域差分系统。可以使受SA干扰的GPS民用码接收机的定位精度由百米级修正到数米级,可以更好的促进GPS在民间的利用。当然,我们也需要认识到,随着我军高技术武器的不断发展,对导航定位的信息支持要求越来越高。
管理贝贝 2019-12-02 01:16:55 0 浏览量 回答数 0

回答

北斗导航系统 北斗卫星导航定位系统,是中国自行研制开发的区域性有源三维卫星定位与通信系统(CNSS),是除美国的GPS、俄罗斯的GLONASS之后第三个成熟的卫星导航系统。 该系统由三颗(两颗工作卫星、一颗备用卫星)北斗定位卫星(北斗一号)、地面控制中心为主的地面部份、北斗用户终端三部分组成。可向用户提供全天候、二十四小时的即时定位服务,定位精度可达数十柰秒(ns)的同步精度,其精度与GPS相当。 三颗导航定位卫星的发射时间分别为: 2000年10月31日; 2000年12月21日; 2003年5月25日,第三颗是备用卫星。 系统构成与工作原理 北斗卫星导航定位系统的系统构成有:两颗地球静止轨道卫星、地面中心站、用户终端。 北斗卫星导航定位系统的基本工作原理是“双星定位”:以2颗在轨卫星的已知坐标为圆心,各以测定的卫星至用户终端的距离为半径,形成2个球面,用户终端将位于这2个球面交线的圆弧上。地面中心站配有电子高程地图,提供一个以地心为球心、以球心至地球表面高度为半径的非均匀球面。用数学方法求解圆弧与地球表面的交点即可获得用户的位置。 由于在定位时需要用户终端向定位卫星发送定位信号,由信号到达定位卫星时间的差值计算用户位置,所以被称为“有源定位”。 北斗星导航系统与GPS系统比较 1、覆盖范围:北斗导航系统是覆盖中国本土的区域导航系统。覆盖范围东经约70°一140°,北纬5°一55°。GPS是覆盖全球的全天候导航系统。能够确保地球上任何地点、任何时间能同时观测到6-9颗卫星(实际上最多能观测到11颗)。 2、卫星数量和轨道特性:北斗导航系统是在地球赤道平面上设置2颗地球同步卫星颗卫星的赤道角距约60°。GPS是在6个轨道平面上设置24颗卫星,轨道赤道倾角55°,轨道面赤道角距60°。航卫星为准同步轨道,绕地球一周11小时58分。 3、定位原理:北斗导航系统是主动式双向测距二维导航。地面中心控制系统解算,供用户三维定位数据。GPS是被动式伪码单向测距三维导航。由用户设备独立解算自己三维定位数据。“北斗一号”的这种工作原理带来两个方面的问题,一是用户定位的同时失去了无线电隐蔽性,这在军事上相当不利,另一方面由于设备必须包含发射机,因此在体积、重量上、价格和功耗方面处于不利的地位。 4、定位精度:北斗导航系统三维定位精度约几十米,授时精度约100ns。GPS三维定位精度P码目前己由16m提高到6m,C/A码目前己由25-100m提高到12m,授时精度日前约20ns。 5、用户容量:北斗导航系统由于是主动双向测距的询问--应答系统,用户设备与地球同步卫星之间不仅要接收地面中心控制系统的询问信号,还要求用户设备向同步卫星发射应答信号,这样,系统的用户容量取决于用户允许的信道阻塞率、询问信号速率和用户的响应频率。因此,北斗导航系统的用户设备容量是有限的。GPS 是单向测距系统,用户设备只要接收导航卫星发出的导航电文即可进行测距定位,因此GPS的用户设备容量是无限的。 6、生存能力:和所有导航定位卫星系统一样,“北斗一号”基于中心控制系统和卫星的工作,但是“北斗一号”对中心控制系统的依赖性明显要大很多,因为定位解算在那里而不是由用户设备完成的。为了弥补这种系统易损性,GPS正在发展星际横向数据链技术,使万一主控站被毁后GPS卫星可以独立运行。而“北斗一号” 系统从原理上排除了这种可能性,一旦中心控制系统受损,系统就不能继续工作了。 7、实时性:“北斗一号”用户的定位申请要送回中心控制系统,中心控制系统解算出用户的三维位置数据之后再发回用户,其间要经过地球静止卫星走一个来回,再加上卫星转发,中心控制系统的处理,时间延迟就更长了,因此对于高速运动体,就加大了定位的误差。此外,“北斗一号”卫星导航系统也有一些自身的特点,其具备的短信通讯功能就是GPS所不具备的。 中新网西昌4月14日电 (记者 孙自法) 中国有关部门负责人十四日在此间表示,在未来几年里,中国将陆续发射系列北斗导航卫星,计划二○○八年左右满足中国及周边地区用户对卫星导航系统的需求,并进行系统组网和试验,逐步扩展为全球卫星导航系统。   当天凌晨,中国在西昌卫星发射中心用“长征三号甲”运载火箭,成功将一颗北斗导航卫星送入太空。而两个月前,中国已在西昌成功发射一颗北斗导航试验卫星。   中国这个要逐步扩展为全球卫星导航系统的北斗导航系统(COMPASS),将主要用于国家经济建设,为中国的交通运输、气象、石油、海洋、森林防火、灾害预报、通信、公安以及其他特殊行业提供高效的导航定位服务。   据悉,建设中的中国北斗导航系统(COMPASS)空间段计划由五颗静止轨道卫星和三十颗非静止轨道卫星组成,提供两种服务方式,即开放服务和授权服务。   卫星导航系统为人类带来了巨大的社会和经济效益,目前世界上只有少数几个国家能够自主研制生产卫星导航系统,正在运行的有美国的GPS系统和俄罗斯的GLONASS系统,欧洲的伽利略全球卫星定位计划也在紧锣密鼓地进行当中。(完) 中关宝评论:随着此星的发射及随后的计划,中国北斗导航系统已将已前北以前的北斗双星定位概概念改变,中国也即将成为世界的卫星导航定位强国。
聚小编 2019-12-02 01:16:55 0 浏览量 回答数 0

回答

一张图说明CDN网络的原理2013年07月25日 14:55:25阅读数:528731.用户向浏览器输入www.web.com这个域名,浏览器第一次发现本地没有dns缓存,则向网站的DNS服务器请求;2.网站的DNS域名解析器设置了CNAME,指向了www.web.51cdn.com,请求指向了CDN网络中的智能DNS负载均衡系统;3.智能DNS负载均衡系统解析域名,把对用户响应速度最快的IP节点返回给用户;4.用户向该IP节点(CDN服务器)发出请求;5.由于是第一次访问,CDN服务器会向原web站点请求,并缓存内容;6.请求结果发给用户。CDN网络是在用户和服务器之间增加Cache层,如何将用户的请求引导到Cache上获得源服务器的数据,主要是通过接管DNS实现,这就是CDN的最基本的原理,当然很多细节没有涉及到,比如第1步,首先向本地的DNS服务器请求。第5步,内容淘汰机制(根据TTL)等。但原理大体如此。当用户访问加入CDN服务的网站时,域名解析请求将最终交给全局负载均衡DNS进行处理。全局负载均衡DNS通过一组预先定义好的策略,将当时最接近用 户的节点地址提供给用户,使用户能够得到快速的服务。同时,它还与分布在世界各地的所有CDNC节点保持通信,搜集各节点的通信状态,确保不将用户的请求 分配到不可用的CDN节点上,实际上是通过DNS做全局负载均衡。对于普通的Internet用户来讲,每个CDN节点就相当于一个放置在它周围的WEB。通过全局负载均衡DNS的控制,用户的请求被透明地指向离他最近的节点,节点中CDN服务器会像网站的原始服务器一样,响应用户的请求。由于它离用户更近,因而响应时间必然更快。每个CDN节点由两部分组成:负载均衡设备和高速缓存服务器负载均衡设备负责每个节点中各个Cache的负载均衡,保证节点的工作效率;同时,负载均衡设备还负责收集节点与周围环境的信息,保持与全局负载DNS的通信,实现整个系统的负载均衡。CDN的管理系统是整个系统能够正常运转的保证。它不仅能对系统中的各个子系统和设备进行实时监控,对各种故障产生相应的告警,还可以实时监测到系统中 总的流量和各节点的流量,并保存在系统的数据库中,使网管人员能够方便地进行进一步分析。通过完善的网管系统,用户可以对系统配置进行修改。理论上,最简单的CDN网络有一个负责全局负载均衡的DNS和各节点一台Cache,即可运行。DNS支持根据用户源IP地址解析不同的IP,实现 就近访问。为了保证高可用性等,需要监视各节点的流量、健康状况等。一个节点的单台Cache承载数量不够时,才需要多台Cache,多台Cache同时 工作,才需要负载均衡器,使Cache群协同工作。
xuning715 2019-12-02 01:11:44 0 浏览量 回答数 0

回答

简介 本文主要介绍把 ECI 通过虚拟节点(virtual node)方式接入到您的阿里云 Kubernetes 集群,ECI 与 Kubernetes 的Pod 为一一对应的关系。有了虚拟节点,当您的 Kubernetes 集群需要扩容时,无需规划node节点计算容量,直接使用虚拟节点动态创建ECI实例,ECI实例与您集群中的真实节点上的Pod网络互联互通。虚拟节点的工作原理参考 virtual-kubelet 。此外,虚拟节点以Pod为单位按需收费,收费规则参考 ECI计费ack-vn-scenario 前置准备 登录阿里云容器服务 Kubernetes 控制台 查看您的集群。如果您还没有集群,参考创建 Kubernetes 集群 安装 ack-virtual-node 插件 配置虚拟节点(可选) 1. 在控制台配置虚拟节点 登录容器服务 Kubernetes 控制台,依次选择 『节点』—>『集群』,确认虚拟节点已经部署完成 ack1 登录容器服务 Kubernetes 控制台,依次点击 『市场』 —>『应用目录』 —> 『Helm 发布列表』 ack2 选择需要编辑的虚拟节点,点击『更新』 ack3 更改配置,本章节主要介绍配置多可用区和Pod quota, 其余配置参考 部署virtual-kubelet 配置多可用区:编辑env下的 ECI_VSWITCH ,配置多可用区交换机ID(交换机ID与可用区为一一对应关系,您可以访问 专有网络控制台 查询您的交换机信息),注意VSwitch要属于同一个VPC下,编辑完成后点击 『更新』,配置完成之后,新创建的Pod将会随机调度到多可用区,如果某个可用区出现库存不足,虚拟节点将会为您往其他可用区调度。ack5 配置虚拟节点Pod quota,以下是相关参数说明,由于virtual-kubelet会以Pod形态部署在您集群的真实节点,如果Pod数量超过1000,virtual-kubelet负载较大,建议把virtual-kubelet所在真实节点的配置升级到8c16g以上。参考 升级ECS配置 参数 参数说明 ECI_VSWITCH 虚拟节点交换机配置 ECI_QUOTA_POD 虚拟节点可弹出的Pod上限,默认值1000个 ECI_QUOTA_CPU 虚拟节点可以弹出的CPU总核数,默认值64000 ECI_QUOTA_MEMORY 虚拟节点可以弹出的Memory总数,默认值64Ti 在集群中配置虚拟节点 通过以下命令获取虚拟节点的运行状况,注意这里需要指定命名空间为 kube-system kubectl get deploy -n kube-system 下图中的 ack-virtaul-node-controller 就是虚拟节点 ack6 通过以下命令编辑虚拟节点的配置信息,注意这里需要指定命名空间为 kube-system kubectl edit deploy ack-virtual-node-controller -n kube-system --record 将Pod创建调度到虚拟节点上 请参考 在虚拟节点上创建Pod 真实节点资源不够自动调度到虚拟节点 当您的真实节点cpu、mem资源不够时,您可以使用 virtual-kubelet-autoscaler 插件将Pod创建调度到虚拟节点,无需再预先分配node资源,具体方式参考 通过 virtual-kubelet-autoscaler 将Pod自动调度到虚拟节点
1934890530796658 2020-03-20 18:47:11 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

回答

一 容器 在学习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

回答

您可以通过容器服务管理控制台,可视化升级您集群的 Kubernetes 版本。升级集群的过程包含升级前置检查、升级Master(独占版会展示当前正在升级的 Master 编号)、升级 Node(会展示已经升级的节点数和总节点数)。 背景信息 您可以在 Kubernetes 集群列表页面查看您的集群的 Kubernetes 版本,以及当前是否有新的版本可供升级。 待升级版本 功能原理 下面主要为您介绍集群升级过程中的相关功能及实现原理。功能原理 集群升级策略 集群升级策略定义了您将使用怎样的策略对集群进行升级。目前默认策略为分批升级。分批升级会在升级 Node 阶段对集群内的节点进行分批升级。其具体策略为: 第一批升级的节点数为 1,后续的批次以 2 的幂数进行增长。暂停后重新恢复升级的第一批次为 1,后续也是以 2 的幂数进行增长。 每一批节点的最大数量不会超过节点总数的 10%。 集群升级前置检查 在您开始集群升级之后,我们会为您自动启动集群升级前置检查。该检查会对集群进行多项健康检查,以确保您的集群可以顺利的完成此次升级。 如果您的集群存在不合理配置或者潜在风险,则无法通过前置检查,如下图所示。 单击查看详情按钮。跳转到集群运维页面,查看具体的失败原因。查看报错 说明 如果遇到前置检查失败请自行修复,或者提交工单申请。 升级检查仅针对集群升级前进行的前置检查,即使不通过也不会影响当前集群的运行及集群状态。 如果您的集群顺利通过升级检查。则可以进入集群升级环节。 集群升级暂停 通过集群升级暂停功能,您可以在集群升级的任意阶段对其升级进程进行暂停。 说明 暂停升级之后,当前批次已经开始升级的节点会完成升级。还未开始升级的节点不会升级。 集群暂停状态为集群升级的中间状态,建议您不要在此时对集群进行操作,并尽快完成升级过程。 您可以在集群成功暂停之后,单击继续,恢复集群的升级进程。 如果集群升级过程中发生错误,集群升级进程会被系统所暂停。具体失败原因会展示在页面下方详情中。您可根据报错进行排查或者提交工单申请。 集群升级取消 您可以在暂停升级后,单击取消,对本次升级进行取消操作。 说明 取消升级之后,当前批次已经开始升级的节点会完成升级。还未开始升级的节点不会升级。 已经完成升级的节点不受影响。 注意事项 集群升级需要机器可以公网访问,以便下载升级所需的软件包。 集群升级 Kubernetes 过程中,可能会有升级失败的情况,为了您的数据安全,强烈建议您先打快照然后再升级。有关 ECS 打快照的操作参见创建快照。 集群升级 Kubernetes 过程中,集群上的应用不会中断。如果应用强依赖于 API Server 可能会有短暂影响。 由于老版本的 FlexVolume(v1.11.2.5 及以前)挂载的 OSS 卷在升级的时候会重新挂载,使用 OSS 卷的 Pod 在集群升级后需要重建。 如果您对 Kubernetes 集群有过任何的配置更改(例如打开了 swap 分区),则升级过程有可能失败。 集群升级过程中您可以在一批节点升级完成后中断进程,此时集群处于升级的中间状态,我们建议您不要对集群进行操作,并尽快完成升级过程。处于中间状态的集群会在 15 日之后关闭升级过程,同时清理一切升级相关的事件和日志信息。 集群升级过程中,如非发生错误,请勿修改 kube-upgrade 命名空间下面的相关资源。 如集群升级失败,升级过程会暂停,您需要分析失败原因并清理 kube-upgrade 命名空间下失败的 Pod,确认修复成功后重启升级过程。如需帮助,请联系在线客服。 准备工作 说明 如果您在非生产环境中有待升级的集群,我们强烈建议您先对该集群进行升级验证,再在生产环境中启动集群升级。 请在集群升级前检查集群的健康状况,确保集群已具备升级条件。 登录容器服务管理控制台。 单击集群 > 集群进入Kubernetes集群列表。在目标集群右侧操作列,单击更多 > 集群检查。 在容器服务(集群运维)菜单下,单击左侧导航栏中的测评 > 升级检查。 在升级检查页面单击执行升级检查。 在弹出升级检查页面,勾选注意事项后,单击执行检查。 升级集群 检查完成后,单击查看详情。 当检查报告中检查结果为正常时,表示升级检查成功,您可以进行集群升级操作。 如果检查结果异常可以自行修复,也可以通过提交工单,请阿里云工程师协助修复。 操作步骤 登录容器服务管理控制台。 在 Kubernetes 菜单下,单击左侧导航栏中的集群 > 集群,在目标集群右侧操作列单击集群升级,进入 Kubernetes 集群升级页面。 集群列表 单击升级。 升级界面 弹出升级提示页面,单击确定。 此时,您可以可视化的看到升级的全过程。升级过程监控
1934890530796658 2020-03-26 11:48:26 0 浏览量 回答数 0

问题

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

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

回答

数据库课程设计 “数据库课程设计”是数据库系统及应用课程的后续实验课,是进一步巩固学生的数据库知识,加强学生的实际动手能力和提高学生综合素质。 一、 课程设计目的 课程设计为学生提供了一个既动手又动脑,独立实践的机会,将课本上的理论知识和实际有机的结合起来,锻炼学生的分析解决实际问题的能力。提高学生适应实际,实践编程的能力。课程设计的目的: 1. 加深对数据库原理、程序设计语言的理论知识的理解和应用水平; 2. 在理论和实验教学基础上进一步巩固已学基本理论及应用知识并加以综合提高; 3. 学会将知识应用于实际的方法,提高分析和解决问题的能力,增强动手能力; 4. 为毕业设计和以后工作打下必要基础。 二、课程设计要求 运用数据库原理的基本理论与应用知识,在微机RDBMS(SQL Server)的环境上建立一个数据库应用系统。要求把现实世界的事物及事物之间的复杂关系抽象为信息世界的实体及实体之间联系的信息模型,再转换为机器世界的数据模型和数据文件,并对数据文件实施检索、更新和控制等操作。 1. 用E-R图设计选定题目的信息模型; 2. 设计相应的关系模型,确定数据库结构; 3. 分析关系模式各属于第几范式,阐明理由; 4. 设计应用系统的系统结构图,确定系统功能; 5. 通过设计关系的主码约束、外码约束和使用CHECK实现完整性控制; 6. 为参照关系设计插入、删除、修改触发器; 7. 实现应用程序设计、编程、优化功能; 8. 对系统的各个应用程序进行集成和调试,进一步优化系统功能、改善系统用户界面完成实验内容所指定的各项要求; 9. 分析遇到的问题,总结并写出课程设计报告; 10. 自我评价 三、实验环境 开发环境VC++、C#、ASP或JAVA;ODBC/JDBC;数据库SQL Server 四、上机实现内容 1. 创建数据库的结构 2. 创建各基本表的结构 3. 编制系统各功能模块,完成数据的管理(增、删、改)及统计查询。对于程序运行界面不做考核的重点。 五、课程设计考核 1.对学生到实验室的情况进行不定时统计; 2.出勤率+课程设计报告+课程设计所开发的应用系统+其他(上机抽查和提问)=综合评定成绩。 3.课程设计结束时请将下列资料上交: (1) 课程设计报告; (2) 所开发的应用系统的源程序、安装和使用说明; (3) 将(1)(2)中的资料压缩成一个压缩包,压缩包文件的命名规则:班级+学号(末2位)+姓名(例如:计科090101王鹏晓); (4) 班长将本班每人的(3)中的压缩包刻录成光盘连同打印的课程设计报告收齐,交给任课教师。 附录﹑课程设计题目 题目1:课程设计选题管理系统(1,24) 包括三大模块:  课程设计题目维护与查询:题目的添加、修改和删除;按题目类型、名称和关键字查询以及已选与未选题目的查询;  学生信息维护与查询;  学生选题维护与管理:学生选题及查询; 具体功能细化:  前台学生选题:学生上网登录系统进行选题;  前台教师出题:  教师添加、修改和删除题目;  教师确认学生的选题;  后台管理出题和选题  添加用户及权限 题目2:书店管理系统(23) 包括四大模块:  售书(图书销售管理及销售统计,查询)  进书(通过书目,向发行商下定单订购图书)  库存(图书库存,统计)  相关查询 题目3:图书馆管理系统(11) 包括四大模块:  图书的查询  借书  还书  图书的预约 题目4:库存管理系统(8) 包括四大模块:  商品目录建立  商品入库管理  商品出库管理  商品库存查询 题目5:工资管理系统(1 人)41 包括四大模块:  系统数据初始化  员工基本信息数据的输入、修改、删除;  员工个人信息及工资表的查询;  员工工资的计算; 参考数据如下:  员工基本状况:包括员工号、员工姓名、性别、所在部门、工资级别、工资等级等。  工资级别和工资金额:包括工资等级、工资额。  企业部门及工作岗位信息:包括部门名称、工作岗位名称、工作岗位工资等。  工龄和工资金额:包括工龄及对应工资额。  公司福利表:包括福利名称、福利值。  工资信息:包括员工号、员工姓名、员工基础工资、员工岗位工资、员工工龄工资、公司福利、员工实得工资。 题目6:酒店客房管理系统 (1 人)14,26 包括四大模块:  前台操作:包括开房登记、退房结账和房状态查看  预订管理:包括预订房间、预订入住和解除预订  信息查询:包括在住客人列表、预订客人列表和历史客人列表  报表统计:包括开房记录统计、退房结账和预订房间统计  员工基本信息数据的输入、修改、删除; 参考数据如下:  住店管理:客人姓名、证件号码、房号、入住时期、预计离开日期、结账离开日期、应付金额  客人信息:姓名、性别、证件类型、证件号码、联系电话  房间信息:房号、房类型、价格、押金、房状态 预订房间  客人姓名、性别、房类型、房号、价格、证件类型、证件号码、联系电话、入住日期、预计离开日期、历史信息 题目7:旅行社管理信息系统(1 人)3 包括如下模块:  旅游团队、团队团员及旅游路线相关信息的输入  旅游团队、团队团员及旅游路线相关信息的维护(修改、浏览、删除和撤销)  旅游团队管理信息的查询(如按团队编号)  团队团员基本情况的查询(可选多种方式)  旅游路线相关信息的查询(如按线路编号)  旅游路线排行榜发布。  数据备份,更改密码。 参考数据如下:  团员信息表(路线编号,团队编号,团员编号,姓名,性别,电话,通信地址,身份证号码, 团费交否,备注)  线路信息表(路线名称,团费,简介,图形,路线编号)  团队信息表(团队编号,路线编号,团员人数,出发日期,返程日期)  旅游团队信息表(团队编号,团队负责人,团员人数,建团时间,是否出发,团费,盈亏) 密码信息(操作员,密码) 题目8:报刊订阅管理系统 (1 人)25,35 包括如下模块:  登录功能:登录统为身份验证登录。分为管理员登录和一般用户登录。分别通过不 同的用户名和密码进入报刊订阅管理界面,新的用户需要注册。  录入新信息功能:对于管理员,包括新用户信息和新报刊信息的录入功能,信息一旦 提交就存入到后台数据库中;普通用户自行注册进行可以修改个人信息。  订阅功能:用户可以订阅报刊,系统自动计算所需金额,并显示在界面上;管理员不 可订阅报刊,必须以用户身份订阅报刊。  查询功能:用户可以查询并显示自己所订阅的信息;管理员可以按人员、报刊、部门 分类查询。查询出的信息显示在界面上,并且可以预览和打印出结果。  统计功能:管理员可以按用户、部门、报刊统计报刊的销售情况,并对一些重要的订 阅信息进行统计;普通用户可以统计出自己的订阅情况,并且可以预览和打印出结果。  系统维护功能:数据的安全管理,主要是依靠管理员对数据库里的信息进行备份和恢 复,数据库备份后,如果出了什么意外可以恢复数据库到当时备份的状态,这提高了系统和 数据的安全性,有利于系统的维护 参考数据如下:  管理员表(Adminuser) :管理员名、密码。  部门表(Department) :部门号,部门名。  用户表(Users) :用户账号、密码、真实姓名、身 份证号、联系电话,联系地址,部门号(和部门表有关)等。  报刊类别表(NewspaperClass) :分类编号、 分类名称。  报刊信息表(Newspaper) :报刊代号、报刊名称、出版 报社、出版周期、季度报价、内容介绍、分类编号(和报刊类别表有关)等。  订单表(Order) :订单编号、用户编号、报刊代号、订阅份数、订阅月数等。 题目9:计算机等级考试教务管理系统(2 人)32 包括四大模块:  用户设置:对考点代码,考点名称进行设置,设置用户与密码;系统复位:即清除上一次考试数据(在之前存入历史)  报名管理: 报各库录入(姓名不能不空,之间不能有空格) 增加、删除、修改、浏览  准考证管理:准考证生成规则:xxx+yy+zz+kk,其中 XXX 为考点代码;YY 为语言代码,XX 为考场号,KK 为座位号 同一级别、语言应根据报名初始库信息按随机数生成准考证,同一考点最多可有 99*30=2970 名考生;如已生成准考证号,再重新生成准考证号,应该给予提示。 准考证打印  考务管理:考生信息查询、浏览、打印  成绩管理:成绩数据录入、接收 成绩合成(总成绩=笔试成绩*0.6+上机成绩*0.4),按大于或等于 60 合格 参考数据如下:  初始报名表(准考证号(为空) ,报名号(主键) ,级别+语言种类(外键) ,姓名,性别, 出生年份,民族,身份证号,联系地址,联系电话,照片,备注,参加培训)  含准考证号的报名表(准考证号(为主键) ,报名号,级别+语言种类(外键) ,姓名,性别, 出生年份,民族,身份证号,联系地址,联系电话,照片,备注,参加培训)  成绩表(准考证号,笔试成绩,上机成绩,总成绩) 级别语言代码表(级别语言代码,级别+语言)  用户信息表(考点代码,考点名称,用户名,密码) 题目10:人事管理系统(1 人)21 包括四大模块:  登录管理:包括操作员管理,口令设置,权限管理  人员管理:包括人事数据维护、人事信息查询和人事信息统计  工资管理  部门管理:包括部门表,职称表和年份表  查询及报表打印 参考数据如下:  人事表(编号,姓名,性别,出生日期,工作日期,部门代码,职称,婚否,简历,相片)  工资表(基本工资,岗位津贴,奖励,应发工资,水电,保险,实发工资)  部门表(代码,部门名称)  职称表(职称代码,职称名称)  年份表(年份代码,年份名称)  操作员表(操作员代码,操作员姓名,口令,部门,电话) 系统日志表(操作员代号,操作员姓名,登录时间,离开时间) 题目11:商品销售管理系统(1 人)19 包括四大模块:  用户登录  基本信息管理:包括销售情况、商品信息、库存表、员工表等信息的录入、浏览、修改、撤销、删除和查询等  商品销售管理:包括商品售出、退回和入库  盘点:包括库存盘点、当日销售盘点 参考数据如下:  商品信息表(商品编号,商品名称,品牌,型号,销售单价) 商品编号=类别代码(1 位)+品名代码(1 位)+品牌代码(2 位)+型号代码(2 位)  销售情况表(成交编号,商品编号,销售数量,总金额,销售日期,员工编号)  库存表(商品编号,供货商编号,进货日期,进货价,库存数量)  员工表(员工编号,员工姓名,性别,基本工资,职务,密码)  供货商表(供货商编号,供货商名称,所在地,联系电话)  员工资料表(员工编号,员工姓名,是否党员,简历,照片) 题目12:学生成绩管理系统(1 人)29 包括四大模块:  基本数据管理:包括院系管理,专业管理(设置院系下面的专业),班级管理(设置专业下面的班级),课程管理(设置相应专业下面的课程)  学生信息管理:包括基本信息录入、基本信息修改  学生成绩管理:包括学生成绩录入、学生成绩修改  信息查询:包括基本信息查询、成绩信息查询、学校人数统计  系统管理:用户管理、数据备份和系统帮助 参考数据如下:  院系信息(院系代码,院系名称)  院系专业信息(班级、院系代码,专业)  学生基本信息(班号,学号,姓名,性别,出生年月,籍贯,政治面貌,身份证号,入学年月,家庭地址,邮政编码,图片信息,备注)  学生成绩表(学号,课号,成绩,备注)  课程表(课号,课程名称,学期,备注)  班表(班号,班级名称)  用户信息表(用户名,密码,用户标识) 题目13:火车售票管理系统(4 人)36 包括四大模块:  售票管理  订票管理  信息查询  系统维护 参考数据如下:  车次信息表(车次,始发站,终点站,发车时间,到达时间)  订票信息表(车次,座位号,发车时期,发车时间,座位等级,票价)  车次座位等级分配及座位占用表(车次,座位号,座位等级,票价,占用标志)  用户信息表(用户名,密码,用户标识) 题目14:小型物业管理系统(1 人) 包括四大模块:  房源管理:对原始资料的录入、修改、查询和刷新。一般用户可以查询与房间有关 的统计资料;物业主管可其进行增、删、改、插等操作  租房管理:对房产出租,退租以及租房面积调整。其中物业主管可对其进行房租金 额计算和收款操作,一般用户对其查询  水电处理:根据租房资料,结合当月水、电量进行分摊,完成应收水电费。其中物 业主管对其进行计算,其他查询  交款处理:提供收款和发票打印以及交款数据查询  查询处理:对租房资料、交款资料,发票资料进行查询 参考数据如下:  房源资料(名称,面积,月租,物业,仓库)  租房资料(名称,面积,单位,月租,物业,押金,仓库)  水电资料(单位,电量,水量,电费,水费)  交费资料(收费项目,应收日期,应收金额,已收金额,未收金额,本次收款)  发票资料(单位,房租,电费,水费,物业)  权限资料(用户,密码,房源管理,租房管理,水电管理,交费管理,发票管理,系统维护) 其中系统管理员,有权进行系统维护;单位内部物业主管,有权进行物业资源调配、单元出 租,退租和收款开票操作;物业管理员,有权进行水电处理和收款处理等操行;租户代表, 有权进行种类费的查询操作 题目15:机房收费管理系统(1 人)7,34 包括四大模块:  登录模块  上机管理模块 说明:上机登记时,余额不足 3 元或卡处于挂失状态,则拒绝登记 每位同学的一次上机形成一条记录,每 36S 遍历一次上机记录表,对表中所有正上机字段为 TRUE 的记录的上机用时增加 36S,同时从上机卡表的余额减少  上机卡管理模块  充值挂失模块  查找统计模块:统计某天上机的总时数、每次上机的平均时数和机房的收入;某学 生上机的次数、上机总时数、每次上机平均时间;挂失和查询余 参考数据如下:  上机卡(卡号,姓名,专业班级,余额,状态) 状态的取值有:正常(能自费上机)  挂失上机记录(卡号,上机日期,开始时间,上机用时,正上机,管理号代码),上机用时记录学生上机时间(S);正上机是一个布尔型,为 True 表示正上机,每 36 秒刷新 其上机用时并扣除上机费用,为 False 表示上机结束。上机记录表永久保存,用于事后查询 和统计 管理员(代码,姓名,口令)  题目16:高校药房管理(1 人)31 包括四大模块:  基础数据处理:包括医生和药剂师名单的录入,修改,删除及查询  营业数据处理:包括药品进货上柜,处理划价,配药,柜存药品查询,处方综合查 询,交接班结转清。 参考数据如下:  药品信息表(货号,货名,计量单位,进货数量,进货单价,出售单价,进货日期,收货人 和供应商)  处方信息(编号,患者姓名,医生姓名,药剂师姓名,处方日期,配药日期) 处方药品信息(处方编号,药品货号,计量单位,配药数量,销售单价,已配药否)  医生名单和药剂师名单表(姓名)  题目17:考勤管理系统(2 人)40 包括四大模块:  记录每个员工每天所有进入公司的时刻和离开公司的时刻。  每天结束时自动统计当天的工作时间  每天结束时自动统计当天迟到或早退的次数。  对于弹性工作制,每天结束时自动统计当月的工时,并自动算出当月欠缺或富余的 时间  每个月末统计该月的工作时间判断是束足够  每个月末统计该月的工作天数并判断是否足够  管理人员查询并修改工作时间(特殊情况下修改)  管理人员账户管理(如设置密码等)  管理人员设定早退及迟到的条件,每个月的工作时间  管理人员设定每个月的工作日期及放假日期 参考数据如下:  员工信息(工号,姓名,年龄,入职时间,职位,性别,密码)  配置信息(上班时间小时,上班时间分钟,下班时间小时,下班时间分钟,每天工作时间)  每月统计数据表(工号,姓名,剩余的时间,迟到的次数,早退的次数,工作天数)  每天统计信息表(工号,姓名,小时,分钟,动作,时间) 其中动作指的时入或离开公司  题目18:单位房产管理系统(2 人)33,10 包括四大模块:  系统模块:完成数据库维护、系统关闭功能  物业费用模块:完成本月物业的计费、历史资料查询和财务部门接口传送数据、物 业相关费用单价设置  房屋资源模块:对房屋资源进行添加、列表显示、查询  职工信息模块:对职工进行添加、列表显示、查询以及相应部门、职务进行维护  帮助模块:对用户使用本系统提供在线帮助 参考数据如下:  职工(编号,姓名,性别,参加工作时间,行政职务,专业技术职务,评上最高行政职务时 间,评上最高专业技术职务时间,双职工姓名,现居住房号,档案号,房产证号,所在部门 编号,是否为户主)  部门(编号,部门名称) 住房级别表(编号,级别,住房标准,控制标准,级别分类)  房产情况(编号,房号,使用面积,现居住人 id,上一个居住人 id,最早居住人 ID,阳台面积)  物业费用(编号,房号,水基数,水现在值,电基数,电现在值,燃气基数,燃气现在值, 当前年份,当前月份)  价格标准(编号,水单价,电单价,燃气单价) 题目19:标准化考试系统 (2 人)15,39 功能要求: 设计一个简单的标准化考试系统,仅有单项选择题、多项选择题和判断题功能即可。 包括四大模块:  题库管理:实现试题的录入、修改、删除功能;  考试子系统:能够实现考生做题、结果自动存入到数据库中,有时间提示;  选择身份(登录)功能:系统能够记录考生输入的登录信息及交卷信息;  自动评分功能:考生交卷后能自动评分;  查看成绩功能:能够查询考生相关信息(包含成绩等)。 参考数据如下: 其它可供选择的题目: 网上教务评教系统130,127,133 16 学生日常行为评分管理系统232,110,230 网上鲜花店 38 基于BS结构的工艺品销售系统12 基于BS结构的校园二手物品交易网站 37 大学生就业管理系统201,208,234 题库及试卷管理系统 数据库原理及应用 课程设计报告 题目: 课程设计选题管理系统 所在学院: 班 级: 学 号: 姓 名: 李四 指导教师: 2011年12月 日 目录 一、 概述 二、需求分析 三、概念设计 四、逻辑设计 五、系统实现 六、小结 一、概述
玄学酱 2019-12-02 01:22:25 0 浏览量 回答数 0

回答

本文主要介绍虚拟节点和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

回答

以太坊的核心元素是以太坊虚拟机(Ethereum Virtual Machine,EVM),它是智能合约的执行环境。EVM分散储存在以太坊网络的每个节点上,智能合约代码被对外隔离,并分布在每个节点上执行,因此以太坊EVM又被称为世界电脑。合同代码不是用图灵完备的高级程序语言编写的,而是由简单的、基于堆栈的低级程序语言编写的,看起来就像JVM的字节码(Java虚拟机)。每个以太坊节点都运行EVM,这意味着对于以太坊网络的参与者,每个节点都参与验证新块是否有效以及计算是否已正确,都是运行EVM代码的独立实例。由于每个节点都参与计算,虽然不一定是最高效的模型,但它具有很高的加密安全性。 从技术上讲,EVM以状态转换作为函数的运作模式,其工作原理是将一串参数输入EVM,以获取整个以太坊网络的新区块状态和gas数量,具体过程为输入(block_state,gas,memory,transaction,message,code,stack,pc)→EVM→输出(block_state,gas)。其中block_state是以太坊网络的全局状态,包括所有账户、账户余额和长期存储;gas是运行这些计算所需的费用,由计算的类型和工作量决定;memory是执行内存;transaction代表交易;message是有关交易的元数据;code就是代码本身;stack和pc是与执行相关的堆栈和程序计数器。这一串参数被输入到EVM以生成整个以太坊网络的新block_state和账户拥有的新gas数量。 以太坊EVM的设计目标有5个:简单、高效、确定性、专用化和安全性。EVM设计简单,可以轻松证明智能合约的安全性,这也有助于保护平台本身。EVM组件尽可能紧凑,以提高空间效率。EVM具有确定性,即相同的输入状态应始终产生相同的输出状态。确定性的虚拟机必然会限制应用范围,例如以太坊的HTTP请求不可用。EVM具有专用的内置函数,例如可以轻松处理20字节地址加密的加密函数、用于自定义加密的模块化指数算法、读取区块数据、读取交易数据的函数,以及与block_state交互的函数。以太坊EVM的安全性在于每次计算都要预先消耗gas,这增加了DoS攻击的成本,使得攻击者无法发动大规模的无效合约。EVM的主要编程语言是Solidity,智能合约用Solidity写好后,通过Solidity Compiler(solc)编译并生成EVM代码。合约语言的复杂性通过Solidity Compiler进行管理,但在架构层面,Solidity仍然是一种简单的基于堆栈的语言。 智能合约是在以太坊EVM上自动执行的合约代码,一般包括合约所有人、合约对象、合约条款、合约算法、合约触发条件等内容。对于可信电子证照应用,数据共享规则被转换为智能合约并部署在区块链上之后,常规共享条款和违约处理条款就可以自动履行,且执行过程由区块链完整记录,其执行状态可被随时查看和审计,从而提供一个公平、公正、公开的合约执行环境。此外,通过智能合约还可对参与方身份进行权限检查,针对交易者身份进行访问控制。 用智能合约完成可信电子证照应用的注册、发证、查验等过程,具体包括5个主要功能模块和5个API。5个主要功能模块为公民用户App、发证机构前端、区块链平台、政府业务库和后台身份管理数据库;5个API包括注册区块链用户、发送制证信息、查验电子证照信息、查询用户公钥和查询电子证明信息,具体分析如下所示。 1. 注册区块链用户 用于新用户注册区块链信息管理账户。对于业务系统注册账号来说分为3个不同的角色:普通用户、制证机关用户、查验机构用户。 输入:账户名称(用于登录系统的ID)。 输出:账户地址(注册用户在区块链上的地址,用于用户之间传输信息)和账户公私钥(普通用户的公私钥用于用户证件信息的加解密,制证机关用户的公私钥用于对发证机构的数字签名进行验证,查验机构用户的公私钥用于对查验信息的加解密)。 2. 发送制证信息 用于制证机构用户存储新增证件信息以及发送给办证用户。以制证机构用户在区块链上给办证用户发送一笔交易为载体,把新增的证件信息保存在区块链上,并发送给办证用户。 输入:申请制证用户的区块链地址(发证机构制证后给该地址用户发送制证信息)、发证机构组织机构代码(发证机构的唯一标示)、申请制证用户的证件信息(需要用户公钥加密)。 输出:该笔交易的Hash值(交易信息地址唯一标识)、记录证件信息的区块编号(交易信息地址唯一标识)。
问问小秘 2019-12-02 03:10:04 0 浏览量 回答数 0

问题

该来的终于来了:“第一起”基于 IPv6 的 DDoS 攻击

作者介绍 杨彪,蚂蚁金服技术专家,《分布式服务架构:原理、设计与实战》和《可伸缩服务架构:框架与中间件》作者。近10年互联网和游戏行业工作经验,曾在酷我音乐盒、人人游戏...
驻云科技 2019-12-01 21:44:35 4186 浏览量 回答数 1

问题

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

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

回答

密码学简介 据记载,公元前400年,古希腊人发明了置换密码。1881年世界上的第一个电话保密专利出现。在第二次世界大战期间,德国军方启用“恩尼格玛”密码机,密码学在战争中起着非常重要的作用。 随着信息化和数字化社会的发展,人们对信息安全和保密的重要性认识不断提高,于是在1997年,美国国家标准局公布实施 了“美国数据加密标准(DES)”,民间力量开始全面介入密码学的研究和应用中,采用的加密算法有DES、RSA、SHA等。随着对加密强度需求的不断提 高,近期又出现了AES、ECC等。 使用密码学可以达到以下目的: 保密性:防止用户的标识或数据被读取。 数据完整性:防止数据被更改。 身份验证:确保数据发自特定的一方。 二. 加密算法介绍 根据密钥类型不同将现代密码技术分为两类:对称加密算法(秘密钥匙加密)和非对称加密算法(公开密钥加密)。 对称钥匙加密系统是加密和解密均采用同一把秘密钥匙,而且通信双方都必须获得这把钥匙,并保持钥匙的秘密。 非对称密钥加密系统采用的加密钥匙(公钥)和解密钥匙(私钥)是不同的。 对称加密算法 对称加密算法用来对敏感数据等信息进行加密,常用的算法包括: DES(Data Encryption Standard):数据加密标准,速度较快,适用于加密大量数据的场合。 3DES(Triple DES):是基于DES,对一块数据用三个不同的密钥进行三次加密,强度更高。 AES(Advanced Encryption Standard):高级加密标准,是下一代的加密算法标准,速度快,安全级别高; AES 2000年10月,NIST(美国国家标准和技术协会)宣布通过从15种侯选算法中选出的一项新的密匙加密标准。 Rijndael被选中成为将来的AES。 Rijndael是在 1999 年下半年,由研究员 Joan Daemen 和 Vincent Rijmen 创建的。AES 正日益成为加密各种形式的电子数据的实际标准。 美国标准与技术研究院 (NIST) 于 2002 年 5 月 26 日制定了新的高级加密标准 (AES) 规范。 算法原理 AES 算法基于排列和置换运算。排列是对数据重新进行安排,置换是将一个数据单元替换为另一个。AES 使用几种不同的方法来执行排列和置换运算。 AES 是一个迭代的、对称密钥分组的密码,它可以使用128、192 和 256 位密钥,并且用 128 位(16 字节)分组加密和解密数据。与公共密钥密码使用密钥对不同,对称密钥密码使用相同的密钥加密和解密数据。通过分组密码返回的加密数据的位数与输入数据相 同。迭代加密使用一个循环结构,在该循环中重复置换和替换输入数据 AES与3DES的比较 算法名称 算法类型 密钥长度 速度 解密时间(建设机器每秒尝试255个密钥) 资源消耗 AES 对称block密码 128、192、256位 高 1490000亿年 低 3DES 对称feistel密码 112位或168位 低 46亿年 中 非对称算法 常见的非对称加密算法如下: RSA:由 RSA 公司发明,是一个支持变长密钥的公共密钥算法,需要加密的文件块的长度也是可变的; DSA(Digital Signature Algorithm):数字签名算法,是一种标准的 DSS(数字签名标准); ECC(Elliptic Curves Cryptography):椭圆曲线密码编码学。 ECC 在1976年,由于对称加密算法已经不能满足需要,Diffie 和Hellman发表了一篇叫《密码学新动向》的文章,介绍了公匙加密的概念,由Rivet、Shamir、Adelman提出了RSA算法。 随着分解大整数方法的进步及完善、计算机速度的提高以及计算机网络的发展,为了保障数据的安全,RSA的密钥需要不断增 加,但是,密钥长度的增加导致了其加解密的速度大为降低,硬件实现也变得越来越难以忍受,这对使用RSA的应用带来了很重的负担,因此需要一种新的算法来 代替RSA。 1985年N.Koblitz和Miller提出将椭圆曲线用于密码算法,根据是有限域上的椭圆曲线上的点群中的离散对数问题ECDLP。ECDLP是比因子分解问题更难的问题,它是指数级的难度。 算法原理——椭圆曲线上的难题 椭圆曲线上离散对数问题ECDLP定义如下:给定素数p和椭圆曲线E,对Q=kP,在已知P,Q 的情况下求出小于p的正整数k。可以证明由k和P计算Q比较容易,而由Q和P计算k则比较困难。 将椭圆曲线中的加法运算与离散对数中的模乘运算相对应,将椭圆曲线中的乘法运算与离散对数中的模幂运算相对应,我们就可以建立基于椭圆曲线的对应的密码体制。 例如,对应Diffie-Hellman公钥系统,我们可以通过如下方式在椭圆曲线上予以实现:在E上选取生成元P,要 求由P产生的群元素足够多,通信双方A和B分别选取a和b,a和b 予以保密,但将aP和bP公开,A和B间通信用的密钥为abP,这是第三者无法得知 的。 对应ELGamal密码系统可以采用如下的方式在椭圆曲线上予以实现: 将明文m嵌入到E上Pm点,选一点B∈E,每一用户都选一整数a,0<a<N,N为阶数已知,a保密,aB公开。欲向A 送m,可送去下面一对数偶:[kB,Pm+k(aAB)],k是随机产生的整数。A可以从kB求得k(aAB)。通过:Pm+k(aAB)- k(aAB)=Pm恢复Pm。同样对应DSA,考虑如下等式: K=kG [其中 K,G为Ep(a,b)上的点,k为小于n(n是点G的阶)的整数] 不难发现,给定k和G,根据加法法则,计算K很容易;但给定K和G,求k就相对困难了。 这就是椭圆曲线加密算法采用的难题。我们把点G称为基点(base point),k(k<n,n为基点G的阶)称为私有密钥(privte key),K称为公开密钥(public key)。 ECC与RSA的比较 ECC和RSA相比,在许多方面都有对绝对的优势,主要体现在以下方面: Ø 抗攻击性强。相同的密钥长度,其抗攻击性要强很多倍。 Ø 计算量小,处理速度快。ECC总的速度比RSA、DSA要快得多。 Ø 存储空间占用小。ECC的密钥尺寸和系统参数与RSA、DSA相比要小得多,意味着它所占的存贮空间要小得多。这对于加密算法在IC卡上的应用具有特别重要的意义。 Ø 带宽要求低。当对长消息进行加解密时,三类密码系统有相同的带宽要求,但应用于短消息时ECC带宽要求却低得多。带宽要求低使ECC在无线网络领域具有广泛的应用前景。 ECC的这些特点使它必将取代RSA,成为通用的公钥加密算法。比如SET协议的制定者已把它作为下一代SET协议中缺省的公钥密码算法。 下面两张表示是RSA和ECC的安全性和速度的比较: 攻破时间 (MIPS年) RSA/DSA (密钥长度) ECC 密钥长度 RSA/ECC 密钥长度比 104 512 106 5:1 108 768 132 6:1 1011 1024 160 7:1 1020 2048 210 10:1 1078 21000 600 35:1 RSA和ECC安全模长得比较 功能 Security Builder 1.2 BSAFE 3.0 163位ECC(ms) 1,023位RSA(ms) 密钥对生成 3.8 4,708.3 签名 2.1(ECNRA) 228.4 3.0(ECDSA) 认证 9.9(ECNRA) 12.7 10.7(ECDSA) Diffie—Hellman密钥交换 7.3 1,654.0 RSA和ECC速度比较 散列算法 散列是信息的提炼,通常其长度要比信息小得多,且为一个固定长度。加密性强的散列一定是不可逆的,这就意味着通过散列结 果,无法推出任何部分的原始信息。任何输入信息的变化,哪怕仅一位,都将导致散列结果的明显变化,这称之为雪崩效应。散列还应该是防冲突的,即找不出具有 相同散列结果的两条信息。具有这些特性的散列结果就可以用于验证信息是否被修改。 单向散列函数一般用于产生消息摘要,密钥加密等,常见的有: Ø MD5(Message Digest Algorithm 5):是RSA数据安全公司开发的一种单向散列算法。 Ø SHA(Secure Hash Algorithm):可以对任意长度的数据运算生成一个160位的数值; SHA-1 在1993年,安全散列算法(SHA)由美国国家标准和技术协会(NIST)提出,并作为联邦信息处理标准(FIPS PUB 180)公布;1995年又发布了一个修订版FIPS PUB 180-1,通常称之为SHA-1。SHA-1是基于MD4算法的,并且它的设计在很大程度上是模仿MD4的。现在已成为公认的最安全的散列算法之一,并 被广泛使用。 算法原理 SHA-1是一种数据加密算法,该算法的思想是接收一段明文,然后以一种不可逆的方式将它转换成一段(通常更小)密文,也可以简单的理解为取一串输入码(称为预映射或信息),并把它们转化为长度较短、位数固定的输出序列即散列值(也称为信息摘要或信息认证代码)的过程。 单向散列函数的安全性在于其产生散列值的操作过程具有较强的单向性。如果在输入序列中嵌入密码,那么任何人在不知道密码 的情况下都不能产生正确的散列值,从而保证了其安全性。SHA将输入流按照每块512位(64个字节)进行分块,并产生20个字节的被称为信息认证代码或 信息摘要的输出。 该算法输入报文的最大长度不超过264位,产生的输出是一个160位的报文摘要。输入是按512 位的分组进行处理的。SHA-1是不可逆的、防冲突,并具有良好的雪崩效应。 通过散列算法可实现数字签名实现,数字签名的原理是将要传送的明文通过一种函数运算(Hash)转换成报文摘要(不同的 明文对应不同的报文摘要),报文摘要加密后与明文一起传送给接受方,接受方将接受的明文产生新的报文摘要与发送方的发来报文摘要解密比较,比较结果一致表 示明文未被改动,如果不一致表示明文已被篡改。 MAC (信息认证代码)就是一个散列结果,其中部分输入信息是密码,只有知道这个密码的参与者才能再次计算和验证MAC码的合法性。MAC的产生参见下图。 输入信息 密码 散列函数 信息认证代码 SHA-1与MD5的比较 因为二者均由MD4导出,SHA-1和MD5彼此很相似。相应的,他们的强度和其他特性也是相似,但还有以下几点不同: Ø 对强行供给的安全性:最显著和最重要的区别是SHA-1摘要比MD5摘要长32 位。使用强行技术,产生任何一个报文使其摘要等于给定报摘要的难度对MD5是2128数量级的操作,而对SHA-1则是2160数量级的操作。这样,SHA-1对强行攻击有更大的强度。 Ø 对密码分析的安全性:由于MD5的设计,易受密码分析的攻击,SHA-1显得不易受这样的攻击。 Ø 速度:在相同的硬件上,SHA-1的运行速度比MD5慢。 对称与非对称算法比较 以上综述了两种加密方法的原理,总体来说主要有下面几个方面的不同: Ø 在管理方面:公钥密码算法只需要较少的资源就可以实现目的,在密钥的分配上,两者之间相差一个指数级别(一个是n一个是n2)。所以私钥密码算法不适应广域网的使用,而且更重要的一点是它不支持数字签名。 Ø 在安全方面:由于公钥密码算法基于未解决的数学难题,在破解上几乎不可能。对于私钥密码算法,到了AES虽说从理论来说是不可能破解的,但从计算机的发展角度来看。公钥更具有优越性。 Ø 从速度上来看:AES的软件实现速度已经达到了每秒数兆或数十兆比特。是公钥的100倍,如果用硬件来实现的话这个比值将扩大到1000倍。 三. 加密算法的选择 前面的章节已经介绍了对称解密算法和非对称加密算法,有很多人疑惑:那我们在实际使用的过程中究竟该使用哪一种比较好呢。 我们应该根据自己的使用特点来确定,由于非对称加密算法的运行速度比对称加密算法的速度慢很多,当我们需要加密大量的数据时,建议采用对称加密算法,提高加解密速度。 对称加密算法不能实现签名,因此签名只能非对称算法。 由于对称加密算法的密钥管理是一个复杂的过程,密钥的管理直接决定着他的安全性,因此当数据量很小时,我们可以考虑采用非对称加密算法。 在实际的操作过程中,我们通常采用的方式是:采用非对称加密算法管理对称算法的密钥,然后用对称加密算法加密数据,这样我们就集成了两类加密算法的优点,既实现了加密速度快的优点,又实现了安全方便管理密钥的优点。 如果在选定了加密算法后,那采用多少位的密钥呢。一般来说,密钥越长,运行的速度就越慢,应该根据的我们实际需要的安全级别来选择,一般来说,RSA建议采用1024位的数字,ECC建议采用160位,AES采用128为即可。 四. 密码学在现代的应用 随着密码学商业应用的普及,公钥密码学受到前所未有的重视。除传统的密码应用系统外,PKI系统以公钥密码技术为主,提供加密、签名、认证、密钥管理、分配等功能。 保密通信:保密通信是密码学产生的动因。使用公私钥密码体制进行保密通信时,信息接收者只有知道对应的密钥才可以解密该信息。 数字签名:数字签名技术可以代替传统的手写签名,而且从安全的角度考虑,数字签名具有很好的防伪造功能。在政府机关、军事领域、商业领域有广泛的应用环境。 秘密共享:秘密共享技术是指将一个秘密信息利用密码技术分拆成n个称为共享因子的信息,分发给n个成员,只有 k(k≤n)个合法成员的共享因子才可以恢复该秘密信息,其中任何一个或m(m≤k)个成员合作都不知道该秘密信息。利用秘密共享技术可以控制任何需要多 个人共同控制的秘密信息、命令等。 认证功能:在公开的信道上进行敏感信息的传输,采用签名技术实现对消息的真实性、完整性进行验证,通过验证公钥证书实现对通信主体的身份验证。 密钥管理:密钥是保密系统中更为脆弱而重要的环节,公钥密码体制是解决密钥管理工作的有力工具;利用公钥密码体制进行密钥协商和产生,保密通信双方不需要事先共享秘密信息;利用公钥密码体制进行密钥分发、保护、密钥托管、密钥恢复等。 基于公钥密码体制可以实现以上通用功能以外,还可以设计实现以下的系统:安全电子商务系统、电子现金系统、电子选举系统、电子招投标系统、电子彩票系统等。 公钥密码体制的产生是密码学由传统的政府、军事等应用领域走向商用、民用的基础,同时互联网、电子商务的发展为密码学的发展开辟了更为广阔的前景。 五. 加密算法的未来 随着计算方法的改进,计算机运行速度的加快,网络的发展,越来越多的算法被破解。 在2004年国际密码学会议(Crypto’2004)上,来自中国山东大学的王小云教授做的破译MD5、HAVAL-128、MD4和RIPEMD算法的报告,令在场的国际顶尖密码学专家都为之震惊,意味着这些算法将从应用中淘汰。随后,SHA-1也被宣告被破解。 历史上有三次对DES有影响的攻击实验。1997年,利用当时各国 7万台计算机,历时96天破解了DES的密钥。1998年,电子边境基金会 (EFF)用25万美元制造的专用计算机,用56小时破解了DES的密钥。1999年,EFF用22小时15分完成了破解工作。因此。曾经有过卓越贡献的 DES也不能满足我们日益增长的需求了。 最近,一组研究人员成功的把一个512位的整数分解因子,宣告了RSA的破解。 我们说数据的安全是相对的,可以说在一定时期一定条件下是安全的,随着硬件和网络的发展,或者是另一个王小云的出现,目前的常用加密算法都有可能在 短时间内被破解,那时我们不得不使用更长的密钥或更加先进的算法,才能保证数据的安全,因此加密算法依然需要不断发展和完善,提供更高的加密安全强度和运 算速度。 纵观这两种算法一个从DES到3DES再到AES,一个从RSA到ECC。其发展角度无不是从密钥的简单性,成本的低廉性,管理的简易性,算法的复 杂性,保密的安全性以及计算的快速性这几个方面去考虑。因此,未来算法的发展也必定是从这几个角度出发的,而且在实际操作中往往把这两种算法结合起来,也 需将来一种集两种算法优点于一身的新型算法将会出现,到那个时候,电子商务的实现必将更加的快捷和安全。
liujae 2019-12-02 01:26:38 0 浏览量 回答数 0

问题

如何保证消息队列的高可用?【Java问答学堂】20期

面试官心理分析 如果有人问到你 MQ 的知识,高可用是必问的。上一讲提到,MQ 会导致系统可用性降低。所以只要你用了 MQ,接下来问的一些要点肯定就是围绕着 MQ 的那些缺点怎么来解决了。 要是...
剑曼红尘 2020-05-18 11:21:10 2 浏览量 回答数 1

回答

微服务 (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

回答

要了解CDN 的实现原理,首先让我们来回顾一下网站传统的访问过程,以便理解其与CDN 访问方式之间的差别: 由上图可见,传统的网站访问过程为: 1. 用户在浏览器中输入要访问的域名; 2. 浏览器向域名解析服务器发出解析请求,获得此域名对应的IP 地址; 3. 浏览器利用所得到的IP 地址,向该IP 对应的服务器发出访问请求; 4. 服务器对此响应,将数据回传至用户浏览器端显示出来。 与传统访问方式不同,CDN 网络则是在用户和服务器之间增加 Cache 层,将用户的访问请求引导到Cache 节点而不是服务器源站点,要实现这一目的,主要是通过接管DNS 实现,下图为使用CDN 缓存后的网站访问过程: 由上图可见,使用CDN 缓存后的网站访问过程演变为: 1. 用户在浏览器中输入要访问的域名; 2. 浏览器向域名解析服务器发出解析请求,由于CDN 对域名解析过程进行了调整,所以用户端一般得到的是该域名对应的 CNAME 记录,此时浏览器需要再次对获得的 CNAME 域名进行解析才能得到缓存服务器实际的IP 地址。 注:在此过程中,全局负载均衡DNS 解析服务器会根据用户端的源IP 地址,如地理位置(深圳还是上海)、接入网类型(电信还是网通)将用户的访问请求定位到离用户路由最短、位置最近、负载最轻的Cache 节点(缓存服务器)上,实现就近定位。定位优先原则可按位置、可按路由、也可按负载等。 3. 再次解析后浏览器得到该域名CDN 缓存服务器的实际IP 地址,向缓存服务器发出访问请求; 4. 缓存服务器根据浏览器提供的域名,通过Cache 内部专用DNS 解析得到此域名源服务器的真实IP 地址,再由缓存服务器向此真实IP 地址提交访问请求; 5. 缓存服务器从真实 IP 地址得到内容后,一方面在本地进行保存,以备以后使用,同时把得到的数据发送到客户端浏览器,完成访问的响应过程; 6. 用户端得到由缓存服务器传回的数据后显示出来,至此完成整个域名访问过程。 通过以上分析可以看到,不论是否使用CDN 网络,普通用户客户端设置不需做任何改变,直接使用被加速网站原有域名访问即可。对于要加速的网站,只需修改整个访问过程中的域名解析部分,便能实现透明的网络加速服务。 CDN 应用与架构 CDN 速度快、传输安全、扩展性强,尤其在应对大容量迸发时游刃有余,主要应用于跨地域的门户及行业网站,如游戏、娱乐、IT、新闻传媒、VOD、远程教育、音视频、下载、IPTV、金融证券等。 利用CDN 网络,网站用户无需投资价值不菲的服务器、网络带宽及相应的人力成本,便能实现将网站内容发布到离终端用户距离最近、路由最短的网际边缘Cache 节点,创造完美、快捷的网站使用体验。 构建 CDN 网络的通常有三类机构,一是基础电信运营商(如中国电信、中国网通等),二是纯粹以 CDN 为主营业务的专业服务商(如 ChinaCache 等),三是 IDC 运营服务商(如 SouIDC 等)。虽然上述机构建设CDN 网络的出发点、侧重点不尽相同,但有一点却是相通的,即都是为用户提供完美的网站加速服务。 IDC 运营商部署在各地的 IDC 中心机房,非常有利于其快速建立起适合自身业务拓展的 CDN 网络,投资少见效快。其最大优势在于可以利用现有的 IDC 托管用户资源,进一步挖掘其潜在的增值服务空间。同时对于其 IDC 托管用户来讲,只需很少的投入便可实现网站的平滑加速,并保持了服务及支持上的无缝延续。 SynCDN 便是SouIDC 构建的CDN 网站加速运营平台。 一般来讲,CDN 网络主要由中心节点、边缘节点两部分构成。 CDN 架构导引 最简单的 CDN 网络只需一台负责全局负载均衡的 DNS 和各节点一台 Cache,即可运行。 DNS 支持根据用户源 IP 地址解析不同的 IP,实现就近访问。为了保证高可用性等,CDN 网管中心需要监控各节点的流量、健康状况等。一个节点的单台Cache 承载数量不够时,才需要多台 Cache,多台Cache 同时工作时,才需要负载均衡器,使Cache 群协同工作。 CDN 中心节点 中心节点包括CDN 网管中心和全局负载均衡DNS 重定向解析系统,负责整个CDN 网络的分发及管理。 CDN 网管中心是整个CDN 能够正常运转的基础保证,它不仅能对整个CDN 网络中的各个子系统和设备进行实时监控,对各种故障产生相应的告警,还可以实时监测到系统中总的流量和各节点的流量,并保存在系统数据库中,使网管人员能够方便地进行进一步分析。一套完善的网管系统,允许用户按需对系统配置进行修改。 全局负载均衡DNS 通过一组预先定义好的策略,将当时最接近用户的Cache 节点地址提供给用户,使用户能够得到快速的服务。同时,它还与分布在各地的所有CDN 节点保持持续通信,搜集各节点的通信状态,确保不会将用户的请求分发到不可用、或不健康的 Cache 节点上。 CDN 边缘节点 CDN 边缘节点主要指异地分发节点,由负载均衡设备、高速缓存服务器两部分组成。 负载均衡设备负责每个节点中各个Cache 的负载均衡,保证节点的工作效率;同时还负责收集节点与周围环境的信息,保持与全局负载均衡DNS 的通信,实现整个系统的负载均衡。 高速缓存服务器(Cache)负责存储客户网站的大量信息,就像一个靠近用户的网站服务器一样响应本地用户的访问请求。通过全局负载均衡DNS 的控制,用户的请求被透明地指向离他最近的节点,节点中Cache 服务器就像网站的原始服务器一样,响应终端用户的请求。因其距离用户更近,故其响应时间才更快。 答案来源于网络
养狐狸的猫 2019-12-02 03:03:30 0 浏览量 回答数 0

回答

要了解CDN 的实现原理,首先让我们来回顾一下网站传统的访问过程,以便理解其与CDN 访问方式之间的差别: 由上图可见,传统的网站访问过程为: 1. 用户在浏览器中输入要访问的域名; 2. 浏览器向域名解析服务器发出解析请求,获得此域名对应的IP 地址; 3. 浏览器利用所得到的IP 地址,向该IP 对应的服务器发出访问请求; 4. 服务器对此响应,将数据回传至用户浏览器端显示出来。 与传统访问方式不同,CDN 网络则是在用户和服务器之间增加 Cache 层,将用户的访问请求引导到Cache 节点而不是服务器源站点,要实现这一目的,主要是通过接管DNS 实现,下图为使用CDN 缓存后的网站访问过程: 由上图可见,使用CDN 缓存后的网站访问过程演变为: 1. 用户在浏览器中输入要访问的域名; 2. 浏览器向域名解析服务器发出解析请求,由于CDN 对域名解析过程进行了调整,所以用户端一般得到的是该域名对应的 CNAME 记录,此时浏览器需要再次对获得的 CNAME 域名进行解析才能得到缓存服务器实际的IP 地址。 注:在此过程中,全局负载均衡DNS 解析服务器会根据用户端的源IP 地址,如地理位置(深圳还是上海)、接入网类型(电信还是网通)将用户的访问请求定位到离用户路由最短、位置最近、负载最轻的Cache 节点(缓存服务器)上,实现就近定位。定位优先原则可按位置、可按路由、也可按负载等。 3. 再次解析后浏览器得到该域名CDN 缓存服务器的实际IP 地址,向缓存服务器发出访问请求; 4. 缓存服务器根据浏览器提供的域名,通过Cache 内部专用DNS 解析得到此域名源服务器的真实IP 地址,再由缓存服务器向此真实IP 地址提交访问请求; 5. 缓存服务器从真实 IP 地址得到内容后,一方面在本地进行保存,以备以后使用,同时把得到的数据发送到客户端浏览器,完成访问的响应过程; 6. 用户端得到由缓存服务器传回的数据后显示出来,至此完成整个域名访问过程。 通过以上分析可以看到,不论是否使用CDN 网络,普通用户客户端设置不需做任何改变,直接使用被加速网站原有域名访问即可。对于要加速的网站,只需修改整个访问过程中的域名解析部分,便能实现透明的网络加速服务。 CDN 应用与架构 CDN 速度快、传输安全、扩展性强,尤其在应对大容量迸发时游刃有余,主要应用于跨地域的门户及行业网站,如游戏、娱乐、IT、新闻传媒、VOD、远程教育、音视频、下载、IPTV、金融证券等。 利用CDN 网络,网站用户无需投资价值不菲的服务器、网络带宽及相应的人力成本,便能实现将网站内容发布到离终端用户距离最近、路由最短的网际边缘Cache 节点,创造完美、快捷的网站使用体验。 构建 CDN 网络的通常有三类机构,一是基础电信运营商(如中国电信、中国网通等),二是纯粹以 CDN 为主营业务的专业服务商(如 ChinaCache 等),三是 IDC 运营服务商(如 SouIDC 等)。虽然上述机构建设CDN 网络的出发点、侧重点不尽相同,但有一点却是相通的,即都是为用户提供完美的网站加速服务。 IDC 运营商部署在各地的 IDC 中心机房,非常有利于其快速建立起适合自身业务拓展的 CDN 网络,投资少见效快。其最大优势在于可以利用现有的 IDC 托管用户资源,进一步挖掘其潜在的增值服务空间。同时对于其 IDC 托管用户来讲,只需很少的投入便可实现网站的平滑加速,并保持了服务及支持上的无缝延续。 SynCDN 便是SouIDC 构建的CDN 网站加速运营平台。 一般来讲,CDN 网络主要由中心节点、边缘节点两部分构成。 CDN 架构导引 最简单的 CDN 网络只需一台负责全局负载均衡的 DNS 和各节点一台 Cache,即可运行。 DNS 支持根据用户源 IP 地址解析不同的 IP,实现就近访问。为了保证高可用性等,CDN 网管中心需要监控各节点的流量、健康状况等。一个节点的单台Cache 承载数量不够时,才需要多台 Cache,多台Cache 同时工作时,才需要负载均衡器,使Cache 群协同工作。 CDN 中心节点 中心节点包括CDN 网管中心和全局负载均衡DNS 重定向解析系统,负责整个CDN 网络的分发及管理。 CDN 网管中心是整个CDN 能够正常运转的基础保证,它不仅能对整个CDN 网络中的各个子系统和设备进行实时监控,对各种故障产生相应的告警,还可以实时监测到系统中总的流量和各节点的流量,并保存在系统数据库中,使网管人员能够方便地进行进一步分析。一套完善的网管系统,允许用户按需对系统配置进行修改。 全局负载均衡DNS 通过一组预先定义好的策略,将当时最接近用户的Cache 节点地址提供给用户,使用户能够得到快速的服务。同时,它还与分布在各地的所有CDN 节点保持持续通信,搜集各节点的通信状态,确保不会将用户的请求分发到不可用、或不健康的 Cache 节点上。 CDN 边缘节点 CDN 边缘节点主要指异地分发节点,由负载均衡设备、高速缓存服务器两部分组成。 负载均衡设备负责每个节点中各个Cache 的负载均衡,保证节点的工作效率;同时还负责收集节点与周围环境的信息,保持与全局负载均衡DNS 的通信,实现整个系统的负载均衡。 高速缓存服务器(Cache)负责存储客户网站的大量信息,就像一个靠近用户的网站服务器一样响应本地用户的访问请求。通过全局负载均衡DNS 的控制,用户的请求被透明地指向离他最近的节点,节点中Cache 服务器就像网站的原始服务器一样,响应终端用户的请求。因其距离用户更近,故其响应时间才更快。 答案来源于网络
养狐狸的猫 2019-12-02 02:37:34 0 浏览量 回答数 0

回答

在开始谈我对架构本质的理解之前,先谈谈对今天技术沙龙主题的个人见解,千万级规模的网站感觉数量级是非常大的,对这个数量级我们战略上 要重 视 它 , 战术上又 要 藐 视 它。先举个例子感受一下千万级到底是什么数量级?现在很流行的优步(Uber),从媒体公布的信息看,它每天接单量平均在百万左右, 假如每天有10个小时的服务时间,平均QPS只有30左右。对于一个后台服务器,单机的平均QPS可以到达800-1000,单独看写的业务量很简单 。为什么我们又不能说轻视它?第一,我们看它的数据存储,每天一百万的话,一年数据量的规模是多少?其次,刚才说的订单量,每一个订单要推送给附近的司机、司机要并发抢单,后面业务场景的访问量往往是前者的上百倍,轻松就超过上亿级别了。 今天我想从架构的本质谈起之后,希望大家理解在做一些建构设计的时候,它的出发点以及它解决的问题是什么。 架构,刚开始的解释是我从知乎上看到的。什么是架构?有人讲, 说架构并不是一 个很 悬 乎的 东西 , 实际 上就是一个架子 , 放一些 业务 和算法,跟我们的生活中的晾衣架很像。更抽象一点,说架构其 实 是 对 我 们 重复性业务 的抽象和我 们 未来 业务 拓展的前瞻,强调过去的经验和你对整个行业的预见。 我们要想做一个架构的话需要哪些能力?我觉得最重要的是架构师一个最重要的能力就是你要有 战 略分解能力。这个怎么来看呢: 第一,你必须要有抽象的能力,抽象的能力最基本就是去重,去重在整个架构中体现在方方面面,从定义一个函数,到定义一个类,到提供的一个服务,以及模板,背后都是要去重提高可复用率。 第二, 分类能力。做软件需要做对象的解耦,要定义对象的属性和方法,做分布式系统的时候要做服务的拆分和模块化,要定义服务的接口和规范。 第三, 算法(性能),它的价值体现在提升系统的性能,所有性能的提升,最终都会落到CPU,内存,IO和网络这4大块上。 这一页PPT举了一些例子来更深入的理解常见技术背后的架构理念。 第一个例子,在分布式系统我们会做 MySQL分 库 分表,我们要从不同的库和表中读取数据,这样的抽象最直观就是使用模板,因为绝大多数SQL语义是相同的,除了路由到哪个库哪个表,如果不使用Proxy中间件,模板就是性价比最高的方法。 第二看一下加速网络的CDN,它是做速度方面的性能提升,刚才我们也提到从CPU、内存、IO、网络四个方面来考虑,CDN本质上一个是做网络智能调度优化,另一个是多级缓存优化。 第三个看一下服务化,刚才已经提到了,各个大网站转型过程中一定会做服务化,其实它就是做抽象和做服务的拆分。第四个看一下消息队列,本质上还是做分类,只不过不是两个边际清晰的类,而是把两个边际不清晰的子系统通过队列解构并且异步化。新浪微博整体架构是什么样的 接下我们看一下微博整体架构,到一定量级的系统整个架构都会变成三层,客户端包括WEB、安卓和IOS,这里就不说了。接着还都会有一个接口层, 有三个主要作用: 第一个作用,要做 安全隔离,因为前端节点都是直接和用户交互,需要防范各种恶意攻击; 第二个还充当着一个 流量控制的作用,大家知道,在2014年春节的时候,微信红包,每分钟8亿多次的请求,其实真正到它后台的请求量,只有十万左右的数量级(这里的数据可能不准),剩余的流量在接口层就被挡住了; 第三,我们看对 PC 端和移 动 端的需求不一样的,所以我们可以进行拆分。接口层之后是后台,可以看到微博后台有三大块: 一个是 平台服 务, 第二, 搜索, 第三, 大数据。到了后台的各种服务其实都是处理的数据。 像平台的业务部门,做的就是 数据存储和读 取,对搜索来说做的是 数据的 检 索,对大数据来说是做的数据的 挖掘。微博其实和淘宝是很类似 微博其实和淘宝是很类似的。一般来说,第一代架构,基本上能支撑到用户到 百万 级别,到第二代架构基本能支撑到 千万 级别都没什么问题,当业务规模到 亿级别时,需要第三代的架构。 从 LAMP 的架构到面向服 务 的架构,有几个地方是非常难的,首先不可能在第一代基础上通过简单的修修补补满足用户量快速增长的,同时线上业务又不能停, 这是我们常说的 在 飞 机上 换 引擎的 问题。前两天我有一个朋友问我,说他在内部推行服务化的时候,把一个模块服务化做完了,其他部门就是不接。我建议在做服务化的时候,首先更多是偏向业务的梳理,同时要找准一个很好的切入点,既有架构和服务化上的提升,业务方也要有收益,比如提升性能或者降低维护成本同时升级过程要平滑,建议开始从原子化服务切入,比如基础的用户服务, 基础的短消息服务,基础的推送服务。 第二,就是可 以做无状 态 服 务,后面会详细讲,还有数据量大了后需要做数据Sharding,后面会将。 第三代 架构 要解决的 问题,就是用户量和业务趋于稳步增加(相对爆发期的指数级增长),更多考虑技术框架的稳定性, 提升系统整体的性能,降低成本,还有对整个系统监控的完善和升级。 大型网站的系统架构是如何演变的 我们通过通过数据看一下它的挑战,PV是在10亿级别,QPS在百万,数据量在千亿级别。我们可用性,就是SLA要求4个9,接口响应最多不能超过150毫秒,线上所有的故障必须得在5分钟内解决完。如果说5分钟没处理呢?那会影响你年终的绩效考核。2015年微博DAU已经过亿。我们系统有上百个微服务,每周会有两次的常规上线和不限次数的紧急上线。我们的挑战都一样,就是数据量,bigger and bigger,用户体验是faster and faster,业务是more and more。互联网业务更多是产品体验驱动, 技 术 在 产 品 体验上最有效的贡献 , 就是你的性能 越来越好 。 每次降低加载一个页面的时间,都可以间接的降低这个页面上用户的流失率。微博的技术挑战和正交分解法解析架构 下面看一下 第三代的 架构 图 以及 我 们 怎么用正交分解法 阐 述。 我们可以看到我们从两个维度,横轴和纵轴可以看到。 一个 维 度 是 水平的 分层 拆分,第二从垂直的维度会做拆分。水平的维度从接口层、到服务层到数据存储层。垂直怎么拆分,会用业务架构、技术架构、监控平台、服务治理等等来处理。我相信到第二代的时候很多架构已经有了业务架构和技术架构的拆分。我们看一下, 接口层有feed、用户关系、通讯接口;服务层,SOA里有基层服务、原子服务和组合服务,在微博我们只有原子服务和组合服务。原子服务不依赖于任何其他服务,组合服务由几个原子服务和自己的业务逻辑构建而成 ,资源层负责海量数据的存储(后面例子会详细讲)。技 术框架解决 独立于 业务 的海量高并发场景下的技术难题,由众多的技术组件共同构建而成 。在接口层,微博使用JERSY框架,帮助你做参数的解析,参数的验证,序列化和反序列化;资源层,主要是缓存、DB相关的各类组件,比如Cache组件和对象库组件。监 控平台和服 务 治理 , 完成系统服务的像素级监控,对分布式系统做提前诊断、预警以及治理。包含了SLA规则的制定、服务监控、服务调用链监控、流量监控、错误异常监控、线上灰度发布上线系统、线上扩容缩容调度系统等。 下面我们讲一下常见的设计原则。 第一个,首先是系统架构三个利器: 一个, 我 们 RPC 服 务组 件 (这里不讲了), 第二个,我们 消息中 间 件 。消息中间件起的作用:可以把两个模块之间的交互异步化,其次可以把不均匀请求流量输出为匀速的输出流量,所以说消息中间件 异步化 解耦 和流量削峰的利器。 第三个是配置管理,它是 代码级灰度发布以及 保障系统降级的利器。 第二个 , 无状态 , 接口 层 最重要的就是无状 态。我们在电商网站购物,在这个过程中很多情况下是有状态的,比如我浏览了哪些商品,为什么大家又常说接口层是无状态的,其实我们把状态从接口层剥离到了数据层。像用户在电商网站购物,选了几件商品,到了哪一步,接口无状态后,状态要么放在缓存中,要么放在数据库中, 其 实 它并不是没有状 态 , 只是在 这 个 过 程中我 们 要把一些有状 态 的 东 西抽离出来 到了数据层。 第三个, 数据 层 比服 务层 更需要 设计,这是一条非常重要的经验。对于服务层来说,可以拿PHP写,明天你可以拿JAVA来写,但是如果你的数据结构开始设计不合理,将来数据结构的改变会花费你数倍的代价,老的数据格式向新的数据格式迁移会让你痛不欲生,既有工作量上的,又有数据迁移跨越的时间周期,有一些甚至需要半年以上。 第四,物理结构与逻辑结构的映射,上一张图看到两个维度切成十二个区间,每个区间代表一个技术领域,这个可以看做我们的逻辑结构。另外,不论后台还是应用层的开发团队,一般都会分几个垂直的业务组加上一个基础技术架构组,这就是从物理组织架构到逻辑的技术架构的完美的映射,精细化团队分工,有利于提高沟通协作的效率 。 第五, www .sanhao.com 的访问过程,我们这个架构图里没有涉及到的,举个例子,比如当你在浏览器输入www.sanhao网址的时候,这个请求在接口层之前发生了什么?首先会查看你本机DNS以及DNS服务,查找域名对应的IP地址,然后发送HTTP请求过去。这个请求首先会到前端的VIP地址(公网服务IP地址),VIP之后还要经过负载均衡器(Nginx服务器),之后才到你的应用接口层。在接口层之前发生了这么多事,可能有用户报一个问题的时候,你通过在接口层查日志根本发现不了问题,原因就是问题可能发生在到达接口层之前了。 第六,我们说分布式系统,它最终的瓶颈会落在哪里呢?前端时间有一个网友跟我讨论的时候,说他们的系统遇到了一个瓶颈, 查遍了CPU,内存,网络,存储,都没有问题。我说你再查一遍,因为最终你不论用上千台服务器还是上万台服务器,最终系统出瓶颈的一定会落在某一台机(可能是叶子节点也可能是核心的节点),一定落在CPU、内存、存储和网络上,最后查出来问题出在一台服务器的网卡带宽上。微博多级双机房缓存架构 接下来我们看一下微博的Feed多级缓存。我们做业务的时候,经常很少做业务分析,技术大会上的分享又都偏向技术架构。其实大家更多的日常工作是需要花费更多时间在业务优化上。这张图是统计微博的信息流前几页的访问比例,像前三页占了97%,在做缓存设计的时候,我们最多只存最近的M条数据。 这里强调的就是做系统设计 要基于用 户 的 场 景 , 越细致越好 。举了一个例子,大家都会用电商,电商在双十一会做全国范围内的活动,他们做设计的时候也会考虑场景的,一个就是购物车,我曾经跟相关开发讨论过,购物车是在双十一之前用户的访问量非常大,就是不停地往里加商品。在真正到双十一那天他不会往购物车加东西了,但是他会频繁的浏览购物车。针对这个场景,活动之前重点设计优化购物车的写场景, 活动开始后优化购物车的读场景。 你看到的微博是由哪些部分聚合而成的呢?最右边的是Feed,就是微博所有关注的人,他们的微博所组成的。微博我们会按照时间顺序把所有关注人的顺序做一个排序。随着业务的发展,除了跟时间序相关的微博还有非时间序的微博,就是会有广告的要求,增加一些广告,还有粉丝头条,就是拿钱买的,热门微博,都会插在其中。分发控制,就是说和一些推荐相关的,我推荐一些相关的好友的微博,我推荐一些你可能没有读过的微博,我推荐一些其他类型的微博。 当然对非时序的微博和分发控制微博,实际会起多个并行的程序来读取,最后同步做统一的聚合。这里稍微分享一下, 从SNS社交领域来看,国内现在做的比较好的三个信息流: 微博 是 基于弱关系的媒体信息流 ; 朋友圈是基于 强 关系的信息流 ; 另外一个做的比 较 好的就是今日 头 条 , 它并不是基于关系来构建信息流 , 而是基于 兴趣和相关性的个性化推荐 信息流 。 信息流的聚合,体现在很多很多的产品之中,除了SNS,电商里也有信息流的聚合的影子。比如搜索一个商品后出来的列表页,它的信息流基本由几部分组成:第一,打广告的;第二个,做一些推荐,热门的商品,其次,才是关键字相关的搜索结果。 信息流 开始的时候 很 简单 , 但是到后期会 发现 , 你的 这 个流 如何做控制分发 , 非常复杂, 微博在最近一两年一直在做 这样 的工作。刚才我们是从业务上分析,那么技术上怎么解决高并发,高性能的问题?微博访问量很大的时候,底层存储是用MySQL数据库,当然也会有其他的。对于查询请求量大的时候,大家知道一定有缓存,可以复用可重用的计算结果。可以看到,发一条微博,我有很多粉丝,他们都会来看我发的内容,所以 微博是最适合使用 缓 存 的系统,微博的读写比例基本在几十比一。微博使用了 双 层缓 存,上面是L1,每个L1上都是一组(包含4-6台机器),左边的框相当于一个机房,右边又是一个机房。在这个系统中L1缓存所起的作用是什么? 首先,L1 缓 存增加整个系 统 的 QPS, 其次 以低成本灵活扩容的方式 增加 系统 的 带宽 。想象一个极端场景,只有一篇博文,但是它的访问量无限增长,其实我们不需要影响L2缓存,因为它的内容存储的量小,但它就是访问量大。这种场景下,你就需要使用L1来扩容提升QPS和带宽瓶颈。另外一个场景,就是L2级缓存发生作用,比如我有一千万个用户,去访问的是一百万个用户的微博 ,这个时候,他不只是说你的吞吐量和访问带宽,就是你要缓存的博文的内容也很多了,这个时候你要考虑缓存的容量, 第二 级缓 存更多的是从容量上来 规划,保证请求以较小的比例 穿透到 后端的 数据 库 中 ,根据你的用户模型你可以估出来,到底有百分之多少的请求不能穿透到DB, 评估这个容量之后,才能更好的评估DB需要多少库,需要承担多大的访问的压力。另外,我们看双机房的话,左边一个,右边一个。 两个机房是互 为 主 备 , 或者互 为热备 。如果两个用户在不同地域,他们访问两个不同机房的时候,假设用户从IDC1过来,因为就近原理,他会访问L1,没有的话才会跑到Master,当在IDC1没找到的时候才会跑到IDC2来找。同时有用户从IDC2访问,也会有请求从L1和Master返回或者到IDC1去查找。 IDC1 和 IDC2 ,两个机房都有全量的用户数据,同时在线提供服务,但是缓存查询又遵循最近访问原理。还有哪些多级缓存的例子呢?CDN是典型的多级缓存。CDN在国内各个地区做了很多节点,比如在杭州市部署一个节点时,在机房里肯定不止一台机器,那么对于一个地区来说,只有几台服务器到源站回源,其他节点都到这几台服务器回源即可,这么看CDN至少也有两级。Local Cache+ 分布式 缓 存,这也是常见的一种策略。有一种场景,分布式缓存并不适用, 比如 单 点 资 源 的爆发性峰值流量,这个时候使用Local Cache + 分布式缓存,Local Cache 在 应用 服 务 器 上用很小的 内存资源 挡住少量的 极端峰值流量,长尾的流量仍然访问分布式缓存,这样的Hybrid缓存架构通过复用众多的应用服务器节点,降低了系统的整体成本。 我们来看一下 Feed 的存 储 架构,微博的博文主要存在MySQL中。首先来看内容表,这个比较简单,每条内容一个索引,每天建一张表,其次看索引表,一共建了两级索引。首先想象一下用户场景,大部分用户刷微博的时候,看的是他关注所有人的微博,然后按时间来排序。仔细分析发现在这个场景下, 跟一个用户的自己的相关性很小了。所以在一级索引的时候会先根据关注的用户,取他们的前条微博ID,然后聚合排序。我们在做哈希(分库分表)的时候,同时考虑了按照UID哈希和按照时间维度。很业务和时间相关性很高的,今天的热点新闻,明天就没热度了,数据的冷热非常明显,这种场景就需要按照时间维度做分表,首先冷热数据做了分离(可以对冷热数据采用不同的存储方案来降低成本),其次, 很容止控制我数据库表的爆炸。像微博如果只按照用户维度区分,那么这个用户所有数据都在一张表里,这张表就是无限增长的,时间长了查询会越来越慢。二级索引,是我们里面一个比较特殊的场景,就是我要快速找到这个人所要发布的某一时段的微博时,通过二级索引快速定位。 分布式服务追踪系统 分布式追踪服务系统,当系统到千万级以后的时候,越来越庞杂,所解决的问题更偏向稳定性,性能和监控。刚才说用户只要有一个请求过来,你可以依赖你的服务RPC1、RPC2,你会发现RPC2又依赖RPC3、RPC4。分布式服务的时候一个痛点,就是说一个请求从用户过来之后,在后台不同的机器之间不停的调用并返回。 当你发现一个问题的时候,这些日志落在不同的机器上,你也不知道问题到底出在哪儿,各个服务之间互相隔离,互相之间没有建立关联。所以导致排查问题基本没有任何手段,就是出了问题没法儿解决。 我们要解决的问题,我们刚才说日志互相隔离,我们就要把它建立联系。建立联系我们就有一个请求ID,然后结合RPC框架, 服务治理功能。假设请求从客户端过来,其中包含一个ID 101,到服务A时仍然带有ID 101,然后调用RPC1的时候也会标识这是101 ,所以需要 一个唯一的 请求 ID 标识 递归迭代的传递到每一个 相关 节点。第二个,你做的时候,你不能说每个地方都加,对业务系统来说需要一个框架来完成这个工作, 这 个框架要 对业务 系 统 是最低侵入原 则 , 用 JAVA 的 话 就可以用 AOP,要做到零侵入的原则,就是对所有相关的中间件打点,从接口层组件(HTTP Client、HTTP Server)至到服务层组件(RPC Client、RPC Server),还有数据访问中间件的,这样业务系统只需要少量的配置信息就可以实现全链路监控 。为什么要用日志?服务化以后,每个服务可以用不同的开发语言, 考虑多种开发语言的兼容性 , 内部定 义标 准化的日志 是唯一且有效的办法。最后,如何构建基于GPS导航的路况监控?我们刚才讲分布式服务追踪。分布式服务追踪能解决的问题, 如果 单一用 户发现问题 后 , 可以通 过请 求 ID 快速找到 发 生 问题 的 节 点在什么,但是并没有解决如何发现问题。我们看现实中比较容易理解的道路监控,每辆车有GPS定位,我想看北京哪儿拥堵的时候,怎么做? 第一个 , 你肯定要知道每个 车 在什么位置,它走到哪儿了。其实可以说每个车上只要有一个标识,加上每一次流动的信息,就可以看到每个车流的位置和方向。 其次如何做 监 控和 报 警,我们怎么能了解道路的流量状况和负载,并及时报警。我们要定义这条街道多宽多高,单位时间可以通行多少辆车,这就是道路的容量。有了道路容量,再有道路的实时流量,我们就可以基于实习路况做预警? 对应于 分布式系 统 的话如何构建? 第一 , 你要 定义 每个服 务节 点它的 SLA A 是多少 ?SLA可以从系统的CPU占用率、内存占用率、磁盘占用率、QPS请求数等来定义,相当于定义系统的容量。 第二个 , 统计 线 上 动态 的流量,你要知道服务的平均QPS、最低QPS和最大QPS,有了流量和容量,就可以对系统做全面的监控和报警。 刚才讲的是理论,实际情况肯定比这个复杂。微博在春节的时候做许多活动,必须保障系统稳定,理论上你只要定义容量和流量就可以。但实际远远不行,为什么?有技术的因素,有人为的因素,因为不同的开发定义的流量和容量指标有主观性,很难全局量化标准,所以真正流量来了以后,你预先评估的系统瓶颈往往不正确。实际中我们在春节前主要采取了三个措施:第一,最简单的就是有降 级 的 预 案,流量超过系统容量后,先把哪些功能砍掉,需要有明确的优先级 。第二个, 线上全链路压测,就是把现在的流量放大到我们平常流量的五倍甚至十倍(比如下线一半的服务器,缩容而不是扩容),看看系统瓶颈最先发生在哪里。我们之前有一些例子,推测系统数据库会先出现瓶颈,但是实测发现是前端的程序先遇到瓶颈。第三,搭建在线 Docker 集群 , 所有业务共享备用的 Docker集群资源,这样可以极大的避免每个业务都预留资源,但是实际上流量没有增长造成的浪费。 总结 接下来说的是如何不停的学习和提升,这里以Java语言为例,首先, 一定要 理解 JAVA;第二步,JAVA完了以后,一定要 理 解 JVM;其次,还要 理解 操作系统;再次还是要了解一下 Design Pattern,这将告诉你怎么把过去的经验抽象沉淀供将来借鉴;还要学习 TCP/IP、 分布式系 统、数据结构和算法。
hiekay 2019-12-02 01:39:25 0 浏览量 回答数 0

问题

用负载均衡实现ECS的高可用性

负载均衡(Server Load Balancer)是将访问流量根据转发策略分发到后端多台云服务器ECS的流量分发控制服务。 应用场景 在以下应用场景中,若您搭配使用SLB,可以极...
chenchuan 2019-12-01 21:33:54 540 浏览量 回答数 0

问题

【案例】从hadoop框架与MapReduce模式中谈海量数据处理

首先申明,不是我原创,但是我看到比较不错的一片讲大数据分析处理的文章。谈到的阿里使用的云梯1,确实是使用的如下文的机制。但云梯1在阿里已经下线,目前使用的云梯2是用的ODPS的机制。技...
jack.cai 2019-12-01 21:00:28 15859 浏览量 回答数 3

问题

【百问百答】《CDN排坑指南》

1、什么是 CDN? 2、阿里云 CDN目前的基本概况是什么? 3、CDN 加速前会造成哪几种不好的情况? 4、阿里云 CDN 缓存策略时什么? 5、阿里云CDN 工作原理是什...
Lee_tianbai 2021-01-08 15:32:02 355 浏览量 回答数 1

问题

Nginx性能为什么如此吊

Nginx性能为什么如此吊,Nginx性能为什么如此吊,Nginx性能为什么如此吊 (重要的事情说三遍)的性能为什么如此吊!!!         最近几年,web架构拥抱解耦的...
小柒2012 2019-12-01 21:20:47 15038 浏览量 回答数 3

问题

用负载均衡实现ECS的可用性有哪些?

负载均衡(Server Load Balancer)是将访问流量根据转发策略分发到后端多台云服务器(Elastic Compute Service,简称 ECS)的流量分...
boxti 2019-12-01 21:37:24 1496 浏览量 回答数 0

回答

结构 timer 就是 Golang 定时器的内部表示,每一个 timer 其实都存储在堆中,tb 就是用于存储当前定时器的桶,而 i 是当前定时器在堆中的索引,我们可以通过这两个变量找到当前定时器在堆中的位置: type timer struct { tb *timersBucket i int when int64 period int64 f func(interface{}, uintptr) arg interface{} seq uintptr } when 表示当前定时器(Timer)被唤醒的时间,而 period 表示两次被唤醒的间隔,每当定时器被唤醒时都会调用 f(args, now) 函数并传入 args 和当前时间作为参数。然而这里的 timer 作为一个私有结构体其实只是定时器的运行时表示,time 包对外暴露的定时器使用了如下所示的结构体: type Timer struct { C <-chan Time r runtimeTimer } Timer 定时器必须通过 NewTimer 或者 AfterFunc 函数进行创建,其中的 runtimeTimer 其实就是上面介绍的 timer 结构体,当定时器失效时,失效的时间就会被发送给当前定时器持有的 Channel C,订阅管道中消息的 Goroutine 就会收到当前定时器失效的时间。 在 time 包中,除了 timer 和 Timer 两个分别用于表示运行时定时器和对外暴露的 API 之外,timersBucket 这个用于存储定时器的结构体也非常重要,它会存储一个处理器上的全部定时器,不过如果当前机器的核数超过了 64 核,也就是机器上的处理器 P 的个数超过了 64 个,多个处理器上的定时器就可能存储在同一个桶中: type timersBucket struct { lock mutex gp *g created bool sleeping bool rescheduling bool sleepUntil int64 waitnote note t []*timer } 每一个 timersBucket 中的 t 就是用于存储定时器指针的切片,每一个运行的 Go 语言程序都会在内存中存储着 64 个桶,这些桶中都存储定时器的信息:  每一个桶持有的 timer 切片其实都是一个最小堆,这个最小堆会按照 timer 应该触发的时间对它们进行排序,最小堆最上面的定时器就是最近需要被唤醒的 timer,我们会在下面展开介绍定时器的创建和触发过程。 工作原理 既然我们已经介绍了定时器的数据结构,接下来我们就可以开始分析它的常见操作以及工作原理了,在这一节中我们将介绍定时器的创建、触发、time.Sleep 与定时器的关系以及计时器 Ticker 的实现原理。 创建 time 包对外提供了两种创建定时器的方法,第一种方法就是 NewTimer 接口,这个接口会创建一个用于通知触发时间的 Channel、调用 startTimer 方法并返回一个创建指向 Timer 结构体的指针: func NewTimer(d Duration) *Timer { c := make(chan Time, 1) t := &Timer{ C: c, r: runtimeTimer{ when: when(d), f: sendTime, arg: c, }, } startTimer(&t.r) return t } 另一个用于创建 Timer 的方法 AfterFunc 其实也提供了非常相似的结构,与 NewTimer 方法不同的是该方法没有创建一个用于通知触发时间的 Channel,它只会在定时器到期时调用传入的方法: func AfterFunc(d Duration, f func()) *Timer { t := &Timer{ r: runtimeTimer{ when: when(d), f: goFunc, arg: f, }, } startTimer(&t.r) return t } startTimer 基本上就是创建定时器的入口了,所有定时器的创建和重启基本上都需要调用该函数: func startTimer(t *timer) { addtimer(t) } func addtimer(t *timer) { tb := t.assignBucket() tb.addtimerLocked(t) } 它会调用 addTimer 函数,这个函数总共做了两件事情,首先通过 assignBucket 方法为当前定时器选择一个 timersBucket 桶,我们会根据当前 Goroutine 所在处理器 P 的 id 选择一个合适的桶,随后调用 addTimerLocked 方法将当前定时器加入桶中: func (tb *timersBucket) addtimerLocked(t *timer) bool { t.i = len(tb.t) tb.t = append(tb.t, t) if !siftupTimer(tb.t, t.i) { return false } if t.i == 0 { if tb.sleeping && tb.sleepUntil > t.when { tb.sleeping = false notewakeup(&tb.waitnote) } if tb.rescheduling { tb.rescheduling = false goready(tb.gp, 0) } if !tb.created { tb.created = true go timerproc(tb) } } return true } addtimerLocked 会先将最新加入的定时器加到队列的末尾,随后调用 siftupTimer 将当前定时器与四叉树(或者四叉堆)中的父节点进行比较,保证父节点的到期时间一定大于子节点:  这个四叉树只能保证父节点的到期时间大于子节点,这对于我们来说其实也足够了,因为我们只关心即将被触发的计数器,如果当前定时器是第一个被加入四叉树的定时器,我们还会通过 go timerproc(tb) 启动一个 Goroutine 用于处理当前树中的定时器,这也是处理定时器的核心方法。 触发 定时器的触发都是由 timerproc 中的一个双层 for 循环控制的,外层的 for 循环主要负责对当前 Goroutine 进行控制,它不仅会负责锁的获取和释放,还会在合适的时机触发当前 Goroutine 的休眠: func timerproc(tb *timersBucket) { tb.gp = getg() for { tb.sleeping = false now := nanotime() delta := int64(-1) // inner loop if delta < 0 { tb.rescheduling = true goparkunlock(&tb.lock, waitReasonTimerGoroutineIdle, traceEvGoBlock, 1) continue } tb.sleeping = true tb.sleepUntil = now + delta noteclear(&tb.waitnote) notetsleepg(&tb.waitnote, delta) } } 如果距离下一个定时器被唤醒的时间小于 0,当前的 timerproc 就会将 rescheduling 标记设置成 true 并立刻陷入休眠,这其实也意味着当前 timerproc 中不包含任何待处理的定时器,当我们再向该 timerBucket 加入定时器时就会重新唤醒 timerproc Goroutine。 在其他情况下,也就是下一次计数器的响应时间是 now + delta 时,timerproc 中的外层循环会通过 notesleepg 将当前 Goroutine 陷入休眠。 func notetsleepg(n *note, ns int64) bool { gp := getg() if gp == gp.m.g0 { throw("notetsleepg on g0") } semacreate(gp.m) entersyscallblock() ok := notetsleep_internal(n, ns, nil, 0) exitsyscall() return ok } 该函数会先获取当前的 Goroutine 并在当前的『CPU 上』创建一个信号量,随后在 entersyscallblock 和 exitsyscall 之间执行系统调用让当前的 Goroutine 陷入休眠并在 ns 纳秒后返回。 内部循环的主要作用就是触发已经到期的定时器,在这个内部循环中,我们会按照以下的流程对当前桶中的定时器进行处理: 如果桶中不包含任何定时器就会直接返回并陷入休眠等待定时器加入当前桶; 如果四叉树最上面的定时器还没有到期会通过 notetsleepg 方法陷入休眠等待最近定时器的到期; 如果四叉树最上面的定时器已经到期; 当定时器的 period > 0 就会设置下一次会触发定时器的时间并将当前定时器向下移动到对应的位置; 当定时器的 period <= 0 就会将当前定时器从四叉树中移除; 在每次循环的最后都会从定时器中取出定时器中的函数、参数和序列号并调用函数触发该计数器; ```js for { if len(tb.t) == 0 { delta = -1 break } t := tb.t[0] delta = t.when - now if delta > 0 { break } ok := true if t.period > 0 { t.when += t.period * (1 + -delta/t.period) if !siftdownTimer(tb.t, 0) { ok = false } } else { last := len(tb.t) - 1 if last > 0 { tb.t[0] = tb.t[last] tb.t[0].i = 0 } tb.t[last] = nil tb.t = tb.t[:last] if last > 0 { if !siftdownTimer(tb.t, 0) { ok = false } } t.i = -1 // mark as removed } f := t.f arg := t.arg seq := t.seq f(arg, seq) } 使用 NewTimer 创建的定时器,传入的函数时 sendTime,它会将当前时间发送到定时器持有的 Channel 中,而使用 AfterFunc 创建的定时器,在内层循环中调用的函数就会是调用方传入的函数了。 **休眠** 如果你使用过一段时间的 Go 语言,你一定在项目中使用过 time 包中的 Sleep 方法让当前的 Goroutine 陷入休眠以等待某些条件的完成或者触发一些定时任务,time.Sleep 就是通过如下所示的 timeSleep 方法完成的: ```js func timeSleep(ns int64) { if ns <= 0 { return } gp := getg() t := gp.timer if t == nil { t = new(timer) gp.timer = t } *t = timer{} t.when = nanotime() + ns t.f = goroutineReady t.arg = gp tb := t.assignBucket() lock(&tb.lock) if !tb.addtimerLocked(t) { unlock(&tb.lock) badTimer() } goparkunlock(&tb.lock, waitReasonSleep, traceEvGoSleep, 2) } timeSleep 会创建一个新的 timer 结构体,在初始化的过程中我们会传入当前 Goroutine 应该被唤醒的时间以及唤醒时需要调用的函数 goroutineReady,随后会调用 goparkunlock 将当前 Goroutine 陷入休眠状态,当定时器到期时也会调用 goroutineReady 方法唤醒当前的 Goroutine: func goroutineReady(arg interface{}, seq uintptr) { goready(arg.(*g), 0) } time.Sleep 方法其实只是创建了一个会在到期时唤醒当前 Goroutine 的定时器并通过 goparkunlock 将当前的协程陷入休眠状态等待定时器触发的唤醒。 Ticker 除了只用于一次的定时器(Timer)之外,Go 语言的 time 包中还提供了用于多次通知的 Ticker 计时器,计时器中包含了一个用于接受通知的 Channel 和一个定时器,这两个字段共同组成了用于连续多次触发事件的计时器: type Ticker struct { C <-chan Time // The channel on which the ticks are delivered. r runtimeTimer } 想要在 Go 语言中创建一个计时器只有两种方法,一种是使用 NewTicker 方法显示地创建Ticker 计时器指针,另一种可以直接通过 Tick 方法获取一个会定期发送消息的 Channel: func NewTicker(d Duration) *Ticker { if d <= 0 { panic(errors.New("non-positive interval for NewTicker")) } c := make(chan Time, 1) t := &Ticker{ C: c, r: runtimeTimer{ when: when(d), period: int64(d), f: sendTime, arg: c, }, } startTimer(&t.r) return t } func Tick(d Duration) <-chan Time { if d <= 0 { return nil } return NewTicker(d).C } Tick 其实也只是对 NewTicker 的简单封装,从实现上我们就能看出来它其实就是调用了 NewTicker 获取了计时器并返回了计时器中 Channel,两个创建计时器的方法的实现都并不复杂而且费容易理解,所以在这里也就不详细展开介绍了。 需要注意的是每一个 NewTicker 方法开启的计时器都需要在不需要使用时调用 Stop 进行关闭,如果不显示调用 Stop 方法,创建的计时器就没有办法被垃圾回收,而通过 Tick 创建的计时器由于只对外提供了 Channel,所以是一定没有办法关闭的,我们一定要谨慎使用这一接口创建计时器。 性能分析 定时器在内部使用四叉树的方式进行实现和存储,当我们在生产环境中使用定时器进行毫秒级别的计时时,在高并发的场景下会有比较明显的性能问题,我们可以通过实验测试一下定时器在高并发时的性能,假设我们有以下的代码: func runTimers(count int) { durationCh := make(chan time.Duration, count) wg := sync.WaitGroup{} wg.Add(count) for i := 0; i < count; i++ { go func() { startedAt := time.Now() time.AfterFunc(10*time.Millisecond, func() { defer wg.Done() durationCh <- time.Since(startedAt) }) }() } wg.Wait() close(durationCh) durations := []time.Duration{} totalDuration := 0 * time.Millisecond for duration := range durationCh { durations = append(durations, duration) totalDuration += duration } averageDuration := totalDuration / time.Duration(count) sort.Slice(durations, func(i, j int) bool { return durations[i] < durations[j] }) fmt.Printf("run %v timers with average=%v, pct50=%v, pct99=%v\n", count, averageDuration, durations[count/2], durations[int(float64(count)*0.99)]) } 完整的性能测试代码可以在 benchmark_timers.go 中找到,需要注意的是:由于机器和性能的不同,多次运行测试可能会有不一样的结果。 这段代码开了 N 个 Goroutine 并在每一个 Goroutine 中运行一个定时器,我们会在定时器到期时将开始计时到定时器到期所用的时间加入 Channel 并用于之后的统计,在函数的最后我们会计算出 N 个 Goroutine 中定时器到期时间的平均数、50 分位数和 99 分位数: $ go test ./... -v === RUN TestTimers run 1000 timers with average=10.367111ms, pct50=10.234219ms, pct99=10.913219ms run 2000 timers with average=10.431598ms, pct50=10.37367ms, pct99=11.025823ms run 5000 timers with average=11.873773ms, pct50=11.986249ms, pct99=12.673725ms run 10000 timers with average=11.954716ms, pct50=12.313613ms, pct99=13.507858ms run 20000 timers with average=11.456237ms, pct50=10.625529ms, pct99=25.246254ms run 50000 timers with average=21.223818ms, pct50=14.792982ms, pct99=34.250143ms run 100000 timers with average=36.010924ms, pct50=31.794761ms, pct99=128.089527ms run 500000 timers with average=176.676498ms, pct50=138.238588ms, pct99=676.967558ms --- PASS: TestTimers (1.21s) 我们将上述代码输出的结果绘制成如下图所示的折线图,其中横轴是并行定时器的个数,纵轴表示定时器从开始到触发时间的差值,三个不同的线分别表示时间的平均值、50 分位数和 99 分位数:  虽然测试的数据可能有一些误差,但是从图中我们也能得出一些跟定时器性能和现象有关的结论: 定时器触发的时间一定会晚于创建时传入的时间,假设定时器需要等待 10ms 触发,那它触发的时间一定是晚于 10ms 的; 当并发的定时器数量达到 5000 时,定时器的平均误差达到了 ~18%,99 分位数上的误差达到了 ~26%; 并发定时器的数量超过 5000 之后,定时器的误差就变得非常明显,不能有效、准确地完成计时任务; 这其实也是因为定时器从开始到触发的时间间隔非常短,当我们将计时的时间改到 100ms 时就会发现性能问题有比较明显的改善:  哪怕并行运行了 10w 个定时器,99 分位数的误差也只有 ~12%,我们其实能够发现 Go 语言标准库中的定时器在计时时间较短并且并发较高时有着非常明显的问题,所以在一些性能非常敏感的基础服务中使用定时器一定要非常注意 —— 它可能达不到我们预期的效果。 不过哪怕我们不主动使用定时器,而是使用 context.WithDeadline 这种方法,由于它底层也会使用定时器实现,所以仍然会受到影响。 总结 Go 语言的定时器在并发编程起到了非常重要的作用,它能够为我们提供比较准确的相对时间,基于它的功能,标准库中还提供了计时器、休眠等接口能够帮助我们在 Go 语言程序中更好地处理过期和超时等问题。 标准库中的定时器在大多数情况下是能够正常工作并且高效完成任务的,但是在遇到极端情况或者性能敏感场景时,它可能没有办法胜任,而在 10ms 的这个粒度下,作者在社区中也没有找到能够使用的定时器实现,一些使用时间轮算法的开源库也不能很好地完成这个任务。
有只黑白猫 2020-01-10 10:01:15 0 浏览量 回答数 0

回答

1.什么是爬虫 爬虫,即网络爬虫,大家可以理解为在网络上爬行的一直蜘蛛,互联网就比作一张大网,而爬虫便是在这张网上爬来爬去的蜘蛛咯,如果它遇到资源,那么它就会抓取下来。想抓取什么?这个由你来控制它咯。 比如它在抓取一个网页,在这个网中他发现了一条道路,其实就是指向网页的超链接,那么它就可以爬到另一张网上来获取数据。这样,整个连在一起的大网对这之蜘蛛来说触手可及,分分钟爬下来不是事儿。 2.浏览网页的过程 在用户浏览网页的过程中,我们可能会看到许多好看的图片,比如 http://image.baidu.com/ ,我们会看到几张的图片以及百度搜索框,这个过程其实就是用户输入网址之后,经过DNS服务器,找到服务器主机,向服务器发出一个请求,服务器经过解析之后,发送给用户的浏览器 HTML、JS、CSS 等文件,浏览器解析出来,用户便可以看到形形色色的图片了。 因此,用户看到的网页实质是由 HTML 代码构成的,爬虫爬来的便是这些内容,通过分析和过滤这些 HTML 代码,实现对图片、文字等资源的获取。 3.URL的含义 URL,即统一资源定位符,也就是我们说的网址,统一资源定位符是对可以从互联网上得到的资源的位置和访问方法的一种简洁的表示,是互联网上标准资源的地址。互联网上的每个文件都有一个唯一的URL,它包含的信息指出文件的位置以及浏览器应该怎么处理它。 URL的格式由三部分组成:①第一部分是协议(或称为服务方式)。②第二部分是存有该资源的主机IP地址(有时也包括端口号)。③第三部分是主机资源的具体地址,如目录和文件名等。爬虫爬取数据时必须要有一个目标的URL才可以获取数据,因此,它是爬虫获取数据的基本依据,准确理解它的含义对爬虫学习有很大帮助。 环境的配置 学习Python,当然少不了环境的配置,最初我用的是Notepad++,不过发现它的提示功能实在是太弱了,于是,在Windows下我用了 PyCharm,在Linux下我用了Eclipse for Python,另外还有几款比较优秀的IDE,大家可以参考这篇文章 学习Python推荐的IDE 。好的开发工具是前进的推进器,希望大家可以找到适合自己的IDE 作者:谢科链接:https://www.zhihu.com/question/20899988/answer/24923424来源:知乎著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。 “入门”是良好的动机,但是可能作用缓慢。如果你手里或者脑子里有一个项目,那么实践起来你会被目标驱动,而不会像学习模块一样慢慢学习。另外如果说知识体系里的每一个知识点是图里的点,依赖关系是边的话,那么这个图一定不是一个有向无环图。因为学习A的经验可以帮助你学习B。因此,你不需要学习怎么样“入门”,因为这样的“入门”点根本不存在!你需要学习的是怎么样做一个比较大的东西,在这个过程中,你会很快地学会需要学会的东西的。当然,你可以争论说需要先懂python,不然怎么学会python做爬虫呢?但是事实上,你完全可以在做这个爬虫的过程中学习python :D看到前面很多答案都讲的“术”——用什么软件怎么爬,那我就讲讲“道”和“术”吧——爬虫怎么工作以及怎么在python实现。先长话短说summarize一下:你需要学习基本的爬虫工作原理基本的http抓取工具,scrapyBloom Filter: Bloom Filters by Example如果需要大规模网页抓取,你需要学习分布式爬虫的概念。其实没那么玄乎,你只要学会怎样维护一个所有集群机器能够有效分享的分布式队列就好。最简单的实现是python-rq: https://github.com/nvie/rqrq和Scrapy的结合:darkrho/scrapy-redis · GitHub后续处理,网页析取(grangier/python-goose · GitHub),存储(Mongodb)以下是短话长说:说说当初写的一个集群爬下整个豆瓣的经验吧。1)首先你要明白爬虫怎样工作。想象你是一只蜘蛛,现在你被放到了互联“网”上。那么,你需要把所有的网页都看一遍。怎么办呢?没问题呀,你就随便从某个地方开始,比如说人民日报的首页,这个叫initial pages,用$表示吧。在人民日报的首页,你看到那个页面引向的各种链接。于是你很开心地从爬到了“国内新闻”那个页面。太好了,这样你就已经爬完了俩页面(首页和国内新闻)!暂且不用管爬下来的页面怎么处理的,你就想象你把这个页面完完整整抄成了个html放到了你身上。突然你发现, 在国内新闻这个页面上,有一个链接链回“首页”。作为一只聪明的蜘蛛,你肯定知道你不用爬回去的吧,因为你已经看过了啊。所以,你需要用你的脑子,存下你已经看过的页面地址。这样,每次看到一个可能需要爬的新链接,你就先查查你脑子里是不是已经去过这个页面地址。如果去过,那就别去了。好的,理论上如果所有的页面可以从initial page达到的话,那么可以证明你一定可以爬完所有的网页。那么在python里怎么实现呢?很简单import Queue initial_page = "http://www.renminribao.com" url_queue = Queue.Queue()seen = set() seen.insert(initial_page)url_queue.put(initial_page) while(True): #一直进行直到海枯石烂 if url_queue.size()>0: current_url = url_queue.get() #拿出队例中第一个的url store(current_url) #把这个url代表的网页存储好 for next_url in extract_urls(current_url): #提取把这个url里链向的url if next_url not in seen: seen.put(next_url) url_queue.put(next_url) else: break 写得已经很伪代码了。所有的爬虫的backbone都在这里,下面分析一下为什么爬虫事实上是个非常复杂的东西——搜索引擎公司通常有一整个团队来维护和开发。2)效率如果你直接加工一下上面的代码直接运行的话,你需要一整年才能爬下整个豆瓣的内容。更别说Google这样的搜索引擎需要爬下全网的内容了。问题出在哪呢?需要爬的网页实在太多太多了,而上面的代码太慢太慢了。设想全网有N个网站,那么分析一下判重的复杂度就是N*log(N),因为所有网页要遍历一次,而每次判重用set的话需要log(N)的复杂度。OK,OK,我知道python的set实现是hash——不过这样还是太慢了,至少内存使用效率不高。通常的判重做法是怎样呢?Bloom Filter. 简单讲它仍然是一种hash的方法,但是它的特点是,它可以使用固定的内存(不随url的数量而增长)以O(1)的效率判定url是否已经在set中。可惜天下没有白吃的午餐,它的唯一问题在于,如果这个url不在set中,BF可以100%确定这个url没有看过。但是如果这个url在set中,它会告诉你:这个url应该已经出现过,不过我有2%的不确定性。注意这里的不确定性在你分配的内存足够大的时候,可以变得很小很少。一个简单的教程:Bloom Filters by Example注意到这个特点,url如果被看过,那么可能以小概率重复看一看(没关系,多看看不会累死)。但是如果没被看过,一定会被看一下(这个很重要,不然我们就要漏掉一些网页了!)。 [IMPORTANT: 此段有问题,请暂时略过]好,现在已经接近处理判重最快的方法了。另外一个瓶颈——你只有一台机器。不管你的带宽有多大,只要你的机器下载网页的速度是瓶颈的话,那么你只有加快这个速度。用一台机子不够的话——用很多台吧!当然,我们假设每台机子都已经进了最大的效率——使用多线程(python的话,多进程吧)。3)集群化抓取爬取豆瓣的时候,我总共用了100多台机器昼夜不停地运行了一个月。想象如果只用一台机子你就得运行100个月了...那么,假设你现在有100台机器可以用,怎么用python实现一个分布式的爬取算法呢?我们把这100台中的99台运算能力较小的机器叫作slave,另外一台较大的机器叫作master,那么回顾上面代码中的url_queue,如果我们能把这个queue放到这台master机器上,所有的slave都可以通过网络跟master联通,每当一个slave完成下载一个网页,就向master请求一个新的网页来抓取。而每次slave新抓到一个网页,就把这个网页上所有的链接送到master的queue里去。同样,bloom filter也放到master上,但是现在master只发送确定没有被访问过的url给slave。Bloom Filter放到master的内存里,而被访问过的url放到运行在master上的Redis里,这样保证所有操作都是O(1)。(至少平摊是O(1),Redis的访问效率见:LINSERT – Redis)考虑如何用python实现:在各台slave上装好scrapy,那么各台机子就变成了一台有抓取能力的slave,在master上装好Redis和rq用作分布式队列。代码于是写成#slave.py current_url = request_from_master()to_send = []for next_url in extract_urls(current_url): to_send.append(next_url) store(current_url);send_to_master(to_send) master.py distributed_queue = DistributedQueue()bf = BloomFilter() initial_pages = "www.renmingribao.com" while(True): if request == 'GET': if distributed_queue.size()>0: send(distributed_queue.get()) else: break elif request == 'POST': bf.put(request.url) 好的,其实你能想到,有人已经给你写好了你需要的:darkrho/scrapy-redis · GitHub4)展望及后处理虽然上面用很多“简单”,但是真正要实现一个商业规模可用的爬虫并不是一件容易的事。上面的代码用来爬一个整体的网站几乎没有太大的问题。但是如果附加上你需要这些后续处理,比如有效地存储(数据库应该怎样安排)有效地判重(这里指网页判重,咱可不想把人民日报和抄袭它的大民日报都爬一遍)有效地信息抽取(比如怎么样抽取出网页上所有的地址抽取出来,“朝阳区奋进路中华道”),搜索引擎通常不需要存储所有的信息,比如图片我存来干嘛...及时更新(预测这个网页多久会更新一次)
xuning715 2019-12-02 01:10:40 0 浏览量 回答数 0

问题

IHS性能优化调优建议

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

回答

面试官心理分析 这个问题是肯定要问的,说白了,就是看你有没有实际干过 es,因为啥?其实 es 性能并没有你想象中那么好的。很多时候数据量大了,特别是有几亿条数据的时候,可能你会懵逼的发现,跑个搜索怎么一下 5~10s,坑爹了。第一次搜索的时候,是 5~10s,后面反而就快了,可能就几百毫秒。 你就很懵,每个用户第一次访问都会比较慢,比较卡么?所以你要是没玩儿过 es,或者就是自己玩玩儿 demo,被问到这个问题容易懵逼,显示出你对 es 确实玩儿的不怎么样? 面试题剖析 说实话,es 性能优化是没有什么银弹的,啥意思呢?就是不要期待着随手调一个参数,就可以万能的应对所有的性能慢的场景。也许有的场景是你换个参数,或者调整一下语法,就可以搞定,但是绝对不是所有场景都可以这样。 性能优化的杀手锏——filesystem cache 你往 es 里写的数据,实际上都写到磁盘文件里去了,查询的时候,操作系统会将磁盘文件里的数据自动缓存到 filesystem cache 里面去。 es 的搜索引擎严重依赖于底层的 filesystem cache,你如果给 filesystem cache 更多的内存,尽量让内存可以容纳所有的 idx segment file 索引数据文件,那么你搜索的时候就基本都是走内存的,性能会非常高。 性能差距究竟可以有多大?我们之前很多的测试和压测,如果走磁盘一般肯定上秒,搜索性能绝对是秒级别的,1秒、5秒、10秒。但如果是走 filesystem cache,是走纯内存的,那么一般来说性能比走磁盘要高一个数量级,基本上就是毫秒级的,从几毫秒到几百毫秒不等。 这里有个真实的案例。某个公司 es 节点有 3 台机器,每台机器看起来内存很多,64G,总内存就是 64 * 3 = 192G。每台机器给 es jvm heap 是 32G,那么剩下来留给 filesystem cache 的就是每台机器才 32G,总共集群里给 filesystem cache 的就是 32 * 3 = 96G 内存。而此时,整个磁盘上索引数据文件,在 3 台机器上一共占用了 1T 的磁盘容量,es 数据量是 1T,那么每台机器的数据量是 300G。这样性能好吗? filesystem cache 的内存才 100G,十分之一的数据可以放内存,其他的都在磁盘,然后你执行搜索操作,大部分操作都是走磁盘,性能肯定差。 归根结底,你要让 es 性能要好,最佳的情况下,就是你的机器的内存,至少可以容纳你的总数据量的一半。 根据我们自己的生产环境实践经验,最佳的情况下,是仅仅在 es 中就存少量的数据,就是你要用来搜索的那些索引,如果内存留给 filesystem cache 的是 100G,那么你就将索引数据控制在 100G 以内,这样的话,你的数据几乎全部走内存来搜索,性能非常之高,一般可以在 1 秒以内。 比如说你现在有一行数据。id,name,age .... 30 个字段。但是你现在搜索,只需要根据 id,name,age 三个字段来搜索。如果你傻乎乎往 es 里写入一行数据所有的字段,就会导致说 90% 的数据是不用来搜索的,结果硬是占据了 es 机器上的 filesystem cache 的空间,单条数据的数据量越大,就会导致 filesystem cahce 能缓存的数据就越少。其实,仅仅写入 es 中要用来检索的少数几个字段就可以了,比如说就写入 es id,name,age 三个字段,然后你可以把其他的字段数据存在 mysql/hbase 里,我们一般是建议用 es + hbase 这么一个架构。 hbase 的特点是适用于海量数据的在线存储,就是对 hbase 可以写入海量数据,但是不要做复杂的搜索,做很简单的一些根据 id 或者范围进行查询的这么一个操作就可以了。从 es 中根据 name 和 age 去搜索,拿到的结果可能就 20 个 doc id,然后根据 doc id 到 hbase 里去查询每个 doc id 对应的完整的数据,给查出来,再返回给前端。 写入 es 的数据最好小于等于,或者是略微大于 es 的 filesystem cache 的内存容量。然后你从 es 检索可能就花费 20ms,然后再根据 es 返回的 id 去 hbase 里查询,查 20 条数据,可能也就耗费个 30ms,可能你原来那么玩儿,1T 数据都放 es,会每次查询都是 5~10s,现在可能性能就会很高,每次查询就是 50ms。 数据预热 假如说,哪怕是你就按照上述的方案去做了,es 集群中每个机器写入的数据量还是超过了 filesystem cache 一倍,比如说你写入一台机器 60G 数据,结果 filesystem cache 就 30G,还是有 30G 数据留在了磁盘上。 其实可以做数据预热。 举个例子,拿微博来说,你可以把一些大V,平时看的人很多的数据,你自己提前后台搞个系统,每隔一会儿,自己的后台系统去搜索一下热数据,刷到 filesystem cache 里去,后面用户实际上来看这个热数据的时候,他们就是直接从内存里搜索了,很快。 或者是电商,你可以将平时查看最多的一些商品,比如说 iphone 8,热数据提前后台搞个程序,每隔 1 分钟自己主动访问一次,刷到 filesystem cache 里去。 对于那些你觉得比较热的、经常会有人访问的数据,最好做一个专门的缓存预热子系统,就是对热数据每隔一段时间,就提前访问一下,让数据进入 filesystem cache 里面去。这样下次别人访问的时候,性能一定会好很多。 冷热分离 es 可以做类似于 mysql 的水平拆分,就是说将大量的访问很少、频率很低的数据,单独写一个索引,然后将访问很频繁的热数据单独写一个索引。最好是将冷数据写入一个索引中,然后热数据写入另外一个索引中,这样可以确保热数据在被预热之后,尽量都让他们留在 filesystem os cache 里,别让冷数据给冲刷掉。 你看,假设你有 6 台机器,2 个索引,一个放冷数据,一个放热数据,每个索引 3 个 shard。3 台机器放热数据 index,另外 3 台机器放冷数据 index。然后这样的话,你大量的时间是在访问热数据 index,热数据可能就占总数据量的 10%,此时数据量很少,几乎全都保留在 filesystem cache 里面了,就可以确保热数据的访问性能是很高的。但是对于冷数据而言,是在别的 index 里的,跟热数据 index 不在相同的机器上,大家互相之间都没什么联系了。如果有人访问冷数据,可能大量数据是在磁盘上的,此时性能差点,就 10% 的人去访问冷数据,90% 的人在访问热数据,也无所谓了。 document 模型设计 对于 MySQL,我们经常有一些复杂的关联查询。在 es 里该怎么玩儿,es 里面的复杂的关联查询尽量别用,一旦用了性能一般都不太好。 最好是先在 Java 系统里就完成关联,将关联好的数据直接写入 es 中。搜索的时候,就不需要利用 es 的搜索语法来完成 join 之类的关联搜索了。 document 模型设计是非常重要的,很多操作,不要在搜索的时候才想去执行各种复杂的乱七八糟的操作。es 能支持的操作就那么多,不要考虑用 es 做一些它不好操作的事情。如果真的有那种操作,尽量在 document 模型设计的时候,写入的时候就完成。另外对于一些太复杂的操作,比如 join/nested/parent-child 搜索都要尽量避免,性能都很差的。 分页性能优化 es 的分页是较坑的,为啥呢?举个例子吧,假如你每页是 10 条数据,你现在要查询第 100 页,实际上是会把每个 shard 上存储的前 1000 条数据都查到一个协调节点上,如果你有个 5 个 shard,那么就有 5000 条数据,接着协调节点对这 5000 条数据进行一些合并、处理,再获取到最终第 100 页的 10 条数据。 分布式的,你要查第 100 页的 10 条数据,不可能说从 5 个 shard,每个 shard 就查 2 条数据,最后到协调节点合并成 10 条数据吧?你必须得从每个 shard 都查 1000 条数据过来,然后根据你的需求进行排序、筛选等等操作,最后再次分页,拿到里面第 100 页的数据。你翻页的时候,翻的越深,每个 shard 返回的数据就越多,而且协调节点处理的时间越长,非常坑爹。所以用 es 做分页的时候,你会发现越翻到后面,就越是慢。 我们之前也是遇到过这个问题,用 es 作分页,前几页就几十毫秒,翻到 10 页或者几十页的时候,基本上就要 5~10 秒才能查出来一页数据了。 有什么解决方案吗? 不允许深度分页(默认深度分页性能很差) 跟产品经理说,你系统不允许翻那么深的页,默认翻的越深,性能就越差。 类似于 app 里的推荐商品不断下拉出来一页一页的 类似于微博中,下拉刷微博,刷出来一页一页的,你可以用 scroll api,关于如何使用,自行上网搜索。 scroll 会一次性给你生成所有数据的一个快照,然后每次滑动向后翻页就是通过游标 scroll_id 移动,获取下一页下一页这样子,性能会比上面说的那种分页性能要高很多很多,基本上都是毫秒级的。 但是,唯一的一点就是,这个适合于那种类似微博下拉翻页的,不能随意跳到任何一页的场景。也就是说,你不能先进入第 10 页,然后去第 120 页,然后又回到第 58 页,不能随意乱跳页。所以现在很多产品,都是不允许你随意翻页的,app,也有一些网站,做的就是你只能往下拉,一页一页的翻。 初始化时必须指定 scroll 参数,告诉 es 要保存此次搜索的上下文多长时间。你需要确保用户不会持续不断翻页翻几个小时,否则可能因为超时而失败。 除了用 scroll api,你也可以用 search_after 来做,search_after 的思想是使用前一页的结果来帮助检索下一页的数据,显然,这种方式也不允许你随意翻页,你只能一页页往后翻。初始化时,需要使用一个唯一值的字段作为 sort 字段。 往期回顾: 【Java问答学堂】1期 为什么使用消息队列?消息队列有什么优点和缺点?Kafka、ActiveMQ、RabbitMQ、RocketMQ 都有什么区别,以及适合哪些场景? 【Java问答学堂】2期 如何保证消息队列的高可用? 【Java问答学堂】3期 如何保证消息不被重复消费?或者说,如何保证消息消费的幂等性? 【Java问答学堂】4期 如何保证消息的可靠性传输?(如何处理消息丢失的问题?) 【Java问答学堂】5期 如何保证消息的顺序性? 【Java问答学堂】6期 如何解决消息队列的延时以及过期失效问题? 【Java问答学堂】7期 如果让你写一个消息队列,该如何进行架构设计? 【Java问答学堂】8期 es 的分布式架构原理能说一下么(es 是如何实现分布式的啊)? 【Java问答学堂】9期 es 写入数据的工作原理是什么啊?es 查询数据的工作原理是什么啊?
剑曼红尘 2020-04-28 14:17:05 0 浏览量 回答数 0

云产品推荐

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