[[436827]]

昨天和網(wǎng)絡(luò)組的同學(xué)閑聊，突然發(fā)現(xiàn)數(shù)據(jù)和網(wǎng)絡(luò)層之間已經(jīng)好久沒有溝通了，其實這兩塊的銜接還是非常重要的，尤其是在高可用方向。我也提出了幾個問題，每個問題都覺得可以聊好久，在先期的溝通中，我覺得不著急給出答案，得到答案，而是經(jīng)過分析之后更合適的答案，所以在文中也是拋出問題，而不是刻意給出答案。

#問題1

服務(wù)器配置了Consul域名，有的業(yè)務(wù)使用IP連接，有的業(yè)務(wù)使用Consul 域名連接，怎么判斷業(yè)務(wù)到底是使用了IP還是域名?

問題背景：數(shù)據(jù)庫高可用的改造過程中，會出現(xiàn)一些業(yè)務(wù)未改造完整，有部分業(yè)務(wù)使用IP連接的情況，這個時候如果數(shù)據(jù)庫發(fā)生了故障，數(shù)據(jù)庫做了切換，從一臺服務(wù)器切換到另外一臺服務(wù)器，那么業(yè)務(wù)訪問的時候如果還使用IP就會報錯，如果能夠提前預(yù)判，就能夠把問題前置處理

#問題2

目前IP的使用是有基于VIP的使用模式，IP漂移的過程處理還是比較快的，在IP層是否還有其他的解決方案

#問題3

IP轉(zhuǎn)發(fā)，如果有一臺服務(wù)器A,上面沒有實際的數(shù)據(jù)庫，有服務(wù)器B，如果需要業(yè)務(wù)訪問服務(wù)器A，能夠直接將請求轉(zhuǎn)發(fā)至服務(wù)器B,是否可以實現(xiàn)?

目前討論了3種實現(xiàn)方式：

1)服務(wù)器A轉(zhuǎn)發(fā)至服務(wù)器B,是一種預(yù)配置的方式

2)服務(wù)器A即時觸發(fā)，轉(zhuǎn)發(fā)請求至服務(wù)器B,難度相對較大

3)在服務(wù)器A的配置前側(cè)做相應(yīng)的配置，能夠更前置處理

#問題4

如果業(yè)務(wù)服務(wù)器有10臺，在數(shù)據(jù)庫層面已經(jīng)開通了防火墻權(quán)限，那么如何快速驗證業(yè)務(wù)服務(wù)器的權(quán)限是否已經(jīng)開通

問題背景：目前業(yè)務(wù)申請權(quán)限后，如果數(shù)據(jù)庫端配置有誤(通常是數(shù)據(jù)庫用戶配置等)，在業(yè)務(wù)發(fā)布上線時發(fā)現(xiàn)問題再緊急處理影響就會比較大

或者是申請數(shù)據(jù)庫權(quán)限后過了好幾天之后才發(fā)現(xiàn)有問題

#問題5

數(shù)據(jù)庫的防火墻里面有很多的服務(wù)器IP,有些服務(wù)器下線了之后其實防火墻信息里面就會始終保留這些信息，導(dǎo)致防火墻信息管理比較混亂

如果能夠提供相應(yīng)的機制能夠知曉相應(yīng)的服務(wù)器IP已經(jīng)下線，就可以聯(lián)動處理這些問題

#問題6

數(shù)據(jù)庫容器化中網(wǎng)絡(luò)層面的支持可以細化到什么粒度?

#問題7

基于域名的方式，需要應(yīng)用服務(wù)器安裝Consul agent，同時配置dnsmasq做域名轉(zhuǎn)發(fā)，如果新增業(yè)務(wù)都沒有使用安裝Consul agent，會基于網(wǎng)絡(luò)DNS做解析

基于API的方式，業(yè)務(wù)需要一定的改造，但是基于API的方式是一種無客戶端的狀態(tài)，配置相對簡單，更容易管理

目前兩種方式各有利弊，如果是基于純粹IP的方式，在一定程度上能夠做到隔離，即業(yè)務(wù)服務(wù)器訪問一個指定的IP,可能ping就不通，但是這些權(quán)限是可以通過防火墻來控制的。所以在這個方向上是否有更好的方案?

本文轉(zhuǎn)載自微信公眾號「楊建榮的學(xué)習(xí)筆記」，可以通過以下二維碼關(guān)注。轉(zhuǎn)載本文請聯(lián)系楊建榮的學(xué)習(xí)筆記公眾號。