Ordering是Guava类库提供的一个犀利强大的比较器工具，Guava的Ordering和JDK Comparator相比功能更强。它非常容易扩展，可以轻松构造复杂的comparator，然后用在容器的比较、排序等操作中。

　　本质上来说，Ordering 实例无非就是一个特殊的Comparator 实例。Ordering只是需要依赖于一个比较器（例如，Collections.max）的方法，并使其可作为实例方法。另外，Ordering提供了链式方法调用和加强现有的比较器。

　　下面我们看看Ordering中的一些具体方法和简单的使用实例。

　　常见的静态方法：

　　natural()：使用Comparable类型的自然顺序， 例如：整数从小到大，字符串是按字典顺序;
　　usingToString() ：使用toString()返回的字符串按字典顺序进行排序；
　　arbitrary() ：返回一个所有对象的任意顺序， 即compare(a, b) == 0 就是 a == b (identity equality)。 本身的排序是没有任何含义， 但是在VM的生命周期是一个常量。

　　简单实例：

import java.util.List;
import org.junit.Test;
import com.google.common.collect.Lists;
import com.google.common.collect.Ordering;

public class OrderingTest {

    @Test
    public void testStaticOrdering(){
        List<String> list = Lists.newArrayList();
        list.add("peida");
        list.add("jerry");
        list.add("harry");
        list.add("eva");
        list.add("jhon");
        list.add("neron");
        
        System.out.println("list:"+ list);

        Ordering<String> naturalOrdering = Ordering.natural();        
        Ordering<Object> usingToStringOrdering = Ordering.usingToString();
        Ordering<Object> arbitraryOrdering = Ordering.arbitrary();
        
        System.out.println("naturalOrdering:"+ naturalOrdering.sortedCopy(list));     
        System.out.println("usingToStringOrdering:"+ usingToStringOrdering.sortedCopy(list));        
        System.out.println("arbitraryOrdering:"+ arbitraryOrdering.sortedCopy(list));
    }
}

　　输出：

list:[peida, jerry, harry, eva, jhon, neron]
naturalOrdering:[eva, harry, jerry, jhon, neron, peida]
usingToStringOrdering:[eva, harry, jerry, jhon, neron, peida]
arbitraryOrdering:[neron, harry, eva, jerry, peida, jhon]

　　操作方法：

　　reverse(): 返回与当前Ordering相反的排序:
　　nullsFirst(): 返回一个将null放在non-null元素之前的Ordering，其他的和原始的Ordering一样；
　　nullsLast()：返回一个将null放在non-null元素之后的Ordering，其他的和原始的Ordering一样；
　　compound(Comparator)：返回一个使用Comparator的Ordering，Comparator作为第二排序元素，例如对bug列表进行排序，先根据bug的级别，再根据优先级进行排序；
　　lexicographical()：返回一个按照字典元素迭代的Ordering；
　　onResultOf(Function)：将function应用在各个元素上之后, 在使用原始ordering进行排序；
　　greatestOf(Iterable iterable, int k)：返回指定的第k个可迭代的最大的元素，按照这个从最大到最小的顺序。是不稳定的。
　　leastOf(Iterable<E> iterable,int k)：返回指定的第k个可迭代的最小的元素，按照这个从最小到最大的顺序。是不稳定的。
　　isOrdered(Iterable)：是否有序，Iterable不能少于2个元素。
　　isStrictlyOrdered(Iterable)：是否严格有序。请注意，Iterable不能少于两个元素。
　　sortedCopy(Iterable)：返回指定的元素作为一个列表的排序副本。

package com.peidasoft.guava.base;

import java.util.List;

import org.junit.Test;

import com.google.common.collect.ImmutableList;
import com.google.common.collect.Lists;
import com.google.common.collect.Ordering;

public class OrderingTest {
    
    @Test
    public void testOrdering(){
        List<String> list = Lists.newArrayList();
        list.add("peida");
        list.add("jerry");
        list.add("harry");
        list.add("eva");
        list.add("jhon");
        list.add("neron");
        
        System.out.println("list:"+ list);
        
        Ordering<String> naturalOrdering = Ordering.natural();
        System.out.println("naturalOrdering:"+ naturalOrdering.sortedCopy(list));    

        List<Integer> listReduce= Lists.newArrayList();
        for(int i=9;i>0;i--){
            listReduce.add(i);
        }
        
        List<Integer> listtest= Lists.newArrayList();
        listtest.add(1);
        listtest.add(1);
        listtest.add(1);
        listtest.add(2);
        
        
        Ordering<Integer> naturalIntReduceOrdering = Ordering.natural();
        
        System.out.println("listtest:"+ listtest);
        System.out.println(naturalIntReduceOrdering.isOrdered(listtest));
        System.out.println(naturalIntReduceOrdering.isStrictlyOrdered(listtest));
        
        
        System.out.println("naturalIntReduceOrdering:"+ naturalIntReduceOrdering.sortedCopy(listReduce));
        System.out.println("listReduce:"+ listReduce);
        
        
        System.out.println(naturalIntReduceOrdering.isOrdered(naturalIntReduceOrdering.sortedCopy(listReduce)));
        System.out.println(naturalIntReduceOrdering.isStrictlyOrdered(naturalIntReduceOrdering.sortedCopy(listReduce)));
        

        Ordering<String> natural = Ordering.natural();
              
        List<String> abc = ImmutableList.of("a", "b", "c");
        System.out.println(natural.isOrdered(abc));
        System.out.println(natural.isStrictlyOrdered(abc));
        
        System.out.println("isOrdered reverse :"+ natural.reverse().isOrdered(abc));
 
        List<String> cba = ImmutableList.of("c", "b", "a");
        System.out.println(natural.isOrdered(cba));
        System.out.println(natural.isStrictlyOrdered(cba));
        System.out.println(cba = natural.sortedCopy(cba));
        
        System.out.println("max:"+natural.max(cba));
        System.out.println("min:"+natural.min(cba));
        
        System.out.println("leastOf:"+natural.leastOf(cba, 2));
        System.out.println("naturalOrdering:"+ naturalOrdering.sortedCopy(list));    
        System.out.println("leastOf list:"+naturalOrdering.leastOf(list, 3));
        System.out.println("greatestOf:"+naturalOrdering.greatestOf(list, 3));
        System.out.println("reverse list :"+ naturalOrdering.reverse().sortedCopy(list));    
        System.out.println("isOrdered list :"+ naturalOrdering.isOrdered(list));
        System.out.println("isOrdered list :"+ naturalOrdering.reverse().isOrdered(list));
        list.add(null);
        System.out.println(" add null list:"+list);
        System.out.println("nullsFirst list :"+ naturalOrdering.nullsFirst().sortedCopy(list));
        System.out.println("nullsLast list :"+ naturalOrdering.nullsLast().sortedCopy(list));
    }

}

//============输出==============
list:[peida, jerry, harry, eva, jhon, neron]
naturalOrdering:[eva, harry, jerry, jhon, neron, peida]
listtest:[1, 1, 1, 2]
true
false
naturalIntReduceOrdering:[1, 2, 3, 4, 5, 6, 7, 8, 9]
listReduce:[9, 8, 7, 6, 5, 4, 3, 2, 1]
true
true
true
true
isOrdered reverse :false
false
false
[a, b, c]
max:c
min:a
leastOf:[a, b]
naturalOrdering:[eva, harry, jerry, jhon, neron, peida]
leastOf list:[eva, harry, jerry]
greatestOf:[peida, neron, jhon]
reverse list :[peida, neron, jhon, jerry, harry, eva]
isOrdered list :false
isOrdered list :false
 add null list:[peida, jerry, harry, eva, jhon, neron, null]
nullsFirst list :[null, eva, harry, jerry, jhon, neron, peida]
nullsLast list :[eva, harry, jerry, jhon, neron, peida, null]

转自：http://singo107.iteye.com/blog/1175084

数据库事务的隔离级别有4个，由低到高依次为Read uncommitted 、Read committed 、Repeatable read 、Serializable ，这四个级别可以逐个解决脏读 、不可重复读 、幻读 这几类问题。

Google是一个非常优秀的公司。他们做出了很多令人称赞的东西—既是公司外部，人们可以看到的东西，也是公司内部。有一些在公司内部并不属于保密的事情，在外部并没有给予足够广泛的讨论。这就是我今天要说的。

让Google的程序如此优秀的一个最重要的事情看起来是非常的简单：代码审查。并不是只有Google做这个事情—代码审查已经被广泛的认可为一种非常好的做法，很多人都在这样做。但我还没有看到第二家这样大的公司能把这种事情运用的如此普遍。在Google，没有程序，任何产品、任何项目的程序代码，可以在没有经过有效的代码审查前提交到代码库里的。

所有人都要经过代码审查。并且很正规的：这种事情应该成为任何重要的软件开发工作中一个基本制度。并不单指产品程序——所有东西。它不需要很多的工作，但它的效果是巨大的。

从代码审查里能得到什么？

很显然：在代码提交前，用第二群眼睛检查一遍，防止bug混入。这是对其最常见的理解，是对代码审查的好处的最广泛的认识。但是，依我的经验来看，这反倒是它最不重要的一点。人们确实在代码审查中找到了bug。可是，这些在代码审查中能发现的绝大部分bug，很显然，都是微不足道的bug，程序的作者花几分钟的时间就能发现它们。真正需要花时间去发现的bug不是在代码审查里能找到的。

代码审查的最大的功用是纯社会性的。如果你在编程，而且知道将会有同事检查你的代码，你编程态度就完全不一样了。你写出的代码将更加整洁，有更好的注释，更好的程序结构——因为你知道，那个你很在意的人将会查看你的程序。没有代码审查，你知道人们最终还是会看你的程序。但这种事情不是立即发生的事，它不会给你带来同等的紧迫感，它不会给你相同的个人评判的那种感受。

还有一个非常重要的好处。代码审查能传播知识。在很多的开发团队里，经常每一个人负责一个核心模块，每个人都只关注他自己的那个模块。除非是同事的模块影响了自己的程序，他们从不相互交流。这种情况的后果是，每个模块只有一个人熟悉里面的代码。如果这个人休假或——但愿不是——辞职了，其他人则束手无策。通过代码审查，至少会有两个人熟悉这些程序——作者，以及审查者。审查者并不能像程序的作者一样对程序十分了解——但他会熟悉程序的设计和架构，这是极其重要的。

当然，没有什么事情能简单的做下来的。依我的经验，在你能正确的进行代码审查前，你需要花时间锻炼学习。我发现人们在代码审查时经常会犯一些错误，导致不少麻烦——尤其在一些缺乏经验的审查者中经常的出现，他们给了人们一个很遭的代码审查的体验，成为了人们接受代码审查制度的一个障碍。

最重要的一个原则：代码审查用意是在代码提交前找到其中的问题——你要发现是它的正确。在代码审查中最常犯的错误——几乎每个新手都会犯的错误——是，审查者根据自己的编程习惯来评判别人的代码。

对于一个问题，通常我们能找出十几种方法去解决。对于一种解决方案，我们能有百万种编码方案来实现它。作为一个审查者，你的任务不是来确保被审查的代码都采用的是你的编码风格——因为它不可能跟你写的一样。作为一段代码的审查者的任务是确保由作者自己写出的代码是正确的。一旦这个原则被打破，你最终将会倍感折磨，深受挫折——这可不是我们想要的结果。

问题在于，这种错误是如此的普遍而易犯。如果你是个程序员，当你遇到一个问题，你能想到一种解决方案——你就把你想到的方案作为标准答案。但事情不是这样的——作为一个好的审查者，你需要明白这个道理。

代码审查的第二个易犯的毛病是，人们觉得有压力，感觉非要说点什么才好。你知道作者用了大量的时间和精力来实现这些程序——不该说点什么吗？

不，你不需要。

只说一句“哇，不错呀”，任何时候都不会不合适。如果你总是力图找出一点什么东西来批评，你这样做的结果只会损害自己的威望。当你不厌其烦的找出一些东西来，只是为了说些什么，被审查人就会知道，你说这些话只是为了填补寂静。你的评论将不再被人重视。

第三是速度。你不能匆匆忙忙的进行一次代码审查——但你也要能迅速的完成。你的同伴在等你。如果你和你的同事并不想花太多时间进行代码复查，你们很快的完成，那被审查者会觉得很沮丧，这种代码审查带来的只有失望的感觉。就好象是打搅了大家，使大家放下手头的工作来进行审查。事情不该是这样。你并不需要推掉手头上的任何事情来做代码审查。但如果中途耽误了几个小时，你中间还要休息一会，喝杯茶，冲个澡，或谈会儿闲话。当你回到审查现场，你可以继续下去，把事情做完。如果你真是这样，我想没有人愿意在那干等着你。

基于云的应用与运行在私有数据中心的应用之间最大的差别就是可扩展性。云提供了按需扩展的能力，能够根据负载的波动对应用进行扩展和收缩。但是传统应用要充分发挥云的优势，并不是简单地将应用部署到云上就万事大吉，而是需要根据云的特点围绕可扩展性重新进行架构设计，近日AppDynamics的开发布道者Dustin.Whittle撰文阐述了适合云端部署的应用架构，对我们传统应用往云端部署有很大的启发和借鉴意义。

应用的架构

Dustin.Whittle给出了云应用的示例架构，它具有高度的可扩展性，如下图所示：

在这个图中，应用按照分层的理念进行了拆分，分别介绍如下：

客户端层：客户端层包含了针对目标平台的用户界面，可能会包括基于Web的、移动端的甚至是胖客户端的用户界面。一般来讲，这可能会是Web应用，包含诸如用户管理、会话管理、页面构建等功能，但是其他客户端所发起的交互都需要以RESTful服务的形式调用服务器。

服务：服务器包含了缓存服务以及聚合（aggregate）服务，其中缓存服务中持有记录系统（system of record）中最新的已知状态，而聚集服务会直接与记录系统交互，并且会执行一些破坏性的操作（会改变记录系统中的状态）。

记录系统：记录系统是领域特定的服务端，它会驱动业务功能，可能会包括客户管理系统、采购系统、预定系统等等，这些很可能是遗留系统，你的应用需要与其进行交互。聚集服务要负责将你的应用从这些特有的记录系统中抽象出来，并为你的应用提供一致的前端接口。

ESB：当记录系统发生数据变化的时候，它需要触发到指定主题（topic）的事件，这就是事件驱动架构（event-driven architecture，EDA）能够影响应用的地方了：当记录系统进行了一项其他系统可能感兴趣的变更时，它会触发一个事件，任何关注记录系统的其他系统会监听到这个事件，并作出对应的响应。这也是使用使用主题（topic）而不是队列（queue）的原因：队列支持点对点（point-to-point）的消息，而主题支持发布-订阅（publish-subscribe）的消息或事件。当与遗留系统进行集成时，我们很期望这些遗留的系统能够免遭负载的影响。因此，我们实现了一个缓存系统，这个缓存系统维持了记录系统中所有最新的已知状态。缓存系统会使用EDA的规则监听记录系统的变化，它会更新自己所保存数据的版本，从而保证与记录系统中的数据相匹配。这是一个很强大的策略，不过会将一致性模型变为最终一致性，也就是说如果你在社交媒体上发布一条状态的话，你的朋友可能在几秒钟甚至几分钟之后才能看到，数据最终是一致的，但有时你所看到的与你的朋友所看到的并不一致。如果能接受这种一致性的话，就能在很大程度上实现可扩展性的收益。

NoSQL：在数据存储方面，有很多的可选方案，但如果要存储大量数据的话，使用NoSQL存储能够更容易地扩展。有多种NoSQL存储可供选择，不过这要匹配所存储数据的特点，如MongoDB适合存储可搜索的数据，Neo4j适合存储高度互相关联的数据，而Cassandra适合存储键/值对，像Solr这样的搜索索引有利于加速对经常访问数据的查询。

将应用拆分为多个层的时候，最好的模式就是使用面向服务架构（service-oriented architecture，SOA）。要实现这一点，可以使用SOAP，也可以使用REST，但是REST更为合适，因为它可扩展性更强。作者接下来对REST的理念进行了深入的阐述，InfoQ上关于REST已有很多相关的文章，如这里和这里，甚至包括Roy Fielding经典博士论文的中译本，所以这里不再赘述。不过，作者在这里特别强调了RESTful Web服务能够保持无状态性（stateless）。无状态是实现可扩展性的关键需求，因为无状态，所以请求可以由任何一个服务器响应。如果你在服务层上需要更多的容量时，只需要为该层添加虚拟机即可，而不需关注客户端状态保持的问题，负载可以很容易地重新分配。

部署到云端

前面介绍了基于云的应用架构，接下来作者阐述了这样的应用该如何部署到云端。

RESTful Web服务要部署到Web容器中，并且要位于数据存储之前。这些Web服务是没有状态的，只会反映其暴露的底层数据的状态，因此可以根据需要部署任意数量的服务器。在基于云的部署中，开始时可以开启足够的实例以应对日常的需求，然后配置弹性策略，从而根据负载增加或减少服务器的数量。衡量饱和度的最好指标就是服务的响应时间。另外还需要考虑这些服务所使用的底层数据存储的性能。示例的部署图如下所示：

如果在云部署时有EDA的需求，那么就需要部署ESB，作者给出的建议是根据功能对ESB进行分区（partitioning），这样一个segment的过大负载不会影响到其他的segment。如下图所示：

这种分离使System 1的负载与System 2的负载实现了隔离。如果System 1产生的负载拖慢了ESB，它只会影响到自己的segment，并不会影响到System 2的segment，因为它部署在其他硬件上。如果ESB产品支持的话，我们还可以给指定的segment添加服务器来实现扩展。

基于云的应用与传统应用有着很大的差别，因为它有着不同的扩展性需求。基于云的应用必须有足够的弹性以应对服务器的添加与移除，必须松耦合，必须尽可能的无状态，必须预先规划失败的情况，并且必须能够从几台服务器扩展到成千上万台服务器。

针对云应用并没有唯一正确的架构，但是本文所阐述的RESTful服务以及事件驱动架构却是经过实践检验有效的架构。作者认为REST和EDA是实现云端可扩展应用的基本工具。

目前，国内许多传统的软件厂商正在逐渐往云端迁移，希望本文所阐述的架构理念能够为读者提供一些借鉴。