首页 文章 精选 留言 我的

精选列表

搜索[脑洞落地],共10000篇文章
优秀的个人博客,低调大师

驻马店市大数据云计算中心项目落地实施

11月18日,驻马店市人民政府与中国移动河南有限公司举行驻马店市大数据云计算中心建设战略合作协议签约仪式。驻马店市委书记余学友出席仪式,向双方合作项目顺利签约表示祝贺。驻马店市委副书记、市长陈星,中国移动河南有限公司党委书记、总经理魏明分别致辞。 驻马店市委常委、市委秘书长李国胜主持签约仪式。驻马店副市长王明威,中国移动河南有限公司党委委员、副总经理余谦代表双方签约。中国移动河南有限公司党委委员、财务部总经理白涛,以及河南移动有关部门、各县区和市直有关方面负责人等出席签约仪式。 陈星在致辞中说,这次签约启动驻马店市大数据云计算中心建设,是驻马店市抢抓国家大数据产业发展机遇,着力打造大数据云计算产业链,助推经济社会转型升级,提升城市综合竞争力的重大举措,也标志着市政府与河南移动战略合作进入更高层次、更宽领域的全新阶段。当前,大数据产业已经成为推动经济转型发展的新动力,也是重塑城市竞争优势的新机遇,更是提升政府治理能力的新途径。这次双方成功签约,对于推动驻马店市大数据产业发展,提升产业发展层次,提高城市管理水平,改善居民生活条件,具有非常重要的意义,也必将为全市经济社会发展注入新活力。希望河南移动在资金、技术、人才等方面持续加大力度,努力构建双方合作发展的新模式、新机制,在互利共赢中实现共同发展。我们将一如既往优化发展环境,搞好协作服务,全力支持河南移动事业发展,推动双方合作项目尽快建成,尽早发挥效益。 魏明在致辞中说,当前,恰逢驻马店市委、市政府带领全市人民奋力开创“十三五”良好开局的关键时期。我们非常荣幸能够与驻马店携手开启大数据云计算中心建设,不断深化新技术、新业务在各个领域的应用,持续推进传统产业升级改造和新兴产业培育壮大。我们相信,借助河南移动智慧城市建设平台,加大“政务云”、“民生云”、“企业云”、“农业云”、“物联网云”在各行业的广泛应用,一定会为促进全市经济社会跨越式发展产生积极而深远的影响。河南移动将充分发挥企业在网络、技术、业务、服务上的领先优势,以及人力、物力、财力等方面的资源优势,高标准、高品质地完成驻马店大数据云计算中心建设任务,为“一核两轴三区四个驻马店”建设作出更大的贡献。 据悉,驻马店市大数据云计算中心项目,是市政府与河南移动实施优势互补、资源共享,加快推进信息化发展的重大举措。项目将面向政务、民生、农业、企业、物联网五个社会主体,加快智慧型政务、教育、医疗、交通、环保、旅游、社区、公共服务、居家生活、城市管理等领域建设,推动信息资源整合共享与云计算产业发展有机结合,实现全市政务系统资源的统一管理服务,为创造良好的投资环境、优化产业结构、推进驻马店信息化建设提供坚实的支撑。 本文转自d1net(转载)

优秀的个人博客,低调大师

窄带物联网建设加快落地产业链迎来重大机遇

日前,中国移动在江西鹰潭建成全国首个地级市全域覆盖的窄带物联网(NB-IoT),同时实现了业务终端与物联网平台的双向数据传输,表明鹰潭窄带物联网已具备业务使用功能。而中国电信也发布“NB-IoT(窄带物联网)企业标准”,并启动了广东、江苏等7省12市的大规模外场实验,计划上半年完成;中国联通则于去年11月在广东开通了首个标准化NB-IoT商用网络,并在上海迪士尼乐园进行了大规模NB-IoT外场启动实验,为游客提供实时停车位信息等服务。随着三大运营商NB-IoT商用步伐的加快,产业链迎来重大发展机遇,一批设备商、芯片商、终端厂商将先后受益。 业内人士指出,基于NB-IoT大容量、广覆盖、低功耗、低成本等优势,该项技术适用于智慧城市、智能化产品等诸多领域,有望涌现大量的创新业务或解决方案,整体市场规模有望达到万亿元级。国际咨询机构埃森哲的研究报告显示,到2030年,物联网将为中国额外创造1.8万亿美元的累计GDP增长。尽管NB-IoT产业链尚处于起步阶段,但一些领先的企业已在该领域抢跑。 据悉,华为、中兴通讯的NB-IoT芯片将分别于今年一、二季度量产;而基于对基站、天线等硬件的升级要求,通宇通讯、顺络电子等相关元器件制造商也争相发力;在终端层面,三川智慧等仪器仪表商、乐心医疗等可穿戴设备商的终端产品均已进入测试或试用阶段,高新兴也通过收购中兴物联加快在物联网领域的布局。 商用部署提速,相关企业抢跑 芯片是NB-IoT的核心,全球主要的芯片设计公司早已投入研发。目前有三类芯片公司涉足NB-IoT领域。一是通信芯片公司,如高通、华为、中兴等;二是计算芯片公司,如Intel等;三是无线芯片公司,如Nordic、Qorvo等。其中,Qorvo专门用于NB-IoT的PA模组将于二季度供货,爱立信、高通也在积极研发相关产品。 在NB-IoT领域,华为等国内厂商的步伐暂时领先。华为海思高级分析师王治国透露,华为首款商用NB-IoT芯片将于今年一季度正式量产。此前,中兴微电子相关人员表示,将于今年二季度发布NB-IoT商用芯片Wisefone7100;紫光旗下的锐迪科表示,其NB-IoT产品将于三季度量产。 在下游终端方面,目前,包括仪表公司、可穿戴设备公司等在内的几十家终端商都在参与华为NB-IoT芯片的合作和测试。 在业内人士看来,华为NB-IoT芯片的量产,将会加快其他公司在该领域的研发。“华为将包括芯片设计在内的全产业链研发走了一遍,其芯片计划一季度量产,那么其他厂家借鉴华为的研发经验,半年到一年时间后,也将迎来芯片量产。” 例如先锋电子1月19日公告,其首台NB-IoT物联网智能燃气表在上海正式安装并上线试运行,该设备可实现正常用气数据抄收、异常事件上报等功能。另外,高新兴通过收购中兴物联推进其“公共安全+物联网”战略。 产业链尚未成熟,瓶颈亟待突破 尽管全产业链已经在“加油干”,但业内专家指出,NB-IoT产业链尚未完全成熟,商用路上,还有诸多瓶颈亟待突破。 首先,芯片还是产业瓶颈。到目前为止,真正能够量产NB-IoT芯片的只有华为一家。在某IC设计公司NB-IoT研发负责人看来,NB-IoT芯片虽小,但低功耗要求设计非常复杂。比如,为满足两节干电池工作十年的能耗指标,NB-IoT芯片既要采用休眠唤醒模式,又要做到全面的蜂窝数据连接覆盖,难度可想而知。 其次,成本是制约产业发展的另一大障碍。目前的NB-IoT芯片尚不能满足低成本要求。华为公司有关人士认为,如果想刺激NB-IoT大规模发展,通信模块单个成本必须低于5美元;如果成本降低到1美元以内,则会带来爆发式增长。目前,紫光旗下的锐迪科已提出“模块成本1美元”的目标。 另外,产业链的协同也成为发展瓶颈。物联网是碎片化、使用场景多元化的市场,除了三大运营商的NB-IoT网络建设与运营需要有统一的“顶层规划”外,物联网产业发展与行业主管部门的计划、政策密切相关,尚需要更加明确、协同性更强的政策导向,以及企业、行业间的密切合作。 本文转自d1net(转载)

优秀的个人博客,低调大师

独家|阿里巴巴创新中心落地贵州省贵安新区

5月24日,在贵阳举行的数博会上,贵州省贵安新区与阿里云签约,宣布将在当地开设阿里巴巴创新中心(贵安新区),依托双方在高校资源、科技创新等方面的优势,共同推动当地创新创业发展。 阿里云战略资深总监李树翀与贵安新区政府代表进行签约 作为国务院首批28个双创示范基地中的区域示范基地和企业示范基地,贵安新区和阿里云的合作备受关注。双方将基于各自的资源优势和区域特点,发挥在推动创新企业发展中的作用,利用新技术来推动新产品、新业态、新模式进步。 阿里巴巴创新中心(贵安新区)将由双方共同合作,以创新中心为窗口,引入云计算大数据等技术资源,构建云端创新创业生态体系,推进云计算大数据及移动互联网产业在贵安新区的集聚发展,提升本地云计算大数据能力,并推动科技类中小企业上云,有效降低企业IT成本,将创新中心打造成示范项目。 除此之外,双方还将共建互联网+教育

优秀的个人博客,低调大师

大数据在企业运营中可落地的八大应用

1、消费者需求分析 很多企业管理者都意识到了消费者再也不是营销产品的被动接收器了,通过大数据来了解并设计消费者的需求的产品,可能是我们所有企业都应该去考虑的第一个大数据的生产应用场景。 借助大数据,我们对采集来的企业内部(内源数据),例如销售网点的数据,消费者直接反馈等,与外部数据(外源数据),例如社交媒体的评论,描述产品用途的传感器数据等,通过微观细分,情感分析,消费者行为分析以及基于位置的营销等手段,让我们企业“擦亮眼睛”,摸清消费者的需求,彻底改变曾经那种“跟者感觉走”的状态,走出直觉猜测消费者的需求的局面。 企业由此迫切需要建立利用内源数据以及外源数据的机制,全渠道了解消费者的需求,使用多重分析法,例如联合分析法,来确定消费者对与产品某种特点的支付意愿,了解使产品抢占市场的重要产品特征,从而改善产品设计,为产品提供相应的改造升级的明确方向和规格参数。 2、打通生产竖井 竖井有两层含义。 首先是信息和数据的孤岛。传统行业经历了过去20年的信息化建设,形成了大量的,种类繁多的大型应用。每个应用系统都有自己的数据,与组织结构的竖井相辅相成,逐步形成了我们今天看到的信息独岛。 其次, 竖井是对于组织部门的一种比喻,这种组织部门有自己的管理团队和人才,但缺乏与其他组织单位合作或交流的动机与需求。跨越竖井是当代企业营销面临的重大挑战之一。重塑企业架构是必由之路。我们必须改变妨碍消费者体验的组织结构,建立基于消费者的意愿,去改变组织结构,去影响消费者与品牌打交道的方式。通过接触其他文化、改变先前的设想,并且要去除联想障碍,来实现各渠道创造无缝体验。 大数据的先进架构,例如大数据湖,可以让跨部门,跨公司,跨地域,甚至跨行业的相关组织,在共同遵循的数据治理框架下,产品设计者与制造工程师可以共享数据,模拟实验以测试不同的产品设计,部件与相应供应商的选择,并计算出相关的成本,以促进产品设计,测试。实现信息与情报的融通。 3、产品与服务的设计 产品可以分为有形产品和无形产品。 生产型企业生产的多为有形产品, 而服务型企业生产的多为无形的产品。无论有形,无形或是把产品服务化的企业,其最终的目的都是以通过服务来增加利润,并且在同质化竞争中体现差异性。 产品设计是明确企业产品性质与特点的过程,这个过程复杂且代价高。生产成本的80%左右是受到了产品设计阶段的决策影响。因此,如何提升产品设计的决策是所有企业家和管理者的共同挑战。 我们在设计并且生产出消费着需要的产品的旅程中发现, 产品的设定和生产要素,跟流程、工艺、市场,消费习惯,销售策略,区域,气候等等都有千丝万缕的关系,数字化能够帮我把这个轮廓勾勒出来。利用大数据的实时数据分析,将数字勾勒出来的消费者偏好转化成为有形的产品特点,利用数据设计产品,实现研发与运营共享数据,共同参与产品设计的改进和调整。 4 、开放式的融合创新 Web 2.0的出现和广泛流行至今,深远地影响了用户使用互联网的方式。互联网,移动通信网以及物联网是当今最具影响力的三个全球性网络,移动互联网恰恰融合了前两者的发展优势,而物联网传感器数据则使得创新型售后服务成为可能。现在,人们越来越习惯从互联网上获取所需的应用与服务。 供应商,消费者,第三方机构等与此同时将自己的数据在网络上共享与保存,不仅仅会通过全渠道征求消费者意见,还与学术或行业研究者合作开发新产品。通过互联网平台来为企业创新出谋划策,与其合作研发产品。Web 2.0时代不单单提供了云计算的接入模式,也为云计算培养了用户习惯。大数据为生产型企业提供创新服务乃至建立新型商业模型提供了历史性的机会。 5、适应性库存管理 总所周知,库存成本往往占了产品成本的50%,过多的库存会造成过高的库存管理成本。与此同时,库存的多少似乎永远也无法解决商品的脱销。无论是库存量还是脱销量,企业在发展过程中,都希望利用信息化手段,能够通过实时跟踪货物,采集数据,确定不同地区在不同时间的库存水平,使得库存水平具有适应性。 运用大数据使得供应与需求信号紧密联系在一起变得容易实现和具有可操作性。我们可以把销售记录,销售网点数据,天气预报,季节性销售周期,区域库存信息等不同纬度的数据融合起来,形成实时感应需求信号,与实时货物位置等信息能关联分析,匹配供求关系。产生的精确的信息,可以反馈到生产计划,库存水平与订单量等库存计算的各个环节, 使企业了解具体地区的库存量并且自动生成订单,从“需求感应”实现“适应性的库存”管理,不断优化库存水平。 6、质量管理 早在上世纪90年代开始,大量的企业就开始通过应用分析法来提高产品质量和生产的效率,其核心是实现生产与服务的需求相匹配。今天的大数据分析手段也是如出一辙。大数据不仅能够使生产商制造产品的时间缩短20%-50%,还能够在产品批量生产前通过模拟,检验防止产品缺陷,减少产品开发周期过程中不必要的环节等。 质量管理强调产品质量要符合消费者预期,这个预期包括预算,功能,外观等等。这是大数据分析法提升质量管理环节的首要收益。通过对内源与外源数据的实时采集和分析,企业能够准确地了解消费者需求以及购买行为,明确产品特征,运用高级分析法准确地指导生产,运输与采购以提升产品或服务的质量。 大数据的实时性与实效性,給企业的生产质量管理提供了质的飞跃。传统质量管理主要是通过静态的,历史的,沉淀的数据,通过检查表,散点图,控制图等检测手段,来发现生产过程的质量问题大数据通过物联网,通过产品上安装传感器,标签等手段,实时监测采集数据,认知产品性能,实时提高质量。 7、劳动力的数字化 劳动力是除了产品成本外,企业最重视的开支。而且,问题的复杂程度也是最大的。 问题除了员工本身之外,有很大一部分问题与管理水平低下有关,管理者不因只强调员工的问题,而忽略自身和机制的问题,特别是在零售,分销,加工等这些劳动密集型企业,劳动力问题尤为突现。 任何一个组织,应该通过有效的科技信息手段,快速建立认知,基于组织的行为和文化标准,提高一致性和我们从雇佣的质量,继任计划,以及到员工的成长进程的全人才生命周期的管理。通过大数据方式,找到进行员工调度的最佳模式,缩短管理时间,实现技能与岗位的周期匹配,劳动力效率最优化。让劳动力的管理成为可预测的,且基于分析学的方法来实现人才资源的管理。这样的方法一是客观,二是从大数据统计的角度将员工的绩效指标和行为特征连接了起来,为每个企业创造了一个“最适合”的劳动力模式。 大数据在帮助企业生产实现需求预测的精确性,对提高员工调度效率起这非常重要的作用,这又进一步说明了在销售环节获取的数据是如何影响生产环节决策的。由此給组织带来提供卓越的客户体验,更高的生产率,更高的销售增长,和更广泛的利润空间。这一切都源自于100%数据驱动的,尽可能避免主观判断和推测。 8、资产智能管理 物联网(IOT)的发展以及感应技术的兴起,为我们开创了一个能紧密连接物理空间许多事物的信息网络。随着大数据分析技术的发展,特别是预测分析的发展,结合互联网云化的广泛应用,物理空间与虚拟信息空间的形成与同步,离不开设备的自我意识和自主维修机械系统。 智能设备的未来,一定是能够自主评估健康状况和退化情况并主动预防潜在性能故障,并且做出维修决策,以避免潜在故障的系统。要实现健康条件评估,就需要利用数据驱动算法分析从机械设备及其周边环境中的数据。实时设备条件信息可反馈至机械控制器以实现自适应控制,同时信息也会反馈至设备管理人员方便及时维修。操作员可根据每台设备的健康条件平衡和调节每台设备工作量和工作压力,从而最大程度优化生产和设备性能,实现主动检修计划的智能决策。 本文转自d1net(转载)

优秀的个人博客,低调大师

唱吧DevOps的落地,微服务CI/CD的范本技术解读

1、业务架构:从单体式到微服务 K歌亭是唱吧的一条新业务线,旨在提供线下便捷的快餐式K歌方式,用户可以在一个电话亭大小的空间里完成K歌体验。K歌亭在客户端有VOD、微信和Web共三个交互入口,业务复杂度较高,如长连接池服务、用户系统服务、商户系统、增量更新服务、ERP等。对于服务端的稳定性要求也很高,因为K歌亭摆放地点不固定,很多场所的运营活动会造成突发流量。 为了快速开发上线,K歌亭项目最初采用的是传统的单体式架构,但是随着时间的推移,需求的迭代速度变得很快,代码冗余变多,经常会出现牵一发动全身的改动。重构不但会花费大量的时间,而且对运维和稳定性也会造成很大的压力;此外,代码的耦合度高,新人上手较困难,往往需要通读大量代码才不会踩进坑里。 鉴于上述弊端,我们决定接下来的版本里采用微服务的架构模型。从单体式结构转向微服务架构中会持续碰到服务边界划分的问题:比如,我们有user服务来提供用户的基础信息,那么用户的头像和图片等是应该单独划分为一个新的service更好还是应该合并到user服务里呢?如果服务的粒度划分的过粗,那就回到了单体式的老路;如果过细,那服务间调用的开销就变得不可忽视了,管理难度也会指数级增加。目前为止还没有一个可以称之为服务边界划分的标准,只能根据不同的业务系统加以调节,目前K歌亭拆分的大原则是当一块业务不依赖或极少依赖其它服务,有独立的业务语义,为超过2个的其他服务或客户端提供数据,那么它就应该被拆分成一个独立的服务模块。 在采用了微服务架构之后,我们就可以动态调节服务的资源分配从而应对压力、服务自治、可独立部署、服务间解耦。开发人员可以自由选择自己开发服务的语言和存储结构等,目前整体上使用PHP做基础的Web服务和接口层,使用Go语言来做长连接池等其他核心服务,服务间采用thrift来做RPC交互。 2、系统架构的构思与解读 2.1 容器编排 唱吧K歌亭的微服务架构采用了Mesos和Marathon作为容器编排的工具。在我们选型初期的时候还有三个其他选择,Kubernetes、 Swarm、 DC/OS: DC/OS:作为Mesosphere公司的拳头产品,基本上是希望一统天下的节奏。所以组件很多,功能也很全面。但是对于我们在进行微服务架构初期,功能过于庞大,学习成本比较高,后期的生产环境维护压力也比较大。 Swarm:Docker公司自己做的容器编排工具,当时了解到100个以上物理节点会有无响应的情况,对于稳定性有一些担忧。 Kubernetes:Google开源的的容器编排工具,在选型初期还没有很多公司使用的案例,同时也听到了很多关于稳定性的声音,所以没有考虑。但是在整个2016年,越来越多的公司开始在线上使用Kubernetes,其稳定性逐步提高,如果再选型应该也是个好选择。 Mesos:因为了解到Twitter已经把Mesos用于生产环境,并且感觉架构和功能也相对简单,所以最后选择了Mesos+Marathon作为容器编排的工具。 2.2 服务发现 我们采用了etcd作为服务发现的组件,etcd是一个高可用的分布式环境下的 key/value 存储服务。在etcd中,存储是以树形结构来实现的,非叶结点定义为文件夹,叶结点则是文件。我们约定每个服务的根路径为/v2/keys/service/$service_name/,每个服务实例的实际地址则存储于以服务实例的uuid为文件名的文件中,比如账户服务account service当前启动了3个可以实例,那么它在etcd中的表现形式则如下图: 当一个服务实例向etcd写入地址成功时我们就可以认为当前服务实例已经注册成功,那么当这个服务实例由于种种原因down掉了之后,服务地址自然也需要失效,那么在etcd中要如何实现呢? 注意,图中的每个文件有一个ttl值,单位是秒,当ttl的值为0时对应的文件将会被etcd自动删除。当每个服务实例启动之后第一次注册时会把存活时间即ttl值初始化为10s,然后每隔一段时间去刷新ttl,用来像向etcd汇报自己的存活,比如7s,在这种情况下基本上可以保证服务有效性的更新的及时性。如果在一个ttl内服务down掉了,则会有10s钟的时间是服务地址有效;而服务本身不可用,这就需要服务的调用方做相应的处理,比如重试或这选择其它服务实例地址。 我们服务发现的机制是每个服务自注册,即每个服务启动的时候先得到宿主机器上面的空闲端口;然后随机一个或多个给自己并监听,当服务启动完毕时开始向etcd集群注册自己的服务地址,而服务的使用者则从etcd中获取所需服务的所有可用地址,从而实现服务发现。 同时,我们这样的机制也为容器以HOST的网络模式启动提供了保证。因为BRIDGE模式确实对于网络的损耗太大,在最开始就被我们否决了,采用了HOST模式之后网络方面的影响确实不是很大。 2.3 监控,日志与报警 我们选择Prometheus汇总监控数据,用ElasticSearch汇总日志,主要的原因有: 生态相对成熟,相关文档很全面,从通用的到专用的各种exporter也很丰富。 查询语句和配置简单易上手。 原生具有分布式属性。 所有组件都可以部署在Docker容器内。 Mesos Exporter,是Prometheus开源的项目,可以用来收集容器的各项运行指标。我们主要使用了对于Docker容器的监控这部分功能,针对每个服务启动的容器数量,每个宿主机上启动的容器数量,每个容器的CPU、内存、网络IO、磁盘IO等。并且本身他消耗的资源也很少,每个容器分配0.2CPU,128MB内存也毫无压力。 在选择Mesos Exporter之前,我们也考虑过使用cAdvisor。cAdvisor是一个Google开源的项目,跟Mesos Exporter收集的信息八成以上都是类似的;而且也可以通过image字段也可以变相实现关联服务与容器,只是Mesos exporter里面的source字段可以直接关联到marathon的application id,更加直观一些。同时cAdvisor还可以统计一些自定义事件,而我们更多的用日志去收集类似数据,再加上Mesos Exporter也可以统计一些Mesos本身的指标,比如已分配和未分配的资源,所以我们最终选择了Mesos Exporter。 如下图,就是我们监控的部分容器相关指标在Grafana上面的展示: Node exporter,是Prometheus开源的项目,用来收集物理机器上面的各项指标。之前一直使用Zabbix来监控物理机器的各项指标,这次使用NodeExporter+Prometheus主要是出于效率和对于容器生态的支持两方面考虑。时序数据库在监控数据的存储和查询的效率方面较关系数据库的优势确实非常明显,具体展示在Grafana上面如下图: Filebeat是用来替换Logstash-forwarder的日志收集组件,可以收集宿主机上面的各种日志。我们所有的服务都会挂载宿主机的本地路径,每个服务容器的会把自己的GUID写入日志来区分来源。日志经由ElasticSearch汇总之后,聚合的Dashboard我们统一都会放在Grafana上面,具体排查线上问题的时候,会用Kibana去查看日志。 Prometheus配置好了报警之后可以通过AlertManager发送,但是对于报警的聚合的支持还是很弱的。在下一阶段我们会引入一些Message Queue来自己的报警系统,加强对于报警的聚合和处理。 ElastAlert是Yelp的一个Python开源项目,主要的功能是定时轮询ElasticSearch的API来发现是否达到报警的临界值,它的一个特色是预定义了各种报警的类型,比如frequency、change、flatline、cardinality等,非常灵活,也节省了我们很多二次开发的成本。 2.4 事务追踪系统——KTrace 对于一套微服务的系统结构来说,最大的难点并不是实际业务代码的编写,而是服务的监控和调试以及容器的编排。微服务相对于其他分布式架构的设计来说会把服务的粒度拆到更小,一次请求的路径层级会比其他结构更深,同一个服务的实例部署很分散,当出现了性能瓶颈或者bug时如何第一时间定位问题所在的节点极为重要,所以对于微服务来说,完善的trace机制是系统的核心之一。 目前很多厂商使用的trace都是参考2010年Google发表的一篇论文《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure》来实现的,其中最著名的当属twitter的zipkin,国内的如淘宝的eagle eye。由于用户规模量级的逐年提升,分布式设计的系统理念越来越为各厂商所接受,于是诞生了trace的一个实现标准opentracing ,opentracing标准目前支持Go、JavaScript、Java、Python、Objective-C、C++六种语言。 由sourcegraph开源的appdash是一款轻量级的,支持opentracing标准的开源trace组件,使用Go语言开发K歌亭目前对appdash进行了二次开发,并将其作为其后端trace服务(下文直接将其称之为Ktrace),主要原因是appdash足够轻量,修改起来比较容易。唱吧K歌亭业务的胶水层使用PHP来实现,appdash提供了对protobuf的支持,这样只需要我们自己在PHP层实现middleware即可。 在trace系统中有如下几个概念 (1)Annotation 一个annotation是用来即时的记录一个事件的发生,以下是一系列预定义的用来记录一次请求开始和结束的核心annotation cs - Client Start。 客户端发起一次请求时记录 sr - Server Receive。 服务器收到请求并开始处理,sr和cs的差值就是网络延时和时钟误差 ss - Server Send: 服务器完成处理并返回给客户端,ss和sr的差值就是实际的处理时长 cr - Client Receive: 客户端收到回复时建立。 标志着一个span的结束。我们通常认为一但cr被记录了,一个RPC调用也就完成了。 其他的annotation则在整个请求的生命周期里建立以记录更多的信息 。 (2)Span 由特定RPC的一系列annotation构成Span序列,span记录了很多特定信息如 traceId, spandId, parentId和RPC name。 Span通常都很小,例如序列化后的span通常都是kb级别或者更小。 如果span超过了kb量级那就会有很多其他的问题,比如超过了kafka的单条消息大小限制(1M)。 就算你提高kafka的消息大小限制,过大的span也会增大开销,降低trace系统的可用性。 因此,只存储那些能表示系统行为的信息即可。 (3)Trace 一个trace中所有的span都共享一个根span,trace就是一个拥有共同traceid的span的集合,所有的span按照spanid和父spanid来整合成树形,从而展现一次请求的调用链。 目前每次请求由PHP端生成traceid,并将span写入Ktrace,沿调用链传递traceid,每个service自己在有需要的地方埋点并写入Ktrace。举例如下图: 每个色块是一个span,表明了实际的执行时间,通常的调用层级不会超过10,点击span则会看到每个span里的annotation记录的很多附加信息,比如服务实例所在的物理机的IP和端口等,trace系统的消耗一般不会对系统的表现影响太大,通常情况下可以忽略,但是当QPS很高时trace的开销就要加以考量,通常会调整采样率或者使用消息队列等来异步处理。不过,异步处理会影响trace记录的实时性,需要针对不同业务加以取舍。 目前K歌亭在生产环境里的QPS不超过1k,所以大部分的记录是直接写到ktrace里的,只有歌曲搜索服务尝试性的写在kafka里,由mqcollector收集并记录,ktrace的存储目前只支持MySQL。一个好的trace设计可以极快的帮你定位问题,判断系统的瓶颈所在。 2.5 自动扩容 在服务访问峰值的出现时,往往需要临时扩容来应对更多的请求。除了手动通过Marathon增加容器数量之外,我们也设计实现了一套自动扩缩容的系统来应对。我们扩缩容的触发机制很直接,根据各个服务的QPS、CPU占用、内存占用这三个指标来衡量,如果三个指标有两个指标达到,即启动自动扩容。我们的自动扩容系统包括3个模块: Scout:用于从各个数据源取得自动扩容所需要的数据。由于我们的日志全部都汇总在ElasticSearch里面,容器的运行指标都汇总到Prometheus里面,所以我们的自动扩容系统会定时的请求二者的API,得到每个服务的实时QPS、CPU和内存信息,然后送给Headquarter。 Headquarter:用于数据的处理和是否触发扩缩容的判断。把从Scout收到的各项数据与本地预先定义好的规则进行比对,如果有两个指标超过定义好的规则,则通知到Signalman模块。 Signalman:用于调用各个下游组件执行具体扩缩容的动作。目前我们只会调用Marathon的/v2/apps/{app_id}接口,去完成对应服务的扩容。因为我们的服务在容器启动之后会自己向etcd注册,所以查询完容器状态之后,扩缩容的任务就完成了。 3、基于Mesos+Marathon的CI/CD 3.1 持续集成与容器调度 在唱吧,我们使用Jenkins作为持续集成的工具。主要原因是我们想在自己的机房维护持续集成的后端,所以放弃了Travis之类的系统。 在实施持续集成的工作过程中,我们碰到了下列问题: Jenkins Master的管理问题。多个团队共享一个Master,会导致权限管理困难,配置改动、升级门槛很高,Job创建和修改有很多规则;每个团队用自己的Master,会导致各个Master之间的插件、更新、环境维护有很多的重复工作。 Jenkins Slave 资源分配不平均:忙时Jenkins slave数量不足,Job运行需要排队;闲时Jenkins Slave又出现空闲,非常浪费资源。 Jenkins job运行需要的环境多种多样,比如我们就有PHP,java,maven,Go,python等多种编译运行环境,搭建和维护slave非常费时。 多个开发人员的同时提交,各自的代码放到各自独立的测试环境进行测试。 基于以上问题,我们选择使用Mesos和Marathon来管理Jenkins集群,把Jenkins Master和Jenkins Slave都放到Docker容器里面,可以非常有效的解决以上问题。基础架构如下图: 不同开发团队之间使用不同的Jenkins Master。把公用的权限、升级、配置和插件更新到私有Jenkins Master镜像里面,推到私有镜像仓库,然后通过Marathon部署新的Master镜像,新团队拿到的Jenkins Master就预安装好了各种插件,各个现有团队可以无缝接收到整体Jenkins的升级。 各种不同环境的Jenkins Slave,做成Slave镜像。按照需要,可以通过Swarm Plugin自动注册到Jenkins master,从而组织成slave pool的形式;也可以每个job自己去启动自己的容器,然后在容器里面去执行任务。 Jenkins job从容器调度的角度分成两类,如下图: 环境敏感型:比如编译任务,需要每次编译的环境完全干净,我们会从镜像仓库拉取一个全新的镜像启动容器,去执行Job,然后再Job执行完成之后关闭容器。 时间敏感型:比如执行测试的Job,需要尽快得到测试结果,但是测试机器的环境对于测试结果没什么影响,我们就会从已经启动好的Slave Pool里面去拉取一个空闲的Slave去执行Job。然后再根据Slave被使用的频率去动态的扩缩容Slave pool的大小就好了。 3.2 CI/CD流程 基于上述的基础架构,我们定义了我们自己的持续集成与持续交付的流程。其中除了大规模使用Jenkins与一些自定制的Jenkins插件之外,我们也自己研发了自己的部署系统——HAWAII。 在HAWAII中可以很直观的查看各个服务与模块的持续集成结果,包括最新的版本,SCM revision,测试结果等信息,然后选择相应的版本去部署生产环境。 在部署之前,可以查看详细的测试结果和与线上版本的区别,以及上线过程中的各个步骤运行的状态。 基于上述基础架构,我们的CI/CD流程如下: SVN或者GIT收到新的代码提交之后,会通过hook启动相应的Jenkins job,触发整个CI流程。 Jenkins从私有镜像仓库拉取相对应的编译环境,完成代码的编译。 Jenkins从私有镜像仓库拉取相对应的运行时环境,把上一步编译好的产品包打到镜像里面,并生成一个新版本的产品镜像。产品镜像是最终可以部署到线上环境的镜像,该镜像的metadata也会被提交到部署系统HAWAII,包括GUID,SCM revision,Committer,时间戳等信息 将步骤3中生成的产品镜像部署到Alpha环境(该环境主要用于自动化回归测试,实际启动的容器其实是一个完整环境,包括数据容器,依赖的服务等)。 Jenkins从私有镜像仓库拉取相对应的UT和FT的测试机镜像,进行测试。测试完成之后,会销毁Alpha环境和所有的测试机容器,测试结果会保存到部署系统HAWAII,并会邮件通知到相关人员。 如果测试通过,会将第3步生成的产品镜像部署到QA环境,进行一系列更大范围的回归测试和集成测试。测试结果也会记录到HAWAII,有测试不通过的地方会从第1步从头开始迭代。 全部测试通过后,就开始使用HAWAII把步骤3中生成的产品镜像部署到线上环境。 4、小结 随着互联网的高速发展,各个公司都面临着巨大的产品迭代压力,如何更快的发布高质量的产品,也是每个互联网公司都面临的问题。在这个大趋势下,微服务与DevOps的概念应运而生,在低耦合的同时实现高聚合,也对新时代的DevOps提出了更高的技术与理念要求。 这也是我们公司在这个新的业务线上面进行,进行尝试的主要原因之一。对于微服务、容器编排、虚拟化、DevOps这些领域,我们一步一步经历了从无到有的过程,所以很多方面都是本着从满足业务的目标来尽量严谨的开展,包括所有的服务与基础架构都进行了高并发且长时间的压力测试。 在下一步的工作中,我们也有几个核心研究的方向与目标,也希望能跟大家一起学习与探讨: 完善服务降级机制 完善报警机制 完善负载均衡机制 http://kb.cnblogs.com/page/565901/

资源下载

更多资源
Mario

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长,特征是大鼻子、头戴帽子、身穿背带裤,还留着胡子。与他的双胞胎兄弟路易基一起,长年担任任天堂的招牌角色。

Nacos

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称,一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集,帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

Spring

Spring

Spring框架(Spring Framework)是由Rod Johnson于2002年提出的开源Java企业级应用框架,旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念,提供核心容器、应用上下文、数据访问集成等模块,支持整合Hibernate、Struts等第三方框架,其适用范围不仅限于服务器端开发,绝大多数Java应用均可从中受益。

WebStorm

WebStorm

WebStorm 是jetbrains公司旗下一款JavaScript 开发工具。目前已经被广大中国JS开发者誉为“Web前端开发神器”、“最强大的HTML5编辑器”、“最智能的JavaScript IDE”等。与IntelliJ IDEA同源,继承了IntelliJ IDEA强大的JS部分的功能。

用户登录
用户注册