乐学 什么是开发框架
人工智能产业链分为基础层、技术层和应用层。基础层是人工智能产业链的基础，为人工智能提供算力支撑和数据输入，中国在此领域发展时间较短，基础层发展较为薄弱。目前，中国的人工智能企业主要集中在北京、广东、上海和浙江，北京的人工智能发展已经步入快车道。
人工智能产业链全景梳理：基础层发展薄弱
基础层主要提供算力和数据支持，主要涉及数据的来源与采集，包括AI芯片、传感器、大数据、云计算、开源框架以及数据处理服务等。技术层处理数据的挖掘、学习与智能处理，是连接基础层与具体应用层的桥梁，主要包括机器学习、深度学习、计算机视觉、自然语言处理、语音识别等。应用层针对不同的场景，将人工智能技术进行应用，进行商业化落地，主要应用领域有驾驶、安防、医疗、金融、教育等。
近年来，人工智能在技术与应用方面取得了巨大的进展，在国际上具备了一定的竞争力，但是基础层的薄弱仍然是限制中国人工智能发展的关键因素。中国在在基础层发展时间较短，较落后于国际先进水平。长期以来，中国的芯片大部份依赖进口，计算力方面的基础薄弱，且开源框架受制于国外AI巨头。
基础层的人工智能算力发挥着越来越重要的作用，AI芯片作为人工智能产业发展的核心，将迎来巨大的发展机遇。目前，中国人工智能芯片优秀企业有寒武纪、华为海思、中星微、西井科技、地平线、富瀚微、四维图新、瑞芯微、深鉴科技等。
人工智能产业链区域热力图：北京AI发展步入快车道
根据公开资料整理人工智能优秀企业区域分布热力地图如下，可见，我国人工智能产业链重点企业集中于北京、广东、上海、浙江等地区。
北京作为中国集聚人工智能企业最多的区域，其人工智能产业的链条已经比较完善，覆盖了整个产业链环节，且在产业链的重点细分领域均出现了行业龙头企业。其中，基础层中传感器的行业龙头京东方科技，AI芯片的行业龙头中星微电子、寒武纪、地平线、四维图新等，云计算的百度云、金山云、世纪互联等，数据服务的百度数据众包、京东众智、数据堂等;技术层的机器学习龙头百度IDL、京东DNN等，计算机视觉的商汤科技、旷视科技等，自然语言处理的百度、搜狗、紫平方等，语音识别的出门问问、智齿科技等;应用层的人工智能重点企业也涉及了各个领域。北京正在逐步形成具有全球影响力的人工智能产业生态体系。
首先，这种框架现在市面上是有的。强烈建议，不要重复造轮子。先介绍几种比较主流的。
Elastic-Job,是当当网开源的分布式调度解决方案，支持任务分片功能，可以充分利用资源。Elastic-Job有两个独立的子项目Elastic-Job-Lite和Elastic-Job-Cloud组成。具体实现可以参考官方教程。其整体架构图如下。
Elastic-Job的特点：
1、分布式调度 2、作业高可用 3、任务分片执行。
另外，还有其他的一些框架，可以对比使用。比如TBSchedule是阿里巴巴开源的分布式调度框架，完全由java实现，目前被应用于淘宝，阿里巴巴，支付宝，京东， 汽车 之家等。大众点评开源的xxl-job，也是应用比较广泛的分布式调度任务。
目前我使用过的有 Elastic-Job和xxl-job。两者功能都很强大，后台管理也比较完善。很容易上手。都可以满足日常的工作需要。区别就是 Elastic-Job依赖zk，但是xxl-job不依赖zk，只依赖数据库。
目前市面上应该还有一些其他的框架，但是以上是比较主流的，可以根据自己的需要来选择。切记不要重复造轮子，造轮子需要大量的时间去验证。会让你在坑里爬不出来。
1XXL-JOB
2Elastic-Job
Elastic-Job 是一个分布式调度解决方案，由两个相互独立的子项目 Elastic-Job-Lite 和 Elastic-Job-Cloud 组成。
定位为轻量级无中心化解决方案，使用 jar 包的形式提供分布式任务的协调服务。
支持分布式调度协调、 *** 性扩容缩容、失效转移、错过执行作业重触发、并行调度、自诊断和修复等等功能特性。
分布式调度解决方案，由两个相互独立的子项目Elastic-Job-Lite和Elastic-Job-Cloud组成。
Elastic-Job-Lite定位为轻量级无中心化解决方案，使用jar包的形式提供分布式任务的协调服务。选择该项目可以满足大多数it企业的需求。
Elastic-Job-Cloud使用Mesos + Docker的解决方案，额外提供资源治理、应用分发以及进程隔离等服务。
轻量级无中心化：Elastic-Job-Lite并无作业调度中心节点，而是基于部署作业框架的程序在到达相应时间点时各自触发调度。
灵活的增删改查作业，集中式管理调度作业
支持高可用：一旦执行作业的服务器崩溃，等待执行的服务器将会在下次作业启动时替补执行。开启失效转移功能效果更好，可以保证在本次作业执行时崩溃，备机立即启动替补执行。
支持分片：作业分片一致性，保证同一分片在分布式环境中仅一个执行实例
任务监控：通过监听Elastic-Job-Lite的zookeeper注册中心的几个关键节点即可完成作业运行状态监控功能
一致性：使用zookeeper作为注册中心，为了保证作业的在分布式场景下的一致性，一旦作业与注册中心无法通信，运行中的作业会立刻停止执行，但作业的进程不会退出，这样做的目的是为了防止作业重分片时，将与注册中心失去联系的节点执行的分片分配给另外节点，导致同一分片在两个节点中同时执行。
同时支持动态扩容，将任务拆分为n个任务项后，各个服务器分别执行各自分配到的任务项。一旦有新的服务器加入集群，或现有服务器下线，elastic-job将在保留本次任务执行不变的情况下，下次任务开始前触发任务重分片
3opencron
opencron是一个功能完善且通用的开源定时任务调度系统，拥有先进可靠的自动化任务管理调度功能，提供可 *** 作的 web 图形化管理满足多种场景下各种复杂的定时任务调度，同时集成了 linux 实时监控、webssh 等功能特性
4quartz
支持集群和分布式，但是没有友好的管理界面，功能单一，对于管理调用的任务比较困难。
quartz使用数据库锁。在quartz的集群解决方案里有张表scheduler_locks，quartz采用了悲观锁的方式对triggers表进行行加锁，以保证任务同步的正确性。一旦某一个节点上面的线程获取了该锁，那么这个Job就会在这台机器上被执行，同时这个锁就会被这台机器占用。同时另外一台机器也会想要触发这个任务，但是锁已经被占用了，就只能等待，直到这个锁被释放。
quartz的分布式调度策略是以数据库为边界资源的一种异步策略。各个调度器都遵守一个基于数据库锁的 *** 作规则从而保证了 *** 作的唯一性。同时多个节点的异步运行保证了服务的可靠。但这种策略有自己的局限性：集群特性对于高CPU使用率的任务效果很好，但是对于大量的短任务，各个节点都会抢占数据库锁，这样就出现大量的线程等待资源。这种情况随着节点的增加会越来越严重。
缺点：quartz的分布式只是解决了高可用的问题，并没有解决任务分片的问题，还是会有单机处理的极限。
5Saturn
Saturn
基于当当Elastic Job代码基础上自主研发的任务调度系统，是唯品会开源的分布式作业调度平台，取代传统的Linux Cron/Spring Batch Job的方式，做到统一配置，统一监控，任务高可用以及分片并发处理。主要是去中心化，高可用，可分片，动态扩容，有认证和授权功能。
主要特性
支持多种语言作业，语言无关(Java/Go/C++/PHP/Python/Ruby/shell)
支持秒级调度
支持作业分片并行执行
支持依赖作业串行执行
支持作业高可用和智能负载均衡
支持异常检测和自动失败转移
支持异地容灾
支持多个集群部署
支持跨机房区域部署
支持 *** 性动态扩容
支持优先级和权重设置
支持docker容器，容器化友好
支持cron时间表达式
支持多个时间段暂停执行控制
支持超时告警和超时强杀控制
支持灰度发布
支持异常、超时和无法高可用作业监控告警和简易的故障排除
支持失败率最高、最活跃和负荷最重的各域各节点TOP10的作业统计
优点：源码清晰，学习入手容易。应用部署简单，提供运维控制台，集中管理作业，运维控制台功能强大，提供作业统计报表 ，告警，增删改查作业，作业统一配置。
最后一个是国内团队封装的
前端时间研究了两款分布式任务调度框架，一个是XXL-Job，现在非常主流，很多常见的一些公司都在使用，像滴滴美团这样的公司都在用，这也是一款开源产品，下载下来导入IDEA就可以使用，分调度器和执行器和管理UI，有很美观的UI界面，可以对任务做增删改查，以及支持自定义开发，有很详细的帮助文档，还提供有demo，傻瓜式的，很简单，亮点是提供了管理界面。
另一个是Quartz，这个组件单机和集群都支持，单机的话是RAMJobStore任务存储，而要支持集群的话，就要将配置改成数据库方式，Quartz提供的有十几张表，其分布式的原理是利用了数据库的行锁，Quartz很简单，也是一款轻量级的开源产品，我们公司一直用这款组件，很成熟无Bug，推荐使用！
springcloudtask，springclouddataflow，正在学习中一、战略层
产品定位：为死宅、深度网购用户（懒人经济）提供方便快捷的生活服务，Slogan是“万种商品、即刻送达”
用户需求：满足用户在各种生活场景下：包括逛超市买生活用品、水果蔬菜、一日三餐、加班点外卖、生日定鲜花蛋糕、生病买药、请家政保姆，足不出户就能快速解决这些问题的需求
优势：1借助京东商城的力量发展。京东到家有京东商城这个巨大的导流平台，并已经有充足的电商经验、成熟的支付体系，所以在O2O电商相当于站在巨人的肩膀上成长；2采用的商业模式和物流模式能很好地实现“万种商品，即可送达”。其整个采用C2C商业模式，只为商家提供一个销售平台，而在物流上，也不再自建供应链，而是与”达达“合作，采用众包模式，成本低速度快。迅速扩张和保证服务质量中间取得平衡
二、范围层
京东到家的主要功能有：
1超市购物水果生鲜半成品菜成品菜外卖等,解决用户买日常用品、买菜、吃饭的问题,这些都属于高频需求，且对物流及时性要求也很高。这部分功能应该属于京东到家主打的核心功能，用户只能看到和购买3公里范围内的服务，保证了送货的及时性。
2买药、订鲜花蛋糕等，解决用户特殊情况下的特殊需求，这些功能使用频次低，但定制化需求高，例如买药，京东到家提供了自测用药、快捷找药等附加功能，让用户不仅可以在线买药，也可以知道买哪种药，订鲜花的页面，京东到家提供了按场景（表白、问候、夫妻）选花。附加功能满足了用户的期待型需求。
3 上门服务。
三、结构层
四、框架层
五、表现层
六、商业模式
C2C模式，不再自建物流
京东商城在最开始决定自建物流，坚持走自营为主的商业模式，一方面考虑用户体验，另外一方面，我们就看到过去整个中国商品平均搬运次数是五到七次，我们要减少一半以上的搬运次数，所以我们设计全国物流体系的时候口号就是减少物品的搬运次数，降低了成本，提高了发货效率
------------附小彩蛋----------------
15年2月京东到家上线，随手扒了一下上线以来的更新日志，发现京东到家的确已经改进了很多地方， 2016年4月最新一版本的更新日志为
1红包分享（改进目的：让用户利用自己社交链，吸引新用户，一种促销手段）
2新增优惠大集合（目的：这个功能放在首页位置，利于刺激那些本来只想来逛逛的用户的消费欲望，提高转化率，让用户领取优惠券不会再像寻宝一样困难，给用户带来更好的购物体验）
3秒杀时可以查看店家名称（目的：用户可以在秒杀页面就得到更多的信息，不需要跳转到详情页就可以直接抢购，个人猜想：可能是产品经理看到了用户在秒杀界面通常都会进入详情页面看看再决定是否要买，而详情页面其实多的是店家信息，因此把这部分信息挪到了秒杀页）
自己体验的时候发现一些有待于改进的点：
用户体验方面
·如果未开启定位权限，选择收货地址，定位的话，只会提醒检查GPS，不能直接跳转到设置中去设置；淘宝到家里面，如果没有开启，可以直接跳转到设置；
·可以考虑加入省流量模式，定时秒杀之前的可以添加消息提醒
·新建收货地址页面，可以考虑自动获取当前所在城市
功能方面
·门店有待于进一步扩展，分类很多，但我点进去之后又不能使用，个人认为可以将这些没有商品的频道灰掉，避免点击进去之后不能用，尤其是在医药健康频道，经过很多步骤自诊选了合适的药品，但是却买不了药，是否可以提醒用户把这些信息复制下来，去其他平台试试。
·在定鲜花界面，场景还可以更加丰富。上门服务频道，分类有待于细化
·必须按店家结算，不能统一结算之后再派发不同店家
·管理收货地址-导入京东收货地址，可以重复添加同一个地址，不能一键导入所有地址，必须在地图上确认，为什么要这么麻烦
·外卖和美食有重叠的部分，可能是因为外卖是饿了么在做，有一部分美食又是京东到家自己做的，所以就把两个分离开了？
·在分类里面没有必要再要“搜索门店”的功能，因为用户通常使用路径是：知道自己要买哪一类商品，但不知道有哪几家在卖。而搜索门店的功能首页搜索框里面已经实现了。
·门店详情页面的一些小建议，这个页面吧商品和商家作为两个大类，放在了页面顶部，1）可以把分类按钮放到商品tab里面，放的太靠上面，在浏览商品的时候并没有看到2）把商家的详细信息没必要放在一级菜单里面在商品页的顶部已经展示了用户最关心的商家信息，可以在它旁边再加一个更多，跳转过去，而顶部就完全是商品的搜索、分类。3）浏览商品的交互方式可以按照“某类商品详情”的页面那样，向下的时候隐藏上面的小标签，一旦向上滑，再展示小标签
·“某类商品详情”标题栏有三个小圆点，可以查看消息和返回主页，这个功能没有必要放，其他页面返回首页都是通过“关闭”实现，最好与其他页面保持一致
·在线客服咨询时，不能一键关闭，必须一层一层返回，可以和其他页面一样，通过“关闭”来实现问题问得有点含糊
京东系统是用PHP编程的
找一个PHP环境整合软件，phpstudy之类的
不过要做网站只会PHP是远远不够的。
1 首先得做规划，做什么内容为主的网站，有什么样的功能。
2 做设计，通常都说美工。美工用photoshop做图，然后用HTML写基本的框架(not framework)，现在都用DIV+CSS模式。
3 现在才是程序出来的时候了，程序就是实现功能，最基本的有会员注册和登录，留言板，后台管理，发帖，回帖 等等。
4 写完程序以后做测试，看看有没有地方不完善或者有错误。
5 网站写完了，还没完。你得申请域名(>京东活动系统 是一个可在线编辑、实时编辑更新和发布新活动，并对外提供页面访问服务的系统。其高时效性、灵活性等特征，极受青睐，已发展成京东几个重要流量入口之一。近几次大促，系统所承载的pv已经达到数亿级。随着京东业务的高速发展，京东活动系统的压力会越来越大。急需要一个更高效，稳定的系统架构，来支持业务的高速发展。本文主要对活动页面浏览方面的性能，进行探讨。
活动页面浏览性能提升的难点：
1 活动与活动之间差异很大，不像商品页有固定的模式。每个页面能抽取的公共部分有限，可复用性差。
2 活动页面内容多样，业务繁多。依赖大量外部业务接口，数据很难做到闭环。外部接口的性能，以及稳定性，严重制约了活动页的渲染速度、稳定性。
经过多年在该系统下的开发实践，提出“页面渲染、浏览异步化”的思想，并以此为指导，对该系统进行架构升级改造。通过近几个月的运行，各方面性能都有显著提升。在分享"新架构"之前，先看看我们现有web系统的架构现状。
以京东活动系统架构的演变为例，这里没有画出具体的业务逻辑，只是简单的描述下架构：
2第二步，一般是在消耗性能的地方加缓存，这里对部分查库 *** 作加redis缓存
3对页面进行整页redis缓存：由于活动页面内容繁多，渲染一次页面的成本是很高。这里可以考虑把渲染好的活动内容整页缓存起来，下次请求到来时，如果缓存中有值，直接获取缓存返回。
以上是系统应用服务层面架构演进的，简单示意。为了减少应用服务器的压力，可以在应用服务器前面，加cdn和nginx的proxy_caxhe，降低回源率。
4整体架构（老）
除了前3步讲的“浏览服务”，老架构还做了其他两个大的优化：“接口服务”、静态服务
1访问请求，首先到达浏览服务，把整个页面框架返回给浏览器（有cdn、nginx、redis等各级缓存）。
2对于实时数据（如秒杀）、个性化数据（如登陆、个人坐标），采用前端实时接口调用，前端接口服务。
3静态服务：静态资源分离，所有静态js、css访问静态服务。
要点：浏览服务、接口服务分离。页面固定不变部分走浏览服务，实时变化、个性化采用前端接口服务实现。
接口服务：分两类，直接读redis缓存、调用外部接口。这里可以对直接读redis的接口采用nginx+lua进行优化（ openresty ），不做详细讲解。 本次分享主要对“浏览服务”架构
在讲新架构之前先看看新老架构下的新能对比
击穿cdn缓存、nginx缓存，回源到应用服务器的流量大约为20%-40%之间，这里的性能对比，只针对回源到应用服务器的部分。
2015双十一， 浏览方法tp99如下：（物理机）
Tp99 1000ms左右，且抖动幅度很大，内存使用近70%，cpu 45%左右。
1000ms内没有缓存，有阻塞甚至挂掉的风险。
2新架构浏览服务新能
本次2016 618采用新架构支持，浏览tp99如下（分app端活动和pc端活动）：
移动活动浏览tp99稳定在8ms, pc活动浏览tp99 稳定在15ms左右。全天几乎一条直线，没有性能抖动。
新架构支持，服务器（docker）cpu性能如下
cpu消耗一直平稳在1%，几乎没有抖动。
对比结果：新架构tp99从1000ms降低到 15ms，cpu消耗从45%降低到1%，新架构性能得到质的提升。
why!!!
下面我们就来揭开新架构的面纱。
1 页面浏览，页面渲染 异步化
再来看之前的浏览服务架构，20%-40%的页面请求会重新渲染页面，渲染需要重新计算、查询、创建对象等导致 cpu、内存消耗增加，tp99性能下降。
如果能保证每次请求都能获取到redis整页缓存，这些性能问题就都不存在了。
即：页面浏览，与页面渲染 异步。
理想情况下，如果页面数据变动可以通过 手动触发渲染（页面发布新内容）、外部数据变化通过监听mq 自动触发渲染。
但是有些外部接口不支持mq、或者无法使用mq，比如活动页面置入的某个商品，这个商品名称变化。
为了解决这个问题，view工程每隔指定时间，向engine发起重新渲染请求-最新内容放入redis。下一次请求到来时即可获取到新内容。由于活动很多，也不能确定哪些活动在被访问，所以不建议使用timer。通过加一个缓存key来实现，处理逻辑如下：
好处就是，只对有访问的活动定时重新发起渲染。
整理架构（不包含业务）：
view工程职责 ：
a直接从缓存或者硬盘中获取静态html返回，如果没有返回错误页面。（文件系统的存取性能比较低，超过 100ms级别，这里没有使用）
b根据缓存key2是否过期，判断是否向engine重新发起渲染。（如果，你的项目外面接口都支持mq，这个 功能就不需要了）
engine工程职责 ：渲染活动页面，把结果放到 硬盘、redis。
publish工程、mq 职责 ：页面发生变化，向engine重新发起渲染。 具体的页面逻辑，这里不做讲解
Engine工程的工作 就是当页面内容发生变化时，重新渲染页面，并将整页内容放到redis，或者推送到硬盘。
View工程的工作，就是根据链接从redis中获取页面内容返回。
3view 工程架构 ( 硬盘 版)
两个版本对比
aRedis版
优点：接入简单、 性能好，尤其是在大量页面情况下，没有性能抖动 。单个docker tps达到 700。
缺点：严重依赖京东redis服务，如果redis服务出现问题，所有页面都无法访问。
b硬盘版
优点：不依赖任何其他外部服务，只要应用服务不挂、网络正常 就可以对外稳定服务。
在页面数量不大的情况下，性能优越。单个docker tps达到 2000。
缺点：在页面数据量大的情况下（系统的所有活动页有xx个G左右），磁盘io消耗增加（这里采用的java io，如果采用nginx+lua，io消耗应该会控制在10%以内）。
解决方案：
a 对所有页面访问和存储 采用url hash方式，所有页面均匀分配到各个应用服务器上。
b 采用nginx+lua 利用nginx的异步io，代替java io。
现在通过nginx+lua做应用服务，所具有的高并发处理能力、高性能、高稳定性已经越来越受青睐。通过上述讲解，view工程没有任何业务逻辑。可以很轻易的就可以用lua实现，从redis或者硬盘获取页面，实现更高效的web服务。如果想学习Java工程化、高性能及分布式、深入浅出。微服务、Spring，MyBatis，Netty源码分析的朋友可以加我的Java进阶qun：694549689，里面有阿里大牛直播讲解技术，以及Java大型互联网技术的视频免费分享给大家。
1具有1-5工作经验的，面对目前流行的技术不知从何下手，需要突破技术瓶颈的可以加。
2在公司待久了，过得很安逸，但跳槽时面试碰壁。需要在短时间内进修、跳槽拿高薪的可以加。
3如果没有工作经验，但基础非常扎实，对java工作机制，常用设计思想，常用java开发框架掌握熟练的可以加。
通过测试对比，view工程读本地硬盘的速度，比读redis还要快（同一个页面，读redis是15ms，硬盘是8ms）。所以终极版架构我选择用硬盘，redis做备份，硬盘读不到时在读redis。
这里前置机的url hash是自己实现的逻辑，engine工程采用同样的规则推送到view服务器硬盘即可，具体逻辑这里不细讲。后面有时间再单独做一次分享。
优点：具备硬盘版的全部优点，同时去掉tomcat，直接利用nginx高并发能力，以及io处理能力。各项性能、以及稳定性达到最优。
缺点：1、硬盘坏掉，影响访问。2方法监控，以及日志打印，需使用lua脚本重写。
无论是redis版、硬盘版、openresty+硬盘版，基础都是页面浏览与页面渲染异步化。
优势：
1、所有业务逻辑都剥离到engine工程，新view工程理论上永远无需上线。
2、灾备多样化（redis、硬盘、文件系统），且更加简单，外部接口或者服务出现问题后，切断engine工程渲染，不再更新redis和硬盘即可。
3、新view工程，与业务逻辑完全隔离，不依赖外部接口和服务，大促期间，即便外部接口出现新能问题，或者有外部服务挂掉，丝毫不影响view工程正常访问。
4、性能提升上百倍，从1000ms提升到10ms左右。详见前面的性能截图。
5、稳定性：只要view服务器的网络还正常，可以做到理论上用不挂机。
6、大幅度节省服务器资源，按此架构，4+20+30=54个docker足以支持10亿级pv。（4个nginx proxy_cache、20个view，30个engine）
从事开发已有近10载，一直就像寄生虫一样吸取着网络上的资源。前段时间受“张开涛”大神所托，对活动系统新架构做了一次简单整理分享给大家，希望能给大家带来一丝帮助。第一次在网上做分享，难免有些没有考虑周全的地方，以后会慢慢的多分享一些自己的心得，大家一起成长。最后再来点心灵鸡汤。。。
0条评论