Monolithic架构到微服务

什么是Monolithic（单体）应用程序?

这种应用程序不是说只负责单个任务，但它们需要几个任务来完成特定的职责。在单体应用程序中，所有服务都打包成一个包，并作为一个进程运行。在单个应用程序中，用户界面、数据访问层和数据存储层是紧密耦合的。通常，大型团队使用单块应用程序，它们不适合基于容器的部署。

好处:

由于默认情况下所有工具和ide都支持这种应用程序，单体应用程序的开发非常简单。

非常容易部署，因为所有组件都打包在一个包中。

易于扩展整个应用程序。

缺点:

很难创建单体应用程序的补丁。

适应新技术是很有挑战性的。

很难维护CI/CD管道。

可维护性非常高，一行代码的刹车会使整个过程停止。

启动需要很长时间，因为所有组件都需要启动。

一个部件的故障将导致整个系统的故障。

什么是微服务?

对微服务没有适当的定义。我们可以将微服务定义为一组松散耦合的组件，它们一起工作以执行任务。这些轻量级组件可以通过各种语言(Java、PHP、Python)进行开发，并且可以使用各种协议(Http/Https/JMS)在两个组件之间进行通信。大多数微服务通过REST api公开它们的服务，以便其他服务能够更容易地调用这些服务。微服务遵循分散式架构。

优点:

能够运用最新的技术开发微服务。

可组合性非常高。

能够独立地扩展微服务。不需要扩展整个系统。

一个组件的故障不会导致整个系统停机。

在开发总体解决方案时，我们可以将微服务开发任务与小团队并行。这有助于减少开发时间。

CI / CD是非常容易的。

缺点:

独立的代码库维护非常困难。

由于权力下放，监督整个系统非常具有挑战性。通信需要非常强大的独立模块通信。

由于网络延迟而带来额外的性能开销。

为什么要移动到微服务架构?

目前，大多数企业应用程序都迁移到基于微服务的体系结构中，以获得最大的业务价值。大多数人都在寻找新技术，同时也在寻求摆脱遗留系统。人们倾向于使用集成，而不是开发整体应用程序

为过渡微服务需要考虑的关键点

确定能够独立运行的组件。

您使用什么技术来开发微服务?

需要考虑独立的服务代码可维护性。

需要考虑基础架构以及如何在每个组件之间实现负载平衡，因为这些服务是独立部署的。

需要考虑将开发服务器的团队数量和一个团队中的成员数量。

策略

冰淇淋勺策略

使用这种策略组织可以逐渐将单体架构转移到微服务架构。该策略主要关注系统的正常运行时间、用户体验，可以并行运行两个系统。从单片应用程序中获取一个组件，并将其开发为微服务，然后将其投入生产。同样地，挖掘所有组件并顺利迁移到微服务。这种策略减少了迁移的风险。使用这种策略需要更长的时间才能将整个系统迁移到微服务体系结构中。

乐高策略

在这种策略中，组织不会完全删除单个应用程序。架构师所做的是将新特性开发为微服务，并保持现有的单体应用程序的原样。这种架构被称为混合架构。这种策略的缺点是维护遗留系统以及微服务和系统集成非常困难。这种策略的优点是可以减少工作量，并且可以在短时间内开发特性。

核弹的策略

整个单体应用程序都是使用来自scratch的微服务编写的。这种策略的主要优点是组织可以克服单体应用程序中的所有错误，可以为新的构建微服务选择任何技术，也可以使用比单片应用程序更新的特性。对于这种策略，组织需要付出更多的努力和更多的投资。