《云計算與虛擬化技術叢書 Service Mesh實戰(zhàn)》—3.4.4　router

3.4.4　router

Linkerd的核心工作是路由，即接收應用請求，然后將應用請求轉發(fā)到正確的目的地址進行處理，它無需關心應用請求的具體有效載荷，只負責轉發(fā)。而這一核心功能是通過配置router實現(xiàn)的，其配置包括Linkerd支持哪種協(xié)議的RPC請求，如HTTP/1.1、HTTP/2等協(xié)議，一個或多個服務器，客戶端以及服務等。還有，Linkerd可配置一個或多個router，每個router代表對某種特定協(xié)議RPC支持。對某個特定的router，要么處理輸出流量，要么處理輸入流量，處理輸出流量的router稱為outgoing router，這種情況下應用請求流量流入outgoing router而不直接轉發(fā)到真實目的地址，如上執(zhí)行curl -s http://192.168.1.11:62000/users/tom/bookings時，請求將被代理到本地outgoing router，然后Linkerd轉發(fā)請求到目標地址（真實服務實例地址或者目標router服務器對應地址）。如果是真實服務實例地址，則請求將直接由真實服務實例處理，反之，請求將轉發(fā)到目標router服務器對應地址，如上UserService訪問BookingService時，流經(jīng)UserService所在機器Linkerdoutgoing router的請求將被轉發(fā)到BookingService所在機器的Linkerd，然后轉發(fā)請求到真實服務實例進行處理，我們稱這個處理輸入流量的router為incoming router。接下來我們開始介紹如何配置router。

protocol：每個router必須配置protocol，不能缺省，Linkerd支持配置http、h2、mux、thrift和thriftmux。不同類型的protocol除通用配置參數(shù)外，還需要配置協(xié)議相關的參數(shù)，具體可參考Linkerd官方文檔配置http、h2、thrift、mux和thriftmux。下面以http協(xié)議為例子介紹如何配置http協(xié)議相關參數(shù)，針對http協(xié)議，盡管其支持配置多個參數(shù)，但通常主要配置以下參數(shù)。

dstPrefix：默認為/svc，可自定義，所有http協(xié)議支持的identifier將請求轉化為服務名字時以該配置為前綴，比如/svc/booking。

httpAccessLog：設置訪問日志存儲路徑，默認為空，即不存儲訪問日志。

identifier：設置http協(xié)議支持的identifier，配置一個或者多個均可，當配置多個時，按順序依次處理，返回第一個identifier處理的結果。identifier的主要作用是將應用請求轉化為服務名字，服務名字以dstPrefix對應的值打頭，然后通過服務名字尋址真實目的地址。當前版本Linkerd為http協(xié)議提供如下indentifier，實際環(huán)境中可根據(jù)需求選擇一個或多個indentifier，而具體配置參考官方文檔（https://linkerd.io/config/1.3.6/linkerd/index.html#http-1-1-identifier·）詳細介紹，在此不再一一介紹。

io.l5d.methodAndHost

io.l5d.path

io.l5d.header

io.l5d.header.token

io.l5d.static

io.l5d.ingress

io.l5d.k8s.istio

默認identifier為io.l5d.header.token，針對該identifier需要配置HTTP頭部header，默認為Host，即：

identifier:

kind: io.l5d.header.token

header: Host

其中header可設置為應用支持的HTTP官方和非官方頭部。當應用請求經(jīng)過該identifier鑒定后，生成服務名字形式為/dstPrefix/[headerValue]，如執(zhí)行命令curl -s -H “Host：booking.service.consul” localhost:4140向Linkerd發(fā)送請求，則生成服務名字/svc/booking.service.consul。

除官方提供的identifier, Linkerd甚至支持開發(fā)自定義的identifer以滿足特定需求，后續(xù)第9章將詳細介紹如何開發(fā)自定義的identifier。

而其他http配置參數(shù)，比如HTTP請求頭部大小、請求大小、響應大小等，通常使用默認值即可。示例中該部分配置為：

- protocol: http

httpAccessLog: /tmp/access_outgoing.log

dstPrefix: /svc? ? # 默認值，已省略

identifier: io.l5d.header.token # 默認值，已省略

server：除配置protocol外，每個router需配置一個或多個server，需要注意的是，server是protocol無關的，無論配置何種protocol，都要配置server，其配置包括server的ip地址，監(jiān)聽端口port, 能處理的最大并行請求數(shù)maxConcurrentRequests以及配置tls使其可處理加密的應用請求等。示例中我們配置兩個router，每個router對應一個server，分別監(jiān)聽不同端口用于不同的目的：

- protocol: http

...

servers:

- port: 4140

ip: 0.0.0.0

- protocol: http

...

servers:

- port: 4141

ip: 0.0.0.0

此時我們只簡單配置server的監(jiān)聽端口及IP地址，其他配置如tls、clearContext等后續(xù)章節(jié)會涉及并詳細介紹。

dtab：dtab由一系列路由規(guī)則組成，以服務名字為輸入，然后將其轉換為客戶端名字，更多內(nèi)容將在第4章詳細介紹，示例中dtab配置如：

dtab: |

/consul => /#/io.l5d.consul/dc1;

/host? ?=> /consul;

/svc? ? => /$/io.buoyant.http.subdomainOfPfx/service.consul/host;

針對該dtab配置，如果服務名字為/svc/booking.service.consul，那么dtab如何以該服務名字為輸入將其轉換為客戶端名字？由于匹配dtab規(guī)則dentry是從底到頂進行匹配，因此，首先跟/svc? ? => /$/io.buoyant.http.subdomainOfPfx/service.consul/host;進行匹配，根據(jù)上述關于rewriting namer的介紹，可知匹配結果為/host/booking，然后跟/host? ?=> /consul;匹配，匹配結果為/consul/booking，最后匹配/consul => /#/io.l5d.consul/dc1;，匹配結果為/#/io.l5d.consul/dc1/booking，即客戶端名字。

interpreter：interpreter決定如何解析服務名字和客戶端名字，其配置包括兩部分。

kind：kind指定從什么地方讀取dtab和namer信息將服務名字轉換為客戶端名字和客戶端名字轉換為IP地址和端口集合。目前Linkerd支持配置的類型有：

default

io.l5d.namerd

io.l5d.namerd.http

io.l5d.mesh

io.l5d.fs

io.l5d.k8s.configMap

默認kind為default，意味著使用Linkerd配置文件中配置的namer和router配置塊的dtab進行服務名字和客戶端名字解析，若未顯示配置namer，則Finagle提供的全局namer接管解析工作，通常全局namer以/$/打頭，如/$/inet；如果設置為io.l5d.namerd、io.l5d.namerd.http和io.l5d.mesh，則從遠端namerd服務中讀取dtab規(guī)則進行服務名字解析和namer配置進行客戶端名字解析，此時即使本地Linkerd配置文件中配置namer和dtab，仍然忽略不計。關于namerd服務的詳細信息，請參考第6章；如果設置為io.l5d.fs，Linkerd通過配置文件中namer配置進行客戶端名字解析，但dtab規(guī)則從指定的文件中讀取，而且支持熱更改，即更改文件中的dtab規(guī)則無需重啟Linkerd服務，Linkerd自動加載；如果設置為io.l5d.k8s.configMap，Linkerd仍然通過配置文件中namer進行客戶端名字解析，但dtab規(guī)則通過Kubernetes API從ConfigMap讀取。當kind為io.l5d.fs和io.l5d.configMap時，本地Linkerd配置文件中配置的dtab均被忽略。更多interpreter的信息請參考官方文檔（https://linkerd.io/config/1.3.6/linkerd/index.html#interpreter）中的詳細介紹。

transformer：如果需要對interpreter已解析的目的地址即IP地址和端口做更進一步的轉化，比如替換端口，transformer可以幫你實現(xiàn)。如果為interpreter配置一個或者多個transformer，轉換時以它們配置的先后順序依次生效，一旦其中一個transformer生效，則剩下的transformer被忽略。當前版本Linkerd支持配置如下transformer：

io.l5d.localhost

io.l5d.specificHost

io.l5d.port

io.l5d.k8s.daemonset

io.l5d.k8s.localhost

io.l5d.replace

io.l5d.const

其中io.l5d.localhost和io.l5d.port以及io.l5d.k8s.daemonset和io.l5d.k8s.localhost是最常見的transformer。而io.l5d.localhost和io.l5d.k8s.localhost主要用于過濾掉與本地Linkerd IP地址不同的地址，剩下與本地Linkerd地址相同的部分，例如地址集192.168.1.12:4140 192.168.1. 13:4140，Linkerd運行于192.168.1.12:4140，則經(jīng)過上述兩個transformer轉換后，剩下192.168.1.12:4140，常配置于incoming router，但io.l5d.k8s.localhost用于Kubernetes環(huán)境。io.l5d.porttransformer替換地址集的端口為指定端口，比如地址集192.168.1.12:39462 192.168.1.13:42251，指定端口為8082，則轉后為192.168.1.12:8082 192.168.1.13:8082，即請求被發(fā)送到8082端口而不是替換前的39462和42251端口。而io.l5d.k8s.daemonset主要用于Kubernetes環(huán)境，將Kubernetes集群中運行Pod對應的地址和端口轉換為某個以DaemonSet運行的服務對應的IP和端口，比如Pod地址集為10.254.1.12:39462 10.255.1.13:42251，其中10.254.1.12:39462對應Pod的主機為192.168.1.12，而以DaemonSet方式運行的Linkerd服務IP地址為192.168.1.12，端口為4140，則請求發(fā)送到192.168.1.12:4140，過濾掉另外一個Pod，然后由Linkerd轉發(fā)到目標服務地址。我們可認為該transformer是io.l5d.localhost或者io.l5d.k8s.localhost和io.l5d.port的結合體，不但過濾掉無用的地址，而且替換端口。io.l5d.port和io.l5d.k8s.daemonset常用于outgoing router。更多transformer的具體配置可參考官方文檔（https://Linkerd.io/config/1.3.6/Linkerd/index.html#transformer）中的詳細介紹。

另外，需注意的是Linkerd配置中有兩個地方可配置transformer，其中第一個地方是namer，然后是interpreter，它們的區(qū)別是namer中配置的transformer只對該namer解析的地址進行轉換，而interpreter中配置的transformer會對所有namer解析的地址進行轉換，轉換范圍更大。因此，如果不想對某些namer解析的地址進行轉換，則無需在interpreter配置transformer，只需在需要進行地址轉換的namer上配置transformer便可實現(xiàn)。

示例中，我們?yōu)閮蓚€router分別配置不同的interpreter及transformer：

# outgoing router

interpreter:

kind: default

transformers:

- kind: io.l5d.port

port: 4141

# incoming router

interpreter:

kind: default

transformers:

- kind: io.l5d.localhost

如上述配置，它們的kind都是default，這意味著Linkerd將通過配置文件中的namer進行客戶端名字解析，即類型為io.l5d.consul的namer。假如經(jīng)dtab轉換后的客戶端名字為/#/io.l5d.consul/dc1/booking，則namer將從數(shù)據(jù)中心為dc1的Consul集群中查詢服務booking對應的健康實例，返回其地址和端口信息：192.168.1.12:39462 192.168.1.13:42251。由于在outgoing router和incoming router中已配置transformer，那么transformer如何對輸出的IP地址和端口進行轉化呢？針對outgoing router，io.l5d.port將interpreter得到地址的端口替換為指定的端口4141，則上述IP地址和端口集合被轉換為192.168.1.12:4141 192.168.1.13:4141，端口被替換為4141，實際上4141是incoming router的server端口，即應用請求將被代理到incoming router的server端口。而針對incoming router，io.l5d.localhost過濾interpreter得到的地址和端口集合，保留與本機有相同地址的一個或多個地址和端口，因此上述IP地址和端口集合被轉換為兩個中的一個，如果發(fā)生轉換的機器具有多個服務實例，也可保留多個地址，最終通過負載均衡算法選出最優(yōu)實例進行請求處理，實際取決于轉換發(fā)生在哪一臺機器，若發(fā)生在192.168.1.12這臺機器，則轉換后為192.168.1.12:39462，請求將由該實例處理。

label：router的標識，默認為protocol的值，可自定義，如示例中定義為incoming和outgoing：

label: outgoing

client：Linkerd的client對應Finagle的客戶端模塊，因此Finagle的客戶端模塊支持配置的參數(shù)幾乎都可配置于Linkerd，而Linkerd提供的大部分功能均由client模塊實現(xiàn)。完成dtab從服務名字到客戶端名字的轉換后，在配置Linkerd的client時，可配置為全局配置（io.l5d.gloabl）或靜態(tài)配置（io.l5d.stati? ? ? ? ? ?c）兩種類型之一。

當為全局配置時，client配置對所有服務client生效。

當為靜態(tài)配置時，client配置對匹配特定前綴的client生效，若匹配多個前綴，配置文件中最后一個匹配的優(yōu)先級最高。

client配置主要包括連接池hostConnectionPool，是否支持tls，選擇什么樣的loadBalancer，使用哪一種熔斷機制等。本節(jié)示例中這些都是默認配置，詳細介紹參考后續(xù)第8章，我們將介紹更多關于如何配置client的知識。

service：service定義Linkerd與服務通信時使用的策略，同client配置一樣，可配置為全局配置（io.l5d.global）或靜態(tài)配置（io.l5d.static），全局配置對所有服務生效，而靜態(tài)配置對匹配的服務生效，若匹配多個時，配置文件中最后一個匹配的優(yōu)先級最高。具體配置包括timeout時間totalTimeoutMs，重試機制retries以及responseClassifier。本章示例中也為默認配置，詳細介紹參考后續(xù)第8章內(nèi)容。

虛擬化 云計算

版權聲明：本文內(nèi)容由網(wǎng)絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實的內(nèi)容，請聯(lián)系我們jiasou666@gmail.com 處理，核實后本網(wǎng)站將在24小時內(nèi)刪除侵權內(nèi)容。

版權聲明：本文內(nèi)容由網(wǎng)絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實的內(nèi)容，請聯(lián)系我們jiasou666@gmail.com 處理，核實后本網(wǎng)站將在24小時內(nèi)刪除侵權內(nèi)容。