Web 微服务在实践中是如何工作的？

理论上，我理解微服务是如何工作的，以及为什么它们在各种情况下都会有帮助，但我仍然不知道它在实践中是如何工作的

假设有一个基于CMS的在线商店作为一个整体应用程序

现在需要在微服务架构中运行在线商店

这种微服务架构在技术上与当前的单一架构有何不同

例如，我选择productsearch.php。如果我想扩展此功能，通常我必须设置一个新服务器，并将整个CMS Resources文件夹复制到其中以进行负载平衡

---

有了微服务，我想productsearch.php将是一个单一的微服务，我只需要复制这个php文件来扩展，而不需要复制其他资源？

我试图用这个虚构的CMS图来解释它。通过微服务体系结构，我们可以独立扩展每个微服务。每个微服务可能由不同的团队开发，甚至可能使用不同的技术开发。但我们需要极大的灵活性和维护开销，我相信这是值得的，因为大部分都可以自动化。
简单地说，molithic应用程序中的每个模块都是微服务的潜在候选者。然而，微服务可以比传统模块更细粒度

---

这很好地解释了如何分解单片应用程序

从技术和概念上讲，微服务独立于其他服务（在一个整体中，您将拥有具有相互依赖性的模块）

从技术上讲，建立在现代微服务平台（如Node.JS、Spring Boot或.NetCore）上的微服务将更容易利用集装箱化系统（如Docker），可能由服务注册和配置管理技术（如Kubernetes、ZooKeeper、Eureka等）支持

---

集装箱化的优点是更容易扩展（添加更多集装箱）。更进一步说，整个微服务/容器化概念和相关技术也有助于实现CI/CD等功能。

基本上，您将拥有许多小型应用程序实例，每个实例都执行一项特定的工作，而不是一个大型应用程序实例。假设在一个大型应用程序中，您发现操作A是一个瓶颈，占用了大部分CPU时间。仅为这一个操作扩展整个应用程序是浪费的。如果操作A本身是一个小的应用程序实例，则可以仅扩展该应用程序。将它放在具有单个端点的负载平衡器后面，将系统的其余部分指向该端点，您就可以更便宜、更容易地解决问题。使用微服务确实会带来麻烦，例如如果出现问题，将故障点转移到基础设施/网络工程师，微服务实际上取决于软件以整体式架构的方式设计的大小/复杂程度。它对一些人有效，对另一些人可能不太有效。在您的例子中，提到php脚本是一个非常复杂的例子，它远远不止于此，网络、虚拟机、带宽、网络架构等等