框架組件，究竟要不要自研？
一、問題的提出
詢問框架組件，是否需要自研?
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;
- }
- 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
還有一些日志，消息的組件，這些組件的架構與細節，未來再和大家細聊。
七、總結
框架組件，是否需要自研?
初期建議：不自研，用熟悉的，業務快速迭代為優先，需要一定技術視野。
長遠建議：
- 統一技術棧
- 淺淺封裝一層
- 適當造輪子
【本文為51CTO專欄作者“58沈劍”原創稿件，轉載請聯系原作者】
