終於迎來了整個鐵人賽的賽末時程，前兩篇的部分我們已經大致把iNODE NINJA使用的情境 (線路分組與規劃) 與實作過程整個說明了一遍。
今天我們要來分享一個更重要的部分，那就是在考慮各個方面下，要怎麼規劃SLB與EDGE之間的對外連線線路情況。

規劃CDN節點

在規劃CDN節點時，需要考慮的重點是:

• 「加速線路」
• 「回源線路」
  考慮到訪問的「加速線路」，就是目標市場訪問時品質最好、延遲最低、最穩定的線路，以及回源伺服器的「回源線路」這兩條，這兩條線路可以說是CDN的命脈，因此在部署節點時，一定要確保對外線路與回源線路的情況，並透過維運團隊實時監測與調整。

SLB/EDGE與Control伺服器

另外我們也與原廠的技術確認了不少iNODE NINJA的相關技術細節，其中有一個需要注意的地方就是SLB/EDGE與Control伺服器之間的連接，這條線路將會連線到iNODE NINJA那邊的主控伺服器，如果這裡的連線中斷，CDN平台就會認定該節點不健康，並且將其解析給拉下線，造成無法訪問的情況，因此除了上述「訪問」與「回源」這兩條線路以外，還有「Control的連線狀態」也是一個相當重要的地方。

架構方案

所以針對這部分，我們需要衡量線路與成本，考慮到幾種可行的架構方案。

架構1

將客戶訪問、回源與和Control Server聯繫的封包都通過同一個Gateway進出、其中回源與Control Server聯繫的線路採用相同的路徑聯繫，這樣的架構需要做好相關路由的規劃，但優點是只需要一個Gateway作為封包進出的關卡。

架構2

客戶透過專屬的加速線路進來我們CDN的SLB訪問，SLB、EDGE透過區域網路溝通，EDGE走第二條線路進行回源到源站伺服器，同時SLB、EDGE走第二條回源用的線路來與Control Server聯繫，這樣在路由方面只要將Control Server的部分設定靜態路由即可，設定上會比較簡單，流量的出入也會比較容易懂，但缺點就是需要兩個Gateway。

架構3

客戶來訪問我們的CDN透過第一個Gateway，EDGE回到源站則是走第二個Gateway，SLB和EDGE之間一樣走區網來進行溝通，而SLB與EDGE與Control互動的流量走第三個專屬的Gateway線路，這樣可以確保客戶訪問、回源、與Control互動都是完全分開、走不同的線路的，因此其中一個線路故障都不會影響其他兩者，但這樣的成本也是最高的，因為要準備三組Gateway與三條線路。

三種架構優缺點分析：

以上三種架構在考量到成本、設備、線路等方面，其實都各有優缺點:

1. 第一種架構

只需要一個Gateway與兩條不同的對外線路，分別用做客戶進來訪問與回源/連線Control之用，同時如果外面訪問的流量被塞爆也有可能影響到與Control的互動。

2.第二種架構

將訪問與回源分開不同的Gateway與線路，並且訪問進來的線路被塞爆也不會影響到與Control的連線，確保解析不會因為外來流量塞爆而導致解析被拉掉的問題，但會需要兩組Gateway導致成本的上升。

3.第三種架構

彈性最大，專門為了Control而開設一條線路，同時進來訪問SLB與EDGE回源的線路也是分開的，不管是訪問還是回源的流量過大，都不會影響到與Control的連線，但這樣的成本自然也是最高的，要準備三組Gateway與三條線路。

結論

以上列出了三種實際上比較常見的架構，實際上要採用哪種架構，當然也是得看實際的情況 (例如流量、開設機器的地點、硬體與基礎設施、線路資源、成本等等)，來選擇使用哪一種架構。
因為受限於目前我們的硬體設施，因此架構的部分暫時只能紙上談兵，沒辦法鉅細靡遺的將所有的架構都一一的測試完畢，但透過這樣的規劃，當在未來客戶量與訪問量都暴增時，就能夠透過這些架構的know-how來創造一個強而有力的CDN服務平台。
下一篇我們會把從第1天一直到最後成功建立了CDN平台，把整個iNODE NINJA的功能給摸過一遍，以及到最後的實現線路分組、架構討論這些歷程來回顧一下，做成心得結論分享。