如果您是软件工程师/开发人员，请想一想，当软件中的某个模块必须更改时，您会怎么做？
答案是改变模块。
但是几十年前，当模块化还不是最重要的时候，情况就有点不同了。
有时，软件就是我们所说的 Monoliths。使用 C 或 C# 或其他过程语言编写的单个相关应用程序，无论何时向其提供更新，都必须完全删除并在服务器上重新安装。这是我们过去常常获得服务停机时间的时候。这些应用程序过去非常快，但更新期间的停机时间仍然是一个大问题。
因此，解析器以负载平衡器的形式出现。
不是使用 1 台或 2 台服务器，而是增加了服务器数量。这有两个方面的帮助：
并非所有时间服务的流量都是相同的。因此，每当流量很高时，服务器之间的负载就会平衡，而在流量较低的时候，一台服务器将正常运行。这减少了资源浪费，提供了备份并在高峰时段处理了大量流量。
接下来，主要优势出现了，现在每当需要更新软件时，不是将应用程序作为一个整体删除，而是从一半的服务器中删除。因此，假设应用程序在 4 个服务器上运行，在低流量期间，2 个服务器将关闭，2 个将启动。然后在 2 台停机的服务器上更新应用程序，然后对其他 2 台服务器重复该过程。因此，用户从未有过停机时间。
但这也没有完全解决问题，因为整个应用程序仍在被替换，这仍然不是理想的情况。
然后随着编程实践中模块化的出现，Oracle 推出了 J2EE，即Java Platform Enterprise Edition。这有助于提供服务、数据库、简化架构以及与现有信息系统集成的选择。这导致了oracle在该领域的垄断，与之相反，产生了微服务的想法。
我们今天在应用程序中看到的是微服务的最佳使用。
无需更改整个应用程序，现在只需更改要更新的模块，而应用程序的其余部分始终正常运行。这可以实现，因为微服务架构通过在架构方法中提供具有这些属性的服务集合，使应用程序松散耦合、围绕业务功能组织并且高度可维护。
最后，由于单体应用程序的悠久历史，我们拥有了目前的应用程序形式，高度模块化、可维护且易于更新。