架構之技術選型

前言

技術選型是一個公司的重中之重，是技術的根基，是部門的方向，是對技術負責人，架構師，cto，基礎架構組的考驗。一個錯誤的選型，可能形成巨大的財務，人力損失。

技術選型原則

開源,是否在持續維護中

開源以後，不懼怕閉源

不用懼怕之後項目會閉源而出現各類問題，若是有一個優秀的項目開源之後，很大的用戶羣體，大型互聯網公司使用過，那麼不用擔憂閉源問題帶來的後果，閉源以後大型互聯網會在原有的基礎上維護或者創新一個相似的。

開源項目會有更多人與團隊參與，社區十分會比較活躍，生態圈會慢慢完善

鳥菜啊我的認爲這點很是重要，開始使用某個技術的時候，可能不須要源碼。時間長了會暴露大量的問題出來，這個時候請人不如求己。

1. 當須要在某個技術上進行擴展的時候，若是不瞭解原理與實現，可能形成嚴重的問題。
2. 深刻源碼，能夠了解實現，正確的使用這個技術。
3. 出現bug的時候，能夠了解bug出現的緣由

持續維護中

若是做者與團隊，中止對開源項目進行維護。不該該選擇該技術。在技術棧裏面已經存在。那麼你須要準備尋找替代品，並在必定時間內完成更新。可是有些項目已經作到終點了，好比dubbo2.0,基本知足了soa全部需求

是否收費，公司對技術費用的承受能力有多少

如今架構組成有大量的技術，每一個技術都收費的話，大部分初創公司基本直接死了，有錢的公司也扛不住這樣量的收費。

是否有一樣功能或在性能方面稍弱，基本功能其羣，而且免費的技術。收費的項目可能有更好的性能，生態，技術支持，可是你須要嗎？

oracle的強大路人皆知，收費挺不便宜的。做爲通常的公司須要那麼多功能的嗎？ 結果是不須要。因此選擇MySQL 是一個優質解決方案

若是收費，投入的資金是否回報高如投入

某金融公司想使用MySQL NDB解決分佈式的問題，隨着數據量的不斷增長，服務實例愈來愈多，收費愈來愈貴，該公司團隊以爲出入不敷。

好比直接購買雲服務，公司須要消息中間件，並且量不大。鳥菜啊就直接建議使用阿里雲的商業版rocketmq。簡單方面，不須要運維。.net團結接受了建議，使用了很長時間。效果很是好。量不大的應用都使用的阿里雲商業版rocketmq,成本沒有提升，解決了2我的的運維，管理，維護成本。

技術程度的定義，是否符合需求（基礎功能），是否須要，須要程度，團隊是否有對應的人員

是核心技術，仍是重要技術，仍是工具。注重是性能，仍是效率。技術做用方面。不一樣要求的可能偏重就不同。若是你技術定位錯了。

符合

一次錯誤的跟風， ——node.js 很火。被不少吹捧成在web領域拯救世界的語言。不少大公司的大牛面也在宣揚node.js在公司裏面實踐獲得不少好處。 ——結果了，公司的架構組（我已經逃離了），就採用node.js。採用node.js幹什麼，實現api網關（也就是接口），把全部的java實現的接口，所有換成了node.js的實現。架構師把一個dome給演示給開發團隊，說多簡單，這多好，那多好，是時代的趨勢等等（我並不知道）。開發團隊熱火朝天的在學習，修改接口。慢慢的出現了不少問題,有些問題搞了很久也沒搞定（鳥菜啊，看了下，不難）。同時發現開發效率並不高，管理，運維十分艱難。一個月後，架構師隆重的宣佈，放棄node.js的方案，一個開發團隊十號人的一個月的努力沒有了.........

須要，程度

某公司想作商品進行檢索，百度了一下想使用lucene solr方案。團隊裏面沒有人會這個套東西，先安排了一我的學習，部署，學習如何使用。在一遍招人熟練使用lucene solr的....... —— 問了下負責人，請問下商品有多少數據，活躍數據多少。 負責人：100萬數據，活躍數據10萬 鳥菜啊： 直接用MySQL 全文搜索。與 lucene的功能差很少。都是用的倒序索引，性能方面都差很少。數據量又不大，不須要分佈式。何須了。團隊裏面又有MySQL dba，不用招人 負責人採用了建議,棉猴的回饋效果不錯。

生態圈是否完善

一個擁有完善或者較完善生態園的技術，會讓你技術落地，問題解決，運維變得很是簡單。選擇一個較完善的技術，是十分重要的。通常來講 社區是否活躍，是否強大，使用羣體是否有必定規模，大型公司，大規模，高併發等複雜環境的實踐的技術，生態圈都比較完善。完善的生態圈，可讓你的入門，學習，研究，擴展，運維，管理的成本大大的下降

不完善的技術

1. 剛剛出來的技術
2. 沒有經歷大規模時間的技術
3. 太偏的技術
4. 只針對一個方面，可能在其餘方面十分欠缺。好比node.js

簡要生態圈對比

1. python的生態圈取向是小型項目與運維方面，java的生態圈取向軟件工程與分佈式方面
2. MySQL有比較健全的生態圈，好比客服端，壓測，備份，管理。在這些方面MongoDB很是弱，有些基本爲零

選擇重點特性，健全，完善的基礎功能的技術，而不是盲目追求大而全，一站式解決方案

Tidb剛剛出來的時候，就一羣人吹捧是比MySQL等等還要優秀的數據庫，是一個解決一切問題的分佈式數據庫等等。 可是公司也面臨數據庫分佈式的問題，而架構師與架構團隊沒法解決這個問題。Tidb的出現，立刻就去看文檔，發現Tidb是分佈式一站式解決方式，架構師簡單搭建，能用以後，而後就讓運維人員在測試環境搭建，結果由於Tidb實在太大，搭建了一個月（架構師的能力的確太差了），在測試的時候各類問題。最終直接放棄了。

須要與這門技術類型的定義是什麼，一個類型與一個定義的技術只選擇一個

好比在架構中已經存在了hibernate，可是你做爲技術負責人感受hibemate在處理複雜的sql十分麻煩，經過研究發現spring-jdbc比較適合，也最簡單。因而引入了spring-jdbc，可是不想大規模的修改代碼，又不想放棄hibernate的開發效率，因而存在兩種功能相同的技術框架。這樣形成團隊其餘開發人，沒法正確的定位那些業務，功能使用那個技術。出現使用混亂現象，代碼可讀性極差，問題定位慢等代價。

是否融入架構體系，是否對現有架構，設計，代碼影響大，替換的代價是否能承受

很簡單的一個例子，把MySQL替換從PostgreSQL，若是應用層所有是按照標準的sql語句，是沒有問題的。可是分頁操做是不同的。須要把全部的分頁的sql修改測試

社區是否活躍，是否強大，使用羣體是否有必定規模

社區活躍表明使用的人多，社區強大表明

某金融公司想使用MySQL NDB解決分佈式的問題，NDB的問題挺多，用戶羣體沒幾個，國內的MySQL 大神沒有一個深刻過，出現的問題沒法解決。並且MySQL NDB的商業服務比較坑。最後把 MySQL NDB換回來了，innodb引擎了。

是否有大型公司，大規模，高併發等複雜環境的實踐。

若是是bat，還有幾家大公司，已經大規模，複雜環境進行的實踐，那麼基本表示這個技術在基本使用，性能方面。沒有什麼問題。有問題，大公司都遇到了，會提供大量的文檔。基本把驗證技術可行性，大量的bug，運維，使用方面都大量的經驗，也會給。

開發者或者開發團隊是否有商業支持或者屬於商業公司

技術選型中，鳥菜啊認爲，這點是十分重要的。優秀的開源技術，須要優秀的程序員，可能須要優秀的開發團隊，這些優秀的程序員，都是人，須要生活，生活須要薪水，並且相對都比較高。穩定的生活，才能無慮的工做，保證開源產品的質量，保證人員穩定。也是這個緣由爲何不少優秀的開源項目都是大型互聯網或計算機公司產出的。

曾經是否在同樣的環境使用，運用過某個技術，或相似的技術

有多個選擇的時候，能夠把本選擇要點做爲重要的選擇因襲

選型者與團隊，有足夠的技術深度與技術廣度，足夠技術能力，編碼能力，分析能力，問題處理能力。是否對選型的技術，深刻了解，對原理了解，擴展，閱讀源碼

沒有足夠的技術深度與技術廣度，很難從上面的選擇要點分析那個是對的，那是適合等等。鳥菜啊在快五年的架構生涯中基本沒有選型失敗的事情。很大部分是鳥菜啊有必定的技術深度與技術廣度。

也許你技術選型對了可是隻是簡單的瞭解原理，沒有足夠技術能力，編碼能力，分析能力，問題處理能力，也沒法融入整個架構體系，沒法深刻優化，擴展，維護等。也是一種很是嚴重的時候。發現瞎貓遇見了死耗子或者跟大公司或者大神走，選型了可是沒法正確的使用技術，導致架構十分臃腫，龐大，難以維護，開發緩慢，問題定位困難等。

架構師與架構組把其餘的選擇都作了，可是沒有達到這一條基本是空話。

架構師與架構組把其餘的選擇都作了，可是沒有達到這一條基本是空話。

架構師與架構組把其餘的選擇都作了，可是沒有達到這一條基本是空話。

那些方面能夠下降入門，學習，研究，深刻，擴展，運維，管理的成本

1. 技術開源
2. 生態圈是否完善
3. 社區是否活躍，是否強大，使用羣體是否有必定規模
4. 是否有大型公司，大規模，高併發等複雜環境的實踐