摘要： 不知道自己应该选用那个AI框架和库？看看本文就行了，本文为AI开发的工程师们梳理了现在最流行的框架，并简单的分析了它们的优缺点。 人工智能已经存在很长时间，然而，由于这一领域的巨大发展，近年来它已成为一个流行语。人工智能曾经被称为一个书呆子和天才领域，但由于各种库和框架的发展，它已成为一个友好的IT领域，更多的人开始了他们的人工智能之旅。 在这篇文章中，我们将研究人工智能的高质量库的优点和缺点，以及它们的一些特点。 1. TensorFlow “使用数据流图计算进行机器学习” 语言：C ++或Python。 当你进入AI时，你会听到的第一个框架之一就是Google的TensorFlow。TensorFlow是一个使用数据流图进行数值计算的开源框架。这个框架被称为具有允许在任何CPU或GPU上进行计算的架构，无论是台式机，服务器还是移动设备，另外这个框架在Python编程语言中是可用的，这也是Python大火的原因。 TensorFlow是通过称为节点的数据层进行排序，并根据获得的信息做出决定。 优点： 使用易于学习的语言（Python）。 使用计算图抽象。 可以使用可视化的TensorBoard。 缺点： 它很慢，因为Python不是编程语言中最快的。 缺乏许多预先训练的模型。 不完全开源。 2.CNTK “开源深度学习工具包”。 语言：C ++。 我们可以称之为它是微软对Google的TensorFlow的回应。 微软的CNTK是一个增强分离计算网络模块化和维护的库，它提供了学习算法和模型描述。在需要大量服务器进行操作的情况下，CNTK可以同时利用多台服务器。 据说它的功能与Google的TensorFlow相近，但是，它更快，在这里了解更多。 优点： 非常灵活。 允许分布式培训。 支持C ++，C＃，Java和Python。 缺点： 它以一种新的语言——Network Description Language（NDL）来实现。 缺乏可视化。 3. Theano “数值计算库” 语言：Python。 Theano是TensorFlow的强有力竞争者，它是一个功能强大的Python库，允许以高效率的方式进行多维数组的数值操作。 该库透明地使用GPU来执行数据密集型计算而不是CPU，因此操作效率很高。出于这个原因，Theano已经被用于为大规模的计算密集型操作长达十年的时间。然而，于二零一七年九月， Theano的1.0版本停止。 但这并不意味着它不再是一个强大的图书馆，你仍然可以随时进行深入的学习研究。 优点： 优化CPU和GPU。 有效的计算任务。 缺点： 与其他库相比，原生Theano有点低级。 需要与其他库一起使用以获得高度的抽象。 AWS使用它上有点bug。 4. Caffe “快速，开放的深度学习框架” 语言：C ++。 Caffe是一个强大的深度学习框架，像这个清单上的其他框架一样，深度学习的研究速度非常快。 借助Caffe，你可以非常轻松地构建用于图像分类的卷积神经网络（CNN）。Caffe在GPU上运行的也很不错，这有助于在运行期间提高速度。 Caffe主类： 优点： Python和MATLAB都可用。 表现的很好。 无需编写代码即可进行模型的训练。 缺点： 对于RNN网络不太友好。 对于新体系结构不太友好。 5. Keras “为人类普及深度学习” 语言：Python。 Keras是一个用Python编写的开源的神经网络库。与TensorFlow，CNTK和Theano不同，Keras并不意味着是一个端到端的机器学习框架。 相反，它作为一个接口，提供了一个高层次的抽象，这使得神经网络的配置变得简单，无论它坐在哪个框架上。 谷歌的TensorFlow目前支持Keras作为后端，而微软的CNTK也会在很短的时间内做到这一点。 优点： 它对用户非常友好。 它很容易扩展。 在CPU和GPU上无缝运行。 与Theano和TensorFlow无缝工作。 缺点： 不能有效地用作独立的框架。 6.Torch “一个开源的机器学习库” 语言：C. Torch是一个用于科学和数字操作的开源机器学习库。 这是一个基于Lua编程语言的库而不是Python。 它通过提供大量的算法，使得深度学习研究更容易，并且提高了效率和速度。它有一个强大的N维数组，这有助于切片和索引等操作。它还提供了线性代数程序和神经网络模型。 优点： 非常灵活。 高水平的速度和效率。 大量的预训练模型可用。 […]
View Details今天给大家带来的分享是基于支付场景的一个微服务实战，会更偏向于应用层的内容。 主要围绕以下四点进行分享： SOA 与微服务 老支付架构遇到的挑战 基于微服务怎么做的改造 未来计划要做的事 SOA 与微服务 在我看来，微服务虽是国外传进来的技术，却和咱们中国的一些理论是挂钩的。所以在正式进入主题之前，先给大家简单介绍一下麦田理论。 关于麦田理论 古代周朝时期，老百姓种地实际是没有任何规划的，也没有任何区域的限制。 一般来说在地里一会种水稻，一会种小麦，一会种蔬菜地交叉来种，可收成之后发现庄稼受阳光程度非常低，营养非常不均衡，后期维护成本非常高。 直到战国时期，有一位农业专家把地划分为多个区域，每一个区域种一种庄稼，地跟地隔开，形成最初的微服务理念。 过去我们看到的很多文章都只是讲到 SOA 和微服务之间的比较，我今天在这个基础上加了一个 DDD。下面就 DDD、SOA 以及微服务的演进过程先做个引子。 DDD、SOA 与微服务 SOA 架构 SOA 是上一个时代的产物，大概是在 2010 年之前出现的，最早提出时是提供给传统行业计算领域的解决方案，当时 Oracle、IBM 也提了很多方案，包括出现的很多流程引擎。 它的思想是将紧耦合的系统，划分为面向业务的粗粒度、松耦合、无状态的服务。 在这之后，微服务的提出者基于 SOA 做了一个改进，就把它变成单一职责、独立部署、细小的微服务，是一个相反的概念。 微服务与 DDD 今天我们一说到微服务就会想到 DDD，有不少朋友认为 DDD 就是为微服务而生的。其实不是这样的，我在接触 DDD 时，它最早是用来做 UML 设计、领域建模的。 DDD 讲究充血模型，而 J2EE 模型以传统的分层架构和 Spring 架构捆绑在一起形成了以贫血模型为主的架构模式。 贫血模型的优点是容易入门、分层清晰，而充血模型要求设计者前期对业务理解较深，不然后期项目会产生混乱。 另外就是 DDD 思想比较宽泛，导致形成百家争鸣的姿态，没有形成一套固定的方法论。 开发者不容易理解，所以后面关注 DDD 的人变少了，而微服务的提出巧妙地借鉴了 DDD 里面的限界上下文、子域、领域事件等关键词，在微服务得到越来越多业界认可的情况下，也给 DDD 带来了重新的焕发机会。 老支付架构遇到的挑战 判断项目好坏的两个角度 我们判断一个优秀项目的好坏，可以从优秀的代码和高可用架构两个方向来讲。 我们在设计高可用架构的同时，也不能忽视代码的重要性，优秀的代码指的是冗错能力、冥等操作、并发情况、死锁情况等，并不一定是指代码写得多漂亮。 这就好比盖楼一样，楼房的基础架子搭得很好，但盖房的工人不够专业，有很多需要注意的地方忽略了，那么在往里面填砖加瓦的时候出了问题。 后果就是房子经常漏雨，墙上有裂缝等各种问题出现，虽然不至于楼房塌陷，但楼房也已经变成了危楼。 从代码和设计的角度来看有： 由不合理的代码所引起的项目无扩展性 数据库经常发生死锁 数据库事务乱用，导致事务占用时间过长 代码容错能力很差，经常因为考虑不足引起事故 程序中打印的大量的无用日志，并且引起性能问题 常用配置信息依然从数据库中读取 滥用线程池，造成栈和堆溢出 从库中查询数据，每次全部查出 业务代码研发不考虑幂等操作 使用缓存不合理，存在惊群效应、缓存穿透等情况 代码上下流流程定义混乱 异常处理机制混乱 再从整体架构角度来看： 整体依然使用单体集群架构 采用单机房服务器布署方式 采用 Nginx+hessian 的方式实现服务化 业务架构划分不彻底，边界模糊 项目拆分不彻底，一个 […]
View Details最近社区针对框架的争论，从发文互怼再到粉丝站队再到大漠穷秋准备离职，令人唏嘘不已。不知从何而起，前端圈已经逐步变成了前端娱乐圈。越来越多的人开始站队 Angular、Vue、React，仅仅围绕这些库或者框架进行前端技术讨论，这实在不是什么好的现象。其实我想基于我个人的经验聊下前端的演进和未来，希望可以贡献微薄的力量，消除一些我个人认为的前端社区不太好的风气。 注意：以下只是我个人对于前端和业务的理解和感悟，不代表任何其他人和我所在公司、团队的观点，意见不同欢迎一起讨论。 ======== 以史为鉴，想要知道前端的未来，必须知道前端的过去，抽象前端发展的规律。 前端的历史 前端的发展始终伴随着端的发展。 PC 端的兴起 06 年左右国内互联网公司开始有了前端工程师的概念，原因很简单，是因为上网访问网页的人数增多，大型互联网公司为了提升用户体验专门剥离了这样一个岗位来解决相关问题。这是第一批专业前端工程师的起源。 在这几年中的发展，进行了很多轮的技术方案、框架、浏览器的演进。比如 jQuery 兼容性库，再到 Require.js 异步加载，再到现在 React、Vue、Angular 等附带编程思想的前端库以及前后端分离、前端构建器、样式预处理器等。这些演进都是随着 PC 端的用户量的增多和业务复杂度的提升，为了用户体验和开发者体验而进化的。 移动端的兴起 09 年左右，智能手机的兴起导致了移动端开发的热潮。人人拥有智能手机，这种特殊的端的特性，也产生了新的业务形态。因此无线前端相关需求开始爆发，无线前端开发、iOS/Android 工程师等需求量非常大。 这几年中的发展，先从最初把 PC 端页面放在手机上渲染，再到出来响应式设计的概念，再到专门做无线端页面，再到独立客户端和 Weex、React Native 这些跨终端的方案。也是出现了非常多的技术演进，这些演进不难看出也是因为用户量的增多和业务复杂度的提升，为了用户体验和开发者体验而进行优化的。 PC 端的衰落 14 年左右，其实 PC 端颓废之势早已显现，但在双十一下被放大。因此阿里系前端在这个时间点附近就开始弱化 PC 端前端的投入。 以前 PC 端业务，在无线端流量更大的直接被下掉，核心链路的 PC 端业务能用就可以了，不再做效果、功能迭代优化。甚至很多业务直接不做 PC 端只做无线端。业务指标也从 PC 的 PV、UV 变成了客户端的 DAU 等指标。 在这个时间，只做 PC 端的前端，毫无无线端经验的前端，将会慢慢丧失竞争力。PC 兼容库 jQuery 之流也渐渐被替换废弃，因为 PC 的业务很少花费精力做兼容性测试，甚至目前我们团队的业务从来都只测试最新版 Chrome。可以看到，随着端和业务形态的变化，很多前端演进的产物会逐步被替换废掉。 移动端的衰落 移动端目前还没有衰落，但一个端只要兴起，就会有衰落的时候。总会有新的、更好的、更高效的端来替代老的端。但这个时机是难以预测的。 前端的未来 回顾前端的历史，前端总是伴随的端的变化而变化： 端的出现 -> 业务场景的落地 -> 需要端的开发者 -> 端开发者学习、演进 -> 端的开发效率提升 -> 新的端出现 -> 端的没落 -> 端开发者转领域或者被淘汰 这也就是为什么前端需要学习这么多东西，有这么庞大的体系的原因。每一个端都有它自己的特性。比如未来可能会火的 VR、AR 端，它们的特性就不同于二维平面的移动端，掌握 VR、AR 端的开发就需要新学习很多三维图形图像以及图像识别领域的东西。 因此如果你想要知道前端的未来，你需要预测端的发展。但端的发展是很难预测的，回到 06 年，有谁会想到会有智能手机，并开创了移动端这个端？ 而现在火热的 […]
View DetailsAOP 概述 面向切面编程（aspect-oriented programming），是一种将横切关注点与业务逻辑分离的编程方式。每个横切关注点都集中在一个地方，而不是分散在多处代码中。这样使我们的服务模块更加简洁，因为它们只包含了主要关注点的代码，而次要的功能或者说辅助的功能被转移到切面中了。 aop-1.png 上图表示划分为三个服务模块的应用，每个模块提供相应的服务，而且这些模块都需要类似的辅助功能，例如日志、安全、事务等等。我们并不想在各个模块中写重复的日志、安全、事务的代码，那么就可以使用选用切面这个方案，来解决这个问题。 AOP 术语 aop-2.png advice – 通知 切面的具体行为，即要切入执行的代码 pointcut – 切点 通知被应用的具体位置 join point – 连接点 程序运行时，能够应用通知的所有点 aspect – 切面 什么时候在什么地方做什么事情，是切点和通知的结合 target – 目标对象 被切入功能的目标对象 introduction – 引入 将新的方法或属性引入到现有的类中 weaving – 织入 把切面应用到目标对象并创建新的代理对象的过程 代理模式 代理模式是使用代理对象完成用户请求，屏蔽用户对真实对象访问的一种设计模式。现实生活中，代理人被授权执行当事人的一些事宜，无需当事人出面，从第三方的角度看，他只和代理人通信。而事实上代理人是要有当事人的授权，并且在核心问题上还需要请示当事人。 AOP 就是使用代理模式实现的，其中的代理类就相当于AOP中的切面。 aop-3.png 静态代理 之所以称为静态代理，是因为在程序运行前，代理类就已经存在了。 举个例子 一般艺人都需要助理，来帮他跑腿，演出前谈价格，演出后收钱，只有表演的时候艺人才亲自出马。 定义一个艺人接口
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
package org.nocoder.proxy.staticproxy; /** * 艺人接口 * @author jason * @date 2019/2/14. */ public interface Artist { /** * 表演 */ void perform(); } |
定义艺人实现类刘德华
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
package org.nocoder.proxy.staticproxy; /** * 艺人刘德华 * * @author jason * @date 2019/2/14. */ public class LiuDehua implements Artist { private LiuDehua() { } public static LiuDehua getInstance() { return new LiuDehua(); } public void perform() { System.out.println("刘德华出场演唱笨小孩..."); } } |
编写代理类
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 |
package org.nocoder.proxy.staticproxy; /** * 艺人助理（代理类） * * @author jason * @date 2019/2/14. */ public class ArtistProxy implements Artist { private LiuDehua liuDehua; private ArtistProxy() { } public ArtistProxy(LiuDehua liuDehua) { this.liuDehua = liuDehua; } public void perform() { System.out.println("助理出面谈价格，签合同..."); liuDehua.perform(); System.out.println("助理出面收钱..."); } } |
运行main方法，将艺人实例传入代理类的构造方法，然后调用代理类的perform()
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
package org.nocoder.proxy.staticproxy; /** * @author jason * @date 2019/2/14. */ public class StaticProxyDemo { public static void main(String[] args) { LiuDehua liuDehua = LiuDehua.getInstance(); ArtistProxy proxy = new ArtistProxy(liuDehua); proxy.perform(); } } |
运行结果
|
1 2 3 4 5 |
助理出面谈价格，签合同... 刘德华出场演唱笨小孩... 助理出面收钱... Process finished with exit code 0 |
静态代理的缺点 假设主题接口中的方法很多，为每一个接口写一个代理方法也很麻烦。如果接口有变动，则真实主题和代理类都要修改，不利于系统维护； 动态代理 动态代理是在程序运行时，利用Java反射机制动态的生成代理类的代理模式。 Jdk动态代理 JDK的动态代理依靠接口实现 如果类并没有实现接口，则不能使用Jdk的动态代理 定义图书服务接口
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
package org.nocoder.proxy.jdkproxy; /** * 图书服务接口 * @author jason * @date 2019/2/14. */ public interface BookService { /** * 新增图书接口 */ void addBook(); } |
编写图书服务实现类
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
package org.nocoder.proxy.jdkproxy; /** * 图书服务实现类 * @author jason * @date 2019/2/14. */ public class BookServiceImpl implements BookService { @Override public void addBook() { System.out.println("新增图书"); } } |
编写InvocationHandler实现类
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 |
package org.nocoder.proxy.jdkproxy; import java.lang.reflect.InvocationHandler; import java.lang.reflect.Method; /** * JDK 动态代理 * @author jason * @date 2019/2/14. */ public class BookServiceInvocationHandler implements InvocationHandler { private Object target; public BookServiceInvocationHandler(Object target){ this.target = target; } @Override public Object invoke(Object proxy, Method method, Object[] args) throws Throwable { System.out.println("事务开始"); Object result = method.invoke(target, args); System.out.println("事务结束"); return result; } } |
运行测试程序
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 |
package org.nocoder.proxy.jdkproxy; import java.lang.reflect.Proxy; /** * JDK动态代理演示 * * @author jason * @date 2019/2/14. */ public class JdkProxyDemo { public static void main(String[] args) { BookServiceInvocationHandler invocationHandler = new BookServiceInvocationHandler(new BookServiceImpl()); // JDK 动态代理只支持接口 BookService bookServiceProxy = (BookService) Proxy.newProxyInstance( BookServiceImpl.class.getClassLoader(), BookServiceImpl.class.getInterfaces(), invocationHandler); bookServiceProxy.addBook(); } } |
运行结果
|
1 2 3 4 5 |
事务开始 新增图书 事务结束 Process finished with exit code 0 |
CGLIB动态代理 JDK的动态代理依靠接口实现，如果有些类并没有实现接口，则不能使用JDK代理，这时就要使用cglib动态代理了。使用cglib需要依赖cglib的jar，使用maven为例
|
1 2 3 4 5 |
<dependency> <groupId>cglib</groupId> <artifactId>cglib-nodep</artifactId> <version>3.2.4</version> </dependency> |
定义图书服务类
|
1 2 3 4 5 6 7 8 9 10 11 |
package org.nocoder.proxy.cglibproxy; /** * @author jason * @date 2019/2/14. */ public class BookService { public void addBook() { System.out.println("新增图书"); } } |
编写MethodInterceptor实现类
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
package org.nocoder.proxy.cglibproxy; import net.sf.cglib.proxy.MethodInterceptor; import net.sf.cglib.proxy.MethodProxy; import java.lang.reflect.Method; /** * @author jason * @date 2019/2/14. */ public class BookServiceMethodInterceptor implements MethodInterceptor { @Override public Object intercept(Object o, Method method, Object[] objects, MethodProxy methodProxy) throws Throwable { System.out.println("事务开始"); methodProxy.invokeSuper(o, objects); System.out.println("事务结束"); return null; } } |
运行测试程序 […]
View DetailsDubbo 出生于阿里系，是阿里巴巴服务化治理的核心框架，并被广泛应用于中国各互联网公司；只需要通过 Spring 配置的方式即可完成服务化，对于应用无入侵，设计的目的还是服务于自身的业务为主。 微服务架构是互联网很热门的话题，是互联网技术发展的必然结果。它提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。 虽然微服务架构没有公认的技术标准和规范或者草案，但业界已经有一些很有影响力的开源微服务架构框架提供了微服务的关键思路，例如 Dubbo 和 Spring Cloud。 各大互联网公司也有自研的微服务框架，但其模式都与这二者相差不大。 微服务主要的优势 降低复杂度 将原来耦合在一起的复杂业务拆分为单个服务，规避了原本复杂度无止境的积累。 每一个微服务专注于单一功能，并通过定义良好的接口清晰表述服务边界；每个服务开发者只专注服务本身，通过使用缓存、DAL 等各种技术手段来提升系统的性能，而对于消费方来说完全透明。 可独立部署 由于微服务具备独立的运行进程，所以每个微服务可以独立部署。当业务迭代时只需要发布相关服务的迭代即可，降低了测试的工作量同时也降低了服务发布的风险。 容错 在微服务架构下，当某一组件发生故障时，故障会被隔离在单个服务中。比如通过限流、熔断等方式降低错误导致的危害，保障核心业务正常运行。 扩展 单块架构应用也可以实现横向扩展，就是将整个应用完整的复制到不同的节点。 当应用的不同组件在扩展需求上存在差异时，微服务架构便体现出其灵活性，因为每个服务可以根据实际需求独立进行扩展。 本文主要围绕微服务的技术选型、通讯协议、服务依赖模式、开始模式、运行模式等几方面来综合比较 Dubbo 和 Spring Cloud 这 2 种开发框架。 架构师可以根据公司的技术实力并结合项目的特点来选择某个合适的微服务架构平台，以此稳妥地实施项目的微服务化改造或开发进程。 核心部件 微服务的核心要素在于服务的发现、注册、路由、熔断、降级、分布式配置，基于上述几种必要条件对 Dubbo 和 Spring Cloud 做出对比。 总体架构 Dubbo 核心部件（如下图）: Provider：暴露服务的提供方，可以通过 jar 或者容器的方式启动服务。 Consumer：调用远程服务的服务消费方。 Registry：服务注册中心和发现中心。 Monitor：统计服务和调用次数，调用时间监控中心。（Dubbo 的控制台页面中可以显示，目前只有一个简单版本。） Container：服务运行的容器。 Dubbo 总体架构 Spring Cloud总体架构（如下图）： Service Provider： 暴露服务的提供方。 Service Consumer：调用远程服务的服务消费方。 EureKa Server： 服务注册中心和服务发现中心。 Spring Cloud 总体架构 点评：从整体架构上来看，二者模式接近，都需要服务提供方，注册中心，服务消费方。 微服务架构核心要素 Dubbo 只是实现了服务治理，而 Spring Cloud 子项目分别覆盖了微服务架构下的众多部件，服务治理只是其中的一个方面。 Dubbo 提供了各种 Filter，对于上述中“无”的要素，可以通过扩展 Filter 来完善。例如： 分布式配置：可以使用淘宝的 diamond、百度的 disconf 来实现分布式配置管理。 服务跟踪：可以使用京东开源的 Hydra，或者扩展 Filter 用 Zippin 来做服务跟踪。 批量任务：可以使用当当开源的 Elastic-Job、tbschedule。 点评：从核心要素来看，Spring […]
View Details0x00 起因 最近需要一个在线编辑器，之前听人说过百度的UEditor不错，去官网下了一个。不过服务端只有ASP.NET版的，如果是为了能尽快使用，只要把ASP.NET版的服务端作为应用部署在IIS上就可以立即使用了。不过我的需求并不急，所以把ASP.NET移植到了ASP.NET Core上。整个过程很简单，只是重新引用了一些包，修改了几处代码，另外就是把Controller中比较长的一个switch语句块重构为了字典，根据url中的action参数从字典中找出并调用相应的Action处理，这样的好处就是如果要扩展action支持的操作无需修改源代码，只要扩展字典就可以，对扩展开放，对修改关闭。最后把服务端功能打成了nuget包UEditorNetCore，方便使用。这篇博客主要就介绍下如何使用UEditorNetCore快速实现UEditor服务端，也可以直接使用源代码中的示例，希望对有这方面需求的园友有所帮助。 0x01 总体设计 当接收到action后，UEditorService会从UEditorActionCollection中找到这个action对应的方法并调用，同时传入HttpContext参数。这些方法调用基层的服务XxxxHandler完成功能，并把返回内容通过HttpContext.Response.WriteAsync()方法写入。如果要扩展对action的支持，可以扩展UEditorActionCollection，具体方法后面有介绍。 0x02 如何使用UEditorNetCore 1.安装UEditorNetCore
|
1 |
Install-Package UEditorNetCore |
2.在Startup.cs的ConfigureServices方法中添加UEditorNetCore服务
|
1 2 3 4 5 6 7 |
public void ConfigureServices(IServiceCollection services) { //第一个参数为配置文件路径，默认为项目目录下config.json //第二个参数为是否缓存配置文件，默认false services.AddUEditorService() services.AddMvc(); } |
3.添加Controller用于处理来自UEditor的请求
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
[Route("api/[controller]")] //配置路由 public class UEditorController : Controller { private UEditorService ue; public UEditorController(UEditorService ue) { this.ue = ue; } public void Do() { ue.DoAction(HttpContext); } } |
4.修改前端配置文件ueditor.config.js serverUrl需要参照第3步Controller中配置的路由，按照上面步骤3中的配置，需要以下配置：
|
1 |
serverUrl:"/api/UEditor" |
这样配置后当前端要获取服务端UEditor配置时就会访问/api/UEditor?action=config。 5.修改服务端配置config.json 上传类的操作需要配置相应的PathFormat和Prefix。示例部署在web根目录，因此Prefix都设置为"/"。使用时要根据具体情况配置。 例如示例中图片上传的配置如下：
|
1 2 |
"imageUrlPrefix": "/", /* 图片访问路径前缀 */ "imagePathFormat": "upload/image/{yyyy}{mm}{dd}/{time}{rand:6}", |
关于PathFormat的详细配置可参照官方文档。 6.添加javascript引用
|
1 2 3 |
<script type="text/javascript" charset="utf-8" src="~/lib/ueditor/ueditor.config.js"></script> <script type="text/javascript" charset="utf-8" src="~/lib/ueditor/ueditor.all.min.js"> </script> <script type="text/javascript" charset="utf-8" src="~/lib/ueditor/lang/zh-cn/zh-cn.js"></script> |
0x03 扩展action UEditor前端和后端交互主要通过在url中给出不同的action参数实现的，例如/api/UEditor?action=config会从服务端获取UEditor配置信息。UEditorNetCore目前支持的有8种action： config 获取服务端配置信息 uploadimage 上传图片 uploadscrawl 上传涂鸦 uploadvideo 上传视频 uploadfile 上传文件 listimage 多图片上传 listfile 多文件上传 catchimage 抓取图片 如果以上action无法满足需求，可以方便的增加、覆盖、移除action。 增加action
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
public void ConfigureServices(IServiceCollection services) { services.AddUEditorService() .Add("test", context => { context.Response.WriteAsync("from test action"); }) .Add("test2", context => { context.Response.WriteAsync("from test2 action"); }); services.AddMvc(); } |
以上代码增加了名字为test和test2两个action，作为示例仅仅返回了字符串。当访问/api/UEditor?action=test时会返回"from test action"。在扩展action时可以使用Config获取服务端配置，也可以使用已有的Handlers，具体可以参考源代码。 覆盖现有action 上面的Add方法除了添加新action外还可以覆盖现有action。当现有的action可能不符合你的要求，可以Add一个同名的action覆盖现有的。 移除action 如果要移除某个action，可以使用Remove方法。
|
1 2 3 4 5 6 |
public void ConfigureServices(IServiceCollection services) { services.AddUEditorService() .Remove("uploadvideo"); services.AddMvc(); } |
以上代码中的Remove("uploadvideo")方法移除了名为uploadvideo的action。 0x04 相关资源 UEditorNetCore代码和示例：https://github.com/durow/UEditorNetCore UEditor代码：https://github.com/fex-team/ueditor UEditor官网：http://ueditor.baidu.com/website/index.html from:https://www.cnblogs.com/durow/p/6116393.html
View Detailsrandom() 方法可返回介于 0 ~ 1 之间的一个随机数。 这里有几种用法： 1.从数组中随机获取成员 var items = [12,a,9,p,8]; var randomItem = items[Math.floor(Math.random() * items.length)]; 2.生成从0到指定值的数字数组 var numbersArray = [] , max = 100; for( var i=1; numbersArray.push(i++) < max;); // numbers = [1,2,3 … 100] 3.生成随机的字母数字字符串 function radomcharnum(len){ var str = ""; for(;str.length<len;str+=Math.random().toString(36).substr(2)); return str.substr(0,len); } 3.得到指定范围的整数(需要Math.floor()或者parseInt()或者Math.ceil()) var randomNum = Math.random()*5; console.log(parseInt(randomNum));//1 console.log(Math.floor(randomNum));//0 Math.floor(Math.random()*(max-min+1)+min);//max为期待的最大的数，min为最小的数 使用parseInt也是可以的。 from:https://www.cnblogs.com/Catherine001/p/7265597.html
View DetailsDownload VMMap (626 KB) Run now from Sysinternals Live. Introduction VMMap is a process virtual and physical memory analysis utility. It shows a breakdown of a process’s committed virtual memory types as well as the amount of physical memory (working set) assigned by the operating system to those types. Besides graphical representations of memory usage, VMMap also shows summary information and a detailed process memory map. Powerful filtering and refresh capabilities allow you to identify the sources of process memory usage and the memory cost of application features. Besides flexible views […]
View Details前世今生： Dubbo源于阿里的淘宝网开源的分布式的服务架构，致力于提供高性能和透明化的RPC远程服务调用方案，是SOA服务化治理方案的核心框架。淘宝网将其开源之后，得到了很多的拓展和支持（比较出名的有：当当网的扩展版本dubbox，京东的扩展版本jd-hydra等） Dubbox（即Dubbo eXtensions）是当当网Fork基于dubbo2.x的升级版本，兼容原有的dubbox。其中升级了zookeeper和spring版本，并且支持restfull风格的远程调用。。 版本： Dubbo目前已停止更新； Dubbox目前还在更新。 说明：dubbox和dubbo 2.x是兼容的， 没有改变dubbo的任何已有的功能和配置方式（除了升级了Spring之类的版本）。 据说淘宝网dubbo与一个非开源的框架HSF有争执，导致dubbo的团队已经解散了，但是其扩展的版本dubbox却得到不断的发展（升级更新）； <!——--升级详情——--|——————-- dubbox-2.8.0：该版本已经在生产环境中使用，主要支持REST风格远程调用、支持Kryo和FST序列化、升级了Spring和Zookeeper客户端、调整了demo应用等等 dubbox-2.8.1：主要支持基于嵌入式tomcat的http-remoting，优化了REST客户端性能，在REST中支持限制服务端接纳的最大HTTP连接数等等 dubbox-2.8.2： 支持REST中的HTTP logging，包括HTTP header的字段和HTTP body中的消息体，方便调试、日志纪录等等 提供辅助类便于REST的中文处理 改变使用@Reference annotation配置时的异常处理方式，即当用annotation配置时，过去dubbo在启动期间不抛出依赖服务找不到的异常，而是在具体调用时抛出NPE，这与用XML配置时的行为不一致。 较大的充实了Dubbo REST的文档 dubbox-2.8.3： 在REST中支持dubbo统一的方式用bean validation annotation作参数校验（沈理） 在RpcContext上支持获取底层协议的Request/Response（沈理） 支持采用Spring的Java Config方式配置dubbo（马金凯） 在Dubbo协议中支持基于Jackson的json序列化（Dylan） 在Spring AOP代理过的对象上支持dubbo annotation配置（Dylan） 修正Dubbo管理界面中没有consumer时出现空指针异常（马金凯） 修正@Reference annotation中protocol设置不起作用的bug（沈理） 修正@Reference annotation放在setter方法上即会出错的bug（Dylan） 详见：https://github.com/dangdangdotcom/dubbox/releases ———/> 嵌入： dubbo：嵌入式Jetty dubbox：基于嵌入式tomcat实现dubbo的 HTTP remoting体系（即dubbo-remoting-http） 对Servlet API的支持： dubbo：2.5 dubbox：升级到3.1 序列化： dubbo： dubbox：基于Dubbo默认的RPC协议添加新的JSON序列化实现； 支持基于Kryo和FST的Java高效序列化实现； Zookeeper注册中心： dubbo：Dubbo提供了Zookeeper注册中心，在整个Dubbo的设计里面充分考虑到了各类用户的需求，一些底层的通讯或者是信息存储都提供有大量的不同的存储方案； dubbox：升级ZooKeeper客户端到最新版本； 使用场景： dubbo：使用Dubbo的RPC调用方式，服务间仍然会存在API强依赖； dubbox：相对于Dubbo支持了REST风格的原创调用（HTTP +JSON/XML）； ——————————————————- ——简言之（dubbox基于dubbo的升级）： ——————- 支持REST风格远程调用（HTTP + JSON/XML)； 支持基于Kryo和FST的Java高效序列化实现； 支持基于Jackson的JSON序列化； 支持基于嵌入式Tomcat的HTTP remoting体系； 升级Spring至3.x； 升级ZooKeeper客户端； 支持完全基于Java代码的Dubbo配置； ————————————————- 附录： Dubbo： 官网首页：http://dubbo.io/ ， 官方用户指南： http://dubbo.io/User+Guide-zh.htm可以当做SOA架构的学习资料 Dubbox： dubbox入门：http://www.cnblogs.com/yjmyzz/p/dubbox-demo.html dubbox架构： http://www.cnblogs.com/Javame/p/3632473.html 当当网dubbox学习参考文档：http://dangdangdotcom.github.io/dubbox/ 分布式服务框架 dubbo/dubbox 入门示例：http://www.cnblogs.com/wanghang/p/6298957.html ———————- […]
View Details图形用户界面（Graphical User Interface，简称 GUI，又称图形用户接口）是指采用图形方式显示的计算机操作用户界面。 与早期计算机使用的命令行界面相比，图形界面对于用户来说在视觉上更易于接受。然而这界面若要通过在显示屏的特定位置，以”各种美观而不单调的视觉消息“提示用户”状态的改变“，势必得比简单的消息呈现花上更多的计算能力。 图形用户界面是一种人与计算机通信的界面显示格式，允许用户使用鼠标等输入设备操纵屏幕上的图标或菜单选项，以选择命令、调用文件、启动程序或执行其它一些日常任务。与通过键盘输入文本或字符命令来完成例行任务的字符界面相比，图形用户界面有许多优点。图形用户界面由窗口、下拉菜单、对话框及其相应的控制机制构成，在各种新式应用程序中都是标准化的，即相同的操作总是以同样的方式来完成，在图形用户界面，用户看到和操作的都是图形对象，应用的是计算机图形学的技术。 GUI 即人机交互图形化用户界面设计。纵观国际相关产业在图形化用户界面设计方面的发展现状，许多国际知名公司早已意识到 GUI 在产品方面产生的强大增值功能，以及带动的巨大市场价值，因此在公司内部设立了相关部门专门从事 GUI 的研究与设计，同业间也成立了若干机构，以互相交流 GUI 设计理论与经验为目的。随着中国 IT 产业，移动通讯产业，家电产业的迅猛发展，在产品的人机交互界面设计水平发展上日显滞后，这对于提高产业综合素质，提升与国际同等业者的竞争能力等等方面无疑起了制约的作用。 GUI的广泛应用是当今计算机发展的重大成就之一，它极大地方便了非专业用户的使用。人们从此不再需要死记硬背大量的命令，取而代之的是可以通过窗口、菜单、按键等方式来方便地进行操作。而嵌入式GUI具有下面几个方面的基本要求：轻型、占用资源少、高性能、高可靠性、便于移植、可配置等特点。 from:https://baike.baidu.com/item/GUI/479966
View Details