一、選型流程
對於重大元件、中介軟體的選型，首先要明確短期、中長期的需求，根據需求，列出一些重點考慮的需求特性，根據這些特性，列出一些測試用例，在選型時，用這些測試用例對入圍產品進行測試，根據測試結果來評判各個產品的優劣以及與需求的匹配程度。（對應下面的第3、4項）
------>相關資料------->
2 召集領導、技術骨幹、架構師等，討論需求和使用中介軟體的必要性
------> (1) 需要自研-------> 《自研流程......>
------> (2) 選用中介軟體-------> 由領導發起中介軟體選型任務（主要由基礎技術平台來具體負責）
3 （選型負責人）廣泛調研和收集符合需求的中介軟體，發布初步《調研報告》，召開討論會
-----> (1) 不符合要求，需要自研-------> 《自研流程......>
-----> (2) 決定選出2到4款拿來做最終的對比測試
4 發起對比測試（根據具體情況進行，可能涉及到效能、穩定性、安全性等各個方面，如果測試複雜，需要效能測試團隊參與）
5 編寫中立的《選型報告》和《測試結論》，完成後，召開討論和評審會議，決定要用哪一款中介軟體
-----> (1) 所有備選的中介軟體，都不完全滿足需求，需要二次開發或者調整需求 -------> 《領導做決定......>
-----> (2) 決定選擇某乙個款中介軟體 ------->
6 由基礎技術平台負責該中介軟體的部署或二次開發 - the end
注意，1、對於第一點 - 「需求的提出和收集」，可以由任何方面發起，包括研發組、架構組、基礎技術組等。
2、選型負責人，主要由基礎技術平台來具體負責，一般來說，必須是高階工程師以上，有豐富經驗的一線架構師來負責，《調研報告》、《選型報告》、《測試結論》等文件，必須是專業的，能說服人的，沒有這個效果就得重寫！
二、重大版本更新流程
1 由版本更新的發起方（例如基礎技術平台，或者業務需求方也可以提出更新）來確定更新內容，召開討論會議，收集反饋意見並 決定是否有公升級的必要
--------> (1) 決定暫不公升級
--------> (2) 決定公升級
2 中間的負責人，準備好新版本（可能還包括二次開發），新版本準備好後，發起測試，通過測試後，發布測試結論；
3 制定公升級計畫（如有必要，可以召集使用方 開會確定公升級計畫），並準備公升級手冊和資料；
4 由基礎技術平台負責該中介軟體的新版本部署 - the end
三、選型標準
列表和舉例如下：
標準說明
springmvc
zolltymvc
滿足需求
能否滿足功能需求及技術指標（比如效能要求）（滿足眼前的需求）；
能否適應未來的發展，滿足未來的需求（適可而止，不一定是越多越好）。
很多，很強，以至於一般都用不完 也很難一一枚舉完。（10分）
成熟度產品正式版本發布時間和次數；
產品是否被長期、廣泛的在生產環境使用；
是否經過業界各種複雜場景及苛刻要求的驗證；
在網際網路上的資料是否豐富。
開源10多年；
發布的版本數以百計；
被全世界廣泛使用、占有率絕對第一；
網上文件和資料非常豐富；（10分）
發布已有5年，有十餘個版本，使用案例很少，僅僅有3、5個小專案在用，市場檢驗不足；文件資料很少。（3分）
可靠性產品bug數量多少；
正式版本是否被發現有嚴重bug；
是否有安全漏洞和隱患；
產品是否經過測試和質量、安全上的檢測；
是否具備容災能力（比如支援集群、副本等）；
穩定可靠，十幾年來，被無數公司使用，很少發現嚴重缺陷和不穩定的情況。（10分）
簡單使用來看，還算穩定可靠，但是沒有經過太多場景的檢驗。（6分）
產品活力
是否開源；
如果開源，參與開發的人有多少，是否深入，是否活躍；
使用者和各種參與者人數多少，是否活躍；
bug修復頻率，版本發布的頻率和穩定性，是否有過停止更新，或者經常發布延期等情況。
**和資料完全開源；
已形成廣大的社群，擁有大量的維護者和開發者；
近十幾年，一直再不停的維護更新，每年都會有很多個版本發布；（10分）
**和資料完全開源；只有乙個維護和開發者，且很少有人關注和互動；近幾年來更新頻率很低，大概1年左右發布一次版本。（3分）
業界案例
業界的主流方案是什麼？最先進的方案又是什麼？
業界的流行趨勢是什麼？
業界（國內、外）知名公司是怎麼做的，他們的方案是什麼？
口碑和行業認可度
有多少公司也採用了這種產品、技術或方案，效果和口碑如何？
服務支援能力
開源還是商業？能否得到官方及時有力的支援？
可維護性
是否容易安裝/公升級/更新；
是否容易日常維護；
是否有安裝和維護等操作說明文件；
是否支援監控；
是否支援灰度發布、平滑公升級。
可測試性
對其本身或相關的功能，是否容易測試，是否容易定位問題；
是否支援自動化測試。
效能效率
響應時間、吞吐量、併發、資源利用率等，是否在同類產品中勝出；
是否支援通過水平擴充套件、負載均衡等方式來提高效能。
由於本身比較複雜，效能效率不算高，但是從各大公司的使用來看，能滿足99.99%的場景。
簡單輕量，對比來看，各方面的效能效率很高。
安全性功能上是否有各種安全策略和保障（比如支援認證、加密等，支援防sql注入、重放攻擊等）
是否暴露出有安全漏洞或隱患
是否經過安全上的檢測；
被廣泛使用，幾乎沒有安全方面的漏洞和隱患。
簡單使用來看，還算安全，但是沒有經過太多的測試檢驗。
二次開發
採用的什麼程式語言和核心技術，是否能夠掌握，掌握的難度如何；
**和文件是否清晰，有無**注釋、設計說明、二次開發說明等。
完全開源，容易進行二次開發，但是由於功能過剩、又有強大的社群支援，幾乎不需要自己進行二次開發和維護。
完全開源，**簡單，容易進行二次開發、擴充套件。
功能的可擴充套件性
設計上是否具備功能上或**級別的可擴充套件能力；
擴充套件是否方便。
易用性教程、詳細說明文件、api文件、參考示例等是否齊全、完善、清晰易懂；
是否容易上手使用；
其功能和設計，是否容易理解。
由於功能強大，設計和**比較複雜，但是由於文件和資料非常豐富，易用性比較好。
由於功能簡單、**少，複雜度不高，易用性很好。
複雜度和冗餘度
在滿足需求的情況下，複雜度越低越好（衡量複雜度的方式，包括**量、步驟的多少等資料指標）；
是否有大量冗餘、很可能用不上的功能，且會對資源利用和易用性等方面造成不好的影響；
效能上是否遠遠超過預期且會造成一些不必要的浪費和其他方面負面的影響。
法律風險
是否開源，開源的協議是什麼
總的來說，springmvc在 功能性、產品成熟度和活力 上勝出，而zolltymvc在 效能效率、複雜度和易用性上勝出。
注意，1、此列表僅為示例，每一項寫得並不詳細，正式的調研報告和選型報告，應該詳細列舉每一項的對比資料（以資料說話，每一項約2頁左右）。
2、限於格式，這裡沒有列出每一項的權重。在實際對比時，可以給每一項，根據自身的需求，來確定每一項的權重，然後分別乘以每一項得分，所有項得分相加，得出總分數。
乙個真實案例：分布式檔案儲存系統選型
訊息中介軟體的技術選型
rabbitmq activemq和zeromq都是極好的訊息中介軟體，但是我們在專案中該選擇哪個更適合呢？很多開發者面臨這個煩惱。下面我會對這三個訊息中介軟體做乙個比較，看了後你們就心中有數了。rabbitmq是amqp協議領先的乙個實現，它實現了 broker 架構，意味著訊息在傳送到客戶端之前...
訊息中介軟體優缺點及選型
1 優點 解耦 通過pub sub發布訂閱訊息，解除系統之間的耦合性 非同步 非同步處理請求，實現快速響應 削峰 mysql一般可以支援每秒2k請求，將請求寫入訊息中介軟體，慢慢拉取2 缺點 可用性降低 請求處理依賴訊息中介軟體 複雜的提高 需要處理重複消費 訊息丟失 訊息傳遞順序等 一致性問題 訊...
分頁和中介軟體
一 分頁 批量匯入資料 booklist for i in range 100 book.objects.bulk create booklist 分頁器的使用 book list book.objects.all paginator paginator book list,10 print cou...