[[436827]]

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

#問題1

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

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

#問題2

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

#問題3

IP轉發，如果有一臺服務器A,上面沒有實際的數據庫，有服務器B，如果需要業務訪問服務器A，能夠直接將請求轉發至服務器B,是否可以實現?

目前討論了3種實現方式：

1)服務器A轉發至服務器B,是一種預配置的方式

2)服務器A即時觸發，轉發請求至服務器B,難度相對較大

3)在服務器A的配置前側做相應的配置，能夠更前置處理

#問題4

如果業務服務器有10臺，在數據庫層面已經開通了防火墻權限，那么如何快速驗證業務服務器的權限是否已經開通

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

或者是申請數據庫權限后過了好幾天之后才發現有問題

#問題5

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

如果能夠提供相應的機制能夠知曉相應的服務器IP已經下線，就可以聯動處理這些問題

#問題6

數據庫容器化中網絡層面的支持可以細化到什么粒度?

#問題7

基于域名的方式，需要應用服務器安裝Consul agent，同時配置dnsmasq做域名轉發，如果新增業務都沒有使用安裝Consul agent，會基于網絡DNS做解析

基于API的方式，業務需要一定的改造，但是基于API的方式是一種無客戶端的狀態，配置相對簡單，更容易管理

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

本文轉載自微信公眾號「楊建榮的學習筆記」，可以通過以下二維碼關注。轉載本文請聯系楊建榮的學習筆記公眾號。