回想一下你和生命中的挚爱相遇的那些日子。那种感觉是彼此的。世界似乎变得更美好,你和你的另一半正踏上激动人心的旅程。你们都全心投入,规划着共同的生活。
生活是如此美好……直到不再美好。
当事情不如预期发展时,你就得去做分手的艰难工作。与彼此及他人沟通。理清共同的开支。继续前行。唉。
信不信由你,我们与科技的关系并没有太大不同。
与服务的分手
曾几何时,你决定采纳某项服务——也许是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 对等连接 的轻松集成使您能够访问仍需保留在传统实现中的资源,即使其余部分已经迁移。
采取这种方法将允许您的新服务在不影响消费者服务的情况下蓬勃发展。
Source:
https://dzone.com/articles/when-tech-service-relationships-dont-work-out