这是一个客座博文，谁是开发经理在及时。你可以在他的GitHub和他的网站上查看Ben的其他工人项目博客。在我们及时启动了一个项目，将我们的web应用程序从遗留的Azure服务迁移到现代PaaS产品中。理论上说，这意味着没有代码改变。我们决定从我们的webhook开始。我们所有的端点可以分为四个c类别：集成内部工具，如HelpScout，PagerDutyPayment confirmations的监控端点calendar integrations，即Google CalendarSMS confirmations尽管数量有限，但这些都是至关重要的。我们做了很多测试，但很明显，只有当我们有了生产流量后，我们才真正知道一切是否正常。我们如何迁移流量？选项1更改CNAME以指向新的托管基础结构。这是高风险的。DNS传播需要时间，因此，如果需要回滚，则需要时间。我们也会在一次。选项2使用流量管理器使用Cloudflare负载平衡来转移流量百分比。我们可以从新基础设施的5%流量开始，假设一切正常，慢慢增加交通。进来在我们的案例中，绝大多数流量都流向了日历集成端点。其他端点不太可能接收到流量，尤其是在流量只有5%的情况下。这不是最好的选项。输入选项3:Cloudflare Workers和Workers KVI记得在想：如果我们可以一次将流量迁移到一个端点，这不是很好吗？我们有大约20个。我们可以从低风险的终点开始，逐步前进起来，我们能够编写Cloudflare Worker脚本那：检测到路径，即/webhooks/paypali如果路径与我们的一个端点匹配，我们检查Workers KV（键值存储）以查看是否启用了该端点。这是我们的特性标志/设置，如果它被启用并且路径匹配，我们将重定向到新的基础设施。这涉及到更改域，但以其他方式保持请求不变，即。webhooks.currentdomain.com/webhooks/paypal到webhooks.newinfrastructure.com/webhooks/paypalat第一步是添加本文中提到的passThroughOnExceptionpost.addEventListener（'fetch'，event=>{event.passThroughOnException事件()事件响应（处理请求（事件））})接下来，在handleRequest方法中，我为每个端点（路径）和相应的Workers KV键创建了一个映射，因此我知道在哪里查找设置常数端点=新映射（）端点.set（'/monitoring'，'monitoring'）端点.set（'/paypal'，'payplipnwebhook'）//更多终结点端点.set（'/helpscout，'helpscouthebhook'）接下来我检查每个请求的路径。如果路径匹配，则检查设置。如果是这样，我们设置一个重定向标志。for（var[key，value]的端点.entries()) {如果(当前URL.pathname.StartWith（钥匙）{const flag=等待WEBHOOK_设置.get（值）如果（标志==1）{控制台.log（`redirected:${key}`）重定向=真打破}}}如果redirect标志为true，我们将更改请求中的主机名，但保留其他所有内容。这涉及到创建一个新的请求对象。如果不重定向，则获取请求。//处理请求让响应=空如果（重定向）{//重定向到新的infraconst newUrl=请求.url.replace（当前主机，新主机）常量初始化={方法：请求.方法,标题：请求.headers,正文：请求.正文}控制台.log（新网址）const redirectedRequest=新请求（newUrl，init）控制台.log（重定向请求）响应=等待获取（redirectedRequest）}其他{//处理现有基础设施响应=等待获取（请求）}完成CodeaddEventListener（'fetch'，event=>{event.passThroughOnException事件()事件响应（处理请求（事件））})功能日志（数据）{回迁（"http://logs-01.loggly.com/inputs//tag/http/"{方法："POST"，正文：数据})}异步函数handleRequest（事件）{试试看{常量请求=事件请求const currentHost='webhooks.currentdomain.com网站'const newHost='webhooks.newinfrastructure.com网站'const currentUrl=新URL(请求.url)让重定向=false//这是路径图和相应的KV条目const endpoints=new Map（）端点.set（'/monitoring'，'monitoring'）端点.set（'/paypal'，'payplipnwebhook'）//更多终结点端点.set（'/helpscout'，'helpscouthebhook'）for（var[key，value]的端点.entries()) {如果(当前URL.pathname.StartWith（钥匙）{const flag=等待WEBHOOK_设置.get（值）如果（标志==1）{控制台.log（`redirected:${key}`）重定向=真打破}}}//处理请求让响应=空如果（重定向）{//重定向到新的infraconst newUrl=请求.url.replace（当前主机，新主机）常量初始化={方法：请求.方法,标题：请求.headers,正文：请求.正文}控制台.log（新网址）const redirectedRequest=新请求（newUrl，init）控制台.log（重定向请求）响应=等待获取（redirectedRequest）}其他{//处理现有基础设施响应=等待获取（请求）}返回响应}捕获（错误）{事件.等待直到（日志（错误））抛出错误}}为什么使用工人KV？我们可以把所有的东西都写成一个硬编码的脚本，每次都会更新它来启用/禁用流量的重定向。这将要求团队在每次我们希望改变。使用Workers KV，我让团队的任何成员都可以使用Cloudflare API启用/禁用端点。为了让事情更简单，我创建了一个邮递员收集和共享去吧。去吧活生生的问题和解决方案！我们开始使用我们的第一个端点。Workers脚本和KV运行良好，但我注意到在Workers>Worker中报告了少量异常状态。Cloudflare提供调试提示。我遵循了"向调试服务器发出子请求"一节，并决定合并logly。我现在可以捕捉异常并将其发送到logly，方法是使用fetch对Loggly提供的URL运行POST。通过这个，我很快确定了问题所在，并纠正了问题。另一个出现的问题是403的过多。这在Workers>Status Code graph（绿色）中非常明显。原来我们的IIS设备有速率限制设置。它没有返回429（请求太多），而是返回了403（禁止）。呜-这不是我的工人或新的基础设施的问题！我们本可以在新的基础设施上设置速率限制，但是我们选择了Cloudflare速率限制。它便宜，易于设置，意味着被阻止的请求一开始甚至不会影响我们的基础设施地点。哪里从这里开始？在我写这篇文章的时候，我们已经转移了所有的交通。所有终结点都已启用。一旦我们准备好让旧的基础设施退役威尔：换一下CNAME指向新的基础结构禁用workerCelebrate！然后我们将转到新的web应用程序，例如API或主web应用程序。我们可能会用两种方法中的一种选项：使用traffic manager根据每个客户迁移一定百分比的流量。它与上面类似，只是我们将为每个客户存储一个设置（KV将为每个客户存储一个设置，并且我们通过请求标头了解客户，该标头将具有客户ID）。例如，我们可以从内部测试帐户开始，然后是beta用户，最后迁移贵宾。升级使用Cloudflare Workers和Workers KV使云基础设施更轻松、更安全