模块vs微服务

一、模块化的微服务

“通过微服务，我们最终可以让团队独立工作”，或者“我们的应用太复杂，这让我们放慢脚步”。这些表达只是导致开发团队走上微服务道路的众多原因中的一小部分。另一个问题是需要可扩展性和弹性。开发人员似乎总是渴望的是系统设计和开发的模块化方法。

软件开发中的模块化可以归结为三个指导原则：

1.1，强大的封装

隐藏组件内部的实现细节，导致不同部件之间的低耦合。团队可以在系统的分离部分上独立工作。

1.2，定义良好的接口

您无法隐藏所有内容（否则您的系统不会做任何有意义的事情），因此组件之间定义良好且稳定的API是必须的。组件可以由符合接口规范的任何实现替换。

1.3，显式依赖

拥有模块化系统意味着不同的组件必须协同工作。你最好有一种表达（和验证）他们关系的好方法。

上述原则可以通过微服务实现。而微服务可以用任何方式实现，只要它为其他服务公开定义良好的接口（通常是REST API）即可。其实施细节是服务的内部细节，可以在没有全系统影响或协调的情况下进行更改。但微服务之间的依赖关系在开发时通常不是很明确，导致运行时可能的服务编排失败。

因此，微服务实现了重要的模块化原则，从而带来了实实在在的好处：

团队可以独立工作和扩展。
微服务规模小，重点突出，降低了复杂性。
服务可在内部更改或替换，而不会产生全局影响。

当我们从一个（虽然有点臃肿）应用程序转变为分布式微服务系统，这其实带来了大量的操作复杂性。突然间，你需要不断部署许多不同的（可能是容器化的）服务。

这里就出现了新的问题：服务发现，分布式日志记录，跟踪等。现在更容易出现分布式计算下的错误了。接口和配置管理的版本控制也会成为一个主要问题，而且问题清单会一直增长下去。

事实证明，微服务之间的连接与所有单个微服务的组合业务逻辑一样复杂。虽然整体代码库中的“意大利面条代码”存在问题，但在这两者之间存在网络边界会使这些纠缠问题升级为彻头彻尾的痛苦。

ps：意大利面条代码是非结构化和难以维护的源代码的贬义词。可能由多