bilibili go框架_最好的开发语言一定是那位吗？Go语言有话说
魯迅先生說過，所有能用 JS 寫的前端項(xiàng)目最終都會(huì)被用 JS 重寫一遍，所有能用 Go 寫的后端項(xiàng)目最終也都會(huì)被用 Go 重寫一遍。
作為一名開發(fā)者，
周六的我們能做什么呢？
是因?yàn)楫a(chǎn)品經(jīng)理的各種需求在加班嗎？
給你說了實(shí)現(xiàn)不了實(shí)現(xiàn)不了！
你不是懂技術(shù)嗎，要不然你來寫！
(這位同學(xué)你怎么能發(fā)語音)
還是像某東一樣日常 996，
苦逼的在公司廁所等待下班時(shí)間的到來。
聽說這是京東廁所里的溫馨小貼士...
但是在上海有這樣一群程序員，他們不僅在周末“無所事事”，沒有加班，沒有 996，甚至周末還能參加各種的技術(shù)沙龍活動(dòng)...
不管因?yàn)槭裁丛蝈e(cuò)過了周末那場精彩的沙龍，沒有來到現(xiàn)場真的為你感到很遺憾，但是也沒關(guān)系，現(xiàn)在可以和我們一起回顧下周六那場精彩紛呈的 Go 語言現(xiàn)場秀。
羨慕這些周末能自由安排時(shí)間的同學(xué) o(╥﹏╥)o
就像開篇魯迅提到的那樣，所有能用 JS 寫的前端項(xiàng)目都會(huì)被用 JS 重寫一遍，所有能用 Go 寫的后端項(xiàng)目都會(huì)被用 Go 重寫一遍。這不，在上周六的趣頭條技術(shù)沙龍上，這三位大神分別帶來了不同的、完全基于 Go 語言實(shí)現(xiàn)的后端服務(wù)項(xiàng)目，將 Go 語言在后端的優(yōu)勢體現(xiàn)到了極致。
1 Go 實(shí)踐三宗“最”-- 最適合自研微服務(wù)框架的語言??實(shí)踐者--趣頭條基礎(chǔ)架構(gòu)部架構(gòu)師徐鵬
在趣頭條的實(shí)踐中，一開始只是想用 Go 語言來做網(wǎng)關(guān)，但做著做著就發(fā)現(xiàn) Go 語言的性能超出了想象，Go 語言的一系列特性也完美符合自研微服務(wù)框架的需求，Negri 微服務(wù)框架也就應(yīng)運(yùn)而生。
Negri 微服務(wù)框架
上圖所示，這是 Negri 的整體框架圖。Sidecar 被譽(yù)為構(gòu)建下一代微服務(wù)的關(guān)鍵，對于構(gòu)建高度高度可伸縮、有彈性、安全且可便于監(jiān)控的微服務(wù)架構(gòu)系統(tǒng)至關(guān)重要，因此 Negri 里對于如何部署配置 Sidecar 也十分的重視。
Negri 與其它框架的不同，在于通過控制平面來負(fù)責(zé)管理機(jī)器資源。因?yàn)?IP 是獨(dú)一無二的，因此選擇以 IP 的方式來獲取配置，并且依此抽象出 Istio 平面。這會(huì)使運(yùn)維部署流程變得相對友好起來，不需要在每臺機(jī)器注入環(huán)境變量，只要通過尋找 IP 的方式來控制平面，就會(huì)得到關(guān)于 Sidecar 的配置文件。
同時(shí) Negri 會(huì)與 Consul 保持兼容，Negri 會(huì)在注冊的過程中對運(yùn)維資源進(jìn)行二次核對，換句話說，單純只在 Sidecar 層面做注冊，而沒有將抽象系統(tǒng)抽離出來單獨(dú)做交互與核對，此時(shí)的 Consul 注冊就容易引起部署的風(fēng)險(xiǎn)。
自研 Service Mesh Negri 特性
發(fā)展到今天，Negri 也已經(jīng)逐漸成長為一款相當(dāng)成熟的微服務(wù)框架，與其它微服務(wù)框架相比，Negri 有著眾多的特性，這里舉出其中幾個(gè)為例：
PHP，Golang，Java甚至Node.Js，Python等開發(fā)語言都可以直接接入
服務(wù)注冊發(fā)現(xiàn)省去了SLB部署環(huán)節(jié)，可自動(dòng)發(fā)現(xiàn)服務(wù)節(jié)點(diǎn)變化
Negri 維護(hù)成本偏低，省去大面積故障所導(dǎo)致的維護(hù)成本
支持限流、熔斷、降級、Trace、Metrics等服務(wù)治理
提供統(tǒng)一的UI，可展示服務(wù)的 Metrics，Trace，日志，調(diào)用關(guān)系等
支持Abtest，Trace，Auth，加解密，Sign 驗(yàn)簽等功能的支持
不侵入代碼
通過 fork 進(jìn)程,配合 Systemd 實(shí)現(xiàn)平滑重啟
動(dòng)態(tài)更新配置,實(shí)時(shí)控制限流熔斷降級等中間件
通過單獨(dú)部署低配置機(jī)器和動(dòng)態(tài)修改服務(wù)流量,灰度發(fā)布服務(wù)
資源隔離，通過 Cgroup 限制資源(CPU,內(nèi)存等)使用
擁有統(tǒng)一的插件編寫體系，無需區(qū)分 Client 或?Server，統(tǒng)一抽象為 Server 端中間件，編寫一次，多端運(yùn)行
Negri 的性能優(yōu)化 -- 榨干 CPU 性能
性能優(yōu)化是所有后臺基礎(chǔ)業(yè)務(wù)框架最重要部分之一，在研發(fā)過程中應(yīng)該經(jīng)常會(huì)發(fā)現(xiàn)無論是 Kong 還是 Trans，或多或少都會(huì)遇到些性能瓶頸，在 Negri 框架下，解決方法主要有以下四點(diǎn)：
首先就是鎖瓶頸，通過拆分多個(gè) Transport，設(shè)置與核心數(shù)相關(guān)的連接池?cái)?shù)量，最終 CPU 會(huì)達(dá)到 10 萬的 KPS；
其次是對象池，這種優(yōu)化非常常見，通過釋放比較頻繁的對象與場景，比如說這個(gè)模塊默認(rèn)提供一個(gè) buffer，此時(shí)就可以作為一個(gè)接口傳遞下來，性能也因此會(huì)提升非常多；
第三是路由緩存，在網(wǎng)關(guān)下接口最多也就是兩三百個(gè)，不會(huì)造成路由性能的下降，但是如果在內(nèi)網(wǎng)的話就不一樣了，PATH 和服務(wù)會(huì)非常多，可能要解析上千個(gè)路由才能匹配到相關(guān)請求的服務(wù)，所以就需要路由緩存來解決問題；
最后是日志 Reopen，業(yè)務(wù)是不能影響的，往往第三方的日志切分工具會(huì)阻斷進(jìn)程，導(dǎo)致業(yè)務(wù)中斷，Reopen 很好解決了這個(gè)問題。
Sidecar 模式的轉(zhuǎn)變
單端口還是多端口？這是一個(gè)問題，因?yàn)?Sidecar 最早是作為網(wǎng)關(guān)被開發(fā)的，已經(jīng)有了自己的運(yùn)行模式。如果是單端口的話，需要重復(fù)編寫客戶端和服務(wù)端中間件，多端口的話只需要一次。
另外如何差異化下發(fā)配置，要抽象出服務(wù)私有化配置的概念，通過 Viper、Merge 的方式來加載，每一個(gè)服務(wù)都要有一個(gè)私有化的配置，另外整個(gè)的服務(wù)和項(xiàng)目也要有單獨(dú)的功能化配置。
2 Go 實(shí)踐三宗“最”-- 全鏈路追蹤的最佳拍檔??實(shí)踐者--七牛大數(shù)據(jù)團(tuán)隊(duì)架構(gòu)師劉凱
全鏈路與 Go 語言之間是相得益彰的關(guān)系，Go 語言提高了全鏈路的開發(fā)效率，而全鏈路反過來也提升了 Go 語言項(xiàng)目的運(yùn)維效率。七牛作為國內(nèi)應(yīng)用 Go 語言程度最深的企業(yè)之一，基于 Go 語言搭建了一套全鏈路架構(gòu)。
七牛全鏈路架構(gòu)共分為三部分，從左至右依次為 HOST、服務(wù)端 Pipeline 以及數(shù)據(jù)可視化邏輯。先看下 HOST 部分，其中的 SDK 是指全鏈路中能夠幫助用戶接入的工具以及插件，下方的 Logkit 是通過鏈路實(shí)現(xiàn)的；
按流程走，之后會(huì)把采集的全鏈路數(shù)據(jù)傳送至服務(wù)端，以 Pipeline 進(jìn)行數(shù)據(jù)寫入，最下方的控制層主要用來統(tǒng)計(jì)動(dòng)態(tài)修改采集頻率。數(shù)據(jù)抵達(dá)右側(cè)后，分為了 ES 和 Cube 兩條線，其中每引入一個(gè)產(chǎn)品都要將其原始信息存到 ES 中，每當(dāng)用戶發(fā)送請求可視化查詢信息時(shí)都要到 ES 內(nèi)部拿數(shù)據(jù)。
如何在低損耗下高效傳輸數(shù)據(jù)
全鏈路追蹤講究的就是高效，七牛在全鏈路追蹤中，對數(shù)據(jù)額傳入以及輸出分別做了不同的優(yōu)化：首先要優(yōu)化傳入效應(yīng)，即用 TCP 和 UDP 兩種協(xié)議，TCP是用于服務(wù)本身，在一些重要的數(shù)據(jù)傳輸上并且不會(huì)出現(xiàn)頻繁更新服務(wù)的情況下，才會(huì)使用TCP協(xié)議，因?yàn)闆]有必要頻繁采集；大部分?jǐn)?shù)據(jù)傳輸是用 UDP 協(xié)議獲取的，兩者結(jié)合極大提高了整個(gè)效率。
其次是優(yōu)化 Thrift 以及 Protobuf。經(jīng)過測試，發(fā)現(xiàn) Thrift 雖然對于語言的兼容性較高，但是單純從性能的角度看不如 Protobuf。
此外還有壓縮、采樣率、動(dòng)態(tài)配置等措施可以提升傳輸效率，歸根結(jié)底，還是依托于Go語言便利的網(wǎng)絡(luò)開發(fā)以及多平臺的支持。
如何產(chǎn)生服務(wù)拓?fù)?/strong>
全鏈路很重要的功能就是要?jiǎng)澏ǜ鱾€(gè)服務(wù)間的調(diào)用關(guān)系與次數(shù)，如何快速形成一個(gè)更為直觀的服務(wù)拓?fù)渚惋@得極為重要。但是不同的產(chǎn)品所依托的技術(shù)手段不同，形成拓?fù)涞难舆t時(shí)間也不盡相同。
通過上圖可以看出，Jaeger 和 Zipkin 是通過 Spark 做的，但是有一天的延遲；Pinpoint 本身是有自己的一套存儲格式的，數(shù)據(jù)存在于Hbase，由于本身已經(jīng)統(tǒng)計(jì)過了，所以完全沒有可比性；阿里云主要是通過網(wǎng)關(guān)來實(shí)現(xiàn)，這個(gè)系統(tǒng)是針對網(wǎng)關(guān)統(tǒng)計(jì)的，因?yàn)檎埱蠛头?wù)在部署時(shí)都會(huì)經(jīng)過網(wǎng)關(guān)，通過服務(wù)與服務(wù)間的調(diào)用關(guān)系，因此服務(wù)間是無延遲的。
服務(wù)內(nèi)部的調(diào)用關(guān)系也一樣，如果像阿里云一樣只統(tǒng)計(jì)網(wǎng)關(guān)的數(shù)據(jù)，是無法展示更多細(xì)節(jié)的，所以最終還是選擇了與Jaeger相同的調(diào)用方式，缺點(diǎn)也很明顯就是會(huì)產(chǎn)生一天左右的延遲。所以在此基礎(chǔ)上，又引入了實(shí)時(shí)計(jì)算框架--Druid。
Druid 通過數(shù)據(jù)預(yù)聚合的方式，為整個(gè)鏈路提供海量數(shù)據(jù)的快速查詢，很契合服務(wù)拓?fù)涞膶?shí)現(xiàn)路徑。當(dāng)數(shù)據(jù)進(jìn)入到鏈內(nèi)，單獨(dú)將數(shù)據(jù)讀取出來并做聚合，聚合之后記得保存，后續(xù)就可以繼續(xù)查詢，這樣將延遲極大的縮短至兩到三分鐘左右。
3 Go 實(shí)踐三宗“最”-- 最能完美融入后端業(yè)務(wù)的語言??實(shí)踐者--B站主站技術(shù)中心高級研發(fā)工程師曹國梁
在微服務(wù)化以后，大多會(huì)遇到服務(wù)拆分較多、調(diào)用鏈較長的局面，一旦調(diào)用鏈?zhǔn)艿侥硞€(gè)壞節(jié)點(diǎn)的影響，這樣在服務(wù)端和用戶端很容易造成超時(shí)的現(xiàn)象，進(jìn)而影響到用戶體驗(yàn)。
初期的CP服務(wù)發(fā)現(xiàn)系統(tǒng)
bilibili 在2017年使用的都是基于 Zookeeper 的CP系統(tǒng)，其優(yōu)點(diǎn)是可以保證數(shù)據(jù)一致性以及可用性。但是CP系統(tǒng)的缺點(diǎn)也很大，即無法支持跨機(jī)房。在實(shí)際生產(chǎn)過程中，由于一些不穩(wěn)定的原因可能會(huì)導(dǎo)致網(wǎng)絡(luò)斷開，會(huì)影響到服務(wù)的注冊，同時(shí)服務(wù)內(nèi)的請求具有強(qiáng)一致性，所以會(huì)重復(fù)同步在 Zookeeper 上，從而導(dǎo)致業(yè)務(wù)中斷。
此外還有一個(gè)性能瓶頸，因?yàn)镃P系統(tǒng)是強(qiáng)一致的系統(tǒng)，強(qiáng)一致性會(huì)緩存日志這一點(diǎn)大家都很清楚，所有日志緩存都會(huì)集中在 Zookeeper 上，基于此的 TCP 檢查效率也會(huì)隨之降低。
AP服務(wù)發(fā)現(xiàn)系統(tǒng)Discovery
基于上述CP系統(tǒng)的一系列不足，bilibili開始了自研AP服務(wù)發(fā)現(xiàn)系統(tǒng)的道路。
bilibili 在2018年開始自研基于Go語言實(shí)現(xiàn)的 Discovery 服務(wù)發(fā)現(xiàn)框架，現(xiàn)在已經(jīng)在內(nèi)部得到大規(guī)模的應(yīng)用，主要有以下三點(diǎn)特性：
注冊后，通過注冊時(shí)的 DirtyTime 復(fù)制節(jié)點(diǎn)信息，所有的健康檢測都會(huì)通過服務(wù)發(fā)現(xiàn)系統(tǒng)去確保節(jié)點(diǎn)信息最終一致。
AP系統(tǒng)在網(wǎng)絡(luò)分區(qū)時(shí)會(huì)進(jìn)行自我保護(hù)，保證健康的服務(wù)節(jié)點(diǎn)可用。
AP系統(tǒng)客戶端通過 HTTP Long Polling 來與服務(wù)端進(jìn)行連接，可以直接調(diào)用，并實(shí)時(shí)關(guān)注推送客戶端的實(shí)例變化。
如何最終保持一致
AP與CP不同的地方一方面是上述額一些特性，另一方面，AP可以確保不同機(jī)房之間的流量調(diào)度以及節(jié)點(diǎn)數(shù)據(jù)一致性。
因?yàn)槊恳粋€(gè)服務(wù)實(shí)例都是全局唯一，因此可以通過服務(wù)的 ID 來全局定位這個(gè)實(shí)例，只需要保持一直遞增的 Dirtytime，Discovery 每收到請求后都會(huì)在服務(wù)內(nèi)廣播一遍，廣播時(shí)也可以檢查數(shù)據(jù)的一致性，那這個(gè)服務(wù)方向就一定會(huì)保持一致。比如像上圖所示，A向B傳播的時(shí)候，表示B中的實(shí)例有部分存在或者是實(shí)例較小，此時(shí)A的信息同步過去然后把B給覆蓋調(diào)。
Discovery?如何進(jìn)行容災(zāi)
任何系統(tǒng)和框架都會(huì)有遇到故障的時(shí)候，那么對待容災(zāi)的態(tài)度就決定了這個(gè)框架以及系統(tǒng)的上限究竟如何。因此發(fā)生網(wǎng)絡(luò)分區(qū)或者是網(wǎng)絡(luò)抖動(dòng)不穩(wěn)定的時(shí)候，Discovery 服務(wù)發(fā)現(xiàn)系統(tǒng)是如何進(jìn)行容災(zāi)的？
1、發(fā)生嚴(yán)重的網(wǎng)絡(luò)分區(qū)時(shí)：
當(dāng)網(wǎng)絡(luò)分區(qū)發(fā)生時(shí)，每個(gè) Discovery 節(jié)點(diǎn)，會(huì)持續(xù)的對外提供服務(wù),接收該分區(qū)下新實(shí)例的服務(wù)注冊和發(fā)現(xiàn)。
短時(shí)間丟失大量心跳，進(jìn)入自我保護(hù)，保證健康的實(shí)例不被剔除，同時(shí)保留“好數(shù)據(jù)”與“壞數(shù)據(jù)”
自我保護(hù)：每分鐘的心跳數(shù)小于閾值(實(shí)例數(shù)量*2*85%)，每15分鐘重置心跳計(jì)算周期
非自我保護(hù)下，隨機(jī)分批逐次剔除，盡量避免單個(gè)應(yīng)用被全部過期。
2、部分 Discovery 節(jié)點(diǎn)不可用：由于每個(gè)節(jié)點(diǎn)都有全量的數(shù)據(jù)，此時(shí)客戶端SDK會(huì)自動(dòng)選擇連接其他正常的 Discovery 節(jié)點(diǎn)獲取數(shù)據(jù)；不可用的 Discovery 節(jié)點(diǎn)重啟后會(huì)自動(dòng)從其他健康的 Discovery 節(jié)點(diǎn)拉取全量的數(shù)據(jù)保持同步
3、全部 Discovery 節(jié)點(diǎn)不可用：客戶端SDK會(huì)緩存數(shù)據(jù)并拒絕任何實(shí)例數(shù)過低的異常變更推送；在宕機(jī)期間，服務(wù)提供者會(huì)一直向 Discovery 節(jié)點(diǎn)發(fā)送心跳請求，直到 Disocvery 節(jié)點(diǎn)重啟恢復(fù)正常之后返回404，此時(shí)服務(wù)提供者通過調(diào)用 Register 接口可以重新注冊。
RPC負(fù)載均衡算法
如果系統(tǒng)拉取到了錯(cuò)誤的節(jié)點(diǎn)信息，這時(shí)就需要快速剔除錯(cuò)誤節(jié)點(diǎn)并均衡后端負(fù)載。但是當(dāng)前市面上常見的負(fù)載均衡算法都是寫死的，并且延遲率較高，會(huì)導(dǎo)致負(fù)載均衡監(jiān)控幾乎起不到效果。
基于此背景，bilibili 對負(fù)載均衡算法進(jìn)行了優(yōu)化及改進(jìn)，形成了負(fù)載均衡3.0版本。通過改為實(shí)時(shí)追蹤，使用帶時(shí)間衰減的滑動(dòng)平均值，每次請求都可以實(shí)時(shí)算一次平均值，來實(shí)時(shí)更新延遲和成功率等信息。
此外也可以引入一些隨機(jī)量進(jìn)來，依上圖所示，橫坐標(biāo)為信息延遲時(shí)間，縱坐標(biāo)為請求的平均響應(yīng)時(shí)間。毫無疑問肯定是請求響應(yīng)時(shí)間越小越好，橫坐標(biāo)的信息延遲也是越低越好。可以看到圖中橫坐標(biāo)在接近0的時(shí)候，紫色線條的算法是永遠(yuǎn)在選節(jié)點(diǎn)里最快相應(yīng)的請求，所以毫無疑問這時(shí)候是效果最好的，但是當(dāng)橫坐標(biāo)在40-50區(qū)間的時(shí)候效果變得很差。
此外也可以引入 inflight 來平衡負(fù)載均衡算法之間的調(diào)度。比如A當(dāng)時(shí)正在發(fā)送的請求是5，B發(fā)給A的請求是10，我們會(huì)將 inflight 調(diào)入到算法中來進(jìn)行兩者之間的合理調(diào)度。歸納一下，即?infight?越高，被調(diào)度的機(jī)會(huì)就越少。
自適應(yīng)限流
? ? ?
現(xiàn)在很多算法上仍然在使用令牌桶限流的技術(shù)，這只是針對局部的服務(wù)端限流，無法呈現(xiàn)出全局視角。此外由于業(yè)務(wù)原因，系統(tǒng)負(fù)載肯定是在不斷變化中的，如何分辨出請求的重要性，如何讓重要請求先通過，這也是單機(jī)令牌桶限流的局限性。
? ? ?
上圖是基于 BBR 算法開發(fā)的自適應(yīng)限流，本質(zhì)是擁塞控制，與限流有一定的相似之處，是基于 CPU\IOPS 作為啟發(fā)值，通過 BBR 算法來決定系統(tǒng)的最大承載量，算法公式為：
cpu > 800 AND InFlight > (maxPass * minRtt * windows / 1000)?
maxPass：最近 5s 內(nèi)，單個(gè)采樣窗口中最大的請求數(shù)。
minRtt：最近 5s 內(nèi)，單個(gè)采樣窗口中最小的響應(yīng)時(shí)間。
windows：一秒內(nèi)采樣窗口的數(shù)量，默認(rèn)配置中是5s/50個(gè)采樣，那么 windows 的值為 10。
以CPU使用率為啟發(fā)值，高于80%，表明處理的請求量是大于系統(tǒng)的承載力的，就會(huì)自動(dòng)進(jìn)行限流，就實(shí)現(xiàn)了完全自動(dòng)化的運(yùn)維。
微服務(wù)中的CoDel隊(duì)列
在過去，傳統(tǒng)的CoDel隊(duì)列都是先進(jìn)先出，請求來的越早在里面排隊(duì)的時(shí)間就越久，也就是系統(tǒng)閑下來時(shí)是被優(yōu)先處理的對象，但是這樣的隊(duì)列在微服務(wù)中卻十分不友好，因?yàn)槲⒎?wù)有超時(shí)機(jī)制，不可能無限等下去。如果放行一個(gè)比較老的請求，這個(gè)請求成功率還是會(huì)變得很低，因?yàn)檫@個(gè)請求由于排隊(duì)時(shí)間過長，導(dǎo)致最終超時(shí)，所以也會(huì)影響到最終的請求成功率。
因此在微服務(wù)下，當(dāng)系統(tǒng)處于高負(fù)載時(shí)，就要實(shí)行后進(jìn)先出的策略，即需要主動(dòng)丟棄排隊(duì)很久的請求，讓那些后進(jìn)來的請求優(yōu)先通過，以吸收突增流量作為緩沖，從而彌補(bǔ)CoDel隊(duì)列之前算法里的緩沖問題。
4 魯迅：開發(fā)者互撩的場面我還真沒見過作為一名開發(fā)者，大家的印象中肯定是悶頭敲鍵盤、不善言辭的那種。這里我只想說，不是他們不善言辭，也不是他們冷漠沒有情趣，而是你沒有g(shù)et到他們的點(diǎn)。在上周六的上海，一群開發(fā)者現(xiàn)場面基，足足互撩了1個(gè)多小時(shí)的時(shí)間。
在【Go的工程化實(shí)踐】、【大并發(fā)和大流量下的Go實(shí)踐】、【Go在行業(yè)中落地與應(yīng)用】以及【Go的未來前景探討】這四個(gè)話題下，大家展開了激烈的討論。我們前來參會(huì)的開發(fā)者真是臥虎藏龍，其中更是有鉆研Go語言達(dá)8年之久的大神隱藏在我們的人群中，最后產(chǎn)出的內(nèi)容質(zhì)量也非常高，足以證明，我們到場的開發(fā)者，真正參與到了我們沙龍活動(dòng)中，并充分展示了自己的技術(shù)實(shí)力與前瞻性。
開發(fā)語言并沒有好壞之分，只有適和與不適合的區(qū)別。無論哪一種開發(fā)語言，只要我們開發(fā)者自己能夠沉下心來去研究，去認(rèn)真觀察他人的最佳實(shí)踐，自己能夠得心應(yīng)手的應(yīng)用這個(gè)語言，那么這款開發(fā)語言，對于我們開發(fā)者自己來說，就是世界上最好的語言。
5 文末福利??這里沒有加班沒有996，甚至周末可以參加各種技術(shù)沙龍活動(dòng)...對Go語言感興趣的你，想把愛好與工作融合在一起嗎，想加入一家專注應(yīng)用Go語言的公司嗎？可以點(diǎn)擊查看更加詳細(xì)的信息，填寫調(diào)查問卷，感受趣頭條速度。
總結(jié)
以上是生活随笔為你收集整理的bilibili go框架_最好的开发语言一定是那位吗？Go语言有话说的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： AI 视频分析识别系统技术分析
- 下一篇： HTML5开发从入门到精通学习路线图