建站
咨詢
售后
建站咨詢
新聞中心
基于Go技術棧的微服務構建是怎樣的，很多新手對此不是很清楚，為了幫助大家解決這個難題，下面小編將為大家詳細講解，有這方面需求的人可以來學習下，希望你能有所收獲。
成都創(chuàng)新互聯(lián)公司專注為客戶提供全方位的互聯(lián)網綜合服務，包含不限于網站制作、網站建設、臨江網絡推廣、小程序設計、臨江網絡營銷、臨江企業(yè)策劃、臨江品牌公關、搜索引擎seo、人物專訪、企業(yè)宣傳片、企業(yè)代運營等，從售前售中售后，我們都將竭誠為您服務，您的肯定，是我們最大的嘉獎；成都創(chuàng)新互聯(lián)公司為所有大學生創(chuàng)業(yè)者提供臨江建站搭建服務，24小時服務熱線：18982081108，官方網址：www.cdcxhl.com
在大型系統(tǒng)的微服務化構建中，一個系統(tǒng)會被拆分成許多模塊。這些模塊負責不同的功能，組合成系統(tǒng)，最終可以提供豐富的功能。在這種構建形式中，開發(fā)者一般會聚焦于最大程度解耦模塊的功能以減少模塊間耦合帶來的額外開發(fā)成本。同時，微服務面臨著如何部署這些大量的服務系統(tǒng)、如何運維這些系統(tǒng)等新問題。
本文的素材來源于我們在開發(fā)中的一些最佳實踐案例，從開發(fā)、監(jiān)控、日志等角度介紹了一些我們基于Go技術棧的微服務構建經驗。
開 發(fā)
微服務的開發(fā)過程中，不同模塊由不同的開發(fā)者負責，明確定義的接口有助于確定開發(fā)者的工作任務。最終的系統(tǒng)中，一個業(yè)務請求可能會涉及到多次接口調用，如何準確清晰的調用遠端接口，這也是一大挑戰(zhàn)。對于這些問題，我們使用了gRPC來負責協(xié)議的制訂和調用。
傳統(tǒng)的微服務通?；趆ttp協(xié)議來進行模塊間的調用，而在我們的微服務構建中，選用了Google推出的gRPC框架來進行調用。
gRPC的接口需要使用Protobuf3定義，通過靜態(tài)編譯后才能成功調用。這一特性減少了由于接口改變帶來的溝通成本。如果使用http rpc，接口改變就需要先改接口文檔，然后周知到調用者，如果調用者沒有及時修改，很可能會到服務運行時才能發(fā)現(xiàn)錯誤。而gRPC的這種模式，接口變動引起的錯誤保證在編譯時期就能消除。
在性能方面，gRPC相比傳統(tǒng)的http rpc協(xié)議有非常大的改善（根據(jù)這個評測，gRPC要快10倍）。gRPC使用http 2協(xié)議進行傳輸，相比較http 1.1, http 2復用tcp連接，減少了每次請求建立tcp連接的開銷。需要指出的是，如果單純追求性能，之前業(yè)界一般會選用構建在tcp協(xié)議上的rpc協(xié)議(thrift等)，但四層協(xié)議無法方便的做一些傳輸控制。相比而言，gRPC可以在http header中放入控制字段，配合nginx等代理服務器，可以很方便的實現(xiàn)轉發(fā)/灰度等功能。
接下來著重談談我們在實踐中如何使用gRPC的一些特性來簡化相關開發(fā)流程。
1. 使用context來控制請求的生命周期
在gRPC的go語言實現(xiàn)中，每個rpc請求的第一個參數(shù)都是context。http2協(xié)議會將context放在HEADER中，隨著鏈路傳遞下去，因此可以為每個請求設置過期時間，一旦遇到超時的情況，發(fā)起方就會結束等待，返回錯誤。
| ctx := context.Background() // blank context ctx, cancel = context.WithTimeout(ctx, 5*time.Second) defer cancel( ) grpc.CallServiveX(ctx, arg1) |
上述這段代碼，發(fā)起方設置了大約5s的等待時間，只要遠端的調用在５s內沒有返回，發(fā)起方就會報錯。
除了能加入超時時間，context還能加入其他內容，下文我們還會見到context的另一個妙用。
2.使用TLS實現(xiàn)訪問權限控制
gRPC集成了TLS證書功能，為我們提供了很完善的權限控制方案。在實踐中，假設我們的系統(tǒng)中存在服務Ａ，由于它負責操作用戶的敏感內容，因此需要保證Ａ不被系統(tǒng)內的其他服務濫用。為了避免濫用，我們設計了一套自簽名的二級證書系統(tǒng)，服務Ａ掌握了自簽名的根證書，同時為每個調用Ａ的服務頒發(fā)一個二級證書。這樣，所有調用Ａ的服務必須經過Ａ的授權，Ａ也可以鑒別每個請求的調用方，這樣可以很方便的做一些記錄日志、流量控制等操作。
3. 使用trace在線追蹤請求
gRPC內置了一套追蹤請求的trace系統(tǒng)，既可以追蹤最近10個請求的詳細日志信息，也可以記錄所有請求的統(tǒng)計信息。
當我們?yōu)檎埱蠹尤肓藅race日志后，trace系統(tǒng)會為我們記錄下最近１０個請求的日志,下圖中所示的例子就是在trace日志中加入了對業(yè)務數(shù)據(jù)的追蹤。
在宏觀上，trace系統(tǒng)為我們記錄下請求的統(tǒng)計信息，比如請求數(shù)目、按照不同請求時間統(tǒng)計的分布等。
需要說明的是，這套系統(tǒng)暴露了一個http服務，我們可以通過debug開關在運行時按需打開或者關閉，以減少資源消耗。
監(jiān)控
1.確定監(jiān)控指標
在接到為整個系統(tǒng)搭建監(jiān)控系統(tǒng)這個任務時，我們面對的第一個問題是要監(jiān)控什么內容。針對這個問題，GoogleSRE這本書提供了很詳細的回答，我們可以監(jiān)控四大黃金指標，分別是延時、流量、錯誤和飽和度。
延時衡量了請求花費的時間。需要注意的，考慮到長尾效應，使用平均延時作為延時方面的單一指標是遠遠不夠的。相應的，我們需要延時的中位數(shù)90%、95%、99%值來幫助我們了解延時的分布，有一種更好的辦法是使用直方圖來統(tǒng)計延時分布。
流量衡量了服務面臨的請求壓力。針對每個API的流量統(tǒng)計能讓我們知道系統(tǒng)的熱點路徑，幫助優(yōu)化。
錯誤監(jiān)控是指對錯誤的請求結果的統(tǒng)計。同樣的，每個請求有不同的錯誤碼，我們需要針對不同的錯誤碼進行統(tǒng)計。配合上告警系統(tǒng)，這類監(jiān)控能讓我們盡早感知錯誤，進行干預。
飽和度主要指對系統(tǒng)CPU和內存的負載監(jiān)控。這類監(jiān)控能為我們的擴容決策提供依據(jù)。
2.監(jiān)控選型
選擇監(jiān)控方案時，我們面臨的選擇主要有兩個，一是公司自建的監(jiān)控系統(tǒng)，二是使用開源Prometheus系統(tǒng)搭建。這兩個系統(tǒng)的區(qū)別列在下表中。
考慮到我們的整個系統(tǒng)大約有100個容器分布在30臺虛擬機上，Prometheus的單機存儲對我們并不是瓶頸。我們不需要完整保留歷史數(shù)據(jù)，自建系統(tǒng)的最大優(yōu)勢也不足以吸引我們使用。相反，由于希望能夠統(tǒng)計四大黃金指標延生出的諸多指標，Prometheus方便的DSL能夠很大程度上簡化我們的指標設計。
最終，我們選擇了Prometheus搭建監(jiān)控系統(tǒng)。整個監(jiān)控系統(tǒng)的框架如下圖所示。
各服務將自己的地址注冊到consul中，Prometheus會自動從consul中拉取需要監(jiān)控的目標地址，然后從這些服務中拉取監(jiān)控數(shù)據(jù)，存放到本地存儲中。在Prometheus自帶的Ｗeb UI中可以快捷的使用PromQL查詢語句獲取統(tǒng)計信息，同時，還可以將查詢語句輸入grafana,固定監(jiān)控指標用于監(jiān)控。
此外，配合插件AlertManager,我們能夠編寫告警規(guī)則，當系統(tǒng)出現(xiàn)異常時，將告警發(fā)送到手機／郵件／信箱。
日志
1.日志格式
一個經常被忽略的問題是如何選擇日志記錄的格式。良好的日志格式有利于后續(xù)工具對日志內容的切割，便于日志存儲的索引。我們使用logrus來打印日志到文件，logrus工具支持的日志格式包裹以空格分隔的單行文本格式、json格式等等。
文本格式 Json格式 |
2.端到端鏈路上的調用日志收集
在微服務架構中，一個業(yè)務請求會經歷多個服務，收集端到端鏈路上的日志能夠幫助我們判斷錯誤發(fā)生的具體位置。在這個系統(tǒng)中，我們在請求入口處，生成了全局ID，通過gRPC中的context將ID在鏈路中傳遞。將不同服務的日志收集到graylog中，查詢時就能通過一個ID，將整個鏈路上的日志查詢出來。
什么是go
go是golang的簡稱，golang 是Google開發(fā)的一種靜態(tài)強類型、編譯型、并發(fā)型，并具有垃圾回收功能的編程語言，其語法與 C語言相近，但并不包括如枚舉、異常處理、繼承、泛型、斷言、虛函數(shù)等功能。
看完上述內容是否對您有幫助呢？如果還想對相關知識有進一步的了解或閱讀更多相關文章，請關注創(chuàng)新互聯(lián)行業(yè)資訊頻道，感謝您對創(chuàng)新互聯(lián)的支持。
網站欄目：基于Go技術棧的微服務構建是怎樣的
文章鏈接：http://www.dlmjj.cn/article/gggoos.html
