這將是一(yi)個(ge)系列，講解 的設(she)計(ji)思考，可以理(li)解為原理(li)+最佳(jia)實踐+產品設(she)計(ji)時(shi)的折中(zhong)取舍(she)。

本系列其他文章：

下面開始第2篇。

上一篇(pian)我(wo)們遺留了一個話題，就是(shi)如果(guo)貴司有多個數據中(zhong)(zhong)心，而且數據中(zhong)(zhong)心之(zhi)間網絡鏈路(lu)較差，此時(shi)應該怎么(me)辦？

夜鶯邊緣架構模式

舉個例子(zi)，假設有(you)北(bei)京、上海(hai)、美東三個數據中心(xin)，北(bei)京和上海(hai)之(zhi)間(jian)有(you)良好的專線(xian)打通，而美東和國內(nei)網絡鏈路較(jiao)差(cha)。

北(bei)京、上海、美東三地均(jun)部署了服務，指標和日志都選擇落在本地，而非傳輸到中(zhong)心(xin)。假(jia)設指標使用(yong)(yong) VictoriaMetrics 存(cun)儲，日志使用(yong)(yong) ElasticSearch 存(cun)儲，整體示例如下：

北(bei)京(jing)(jing)(jing)(jing)、上海(hai)機房(fang)既然(ran)網絡鏈路很好，姑且可以看做(zuo)是同一個機房(fang)，用一套夜鶯統一處理，比如就把夜鶯部署在北(bei)京(jing)(jing)(jing)(jing)機房(fang)，讓夜鶯讀取北(bei)京(jing)(jing)(jing)(jing)、上海(hai)的(de)數據(ju)源(yuan)，做(zuo)告警(jing)判定。那美東(dong)呢？讓北(bei)京(jing)(jing)(jing)(jing)機房(fang)的(de)夜鶯讀取美東(dong)的(de)數據(ju)源(yuan)做(zuo)告警(jing)是不(bu)行的(de)，因為網絡鏈路不(bu)好，經(jing)常超時。

告(gao)警判定是周(zhou)期(qi)性(xing)的(de)，比如15秒一(yi)次，很頻繁，我們需要確(que)保查詢時(shi)網絡(luo)鏈路(lu)是好的(de)，最佳(jia)實踐(jian)就(jiu)是把告(gao)警引擎(qing)直接部署(shu)到美東(dong)，這樣本機房查詢，就(jiu)沒問題了。

所(suo)以(yi)，夜鶯引入了(le)邊緣機房(fang)部署架構。可以(yi)把告(gao)(gao)警(jing)引擎抽離出來作為一個(ge)單(dan)獨的(de)模(mo)塊，部署到美東。這個(ge)模(mo)塊可以(yi)從(cong)中心端夜鶯同步告(gao)(gao)警(jing)規(gui)則(ze)，把告(gao)(gao)警(jing)規(gui)則(ze)存在內存里，然后(hou)查詢本地(di)數據源的(de)數據，做告(gao)(gao)警(jing)判定(ding)。

架構示意圖：

夜鶯中心端的進程叫 n9e，n9e 是 nightingale 的縮寫，邊緣機房（這里是指美東機房）單獨部署了一個 n9e-edge 進程。

n9e-edge 進程要連中心端的 n9e，所以你在 n9e-edge 的配置文件里，需要指定 n9e 的(de) HTTP 地址(zhi)和(he)認證(zheng)信息(xi)（如需）。

如果美東和北京的網絡臨時中斷了，影響也不大，美東的 n9e-edge 沒法從北京的 n9e 同步告警規則了，不算太大的問題。另外 n9e-edge 產生的告警事件沒法寫到中心數據庫了，所以你在頁面上沒法看到相關的告警事件，但只要美東的外網出口沒問題，n9e-edge 產生的(de)告警(jing)事件還是可(ke)以(yi)推送出去的(de)，因為告警(jing)媒(mei)介都是走的(de)外(wai)網，比如(ru)釘釘、企微(wei)、Slack，都是外(wai)網 SaaS 服務。

預告

本(ben)篇先(xian)到這里。下(xia)一篇預告(gao)：夜鶯(ying)沒有自(zi)研時序存儲，卻又提供了 agent，有點擰(ning)巴，到底是(shi)為(wei)啥？