在 Azure 中 VNet 是串起內網通連的基礎，若要讓兩條不同的 VNet 彼此可以互通，我們可以使用 peering 來達成目的。而當產品架構日益龐大之後，VNet 的數量也會隨之增長，此時過多的 peering 會致使服務間的網路拓樸變得錯綜複雜且不易維護，這時可以考慮使用 Private Link 來有效降低過多 peering 所造成的耦合性。本文將簡述網路架構的演進過程以及如何使用 Private Link 來減少 VNet peering 所帶來的耦合關係。
前言
通常在有切分功能型服務的架構中，都會有服務相依性的現象存在。
這邊我自定義兩個名詞來區分服務相依的對象： Provider 及 Consumer。
Provider 主要是負責提供基礎服務給 Consumer 叫用而存在，如下圖。
Provider 的角色可能是底層的權限驗證系統，或是如 Elasticsearch 這般的日誌服務等等，它扮演的大多是比較偏向基礎設施類型的通用服務。
而 Consumer 的角色就比較多元一點了，只要會呼叫 Provider 的，在這邊都通稱為 Consumer。
網路架構演進過程
接著我想簡單描述一下服務網路架構的從 0 開始的整個演進過程。
畢竟並不是每個專案一開始就需要這麼龐大的架構支撐。
這邊是以我自身經驗為主，可能不一定適用於每個團隊現況。
---
通常在專案之初，服務會是最小且最簡單的規模。
在這個時期，我們可以考慮將 Provider 及 Consumer 放在同一個 VNet 即可，這樣也可以省下 peering 所造成的額外費用。
而實務上可能會因為公司的政策方針，或是一些特殊的條件限制，導致我們必須將 Provider 及 Consumer 置於不同的 VNet 中。
當服務數量還不是太多的狀況，使用 VNet peering 會是最簡單也最直覺的解決方案。
不過當 Consumer 的數量日益增加之後，peering 也會跟著變多，而通常實務上 peering 的數量可能不僅於此。
眼尖的朋友會發現，我們目前 Provider-Consumer 之間的拓樸關係圖，其實就是 Hub-Spoke 的形狀。
把 provider 類型的基礎服務放在 Hub-VNet 上是常見的做法，雖然避不了 peering 的過程，但是這樣的設計仍然能夠使網路連接的拓樸線是有規則的存在著。
那有沒有什麼方式，可以讓我們在沒有 Hub-Spoke peering 的網狀規劃下，仍然可以實現 provider-consumer 互相通連的機制呢？
有的，本文的主角 Private Link 就是幫我們達成目的的得意助手！
使用 Private Link
在下圖中，主要展示了使用 Private Link 後的網路拓樸。
你可以發現在 provider-vnet 及 consumer-vnet 中彼此是沒有 peering 存在的。
那這樣 consumer 要如何連接到 provider 呢？答案是透過 Private Endpoint。
我們可以在 consumer 所在的 vnet 中埋一個 Private Endpoint，並指定 Private Endpint 的連接對象為 Private Link。
一個 Private Link 可以同時綁定多個 VNet 的 Private Endpoint，至多可以到 1000 個（請參考 private link limit）。
在 Private Link 的先天條件上，必須要綁一個 SLB（Standard Load Balancer）的 Frontend IP 給它專用。
而請求打進來之後，透過 SLB 的 規則匹配，就可以抵達位於 位於 Backend Pool 中的 Provider 服務。
在這個過程中，Private Link 中的 NAT 會負責進行 IP 位址轉譯的動作。
預設在建立 Private Link 時僅會產生一組 NAT IP 設定，但在流量較大的情況下可能會達到瓶頸。
可幸的是 NAT 數量是可以擴增的，一個 Private Link 最多可以擁有 8 個 NAT IP。
透過這樣的設計，我們就可以讓 Provider 與 Consumer 之間的網路拓樸更為單純一些。
小結
礙於篇（ㄞˋ）幅（ㄎㄨㄣˋ）關係，這邊我將文章拆分為概論及實作兩個部分。
本文主要簡述整個網路架構由簡入繁的過程，而實際上 Private Link 的主要功能及目的其實不僅此於這些，關於實作的部分，會在下文中繼續介紹。
題外話，這篇文章畫圖的時間好像比打字的時間還要多，也是挺有趣的體驗。
以上內容如有勘誤，再請不吝告知。
