作者 | 李冬梅、核子可乐
多年来，AWS 凭借其迅速实施、便捷伸缩、跨地域服务、弹性伸缩、运行可靠等多项优势广受认可，依据 Group 公布的 2022 年第二季度数据，全球云服务产业在本季实现营收 547 亿美元，过去一年累计收入达 2050 亿美元。在众多云服务提供商中，亚马逊云凭借近 34%的市场份额位居首位，这一比例超过了后两名市场占有量之和。
但优势突出的AWS并非所有公司都适用，对于很多员工总数甚至不到十人的小型初创企业而言，AWS的开销远超他们的预算，因此这些公司只能另寻他法，挑选一些成本更低的替代品。
Fly.io 在开发者体验方面远胜于 AWS，其入门门槛十分平缓。不过，Fly.io 内部仍存在一些尚未完善之处。倘若用户能够自主维护基础设备，并且可以容忍技术支持不够顶尖的情况，那么 Fly.io 值得考虑。
整体而言，大型云服务提供商的方案往往更繁复炫目，而 Fly.io 的服务则显得更为简洁实用。
公司简介
它是一套持续集成和持续部署系统，该企业由具备深厚软件工程背景的专业人士建立，对于他们而言，维持简便且高效至关重要。
和其他新创企业相似，在创业初期，所有人都渴望迅速推进，探明商业前景如何。亚马逊云服务显然是首选，能够助企业在短期内确立自身地位。只需少量免费额度，整整一年都不必顾虑基础设备问题，这简直无与伦比。
但是日子飞逝，无偿的积分很快消耗殆尽。团队检视了 AWS 的费用清单，察觉到这种支出对于仅凭自身力量发展的初创企业而言过于沉重。因此他们着手四处探寻更经济实惠的替代方案，而且必须确保这些方案不会干扰系统的稳定性、安全性以及可伸缩性。
为什么要“逃离”AWS？
成本是促使迁移的主要原因。AWS服务费用并不低廉，团队成员透露，他们觉得许多服务对他们当前工作无实际帮助，或许将来可能会有需求，但现阶段没有必要使用。
构思上，应当选用一个规模不大的基础架构组合，其构成要素明确为：
实验迅速完成，验证概念取得进展，于是开始关注 Fly.io，并着手构建一个展示平台，以便完善各项要素。
准备工作
搭建登台环境期间，需要将 AWS 基础设施中的每个组成部分逐一对应，并与 Fly.io 组件进行关联。
Fly.io 提供了功能完备的命令行工具，用户能够针对每个项目设定专属的 fly.toml 设置文件。借助这个文件，工作小组可以便捷地构建项目并顺利完成基础设置。整体感受相当令人满意。
来看看 的登台 fly.toml:
app = "terrateam-app-staging"
kill_signal = "SIGINT"
kill_timeout = 60
[env]
数据库主机地址为terrateam-db-staging.internal，这是一个内部使用的地址，用于连接到测试环境的数据库服务器，该地址专门用于部署阶段的测试工作，确保系统在上线前能够正常运行，并且所有的数据交互都通过这个地址进行，以保证数据的安全性和稳定性，同时这个地址也是开发团队在开发过程中调试和测试的重要环节，通过这个地址可以方便地访问到测试数据库，进行各种功能的验证和测试，确保系统的可靠性和性能满足要求，在正式上线后，这个地址将不再使用，而是切换到正式的生产环境地址，以提供稳定可靠的服务。
数据库的名称是terrateam, 数据库的端口号是5432,
DB_USER = "app"
TERRAT_PORT = "8180"
TERRAT_PYTHON_EXEC指向的是"/usr/bin/python3"这个可执行文件
[[services]]
internal_port = 8080
protocol = "tcp"
[services.concurrency]
hard_limit = 25
soft_limit = 20
type = "connections"
[[services.http_checks]]
grace_period = "10s"
interval = "10s"
method = "get"
path = "/health"
protocol = "http"
restart_limit = 0
timeout = "3s"
tls_skip_verify = false
服务中的网络检测项目，针对头部信息进行验证，确保符合规范要求，同时检查内容是否完整，确认数据传输的准确性，保障系统稳定运行，维护网络安全环境，提升用户体验质量。
[[services.ports]]
force_https = true
handlers = ["http"]
port = 80
[[services.ports]]
handlers = ["tls", "http"]
port = 443
[deploy]
strategy = "rolling"
测试
开始打造表演场所时，技术组迅速碰到了一些困难，不过这些麻烦都有容易的解决手段。
IPv6
Fly.io 应用端点会解析为 IPv6 地址。
josh@elmer:~ $ 使用飞连接 ssh, 目标地址为 fdaa:0:c037:a7b:c6ef:47dd:247:2... , 指定应用 -app- , 再次指定应用 -app- , 接着执行 dig 命令, 查询数据库 -db- , 查询地址 A , 查询数据库 -db- , 查询 AAAA 记录 , 最后指定地址 +:0:c037:a7b:c207:e395:9a80:2/ .
然而该软件无法兼容 IPv6，这是开发团队原先的疏漏，不过自从应用了 Happy 算法，相关问题立刻得到了处理。
与 SSL
数据库连接存在问题。尽管工作人员借助系统可以分析并到达数据存储位置，却一直无法建立联系。负责维护的技术人员所用的数据存储设施必须通过 SSL 协议来构建安全通道。虽然可以无视这一规定，不过采用 SSL 设置明显更为稳妥。
查找 Fly.io 的相关资料，好像没有发现通过 fly.toml 文件来设置 SSL 的快捷途径。深入探究后，相关人员了解到 Fly.io 与 AWS RDS 存在差异。官方资料中清楚说明，并非托管服务。
Fly.io 命令行工具在新建数据库方面给予特殊协助，不过仅限于初始建立过程。后续的维护工作、性能提升、版本迭代、应急处理以及参数设置等，都需要使用者自行完成。这并非表达不满，毕竟 Fly.io 的立场相当直白，会清楚说明其服务范围及限制条件。
配置 SSL 需要先生成证书，然后要在配置文件里设置好参数。这样，原先的难题就成功化解了。
正式迁移
处理完登录环节的难题，接下来要着手建立 Fly.io 的正式应用，并且马上开始转换工作。
团队讨论了两种迁移方法：
实时迁移
凭借个人体会，每次提及更换部署环境时，众人首先探讨的是如何让所有服务暂停来实现迁移的挑战性。团队随后制定了一个包含大量 Nginx 设置的方案，不过最终决定放弃这个计划。
和实时迁移所付出的精力及难度相比，团队认为不如采用短暂中断服务的快速迁移方式，因为某些操作确实越是简便、越直接越好，而且还能补发传输中遗漏的数据，这更加坚定了技术团队选择用短暂停机换取简单迁移的决策。
快速迁移
快速迁移就很直观了：
降低 app..io 的 DNS 存活时间,中断 AWS ALB 的进站访问,将 AWS RDS 数据库转移至新 Fly.io 数据库,调整 app..io 以对接新的 Fly.io 应用接口,重发缺失的请求——尽管后续确认并无遗漏,此举具备显著益处
使用 Fly.io 进行部署后，技术团队感受到了诸多便利之处，这些便利均源自 Fly.io 组织的特性。实践证明，Fly.io 对常规工程团队的基础设施搭建需求有着深刻认知。
可观察性
Fly.io 提供了完善的监控功能作为免费服务。当建立新项目时，平台会自动配置一个控制面板，里面内置了多种标准化的数据图形。用户还可以方便地基于已有的图形界面，设计全新的数据展示方式，显著提升了系统运行状态的查看便捷性。相比之下，AWS 的同类功能就显得较为繁琐。
再者，倘若把软件设定为对外可用模式，相关数据便会自行呈现在控制面板上。
远程访问
与 AWS 对比，Fly.io 又展现了一项突出优势。远程访问正在运行的容器是常见需求，特别是在初次建立基础设施或处理持续性问题期间。通常情况下，仅需要执行一个简单的 shell 命令。
Fly.io CLI 提供一种非常简单的访问权限获取方式：
josh登录elmer系统主目录后,通过fly工具使用ssh协议,连接到指定设备fdaa:0:c037:a7b:c6ef:47dd:247:2...,并执行应用操作,同时指定应用名称为-app-,目标地址为该设备路径/
这种方式非常好，现在终于可以摆脱虚拟专用网络、SSH 密钥、堡垒主机的烦恼，fly ssh 命令才是真正的方便！
IPv6 专用网络
每个 Fly.io 用户都会得到一个配备 IPv6 终端的自动化安全专用线路。对于类似这种基础应用，这非常便捷。无需自行搭建独立的专用线路，也无需担忧 CIDR、子网、路由及网络配置等复杂问题。运行状态良好，配置完全合适。
多区域可扩展性
Fly.io 的跨地域扩展能力十分出色。只需在 fly.toml 文件中设定多个地点，该软件便能自动部署到多个地点。这些地点可以根据需求随时调整，且无需中断服务。相比之下，其他云服务提供商要做到这一点，难度要大得多。
简洁的 UI
Fly.io的管理界面十分干净利落，布局井然有序，操作便捷。它不同于其他云服务提供商那样界面繁杂。技术部门的人员总能迅速定位所需功能，这个优点务必维持下去。
短板 提供程序
免费软件同样存在局限性。技术团队最初打算运用 来生成所有内容，但很快发现这完全不可行。Fly.io 的支持能力不足，无法构建完整的环境。尽管结果令人沮丧，技术团队仍然选择继续努力。这一点对 来说尤其关键，毕竟 是一家高度重视用户体验的企业。技术团队已经制定了相关安排，接下来将逐步参与 Fly.io 程序的开发工作。
的可用性问题
Fly.io 通过集群管理器来完成 故障切换。技术团队指出：切换的稳定性欠佳。这确实是个缺陷，毕竟它就是设计用来处理这个情况的。
技术团队一成员透露，他们曾经遭遇过一次意外，不得不手动建立新数据库，同时从存档中复原数据。Fly.io已经接到反映，正积极寻求更优越的方案来替代当前措施。
日志记录
Fly.io 提供的容器日志系统相对比较基础。尽管借助 Fly.io 命令行工具或管理界面可以方便地查阅记录，不过所展示的信息非常有限。因此，技术人员不得不在程序内部处理日志，或者将其传输到其他平台，从而为每个 Fly.io 应用单独构建远程记录机制。这种方式会产生额外的管理成本，期待未来能够得到优化。
技术支撑
Fly.io 并非以细致周到的服务著称，倘若用户有即时获得技术协助的迫切需求，那么这家公司或许难以满足。
使用电子邮途径递交求助请求时（当前仅设此沟通渠道），常常需要等待数小时乃至数日方能收到应答。偶有情形下，Fly.io 方面完全未予理会，让人感觉其服务响应能力逊于其他云平台提供商。
然而 Fly.io 核心在于让用户自行管理基础设置，他们仅负责供应基础组件。优质的服务当然令人满意，不过他们坚持认为环境维护终究是用户的责任。
团队透露，对于 Fly.io 抱有相当大的期盼，盼望将来能获得更佳的服务感受。即便无法从相关人员处直接探知确切回应，也应当至少获取些许方向。
写在最后
任何平台都不可能完全没有缺陷，据观察，Fly.io似乎已经做到了极致，团队使用后几乎没有提出异议，尤其因为他们清楚说明了自己的产品具体功能以及局限之处。
它的架构相当精简，这或许解释了为何 Fly.io 能如此精准地满足特定场景的要求。它不依赖繁复的组件或庞大的支撑体系，其关键构成仅包含数据存储单元和封装应用环境。
但各位读者朋友的需求或许并非这样，倘若大家需要消息中间件、S3 存储桶、IAM 等更为周全的服务单元，那么 Fly.io 或许并非理想之选。
参考链接：