GopherChina第一天小結

GopherChina第一天小結

今天參加了Asta舉辦的第五屆GopherChina,第一天參加完,很有感覺,晚上回來趁着還有記憶,來作一下記錄。mysql

寫在前面

一早從9點開始,一天下來一共八個主題,各個主題都有本身的特點,所有聽下來也是挺不容易的。這些主題有大到說框架,也有小到說具體的某個包的使用的。golang

參會

一早上真心起的比上班還早,早早就過去佔了個位子。以前也參加過一些技術大會,最擔憂的就是講師講說的主題變成某個公司的宣傳分享。咱們聽衆大都懷着學習的心態來的,都但願能在技術大會上獲得的是一些乾貨,所謂乾貨,就是經驗。就是說並非你用Golang作了多牛逼的事情,而是你怎麼用Golang作了多牛逼的事情,在作了多牛逼的事情的過程當中有哪些經驗只談,哪怕只有一個經驗分享,能讓咱們在實際工做中繞開這個坑,也或許就值回票價了。redis

大型微服務框架設計實踐

這個是我司滴滴歡總的分享。其實以前我在內部已經聽過一遍這個分享了,當時聽完以後就對這個在咱們外賣部門踐行下來的微服務框架的思想、實現都很是感興趣。還強烈建議其餘公司的小夥伴必定要仔細聽歡總這個分享。今天第二次聽,PPT已經較以前內部分享的潤色很多,也作了一些公司業務的脫敏處理。不過總體聽完,讓我對業務框架的認識又深了一層。算法

整個PPT大體是從框架開始提及,從框架的進化史,說到框架的風格(從配置->約定->DSL->容器化),從而引入「操做系統」的概念,表述說如今的服務框架,正愈來愈向操做系統的方向發展。我如今還記得今天杜歡在大會上表達的一些對框架的言論,好比業務框架應該符合原則「Rule Of Lease Power」,即恰好夠用。好的框架須要屏蔽業務無關的通用技術細節,讓一些不可靠的調用變得可靠起來。這些言論真是不能贊成更多。框架和業務代碼的關係就是一個封閉開放的原則,框架須要把不想對業務代碼開放的部分給儘量封裝掉,讓業務的思惟負擔徹底聚焦在具體的業務代碼中。sql

參會

然後歡總就開始聊起了他親手寫的微服務框架的一些實現要點。這些要點雖然沒有具體的代碼展現,不過基本也把如何實現都說了一下。首先框架與業務正交,經過提供一系列工具鏈,能自動生成最初的項目模版,並經過代碼注入一些框架須要的代碼。這個是說的對於框架,完善的工具鏈是能減輕不少業務的負擔的。其次,他的框架將全部底層實現都進行了封裝,包括對mysql,redis,kafka等的封裝。其中還特地說了他的redis封裝,基本就是按照redis的command 文檔進行了一輪封裝。還有,他提到的對http和rpc作劫持的工做,我以爲這個部分不是全部的業務框架設計者都能想到的,他包裝了http.Handler,也對thrift的序列化流程進行了劫持,具體在劫持過程後,能有效的進行context注入,請求回放,全鏈路壓測等工做。具體如何使用FSM實現thrift的protocol這塊就沒大聽懂了。接着,就是提供了跨服務邊界的context。這塊下午在b站毛總的分享裏面也提到了,基本上跨服務的context控制是golang微服務框架的標配了把。實現跨服務context以後,對TimeoutContext的使用就能作防雪崩的事情,每一個服務調用都會自動計算超時時間,能有效防止雪崩效應。數組

最終歡總很自豪的給咱們展現了這個框架服務的業務收益。緩存

參會

從歡總這個分享中,基本能對Golang的微服務框架所必須的特性都會有了很好的瞭解了。網絡

如何用Go打造高性能路徑規劃和ETA引擎

這個也是我今天很期待的一個topic之一。以前半年在路網的項目中也投入了很多精力。對路網的生產,製造,使用流程都有了一些瞭解。其實我很想了解下Grab中路網在整個項目工程中的生產、服務、變動方面的東西。可是整個PPT聽下來,和我想聽到的描述方向仍是有一些不一樣的。架構

胡泊描述的這個topic主要描述的是Grab地圖團隊中使用Golang作了哪些事情。他們使用OSM作地圖數據,經過軌跡數據和算法來補充OSM中缺失的路網數據。他們稱之爲路網學習。而後軌跡數據和路網數據的mapmatch的匹配也是徹底由golang實現,具體實現使用的算法給咱們展現了很複雜的算法PPT,徹底聽懵了。在司機軌跡定位處理和提供路況服務工程這塊,花了好幾個PPT說了下Grab在軌跡處理這塊的一些優化點,好比對數據進行壓縮,將數據存儲分離,建立緩存層,引入大數據spark streaming處理等。後續又展現了路徑規劃和ETA的算法邏輯。併發

這個主題整個聽下來只能用一臉懵逼來形容了。感受聽了一個小時的算法和機器學習知識的課程。最後給的Go在GEO領域的一些開源的項目卻是一大亮點,後續若是還有機會作路網相關的工做,能夠研究一下這些項目。

參會

TiDB的Golang實踐

早就聽聞TiDB的大名,也沒有機會在項目中實踐使用。此次的分享,總體聽下來對TiDB的一些架構設計也有了一些模模糊糊的印象了。

首先姚維先介紹了下 TiDB的 SQL處理層的模型結構。感受和mysql的SQL解析層的邏輯同樣。主要是建立AST樹,對這個樹進行語法驗證等處理。

然後畫風一轉,聊到了分佈式系統的測試,像TiDB這種ToB的產品對測試要求更是嚴格了,由於一旦被企業使用,沒法輕易進行升級。分佈式系統的Error能夠出如今任何地方,軟件,硬件網絡等都有可能出現問題,因此如何模擬這些各類場景下的錯誤是很重要的。姚維介紹了Pingcap內部的一個Schrodinger平臺,薛定諤平臺。不過沒有很好展現一下這個平臺的使用和有點。然後就花了大篇幅描述了一下FailPoint的測試注入。

咋聽下,我沒有能立馬理解FailPoint的意思,模糊的理解到這個意思是以某種方式來模擬各類異常狀況,好比panic,之類的錯誤Mock的方式。後來回家以後又去網上查了查,TiKV 源碼解析(五)fail-rs 介紹大體說的也是這個意思。

參會

聊完failpoint以後,姚維很乾貨的分享了他們是如何測試代碼是否又goroutine泄漏的。原理說白了就很簡單,使用runtime.Stack在測試代碼運行先後計算goroutine數量,固然我理解測試代碼運行完成以後是會觸發gc的。若是觸發gc以後,發現還有goroutine沒有被回收,那麼這個goroutine頗有多是被泄漏的。這招是我以爲從這個分享學到的最實用的一招之一。姚維能將一個看起來很不容易解決的問題用最直接的語言描述出來,我喜歡這樣的分享方式。

再後面,就說到了TiDB是如何使用Chunk結構來存儲表數據的。基本上在我理解就是使用Apache Arrow的方式,將TiDB的內容列式存儲到Chunk結構中。一樣的,姚維對Chunk的描述,引入,演變過程都用最直接的語言描述的很是清楚。

Testing; how, what,why

這個Dave大神的一個分享,不過期間安排的不是很好,下午一點,這是困點時間,再加上是英文闡述。我不得不認可,我在一個小時中間,大概打盹了半個小時。。。

Dave人很nice,貼心的把PPT的關鍵字都粗體。基本上Dave的整個Topic是在告訴你們如何進行單元測試,如何看測試覆蓋率,測試的重要性,如何纔是合理的測試用例。基本上他也是建議使用如今比較流行的數組測試,一個大數組中存儲不一樣的輸入,輸出,而後對這個大數組循環判斷輸入是否能產生指望輸出。

我打盹以前聽的內容是如何寫單元測試,打盹以後聽到的內容是測試是很是重要的。中間的部分,等PPT放出來的時候再具體看看把。

感受Dave大神說的比較務實,徹底是站在工程師編寫代碼的角度來講如何寫測試用例,沒有平常聽到的架構、設計等仍是稍微有點感動。可能基本功纔是體現工程師素養的地方把。

Go業務基礎庫之Error & Context

這個是B站毛劍的分享。毛總上臺以前,臺下響起了雷鳴般的掌聲,由於B站因爲泄漏事件正處在焦點。毛總上臺第一句話但願你們提問緩解不要問一些不合適的問題。。。全場笑然。

毛總的乾貨仍是不少的,他的主題也是很踏實的,也是從業務框架的角度來講,B站是如何處理Error和Context的。

關於Error,首先是使用WithStack保存堆棧信息,以方便查找根因。而且詳細告訴咱們B站的大倉庫是如何處理error的規則的。基本上聽下來,就是對全部調用第三方的服務的錯誤都須要第一時間對error進行wrap,對於go-common庫以前的error,統一在go-commmon層進行wrap處理。然後,再三告訴你們他在錯誤處理方面的一些最佳實踐。包括什麼時候打錯誤日誌,什麼時候直接透傳,如何集中處理併發goroutine的錯誤,如何規劃錯誤代碼和錯誤信息等。總體聽下來,毛總的這些建議,恐怕須要是從架構師視角才能得出來的乾貨。

參會

關於Context,實際上是在業界討論很是多的了。總結下來,毛總對Context的觀點有幾個,首先強烈建議顯示傳遞,即函數第一個參數爲context。其次,強烈建議context覆蓋全業務,包括日誌,mysql,緩存等。再次,context的超時控制須要在流量入口處設置,而且越早設置越好,甚至說到了若是能提前到LSB路由分發以前設置會更好。還有,Context中存儲的元數據都須要有哪些,包括調用者,調用地址,traceid等信息。在goroutine中如何傳遞context等都是很好的B站實踐總結。

最終總結了下業務基礎庫的思考。

乾貨滿滿,問答環節也沒人不識相的提起一些不合適的問題。這一part愉快結束。

Go同步和併發設計模型

這場嚴重超時,基本上講了一個小時多時間。主要是作了一下Golang中鎖、併發處理、內存模型的梳理。雖然講的很細,不過我我的並不喜歡這樣的梳理描述。一個是比較冗長,另一個是沒有結合具體的業務場景來講,光總結仍是有點虛了。

這個topic一共五個話題,基本同步原語,擴展同步原語,原子操做,channel,內存模型。基本就是把mutex,RWmutex,Cond,channel等併發相關的結構都梳理了一遍。

到最後已經沒有很仔細聽了,整體感受有點尷尬。

百度App Go語言實戰

這個topic其實更像是百度效能平臺的介紹。

首先百度對內部項目都會有一個工程能力評估圖,對代碼規範、測試、上線等流程都有本身的評估標準。其次介紹了一下百度內部對開發規範,開發工具,代碼規範的介紹。比較有乾貨的是介紹了一下在實現開發框架server遇到的點,好比建立了一個goroutine池來控制goroutine的數量。server端出現TIME_WAIT過多問題的處理。然後介紹了一下百度的構建體系,如何自建鏡像等。具體的實現邏輯沒有細想,不過感受百度內部爲了保證golang的代碼交付質量,作了不少工做。最後還介紹了百度的代碼檢查工具,基本上也是使用AST解析代碼,並和規則匹配來檢查的。

用Golang搭建實時音視頻雲

這個是最後一個主題,因爲前面的延遲,時間已經比較玩了,基本上會場上人數較少了一半多了。

具體的內容我也已經沒有很高的注意力聽了,基本上是聊的golang在WebRTC協議的服務端實現。上來先是例行解釋下爲什麼技術選型使用golang,然後對WEBRTC的協議進行了說明,接着大體說了一下他們實現的具體架構,和他們遇到的問題。

比較有印象是他們遇到的問題。他們整個團隊是以前各類語系的人都有,因而出現各類錯誤,好比阻塞for循環select的問題,好比日期格式化的問題。好比依賴庫版本問題。總體聽下來感受他們的CR仍是須要增強,可能百度的那套Code的檢測機制就很合適。

不過總體聽下來開闊了一下視野。

總結

其實一天若干個話題聽下來,能記住的寥寥,可是晚上寫這篇文章的時候,還能在頭腦中浮現的,就是已經記在內心的乾貨了。

明天繼續早起。

相關文章
相關標籤/搜索