微服务帮助我们更快地构建、扩展和部署软件。以下是如何在不失去理智的情况下迁移您的单体应用。
要么快速构建你的软件，要么等死！
这是软件领域的规则。当我作为顾问工作时，我亲眼看到了对速度的争夺。
我曾与一家全球银行合作，建立一个信贷审批应用程序。它的规模很大--混合了几十种服务，以确保你值得他们的APR。
但是有一天，他们的首席开发人员把我拉到一边说。
"我害怕对我们的应用程序进行修改。因为我知道，有些东西已经烂透了！"
如果他害怕做出改变，你认为他们会有多快？
单体Monoliths 是作为单个单元部署的大型应用程序，它们并不全是坏事，但随着应用程序的增长，单体式应用程序成为改变的噩梦：开发放缓。这就是我们使用微服务的原因。
微服务帮助我们快速构建软件。它们是我们可以快速构建、更改和扩展的小型服务。为了获得这种速度，我们可以将我们的整体分解成一组微服务。
但在这个旅程中也有挑战。
我们如何将整体迁移到微服务？
迁移最重要的部分是记住目标。“为什么”将决定我们如何进行迁移。对我们来说，这是对速度的需求。
要将我们的整体分解为微服务，我们需要回答三个问题：
- 我们应该首先迁移哪些应用程序？
- 我们如何将我们的应用程序迁移到微服务？
- 我们将如何构建、运行和管理这些新的微服务？
1、我们应该首先迁移哪些应用程序？
并非一切都需要成为微服务。为了选择一个好的候选应用程序进行迁移，我们将尝试最大化收益和最小化风险。想想投资回报率。以下是优秀候选人的迹象。
标志 #1：应用程序经常更改
这有助于我们获得迁移到微服务的最大价值（并减少大部分减速）。每次我们进行更改服务时，我们都会从迁移中获得速度优势。
标志 #2：应用程序需要低 LOE 才能迁移
这似乎与第一个迹象相反。但是，使用现代运行时或具有明确定义边界的单体应用程序需要较少的重构，并且可能是很好的候选者。
标志 #3：该应用程序几乎没有其他依赖它的应用程序
避免首先迁移核心应用程序。您将已经了解如何构建、部署和编排新服务。你不想在陷入依赖关系的网络时这样做。
2、我们如何将我们的应用程序迁移到微服务？
迁移最好分阶段进行。当团队一口气尝试时，通常会以挫败感告终并放弃整个努力。
对于 Java 应用程序，我们推荐三个步骤：
第 1 步：迁移到现代应用程序服务器
为了使您的迁移工作更轻松，请迁移到具有以下特征的应用程序服务器（banq注：微服务已经没有应用服务器概念，直接一个Jar应用，被Weblogic等洗脑的体系还有这个概念，本文是Redhat的软文）：
- 符合开放标准。被锁定会减慢您快速移动的能力。
- 可以轻松地在容器平台上运行。 这将有助于未来的现代化工作。
第 2 步：在容器平台上运行单体应用
如果您执行了第一步，您将能够轻松地将应用程序部署到容器平台。但这不是我们的最终目的地，在容器平台上运行单体应用有一些速度优势，例如：
- 自动缩放，
- 故障转移
- 零停机部署
第 3 步：拆分单体应用
这可能是一篇单独的文章。现在我们的应用程序在容器平台上，我们将开始分解我们的整体。以下是创建微服务时的一些技巧。
首先从边缘开始。与标志 #3 类似，从没有大量依赖项的服务开始。
- 思考能力，而不是代码。根据业务功能分解事物。这有助于我们独立部署、快速行动，并且是安排能够管理端到端交付的团队的关键。
- 不要忘记数据。为了获得速度的全部好处，每个服务都应该有自己的数据存储。您可以通过 API为其他服务公开数据或将其复制到微服务的数据库中。
3、我们将如何构建、运行和管理我们的微服务？
为了有效地构建和运行我们的新微服务，我们需要一个新的运行时和一个平台。
容器本机 Java
您可能已经意识到 Java EE 并不是为微服务而构建的。加载胖 JVM 与“微”相反。所以我们需要一个可以在容器中运行良好的运行时。
运行微服务
微服务帮助我们走得更快。但是我们有一些新问题，例如：
- 部署——我们如何构建和部署五项服务而不是一项？
- 编排——我们如何管理数百个正在运行的微型服务？
- 通信——我们的服务将如何发现彼此并进行通信？
最佳实践
迁移可能需要大量工作，但可以让您的生活更轻松。
- 分阶段进行迁移。
- 构建良好的微服务。从边缘开始，专注于业务功能，不要忘记数据。
- 使用容器运行时和平台