新用戶登錄后自動創建賬號
登錄CSDN年度技術盛宴 “SDCC 2015中國軟件開發者嘉年華”將于2015年11月19-21日在北京召開。
本期我們采訪的講師是來自快的打車架構師王小雪,他在阿里巴巴工作了4年。從無到有組建了快的打車基礎服務團隊,主持研發、引進了眾多基礎框架和服務,推進快的架構升級,從穩定性、可用性、性能、安全、監控多方面體系化的建設了快的高可用架構。對高并發分布式系統架構、實時數據處理、網絡通信和Java中間件有比較深厚的經驗積累。
1,請簡單介紹下您和目前的工作,以及關注的領域、技術積累。
王小雪:我畢業后在深圳工作了4年,然后在阿里巴巴工作了4年,2014年年初到快的打車工作,在快的基礎研發部門負責基礎服務和中間件的工作,例如分布式消息、服務、無線開放平臺、數據平臺等,參與了實時計算平臺、監控、安全、數據架構方面的建設,還有其他方面的事情,主持了快的多個大型營銷活動的技術架構。
快的和滴滴合并后,按照集團的分工,最近一段時間,原快的基礎研發部門十幾個人全部轉換了工作方向,基礎研發部門后面的工作重心是集團的大數據架構、在線數據實時處理和機器學習。這對我們來說是一個新的挑戰,所以目前我們的工作重心和學習方向就是在這一方面了。
關于關注的領域,當前我比較關注實時計算、機器學習、容器與虛擬化這三個大方向,也算是這個行業未來的熱門和趨勢吧。
關于技術的積累,我在阿里巴巴工作之前主要是負責企業系統的,雖然沒有什么太大的流量和性能挑戰,但是對于需求分析、產品思維、擴展性設計方面的要求還是有些要求的。在阿里巴巴我先后經歷了搜索、無線、大流量Web系統等方面的工作,自己也比較喜歡學習和思考吧,對阿里的很多中間件源碼都深入的研究過,在高并發大流量分布式系統架構、Java中間件(例如分布式RPC、消息、通信、容器、模板引擎等)、實時/流式計算和存儲等方面有些積累,對Storm和HBase有過比較深入的研究。
2, 您對架構是怎樣的理解?以及您對于架構師是如何定義的?
王小雪:架構和架構師我分開來說:
其實我很少跟別人談論架構和架構師應該怎么做,因為這個話題比較容易引起口水戰,但你問到這個問題我就說下我的拙見吧。
我想很多人對架構這兩個的定義是比較模糊的,這里我只說下我的個人看法,沒有一種架構能解決所有問題,但大的指導原則總是在的,我認為的架構要點很樸素,事實上每個展開是一個很大的話題:
可用性:這是最重要的,系統不可用什么都是浮云。這里要考慮的點很多,例如單點、性能瓶頸、可能的風險、快速發現故障、快速定位問題原因等
擴展性:基于高度的復用抽象,能夠快速靈活的滿足業務需求
伸縮性:系統服務能力是否可以隨著加機器得到線性的提升
安全性:不給外部鉆空子的機會
技術棧:在一個公司里,過多的語言選型或者同一個領域過多的架構選型,不是一件好事,除非是的確有必要,否則會花巨大的成本在內部系統整合上,因為語言不一樣,很多東西很難復用,也很難集中力量對某個語言生態有深度的掌握,這是沒有必要的。不是說架構師不應該多學習幾門編程語言,而是要注意公司內部多語言開發的成本與內耗,目前快的打車系統以java為主,也在用python、golang、c,但基本都是工具的開發。
以下是我認為架構師在設計時應該秉承的一些原則吧。
業務為王:技術只是手段,業務才是根本,這句話可能對技術人有些打擊,但這是事實。不能為了玩技術而技術,要解決實際的問題,直接或間接的產生技術價值。
發散思考:架構不是僅解決問題就行。無論大小或簡單復雜,有些點是必須要考慮的:例如單點、性能瓶頸、可能的風險、快速發現故障、快速定位問題原因、快速響應業務需求。
適度設計:架構是不斷迭優化的。特別是在互聯網這個行業,充滿了很多機遇,也充滿了很多不確定性,業務經常需要快速試錯,發展速度也相當快。不能想當然的設計一套大而全的方案,期望解決所有的問題,而要隨著業務的場景和發展,秉承一些基本的設計原則同時,解決最重要的問題。
3,你認為具備哪些素質才能稱為是出色的架構師?
王小雪:出色的架構師 = 一個優秀的程序員+半個產品經理+半個項目經理。
對應的能力:扎實的技術,較好的產品思維,較好的溝通能力與管理能力。
4,這幾年快的,有哪些技術架構的節點性事件?能否就各階段從穩定性、可用性、性能、安全、監控等多方面來闡述快的高可用架構。以及作為架構師,你的工作重點有哪些?
王小雪:你這是一句話問好幾個問題啊,而且都挺復雜,我簡單說下吧,更詳細的在分享上會有。快的打車的技術大概分為3個階段:基本功能可用、核心鏈路性能優化、體系化的架構設計。快的打車的技術架構從2014年4月份開始做體系化的設計。
我們將系統按照業務域做了拆分,實現了服務化的改造,以前快的系統全都在一個大工程里,核心功能和非核心功能相互影響,穩定性不是太好,服務化后各個業務系統都是獨立的,可以分別開發、發布、擴容,系統的穩定性和開發效率得到非常大的提升。
我們在系統全局的容量規劃上也做了很多事情,我們壓測出線上系統的容量極限,通過監控記錄各個量級下的系統指標,能夠比較精確估算我們是否要擴容或者縮容,因此面對大型營銷活動或者快速增長的業務量,我們可以做到提前規劃系統的服務能力。
我們消除了所有的單點,仔細排查了各個節點的故障恢復能力,比如網絡閃斷重連后,這個節點或組建是否能正常工作,review每個應用的JVM配置并且有針對性的GC優化。
我們還在做數據層面做了很大的改造,分庫分表、基于binlog的數據同步平臺、基于HBase的實時數據中心。
大概的說一下。網絡層面,我們通過阿里云盾防范DDos攻擊。應用都做了基本的XSS、CSRF、SQL注入等防范。在無線請求接入方面,我們建設了無線網關,對訪問者IP、用戶ID都做了流量限制,對后端服務做了容量保護。我們所有內部系統的登錄都是需要真實的員工手機驗證的。我們建設了風控平臺,打擊作弊行為。
我們收集了全網日志,并且將請求鏈路上的日志通過標識串聯起來,通過ElasticSearch實現實時索引和查詢,極大的提高了故障定位的效率。
我們建設了自己的實時計算平臺,在這個平臺之上我們又建設了監控平臺,我們能夠分鐘級別知道每個系統的運行情況和資源開銷,知道當前時間的業務數據,比如當前這一分鐘的乘客發單量、司機接單量、支付量等等。可以看到歷史數據,可以觀察選定時間段的曲線圖。
這個過程我們整個基礎研發團隊做了非常多的努力,大家一起齊心協力做了很多事情,也取得了不錯的成果。這里面我的主要工作是基礎服務和中間件,因為做上層改造必須要有下層的可靠支持,例如NIO通信、文件存儲、分布式協調服務、服務框架、分布式消息、配置中心、數據同步、無線網關等,推動這些基礎服務在業務系統落地;另外也協同CTO與基礎研發負責人一起制定公司的技術規劃,參與其他基礎研發工作的設計,參與一些應用架構的優化。
5,可否請您簡單介紹一下快的整體架構的一些架構特點?
王小雪:高頻的地理位置計算;大量的TCP長連接通信;大量的數據存儲;系統實時性要求很高,能夠緩存的場景很少,必須快速定位故障;時刻要面臨刷單、攻擊等問題。
6,快的成立已來,業務高速發展的同時,研發團隊規模也是有了驚人的變化,作為從無到有的團隊組建者,最大的挑戰是什么?以及,現在您所負責的研發團隊人員搭配是怎樣的?
王小雪:最大的挑戰倒不是解決系統問題,而是尋找合適的人才。
基礎研發分為:中間件和基礎服務,業務架構,數據架構,監控,運維。雖然做了很多事情,實際上快的基礎研發團隊人很少,整個基礎研發團隊到現在包括運維只有20個人,但是大部分人是去年年底和今年剛來的,這其中包括7個我們校招過來的應屆生。去年最辛苦的時候只有10個人:基礎研發總監,中間件和基礎服務2個人,業務架構1個人,數據架構2個人(包括DBA),監控1個人,IT和運維一共3個人,我負責中間件和基礎服務,監控原來也在我這里,后來我實在忙不過來就剝離出去了,我現在下面也只有5個人。去年的時候我們非常的辛苦,凌晨下班非常正常,經常通宵,大家雖然分工明確,但是互相幫忙互相鼓勵,結下了非常深厚的兄弟情誼。
7,如今,您又是如何安排自己的新技術學習、研發團隊管理、編程、生活等時間的?
王小雪:我一直都在寫代碼,不是為了練手,就是實實在在的編碼,做一些核心設計和review方案。簡單說吧,白天編碼和團隊同學溝通,事實上也談不上團隊管理,大家都是非常靠譜和成熟的工程師,自驅性很強,我只是關注大家的工作和學習方向就行,當然也兼做一些后勤的工作:)比如給團隊同學介紹女朋友啊;晚上學習自己感興趣的東西;生活就在周末。這樣的安排我自己覺得還行。
8,您在本次SDCC 2015大會上想分享的話題是?
王小雪:快的打車架構實踐。在快的從小到大的過程中,我們走過的路,我們踩過的坑,我們的笑,我們的哭,我愿意真誠的分享給大家,給所有在創業路上奮斗的同行。
9,您最期待在SDCC 2015大會上看到哪些內容?
王小雪:容器和虛擬化;在線學習;創業公司的干貨實踐。
架構師應該戰斗在一線。不是要事無巨細的解決所有問題,而是要保持對業務的敏感度,否則居高堂之上坐而論道,你怎么能設計一個接地氣的方案去解決問題呢?
架構師應該理解業務。架構師是業務和技術的紐帶,對業務充分了解才能解決業務痛點。
架構師應該做好權衡。架構設計事實上也是一種平衡的藝術,沒有固定的模式判定哪個方案是最優解,很多事情都具有兩面性,利弊的取舍得看問題場景和業務的發展現狀。
由CSDN舉辦的 SDCC 2015中國軟件開發者嘉年華將于11月19-21日在北京舉行,本次大會涵蓋:新型數據庫、編程語言、工具與平臺、產品與設計、前端開發、算法、微信開發、架構實踐、安全等九大分 論壇,屆時國外知名講師將分享所在領域的最佳實踐。