近幾年誕生了很多微服務框架,比如JAVA的Spring Cloud、Dubbo;Golang的GoKit和GoMicro以及NodeJs的Seneca。幾乎每種主流語言都有其對應的微服務框架。
目前創新互聯公司已為數千家的企業提供了網站建設、域名、網頁空間、綿陽服務器托管、企業網站設計、臺安網站維護等服務,公司將堅持客戶導向、應用為本的策略,正道將秉承"和諧、參與、激情"的文化,與客戶和合作伙伴齊心協力一起成長,共同發展。
Go在微服務框架中有其獨特的優勢,至于優勢在哪,自行google。
1、GoKit框架
這是一個工具包的集合,可以幫助攻城獅構建強大、可靠和可維護的微服務。提供了用于實現系統監控和彈性模式組件的庫,例如日志、跟蹤、限流、熔斷等。
基于這個框架的應用程序架構由三個主要的部分組成:
傳輸層:用于網絡通信,服務通常使用HTTP或者gRPC等網絡傳輸協議,或者使用NATS等發布訂閱系統相互通信。
接口層:是服務器和客戶端的基本構建塊。每個對外提供的接口方法都會定義為一個Endpoint,一遍在服務器和客戶端之間進行網絡通信,每個端點使用傳輸層通過HTTP或gRPC等具體通信模式對外提供服務
服務成:具體的業務邏輯實現
2、GoMicro框架
這是一個基于Go語言實現的插件化RPC微服務框架。提供了服務發現、負載均衡、同步傳輸、異步通信以及事件驅動等機制,嘗試簡化分布式系統之間的通信,讓開發者更專注于自身業務邏輯的開發。
GoMicro的設計哲學是可插拔的架構理念,提供了可快速構建系統的組件,并且可以根據自身的需求對GoMicro提供的默認實現進行定制。所有插件都可在倉庫github.com/micro/go-plugins 中找到。
一、服務注冊中心的由來
假如沒有服務注冊中心,我們會干些什么事情呢?
在傳統行業的項目架構中以下的方案最為常見了:
這種架構開發、部署都是最簡單的,一般適用于中小企業訪問量并不是太多的情況下,各個系統服務一臺機器就搞定了。系統之間的調用也是拿到對方的IP+PORT直接連接。
接下來可能因為應用B開始訪問量大了,單臺機器已經不能滿足我們的需求,于是一些反向代理工具應運而出,其中比較常見的有Apache、Nigix,架構演變為:
相比之前的應用B的單臺機器訪問,這種nginx代理的方式減輕了服務器的壓力,但是可能會出現Nginx掛了,那么整個服務也不可用,于是又來了這么一套架構:
這樣看方案算是完美了吧。然后事情并不是想象的那么一帆風順,這還只是應用A調用一個應用B,如果應用A調用的可能是應用B、C、D、E...,這種完全就不知道他后面到底還想干嘛,這種架構看似可以,但是絕對會累死運維的(nginx的配置將會非常混亂,直接導致運維不干了)。
服務注冊中心干些什么事情呢?
上面提到的那種靠人力(主要是運維干的事情)比較繁瑣,還不好維護,有這么幾點不方便:應用服務的地址變了、雙十一搞活動服務器新增等等。那么我們可以有這么的一種架構:
服務注冊中心主要是維護各個應用服務的ip+port列表,并保持與各應用服務的通訊,在一定時間間隔內進行心跳檢測,如果心跳不能到達則對服務IP列表進行剔除,并同時通知給其它應用服務進行更新。同樣要是有新增的服務進來,應用服務會向注冊中心進行注冊,服務注冊中心將通知給其它應用進行更新。每個應用都有需要調用對應應用服務的地址列表,這樣在進行調用時只要處理客戶負載雜均衡即可。
二、微服務注冊中心
1.Zookeeper
ZooKeeper是一個分布式的,開放源碼的分布式應用程序協調服務,是Google的Chubby一個開源的實現,是Hadoop和Hbase的重要組件。它是一個為分布式應用提供一致性服務的軟件,提供的功能包括:配置維護、域名服務、分布式同步、組服務等。
上面的話直接摘抄百度百科的內容,國內很多公司做分布式開發最初的選型大部分都是采用dubbo框架。dubbo框架注冊中心主要使用zookeeper。zookeeper服務端與客戶端的底層通訊為netty。zookeeper采用CAP理論中的CP,一般集群部署最少需要3臺機器。
2.Euraka
先來看一下euraka的架構圖:
Register:服務注冊
當Eureka客戶端向Eureka Server注冊時,它提供自身的元數據,比如IP地址、端口,運行狀況指示符URL,主頁等。
Renew:服務續約
Eureka客戶會每隔30秒發送一次心跳來續約。 通過續約來告知Eureka Server該Eureka客戶仍然存在,沒有出現問題。 正常情況下,如果Eureka Server在90秒沒有收到Eureka客戶的續約,它會將實例從其注冊表中刪除。 建議不要更改續約間隔。
Fetch Registries:獲取注冊列表信息
Eureka客戶端從服務器獲取注冊表信息,并將其緩存在本地。客戶端會使用該信息查找其他服務,從而進行遠程調用。該注冊列表信息定期(每30秒鐘)更新一次。每次返回注冊列表信息可能與Eureka客戶端的緩存信息不同, Eureka客戶端自動處理。如果由于某種原因導致注冊列表信息不能及時匹配,Eureka客戶端則會重新獲取整個注冊表信息。 Eureka服務器緩存注冊列表信息,整個注冊表以及每個應用程序的信息進行了壓縮,壓縮內容和沒有壓縮的內容完全相同。Eureka客戶端和Eureka 服務器可以使用JSON / XML格式進行通訊。在默認的情況下Eureka客戶端使用壓縮JSON格式來獲取注冊列表的信息。
Cancel:服務下線
Eureka客戶端在程序關閉時向Eureka服務器發送取消請求。 發送請求后,該客戶端實例信息將從服務器的實例注冊表中刪除。該下線請求不會自動完成,它需要調用以下內容:
DiscoveryManager.getInstance().shutdownComponent();
Eviction 服務剔除
在默認的情況下,當Eureka客戶端連續90秒沒有向Eureka服務器發送服務續約,即心跳,Eureka服務器會將該服務實例從服務注冊列表刪除,即服務剔除。
自我保護機制:
既然Eureka Server會定時剔除超時沒有續約的服務,那就有可能出現一種場景,網絡一段時間內發生了 異常,所有的服務都沒能夠進行續約,Eureka Server就把所有的服務都剔除了,這樣顯然不太合理。所以,就有了 自我保護機制,當短時間內,統計續約失敗的比例,如果達到一定閾值,則會觸發自我保護的機制,在該機制下, Eureka Server不會剔除任何的微服務,等到正常后,再退出自我保護機制。自我保護開關(eureka.server.enableself-preservation: false)
3.Consul
consul推薦的架構圖:
Consul不像Euraka的部署那么簡單,他是go語言開發的,需要運維單獨部署,有提供java的客戶端連接,采用的是CAP的CP。
4.Nacos
Euraka是Spring Cloud Netflix早期版本中推薦使用的,后來euraka1.0版本不再維護,euraka2.0已經閉源,導致很多新項目基于Spring Cloud Netflix 開發的選型變遷為Consul.
Nacos是阿里開源的服務注冊中心,它可以與spring cloud aliaba集成使用。
Nacos的官方介紹:
Nacos 致力于幫助您發現、配置和管理微服務。Nacos 提供了一組簡單易用的特性集,幫助您實現動態服務發現、服務配置管理、服務及流量管理。
Nacos 幫助您更敏捷和容易地構建、交付和管理微服務平臺。 Nacos 是構建以“服務”為中心的現代應用架構(例如微服務范式、云原生范式)的服務基礎設施。
Nacos 地圖
Nacos 生態圖
如 Nacos 全景圖所示,Nacos 無縫支持一些主流的開源生態,例如
Spring Cloud
Apache Dubbo and Dubbo Mesh TODO
Kubernetes and CNCF TODO
三、服務注冊與發現技術選型
以下是來自網上的一個分享:
除了上述的幾種以外,筆者更推薦使用Nacos作為服務注冊中心。
推薦理由:
Nacos服務注冊表結構Mapnamespace, Mapgroup::serviceName, Service采用多層次Map結構,控制的顆粒度更細,支持金絲雀模式發布,心跳同步機制也更快速,服務更新更及時。
作用:基于GO語言開發,用于實現分布式系統的服務發現與配置的等管理。
特性:
開發模式的下,一般我們的都是基于客戶端的自注冊的模式進行,意思就是服務啟動的時候,把服務的信息都提交到的我們的注冊中心上。
當我們的Consumerl消費者請求Prodcuer的是,會先從Consul獲取到存貯Producter的數據(地址IP 和端口等)的臨時表,從這個臨時表里面任選一個Producr是的IP和Port,進行服務的請求
當前名稱:go語言注冊微服務管理 go語言 微服務
文章鏈接:http://vcdvsql.cn/article6/hehsig.html
成都網站建設公司_創新互聯,為您提供網站策劃、自適應網站、網站建設、、品牌網站制作、小程序開發
聲明:本網站發布的內容(圖片、視頻和文字)以用戶投稿、用戶轉載內容為主,如果涉及侵權請盡快告知,我們將會在第一時間刪除。文章觀點不代表本網站立場,如需處理請聯系客服。電話:028-86922220;郵箱:631063699@qq.com。內容未經允許不得轉載,或轉載時需注明來源: 創新互聯