
内容来源:2017年6月24日,腾讯前端高级工程师龚澄在“腾讯Web前端大会 TFC 2017 ”进行《WePY-小程序框架设计》演讲分享。IT大咖说作为独家视频合作方,经主办方和讲者审阅授权发布。 阅读字数:2178 | 4分钟阅读 嘉宾演讲视频回放及PPT,请点击:http://t.cn/Rs3o7vR 摘要 去年11月初,微信小程序开始公测,小程序是一种新的开放能力,开发者可以一用Web相关技术快速开发小程序。这次分享内容包括:小程序开发基础内容;WePY框架说明,为什么要做这个框架以及框架介绍;WePY框架在我们业务开发中的实际应用和经验分享。 小程序基础封闭内测 2016年8月,我们有手机充值、自选股、理财通、信用卡还贷和腾讯体育这五个团队参加了小程序的封闭内测。根据这五个产品形态可以看出小程序的一些特点,它面向的是一种服务,一种轻应用,它还是一种Web开发模式,上手简单。 小程序架构 我们平时做公众号开发或做一些混合应用时,Native层是必须的,在调用一些底层能力的时候,一定会用到JSBridge。 小程序和Web开发最大的区别就在于它的视图层和逻辑层完全分离。 优势与限制 优势: 1、视图操作基于数据绑定。 2、支持模块化。模块化最大的特点就是可以依赖于第三方。 3、丰富的内置组件。 4、登录API获取code,提升用户体验。 5、优秀的系统调用能力。 6、样式支持自适应单位rpx。 限制: 1、无法动态创建视图节点。 2、不支持组件开发。 3、不支持NPM包。 4、页面最多只能打开5层。 5、5个并发网络请求。 6、http特性不完善。 7、无法外跳。 主流框架特性 小程序框架唯一的缺陷就是缺少组件系统,无法支持组件化开发。 组件化开发框架WePYWePY简介 WePY通过预编译手段使小程序支持组件化,类Vue.js风格的开发模式,让开发者可以像普通Web应用一样开发小程序。它是一款Github开源框架。 写过几篇关于WePY的文章,被一些社区转载,然后WePY框架先后被CSDN和开源中国首页推荐。 WePY用户交流群目前大概有1100人左右,并且有用户自发地开发第三方WePY组件。 为什么会有WePY 从开发角度来说,小程序有自己的一套固定的开发模式,我希望用户能够像开发H5一样开发小程序,这是我的初衷。 第二个是框架。一方面是因为小程序不支持组件化,另一方面是因为其它框架有一些比较好的特性在小程序里是没有的。我们想借鉴其它框架的优秀特性,把它们引入到小程序的开发当中去。 小程序出现以后,由于原来的代码无法迁移到小程序,所以需要重新开发一套H5业务,开发者要同时维护两套代码,这是比较令人头疼的问题。 小程序和H5所要实现的功能其实是一样的。我们现在不仅有H5,还有Native端,H5里还包含了微信端、QQ端。我们在考虑是否能有一个适配层,让小程序业务代码运行在微信、手Q甚至是原生APP之上。 小程序开源项目分类 增强库类:开发者对原生小程序进行二次分装,对小程序进行功能补充。 脚手架类:组织项目风格,并且会提供简单的编译打包功能。 预编译类:完全拥有自己的开发模式。 开发模式选型 在框架选型的时候参考了一些网上现有的框架,主要是从单文件组件、轻量级、学习成本低、社区与资源这几点去考虑。 WePY项目代码结构 这是WePY的一个代码对比图。 WePY配套功能 WePY编译过程 首先它拿到的是一个wpy格式文件,通过拆分分成Style、Template和Script。这部分进入编译器通过类型进行编译,生成四个文件,这四个文件会进入插件处理系统,最终生成了index.wxss、index.wxml、index.js、index.json,就是我们真正运行在小程序的文件。 对比 WePY与Web之间的联系小程序与Web 做小程序开发的人一般都会考虑H5代码是否可以无痛转成小程序,但研究发现要做到这一步其实是很难的。 于是我们采取了一个折中的方法,用一份WePY代码去生成不同的类型,让它可以运行在小程序端。对于小程序就生成小程序可以运行的内容,对于Web端就生成Web端可以执行的内容。 小程序转Web时存在的问题 1、小程序的开发模式与Web端的开发模式不一样。 2、标签和样式存在差异。 3、小程序模版中的一些属性或者表达式在Web端原生并不支持。 4、Web原生不支持模块化。 5、小程序包含大量内置组件和API,但Web端并不支持。 开发模式 WePY本身是一种类似于Vue的开发方式,所以它的这套代码完全可以基于Vue运行在浏览器,基于小程序运行在微信端。开发模式通过WePY达到了统一。 标签与样式差异 标签相近可以直接通过替换来实现,但小程序标签有些小程序特有的属性,在Web端没有,所以它的有些标签的处理不是通过替换去做的。 rpx单位在Web端是没有的。rpx是以iPhone6为基础的1334×750的分辨率上,有750个物理像素,默认单位是750rpx,换算时1rpx=0.5px。 模版语法转换 模版语法几乎都是相似的,只有一些特殊语法需要进行转换。 模块打包 这一块我参考了webpack,因为Web端现在模块化打包已经比较成熟了。 首先这里举了一个例子,是模块化引用的关系。在做编译的过程中,我会梳理它的模块依赖关系,给每一个模块做编号。在打包bundle的时候会把它输出到同一个文件的数组里,拆分入口代码去定义wepy_require,再把原有代码中的require改成require数组1,调用数组1就可以了。这是整个模块化打包的原理。 小程序组件与API 因为小程序组件和API在Web端是没有的,所以我们要想办法在Web端去补齐它的这个差异。Web端是基于Vue运行的,可以使用Vue组件去完成它所有的组件。 只需要处理好接口让Vue代码可以直接注入到bundle里,让它可以完美运行。 只要把小程序的所有组件通过Vue实现一遍,那么这部分组件就可以在Web端运行。 基础API完全有能力在Web端实现,还有一部分不能在Web端实现的,比如调用用户属性,可以通过它提供的对应的JS API去实现。微信浏览器和QQ浏览器提供的JS API完全可以实现小程序API这一块,所以就分了两层,第一层是基础层,第二层是适配层。假如代码要运行在QQ端就用wepy-web-qq,这一块就包括了所有API在QQ端的实行。适配层可以让代码运行在不同的浏览器环境。 这里有一个我自己制作的DEMO小程序https://chong.qq.com/mobile/wepy_chong.html,大家可以体验一下。 我今天的分享就到这里,感谢聆听!
内容来源:2017年5月13日,ThoughtWorks AR/VR高级研发工程师陈成在“2017技术雷达峰会|洞察构建未来的技术和趋势”进行《AR,离我们并不遥远》演讲分享。IT大咖说作为独家视频合作方,经主办方和讲者审阅授权发布。阅读字数: 2388 用时: 4分钟 嘉宾演讲视频和PPT地址:http://t.cn/RCZJKAI 头脑风暴 真实的情境 AR项目的头脑风暴一定要在真实情境中去做,因为AR应用是基于现实基于情境的。 只有在真实使用的情境中才能发掘信息,去进行需求收集、用户访谈、用户流程、创意产生等等的这一系列流程。 设备 根据场景需求,基于设备和设备所能提供的API选择设备。 我们的应用可以是2C,供消费者自己使用;可以是2B,在商业环境中给工作人员用;也可能是2B2C,需要工作人员指导消费者在商业场里景使用。 设备可以大致分为手机AR和头戴式AR两大类。 手机AR是用手机摄像头捕捉到真实世界的景象,并在上面叠加虚拟的物品呈现出的AR。 头戴式AR是一个穿戴设备。比如微软推出的HoloLens设备,他们和各行业企业合作推出了很多AR范例应用。 考虑设备能力 内容要由合适的设备来承载和展现。 渲染能力:设备是否具备我们需要的场景复杂度的需求; 续航时间:产品是短时间的应用还是长时间的应用,使用频率是怎样的; 网络能力:是否需要联网; 在室内还是室外; 场景的规模有多大…… 这些都是我们需要考虑的方面,为优化做准备。 原型 纸盒原型 我们用一些纸盒、乐高或者是真实的物品代替,在真实的3D空间、实际场景中做实验,检测我们的原型设计是否可用有效,用户使用是否方便。 交互设计 设计师与程序员合作,使用几何模型(而不是高精度模型)进行开发实验。 这个阶段还要进行交互范式探索。 最后产出故事板,借助故事板来描述3D的情景。 设定优化目标 为场景和设备设定合适的优化目标和指标,要考虑的是帧率、内存消耗、耗电量和设备温度等等。 高保真设计 设计工具 高保真设计会用到一些设计工具,比如用3DS Max、Maya、Blender进行模型的制作和动画,Substance用来做材质纹理,等等。 制作适合设备的素材 素材中在场景中渲染出来后看不见的面,可以去掉,降低渲染的损耗。 控制点和面的数量,超过限制性能会降低很多。 拆分大的素材,没被看见的部分就不用渲染。 开发 Unity 我们的开发平台选用Unity 3D引擎。它的出身是一个游戏引擎,在当前AR、VR飞速发展的环境下,它已经一个通用的3D开发平台,可以适配到超过30个平台做构建,在AR、VR方面,Unity占的份额非常高。 设备API丨开源工具库 开发是基于设备API去做的,利用开源工具库丰富我们可以提供的其它功能。 用户输入输出 输入一般会用到注视和手势。在手机VR上的视角中心有一个点,这个点会跟随用户头部的移动而移动。从AR技术实现上,我们会在用户的视角中间打一个光束,和它交叉的点就是光标所在的位置。利用那个点去跟所选取到的虚拟物品进行交互,交互的方法就是用手势,如果是基于手机上的AR app,我们会用屏幕点击来进行。 输出方面物体的渲染交给Unity去做,构建虚拟场景,然后把虚拟的物品渲染出来。除了视觉上的物体渲染,还需要有听觉上的感受。空间声音就是很重要的一方面。空间声音就是声音具有空间感,使用户体验感受更加真实。 环境空间感知 这是AR区别于VR的地方,它会和真实世界结合起来,把虚拟世界变为现实世界。分为空间建模、空间分析理解以及图像和物体识别。 空间建模:如图可见,用户所在空间被扫描叠加了一层建模的样子,是通过设备传感器所做到的。建模可以被渲染出来,它的渲染和物理部分是分开的。图中渲染后用不同颜色表现出距离信息。建模包含了物理信息,它有一个碰撞机,能让虚拟物品叠加上去。 空间分析理解:建模后拿到模型,经过空间分析理解可以知道哪里是地面、哪里是墙、哪里是天花板。 图像和物体识别:图像和物体识别可以用第三方服务做到,比如Vuforia,开源的ARToolkit,等等。识别出来后再进行叠加处理。 AI:AI服务完全可以融入AR应用中,为AR增添色彩。例如微软、谷歌、IBM的服务,都可以通过接口的方式把数据传输给它们处理,再拿回来进行使用。这样AR的服务就可以做到语音识别和对话,UI不再是一个对话列表,而是可以真的有一个虚拟人在和用户进行交流。 共享协作:根据场景需求,与相同或不同设备协同合作。可以与其它设备做到同步的交互,也可以头戴设备与平板结合做演示,远程控制用户的体验。 代码管理与协作开发:Git是我们常用的。Github for Unity是直接放在Unity里的一个插件,进行图形化的管理。Unity也推出了服务Collaborate。 Unity和代码优化:首先要做Unity player settings和quality settings,不同设备需要不同的设置。根据应用内容设置摄像机的clipping plane,避免过多渲染。设置stabilization plane,添加spatial anchor,增加稳定性。放置物体在合适的位置,观看舒适度更高。把spatial mapping的精度降低到Low。写着色器,或者使用HoloToolKit之中的着色器。使用draw call batching和instancing,一次性渲染多个对象。使用纯GPU绘制大量的物体。 测试 Unity Test Runner Unity Test Runner是Unity集成的工具。Edit mode用于做unit test,play mde可做integration test。要注意Undo或在新场景中测试。 Unity 中预览 可以在Unity中直接进行预览。在editor中有一些预设的空间模型可以预览,也可以远程连到你的设备。 监视数据 帧率一定要保证在60帧或者以上,如果低于60帧可能会产生抖动或者不稳定,用户会感到晕眩。 HoloLens上内存如果超过900兆会被直接关掉,也是我们需要关注的问题。 耗电量取决于应用的强度和帧率。 设备温度要关注的是环境处于室内还是室外,还有使用时间等因素都和温度有着密不可分的关系。这对用户的舒适度会有很大影响,尤其是头戴式AR设备,如果设备温度过高,用户体验会很差。 本地构建 部署到模拟器,再部署到设备上进行使用。 CI/CD 用Jenkins启动Unity命令行工具,可直接使用Unity的接口。可以用Unity的Unity Cloud Build服务,构建手机应用。 迭代循环 迭代循环的流程是头脑风暴-原型设计-高保真设计-开发-测试-部署,最重要的是优化。 我今天的演讲就到这里,谢谢大家。 推荐文章 基于容器和微服务加快迭代速度实践Web与人工智能时代近期活动内含赠票福利 | 你可能正在错过一场下半年最火的互联网大会 编者:IT大咖说,欢迎关注“itdakashuo”,@IT大咖说 ,转载请标明版权和出处
内容来源:2017年5月21日,当当架构部总监张亮在“饿了么技术沙龙-Java专场”进行《玩转Java开源项目》演讲分享。IT大咖说作为独家视频合作方,经主办方和讲者审阅授权发布。阅读字数:3334 | 7分钟阅读 嘉宾演讲视频和PPT地址:点击下载 Java开源现状 Java是一门历史非常悠久的开发语言,从1995年初见至今,时间的指针已不知不觉的拨动了二十多个年头。请跟我简单回顾一下Java那些抓住历史高光的瞬间,也顺便回忆一下当时那些与Java一起产生共鸣的技术风暴。 Java首次出现在人们的视野中是1995年,它提出了Write once,runanywhere的口号让开发者觉得兴奋。随着JDK 1.0的发布,一些核心概念闪亮登场,它们是JVM,Applet和AWT。Applet和AWT目前虽已退出历史潮流,但当初在网页上展现的冒着热气的咖啡的Applet小程序,确实让人眼前一亮。JVM则沿用至今,基于JVM的跨平台特性对后续的技术产生了深远的影响。 1998年发布的JDK 1.2,首次提出了J2SE、J2EE和J2ME三个系列,分别对应于标准开发,企业级开发和手机开发。J2ME随着手机硬件的更新换代,已逐渐退出历史舞台。而J2SE和J2EE则一直沿用至今。J2EE规范中著名的EJB、JSP、Servlet等既是从那时开始加入并日臻完善的。 2002年发布的JDK 1.4是非常经典的版本,这可能是至今仍然可能在老程序中看到的最老版本。而由于EJB使用起来过于复杂,轻量级的开发框架SpringFramework开始流行。开发者越来越多的抛弃掉笨重的EJB,而转向更为灵活的Spring Framework阵营。而后来出版的由其作者Rod Johnson撰写的《expert one-on-one J2EE Development without EJB》更是成为了不朽的名作,Spring Framework也随之成为Java开发者必须掌握的技术栈。 2006年JDK 1.6发布,从JDK 1.5开始尝试的诸如泛型,元注解等编程语言层面的增强,在JDK 1.6中得到了进一步的完善。同期,参考Google发表的3篇著名的关于GFS、MapReduce和Bigtable学术论文,由Doug Cutting用Java创建并开发的Hadoop面世,它在一定程度上颠覆了传统关系型数据库在数据存储和分析领域的绝对统治,从此大数据成为了技术圈乃至全世界各个领域的热词。 2009年JDK 1.7发布。同时由Google开源的Android趋于成熟,和Apple的IOS形成鼎立之势,共同开启了基于智能手机的移动互联网时代。 随着互联网的发展,信息越来越多,技术的更新迭代也越来越快。最近的一次Java大版本的发布,是2014年的JDK 1.8,它也是目前为止Java的最新版本。而在同一时期出现最多的焦点技术是以Docker为主的容器和如何有效治理容器的微服务。容器方面Java虽然难于建树,但基于Java的Spring Boot、SpringCloud、Zookeeper等优秀的框架以及组件为微服务奠定了坚实的基础。 谈了很久Java历史,那么经历了这么多年的发展,Java必然沉淀了大量极具价值的项目,可供免费使用的开源项目层出不穷。Java门槛越来越高,不仅仅是编程语言层面的问题,也不仅是难于理解的面向对象、设计模式等,而是在于它的技术广度。由于技术栈众多,它几乎很难快速上手,但从另一方面讲,Java生态相对于其他语言更加稳定和成熟,技术组件几乎应有尽有。 Java开源项目类型盘点 基础类:为编程提供便利的基础类库。如:Guava、ApacheCommons等。 框架类:曾被认为Java最重要的部分,早期是业务开发工程师的饭碗。如:SpringFramework、Hibernate、MyBatis、Struts等。 测试类:与其他语言比,Java有较完善的测试体系,它很容易提升测试覆盖率,这得益于广泛的测试类库。如:Junit、TestNG、DbUnit、Mocktio等。 构建类:由于使用Java开发的项目大多规模大,依赖复杂,因此Java构建类工具很完善。如:Ant、Maven等。 中间件:中间件种类很多。比如:Tomcat、Jetty等Web中间件,ActiveMQ、RocketMQ等消息中间件、Dubbo等服务治理中间件等。基础中间件已非常成熟,而分布式中间件仍极少有统一标准。 NoSQL:NoSQL是关系型数据库的有益补充。NoSQL类型主要分为文档数据库、列簇数据库、KV数据库和图数据库。相关产品众多,使用Java开发的也不少,如:Cassandra、Neo4j等。 搜索:全文检索领域中,Lucene是基础类库的佼佼者。而基于Lucene封装的Solr、Elasticsearch等高可用搜索引擎也是很常见的技术。 大数据:Hadoop系列几乎全是用Java开发的。 手机端:刚才提到过的Android系统。 桌面端:虽然使用Java开发桌面系统并非现在的主流,但深入人心的产品依然很多,如:Eclipse。 Java开源不擅长的领域 在容器、缓存和关系型数据库这三个领域,Java的开源项目并不多见,而且当前Java也没有太多机会进驻这些领域。 当今需要的Java开源解决方案 虽然Java已有为数众多的成熟开源项目,但是目前仍稀缺的优秀开源领域主要是分布式、服务化和弹性化这三个方面。 在互联网行业分布式、服务化和弹性化是很重要的非功能需求。每个互联网企业中都有一套足够成熟的系统,但很多系统难于解耦且定制化严重,因此在这方面,成熟的开源产品凤毛麟角。因此,有价值的开源项目应该从这三方面考虑,而且Java比较适合做这些领域的开发。 开发一个开源项目的那些事儿 开源项目的来源 来源主要从四个方面,大公司、创业公司、社区以及个人。 大公司所做的开源产品基本上不与经济收益直接相关。如:Google开源的Kubernetes,Linkedin开源的Kafka等。 创业公司开源的产品一般会与他们的经济利益绑定,大都开源其核心技术,然后针对定制化、咨询以及企业版进行收费服务。如:Docker、Mesosphere的Mesos、Elastic的Elasticsearch等。 完全由社区驱动的开源的产品拥有强大的开源基因,是开源世界的典范。如:Linux、Apache等。 而个人开源的产品,一般是处于孵化阶段。 如何做一个有价值的开源项目 1、以熟悉各种轮子为前提重复造轮子是巨大的精力浪费,有价值的开源项目应该是现有轮子不能完全覆盖的范围。 2、以解决实际问题为目的任何技术项目都是以解决实际存在的业务问题为前提的,完全脱离业务的技术其存在价值是存疑的。 3、以系统眼光去规划设计相比于闭源项目,开源项目的受众更广,影响范围更大,每次升级都带来颠覆性的变更是灾难性的。因此尽量的合理设计系统架构和roadmap是成功的关键。好的系统是设计出来,而非改造出来的。前瞻性的眼光非常重要。 4、以工匠精神去雕琢细节开放出去的源代码会在一定的范围内引起共鸣。一个值得研读开源项目,其代码必须经过雕琢,让其规范、一致、优雅、易懂,尽量将细节做到极致。通过代码质量给予使用者信心。 打造合理社区 1、灌输开源精神freeis not free是开源的一句名言。开源的价值不仅仅在于免费,更在于自由。既然已经把源代码开放出去了,那么使用者想怎么改都可以,而不应一味地向开源人索取。因此需要合理对用户进行引导,并让其认同开源精神,最终做到积极反馈社区。 2、关注核心用户应尽早识别出核心用户,与核心用户共同发展。最好能够抱团形成组织,或作为周边生态加入更大的组织,并利用核心用户的影响力吸引更多的用户。 3、坚持与耐心成功从来不是一件容易的事,开源也不例外。开源之后要坚持去推广、运营和完善它,并保持足够耐心。相信是金子总会发亮,坚持才能带来最终的收获。 4、文档文档的重要性甚至优于程序本身。应尽量将使用场景、使用限制、使用建议、配置手册、实现原理、常见问题等描述清晰。优质文档可以屏蔽大量重复问题,减少开源维护者的精力消耗。 聊聊当当开源 当当目前的主要开源产品有三个,分别对应于用于异步化的作业中间件、用于服务化的服务治理中间件以及用于数据水平扩展的数据库分库分表中间件。其关注的核心都是分布式和弹性化。这三个开源项目都有属于自己的关键词。 Elastic-job:Elastic-job的关键词是融入。它是一个分布式弹性化调度框架,由Lite和Cloud两个分支组成,Elastic-Job-Lite提供轻量级、无中心化的作业治理服务。Elastic-Job-Cloud采用中心化方式,它与Mesos完美结合,很容易提供一站式的作业云平台服务。下图是以Elastic-Job-Cloud为核心的当当作业云架构图:Sharding-jdbc:Sharding-jdbc的关键词是兼容。它作为一个分布式的数据库中间层,主要职责是透明化数据库水平扩展以及柔性事务的处理。它扩展并完全兼容JDBC协议,因此任何基于JDBC的Java ORM框架均可无缝兼容使用。应用开发工程师无需对现有代码进行任何调整,只需要配置完成分片规则即可直接享用Sharding-JDBC带来的便利。Sharding-JDBC不仅仅是简单的SQL识别,它拥有一套复杂且完善的知识理论。下图是Sharding-JDBC的架构图:Dubbox:Dubbox的关键词是扩展。它在阿里开源的Dubbo基础上直接扩展,增加了REST协议等新功能,用于实现异构语言间调用。 三个项目的Github地址是:https://github.com/dangdangdotcom/elastic-jobhttps://github.com/dangdangdotcom/sharding-jdbchttps://github.com/dangdangdotcom/dubbox 这3个项目已较为成熟,已在当当大规模使用,比较符合互联网的业务场景。欢迎感兴趣的同学使用、star和fork,欢迎联系我们并提出宝贵建议。 我的分享到此结束,谢谢大家! 编者:IT大咖说,欢迎关注“itdakashuo”,@IT大咖说 ,转载请标明版权和出处
内容来源:2017年6月18日,手淘前端技术专家大漠在“2017 iWeb峰会·第六届HTML5峰会 ”进行《手淘互动动效的探索》演讲分享。IT大咖说作为独家视频合作方,经主办方和讲者审阅授权发布。阅读字数:3089 | 6分钟阅读 嘉宾演讲视频 http://www.itdks.com/dakashuo/detail/2199 “互动,是连接用户的桥梁” 我们以前访问Web页面是没有动画和动效的,甚至点击跳转的功能都很少。那时是纯粹的文字展示,图片在网站上也很少能看见。 最初点击一个链接跳到一个新的页面,这是一种交互。随着技术的变革,点击一个按钮会弹出一个窗口,这也是我以前认识的一种交互。现在我们的交互行为变得更加复杂。 用户无需进行任何操作,页面只是告诉用户去点击某个按钮可以进入一个页面或一个会场。这种交互行为在内部我们称之为引流。 还有一种是纯氛围的动画交互效果。 橱窗是加上一些动效或陀螺仪的功能,让用户觉得耳目一新。 抽奖是加入了一些用户的交互行为,点击红包就会告诉用户中了多少钱或者运气不好没有中奖。 视频现在也是一种传替交互的表现形式,如果加上一些其它的技术手段上去,能表现出来的就不止是我们看到的视频那样。 我们目前尝试在手淘互动里加一些简单的游戏,这些游戏就是利用前端的代码加一些创意,把用户吸引到互动的活动里来,让用户在这里驻留的时间更久。或者通过这些小游戏给用户带来一定的收益。 提醒是一个时间倒计时,告诉用户还有多少时间去参加“双十一”抢红包的活动。 交互在我们团队就是以上这些表现形式。 最早我们只能看到PC端的Web页面,随着移动端的快速发展,移动端的互动方式也会越来越丰富。 “动画,用于点缀” 最早实现动画的技术方案是Gif、视频,还有早期PC端看到的Flash页面,这些方案都是前端不用参与的。 但是Gif图放到移动端,会产生一些不好的后果。以及iOS不支持Flash,视频也有一些存在的风险。 在CSS3出现以后,大家做简单动画的时候会经常用到。还有一些SVG和Canvas动画。但其实这些都还不能满足我们各种业务场景。 我们今天的重点会放在JS-Driven Animation动画。 0-1的过程 2015年,我们团队经历了一个0-1的过程。在15年之前,各种大触看到的氛围和动效基本上是Gif图或是视频。15年年货节,我们尝试了第一次的改变,通过前端CSS或JS的技术手段,把一个Gif图转换成动画效果。完成这个效果的时候,无论是需求方还是产品都很满意,因为这种方案可以随时更改动画中的元素。 CSS动画的痛点 沟通成本高。 开发成本高:因为要通过CSS去繁衍一个视频或Gif图演示的动效,除了要懂这方面的技术之外,还要让Gif图通过代码层面来实现。 还原度低:CSS实现动画的手段是有限的,要做一些复杂的动画还是有难度。 可控制性低:如果需求方改变了其中某一个动画需求,我们至少要花2-3天来繁衍那部分的效果。 可交互性弱:CSS动画无法实现在播到某个时间段突然弹出窗口告知用户可以参加的活动。 日渐无法满足业务场景:在0-1的过程中,需求方可能还是比较满意的,但是如果每次的动画效果都是用这种方案来实现,需求方会觉得很无聊,做出来也无法达到100%的还原度。 JS-Driven Animation 经过市场调研综合结果之后,我们最终还是选择自己“造轮子”。因为我们希望可以是自己控制的,不用担心被别人起诉,也不担心新功能无法在它的基础上进行扩展。 后来我们经过一年的时间做了一个用JS驱动动画的工具Animation Flow Tool。 动画管理 我个人喜欢把动画的管理当作是导演一场舞台剧,要指挥每个演员何时出场,出来做什么,何时退场。在我们的动画管理中有一个timeline,它很像导演的角色。 通过时间轴可以很好地控制动画的场景,包括它何时播放、何时停止、何时退出。 CSS处理动画衔接的短板 CSS是通过持续时间来实现控制,如果所有时间点都已经确定了,这样做是没有问题的。 比如动画“火山升起”的时候发来1秒的时间,第二个动画“火焰柱喷发”是在“火山升起”结束后开始播放。这时就可知它的延迟时间是1秒,“岩浆流动”同时播放也是1秒。到了“红包喷发”的时候就需要进行计算,前面的动画播放4秒后再播放“红包喷发”,它的延迟是1.4秒。如果这时“火山升起”的持续时间有所变动,那么后续的所有时间都要重新进行计算。这是CSS管理动画最大的缺点之一。 动画(片段)之间有重叠 后来我们改变了一种模式,通过JS来监控第一段动画,并告诉后面的动画什么时候结束再可以开始播放。这时无论第一段动画如何改变,都不用担心后面的动画。 扩展动画 互动常见的动画类型 CSS在手淘上实现的动效性质都是相同的,我们把它定义为精灵动画和路径动画。经过一年我们发现这两种动画是我们业务中最常见的动画效果,于是就对它们进行了封装。 精灵动画 以前要把所有图案拼成一张图,然后通过Animation控制每一帧的播放。后来我们通过API来控制。 比如一个图案从底部出现到顶部隐藏一共经历了80帧。按照以前CSS的动画实现方案,需要拼80张图片。在这80张小图里有40张可能是相同的,CSS却不能把相同的图片利用起来。 而AFT的方案是可以的,也就是说在这个基础上最起码节省了40张图片。 CSS路径动画 在没有AFT的情况下,我们做的是路径动画,通过translate来改变x和y轴的轨径位置。 我们当时做这个动画效果描点描了很久,但是产品经理突然提出不要Z形的路径,要改成S形,我们又只好重新描S形的路径出来。有一位同事描了七套路径,需求方还不是很满意,因为用translate来描点,不管怎么描到无法达到流畅的效果。 AFT路径动画 后来我们改用SVG的路径,无论需求方想要什么路径,只要找个SVG的制图软件导出路径节点就可以。这是我们后来对路径动画做的改变。 如果以后CSS的路径动画属性得到浏览器的支持,可以直接用原生的CSS路径动画,也支持SVG导出的路径,实现路径动画,AFT就要退出历史舞台了。 AFT骨骼动画 骨骼动画是借助第三方平台的工具把骨骼动画做出来,导出它的json数据,拿到json数据再出动画效果。 AFT架构的演变 最早的时候我们是利用IDE导出一份json数据,通过第三方JS库来实现DOM的动画效果。 我们的第二种方案是通过An/AE导出一份json数据,再通过前端的DSL层面来实现动画效果。 经过实验,这两种都不是我们想要的实现方案,后来我们对它进行了一些简单的改造。 aft.js架构细节 第一部分是元素,第二部分是动效器,第三部分是引擎,最关键的一点是动画管理,也就是时间轴。 元素和动效是分离的,只要做动效,然后把动效赋予到元素上,再找引擎来渲染。 我们专注于做管理动画,怎样把动画描述出来,怎样把动画串起来构成我们所需业务的动画。这是AFT后面实现的底层架构,看上去没有以前那么复杂。 业务开发模式 曾经开发模式 视觉设计提供一个Gif或视频文件和一个PSD文件,交付到前端。前端根据Gif或视频的动画效果,把整个动画繁衍出来。也就是AFT动画繁衍的过程。这个模式的沟通成本非常高。 现在的业务开发模式 前端只负责业务层的逻辑代码,视觉通过AE这种制作动画的工具去导出动画。要有业务逻辑,再通过前端加入业务逻辑。如果不要业务逻辑的话,就无需前端界入了。 “可量化和数据驱动” 粗犷的做法 AE导出的不是json数据,它做出一个视频,然后前端再通过代码繁衍。 正确的做法 通过动画编程语言进行实现,要什么效果就能繁衍出什么效果。 思考探索 我们提出了一个“动画工程师”的概念。我们团队目前还在思考动画工程师应该做什么,动画工程师是不是能直接实现动画的过程就可以称之为动画工程师。但我个人认为远远不止这些,我们还在思考探索中。 我今天的分享就到这里,感谢聆听! 推荐文章Mars在移动网络的探索和实践阿里巴巴前端专家渚薰:H5互动的正确打开方式近期活动直播 |【阿里云MVP MeetUp】一起把云计算拆了玩儿
内容来源:2017年5月25日,极光高级Android工程师王可为在“极光开发者沙龙”进行《移动端SDK优化的特点与经验分享》演讲分享。IT大咖说作为独家视频合作方,经主办方和讲者审阅授权发布。阅读字数:2098 | 4分钟阅读 嘉宾分享视频和PPT地址 SDK和APP的差别 重复造轮子 我们做APP开发的有这样一句话:“不要重复造轮子。”意思就是希望快速迭代,每个APP有自己独有的功能。基础业务可以直接用别人已经做好的框架或第三方的包导入进来,但业务代码一定要做自己独有的。 在体积大小上,SDK和APP就有明显差异。APP的核心代码只需做上面一小块,但这样做的结果是一个APP本身大小有几十兆甚至一百多兆,用户可以接受。而SDK需要做得小,体积在几百K以内,才是开发者能接受的。 所以SDK不能直接用别人的“轮子”。做基础业务的话,像网络、数据库可以用Android原生的API来做,这样能把体积控制在较小的范围内,APP开发者才会用较小的包去做他们的业务。它的好处就是保持代码的精简,并且内部可见,方便调试和修改。 为了体积,以及优化架构和性能上,我们要“重复造轮子”。 配置 APP只需要开发者根据自己的需求写一份配置列表。 SDK的权限则是交给开发者,开发者具体用的什么权限或版本,我们是无法控制的,只能通过指引说明的形式告诉他们如何配置。 所以我们要考虑配置做到尽量简便、友好、灵活。 升级 一个APP如果要升级,开发新版本上架到应用商场把它替换下来,或是推送更新通知,保证用户较快地用到新版本,同时在线版本范围比较小,老版本占有率慢慢降低。 而SDK不是直接上架市场,是需要开发者主动去拿文件,集成到自己的工程,再上架到市场。有些开发者几个月之后才做更新,甚至有的从不更新,这个情况导致同时存在很多个历史久远的老版本,这个问题会要求我们做很多兼容性的考虑,所以可靠性和性能考虑的份量是比新功能要重的。 极光SDK的架构优化 旧架构 2016年之前极光推的主要是两个SDK,一个是Jpush,一个是JMessage。 旧架构的推送跟IM是两个独立的SDK,存在很多种冗余代码。缺点是占用空间大,有重复操作,占用了通道和线程资源,还有就是冗余代码的升级管理非常麻烦。 新架构 我们在拓展业务后还新增了统计和分享,针对多条业务线的考虑,我们做了架构调整,把业务跟核心做了分层。 JCore负责核心通用的功能,上层SDK各自在JCore之上运行自有业务,使结构更加清晰,利于拓展共享资源,减少重复动作,针对性做基础优化更加方便。 实际开发中需要考虑的 在和服务器通信的时候,从协议的制定上要考虑兼容不同的组件和同时在线的不同版本。在代码设计上涉及到的策略类要采取策略模式,方便替换更优策略。 核心组件和上层的组件拆分成两个,针对升级不同步的问题需要有更多的接口,要简洁,适应变化。 以及关于各个组件之间的通信,通过命令模式,把动作抽象成为可传出的对象,实现分发和缓冲。 在Android开发的工程设计中,由于被拆分为两个包,一些接口难免会暴露出来,但是为了起到保护代码的作用,又不能完全暴露。所以在方便和保护之间要做取舍权衡。 因为引入了很多组件,在打包、编译脚本的时候可以用到Jenkins+Gradle,编写脚本,做集成,可以自动打出多个包。 极光SDK的性能优化 多进程与多线程 多线程是语言的基本功,通常情况业务是在主线程执行,但是在移动端主线程任务过重会卡顿影响到用户体验,要尽量克制。所以在占用资源比较多、耗时的情况下要另外多开一个线程。 在Android应用的设计理念上,进程是非常宝贵的资源,它尽量不把进程管理交给开发者,而是让系统去处理。 如果是单进程的应用,做的任务很多,内存占用数高,派多个进程可以分担上面的一部分任务资源到另一个进程,避免占用资源太高被回收。另外一个好处是,在后台跑的主进程因为一些无法预测的原因被系统回收掉了,在主进程的任务依然可以继续执行下去。 开了多进程以后内存空间是独立的,可能在主进程是初始化的,但在子进程上未被初始化。写代码的时候没有意识到,在运行的时候就出乎意料了。这就是数据不同步会造成的问题。 数据不同步是主进程和线进程都能遇到的问题,如何巧妙利用它的性能又不出错,我个人经常用双重检查锁,看上去代码更复杂,但有利于性能更好地运行,并且不容易出现数据不同步的问题。 由于变量在多进程时是不同步的,所以跨进程共享的变量,需要通过进程间通信的机制,把变量的读和写均放到同一个进程中,虽然会带来一点性能损耗,但是这样才能保证数据正确性。 储存方式 同一个进程下,可以做一次读取多次使用。 写的操作可以批量提交。 使用内存级别储存,响应更快。 跨进程的批量读取和提交。 拆分存储区。 长链接优化 我们做极光推送,推送主要的任务都是在长链接里。客户端和服务器进行通讯,先要进行接入服务。 我们有一个SIS服务,就是另外开辟服务器去找当时的设备,它介入哪一个IP,接入哪个端口有更快的响应,我们会下发一个列表给客户端,让它们自己去尝试。 要做性能优化,可以先把列表缓存在本地,如果失败了再用SIS下发的地址。然后写一些选择的策略,优先选择可用的,排除不可用的。 在接入服务这部分,会把当时的状况上报给服务器,让服务器根据这些上报的数据反馈做调整。 我的分享到此结束,谢谢大家! 编者:IT大咖说,欢迎关注“itdakashuo”,@IT大咖说 ,转载请标明版权和出处。
本文由红薯在 开源中国-OSC源创会第58期【福州站】的演讲整理而成。本文总字数:1516个 预计阅读时间:8分钟 嘉宾演讲视频地址:http://t.cn/RSlMZEX嘉宾PPT下载地址:http://t.cn/RCIVAlD 开源中国的现状 我们现在全球排名是大概800名,每天的ip数超过80万,大概1000万的PV,超过5000万的动态请求。 开源中国有几个应用的策略,可能不仅仅是开源中国,我们整个做web网站的时候,缓存应用都有以下的几个场景。 对象缓存 对象缓存就是根据用户的编号,拿到用户的详细的资料。这个非常好理解。 列表缓存 比如我们今天发了什么新闻,会有一个列表的页面,这个列表存的是一个ID。假如要改一篇新闻,我们就可以根据ID获取它的渠道列表后再找到新闻详细的内容。这样只需要改一个对象缓存,清除那个对象缓存再更新一下就好了。 页面片段缓存 页面片段就好比首页有很多的内容,可以把某一块html保存到内存里,这样输出会很快。 在清除缓存的时候,我们的策略还有过期自动清除、程序清除和手工清除。 Ehcache缓存框架 开源中国是用Java开发的。Java在做缓存的时候有一个很著名的Ehcache框架,它是基于内存的一个缓存框架,速度非常快。因为不能把所有数据都放在内存里,它可以把一部分数据放进磁盘,是一个两级的缓存。它还支持多个区域的缓存结构,用户是一个缓存,新闻帖子之类的可以单独设置缓存失效策略。Ehcache还提供了缓存数据的侦听接口。一个缓存数据一旦出现问题,就会得到通知。Ehcache也支持集群部署。 J2Cache 开源中国成立公司是在2011年,网站在2008年就上线了。这个网站撑了有两三年的时间,后来数据长得很快,就开始出现问题了。第一个就是单节点无法应付高并发的访问。还有一个最可怕的问题就是因为程序更新很频繁,Java每次更新的时候都要重启。一旦重启后,整个Ehcache缓存里的数据都被清掉。所以说重启然后大量访问进来的话,数据库基本上很快就会崩掉了。 那么我们为什么不选择Ehcache的集群方案呢?因为当我们在一个节点里存数据的时候,它同时会通过网络传播的形式将数据复制到其它节点。这样会造成网络开销很大。而不用redis则是因为它读缓存数据非常慢。 我们想的方案是把Ehcache和redis结合起来,取长补短。尽量从本机取数据,取不到的时候再去redis里面取。 Ehcache+ redis,就是J2Cache。 这样结合可以保证高性能。数据基本上都是从Ehcache里面取的,有效的缓解应用冷启动对数据库的压力。应用和redis之间不会有大量的数据传输,因为大量数据传输只存在于冷启动的时候。 J2Cache数据读取流程 每次读数据的时候首先从Ehcache里先读,因为Ehcache在你的内存中。如果有的话直接返回,没有的话就通过通过网络去读redis的数据,如果数据有的话就把它塞到Ehcache里面,再返回。如果redis也没有,这时才读数据库的数据,然后同时把它的数据塞到Ehcache和redis里面,最后返回数据。 J2Cache数据更新流程 清除数据首先是要清除节点。其他节点在收到这个命令的时候,它会清除当前Ehcache里面对应的数据。这样的话清除某一个节点数据,然后通过广播把这数据给其他其他节点,同时也清楚这个数据,这样就保证了整个集群里面的缓存数据是同步的。 序列化库的选择 因为缓存数据要通过网络传输到redis上,所以我们要求所有的对象都必须是可序列化的。我们最终使用的是FST,因为它速度很快,生成的那个序列号体积也比较小,关键是它对你的项目没有任何侵入性。 我今天要分享的就这些,谢谢! 编者:IT大咖说,欢迎关注“itdakashuo”,@IT大咖说 ,转载请标明版权和出处。
内容来源:2016年12月16日,微博产品资深运维架构师王关胜在“GIAC全球互联网架构大会”进行《新浪微博平台自动化运维演进之路》演讲分享。IT大咖说作为独家视频合作方,经主办方和讲者审阅授权发布。阅读字数: 2557 用时: 4分钟 点击嘉宾演讲视频观看 Sina Weibo业务介绍 微博业务简介 微博平台是属于偏后端的一个产品,它所提供的服务就是固定量的接口,比如信息流里的接口、用户接口、关系接口等等。 微博核心业务 微博最核心的产品就是信息流,以信息流为中心出发,它周边的用户、关系以及通知等主路径的服务都在内部平台,属于核心服务。 微博业务部署结构 我们对于核心业务要求多机房部署,电信和联通机房都部署了完整的链路。 服务保障——服务治理(开发主导) 在这样一个复杂的架构下,运维和开发需要紧密配合。我们内部组织架构调整后,运维团队属于开发团队,配合起来就非常紧密。 内部分为了两个方向。第一个方向的部分是开发主导,运维参与。比如建立完善的SLA体系,我们这个SLA体系做在应用层上,从开发和运维层面在代码上做一些改造,在数据层面上做收集。降级/封禁也是相似的方法,开发在代码上做降级/封禁的入口,具体提供的功能和平台是在运维做的系统里。 服务保障——防御体系(运维主导) 第二个方向就是由运维全程主导,开发参与。例如容量、监控、干预还有运维的部署架构。 架构要做到极简、稳健、美丽; 监控要求具有实时性,报警快、准,覆盖全面; 容量的性能要好,冗余足够,能快速动态扩容,有压测、容量预警; 干预的预案要全,手段多,操作快速,方案细致,要做到干预行之有效。 整体的防御体系要由标准化转化为可视化、自动化,最后升级到智能化。 微博平台运维进化历程 微博平台的运维进化历程大概分成四个阶段。最早是人工阶段,所有的脚本都要依赖于人工,也就是所谓的脚本时代; 第二阶段是工具系统。当规模有一定的成长之后,做到了工具系统化和运维标准化; 下一个阶段就是综合运维平台。要把很多运维系统做成一个运维平台,就需要让系统平台化、数据API化和运维服务化; 目前我们比较推崇的是利用混合云DCP的思路来做一些系统。 百台规模运维标准化 百台规模——一切皆需求 这个阶段主要的工作就是日常的需求对接、完善监控警报、代码的发布和回滚、还有服务的扩缩容以及之前的一些配管工具。这些工作都要做到快速迭代、快速上线、快速响应。 百台规模——需求达成 当时只需要利用Python、Perl、Shell等去写各种脚本,日常的需求基本都能达成。 我们也在研究一些开源的工具。当时在业务部署的层面最开始是用脚本,后来发现脚本比较麻烦,就改用配管。 百台规模——标准化梳理 配管是该阶段比较核心的内容,需求经过抽象可分为三类,机器上的基础配置、机房相关和业务相关。 所有配置要能通过标准化的配管工具管理起来,每一类服务都进行标准化梳理,就能达到我们这个阶段的目标了。 百台规模——CMDB&配管 新浪在很多部门都会用到Puppet来做配置管理工作。我们当时借鉴了这样一套配管工具,把所有能通过Puppet做的需求在标准化之后尽量用到Puppet。这样就能基本上满足那个阶段的需求。 百台规模——配管UI化 在三大需求之上,我们也给Puppet做了完善管理的UI。与Puppet相关所有配置的需求不再需要通过手工管理,直接UI化,就可以在页面上修改配置,把配置管理起来,再通过Puppet的API下发。满足了当时的需求。 千台规模平台化&可视化 千台规模——挑战性加大 我们面临了很多的挑战:服务器规模线性增长;业务单元线性增长;系统变更及代码上线次数线性增长;大型运营活动及三节保障;每日不定时段的PUSH。所以要做一些工具来满足需求。 但同时也出现了人力成本线性增长、差异化加剧导致认知成本线性增长的问题。 千台规模——构建运维平台 我们当时内部做了一套比较完善的运维管理系统Jpool。它是一个通用的集群管理平台,核心模块包含了用户权限、资源管理、配置管理、部署管理、任务管理、Nginx变更管理、降级/封杀管理和日志查询平台。 Dispatch和Puppet Master组成了这个平台里最核心的部分。Puppet Master管理了配管方面,Dispatch是一个分布式的命令通道。 千台规模——运维平台Joopl框架 千台规模——Joopl核心组件 Dispatch是一个分布式任务调度引擎。在Dispatch里有三大任务线程,任务处理线程、与agent连接的通信协议层及通信线程和主线程。 千台规模——统一运维平台 整合工单流程变更、统一配管系统、统一负载均衡系统、持续集成和监控报警系统这些工具系统,形成完整的运维平台。 平台建成后还能在上面做一些日常的变更手段,例如Puppet/Nginx变更、服务的部署变更、服务降级/封禁、扩容/缩容以及业务docker化。还有其它的像流量切换、限流、数据修复等等都是可以在运维平台上完成的。 万台规模自动化&智能化 万台规模——面临的核心挑战 针对一些突发的娱乐事件,我们需要有峰值应对才能保证服务的稳定。 在这个阶段我们要设置混合云系统,主要从四个点出发。 最核心的是峰值应对,可以进行快速扩容,及时回收; 其次是成本优化,可伸缩的业务利用公有云,私有云的内部进行弹性部署; 打通多语言环境,全公司统一平台,做到运维统一化; 业务快速迭代,基础设施标准化,提高发布效率。 万台规模——峰值应对——混合云DCP 峰值应对:目标“无人值守”的扩缩容 由于近几年突发的爆炸性事件增多,所以我们要做到扩缩容“无人值守”。 基于运维自动化之上再做“无人值守”就需要各种各样的业务指标,而我们的监控可以收集所有的业务指标。有了详细指标就可以做到“无人值守”。 总结:自动化核心——任务调度引擎 一个产品要想发展壮大,必须得有一套完整的任务通道。利用任务通道把所有运维相关的操作抽象为标准化的操作库,加上流程引擎,然后再做统一的任务编排。 有了这四大核心内容,再做平台或自动化思路就比较方便了。 今天要分享的就是这些,谢谢大家! 相关推荐 XpmJS —— 小程序后端开发思考和实践魅族推荐平台架构近期活动活动 | 区块链技术如何改变我们的生活活动 | 一起出发,吹响Container+的号角
内容来源:2016年12月16日,郑然在“GIAC 全球互联网架构大会”进行《支撑百度搜索引擎99.995%可靠名字服务架构设计》演讲分享。IT大咖说作为独家视频合作方,经主办方和讲者审阅授权发布。阅读字数:2783 | 4分钟阅读 点击观看嘉宾演讲视频 搜索引擎的挑战 机器数量多,服务数量大:我们有数万台服务器,数十万个服务,分布在多个IDC。 服务变更多,变更数据大:每天几十万次变更,每周10P量级的文件更新,千余人并行开发上百个模块。 检索流量大,稳定性要高:每秒数万次请求,满足99.995%的可用性,极短时间的故障都可能引发大量的拒绝。 服务发现的原理 什么是服务发现 服务上游如何找到下游;服务上游如何负载均衡;下游挂了上游如何感知。 客户端服务发现 所有服务下游自行向服务注册表中进行注册,同时服务上游集成注册表的客户端,查询注册表以获取服务下游列表。服务上游集成负载均衡器,实施负载均衡。 服务端服务发现 服务端服务发现和客户端服务发现的区别就在于,服务端服务发现所有服务上游的请求都是通过网关去查询。 服务发现组件 服务发现主要由服务注册表、注册表客户端和负载均衡组成。 服务注册表是分布式的存储,持久化服务地址和自定义属性,服务名字全局唯一。 注册表客户端支持对注册表的增删改查,支持高并发高吞吐,对延迟的要求不太高,读多写少。 负载均衡对于整个服务系统来说是一个不可或缺的组件。它根据负载选择某个服务,剔除和探活故障服务。 关键技术与实践难点 Eden架构蓝图 Eden是百度网页搜索部自行研发的基于百度matrix集群操作系统的PaaS平台。它主要负责服务的部署、扩缩容、故障恢复等一系列服务治理的相关工作。底层是基础设施层,包括监控、故障检测以及matrix集群操作系统。 Eden由三部分组成,第一部分是总控服务,分为InstanceMgr和NamingService。底层有多个agent来执行总控下发的命令。所有的源数据保存在zookeeper上,并提供了命令行、web之类的接口来使用。还有一个机器维修仲裁的组件,根据故障类型、服务状态来决策机器的维修,同时提供了日志的收集分析,和一个仿真的测试平台。 在这之上是job engine层,提供了封装日常服务变更的操作,包括升级、数据的变更、服务扩容、故障实例的迁移等,在这层上做了抽象。 最上面是一些托管的服务,有网页图片搜索服务、度秘服务、和信息流。 服务发现组件 对于一个IDC来说,我们会部署一套NamingService,agent复用的是Eden的agent。 服务发现不可避免的是要支持跨机房的服务发现机制,必须要有跨机房查询的功能,我们就做了一套远程的跨机房查询,上层提供了SDK接口把这些过程封装起来。 为了支持跨机房一定要APP的ID或者名字必须要全局唯一。 技术难点 我觉得一个真正能够在线上稳定运行的服务发现系统必须要解决以下六个问题: 调用时机:谁来向服务注册表注册和注销服务? 健康检查:上游如何感知下游的健康情况? 无损升级:如何无损的进行服务升级? 变更分级:连接关系变更如何分级? 感知变化:上游服务如何感知下游服务列表的变化? 避免单点:如何避免服务注册表局部故障? 调用时机 第一种方式是服务自己,在启动或停止的时候注册或注销自己。这种方式服务的启停对注册表有很强的依赖,服务需要植入SDK,会产生植入成本,容易干扰运维的可预期性,影响过载保护策略。 第二种方式就是采用第三方组件,有一个代理模块去实施服务的注册和注销。我们使用这种方法的时候是利用agent通过SDK去操作。它的优点就是只需在服务添加删除时修改注册表,不用植入SDK,对注册表的依赖很弱,更容易进行运维效果监控,降低注册表的负载。 健康检查 健康检查有服务端健康检查和客户端健康检查两种做法。 服务端健康检查是服务自己做健康检查,把健康结果反馈给服务注册表。但这种方式对注册表的依赖性很强,而且它自己的健康不一定是上游看到的健康,所以结果未必准确,感知周期也很长。 客户端健康检查则是客户端和服务端建立心跳和探活机制。它的优点是对注册表的依赖性弱,感知周期短,准确性更高了。 无损升级 升级就意味着同时重启的数量要比平时更多。对于上游来说,不可访问的服务也比日常要多,这就意味着失败概率会变大。 重试虽然可以在一定程度上解决问题,但重试的副作用大,通常重试的次数会被严格限制。 而健康检查虽然可以探测到不可用的下游服务,但是健康检测存在周期性。 后来我们又有了一个更好的做法::我们采取的方法是下游服务退出过程中,先不会关闭服务读写端口,而仅仅关闭心跳端口,使服务处于"跛脚鸭"状态,等上游检测到下游心跳异常之后,将流量调度到其他服务实例,然后下游服务实例再关闭读写端口退出,从而实现完全可控的无损服务升级。 变更分级 基于分布式锁的个数,控制上游变更的服务,但上游分级方式具有随机性,出错情况损失偏大。 给下游实例打tag,标记是否被上游可见。 其实这种分级方式并不是很好,因为变更连接关系高危变更,一旦错误,损失很大。更好的方法是通过权重来控制下游服务的流量比例。 感知变化 我们在实践中发现zookeeper的通知机制不可靠,对注册表依赖过重,发生局部故障,影响服务可用性。 而轮询是一种比较可靠的机制。由agent周期性轮询服务注册表,引入版本节点,只有版本变化时,才获取全量数据,增强了运维的可预期性。 避免单点 对于IDC来说,它不希望由于服务发现系统局部故障而影响服务。 历史上我们发生过多次zookeeper的局部故障,比如网络抖动导致大量session超时所引起的通知机制。 把这些“不可靠”作为设计思路,我们把上游持久化缓存下游服务列表,作为容灾手段。采用的是轮询机制。 健康检查是通过上游服务探测下游服务健康状态。 应用范围 目前的服务发现系统应用到了万级的服务数量,支持了十万级的服务实例数量,覆盖了百度搜索引擎规模最大的indexer服务,数千个实例扩缩容的索引分布调整,分钟级完成连接变更。 应用案例 相关对策 原有方案无论是ssdb、proxy还是master,都大量应用了对于zk通知的机制,同时还依赖zk的session机制做探活。 这个方案在实际应用中很容易出现网络抖动session超时的故障,zk通知机制也容易丢消息,zk故障会导致服务整体不可用,平均1~2个月就会发生故障。 所以我们把它迁移到了NamingService,以解决上述问题。 总结和思考 总结 使用第三方组件进行注册和注销; 上游探测下游服务健康状态; 通过服务分组实现无损升级; 连接关系变更一定要有分级机制; 使用轮询而不使用通知; 以服务注册不可靠作为假设条件。 思考 我们打算引入类似k8s的endpoint机制;通过控制流量比例更好的实现分级;提升易用性,成为通用的中间件。 以上就是我今天的分享,谢谢大家! 相关推荐 Mars在移动网络的探索和实践京东小程序的三生三世
内容来源:2017年2月26日,叶金荣在“OSC源创会福州站”进行《MySQL 5.7新时代》演讲分享。IT大咖说作为独家视频合作方,经主办方和讲者审阅授权发布。阅读字数:1132 | 4分钟阅读 嘉宾演讲视频地址:http://t.cn/RK7Ncl0 MySQL5.7新气象 2013.4.23发布了MySQL5.7.1,距今已有4年了。它最主要的几个特性,一是性能上提升、InnoDB方面的性能提升,还有复制极大增强,以及查询优化器开始支持基于代价的规则。 并原生支持JSON。 Performance_Schema增加了众多信息。 新增sys schema,管理更方便了。 安全性提升。 GIS增强。 性能增强 这是5.7和5.5和5.6的性能对比,可以看到5.7的性能强悍多了,尤其是在高并发场景下。 优化器增强 5.7版本在查询过程中可以增加很多关键字,避开某些执行计划方面的坑。 InnoDB引擎 最瞩目的无疑是可以在线修改InnoDB Buffer Pool,由小改大几乎没有影响,由大改小只需要释放部分内存,影响也不大,可做到秒级完成。 InnoDB Buffer dump and load增强。 Temporary table增强。5.7版本InnoDB的临时表可以单独放在自己的临时表空间里,此外临时表不会再记录redo。 Online DDL增强,在线增加VARCHAR列长度。在不跨越255字节长度的前提下,可以把字节数直接进行在线调整。增加VARCHAR长度几乎无额外代价。 InnoDB Monitor取消innodb_xx_monitor机制,改成另外两个选项控制。 支持更多page_cleaner线程提升purge效率。 表空间文件迁移增强,增加对分区表空间文件支持。 自动检测设备是否支持原子写,确认后关闭double writebuffer。 索引更新效率提升3倍以上。 InnoDB表分区性能提升,尤其是在有大量分区情况,且内存消耗更少。 支持spatial indexes,检索更精确。 透明data page压缩,压缩比变化不大,但读取效率高多了。(尤其是在慢速I/O设备上) MySQL复制 真正实现多线程并发复制。 多源复制。把多个主服务器上的数据复制到从服务器上,这样的好处就是可以做到数据汇总,在数据分析业务场景中非常实用,也可以提高服务器资源利用率。 复制性能提升。减少master上的dump thread并发锁,提高并发率。 半同步复制更可靠更灵活。接收、发送信号线程分离(串行变并行),提高复制效率。 组复制类似PXC架构,可以实现多节点同时写入,同时提供读写均衡。 复制管理更方便。无需完全停止所有SLAVE线程即可在线执行CHANGE MASTER TO。可在线修改REPLICATION FILTER规则。执行SHOW SLAVE STATUS无锁,不再被阻塞。 Mysqlbinlog解析binlog同时支持rewrite规则。 PERFORMANCE_SCHEMA 内存统计视图有助于更快理解内存分配情况,以及找到内存泄露原因。 通过事务相关图,可以看到事务延迟,事务隔离级别,是否自动提交以及GTID信息。 MySQL复制相关图可以看到复制相关信息,可以取代SHOW SLAVE STATUS。 SYS Schema 从SYS Schema可以快速获取锁等待、内存分配和SQL统计。 查看I/O读写最多的文件。 查看热门SQL top10。 安全性 数据库安全增强。 初始化时采用随机密码。 只创建root@localhost账号,再也没有匿名账号。 不创建test库。 设置密码有效期,过期不予连接。 密码过期或首次登录需要设置新密码。 今天的分享到此结束,谢谢大家!
内容来源:2017年4月8日,第四范式资深测试开发工程师孙高飞在“饿了么技术沙龙【第四弹】北京研发中心测试专场”进行《docker搭建大规模测试环境的实践》演讲分享。IT大咖说作为独家视频合作方,经主办方和讲者审阅授权发布。 嘉宾分享视频地址:http://t.cn/R9UCnpq 困境 当今互联网行业发展迅速,产品架构逐渐复杂,导致环境搭建困难。 测试环境不一致。 因为搭建环境困难,环境不多,所以一套环境有多人使用,容易造成环境的互相踩踏问题。 随着业务的发展和时间的积累,我们发现case越来越多。我们希望能够用分布式的执行方式在多台机器上并发执行,以提升执行速度。但是测试机器稀缺,速度依然无法提升。 解决方案 自动化 搭建一个环境必须做到一键部署,在迁移、实践和删除环境中也要做到自动化。 标准化 标准化用来解决测试环境不一致的问题。我们希望测试环境、开发环境甚至生产环境都是一致的。 集群化 根据以往的经验发现,测试资源是一种比较稀缺的资源。要把测试环境扩展到一定的量级,使稀缺资源变成普通的、人人都能简单获取的一种资源,这样就省去了复杂的流程和排队等待的过程。 DOCKER 容器技术相较于虚拟机来说还是非常节省资源的。Docker不需要运行完整的操作系统。在一个宿主机上运行的所有容器都是共享宿主机的内核,所以每启动一个容器,都比虚拟机节省了一个内核的空间。 简化了运维成本,极大降低部署环境的学习门槛。 假如公司新进了一批机器,要把环境迁移到某些环境上来,只要把它做成镜像,就可以很方便地进行迁移。而且这些镜像都是一致的,通过制作镜像可以解决标准化的问题。 容器的启动速度和删除速度都是秒级的,有些不是长时间运行的服务在用完后就能将其删除。这样docker的宿主机就始终能保持一个低压力的状态。 把应用程序当成一个个集装箱,全都放在docker里。主要是放基础容器、测试环境和测试执行机器。也可把执行测试机器全部制作成镜像,在需要使用的时候启动它并放进docker里。 网络的玩法 端口映射 在docker默认的启动模式是bridege模式的情况下,docker为我们创建了一个叫docker0的网桥,这个网桥专门负责为容器进行转发。它会给容器分配很多虚拟IP,但这些IP只能在容器内部沟通使用。要是想与容器进行通讯,最常用的方法就是端口映射,把容器端口映射到宿主机上。 这种方式的优点是简单,不用做任何配置。当然它的缺点也很明显,要维护一个很庞大的端口列表,记住每一个环境容器的端口是什么,对外暴露的端口是什么。 固定IP 我们希望这些容器能像虚拟机一样,给它分配真实的IP去访问它。但这个做法会稍微有些麻烦,docker不支持这样做,我们需要利用一些转化规则。 创建一个新的网桥br0,给它分配一个真实的IP,把宿主机的网卡挂到网桥上,同时改变docker的启动参数,默认启动的时候连到br0上。重新划分网段,把所有容器的网段全都分配成和宿主机在相同的网段上。这样启动容器时分配的就是真实IP,并与宿主机相处于同一个网段。 这种方式让外界用户感受不到是在使用容器还是虚拟机,是对测试环境非常友好的一种方式。 但它并不适合在大规模的测试环境中使用。所有环境都有了真实IP,都被放到了真实的网络环境中,如果容器太多就会出现广播风暴的问题。 环境部署 Container模式 Container模式的特点是可以把所有容器绑定到一个IP地址上。 虽然所有模块都装在不同的容器里,但它们都有同样的IP,只是它们用不同的端口对外暴露服务。 它的优点是配置管理,效率高,是对开发最友好的一种模式。 缺点是标准化。因为我们公司产品的一些特性,产品环境并不是这样去部署的,所以可能会出现环境不一致带来的一系列问题。 打包模式 有多少模块就并发启动多少容器,这些容器的网络模式可以用host。Host的特性是把所有容器的网络环境挂载到宿主机上。把这些并发编译后上传到FTP上,然后启动一个或多个部署容器。 打包模式的优点就是标准化。但它的效率不如Container模式高。 存储的玩法 外部存储 把数据库放到容器外面,在容器内部和数据库进行沟通,保证数据库不会造成数据的丢失。 Volume存储 这是docker比较推荐的一种方式。它允许把容器中的某个路径挂载到外部设备上。比如挂载到宿主机上,容器实时向文件中写数据,宿主机上同时也会保存这份数据。 集群 我们想要提供一个统一接口去管理集群上所有节点,所以考虑使用一些开源的分布式框架。目前在业界最火的三种框架就是mesos、Kubernetes、swarm mode。 Mesos诞生的时间非常早,专注于资源调度,后来docker火了之后才兼容了docker。它的调度框架的二次调度,只装一个mesos是不够的,还依赖于很多其它的东西。Mesos发展得越来越复杂,需要专业运维去支持,所以mesos并不适合作为测试环境的框架来使用。 Kubernetes是google内部集群框架block的一个开源版本。它当时是为docker设计的,而现在Kubernetes慢慢开始兼容其它平台。Kubernetes原本应该是最复杂的集群管理框架,google提供了客户端工具,把很多内部细节封装起来,简化了它的使用方式。它最近推行的容器化部署也极大降低了Kubernetes的使用门槛。 Swarmmode是从docker1.12版本开始内置到docker引擎当中的,非常简单。它把所有需要的东西全都内置到了一条命令上。只要运行一次这条命令,所有的服务发现、跨节点沟通等等的负载均衡都已经做好了。Swarm mode是三种框架中最简单的一种,但并不灵活,功能也没有那么强大了。 K8S基本概念 POD Pod是Kubernetes一个逻辑的概念,是一组容器的组合,是Kubernetes在一个节点上控制的最小的逻辑单元。 Deployment 可以把Deployment看成一个守护进程,如果把一个Pod挂载到Deployment上面,它能保证Pod始终运行。要是监控到定义的这组Pod某一个节点挂了,容器也都挂了,它会利用调度系统找一个合适的节点启这些Pod。Deployment可以关联多组Pod。 Service Service同样可以关联到多组环境上,帮我们做负载均衡。当有请求过来的时候,Service会自动分配到各种不同的Pod上去。假如出现了运维事故或IT事故,一个节点挂了,它会自动切换到其它几个节点的容器上去运行,不会影响到它的服务,保证了PM的环境是始终存在的。 安装服务 从单点扩展到集群,复杂度就提升了。 首先要关注的就是跨主机通信问题。Docker分配的是虚拟IP,只能在一个节点的容器中互相沟通。扩展到集群之后,要装一个网络插件来解决问题。 容器之间要互相沟通,必须知道对方的IP地址。Docker在每次启动的时候IP地址都会改变,要有一个DNS去注册域名,在配置文件中做通讯的时候执行这个域名就可以了。 要知道容器运行消耗了多少资源,应该再安装一个服务来做容器级的监控。 Docker变向集群化的时候,就面临了镜像如何在每一个节点上进行分发的问题。所以要有一个镜像仓库来存放所有镜像,每个节点都会拉最新镜像进行部署。 以上是我今天分享的内容,感谢聆听!
内容来源:2017年5月21日,豆子科技首席架构师钟声在“饿了么java专场”进行《Java的纯真年代》演讲分享。IT大咖说作为独家视频合作方,经主办方和讲者审阅授权发布。 嘉宾分享视频地址:http://t.cn/RSXPHEE 很多人已经忘记了Java的纯真 用Java去写跨平台的基础软件,利用java优秀的网络处理能力,去探寻异构系统跨平台java多线程服务程序。 Java的Socket程序也许是用得最多的一个应用方向。每天都在为java多线程的开销而烦恼,不断的进行性能诊断和系统的优调。 有时候为了解决java内存消耗太大的问题彻夜未眠。为了降低内存的消耗,减少与磁盘交换数据的可能性而烦恼。为了让java程序跑得快,不断的去尝试简化应用程序。 互联网让纯真,再次回归 快速上线 快速地将程序开发出来,并快速地进行部署上线。如今互联网越来越快,产品的推出也越来越快,公司和公司之间拼的就是速度。 高并发 用户量一旦增大,后台的服务器和架构要能支撑得住。 海量数据 大量数据在提供服务,要在海量数据中做数据挖掘和数据分析,为客户提供所需的东西。 Saas Saas做一套系统供很多企业用户使用,用户看起来觉得每个系统都是他的私有系统,实际上是同一套架构。 而以上这些在有些程序员眼里,好像跟java是无关的。 那么再看看一下这些与java有关吗? 5000次/秒并发的服务; 1w台网络设备监控指标采集只需9秒就能完成; 从每天数据增量在20GB的数据库里拿出数据出图表; 高并发的DNS Server; …… 这些都是用java写的。 一则故事 曾经有一个java开发团队项目中遇到了一个“数据导出速度慢”的问题,原因是由于其导出方式导致大数据量在网络上传递,导致网络传递速度慢进而影响整体导出速度慢。 然而这个团队的主管错误地认为,这是由于java本身的速度导致的。于是花大力气招聘C语言工程师来重新完成这个程序的编码。 最终,C语言工程师开发了近两个月,由于完全仿照原java导出程序的程序处理方式,结果依然没有任何改进。 这个主管没有从影响导出速度的“大数据量”方面入手解决问题,而是想当然的认为对速度的影响主要来自于java语言本身,最终导致了程序的失败。 锋利的设计 作为java程序员,我们不要“青龙偃月刀”,而是需要“红缨枪”,一枪命中。 想要“青龙偃月刀”的程序员,总是想要完美无瑕疵,就怕有人说自己不专业,程序设计得就越发复杂,滥用设计模式。被架构师“拖死”的公司比比皆是,真是哀鸿遍野。 很多老板误认为投入足够的资金和人力就能开发出优秀的系统,其实不然。就好比一个丑女即使全是戴满金条,依然还是丑女。而最终唯一的结果只是浪费了资金。 它的好处就是完整地实现了HTTP协议,方便控制缓存和触发机制;对HTTP的接收和返回进行了改造,提高灵活性;省去了原来HTTP一些标准复杂的协议细节。 这个架构在1w台网络设备监控指标采集只需9秒就能完成。 这是一个高并发的DNS Server。 Java是纯真的 让我们变得不再纯真的并不是Web开发工作本身,让我们不再纯真的是包裹在一个单纯的java开发技术外的复杂的、八股的、晦涩的概念,让我们变得越来越虚伪,越来越务虚。 我们应让java自由、直接、透明、简单、高效,像匕首那样锋利,像战士那样勇猛,像农夫那样朴实。 反对繁琐华丽的设计,反对架床迭屋的层层抽象,反对复杂的结构和不必要的灵活性。 我的分享到此结束,谢谢大家! ---------叶子分割线---------------------------- 福利赠票! IT大咖说作为第二届APMCon中国应用性能管理大会的官方现场直播合作伙伴,特为小伙伴们争取了少量免费VIP票福利(原价¥1388)! 获取方式: 扫码加这位小姐姐微信(或加微信号:ITDKS666),她会告诉你咋获取!(备注:听云社区) 小茉莉
内容来源:2017年5月13日,饿了么资深Java工程师朱杰在“Java开发者大会 | Java之美【上海站】”进行《老树新花-Java异步服务开发》演讲分享。IT大咖说作为独家视频合作方,经主办方和讲者审阅授权发布。阅读字数: 1901 用时: 13分钟 嘉宾演讲视频地址:http://t.cn/RKtxNEE 同步模型 以前在并发量很低的情况下,是通过线程去收取数据并发送数据给客户端。但是当并发量和客户端连接数比较高的时候,服务器会出现明显的瓶颈。 阻塞模型比较符合人的思考逻辑,但它会有线程阻塞的问题。阻塞模型会让出CPU,不适用于高并发。 线程池或连接池只能解决一部分问题。因为线程池和连接池的本质作用并不是能直接提高QPS,而是减少或销毁线程的连接处以及开销。 我们平时调用阻塞API的一个问题就在于单机的线程数是有限的。所以如果要提高服务端性能的话,首先就要去阻塞。 异步模型 异步阻塞模型处理I/O时大部分时间是非阻塞的(监听时除外),它调用的API会立即返回,这点是需要注意的。此外,处理结果的程序并不保证调用API当前的线程,这点在处理线程安全的问题上尤其要注意。 Java中很多API都是基于操作系统底层API的模型,并没有做更高层次的封装。 Java把一层阻塞异部I/O做了封装,这些就是Java或C语言异步模型的基石。 少数线程等待事件发生,再根据对应类型处理相关事件。 最近“协程”这个词比较火,看上去能解决异步模型的大部分问题。它是一个轻量级线程,可以直接当作线程来用。还能阻塞I/O API,阻塞的是协程而非线程。 协程是用户态资源,用户态调度,消耗极低,可以启动数十万个协程。 它的实现和线程不是1对1 的关系,难点在于编程语言的内部实现。 Python虽然支持协程,但是由于全局解释锁的关系,同一时刻只有单个CPU在运行。所以python选择多进程+协程的做法。 Go语言完美解决了支持不阻塞线程的I/O操作,并支持多线程。 要能像同步I/O一样编写代码,不会创造过多数量的线程。尽量让CPU处于忙碌状态而非等待,并寻找满足以上条件的Java库。但是Java由于本身语言的问题,即使是Java协程三方库也只能部分支持协程。 退而求其次,我们只能使用Java异步工具库。如果要提高并发量,可以使用异步JDBC和异步HTTP CLIENT,这个库基于NETTY。 做到服务异步化,要查看接口是否可支持异步。还可以使用Java的异步工具库,比如Java的异步数据访问方式和异步HTTP CLIENT。如果使用的是三方框架,可以修改调用方式,有的框架支持异步回调和事件监听。最重要的是要注意线程安全问题。 异步化的优势就是极大提高了I/O密集型业务的性能,保守估计有10~100倍,也就解决了线程数创建过多的问题。 而它的缺点是增加了编程难度,包括状态保存、回调处理以及线程安全等。也存在压垮下游服务的问题:) 老树新花-基于Netty的Java模型 Netty是基于原生的异步模型,封装并优化。它修复JDK中的一些BUG,提供了多种辅助类方便开发。编程模型高效简单,开发者只需关心具体实现逻辑即可,基本不用花精力做Java网络层面的优化。此外,Netty成熟稳定,业界使用多,我们能够相信,使用它不会遇到难以解决的大问题。 Netty基于事件连接,如果有数据传入以及连接上有异常事件或自定义事件,只需复写它的回调函数就能做相应的处理。 Netty所有I/O API全都是消除阻塞异步化。线程模式也非常好,它单个连接上的所有I/O事件都由同一个线程执行,避免了线程安全问题。 Netty的单个链接绑定一个线程,EVENTLOOP即一个线程,EVENTLOOPGROUP是一个线程组。 Netty任何的I/O API都是产生一个任务,放入该连接对应的线程里执行,做到局部串行化。 Netty一切操作都是以事件驱动来执行,所有I/O API都是用异步+回调监听的方式来处理消息。单一的连接处理都在一个线程里,来避免线程安全问题。 案例-饿了么数据库中间件 我们是一个实现了MYSQL协议的中间代理服务。上游至少要支持上万客户端的连接,下游要支持上千数据库连接。 为了快速实现功能,我们最早是找了一个基于GITHUB阻塞I/O开源库,首要任务是把同步改为了异步。 线程模型的上下游各有Netty的一个线程组,中间件内部还有一个处理业务的线程组。 但有一个最本质的问题在于这三个线程组之间的线程安全得不到保证。 因为这个中间件前后端都是异步的,所以按正常流程是由协议来保证顺序执行,而异常中断是并发执行的。 参考Netty,我们把每一个连接绑定到一个单线程池,保证Task串行执行。 前后端异步的好处在于模型简单,便于后续修改。 我个人认为,在程序里过多的使用WAIT/NOTIFY/LOCK不一定代表良好的多线程编程能力,却可能代表这是不够优雅的设计。 除了前后端异步和信号量控制异步,在中间件中我们还用到了日志异步、心跳异步、JOB异步和配置变更异步。 在饿了么数据库中间件开发过程中,异步化所有API以去除阻塞,局部串行化解决线程安全问题,模型简单,易于修改和理解。 今天的分享就到这里,谢谢大家!
内容来源:2017年5月14日,大漠穷秋在“OSC源创会南京站”进行《Angular 4.0核心特性》演讲分享。IT大咖说作为独家视频合作方,经主办方和讲者审阅授权发布。阅读字数:1354 | 8分钟阅读 摘要 基于最新的Angular4.0版本,超级大咖大漠穷秋为我们讲解强大的集成开发平台Angular/cli,以及Angular最核心的3大概念:组件、模块、路由。 嘉宾演讲视频地址:http://t.cn/RKc9GNc 集成开发环境@Angular4.0 2009年,出现了node.js。它的出现标志着前端开发正式进入了工业化的时代,前端工程师这个职位得以确立。 Node.js出现后,才有了完整的工具链。 @Angular/cli 我们需要有一个统一的node.js模块把所有node工具集成在一起,Angular/cli就是这样一个平台。命令行工具可以创建出里面所有的组件或概念,在生成目录结构的过程中,还会生成代码的模版。 但是Angular/cli也有一些“坑”。 在Windows下面,node-jyp这个包依赖于Visual Studio,node-sass这个node模块也被墙掉了。所以强烈推荐使用cnpm安装。 Angular/cli把打包、压缩等工作全部分装在命令行里面,并集成了test的所有功能。 Angular中的3大核心概念 Angular中的3个核心的概念分别是“component”、“module”和“route”,“组件化”是Angular最核心的概念。 Component 在新版本Angular里采用了不可变数据类型,帮助执行脏检查机制。 Angular2-dependencies-graph是一个node.js的模块,通过它把项目的目录和结构生成图表,就可以清晰地知道自己写的模块位于项目的哪个位置。 NgModule 在真正开发业务系统的时候,光有UI组件是不够的,还有服务、路由以及各种各样的directive。 模块是用来组织业务代码的利器。把应用切分成多个模块,当用户进入index页面的时候,只加载其中的bundle-0.js,当用户点到对应模块的时候再加载其它的代码。 切分模块的时候,需要在业务的文件体积和请求数量之间取得一个平衡。 Router 如果没有router,浏览器的前进后退按钮就不能用,也无法把URL拷贝并分享给你的朋友。 Angular新版本中静态路由只要写component属性,说明这个路由需要交给哪个component来处理,Angular就会自动创建这个component并渲染出来。 做异步路由时要注意的是,写的是loadchildren,加载的对象是module而不是component。由此可见,NgModule是用来配合Angular/cli做模块的打包和加载。在Angular新版本里,module是最小的打包和加载单位。 路由守卫用来防止未授权的访问。在前端需要对路由做一定的防护,但目前的防护还远远不够,最重头的还是在server端,Angular就提供了这样一些特性。 Angular架构特色 Angular是第一个把依赖注入这个思想带入到前端开发里来的。 在Angular里,依赖注入只有构造器注入这一种方式。只要在构造函数里写需要应用到怎样的属性,Angular会自动创建它的实例并注入class。 注射器也是一个树型结构,在每个标签上都有injector的实例。 Angular还有一个最重要的设计特色就是数据绑定,它实现了双向数据绑定。双向数据绑定最低层有一个脏检查机制,要做这件事非常的难,所以在Angular之前没有人去做双向绑定。新版本的Angular重写了脏检查机制,不会再出现效率问题。 UI库 在Angular里面已经有一些比较成熟的组件库可以用了。例如ng2-bootstrap、PrimeNG和官方提供的Angular-Material2,在移动端也有Ionic支持。 参考资源推荐 ng2-admin:这个项目做得比较庞大,它里面的图表、地图插件、list和UI形态等都已经集成好了,可以把它拉下来再自己去做改动。 JHipster:它的后端基于SpringMVC。前端用户Angular做它的前端框架,它实现了Angular1和Angular2两个版本,选择范围比较广。可以利用它快速搭建应用框架。 今天的分享到此结束,谢谢大家! 福利赠票! 炎炎夏日,IT大咖说赠福利,送清凉!作为GOPS全球运维大会的官方现场直播合作伙伴,特为小伙伴们争取了免费票福利(原价¥1600)! 获取方式: 扫码加这位小姐姐微信(或加微信号:ITDKS666),她会告诉你咋整!(备注:GOPS) 小茉莉 名额有限,未获得赠票的小伙伴,可访问IT大咖说专属通道(http://t.cn/RKQIv6q)购票,享7折优惠! 原文地址:http://t.cn/Ros8b2x
2017年3月26日,ThoughtWorks高级咨询师张帅、王智勇在“Mobile Open Day—小步构建移动开发知识网络”进行《Getting started with Kotlin on Android》演讲分享。IT大咖说作为独家视频合作方,经主办方和讲者审阅授权发布。 嘉宾分享视频地址:http://t.cn/RKwZwbZ Java VS Kotlin 在Java的使用中会遇到很多问题。它的语法繁琐,API低级;随时可能出现null pointer问题;有各种各样的util类和混乱的泛型。 Data Class在Java Bean里有成员函数string topic、string type和list speakers。 Getter/Setter可以使Java成员既有封装性,又能对外暴露很多接口。 还有很多其它的方法,比如toString、hashCode和equals。 Singleton 而Kotlin要实现一个单例,只需一个关键字“object”。 OptionalNull pointer是代码中一个常见的bug。 Late-Initialized&Lazy在代码中经常会遇到一些方法,它们不需要在构造函数中进行初始化操作,这时就可以通过lateinit var关键字把它声明成懒加载模式。 Full name是通过last name和first name组装起来的,只有用到full name的时候,才会调出lazy的这个表达式,生成一个值,非常方便,解决了懒加载的问题。 Extensions在Java中,要想扩展一个类,我们会写一堆Utils。 而在Kotlin中,我们可以直接对double对象进行扩展,再也不需要Utils的类了。 Collections常见的Collections有Stack、Map、Queue和List等等。 在Kotlin中把Collections分为mutable和immutable两类,这样有助于消除错误,设计更好的API。 Generics我们要创造一个协变的应用才能引用它子类的集合,与之对应的还有逆变。 在Kotlin里数组默认不是协变的。 对于不可变集合是默认协变,可变集合默认是逆变的。 总结一下Kotlin提供了高级的语法,例如data、object等。 对于null pointer问题,它有optional对象。 有val、late-intialized、lazy和Collections支持。 可以用扩展语法让代码更加可读。 Generics简单好用。 Kotlin cool feature Inline function如果在开发过程中发现有性能问题,可以把代码进行优化,在代码运行起来之后,body block会被封装成一个函数对象。加入了Inline,body就会被Inline到函数调用的地方去。 Inline还有个功能叫reified。当我们读取网络返回的时候,会用Gson来解析字符串,在写的过程中会发现语法有冗余。引入reified以后,可以把类型声明成reified,这样在函数题里就会引用到这个类型具体的Class。Kotlin有一定的类型推导功能。 Sealed ClassSealedClass可以限制住一个副类一共有多少个子类。 Delegated properties对于一个property,可以把它Delegated一个对象上,每当读写property的时候,它都会调用对应的函数。 CoroutinesCoroutines把回调式的写法改成了流式的写法。 总结一下Inline function减少了运行的开销。SeadledClass限制了类的层级。Delegate使得代码更加简洁。Coroutines提高了异步代码的可读性。 Kotlin in Android 在Android上有一个常见的类叫做viewholder。 Kotlin在Android上可以自动把view找出来,不需要手写代码。 Kotlin's Reference 引入Kotlin 已知问题Kotlin与mockito的兼容性。在Kotlin里的静态代码检查工具还不完善。Kotlin对于Java里的一些关键词和操作符的语义做了改变。 以上是我今天分享的内容,感谢聆听! 福利赠票! IT大咖说作为7月24日OpenStack Days China大会(在北京国家会议中心举行)的官方现场直播合作伙伴,特为小伙伴们争取了少量免费VIP票福利(原价¥600)! 获取方式: 扫码加这位小姐姐微信(或加微信号:ITDKS666),她会告诉你咋整!(备注:openstack)
内容来源:2017年5月20日,乐逗游戏高级数据分析师在“第十届中国R会议软件工具专场”进行《HTTPS最佳安全实践》演讲分享。IT大咖说作为独家视频合作方,经主办方和讲者审阅授权发布。 阅读字数: 753 用时: 3分钟 摘要 本演讲将介绍如何利用CSS对shiny页面进行个性化设计及在网页中嵌入视频;并通过一个详细案例介绍了利用htmlwidgets包开发HTML控件,基于D3.JS库创建简单的交互桑基图,包括控件创建、函数修改、数据调用及与shiny结合的演示。 嘉宾演讲视频地址:http://t.cn/Ro89hHa 利用css对Shiny页面优化 添加CSS的三种方式 CSS为HTML文档提供了一种复杂外观的样式语言。由于Shiny应用程序用户界面(UI)是一个HTML文档,可以使用CSS来控制Shiny应用程序的外观。 要用CSS美化应用程序,常用的有三种方式。 1、创建一个样式表,把它放到www目录文件下:在应用的当前目录下,创建www文件夹,把CSS样式放在www目录里。对Shiny自带的“03_reactivity”例子添加个性化样式。 2、把CSS添加到HTML标题中。 3、将样式直接添加到HTML控件标签中:直接在用户界面中的单个HTML元素中添加CSS样式,优先级高于其他的CSS源。 给应用增加登录窗口 免费的Shiny没有权限控制,如果掌握一些基本的CSS知识,就可以轻易地给应用添加一个登录窗口。 利用htmlwidgets包创建HTML控件 下载d3plus.zip 利用htmlwidgets包调用d3plus.js库,生成交互式图表。 创建新包 创建一个新包,包名为myd3plus,将会生成treemap.R、treemap.ymal和treemap.js三个文件。 创建lib目录,存放js文件 将下载的d3plus.zip解压,把里面的文件d3.js和d3plus.js拷贝至htmlwidgets/lib目录下。 修改treemap.ymal的文件配置 修改treemap.ymal的文件配置,该文件是用来设置控件依赖的js库。 Stylesheet是用来指定特定的CSS格式,此处不添加。 修改treemap.R的文件配置 在treemap.R中,删除message=message命令,增加data=data命令。 安装包 运行devtools::install()对myd3plus包进行安装。 运行treemap函数 构建简单数据框,运行treemap函数,查看效果。 与Rmarkdown结合 利用htmlwidgets包创建的控件,很容易与Rmarkdown和Shiny结合。 我的分享到此结束,谢谢大家! 相关推荐 推荐文章 百度外卖如何做到前端开发配置化 阿里巴巴前端专家渚薰:H5互动的正确打开方式 近期活动 直播 | 2017红象云腾大数据基础软件V5.0发布暨合作伙伴大会 点击【www.itdks.com】进入干货密道
在科技风暴中,我们感受到了AI的巨大力量。 万物互联,声动世界,基于近十年的技术积淀,思必驰潜心打造优质语音方案,数亿用户通过思必驰语音实现了与智能产品的自由对话。 AI展现了科技的无限价值,面向AI开发者们,思必驰即将重磅推出DUI开放平台:有意思的智能对话定制平台,随心所欲,自由定制。 7月7日-9日,全球人工智能与机器人峰会(CCF-GAIR)将在深圳拉开帷幕,全球范围内最顶尖的学术专家、企业领袖、明星创业团队和风险投资人们将在大会现场共同探讨人工智能未来趋势。思必驰,作为国内专业的人工智能语音企业将出席CCF-GAIR大会,并带来思必驰DUI开放平台的首次亮相。 “思必驰DUI开放平台(AISpeech Dialogue User Interface),一站式开发,高可用定制,覆盖多应用场景和丰富的第三方内容资源,内置国内最专业的语音及语言技能库,为物联网、移动互联网和互联网的开发者提供单项技术服务和完整的智能对话交互解决方案。 伴随着人工智能技术的猛烈浪潮,车载、家居、机器人等领域的智能硬件层出不穷,强大的市场需求推动着AI技术向更广阔的领域拓展,向更快捷简单的方式变迁。思必驰是技术驱动型团队,具备平台级的技术能力和基础研发能力,这是思必驰DUI开放平台诞生的先天优势。 早在2014年,思必驰即发布了国内第一个口语对话系统平台"思必驰对话工场",在国内首次提出“对话服务”的概念,开放底层的ASR、TTS、NLU等SDK接口,设立专门的技术支持团队。为追求体验升级,打造高可用定制的对话平台,2016年初,思必驰开始策划DUI开放平台并结合业务进行了模块化尝试,2016年底,升级成为公司重大战略方向之一。 我们脚踏实地,针对中国市场的实际需求,力求打造更独特更具开创意义的人机对话系统定制平台。 思必驰DUI开放平台是一站式的高可用定制平台,打造专业技能商店,提供云+端混合方案,具备高可用定制、多场景覆盖、数据可视化、个性自定义、开发零门槛等功能优势,思必驰DUI开放平台将从综合性、完整性和服务性等方面打造核心竞争力。 思必驰DUI开放平台暂未正式上线,现以Workshop形式进行小规模体验,首站“开发者实战营”将于7月7日在深圳举行,携手CCF-GAIR大会,邀请业界资深人士及百位优秀的开发者共同参与,现场实操,体验DUI定制技能的开发乐趣。 详情 主题:AI is DUI,思必驰开发者实战营 --------7分钟创建一个定制AI 时间:2017年7月7日14:00-17:30 地点:深圳市福田区福华路大中华喜来登酒店6层 合作单位:机器之心、机器之能、雷锋网、华院数据、开源中国、CSDN、51CTO、B12、IT大咖说 线上直播: 扫码报名 看直播 >>>> 这些看点不容错过 大咖首秀:思必驰神秘大咖首次亮相,亲自解读玩转攻略! 独家权限:获取独家内测使用权限。 现场实战:随机挑选开发者上台,零距离体验。 超嗨Q&A:知无不言言无不尽! 奖品多多:创意周边+大奖,程序猿必备! ……….... 更多平台功能亮点、活动看点将再次推送曝光! 点击http://t.cn/RKvTQvW了解详情。
编辑IT大咖说阅读字数: 2672用时:8分钟本文内容来源于任伟在【沪江技术沙龙】-漫谈微服务架构实践上的主题演讲,IT大咖说为沪江技术沙龙独家视频知识分享平台。 内容摘要Bilibili作为一个大型弹幕视频网站,在竞争日益激烈的互联网行业中,开始重视技术生态的演进,探索寻求适合企业本身的一个微服务架构。本次分享主要讲述了B站高性能微服务架构的演进。 大家好,我是来自bilibili的任伟。今天的分享分为三个部分内容: 曾经的价格体系。 面临的一些痛点问题。 高性能微服务架构在B站的落地。 曾经的价格体系 B站从成立至今已经有将近八年的时间了,但是从前两年我们才开始重视整个的技术生态的演进。在整个B站的代码体系里面,我们曾经也把B站的老代码称之为全家桶。因为它是一套代码,涵盖了几乎所有bilibili里面的业务体系。我们现在的引进方向以科研为主,整个B站光是网站这一块,就有很多的分支,而整个的分支对应的域名也很多。 B站以前代码的体系从安全体系上来讲,我们进行了一系列的拆分。整个的代码仓库主要分为三个部分,一是主站的业务逻辑,还有一个是分发管理的逻辑,以及配置文件。配置文件整体的发布是一套非常繁杂的流程,它用脚本的方式把整个配置文件慢慢的生成,而这些跟本身主张的代码逻辑是隔离开来的。 我是一个工作很多年的PHP研发。在接触B站之前,我一直认为PHP的业务结构开发速度会非常快。但是了解了B站的代码就会发现,其实用PHP语言体系来做的事情非常多。就目前而言,整个B站的运维体系的工具都是由PHP来完成的。因为我们是一个视频类的网站,最重要的就是视频资源的管理,而这个调度其实一开始也是由PHP来完成的。 下面图片是一个我们的业务集群,主要分三大块,一块是面向移动端的服务集群,一个是面向PC端的服务集群,还有一个就是面向弹幕的。 面临的一些痛点问题 整个B站曾经的体系是非常庞杂的,这么大的一个系统面临着很多问题。 代码和文档问题 就代码来说,维护的难度非常大。对于研发而言,如果我们只是关注某一块的业务逻辑,就好像管中窥豹。而且最重要的是它文档缺失。虽说一个好的编码习惯就是一个好的文档,但在业务量或整个体系比较庞大的情况下,文档和代码还是有本质区别的。 B站是基于各种网站慢慢成长起来的一个企业,所以当时在做这块的时候没有特别重视,文档一直有比较大的缺失,导致代码维护非常麻烦。 基础架构 整个的基础架构是基于织梦CMS,是一个比较流行的开源的内容管理系统。绝大多数业务逻辑我们做了一些深度的定制,导致一般研发很难搞定前面底层里的一些逻辑。 业务机会聚合在一起,不易被扩展和拆分。B站在发展到前两年的时候,让运维独立去搭一套整个B站的扩展体系并不是那么容易,B站的运行环境基本上只能通过创始人来扩展我们的负载。 运维复杂 运维复杂,因为配置也是相当复杂。后来已经不允许在运维再增加业务上的一些重写逻辑,只有让代码这边自己去处理。所以重构优化,我们已经提上了日程。 我们公司成立的基础是一个天才型选手,以前在那套系统加入了一些黑科技的东西,但同时就限制了公司团队的发展。 基于这样的一些重点问题,我们在去年开始思考怎么来解决B站目前面临的这些问题。因为B站发展速度非常快,业务的发展导致团队也会不停的增长,我们需要考虑各方面的因素。我们需要有一部分的业务要参与进来,然后梳理出来,再进行一系列架构方面的重组。 高性能微服务如何在B站落地 通过整个的服务体系我们可以看到,基本上以命名规则可以看到service里面的一些内部服务。对于终端和PC端,我们都是以show和interface作为作为项目向外透露接口,他们的区别就在于show是一个单纯的业务,它有紧急预案和service。但是interface会做一些数据的聚合。服务间的依赖标准主要是RPC。 介绍完大体框架之后,我们先看一下为什么当时B站会选择go语言作为技术站。我们选择go主要是因为它的执行和开发效率非常的高效。相比其他语言,优势还是挺明显的。比如我们主站的首页的动态图,每五秒钟需要获取各个分区里面的最新稿件,订单访问量是非常大的。利用go服务可以明显地感觉到移动端的访问量占整个B站的访问量已经达到了60%以上,但是他那边基本上所有的服务接口都不走CDN,直接打到元,他们那边量也是非常大,但是也没有出过什么错。 B站go语言成长非常迅速,因为它的背景是google,生态也比较丰富,支持kafka、canel、hbase这些比较流行的风格式管理框架。鉴于此,我们就选择了go语言作为我们整个公司的在技术上的统一。而且相对而言,它的调用效率要比http比较高,就是我们不走apI接口接收内部的RPC。 为什么说B站微服务在整个经营效率上会这么高呢,除了它本身语言体系上没有其他语言那么臃肿之外,我们还做了一些努力。比如在整个的对外服务的这一层上,基本上没有任何的请求可以直接打到DB,全部是缓存。我们都是通过多层缓存机制来保障的。 我觉得微服务最重要的一点就是服务隔离。在实际项目中我们也遇到很多问题。因为公共资源,导致某一个服务和资源挂钩,会拖垮相应的服务,所以说服务隔离非常重要。 选择go的另外一个重要原因就是它本身跟docker的结合有天然的优势。因为go语言的运行环境非常的精良,它不需要依赖于任何的其他的环境。所以我们动态的管理相对于其他项目来讲的,是整个公司里面最干净的docker。我们的团队也会做服务巡查。某一个服务如果出现问题都能第一时间来反馈到我们的平台里。 go语言的几个基础 数据总线中间件 数据总线中间件,叫Databus。它是一个面向redis协议背靠kafka的消息中间件,它是基于内地市场放上的行为,主要目的就是用来deal。 数据库deal 我们主张直接更新缓存,并把消息推送到数据总线,然后由数据总线来更新数据库。 我们这边本身也有一些稿件的时候,比如说用户提交的一些视频,在我们这边的话会有一个基于canal的go服务,这个服务的主要作用就是在于监听数据库日志,来解析出数据库里面的更新和参数方程,来更新缓存。 我们自己魔改了twproxy,这是一个开源的想法。我们自己做了一些二次的开发。因为以前bilitw是单进程,我们这个是一个多进程的魔改负载均衡的组件。 配置中心disconf也是我们自己研发。基本上我们以自己造文字为主了。也做了一套自己的小文件存储系统BFS。这套系统跟当前比较流行的一些云存储还是很像的,它的吞吐量足够大,扩展性也足够好。 B站发展到现在,微服务还只是一个刚起步的阶段,我们也在微服务这条路上慢慢探索适合我们的一个微服务架构。我认为适合企业本身的微服务就是最好的。 我今天要分享的就这么多,谢谢! 原文地址:http://www.itdks.com/dakashuo/detail/1179
内容来源:2017年5月23日,亚洲诚信高级技术经理余宁在“世界云计算 · 中国站”进行《HTTPS最佳安全实践》演讲分享。IT大咖说作为独家视频合作方,经主办方和讲者审阅授权发布。 阅读字数:946 | 3分钟阅读 摘要 随着亚洲诚信2016年推出加密无处不在以来,HTTPS的使用成本和技术门槛逐步降低,HTTPS正被越来越多的网站和企业使用。但是我们发现,进行正确的HTTPS配置和安全部署情况并不乐观。此次分享主要向大家介绍HTTPS常见安全威胁以及如何部署安全的HTTPS服务。 HTTPS行业动态 2014年到2015年,Google、Baidu等搜索引擎优先收录了HTTPS网站。 2015年,Baidu、Alibaba等国内大型互联网公司陆续实现了全站HTTPS加密。 2016年,Apple强制实施ATS标准;微信小程序要求后台通信必须用HTTPS;美国、英国政府机构网站实现全站HTTPS;国家网络安全法规定,网络运营者需要保护其用户信息的安全,并明确了相关法律责任。 2017年,Chrome、Firefox将标示HTTPS站点不安全。 HTTP/2的主流实现都要求使用HTTPS。TLS1.3即将发布,使HTTPS更快更安全。 HTTPS安全现状 HTTPS的安全现状仍是不容乐观。 如何让HTTPS更安全 证书选择 首先要考虑证书品牌,看它的兼容性、技术背景如何,口碑怎样,占有率是多少。 审核类型根据审核的强度分为了EV、OV、DV。商用站点最好是选择EV、OV。 从证书功能上来看,又分为单域名、多域名和通配符。而一般情况下,多域名和通配符容易增加风险,所以在能满足基本需求的情况下尽量选择单域名。 常见的证书算法有RSA、ECC等。ECC是目前更安全、性能更高的一种算法。 优化配置完善证书链,提升兼容性。 启用安全协议版本,弃用不安全协议版本。 选用安全性能好的套件组合,弃用一些有安全漏洞或加密强度不高的套件组合。 利用Session ID和Session Ticker实现会话恢复。 漏洞修复通过调整加密协议、加密套件或升级SSL服务端等措施得到修复。 安全加固HSTS:浏览器实现HTTPS强制跳转,减少会话劫持风险。 HPKP:指定浏览器信任的公钥,防止CA误发证书而导致中间人攻击。 CAA:通过DNS指定自己信任的CA,使CA避免误发证书。 OCSPStapling:服务端SSL握手过程直接返回OCSP状态,避免用户向CA查询,保护用户隐私。 MySSL——HTTPS安全评估 HTTP安全概览 HTTP配置建议 1、配置符合PFS规范的加密套件。 2、在服务端TLS协议中启用TLS1.2。 3、保证当前域名与所使用的证书匹配。 4、保证证书在有效期内。 5、使用SHA-2签名算法的证书。 6、保证证书签发机构是可信的CA机构。 7、HSTS的max-age需要大于15768000秒。 MySSL——HTTPS最佳安全实践 我的分享到此结束,谢谢大家! 相关推荐 推荐文章 百度外卖如何做到前端开发配置化 阿里巴巴前端专家渚薰:H5互动的正确打开方式 近期活动 直播 | 2017红象云腾大数据基础软件V5.0发布暨合作伙伴大会 点击【www.itdks.com】进入干货密道
内容来源:2017年5月13日,徐辛承在“H5梦工厂”进行《前端开发配置化方案》演讲分享。IT大咖说作为独家视频合作方,经主办方和讲者审阅授权发布。 阅读字数:2017 | 9分钟阅读 摘要前端开发的主要职能就是把网站的界面更好地呈现给用户,它涵盖的知识面非常广,既有具体的技术,又有抽象的理念。百度外卖高级前端工程师徐辛承,为我们带来关于百度外卖前端开发配置化方案的分享。 内部平台开发中的痛点 所有业务线由一个大的内部平台来完成,最后集中下放到APP中。这个系统的缺点就是重复性工作很多。 以banner配置为例,我们发现页面功能相似度高,重复工作较多。我们之前的开发模式在搭建基础页面时,主要靠复制另一个类似项目的代码,在此基础上进行修改来完成。同时由于一个代码可能要多人开发,代码风格难以统一。 受到了百度H5的启发,我们最终想到要通过一个平台来解决这些问题。百度H5是通过拖拽的方式来生成H5活动页面的一个平台,它的组件非常丰富。它整个页面的设计思路和现在一些组件化框架的思路很相似。它把页面中的元素拆分到以组件为最小单位,通过组件构成一个页面。 但其实它并不适合我们的业务场景。因为在这样一个平台中,我们内部平台的交互无法支持,组件也不能拓展。 我们想要的得是一个简单的平台,所有角色都能使用,拖拽界面适用度高,大家乐于接受。 我们希望任何页面都能用可视化的方式去完成。我们会提供丰富的组件库、交互的配置方式,同时也提供了自定义拓展脚本,通过配置化的方式去生成页面。 因为是我们自己的团队来开发这个项目,所以我们希望这个项目的可维护性很强。我们会用熟悉的技术栈开发,用可扩展性强的方式去挖掘技术栈底层内容,模块会拆分得很详细。 最终基于这些想法,我们开发了Blocks平台。 页面配置平台Blocks 1什么是Blocks?Blocks是一个拖拽+配置生成的系统。组件是页面中的最小单位,Blocks有拖拽形式的页面画布,可以支持组件的添加和扩展、支持自定义脚本。Blocks是基于vue2.0开发。 2页面配置模块 页面配置模块主要分为组建列表、页面画布和设置组件属性。它的输出是config.js,同时会在mapConfig.js里预留事件钩子。 3脚本配置模块 因为现在还没有完全实现可视化,我们在JSON文件里开发扩展脚本,生成了一些事件钩子去更快地开发代码。 4页面渲染引擎 页面渲染引擎是最核心的部分。通过JSON配置文件生成页面,解析组件的配置和层级关系,以及解析配置文件里的自定义扩展脚本,最后渲染出页面。 平台核心设计 1核心思想 我们最初的想法是,输入是JSON,输出是Web Page。后来经过思考发现在一个JSON中实现输入有些困难,所以把JSON拆分为Config.js和MapConfig.js。 2Config.js 3为什么这么做? 因为Virtual Dom Tree结构为object,代码量有明显减少。基于Virtual Dom的实现,它的拓展性是很强的。 4每一个节点 针对每一个Virtual Dom的节点,主要有三个属性。 第一个是Tag,就是节点名称,也可以理解为这个节点用的组件。 第二是Data,节点属性。 Children是这个节点包含的所有节点。 5MapConfig.js 以前用的框架是MVC,Model和View没有框架实现,它们之间的交互都是通过Controller来解决。 这种命令性的开发方式会导致Controller开发效率底下,容易变得臃肿和难以维护。 6脚本配置 在state里它是一个驱动应用的数据源。View以声明方式将state映射到视图。而actions是响应在view上的用户输入导致的状态变化。 但如果把代码中的事件写得很松散的话,并没有办法形成一个配置文件。所以我们运用了Vuex。 Vuex是专为Vue.js应用程序开发的状态管理模式,也是集中管理状态的一个工具,它以相应的规则保证状态以一种可预测的方式发生变化。 Vuex.store是MapConfig.js的一部分,它包含了State、Getters、Mutations和Actions。组件属性在State里,组件预埋的钩子放在Mutations和Actions里,Getters在需要的时候会用到。 Vuex提供了辅助函数mapState、mapGetters、mapMutations和mapActions在平台中进行执行。 目前新增了页面配置模块和脚本配置模块。 7组件的引入 对通用组件库和业务组件做了一次封装。以input组件为例,在写input组件模版的时候需要写一些相应的属性,组件配置模块把这些属性抽离出来,以可视化的模式在表单中进行填写。 每个组件中主要分为index.vue和setting.js。Index.vue是渲染在画布和页面中的一个模版文件,setting.js是一个组件设置表单。 8脚本配置模块 脚本配置模块主要提供了Vuex.store的开发和组建内部事件扩展,未来还会增加常规事件的可视化配置。当公司内部RD接口变多的时候,接口规范会很难做到,如果有一个平台能做到前端的交互和交互的规范,就可以反向约束RD接口的规范,更可以提高开发效率。 平台现状和规划 1收益对比 做这个平台之前,在接口上没有太多的规范。通过这个平台可以约束RD接口进行规范。有了规范之后可以极大地提高工作效率。 之前我们每个人代码风格不同,代码质量很低,难以维护。通过拖拽的方式生成,质量会很高。 原来基本所有的工作都是由研发完成的,现在部分工作可以外放,甚至当页面简单或者平台做到极致的时候,就可以实现0成本开发。 2未来要做的工作 功能:把组件库做得更丰富,尽量支持更多的组件;提供一个组合件的功能和可视化的交互配置。 易用性:增加UI设计,做一些系统交互方面的优化。 落地:对老代码做重构,用这个平台做新项目开发。 我的分享到此结束,谢谢大家! 相关推荐 推荐文章 阿里巴巴前端专家渚薰:H5互动的正确打开方式 微信开发中的前后端之坑 近期活动 直播 | 2017红象云腾大数据基础软件V5.0发布暨合作伙伴大会 点击【http://www.itdks.com】进入干货密道
编辑IT大咖说阅读字数: 1539 用时: 6分钟 摘要 现在越来越多的产品或营销页面,以H5互动(动画、3D)的方式呈现给观众。互动场景的设计、还原、开发、优化,对于前端开发者来说变成了整个业务开发过程中最重的负担。 手淘互动团队用一套流程工具以及一系列技术方案,解决的开发过程中痛点,提高整个周期的效率。本次分享,从前端架构和工程说起,以手淘互动开发为案例,为前端开发者打开互动制作的一扇门。 “交互,是链接用户的桥梁” 交互是HTML技术发展过程中的一个里程碑。很早以前,一个页面就是一大段文本,之后出现了按钮,出现了表单,才有了一定的交互。 交互不只是点击,交互的概念可以涉猎的很广。 对于用户来说,获取信息的方式有两种。第一种是通过被动的去获取页面中信息,第二种是它主动去寻求反馈。 用户通过这两个途径去获得想要的东西,对于互动来说,也需要在这两点上通过自己的创意和技术去表达给用户。 “动画,是展现页面的灵魂” 假如把页面比喻成一个机器人,交互就是赋予了我们一个能对机器人进行操纵的连接。动画能够帮助一个“机器人”活起来。对于动画来说,它其实是动效和时间的一个完美的结合。 动效可以抽象地理解为起始值到终止值之间一个变化的过程。 如果是具体的元素,可以把这个变化的过程做一些映射;对于类似three.js这样的框架,它的对象本身有一些属性,这些属性也能够认为它是一个0-1的动效变化过程。 概括来讲,它们都是一次差值算法。这就是动效的定义。 把动效串起来就是动画。动效负责自己的元素,让它能够运动;而动画则负责把这些动效管理起来。 “除了桥梁和灵魂,还有?” 交互是桥梁,动画是灵魂。除此之外,更重要的是我们需要在H5的互动页面里把它表达出来。 兼容性对互动页面进行一轮机型适配。 性能优化性能在动画、互动页面里,可以直接把它映射为帧。我们需要做的就是JankFree,这样动画、交互、互动才能完美地呈现给用户。 Jank Free则需要从CPU和GPU两方面来做。 降级降级可分为内容降级和版本降级。 内容降级比较容易理解,就是能够保证主要内容,把次要内容去掉或降级。这样能让更多用户看到页面的内容。 版本降级主要是用在3D和2D版本上。 同native的亲密接触我们会native的页面上去做一个H5的view,然后把它透明,同时也可以获得native里每个元素的位置,并在H5里面替换成H5的动画元素,让用户感受到动画和首页紧密结合在一起。 解放生产力的工具Airbnb已经有了一个lottie。我们通过JSON和DSL间的一次转换对赋予它二次开发能力,可以对JSON进行动画微调,也可以把很多动画片段、JSON数据组合起来运用到业务中去,附加业务属性。 因为DSL比较接近前端的开发思路,我们借助DSL的设计思想和JSON进行转换之后,能够让我们在动画的开发过程当中能够参与进去,真正做到想要的东西。 Web3DWeb3D对于前端来说其实是跨界,实质上是GPU编程。 互动是前端界的又一股泥石流 互动其实也是前端的一个分支,但它和传统的前端开发不一样。它需要有另外一种思维或知识积累。 所以我希望大家能够在感兴趣的前提下去深入探索这方面的东西,然后呈现给大家更多更炫酷的内容。 我的演讲到此结束,谢谢大家! 相关推荐 推荐文章 干货 | 豆子科技首席架构师钟声:Java的纯真年代 开源中国社区创始人红薯:J2Cache开源中国两级缓存实践 近期活动 直播 | 6月28日中国开源产业峰会 嘉宾分享视频地址:http://www.itdks.com/dakashuo/detail/526
时光荏苒 技术发展与创新脚步永不停息 回首过去一年 DPDK已经正式加入Linux基金会 社区发展与参与度前所未有 更多贡献者的添砖加瓦 使得网络数据面的软件创新层出不穷 为了进一步促进数据平面技术的发展 为大家提供一个交流分享的平台 DPDK中国技术峰会2017将于6月27日举行 我们诚挚地邀请您参加此次峰会 共商未来! 大会时间:2017 年 6 月 27 日 08:30 ~ 17:30 大会地点:上海万豪虹桥大酒店 线上直播:扫二维码直播报名! 扫码报名 看直播 会议日程 Agenda 技术主题 Technical topics 本次会议将围绕以下技术主题展开讨论: 电信网络数据面的现状与挑战,解决方法 数据中心网络的构建与发展,软件 DPDK/FD.io的路线图与建议 虚拟化与容器化网络 创新网络技术如P4,高速I/O, 加速器 内核态,用户态网络技术的创新 组织机构 Organization 【主办方】DPDK社区、英特尔 【媒体支持】 SDNLAB 【直播支持】 IT大咖说 直播报名地址:http://www.itdks.com/dakashuo/play/2604
编辑IT大咖说字数:2916用时:8分钟本文内容来源于黎山在阿里云栖社区-运维/DevOps在线技术峰会上的主题演讲,IT大咖说为视频合作方。 内容概况云计算的特点是开箱即用,可以随时的扩缩容,不用考虑硬件的损坏问题,也有丰富的云服务和云平台供我们选择。在本次演讲中,黎山通过实际应用场景为我们讲述了基础设施及代码的重要性,以及在云计算的运维中,如何利用工具来实现自动化,提高效率。 大家好,今天我们围绕几个议题展开: 通过实际的应用场景来讲解IaC的重要性。 Terraform、Packer的使用介绍。 多个工具组合案例+操作演示。 实际应用场景 应用场景解析一 某应用为了增大吞吐量,做了流量的均衡处理,在整个的基础设施架构中,选择了两台ECS挂在SOB的一个基础设施。如果要实现这样的一个架构,需要做以下8个步骤来完成这些基础设施的搭建:创建ECS、创建安全组、添加安全组规则、创建SOB、添加后端服务器、配置监听端口、配置会话保持、添加健康检查。要通过这八个步骤来完成两个ECS挂到SOB上面的基础设施搭建。 应用场景解析二 应用二的特点是需要做网络隔离,所以要把它整个的应用架构搭在VPC下面。它有对外访问网络的需求,同时也有应用对外提供服务。如果要实现这样一个基础设施的话,大的步骤是需要以下七步:创建为PC、创建VSWITCH、创建NET网关、新建共享带宽包、创建ECS、创建SLB、创建SNAT、最后挂载SLB。中间省略了若干个配置操作。 应用场景解析三 应用三与应用二是一样的基础设施要求,就要按照固定的流程再重新做一遍重复的这些操作。 应用场景解析四 随着应用的增加和业务的发展,我们的基础设施的资源也在增加。我们希望能够把应用和基础设施做一个分组,也就是通过打标签的方式,把哪些资源属于哪一个应用做分类。 应用场景解析五 随着业务的发展,应用二深受市场欢迎,流量也暴增。就需要增加ECS以承载更多的并发和访问量,所以需要扩容一台与线上应用一致的ECS挂载到SOB上面,这里的一个关键点是扩容一台与现上应用一致的ECS。 按照传统的操作方式,先将已经安装好应用的ECS打上快照,然后生成镜像,基于此镜象创建ECS,再添加到SLB当中,同样这里面省略了若干的配置步骤。 场景总结: 通过以上几个场景可知,它们的特点就是,操作流程是有序可循的,并且配置是固定的。如果全部是手工操作的话,会带来以下缺点:效率低、时间长、可能导致错误、变更不能回滚、过程中没有历史记录、过程不能审计。 针对场景五的IaC思想。场景五的一个需求就是要扩展,扩容一台与线上应用一致的ECS。如果用IaC的思想,操作流程应该是利用Packer创建一个镜像,在打镜像的时候,把提供服务的应用打到镜像当中,然后用Terraform创建ECS以及其他资源。在创建ECS的时候,选择Packer打出来镜像ID。在变更的时候,我们只需要修改Terraform的模板,把ECS变量的参数加一,执行变更就可以了。就能够实现扩容一台与线上应用一致的ECS并且自动挂载到SLB下面。 Terraform 和 Packer 的介绍 它们来自于HashiCorp家族,有两大特点,第一是支持多平台,第二是开源。现在主流的云平台像阿里云、AWS、Azure等都已经支持了。另一个开源的好处是成熟、透明、可自增强。 Terraform最重要的一点就是模板,模板里面最重要的就是resource。resource是来描述资源,它后面有两个字串。第一个字符串是资源名称,这个名称是固定的;后面的一个串代表的是别名,别名可以自定义。我们就以这个模板为例来详细讲解一下,怎么通过模板去描述一个把资源的定义。 首先看一下安全组。安全组的规则可以定义出网或者入网规则,它的端口是多少,指定的规则作用在哪一个安全组上。也就是对security_group的一个引用,还可以指定它的网段。 对于ECS来讲可以指定instance的name,还有它的镜像ID和count。前面说如果应用于场景五,我们如果想扩容一台的话,我们就在count数加一,它就会自动创建一台ECS,可以指定这台ECS所依赖的安全组。SLB同样是指定它的name以及网络的收费类型,它是公网SLB还是私网SLB,还有对它监听的一些配置。 最后一个是SLB的挂载。这里定义了SLB和instance这两个主要的参数,也就是要把哪些instance挂载到SLB下面。 Terraform最重要的三个命令就是PLAN、APPLY和DESTROY。Terraform的意义是执行之后会看到资源的所有的参数值以及要创建哪些资源,如果确认没有问题的话,就执行APPLY去真正的创建这些资源,然后通过DESTROY做销毁。 我们通过一个实例的操作演示来看一下,创建一个VPC集群的。Terraform在运行时是怎样的状态。这个整个的基础架构是一个VPC集群,有一个子网,子网里面有一个ECS,有安全组、安全组规则,通过NET网关和共享带宽包来实现子网出网和入网的能力。 首先执行Terraform plan。我们要预览一下要创建哪些资源,一共有八个资源会被添加。确认没有问题的话,我们去执行Terraform apply,这个时候就会实际的创实际的创建这些资源。创建完成之后会返回带宽包的两个ip以及instance的ID。 Packer主要的思想也是通过模板来定义一些内容,然后创建镜像。Packer会通过模板自己来决定是基于阿里云的基础镜像创建还是基于自定义镜像创建,然后会自动创建一个经典网络的ECS或者是VPC网络的ECS,同时会根据模板的定义在ECS之上去添加这个去安装相关的应用,然后把ECS打一个快照,根据这个快照生成镜像。当镜像创建完成之后,会把它中间所用到的这些资源都释放掉,可以再做进一步的操作。 Packer模板最重要的就是两部分,一个是builders一个是provisioners。Builders的type来决定她创建的这个镜像是给哪里用的。Provisioners定义的就是镜像中要处理的任务。Packer的命令最主要的就是Packer build的一个指定目录的json。在执行完build之后会提示镜像创建完成并返回镜像ID。 多个工具组合案例 用Packer制作镜像,制作镜像之后会生成镜像ID,然后用Terraform的模板镜像ID创建ECS,这个ECS就自带了所要提供的服务的应用。这个好处就是一次制作重复使用,免去每次创建机器来重复安装服务的过程。也可以用Packer把应用打在镜像当中,然后通过ESS去做伸缩。很多用户在做弹性伸缩的时候呢会遇到一个麻烦,就是在最初的时候,ECS所用到的镜像是只有一个操作系统的镜像,是没有服务的,创建出来之后不能够直接使用。如果结合Packer,Packer把这些应用打在镜像当中,然后用Terraform或其他工具,在用弹性伸缩的时候直接是基于已经安装好应用服务的镜像去做伸缩。另外一个工具就是把Terraform和Ansible结合,一起去实现这个组合。 自动化的实现路径共有三条主线。第一条线可以利用Packer去而生成镜像,自动的存储到自定义镜像列表当中,然后用Terraform创建更新或者销毁这些基础设施。在创建ECS的时候,我们可以选择Packer创建出来的那个镜像ID。在运行期我们可以使用Ansible去管理这些基础设施或是ECS上的应用。 用代码描述基础设施的好处就是,代码编写好,验证也是正确的,之后每次执行任务都不会出错,并且快速高效。还可以用代码代替文档,并且也有历史记录,可回滚。不用担心文档更新不及时或者是人员流动带来的一些问题。而且不用通过访问生产环境就能够知道生产环境上的配置情况,也可以提高整个团队DevOps的能力。 今天的分享就到这,谢谢大家! 相关推荐 推荐文章 灵雀云首席架构师邵明岐:教育行业转型DevOps实践 美团云DevOps专家雷雨:美团点评数据中心基础服务框架 近期活动 直播 | Kubernetes Meetup 中国2017 南京站 视频地址:http://www.itdks.com/dakashuo/detail/1247
作为世界上最先进的开源数据库, PostgreSQL市场占有率不断提升。在中国,PostgreSQL发展备受关注,大型互联网公司、软件公司纷纷投入到PostgreSQL的应用开发及内核研究工作中。基于此背景,建立完善的PostgreSQL推进发展机制,形成有序的决议策略,成立有组织有秩序的官方机构势在必行。 2017年4月,由工信部批准,中国开源软件推进联盟PostgreSQL分会宣告成立。从此,PostgreSQL将在政府的支持下迎来突飞猛进的发展。2017年6月21日,第十二届开源中国开源世界高峰论坛上,PostgreSQL分会将举行成立发布会,并进行2017年PostgreSQL技术论坛。本次论坛将是一场汇聚各界PostgreSQL大拿、交流最新业界技术动态和真实应用案例的盛宴,欢迎各位PGer莅临交流! 大会时间:2017 年 6 月 21 日 13:00 ~ 18:00 大会地点:中国 北京 海淀区知春路25号丽亭华苑酒店 线上直播:扫二维码直播报名! 扫码报名 看直播 会议日程 Agenda 13:00-13:20 入场签到(另有限量T恤,先到先得) 13:20-13:40 开场致辞 13:40-14:10 周宝峰《渥太华2017pgconf归来》 14:10-14:40 许中清《PG在腾讯的应用》 14:40-15:10 朱贤文《解读PG Explaining》 15:10-15:40 胡怡文《大数据流计算和PG结合实现资金实时监控》 15:40-16:00 茶歇、休息交流 16:00-16:10 Henry Ren 探探《Happy Hacking in Tantan Using Golang & PostgreSQL - PostgreSQL in Tantan》 16:10-16:20 刘奎恩《开源数据库中时空轨迹数据管理》 16:20-16:30 刘立兼《基于PostgreSQL构建灵活的表单系统》 16:30-17:00 德哥《PG视角看HTAP的未来发展之路》 17:00-17:30 杨利兵《PG在国家电网的应用》 17:30-18:00 谢红军《PG与数据中心融合架构》 18:00-18:30 李海龙《去哪儿PG指南》 主讲嘉宾简介 Introduce 直播报名地址:http://t.cn/RobKBzk
2016年被称为直播元年,来到2017年,许多直播App面临着并购和转型,如直播与短视频和游戏或将更多的结合。在这样的背景下,直播技术还会有哪些突破呢?比如,在特定场景下的连麦与多人共享白板技术,读写分离的低成本海量视频存储方案,智能抠像技术,面向海外市场的CDN网络架构等等,这些会成为新一波技术趋势吗? 音视频技术社区LiveVideoStack策划了『后直播时代技术』系列沙龙,旨在分享一线技术人的实践与探索,一窥直播技术趋势。6月17日,『LiveVideoStack Meet杭州:后直播时代技术』将在拱墅区丰潭路430号丰元国际大厦A座B1层举行,将邀请业界一线技术专家分享后直播时代的技术,期待你的到来。 活动时间:2017 年 6 月 17 日 13:00-17:30 活动地点:杭州拱墅区丰潭路430号丰元国际大厦A座B1楼硬趣空间 线上直播:关注微信公众号“IT大咖说”,在线观看! 活动议程 Agenda 13:00-13:55 签到 13:55-14:00 开场介绍 14:00-14:40 陈举锋《后移动直播时代的互动探索》 14:40-15:20 黄慧攀《实时音视频互动的技术探索》 15:20-15:30 茶歇 15:30-16:10 林君《高并发实时音视频互动技术解密——以“狼人杀”为例》 16:10-16:50 邱彦林《图像技术在直播中的应用与未来》 16:50-17:30 何荣光《网易云海外推流部署实践》 17:30-17:40 抽奖 17:40-18:00 OpenSpace自由讨论 嘉宾及话题 Guests & Topics 礼物 Gift 【抽奖/互动礼品:热门技术图书】 【特等奖:小米网络音响】 特别鸣谢 special thanks 【合作伙伴】 【视频伙伴】 报名地址:http://h5.welian.com/event/i/MzU1ODE=/oUMiajuMJEzFjYcQKLrNzBVNVuCM
嘉宾|张寿松 编辑|IT大咖说 张寿松,区块链技术专家,DACA亚洲区块链协会会长,中国通信工业协会区块链专业委员会副主任,比特币交易网BtcTrade董事长,区块宝创始人。 注:本文由IT大咖说整理自区块链技术专家 张寿松先生 在 2017中国金融交易技术大会 上的演讲。 谢谢大家,非常荣幸能作为第一个演讲的嘉宾,如果说把这个会议比做一个区块链的话,我相信这个第一场就是创始区块,参与的节点比较少。随着会议的进行,下个区块参与的节点会越来越多,参会的人也会陆续的到来。今天我跟大家分享的是区块链的变与不变。主要从这四个方面给大家分享一下。 2016,区块链行业发展回顾 Gartner2016新兴技术曲线,这个技术曲线被很多媒体和行业广泛的采用。在这个新兴技术曲线里一共上榜了34个新的技术,包括C打印量子计算,以及一些增强现实VR之类的机器学习也比较火,还有区块链,也是我们毋庸置疑的一个热门话题之一。其中区块链是第一次进入这个曲线,而且在16年的时候瞬间到达了期望膨胀期。Gartner认为区块链是一个热炒的概念,包括了其它的一些技术处理过程,也包括中间件、数据库、数据安全数据分析等一系列的东西,它最基本的是被作为一个分布式的加密账本来使用。 Gartner还发布了一个新兴技术的优先矩阵,它列举了这些技术分别是处于哪个阶段,大概有几年的时间才能落实到实际应用的场景里去。 这里比较关注的有两点。第一个是区块链。区块链目前处于一个转型期,预计是在在未来5到10年才会有真正非常大规模的应用。而另外一个就是脑机接口,超过十年之后可能会有一定的大规模应用。 区块宝截止到2016年9月份,总融资大约是194起,总投资金额超过13.49亿美元,从这个区块链融资的进度来看,天使轮和A轮融资为主,总共150家,占了总融资企业的76%,在投资的金额来看,大于2000万美元的一共是22起;1000万到2000万美元之间的有12起;在200万到1000万美元之间有63起。大部分企业是在2016年开始初创,有少部分企业做到一定的规模,在B轮C轮呢是微乎其微的,这里面可能还包括一些之前就在做数字货币行业的一些情况。 2017,区块链的 “变” 在国际上,金融领域是率先会落地的,但是国内情况就不太一样。其实国内的金融在国际上来讲,是非常发达领先的,像支付宝和微信,已经很便利了。美国最早落地的是银行业,在中国则是泛金融领域。 泛金融领域有四个方面。 第一 加密数字货币 我们在区块链这个行业有一些谈“币”色变。这个技术最早来源于一个开源技术,比特币到目前为止也仍然是市值最高的一个区块链项目。中国的央行也在推出自己的货币,和人民币挂钩的数字货币。现在的人民币都有唯一编号,但这个编号并没有真正的把它数字化,因为都是在线下流通。如果央行未来推出了数字货币,针对每个人民币都进行数字化,每一个人民币上都有唯一编号,这样所有交易记录、转账记录都清晰可查。 第二 股票交易和外汇交易、清算结算和交易所 在美国,微软跟美银证券在合作一些业务来代替相应的体系。还有政府信用及认证、纯正信贷分析,这一方面我觉得比金融领域会更先落地,因为区块链一个重大特性就是不可篡改,对历史数据的公开透明不可篡改。 第三 政府信用 因为政府需要更多的公开透明的公信力,所以这方面更适合区块链。 第四 其他的一些商业平台 比如数字资产,一些资产的数据化。不管是商品还是企业的股权,数字化之后就不局限于在自己的体系内流通,可以跨平台,跨领域,让资产流动更便捷。 关于版权,不管是视频音乐,还是著作内容类的。在这方面有一个先后的问题。比如一个作家,他和别人都写了一篇相似的文章,是谁抄袭了谁呢?区块链可以说明,因为它不可篡改。所以未来在取证上,如果有区块链来记载一些著作的信息,采集著作的过程,这个版权的归属就非常清晰。 包括专利做的商标保护,其实都是类似的。档案管理、学历、各种征信的数据、还有社交一些公益的作用。 学历证明。比如你想伪造一个好的学历,根据现有的技术手段,只要有足够的钱和关系,就能买一条数据,这些数据无非在数据库里查不到。但如果这个系统使用区块链做,就无法伪造。因为每个区块都对前一个区块的数据做过计算,有一个确定的值,如果这个值的内容变了,后来所有的数据都会变,这就是区块链的特性。 现在共享经济这个词比较火,像之前的小黄车,我们做的团购众筹,还有打车,airbnb租房其实都是共享自己的东西,共享资源、时间或者共享自己的其他东西。举个例子,像互助保险,也是一种分享经济的一种。但是对于保险甚至说是说延伸到工艺来讲的话,它最大的问题就是不公开不透明。投了多少钱你是不知道的,这些钱有多少拿去做真正的事也是不公开的。但如果使用区块链的话,别人投一块钱,是一个数字资产,所有的交易机构、转让机构都能查到。从区块链可以查询项目里每一条的账目记录。 还有微电网配电网,是把空闲的电量去交易。这个也是使用区块链实现。像供应链流程管理这方面,防伪溯源主要擅长做的事也是容易标准落地的。包括一些收藏品奢侈品的验证,它的产地、生产流程,物流的信息也可以在区块链上去记录。 还有医院的医疗体系为了防止数据造假,换了医院后要给病人重新检查。如果医院的体系都用区块链去做的话,每一家医院查询的结果都会清楚真实地显示在区块链上。 2017,区块链的 “不变” 首先是性能指标。区块链有非常多的节点,一个强大的情况下节点有几十万个,所以想在这些节点中同步这些数据,想做到真正不可篡改公开透明的话,它的效率相对中心化的数据库是比较低的。虽然现在有些新的技术和验证,还有其他的技术都在升级,但对区块链高并发低延迟的需求仍然无法解决。 还有安全属性的问题。在比较大的项目也曾出现过安全问题,因为安全问题导致我们的分差,其实是区块链的更改。在安全领域上我认为区块链还是有一些路要走。 互联属性也是比较重要的。就在的链非常多,每一家创业企业都在做自己的链。但这个体系没法形成一个统一。如果用一个创业公司或者自己做的一条链,就没法去容纳以太币,或是非常流行的数字资产集团。还有一些其他的属性,像交易属性、功能属性、实现属性和发展属性,不再细讲。 区块链不是一个非有不可的东西,它只是一个技术的升级。以前用传统的数据库,现在我们用区块链分布式的数据库。对于银行来说,它们使用区块链的成本很高,因为它有大量的历史的教育机构,而且现有的它们的交易性和机动性是非常稳定的,它从一个稳定的系统去换了一个新系统,可想而知这个难度有多大。 基本每个区块链系统里都会涉及到一个对应的数字资产和代币,比如像以太坊的以太币。项目成熟之后,数字货币会有一定价值和金融属性。在美国它被定位成金融的一个投资产品。中国的把数字货币定为数字商品,并且已经成为一种双赢商品,大家可以收藏和买卖,作为商品来监管。日本则把这个数据当成了一个货币的来监管。 我们如何应对? 区块链不只单纯是技术,它对应的还有一些金融方面受到监管,在监管层面也会有一些新的举措。我们投资了一个叫Asch的平台。Asch是一个去中心化的平台,大家可以在这个上面创建智能合约,创建应用完成各种各样的事,那它跟以太坊有什么区别呢? 以太坊只有唯一的一条链,如果你把它打造成一个操作系统,未来上面有成千上万的应用,甚至几十万的费用,每个应用又有很多的数据。但是因为所有的东西在一条链上,所以不管这个应用有没有价值,都需要同步它的数据,这样未来可能会有更多的资源占用,个人是无法运行,甚至有些大厂商在服务器上都没法运行。以太坊的这个区块链在一定程度上就已经失去了初衷,这是以太坊的一个缺点。 相对以太坊,我们做了侧链的改进。Asch是主链的一个数据,每个APP是一条侧链,用户可以根据需要的APP按需下载数据。除了数据方面更精炼,在架构上的安全性也更高。因为智能合约每个应用是由用户编写的,我们无法控制这个应用的一个安全度。一个应用出了问题,整个系统都要都要停滞。如果这个应用是放在侧链上,无论发生了什么问题,我们都可以去干涉这个侧链去解决,不会影响其他的应用,因为其他应用它的数据都是完全隔离的。这是在安全性的一些升级。 “变”,是技术的在不断的升级和迭代。以太坊把技术升级到更高的层面,使用虚拟机的技术,可以执行一些高级的语言。我相信未来也会有更多的项目会出来,无论是在性能还是在其他的一些空间容量,而且各个方面都有一定的升级。 最后做一些总结,2017年希望有更多的应用落地,技术上有更多的升级,政策也会出现了营养化。包括现在央行也是针对数字货币的历史的交易平台来做一些相关的政策指导。我相信大家齐心协力会让这个行业更好。 谢谢大家! 相关专题: Crescent Quant创始人龚晖:解锁区块链的创业密码 原文地址:http://www.itdks.com/dakashuo/detail/819
由阿里云授权服务中心&袋鼠学院共同举办,IT大咖说提供独家视频支持的系列沙龙之:“企业互联网架构优化升级之路”第一趴开启! 本次沙龙邀请的都是牛逼哄哄的嘉宾呢,比如阿里云消息队列产品经理曼红(女老师讲起技术来,真的是气场满满);还有这次是袋鼠云首席架构师-正风老师的处女秀,多少次请他分享都请不动呢~ 很多企业都对淘宝的IT架构演进特别感兴趣,到底怎样的架构设计和IT系统建设才能支撑淘宝这么多年来如此大规模的交易量、不断提升如此庞大体量用户的购物体验、经过每一次双十一之夜的检验呢?无论你是正在思考自己公司互联网架构建设的企业CTO或者技术负责人,又或这你是致力于成为高级架构师的开发人员,还是单纯想了解Aliware产品的技术爱好者,相信本次沙龙都能给你一些收获。 活动时间:2017 年 6 月 4 日 13:30-17:00 活动地点:袋鼠云总部(浙江杭州市紫霞街176号 杭州互联网创新创业园2号楼8F) 线上直播:不在现场的小伙伴没有遗憾,IT大咖说和云栖社区联合打造双通道直播 IT大咖说直播 长按二维码报名 或者点击网址:http://www.itdks.com/dakashuo/playback/483 阿里云直播 长按二维码报名 或者点击网址:http://yq.aliyun.com/webinar/play/241 嘉宾及话题 Guests & Topics 特别鸣谢 special thanks 点击"原文链接",报名参加! 报名链接:http://www.bagevent.com/event/581635
嘉宾演讲视频 Guest Video 很早之前就有人说“Java已经死了”,但时至今日,Java在IT技术中仍然占据非常重要的地位。 正因为有好多人对Java的前世今生、Java的未来发展有许多的困惑和迷茫,5月21日,饿了么科技在北京,邀请了豆子科技、融数、当当以及饿厂自家的四位架构师跟大家聊聊Java。 豆子科技首席架构师钟声,用非常幽默风趣的方式,让大家的思绪一下又回到了刚接触Java的年代。一个接一个的段子+实例,让我们再次认识纯真的Java,也对Java未来的发展愈加有了信心。 演讲PPT Topics ppt PPT篇幅过长,想要完整版,请戳原文链接 原文地址:http://www.itdks.com/dakashuo/detail/1706
嘉宾演讲视频 Guest Video 5月13日,七牛云携手 OneAPM 共同为大家带来了一场精彩的技术盛宴。在现今,云计算普及、Docker 兴起,新一代信息技术不断发展,业务扩张导致用户体量愈发庞大,系统管理难度指数直线上升,给运维带来前所未有的挑战。 OneAPM研发总监高海强,对于我们的业务系统能否经受的住高并发用户访问,有什么测试手段和方法可以做到提前验证,与大家分享了实现压测平台的关键技术与细节。 演讲PPT Topics ppt PPT篇幅过长,想要完整版,请戳原文链接 原文链接:http://www.itdks.com/dakashuo/detail/1346
中国R会议是由统计之都发起,并同国内高校共同举办的极有特色的数据科学会议。2008年,中国R会议在中国人民大学举办第1届,2016年已发展至全年9个城市先后举办,服务数据科学在校师生和业界人士数万人,内容覆盖数据科学相关的多个行业,R会议非常有幸见证了数据科学在中国的蓬勃发展。 2017年,是中国R会议值得纪念的第10个年头,本届R会议将于5月19-21日在美丽的清华大学举办。在这样一个值得纪念的时刻,让我们相聚清华大学统计学研究中心,相聚R会议十周年庆典,也相聚这场数据与统计的盛宴!本届会议覆盖数据科学多个领域,我们非常期待您的到来,希望您的演讲能让听众更多受益,能让会议更加精彩! 2017年,清华大学统计学研究中心、北京大学商务智能研究中心和统计之都携手共同主办第10届中国R会议。本届会议的主题包括医疗健康、生物信息、消费金融、量化投资、工业工程、智能制造、软件工具、计算平台、概率统计、机器学习、人工智能、自然语言、天文地理、城市规划、环境科学、社交网络、政务数据、商务统计、人文科学等诸多话题。其中5月19日主旨演讲会场设于清华大学新清华学堂,20-21日将举办上述主题的平行分会场。 活动时间:2017 年 5 月 19 日 - 21日 活动地点:清华大学,其中19日为新清华学堂,19日下午的狗熊会专场在紫光会议中心,20~21日为分会场会议厅和教室 线上直播:不在现场的小伙伴没有遗憾,IT大咖说和腾讯课堂联合打造双通道直播 IT大咖说直播 长按二维码报名 或者点击网址:http://www.itdks.com/dakashuo/playback/426 腾讯课堂直播 长按二维码报名 或者点击网址:https://ke.qq.com/course/208165 会议日程 Agenda 特别鸣谢 special thanks 【战略合作伙伴】 【金牌赞助】 【银牌赞助】 【会议视频服务独家合作伙伴】 报名详情请访问:http://china-r.org/bj2017/index.html