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

作為一名開發者，

周六的我們能做什么呢？

是因為產品經理的各種需求在加班嗎？

給你說了實現不了實現不了！

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

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

還是像某東一樣日常 996，

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

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

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

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

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

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

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

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

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

Negri 微服務框架

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

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

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

自研 Service Mesh Negri 特性

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

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

• 服務注冊發現省去了SLB部署環節，可自動發現服務節點變化

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

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

• 提供統一的UI，可展示服務的 Metrics，Trace，日志，調用關系等

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

• 不侵入代碼

• 通過 fork 進程,配合 Systemd 實現平滑重啟

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

• 通過單獨部署低配置機器和動態修改服務流量,灰度發布服務

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

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

Negri 的性能優化 -- 榨干 CPU 性能

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

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

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

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

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

Sidecar 模式的轉變

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

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

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

實踐者--七牛大數據團隊架構師劉凱

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

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

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

如何在低損耗下高效傳輸數據

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

其次是優化 Thrift 以及 Protobuf。經過測試，發現 Thrift 雖然對于語言的兼容性較高，但是單純從性能的角度看不如 Protobuf。

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

如何產生服務拓撲

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

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

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

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

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

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

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

初期的CP服務發現系統

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

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

AP服務發現系統Discovery

基于上述CP系統的一系列不足，bilibili開始了自研AP服務發現系統的道路。

bilibili 在2018年開始自研基于Go語言實現的 Discovery 服務發現框架，現在已經在內部得到大規模的應用，主要有以下三點特性：

• 注冊后，通過注冊時的 DirtyTime 復制節點信息，所有的健康檢測都會通過服務發現系統去確保節點信息最終一致。

• AP系統在網絡分區時會進行自我保護，保證健康的服務節點可用。

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

如何最終保持一致

AP與CP不同的地方一方面是上述額一些特性，另一方面，AP可以確保不同機房之間的流量調度以及節點數據一致性。

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

Discovery?如何進行容災

任何系統和框架都會有遇到故障的時候，那么對待容災的態度就決定了這個框架以及系統的上限究竟如何。因此發生網絡分區或者是網絡抖動不穩定的時候，Discovery 服務發現系統是如何進行容災的？

1、發生嚴重的網絡分區時：

• 當網絡分區發生時，每個 Discovery 節點，會持續的對外提供服務,接收該分區下新實例的服務注冊和發現。

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

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

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

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

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

RPC負載均衡算法

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

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

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

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

自適應限流

? ? ?

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

? ? ?

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

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

maxPass：最近 5s 內，單個采樣窗口中最大的請求數。

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

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

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

微服務中的CoDel隊列

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

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

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

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

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

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

5 文末福利??

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

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。