架構元件，究竟要不要自研？

一、問題的提出

詢問架構元件，是否需要自研？

18年規劃系統介紹58到家的技術體系，15年加盟58到家後，架構部正好也是負責範圍的一部分，故談一談自己的想法，個人觀點：

• 如果公司業務不複雜，研發人數比較少，技術實力相對有限，一定不要自研架構元件
• 如果公司業務複雜，研發人數比較多，技術能力能夠勝任，建議自研部分架構元件

二、為什麼早期不建議自研？

早期研發人數較少，公司也不确定能走多遠，業務相對簡單，業務以“快速疊代”為最高優先級，此時一般會選擇“自己熟悉的技術”作為選型：

• 研發語言：熟PHP選PHP，熟Java選Java
• 資料庫：熟MySQL選MySQL，熟SQL-server選SQL-server
• 架構元件：熟Ruby on Rails選ROR，熟ThinkPHP選ThinkPHP，熟SSH選SSH
• …

此時千萬不要糾結選型，選自己熟悉的，業務以快速疊代為最優先，公司得先生存下來。

多說一句，此時對于技術合夥人的技術視野就有一定要求，如果早期方向不對，例如選擇了IOE或者微軟技術體系，等公司發展若幹年，資料量并發量上漲很多倍，成本以及未來的技術應對恐怕會有麻煩。

58同城早期選型是微軟技術體系，後來資料量增大，并發量增大，機器資料庫越來越多，性能扛不住，成本也扛不住（你猜一個SQL-server的licence一年多少錢？），後來老崔帶領大家轉型開源陣營：

• Windows -> Linux
• SQL-server -> MySQL
• C# -> Java

雖然短痛了1-2年，但長遠來說，絕對是正确的決策。

如今，如果你再創業，選雲，選LAMP或者SSH，八成不會走太大的彎路。

三、随着規模的擴大，為什麼要控制技術棧？

随着業務越來越複雜，研發人數越來越多，如果每個leader都選擇自己擅長的架構，就會出現這樣的情況：

• 站點架構，team A用着SSH，team B用着Spring+SpringMVC+Mybatis
• 服務架構，team C用着REST，team D用着dubbo，team E用着thrift
• 資料庫通路，team X用着mybatis，team Y用着DAO，team Z用着jdbc

對于整體而言，跨部門的調用越來越麻煩，重複造的輪子越來越多，技術效率會逐漸降低，研發+測試+運維成本都越來越高。

第一個觀點：即使不自研，技術棧也請盡量統一。

四、統一了技術棧，為什麼建議淺淺的封裝一層？

統一了技術棧以後，如果不封裝，redis官方Java用戶端Jedis可能有這樣一些接口：

String Memcache::get(String key)

String Memcache::set(String key, Stringvalue)

String Memcache::del(String key)

淺淺的封裝一層，會變成這樣：

String 58DaojiaKV::get(String key) {

         String result = Memcache::get(key);

         return result;

}

String 58DaojiaKV::set(String key, Stringvalue) {

         String result = Memcache::set(key, value);

String 58DaojiaKV::del(String key) {

         String result = Memcache::del(key);

這有什麼好處呢？

• 對上遊屏蔽底層實作的細節，調用方不用關注緩存是memcache還是redis，調用方隻關注58DaojiaKV
• 底層變化的時候，對上遊透明，當memcache不能滿足需求，要切換為redis時，所有調用方不需要大的變化，更新一個最新的58DaojiaKV即可，58DaojiaKV的接口不變，實作變為：

         String result = Jedis::get(key);

         String result = Jedis::set(key, value);

         String result = Jedis::del(key);

• 統一實作一些通用的功能，就不需要每一個上遊更新了，例如，要實作一個緩存通路時間統計的功能，所有調用方不需要大的變化，更新一個最新的58DaojiaKV即可：

         Long startTime = now();

         String result = Jedis::get(key);

         Long endTime = now();

         reportKVTime(startTime- endTime);

同理，如果要實作統一的告警，調用鍊跟蹤，SQL執行時間，也可以用類似的方法。

第二個觀點：第三方庫，不但要統一，還可以淺淺的封裝一層，預留未來的擴充性。

五、随着規模的進一步擴大，為什麼需要适當的造一些輪子？

業務進一步發展，研發團隊進一步擴張，雖然使用了統一的技術棧，但不同研發團隊的痛點是極其類似的：

• 有站點，監控服務的可用性，處理時間監控需求
• 有告警需求
• 有自動化釋出，自動化運維需求
• 有服務治理，服務自動發現需求
• 有調用鍊跟蹤需求
• 有SQL監控需求
• 有系統層面資料收集與可視化展現的需求

此時，開源的架構可能滿足不了需求了：

• 開源架構/元件太重了，我們需要的可能隻是一個輕量級的架構/元件
• 開源架構/元件，隻能滿足我們的一部分需求
• 不了解開源架構/元件的設計理念，要二次開發成本更高（維護dubboX的同學，維護資料庫中間件Atlas的同學可以出來說兩句）
• 有些通用的需求是和業務緊密結合的，開源架構/元件可能滿足不了

此時，如果技術實力具備，可以統一研發一些架構群組件，解決所有技術團隊的通用痛點，滿足所有技術團隊的通用需求。

未來介紹監控平台、服務治理、調用鍊跟蹤系統、資料收集中心的時候，大家能夠更深刻的了解到“造一些輪子”的好處。

第三個觀點：适當造一些輪子。

六、58到家自研的架構元件有哪些？

通用架構+服務：

• WEB架構，Daojia-Web-Framework，DWF
• Service架構，Daojia-Service-Framework，DSF
• 消息隊列，Daojia-Msg-Queue，DMQ

基礎元件：

• 緩存通路元件DMemcache，DJedis
• 資料庫通路元件DAO
• 分庫分表元件DShard

還有一些日志，消息的元件，這些元件的架構與細節，未來再和大家細聊。

七、總結

架構元件，是否需要自研？

初期建議：不自研，用熟悉的，業務快速疊代為優先，需要一定技術視野。

長遠建議：

• 統一技術棧
• 淺淺封裝一層

• 适當造輪子

  本文轉自“架構師之路”公衆号，58沈劍提供。