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是實現云端可擴展應用的基本工具。

目前，國內許多傳統的軟件廠商正在逐漸往云端遷移，希望本文所闡述的架構理念能夠為讀者提供一些借鑒。