paulwong

2010年9月15日 #

JAX-RS2资源

JAX-RS 2比JAX-RS 1增加了过滤器、拦截器、异步处理等特性。@import url(http://www.blogjava.net/CuteSoft_Client/CuteEditor/Load.ashx?type=style&file=SyntaxHighlighter.css);@import url(/css/cuteeditor.css);

JAXRSClientSpringBoot
http://cxf.apache.org/docs/jaxrsclientspringboot.html

CXFSpringBoot
http://cxf.apache.org/docs/springboot.html

Restfull Webservice书源码
https://github.com/feuyeux

JAX-RS 2.0 REST客户端编程实例
http://www.importnew.com/8939.html

本人的DEMO
https://git.oschina.net/paulwong/test-cxf

posted @ 2017-09-24 17:19 paulwong 阅读(117) | 评论 (0)编辑 收藏

SPRING CLOUD JWT资源


https://github.com/thomas-kendall/trivia-microservices


一个Spring Boot, JWT,AugularJS接口安全验证的简单例子
http://blog.csdn.net/offbye/article/details/47607711



https://github.com/tuanngda/spring-boot-oauth2-demo


Spring Oauth2 with JWT Sample
http://www.tuicool.com/articles/EjUFZj7


http://stackoverflow.com/questions/38156213/spring-cloud-zuul-jwt-for-value-reference-tokens

posted @ 2017-03-24 23:11 paulwong 阅读(159) | 评论 (0)编辑 收藏

Spring Boot Admin资源

Spring Boot Admin 的使用
http://blog.csdn.net/kinginblue/article/details/52132113

posted @ 2017-03-21 22:10 paulwong 阅读(109) | 评论 (0)编辑 收藏

DDD领域驱动设计 - 设计文档模板

设计文档模板:

  1. 系统背景和定位
  2. 业务需求描述
  3. 领域语言整理,主要是整理领域中的各种术语的定义,名词解释
  4. 领域划分(分析出子域、核心域、支撑域)
  5. 系统用例图
  6. 每个子域的领域模型设计(实体、值对象、聚合、领域事件,需要注意的是:领域模型是需要抽象的,要分析业务本质,而不是简单的直接对需求进行建模)
  7. 领域模型详细说明(如为什么这样设计的原因、模型内对象的关系、各种业务规则、数据一致性规则等)
  8. 领域服务、仓储、工厂设计
  9. Saga业务流程设计
  10. 关键聚合根的状态流转图
  11. 场景走查(讲述如何通过领域模型、领域服务、仓储、Saga流程等完成系统用例以及关键业务流程的)
  12. 架构设计(如传统三层架构、经典四层架构、CQRS/ES架构)

一些其他的思考:

  • 去除一切花俏的建模技巧,我觉得最重要的方向就是去努力分析问题和事物的本质,针对这个本质进行领域建模。这个领域建模,最主要的还是锻炼的人的事物抽象能力。10个人,建出来的领域模型都不同。本质原因就是大家对同一个问题的理解不同,对事物的本质的理解不同。虽然最终都能解决当前的问题,但是对适应未来需求变化的能力却是不同。
  • 所以,我们要把时间花在多理解业务上,让自己成为领域专家,只有这样,才能充分理解业务。多理解一点业务,你才能更好的抽象出业务本质背后的领域模型。很少有人能做到很快理解业务,并很快针对业务设计出正确的领域模型,至少我是不行。
  • 领域建模需要时间,是一个迭代的过程,人无完人。而时间很多时候也不会很充足,所以,不太可能一步到位把领域设计做的很完美。我们在整体项目规划的时候可能会有个大的架构设计、业务大图(边界思维),但是不可能达到领域设计的粒度,只能是一期一期的完善,到最后可能才会有完整的上面的目录内容。每一期都需要考虑支持的场景约束、上下文、系统边界、持续集成的相关设计。设计product, not project。

posted @ 2017-02-19 12:14 paulwong 阅读(150) | 评论 (0)编辑 收藏

浅谈我对DDD领域驱动设计的理解(转)

从遇到问题开始

当人们要做一个软件系统时,一般总是因为遇到了什么问题,然后希望通过一个软件系统来解决。

比如,我是一家企业,然后我觉得我现在线下销售自己的产品还不够,我希望能够在线上也能销售自己的产品。所以,自然而然就想到要做一个普通电商系统,用于实现在线销售自己企业产品的目的。

再比如,我是一家互联网公司,公司有很多系统对外提供服务,面向很多客户端设备。但是最近由于各种原因,导致服务经常出故障。所以,我们希望通过各种措施提高服务的质量和稳定性。其中的一个措施就是希望能做一个灰度发布的平台,这个平台可以提供灰度发布的服务。然后,当某个业务系统做了一些修改并需要发布时,可以使用我们的灰度发布平台来非常方便的实现灰度发布的功能。比如在灰度发布平台上方便的定制允许哪些特定的客户端才会访问新服务,哪些客户端继续使用老服务。灰度发布平台可以提供各种灰度的策略。有了这样的灰度发布机制,那即便系统的新逻辑有什么问题,受影响的面也不会很大,在可控范围内。所以,如果公司里的所有对外提供服务的系统都接入了灰度平台,那这些系统的发布环节就可以更加有保障了。

总之,我们做任何一个软件系统,都是有原因的,否则就没必要做这个系统,而这个原因就是我们遇到的问题。所以,通过问题,我们就知道了我们需要一个什么样的系统,这个系统解决什么样的问题。最后,我们就很自然的得出了一个目标,即知道了自己要什么。比如我要做一个论坛、一个博客系统、一个电商平台、一个灰度发布系统、一个IDE、一个分布式消息队列、一个通信框架,等等。

DDD切入点1 - 理解概念

DDD的全称为Domain-driven Design,即领域驱动设计。下面我从领域、问题域、领域模型、设计、驱动这几个词语的含义和联系的角度去阐述DDD是如何融入到我们平时的软件开发初期阶段的。要理解什么是领域驱动设计,首先要理解什么是领域,什么是设计,还有驱动是什么意思,什么驱动什么。

什么是领域(Domain)?

前面我们已经清楚的知道我们现在要做一个什么样的系统,这个系统需要解决什么问题。我认为任何一个系统都会属于某个特定的领域,比如论坛是一个领域,只要你想做一个论坛,那这个论坛的核心业务是确定的,比如都有用户发帖、回帖等核心基本功能。比如电商平台、普通电商系统,这种都属于网上电商领域,只要是这个领域的系统,那都有商品浏览、购物车、下单、减库存、付款交易等核心环节。所以,同一个领域的系统都具有相同的核心业务,因为他们要解决的问题的本质是类似的。

因此,我们可以推断出,一个领域本质上可以理解为就是一个问题域,只要是同一个领域,那问题域就相同。所以,只要我们确定了系统所属的领域,那这个系统的核心业务,即要解决的关键问题、问题的范围边界就基本确定了。通常我们说,要成为一个领域的专家,必须要在这个领域深入研究很多年才行。因为只有你研究了很多年,你才会遇到非常多的该领域的问题,同时你解决这个领域中的问题的经验也非常丰富。很多时候,领域专家比技术专家更加吃香,比如金融领域的专家。

什么是设计(Design)?

DDD中的设计主要指领域模型的设计。为什么是领域模型的设计而不是架构设计或其他的什么设计呢?因为DDD是一种基于模型驱动开发的软件开发思想,强调领域模型是整个系统的核心,领域模型也是整个系统的核心价值所在。每一个领域,都有一个对应的领域模型,领域模型能够很好的帮我们解决复杂的业务问题。

从领域和代码实现的角度来理解,领域模型绑定了领域和代码实现,确保了最终的代码实现就一定是解决了领域中的核心问题的。因为:1)领域驱动领域模型设计;2)领域模型驱动代码实现。我们只要保证领域模型的设计是正确的,就能确定领域模型可以解决领域中的核心问题;同理,我们只要保证代码实现是严格按照领域模型的意图来落地的,那就能保证最后出来的代码能够解决领域的核心问题的。这个思路,和传统的分析、设计、编码这几个阶段被割裂(并且每个阶段的产物也不同)的软件开发方法学形成鲜明的对比。

什么是驱动(Driven)?

上面其实已经提到了,就是:1)领域驱动领域模型设计;2)领域模型驱动代码实现。这个就和我们传统的数据库驱动开发的思路形成对比了。DDD中,我们总是以领域为边界,分析领域中的核心问题(核心关注点),然后设计对应的领域模型,再通过领域模型驱动代码实现。而像数据库设计、持久化技术等这些都不是DDD的核心,而是外围的东西。

领域驱动设计(DDD)告诉我们的最大价值我觉得是:当我们要开发一个系统时,应该尽量先把领域模型想清楚,然后再开始动手编码,这样的系统后期才会很好维护。但是,很多项目(尤其是互联网项目,为了赶工)都是一开始模型没想清楚,一上来就开始建表写代码,代码写的非常冗余,完全是过程是的思考方式,最后导致系统非常难以维护。而且更糟糕的是,出来混总是要还的,前期的领域模型设计的不好,不够抽象,如果你的系统会长期需要维护和适应业务变化,那后面你一定会遇到各种问题维护上的困难,比如数据结构设计不合理,代码到处冗余,改BUG到处引入新的BUG,新人对这种代码上手困难,等。而那时如果你再想重构模型,那要付出的代价会比一开始重新开发还要大,因为你还要考虑兼容历史的数据,数据迁移,如何平滑发布等各种头疼的问题。所以,就导致我们最后天天加班。

虽然,我们都知道这个道理,但是我也明白,人的习惯很难改变的,大部分人都很难从面向过程式的想到哪里写到哪里的思想转变为基于系统化的模型驱动的思维。我想,这或许是DDD很难在中国或国外流行起来的原因吧。但是,我想这不应该成为我们放弃学习DDD的原因,对吧!

概念总结:

  1. 领域就是问题域,有边界,领域中有很多问题;
  2. 任何一个系统要解决的那个大问题都对应一个领域;
  3. 通过建立领域模型来解决领域中的核心问题,模型驱动的思想;
  4. 领域建模的目标针对我们在领域中所关心的问题,即只针对核心关注点,而不是整个领域中的所有问题;
  5. 领域模型在设计时应考虑一定的抽象性、通用性,以及复用价值;
  6. 通过领域模型驱动代码的实现,确保代码让领域模型落地,代码最终能解决问题;
  7. 领域模型是系统的核心,是领域内的业务的直接沉淀,具有非常大的业务价值;
  8. 技术架构设计或数据存储等是在领域模型的外围,帮助领域模型进行落地;

DDD切入点2 - 理解领域、拆分领域、细化领域

理解领域知识是基础

上面我们通过第一步,虽然我们明确了要做一个什么样的系统,该系统主要解决什么问题,但是就这样我们还无法开始进行实际的需求分析和模型设计,我们还必须将我们的问题进行拆分,需求进行细化。有些时候,需求方,即提出问题的人,很可能自己不清楚具体想要什么。他只知道一个概念,一个大的目标。比如他只知道要做一个股票交易系统,一个灰度发布系统,一个电商平台,一个开发工具,等。但是他不清楚这些系统应该具体做成什么样子。这个时候,我认为领域专家就非常重要了,DDD也非常强调领域专家的重要性。因为领域专家对这个领域非常了解,对领域内的各种业务场景和各种业务规则也非常清楚,总之,对这个领域内的一切业务相关的知识都非常了解。所以,他们自然就有能力表达出系统该做成什么样子。所以,要知道一个系统到底该做成什么样子,到底哪些是核心业务关注点,只能靠沉淀领域内的各种知识,别无他法。因此,假设你现在打算做一个电商平台,但是你对这个领域没什么了解,那你一定得先去了解下该领域内主流的电商平台,比如淘宝、天猫、京东、亚马逊等。这个了解的过程就是你沉淀领域知识的过程。如果你不了解,就算你领域建模的能力再强,各种技术架构能力再强也是使不上力。领域专家不是某个固定的角色,而是某一类人,这类人对这个领域非常了解。比如,一个开发人员也可以是一个领域专家。假设你在一个公司开发和维护一个系统已经好几年了,但是这个系统的产品经理(PD)可能已经换过好几任了,这种情况下,我相信这几任产品经理都没有比你更熟悉这个领域。

拆分领域

上面我们明白了,领域建模的基础是要先理解领域,让自己成为领域专家。如果做到了这点,我们就打好了坚实的基础了。但是,有时一个领域往往太复杂,涉及到的领域概念、业务规则、交互流程太多,导致我们没办法直接针对这个大的领域进行领域建模。所以,我们需要将领域进行拆分,本质上就是把大问题拆分为小问题,然后各个击破的思路。然后既然把一个大的领域划分为了多个小的领域(子域),那最关键的就是要理清每个子域的边界;然后要搞清楚哪些子域是核心子域,哪些是非核心子域,哪些是公共支撑子域;然后,还要思考子域之间的联系是什么。那么,我们该如何划分子域呢?我的个人看法是从业务相关性的角度去思考,也就是我们平时说的按业务功能为出发点进行划分。还是拿经典的电商系统来分析,通常一个电商系统都会包含好几个大块,比如:

  • 会员中心:负责用户账号登录、用户信息的管理;
  • 商品中心:负责商品的展示、导航、维护;
  • 订单中心:负责订单的生成和生命周期管理;
  • 交易中心:负责交易相关的业务;
  • 库存中心:负责维护商品的库存;
  • 促销中心:负责各种促销活动的支持;

上面这些中心看起来很自然,因为大家对电子商务的这个领域都已经非常熟悉了,所以都没什么疑问,好像很自然的样子。所以,领域划分是不是就是没什么挑战了呢?显然不是。之所以我们觉得子域划分很简单,是因为我们对整个大领域非常了解了。如果我们遇到一个冷门的领域,就没办法这么容易的去划分子域了。这就需要我们先去努力理解领域内的知识。所以,我个人从来不相信什么子域划分的技巧什么的东西,因为我觉得这个工作没有任何诀窍可以使用。当我们不了解一个东西的时候,如何去拆解它?当我们对整个领域有一定的熟悉了,了解了领域内的相关业务的本质和关系,我们就自然而然的能划分出合理的子域了。不过并不是所有的系统都需要划分子域的,有些系统只是解决一个小问题,这个问题不复杂,可能只有一两个核心概念。所以,这种系统完全不需要再划分子域。但不是绝对的,当一个领域,我们的关注点越来越多,每个关注点我们关注的信息越来越多的时候,我们会不由自主的去进一步的划分子域。比如,也许我们一开始将商品和商品的库存都放在商品中心里,但是后来由于库存的维护越来越复杂,导致揉在一起对我们的系统维护带来一定的困难时,我们就会考虑将两者进行拆分,这个就是所谓的业务垂直分割。

细化子域

通过上面的两步,我们了解了领域里的知识,也对领域进行了子域划分。但这样还不够,凭这些我们还无法进行后续的领域模型设计。我们还必须再进一步细化每个子域,进一步明确每个子域的核心关注点,即需求细化。我觉得我们需要细化的方面有以下几点:

  1. 梳理领域概念:梳理出领域内我们关注的概念、概念的关系,并统一交流词汇,形成统一语言;
  2. 梳理业务规则:梳理出领域内我们关注的各种业务规则,DDD中叫不变性(invariants),比如唯一性规则,余额不能小于零等;
  3. 梳理业务场景:梳理出领域内的核心业务场景,比如电商平台中的加入购物车、提交订单、发起付款等核心业务场景;
  4. 梳理业务流程:梳理出领域内的关键业务流程,比如订单处理流程,退款流程等;

从上面这4个方面,我们从领域概念、业务规则、交互场景、业务流程等维度梳理了我们到底要什么,整理了整个系统应该具备的功能。这个工作我觉得是一个非常具有创造性和有难度的工作。我们一方面会主观的定义我们想要什么;另一方面,我们还会思考我们要的东西的合理性。我认为这个就是产品经理的工作,产品经理必须要负起职责,把他的产品充分设计好,从各个方面去考虑,如何设计一个产品,才能更好的解决用户的核心诉求,即领域内的核心问题。如果对领域不够了解,如果想不清楚用户到底要什么,如果思考问题不够全面,谈何设计出一个合理的产品呢?

关于领域概念的梳理,我觉得可以采用四色原型分析法,这个分析法通过系统的方法,将概念划分为不同的种类,为不同种类的概念标注不同的颜色。然后将这些概念有机的组合起来,从而让我们可以清晰的分析出概念和概念之间的关系。有兴趣的同学可以在网上搜索下四色原型

注意:上面我说的这四点,重点是梳理出我们要什么功能,而不是思考如何实现这些功能,如何实现是软件设计人员的职责。

DDD切入点3 - 领域模型设计

这部分内容,我想学习DDD的人都很熟悉了。DDD原著中提出了很多实用的建模工具:聚合、实体、值对象、工厂、仓储、领域服务、领域事件。我们可以使用这些工具,来设计每一个子域的领域模型。最终通过领域模型图将设计沉淀下来。要使用这些工具,首先就要理解每个工具的含义和使用场景。不要以为很简单哦,比如聚合的划分就是一个非常具有艺术的活。同一个系统,不同的人设计出来的聚合是完全不同的。而且很有可能高手之间的最后设计出来的差别反而更大,实际上我认为是世界观的相互碰撞,呵呵。所以,要领域建模,我觉得每个人都应该去学学哲学知识,这有助于我们更好的认识世界,更好的理解事物的本质。

关于这些建模工具的概念和如何运用我就不多展开了,我博客里也有很多这方面的介绍。下面我再讲一下我认为比较重要的东西,比如到底该如何领域建模?步骤应该是怎么样的?

领域建模的方法

通过上面我介绍的细化子域的内容,现在再来谈该如何领域建模,我觉得就方便很多了。我的主要方法是:

  1. 划分好边界上下文,通常每个子域(sub domain)对应一个边界上下文(bounded context),同一个边界上下文中的概念是明确的,没有任何歧义;
  2. 在每个边界上下文中设计领域模型,具体的领域模型设计方法有很多种,如以场景为出发点的四色原型分析法,或者我早期写的这篇文章;这个步骤最核心的就是找出聚合根,并找出每个聚合根包含的信息;关于如何设计聚合,可以看一下我写的这篇文章
  3. 画出领域模型图,圈出每个模型中的聚合边界;
  4. 设计领域模型时,要考虑该领域模型是否满足业务规则,同时还要综合考虑技术实现等问题,比如并发问题;领域模型不是概念模型,概念模型不关注技术实现,领域模型关心;所以领域模型才能直接指导编码实现;
  5. 思考领域模型是如何在业务场景中发挥作用的,以及是如何参与到业务流程的每个环节的;
  6. 场景走查,确认领域模型是否能满足领域中的业务场景和业务流程;
  7. 模型持续重构、完善、精炼;

领域模型的核心作用:

  1. 抽象了领域内的核心概念,并建立概念之间的关系;
  2. 领域模型承担了领域内的状态的维护;
  3. 领域模型维护了领域内的数据之间的业务规则,数据一致性;

下图是我最近做个一个普通电商系统的商品中心的领域模型图,给大家参考:

领域模型设计只是软件设计中的一小部分

需要特别注意的是,领域模型设计只是整个软件设计中的很小一部分。除了领域模型设计之外,要落地一个系统,我们还有非常多的其他设计要做,比如:

  • 容量规划
  • 架构设计
  • 数据库设计
  • 缓存设计
  • 框架选型
  • 发布方案
  • 数据迁移、同步方案
  • 分库分表方案
  • 回滚方案
  • 高并发解决方案
  • 一致性选型
  • 性能压测方案
  • 监控报警方案

等等。上面这些都需要我们平时的大量学习和积累。作为一个合格的开发人员或架构师,我觉得除了要会DDD领域驱动设计,还要会上面这么多的技术能力,确实是非常不容易的。所以,千万不要以为会DDD了就以为自己很牛逼,实际上你会的只是软件设计中的冰山一角而已。

总结

本文的重点是基于我个人对DDD的一些理解,希望能整理出一些自己总结出来的一些感悟和经验,并分享给大家。我相信很多人已经看过太多DDD书上的东西,我总是感觉书上的东西看似都太”正规“,很多时候我们读了之后很难消化,就算理解了书里的内容,当我们想要运用到实践中时,总是感觉无从下手。本文希望通过通俗易懂的文字,介绍了一部分我对DDD的学习感悟和实践心得,希望能给大家一些启发和帮助。

posted @ 2017-02-19 12:12 paulwong 阅读(158) | 评论 (0)编辑 收藏

DDD CQRS架构和传统架构的优缺点比较

最近几年,在DDD的领域,我们经常会看到CQRS架构的概念。我个人也写了一个ENode框架,专门用来实现这个架构。CQRS架构本身的思想其实非常简单,就是读写分离。是一个很好理解的思想。就像我们用MySQL数据库的主备,数据写到主,然后查询从备来查,主备数据的同步由MySQL数据库自己负责,这是一种数据库层面的读写分离。关于CQRS架构的介绍其实已经非常多了,大家可以自行百度或google。我今天主要想总结一下这个架构相对于传统架构(三层架构、DDD经典四层架构)在数据一致性、扩展性、可用性、伸缩性、性能这几个方面的异同,希望可以总结出一些优点和缺点,为大家在做架构选型时提供参考。

前言

CQRS架构由于本身只是一个读写分离的思想,实现方式多种多样。比如数据存储不分离,仅仅只是代码层面读写分离,也是CQRS的体现;然后数据存储的读写分离,C端负责数据存储,Q端负责数据查询,Q端的数据通过C端产生的Event来同步,这种也是CQRS架构的一种实现。今天我讨论的CQRS架构就是指这种实现。另外很重要的一点,C端我们还会引入Event Sourcing+In Memory这两种架构思想,我认为这两种思想和CQRS架构可以完美的结合,发挥CQRS这个架构的最大价值。

数据一致性

传统架构,数据一般是强一致性的,我们通常会使用数据库事务保证一次操作的所有数据修改都在一个数据库事务里,从而保证了数据的强一致性。在分布式的场景,我们也同样希望数据的强一致性,就是使用分布式事务。但是众所周知,分布式事务的难度、成本是非常高的,而且采用分布式事务的系统的吞吐量都会比较低,系统的可用性也会比较低。所以,很多时候,我们也会放弃数据的强一致性,而采用最终一致性;从CAP定理的角度来说,就是放弃一致性,选择可用性。

CQRS架构,则完全秉持最终一致性的理念。这种架构基于一个很重要的假设,就是用户看到的数据总是旧的。对于一个多用户操作的系统,这种现象很普遍。比如秒杀的场景,当你下单前,也许界面上你看到的商品数量是有的,但是当你下单的时候,系统提示商品卖完了。其实我们只要仔细想想,也确实如此。因为我们在界面上看到的数据是从数据库取出来的,一旦显示到界面上,就不会变了。但是很可能其他人已经修改了数据库中的数据。这种现象在大部分系统中,尤其是高并发的WEB系统,尤其常见。

所以,基于这样的假设,我们知道,即便我们的系统做到了数据的强一致性,用户还是很可能会看到旧的数据。所以,这就给我们设计架构提供了一个新的思路。我们能否这样做:我们只需要确保系统的一切添加、删除、修改操作所基于的数据是最新的,而查询的数据不必是最新的。这样就很自然的引出了CQRS架构了。C端数据保持最新、做到数据强一致;Q端数据不必最新,通过C端的事件异步更新即可。所以,基于这个思路,我们开始思考,如何具体的去实现CQ两端。看到这里,也许你还有一个疑问,就是为何C端的数据是必须要最新的?这个其实很容易理解,因为你要修改数据,那你可能会有一些修改的业务规则判断,如果你基于的数据不是最新的,那意味着判断就失去意义或者说不准确,所以基于老的数据所做的修改是没有意义的。

扩展性

传统架构,各个组件之间是强依赖,都是对象之间直接方法调用;而CQRS架构,则是事件驱动的思想;从微观的聚合根层面,传统架构是应用层通过过程式的代码协调多个聚合根一次性以事务的方式完成整个业务操作。而CQRS架构,则是以Saga的思想,通过事件驱动的方式,最终实现多个聚合根的交互。另外,CQRS架构的CQ两端也是通过事件的方式异步进行数据同步,也是事件驱动的一种体现。上升到架构层面,那前者就是SOA的思想,后者是EDA的思想。SOA是一个服务调用另一个服务完成服务之间的交互,服务之间紧耦合;EDA是一个组件订阅另一个组件的事件消息,根据事件信息更新组件自己的状态,所以EDA架构,每个组件都不会依赖其他的组件;组件之间仅仅通过topic产生关联,耦合性非常低。

上面说了两种架构的耦合性,显而易见,耦合性低的架构,扩展性必然好。因为SOA的思路,当我要加一个新功能时,需要修改原来的代码;比如原来A服务调用了B,C两个服务,后来我们想多调用一个服务D,则需要改A服务的逻辑;而EDA架构,我们不需要动现有的代码,原来有B,C两订阅者订阅A产生的消息,现在只需要增加一个新的消息订阅者D即可。

从CQRS的角度来说,也有一个非常明显的例子,就是Q端的扩展性。假设我们原来Q端只是使用数据库实现的,但是后来系统的访问量增大,数据库的更新太慢或者满足不了高并发的查询了,所以我们希望增加缓存来应对高并发的查询。那对CQRS架构来说很容易,我们只需要增加一个新的事件订阅者,用来更新缓存即可。应该说,我们可以随时方便的增加Q端的数据存储类型。数据库、缓存、搜索引擎、NoSQL、日志,等等。我们可以根据自己的业务场景,选择合适的Q端数据存储,实现快速查询的目的。这一切都归功于我们C端记录了所有模型变化的事件,当我们要增加一种新的View存储时,可以根据这些事件得到View存储的最新状态。这种扩展性在传统架构下是很难做到的。

可用性

可用性,无论是传统架构还是CQRS架构,都可以做到高可用,只要我们做到让我们的系统中每个节点都无单点即可。但是,相比之下,我觉得CQRS架构在可用性方面,我们可以有更多的回避余地和选择空间。

传统架构,因为读写没有分离,所以可用性要把读写合在一起综合考虑,难度会比较更大。因为传统架构,如果一个系统的高峰期的并发写入很大,比如为2W,并发读取也很大,比如为10W。那该系统必须优化到能同时支持这种高并发的写入和查询,否则系统就会在高峰时挂掉。这个就是基于同步调用思路的系统的缺点,没有一个东西去削峰填谷,保存瞬间多出来的请求,而必须让系统不管遇到多少请求,都必须能及时处理完,否则就会造成雪崩效应,造成系统瘫痪。但是一个系统,不会一直处在高峰,高峰可能只有半小时或1小时;但为了确保高峰时系统不挂掉,我们必须使用足够的硬件去支撑这个高峰。而大部分时候,都不需要这么高的硬件资源,所以会造成资源的浪费。所以,我们说基于同步调用、SOA思想的系统的实现成本是非常昂贵的。

而在CQRS架构下,因为CQRS架构把读和写分离了,所以可用性相当于被隔离在了两个部分去考虑。我们只需要考虑C端如何解决写的可用性,Q端如何解决读的可用性即可。C端解决可用性,我觉得是更加容易的,因为C端是消息驱动的。我们要做任何数据修改时,都会发送Command到分布式消息队列,然后后端消费者处理Command->产生领域事件->持久化事件->发布事件到分布式消息队列->最后事件被Q端消费。这个链路是消息驱动的。相比传统架构的直接服务方法调用,可用性要高很多。因为就算我们处理Command的后端消费者暂时挂了,也不会影响前端Controller发送Command,Controller依然可用。从这个角度来说,CQRS架构在数据修改上可用性要更高。不过你可能会说,要是分布式消息队列挂了呢?呵呵,对,这确实也是有可能的。但是一般分布式消息队列属于中间件,一般中间件都具有很高的可用性(支持集群和主备切换),所以相比我们的应用来说,可用性要高很多。另外,因为命令是先发送到分布式消息队列,这样就能充分利用分布式消息队列的优势:异步化、拉模式、削峰填谷、基于队列的水平扩展。这些特性可以保证即便前端Controller在高峰时瞬间发送大量的Command过来,也不会导致后端处理Command的应用挂掉,因为我们是根据自己的消费能力拉取Command。这点也是CQRS C端在可用性方面的优势,其实本质也是分布式消息队列带来的优势。所以,从这里我们可以体会到EDA架构(事件驱动架构)是非常有价值的,这个架构也体现了我们目前比较流行的Reactive Programming(响应式编程)的思想。

然后,对于Q端,应该说和传统架构没什么区别,因为都是要处理高并发的查询。这点以前怎么优化的,现在还是怎么优化。但是就像我上面可扩展性里强调的,CQRS架构可以更方便的提供更多的View存储,数据库、缓存、搜索引擎、NoSQL,而且这些存储的更新完全可以并行进行,互相不会拖累。理想的场景,我觉得应该是,如果你的应用要实现全文索引这种复杂查询,那可以在Q端使用搜索引擎,比如ElasticSearch;如果你的查询场景可以通过keyvalue这种数据结构满足,那我们可以在Q端使用Redis这种NoSql分布式缓存。总之,我认为CQRS架构,我们解决查询问题会比传统架构更加容易,因为我们选择更多了。但是你可能会说,我的场景只能用关系型数据库解决,且查询的并发也是非常高。那没办法了,唯一的办法就是分散查询IO,我们对数据库做分库分表,以及对数据库做一主多备,查询走备机。这点上,解决思路就是和传统架构一样了。

性能、伸缩性

本来想把性能和伸缩性分开写的,但是想想这两个其实有一定的关联,所以决定放在一起写。

伸缩性的意思是,当一个系统,在100人访问时,性能(吞吐量、响应时间)很不错,在100W人访问时性能也同样不错,这就是伸缩性。100人访问和100W人访问,对系统的压力显然是不同的。如果我们的系统,在架构上,能够做到通过简单的增加机器,就能提高系统的服务能力,那我们就可以说这种架构的伸缩性很强。那我们来想想传统架构和CQRS架构在性能和伸缩性上面的表现。

说到性能,大家一般会先思考一个系统的性能瓶颈在哪里。只要我们解决了性能瓶颈,那系统就意味着具有通过水平扩展来达到可伸缩的目的了(当然这里没有考虑数据存储的水平扩展)。所以,我们只要分析一下传统架构和CQRS架构的瓶颈点在哪里即可。

传统架构,瓶颈通常在底层数据库。然后我们一般的做法是,对于读:通常使用缓存就可以解决大部分查询问题;对于写:办法也有很多,比如分库分表,或者使用NoSQL,等等。比如阿里大量采用分库分表的方案,而且未来应该会全部使用高大上的OceanBase来替代分库分表的方案。通过分库分表,本来一台数据库服务器高峰时可能要承受10W的高并发写,如果我们把数据放到十台数据库服务器上,那每台机器只需要承担1W的写,相对于要承受10W的写,现在写1W就显得轻松很多了。所以,应该说数据存储对传统架构来说,也早已不再是瓶颈了。

传统架构一次数据修改的步骤是:1)从DB取出数据到内存;2)内存修改数据;3)更新数据回DB。总共涉及到2次数据库IO。

然后CQRS架构,CQ两端加起来所用的时间肯定比传统架构要多,因为CQRS架构最多有3次数据库IO,1)持久化命令;2)持久化事件;3)根据事件更新读库。为什么说最多?因为持久化命令这一步不是必须的,有一种场景是不需要持久化命令的。CQRS架构中持久化命令的目的是为了做幂等处理,即我们要防止同一个命令被处理两次。那哪一种场景下可以不需要持久化命令呢?就是当命令时在创建聚合根时,可以不需要持久化命令,因为创建聚合根所产生的事件的版本号总是为1,所以我们在持久化事件时根据事件版本号就能检测到这种重复。

所以,我们说,你要用CQRS架构,就必须要接受CQ数据的最终一致性,因为如果你以读库的更新完成为操作处理完成的话,那一次业务场景所用的时间很可能比传统架构要多。但是,如果我们以C端的处理为结束的话,则CQRS架构可能要快,因为C端可能只需要一次数据库IO。我觉得这里有一点很重要,对于CQRS架构,我们更加关注C端处理完成所用的时间;而Q端的处理稍微慢一点没关系,因为Q端只是供我们查看数据用的(最终一致性)。我们选择CQRS架构,就必须要接受Q端数据更新有一点点延迟的缺点,否则就不应该使用这种架构。所以,希望大家在根据你的业务场景做架构选型时一定要充分认识到这一点。

另外,上面再谈到数据一致性时提到,传统架构会使用事务来保证数据的强一致性;如果事务越复杂,那一次事务锁的表就越多,锁是系统伸缩性的大敌;而CQRS架构,一个命令只会修改一个聚合根,如果要修改多个聚合根,则通过Saga来实现。从而绕过了复杂事务的问题,通过最终一致性的思路做到了最大的并行和最少的并发,从而整体上提高系统的吞吐能力。

所以,总体来说,性能瓶颈方面,两种架构都能克服。而只要克服了性能瓶颈,那伸缩性就不是问题了(当然,这里我没有考虑数据丢失而带来的系统不可用的问题。这个问题是所有架构都无法回避的问题,唯一的解决办法就是数据冗余,这里不做展开了)。两者的瓶颈都在数据的持久化上,但是传统的架构因为大部分系统都是要存储数据到关系型数据库,所以只能自己采用分库分表的方案。而CQRS架构,如果我们只关注C端的瓶颈,由于C端要保存的东西很简单,就是命令和事件;如果你信的过一些成熟的NoSQL(我觉得使用文档性数据库如MongoDB这种比较适合存储命令和事件),且你也有足够的能力和经验去运维它们,那可以考虑使用NoSQL来持久化。如果你觉得NoSQL靠不住或者没办法完全掌控,那可以使用关系型数据库。但这样你也要付出努力,比如需要自己负责分库分表来保存命令和事件,因为命令和事件的数据量都是很大的。不过目前一些云服务如阿里云,已经提供了DRDS这种直接支持分库分表的数据库存储方案,极大的简化了我们存储命令和事件的成本。就我个人而言,我觉得我还是会采用分库分表的方案,原因很简单:确保数据可靠落地、成熟、可控,而且支持这种只读数据的落地,框架内置要支持分库分表也不是什么难事。所以,通过这个对比我们知道传统架构,我们必须使用分库分表(除非阿里这种高大上可以使用OceanBase);而CQRS架构,可以带给我们更多选择空间。因为持久化命令和事件是很简单的,它们都是不可修改的只读数据,且对kv存储友好,也可以选择文档型NoSQL,C端永远是新增数据,而没有修改或删除数据。最后,就是关于Q端的瓶颈,如果你Q端也是使用关系型数据库,那和传统架构一样,该怎么优化就怎么优化。而CQRS架构允许你使用其他的架构来实现Q,所以优化手段相对更多。

结束语

我觉得不论是传统架构还是CQRS架构,都是不错的架构。传统架构门槛低,懂的人也多,且因为大部分项目都没有什么大的并发写入量和数据量。所以应该说大部分项目,采用传统架构就OK了。但是通过本文的分析,大家也知道了,传统架构确实也有一些缺点,比如在扩展性、可用性、性能瓶颈的解决方案上,都比CQRS架构要弱一点。大家有其他意见,欢迎拍砖,交流才能进步,呵呵。所以,如果你的应用场景是高并发写、高并发读、大数据,且希望在扩展性、可用性、性能、可伸缩性上表现更优秀,我觉得可以尝试CQRS架构。但是还有一个问题,CQRS架构的门槛很高,我认为如果没有成熟的框架支持,很难使用。而目前据我了解,业界还没有很多成熟的CQRS框架,java平台有axon framework, jdon framework;.NET平台,ENode框架正在朝这个方向努力。所以,我想这也是为什么目前几乎没有使用CQRS架构的成熟案例的原因之一。另一个原因是使用CQRS架构,需要开发者对DDD有一定的了解,否则也很难实践,而DDD本身要理解没个几年也很难运用到实际。还有一个原因,CQRS架构的核心是非常依赖于高性能的分布式消息中间件,所以要选型一个高性能的分布式消息中间件也是一个门槛(java平台有RocketMQ),.NET平台我个人专门开发了一个分布式消息队列EQueue,呵呵。另外,如果没有成熟的CQRS框架的支持,那编码复杂度也会很复杂,比如Event Sourcing,消息重试,消息幂等处理,事件的顺序处理,并发控制,这些问题都不是那么容易搞定的。而如果有框架支持,由框架来帮我们搞定这些纯技术问题,开发人员只需要关注如何建模,实现领域模型,如何更新读库,如何实现查询,那使用CQRS架构才有可能,因为这样才可能比传统的架构开发更简单,且能获得很多CQRS架构所带来的好处。

posted @ 2017-02-19 08:39 paulwong 阅读(266) | 评论 (0)编辑 收藏

快速理解聚合根、实体、值对象的区别和联系

posted @ 2017-02-19 08:32 paulwong 阅读(110) | 评论 (0)编辑 收藏

基于Spring Boot, Axon CQRS/ES,和Docker构建微服务

这是一个使用Spring Boot和Axon以及Docker构建的Event Sorucing源码项目,技术特点:
1.使用Java 和Spring Boot实现微服务;
2.使用命令和查询职责分离 (CQRS) 和 Event Sourcing (ES) 的框架Axon Framework v2, MongoDB 和 RabbitMQ;
3.使用Docker构建 交付和运行;
4.集中配置和使用Spring Cloud服务注册;
5.使用Swagger 和 SpringFox 提供API文档

项目源码:GitHub

工作原理:
这个应用使用CQRS架构模式构建,在CQRS命令如ADD是和查询VIEW(where id=1)分离的,在这个案例中领域部分代码已经分离成两个组件:一个是属于命令这边的微服务和属性查询这边的微服务。

微服务是单个职责的功能,自己的数据存储,每个能彼此独立扩展部署。

属于命令这边的微服务和属性查询这边的微服务都是使用Spring Boot框架开发的,在命令微服务和查询微服务之间通讯是事件驱动,事件是通过RabbitMQ消息在微服务组件之间传递,消息提供了一种进程节点或微服务之间可扩展的事件载体,包括与传统遗留系统或其他系统的松耦合通讯都可以通过消息进行。

请注意,服务之间不能彼此共享数据库,这是很重要,因为微服务应该是高度自治自主的,这样反过来有助于服务能够彼此独立地扩展伸缩规模。

CQRS中命令是“改变状态的动作”。命令的微服务包含所有领域逻辑和业务规则,命令被用于增加新的产品或改变它们的状态,这些命令针对某个具体产品的执行会导致事件Event产生,这会通过Axon框架持久化到MongoDB中,然后通过RabbitMQ传播给其他节点进程或微服务。

在event-sourcing中,事件是状态改变的原始记录,它们用于系统来重新建立实体的当前状态(通过重新播放过去的事件到当前就可以构建当前的状态),这听上去会很慢,但是实际上,事件都很简单,执行非常快,也能采取‘快照’策略进行优化。

请注意,在DDD中,实体是指一个聚合根实体。

上面是命令这边的微服务,下面看看查询这边的微服务:
查询微服务一般扮演一种事件监听器和视图角色,它监听到命令那边发出的事件,然后处理它们以符合查询这边的要求。

在这个案例中,查询这边只是简单建立和维持了一个 ‘materialised view’或‘projection’ ,其中保留了产品的最新状态,也就是产品id和描述以及是否被卖出等等信息,查询这边能够被复制多次以方便扩展,消息可以保留在RabbitMQ队列中实现持久保存,这种临时保存消息方式可以防止查询这边微服务当机。

命令微服务和查询微服务两者都有REST API,提供外界客户端访问。

下面看看如何通过Docker运行这个案例,需要 Ubuntu 16.04:
1.Docker ( v1.8.2)
2.Docker-compose ( v1.7.1)

在一个空目录,执行下面命令下载docker-compose:

$ wget https://raw.githubusercontent.com/benwilcock/microservice-sampler/master/docker-compose.yml
注意:不要更改文件名称。

启动微服务:只是简单一个命令:

$ docker-compose up

你会看到许多下载信息和日志输出在屏幕上,这是Docker image将被下载和运行。一共有六个docker,分别是: ‘mongodb’, ‘rabbitmq’, ‘config’, ‘discovery’, ‘product-cmd-side’, 和 ‘product-qry-side’.

使用下面命令进行测试增加一个新产品:

$ curl -X POST -v --header "Content-Type: application/json" --header "Accept: */*" "http://localhost:9000/products/add/1?name=Everything%20Is%20Awesome"

查询这个新产品:

$ curl http://localhost:9001/products/1

Microservices With Spring Boot, Axon CQRS/ES, and Docker

posted @ 2017-02-18 22:00 paulwong 阅读(346) | 评论 (0)编辑 收藏

DDD资源

微服务+DDD
https://github.com/benwilcock/microservice-sampler



https://github.com/AxonFramework/AxonBank

http://www.cnblogs.com/netfocus/p/4150084.html

posted @ 2017-02-18 21:53 paulwong 阅读(84) | 评论 (0)编辑 收藏

使用 Docker 搭建 Java Web 运行环境

     摘要: Docker 是 2014 年最为火爆的技术之一,几乎所有的程序员都听说过它。Docker 是一种“轻量级”容器技术,它几乎动摇了传统虚拟化技术的地位,现在国内外已经有越来越多的公司开始逐步使用 Docker 来替换现有的虚拟化平台了。作为一名 Java 程序员,我们是时候一起把 Docker 学起来了!本文会对虚拟化技术与 Docker 容器技术做一个对比,然后引出一些 ...  阅读全文

posted @ 2016-10-15 19:57 paulwong 阅读(744) | 评论 (0)编辑 收藏

使用Spring Cloud Security OAuth2搭建授权服务

Spring Cloud Security OAuth2 是 Spring 对 OAuth2 的开源实现,优点是能与Spring Cloud技术线无缝集成,如果全部使用默认配置,开发者只需要添加注解就能完成 OAuth2 授权服务的搭建。

1. 添加依赖

授权服务是基于Spring Security的,因此需要在项目中引入两个依赖:

<dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-starter-security</artifactId>
</dependency>

<dependency>
         <groupId>org.springframework.cloud</groupId>
         <artifactId>spring-cloud-starter-oauth2</artifactId>
 </dependency>


前者为 Security,后者为Security的OAuth2扩展。

2. 添加注解和配置

在启动类中添加@EnableAuthorizationServer注解:

@SpringBootApplication
@EnableAuthorizationServer
public class AlanOAuthApplication {
    public static void main(String[] args) {
        SpringApplication.run(AlanOAuthApplication.class, args);
    }
}


完成这些我们的授权服务最基本的骨架就已经搭建完成了。但是要想跑通整个流程,我们必须分配 client_idclient_secret才行。Spring Security OAuth2的配置方法是编写@Configuration类继承AuthorizationServerConfigurerAdapter,然后重写void configure(ClientDetailsServiceConfigurer clients)方法,如:

@Override
    public void configure(ClientDetailsServiceConfigurer clients) throws Exception {
        clients.inMemory() // 使用in-memory存储
                .withClient("client") // client_id
                .secret("secret") // client_secret
                .authorizedGrantTypes("authorization_code") // 该client允许的授权类型
                .scopes("app"); // 允许的授权范围
    }


3. 授权流程

访问授权页面:

localhost:8080/oauth/authorize?client_id=client&response_type=code&redirect_uri=http://www.baidu.com


此时浏览器会让你输入用户名密码,这是因为 Spring Security 在默认情况下会对所有URL添加Basic Auth认证。默认的用户名为user, 密码是随机生成的,在控制台日志中可以看到。

oauth2

画风虽然很简陋,但是基本功能都具备了。点击Authorize后,浏览器就会重定向到百度,并带上code参数:

这里写图片描述

拿到code以后,就可以调用

POST/GET http://client:secret@localhost:8080/oauth/token
  • 1

来换取access_token了:

curl -X POST -H "Cache-Control: no-cache" -H "Content-Type: application/x-www-form-urlencoded" -d 'grant_type=authorization_code&code=Li4NZo&redirect_uri=http://www.baidu.com' "http://client:secret@localhost:8080/oauth/token"

返回如下:

{
  "access_token": "32a1ca28-bc7a-4147-88a1-c95abcc30556",
  "token_type": "bearer",
  "expires_in": 2591999,
  "scope": "app"
}

到此我们最最基本的授权服务就搭建完成了。然而,这仅仅是个demo,如果要在生产环境中使用,还需要做更多的工作。

4. 使用MySQL存储access_token和client信息

把授权服务器中的数据存储到数据库中并不难,因为 Spring Cloud Security OAuth 已经为我们设计好了一套Schema和对应的DAO对象。但在使用之前,我们需要先对相关的类有一定的了解。

4.1 相关接口

Spring Cloud Security OAuth2通过DefaultTokenServices类来完成token生成、过期等 OAuth2 标准规定的业务逻辑,而DefaultTokenServices又是通过TokenStore接口完成对生成数据的持久化。在上面的demo中,TokenStore的默认实现为InMemoryTokenStore,即内存存储。 对于Client信息,ClientDetailsService接口负责从存储仓库中读取数据,在上面的demo中默认使用的也是InMemoryClientDetialsService实现类。说到这里就能看出,要想使用数据库存储,只需要提供这些接口的实现类即可。庆幸的是,框架已经为我们写好JDBC实现了,即JdbcTokenStoreJdbcClientDetailsService

4.2 建表

要想使用这些JDBC实现,首先要建表。框架为我们提前设计好了schema, 在github上:https://github.com/spring-projects/spring-security-oauth/blob/master/spring-security-oauth2/src/test/resources/schema.sql

在使用这套表结构之前要注意的是,对于MySQL来说,默认建表语句中主键是varchar(255)类型,在mysql中执行会报错,原因是mysql对varchar主键长度有限制。所以这里改成128即可。其次,语句中会有某些字段为LONGVARBINARY类型,它对应mysql的blob类型,也需要修改一下。

4.3 配置

数据库建好后,下一步就是配置框架使用JDBC实现。方法还是编写@Configuration类继承AuthorizationServerConfigurerAdapter

@Autowired
    private AuthenticationManager authenticationManager;

    @Autowired
    private DataSource dataSource;
    @Bean // 声明TokenStore实现
    public TokenStore tokenStore() {
        return new JdbcTokenStore(dataSource);
    }
    @Bean // 声明 ClientDetails实现
    public ClientDetailsService clientDetails() {
        return new JdbcClientDetailsService(dataSource);
    }
    @Override // 配置框架应用上述实现
    public void configure(AuthorizationServerEndpointsConfigurer endpoints) throws Exception {
        endpoints.authenticationManager(authenticationManager);
        endpoints.tokenStore(tokenStore());

        // 配置TokenServices参数
        DefaultTokenServices tokenServices = new DefaultTokenServices();
        tokenServices.setTokenStore(endpoints.getTokenStore());
        tokenServices.setSupportRefreshToken(false);
        tokenServices.setClientDetailsService(endpoints.getClientDetailsService());
        tokenServices.setTokenEnhancer(endpoints.getTokenEnhancer());
        tokenServices.setAccessTokenValiditySeconds( (int) TimeUnit.DAYS.toSeconds(30)); // 30天
        endpoints.tokenServices(tokenServices);
    }

完成这些后,框架就会将中间产生的数据写到mysql中了。oauth_client_details是client表,可以直接在该表中添加记录来添加client: 
这里写图片描述

4.4 需要注意的地方

这里不得不说 Spring 设计有一个奇葩地的方。注意看oauth_access_token表是存放访问令牌的,但是并没有直接在字段中存放token。Spring 使用OAuth2AccessToken来抽象与令牌有关的所有属性,在写入到数据库时,Spring将该对象通过JDK自带的序列化机制序列成字节直接保存到了该表的token字段中。也就是说,如果只看数据表你是看不出access_token的值是多少,过期时间等信息的。这就给资源服务器的实现带来了麻烦。我们的资源提供方并没有使用Spring Security,也不想引入 Spring Security 的任何依赖,这时候就只能将 DefaultOAuth2AccessToken的源码copy到资源提供方的项目中,然后读取token字段并反序列化还原对象来获取token信息。但是如果这样做还会遇到反序列化兼容性的问题,具体解决方法参考我另一篇博文:http://blog.csdn.net/neosmith/article/details/52539614

5. 总结

至此一个能在生产环境下使用的授权服务就搭建好了。其实我们在实际使用时应该适当定制JdbcTokenStoreClientDetailsService来实适应业务需要,甚至可以直接从0开始实现接口,完全不用框架提供的实现。另外,Spring 直接将DefaultOAuth2AccessToken序列化成字节保存到数据库中的设计,我认为是非常不合理的。或许设计者的初衷是保密access_token,但是通过加密的方法也可以实现,完全不应该直接扔字节。不过通过定制TokenStore接口,我们可以使用自己的表结构而不拘泥于默认实现。

http://blog.csdn.net/tracker_w/article/category/6360121

http://blog.csdn.net/neosmith/article/details/52539927

posted @ 2016-09-16 18:22 paulwong 阅读(3857) | 评论 (0)编辑 收藏

使用Spring Cloud Feign作为HTTP客户端调用远程HTTP服务

在Spring Cloud Netflix栈中,各个微服务都是以HTTP接口的形式暴露自身服务的,因此在调用远程服务时就必须使用HTTP客户端。我们可以使用JDK原生的URLConnection、Apache的Http Client、Netty的异步HTTP Client, Spring的RestTemplate。但是,用起来最方便、最优雅的还是要属Feign了。

Feign简介

Feign是一种声明式、模板化的HTTP客户端。在Spring Cloud中使用Feign, 我们可以做到使用HTTP请求远程服务时能与调用本地方法一样的编码体验,开发者完全感知不到这是远程方法,更感知不到这是个HTTP请求。比如:

@Autowired
private AdvertGropRemoteService service; // 远程服务

public AdvertGroupVO foo(Integer groupId) {
    return service.findByGroupId(groupId); // 通过HTTP调用远程服务
}

开发者通过service.findByGroupId()就能完成发送HTTP请求和解码HTTP返回结果并封装成对象的过程。

Feign的定义

为了让Feign知道在调用方法时应该向哪个地址发请求以及请求需要带哪些参数,我们需要定义一个接口:

@FeignClient(name = "ea")  //  [A]
public interface AdvertGroupRemoteService {

    @RequestMapping(value = "/group/{groupId}", method = RequestMethod.GET) // [B]
    AdvertGroupVO findByGroupId(@PathVariable("groupId") Integer adGroupId) // [C]

    @RequestMapping(value = "/group/{groupId}", method = RequestMethod.PUT)
    void update(@PathVariable("groupId") Integer groupId, @RequestParam("groupName") String groupName)

A: @FeignClient用于通知Feign组件对该接口进行代理(不需要编写接口实现),使用者可直接通过@Autowired注入。

B: @RequestMapping表示在调用该方法时需要向/group/{groupId}发送GET请求。

C: @PathVariableSpringMVC中对应注解含义相同。

Spring Cloud应用在启动时,Feign会扫描标有@FeignClient注解的接口,生成代理,并注册到Spring容器中。生成代理时Feign会为每个接口方法创建一个RequetTemplate对象,该对象封装了HTTP请求需要的全部信息,请求参数名、请求方法等信息都是在这个过程中确定的,Feign的模板化就体现在这里。

在本例中,我们将Feign与Eureka和Ribbon组合使用,@FeignClient(name = "ea")意为通知Feign在调用该接口方法时要向Eureka中查询名为ea的服务,从而得到服务URL。

Feign的Encoder、Decoder和ErrorDecoder

Feign将方法签名中方法参数对象序列化为请求参数放到HTTP请求中的过程,是由编码器(Encoder)完成的。同理,将HTTP响应数据反序列化为java对象是由解码器(Decoder)完成的。

默认情况下,Feign会将标有@RequestParam注解的参数转换成字符串添加到URL中,将没有注解的参数通过Jackson转换成json放到请求体中。注意,如果在@RequetMapping中的method将请求方式指定为POST,那么所有未标注解的参数将会被忽略,例如:

@FeignClient(name = "ea")  //  [A]
public interface AdvertGroupRemoteService {

    @RequestMapping(value = "/group/{groupId}", method = RequestMethod.GET) // [B]
    AdvertGroupVO findByGroupId(@PathVariable("groupId") Integer adGroupId) // [C]

    @RequestMapping(value = "/group/{groupId}", method = RequestMethod.PUT)
    void update(@PathVariable("groupId") Integer groupId, @RequestParam("groupName") String groupName)

此时因为声明的是GET请求没有请求体,所以obj参数就会被忽略。

在Spring Cloud环境下,Feign的Encoder*只会用来编码没有添加注解的参数*。如果你自定义了Encoder, 那么只有在编码obj参数时才会调用你的Encoder。对于Decoder, 默认会委托给SpringMVC中的MappingJackson2HttpMessageConverter类进行解码。只有当状态码不在200 ~ 300之间时ErrorDecoder才会被调用。ErrorDecoder的作用是可以根据HTTP响应信息返回一个异常,该异常可以在调用Feign接口的地方被捕获到。我们目前就通过ErrorDecoder来使Feign接口抛出业务异常以供调用者处理。

Feign的HTTP Client

Feign在默认情况下使用的是JDK原生的URLConnection发送HTTP请求,没有连接池,但是对每个地址会保持一个长连接,即利用HTTP的persistence connection 。我们可以用Apache的HTTP Client替换Feign原始的http client, 从而获取连接池、超时时间等与性能息息相关的控制能力。Spring Cloud从Brixtion.SR5版本开始支持这种替换,首先在项目中声明Apache HTTP Client和feign-httpclient依赖:

@RequestMapping(value = "/group/{groupId}", method = RequestMethod.GET)
void update(@PathVariable("groupId") Integer groupId, @RequestParam("groupName") String groupName, DataObject obj);

然后在application.properties中添加:

feign.httpclient.enabled=true

总结

通过Feign, 我们能把HTTP远程调用对开发者完全透明,得到与调用本地方法一致的编码体验。这一点与阿里Dubbo中暴露远程服务的方式类似,区别在于Dubbo是基于私有二进制协议,而Feign本质上还是个HTTP客户端。如果是在用Spring Cloud Netflix搭建微服务,那么Feign无疑是最佳选择。

http://blog.csdn.net/tracker_w/article/category/6360121
http://blog.csdn.net/neosmith/article/details/52449921

posted @ 2016-09-16 18:13 paulwong 阅读(1454) | 评论 (0)编辑 收藏

微服务框架Spring Cloud

2016

posted @ 2016-09-11 20:49 paulwong 阅读(518) | 评论 (0)编辑 收藏

JHipster

基于SPRING CLOUD的微服务框架
http://jhipster.cn/

posted @ 2016-09-11 16:40 paulwong 阅读(183) | 评论 (0)编辑 收藏

Spring Boot 性能优化

摘要
Spring 框架给企业软件开发者提供了常见问题的通用解决方案,包括那些在未来开发中没有意识到的问题。但是,它构建的 J2EE 项目变得越来越臃肿,逐渐被 Spring Boot 所替代。Spring Boot 让我们创建和运行项目变得更为迅速,现在已经有越来越多的人使用它。我们已经在几个项目中使用了 Spring Boot ,今天我们就来一起讨论一下如何改进 Spring Boot 应用的性能。

Spring 框架给企业软件开发者提供了常见问题的通用解决方案,包括那些在未来开发中没有意识到的问题。但是,它构建的 J2EE 项目变得越来越臃肿,逐渐被 Spring Boot 所替代。Spring Boot 让我们创建和运行项目变得更为迅速,现在已经有越来越多的人使用它。我们已经在几个项目中使用了 Spring Boot ,今天我们就来一起讨论一下如何改进 Spring Boot 应用的性能。

首先,从之前我在开发中遇到的一个问题说起。在一次查看项目运行日志的时候,我偶然发现了一个问题,日志里显示这个项目总是加载 Velocity 模板引擎,但实际上这个项目是一个没有 web 页面的 REST Service 项目。于是我花了一点时间去寻找产生这个问题的原因,以及如何改进 Spring Boot 应用的性能。在查找了相关的资料后,我得出的结论如下:

组件自动扫描带来的问题

默认情况下,我们会使用 @SpringBootApplication 注解来自动获取的应用的配置信息,但这样也会给应用带来一些副作用。使用这个注解后,会触发自动配置( auto-configuration )和 组件扫描 ( component scanning),这跟使用 @Configuration、@EnableAutoConfiguration 和 @ComponentScan 三个注解的作用是一样的。这样做给开发带来方便的同时,也会有两方面的影响:

1、会导致项目启动时间变长。当启动一个大的应用程序,或将做大量的集成测试启动应用程序时,影响会特别明显。

2、会加载一些不需要的多余的实例(beans)。

3、会增加 CPU 消耗。

针对以上两个情况,我们可以移除 @SpringBootApplication 和 @ComponentScan 两个注解来禁用组件自动扫描,然后在我们需要的 bean 上进行显式配置:

// 移除 @SpringBootApplication and @ComponentScan, 用 @EnableAutoConfiguration 来替代
@Configuration
@EnableAutoConfiguration
public class SampleWebUiApplication {

    
// 

    
// 用 @Bean 注解明确显式配置,以便被 Spring 扫描到
    @Bean
    
public MessageController messageController(MessageRepository messageRepository) {
        
return new MessageController(messageRepository);
    }

如何避免组件自动扫描带来的问题

我们在上面提到,@SpringBootApplication 注解的作用跟 @EnableAutoConfiguration 注解的作用是相当的,那就意味着它也能带来上述的三个问题。要避免这些问题,我们就要知道我们需要的组件列表是哪些,可以用 -Ddebug 的方式来帮助我们明确地定位:

mvn spring-boot:run -Ddebug … ========================= AUTO-CONFIGURATION REPORT =========================   Positive matches: -----------------     DispatcherServletAutoConfiguration       - @ConditionalOnClass classes found: org.springframework.web.servlet.DispatcherServlet (OnClassCondition)       - found web application StandardServletEnvironment (OnWebApplicationCondition)  ... 

接着拷贝 Positive matches 中列出的信息:

DispatcherServletAutoConfiguration 
EmbeddedServletContainerAutoConfiguration
ErrorMvcAutoConfiguration
HttpEncodingAutoConfiguration
HttpMessageConvertersAutoConfiguration
JacksonAutoConfiguration
JmxAutoConfiguration
MultipartAutoConfiguration
ServerPropertiesAutoConfiguration
PropertyPlaceholderAutoConfiguration
ThymeleafAutoConfiguration
WebMvcAutoConfiguration
WebSocketAutoConfiguration

然后来更新项目配置,显式地引入这些组件,引入之后,再运行一下应用确保没有错误发生:

@Configuration
@Import({
        DispatcherServletAutoConfiguration.
class,
        EmbeddedServletContainerAutoConfiguration.
class,
        ErrorMvcAutoConfiguration.
class,
        HttpEncodingAutoConfiguration.
class,
        HttpMessageConvertersAutoConfiguration.
class,
        JacksonAutoConfiguration.
class,
        JmxAutoConfiguration.
class,
        MultipartAutoConfiguration.
class,
        ServerPropertiesAutoConfiguration.
class,
        PropertyPlaceholderAutoConfiguration.
class,
        ThymeleafAutoConfiguration.
class,
        WebMvcAutoConfiguration.
class,
        WebSocketAutoConfiguration.
class,
})
public class SampleWebUiApplication {}


在上面的代码中,我们可以删掉我们不需要的组件信息,来提高应用的性能,比如在我的项目中,不需要 JMX 和 WebSocket 功能,我就删掉了它们。删掉之后,再次运行项目,确保一切正常。

将Servlet容器变成Undertow

默认情况下,Spring Boot 使用 Tomcat 来作为内嵌的 Servlet 容器。我们可以启动项目,然后用 VisualVM 或者 JConsole 来查看应用所占的内存情况:

Spring Boot 性能优化

以上是我使用 Spring Boot 的默认方式启动应用后,用 VisualVM 监控到的内存的占用情况:堆内存占用 110M,16 个线程被开启。

可以将 Web 服务器切换到 Undertow 来提高应用性能。Undertow 是一个采用 Java 开发的灵活的高性能 Web 服务器,提供包括阻塞和基于 NIO 的非堵塞机制。Undertow 是红帽公司的开源产品,是 Wildfly 默认的 Web 服务器。首先,从依赖信息里移除 Tomcat 配置:

<exclusions>
        
<exclusion>
                
<groupId>org.springframework.boot</groupId>
                
<artifactId>spring-boot-starter-tomcat</artifactId>
        
</exclusion>
</exclusions>


然后添加 Undertow:

<dependency>
        
<groupId>org.springframework.boot</groupId>
        
<artifactId>spring-boot-starter-undertow</artifactId>
</dependency>


启动项目后,用 VisualVM 监控到的信息显示:堆内存占用 90M,13个线程被开启。

Spring Boot 性能优化

总结

这些都是我们在项目开发中使用到的一些优化 Spring Boot 应用的小技巧,对于大的应用性能的提高还是很明显的。大家可以尝试一下,然后告诉我们你的测试结果。

最后,附上代码,大家可以去这里下载:spring-boot-performance

文中大部分内容参考英国一个架构师的博客 和 DZone 近期发布的文章,在此感谢两位大牛。参考文章及链接:

(1)Spring Boot 性能优化:Spring Boot Performance

(2)Spring Boot 内存优化:Spring Boot Memory Performance

(3)https://www.techempower.com/benchmarks/

(4)Spring 应用程序优化:Optimizing Spring Framework for App Engine Applications

posted @ 2016-09-11 16:37 paulwong 阅读(306) | 评论 (0)编辑 收藏

spring cloud项目读取配置管理

摘要
spring cloud config server配置好了数据库连接信息,这个项目读取config,获取连接信息。这里以mybtis作为列子。从服务器读取jdbc信息后,运行mybatis程序。

确认服务是否成功
http://localhost:8888/demo-config/test
{"name":"demo-config","profiles":["test"],"label":"master","version":"02d28ad4925aa9bd1bf8a48d2edbf04ce61aa45a","propertySources":[{"name":"https://git.oschina.net/penghaozhong/demo.git/demo-config-repo/demo-config-test.properties","source":{"jdbc.url":"jdbc:mysql://localhost:3306/demo?characterEncoding=UTF-8","jdbc.username":"root","jdbc.driver":"com.mysql.jdbc.Driver","jdbc.password":"xxxxxx","jdbc.type":"mysql"}}]}

    2. 配置读取配置文件

  



在bootstrap.properties中添加读取配置管理的地址。

3. 读取配置文件属性,这里采用@ConfigurationProperties
/**
 * 读取数据库配置文件
 * 
@author penghaozhong
 *
 
*/
@ConfigurationProperties(prefix = DataSourceProperties.PREFIX, ignoreUnknownFields = false)
public  class  DataSourceProperties {
    
        public DataSourceProperties() {
        super();
    }
        //对应配置文件里的配置键
        public final static String PREFIX="jdbc";    
        
        private String type; 
        private String driver; 
        private String url; 
        private String username; 
        private String password;
        
        public String getType() {
            return type;
        }
        public void setType(String type) {
            this.type = type;
        }
        public String getDriver() {
            return driver;
        }
        public void setDriver(String driver) {
            this.driver = driver;
        }
        public String getUrl() {
            return url;
        }
        public void setUrl(String url) {
            this.url = url;
        }
        public String getUsername() {
            return username;
        }
        public void setUsername(String username) {
            this.username = username;
        }
        public String getPassword() {
            return password;
        }
        public void setPassword(String password) {
            this.password = password;
        }

}


4. 配置mybatis
@Configuration
@MapperScan("com.phz.test.spring.cloud.demo")
@EnableConfigurationProperties(DataSourceProperties.class)
@EnableTransactionManagement
public class MybatisDataSource {

    // mybaits mapper xml搜索路径
    private final static String MAPPERLOCATIONS = "classpath:/mappings/**/*.xml";
    private final static String CONFIGLOCATION = "classpath:/mybatis-config.xml";

    @Autowired
    private  DataSourceProperties dataSourceProperties;
    private DruidDataSource datasource = null;

    @Bean(destroyMethod = "close")
    public  DataSource dataSource(){
        datasource = new DruidDataSource();  
        datasource.setUrl(dataSourceProperties.getUrl());
        datasource.setDbType(dataSourceProperties.getType());
        datasource.setDriverClassName(dataSourceProperties.getDriver());
        datasource.setUsername(dataSourceProperties.getUsername());
        datasource.setPassword(dataSourceProperties.getPassword());
        return datasource;
    }

    @PreDestroy
    public void close() {
        if(datasource != null){
            datasource.close();
        }
    }

    @Bean
    public SqlSessionFactory sqlSessionFactoryBean() throws Exception {
        SqlSessionFactoryBean sqlSessionFactoryBean = new SqlSessionFactoryBean();
        sqlSessionFactoryBean.setDataSource(dataSource());
        PathMatchingResourcePatternResolver resolver = new PathMatchingResourcePatternResolver();
        sqlSessionFactoryBean.setMapperLocations(resolver.getResources(MAPPERLOCATIONS));
        sqlSessionFactoryBean.setConfigLocation(resolver.getResource(CONFIGLOCATION));
        sqlSessionFactoryBean.setTypeAliasesPackage("com.phz.test.spring.cloud.demo.entity");
        return sqlSessionFactoryBean.getObject();
    }

    @Bean
    public PlatformTransactionManager transactionManager() {
        return new DataSourceTransactionManager(dataSource());
    }

}











posted @ 2016-09-11 16:26 paulwong 阅读(731) | 评论 (0)编辑 收藏

spring-loaded热部署

什么是spring-loaded?

spring-loaded是一个对于jvm代理运行时期改变类文件的重载(重新加载),它转换类loadtime让他们服从后重新加载。不像“热代码替换”只允许一次简单的改变JVM运行(例如更改方法体)spring-loaded允许您添加/修改/删除/字段/方法构造函数。注释类型/方法/字段/构造函数也可以修改和可以添加/删除/修改值的枚举类型。

有什么好处?

开发测试阶段:能够在启动后动态更改代码调试,无需重启减少切换debug时间(ps:对于eclipse而言,在debug时期只能做到动态更新方法体不能增加)
对于线上测试发布阶段: 能够在出现问题后直接替换class文件而不重启应用(ps:对于外部提供的服务jar形式同样能做到)
怎么使用?

项目地址

https://github.com/spring-projects/spring-loaded

第一步:下载文件
http://repo.spring.io/release/org/springframework/springloaded/1.2.5.RELEASE/springloaded-1.2.5.RELEASE.jar

第二步:配置jvm启动参数

eclipse
eclipse:run as --> run configurations --> arguments -->> VM arguments
-javaagent:E:\repository\org\springframework\spring-load\springloaded-1.2.5.RELEASE.jar 
-noverify -Dspringloaded=verbose
详细描述:
-javaagent: 配置java代理使用下载后的jar包路径
-noverify: 禁用字节码验证
-Dspringloaded=verbose 显示springloaded时的详细信息


image

java命令启动

java -javaagent:E:\repository\org\springframework\spring-load\springloaded-1.2.5.RELEASE.jar -noverify Test  类似 

java jar包动态替换

1.打成runnable Jar
2.命令启动:

java -javaagent:E:\repository\org\springframework\spring-load\springloaded-1.2.5.RELEASE.jar -noverify -Dspringloaded=watchJars=main.jar main.jar

/**  * 类Test.java的实现描述:TODO 类实现描述   * @author Administrator 2016年7月4日 下午4:55:59  */ public class Test {     public static void main(String[] args) throws InterruptedException {          while(true) {             try {                 println();                 Thread.sleep(1000);             } catch (Throwable e) {                  e.printStackTrace();              }          }       }     public static void println() {          System.out.println("112222221222222");          }  } 

改变为

/**  * 类Test.java的实现描述:TODO 类实现描述   * @author Administrator 2016年7月4日 下午4:55:59  */ public class Test {     public static void main(String[] args) throws InterruptedException {          while(true) {             try {                 println();                 Thread.sleep(1000);             } catch (Throwable e) {                  e.printStackTrace();              }          }       }     public static void println() {          System.out.println("test replace jar");          }  } 
3.重新打包替换
PS:实测在window下无用 手上无linux机器待测试




1

posted @ 2016-09-11 10:40 paulwong 阅读(645) | 评论 (0)编辑 收藏

MICROSERVICE 资源

Spring Cloud 为开发者提供了在分布式系统(如配置管理、服务发现、断路器、智能路由、微代理、控制总线、一次性 Token、全局锁、决策竞选、分布式会话和集群状态)操作的开发工具。使用 Spring Cloud 开发者可以快速实现上述这些模式。

主要有eureka做服务发现、config做分布式配置、zuul做api-gateway、feign做客户端负载均衡、hystrix做断路器、turbine做聚合的monitor、graphite做指标监控。

http://blog.csdn.net/liaokailin/article/category/6212338


MICROSERVICE WITH SPRING-CLOUD.
https://github.com/kennyk65/Microservices-With-Spring-Student-Files




!!!spring-cloud-study
http://git.oschina.net/itmuch/spring-cloud-study

posted @ 2016-09-01 21:46 paulwong 阅读(132) | 评论 (0)编辑 收藏

Disruptor

一个ring buffer实现多线程通信。由于他们之间通信不需要锁所以性能有很大的提高。

Disruptor更多的应用在高速事务中,利用JVM的伪内存,这也可能是它为LMAX而生的,和akka的应用场景不一样。

一般编写并发应用程序马上想到多线程或者多进程。但多线程需要处理资源竞争,共享访问等问题,搞不好容易出现死锁,当程序规模比较大时,排查难度很大。 Actor模型提供了另一种编写并发应用程序的思路。 有点类似Node.JS的基于事件异步处理. (其实我觉得基于消息异步和基于事件异步是一回事)

什么是基于消息异步呢?很简单,比如要开展一个项目,需要多人协作。作为项目经理的你,只需要像手下发出命令,个人各干各的,互不干扰。做完了就回送一个消息给项目经理,项目经理再分派新的任务. (可能比喻得不恰当,但Actor的基本思路就是这样,你不需要考虑资源共享和线程并发什么的, Actor库屏蔽了这些底层的实现细节 . 每个Actor就相当于一个人或者叫一个处理者,他们的职责很单一,就是响应对方发来的消息,做出响应,并回送一个响应消息。 每个Actor负责做自己的份内事,最后有一个调度角色的Actor将所有Actor管理起来,形成一个整体)

Akka 是针对Scala和Java的Actor库,JActor是一个用纯Java编写的Actor库。 

https://github.com/LMAX-Exchange/disruptor
http://www.oschina.net/p/disruptor

posted @ 2016-06-05 18:19 paulwong 阅读(234) | 评论 (0)编辑 收藏

JPA概要

1 JPA概述

JPA(Java Persistence API,Java持久化API),定义了对象-关系映射(ORM)以及实体对象持久化的标准接口。

JPA是JSR-220(EJB3.0)规范的一部分,在JSR-220中规定实体对象(EntityBean)由JPA进行支持。

所以JPA不局限于EJB3.0,而是作为POJO持久化的标准规范,可以脱离容器独立运行,开发和测试更加方便。

JPA在应用中的位置如下图所示:

 

JPA维护一个Persistence Context(持久化上下文),在持久化上下文中维护实体的生命周期。主要包含三个方面的内容:

  1. ORM元数据。JPA支持annotion或xml两种形式描述对象-关系映射。
  2. 实体操作API。实现对实体对象的CRUD操作。
  3. 查询语言。约定了面向对象的查询语言JPQL(Java Persistence Query Language)。

JPA的主要API都定义在javax.persistence包中。如果你熟悉Hibernate,可以很容易做出对应:

 
org.hibernatejavax.persistence说明
cfg.ConfigurationPersistence读取配置信息
SessionFactoryEntityManagerFactory用于创建会话/实体管理器的工厂类
SessionEntityManager提供实体操作API,管理事务,创建查询
TransactionEntityTransaction管理事务
QueryQuery执行查询

2 实体生命周期

实体生命周期是JPA中非常重要的概念,描述了实体对象从创建到受控、从删除到游离的状态变换。对实体的操作主要就是改变实体的状态。

JPA中实体的生命周期如下图:

  1. New,新创建的实体对象,没有主键(identity)值
  2. Managed,对象处于Persistence Context(持久化上下文)中,被EntityManager管理
  3. Detached,对象已经游离到Persistence Context之外,进入Application Domain
  4. Removed, 实体对象被删除

EntityManager提供一系列的方法管理实体对象的生命周期,包括:

  1. persist, 将新创建的或已删除的实体转变为Managed状态,数据存入数据库。
  2. remove,删除受控实体
  3. merge,将游离实体转变为Managed状态,数据存入数据库。

如果使用了事务管理,则事务的commit/rollback也会改变实体的状态。

3 实体关系映射(ORM)

3.1 基本映射

 
对象端数据库端annotion可选annotion
ClassTable@Entity@Table(name="tablename")
propertycolumn@Column(name = "columnname")
propertyprimary key@Id@GeneratedValue 详见ID生成策略
propertyNONE@Transient 

3.2 ID生成策略

ID对应数据库表的主键,是保证唯一性的重要属性。JPA提供了以下几种ID生成策略

  1. GeneratorType.AUTO ,由JPA自动生成
  2. GenerationType.IDENTITY,使用数据库的自增长字段,需要数据库的支持(如SQL Server、MySQL、DB2、Derby等)
  3. GenerationType.SEQUENCE,使用数据库的序列号,需要数据库的支持(如Oracle)
  4. GenerationType.TABLE,使用指定的数据库表记录ID的增长 需要定义一个TableGenerator,在@GeneratedValue中引用。例如:

    @TableGenerator( name="myGenerator", table="GENERATORTABLE", pkColumnName = "ENTITYNAME", pkColumnValue="MyEntity", valueColumnName = "PKVALUE", allocationSize=1 )

    @GeneratedValue(strategy = GenerationType.TABLE,generator="myGenerator")

3.3 关联关系

JPA定义了one-to-one、one-to-many、many-to-one、many-to-many 4种关系。

对于数据库来说,通常在一个表中记录对另一个表的外键关联;对应到实体对象,持有关联数据的一方称为owning-side,另一方称为inverse-side。

为了编程的方便,我们经常会希望在inverse-side也能引用到owning-side的对象,此时就构建了双向关联关系。 在双向关联中,需要在inverse-side定义mappedBy属性,以指明在owning-side是哪一个属性持有的关联数据。

对关联关系映射的要点如下:

 
关系类型Owning-SideInverse-Side
one-to-one@OneToOne@OneToOne(mappedBy="othersideName")
one-to-many / many-to-one@ManyToOne@OneToMany(mappedBy="xxx")
many-to-many@ManyToMany@ManyToMany(mappedBy ="xxx")

其中 many-to-many关系的owning-side可以使用@JoinTable声明自定义关联表,比如Book和Author之间的关联表:

@JoinTable(name = "BOOKAUTHOR", joinColumns = { @JoinColumn(name = "BOOKID", referencedColumnName = "id") }, inverseJoinColumns = { @JoinColumn(name = "AUTHORID", referencedColumnName = "id") })

关联关系还可以定制延迟加载和级联操作的行为(owning-side和inverse-side可以分别设置):

通过设置fetch=FetchType.LAZY 或 fetch=FetchType.EAGER来决定关联对象是延迟加载或立即加载。

通过设置cascade={options}可以设置级联操作的行为,其中options可以是以下组合:

  • CascadeType.MERGE 级联更新
  • CascadeType.PERSIST 级联保存
  • CascadeType.REFRESH 级联刷新
  • CascadeType.REMOVE 级联删除
  • CascadeType.ALL 级联上述4种操作

3.4 继承关系

JPA通过在父类增加@Inheritance(strategy=InheritanceType.xxx)来声明继承关系。A支持3种继承策略:

  1. 单表继承(InheritanceType.SINGLETABLE),所有继承树上的类共用一张表,在父类指定(@DiscriminatorColumn)声明并在每个类指定@DiscriminatorValue来区分类型。
  2. 类表继承(InheritanceType.JOINED),父子类共同的部分公用一张表,其余部分保存到各自的表,通过join进行关联。
  3. 具体表继承(InheritanceType.TABLEPERCLASS),每个具体类映射到自己的表。

其中1和2能够支持多态,但是1需要允许字段为NULL,2需要多个JOIN关系;3最适合关系数据库,对多态支持不好。具体应用时根据需要取舍。

4 事件及监听

通过在实体的方法上标注@PrePersist,@PostPersist等声明即可在事件发生时触发这些方法。

5 Query Language 查询语言

JPA提供两种查询方式,一种是根据主键查询,使用EntityManager的find方法:

T find(Class entityClass, Object primaryKey)

另一种就是使用JPQL查询语言。JPQL是完全面向对象的,具备继承、多态和关联等特性,和hibernate HQL很相似。

使用EntityManager的createQuery方法:

Query createQuery(String qlString)

5.1 使用参数

可以在JPQL语句中使用参数。JPQL支持命名参数和位置参数两种参数,但是在一条JPQL语句中所有的参数只能使用同一种类型。

举例如下:

  • 命令参数

Query query = em.createQuery("select p from Person p where p.personid=:Id"); query.setParameter("Id",new Integer(1));

  • 位置参数

Query query = em.createQuery("select p from Person p where p.personid=?1"); query.setParameter(1,new Integer(1));

5.2 命名查询

如果某个JPQL语句需要在多个地方使用,还可以使用@NamedQuery 或者 @NamedQueries在实体对象上预定义命名查询。

在需要调用的地方只要引用该查询的名字即可。

例如:

@NamedQuery(name="getPerson", query= "FROM Person WHERE personid=?1")

@NamedQueries({ @NamedQuery(name="getPerson1", query= "FROM Person WHERE personid=?1"), @NamedQuery(name="getPersonList", query= "FROM Person WHERE age>?1") })

Query query = em.createNamedQuery("getPerson");

5.3 排序

JPQL也支持排序,类似于SQL中的语法。例如: Query query = em.createQuery("select p from Person p order by p.age, p.birthday desc");

5.4 聚合查询

JPQL支持AVG、SUM、COUNT、MAX、MIN五个聚合函数。例如:

Query query = em.createQuery("select max(p.age) from Person p"); Object result = query.getSingleResult(); String maxAge = result.toString();

5.5 更新和删除

JPQL不仅用于查询,还可以用于批量更新和删除。

如:

Query query = em.createQuery("update Order as o set o.amount=o.amount+10"); //update 的记录数 int result = query.executeUpdate();

Query query = em.createQuery("delete from OrderItem item where item.order in(from Order as o where o.amount<100)"); query.executeUpdate();

query = em.createQuery("delete from Order as o where o.amount<100"); query.executeUpdate();//delete的记录数

5.6 更多

与SQL类似,JPQL还涉及到更多的语法,可以参考:http://docs.oracle.com/cd/E11035_01/kodo41/full/html/ejb3_langref.html

6 事务管理

JPA支持本地事务管理(RESOURCELOCAL)和容器事务管理(JTA),容器事务管理只能用在EJB/Web容器环境中。

事务管理的类型可以在persistence.xml文件中的“transaction-type”元素配置。

JPA中通过EntityManager的getTransaction()方法获取事务的实例(EntityTransaction),之后可以调用事务的begin()、commit()、rollback()方法。

Date: 2012-12-30 16:46:29 CST

Author: Holbrook

Org version 7.8.11 with Emacs version 24

posted @ 2016-06-04 16:08 paulwong 阅读(177) | 评论 (0)编辑 收藏

IM资源

kafka-examples视频上的例子
https://github.com/gwenshap/kafka-examples

zer0MQTTServer
https://github.com/zer0Black/zer0MQTTServer
http://www.w2bc.com/Article/85741

moquette
https://github.com/andsel/moquette

融云 Blog
http://www.rongcloud.cn/pricing

EMQTT
http://emqtt.com/docs

群聊天系统,高吞吐量,高转发量,后端什么架构?
http://www.v2ex.com/t/92125

用Java实现一个IM的server端需要熟悉哪些技术点或框架?
http://www.zhihu.com/question/37090498

使用Java API创建(create),查看(describe),列举(list),删除(delete)Kafka主题(Topic)--转载
http://www.cnblogs.com/davidwang456/p/4313784.html

kafka中文教程
http://orchome.com/3

Kafka入门经典教程
http://www.open-open.com/lib/view/open1455842076964.html

Kafka深度解析
http://www.open-open.com/lib/view/open1457055194765.html

大型网站架构系列:分布式消息队列(一)
http://www.open-open.com/lib/view/open1453645976605.html



posted @ 2016-05-23 22:03 paulwong 阅读(161) | 评论 (0)编辑 收藏

Eclipse使用git最简易流程

git有诸多好处,网上都说的很清楚了,在这里我不再赘述。对于我来说,私下里想做一些项目,而又不能很好的保存自己的代码和进行版本控制,这时候,就用到了git。下面,就以我个人为例讲讲git从0开始如何安装使用。

Step1 准备工作

msysgit,下载地址为http://msysgit.github.io/

Eclipse IDE for Java EE Developers(必须是这个,自带Egit,或者自行安装Egit插件),在Eclipse官网下载,地址http://www.eclipse.org/downloads/

github账号,github官网注册一个,地址https://github.com/

廖雪峰的git教程,地址为http://www.liaoxuefeng.com/wiki/0013739516305929606dd18361248578c67b8067c8c017b000,讲得很好,我大概花了3个晚上的时间看,如果仅仅是为了安装上,可以先暂时略过,后面再看。

Step2 msysgit安装

一路next就行,注意可能会遇到360的拦截(该死,点击允许本程序所有操作或者安装前就退出360即可)。

Step3 git用户名和邮箱配置

单击开始菜单,打开Git Bush,

教程1

 

输入以下命令

git config --global user.name "Your Name"

git config --global user.email email@example.com

用户名和邮箱替换为自己的,为本台机器所有仓库指定用户名和email地址。

 

Step4 创建SSH Key

因为本地git仓库和远程的github仓库之间是通过ssh加密的,所以,还需要创建一个SSH Key。

输入以下命令

ssh-keygen -t rsa -C youremail@example.com

同样将邮箱替换为自己的。在路径C盘->用户->用户名,找到.ssh文件夹,打开就可以看到两个文件id_rsa和id_rsa.pub,

打开id_rsa.pub,将其中的内容复制下来(这就相当于一把钥匙,持有钥匙的人可以访问你的内容,下一个小结讲解这把钥匙的用途),下面是我的

教程2

 

Step5 与github上的仓库相关联

注册一个github账号

注册完成之后,点击右上角的settings(就是那个齿轮,设置的图标)

教程3

 

进入设置页面

image

选SSH Keys,点击add SSH key,就可以添加了,title随便填写,将从id_rsa.pub中复制的内容粘贴到这里。从此,gitgub仓库就能够识别你本地的仓库了。也就是说,你离将本地代码推送到github上,或者将github上的代码克隆到本地,就只差一步了。(可参考廖雪峰前辈的教程先进行在非Eclipse下的操作,更有感觉)

 

Step6 Egit的使用

首先,登入你的github账号,点击加号,选择New repositrory,创建一个新的仓库,如图所示。

教程6

名字叫做test2,其他都默认就好。

点击绿色按钮创建,就创建好了一个github仓库。

教程7

将地址复制下来,保存好备用。

 

打开Eclipse,像平常一样,新建一个web工程,或者其他你常用的工程。我这里工程叫做scott

{4$7`FVS]283EW(~80FR(JT

右击项目,选择Team->Share Project,弹出如下窗口。

image

选择git,next,在弹出的界面上,①先勾选Use or create……,②createrepository,③勾选工程,④finish。

教程8

这时候,你就创建好了一个git工程,右击工程,选择Team,你可以像svn一样进行commit,synchronize等操作,但是,remote操作中,push是灰色的,表示还不能将代码推送到github仓库上去。

教程10

这时,打开Git Repository视图(具体怎么打开百度去,这都是基本常识了)

教程11

右键选择Create Remote,点OK

image

点击Change,弹出如下界面

image

URI输入之前在github上拷贝的地址,下面的内容会自动填上。你只需要再填上github上的用户名和密码即可。finish,save。

接下来的几步就简单了,在项目里面随便写点代码,然后先将新增的代码提交到本地,例如,将cat类,先add to index,然后commit。这时候,右键工程,Team->remote中就有了push选项,意味着你可以将本地代码保存在github中了。祝贺你!

教程12

点击Push,点击add All Branches Spec,将本地版本库添加,然后Finish,后面一路Next,再次查看github,可以看到代码已经成功推送。

最后,看看我们在github上的代码吧!

作者: 张万帆 
欢迎任何形式的转载,但请务必注明出处。

posted @ 2016-05-15 18:17 paulwong 阅读(214) | 评论 (0)编辑 收藏

Eclipse上安装GIT插件EGit及使用

一、Eclipse上安装GIT插件EGit

 

      Eclipse的版本eclipse-java-helios-SR2-win32.zip(在Eclipse3.3版本找不到对应的 EGit插件,无法安装)

 

     

 

 

 

EGit插件地址:http://download.eclipse.org/egit/updates

 

OK,随后连续下一步默认安装就可以,安装后进行重启Eclipse

 

二、在Eclipse中配置EGit

 

准备工作:需要在https://github.com 上注册账号

 

Preferences > Team > Git > Configuration

 

 

这里的user.name 是你在https://github.com上注册用户名

 

 

user.email是你在github上绑定的邮箱。在这里配置user.name即可

 

 

三、新建项目,并将代码提交到本地的GIT仓库中

 

1、新建项目 git_demo,并新建HelloWorld.java类

 

 

2、将git_demo项目提交到本地仓库,如下图

 

 

 

 

 

 

到此步,就成功创建GIT仓库。但文件夹处于untracked状态(文件夹中的符号”?”表示),下面我们需要提交代码到本地仓库,如下图

 

 

 

 

 

 

 

OK,这样代码提交到了本地仓库

 

 

四:将本地代码提交到远程的GIT仓库中

 

准备工作:在https://github.com上创建仓库

 

 

 

 

 

 

点击“Create repository” ,ok,这样在github上的仓库就创建好了。

 

注意创建好远程仓库后,点击进去,此时可以看到一个HTTP地址,如红线框,这个是你http协议的远程仓库地址

 

 

准备工作做好了,那开始将代码提交到远程仓库吧

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

OK,这样提交远程GIT就完成了,可以在https://github.com核对一下代码是否已经提交

 

 

注意的问题

   如果是首次提交会第一步:先在本地建立一个一样的仓库,称本地仓库。

          第二步:在本地进行commit操作将把更新提交到本地仓库;

          第三步: 将服务器端的更新pull到本地仓库进行合并,最后将合并好的本地仓库push到服务器端,这样就进行了一次远程提交。

 

  如果非首次提交同样的道理

          第一步:将修改的代码commit操作更新到本地仓库;

         第二步:第三步: 将服务器端的更新pull到本地仓库进行合并,最后将合并好的本地仓库push到服务器端

 

 

posted @ 2016-05-15 17:46 paulwong 阅读(148) | 评论 (0)编辑 收藏

排版六原则


作者: 阮一峰

日期: 2010年10月16日

上个月,我贴了《图形化简历》

几天后,就收到了秋叶老师的来信,希望与我探讨一些设计问题。他写过一本畅销书《说服力-让你的PPT会说话》,眼下正在写续集。

我看了新书的样章,觉得很不错,有些内容很值得分享。

====================================

首先,我们先看一个例子。良好的设计如何使得一个平庸的文档脱胎换骨。下面是一张大学生的求职简历,再普通不过了,想要引起招聘经理的注意,恐怕很难。

秋叶老师对它进行了简单的排版,还是一张表格,还是黑白配色,没有使用任何图形元素,效果却完全不一样了。

真是令人眼前一亮,不由自主地想多看几眼。这就是优秀设计的作用:它让你脱颖而出。

====================================

秋叶老师把他的排版心得,总结为六个原则:对齐,聚拢,重复,对比,强调,留白。我是这样理解的:

一、对齐原则

  相关内容必须对齐,次级标题必须缩进,方便读者视线快速移动,一眼看到最重要的信息。

二、聚拢原则

  将内容分成几个区域,相关内容都聚在一个区域中。段间距应该大于段内的行距。

三、留白原则

  千万不要把页面排得密密麻麻,要留出一定的空白,这本身就是对页面的分隔。这样既减少了页面的压迫感,又可以引导读者视线,突出重点内容。

四、降噪原则

  颜色过多、字数过多、图形过繁,都是分散读者注意力的"噪音"。

五、重复原则

  多页面排版时,注意各个页面设计上的一致性和连贯性。另外,在内容上,重要信息值得重复出现。

六、对比原则

  加大不同元素的视觉差异。这样既增加了页面的活泼,又方便读者集中注意力阅读某一个子区域。

====================================

下面用一个PPT的例子,演示排版六原则。

上面这张ppt有两个毛病。一是字数太多,抓不住重点;二是右边没有对齐,使得读者的视线只能一行行地从行首到行尾移动,不能直上直下。

现在进行修改。

第一步,根据"聚拢原则",将六点分成六个区域。

第二步,根据"降噪原则",将每一点分成"小标题"和"说明文字"两部分。

第三步,根据"对齐原则",将每一个部分、每一种元素对齐。

第四步,根据"对比原则",加大"小标题"和"说明文字"在字体和颜色上的差异。

第五步,根据"留白原则",留出一定的空白。

页面的可读性大大增加。

(完)

posted @ 2016-05-06 17:55 paulwong 阅读(97) | 评论 (0)编辑 收藏

MyThrift 0.0.1 发布,轻量级 RPC 服务框架

1)什么是MyThrift?

基于以下组件打造的一款轻量级RPC服务框架:thrift(facebook出品)、commons-pool(socket连接池)、自研服务治理框架(zookeeper).

2)为什么要写MyThrift?

2.1)提出问题:

    各种存储越来越多(redis,mysql,hdfs,hbase,mq),

    让web开发人员自己访问存储,并保证性能,是一件高要求的事情。

    造成的结果就是软件开发进度缓慢,性能低下,各种bug.

2.2)分析问题:

    RPC框架:考虑到本人看过thrift的源码,尤其是针对网络模块非常熟悉,并在实际生产环境中使用过,thrift性能不错。

    TCP/IP:有过2年的TCP/IP报文分析经验,从链路层到应用层都很熟悉。

    ZooKeeper:在MySQL-Binlog项目中攒出了一些使用经验,同时积极吸收Motan,JACK,HArpc等兄弟软件的优秀理念部分。

    连接池:使用commons-pool连接池组件。

2.3)解决问题:

    糅合thrift,zookeeper,commons-pool打造一款轻量级、性能高、上手容易的rpc调用框架,

    使得架构师和后台开发人员可以将各种复杂存储的IO访问对外暴露为服务(其实就是跨机器的普通函数调用)

    这样web开发人员可以专注于业务逻辑,加速产品迭代,对企业带来的好处不用多说!

本次版本内容:

1)server端进行网络模型参数调优

2)client端有连接池

3)支持server注册多个thrift的处理器Processor

可用于集中式负载的服务化组件,达到生产环境级别,经历过生产环境的考验,可放心使用。

http://git.oschina.net/qiangzigege/MyThrift 

内附非常详细+多图预警的《MyThrift在线使用文档.md》,0基础轻松上手!

posted @ 2016-05-05 17:02 paulwong 阅读(1248) | 评论 (0)编辑 收藏

Couchbase介绍,更好的Cache系统

在移动互联网时代,我们面对的是更多的客户端,更低的请求延迟,这当然需要对数据做大量的 Cache 以提高读写速度。

术语

  • 节点:指集群里的一台服务器。

现有 Cache 系统的特点

目前业界使用得最多的 Cache 系统主要是 memcached 和 redis。 这两个 Cache 系统都有都有很大的用户群,可以说是比较成熟的解决方案,也是很多系统当然的选择。 不过,在使用 memcached 和 redis 过程中,还是碰到了不少的问题和局限:

  • Cluster 支持不够。在扩容、负载均衡、高可用等方面存在明显不足。
  • 持久化支持不好,出现问题后恢复的代价大。memcached 完全不支持持久化,redis 的持久化会造成系统间歇性的负载很高。

我期待的理想 Cache 系统

良好的 cluster 支持

  • Key 可以动态分散(Auto Sharding)在不同的服务器上,可以通过动态添加服务器节点增加系统容量。
  • 没有单点失效,任何一个单点都不会造成数据不可访问。
  • 读写负载可以均匀分布在系统的不同节点上。

支持异步持久化支持

  • 方便快速恢复,甚至可以直接用作 key/value 数据库。 经常在跟业界朋友交流时,会提到用 key 分段的方法来做容量扩展以及负载均衡。但是用静态的 key 分段会有不少问题:
  • Cache 系统本身及使用 cache 的客户端都需要预设一个分段逻辑,这个逻辑后期如果需要调整将会非常困难。不能解决单点失效的问题,还需要额外的手段。运维需要更多的人为参与,避免 key 超出现有分区,一旦出现 key 找不到对应服务器,访问直接失败。

最接近需求的系统:Couchbase

基于这些想法,我花了几天时间在 google, stack overflow, quora 上看了很多大家关于 cache cluster 的讨论,找到一个比较新系统 Couchbase。

mem vs cbmemcached VS couchbase

Couchbase 的集群设计对等网

Couchbase 群集所有点都是对等的,只是在创建群或者加入集群时需要指定一个主节点,一旦结点成功加入集群,所有的结点对等。

high_level_architecture

图片来源:couchbase.com

对等网的优点是,集群中的任何节点失效,集群对外提供服务完全不会中断,只是集群的容量受影响。 Smart Client

由于 couchbase 是对等网集群,所有的节点都可以同时对客户端提供服务,这就需要有方法把集群的节点信息暴露给客户端,couchbase 提供了一套机制,客户端可以获取所有节点的状态以及节点的变动,由客户端根据集群的当前状态计算 key 所在的位置。 vBucket

vBucket 概念的引入,是 couchbase 实现 auto sharding,在线动态增减节点的重要基础。

简单的解释 vBucket 可以从静态分片开始说起,静态分片的做法一般是用 key 算出一个 hash,得到对应的服务器,这个算法很简单,也容易理解。如以下代码所示:

servers = ['server1:11211', 'server2:11211', 'server3:11211'] server_for_key(key) = servers[hash(key) % servers.length] 

但也有几个问题:

  • 如果一台服务器失效,会造成该分片的所有 key 失效。
  • 如果服务器容量不同,管理非常麻烦。
  • 前面提到过,运维、配置非常不方便。

为了把 key 跟服务器解耦合,couchbase 引入了 vBucket。可以说 vBucket 代表一个 cache 子集,主要特点:

  • key hash 对应一个 vBucket,不再直接对应服务器。
  • 集群维护一个全局的 vBucket 与服务器对应表。
  • 前面提到的 smart client 重要的功能就是同步 vBucket 表。

如以下代码所示:

servers = ['server1:11211', 'server2:11211', 'server3:11211'] vbuckets = [0, 0, 1, 1, 2, 2] server_for_key(key) = servers[vbuckets[hash(key) % vbuckets.length]] 

vBucket

图片来源:http://dustin.sallings.org/2010/06/29/memcached-vbuckets.html

由于 vBucket 把 key 跟服务器的静态对应关系解耦合,基于 vBucket 可以实现一些非常强大有趣的功能,例如:

  • Replica,以 vBucket 为单位的主从备份。如果某个节点失效,只需要更新 vBucket 映射表,马上启用备份数据。
  • 动态扩容。新增加一个节点后,可以把部分 vBucket 转移到新节点上,并更新 vBucket 映射表。

vBucket 非常重要,以后可以单独写一篇文章分享。

总结

  • Couchbase 的对等网设计,smart client 直接获取整的集群的信息,在客户端实现负载均衡,整个集群没有单点失效,并且完全支持平行扩展。
  • vBucket 的引入,完全实现了 auto sharding,可以方便灵活的把数据的子集在不同节点上移动,以实现集群动态管理。
  • Couchbase 有一个非常专业的 web 管理界面,并且支持通过 RESTful API 管理,这也是 memcached, redis 不能企及的。
  • 如果只是做 key/value 的 cache,Couchbase 可以完全取代 memcached。
  • Couchbase 已经被我们在生产环境中大量采用。

posted @ 2016-05-04 15:00 paulwong 阅读(130) | 评论 (0)编辑 收藏

[转]巅峰对决 - 框架的性能比较

转自:http://colobu.com/2016/04/25/performance-comparison-of-frameworks/
这句话也可以应用在软件开发上,"无快不破"强调的是软件的性能。我陆陆续续写了多篇各种框架的文章,也在github上开了多个性能比较的开源项目,本文做一个汇总,以备将来的查找。

  1. 最快的web服务器
  2. 最快的并发框架
  3. 最快的RPC服务器
  4. 最快的websocket框架
  5. 最快的RESTful框架
  6. 最快的Go序列化框架
  7. 最快的Go web框架
  8. 最快的Java序列化框架

posted @ 2016-05-03 14:36 paulwong 阅读(153) | 评论 (0)编辑 收藏

轻量级 RPC 框架新浪微博的 motan

概述

motan是一套高性能、易于使用的分布式远程服务调用(RPC)框架。

功能

  • 支持通过spring配置方式集成,无需额外编写代码即可为服务提供分布式调用能力。

  • 支持集成consul、zookeeper等配置服务组件,提供集群环境的服务发现及治理能力。

  • 支持动态自定义负载均衡、跨机房流量调整等高级服务调度能力。

  • 基于高并发、高负载场景进行优化,保障生产环境下RPC服务高可用。

文档索引

posted @ 2016-04-25 14:22 paulwong 阅读(1447) | 评论 (1)编辑 收藏

dubboss

HTTPCLIENT请求基于NETTY的HTTP服务器,NETTY生成相关的HTTPREQUEST、HTTPRESPONSE,调用SPRING 的DISPATCHSERVLET.SERVICE,将HTTPRESPONSE生成二进制字节,返回HTTPCLIENT。DISPATCHSERVLET同时会调用SPRING的CONTROLLER干活,即以前的SPRING MVC那套可以保留。

缺点:
nginx+tomcat与netty优缺点
http://www.oschina.net/question/1765708_158026

我的架构最开始是 nginx + [netty (tcp) ] 用nginx做负载均衡。后来分布式接口变成了http restful -> nginx + [netty(http) ]

于是参考了netty的官方http例子,开始移植代码,其实移植量不大,只需要把原来的tpc handler里面的逻辑放到http handler里面就可以了。本以为ok了,测试才发现了大量的问题,其实问题本身是由于对http基础掌握的还不够透彻,比如keep-alive属性,这个平时基本不用的东西,当你要自己开发http server时,变的很有用,你不能每次都close channel.你要化很多时间了解header里面每个字段的意思,然后去实现它。再比如一个post请求,你要自己写代码从body里面读数据,解码等。

最终我放弃了netty,回到了tomcat.应为tomcat把http的一切都帮你搞定了。

最终的架构是 nginx + [tomcat(http) ]

tomcat就是针对http层的,所以我建议http还是选择tomcat(或者其他成熟的http-server),并不是说netty不好,而是你的选择问题,netty是一个网络组件,tcp,udp,http都可以弄,但是官方文档都是些hello wolrd级别的。如果你非常了解http结构,完全可以基于netty搞出一个比tomcat牛的http server.

如果做tcp开发,netty不二之选!

dubboss是一个分布式REST服务的框架,实现了如下功能:

  • 基于dubbo的RPC
  • 基于netty的应用服务器
  • 基于springmvc的REST调用
  • 基于ngnix的负载均衡

https://github.com/leiguorui/dubboss

posted @ 2016-04-20 13:04 paulwong 阅读(1359) | 评论 (0)编辑 收藏

!!!架构网站内容不错

http://colobu.com/categories/%E6%9E%B6%E6%9E%84/page/2/

posted @ 2016-04-19 17:54 paulwong 阅读(141) | 评论 (0)编辑 收藏

SPRING MVC整合NETTY

http://wenku.baidu.com/view/4573aba4ce2f0066f53322e8.html

posted @ 2016-04-19 13:27 paulwong 阅读(631) | 评论 (0)编辑 收藏

Tigase服务器安装以及集群

     摘要: 安装第一台tigase服务器安装tigase服务器所需环境。[root@tigase3~]# yum install java-1.7.0-openjdk.x86_64 java-1.7.0-openjdk-devel.x86_64下载tigase服务器软件包。[root@tigase3tmp]#wget https://projects.tigase.org/attachments/d...  阅读全文

posted @ 2016-04-19 10:17 paulwong 阅读(207) | 评论 (0)编辑 收藏

在 Java 应用程序中使用 Elasticsearch

http://www.ibm.com/developerworks/cn/java/j-use-elasticsearch-java-apps/index.html?ca=drs-

posted @ 2016-04-18 23:39 paulwong 阅读(157) | 评论 (0)编辑 收藏

集中式日志系统 ELK 协议栈详解


http://www.ibm.com/developerworks/cn/opensource/os-cn-elk/index.html?ca=drs-

posted @ 2016-04-18 23:33 paulwong 阅读(190) | 评论 (0)编辑 收藏

DUBBO简介

http://dubbo.io/User+Guide-zh.htm

随着互联网的发展,网站应用的规模不断扩大,常规的垂直应用架构已无法应对,分布式服务架构以及流动计算架构势在必行,亟需一个治理系统确保架构有条不紊的演进。

  • 单一应用架构
    • 当网站流量很小时,只需一个应用,将所有功能都部署在一起,以减少部署节点和成本。
    • 此时,用于简化增删改查工作量的 数据访问框架(ORM) 是关键。
  • 垂直应用架构
    • 当访问量逐渐增大,单一应用增加机器带来的加速度越来越小,将应用拆成互不相干的几个应用,以提升效率。
    • 此时,用于加速前端页面开发的 Web框架(MVC) 是关键。
  • 分布式服务架构
    • 当垂直应用越来越多,应用之间交互不可避免,将核心业务抽取出来,作为独立的服务,逐渐形成稳定的服务中心,使前端应用能更快速的响应多变的市场需求。
    • 此时,用于提高业务复用及整合的 分布式服务框架(RPC) 是关键。
  • 流动计算架构
    • 当服务越来越多,容量的评估,小服务资源的浪费等问题逐渐显现,此时需增加一个调度中心基于访问压力实时管理集群容量,提高集群利用率。
    • 此时,用于提高机器利用率的 资源调度和治理中心(SOA) 是关键。

posted @ 2016-04-15 11:28 paulwong 阅读(159) | 评论 (0)编辑 收藏

Netty是什么?

本质:JBoss做的一个Jar包

 

目的:快速开发高性能、高可靠性的网络服务器和客户端程序

 

优点:提供异步的、事件驱动的网络应用程序框架和工具

 

通俗的说:一个好使的处理Socket的东东

 

 

如果没有Netty?

 

远古:java.net + java.io

 

近代:java.nio

 

其他:Mina,Grizzly

 

为什么不是Mina?

 

1、都是Trustin Lee的作品,Netty更晚;

2、Mina将内核和一些特性的联系过于紧密,使得用户在不需要这些特性的时候无法脱离,相比下性能会有所下降,Netty解决了这个设计问题;

3、Netty的文档更清晰,很多Mina的特性在Netty里都有;

4、Netty更新周期更短,新版本的发布比较快;

5、它们的架构差别不大,Mina靠apache生存,而Netty靠jboss,和jboss的结合度非常高,Netty有对google protocal buf的支持,有更完整的ioc容器支持(spring,guice,jbossmc和osgi);

6、Netty比Mina使用起来更简单,Netty里你可以自定义的处理upstream events 或/和 downstream events,可以使用decoder和encoder来解码和编码发送内容;

7、Netty和Mina在处理UDP时有一些不同,Netty将UDP无连接的特性暴露出来;而Mina对UDP进行了高级层次的抽象,可以把UDP当成"面向连接"的协议,而要Netty做到这一点比较困难。

 

 

Netty的特性

 

设计

统一的API,适用于不同的协议(阻塞和非阻塞)

基于灵活、可扩展的事件驱动模型

高度可定制的线程模型

可靠的无连接数据Socket支持(UDP)

 

性能

更好的吞吐量,低延迟

更省资源

尽量减少不必要的内存拷贝

 

安全

完整的SSL/TLS和STARTTLS的支持

能在Applet与Android的限制环境运行良好

 

健壮性

不再因过快、过慢或超负载连接导致OutOfMemoryError

不再有在高速网络环境下NIO读写频率不一致的问题

 

易用

完善的JavaDoc,用户指南和样例

简洁简单

仅信赖于JDK1.5

 

看例子吧!

 

Server端:

 

Java代码  收藏代码
  1. package me.hello.netty;  
  2.   
  3. import org.jboss.netty.bootstrap.ServerBootstrap;  
  4. import org.jboss.netty.channel.*;  
  5. import org.jboss.netty.channel.socket.nio.NioServerSocketChannelFactory;  
  6. import org.jboss.netty.handler.codec.string.StringDecoder;  
  7. import org.jboss.netty.handler.codec.string.StringEncoder;  
  8.   
  9. import java.net.InetSocketAddress;  
  10. import java.util.concurrent.Executors;  
  11.   
  12. /** 
  13.  * God Bless You! 
  14.  * Author: Fangniude 
  15.  * Date: 2013-07-15 
  16.  */  
  17. public class NettyServer {  
  18.     public static void main(String[] args) {  
  19.         ServerBootstrap bootstrap = new ServerBootstrap(new NioServerSocketChannelFactory(Executors.newCachedThreadPool(), Executors.newCachedThreadPool()));  
  20.   
  21.         // Set up the default event pipeline.  
  22.         bootstrap.setPipelineFactory(new ChannelPipelineFactory() {  
  23.             @Override  
  24.             public ChannelPipeline getPipeline() throws Exception {  
  25.                 return Channels.pipeline(new StringDecoder(), new StringEncoder(), new ServerHandler());  
  26.             }  
  27.         });  
  28.   
  29.         // Bind and start to accept incoming connections.  
  30.         Channel bind = bootstrap.bind(new InetSocketAddress(8000));  
  31.         System.out.println("Server已经启动,监听端口: " + bind.getLocalAddress() + ", 等待客户端注册。。。");  
  32.     }  
  33.   
  34.     private static class ServerHandler extends SimpleChannelHandler {  
  35.         @Override  
  36.         public void messageReceived(ChannelHandlerContext ctx, MessageEvent e) throws Exception {  
  37.             if (e.getMessage() instanceof String) {  
  38.                 String message = (String) e.getMessage();  
  39.                 System.out.println("Client发来:" + message);  
  40.   
  41.                 e.getChannel().write("Server已收到刚发送的:" + message);  
  42.   
  43.                 System.out.println("\n等待客户端输入。。。");  
  44.             }  
  45.   
  46.             super.messageReceived(ctx, e);  
  47.         }  
  48.   
  49.         @Override  
  50.         public void exceptionCaught(ChannelHandlerContext ctx, ExceptionEvent e) throws Exception {  
  51.             super.exceptionCaught(ctx, e);  
  52.         }  
  53.   
  54.         @Override  
  55.         public void channelConnected(ChannelHandlerContext ctx, ChannelStateEvent e) throws Exception {  
  56.             System.out.println("有一个客户端注册上来了。。。");  
  57.             System.out.println("Client:" + e.getChannel().getRemoteAddress());  
  58.             System.out.println("Server:" + e.getChannel().getLocalAddress());  
  59.             System.out.println("\n等待客户端输入。。。");  
  60.             super.channelConnected(ctx, e);  
  61.         }  
  62.     }  
  63. }  

 

客户端:

 

Java代码  收藏代码
  1. package me.hello.netty;  
  2.   
  3. import org.jboss.netty.bootstrap.ClientBootstrap;  
  4. import org.jboss.netty.channel.*;  
  5. import org.jboss.netty.channel.socket.nio.NioClientSocketChannelFactory;  
  6. import org.jboss.netty.handler.codec.string.StringDecoder;  
  7. import org.jboss.netty.handler.codec.string.StringEncoder;  
  8.   
  9. import java.io.BufferedReader;  
  10. import java.io.InputStreamReader;  
  11. import java.net.InetSocketAddress;  
  12. import java.util.concurrent.Executors;  
  13.   
  14. /** 
  15.  * God Bless You! 
  16.  * Author: Fangniude 
  17.  * Date: 2013-07-15 
  18.  */  
  19. public class NettyClient {  
  20.   
  21.     public static void main(String[] args) {  
  22.         // Configure the client.  
  23.         ClientBootstrap bootstrap = new ClientBootstrap(new NioClientSocketChannelFactory(Executors.newCachedThreadPool(), Executors.newCachedThreadPool()));  
  24.   
  25.         // Set up the default event pipeline.  
  26.         bootstrap.setPipelineFactory(new ChannelPipelineFactory() {  
  27.             @Override  
  28.             public ChannelPipeline getPipeline() throws Exception {  
  29.                 return Channels.pipeline(new StringDecoder(), new StringEncoder(), new ClientHandler());  
  30.             }  
  31.         });  
  32.   
  33.         // Start the connection attempt.  
  34.         ChannelFuture future = bootstrap.connect(new InetSocketAddress("localhost", 8000));  
  35.   
  36.         // Wait until the connection is closed or the connection attempt fails.  
  37.         future.getChannel().getCloseFuture().awaitUninterruptibly();  
  38.   
  39.         // Shut down thread pools to exit.  
  40.         bootstrap.releaseExternalResources();  
  41.     }  
  42.   
  43.     private static class ClientHandler extends SimpleChannelHandler {  
  44.         private BufferedReader sin = new BufferedReader(new InputStreamReader(System.in));  
  45.   
  46.         @Override  
  47.         public void messageReceived(ChannelHandlerContext ctx, MessageEvent e) throws Exception {  
  48.             if (e.getMessage() instanceof String) {  
  49.                 String message = (String) e.getMessage();  
  50.                 System.out.println(message);  
  51.   
  52.                 e.getChannel().write(sin.readLine());  
  53.   
  54.                 System.out.println("\n等待客户端输入。。。");  
  55.             }  
  56.   
  57.             super.messageReceived(ctx, e);  
  58.         }  
  59.   
  60.         @Override  
  61.         public void channelConnected(ChannelHandlerContext ctx, ChannelStateEvent e) throws Exception {  
  62.             System.out.println("已经与Server建立连接。。。。");  
  63.             System.out.println("\n请输入要发送的信息:");  
  64.             super.channelConnected(ctx, e);  
  65.   
  66.             e.getChannel().write(sin.readLine());  
  67.         }  
  68.     }  
  69. }  

 

Netty整体架构



 

Netty组件

 

ChannelFactory

Boss

Worker

Channel

ChannelEvent

Pipeline

ChannelContext

Handler

Sink

 

Server端核心类

NioServerSocketChannelFactory

NioServerBossPool 

NioWorkerPool

NioServerBoss

NioWorker

NioServerSocketChannel

NioAcceptedSocketChannel

DefaultChannelPipeline

NioServerSocketPipelineSink

Channels

 

 

ChannelFactory

Channel工厂,很重要的类

保存启动的相关参数

 

NioServerSocketChannelFactory

NioClientSocketChannelFactory

NioDatagramChannelFactory

 

这是Nio的,还有Oio和Local的

 

 

SelectorPool

 

Selector的线程池

 

NioServerBossPool 默认线程数:1

NioClientBossPool      1

NioWorkerPool      2 * Processor

NioDatagramWorkerPool

 

 

Selector

 

选择器,很核心的组件

 

NioServerBoss

NioClientBoss

NioWorker

NioDatagramWorker

 

 

Channel

 

通道

 

NioServerSocketChannel

NioClientSocketChannel

NioAcceptedSocketChannel

NioDatagramChannel

 

Sink

负责和底层的交互

如bind,Write,Close等

 

NioServerSocketPipelineSink

NioClientSocketPipelineSink

NioDatagramPipelineSink

 

Pipeline

负责维护所有的Handler

 

ChannelContext

一个Channel一个,是Handler和Pipeline的中间件

 

Handler

对Channel事件的处理器

 

 

ChannelPipeline

 



 

 

 

优秀的设计----事件驱动



 

 

优秀的设计----线程模型



 

注意事项

 

解码时的Position

 

Channel的关闭

 

更多Handler

 

 

Channel的关闭

 

用完的Channel,可以直接关闭;

1、ChannelFuture加Listener

2、writeComplete

 

一段时间没用,也可以关闭

TimeoutHandler

posted @ 2016-04-12 15:19 paulwong 阅读(276) | 评论 (0)编辑 收藏

轻量级分布式 RPC 框架

     摘要: Code highlighting produced by Actipro CodeHighlighter (freeware)http://www.CodeHighlighter.com/-->1、每套服务需搭配一个RPCSERVER2、RPCSERVER作为SPRING 容器的一个BEAN3、在SPRING启动的时候,RPCSERVER会启动一个NETTY服务器端,然后将SPRING...  阅读全文

posted @ 2016-04-12 13:44 paulwong 阅读(502) | 评论 (0)编辑 收藏

为什么开发与测试老掐架呢

让我们思考几个常见的问题:

  • 软件测试的目的是什么?

  • 开发人员能否构建出没有Bug的完美软件?

  • 测人人员和开发人员是什么关系?

  • 软件测试能否保证软件质量?

先闭目冥想五分钟吧,然后可以尝试着回答上面的问题。

计算机先驱 Maurice Wikes 回忆起 1949 年他在英国剑桥工作的情形,在拖着打孔纸带上楼给雏形计算机 EDASC 装载程序时,他看到了自己的未来:

我强烈的意识到,生命中剩下的好日子,都将耗费在给自己的程序找错误上头。

Maurice Wikes告诉我们,没有完美的软件。

我曾经写过一篇荐书文,推荐了温伯格技术思想三部曲中的《颠覆完美软件:软件测试必须知道的几件事》。在这本书里,温伯格也告诉我们,没有完美的软件。所有的开发和测试人员都应该读读那本书。

温伯格在《颠覆完美软件》中几乎讨论所有常见的与软件测试相关的概念、问题和指导思想,所以,在这篇文章里,我只能来吐槽啦,我将从以下几方面列一些常见的现象,希望能引起大家的思考。

  • 测试和开发的关系

  • 流程与标准

  • 资源

  • 态度

测试和开发的关系

测试和开发是对立的吗?

从处理Bug的角度看,似乎可以这么说。开发人员既生产代码,也生产Bug。因为开发人员不可避免地会生产Bug,所以测试人员必须存在,以便在软件交付之前尽可能多地检出Bug,保证交付给客户的软件质量更好一些。一个产Bug,一个挑Bug,看起来似乎是对立的。

在现实中,很多测试团队和开发团队也正是因为这一点而搞得关系不和,甚至真的对立起来。请回想一下你周围发生的与开发和测试相关的事儿,看看有没有遇到过下面的情景:

  • 开发说,测试净找麻烦,客户跟本不可能像他们那样使用软件

  • 测试说,问题总是会在看似极端的条件下产生,用户总是会不经意触碰到看似极端的不可能出现的条件

  • 开发说,测试花在异常情况下的精力比测试主流程还多,不知道轻重缓急

  • 测试说,开发从来不考虑测试的感受,连测都不测就扔给我们

  • 开发说,我都测了,还要测试人员干什么

  • 测试说,这么明显的问题你们都不测一下,把我们测试当垃圾桶啊

  • ……

许许多多类似的问题,让开发和测试的关系从扑朔迷离、相爱相杀走向对立。我见过开发和测试搞冷战某人遇见某人侧脸而过,也见过测试经理和开发经理打架,还见过高层领导故意让测试团队和开发团队关系紧张以为这样可以提高测试效率也能给开发压力最终会产出更高质量的软件……

实际上,测试和开发拥有同一个目的:让软件更完美。测试和开发的关系,是一个问题的两面,应该是相辅相成和平共处的。测试不是为了挑刺儿,他提出的问题也不针对生产软件的开发人员,而仅仅是在努力想让开发人员的产出物看起来更好用。只要开发不将测试提Bug这个行为看成针对个人的行为,一切就有了美好的前提。

否定软件,并不是否定开发软件的人。这是开发和测试都需要明确的一个原则和前提。

还有的人认为开发和测试之关系类似皮与毛,皮之不存毛将焉附?所以有的开发也会因此而有优越感:没我们写软件,你们测试早下岗了!可是,开发不写软件,开发也下岗了耶!

感谢开发的不完美,让测试可以有事可做并练就慧眼。

感谢测试的认真细致和耐心体贴,让开发可以发现自己的不完美并有机会提升自己——那些说我软件不好的,都是为了我好。

资源

别动我们测试的服务器,你们自己搭一个!

我们没环境,不用你们的用谁的?

谁把我们的测试手机拿走了?你们申请一个嘛,老来占我们设备。

谁在用我们的账号?招呼都不打!我要用,赶紧退出来!

有时开发和测试之间也会有资源上的冲突,要有努力的有创造性的解决(我可以负责任地说,装黑苹果不是好办法),不要让大家伙的工作卡在环境上,这是管理者要解决的基本问题。我见过很多非常棒的一线经理,在现实制约下,主动把自己的手机、iPad都贡献出来当做测试设备。这也是解决资源问题的一种办法哦。

流程与标准

你身边的人员会这么抱怨吗:

  • 开发根本不看我们的测试用例,评审邮件从来就不回复

  • 我们一报Bug,开发就说用户根本不可能这么用,还说不知道我们怎么会这么测

  • 送测单里根本不写测试范围或者寥寥几句跟没写一样

  • 开发调整设计从来也不告诉我们

  • 为什么产品经理和UI只和开发讨论需求变更?

  • 为什么发布计划里不给测试预留测试时间?

  • 为什么开发写完代码测都不测就扔给我们?

  • 为什么客户那里发现了问题老问是谁测的、为什么没测出来?

  • 测试老是一声不吭就把Bug优先级设置为Major

  • 测试总是把大量时间花在用户根本不可能用到的功能上

  • 测试分不清哪些什么是重点,你给他说他还老是一堆道理这了那了

  • 测试提的Bug,现象描述也不准确,重现步骤也没有,有的根本就知道是不是误操作

  • 测试老来打断我,一会儿叫一下一会儿叫一下,根本没办法专注开发

  • jira上的Bug重复率太高,一个问题提N遍,难道就不能合并一下?

  • 测试发现Bug,一声招呼都不打就直接告诉老板了,搞得我很被动

  • 测试就是专门挑刺儿的,有劲不往正地儿使,你倒是测测用户常用的功能啊

  • 那么简单的Bug都能流出到用户那里,真不知道测试怎么测的

  • 开发老嫌测试报告数据不漂亮,逼着我们调整

Ok,如果你身边的开发和测试从来没有过类似的问题,那很好,恭喜你,看来你们的团队人nice协作也很顺畅,棒棒哒。

假如你身边充斥着这样嘈杂的抱怨,那说明什么呢?开发、测试、发布这一套流程有问题?还是团队缺乏明确的指向来引导大家向积极、有效的行为靠近?

流程和标准总是有待解释的,再好的规则,歪嘴和尚也能把它念斜……

我们随便挑一个问题吧:为什么开发写完代码测都不测就扔给我们?这个问题普遍存在,它反映出的是程序员和测试人员的工作边界难以界定的矛盾。

程序员会说,我都测一遍,还要你们测试做什么?

测试会说,你测都不测,冒烟都过不了,有没有责任心?

程序员说,要我写测试用例,搭各种环境,遍历各种正常、异常逻辑,我还有没有时间写代码了?

测试会说,我们测试是垃圾桶吗,什么烂玩意儿都直接扔给我们,我们的时间就那么不值钱?

开发会说,测试本来就是干这个的,你不测谁测?

……

像这样的问题,能制定一个标准,说明什么样的逻辑开发要自测覆盖什么样的逻辑可以交给测试来测?能画一条三八线吗?

不能。所以,这个时候,靠谱的一线管理者就显得很重要。如何创造性的发现适合团队的方法来让大家顺畅地协同工作,比标准、制度更重要,这往往依赖于技术管理者的能力和团队成员的意识。没有普适的方法,只有适合这个组织的、此时此地的策略,加油吧,在战斗中摸索出最适合当下的道路。

那什么是靠谱的一线管理者呢?

温伯格《成为技术领导者》一书中对领导职责的定义如下:

领导的职责就是创造这样一个环境,每个人都能在其中发挥出更多的能力。

如果一个技术领导带领的团队,大部分人都能专心做与其能力适配的事情而不用整天泡在与本节前面所列类似的问题里,那他基本上就算是比较靠谱了。

至于像给测试预留多长的测试周期、调整设计要不要通知测试、需求调整要不要测试参与等问题,合理的流程和标准可以起到很大的辅助作用,技术领导者只要依据合理的制度,引导大家有效参与,就可以化解。

态度

场景一:

测试MM对阿猿说发现了一个Bug。  阿猿矢口否认:不可能,绝对不可能!  MM:真的有Bug,你过来看一下!  阿猿:我都不用看,在我这儿好好儿的。  MM:你来看一下嘛……  阿猿:看什么看,肯定你环境问题,动什么东西了吗?重启了吗?

场景二:

测试MM想在jira上提个Bug,先在QQ上对阿猿说:有个Bug,你过来看下?  阿猿:忙着呢,焦头烂额的。  MM:一分钟都用不了,你来看下吧。  阿猿:思路一打断就不好恢复了,等会儿!  MM:你不看我提到jira上了啊。  阿猿:随便,你不就是爱提Bug嘛。

场景三:

测试MM呼叫阿猿:阿猿阿猿,程序又崩溃了,快来看看!  阿猿慢腾腾地起身过来,鼠标点几下:看不出来什么问题,你怎么操作的?  MM:这样点一下,那样,这样,……回车……。  阿猿:重现不了啊,你想办法重现,重现了再叫我,我忙着呢。  MM:……

我曾经画过一张暴漫,以“她发现了一个Bug”为题发布在微信订阅号“程序视界”里,再现类似的场景,感兴趣的可以在订阅号内回复10019查看(点击订阅号底部的帮助菜单里的“所有文章”子菜单也能找到)。

开发和测试的日常工作中,上面的情景不断上演,这其中有一部分原因来自态度。我们有时还能听到类似下面的话:

  • 你Bug里的现象描述根本没用

  • 你根本就没理解这个逻辑,给你说不清楚

  • 测试什么都不懂……

  • 你听我的,我让你怎么测你就怎么测

  • 你这种测法儿,再好的软件都经不起你折腾

  • 用户根本不可能这样用,你们整来整去净瞎耽误工夫

  • 一轮都没测完,你们就给老板说可以按期交付没问题?

  • 你们安排计划时根本不考虑测试,三天,三天怎么可能测得完!

  • ……

有时,有一些开发人员会用技术优势藐视测试,认为测试工作技术含量低,内心认为测试是附属没地位,说话就不太客气……测试会感觉到,反过来也会对开发有意见……就这么,从相敬如宾开始走向嫌怨丛生……

有个朋友的QQ签名档是:没有自我,只有大道。我琢磨,放在软件项目里,也挺适用的。

其实,开发和测试拥有共同的目的:生产高质量软件。具体说,每一个产品、项目、版本都有明确的目标,这些目标是属于开发和测试的,是大家的。我们把共同的目标牢记在心,摆在首位,我们还要想着别人所做的一切,都是针对软件本身,都是在为目标而努力,这样就心平气和多了,就容易从当下的泥沼中超脱出来,求同存异共同前进。

    作者:foruok 微信订阅号“程序视界”(programmer_sight)

    原文:CSDN

    posted @ 2016-04-12 11:01 paulwong 阅读(150) | 评论 (0)编辑 收藏

    Dubbos

         摘要: dubbos主要是基于dubbox的基础上,进行进一步的优化及拓展。Dubbos当前的主要功能支持REST风格远程调用(HTTP + JSON/XML):基于非常成熟的JBoss RestEasy框 架,在dubbo中实现了REST风格(HTTP + JSON/XML)的远程调用,以显著简化企业内部的跨语言交互,同时显著简化企业对外的Open API、无线API甚至AJAX服务端等等的开...  阅读全文

    posted @ 2016-04-12 10:59 paulwong 阅读(322) | 评论 (0)编辑 收藏

    Hack a Wifi Network WPA2/WPA/WEP

    First of all you will need a Linux operating system & a little education about Python
    programming.
    You can install Linux operating system on any Pc or Laptop.
    Note : This tutorial is only for eduactional purpose. The author of this pdf is not responsible for any illegal work. During installing and setting up you can loose all of your data, Do not do if you don’t know about programming.
    Device:
    Use Tp-link TL-WN722N Wifi Adapter for High gain.
    Start! Open Terminal:
    1. airmon-ng check kill
    2. airmon-ng
    3. airmon-ng start wlan0
    4. airodump-ng wlan0mon
    5. (control + c to stop)
    6. airodump-ng wlan0mon —bssid 5C:F9:6A:CD:8A:1D -c 1 -w WPA2
    7. wait for 1 minute, capture handshake
    8. aircrack-ng WPA2-01.cap -w /root/rockyou.txt
    /darkc0de
    /Wpa list 1,2,3

    darkc0de, Wpalist & rockyou.txt are the dictionaries files. You can download these from internet.
    This PDF is made by Malik Mubashir

    posted @ 2016-04-05 16:53 paulwong 阅读(131) | 评论 (0)编辑 收藏

    Walle --web部署系统工具

    Walle 一个web部署系统工具,配置简单、功能完善、界面流畅、开箱即用!支持git、svn版本管理,支持各种web代码发布,PHP,Python,JAVA等代码的发布、回滚,可以通过web来一键完成。

    官网主页 | Github主页

    功能列表

    • 用户分身份注册、登录
    • 开发者发起上线任务申请、部署
    • 管理者审核上线任务
    • 支持多项目部署
    • 支持多项目多任务并行
    • 快速回滚
    • 项目的用户权限管理
    • 部署前准备任务pre-deploy(前置检查)
    • 代码检出后处理任务post-deploy(如vendor)
    • 同步后更新软链前置任务pre-release
    • 发布完毕后收尾任务post-release(如重启)
    • 执行sql构建(不要担心忘记测试环境sql同步)
    • 线上文件指纹确认
    • 支持git、svn版本管理

    posted @ 2016-03-29 22:09 paulwong 阅读(192) | 评论 (0)编辑 收藏

    SHARDING-JDBC

    https://github.com/dangdangdotcom/sharding-jdbc/

    posted @ 2016-03-29 21:26 paulwong 阅读(145) | 评论 (0)编辑 收藏

    想知道吗?CTO 比普通程序员强在哪?

    互联网的蓬勃发展,让无数的程序员身价水涨船高,都变成了「香饽饽」,更有了不少「创业」,「当上 CTO,迎娶白富美的传说」。都说不想当元帅的士兵不是好士兵,我觉得这件事见仁见智,但提升自己的价值,让自己变得更优秀更有竞争力,一定是一线城市的大部分 IT 人内心的追求。

    诚然,并不是所有程序员都会变成 CTO,程序员——>CTO 的路径像是一个漏斗,极少数人沉淀下来,在业界掀起一阵阵飓风。这些 CTO 比起普通的程序员,强在哪?丰富的技术知识只是基础,更重要的是战略眼光,管理把控能力。那么 CTO 所思所想,和普通程序员究竟有什么不同?

     普通的程序员往往只负责模块的开发,代码的优化,和新技术的钻研,哦对我说的是普通程序员,而不是只会 fork 的小白程序员;而走向管理领域的高级程序员也许已经开始负责团队,背负团队进度和效率。而 CTO,往往不仅要考虑优化团队的开发工具、流程,肩负起把控整体技术方向的重任,要具有前瞻性,同时还要对企业绩效负责。尤其是技术驱动型公司,你问这样的公司 CTO 好招么,答案通常是「很难招」。技术选型其实是创业公司最纠结的问题,很多团队往往一上来基于已有的程序员的个人习惯和爱好,选择了一个技术方案,然后到某一天一看,我靠,全是坑(当然,也可能与执行者的能力有关)。

    图为通常来说程序员的发展路线:

    影响企业绩效的因素在方方面面,核心因素却往往集中在产品上。不夸张地说,应用程序的性能对于企业绩效有着非常巨大的影响。互联网产品遍地开花,SDK 层出不穷,用户对于一种新产品的尝试时间与互联网产品更新的速度成反比。用户体验这个已经被讲烂的概念依然还是提升产品价值的关键按钮,无论是 2C 还是 2B。

    一旦用户未在你所负责的产品中获得最佳体验,或者直接解决痛点,他们会毫不犹豫的选择其他平台。

    这个问题普通程序员通常解决不了,而一名优秀的 CTO 就需要下点功夫了。如何成为一名优秀的 CTO,这是一个问题,而一个问题往往是另一个问题的解决方案。为什么一个团队需要优秀的 CTO?是因为需要有人来带领技术团队优化应用性能——解决用户体验的难题,提升开发、运维,把控技术团队的战略方向。那么,优化应用性能,获得好的用户体验,提升开发、运维效率,又该怎么做呢?

    为了确保应用程序能够达到甚至超越用户的高期望,需要不断优化底层 IT 基础设施的性能。然而,随着基础设施变得越来越动态化,混合化和复杂化,一波波新的挑战随之而生,让不少 CTO 多了几根白头发。

    但是一个问题的产生,往往意味着相应的解决方法正在路上。为了优化应用程序的性能,优秀的 CTO 需要足够主动和敏捷。

    主动优化包括物理和虚拟服务器,网络,存储设备,数据库,终端用户服务,云,和大数据环境在内的所有基础设施。需要将 IT 团队带领成为不仅能够迅速识别和解决问题,同时具有强大的反脆弱性,在问题对用户体验产生不利影响之前,先发制人的组织。以下五大关键措施或许可以帮助我们实现一点。

    1. 捕捉和报告性能指标

    鉴于良好性能的重要性,对于 IT 团队来说只在基础设施组件出现问题时产生告警是不足够的。CTO 需要让团队能够提前发现潜在的性能问题,并主动解决。例如,通过免费或付费的第三方工具及一些开源工具,配置告警,在问题出现之前解决。不同的团队,往往有最为适合自己的基础设施监控手段,优秀的 CTO 需要能够综合衡量团队大小,开发、运维水平,与人力和资金成本,选择最符合公司当下情况的监控方式。对于变动型较大或者高速发展的公司,盲目增加人力和花费时间去进行自主开发系统监控解决方案往往造成时间的浪费,得不偿失。

    2. 统一视图和工具来增加可视性,并加快问题解决

    由于开源工具与第三方解决方案层出不穷,不少 IT 团队也勇于尝试新工具、新方法。虽然有很多新的工具,解决不同方面的问题,但当问题出现时,团队成员仍然花费许多时间开会讨论,不断地开会浪费了许多时间。而与此同时,用户却经历着槽糕的体验。为什么明明有许多工具却依然采取本办法沟通呢?原因有两个,一个是很多 IT 团队内部在使用不同的协作、监控等工具,另一个是其实团队内部并没有养成利用监控平台或者协作工具的习惯。这种时候 CTO 就需要发挥作用,采用一个统一且功能强大的视图和架构来监测关键的 IT 服务,无论是虚拟机,物理主机,云主机,或者其他组件,同时采取深刻理解DevOps,掌握提升协作、沟通效率,优化开发流程,节省运维成本,提前发现问题的方法。

    想知道吗?CTO 比普通程序员强在哪?

    3. 跟踪用户体验

    IT 团队可能拥有大量的性能指标,但是如果不知道用户的真实体验,就还是无法真正了解性能表现。什么是真实的体验?就是用户在实际操作中,是如何使用我们的产品的,在某个界面停留多久,对哪个环节不满意,诸如此类。IT 团队需要分析端到端的基础设施的响应时间,并借助虚拟交易功能,持续跟踪交易响应时间,即使在用户不使用应用程序的情况下。

    想知道吗?CTO 比普通程序员强在哪?

    4. 采用严格的 SLA 管理

    一旦企业的全面监测到位, IT 团队针对服务水平协议(SLAs)跟踪性能和体验是至关重要的。IT 团队需要能够跟踪 SLA 合规性,当潜在问题出现时,立即识别和解决。通过跟踪 SLAs,IT 企业可以评估他们在管理用户体验和基础设施性能上的有效性。 这一评估对于准确计量团队绩效,设定目标和跟踪进展也是至关重要的。

    5. 将 IT 和非 IT 数据相关联,进行高效的容量规划

    满足用户不断提高的期望,并不仅仅是跟踪 IT 数据。通过关联 IT 和业务数据,团队可以主动识别瓶颈,提高终端用户体验。比如,将服务器 CPU 利用率指标和简单的历史数据相关联;比如,将用户登录或交易的数量与 IT 数据一起进行展示,可以为适应未来发展的容量规划,提供有意义的见解。下图为某团队将 PHP 请求、响应时间等数据和系统性能数据一起导入 Cloud Insight 仪表盘进行展示的例子。

    想知道吗?CTO 比普通程序员强在哪?想知道吗?CTO 比普通程序员强在哪?

    插播一个好玩的,下图为某团队成员别出心裁将键盘使用记录导入仪表盘进行展示,也许键盘记录只是一种出于好玩的别出心裁,但同理,也可以将运营数据、业务数据、系统性能数据一起导入仪表盘进行展示,这对一个快速增长的 IT 团队来说,就很有价值了。

    想知道吗?CTO 比普通程序员强在哪?

    总结

    数据驱动互联网高速发展的时代,技术团队 Leader 除了技术过硬,眼光独到,还要将紧跟 DevOps 的步伐,放眼国内外,快速、敏捷、尽可能多的优化团队开发手段和流程,减少开发、运维、运营之间的沟通壁垒,将数据化融入到技术推进的方方面面。而当你在这些方面有了核心竞争力,就不再只是一名普通的程序员了。

    posted @ 2016-03-29 20:44 paulwong 阅读(102) | 评论 (0)编辑 收藏

    MongoDB健壮集群——用副本集做分片

         摘要: 1.    MongoDB分片+副本集健壮的集群方案多个配置服务器 多个mongos服务器  每个片都是副本集 正确设置w架构图说明:1.   此实验环境在一台机器上通过不同port和dbpath实现启动不同的mongod实例2.   总的9个mongod实例,分别做成shard...  阅读全文

    posted @ 2015-12-18 14:03 paulwong 阅读(303) | 评论 (0)编辑 收藏

    利用Mongodb的复制集搭建高可用分片,Replica Sets + Sharding的搭建过程

         摘要: 参考资料 reference:  http://mongodb.blog.51cto.com/1071559/740131  http://docs.mongodb.org/manual/tutorial/deploy-shard-cluster/#sharding-setup-shard-collection感谢网友Mr.Sharp,他给了我很多...  阅读全文

    posted @ 2015-12-18 13:54 paulwong 阅读(298) | 评论 (0)编辑 收藏

    MONGODB的复制与分片

    复制:为了防止单点故障,会有几个实例在运行,保持相同的数据。

    • 一般主从:一主多从,主作读写数据,从作从主备份数据用,如果主宕机,则整个MONGODB无法工作。
    • 复制式主从:一动态主多从,主由选举产生,当中一个主宕机,其他的从会选出一个主。

    适用场景:高负荷的读多写少。

    分片:SHARDING,一般数据库中的分库分表,一个表分成几个表用。每个片再做复制。

    适用场景:高负荷的写多读少。即如果发现MONGODB写不能支撑了,则要转此模式。

    安装配置服务器,安装ROUTER:MONGOS,安装分片服务器,通知MONGOS挂载SHARD。

    如果只启用数据库的分片,则不同的表放在不同的分片上,即一个表只占一个分片,另一个表占另一个分片,如果做了表的分片,则此表会分布在所有分片上。











    posted @ 2015-12-18 13:21 paulwong 阅读(191) | 评论 (0)编辑 收藏

    Android Application Architecture 安卓APP架构[译]

    本文介绍了文章作者从事了几年android应用的开发,经历2次架构变革,第一次集成了RxJava第二次集成了MVP,并将RxJava与MVP完美结合,实现了低耦合,代码简单,测试方便的架构。

    其实我们在开发中也遇到过,Android入门门槛较低,如果前期对APP规划不清晰,Coder们对未来变化把握不准,技术架构经验不够强大,最终导致就是一个Activity几千行,里面写了大量的Private方法,拆成几个Fragment、封装出来几个类都是无法解决,结果就是看Activity难受的要死,纠结,看了不爽改也不是不改也不是,严重影响看的人的心情。并且怨天尤人这个是产品人员规划App不好,没有前瞻性,改来改去。。。

    这篇文章就是使用新的结构解决该问题。

    安卓APP架构

    Android Application Architecture

    Our journey from standard Activities and AsyncTasks to a modern MVP-based architecture powered by RxJava.

    这篇文章主要目的是讲述如何将传统的Activities 与 AsyncTasks 模式向目前主流的MVP架构基础的响应式编程框架过度。

    1*HrE2lljEfsCu1X_OUDfHYA

    Different parts of a software codebase should be independent, yet perfectly work together like a well-oiled machine — photo by Chester Alvarez.

    先畅享一下:~~~如果松耦合架构,分工明确,然后完美的组合在一起工作是一个很吊的事情。
    (转个图片还要写明白谁拍的,版权意识真强)

    The Android dev ecosystem moves very quickly. Every week new tools are created, libraries are updated, blog posts are written and talks are given. If you go on holiday for a month, by the time you come back there will be a new version of the support library and/or Play Services.

    最近几年Android的生态链变化非常迅速,从底层的Android Api到应用层的各种开源的类库、工具更新非常迅速。一不留神就落后了。

    I’ve been making Android apps with the ribot team for over three years. During this time, the architecture and technologies we’ve used to build Android apps have been continuously evolving. This article will take you through this journey by explaining our learnings, mistakes and the reasoning behind these architectural changes.

    我在Ribot团队从事Android应用开发工作三年多,伴随着公司技术的不断创新,积累了很多经验、错误以及在技术选型背后的故事。

    旧的应用架构

    The old times
    Back in 2012 our codebases used to follow a basic structure. We didn’t use any networking library and AsyncTasks were still our friends. The diagram below shows approximately how the architecture was.

    2012年那个时候,我们的代码都是用的原生Android,没有使用任何的网络请求框架,而是基于AsyncTasks书写。
    1*TTtpcT4H80THBofnCtQ_L>The code was structured in two layers: the data layer that was in charge of retrieving/saving data from REST APIs and persistent data stores; and the view layer, whose responsibility was handling and displaying the data on the UI.
    The APIProvider provides methods to enable Activities and Fragments to easily interact with the REST API. These methods use URLConnection and AsyncTasks to perform network calls in a separate thread and return the result to the Activities via callbacks.

    代码分为两层,Data与View,Data层主要是用来从API获取数据,保存到持久化的db当中。View层主要就是把Data的数据显示到UI上。APIProvider提供方法出来,用于在Activity或者Fragment中方便的进行控制与交互。技术上将,使用URLConnection与AsyncTasks实现了一个异步的网络请求并将结果返回到调用的回调方法里面。

    In a similar way, the CacheProvider contains methods that retrieve and store data from SharedPreferences or a SQLite database. It also uses callbacks to pass the result back to the Activities.

    相同的原理CacheProvider提供一系列方法,将SharedPreferences或者SQLite的数据取出来,并且返回给到Activity

    问题

    The problems
    The main issue with this approach was that the View layer had too many responsibilities. Imagine a simple common scenario where the application has to load a list of blog posts, cache them in a SQLite database and finally display them on a ListView. The Activity would have to do the following:

    主要问题是View层有太多的累赘,以一个博客列表为例来讲述,比如博客需要显示一个ListView,从SQLite读取数据,Activity需要做到以下几点:

    1. Call a method loadPosts(callback) in the APIProvider
    2. Wait for the APIProvider success callback and then call savePosts(callback) in the CacheProvider.
    3. Wait for the CacheProvider success callback and then display the posts on the ListView.
    4. Separately handle the two potential errors callback from the APIProvider and CacheProvider.
    1. 执行APIProvider里面的loadPosts的方法,里面传入回调参数内容。
    2. 等待loadPosts执行成功后,执行回调里面的CacheProvider中的savePosts方法,savePosts也要传入回调参数。
    3. 等待savePosts执行成功后,执行回调里面的方法刷新ListView
    4. 分别书写代码处理2 3 两步的错误回调内容。

    This is a very simple example. In a real case scenario the REST API will probably not return the data like the view needs it. Therefore, the Activity will have to somehow transform or filter the data before showing it. Another common case is when the loadPosts() method takes a parameter that needs to be fetched from somewhere else, for example an email address provided by the Play Services SDK. It’s likely that the SDK will return the email asynchronously using a callback, meaning that we now have three levels of nested callbacks. If we keep adding complexity, this approach will result into what is known as callback hell.

    这还是一个比较简单的例子,在一些真实的场景中,远程的API可能没有返回程序的必须值,但是activity必须把数据处理完成之后才能显示结果。再一个例子就是如果loadPosts方法需要借助一些其他地方的返回参数时,类似用多线程去实现同步请求,为保证数据正常请求,意味着必须做一个三层的回调,如果再复杂一些,想理清楚这些回调就是很蛋疼的事情。

    In summary:
    Activities and Fragments become very large and difficult to maintain
    Too many nested callbacks means the code is ugly and difficult to understand so painful to make changes or add new features.
    Unit testing becomes challenging, if not impossible, because a lot of the logic lives within the Activities or Fragments that are arduous to unit test.

    总之,回调多了之后,Activity与Fragment会乱的要死,并且一般人无法直视。

    牛逼的新架构出来了

    A new architecture driven by RxJava
    We followed the previous approach for about two years. During that time, we made several improvements that slightly mitigated the problems described above. For example, we added several helper classes to reduce the code in Activities and Fragments and we started using Volley in the APIProvider. Despite these changes, our application code wasn’t yet test-friendly and the callback hell issue was still happening too often.

    我们在蛋疼的架构中煎熬了2年,当然也尝试过很多方式,最终也只能是缓和一下乱的问题。我们在APIProvider使用了Volley,代替了AsyncHttpClient,但是其实是一个吊样。

    It wasn’t until 2014 when we started reading about RxJava. After trying it on a few sample projects, we realised that this could finally be the solution to the nested callback problem. If you are not familiar with reactive programming you can read this introduction. In short, RxJava allows you to manage data via asynchronous streams and gives you many operators that you can apply to the stream in order to transform, filter or combine the data.

    不到2014年我们就开始进行RxJava的预研,然后尝试了一批简单的项目,感觉RxJava的方式是解决我们嵌套回调的终极解决办法。简单的说,RxJava允许你通过异步流的方式管理你的数据,并且还可以通过操作符(Operators)对Observable对象的变换

    Taking into account the pains we experienced in previous years, we started to think about how the architecture of a new app would look. So we came up with this.

    我们用了几年的经验痛定思痛,搞了下面这么个东西,新的APP的架构图

    1*kCynNIa5PscRl41V2scosA-200

    Similar to the first approach, this architecture can be separated into a data and view layer. The data layer contains the DataManager and a set of helpers. The view layer is formed by Android framework components like Fragments, Activities, ViewGroups, etc.

    与第一种方法相似,这个架构也是分为Data层与View层,Data层包含DataManager与一堆Helper;View层是包含Fragments, Activities, ViewGroups等。

    Helper classes (third column on diagram) have very specific responsibilities and implement them in a concise manner. For example, most projects have helpers for accessing REST APIs, reading data from databases or interacting with third party SDKs. Different applications will have a different number of helpers but the most common ones are:

    Helper主要是集成第三方的类库,以便于在代码中几行代码就可以清晰的实现某个功能,比如请求API,访问数据库等,虽然不同的应用程序都有不同的类库,但是他们无非就是以下这些内容:

    • PreferencesHelper: reads and saves data in SharedPreferences.
    • DatabaseHelper: handles accessing SQLite databases.
    • Retrofit services: perform calls to REST APIs. We started using Retrofit instead of Volley because it provides support for RxJava. It’s also nicer to use.
    • 从SharedPreferences中读取或者写入数据
    • 读写SQLite数据库
    • 类似与square的Retrofit服务,也就是Http Client,我们用Restrofit替代了Volley因为他支持Rxjava,并且更吊。

    Most of the public methods inside helper classes will return RxJava Observables.
    The DataManager is the brain of the architecture. It extensively uses RxJava operators to combine, filter and transform data retrieved from helper classes. The aim of the DataManager is to reduce the amount of work that Activities and Fragments have to do by providing data that is ready to display and won’t usually need any transformation.

    RxJava最核心的两个东西是Observables(被观察者,事件源)和Subscribers(观察者),在Helper类中的Public方法,一般都会返回一个RxJava的Observables;DataManager是整个架构的大脑,他大量的使用Rxjava的operators对Helper返回来的数据进行的整合过滤、二次处理。

    The code below shows what a DataManager method would look like. This sample method works as follows:

    下面用一个例子来说明DataManager是做什么的:

    1. Call the Retrofit service to load a list of blog posts from a REST API
    2. Save the posts in a local database for caching purposes using the DatabaseHelper.
    3. Filter the blog posts written today because those are the only ones the view layer wants to display.
    1. 调用Retrofit的服务,去请求一个博客列表的API
    2. 用DatabaseHelper保存这些数据到数据库
    3. 过滤出这些BLOG哪些是今天写的,然后显示到UI界面上。

    Components in the view layer such as Activities or Fragments would simply call this method and subscribe to the returned Observable. Once the subscription finishes, the different Posts emitted by the Observable can be directly added to an Adapter in order to be displayed on a RecyclerView or similar.

    Observables发出一系列事件,Subscribers(例如 Activities or Fragments)处理这些事件,可以直接将数据显示到一些可以回收、重用的View上面。
    【BTW:如果一个Observerble没有任何的的Subscriber,那么这个Observable是不会发出任何事件的】

    The last element of this architecture is the event bus. The event bus allows us to broadcast events that happen in the data layer, so that multiple components in the view layer can subscribe to these events. For example, a signOut() method in the DataManager can post an event when the Observable completes so that multiple Activities that are subscribed to this event can change their UI to show a signed out state.

    这个架构的另外一个模块是event bus,event bus可以让我们在Data层发出广播(不是Android的Broadcast)然后不同的模块去注册并接收不同的广播事件

    Why was this approach better?
    RxJava Observables and operators remove the need for having nested callbacks.
    1*BIsOCzJnc-SSU8fPXTiP1A

    为什么这个方式这么牛逼,是因为Observables与operators可以去掉那一堆必须的回调方法

    The DataManager takes over responsibilities that were previously part of the view layer. Hence, it makes Activities and Fragments more lightweight.
    Moving code from Activities and Fragments to the DataManager and helpers means that writing unit tests becomes easier.

    DataManager替代了传统架构中很多代码,从而使得Activity与Fragment变得更加轻量级。并且使得单元测试变得更加简单。

    Clear separation of responsibilities and having the DataManager as the only point of interaction with the data layer, makes this architecture test-friendly. Helper classes or the DataManager can be easily mocked.

    DataManager成为了唯一的数据交互部分,这样清晰的架构使得更方便进行代码自测。

    What problems did we still have?
    For large and very complex projects the DataManager can become too bloated and difficult to maintain.
    Although view layer components such as Activities and Fragments became more lightweight, they still have to handle a considerable amount of logic around managing RxJava subscriptions, analysing errors, etc.

    我们还有什么问题?
    - 如果对于非常庞大并且复杂的项目来说,DataManger也会变得非常臃肿并且难以维护。
    - 尽管Activity与Fragment已经变得更加轻量级,但是对于错误异常的处理还是要在subscriptions的地方去书写。

    一体化的MVP模式

    Integrating Model View Presenter
    In the past year, several architectural patterns such as MVP or MVVM have been gaining popularity within the Android community. After exploring these patterns on a sample project and article, we found that MVP could bring very valuable improvements to our existing approach. Because our current architecture was divided in two layers (view and data), adding MVP felt natural. We simply had to add a new layer of presenters and move part of the code from the view to presenters.

    前几年开始,很多类似MVP与MVVM在Android的一些社区比较流行,经过研究之后,我们发现MVP模式是对我们目前的方案最有价值的改动。我们的两层架构View-Data与MVP的 Model-View架构天然融合,理念一致。我们只需要增加一个presenters层,然后把之前在view实现的代码移到上面就可以了。
    1*NonRJ0uzzN9o1ygT6J421g

    The data layer remains as it was but it’s now called model to be more consistent with the name of the pattern.
    Presenters are in charge of loading data from the model and calling the right method in the view when the result is ready. They subscribe to Observables returned by the data manager. Therefore, they have to handle things like schedulers and subscriptions. Moreover, they can analyse error codes or apply extra operations to the data stream if needed. For example, if we need to filter some data and this same filter is not likely to be reused anywhere else, it may make more sense to implement it in the presenter rather than in the data manager.

    之前的Data层就是现在的MVP中的Model,Presenter现在负责从Model中加载数据,加载完成后后再去调用左边的在Activity、ViewGroup中的方法。Presenters的subscribe去接收data manager中的Observables广播出来的数据。
    举例说明,如果我们需要增加数据的过滤操作但是并不是所有地方都需要的那种,那就可以在presenter里面写这些代码,而不用写在公共的datamanager里面。

    Below you can see what a public method in the presenter would look like. This code subscribes to the Observable returned by the dataManager.loadTodayPosts() method we defined in the previous section.

    我们定义的dataManager.loadTodayPosts()会广播出数据给到对应的subscribes

    The mMvpView is the view component that this presenter is assisting. Usually the MVP view is an instance of an Activity, Fragment or ViewGroup.

    MVP的View并不是指的Android的View,而是一个界面组件的的实例,例如Activity, Fragment , ViewGroup 在注册presenter的时候,需要把自己当前的实例传递进去。

    // Activity onCreate 中的代码段  if (presenter == null)         presenter = new Presenter1();         presenter.onTakeView(this);  

    Like the previous architecture, the view layer contains standard framework components like ViewGroups, Fragments or Activities. The main difference is that these components don’t subscribe directly to Observables. They instead implement an MvpView interface and provide a list of concise methods such as showError() or showProgressIndicator(). The view components are also in charge of handling user interactions such as click events and act accordingly by calling the right method in the presenter. For example, if we have a button that loads the list of posts, our Activity would call presenter.loadTodayPosts() from the onClick listener.

    这个架构与上一个架构不同的是,ViewLayer 也就是Activity这些,不会直接去订阅接收Observables发出的这些事件。而是只在Activity实现几个简单的显示错误、显示进度的方法(用接口interface来规范统一),然后把当前实例以参数形式传递给到对应事件的Presenter,由Presenter去执行这些显示错误、显示进度的方法。
    当然对于用户交互部分的按钮点击事件还是要在Activity中进行处理。

    If you want to see a full working sample of this MVP-based architecture, you can check out our Android Boilerplate project on GitHub. You can also read more about it in the ribot’s architecture guidelines.

    关于MVP的文章可以自行百度一下,MVP Android 关键词

    Why is this approach better?

    为什么这个又最吊

    • Activities and Fragments become very lightweight. Their only responsibilities are to set up/update the UI and handle user events. Therefore, they become easier to maintain.
    • We can now easily write unit tests for the presenters by mocking the view layer. Before, this code was part of the view layer so we couldn’t unit test it. The whole architecture becomes very test-friendly.
    • If the data manager is becoming bloated, we can mitigate this problem by moving some code to the presenters.
    • Activity与Fragment代码量大大降低,逻辑代码全部都丢给了Presenter,结果就是Activity只需要负责UI交互的按钮等代码。
    • 对于Presenter可以写单独的单元测试代码,只需要对Presenter提供的方法测试即可
    • 如果DataManager变得臃肿庞大了,我们可以分离这些代码到各自的Presenter中去。

    What problems do we still have?
    现在还有遗留什么问题

    Having a single data manager can still be an issue when the codebase becomes very large and complex. We haven’t reached the point where this is a real problem but we are aware that it could happen.

    只有一个DataManager仍旧是一个问题,尤其是当代码项目比较庞大的时候,当然我们还没有到达这个庞大的地步,尽管我们知道这个将来某天会发生。

    It’s important to mention that this is not the perfect architecture. In fact, it’d be naive to think there is a unique and perfect one that will solve all your problems forever. The Android ecosystem will keep evolving at a fast pace and we have to keep up by exploring, reading and experimenting so that we can find better ways to continue building excellent Android apps.

    如果想有个完美的架构解决你所有问题是不可能的。TMD Android的整个生态圈变化太快,又TM的不标准,就导致我们不断的去探索探索。。。以致于去找到更吊的方法去做Android apps。

    I hope you enjoyed this article and you found it useful. If so, don’t forget to click the recommend button. Also, I’d love to hear your thoughts about our latest approach.

    希望读了之后对我们的最新解决方案能有些建议想法。

    【本文翻译的目的是在闲暇时间,研究新技术,用通俗技术语言写给自己看,便于日后方便查阅为目】
    原文:https://medium.com/ribot-labs/android-application-architecture-8b6e34acda65
    MVP介绍:http://www.jcodecraeer.com/a/anzhuokaifa/androidkaifa/2015/0425/2782.html
    RxAndroid:https://github.com/ReactiveX/RxAndroid
    Eventbus:https://github.com/greenrobot/EventBus

    posted @ 2015-12-18 13:07 paulwong 阅读(307) | 评论 (0)编辑 收藏

    mongodb的监控与性能优化

         摘要: .mongodb的监控 mongodb可以通过profile来监控数据,进行优化。查看当前是否开启profile功能用命令db.getProfilingLevel()  返回level等级,值为0|1|2,分别代表意思:0代表关闭,1代表记录慢命令,2代表全部开始profile功能为db.setProfilingLevel(level);  #level等级,值同上l...  阅读全文

    posted @ 2015-12-16 18:50 paulwong 阅读(251) | 评论 (0)编辑 收藏

    高压锅内部烧黑,如何去掉?

    http://www.360doc.com/content/11/0415/13/117643_109815383.shtml

    http://wenda.tianya.cn/question/4b4edcf687745412

    http://zhidao.baidu.com/question/456177515446176485.html

    http://iask.sina.com.cn/b/6262165.html

    http://baike.pcbaby.com.cn/qzbd/5691.html#ldjc4ta=baby_tbody2

    http://www.xiaoqiaomen.cc/qingjieweisheng/258.html

    http://home.19lou.com/forum-106-thread-6901352097188270-1-1.html

    posted @ 2015-12-14 18:25 paulwong 阅读(200) | 评论 (0)编辑 收藏

    MONGODB删除/新增/更改大量记录的方法

    MONGODB中,由于删除大量记录会十分耗时,一般推荐由MONGODB自己在后台处理,只需在某个字段设一个索引的标签即可。

    @Indexed(expireAfterSeconds=180)
    private Date deletedAt;

    以上代码,如果字段deletedAt有值,那么将在180秒后被MONGODB删除,如果没值不会被删除。

    批量新增,小批量更新,防止读取超时
    private <T> void insertAll(List<T> list) {
            if (null != list) {
                int total = list.size();
                int count = (total + 50000 -1) / 50000;
                for (int i = 0; i < count; i++) {
                    int toIndex = ((i +1) * 50000 > total) ? total : ((i +1) * 50000);
                    log.info("toIndex = " + toIndex);
                    mongoTemplate1.insertAll(list.subList(i * 50000, toIndex));
                }
            }
        }

    批量更改
    import java.util.Date;

    import org.springframework.beans.factory.annotation.Autowired;
    import org.springframework.data.mongodb.core.MongoTemplate;
    import org.springframework.data.mongodb.core.query.Criteria;
    import org.springframework.data.mongodb.core.query.Query;
    import org.springframework.data.mongodb.core.query.Update;

    import com.tcl.project7.boss.gameapplication.yearendactivities.bigwheelgame.valueobject.SingleUseRedeemCode;

    public class SingleUseRedeemCodeRepositoryImpl implements SingleUseRedeemCodeRepositoryCustom{
        
        @Autowired
        private MongoTemplate mongoTemplate1;
        
        public void batchUpdateSingleUseRedeemCodeList(String bigWheelGameAwardId) {
            
            Query query = new Query();
            query.addCriteria(Criteria.where("bigwheelgameawardid").is(bigWheelGameAwardId));
            mongoTemplate1.updateMulti(
                                        query, 
                                        new Update().set("bigwheelgameawardid", "-1")
                                            .set("deletedat", new Date()), 
                                        SingleUseRedeemCode.class);
        }

    }


    Expire Data from Collections by Setting TTL

    New in version 2.2.

    This document provides an introduction to MongoDB’s “time to live” or TTL collection feature. TTL collections make it possible to store data in MongoDB and have the mongod automatically remove data after a specified number of seconds or at a specific clock time.

    Data expiration is useful for some classes of information, including machine generated event data, logs, and session information that only need to persist for a limited period of time.

    A special TTL index property supports the implementation of TTL collections. The TTL feature relies on a background thread in mongod that reads the date-typed values in the index and removes expired documentsfrom the collection.

    Procedures

    To create a TTL index, use the db.collection.createIndex() method with theexpireAfterSeconds option on a field whose value is either a date or an array that contains date values.

    NOTE

    The TTL index is a single field index. Compound indexes do not support the TTL property. For more information on TTL indexes, see TTL Indexes.

    Expire Documents after a Specified Number of Seconds

    To expire data after a specified number of seconds has passed since the indexed field, create a TTL index on a field that holds values of BSON date type or an array of BSON date-typed objects and specify a positive non-zero value in the expireAfterSeconds field. A document will expire when the number of seconds in the expireAfterSeconds field has passed since the time specified in its indexed field. [1]

    For example, the following operation creates an index on the log_events collection’s createdAt field and specifies the expireAfterSeconds value of 3600 to set the expiration time to be one hour after the time specified by createdAt.

    db.log_events.createIndex( { "createdAt": 1 }, { expireAfterSeconds: 3600 } ) 

    When adding documents to the log_events collection, set the createdAt field to the current time:

    db.log_events.insert( {    "createdAt": new Date(),    "logEvent": 2,    "logMessage": "Success!" } ) 

    MongoDB will automatically delete documents from the log_events collection when the document’screatedAt value [1] is older than the number of seconds specified in expireAfterSeconds.

    [1](12) If the field contains an array of BSON date-typed objects, data expires if at least one of BSON date-typed object is older than the number of seconds specified in expireAfterSeconds.

    SEE ALSO

    $currentDate operator

    Expire Documents at a Specific Clock Time

    To expire documents at a specific clock time, begin by creating a TTL index on a field that holds values of BSON date type or an array of BSON date-typed objects and specify an expireAfterSeconds value of0. For each document in the collection, set the indexed date field to a value corresponding to the time the document should expire. If the indexed date field contains a date in the past, MongoDB considers the document expired.

    For example, the following operation creates an index on the log_events collection’s expireAt field and specifies the expireAfterSeconds value of 0:

    db.log_events.createIndex( { "expireAt": 1 }, { expireAfterSeconds: 0 } ) 

    For each document, set the value of expireAt to correspond to the time the document should expire. For instance, the following insert() operation adds a document that should expire at July 22, 201314:00:00.

    db.log_events.insert( {    "expireAt": new Date('July 22, 2013 14:00:00'),    "logEvent": 2,    "logMessage": "Success!" } ) 

    MongoDB will automatically delete documents from the log_events collection when the documents’expireAt value is older than the number of seconds specified in expireAfterSeconds, i.e. 0 seconds older in this case. As such, the data expires at the specified expireAt value.

    posted @ 2015-12-11 15:03 paulwong 阅读(279) | 评论 (0)编辑 收藏

    How to delete large amount of data of a MongoDB collection “quickly”

    We have a db collection that is around 30 million documents, and I need to trim it down, to only keeping the documents created on the last month. 

    One approach would be use the remove command with a condition on the created_at field (the collection already have an index on this field):

    db.my_collection.remove({created_at: {$lte: new Date("11/01/2012")}});

    But this approach will be very slow, instead of that, a better way to do it is rename the current collection (for instance to “old_collection”) using renameCollection. Then performing a query-and-insert from the “old_collection” into “my_collection”:

    db.my_collection.renameCollection("old_collection");  
    db.createCollection("my_collection");
    db.my_collection.createIndex(...); // recreate the indexes for the collection
    // copy docs from old collection into the new collection
    db.old_collection.find(
    {created_at: {$gte: new Date("11/01/2012")}} ).sort({_id: -1}).forEach(
    function(row) { db.my_collection.insert(row); } ); // drop old collection db.old_collection.drop();

    This approach is typically faster than running a bunch of removes on your data

    posted @ 2015-12-10 20:09 paulwong 阅读(194) | 评论 (0)编辑 收藏

    MongoDB 固定集合(Capped Collections)

    MongoDB 固定集合(Capped Collections)是性能出色且有着固定大小的集合,对于大小固定,我们可以想象其就像一个环形队列,当集合空间用完后,再插入的元素就会覆盖最初始的头部的元素!


    创建固定集合

    我们通过createCollection来创建一个固定集合,且capped选项设置为true:

    >db.createCollection("cappedLogCollection",{capped:true,size:10000})

    还可以指定文档个数,加上max:1000属性:

    >db.createCollection("cappedLogCollection",{capped:true,size:10000,max:1000})

    判断集合是否为固定集合:

    >db.cappedLogCollection.isCapped()

    如果需要将已存在的集合转换为固定集合可以使用以下命令:

    >db.runCommand({"convertToCapped":"posts",size:10000})

    以上代码将我们已存在的 posts 集合转换为固定集合。


    固定集合查询

    固定集合文档按照插入顺序储存的,默认情况下查询就是按照插入顺序返回的,也可以使用$natural调整返回顺序。

    >db.cappedLogCollection.find().sort({$natural:-1})

    固定集合的功能特点

    可以插入及更新,但更新不能超出collection的大小,否则更新失败,不允许删除,但是可以调用drop()删除集合中的所有行,但是drop后需要显式地重建集合。

    在32位机子上一个cappped collection的最大值约为482.5M,64位上只受系统文件大小的限制。


    固定集合属性及用法

    属性

    • 属性1:对固定集合进行插入速度极快
    • 属性2:按照插入顺序的查询输出速度极快
    • 属性3:能够在插入最新数据时,淘汰最早的数据

    用法

    • 用法1:储存日志信息
    • 用法2:缓存一些少量的文档

    posted @ 2015-12-09 14:41 paulwong 阅读(191) | 评论 (0)编辑 收藏

    MongoDB 聚合

    http://www.runoob.com/mongodb/mongodb-aggregate.html
    MongoDB中聚合(aggregate)主要用于处理数据(诸如统计平均值,求和等),并返回计算后的数据结果。有点类似sql语句中的 count(*)。


    aggregate() 方法

    MongoDB中聚合的方法使用aggregate()。

    语法

    aggregate() 方法的基本语法格式如下所示:

    >db.COLLECTION_NAME.aggregate(AGGREGATE_OPERATION)

    实例

    集合中的数据如下:

    {    _id: ObjectId(7df78ad8902c)    title: 'MongoDB Overview',     description: 'MongoDB is no sql database',    by_user: 'w3cschool.cc',    url: 'http://www.w3cschool.cc',    tags: ['mongodb', 'database', 'NoSQL'],    likes: 100 }, {    _id: ObjectId(7df78ad8902d)    title: 'NoSQL Overview',     description: 'No sql database is very fast',    by_user: 'w3cschool.cc',    url: 'http://www.w3cschool.cc',    tags: ['mongodb', 'database', 'NoSQL'],    likes: 10 }, {    _id: ObjectId(7df78ad8902e)    title: 'Neo4j Overview',     description: 'Neo4j is no sql database',    by_user: 'Neo4j',    url: 'http://www.neo4j.com',    tags: ['neo4j', 'database', 'NoSQL'],    likes: 750 },

    现在我们通过以上集合计算每个作者所写的文章数,使用aggregate()计算结果如下:

    > db.mycol.aggregate([{$group : {_id : "$by_user", num_tutorial : {$sum : 1}}}]) { "result" : [ { "_id" : "w3cschool.cc", "num_tutorial" : 2 }, { "_id" : "Neo4j", "num_tutorial" : 1 } ], "ok" : 1 } >

    以上实例类似sql语句: select by_user, count(*) from mycol group by by_user

    在上面的例子中,我们通过字段by_user字段对数据进行分组,并计算by_user字段相同值的总和。

    下表展示了一些聚合的表达式:

    表达式描述实例
    $sum计算总和。db.mycol.aggregate([{$group : {_id : "$by_user", num_tutorial : {$sum : "$likes"}}}])
    $avg计算平均值db.mycol.aggregate([{$group : {_id : "$by_user", num_tutorial : {$avg : "$likes"}}}])
    $min获取集合中所有文档对应值得最小值。db.mycol.aggregate([{$group : {_id : "$by_user", num_tutorial : {$min : "$likes"}}}])
    $max获取集合中所有文档对应值得最大值。db.mycol.aggregate([{$group : {_id : "$by_user", num_tutorial : {$max : "$likes"}}}])
    $push在结果文档中插入值到一个数组中。db.mycol.aggregate([{$group : {_id : "$by_user", url : {$push: "$url"}}}])
    $addToSet在结果文档中插入值到一个数组中,但不创建副本。db.mycol.aggregate([{$group : {_id : "$by_user", url : {$addToSet : "$url"}}}])
    $first根据资源文档的排序获取第一个文档数据。db.mycol.aggregate([{$group : {_id : "$by_user", first_url : {$first : "$url"}}}])
    $last根据资源文档的排序获取最后一个文档数据db.mycol.aggregate([{$group : {_id : "$by_user", last_url : {$last : "$url"}}}])

    管道的概念

    管道在Unix和Linux中一般用于将当前命令的输出结果作为下一个命令的参数。

    MongoDB的聚合管道将MongoDB文档在一个管道处理完毕后将结果传递给下一个管道处理。管道操作是可以重复的。

    表达式:处理输入文档并输出。表达式是无状态的,只能用于计算当前聚合管道的文档,不能处理其它的文档。

    这里我们介绍一下聚合框架中常用的几个操作:

    • $project:修改输入文档的结构。可以用来重命名、增加或删除域,也可以用于创建计算结果以及嵌套文档。
    • $match:用于过滤数据,只输出符合条件的文档。$match使用MongoDB的标准查询操作。
    • $limit:用来限制MongoDB聚合管道返回的文档数。
    • $skip:在聚合管道中跳过指定数量的文档,并返回余下的文档。
    • $unwind:将文档中的某一个数组类型字段拆分成多条,每条包含数组中的一个值。
    • $group:将集合中的文档分组,可用于统计结果。
    • $sort:将输入文档排序后输出。
    • $geoNear:输出接近某一地理位置的有序文档。

    管道操作符实例

    1、$project实例

    db.article.aggregate( { $project : {         title : 1 ,         author : 1 , }} );

    这样的话结果中就只还有_id,tilte和author三个字段了,默认情况下_id字段是被包含的,如果要想不包含_id话可以这样:

    db.article.aggregate( { $project : {         _id : 0 ,         title : 1 ,         author : 1 }});

    2.$match实例

    db.articles.aggregate( [ { $match : { score : { $gt : 70, $lte : 90 } } }, { $group: { _id: null, count: { $sum: 1 } } } ] );

    $match用于获取分数大于70小于或等于90记录,然后将符合条件的记录送到下一阶段$group管道操作符进行处理。

    3.$skip实例

    db.article.aggregate( { $skip : 5 }); 

    经过$skip管道操作符处理后,前五个文档被"过滤"掉。

    posted @ 2015-12-08 10:44 paulwong 阅读(216) | 评论 (0)编辑 收藏

    Java 中正确使用 hashCode 和 equals 方法

         摘要: 在这篇文章中,我将告诉大家我对hashCode和equals方法的理解。我将讨论他们的默认实现,以及如何正确的重写他们。我也将使用Apache Commons提供的工具包做一个实现。 目录:hashCode()和equals()的用法重写默认实现使用Apache Commons Lang包重写hashCode()和equals()需要注意记住的事情当使用ORM的时候特别要注意的hashC...  阅读全文

    posted @ 2015-12-01 10:52 paulwong 阅读(148) | 评论 (0)编辑 收藏

    SAMSUNG NOTE2双清教程

    双清教程:

    1. 手机关机,按住音量上+HOME+电源键
    2. 选择 wipe date/factory reset
    3. 选择 yes dalete all user data
    4. 选择 wipe cache partition
    5. 选择 yes wipe cache




    posted @ 2015-11-26 19:27 paulwong 阅读(107) | 评论 (0)编辑 收藏

    如何医治牙龈出血

    如何医治牙龈出血啊。。。谢谢啊,狂急!!!!
    悬赏分:0 - 解决时间:2005-11-22 12:37
    提问者: 小哈纳斯 - 魔法学徒 一级 

    http://www.234.com.tw/perio/topicList.cfm?kid=61

    最佳答案
    这里是我以前答复两个患者的资料,对你有作用:

    一 关于青年人牙龈出血

    ⑴ 我想你是牙龈出血。若是其它原因出血,你肯定早住医院而不会在这里轻松发贴了。

    ⑵ 这个臭味是来自血的腐败。既然牙龈会出血,也表明你有牙周的问题,这些渗血部位的牙垢及食物残渣也会发出难闻的气味。

    ⑶ 治疗一般应到专门的口腔门诊。看来你是第一次涉及口腔的保健,治疗的流程应该是这样的:

       先消除炎症:常规是口服利菌沙,灭滴灵,维生素C,维生素K。治疗约1周后,牙龈炎症消除,就应着手解决根本问题了。

       再清除牙垢:这是引起牙周炎的原因。牙垢很硬,堆积在牙龈周围,不断地刺激和损伤着牙龈,使成创面出血。而出血又可进一步形成牙垢,如此成恶性循环。

    ⑷ 在我们三甲医院,这个费用偏高些,约100元。它包括消炎和约两次的除垢(洗牙)。在县市级的医院应该便宜些。

    ⑸ 消炎7天加除垢2天。若同时治疗龋齿,还加2天。

    ⑹ 当然,你也可只做消炎一步,除垢待以后有时间再做。如此,你到大的药房去,买前3种药自己服。买3-5天的量。约花20元。

    ⑹ 这3-5天内,你要睡眠良好,尽量避免感冒发热,那会引起血管通透性趋增,使出血严重一些,不利于治疗消炎。

    ⑺ 平时多食富含维生素C的水果蔬菜很重要!!!
    好,暂就说这么多。对顽固性的牙龈出血(例如出了多年血),或是这样治疗仍不见效,请再设问,我们来为你确定新的治疗方案。

    二 关于老是治不好的牙龈出血(先用一法!!!!)

    楼上解释的对。但我要教你最重要的东西,就是怎样解决这个问题。当然,解决之后,你要补我的专家号,呵呵。(我有个熟人有40年牙龈出血的经历,可是它近年突然好了。你想知道原因吗?我给了他一个新招。)


       ⑴ 连服维生素C7天,每天100-300mg。(这个量不算多,意义你明白。)

       ⑵ 这7天内保持好睡眠,目的是调节好人的生理状态,使不容易感冒什么的,避免因发烧造成的微血管通透性能趋增,使容易出血。

       ⑶ 本条最重要:去药房买“阿奇霉素分散片”,买大厂出的,我建议买天津药业悦来牌的。每盒6片×0.25g,请单次口服4片,并详细阅读一下说明书。记住:只吃一次即可。若有严重的不良反应(极少有!!),带着这个药的说明书去看门诊,医生会处置。如果没有不良反应,可在48小时后把另2片吃了,仅此而已。

       该药是目前极有名的药,4年前从国外进来现已完全本土化,真的是国外科学家对人类的大贡献!也不算贵,约20-30元1盒6片。主要用途是对付非淋菌性性病。

       它是广谱抗菌药,更是☆靶向制剂☆。你明白这个吗?我说个白话以便你能听懂:这个药可跟随人的巨嗜细胞走。而巨嗜细胞又跟着炎症走,所以疗效显著。

       ⑷ 一般的牙科医生,都会建议你用利君沙和灭滴灵,外加维生素C和K。但我想你是老牙龈出血,这种药用过多次,不会太奏效,阿奇霉素毒副作用比上述两种都小,更重要的是你没用过,致病菌没有抗药性。

       ⑸ 炎症消除、出血停止之后,建议你去做一次牙垢清除。多年的出血肯定会导致牙根周围有比较多的牙垢,这些牙垢年复一年刺激着周围的牙龈,不但是细菌的温床,也使牙龈面持续受到创伤,牙龈出血还会卷土重来。

       ⑹ 此次牙龈炎症消除之后,口腔气味也会比以前好转,但牙根的一部分将暴露的比以前利害(以前被肿胀的牙龈包裹),产生龋齿的可能性将增加。因此要注意好口腔清洁。

    回答者: ccd2093 - 举人 四级 11-14 08:51
    提问者对于答案的评价:
    非常感谢~~

    posted @ 2015-11-19 08:47 paulwong 阅读(102) | 评论 (0)编辑 收藏

    javax.crypto.IllegalBlockSizeException: Data must not be longer than 256 bytes 解决办法

    如果用RSA加密数据的话,会有数据长度的要求,否则会抛异常:
    javax.crypto.IllegalBlockSizeException: Data must not be longer than 256 bytes

    推荐的做法:

    1. 随机生成一个密钥,用作对称密钥UUID
    2. 用此对称密钥,用对称加密法AES加密数据
    3. 用RSA的公钥加密此对称密钥
    4. 发送加密后的对称密钥和加密数据
    5. 用RSA私钥解密加密后的对称密钥
    6. 用解密密后的对称密钥,解密数据
    7. 完成
    AESSecurityUtil.java
    import java.security.Key;
    import java.util.UUID;

    import javax.crypto.Cipher;
    import javax.crypto.spec.SecretKeySpec;

    import sun.misc.BASE64Decoder;
    import sun.misc.BASE64Encoder;

    public class AESSecurityUtil {

        // 加密算法
        /** 指定加密算法为RSA */
        private static final String ALGORITHM = "AES";

        // 加密密钥
        
    // private static final byte[] keyValue = new byte[] { 'T', 'h', 'e',
        
    // 'B','e', 's', 't', 'S', 'e', 'c', 'r', 'e', 't', 'K', 'e', 'y' };
        
    // 16位的加密密钥
    //    private byte[] keyValue;

        /**
         * 用来进行加密的操作
         * 
         * 
    @param Data
         * 
    @return
         * 
    @throws Exception
         
    */
        public static String encrypt(String keyString, String data)
                throws Exception {
            Key key = generateKey(keyString);
            Cipher c = Cipher.getInstance(ALGORITHM);
            c.init(Cipher.ENCRYPT_MODE, key);
            byte[] encVal = c.doFinal(data.getBytes());
            String encryptedValue = new BASE64Encoder().encode(encVal);
            return encryptedValue;
        }

        /**
         * 用来进行解密的操作
         * 
         * 
    @param encryptedData
         * 
    @return
         * 
    @throws Exception
         
    */
        public static String decrypt(String keyString, String encryptedData) throws Exception {
            Key key = generateKey(keyString);
            Cipher c = Cipher.getInstance(ALGORITHM);
            c.init(Cipher.DECRYPT_MODE, key);
            byte[] decordedValue = new BASE64Decoder().decodeBuffer(encryptedData);
            byte[] decValue = c.doFinal(decordedValue);
            String decryptedValue = new String(decValue);
            return decryptedValue;
        }
        
        public static String generateKeyString()
        {
            //必须长度为16
            return UUID.randomUUID().toString().replaceAll("-", "").substring(0, 16);
        }

        /**
         * 根据密钥和算法生成Key
         * 
         * 
    @return
         * 
    @throws Exception
         
    */
        private static Key generateKey(String keyString) throws Exception {
            Key key = new SecretKeySpec(keyString.getBytes(), ALGORITHM);
            return key;
        }
        
        public static void main(String [] args) throws Exception
        {
            String keyString = generateKeyString();
    //        String keyString = "1234567890123456";
            System.out.println("密钥:" + keyString);
            
            String source = "恭喜发财!";// 要加密的字符串
            System.out.println("准备用密钥加密的字符串为:" + source);
            
            String cryptograph = encrypt(keyString, source);// 生成的密文
            System.out.print("用密钥加密后的结果为:" + cryptograph);
            System.out.println();

            String target = decrypt(keyString, cryptograph);// 解密密文
            System.out.println("用密钥解密后的字符串为:" + target);
            System.out.println();
        }

    }


    CryptoUtil.java
    import com.tcl.project7.boss.common.crypto.CryptoData;
    import com.tcl.project7.boss.common.util.JsonManager;
    import com.tcl.project7.boss.common.util.file.FileUtil;
    import com.tcl.project7.boss.gameapplication.yearendactivities.bigwheelgame.player.valueobject.BigWheelGameRequest;

    public class CryptoUtil {
        
        public static CryptoData encrypt(String data) throws Exception
        {
            //1、产生AES密钥
            String keyString = AESSecurityUtil.generateKeyString();
            
            //2、用AES法加密数据
            String cryptograph = AESSecurityUtil.encrypt(keyString, data);
            
            //3、用RSA加密AES密钥
            String finalKey = RSASecurityUtil.encrypt(keyString);
    //        System.out.print("用RSA加密AES密钥为:" + finalKey);
    //        System.out.print("加密数据:" + cryptograph);
            
            CryptoData cryptoData = new CryptoData();
            cryptoData.setKey(finalKey);
            cryptoData.setContent(cryptograph);
            
            //4、返回数据
            return cryptoData;
        }
        
        public static String decrypt(String keyString, String data) throws Exception
        {
            //1、解密密钥
            String decryptKeyString = RSASecurityUtil.decrypt(keyString);
            
            //2、解密内容
            String decryptData = AESSecurityUtil.decrypt(decryptKeyString, data);
            
            //3、返回
            return decryptData;
            
        }
        
        public static void main(String [] args) throws Exception
        {
            String aFilePath = "DATA/TESTING-FILE/TOCRYPTO/tocrypto.txt";
            String source = FileUtil.getContents(aFilePath);
            
            CryptoData cryptoData = encrypt(source);
            System.out.print(cryptoData);
            
            String target = decrypt(cryptoData.getKey(), cryptoData.getContent());
            System.out.print(target);
            
            BigWheelGameRequest bigWheelGameRequest = JsonManager.getBean(target, BigWheelGameRequest.class);
            System.out.print(bigWheelGameRequest);
        }

    }


    CryptoData.java
    import java.io.Serializable;

    public class CryptoData implements Serializable{

        private static final long serialVersionUID = -4774469372648172844L;
        
        private String key;
        
        private String content;

        public String getKey() {
            return key;
        }

        public void setKey(String key) {
            this.key = key;
        }

        public String getContent() {
            return content;
        }

        public void setContent(String content) {
            this.content = content;
        }

        public String toString() {
            return "CryptoData [key=" + key + ", content=" + content + "]";
        }

    }

    posted @ 2015-11-18 15:27 paulwong 阅读(1696) | 评论 (0)编辑 收藏

    JSON转JAVA BEAN


    import java.io.IOException;

    import org.codehaus.jackson.JsonParseException;
    import org.codehaus.jackson.map.DeserializationConfig;
    import org.codehaus.jackson.map.JsonMappingException;
    import org.codehaus.jackson.map.ObjectMapper;
    import org.codehaus.jackson.type.TypeReference;
    import org.junit.Test;
    import org.slf4j.Logger;
    import org.slf4j.LoggerFactory;


    public class ColumnControllerTest {
        
        private Logger logger = LoggerFactory.getLogger(ColumnControllerTest.class);
        
        
        @Test
        public void testTest()
        {
            ObjectMapper mapper = new ObjectMapper();
            /*AnnotationIntrospector introspector = new JaxbAnnotationIntrospector();
            // make deserializer use JAXB annotations (only)
            mapper.getDeserializationConfig().setAnnotationIntrospector(introspector);
            // make serializer use JAXB annotations (only)
            mapper.getSerializationConfig().setAnnotationIntrospector(introspector);
    */
            mapper.configure(DeserializationConfig.Feature.FAIL_ON_UNKNOWN_PROPERTIES, false);
            
            String userStr = "{\"username\":\"paul\",\"email\":\"paul@paul.com\"}";
            try {
                TypeReference<TestUser> temp = new TypeReference<TestUser>(){};
                TestUser testUser = mapper.readValue(userStr, temp);
                System.out.println(testUser.toString());
                
                String result = mapper.writeValueAsString(testUser);
                System.out.println(result);
                
            } catch (JsonParseException e) {
                // TODO Auto-generated catch block
                e.printStackTrace();
            } catch (JsonMappingException e) {
                // TODO Auto-generated catch block
                e.printStackTrace();
            } catch (IOException e) {
                // TODO Auto-generated catch block
                e.printStackTrace();
            }
        }

    }

    posted @ 2015-11-18 13:30 paulwong 阅读(161) | 评论 (0)编辑 收藏

    不得不承认Zeroc Ice是RPC王者: 完爆Dubbo,Thrift,谷歌RPC

         摘要: ice-dubbo-thrift-grpc性能测试对比,本次测试过程中还发现了一个支付宝的秘密,附件文档中会详细说明。测试说明    本测试只是个人为了对rpc进行技术选型,测试可能不够严谨,对某些rpc的参数可能也不是最优,如果你知道更优的参数配置或者改进意见等,欢迎反馈给我magicdoom@gmail.com。另外代码有些地方只是为了测试方便,不作为平时编程的范例。所有测...  阅读全文

    posted @ 2015-11-13 16:19 paulwong 阅读(7391) | 评论 (1)编辑 收藏

    Tengine

    简介

    Tengine是由淘宝网发起的Web服务器项目。它在Nginx的基础上,针对大访问量网站
    的需求,添加了很多高级功能和特性。Tengine的性能和稳定性已经在大型的网站如
    淘宝网天猫商城等得到了很好的检验。它的最终目标是打造一个高效、稳定、安全、
    易用的Web平台。

    从2011年12月开始,Tengine成为一个开源项目,Tengine团队在积极地开发和维护
    着它。Tengine团队的核心成员来自于淘宝搜狗等互联网企业。Tengine是社区合作
    的成果,我们欢迎大家参与其中,贡献自己的力量。

    特性

    动态

    邮件列表

    posted @ 2015-11-06 12:56 paulwong 阅读(130) | 评论 (0)编辑 收藏

    SPRING IO

    Spring起初只专注ioc和aop,现在已发展成一个庞大体系。比如security、mvc等。
    如此一来,不同模块或者与外部进行集成时,依赖处理就需要各自对应版本号。
    比如,较新spring与较老的quartz,它们集成就会遇到问题,给搭建和升级带来不便。

    因此Spring IO Platform应运而生,只要项目中引入了它,外部集成时依赖关系无需版本号

    <dependency>
     <groupId>org.springframework</groupId>
     <artifactId>spring-core</artifactId> 
    </dependency>

    Spring IO Platform只是一个pom文件,记录了spring与其他开源项目对应的版本。
    省去了版本号,也就省去了处理依赖时的问题,因为Spring IO Platform中有最优的版本。

    posted @ 2015-10-30 14:05 paulwong 阅读(166) | 评论 (0)编辑 收藏

    一篇不错的Docker入门介绍

    看到这标题你可能会想,网上不是已经有很多Docker的入门介绍了么?同一个主题被讲过很多次,还有没有必要必要再讲?可是,我体内这混杂的的高傲与固执虽然让人厌恶,但却让我广受大家的欢迎,这也让我觉得我应该来一发(篇),哈哈。 

    举一个我遇到的场景,ELK三剑客,即Elasticsearch、Logstash和Kibana。我可以选择把它们直接安装在我的MacBook上,这是我主力开发机,但是在上面已经装好一个Elasticsearch了。我不想破坏现在已有的环境。要解决这个问题,用2015年时下最热门的解决方案就是Docker了。如果过去一年关于Docker的各种热闹你都错过了,那么请继续往下看。 

    Docker做的事情就是将的软件隔离起来,让它们即使出了问题也不会互相影响。这并不是什么横空出世的新思想。你很可能会说内核控制的进程不就这样玩么?每一个进程都有自己的内存空间,并且在一个进程自身看来,内存空间与所处在的计算机的内存空间是一样的。然而内核欺骗了进程,在背后将内存地址重新映射到了真实的内存空间中。想想今天高速运转处理器,任何地方见到的系统都能同时运行多个进程。今天的文明社会比人类历史任何一个时间点制造的谎言数量级都要很多的量级。 

    扯远了,Docker将进程的隔离模型的进行了扩展,让隔离性变得更强。Docker是在Linux内核的基础上打造的一系列工具。整个文件系统被抽象了,网络被虚拟化了,其它进程被隐藏了,并且从理论上,不可能逃脱容器去对在一个机器上的其他进程搞破坏。实际中,每个人对于怎么才能逃脱容器,至少去收集一点运行容器的机器的相关信息,持开放的态度。跟虚拟机比较起来,容器的隔离性还是较弱。 

     

    上面箭头:提升单机性能;下面箭头:提升隔离性

    但换个角度看,进程比容器性能更好,容器性能比虚拟机性能更佳。原因很简单,隔离性更高,在每一个上下文中就需要运行更多的东西,从而拖慢速度。选择一个隔离性的过程,实际就是决定你对要运行进程的信任有多少的过程 - 它会不会去干扰其他的进程?如运行的进程都是自己的亲儿子,那你对他们会有一个很高的信任度,对他们用最少的隔离,运行在一个进程中就行了。如果是SAP,那么你很可能需要尽可能高的隔离性:将电脑装在封存在箱子里,绑在火箭上发射到月球。 

    Docker另一个很好的特性是,容器可以作为一个整体交付。他们不会像虚拟机那么臃肿。这大大的提高了部署的简易度。在这个微服务流行的世界里,你可以很容易将你的服务捆在一起,用镜像来发布。你甚至可以将build的结果指定成一个Docker镜像。 

    Docker将会怎样改变软件开发和部署的过程仍然有待观察。尽管我觉得Docker是一种带有破坏性的技术,但影响还在几年之后才会到来。虽然我会认为Docker会让很多系统管理员丢掉工作,但是实际上Docker却会改变他们的工作。每个人现在都需要一点变革,赶上时代的脚步。 

    又扯远了,说说OSX上的Docker。 

    细心的你可能注意到,我之前说Docker是运行在Linux内核之上的。然而OSX没有Linux内核,那怎么运行Docker呢。为了解决这个问题,我们需要用虚拟机来运行Docker。我们可以用一个叫boot2docker的工具来做这件事情,但是最近被docker-machine取代了。 

    我的机上有一个比较老的Docker,但是我觉得想试试Docker Compose,因为我运行着很多的服务。Docker Compose能让很多的容器协作起来运行一个整体的环境。为了遵循保证隔离服务的宗旨,每一个服务都运行在单独的容器中。因而,一个典型的web应用中,可以把web服务器运行在一个容器里面,数据库运行在另外一个容器里面,然后这些容器可以放在同一个机器上。 

    我从Docker官网上下载了安装包,并且跟着安装指南http://docs.docker.com/mac/step_one/安装。装好Docker后,我让docker-machine在Virtual Box上创建了新的虚拟机。 

     

    一起看起来很顺利,然后启动随处可见的hello-world镜像。 

    很惊讶这个镜像的并不完全,完全没有发现任何一个地方有“hello world”的输出。然而好在,不是每一个Docker镜像都实现地这般草率。这个hello world的例子比较无聊,看看能不能找到更加有意思的。我们想从容器中服务一个页面,我打算使用Nginx,已经有一个现成的Nginx的容器了,因此我创建了个新的Dockerfile。Dockerfile包含了一系列如何指导Docker从一系列镜像中创建出一个容器的指令。这里提到的容器包含以下内容: 
    Java代码 
    1. FROM nginx  
    2. COPY *.html /usr/share/nginx/html/  

    第一行设置了我们容器的基础镜像。第二行将本地的带有html后缀的文件拷贝到Nginx容器中WEB服务器的目录里。为了使用这个Dockerfile文件,我们需要创建一个Docker的镜像: 
    Java代码 
    1. /tmp/nginx$ docker build -t nginx_test .  
    2. Sending build context to Docker daemon 3.072 kB  
    3. Step 0 : FROM nginx  
    4. latest: Pulling from library/nginx  
    5. 843e2bded498: Pull complete  
    6. 8c00acfb0175: Pull complete  
    7. 426ac73b867e: Pull complete  
    8. d6c6bbd63f57: Pull complete  
    9. 4ac684e3f295: Pull complete  
    10. 91391bd3c4d3: Pull complete  
    11. b4587525ed53: Pull complete  
    12. 0240288f5187: Pull complete  
    13. 28c109ec1572: Pull complete  
    14. 063d51552dac: Pull complete  
    15. d8a70839d961: Pull complete  
    16. ceab60537ad2: Pull complete  
    17. Digest: sha256:9d0768452fe8f43c23292d24ec0fbd0ce06c98f776a084623d62ee12c4b7d58c  
    18. Status: Downloaded newer image for nginx:latest  
    19. ---> ceab60537ad2  
    20. Step 1 : COPY *.html /usr/share/nginx/html/  
    21. ---> ce25a968717f  
    22. Removing intermediate container c45b9eb73bc7  
    23. Successfully built ce25a968717f   

    Docker build命令开始将拉取已经构建好的Nginx容器。然后将我们的文件拷贝到容器里面,并且显示容器的hash值,这让它们很容易辨认。要运行这个容器我们可以运行: 
    Java代码 
    1. /tmp/nginx$ docker run --name simple_html -d -p 3001:80 -p 3002:443 nginx_test  

    这条命令让Docker运行nginxtest的容器,并且取名为simple_html。-d选项是为了让Docker在后台运行这条命令,并且最终-p选项是为了转发端口,这里需要将本地的3001端口映射到容器的80端口 - 即正常的web服务器端口。现在我们可以连接到web服务上了。如果我们打开chrome,访问localhost:3001就会看到: 

     

    居然不行,问题在于Docker没有意识到自己运行在虚拟机的环境里面,因此我们需要将vm的端口映射到我们本地机器上: 
    Java代码 
    1. Docker container:80 -> vm host:3001 -> OSX:3001  

    这个从虚拟机管理器里面可以轻松的搞定: 

     

    现在我们可以看到页面了: 

     

    这就是我们放在容器中的文件。好极了!现在我准备好尝试更复杂一点的容器了。 

    小贴士: 

    我注意到在虚拟机里面同时并行的运行Docker会整个让系统hang住。我怀疑同时跑两个虚拟工具可能让某个地方卡住产生了冲突的结果。我相信docker-machine的并行的支持正在在积极的解决中,0.5版本可能会看到。直到这之前,你可以参考:http://kb.parallels.com/en/123356并且看看:https://github.com/Parallels/docker-machine中对docker-machine的fork版本。 

    原文链接:Yet another intro to docker (翻译:钟最龙 校对:宋喻) 

    译文来自:DockOne.io

    posted @ 2015-10-30 12:49 paulwong 阅读(188) | 评论 (0)编辑 收藏

    糖果CMS,一个像糖果一样的CMS 糖果CMS

    一个JAVA的内容管理系统
    http://www.oschina.net/p/tg-cms

    posted @ 2015-10-27 18:24 paulwong 阅读(185) | 评论 (0)编辑 收藏

    REDIS监控

    http://git.oschina.net/hellovivi/RedisFlag

    posted @ 2015-10-19 12:39 paulwong 阅读(181) | 评论 (1)编辑 收藏

    深度技术揭秘,支付宝,财付通,到底每天都是怎样工作的?

    为了可以更好地解释支付结算系统对账过程,我们先把业务从头到尾串起来描述一下场景,帮助大家理解:一个可能得不能再可能的场景,请大家深刻理解里面每个角色做了什么,获取了哪些信息:  某日阳光灿烂,支付宝用户小明在淘宝上看中了暖脚器一只,价格100元。犹豫再三后小明使用支付宝网银完成了支付,支付宝显示支付成功,淘宝卖家通知他已发货,最近几日注意查收。
      小明:持卡人,消费者,淘宝和支付宝的注册会员,完成了支付动作,自己的银行账户资金减少,交易成功。
      银行:收单银行,接受来自支付宝的名为“支付宝BBB”的100元订单,并引导持卡人小明支付成功,扣除小明银行卡账户余额后返回给支付宝成功通知,并告诉支付宝这笔交易在银行流水号为“银行CCC”
      支付宝:支付公司,接收到淘宝发来的订单号为“淘宝AAA”的商户订单号,并形成支付系统唯一流水号:“支付宝BBB”发往银行系统。然后获得银行回复的支付成功信息,顺带银行流水号“银行CCC”
      淘宝:我们支付公司称淘宝这类电商为商户,是支付系统的客户。淘宝向支付系统发送了一笔交易收单请求,金额为100,订单号为:“淘宝AAA”,支付系统最后反馈给淘宝这笔支付流水号为“支付BBB”
      以上流程貌似大家都达到了预期效果,但实际上仍然还有一个问题:
      对支付公司(支付宝)而言,虽然银行通知了它支付成功,但资金实际还要T+1后结算到它银行账户,所以目前只是一个信息流,资金流还没过来。
      Tips:插一句话,对支付系统内部账务来说,由于资金没有能够实时到账,所以此时小明的这笔100元交易资金并没有直接记入到系统资产类科目下的“银行存款”科目中,而是挂在“应收账款”或者“待清算科目”中。大白话就是,这100元虽然答应给我了,我也记下来了,但还没收到,我挂在那里。
      对商户(淘宝)而言,虽然支付公司通知了它支付成功,他也发货了,但资金按照合同也是T+1到账。如果不对账确认一下,恐怕也会不安。
      倒是对消费者(小明)而言:反正钱付了,你们也显示成功了,等暖脚器呀等暖脚器~
      基于支付公司和商户的困惑,我们的支付结算系统需要进行两件事情:一是资金渠道对账,通称对银行帐;二是商户对账,俗称对客户帐。对客户帐又分为对公客户和对私客户,通常对公客户会对对账文件格式、对账周期、系统对接方案有特殊需求,而对私客户也就是我们一般的消费者只需要可以后台查询交易记录和支付历史流水就可以了。
      我们先聊银行资金渠道对账,由于支付公司的资金真正落地在商业银行,所以资金渠道的对账显得尤为重要。
      在一个银行会计日结束后,银行系统会先进行自己内部扎帐,完成无误后进行数据的清分和资金的结算,将支付公司当日应入账的资金结算到支付公司账户中。于此同时,目前多数银行已经支持直接系统对接的方式发送对账文件。于是,在某日临晨4点,支付宝系统收到来自银行发来的前一会计日对账文件。根据数据格式解析正确后和前日支付宝的所有交易数据进行匹配,理想情况是一一匹配成功无误,然后将这些交易的对账状态勾对为“已对账”。
      Tips:此时,对账完成的交易,会将该笔资金从“应收账款”或者“待清算账款”科目中移动到“银行存款”科目中,以示该交易真正资金到账。
      以上太理想了,都那么理想就不要对账了。所以通常都会出一些差错,那么我总结了一下常见的差错情况:
      1.支付时提交到银行后没有反馈,但对账时该交易状态为支付成功
      这种情况很正常,因为我们在信息传输过程中,难免会出现掉包和信息不通畅。消费者在银行端完成了支付行为,银行的通知信息却被堵塞了,如此支付公司也不知道结果,商户也不知道结果。如果信息一直没法通知到支付公司这边,那么这条支付结果就只能在日终对账文件中体现了。这时支付公司系统需要对这笔交易进行补单操作,将交易置为成功并完成记账规则,有必要还要通知到商户。
      此时的小明:估计急的跳起来了……付了钱怎么不给说支付成功呢!坑爹!
      TIPS:通常银行系统会开放一个支付结果查询接口。支付公司会对提交到银行但没有回复结果的交易进行间隔查询,以确保支付结果信息的实时传达。所以以上情况出现的概率已经很少了。
      2.我方支付系统记录银行反馈支付成功,金额为100,银行对账金额不为100
      这种情况已经不太常见了,差错不管是长款和短款都不是我们想要的结果。通常双方系统通讯都是可作为纠纷凭证的,如果银行在支付结果返回时确认是100元,对账时金额不一致,可以要求银行进行协调处理。而这笔账在支付系统中通常也会做对应的挂账处理,直到纠纷解决。
      3.我方支付系统记录银行反馈支付成功,但对账文件中压根不存在
      这种情况也经常见到,因为跨交易会计日的系统时间不同,所以会出现我们认为交易是23点59分完成的,银行认为是第二天凌晨0点1分完成。对于这种情况我们通常会继续挂账,直到再下一日的对账文件送达后进行对账匹配。
      如果这笔交易一直没有找到,那么就和第二种情况一样,是一种短款,需要和银行追究。
      以上情况针对的是一家银行资金渠道所作的流程,实际情况中,支付公司会在不同银行开立不同银行账户,用以收单结算(成本会降低),所以真实情况极有可能是:
      临晨1点,工行对账文件丢过来(支行A)
      临晨1点01分,工行又丢一个文件过来(支行B)
      临晨1点15分,农行对账文件丢过来
      。 。 。
      临晨5点,兴业银行文件丢过来
      。。。
      不管什么时候,中国银行都必须通过我方业务员下载对账文件再上传的方式进行对账,所以系统接收到中行文件一般都是早上9点05分……
      对系统来说,每天都要处理大量并发的对账数据,如果在交易高峰时段进行,会引起客户交互的延迟和交易的失败,这是万万行不得的所以通常支付公司不会用那么傻的方式处理数据,而是在一个会计日结束后,通常也是临晨时段,将前一日交易增量备份到专用对账服务器中,在物理隔绝环境下进行统一的对账行为,杜绝硬件资源的抢占。
      以上是银行资金渠道入款的对账,出款基本原理一致,不过出款渠道在实际业务过程中还有一些特别之处,由于大家不是要建设系统,我就不赘述了。
      谈完了资金渠道的对账,我们再来看看对客户帐。
      前面提到了,由于资金落在银行,所以对支付公司来说,对银行帐非常重要。那么同理,由于资金落在支付公司,所以对商户来说,对支付公司账也一样重要。能否提供高品质甚至定制化的服务,是目前支付公司走差异化路线的一个主要竞争点。
      之前说过,银行与支付公司之间的通讯都是可以作为纠纷凭证的。原理是对支付报文的关键信息进行密钥加签+md5处理,以确保往来报文“不可篡改,不可抵赖”。
      同理,支付公司和商户之间也会有类似机制保证报文的可追溯性,由此我们可以知道,一旦我方支付系统通知商户支付结果,那么我们就要为此承担责任。由此我们再推断一个结论:
      即便某支付订单银行方面出错导致资金未能到账,一旦我们支付系统通知商户该笔交易成功,那么根据协议该结算的资金还是要结算给这个商户。自然,我们回去追究银行的问题,把账款追回。
      没经过排版的小知识点---------------------------------------------------
      一、对支付系统而言,最基本的对账功能是供商户在其后台查询下载某一时间段内的支付数据文件,以供商户自己进行对账。
      这个功能应该是个支付公司就有,如果没有就别混了。
      二、对大多数支付系统而言,目前已经可以做到对账文件的主动投送功能。
      这个功能方便了商户系统和支付系统的对接,商户的结算人员无须登录支付平台后台下载文件进行对账,省去了人工操作的麻烦和风险。
      对大型支付系统而言,商户如果跨时间区域很大,反复查询该区域内的数据并下载,会对服务器造成比较大的压力。各位看官别笑,觉得查个数据怎么就有压力了。实际上为了这个查询,我最早就职的一家支付公司重新优化了所有SQL语句,并且因为查询压力过大服务器瘫痪过好几次。
      现在比较主流的做法是把商户短期内查询过、或者经常要查询的数据做缓存。实在不行就干脆实时备份,两分钟同步一次数据到专用数据库供商户查询,以避免硬件资源占用。甚至……大多数支付公司都会对查询范围跨度和历史事件进行限制,比如最多只能查一个月跨度内,不超过24个月前的数据……以避免服务嗝屁。
      对账这块大致就这样了,再往细的说就说不完了,
      风险控制,在各行各业都尤其重要。
      金融即风险,控制好风险,才有利润。
      虽然第三方支付严格意义上说并非属于金融行业,但由于涉及资金的清分和结算,业务主体又是资金的收付,所以风险控制一样非常重要。
      对支付公司来说,风控主要分为合规政策风控以及交易风控两种。
      前者主要针对特定业务开展,特定产品形态进行法规层面的风险规避,通常由公司法务和风控部门一起合作进行。例如,一家公司要开展第三方支付业务,现在要获得由人民银行颁发的“支付业务许可证”。遵守中国对于金融管制的所有条规,帮助人行监控洗钱行为……这些法规合规风险,虽然条条框框,甚至显得文绉绉,但如果没人解读没人公关,业务都会无法开展。
      当然,这块也不是本题所关注的重点,提问者关注的,应当是业务进行过程中的交易风控环节。
      现在随着各支付公司风险控制意识的加强,风控系统渐渐被重视起来。除了上述提到的合规风控相关功能,风控系统最讲技术含量,最讲业务水平,最考究数据分析的业务就是交易风控环节。
      对一笔支付交易而言,在它发生之前、发生过程中及发生过程后,都会被风控系统严密监控,以确保支付及客户资产安全。而所有的所有秘密,都归结到一个词头上:规则。风控系统是一系列规则的集合,任何再智能的风控方案,都绕不开规则二字。
      我们先看看,哪些情况是交易风控需要监控处理的:
      1.钓鱼网站
      什么是钓鱼呢?
      用我的说法,就是利用技术手段蒙蔽消费者,当消费者想付款给A的时候,替换掉A的支付页面,将钱付给B,以达成非法占用资金的目的。
      还有更低级的,直接就是发小广告,里面带一个类似http://tiaobao.com的网址,打开后和淘宝页面一摸一样,上当客户直接付款给假冒网站主。
      第一种情况风控系统是可以通过规则进行简单判定的,虽然有误杀,但不会多。
      通常使用的规则是判断提交订单的IP地址和银行实际支付完成的IP地址是否一致,如果不一致,则判断为钓鱼网站风险交易,进入待确认订单。
      但第二种情况,亲爹亲娘了,支付公司真的没办法。当然遇到客户投诉后可能会事后补救,但交易是无法阻止了。
      2.盗卡组织利用盗卡进行交易
      大家都知道,信用卡信息是不能随便公布给别人的,国内大多信用卡虽然都设置了密码,但银行仍然会开放无磁无密支付接口给到商户进行快速支付之用。
      所谓无磁无密,就是不需要磁道信息,不需要密码就可以进行支付的通道。只需要获取到客户的CVV,有效期,卡号三个核心信息,而这三个信息是在卡上直接有的,所以大家不要随便把卡交给别人哦~
      碰到类似的这种交易,风控系统就不会像钓鱼网站这样简单判断了。
      过去我们所有的历史交易,都会存库,不仅会存支付相关信息,更会利用网页上的控件(对,恶心的activex或者目前用的比较多的flash控件)抓取支付者的硬件信息,存储在数据库中。
      当一笔交易信息带着能够搜集到的硬件信息一同提交给风控系统时,风控系统会进行多种规则判定。
      例如:当天该卡是否交易超过3次
      当天该IP是否交易超过3次
      该主机CPU的序列号是否在黑名单之列
      等等等等,一批规则跑完后,风控系统会给该交易进行加权评分,标示其风险系数,然后根据评分给出处理结果。
      通过硬件信息采集以及历史交易记录回溯,我们可以建立很多交易风控规则来进行监控。所以规则样式的好坏,规则系数的调整,就是非常重要的用以区别风控系统档次高低的标准。
      例如,我听说著名的风控厂商RED,有一个“神经网络”机制,灰常牛逼。
       
      其中有一个规则我到现在还记忆犹新:
      某人早上八点在加利福尼亚进行了信用卡支付,到了下午一点,他在东亚某小国家发起了信用卡支付申请。系统判断两者距离过长,不是短短5小时内能够到达的,故判定交易无效,支付请求拒绝。
      规则非常重要,当然,数据也一样重要。我们不仅需要从自己的历史记录中整合数据,同时还要联合卡组织、银行、风控机构,购买他们的数据和风控服务用来增加自己的风控实力。
      SO,风控是一个不断积累数据、分析数据、运营数据、积累数据的循环过程。
      好的风控规则和参数,需要经过无数次的规则修改和调整,是一个漫长的过程。
      不知道大家做互联网,有没有利用GA做过AB测试,同样的,风控系统也需要反复地做类似AB测试的实验,以保证理论和实际的匹配。
      最后给大家说一个小小的概念:
      所谓风控,是指风险控制,不是风险杜绝。
      风控的目标一定不是把所有风险全部杜绝。
      合理的风控,目标一定是:利润最大化,而不是风险最小化
      过于严格的风控规则,反而会伤害公司利益(看看销售和风控经常打架就知道了)
      不光是交易的风控,我们日常制定规则,法规,公司流程,也一定要秉着这个出发点进行规划。

    posted @ 2015-09-09 23:09 paulwong 阅读(508) | 评论 (0)编辑 收藏

    Reactor模式详解

    前记

    第一次听到Reactor模式是三年前的某个晚上,一个室友突然跑过来问我什么是Reactor模式?我上网查了一下,很多人都是给出NIO中的 Selector的例子,而且就是NIO里Selector多路复用模型,只是给它起了一个比较fancy的名字而已,虽然它引入了EventLoop概 念,这对我来说是新的概念,但是代码实现却是一样的,因而我并没有很在意这个模式。然而最近开始读Netty源码,而Reactor模式是很多介绍Netty的文章中被大肆宣传的模式,因而我再次问自己,什么是Reactor模式?本文就是对这个问题关于我的一些理解和尝试着来解答。

    什么是Reactor模式

    要回答这个问题,首先当然是求助Google或Wikipedia,其中Wikipedia上说:“The reactor design pattern is an event handling pattern for handling service requests delivered concurrently by one or more inputs. The service handler then demultiplexes the incoming requests and dispatches them synchronously to associated request handlers.”。从这个描述中,我们知道Reactor模式首先是事件驱动的,有一个或多个并发输入源,有一个Service Handler,有多个Request Handlers;这个Service Handler会同步的将输入的请求(Event)多路复用的分发给相应的Request Handler。如果用图来表达:

    从结构上,这有点类似生产者消费者模式,即有一个或多个生产者将事件放入一个Queue中,而一个或多个消费者主动的从这个Queue中Poll事件来处理;而Reactor模式则并没有Queue来做缓冲,每当一个Event输入到Service Handler之后,该Service Handler会主动的根据不同的Event类型将其分发给对应的Request Handler来处理。

    更学术的,这篇文章(Reactor An Object Behavioral Pattern for Demultiplexing and Dispatching Handles for Synchronous Events)上说:“The Reactor design pattern handles service requests that are delivered concurrently to an application by one or more clients. Each service in an application may consistent of several methods and is represented by a separate event handler that is responsible for dispatching service-specific requests. Dispatching of event handlers is performed by an initiation dispatcher, which manages the registered event handlers. Demultiplexing of service requests is performed by a synchronous event demultiplexer. Also known as Dispatcher, Notifier”。这段描述和Wikipedia上的描述类似,有多个输入源,有多个不同的EventHandler(RequestHandler)来处理不同的请求,Initiation Dispatcher用于管理EventHander,EventHandler首先要注册到Initiation Dispatcher中,然后Initiation Dispatcher根据输入的Event分发给注册的EventHandler;然而Initiation Dispatcher并不监听Event的到来,这个工作交给Synchronous Event Demultiplexer来处理。

    Reactor模式结构

    在解决了什么是Reactor模式后,我们来看看Reactor模式是由什么模块构成。图是一种比较简洁形象的表现方式,因而先上一张图来表达各个模块的名称和他们之间的关系:

    Handle:即操作系统中的句柄,是对资源在操作系统层面上的一种抽象,它可以是打开的文件、一个连接(Socket)、Timer等。由于Reactor模式一般使用在网络编程中,因而这里一般指Socket Handle,即一个网络连接(Connection,在Java NIO中的Channel)。这个Channel注册到Synchronous Event Demultiplexer中,以监听Handle中发生的事件,对ServerSocketChannnel可以是CONNECT事件,对SocketChannel可以是READ、WRITE、CLOSE事件等。
    Synchronous Event Demultiplexer:阻塞等待一系列的Handle中的事件到来,如果阻塞等待返回,即表示在返回的Handle中可以不阻塞的执行返回的事件类型。这个模块一般使用操作系统的select来实现。在Java NIO中用Selector来封装,当Selector.select()返回时,可以调用Selector的selectedKeys()方法获取Set<SelectionKey>,一个SelectionKey表达一个有事件发生的Channel以及该Channel上的事件类型。上图的“Synchronous Event Demultiplexer ---notifies--> Handle”的流程如果是对的,那内部实现应该是select()方法在事件到来后会先设置Handle的状态,然后返回。不了解内部实现机制,因而保留原图。
    Initiation Dispatcher:用于管理Event Handler,即EventHandler的容器,用以注册、移除EventHandler等;另外,它还作为Reactor模式的入口调用Synchronous Event Demultiplexer的select方法以阻塞等待事件返回,当阻塞等待返回时,根据事件发生的Handle将其分发给对应的Event Handler处理,即回调EventHandler中的handle_event()方法。
    Event Handler:定义事件处理方法:handle_event(),以供InitiationDispatcher回调使用。
    Concrete Event Handler:事件EventHandler接口,实现特定事件处理逻辑。

    Reactor模式模块之间的交互

    简单描述一下Reactor各个模块之间的交互流程,先从序列图开始:

    1. 初始化InitiationDispatcher,并初始化一个Handle到EventHandler的Map。
    2. 注册EventHandler到InitiationDispatcher中,每个EventHandler包含对相应Handle的引用,从而建立Handle到EventHandler的映射(Map)。
    3. 调用InitiationDispatcher的handle_events()方法以启动Event Loop。在Event Loop中,调用select()方法(Synchronous Event Demultiplexer)阻塞等待Event发生。
    4. 当某个或某些Handle的Event发生后,select()方法返回,InitiationDispatcher根据返回的Handle找到注册的EventHandler,并回调该EventHandler的handle_events()方法。
    5. 在EventHandler的handle_events()方法中还可以向InitiationDispatcher中注册新的Eventhandler,比如对AcceptorEventHandler来,当有新的client连接时,它会产生新的EventHandler以处理新的连接,并注册到InitiationDispatcher中。

    Reactor模式实现

    Reactor An Object Behavioral Pattern for Demultiplexing and Dispatching Handles for Synchronous Events中,一直以Logging Server来分析Reactor模式,这个Logging Server的实现完全遵循这里对Reactor描述,因而放在这里以做参考。Logging Server中的Reactor模式实现分两个部分:Client连接到Logging Server和Client向Logging Server写Log。因而对它的描述分成这两个步骤。
    Client连接到Logging Server

    1. Logging Server注册LoggingAcceptor到InitiationDispatcher。
    2. Logging Server调用InitiationDispatcher的handle_events()方法启动。
    3. InitiationDispatcher内部调用select()方法(Synchronous Event Demultiplexer),阻塞等待Client连接。
    4. Client连接到Logging Server。
    5. InitiationDisptcher中的select()方法返回,并通知LoggingAcceptor有新的连接到来。 
    6. LoggingAcceptor调用accept方法accept这个新连接。
    7. LoggingAcceptor创建新的LoggingHandler。
    8. 新的LoggingHandler注册到InitiationDispatcher中(同时也注册到Synchonous Event Demultiplexer中),等待Client发起写log请求。
    Client向Logging Server写Log

    1. Client发送log到Logging server。
    2. InitiationDispatcher监测到相应的Handle中有事件发生,返回阻塞等待,根据返回的Handle找到LoggingHandler,并回调LoggingHandler中的handle_event()方法。
    3. LoggingHandler中的handle_event()方法中读取Handle中的log信息。
    4. 将接收到的log写入到日志文件、数据库等设备中。
    3.4步骤循环直到当前日志处理完成。
    5. 返回到InitiationDispatcher等待下一次日志写请求。

    Reactor An Object Behavioral Pattern for Demultiplexing and Dispatching Handles for Synchronous Events有对Reactor模式的C++的实现版本,多年不用C++,因而略过。 

    Java NIO对Reactor的实现

    在Java的NIO中,对Reactor模式有无缝的支持,即使用Selector类封装了操作系统提供的Synchronous Event Demultiplexer功能。这个Doug Lea已经在Scalable IO In Java中有非常深入的解释了,因而不再赘述,另外这篇文章对Doug Lea的Scalable IO In Java有一些简单解释,至少它的代码格式比Doug Lea的PPT要整洁一些。

    需要指出的是,不同这里使用InitiationDispatcher来管理EventHandler,在Doug Lea的版本中使用SelectionKey中的Attachment来存储对应的EventHandler,因而不需要注册EventHandler这个步骤,或者设置Attachment就是这里的注册。而且在这篇文章中,Doug Lea从单线程的Reactor、Acceptor、Handler实现这个模式出发;演化为将Handler中的处理逻辑多线程化,实现类似Proactor模式,此时所有的IO操作还是单线程的,因而再演化出一个Main Reactor来处理CONNECT事件(Acceptor),而多个Sub Reactor来处理READ、WRITE等事件(Handler),这些Sub Reactor可以分别再自己的线程中执行,从而IO操作也多线程化。这个最后一个模型正是Netty中使用的模型。并且在Reactor An Object Behavioral Pattern for Demultiplexing and Dispatching Handles for Synchronous Events的9.5 Determine the Number of Initiation Dispatchers in an Application中也有相应的描述。

    EventHandler接口定义

    对EventHandler的定义有两种设计思路:single-method设计和multi-method设计:
    A single-method interface:它将Event封装成一个Event Object,EventHandler只定义一个handle_event(Event event)方法。这种设计的好处是有利于扩展,可以后来方便的添加新的Event类型,然而在子类的实现中,需要判断不同的Event类型而再次扩展成 不同的处理方法,从这个角度上来说,它又不利于扩展。另外在Netty3的使用过程中,由于它不停的创建ChannelEvent类,因而会引起GC的不稳定。
    A multi-method interface:这种设计是将不同的Event类型在 EventHandler中定义相应的方法。这种设计就是Netty4中使用的策略,其中一个目的是避免ChannelEvent创建引起的GC不稳定, 另外一个好处是它可以避免在EventHandler实现时判断不同的Event类型而有不同的实现,然而这种设计会给扩展新的Event类型时带来非常 大的麻烦,因为它需要该接口。

    关于Netty4对Netty3的改进可以参考这里
    ChannelHandler with no event objectIn 3.x, every I/O operation created a ChannelEvent object. For each read / write, it additionally created a new ChannelBuffer. It simplified the internals of Netty quite a lot because it delegates resource management and buffer pooling to the JVM. However, it often was the root cause of GC pressure and uncertainty which are sometimes observed in a Netty-based application under high load.

    4.0 removes event object creation almost completely by replacing the event objects with strongly typed method invocations. 3.x had catch-all event handler methods such as handleUpstream() andhandleDownstream(), but this is not the case anymore. Every event type has its own handler method now:

    为什么使用Reactor模式

    归功与Netty和Java NIO对Reactor的宣传,本文慕名而学习的Reactor模式,因而已经默认Reactor具有非常优秀的性能,然而慕名归慕名,到这里,我还是要不得不问自己Reactor模式的好处在哪里?即为什么要使用这个Reactor模式?在Reactor An Object Behavioral Pattern for Demultiplexing and Dispatching Handles for Synchronous Events中是这么说的:
    Reactor Pattern优点

    Separation of concerns: The Reactor pattern decouples application-independent demultiplexing and dispatching mechanisms from application-specific hook method functionality. The application-independent mechanisms become reusable components that know how to demultiplex events and dispatch the appropriate hook methods defined byEvent Handlers. In contrast, the application-specific functionality in a hook method knows how to perform a particular type of service.

    Improve modularity, reusability, and configurability of event-driven applications: The pattern decouples application functionality into separate classes. For instance, there are two separate classes in the logging server: one for establishing connections and another for receiving and processing logging records. This decoupling enables the reuse of the connection establishment class for different types of connection-oriented services (such as file transfer, remote login, and video-on-demand). Therefore, modifying or extending the functionality of the logging server only affects the implementation of the logging handler class.

    Improves application portability: The Initiation Dispatcher’s interface can be reused independently of the OS system calls that perform event demultiplexing. These system calls detect and report the occurrence of one or more events that may occur simultaneously on multiple sources of events. Common sources of events may in- clude I/O handles, timers, and synchronization objects. On UNIX platforms, the event demultiplexing system calls are calledselect and poll [1]. In the Win32 API [16], the WaitForMultipleObjects system call performs event demultiplexing.

    Provides coarse-grained concurrency control: The Reactor pattern serializes the invocation of event handlers at the level of event demultiplexing and dispatching within a process or thread. Serialization at the Initiation Dispatcher level often eliminates the need for more complicated synchronization or locking within an application process.

    这些貌似是很多模式的共性:解耦、提升复用性、模块化、可移植性、事件驱动、细力度的并发控制等,因而并不能很好的说明什么,特别是它鼓吹的对性能的提升,这里并没有体现出来。当然在这篇文章的开头有描述过另一种直观的实现:Thread-Per-Connection,即传统的实现,提到了这个传统实现的以下问题:
    Thread Per Connection缺点

    Efficiency: Threading may lead to poor performance due to context switching, synchronization, and data movement [2];

    Programming simplicity: Threading may require complex concurrency control schemes;

    Portability: Threading is not available on all OS platforms. 对于性能,它其实就是第一点关于Efficiency的描述,即线程的切换、同步、数据的移动会引起性能问题。也就是说从性能的角度上,它最大的提升就是减少了性能的使用,即不需要每个Client对应一个线程。我的理解,其他业务逻辑处理很多时候也会用到相同的线程,IO读写操作相对CPU的操作还是要慢很多,即使Reactor机制中每次读写已经能保证非阻塞读写,这里可以减少一些线程的使用,但是这减少的线程使用对性能有那么大的影响吗?答案貌似是肯定的,这篇论文(SEDA: Staged Event-Driven Architecture - An Architecture for Well-Conditioned, Scalable Internet Service)对随着线程的增长带来性能降低做了一个统计:

    在这个统计中,每个线程从磁盘中读8KB数据,每个线程读同一个文件,因而数据本身是缓存在操作系统内部的,即减少IO的影响;所有线程是事先分配的,不会有线程启动的影响;所有任务在测试内部产生,因而不会有网络的影响。该统计数据运行环境:Linux 2.2.14,2GB内存,4-way 500MHz Pentium III。从图中可以看出,随着线程的增长,吞吐量在线程数为8个左右的时候开始线性下降,并且到64个以后而迅速下降,其相应事件也在线程达到256个后指数上升。即1+1<2,因为线程切换、同步、数据移动会有性能损失,线程数增加到一定数量时,这种性能影响效果会更加明显。

    对于这点,还可以参考C10K Problem,用以描述同时有10K个Client发起连接的问题,到2010年的时候已经出现10M Problem了。

    当然也有人说:Threads are expensive are no longer valid.在不久的将来可能又会发生不同的变化,或者这个变化正在、已经发生着?没有做过比较仔细的测试,因而不敢随便断言什么,然而本人观点,即使线程变的影响并没有以前那么大,使用Reactor模式,甚至时SEDA模式来减少线程的使用,再加上其他解耦、模块化、提升复用性等优点,还是值得使用的。

    Reactor模式的缺点

    Reactor模式的缺点貌似也是显而易见的:
    1. 相比传统的简单模型,Reactor增加了一定的复杂性,因而有一定的门槛,并且不易于调试。
    2. Reactor模式需要底层的Synchronous Event Demultiplexer支持,比如Java中的Selector支持,操作系统的select系统调用支持,如果要自己实现Synchronous Event Demultiplexer可能不会有那么高效。
    3. Reactor模式在IO读写数据时还是在同一个线程中实现的,即使使用多个Reactor机制的情况下,那些共享一个Reactor的Channel如果出现一个长时间的数据读写,会影响这个Reactor中其他Channel的相应时间,比如在大文件传输时,IO操作就会影响其他Client的相应时间,因而对这种操作,使用传统的Thread-Per-Connection或许是一个更好的选择,或则此时使用Proactor模式。

    参考

    Reactor Pattern WikiPedia
    Reactor An Object Behavioral Pattern for Demultiplexing and Dispatching Handles for Synchronous Events
    Scalable IO In Java
    C10K Problem WikiPedia

    posted @ 2015-09-08 12:28 paulwong 阅读(290) | 评论 (0)编辑 收藏

    Netty3架构解析

    前记

    很早以前就有读Netty源码的打算了,然而第一次尝试的时候从Netty4开始,一直抓不到核心的框架流程,后来因为其他事情忙着就放下了。这次趁着休假重新捡起这个硬骨头,因为Netty3现在还在被很多项目使用,因而这次决定先从Netty3入手,瞬间发现Netty3的代码比Netty4中规中矩的多,很多概念在代码本身中都有清晰的表达,所以半天就把整个框架的骨架搞清楚了。再读Netty4对Netty3的改进总结,回去读Netty4的源码,反而觉得轻松了,一种豁然开朗的感觉。

    记得去年读Jetty源码的时候,因为代码太庞大,并且自己的HTTP Server的了解太少,因而只能自底向上的一个一个模块的叠加,直到最后把所以的模块连接在一起而看清它的真正核心骨架。现在读源码,开始习惯先把骨架理清,然后延伸到不同的器官、血肉而看清整个人体。

    本文从Reactor模式在Netty3中的应用,引出Netty3的整体架构以及控制流程;然而除了Reactor模式,Netty3还在ChannelPipeline中使用了Intercepting Filter模式,这个模式也在Servlet的Filter中成功使用,因而本文还会从Intercepting Filter模式出发详细介绍ChannelPipeline的设计理念。本文假设读者已经对Netty有一定的了解,因而不会包含过多入门介绍,以及帮Netty做宣传的文字。

    Netty3中的Reactor模式

    Reactor模式在Netty中应用非常成功,因而它也是在Netty中受大肆宣传的模式,关于Reactor模式可以详细参考本人的另一篇文章《Reactor模式详解》,对Reactor模式的实现是Netty3的基本骨架,因而本小节会详细介绍Reactor模式如何应用Netty3中。

    如果读《Reactor模式详解》,我们知道Reactor模式由Handle、Synchronous Event Demultiplexer、Initiation Dispatcher、Event Handler、Concrete Event Handler构成,在Java的实现版本中,Channel对应Handle,Selector对应Synchronous Event Demultiplexer,并且Netty3还使用了两层Reactor:Main Reactor用于处理Client的连接请求,Sub Reactor用于处理和Client连接后的读写请求(关于这个概念还可以参考Doug Lea的这篇PPT:Scalable IO In Java)。所以我们先要解决Netty3中使用什么类实现所有的上述模块并把他们联系在一起的,以NIO实现方式为例:

    模式是一种抽象,但是在实现中,经常会因为语言特性、框架和性能需要而做一些改变,因而Netty3对Reactor模式的实现有一套自己的设计:

    1. ChannelEvent:Reactor是基于事件编程的,因而在Netty3中使用ChannelEvent抽象的表达Netty3内部可以产生的各种事件,所有这些事件对象在Channels帮助类中产生,并且由它将事件推入到ChannelPipeline中,ChannelPipeline构建ChannelHandler管道,ChannelEvent流经这个管道实现所有的业务逻辑处理。ChannelEvent对应的事件有:ChannelStateEvent表示Channel状态的变化事件,而如果当前Channel存在Parent Channel,则该事件还会传递到Parent Channel的ChannelPipeline中,如OPEN、BOUND、CONNECTED、INTEREST_OPS等,该事件可以在各种不同实现的Channel、ChannelSink中产生;MessageEvent表示从Socket中读取数据完成、需要向Socket写数据或ChannelHandler对当前Message解析(如Decoder、Encoder)后触发的事件,它由NioWorker、需要对Message做进一步处理的ChannelHandler产生;WriteCompletionEvent表示写完成而触发的事件,它由NioWorker产生;ExceptionEvent表示在处理过程中出现的Exception,它可以发生在各个构件中,如Channel、ChannelSink、NioWorker、ChannelHandler中;IdleStateEvent由IdleStateHandler触发,这也是一个ChannelEvent可以无缝扩展的例子。注:在Netty4后,已经没有ChannelEvent类,所有不同事件都用对应方法表达,这也意味这ChannelEvent不可扩展,Netty4采用在ChannelInboundHandler中加入userEventTriggered()方法来实现这种扩展,具体可以参考这里

    2. ChannelHandler:在Netty3中,ChannelHandler用于表示Reactor模式中的EventHandler。ChannelHandler只是一个标记接口,它有两个子接口:ChannelDownstreamHandler和ChannelUpstreamHandler,其中ChannelDownstreamHandler表示从用户应用程序流向Netty3内部直到向Socket写数据的管道,在Netty4中改名为ChannelOutboundHandler;ChannelUpstreamHandler表示数据从Socket进入Netty3内部向用户应用程序做数据处理的管道,在Netty4中改名为ChannelInboundHandler。

    3. ChannelPipeline:用于管理ChannelHandler的管道,每个Channel一个ChannelPipeline实例,可以运行过程中动态的向这个管道中添加、删除ChannelHandler(由于实现的限制,在最末端的ChannelHandler向后添加或删除ChannelHandler不一定在当前执行流程中起效,参考这里)。ChannelPipeline内部维护一个ChannelHandler的双向链表,它以Upstream(Inbound)方向为正向,Downstream(Outbound)方向为方向。ChannelPipeline采用Intercepting Filter模式实现,具体可以参考这里,这个模式的实现在后一节中还是详细介绍。

    4. NioSelector:Netty3使用NioSelector来存放Selector(Synchronous Event Demultiplexer),每个新产生的NIO Channel都向这个Selector注册自己以让这个Selector监听这个NIO Channel中发生的事件,当事件发生时,调用帮助类Channels中的方法生成ChannelEvent实例,将该事件发送到这个Netty Channel对应的ChannelPipeline中,而交给各级ChannelHandler处理。其中在向Selector注册NIO Channel时,Netty Channel实例以Attachment的形式传入,该Netty Channel在其内部的NIO Channel事件发生时,会以Attachment的形式存在于SelectionKey中,因而每个事件可以直接从这个Attachment中获取相关链的Netty Channel,并从Netty Channel中获取与之相关联的ChannelPipeline,这个实现和Doug Lea的Scalable IO In Java一模一样。另外Netty3还采用了Scalable IO In Java中相同的Main Reactor和Sub Reactor设计,其中NioSelector的两个实现:Boss即为Main Reactor,NioWorker为Sub Reactor。Boss用来处理新连接加入的事件,NioWorker用来处理各个连接对Socket的读写事件,其中Boss通过NioWorkerPool获取NioWorker实例,Netty3模式使用RoundRobin方式放回NioWorker实例。更形象一点的,可以通过Scalable IO In Java的这张图表达:


    若与Ractor模式对应,NioSelector中包含了Synchronous Event Demultiplexer,而ChannelPipeline中管理着所有EventHandler,因而NioSelector和ChannelPipeline共同构成了Initiation Dispatcher。

    5. ChannelSink:在ChannelHandler处理完成所有逻辑需要向客户端写响应数据时,一般会调用Netty Channel中的write方法,然而在这个write方法实现中,它不是直接向其内部的Socket写数据,而是交给Channels帮助类,内部创建DownstreamMessageEvent,反向从ChannelPipeline的管道中流过去,直到第一个ChannelHandler处理完毕,最后交给ChannelSink处理,以避免阻塞写而影响程序的吞吐量。ChannelSink将这个MessageEvent提交给Netty Channel中的writeBufferQueue,最后NioWorker会等到这个NIO Channel已经可以处理写事件时无阻塞的向这个NIO Channel写数据。这就是上图的send是从SubReactor直接出发的原因。

    6. Channel:Netty有自己的Channel抽象,它是一个资源的容器,包含了所有一个连接涉及到的所有资源的饮用,如封装NIO Channel、ChannelPipeline、Boss、NioWorkerPool等。另外它还提供了向内部NIO Channel写响应数据的接口write、连接/绑定到某个地址的connect/bind接口等,个人感觉虽然对Channel本身来说,因为它封装了NIO Channel,因而这些接口定义在这里是合理的,但是如果考虑到Netty的架构,它的Channel只是一个资源容器,有这个Channel实例就可以得到和它相关的基本所有资源,因而这种write、connect、bind动作不应该再由它负责,而是应该由其他类来负责,比如在Netty4中就在ChannelHandlerContext添加了write方法,虽然netty4并没有删除Channel中的write接口。

    Netty3中的Intercepting Filter模式

    如果说Reactor模式是Netty3的骨架,那么Intercepting Filter模式则是Netty的中枢。Reactor模式主要应用在Netty3的内部实现,它是Netty3具有良好性能的基础,而Intercepting Filter模式则是ChannelHandler组合实现一个应用程序逻辑的基础,只有很好的理解了这个模式才能使用好Netty,甚至能得心应手。

    关于Intercepting Filter模式的详细介绍可以参考这里,本节主要介绍Netty3中对Intercepting Filter模式的实现,其实就是DefaultChannelPipeline对Intercepting Filter模式的实现。在上文有提到Netty3的ChannelPipeline是ChannelHandler的容器,用于存储与管理ChannelHandler,同时它在Netty3中也起到桥梁的作用,即它是连接Netty3内部到所有ChannelHandler的桥梁。作为ChannelPipeline的实现者DefaultChannelPipeline,它使用一个ChannelHandler的双向链表来存储,以DefaultChannelPipelineContext作为节点:

    public interface ChannelHandlerContext {
        Channel getChannel();
        ChannelPipeline getPipeline();
        String getName();
        ChannelHandler getHandler();
        boolean canHandleUpstream();
        boolean canHandleDownstream();
        void sendUpstream(ChannelEvent e);
        void sendDownstream(ChannelEvent e);
        Object getAttachment();
        void setAttachment(Object attachment);
    }

    private final class DefaultChannelHandlerContext implements ChannelHandlerContext {
        volatile DefaultChannelHandlerContext next;
        volatile DefaultChannelHandlerContext prev;
        private final String name;
        private final ChannelHandler handler;
        private final boolean canHandleUpstream;
        private final boolean canHandleDownstream;
        private volatile Object attachment;
    ..
    }

    在DefaultChannelPipeline中,它存储了和当前ChannelPipeline相关联的Channel、ChannelSink以及ChannelHandler链表的head、tail,所有ChannelEvent通过sendUpstream、sendDownstream为入口流经整个链表:

    public class DefaultChannelPipeline implements ChannelPipeline {
        private volatile Channel channel;
        private volatile ChannelSink sink;
        private volatile DefaultChannelHandlerContext head;
        private volatile DefaultChannelHandlerContext tail;

        public void sendUpstream(ChannelEvent e) {
            DefaultChannelHandlerContext head = getActualUpstreamContext(this.head);
            if (head == null) {
                return;
            }
            sendUpstream(head, e);
        }

        void sendUpstream(DefaultChannelHandlerContext ctx, ChannelEvent e) {
            try {
                ((ChannelUpstreamHandler) ctx.getHandler()).handleUpstream(ctx, e);
            } catch (Throwable t) {
                notifyHandlerException(e, t);
            }
        }

        public void sendDownstream(ChannelEvent e) {
            DefaultChannelHandlerContext tail = getActualDownstreamContext(this.tail);
            if (tail == null) {
                try {
                    getSink().eventSunk(this, e);
                    return;
                } catch (Throwable t) {
                    notifyHandlerException(e, t);
                    return;
                }
            }
            sendDownstream(tail, e);
        }

        void sendDownstream(DefaultChannelHandlerContext ctx, ChannelEvent e) {
            if (e instanceof UpstreamMessageEvent) {
                throw new IllegalArgumentException("cannot send an upstream event to downstream");
            }
            try {
                ((ChannelDownstreamHandler) ctx.getHandler()).handleDownstream(ctx, e);
            } catch (Throwable t) {
                e.getFuture().setFailure(t);
                notifyHandlerException(e, t);
            }
        }

    对Upstream事件,向后找到所有实现了ChannelUpstreamHandler接口的ChannelHandler组成链(
    getActualUpstreamContext()),而对Downstream事件,向前找到所有实现了ChannelDownstreamHandler接口的ChannelHandler组成链(getActualDownstreamContext()):

        private DefaultChannelHandlerContext getActualUpstreamContext(DefaultChannelHandlerContext ctx) {
            if (ctx == null) {
                return null;
            }
            DefaultChannelHandlerContext realCtx = ctx;
            while (!realCtx.canHandleUpstream()) {
                realCtx = realCtx.next;
                if (realCtx == null) {
                    return null;
                }
            }
            return realCtx;
        }
        private DefaultChannelHandlerContext getActualDownstreamContext(DefaultChannelHandlerContext ctx) {
            if (ctx == null) {
                return null;
            }
            DefaultChannelHandlerContext realCtx = ctx;
            while (!realCtx.canHandleDownstream()) {
                realCtx = realCtx.prev;
                if (realCtx == null) {
                    return null;
                }
            }
            return realCtx;
        }

    在实际实现ChannelUpstreamHandler或ChannelDownstreamHandler时,调用 ChannelHandlerContext中的sendUpstream或sendDownstream方法将控制流程交给下一个 ChannelUpstreamHandler或下一个ChannelDownstreamHandler,或调用Channel中的write方法发送 响应消息。

    public class MyChannelUpstreamHandler implements ChannelUpstreamHandler {
        public void handleUpstream(ChannelHandlerContext ctx, ChannelEvent e) throws Exception {
            // handle current logic, use Channel to write response if needed.
            
    // ctx.getChannel().write(message);
            ctx.sendUpstream(e);
        }
    }

    public class MyChannelDownstreamHandler implements ChannelDownstreamHandler {
        public void handleDownstream(
                ChannelHandlerContext ctx, ChannelEvent e) throws Exception {
            // handle current logic
            ctx.sendDownstream(e);
        }
    }

    当ChannelHandler向ChannelPipelineContext发送事件时,其内部从当前ChannelPipelineContext节点出发找到下一个ChannelUpstreamHandler或ChannelDownstreamHandler实例,并向其发送ChannelEvent,对于Downstream链,如果到达链尾,则将ChannelEvent发送给ChannelSink:

    public void sendDownstream(ChannelEvent e) {
        DefaultChannelHandlerContext prev = getActualDownstreamContext(this.prev);
        if (prev == null) {
            try {
                getSink().eventSunk(DefaultChannelPipeline.this, e);
            } catch (Throwable t) {
                notifyHandlerException(e, t);
            }
        } else {
            DefaultChannelPipeline.this.sendDownstream(prev, e);
        }
    }

    public void sendUpstream(ChannelEvent e) {
        DefaultChannelHandlerContext next = getActualUpstreamContext(this.next);
        if (next != null) {
            DefaultChannelPipeline.this.sendUpstream(next, e);
        }
    }

    正是因为这个实现,如果在一个末尾的ChannelUpstreamHandler中先移除自己,在向末尾添加一个新的ChannelUpstreamHandler,它是无效的,因为它的next已经在调用前就固定设置为null了。


    ChannelPipeline作为ChannelHandler的容器,它还提供了各种增、删、改ChannelHandler链表中的方法,而且如果某个ChannelHandler还实现了LifeCycleAwareChannelHandler,则该ChannelHandler在被添加进ChannelPipeline或从中删除时都会得到同志:

    public interface LifeCycleAwareChannelHandler extends ChannelHandler {
        void beforeAdd(ChannelHandlerContext ctx) throws Exception;
        void afterAdd(ChannelHandlerContext ctx) throws Exception;
        void beforeRemove(ChannelHandlerContext ctx) throws Exception;
        void afterRemove(ChannelHandlerContext ctx) throws Exception;
    }

    public interface ChannelPipeline {
        void addFirst(String name, ChannelHandler handler);
        void addLast(String name, ChannelHandler handler);
        void addBefore(String baseName, String name, ChannelHandler handler);
        void addAfter(String baseName, String name, ChannelHandler handler);
        void remove(ChannelHandler handler);
        ChannelHandler remove(String name);
        <T extends ChannelHandler> T remove(Class<T> handlerType);
        ChannelHandler removeFirst();
        ChannelHandler removeLast();
        void replace(ChannelHandler oldHandler, String newName, ChannelHandler newHandler);
        ChannelHandler replace(String oldName, String newName, ChannelHandler newHandler);
        <T extends ChannelHandler> T replace(Class<T> oldHandlerType, String newName, ChannelHandler newHandler);
        ChannelHandler getFirst();
        ChannelHandler getLast();
        ChannelHandler get(String name);
        <T extends ChannelHandler> T get(Class<T> handlerType);
        ChannelHandlerContext getContext(ChannelHandler handler);
        ChannelHandlerContext getContext(String name);
        ChannelHandlerContext getContext(Class<? extends ChannelHandler> handlerType);
        void sendUpstream(ChannelEvent e);
        void sendDownstream(ChannelEvent e);
        ChannelFuture execute(Runnable task);
        Channel getChannel();
        ChannelSink getSink();
        void attach(Channel channel, ChannelSink sink);
        boolean isAttached();
        List<String> getNames();
        Map<String, ChannelHandler> toMap();
    }

    在DefaultChannelPipeline的ChannelHandler链条的处理流程为:


    http://www.blogjava.net/DLevin/archive/2015/09/04/427031.html


    参考:

    《Netty主页》
    《Netty源码解读(四)Netty与Reactor模式》
    《Netty代码分析》
    Scalable IO In Java
    Intercepting Filter Pattern

    posted @ 2015-09-08 11:11 paulwong 阅读(262) | 评论 (0)编辑 收藏

    最新版BOOTSTRAP 4.0教学


    http://wiki.jikexueyuan.com/project/bootstrap4/

    posted @ 2015-09-02 10:56 paulwong 阅读(240) | 评论 (0)编辑 收藏

    张左峰的歪理邪说 之 Redmine 1.4.X 史上最全插件方案

    原创作品,允许转载,转载时请务必以超链接形式标明文章 原始出处 、作者信息和本声明。否则将追究法律责任。http://salivaxiu.blog.51cto.com/330680/1613510

    前面有一个0.9.X的插件推荐列表,但是太老了,更新一下!

     

    PS.很多插件是我自己汉化,甚至付费的,并且进行小幅修改,所以仅供参考。。。。。

     

    PPS.话说,搞Redmine这帮人,真是一群疯子,更新太快了。。。。。就不敢更新慢点么。。。。。。

     

    Advanced roadmap & milestones plugin  0.7.0  高级路线图,里程碑,不解释
    Author box  0.0.3  这个可以在Wiki侧边栏显示一个你的头像和信息,搞个人崇拜用的
    CRM plugin 2.3.3-pro CRM插件,很好用,也很专业,付费的
    Due Date Reminder plugin  0.2.1 超期提醒插件
    Issue Hot Buttons Plugin  0.4.5 超级有用的插件,快速自定义功能按钮,很方便更新问题,尤其是一两项的时候
    Redmine Add Subversion Links  0.0.5 为版本库增加直接的SVN链接
    Redmine Assets plugin  0.0.1 软资产管理,各位亲们,如果你有几万个问题,里卖包含图片文档啥的,你要找一个特痛苦吧?这个插件帮你解决
    Redmine Banner plugin 0.0.6 公告。。。超级实用。。。可以针对全局,也可以针对项目,发出公告
    Redmine Better Gantt Chart plugin 0.6.5 更好的甘特图。。的确更好
    Redmine CKEditor plugin 0.0.6 超级棒的Textile插件,替换Redmine那个简单的文本编辑器
    Redmine Code Review plugin 0.4.8 代码评审,不解释
    Redmine Default Version plugin 0.0.2 默认版本,给新建问题设置一个默认版本
    Digest plugin 0.2.0 一个后台发送项目活动信息的插件,做日报,或者什么汇报用的DMSF 1.2.3 网页版的SVN,文档管家,支持HTML5,超级好用,但是界面稍显臃肿
    Redmine Doodles plugin 0.5.1 投票,不解释
    Redmine Glossary Plugin 0.7.0 名词解释插件,知识管理一部分
    Redmine Good Job plugin 0.1.1 Goodjob....耍帅用的
    Issue Importer 1.0 导入插件,超级实用,如果你有多个工作系统,切换来切换去,离不开这玩意,但是不建议新手使用,批量出错,特痛苦。
    Redmine Information Plugin 0.2.5 这个也挺有用的,把系统的一些信息开放出来,比如宏,让大家参考
    Redmine Attach Screenshot plugin 0.4.2 附件截图,好似用了Java
    Redmine Issue Checklist plugin 1.0.3 Checklist,这个还解释么
    Redmine Issue Extensions plugin 0.1.0 问题扩展插件,官方都用的,必须用啊
    Redmine Issue Templates plugin 0.0.2.1 这是一个比较好用的插件,问题模板,尤其是一些重复性高,但是需要对过程管理的,配合
    ChecklistKnowledgebase 1.0.0 知识库。。。我觉得也很实用的,不过有个BUG,需要你在数据库指定关联一下项目
    List duplicate views plugin 0.0.5 好似可以检测到插件冲突。。。我就遇到过
    Redmine Local Avatars plugin 0.1.1 本地头像,哈哈,我们断网的
    Redmine Logs plugin 0.0.3 可以再后台直接看日志,不用登陆到服务器了
    Redmine (Monitoring & Controlling | Monitoramento & Controle) 0.1.1 图形化的数据分析插件,装B用的(当然也有实际意义,宏观数据)
    My Roadmaps plugin 0.1.12 我的路线图。。。。其实没啥用
    Redmine News Balloon plugin 0.0.1 如果有新闻,会弹出一个气泡,提醒你
    Niko-niko Calendar plugin 1.1.2 我最最最最喜欢的插件,感觉跟每天微博一样,挺有意思的
    Redmine plugin views revisions plugin 0.0.1 忘了。。。。。
    Preview attached files and attributes column plugin 0.1.7 附件的那个缩略图
    Private Wiki 0.1.1 私有维基,Redmine最大的问题,在于权限管理不够细分,多这么一个插件,就相当增加一项特殊权限
    Reorder links arbitrary 0.0.7 这个对管理员设置有帮助,可以快速设置排序
    Smart issues sort plugin 0.3.1 智能排序,对经常用父任务的人,帮助很大
    My Page Blocks plugin 1.2 (20120610) 自定义我的工作台,很好使!
    Redmine Wiki Extensions plugin 0.4.1 维基扩展,不解释,官方都用
    Wiki sidebar toc plugin 0.0.1 维基侧边栏吧?想不起来了
    Redmine Wiki table of contents plugin 0.0.3 维基快速位置排序
    Issues XLS export 0.2.1  问题列表XLS导出

     

    我还没用的,但是考虑装上试试的列表,都是1.4.X可以用的

     

    用户属性 http://www.redmine.org/plugins/userprofile
    会议室预定 http://www.redmine.org/plugins/mmqb
    费用、分票 http://www.redmine.org/plugins/invoices       需付费,可以考虑
    免费发票 http://www.redmine.org/plugins/haltr
    我的技能 http://www.redmine.org/plugins/redmine_coderwall
    甘特图日期 http://www.redmine.org/plugins/redmine_gantt_with_date
    登陆后跳转 http://www.redmine.org/plugins/landing_page
    Wiki加密 http://www.redmine.org/plugins/redmine_wikicipher     可以考虑
    Email过滤 http://www.redmine.org/plugins/redmine_email_notification_content_filter  可以考虑
    另一个截图 http://www.redmine.org/plugins/javasript_screenshot
    项目侧边栏 http://www.redmine.org/plugins/sidebar       可以考虑
    匿名观察 http://www.redmine.org/plugins/anonymous-watchers     可以考虑
    你的意思 http://www.redmine.org/plugins/didyoumean      可以考虑
    隐身模式 http://www.redmine.org/plugins/redmine_stealth      可以考虑
    发行说明 http://www.redmine.org/plugins/redmine_release_notes

    论坛主题 http://www.redmine.org/plugins/redmine_boards
    自定义邮件 http://www.redmine.org/plugins/notify_custom_users
    日历假期 http://www.redmine.org/plugins/redmine_multi_calendar
    多种上传 http://www.redmine.org/plugins/redmine_multiple_files_upload

    Wiki
    维基按钮 http://www.redmine.org/plugins/redmine_wiki_files_toolbar

    Time
    时间联系 http://www.redmine.org/plugins/linked_time_entries

    版本库
    SCM扩展  http://www.redmine.org/plugins/redmine_scm_extensions
    编辑维基 http://www.redmine.org/plugins/redmine_require_wiki_comment

    posted @ 2015-08-19 10:26 paulwong 阅读(883) | 评论 (0)编辑 收藏

    20 个有用的 Angular.js 工具

    喜欢 Angular.js?我们为开发者编写了一份最佳 angular.js 工具和资源清单,这可让使用 angular 开发应用程序变得高效。

    对于大多数想要设计动态 web 应用的开发者而言,Angular.js 成为了一个可以选择的框架。angularjs 开发者如果想开始一个 AngularJS 工程,为了采取成熟的方式开发网页,他们或许需要很多工具。

    在开始使用 angular.js 之前,Angular.js 新手或许也想读一些优秀的 angular.js 书籍。

    我们同样也编写了一份庞大的在线 angular.js 教程清单。

    为了减轻使用 AngularJS 开发 web 应用的负担,这里列出了几个出色的工具,包括测试、前端开发、编辑、函数库、扩展、模块、代码生成器、网格工具。

    shirleywong
    shirleywong
    翻译于 1周前

    0人顶

     翻译的不错哦!

    Angular.js 开发最佳 IDE

    Angular.js 需要的大部分集成开发环境(IDE)和轻量级的编辑器列在了下面。

    Webstorm

    Webstorm是一个出色的代码编辑器,它完全理解工程,可以为任何类型的网站提供高质量的代码。它支持所有最流行最新的网站开发技术。使用这个工具开发网站,可以很好地集成单点或流程。 

    Aptana

    Aptana 是一具集成开发环境,可以帮助你优雅地创建网站应用。使用它做为 AngularJS 的集成开发工具,你需要在 Eclipse 商店激活 AngularJS Eclipse 扩展。

    wancheng
    wancheng
    翻译于 1周前

    0人顶

     翻译的不错哦!

    文本编辑器 Sublime

    对 AngularJS Web 开发者来说,方便的文本编辑工具是 Sublime。它帮助程序员使用快捷方式或几个按键实现编码。它具有很强的适应性,可以定制任何类型的编程环境。它也可以按照你的意愿分块编辑。它还可以轻松地在项目之间切换,所有的修改都将自动保存在各自的项目中。

    Angular.js 的专用测试工具

    测试是开发的重要组成部分,无论对于使用 Angular.js 还是任何其他软件都是如此。下面的工具可以帮助你简化采用 Angular.js 开发的应用程序的测试。

    这些工具都是在线 JavaScript 测试工具的好伴侣。

    Protractor

    Protractor 是一个端到端的测试框架,贯穿于 AngularJS,是一个完全自动化的测试工具。它可以运行在真实的浏览器中测试你的应用程序。它使用了 WebDriver,Mocha, jasmine, Node.js, selenium 和cucumber 等都使用的伟大的技术。

    当所有的待处理网页任务完成时,它会自动使用AngularJS的应用进行通信。所以,你在测试时不需要使用等待或睡眠命令。

    Iam魔方
    Iam魔方
    翻译于 1周前

    0人顶

     翻译的不错哦!

    Jasmine

    Jasmine 是一个行为驱动开发框架,专为 Javascript 用户创建。它提供了基本的测试框架,并且可以持续维护。所有测试都可以使用一个 all-in-one 的包完成,这是 Jasmine 的主要特点,高效测试你的应用。

    这个框架的一个缺点是它不能感知运行平台(浏览器)。如果配合Karma使用这个问题很容易避免。

    Karma 可以做为测试运行者配合 Jasmine 使用。它是一个测试框架帮且你高效地测试应用。 

    Code Orchestra

    它是一个绝对意义上的前端开发工具帮助你创建和测试网站应用。你可以实时写代码,根据建议修改代码,以同样的格式保存代码。通过这个工具修改后的代码会自动布署到运行中的应用。

    wancheng
    wancheng
    翻译于 1周前

    0人顶

     翻译的不错哦!

    最好的 Angular.js 函数库

    下面是一些有用的库,它们可以增强 angular.js 框架的能力,对开发者有所帮助。没有必要从头构建那些可能已经成为开放源码的函数库。

    CodePen

    对于所有 HTML,CSS 和 JavaScript 的前端开发者,CodePen 是一款完美的编辑工具。这个工具可以最大限度地减少对网站的创建、测试和完善的繁琐的网页开发工作。它是一个协作的在线编程环境。

    Web 开发人员可以清晰地跨平台实时查看。它有一个浏览器中的代码编辑器,可以自动地迅速地上传多个文件。这个功能可协助 Web 开发人员在几秒的时间内创建一个新的代码。

    Angular Fire

    使用 Angular Fire,可以轻松地帮助你开发 AngularJS 的应用后台。AngularJS 绑定的 Firebase 已经正式被 Angular Fire 支持。Firebase 是一个基于云计算的平台,可以很容易地集成实时应用和快速创建后台。

    当 Firebase 和 Angular Fire 组合在一起,它们有助于以更快的速度同步数据和提供良好的用户管理服务。它还提供了一个三向的数据绑定、用户身份验证和静态托管。

    Iam魔方
    Iam魔方
    翻译于 7天前

    0人顶

     翻译的不错哦!

    AngularUI

    AngularJS 以高效率创建单页面应用而出名. 创建这些单页面应用时候,我们需要一个灵活的路由,这个优秀的AngularJS框架是构建一个全面的UI组件俗称ui-router。 它能根据应用程序的状态提供一个简单的导航和改变视图,而不仅仅是基于URL。
    AngularUI还包含非常多的UI组件,这些组件是使用原生指令像ui—maps,ui-calendar,ui-Bootstrap创建的。这些UI组件和指令可以更快建设Angular网站

    UI Bootstrap

    UI Bootstrap是一个不同寻常的AngularUI组件,它能帮助你创建基于智能手机的web应用程序,而且用户体验不错。这个UI组件提供的AngularJS原生指令完全兼容Twitte Bootstrap

    成熟的毛毛虫
    成熟的毛毛虫
    翻译于 5天前

    1人顶

     翻译的不错哦!

    Angular.js 有用的扩展和工具

    下面是一些 Angular.js 扩展,可以满足一些特殊应用之需。

    Ng-Inspector

    Ng-Inspector 是一个优秀的浏览器插件,支持 Firefox,Chrome 和 Safari,复用它可以创建一个探测控制面板,方便开发,调试 AngularJS 应用,它提供了完整的辅助功能。

    使用它可以更方便的和你的应用交互,还可以实时更新。它还可以看到全部范围内的层次结构,模型,类型和值。点击你关注的一个范围,它会高亮显示相应的 DOM 结点。

    AngularJS Batarang

    你可以使用 AngularJS Batarang 来调试你的 AngularJ S应用,它是一个专为 Chrome 提供的插件。它帮助你改善应用性能。还可能衡量调节性能的进度。

    wancheng
    wancheng
    翻译于 4天前

    0人顶

     翻译的不错哦!

    Restangular

    AngularJS 独有的一个服务是 Restangular,它可以帮助您轻松应对各种要求,例如获取、发送、删除以及把数据存入数据库。它对于所有从 RESTful API 中大规模存取数据的 AngularJS 应用都很有必要。

    Generator Angular - 一个有用的工具

    Yeomen Generator

    你可以很容易地开始一个具有合理的默认值和最好的用例的项目。建立这样的 Angular 应用,这款 Yeomen generator 工具是非常有用的。它只需几条终端的命令,便加速了 AngularJS 应用的开发过程。这个工具是非常有用的。这些专用的生成工具将有助于应用了解项目的有关信息,并有助于开发和测试应用程序。

    Iam魔方
    Iam魔方
    翻译于 3天前

    0人顶

     翻译的不错哦!

    Angular Deckgrid

    Angular Deckgrid 可以为你提供响应度和颜值俱高的应用,可以适配不同的移动终端。轻量级类砖石结构易于创建灵活的表格,高效创建图片展示。 

    Radian

    Radian 是一个优秀的框架,使用它只需要少量的设置就可以开启 AngularJS 项目。在多人开发项目中它是一个理想的选择。

    Lumx

    Lumx 以快速简单的方式帮助你创建简单而优雅的应用。 这个可响应式前端框架是基于AngularJS 和Google 材料设计规范。这个工具可嵌入最新的技术,如 Sass 预处理器,AngularJS 和 JQuery,能极大地提高 web 应用的性能。

    wancheng
    wancheng
    翻译于 1天前

    0人顶

     翻译的不错哦!

    Angular Gettext

    你可以用英语编码,在编码需要被翻译的地方加上注解。Angular Gettext 工具就会自动翻译那些独立的部分。这是 AngularJS 非常简单而强大的翻译支持工具。

    NgDocs

    AngularJS 框架内置 ngDocs 工具可以简化你项目文档和参考手册的相关工作。这款基于 Android 的工具也能提供给所有新手一些容易跟进的教程。

    叶秀兰
    叶秀兰
    翻译于 18小时前

    0人顶

     翻译的不错哦!

    NgTables

    无论是简单还是复杂的 Web 应用,在 AngularJS 框架中很容易创建一个表格,然后通过实用的 ngTables 工具进行高效的管理。ngTable 是 AngularJS 表格指令,支持排序,过滤和分页,在编译步骤中自动生成带有标题和过滤器的标题行。

    ngTable 支持定制过滤选项,表格分组,表格外部数据控制 等等功能。

    总的来说,这些都是创建任意 AngularJS Web 应用的,最有用的工具集合。用好这些工具可以帮助你轻松高效的创建 AngularJS 项目。

    posted @ 2015-08-12 13:32 paulwong 阅读(257) | 评论 (0)编辑 收藏

    排版六原则

    作者: 阮一峰

    日期: 2010年10月16日

    上个月,我贴了《图形化简历》

    几天后,就收到了秋叶老师的来信,希望与我探讨一些设计问题。他写过一本畅销书《说服力-让你的PPT会说话》,眼下正在写续集。

    我看了新书的样章,觉得很不错,有些内容很值得分享。

    ====================================

    首先,我们先看一个例子。良好的设计如何使得一个平庸的文档脱胎换骨。下面是一张大学生的求职简历,再普通不过了,想要引起招聘经理的注意,恐怕很难。

    秋叶老师对它进行了简单的排版,还是一张表格,还是黑白配色,没有使用任何图形元素,效果却完全不一样了。

    真是令人眼前一亮,不由自主地想多看几眼。这就是优秀设计的作用:它让你脱颖而出。

    ====================================

    秋叶老师把他的排版心得,总结为六个原则:对齐,聚拢,重复,对比,强调,留白。我是这样理解的:

    一、对齐原则

      相关内容必须对齐,次级标题必须缩进,方便读者视线快速移动,一眼看到最重要的信息。

    二、聚拢原则

      将内容分成几个区域,相关内容都聚在一个区域中。段间距应该大于段内的行距。

    三、留白原则

      千万不要把页面排得密密麻麻,要留出一定的空白,这本身就是对页面的分隔。这样既减少了页面的压迫感,又可以引导读者视线,突出重点内容。

    四、降噪原则

      颜色过多、字数过多、图形过繁,都是分散读者注意力的"噪音"。

    五、重复原则

      多页面排版时,注意各个页面设计上的一致性和连贯性。另外,在内容上,重要信息值得重复出现。

    六、对比原则

      加大不同元素的视觉差异。这样既增加了页面的活泼,又方便读者集中注意力阅读某一个子区域。

    ====================================

    下面用一个PPT的例子,演示排版六原则。

    上面这张ppt有两个毛病。一是字数太多,抓不住重点;二是右边没有对齐,使得读者的视线只能一行行地从行首到行尾移动,不能直上直下。

    现在进行修改。

    第一步,根据"聚拢原则",将六点分成六个区域。

    第二步,根据"降噪原则",将每一点分成"小标题"和"说明文字"两部分。

    第三步,根据"对齐原则",将每一个部分、每一种元素对齐。

    第四步,根据"对比原则",加大"小标题"和"说明文字"在字体和颜色上的差异。

    第五步,根据"留白原则",留出一定的空白。

    页面的可读性大大增加。

    (完)

    posted @ 2015-08-07 15:49 paulwong 阅读(468) | 评论 (0)编辑 收藏

    关于颜色理论

    作者: 阮一峰

    日期: 2008年7月21日

    制作网页的过程中,我一直不知道应该如何配色。

    我的意思是,我不知道应该选择哪些颜色放在一起,完全凭感觉。于是昨天,我在网上找了一些资料,希望找到理论指导。

    结果很失望。颜色理论研究的都是颜色的本质,至于颜色搭配,最终靠的还是个人感觉。说到底,Choosing colors is art, not science。不过,我还是记录一下吧,其中一些东西还是很有趣的。

    =================

    1. Color Wheel

    所谓Color Wheel,就是将一系列颜色,有次序地通过一个圆盘的形式,展现出来。

    它的产生方式是,首先列出三原色(PRIMARY COLORS):红、黄、蓝。

    Photobucket

    然后,二二混合,产生二级颜色(SECONDARY COLORS):绿、橙、紫。

    接着,继续二二混合,又产生6种三级颜色(TERTIARY COLORS):黄橙、红橙、红紫、蓝紫、黄绿、蓝紫。

    通过不断混合相邻颜色,产生新的颜色,最终形成一个全域的Color Wheel。

    2. 类似色和互补色

    12色的Color Wheel上任意三个相邻的颜色,被称为类似色(analogous colors)。通常认为,它们放在一起会很和谐。

    Color Wheel对角线上的两种颜色,被称为互补色(complementary colors)。通常认为,它们放在一起,会形成对比效果。

    此外,如果要寻找三种互相平衡的颜色,可以选择12色的Color Wheel上任意三个三角对立的颜色(Triad)。

    如果要寻找三种颜色,其中二种互相类似,另一种与它们形成对比,则可以选取互补色两侧相邻的颜色。(split-complementary colors

    3. 颜色模型

    常用的颜色模型有三种,分别是RGB、CMYK、HSV模型。

    4. RGB模型

    RGB是Red、Green和Blue的缩写,任意颜色都可以由红、绿、蓝这三种颜色不同比例混合后产生。这个模型主要用于电子显示屏的颜色显示。

    RGB模型通常用三个十六进制数来表示颜色,FFFFFF代表100%的红色、100%的绿色和100%蓝色混合,产生白色;000000代表0%的红色、0%的绿色和0%蓝色混合,产生黑色。

    5. HSV模型

    H指的是Hue(色调),它是"颜色"的同义词。

    S指的是Saturation(饱和度),它指的是颜色的纯度,即颜色中含有灰色(gray)的程度。饱和度越高,颜色越纯;饱和度越低,颜色中灰色成分越大。任何颜色,饱和度变成最小值时,都会变成灰色。

    V指的是Value,即颜色中白色的成分。这个值越大,颜色就越白越亮,这个值最小,颜色就越黑越暗。最大值时,所有颜色都变成白色,最小值时,所有颜色都变成黑色。

    HSV模型是通过调节这三个值来标识颜色。它通常是一个color wheel的形式,所有边缘的颜色都是饱和度最高的颜色,越向圆心饱和度越小。Hue通过角度值选取,另有一个亮度轴,来选取Value值。

    6.CMYK模型

    这个模型主要用于印刷业,就是指用cyan, magenta, yellow, black这四种颜料混合,产生其他各种颜色。

    印刷品上的图案,仔细看其实都是由一个个小点构成,而每个小点又都是采用四色套印,重合叠加后产生各种颜色的效果。

    (完)

    posted @ 2015-08-07 15:47 paulwong 阅读(401) | 评论 (0)编辑 收藏

    RESTful API 设计指南

    作者: 阮一峰

    日期: 2014年5月22日

    网络应用程序,分为前端和后端两个部分。当前的发展趋势,就是前端设备层出不穷(手机、平板、桌面电脑、其他专用设备......)。

    因此,必须有一种统一的机制,方便不同的前端设备与后端进行通信。这导致API构架的流行,甚至出现"API First"的设计思想。RESTful API是目前比较成熟的一套互联网应用程序的API设计理论。我以前写过一篇《理解RESTful架构》,探讨如何理解这个概念。

    今天,我将介绍RESTful API的设计细节,探讨如何设计一套合理、好用的API。我的主要参考了两篇文章(12)。

    RESTful API

    一、协议

    API与用户的通信协议,总是使用HTTPs协议

    二、域名

    应该尽量将API部署在专用域名之下。

     https://api.example.com 

    如果确定API很简单,不会有进一步扩展,可以考虑放在主域名下。

     https://example.org/api/ 

    三、版本(Versioning)

    应该将API的版本号放入URL。

     https://api.example.com/v1/ 

    另一种做法是,将版本号放在HTTP头信息中,但不如放入URL方便和直观。Github采用这种做法。

    四、路径(Endpoint)

    路径又称"终点"(endpoint),表示API的具体网址。

    在RESTful架构中,每个网址代表一种资源(resource),所以网址中不能有动词,只能有名词,而且所用的名词往往与数据库的表格名对应。一般来说,数据库中的表都是同种记录的"集合"(collection),所以API中的名词也应该使用复数。

    举例来说,有一个API提供动物园(zoo)的信息,还包括各种动物和雇员的信息,则它的路径应该设计成下面这样。

    • https://api.example.com/v1/zoos
    • https://api.example.com/v1/animals
    • https://api.example.com/v1/employees

    五、HTTP动词

    对于资源的具体操作类型,由HTTP动词表示。

    常用的HTTP动词有下面五个(括号里是对应的SQL命令)。

    • GET(SELECT):从服务器取出资源(一项或多项)。
    • POST(CREATE):在服务器新建一个资源。
    • PUT(UPDATE):在服务器更新资源(客户端提供改变后的完整资源)。
    • PATCH(UPDATE):在服务器更新资源(客户端提供改变的属性)。
    • DELETE(DELETE):从服务器删除资源。

    还有两个不常用的HTTP动词。

    • HEAD:获取资源的元数据。
    • OPTIONS:获取信息,关于资源的哪些属性是客户端可以改变的。

    下面是一些例子。

    • GET /zoos:列出所有动物园
    • POST /zoos:新建一个动物园
    • GET /zoos/ID:获取某个指定动物园的信息
    • PUT /zoos/ID:更新某个指定动物园的信息(提供该动物园的全部信息)
    • PATCH /zoos/ID:更新某个指定动物园的信息(提供该动物园的部分信息)
    • DELETE /zoos/ID:删除某个动物园
    • GET /zoos/ID/animals:列出某个指定动物园的所有动物
    • DELETE /zoos/ID/animals/ID:删除某个指定动物园的指定动物

    六、过滤信息(Filtering)

    如果记录数量很多,服务器不可能都将它们返回给用户。API应该提供参数,过滤返回结果。

    下面是一些常见的参数。

    • ?limit=10:指定返回记录的数量
    • ?offset=10:指定返回记录的开始位置。
    • ?page=2&per_page=100:指定第几页,以及每页的记录数。
    • ?sortby=name&order=asc:指定返回结果按照哪个属性排序,以及排序顺序。
    • ?animal_type_id=1:指定筛选条件

    参数的设计允许存在冗余,即允许API路径和URL参数偶尔有重复。比如,GET /zoo/ID/animals 与 GET /animals?zoo_id=ID 的含义是相同的。

    七、状态码(Status Codes)

    服务器向用户返回的状态码和提示信息,常见的有以下一些(方括号中是该状态码对应的HTTP动词)。

    • 200 OK - [GET]:服务器成功返回用户请求的数据,该操作是幂等的(Idempotent)。
    • 201 CREATED - [POST/PUT/PATCH]:用户新建或修改数据成功。
    • 202 Accepted - [*]:表示一个请求已经进入后台排队(异步任务)
    • 204 NO CONTENT - [DELETE]:用户删除数据成功。
    • 400 INVALID REQUEST - [POST/PUT/PATCH]:用户发出的请求有错误,服务器没有进行新建或修改数据的操作,该操作是幂等的。
    • 401 Unauthorized - [*]:表示用户没有权限(令牌、用户名、密码错误)。
    • 403 Forbidden - [*] 表示用户得到授权(与401错误相对),但是访问是被禁止的。
    • 404 NOT FOUND - [*]:用户发出的请求针对的是不存在的记录,服务器没有进行操作,该操作是幂等的。
    • 406 Not Acceptable - [GET]:用户请求的格式不可得(比如用户请求JSON格式,但是只有XML格式)。
    • 410 Gone -[GET]:用户请求的资源被永久删除,且不会再得到的。
    • 422 Unprocesable entity - [POST/PUT/PATCH] 当创建一个对象时,发生一个验证错误。
    • 500 INTERNAL SERVER ERROR - [*]:服务器发生错误,用户将无法判断发出的请求是否成功。

    状态码的完全列表参见这里

    八、错误处理(Error handling)

    如果状态码是4xx,就应该向用户返回出错信息。一般来说,返回的信息中将error作为键名,出错信息作为键值即可。

     {     error: "Invalid API key" } 

    九、返回结果

    针对不同操作,服务器向用户返回的结果应该符合以下规范。

    • GET /collection:返回资源对象的列表(数组)
    • GET /collection/resource:返回单个资源对象
    • POST /collection:返回新生成的资源对象
    • PUT /collection/resource:返回完整的资源对象
    • PATCH /collection/resource:返回完整的资源对象
    • DELETE /collection/resource:返回一个空文档

    十、Hypermedia API

    RESTful API最好做到Hypermedia,即返回结果中提供链接,连向其他API方法,使得用户不查文档,也知道下一步应该做什么。

    比如,当用户向api.example.com的根目录发出请求,会得到这样一个文档。

     {"link": {   "rel":   "collection https://www.example.com/zoos",   "href":  "https://api.example.com/zoos",   "title": "List of zoos",   "type":  "application/vnd.yourformat+json" }} 

    上面代码表示,文档中有一个link属性,用户读取这个属性就知道下一步该调用什么API了。rel表示这个API与当前网址的关系(collection关系,并给出该collection的网址),href表示API的路径,title表示API的标题,type表示返回类型。

    Hypermedia API的设计被称为HATEOAS。Github的API就是这种设计,访问api.github.com会得到一个所有可用API的网址列表。

     {   "current_user_url": "https://api.github.com/user",   "authorizations_url": "https://api.github.com/authorizations",   // ... } 

    从上面可以看到,如果想获取当前用户的信息,应该去访问api.github.com/user,然后就得到了下面结果。

     {   "message": "Requires authentication",   "documentation_url": "https://developer.github.com/v3" } 

    上面代码表示,服务器给出了提示信息,以及文档的网址。

    十一、其他

    (1)API的身份认证应该使用OAuth 2.0框架。

    (2)服务器返回的数据格式,应该尽量使用JSON,避免使用XML。

    (完)

    posted @ 2015-08-07 14:13 paulwong 阅读(365) | 评论 (0)编辑 收藏

    理解OAuth 2.0

         摘要: 作者: 阮一峰日期: 2014年5月12日OAuth是一个关于授权(authorization)的开放网络标准,在全世界得到广泛应用,目前的版本是2.0版。本文对OAuth 2.0的设计思路和运行流程,做一个简明通俗的解释,主要参考材料为RFC 6749。一、应用场景为了理解OAuth的适用场合,让我举一个假设的例子。有一个"云冲印"的网站,可以将用户储存在Google的照片,...  阅读全文

    posted @ 2015-08-07 14:12 paulwong 阅读(248) | 评论 (0)编辑 收藏

    XMLHttpRequest Level 2 使用指南

    作者: 阮一峰

    日期: 2012年9月 8日

    XMLHttpRequest是一个浏览器接口,使得Javascript可以进行HTTP(S)通信。

    最早,微软在IE 5引进了这个接口。因为它太有用,其他浏览器也模仿部署了,ajax操作因此得以诞生。

    但是,这个接口一直没有标准化,每家浏览器的实现或多或少有点不同。HTML 5的概念形成后,W3C开始考虑标准化这个接口。2008年2月,就提出了XMLHttpRequest Level 2 草案。

    这个XMLHttpRequest的新版本,提出了很多有用的新功能,将大大推动互联网革新。本文就对这个新版本进行详细介绍。

    一、老版本的XMLHttpRequest对象

    在介绍新版本之前,我们先回顾一下老版本的用法。

    首先,新建一个XMLHttpRequest的实例。

      var xhr = new XMLHttpRequest();

    然后,向远程主机发出一个HTTP请求。

      xhr.open('GET', 'example.php');

      xhr.send();

    接着,就等待远程主机做出回应。这时需要监控XMLHttpRequest对象的状态变化,指定回调函数。

      xhr.onreadystatechange = function(){

        if ( xhr.readyState == 4 && xhr.status == 200 ) {

          alert( xhr.responseText );

        } else {

          alert( xhr.statusText );

        }

      };

    上面的代码包含了老版本XMLHttpRequest对象的主要属性:

      * xhr.readyState:XMLHttpRequest对象的状态,等于4表示数据已经接收完毕。

      * xhr.status:服务器返回的状态码,等于200表示一切正常。

      * xhr.responseText:服务器返回的文本数据

      * xhr.responseXML:服务器返回的XML格式的数据

      * xhr.statusText:服务器返回的状态文本。

    二、老版本的缺点

    老版本的XMLHttpRequest对象有以下几个缺点:

      * 只支持文本数据的传送,无法用来读取和上传二进制文件。

      * 传送和接收数据时,没有进度信息,只能提示有没有完成。

      * 受到"同域限制"(Same Origin Policy),只能向同一域名的服务器请求数据。

    三、新版本的功能

    新版本的XMLHttpRequest对象,针对老版本的缺点,做出了大幅改进。

      * 可以设置HTTP请求的时限。

      * 可以使用FormData对象管理表单数据。

      * 可以上传文件。

      * 可以请求不同域名下的数据(跨域请求)。

      * 可以获取服务器端的二进制数据。

      * 可以获得数据传输的进度信息。

    下面,我就一一介绍这些新功能。

    四、HTTP请求的时限

    有时,ajax操作很耗时,而且无法预知要花多少时间。如果网速很慢,用户可能要等很久。

    新版本的XMLHttpRequest对象,增加了timeout属性,可以设置HTTP请求的时限。

      xhr.timeout = 3000;

    上面的语句,将最长等待时间设为3000毫秒。过了这个时限,就自动停止HTTP请求。与之配套的还有一个timeout事件,用来指定回调函数。

      xhr.ontimeout = function(event){

        alert('请求超时!');

      }

    目前,Opera、Firefox和IE 10支持该属性,IE 8和IE 9的这个属性属于XDomainRequest对象,而Chrome和Safari还不支持。

    五、FormData对象

    ajax操作往往用来传递表单数据。为了方便表单处理,HTML 5新增了一个FormData对象,可以模拟表单。

    首先,新建一个FormData对象。

      var formData = new FormData();

    然后,为它添加表单项。

      formData.append('username', '张三');

      formData.append('id', 123456);

    最后,直接传送这个FormData对象。这与提交网页表单的效果,完全一样。

      xhr.send(formData);

    FormData对象也可以用来获取网页表单的值。

      var form = document.getElementById('myform');

      var formData = new FormData(form);

      formData.append('secret', '123456'); // 添加一个表单项

      xhr.open('POST', form.action);

      xhr.send(formData);

    六、上传文件

    新版XMLHttpRequest对象,不仅可以发送文本信息,还可以上传文件。

    假定files是一个"选择文件"的表单元素(input[type="file"]),我们将它装入FormData对象。

      var formData = new FormData();

      for (var i = 0; i < files.length;i++) {

        formData.append('files[]', files[i]);

      }

    然后,发送这个FormData对象。

      xhr.send(formData);

    七、跨域资源共享(CORS)

    新版本的XMLHttpRequest对象,可以向不同域名的服务器发出HTTP请求。这叫做"跨域资源共享"(Cross-origin resource sharing,简称CORS)。

    使用"跨域资源共享"的前提,是浏览器必须支持这个功能,而且服务器端必须同意这种"跨域"。如果能够满足上面的条件,则代码的写法与不跨域的请求完全一样。

      xhr.open('GET', 'http://other.server/and/path/to/script');

    目前,除了IE 8和IE 9,主流浏览器都支持CORS,IE 10也将支持这个功能。服务器端的设置,请参考《Server-Side Access Control》

    八、接收二进制数据(方法A:改写MIMEType)

    老版本的XMLHttpRequest对象,只能从服务器取回文本数据(否则它的名字就不用XML起首了),新版则可以取回二进制数据。

    这里又分成两种做法。较老的做法是改写数据的MIMEType,将服务器返回的二进制数据伪装成文本数据,并且告诉浏览器这是用户自定义的字符集。

      xhr.overrideMimeType("text/plain; charset=x-user-defined");

    然后,用responseText属性接收服务器返回的二进制数据。

      var binStr = xhr.responseText;

    由于这时,浏览器把它当做文本数据,所以还必须再一个个字节地还原成二进制数据。

      for (var i = 0, len = binStr.length; i < len; ++i) {

        var c = binStr.charCodeAt(i);

        var byte = c & 0xff;

      }

    最后一行的位运算"c & 0xff",表示在每个字符的两个字节之中,只保留后一个字节,将前一个字节扔掉。原因是浏览器解读字符的时候,会把字符自动解读成Unicode的0xF700-0xF7ff区段。

    八、接收二进制数据(方法B:responseType属性)

    从服务器取回二进制数据,较新的方法是使用新增的responseType属性。如果服务器返回文本数据,这个属性的值是"TEXT",这是默认值。较新的浏览器还支持其他值,也就是说,可以接收其他格式的数据。

    你可以把responseType设为blob,表示服务器传回的是二进制对象。

      var xhr = new XMLHttpRequest();

      xhr.open('GET', '/path/to/image.png');

      xhr.responseType = 'blob';

    接收数据的时候,用浏览器自带的Blob对象即可。

      var blob = new Blob([xhr.response], {type: 'image/png'});

    注意,是读取xhr.response,而不是xhr.responseText。

    你还可以将responseType设为arraybuffer,把二进制数据装在一个数组里。

      var xhr = new XMLHttpRequest();

      xhr.open('GET', '/path/to/image.png');

      xhr.responseType = "arraybuffer";

    接收数据的时候,需要遍历这个数组。

      var arrayBuffer = xhr.response;

      if (arrayBuffer) {

        var byteArray = new Uint8Array(arrayBuffer);

        for (var i = 0; i < byteArray.byteLength; i++) {

          // do something

        }
      }

    更详细的讨论,请看Sending and Receiving Binary Data

    九、进度信息

    新版本的XMLHttpRequest对象,传送数据的时候,有一个progress事件,用来返回进度信息。

    它分成上传和下载两种情况。下载的progress事件属于XMLHttpRequest对象,上传的progress事件属于XMLHttpRequest.upload对象。

    我们先定义progress事件的回调函数。

      xhr.onprogress = updateProgress;

      xhr.upload.onprogress = updateProgress;

    然后,在回调函数里面,使用这个事件的一些属性。

      function updateProgress(event) {

        if (event.lengthComputable) {

          var percentComplete = event.loaded / event.total;

        }

      }

    上面的代码中,event.total是需要传输的总字节,event.loaded是已经传输的字节。如果event.lengthComputable不为真,则event.total等于0。

    与progress事件相关的,还有其他五个事件,可以分别指定回调函数:

      * load事件:传输成功完成。

      * abort事件:传输被用户取消。

      * error事件:传输中出现错误。

      * loadstart事件:传输开始。

      * loadEnd事件:传输结束,但是不知道成功还是失败。

    十、阅读材料

      1. Introduction to XMLHttpRequest Level 2: 新功能的综合介绍。

      2. New Tricks in XMLHttpRequest 2:一些用法的介绍。

      3. Using XMLHttpRequest:一些高级用法,主要针对Firefox浏览器。

      4. HTTP Access Control:CORS综述。

      5. DOM access control using cross-origin resource sharing:CORS的9种HTTP头信息

      6. Server-Side Access Control:服务器端CORS设置。

      7. Enable CORS:服务端CORS设置。

    (完)

    posted @ 2015-08-07 12:24 paulwong 阅读(184) | 评论 (0)编辑 收藏

    理解DOMString、Document、FormData、Blob、File、ArrayBuffer数据类型

         摘要: 一、XMLHttpRequest 2.0的家臣们我大学那会儿,一个称为Ajax的东西对前端行业造成了深远影响,不仅是JS语言,而包括前端地位、职位兴起以及工作分工等。抛开IE6浏览器不谈,其他浏览器的Ajax实际上都是借助XMLHttpRequest实现的。然后,好多年过去了,XMLHttpRequest带着两位家臣,DOMString和Document数据类型攻城略地,几乎一统天下。然时代是发展...  阅读全文

    posted @ 2015-08-07 12:08 paulwong 阅读(430) | 评论 (0)编辑 收藏

    AJAX下载+监控进度+保存文件

    全程用AJAX下载文件,并显示下载进度,之后保存文件。

    HTML5文件:

    <!DOCTYPE html>
    <html>
    <head>
        <title>XMLHttpRequest Download Progress</title>
    </head>
    <body>
        <progress id="p"></progress>
        <input type="button" onclick="downloadAndSave();" value="Download"/>
        <script>
            
    function downloadAndSave()
            {
                
    var progressBar = document.getElementById('p'), xhr = new XMLHttpRequest();
                xhr.open('GET', '
    2');
                xhr.responseType 
    = "arraybuffer";
                xhr.onprogress 
    = function(event) {
                    
    if(event.lengthComputable) {
                        progressBar.max 
    = event.total;
                        progressBar.value 
    = event.loaded;
                    }
                };
                xhr.onloadend 
    = function