让我们把这些术语的混淆扼杀在萌芽状态，好吗？
如今，“微”很重要。微服务和微分段正在并将继续对数据中心架构产生影响，但不一定出于相同的原因。越来越多的人——尤其是那些有网络背景的人——将两者混为一谈，并用它们来表示同一件事。
他们不是。
一是关于申请。另一个，网络。有一种关系，但这是一种自愿的关系。它们是两种截然不同的事物，我们需要纠正迅速变得普遍的误解。
微服务
微服务是在将应用程序分解为更小的部分的过程中产生的一组服务（如果您愿意的话，可以称为迷你应用程序）。如果你将一个单体应用程序分割成许多部分，你最终会得到微服务。它是一个应用程序架构；一种设计应用程序的方法。
这种架构方法对网络架构有重大影响，因为它
迫使更广泛的应用程序仿射服务
（如负载平衡、缓存和加速）分布在更靠近单个服务的位置。微服务作为一种方法是
网络分叉
的一个强制因素，因为它将应用亲和服务与企业亲和服务分开。
微服务架构的好处在于它们非常高效；它将功能域或对象域分开，因此非常适合更有针对性和高效的可伸缩性模型。它在设计 API 时特别有用，因为除了可扩展性优势之外，它还可以本地化功能并启用隔离升级和新功能，而不必中断其他服务（以及开发其他服务的团队）。这非常适合敏捷方法，同时能够更加关注 API 开发，因为它与其他服务以及将使用该服务的应用程序相关。
微分段
微分段是关于网络的；准确地说，目前它是关于网络中的安全功能以及它们所在的位置。它是一种网络架构，与微服务一样，打破了对某些事物（在本例中为安全性）的整体方法并将其分发到多个服务中。您可以说微分段是微安全服务，因为它将安全策略分解为多个集中的安全策略，并以资源亲和的方式分发它们。也就是说，应用程序特有的安全策略在物理上 更靠近 该应用程序，而不是作为宏伟的公司策略的一部分位于网络边缘。
这种方法虽然最初侧重于安全性，但也可以应用于其他服务。如上所述，由于对应用程序采用微服务方法，网络自然会分叉，并且应用程序亲和服务（如安全性）更接近应用程序。这就是微分段的全部内容；较小的分布式安全“段”（以及其他应用程序仿射服务，如负载平衡和缓存）在逻辑上靠近应用程序部署。
因此，如果这两种方法之间存在任何关系，那就是微服务倾向于创建一个发生微分段的环境。
微分段还有其他原因，包括在边缘支持每个特定于应用程序的服务所需的规模只是将 IT 推向了智慧的边缘（只是有点双关语）。另一个驱动因素（或者它可能是一个好处？）是服务隔离，它可以在单个服务发生变化时减少中断。例如，对核心防火墙的更改被认为具有潜在的高度破坏性，因为如果出错，一切都会崩溃。更改负责为两个或三个应用程序提供服务的本地化隔离服务的防火墙规则，如果出现问题，中断率要低得多。
这在稳定性与敏捷性同样重要的复杂环境中是非常可取的。
同居
简而言之，微服务之于应用程序就像微分段之于网络服务。两者都是关于将单体架构分解为其核心组件，并以一种支持更具可扩展性、安全性和隔离控制域的方式按拓扑方式分布它们。
需要记住的是，仅仅因为开发人员决定利用微服务并不意味着网络会以某种方式神奇地变成微分段，或者如果使用微分段来优化网络服务架构，应用程序会突然变成微服务。微分段可用于在逻辑上隔离单体应用程序，就像微服务一样容易。
两种方法都可以独立使用，尽管网络中的最佳实践似乎表明，如果开发人员决定使用微服务，微分段也不会落后太多。但是在网络中使用微分段并不意味着开发人员将全力以赴使用微服务。