快狗叫車CTO沈劍：開源框架VS自研框架，企業該如何選擇？

【導語】 快狗叫車（原58速運），是以短途貨運為切入點，實現基於使用者位置下單、司機系統派單、線上支付及服務評價的全流程交易閉環的同城貨運交易服務平臺。為了解快狗最新的技術發展，本期名人堂專訪嘉賓就是快狗叫車CTO沈劍，他將和我們分享如何有效快速實現資料庫架構設計的一致性最佳實踐。

【嘉賓簡介】

沈劍：網際網路架構技術專家，“架構師之路”公眾號作者。曾任百度高階工程師，58同城高階架構師，58同城技術委員會主席。15年調至58到家任高階總監，技術委員會主席，負責基礎架構，技術平臺，運維安全，資訊系統等後端技術體系搭建。現任快狗叫車任CTO，負責快狗叫車技術體系的搭建。本質，技術人一枚。

好的架構不是設計出來的而是演進出來的

大多數企業在建立之初，架構並不是完整的，都是隨著業務的發展和需求一步步演進而來的。

沈劍表示自己曾面試過 “紙面架構師”，面試的時候總是拿著同一套架構方案，往不同的業務或者同一個業務的不同階段上生搬硬套，懂技術的面試官其實對這其中的套路心知肚明。架構是服務於業務的，旨在解決問題，不同的業務有不同的特點，應當用最合適的業務架構來解決不同的業務問題。業務的不同階段，訴求與特點也不一樣，不能期望用同一套架構方案來解決所有問題。

拿58同城和快狗叫車舉例，兩者的業務特點不同，架構設計時考慮的點也不一樣。58同城的本質是一個資訊平臺，它的特點是使用者多，資料量大，併發量大，架構設計需要重點考慮容量設計，如何保持好擴充套件性，承載海量的資料與併發。而快狗叫車是一個線上叫車業務平臺，它的特點是閉環，在下單、推送、搶單、中單、完單、支付這整個流程中都是封閉的，對架構的穩定性要求更高。

如果58同城釋出不了帖子了，不影響使用者瀏覽帖子、搜尋帖子，並不影響58同城的整體業務流程。但快狗叫車由於是閉環訂單系統，中間任何一個環節出現問題，這個訂單業務就無法正常執行。

快狗叫車至今經歷了四年的發展，對比當下的架構與四年前的架構，是很大區別的。初期公司業務的發展有很大的侷限性和未知性，這就要求架構必須能夠“快速迭代”，能夠跟上的業務的需求變更。但隨著時間推移，資料量日益增加，併發量也越來越高，之前架構的功能無法滿足現階段業務的要求了，這就需要重塑架構和優化架構，這個過程就是架構隨著業務的發展，而進行同步演進。

開源框架vs 自研框架

開源技術在當下掀起了一陣風潮，有不少企業在框架選擇方面也開始走向開源，而面臨開源和自研框架企業該如何選擇呢？其實可以總結為以下兩點：

1、如果公司業務不復雜，研發人數比較少，技術實力相對有限，一定不要自研框架元件；

2、如果公司業務複雜，研發人數比較多，技術能力能夠勝任，建議自研部分框架元件；

早期企業投入研發的人數較少，公司的未來發展方向也不是很確定，業務相對簡單，架構應以快速迭代為目標，這時企業應該以“自己熟悉的技術”作為選型，在研發語言方面，熟悉哪款程式語言便選擇哪款語言；在框架元件方面：熟悉Ruby on Rails選ROR，熟悉ThinkPHP選ThinkPHP……等等，這個時期不需要糾結選型，而是選擇公司擅長的熟悉的，以能進行快速迭代為優先，以能夠及時跟上業務的發展為目標，讓公司先生存下來。

而隨著業務需求變化，研發人員的增加，如果每個leader都選擇自己擅長的框架，就會出現這樣的情況：

（1）站點框架，team A用著SSH，team B用著其他；

（2）服務框架，team C用著REST，team D用著dubbo，team E用著thrift

（3）資料庫訪問，team X用著mybatis，team Y用著DAO，team Z用著jdbc

（4）…

對於整體架構而言，跨部門的呼叫越來越麻煩，重複造的輪子越來越多，技術效率逐步降低，研發、測試和後期運維成本都越來越高。

此時，可以適當的造一些輪子，來解決各個研發團隊的通用痛點：

（1）有站點，監控服務的可用性，處理時間監控需求；

（2）有告警需求；

（3）有自動化釋出，自動化運維需求；

（4）有服務治理，服務自動發現需求；

（5）有呼叫鏈跟蹤需求

（6）有SQL監控需求

（7）有系統層面資料收集與視覺化展現的需求；

此時開源的框架可能滿足不了業務發展的複雜化需求，如果研發技術實力具備，可以統一研發一些框架和元件，解決所有技術團隊的通用痛點，滿足所有技術團隊的通用需求。

資料庫架構中一致性最佳實踐

在企業中，尋求發展必然就會產生變化，業務會越來越複雜，資料量和併發量會越來越大，所以資料庫往往最先成為系統的瓶頸。而要解決資料庫的瓶頸問題，最常用的優化手段是：主從同步，讀寫分離；增加快取；資料冗餘，反正規化設計；分庫儲存更大量的資料等等。

但使用了上述優化手段之後，會帶來新的問題：

（1）主從的延時，容易導致資料不一致；

（2）資料庫與快取，也容易出現資料不一致；

（3）冗餘多份的資料，也可能出現資料不一致；

（4）分庫之後，多庫無法保證一致性；

這些都是在架構演進過程中很常見的的問題，也是大家在進行架構設計過程會遇到的問題，而這些問題該如何解決呢？請繼續看下去！

由 IT168 旗下 ITPUB 企業社群平臺主辦的第十屆中國系統架構師大會（SACC2018）。2018 年 10 月 18 日，核心業務系統架構設計專場，快來享受技術人的盛宴。本次資料庫架構專場會有：

（1）快狗叫車的架構師，會有一致性的專題演講

（2）騰訊的架構師，會有NoSQL方面的分享

（3）瓜子的架構師，會有業務系統資料庫架構設計的分享

（4）最重磅的，資料庫大神，阿里的何登成老師，會分享阿里自研的X-DB的架構設計

（5）…

這些話題，能夠讓大家瞭解到，典型業務資料庫架構如何設計，如何進行資料庫與NoSQL的設計折衷，如何解決資料庫架構設計中遇到的典型問題，也能夠了解到資料庫核心。

更多的細節，歡迎來SACC，資料架構設計專場進行面對面的交流！本專場日程如下，精彩議題持續更新中！

搶票入口： http://sacc.it168.com/goupiao.html 

  

▲長按識別二維碼或點選閱讀原文 立即購票

大會官網： http://sacc.it168.com

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/31547542/viewspace-2215217/，如需轉載，請註明出處，否則將追究法律責任。