1. 程式人生 > >Mesos:服務發現與負載均衡

Mesos:服務發現與負載均衡

Mesos: Service Discovery & Load Balancing

這一章主要探討是Mesos關於服務發現與應用的負載均衡的解決方案,主要側重對服務發現與負載均衡進行講解,需要明白的一點,Mesos作為 兩層架構,Marathon作為Mesos的systemd服務,服務發現功能只需要向marathon提供即可,marathon啟動的k8s、 Cloud Foundry都用自身的服務發現功能。

1、Service Discovery with Marathon-Bridge and HAProxy

服務發現的功能實現是為Dcos系統中的服務提供便捷的網路通訊,它的側重點在於對服務進行註冊,更新,查詢等功能,服務發現的實現方法較多, 主要有DNS、集中式服務路由、應用內部實現服務註冊/服務發現等方式,Dcos服務發現功能採用的是Mesos-DNS策略,有關Mesos-DNS的 具體介紹詳見上一篇文章。
通過Mesos-DNS的服務發現策略,可以通過輔助指令碼利用Marathon REST API定時(通過linux crond服務)產生HAProxy 配置檔案,通過diff 生成的hapxoy配置檔案與已有的haproxy,來判斷是否進行reload haproxy操作。

Mesos-slave預設想master提供的埠資源的範圍是31000-32000,當marathon啟動一個task 例項時,所在的mesos-slave會隨意給其繫結一個或多個在其範圍內的埠。需要注意的是應用繫結的實際埠(即mesos-slave分配給它的 埠)和應用在配置時所指定的形式埠(這是以後直接訪問的應用埠)之間的區別,形式埠(即應用埠)是應用執行在marathon的一種名稱空間, 不是直接繫結的,也就是說其他服務也可以繫結這樣一個埠,只是服務不同而已,它間接的被負載均衡器所使用。

服務發現功能,允許marathon上的應用可以通過配置的埠與其他marathon應用進行通訊,這樣做的好處就是,無需知道實際分配的埠是 多少,例如: python的wsgi服務(配置時你指定的是80)需要跟mysql(配置時你指定的327)進行通訊,這樣你可以直接與localhost:327進 行通訊即可。

HAProxy會把請求路由到具體的服務節點上,如果此服務路徑不可達,它將繼續將路由到下一個服務節點。需要注意的是,目前服務發現功能只支援marathon上的應用。

使用 HAProxy

Marathon附帶一個簡單的被叫做 haproxy-marathon-bridge 的shell指令碼以及更高階的Python指令碼 servicerouter.py(這個指令碼在marathon/bin下面)。兩個指令碼都可以將Marathon的REST API列表中正在執行的任務推送到HAproxy的設定檔案中,HAproxy是一個輕量級的TCP/HTTP的代理。haproxy- marathon-bridge提供了一個最小設定功能。 而servicerouter.py支援如SSL解除安裝,sticky連線和虛擬主機的負載均衡的更高階的功能。

負載均衡實現原理就是上述提及的,通過輔助指令碼(這裡是使用haproxy-marathon-bridge)利用Marathon REST API定時(通過linux crond服務)產生HAProxy 配置檔案,通過diff 生成的hapxoy配置檔案與已有的haproxy,來判斷是否進行reload haproxy操作。

下圖描述了在一個叢集分別在兩個節點安裝同一服務,SVC1和SVC2,分配配置的應用埠是1111和2222,可以看到實際分配給它們的是31100和31200。

現有叢集應用

當slave2節點上的SVC2服務通過localhost:2222連線SVC1服務時,HAProxy將把請求轉發到第一配置項SVC1的slave1節點。

HAProxy請求轉發

如果slave1節點掛了,下一次對Localhost:2222的請求,將被轉發到slave2上。

HAProxy轉發

haproxy與Marathon的橋接

通過 haproxy-marathon-bridge指令碼從Marathon生成一個HAProxy配置在leader.mesos:8080執行:

$ ./bin/haproxy-marathon-bridge leader.mesos:8080 > /etc/haproxy/haproxy.cfg

重新載入HAProxy配置而不中斷現有的連線:

$ haproxy -f haproxy.cfg -p haproxy.pid -sf $(cat haproxy.pid)

配置指令碼並重新載入可以通過Cron經常觸發來跟蹤拓撲變化。如果一個節點在重新載入時消失, HAProxy的健康檢查將抓住它並停止向這個node傳送traffic 。

為了方便這個設定,haproxy-marathon-bridge 指令碼以另一種方式可以呼叫安裝指令碼本身,HAProxy和定時任務每分鐘ping一次的Marathon服務,如果有任何改變將立刻重新整理HAProxy。

$ ./bin/haproxy-marathon-bridge install_haproxy_system leader.mesos:8080

Marathon需要ping的列表存按行儲存在 /etc/haproxy-marathon-bridge/marathons

指令碼安裝在 /usr/local/bin/haproxy-marathon-bridge

-cronjob安裝在/etc/cron.d/haproxy-marathon-bridge 注意需要用root來執行。

所提供的只是一個基本的示例指令碼。

servicerouter.py

通過servicerouter.py指令碼從Marathon生成一個HAProxy配置在leader.mesos:8080執行:

$ ./bin/servicerouter.py --marathon http://leader.mesos:8080 --haproxy-config /etc/haproxy/haproxy.cfg

如果有任何變化,將會重新整理haproxy.cfg,這樣HAproxy將會重新自動載入。

servicerouter.py有許多額外的功能,像sticky 會話,HTTP到HTTPS的重定向,SSL解除安裝,VHost支援和模板功能。

2、Service Discovery with Bamboo and HAProxy

場景:當你在Mesos叢集上部署的了一系列的微服務,而這些服務能夠以HTTP方式通過訪問特定的URL來對外提供服務或者對內進行通訊。

  • Mesos 叢集上通過Marathon框架啟動應用(服務),Marathon通過健康檢查(healthcheck)跟蹤它們的狀態
  • Bamboo通過監聽Marathon event以更新HAProxy配置檔案
  • HAProxy ACL規則通過Bamboo進行配置,其能夠根據請求的特徵,如URL規則、hostname、HTTP headers,來匹配應用服務。

處理流程

Bamboo的處理流程跟上述的方案是異曲同工的。

優點:
1. 允許任意URL與服務進行對應
2. 允許通過HTTP Header與服務進行對應
3. 及時的觸發Marathon event來促使HAProxy進行改變
4. HAProxy heavy lifting
不足:
1. 對於非HTP不適用
2. 內部需要有HAProxy故障切換機制除非能夠實現SmartStack架構的服務
3. 內部非流量都鄒另外的hop(HAProxy)

實現

1、安裝HAProxy和Bamboo

HAProxy

HAProxy的安裝可以使用如下方式:
apt-get install haproxy

Bamboo

Bamboo專案地址,你可以通過構建指令碼來製作deb或者rpm的軟體包,當然也可以通過build container進行構建deb 軟體包

docker build -f Dockerfile-deb -t bamboo-build .
docker run -it -v $(pwd)/output:/output bamboo-build
# package ends up as output/bamboo_1.0.0-1_all.deb

需要注意的是,需要修改/var/bamboo/production.json來修改對應的Marathon、HAProxy、Zookeeper的hostname,然後重啟bamboo,通過retsart bamboo-server

2、在marathon上部署應用

編輯ghost.json檔案,填入下述配置:

{
  "id": "ghost-0",
  "container": {
    "type": "DOCKER",
    "docker": {
      "image": "ghost",
      "network": "BRIDGE",
      "portMappings": [{ "containerPort": 2368 }]
    }
  },
  "env": {},
  "instances": 1,
  "cpus": 0.5,
  "mem": 256,
  "healthChecks": [{ "path": "/" }]
}

然後使用curl -X POST -H "Content-Type: application/json" http://marathon.mesos:8080/v2/apps [email protected]即可部署該應用,可以看到marathon UI

Marathon UI

3、Bamboo配置rules

可以定義rules來告訴HAProxy如何去proxy:

rules

首先,在/etc/hosts新增一行,這樣就可以匹配Host Header:

# ip of HAProxy
192.168.99.100 ghost.local
  • 1
  • 2

訪問Bamboo UI,通常是http://haproxy:8000, 然後新增對應的name:ghost-0,如下圖:

Bamboo

檢視一下是否新增成功:

這裡寫圖片描述

local

參考文件:
1、Service Discovery mesosphere
2、marathon-lb github
3、Service Discovery pi
4、Bamboo-haproxy-marathonbamboo
5、數人科技mesosphere中文文件

作者

中移蘇研:zouyee、曹高晉

相關推薦

Mesos:服務發現負載均衡

Mesos: Service Discovery & Load Balancing 這一章主要探討是Mesos關於服務發現與應用的負載均衡的解決方案,主要側重對服務發現與負載均衡進行講解,需要明白的一點,Mesos作為 兩層架構,Marathon作為Mesos的sys

《Istio官方文件》—— 服務發現負載均衡

原文連結  譯者:carvendy 服務發現與負載均衡   本文講述Istio在服務網格中,如何對互動的服務進行負載均衡。   服務註冊: Istio假定存在一個服務可以將pod/VM的地址資訊註冊上去。假設一個新的服務可以自動註冊上去,而當服務不健康的時候可以自動移除。管理平臺,比如說Kub

SpringCloud服務發現負載均衡ribbon(三)

SpringCloud學習總結 3、服務發現與負載均衡ribbon 一、服務發現 修改provider8001主啟動類,增加註解@EnableDiscoveryClient package com.atguigu.springcloud; import org.spri

從零開始入門 | Kubernetes 中的服務發現負載均衡

作者 | 阿里巴巴技術專家  溪恆 一、需求來源 為什麼需要服務發現 在 K8s 叢集裡面會通過 pod 去部署應用,與傳統的應用部署不同,傳統應用部署在給定的機器上面去部署,我們知道怎麼去呼叫別的機器的 IP 地址。但是在 K8s 叢集裡面應用是通過 pod 去部署的, 而 pod 生命週期是短暫

Spring Cloud ---- 服務消費負載均衡(Rest + Ribbon )

  上一篇主要寫了基於Eurake的服務的註冊,主要就是建立註冊中心,建立服務者,將服務者註冊到註冊中心,完成服務的暴露。這一篇主要寫服務的消費與服務消費的負載均衡。   服務的呼叫方式有兩種,Rest + ribbon ,另一鍾是feign,feign集成了ribbon。這一篇主要說前者.   因為服務

Spring Cloud ---- 服務消費負載均衡(feign)

req 啟動文件 創建 code cli 負載均衡。 auto request 文件   feign是一個聲明式的偽客戶端,只需要創建一個接口並且註解,它具有可插拔的特性。feign集合了Ribbon,再與Eurake結合實現服務的註冊發現與負載均衡。結合Hystrix,具

基於consul實現微服務服務發現負載均衡

一. 背景 隨著2018年年初國務院辦公廳聯合多個部委共同釋出了《國務院辦公廳關於促進“網際網路+醫療健康”發展的意見(國辦發〔2018〕26號)》,國內醫療IT領域又迎來了一波網際網路醫院建設的高潮。不過網際網路醫院多基於實體醫院建設,雖說掛了一個“網際網路”的名號,但網

Eureka + Ribbon實現微服務服務發現負載均衡

目錄 1:原理結構圖 2:搭建Eureka Server服務註冊中心 3:搭建Eureka Provider (服務提供者,即Eureka Client) 4:搭建 Eurka-Consumer 1:原理結構圖 2:搭建Eureka Server服務註冊中心 建

Docker(九) - Swarm服務(service)負載均衡

需要準備的: 一臺管理節點主機(可虛擬)和倆臺worker工作節點主機(可虛擬)。 實驗的機器都需要存在你要執行的映象。 進入管理節點終端 格式:docker service create --replicas 數量 -p 訪問埠:容器埠 --name 服務名

kubernetes服務訪問負載均衡(一)

當使用kubernetes來發布應用時,Pod例項的生命週期是短暫,PodIP也是易變的。所以kubernetes中抽象了一個叫Service的概念,給應用提供一個固定的訪問入口。 定義一個Service 假如現在:你有一個tomcat映象,你用它建立了

用DCOS和marathon-lb實現服務發現負載均衡:第一部分

最近在研究使用Mesos,對marathon-lb和mesos-dns等諸多工具,只是停留在知道和會用的階段,特別是對於基於marathon-lb的HAProxy的應用分組和使用更是一頭霧水。現在資料也少,看了官網上的這篇文章覺得講得還算是全面。兄弟英文水平差,

用DCOS和marathon-lb實現服務發現負載均衡:第二部分

最近在研究使用Mesos,對marathon-lb和mesos-dns等諸多工具,只是停留在知道和會用的階段,特別是對於基於marathon-lb的HAProxy的應用分組和使用更是一頭霧水。現在資料也少,看了官網上的這篇文章覺得講得還算是全面。兄弟英文水平差,

服務SpringCloud之服務呼叫負載均衡

上一篇我們學習了服務的註冊與發現,本篇部落格是在上一篇的基礎上學習服務的呼叫。上一部落格主要建立了Eureka的服務端和一個Client,該Client包含了一個Controller用來提供對外服務供外部呼叫,可以作為生產者。 一、引入依賴 前面建立了EurekaClient的專案,在專案中引入了spri

基於gRPC的註冊發現負載均衡的原理和實戰

[gRPC](https://github.com/grpc/grpc-go)是一個現代的、高效能、開源的和語言無關的通用RPC框架,基於HTTP2協議設計,序列化使用PB(Protocol Buffer),PB是一種語言無關的高效能序列化框架,基於HTTP2+PB保證了的高效能。[go-zero](http

Marathon-lb 服務自動發現負載均衡

lb marathon Marathon-lb用途在使用Marathon+Mesos 的容器集群中,我們會構建很多個容器,這些容器在不同的slave上分配了不同的隨機端口,這些Docker容器在HA模式下運行,如果任何slave節點故障導致容器實例意外退出,它將自動重新創建到健康的節點上。 所以我們不

Spring Cloud 服務註冊發現-路由-負載均衡-全鏈路日誌跟蹤-監控

Spring Cloud Netflix / Nodejs 嘗試使用Spring Cloud Netflix 加 Nodejs 技術棧混合搭建微服務。 (示例並無任何業務意義,只為做演示) 程式碼: https://github.com/choelea/sp

白話講解微服務註冊發現負載均衡

一、公益圖書館例子 筆者不想直接用專業的術語來說明“微服務註冊與發現”,所以我們來看生活中的一個案例:“公益圖書館”。隨著人們生活水平的不斷提高,追求精神食糧的朋友也越來越多。筆者曾經在一些城市看見過公益圖書館,其執行邏輯是:一些公益組織和個人提供一塊場所,然後由組織內的人向圖書館內捐書。捐出的書越多,一

EG:nginx反向代理兩臺web服務器,實現負載均衡 所有的web服務共享一臺nfs的存儲

分享 代理服 /dev/ 負載均衡 chmod 修改 修改配置 防火墻 usr step1: 三臺web服務器環境配置:iptables -F; setenforce 0 關閉防火墻;關閉setlinux step2:三臺web服務器 裝軟件 step3:主機修改配置文件

【Web】Nginx 反向代理負載均衡

連接 代理服務器 body 後端服務 style 執行 class redirect 配置文件 反向代理   反向代理(Reverse Proxy)方式是指以代理服務器來接受internet上的連接請求,然後將請求轉發給內部網絡上的服務器,並將從服務器上得到的結果返回給in

Ngnix反向代理負載均衡[轉]

web 客戶端連接 虛擬域名 安裝 服務器性能 正則匹配 服務端 file add nginx啟動和關閉(centos平臺) /usr/local/nginx/sbin/nginx #啟動 /usr/local/nginx/sbin/nginx -s re