Why、When以及How：成功迁移到微服务

当一个业务应用程序(一个开发团队)变得更大，达到一定的规模时，公司就会遇到严重的管理和合作瓶颈。此外，如果一个软件产品基于一个巨大的整体架构，那么它们也面临着技术挑战。在这种情况下，业务需要一个解决方案来修复工作流并增强项目上的协作。

一旦传统后端整体结构的复杂性要求更高的可伸缩性，那么微服务体系结构(MSA)就可以解决与传统后端整体结构相关的问题。

Netflix、亚马逊(Amazon)和优步(Uber)等大型科技公司展示了向微服务的迁移如何影响了它们的业务。非科技公司也从中受益。沃尔玛通过微服务重振其在线业务的案例，可能是此类架构对传统企业变革潜力的一个例子。

根据最近的调查，80%的公司依赖于微服务，并朝着完全的微服务体系结构发展。9%的软件主要基于分布式结构，38%将微服务与传统的整体结合起来，33%计划在不久的将来进行转换。

Why:微服务在企业软件开发中的角色

企业应用程序通常以整体的形式出现，例如MVC。这种通常的做法似乎是合理的，因为支持要求较低，而且系统在小范围内工作得很好。因此，如果它可以起作用，公司就不需要改变任何东西。

一旦系统变得太大而无法无缝地作为一个整体进行维护，微服务就会发挥其业务节省的作用。一个常见的做法是将整体分解成小的独立部分，每个部分由一个敏捷子团队部署和维护。这样你就把团队协作问题抛在了脑后。

微服务的好处和困难

微服务解决了许多技术和协作问题，但它们并不完美。实际上，企业采用这种体系结构是因为对于软件性能至关重要的独特优势。但是采用者必须知道在使用这样的系统时他们将面临什么样的挑战。

好处:

• Independence of elements：一个系统可以在没有一个或几个元素的情况下正常工作。
• 稳定性：首先，使用微服务体系结构，您可以更容易地扩展团队。其次，更高的可伸缩性会影响开发速度。每个子团队都有自己的待办事项列表并独立交付，所以他们可以以5倍的速度进行开发。
• 灵活性：如果您需要应用或尝试新技术，microservices将允许您更容易地将其结合起来。
• 降低准入门槛： 您的开发团队正在成长。因此，您决定切换到微服务来改进工作流。好处是双向的:新专家可以更快地进入微服务体系结构。

困难:

• 分布式系统： 多个模块和数据库之间有很多连接。因此，必须非常小心地处理请求、事务、数据管理。
• 测试：整体架构使用开箱即用的战争。QA专家只需要启动该文件，以确认monolith与底层数据库的连接。相反，微服务要求在开始测试之前对每个服务进行验证。

When: 迁移到Mmicroservice体系结构的正确时机

微型服务的诞生是为了满足现代市场的需求。企业必须比竞争对手更好、更快地分析数据、创新和推出新产品和服务。它们需要灵活地满足客户不断变化的需求。迁移到微服务体系结构使他们能够更容易地做到这一点。

然而，企业通常只在实际需要发生时才接受这种解决方案。在大多数情况下，一个拥有超过25名成员的开发团队在维护整体结构的同时，开始遭受协作困难。因此，采用微服务的计划通常来自开发团队或软件供应商。

迁移到微服务可能是一个挑战。但从长远来看，这是值得的。

How: 迁移到微服务的方法

如何将微服务集成到整体架构中?

有两种基本方法:

1. 将一个核心整体架构系统分割成微型服务

这种方式既困难又昂贵。完全重新平台化可能需要长达一年的详尽工作。由于微服务不是一种普通的体系结构，而且MSA的专业知识也很难获得，因此这样的项目需要有才华和技能的专家。

显然，如果没有真正的需要，任何企业都不应该采用这种方法。当现有的在线系统变得过于笨重、无法应付负载时，企业往往会决定采取如此激进的措施。因此，他们迫切需要重新开发过时的遗留软件。

这不是一个容易的决定，因为它需要大量的投资和人力。因此，如果你觉得你需要打破你的单一业务，建立一个全新的平台与微服务，确保你有经验丰富的建筑师精通这个主题。

2. 保持整体，并在其周围建立微型服务

当您的团队过于庞大，无法维护整体功能并迅速添加新功能时，可能的解决方案是将新功能构建为微服务。因此，新来者将作为子团队工作，而核心~25开发人员将继续使用monolith。因此，当您在它周围构建尽可能多的微服务时，这个整体就变成了一个大型宏服务。

即使您正在外包软件开发，这种方法也不会干扰您的团队的工作。一般来说，雇佣和配备使用微服务的新程序员更容易。此外，这种体系结构的灵活性增强了协作并促进了远程团队的管理。例如，您的现场工程师可能在软件产品的整体和业务逻辑上工作，而一个外包团队围绕它开发多个微服务。

尽管如此，这种方法的陷阱是，如果您将来必须重新构建您的整体，那么这个过程将是一个比一开始完全使用微服务更大的挑战。在选择这个选择之前，最好三思而后行，选择一个长期的策略。

现实世界的情况总是与理论不同，微服务案例也不例外。在决定迁移到微服务之前，企业应该始终考虑自己的业务需求、行业威胁和可能性。这两种实现微服务的方法只是指导您完成此过程的里程碑。您的业务情况是独特的，需要一个原始的解决方案。然而，改变是不可避免的，你需要准备好接受它。