框架元件,究竟要不要自研?
一、問題的提出
詢問框架元件,是否需要自研?
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);
return result;
}
String 58DaojiaKV::del(String key) {
String result = Memcache::del(key);
return result;
}
這有什麼好處呢?
- 對上游遮蔽底層實現的細節,呼叫方不用關注快取是memcache還是redis,呼叫方只關注58DaojiaKV
- 底層變化的時候,對上游透明,當memcache不能滿足需求,要切換為redis時,所有呼叫方不需要大的變化,升級一個最新的58DaojiaKV即可,58DaojiaKV的介面不變,實現變為:
String 58DaojiaKV::get(String key) {
String result = Jedis::get(key);
return result;
}
String 58DaojiaKV::set(String key, Stringvalue) {
String result = Jedis::set(key, value);
return result;
}
String 58DaojiaKV::del(String key) {
String result = Jedis::del(key);
return result;
}
- 統一實現一些通用的功能,就不需要每一個上游升級了,例如,要實現一個快取訪問時間統計的功能,所有呼叫方不需要大的變化,升級一個最新的58DaojiaKV即可:
String 58DaojiaKV::get(String key) {
Long startTime = now();
String result = Jedis::get(key);
Long endTime = now();
reportKVTime(startTime- endTime);
return result;
}
String 58DaojiaKV::set(String key, Stringvalue) {
Long startTime = now();
String result = Jedis::set(key, value);
Long endTime = now();
reportKVTime(startTime- endTime);
return result;
}
String 58DaojiaKV::del(String key) {
Long startTime = now();
String result = Jedis::del(key);
Long endTime = now();
reportKVTime(startTime- endTime);
return result;
}
同理,如果要實現統一的告警,呼叫鏈跟蹤,SQL執行時間,也可以用類似的方法。
第二個觀點:第三方庫,不但要統一,還可以淺淺的封裝一層,預留未來的擴充套件性。
五、隨著規模的進一步擴大,為什麼需要適當的造一些輪子?
業務進一步發展,研發團隊進一步擴張,雖然使用了統一的技術棧,但不同研發團隊的痛點是極其類似的:
- 有站點,監控服務的可用性,處理時間監控需求
- 有告警需求
- 有自動化釋出,自動化運維需求
- 有服務治理,服務自動發現需求
- 有呼叫鏈跟蹤需求
- 有SQL監控需求
- 有系統層面資料收集與視覺化展現的需求
- …
此時,開源的框架可能滿足不了需求了:
- 開源框架/元件太重了,我們需要的可能只是一個輕量級的框架/元件
- 開源框架/元件,只能滿足我們的一部分需求
- 不瞭解開源框架/元件的設計理念,要二次開發成本更高(維護dubboX的同學,維護資料庫中介軟體Atlas的同學可以出來說兩句)
- 有些通用的需求是和業務緊密結合的,開源框架/元件可能滿足不了
- …
此時,如果技術實力具備,可以統一研發一些框架和元件,解決所有技術團隊的通用痛點,滿足所有技術團隊的通用需求。
未來介紹監控平臺、服務治理、呼叫鏈跟蹤系統、資料收集中心的時候,大家能夠更深刻的理解到“造一些輪子”的好處。
第三個觀點:適當造一些輪子。
六、58到家自研的框架元件有哪些?
通用框架+服務:
- WEB框架,Daojia-Web-Framework,DWF
- Service框架,Daojia-Service-Framework,DSF
- 訊息佇列,Daojia-Msg-Queue,DMQ
基礎元件:
- 快取訪問元件DMemcache,DJedis
- 資料庫訪問元件DAO
- 分庫分表元件DShard
還有一些日誌,訊息的元件,這些元件的架構與細節,未來再和大家細聊。
七、總結
框架元件,是否需要自研?
初期建議:不自研,用熟悉的,業務快速迭代為優先,需要一定技術視野。
長遠建議:
- 統一技術棧
- 淺淺封裝一層
- 適當造輪子