Codename One如何从App Engine迁移到Spring Boot

在周末，我们将大量代码迁移到了新的构建服务器上。在这篇文章中，我将尝试介绍三件事。我将解释迁移的体系结构/历史和过程。有效的方法，无效的方法和经验教训。最后，这将如何影响Codename One用户的前进。

我希望这对非Codename One用户的公众来说是一个有趣的故事，因为它是摆脱App Engine（和类似的PaaS）的成功案例，尤其是在我们经历了可怕的 App Engine 体验之后。

我将从一些历史开始，以解释背景和动机。我们于2012年1月成立了Codename One。那时，我和Chen曾在加速器中以完整启动模式工作。 Chen之前从未在初创公司工作过，他对工作的速度感到惊讶，他打趣说，我们在三个月内所做的工作比在Sun Microsystems五年内做的更多！

构建云是在此期间构建的，但在过去6年中进行了改进，以适应我们不断增长的需求。我们错误地选择了构建云的App Engine，因为我们希望缩短上市时间，同时又要保持实施的可扩展性。

Google为初创企业提供免费托管额度的事实也是一个很大的诱因。

构建云是作为整体构建的，这不是一件坏事。实际上，马丁·福勒（Martin Fowler）特别建议人们首先从整体架构开始。云服务器实际上并不进行构建，因为我们需要专用的独立服务器（例如Mac，Windows计算机等）。

它本质上精心策划了所有不同的作品，因此它们将一起工作。过去，它处理的内容更多，但是随着时间的流逝，我们一步一步地切开了一部分，以进入微服务架构，例如：

推
防撞保护
生成文件提交
构建服务器Web UI

和更多。我们尝试删除所有内容，因为应用引擎太差劲了，但云服务器中仍然有很多东西：

用户授权/注册/**
构建业务流程-提交，状态，服务器分配等
帐单-我们不存储帐单信息，但PayPal在付款时通知了旧服务器
一些交易邮件基础架构

前两个是很大的部分，其中包含许多代码。他们还与其他一切紧密相连。

当我们开始使用App Engine时，我们相信Google声称它支持JPA。为了使我们的代码具有可移植性，我们使用了JPA，因此我们可以进行迁移。

我们发现App Engine上的JPA支持是一个可笑的笑话。基本功能无法正常工作且痛苦地失败，具有讽刺意味的是，这些失败仅在业务扩展时才会发生，因此，我们没有停机而导致平稳的性能下降。

随着我们的前进，我们重写了许多JPA代码以使用App Engine实体API和memcached 。幸运的是，我们保存了很多旧的JPA代码。

在过去的一年中，由于Google封锁了用于支持App Engine的旧插件，因此无法更新App Engine部署。

迁移到全新项目结构的方法的文献资料很少，并且似乎有很大的风险，因为事情可能会严重失败。所以我们别无选择。

它是如何工作的？

在开发课程和即将出版的书的过程中，我们与Spring Boot进行了大量合作。开发的速度和易用性完全不同。

考虑到这一点，我们决定进行实时迁移到Spring Boot服务器，该服务器可以替代App Engine。为了保持可扩展性，我们决定使用Cloudflare（就像在主要网站上所做的那样）。它使缩放非常容易。

因为过去我们已经从应用程序引擎中提取了构建UI，现在将其作为网站的一部分托管，所以我们为后端服务器提供了清晰的API。这样，我们可以更改进入应用引擎服务器的所有调用，只需将完全相同的调用指向新的云服务器。

云服务器决定是应该在本地处理呼叫还是要求App Engine为其执行呼叫。这样，我们为现有用户添加了一个新层，但是它应该是100％兼容的，并且不会失败。

我们之所以必须采用这种方法，是因为插件安装在最终用户计算机上，有些插件可能仍指向旧的App Engine。我们不希望所有构建突然中断。我们希望用户轻而易举地摆脱旧的App Engine部署。

通常，从头开始重写会更容易，但是因为我们希望尽可能减少中断，所以我们尝试将新的Spring Boot服务器设置为100％兼容，因此我们必须导入代码并尝试转换没有层级的servlet的旧混搭到适当的体系结构，以适当地分隔各层。

由于原始的有线协议比较混乱，因此看起来仍然有些混乱。但是现在这已经成为我们的工作了，我们将能够重新审视并改进很多遗漏的部分。

什么地方出了错？

许多事情以意想不到的方式失败了。

我们在生产中遇到的最大问题是Cloudflare。 Cloudflare阻止了DDoS攻击，它使用的技巧之一就是阻止所有不包含User-Agent标头的流量。

我们的许多代码都使用URL类，并且没有添加该标头。因此，基本的东西在开发环境中效果很好，但在生产中却失败了。

从数据存储区迁移到SQL时，我们迁移了许多旧的数字键。因此，新的基于String的键工作得相当不错，但是一些JavaScript客户端函数使用了语法，例如： doThis(id) 。

这似乎可行，但是当**是字符串时，只是默默地失败了。我们必须在这些方法上加上引号才能通过。由于平台中有许多细微的功能，我们只是错过了对此进行测试。

某些OTA和安装功能在生产中失败。这与我们完全错过的App Engine实现中相对隐藏/模糊的代码有关。

实际上，我们在旧的应用程序引擎中使用了JSP的几个功能。虽然Spring Boot支持JSP，但它具有一些部署限制，因此我们只是将该代码转换为标准的Web服务调用。

这不是一个理想的解决方案，但是由于要移植的代码很少，因此我们可以解决。

经过一些工作后，Spring Boot会因RAM错误而失败。原来，我们需要使用conf文件在Spring Boot中显式设置Xmx/Xms 标志。我们没有在以前的部署中碰到过它，因为我们没有做一些我们在这里做的繁重的IO。

什么有效

如此多的事情“奏效”！

到SQL的迁移通常很顺利，并且仅包括一些陷阱/模式更改。能够使用适当的SQL代替数据存储是向前迈出的一大步。它是如此之快，我们不需要Memcached并获得更好的启动性能！

真正令人惊奇的是查询和第三方工具。这大大提高了我们解决问题的能力。

尽管存在User-Agent问题，但Cloudflare是一项巨大的资产。它使重复查询的缓存变得微不足道。更好的是，由于我们现在通过服务器代理一些下载，因此借助Cloudflare，我们可以获得更快/更可靠的下载。

我不能对Spring Boot赞不绝口，这让它变得微不足道。它有痛点（无法读取的巨大堆栈痕迹），但是开发的便利性令人惊讶。我们现在通过IaaS管理我们自己的基础架构。与以前的PaaS部署相比，它更容易，更快，更便宜并且可扩展性更好。四个标准中的四个。

到目前为止，虽然我们尚未全面测试扩展能力，但CPU利用率还是持平/低。这种架构的扩展性可能比应用程序引擎好得多。

Google将App Engine作为“ Google Scale”解决方案出售，但是与之合作的任何人都将知道，只有在您可以花“ Google Sums”来支付费用的情况下，这才适用。

App Engine尝试通过添加计算资源来扩展规模，而不是放慢速度。

这意味着，如果您有1万活跃用户，则需要为很多服务器付费来处理它们。我们当前的解决方案可以轻松处理1万个并发用户。它会减慢速度，但不会崩溃。多亏Linode还是便宜的。

我们还借此机会将大多数交易电子邮件移至mailgun。因此，如果您收到我们的电子邮件，则将注意到它使用了另一个域。

过去，开发人员在注册时遇到的主要问题之一是由于公司收件箱使我们陷入了垃圾邮件。假设SendGrid可以帮助我们解决这些问题，我们做出了一些错误的技术选择。 Ť

他可能不是SendGrid的错，而是我们对该领域缺乏了解。

我们决定从新的域开始，为电子邮件添加新的域。我们并没有把所有的东西都搬到那儿，我不确定是否会因为担心交付能力而搬家。无论如何，这似乎是一个好举动，因为到目前为止，我们具有100％的可交付性。

这会如何影响您

我已经在这里讨论了其中一些。但是，还有另外一个条目：IPN。

我们通过贝宝处理订阅。我们很乐意添加其他选项，但是所有这些选项的全局部署都存在后勤问题。我们不希望服务器上有任何计费数据，因为我们不想处理这种复杂性。

PayPal计费可以通过称为IPN的解决方案进行工作，这意味着PayPal会在每次计费时调用我们。这样，我们可以根据收到的付款来更新我们的用户数据库。到目前为止，一切都很好。

不幸的是，设置后无法更改IPN地址。因此，现有订阅者仍指向旧的应用程序引擎URL。我们有一种轮询应用程序引擎以解决现有订阅者订阅级别的方法。

这只会影响当前的付费用户，并且可能会导致您的订阅似乎还有2天的剩余时间。

我们计划在App Engine中迁移项目，因此IPN将是唯一剩下的部分，并且将指向我们的服务器。为此，我们需要使App Engine脱机并使用新项目进行设置。那需要时间。因此，目前，此解决方法已经到位。

我们计划在月底前禁用App Engine构建。这意味着您需要将插件更新到最新版本才能进行构建。如果您不这样做，将会得到一个错误。我们仍然不会删除应用引擎，因为其他一些功能很难迁移。

下一步是什么？

现在已经到位了，我们终于可以实现我们一直渴望的一些很棒的功能了......免费用户的更高构建配额，包括推送通知等功能。

所有这些都将在未来几个月内出现...

我不想宣布日期，因为我仍在写这本书，我们需要推出Codename One 5.0，但希望在5.0之前推出，而现在5.0计划于9月发布。

如果您想了解有关Spring Boot的更多信息，请参考以下有用的资源，例如书籍和课程，以供进一步阅读：

From: https://hackernoon.com/migrating-from-app-engine-to-spring-boot-75de8b4566ce