當（技術服務）關係不奏效時

回想起你遇見生命中的摯愛的那些日子。那種感覺是雙方的。世界看起來更美好，你和你的另一半一起走在令人興奮的旅程上。你們都全心投入，計劃共同的生活。

生活是如此美妙……直到不再美妙。

當事情未如預期發展時，你就必須進行艱難的關係解開工作。與彼此和其他人溝通。整理共享的購買。繼續前行。唉。

信不信由你，我們與科技的關係並沒有太大不同。

與服務分手

曾經有個時候你決定採用一項服務——也許是SaaS，或PaaS，或其他更通用的東西。在那個時候，你是否在做決定的同時也考慮過未來不再使用該服務的時刻？大概沒有。你只是想到未來的所有美好可能性。

但當選擇該服務不再符合你的最佳利益時會怎樣？現在，你面臨一個挑戰，這被稱為服務放棄。雖然服務可以在合理的努力下關閉，但獲取底層數據可能會出現問題。這通常取決於服務的類型和該服務提供者擁有的數據量。

有時，理想的解開看起來是這樣的：停止為服務付費，但在一段時間內保留對數據源的訪問。這可能嗎？是的，可能！

VPC對等連接的力量

主要雲端服務提供商已經接受了 虛擬私人雲 (VPC) 網路，作為建立資源之間連接的事實標準。例如，AWS 上的 EC2 實例可以使用 VPC 和 VPC 端點服務來訪問數據源。可以將其視為點對點連接。

VPC 允許我們授予對同一雲端提供商中其他資源的訪問權限，但我們也可以使用它們來 授予對外部服務的訪問權限。考慮一項最近被放棄的服務，但原始數據源仍然存在。這樣看起來可能是這樣的：

這個概念稱為 VPC 互連，它允許從另一個網路建立私有連接。

服務遷移示例

讓我們考慮一個更具體的例子。在你的組織中，做出了簡化在雲端運作方式的商業決策。在繼續利用一些 AWS 服務的同時，你的組織希望通過終止在 AWS 上運行的第三方雲端服務來優化其構建、部署和管理應用程序的方式。他們計算了一下，得出結論認為內部軟體工程師可以以他們之前支付給第三方提供商的一小部分成本，建立並支持一個新的自動擴展服務在 Heroku 上。

然而，由於與服務提供商的長期合作，遷移數據來源在近期內並不是一個選項。您不想使用該服務，並且無法移動數據，但仍希望訪問數據。幸運的是，該提供商已同意續簽新合約，繼續託管數據並通過 VPC 對等連接提供訪問。

以下是新安排的樣子：

與 Heroku 的 VPC 對等連接

為了讓您的新服務（Heroku 應用程式）能訪問 AWS 中的原始數據來源，您首先需要在私有空間內運行您的應用程式。欲了解更多信息，您可以閱讀 安全雲採用和我對 Heroku 私有空間的發現。

接下來，您需要滿足以下簡單的網絡要求：

• VPC 必須在其網絡配置中使用兼容的 IPv4 CIDR 區塊。
• VPC 必須使用 RFC1918 CIDR 區塊（10.0.0.0/8、172.16.0.0/12 或 192.168.0.0/16）。
• VPC 的 CIDR 區塊不得與您的私有空間的 CIDR 範圍重疊。默認範圍為 10.0.0.0/16、10.1.0.0/16 和 172.17.0.0/16。

在您的私有空間運行後，您需要檢索其對等連接信息：

$ heroku spaces:peering:info our-new-app

=== our-new-app Peering Info

AWS Account ID:    647xxxxxx317

AWS Region:        us-east-1

AWS VPC ID:        vpc-e285ab73

AWS VPC CIDR:      10.0.0.0/16

Space CIDRs:       10.0.128.0/20, 10.0.144.0/20, 10.0.0.0/20, 10.0.16.0/20

Unavailable CIDRs: 10.1.0.0/16

抄下 AWS 帳戶 ID (647xxxxxx317) 和 AWS VPC ID (vpc-e285ab73)。您需要將這些資訊提供給控制 AWS 數據來源的第三方供應商。接下來，他們可以使用 AWS 控制台或 CLI 來 創建對等連接。他們的操作看起來像這樣：

$ aws ec2 create-vpc-peering-connection \ 

  --vpc-id vpc-e527bb17 \

  --peer-vpc-id vpc-e285ab73 \

  --peer-owner-id 647xxxxxx317

{

    "VpcPeeringConnection": {

        "Status": {

            "Message": "Initiating Request to 647xxxxxx317",

            "Code": "initiating-request"

        },

        "Tags": [],

        "RequesterVpcInfo": {

            "OwnerId": "714xxxxxx214",

            "VpcId": "vpc-e527bb17",

            "CidrBlock": "10.100.0.0/16"

        },

        "VpcPeeringConnectionId": "pcx-123abc456",

        "ExpirationTime": "2025-04-23T22:05:27.000Z",

        "AccepterVpcInfo": {

            "OwnerId": "647xxxxxx317",

            "VpcId": "vpc-e285ab73"

        }

    }

}

這會創建一個對等請求。一旦供應商完成這一步，您可以在 Heroku 端查看待處理的請求：

$ heroku spaces:peerings our-new-app

在下面的截圖中，我們可以看到對等連接的待接受狀態。

從這裡，您可以接受對等連接請求：

$ heroku spaces:peerings:accept pcx-123abc456 --space our-new-app

Accepting and configuring peering connection pcx-123abc456

我們再次檢查請求狀態：

$ heroku spaces:peerings our-new-app

我們看到對等連接已經啟用。

此時，我們在 Heroku 私有空間中運行的應用將能夠無障礙地訪問 AWS 數據來源。

結論

生活中一個不幸的真相是，關係的失敗與持久一樣常見。這適用於人，也適用於技術。

在技術決策方面，有時變化的情況和需求驅使我們朝著不同的方向前進。有時，事情就是不奏效。而在這些情況下，最大的挑戰往往是解開現有實施——而不失去對持久數據的訪問權。

幸運的是，Heroku 提供了一個解決方案，可以逐步從現有的雲端解決方案中遷移，同時保留對外部託管數據的訪問。它對 與 AWS 的 VPC 對等互連 的輕鬆集成使您能夠訪問仍然需要存在於舊有實現中的資源，即使其他部分已經轉移。

採用這種方法將使您的新服務在不中斷消費者服務的情況下蓬勃發展。