一、前言
??我們在展開一個新的產(chǎn)品或者項目開發(fā)之前，一般需要進(jìn)行技術(shù)選型，那么什么是技術(shù)選型呢？通俗來說就是：我們需要實現(xiàn)某個方面的需求，而市面上已經(jīng)有很多現(xiàn)成的解決方案，那么我們就需要全面的評估各種解決方案，選擇一個最適合我們使用的，這一個過程就是技術(shù)選型。
通常來說，技術(shù)選型有以下幾個階段：
- 1、技術(shù)調(diào)研
技術(shù)調(diào)研是指：可以實現(xiàn)我們需求的解決方案有哪些。我們可以先把這些方案列出來作為備選技術(shù)。 - 2、技術(shù)對比
技術(shù)對比是指：對這些備選技術(shù)進(jìn)行一個全面的橫向?qū)Ρ?，對比的維度包含以下方面：使用復(fù)雜度、文檔完善度、社區(qū)活躍度、功能完整度、發(fā)展趨勢，最后肯定還要對比它們的性能了。 - 3、需求配對
需求配對是指：在我們了解了這些備選技術(shù)并做了全面的對比后，再根據(jù)我們實際的需求來選擇一個最適合我們使用的技術(shù)。
那么接下來我們就根據(jù)以下幾個需求來做技術(shù)選型：
- 構(gòu)建分布式&微服務(wù)應(yīng)用的需求
- 使用分布緩存服務(wù)的需求
- 使用消息隊列的需求
- 使用搜索服務(wù)器的需求
這里需要特別說明，技術(shù)選型需要對各種技術(shù)進(jìn)行全面的對比，那有可能筆者本身對某個技術(shù)的了解就有偏差，主觀性比較強，所以以下的言論大家參考即可，不必較真，如有什么描述不對的地方，歡迎一起討論，一起學(xué)習(xí)。
分布式&微服務(wù)框架選型
1、技術(shù)調(diào)研
??在現(xiàn)在的分布式領(lǐng)域中，比較流行的分布式應(yīng)用框架有Dubbo、Motan、SpringCloud，他們都可以構(gòu)建分布式&微服務(wù)應(yīng)用。其中Dubbo和Motan不管是使用上、思想上還是實現(xiàn)上，都是非常相似的技術(shù)，它們分別出自互聯(lián)網(wǎng)大廠阿里和微博，經(jīng)受了大規(guī)模服務(wù)調(diào)用的實際考驗，同時被大量互聯(lián)網(wǎng)公司應(yīng)用在他們的生成環(huán)境中。而SpringCloud是大名鼎鼎的Spring家族的產(chǎn)品。Spring專注于企業(yè)級開源框架的研發(fā)，不論是在中國還是在世界上使用都非常廣泛，開發(fā)出通用、開源、穩(wěn)健的開源框架就是他們的主業(yè)。
2、技術(shù)對比
| SpringCloud | Dubbo | Motan | |
|---|---|---|---|
| 使用復(fù)雜度 | 由于SpringCloud與SpringBoot無縫整合，所以決定了SpringCloud的使用將非常簡單，基本上就是加依賴、貼注解就搞定。并且服務(wù)提供方和服務(wù)消費方通過 Json方式交互，因此只需要定義好相關(guān) Json 字段即可，消費方和提供方無API接口依賴，有效降低了模塊的依賴關(guān)系。 | 框架使用動態(tài)代理的方式，屏蔽了遠(yuǎn)程調(diào)用和參數(shù)封裝的麻煩，實現(xiàn)了調(diào)用遠(yuǎn)程方法就好像調(diào)用本地方法一樣。但正因為使用了動態(tài)代理，所以服務(wù)提供方和服務(wù)消費方有API接口依賴，這就導(dǎo)致了項目各個模塊之間的依賴關(guān)系非常復(fù)雜，增加了開發(fā)和維護(hù)的難度。 | 與Dubbo一致。 |
| 文檔完善度 | Spring官網(wǎng)上有完善的文檔，但是中文文檔比較少，這對于英文菜雞來說是一件比較頭痛的問題。 | 有非常完善的中文文檔。 | 官方文檔不是很全，有些功能在文檔上找不到。 |
| 社區(qū)活躍度 | 依托Spring開源家族，社區(qū)非?；钴S，所以開發(fā)和維護(hù)團(tuán)隊強大，解決問題快，版本升級迭代快。 | 幾乎到了停止維護(hù)的程度，但是18年一系列的動作，包含恢復(fù)維護(hù)和捐獻(xiàn)給Apache，都一定程度的增加了活躍度，但還遠(yuǎn)比不上SpringCloud。 | 比Dubbo的活躍度更低。 |
| 功能完整度 | SpringCloud號稱是分布式&微服務(wù)一站式解決方案的提供者，在所有的分布式框架中，功能是最齊全的。有幾個核心的功能：服務(wù)調(diào)度、服務(wù)治理、服務(wù)注冊中心、服務(wù)網(wǎng)關(guān)、熔斷器、分布式配置中心、分布式服務(wù)跟蹤系統(tǒng)、消息總線等。而這些功能的使用是開箱即用的。 | Dubbo在本身框架上，只能提供服務(wù)調(diào)度、服務(wù)治理、服務(wù)注冊中心的功能，其他的功能需要整合第三方中間件，或者自己二次開發(fā)做擴(kuò)展。增加了項目的復(fù)雜度和使用難道。 | 與Dubbo一致。 |
| 發(fā)展趨勢 | SpringCloud的市場占有率是程上升的趨勢，并且自身在快速發(fā)展完善。 | 從目前來看，市場占有率高，但發(fā)展平穩(wěn)，有大量的項目使用Dubbo開發(fā)或改造，也有大量的項目從Dubbo改造成SpringCloud。自身發(fā)展到了一個成熟的階段，后續(xù)不會有大的改動，除非推翻整個架構(gòu)重新設(shè)計。 | 市場占有率低。 |
| 性能 | SpringCloud是使用REST接口通訊，而REST其實就是應(yīng)用層的http協(xié)議，吧交互的數(shù)據(jù)是Json。在數(shù)據(jù)傳輸上，效率比較低，并且網(wǎng)絡(luò)帶寬占用比較大。 | Dubbo默認(rèn)采用TCP協(xié)議，數(shù)據(jù)是二進(jìn)制文件，傳輸效率高，帶寬占用低。 | 與Dubbo一致。 |
3、需求配對
??通過以上的對比，我們發(fā)現(xiàn)Motan沒有一項對比是占絕對優(yōu)勢的，所以我們可以先排除掉Motan，剩下的就是SpringCloud和Dubbo之間選擇了。而SpringCloud和Dubbo各有各的優(yōu)勢與劣勢，SpringCloud的優(yōu)勢在于它的社區(qū)和發(fā)展前景，Dubbo的優(yōu)勢在于它的性能和文檔，該選擇哪個，就只能看我們具體的需求了。
??如果準(zhǔn)備開展的產(chǎn)品或項目，服務(wù)拆分的粒度是非常細(xì)的，那么首先需要考慮的是開發(fā)和維護(hù)的復(fù)雜度，網(wǎng)絡(luò)性能和帶寬其實不是什么太大的問題，如果真的成了問題，通過壓縮、二進(jìn)制、高速緩存、分段降級等方法，也能解決。所以這種情況下，就選擇SpringCloud。反之服務(wù)拆分粒度不大，不會造成過于復(fù)雜和臃腫的模塊依賴關(guān)系，那么根據(jù)Dubbo的網(wǎng)絡(luò)傳輸性能來看，我不需要做額外的事情，就有一個性能強的應(yīng)用，那肯定是選擇Dubbo。
分布式緩存選型
1、技術(shù)調(diào)研
??這里說的分布式緩存服務(wù)器，其實就是我們常說的Nosql數(shù)據(jù)庫，在不考慮大數(shù)據(jù)的前提下，java領(lǐng)域里，流行的、優(yōu)秀的分布式緩存服務(wù)器已經(jīng)過濾剩不多了，我們這里列舉3個備選技術(shù)：Redis、Memcached、MongoDB。既然我們的需求是使用分布式緩存，那緩存當(dāng)然主要是操作內(nèi)存了，這3款備選技術(shù)都是主要操作內(nèi)存，而Redis和Memcached是Key-value型的，MongoDB是文檔型的，各自都是自己所屬類型Nosql數(shù)據(jù)庫的優(yōu)秀代表。
2、技術(shù)對比
| Redis | Memcached | MongoDB | |
|---|---|---|---|
| 使用復(fù)雜度 | 簡單，就跟操作java的Map一樣。 | 簡單，就跟操作java的Map一樣。 | 對比起來要難很多，需要學(xué)習(xí)它的查詢語言。 |
| 文檔完善度 | 文檔齊全。 | 文檔齊全。 | 文檔齊全，但中文文檔稍有欠缺。 |
| 社區(qū)活躍度 | 社區(qū)非?；钴S，大量的開發(fā)者不斷為Redis增加新功能。 | 不活躍。 | 雖然MongoDB Inc是一家上市的商業(yè)公司，但該公司對社區(qū)的回饋力度上卻很大，非常注重自己的產(chǎn)品在開源社區(qū)中的發(fā)展。 |
| 功能完整度 | 對于key/value型的數(shù)據(jù)庫來說，Redis的功能可以說是十分強大的。從支持的數(shù)據(jù)庫類型來看，它支持String、List、Set、Hash，后續(xù)的版本還添加了GEO、Bitmap等數(shù)據(jù)類型。支持簡單事務(wù)、消息隊列。支持多種數(shù)據(jù)持久化方式和多種集群方式。 | 同是key/value型數(shù)據(jù)庫，但是支持的數(shù)量類型少，只能使用String類型，不支持?jǐn)?shù)據(jù)持久化。 | Json格式的文檔型數(shù)據(jù)庫，非常接近關(guān)系型數(shù)據(jù)庫的使用方式，屬于半結(jié)構(gòu)化的數(shù)據(jù)庫（json，xml），有強大的查詢語法，健全的事務(wù)機制，簡單的存儲過程定義，也支持?jǐn)?shù)據(jù)持久化和集群擴(kuò)展。 |
| 發(fā)展趨勢 | 市場占有率呈現(xiàn)上升趨勢，并且版本不斷更新，每次更新都新增很多實用的功能。 | 市場占有率低，版本更新慢。 | 在DB-Engines上總得分排名前5，長時間位于第4位，前3為分別是oracle，mysql和SQLServer，由此可以看出MangoDB的流行程度，并且增長率以較大的比率增長。 |
| 性能 | 在所有以內(nèi)存操作為主的Nosql數(shù)據(jù)庫中，單實例性能算是中規(guī)中矩，因為他是單線程的，沒法利用CPU的多核優(yōu)勢，但好在大并發(fā)的情況下，減少了數(shù)據(jù)一致性的問題，和多線程環(huán)境上下文切換帶來的額外消耗問題。 | 充分的利用了CPU多核優(yōu)勢，單實例性能極高，數(shù)據(jù)吞吐量也非常大，但由于不能做數(shù)據(jù)持久化，所以注定了它的應(yīng)用場景只能作為緩存，不是一個真正意義上的Nosql數(shù)據(jù)庫。 | 也是以操作內(nèi)存為主，同時支持?jǐn)?shù)據(jù)持久化，由于是半結(jié)構(gòu)化的數(shù)據(jù)庫，所以同樣有索引功能，結(jié)合豐富的查詢語句，可以快速的查詢數(shù)據(jù)。 |
3、需求配對
??從性能這個維度來看的話，這3款數(shù)據(jù)庫性能都很高，對于我們來說都不會成為瓶頸。那么再通過其他維度對比的話，我們可以排除掉Memcached，因為它和Redis都是key/value數(shù)據(jù)庫，但它各方面都不如Redis，那剩下的就是Redis和MongoDB了。
??這兩個Nosql數(shù)據(jù)庫分別是key/value型和文檔型的代表，各自有自己的應(yīng)用場景，Redis更適合數(shù)據(jù)量不大，查詢方式簡單（即Map的這種通過key查詢value），以作為關(guān)系型數(shù)據(jù)庫的緩存為主的需求場景下更適合。而如果是以海量數(shù)據(jù)存儲為主，查詢復(fù)雜度接近關(guān)系型數(shù)據(jù)庫，并且想在大多數(shù)業(yè)務(wù)下替換掉關(guān)系型數(shù)據(jù)庫的需求場景下，則選擇MongoDB。
消息隊列技術(shù)選型
1、技術(shù)調(diào)研
??分布式消息隊列分成Broker類和Brokerless類，Broker類的消息隊列，是指有獨立部署運行的分布式服務(wù)，發(fā)送者把消息發(fā)送到Broker服務(wù)進(jìn)程，再由Broker服務(wù)進(jìn)程推送給訂閱者，或者訂閱者主動拉取消息。Brokerless類的消息隊列，采用API的方式，編譯到應(yīng)用程序中，在應(yīng)用程序間進(jìn)行點對點的通信。而java領(lǐng)域里，分布式消息隊列非常多，常見的有：ActiveMQ、RabbitMQ、RocketMQ、ZeroMQ、Kafka。其中RocketMQ是阿里開源的一款消息隊列，性能和吞吐量非常高，這點是毋容置疑的，畢竟經(jīng)受住阿里雙11的考驗，ZeroMQ則是為數(shù)不多的Brokerless類代表。所以我們選擇這5款常見的、具有代碼性的MQ作為備選技術(shù)。
2、技術(shù)對比
| ActiveMQ | RabbitMQ | RocketMQ | ZeroMQ | Kafka | |
|---|---|---|---|---|---|
| 使用復(fù)雜度 | 簡單。 | 簡單。 | 簡單。 | 因為Brokerless的特點，所以需要API的整合，復(fù)雜度會稍微高一點。 | 使用方式上，跟其他的MQ有點區(qū)別，比如ActiveMQ和RabbitMQ。 |
| 文檔完善度 | 文檔全，但是比較亂。 | 文檔齊全。官方翻譯中文文檔正在進(jìn)行中。 | 是阿里開發(fā)的，文檔齊全，但卻沒有中文文檔，可能捐給了Apache后就由他們打理了。 | 文檔不是很系統(tǒng)。 | 文檔齊全。但中文文檔稍有欠缺。 |
| 社區(qū)活躍度 | 是Apache下的一個開源項目，已經(jīng)存在很久了，是非常老牌和成熟的項目，現(xiàn)在社區(qū)已經(jīng)不怎么活躍了。 | 社區(qū)非?；钴S。 | 社區(qū)不太活躍，據(jù)說GitHub上提交的問題解決的比較慢。 | 社區(qū)活躍度高。 | 社區(qū)活躍度高。 |
| 功能完整度 | 功能比較完善，支持的通訊協(xié)議多，消息持久化方式多，支持事務(wù)，支持高可用集群。 | 同樣支持多種通訊協(xié)議和多種持久化方式，不支持事務(wù)。并且有插件機制，提供了許多插件，從多方面進(jìn)行擴(kuò)展，也可以編寫自己的插件，所以功能非常豐富。 | 使用自有的協(xié)議通訊，支持持久化，不支持事務(wù)，使用分片的方式集群擴(kuò)容，有容錯容災(zāi)能力。功能上與Kafka非常相似，在設(shè)計上，一定程度的參考Kafka。 | 使用TCP協(xié)議作為消息通訊的方式，不支持消息持久化，不支持事務(wù)，比較輕巧。 | 使用自有的協(xié)議通訊，支持持久化，不支持事務(wù)，使用分片的方式集群擴(kuò)容，有容錯容災(zāi)能力。 |
| 發(fā)展趨勢 | ActiveMQ雖然現(xiàn)在各方面都不太活躍，還有點老舊臃腫，感覺像日落西山的樣子。但并不意味著ActiveMQ的壽命將要終止，因為其下一代產(chǎn)品Apollo，真在快速的版本迭代中，以另一種方式繼續(xù)發(fā)展。 | 在分布式消息隊列中使用率是最高的，并且使用率還在快速的增加，因為SpringCloud消息總線組件默認(rèn)就是使用它。 | 當(dāng)前主要是在中國用的比較多。官網(wǎng)上介紹的使用案例都是中國企業(yè)。但RocketMQ是后起之秀，借鑒了很多之前消息隊列的優(yōu)點，比如Kafka。所以后續(xù)的發(fā)展值得期待 | 知名度和市場占有率都相對較低。 | 大量用在大數(shù)據(jù)領(lǐng)域。 |
| 性能 | 性能和吞吐量差強人意，甚至還有用戶反映有消息丟失的情況。 | 性能和吞吐量比ActiveMQ高，屬于萬級。消息也比較可靠。 | 性能和吞吐量非常高，屬于十萬級。 | 號稱是“史上最快的消息隊列”，專門為高吞吐，低延遲開發(fā)，但是與應(yīng)用程序共享資源，擴(kuò)容能力弱，所以這個稱號其實有點噱頭的意思。 | 性能和吞吐量非常高，屬于十萬級。 |
3、需求配對
??ZeroMQ小而美，RabbitMQ大而穩(wěn)，RocketMQ和Kakfa快而強。而ActiveMQ似乎沒有什么特別可取之處，支持事務(wù)功能也比較雞肋，所以企業(yè)新展開的項目一般都不會使用ActiveMQ了，還會使用的，那都是信仰和情懷了。ZeroMQ不是獨立運行的中間件服務(wù)，除了消耗我們應(yīng)用的資源外，自身集群擴(kuò)展能力還很弱。而RocketMQ看似比上不足，比下有余，性能比除了Kafka外的其他MQ都高，但是社區(qū)活躍度和產(chǎn)品成熟度卻比不上其他MQ。所以在RocketMQ還不是很成熟的現(xiàn)階段，不會是最好的選擇。剩下的RabbitMQ和Kakfa，具體選擇哪一個，就按照我們實際需求來選擇。
??如果僅僅只是希望在自己的項目中添加一個分布式消息隊列，并不要求有很高性能和吞吐量的，那RabbitMQ是一個很好的選擇，消息既可靠，功能擴(kuò)展性又高，且有SpringCloud官方支持。但是，如果對性能和吞吐量有很高要求的，或者做數(shù)據(jù)收集/分發(fā)、與大數(shù)據(jù)領(lǐng)域技術(shù)結(jié)合等特殊需求的場景下，則使用Kafka。
搜索服務(wù)器技術(shù)選型
1、技術(shù)調(diào)研
??搜索服務(wù)的備選技術(shù)上，我們選擇的是Solr和Elasticsearch，這兩者底層都是使用Lucene搜索引擎，
Solr是Apache的開源項目，Elasticsearch是Elastic公司的開源技術(shù)棧之一。都是很流行的搜索服務(wù)器。
2、技術(shù)對比
| Solr | Elasticsearch | |
|---|---|---|
| 使用復(fù)雜度 | 簡單。 | 對比Solr來說，稍顯復(fù)雜，特別是安裝流程，管理界面上。 |
| 文檔完善度 | 完善，學(xué)習(xí)資料多。 | 中文文檔相對缺乏，學(xué)習(xí)資料比較少。 |
| 社區(qū)活躍度 | 有更大、更成熟的開發(fā)者和貢獻(xiàn)者社區(qū)。 | 主要靠Elastic公司開發(fā)和維護(hù)。 |
| 功能完整度 | 比較成熟。支持的數(shù)據(jù)格式多，如json、xml、csv，友好的管理界面，官方提供功能多，高可用集群需要依賴zookeeper。 | 不夠成熟。只支持json數(shù)據(jù)格式，更注重于核心功能，高級功能由第三方插件提供，自帶高可用集群功能。 |
| 發(fā)展趨勢 | 在DB-Engines上總得分排名第15位，每年都有小幅下降。 | 在DB-Engines上總得分排名第7位，每年都以很高的幅度增長。 |
| 性能 | 當(dāng)建立索引時, Solr會產(chǎn)生IO阻塞，查詢性能下降。對已有的數(shù)據(jù)搜索時，性能比較高，但是隨著數(shù)據(jù)量增加，Solr的搜索效率會下降。 | 建立索引時，不會產(chǎn)生IO阻塞。這方面Elasticsearch具有明顯的優(yōu)勢，這對于實時搜索的要求有很大的幫助。對已有數(shù)據(jù)搜索沒有Solr快，但是隨著數(shù)據(jù)量增加，Elasticsearch的搜索速度沒有明顯的變化。并且亮點是其分布式的特點，集群擴(kuò)展非常簡單方便，數(shù)據(jù)分片存儲，輕松擴(kuò)展TB級別，所有節(jié)點對外表現(xiàn)對等，自動均衡。 |
3、需求配對
??Solr在數(shù)據(jù)量不大的傳統(tǒng)搜索應(yīng)用表現(xiàn)要好于Elasticsearch，這體現(xiàn)在使用簡易度上，功能上完整度上，還有少量數(shù)據(jù)搜索效率上。但Solr畢竟是很久之前的產(chǎn)品，似乎不太適應(yīng)當(dāng)前大數(shù)據(jù)發(fā)展的趨勢，而Elasticsearch天生支持大數(shù)據(jù)，并且很多有大數(shù)據(jù)需求的互聯(lián)網(wǎng)公司，實際生產(chǎn)環(huán)境測試，將搜索服務(wù)器從Solr轉(zhuǎn)到Elasticsearch以后的平均查詢速度有了50倍的提升。
??所以，總的來說，數(shù)據(jù)量少的傳統(tǒng)搜索應(yīng)用可以使用Solr，新興的實時搜索大數(shù)據(jù)應(yīng)用選擇Elasticsearch。
