魯迅先生說過，所有能用 JS 寫的前端項目最終都會被用 JS 重寫一遍，所有能用 Go 寫的后端項目最終也都會被用 Go 重寫一遍。

作為一名開發(fā)者，

周六的我們能做什么呢？

是因為產(chǎn)品經(jīng)理的各種需求在加班嗎？

給你說了實現(xiàn)不了實現(xiàn)不了！

你不是懂技術嗎，要不然你來寫！

(這位同學你怎么能發(fā)語音)

還是像某東一樣日常 996，

苦逼的在公司廁所等待下班時間的到來。

聽說這是京東廁所里的溫馨小貼士...

但是在上海有這樣一群程序員，他們不僅在周末“無所事事”，沒有加班，沒有 996，甚至周末還能參加各種的技術沙龍活動...

不管因為什么原因錯過了周末那場精彩的沙龍，沒有來到現(xiàn)場真的為你感到很遺憾，但是也沒關系，現(xiàn)在可以和我們一起回顧下周六那場精彩紛呈的 Go 語言現(xiàn)場秀。

羨慕這些周末能自由安排時間的同學 o(╥﹏╥)o

就像開篇魯迅提到的那樣，所有能用 JS 寫的前端項目都會被用 JS 重寫一遍，所有能用 Go 寫的后端項目都會被用 Go 重寫一遍。這不，在上周六的趣頭條技術沙龍上，這三位大神分別帶來了不同的、完全基于 Go 語言實現(xiàn)的后端服務項目，將 Go 語言在后端的優(yōu)勢體現(xiàn)到了極致。

1 Go 實踐三宗“最”-- 最適合自研微服務框架的語言??

實踐者--趣頭條基礎架構部架構師徐鵬

在趣頭條的實踐中，一開始只是想用 Go 語言來做網(wǎng)關，但做著做著就發(fā)現(xiàn) Go 語言的性能超出了想象，Go 語言的一系列特性也完美符合自研微服務框架的需求，Negri 微服務框架也就應運而生。

Negri 微服務框架

上圖所示，這是 Negri 的整體框架圖。Sidecar 被譽為構建下一代微服務的關鍵，對于構建高度高度可伸縮、有彈性、安全且可便于監(jiān)控的微服務架構系統(tǒng)至關重要，因此 Negri 里對于如何部署配置 Sidecar 也十分的重視。

Negri 與其它框架的不同，在于通過控制平面來負責管理機器資源。因為 IP 是獨一無二的，因此選擇以 IP 的方式來獲取配置，并且依此抽象出 Istio 平面。這會使運維部署流程變得相對友好起來，不需要在每臺機器注入環(huán)境變量，只要通過尋找 IP 的方式來控制平面，就會得到關于 Sidecar 的配置文件。

同時 Negri 會與 Consul 保持兼容，Negri 會在注冊的過程中對運維資源進行二次核對，換句話說，單純只在 Sidecar 層面做注冊，而沒有將抽象系統(tǒng)抽離出來單獨做交互與核對，此時的 Consul 注冊就容易引起部署的風險。

自研 Service Mesh Negri 特性

發(fā)展到今天，Negri 也已經(jīng)逐漸成長為一款相當成熟的微服務框架，與其它微服務框架相比，Negri 有著眾多的特性，這里舉出其中幾個為例：

• PHP，Golang，Java甚至Node.Js，Python等開發(fā)語言都可以直接接入

• 服務注冊發(fā)現(xiàn)省去了SLB部署環(huán)節(jié)，可自動發(fā)現(xiàn)服務節(jié)點變化

• Negri 維護成本偏低，省去大面積故障所導致的維護成本

• 支持限流、熔斷、降級、Trace、Metrics等服務治理

• 提供統(tǒng)一的UI，可展示服務的 Metrics，Trace，日志，調(diào)用關系等

• 支持Abtest，Trace，Auth，加解密，Sign 驗簽等功能的支持

• 不侵入代碼

• 通過 fork 進程,配合 Systemd 實現(xiàn)平滑重啟

• 動態(tài)更新配置,實時控制限流熔斷降級等中間件

• 通過單獨部署低配置機器和動態(tài)修改服務流量,灰度發(fā)布服務

• 資源隔離，通過 Cgroup 限制資源(CPU,內(nèi)存等)使用

• 擁有統(tǒng)一的插件編寫體系，無需區(qū)分 Client 或?Server，統(tǒng)一抽象為 Server 端中間件，編寫一次，多端運行

Negri 的性能優(yōu)化 -- 榨干 CPU 性能

性能優(yōu)化是所有后臺基礎業(yè)務框架最重要部分之一，在研發(fā)過程中應該經(jīng)常會發(fā)現(xiàn)無論是 Kong 還是 Trans，或多或少都會遇到些性能瓶頸，在 Negri 框架下，解決方法主要有以下四點：

• 首先就是鎖瓶頸，通過拆分多個 Transport，設置與核心數(shù)相關的連接池數(shù)量，最終 CPU 會達到 10 萬的 KPS；

• 其次是對象池，這種優(yōu)化非常常見，通過釋放比較頻繁的對象與場景，比如說這個模塊默認提供一個 buffer，此時就可以作為一個接口傳遞下來，性能也因此會提升非常多；

• 第三是路由緩存，在網(wǎng)關下接口最多也就是兩三百個，不會造成路由性能的下降，但是如果在內(nèi)網(wǎng)的話就不一樣了，PATH 和服務會非常多，可能要解析上千個路由才能匹配到相關請求的服務，所以就需要路由緩存來解決問題；

• 最后是日志 Reopen，業(yè)務是不能影響的，往往第三方的日志切分工具會阻斷進程，導致業(yè)務中斷，Reopen 很好解決了這個問題。

Sidecar 模式的轉變

單端口還是多端口？這是一個問題，因為 Sidecar 最早是作為網(wǎng)關被開發(fā)的，已經(jīng)有了自己的運行模式。如果是單端口的話，需要重復編寫客戶端和服務端中間件，多端口的話只需要一次。

另外如何差異化下發(fā)配置，要抽象出服務私有化配置的概念，通過 Viper、Merge 的方式來加載，每一個服務都要有一個私有化的配置，另外整個的服務和項目也要有單獨的功能化配置。

2 Go 實踐三宗“最”-- 全鏈路追蹤的最佳拍檔??

實踐者--七牛大數(shù)據(jù)團隊架構師劉凱

全鏈路與 Go 語言之間是相得益彰的關系，Go 語言提高了全鏈路的開發(fā)效率，而全鏈路反過來也提升了 Go 語言項目的運維效率。七牛作為國內(nèi)應用 Go 語言程度最深的企業(yè)之一，基于 Go 語言搭建了一套全鏈路架構。

七牛全鏈路架構共分為三部分，從左至右依次為 HOST、服務端 Pipeline 以及數(shù)據(jù)可視化邏輯。先看下 HOST 部分，其中的 SDK 是指全鏈路中能夠幫助用戶接入的工具以及插件，下方的 Logkit 是通過鏈路實現(xiàn)的；

按流程走，之后會把采集的全鏈路數(shù)據(jù)傳送至服務端，以 Pipeline 進行數(shù)據(jù)寫入，最下方的控制層主要用來統(tǒng)計動態(tài)修改采集頻率。數(shù)據(jù)抵達右側后，分為了 ES 和 Cube 兩條線，其中每引入一個產(chǎn)品都要將其原始信息存到 ES 中，每當用戶發(fā)送請求可視化查詢信息時都要到 ES 內(nèi)部拿數(shù)據(jù)。

如何在低損耗下高效傳輸數(shù)據(jù)

全鏈路追蹤講究的就是高效，七牛在全鏈路追蹤中，對數(shù)據(jù)額傳入以及輸出分別做了不同的優(yōu)化：首先要優(yōu)化傳入效應，即用 TCP 和 UDP 兩種協(xié)議，TCP是用于服務本身，在一些重要的數(shù)據(jù)傳輸上并且不會出現(xiàn)頻繁更新服務的情況下，才會使用TCP協(xié)議，因為沒有必要頻繁采集；大部分數(shù)據(jù)傳輸是用 UDP 協(xié)議獲取的，兩者結合極大提高了整個效率。

其次是優(yōu)化 Thrift 以及 Protobuf。經(jīng)過測試，發(fā)現(xiàn) Thrift 雖然對于語言的兼容性較高，但是單純從性能的角度看不如 Protobuf。

此外還有壓縮、采樣率、動態(tài)配置等措施可以提升傳輸效率，歸根結底，還是依托于Go語言便利的網(wǎng)絡開發(fā)以及多平臺的支持。

如何產(chǎn)生服務拓撲

全鏈路很重要的功能就是要劃定各個服務間的調(diào)用關系與次數(shù)，如何快速形成一個更為直觀的服務拓撲就顯得極為重要。但是不同的產(chǎn)品所依托的技術手段不同，形成拓撲的延遲時間也不盡相同。

通過上圖可以看出，Jaeger 和 Zipkin 是通過 Spark 做的，但是有一天的延遲；Pinpoint 本身是有自己的一套存儲格式的，數(shù)據(jù)存在于Hbase，由于本身已經(jīng)統(tǒng)計過了，所以完全沒有可比性；阿里云主要是通過網(wǎng)關來實現(xiàn)，這個系統(tǒng)是針對網(wǎng)關統(tǒng)計的，因為請求和服務在部署時都會經(jīng)過網(wǎng)關，通過服務與服務間的調(diào)用關系，因此服務間是無延遲的。

服務內(nèi)部的調(diào)用關系也一樣，如果像阿里云一樣只統(tǒng)計網(wǎng)關的數(shù)據(jù)，是無法展示更多細節(jié)的，所以最終還是選擇了與Jaeger相同的調(diào)用方式，缺點也很明顯就是會產(chǎn)生一天左右的延遲。所以在此基礎上，又引入了實時計算框架--Druid。

Druid 通過數(shù)據(jù)預聚合的方式，為整個鏈路提供海量數(shù)據(jù)的快速查詢，很契合服務拓撲的實現(xiàn)路徑。當數(shù)據(jù)進入到鏈內(nèi)，單獨將數(shù)據(jù)讀取出來并做聚合，聚合之后記得保存，后續(xù)就可以繼續(xù)查詢，這樣將延遲極大的縮短至兩到三分鐘左右。

3 Go 實踐三宗“最”-- 最能完美融入后端業(yè)務的語言??

實踐者--B站主站技術中心高級研發(fā)工程師曹國梁

在微服務化以后，大多會遇到服務拆分較多、調(diào)用鏈較長的局面，一旦調(diào)用鏈受到某個壞節(jié)點的影響，這樣在服務端和用戶端很容易造成超時的現(xiàn)象，進而影響到用戶體驗。

初期的CP服務發(fā)現(xiàn)系統(tǒng)

bilibili 在2017年使用的都是基于 Zookeeper 的CP系統(tǒng)，其優(yōu)點是可以保證數(shù)據(jù)一致性以及可用性。但是CP系統(tǒng)的缺點也很大，即無法支持跨機房。在實際生產(chǎn)過程中，由于一些不穩(wěn)定的原因可能會導致網(wǎng)絡斷開，會影響到服務的注冊，同時服務內(nèi)的請求具有強一致性，所以會重復同步在 Zookeeper 上，從而導致業(yè)務中斷。

此外還有一個性能瓶頸，因為CP系統(tǒng)是強一致的系統(tǒng)，強一致性會緩存日志這一點大家都很清楚，所有日志緩存都會集中在 Zookeeper 上，基于此的 TCP 檢查效率也會隨之降低。

AP服務發(fā)現(xiàn)系統(tǒng)Discovery

基于上述CP系統(tǒng)的一系列不足，bilibili開始了自研AP服務發(fā)現(xiàn)系統(tǒng)的道路。

bilibili 在2018年開始自研基于Go語言實現(xiàn)的 Discovery 服務發(fā)現(xiàn)框架，現(xiàn)在已經(jīng)在內(nèi)部得到大規(guī)模的應用，主要有以下三點特性：

• 注冊后，通過注冊時的 DirtyTime 復制節(jié)點信息，所有的健康檢測都會通過服務發(fā)現(xiàn)系統(tǒng)去確保節(jié)點信息最終一致。

• AP系統(tǒng)在網(wǎng)絡分區(qū)時會進行自我保護，保證健康的服務節(jié)點可用。

• AP系統(tǒng)客戶端通過 HTTP Long Polling 來與服務端進行連接，可以直接調(diào)用，并實時關注推送客戶端的實例變化。

如何最終保持一致

AP與CP不同的地方一方面是上述額一些特性，另一方面，AP可以確保不同機房之間的流量調(diào)度以及節(jié)點數(shù)據(jù)一致性。

因為每一個服務實例都是全局唯一，因此可以通過服務的 ID 來全局定位這個實例，只需要保持一直遞增的 Dirtytime，Discovery 每收到請求后都會在服務內(nèi)廣播一遍，廣播時也可以檢查數(shù)據(jù)的一致性，那這個服務方向就一定會保持一致。比如像上圖所示，A向B傳播的時候，表示B中的實例有部分存在或者是實例較小，此時A的信息同步過去然后把B給覆蓋調(diào)。

Discovery?如何進行容災

任何系統(tǒng)和框架都會有遇到故障的時候，那么對待容災的態(tài)度就決定了這個框架以及系統(tǒng)的上限究竟如何。因此發(fā)生網(wǎng)絡分區(qū)或者是網(wǎng)絡抖動不穩(wěn)定的時候，Discovery 服務發(fā)現(xiàn)系統(tǒng)是如何進行容災的？

1、發(fā)生嚴重的網(wǎng)絡分區(qū)時：

• 當網(wǎng)絡分區(qū)發(fā)生時，每個 Discovery 節(jié)點，會持續(xù)的對外提供服務,接收該分區(qū)下新實例的服務注冊和發(fā)現(xiàn)。

• 短時間丟失大量心跳，進入自我保護，保證健康的實例不被剔除，同時保留“好數(shù)據(jù)”與“壞數(shù)據(jù)”

• 自我保護：每分鐘的心跳數(shù)小于閾值(實例數(shù)量*2*85%)，每15分鐘重置心跳計算周期

• 非自我保護下，隨機分批逐次剔除，盡量避免單個應用被全部過期。

2、部分 Discovery 節(jié)點不可用：由于每個節(jié)點都有全量的數(shù)據(jù)，此時客戶端SDK會自動選擇連接其他正常的 Discovery 節(jié)點獲取數(shù)據(jù)；不可用的 Discovery 節(jié)點重啟后會自動從其他健康的 Discovery 節(jié)點拉取全量的數(shù)據(jù)保持同步

3、全部 Discovery 節(jié)點不可用：客戶端SDK會緩存數(shù)據(jù)并拒絕任何實例數(shù)過低的異常變更推送；在宕機期間，服務提供者會一直向 Discovery 節(jié)點發(fā)送心跳請求，直到 Disocvery 節(jié)點重啟恢復正常之后返回404，此時服務提供者通過調(diào)用 Register 接口可以重新注冊。

RPC負載均衡算法

如果系統(tǒng)拉取到了錯誤的節(jié)點信息，這時就需要快速剔除錯誤節(jié)點并均衡后端負載。但是當前市面上常見的負載均衡算法都是寫死的，并且延遲率較高，會導致負載均衡監(jiān)控幾乎起不到效果。

基于此背景，bilibili 對負載均衡算法進行了優(yōu)化及改進，形成了負載均衡3.0版本。通過改為實時追蹤，使用帶時間衰減的滑動平均值，每次請求都可以實時算一次平均值，來實時更新延遲和成功率等信息。

此外也可以引入一些隨機量進來，依上圖所示，橫坐標為信息延遲時間，縱坐標為請求的平均響應時間。毫無疑問肯定是請求響應時間越小越好，橫坐標的信息延遲也是越低越好?？梢钥吹綀D中橫坐標在接近0的時候，紫色線條的算法是永遠在選節(jié)點里最快相應的請求，所以毫無疑問這時候是效果最好的，但是當橫坐標在40-50區(qū)間的時候效果變得很差。

此外也可以引入 inflight 來平衡負載均衡算法之間的調(diào)度。比如A當時正在發(fā)送的請求是5，B發(fā)給A的請求是10，我們會將 inflight 調(diào)入到算法中來進行兩者之間的合理調(diào)度。歸納一下，即?infight?越高，被調(diào)度的機會就越少。

自適應限流

? ? ?

現(xiàn)在很多算法上仍然在使用令牌桶限流的技術，這只是針對局部的服務端限流，無法呈現(xiàn)出全局視角。此外由于業(yè)務原因，系統(tǒng)負載肯定是在不斷變化中的，如何分辨出請求的重要性，如何讓重要請求先通過，這也是單機令牌桶限流的局限性。

? ? ?

上圖是基于 BBR 算法開發(fā)的自適應限流，本質是擁塞控制，與限流有一定的相似之處，是基于 CPU\IOPS 作為啟發(fā)值，通過 BBR 算法來決定系統(tǒng)的最大承載量，算法公式為：

cpu > 800 AND InFlight > (maxPass * minRtt * windows / 1000)?

maxPass：最近 5s 內(nèi)，單個采樣窗口中最大的請求數(shù)。

minRtt：最近 5s 內(nèi)，單個采樣窗口中最小的響應時間。

windows：一秒內(nèi)采樣窗口的數(shù)量，默認配置中是5s/50個采樣，那么 windows 的值為 10。

以CPU使用率為啟發(fā)值，高于80%，表明處理的請求量是大于系統(tǒng)的承載力的，就會自動進行限流，就實現(xiàn)了完全自動化的運維。

微服務中的CoDel隊列

在過去，傳統(tǒng)的CoDel隊列都是先進先出，請求來的越早在里面排隊的時間就越久，也就是系統(tǒng)閑下來時是被優(yōu)先處理的對象，但是這樣的隊列在微服務中卻十分不友好，因為微服務有超時機制，不可能無限等下去。如果放行一個比較老的請求，這個請求成功率還是會變得很低，因為這個請求由于排隊時間過長，導致最終超時，所以也會影響到最終的請求成功率。

因此在微服務下，當系統(tǒng)處于高負載時，就要實行后進先出的策略，即需要主動丟棄排隊很久的請求，讓那些后進來的請求優(yōu)先通過，以吸收突增流量作為緩沖，從而彌補CoDel隊列之前算法里的緩沖問題。

4 魯迅：開發(fā)者互撩的場面我還真沒見過

作為一名開發(fā)者，大家的印象中肯定是悶頭敲鍵盤、不善言辭的那種。這里我只想說，不是他們不善言辭，也不是他們冷漠沒有情趣，而是你沒有get到他們的點。在上周六的上海，一群開發(fā)者現(xiàn)場面基，足足互撩了1個多小時的時間。

在【Go的工程化實踐】、【大并發(fā)和大流量下的Go實踐】、【Go在行業(yè)中落地與應用】以及【Go的未來前景探討】這四個話題下，大家展開了激烈的討論。我們前來參會的開發(fā)者真是臥虎藏龍，其中更是有鉆研Go語言達8年之久的大神隱藏在我們的人群中，最后產(chǎn)出的內(nèi)容質量也非常高，足以證明，我們到場的開發(fā)者，真正參與到了我們沙龍活動中，并充分展示了自己的技術實力與前瞻性。

開發(fā)語言并沒有好壞之分，只有適和與不適合的區(qū)別。無論哪一種開發(fā)語言，只要我們開發(fā)者自己能夠沉下心來去研究，去認真觀察他人的最佳實踐，自己能夠得心應手的應用這個語言，那么這款開發(fā)語言，對于我們開發(fā)者自己來說，就是世界上最好的語言。

5 文末福利??

這里沒有加班沒有996，甚至周末可以參加各種技術沙龍活動...對Go語言感興趣的你，想把愛好與工作融合在一起嗎，想加入一家專注應用Go語言的公司嗎？可以點擊查看更加詳細的信息，填寫調(diào)查問卷，感受趣頭條速度。

總結

以上是生活随笔為你收集整理的bilibili go框架_最好的开发语言一定是那位吗？Go语言有话说的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。