将 Zapier 或 Make 自动化流程迁移到新的地理编码主机
基于地理编码步骤构建的无代码自动化流程，需要与自定义代码不同的迁移方法。下面介绍如何完成这种切换。
依赖单一小型服务商让我们认识到的供应商风险
单一的 API 依赖很容易被忽视，正是因为它会在很长时间里默默正常工作。一个两年来每天都返回正确结果的地理编码调用，感觉并不像一种风险，而像一个已经解决的问题。只有在服务商那边发生变化的那一天，风险才会显现出来：某个端点停用、定价调整、公司被收购，或者仅仅是一次服务中断。而到那时，没有备选方案的代价已经在手忙脚乱中付出，而不是通过有计划的迁移来承担。
小型服务商比大型服务商承担着更严重的这种风险，不是因为它们在日常运行中不够可靠，而是因为它们自身的运营通常冗余较少，商业模式也对任何单个大客户的流失或任何融资变化更加敏感。这不是对任何特定小型服务商的批评，而是一个关于公司规模的结构性事实，适用于许多在其他方面非常出色的服务。
实际的教训并不一定是要避开小型服务商。而是要构建一种不假定任何一家服务商会永久存在的架构，无论其规模大小。几个具体的习惯会有所帮助：
- 在您自己的代码中，把服务商特有的逻辑放在一个内部接口之后，让解析函数从您自己规范化的数据结构中读取数据，而不是直接读取散落在整个代码库中的某家服务商的字段名
- 定期测试您的集成是否真的能够迁移，即使您近期并没有迁移计划，因为未经测试的可移植性假设并不等于真正的可移植性
- 把完整迁移所需的工程时间成本作为一项长期保存的组织知识来跟踪，而不是在危机中才第一次去计算
基于兼容的方法会在一定程度上改变这笔账，因为它减少了迁移成本中落在您自己解析代码上的部分。My Geocode 运行着 17 个兼容主机，完全复现了 Google Maps Platform、Mapbox、HERE、ipstack 等主要服务商的请求和响应结构，文档见 /compatibility/。这意味着，如果您要离开的服务商恰好已经有匹配的兼容主机，那么被迫迁移中风险最高的部分，也就是在时间压力下重写解析逻辑，往往是可以避免的。
话虽如此，关于供应商风险的更深层教训，无论您使用哪家服务商或平台（包括我们）都同样适用：最健康的状态是，切换是一个真实的、经过测试的选项，而不是一个理论上的选项。在需要之前先针对另一家服务商进行一次小规模试用，哪怕只用您一小部分流量，也能把供应商风险从一种抽象的担忧转化为一种具体的、经过演练的能力。测试的成本相对较低，而回报只会在您真正需要它的那一天显现。