当一个业务应用程序(一个开发团队)变得更大,达到一定的规模时,公司就会遇到严重的管理和合作瓶颈。此外,如果一个软件产品基于一个巨大的整体架构,那么它们也面临着技术挑战。在这种情况下,业务需要一个解决方案来修复工作流并增强项目上的协作。
一旦传统后端整体结构的复杂性要求更高的可伸缩性,那么微服务体系结构(MSA)就可以解决与传统后端整体结构相关的问题。
Netflix、亚马逊(Amazon)和优步(Uber)等大型科技公司展示了向微服务的迁移如何影响了它们的业务。非科技公司也从中受益。沃尔玛通过微服务重振其在线业务的案例,可能是此类架构对传统企业变革潜力的一个例子。
根据最近的调查,80%的公司依赖于微服务,并朝着完全的微服务体系结构发展。9%的软件主要基于分布式结构,38%将微服务与传统的整体结合起来,33%计划在不久的将来进行转换。
Why:微服务在企业软件开发中的角色
企业应用程序通常以整体的形式出现,例如MVC。这种通常的做法似乎是合理的,因为支持要求较低,而且系统在小范围内工作得很好。因此,如果它可以起作用,公司就不需要改变任何东西。
一旦系统变得太大而无法无缝地作为一个整体进行维护,微服务就会发挥其业务节省的作用。一个常见的做法是将整体分解成小的独立部分,每个部分由一个敏捷子团队部署和维护。这样你就把团队协作问题抛在了脑后。
微服务的好处和困难
微服务解决了许多技术和协作问题,但它们并不完美。实际上,企业采用这种体系结构是因为对于软件性能至关重要的独特优势。但是采用者必须知道在使用这样的系统时他们将面临什么样的挑战。
好处:
困难:
When: 迁移到Mmicroservice体系结构的正确时机
微型服务的诞生是为了满足现代市场的需求。企业必须比竞争对手更好、更快地分析数据、创新和推出新产品和服务。它们需要灵活地满足客户不断变化的需求。迁移到微服务体系结构使他们能够更容易地做到这一点。
然而,企业通常只在实际需要发生时才接受这种解决方案。在大多数情况下,一个拥有超过25名成员的开发团队在维护整体结构的同时,开始遭受协作困难。因此,采用微服务的计划通常来自开发团队或软件供应商。
迁移到微服务可能是一个挑战。但从长远来看,这是值得的。
How: 迁移到微服务的方法
如何将微服务集成到整体架构中?
有两种基本方法:
1. 将一个核心整体架构系统分割成微型服务
这种方式既困难又昂贵。完全重新平台化可能需要长达一年的详尽工作。由于微服务不是一种普通的体系结构,而且MSA的专业知识也很难获得,因此这样的项目需要有才华和技能的专家。
显然,如果没有真正的需要,任何企业都不应该采用这种方法。当现有的在线系统变得过于笨重、无法应付负载时,企业往往会决定采取如此激进的措施。因此,他们迫切需要重新开发过时的遗留软件。
这不是一个容易的决定,因为它需要大量的投资和人力。因此,如果你觉得你需要打破你的单一业务,建立一个全新的平台与微服务,确保你有经验丰富的建筑师精通这个主题。
2. 保持整体,并在其周围建立微型服务
当您的团队过于庞大,无法维护整体功能并迅速添加新功能时,可能的解决方案是将新功能构建为微服务。因此,新来者将作为子团队工作,而核心~25开发人员将继续使用monolith。因此,当您在它周围构建尽可能多的微服务时,这个整体就变成了一个大型宏服务。
即使您正在外包软件开发,这种方法也不会干扰您的团队的工作。一般来说,雇佣和配备使用微服务的新程序员更容易。此外,这种体系结构的灵活性增强了协作并促进了远程团队的管理。例如,您的现场工程师可能在软件产品的整体和业务逻辑上工作,而一个外包团队围绕它开发多个微服务。
尽管如此,这种方法的陷阱是,如果您将来必须重新构建您的整体,那么这个过程将是一个比一开始完全使用微服务更大的挑战。在选择这个选择之前,最好三思而后行,选择一个长期的策略。
现实世界的情况总是与理论不同,微服务案例也不例外。在决定迁移到微服务之前,企业应该始终考虑自己的业务需求、行业威胁和可能性。这两种实现微服务的方法只是指导您完成此过程的里程碑。您的业务情况是独特的,需要一个原始的解决方案。然而,改变是不可避免的,你需要准备好接受它。