随着我们深圳尼高网站设计公司不断的发展，到现在已经有15个年头了，一路走来我们成长了很多也遇到了无数的困难，今天我想花点时间来总结一下我们在
网站开发时经常犯过的错误。
1、不要将应用程序从数据中心迁移到云，我们也经常会用到云产品，但为物理数据中心设计的应用程序很少能无缝迁移到云中。我们现在已经参与了三项尝试，将为特定数据中心编写的应用程序大规模迁移到云，每次我都遇到了关于环境的未记录假设的问题。
在开发人员编写和测试应用程序时，他们对环境的运行方式产生了期望。服务器如何工作，我的应用程序获得什么样的性能，网络有多可靠，我可以预期什么样的延迟等等。这些是任何人在环境中工作多年都会做的合理的事情，但它意味着当你打包一个应用程序并在其他地方运行它时，特别是旧应用程序，奇怪的事情发生了。您之前从未遇到过的错误开始出现，需要做出各种奇怪的架构决策来尝试并允许这种转换。
很快，您已经消除了迁移的许多价值，甚至可能会做一些糟糕的事情，例如通过直接连接将数据中心连接到 AWS，以尝试无缝桥接这两个环境。您的复杂决策列表开始增加和增长，越来越多地影响到您的云提供商的边缘案例。不可避免地，您会发现一些无法移动的东西，并且您现在陷入了两个环境中，一个需要维护的数据中心和一个新的云帐户。你为你的傲慢感到惋惜。
将应用程序移植到云端。为开发人员提供一个与数据中心环境完全隔离的环境，让他们将应用程序移植到云端，然后为您的应用程序安排 4-8 小时的停机时间。这将允许持久层进行切换，然后您可以更改您的 DNS 条目以指向您的新云存在。试图防止这种停机时间会使您陷入一个又一个错误决定的错误决定中。
2、不要编写自己的秘密系统，出于某种原因，组织喜欢编写自己的机密管理系统。通常这些是由基础设施团队编写的应用程序，通常是环境变量注入系统或某种基于 RSA 密钥的解密 API 调用。甚至我们也成为这个想法的受害者，认为“当然它不会那么困难”。出于某种原因，我们要在我将管理的 PostgREST 应用程序中管理我们的秘密。我们编写了一个应用程序，它会根据各种标准生成 JWT 并将其返回给应用程序。这些将允许他们以完全安全的方式访问他们的秘密。
现在为 PostgREST 辩护，它很好地完成了它所承诺的事情。但是，机密管理的问题比最初出现的要复杂。首先我们遇到了缓存的问题，你如何避免每小时访问这个服务一百万次，但仍然保持一些使用服务器作为事实来源的概念。这可以通过一些 Nginx 配置解决，但这是我应该想到的。
然后我用旋转的耙子打自己的脸。推送新版本是微不足道的，但机密通常不会版本化给客户端。我使用我的应用程序进行身份验证，我看到了正确的秘密。但是在轮换期间有两个正确的秘密，我说的时候很明显，但在我写的时候没有想到。同样，这不是一件很难修复的事情，但是随着时间的推移，我遇到了越来越多的服务边缘情况，我意识到我犯了一个巨大的错误。
现实情况是，机密管理是一种典型的高风险低回报服务。它不会直接帮助我的客户，也不会真正打动我运行它的领导层，它会消耗我大量的时间来调试它，并且在运行它方面需要很多特定领域的知识。我不得不重新考虑很多部分，从多区域可用性（例如，跨区域同步是一种拖累）到强化服务。
