微服务这个概念并不是近年才有的，但这两年随着以容器为核心的新一代应用承载平台的崛起，微服务焕发了新的生命力。
传统的巨大单体应用程序在部署和运行时，需要单台服务器具有大量内存和其他资源。巨大的单体应用必须通过在多个服务器上复制整个应用程序来实现横向扩展，因此其扩展能力极差；此外，这些应用程序往往更复杂，各个功能组件紧耦合，使得维护和更新更加困难。
在这种情况下，想单独升级应用的一个功能组件，就会有“牵一发而动全身”的困扰。
在微服务架构中，传统的巨大单体应用被拆分为小型模块化的服务，每项服务都围绕特定的业务领域构建，不同微服务可以用不同的编程语言编写，甚至可以使用完全不同的工具进行管理和部署。
与单体应用程序相比，微服务组织更好、更小、更松耦合，并且是独立开发、测试和部署的。由于微服务可以独立发布，因此修复错误或添加新功能所需的时间要短得多，并且可以更有效地将更改部署到生产中。此外，由于微服务很小且无状态，因此更容易扩展。
总体而言，微服务通常具有六个特点：以单个业务或域为模型；每个微服务实现自己的业务逻辑，包含独立的持久数据存储；每个微服务有一个单独发布的API；每个微服务能够独立运行；每个微服务独立于其他服务且松耦合；每个微服务可以独立地升级、回滚、扩容、缩容。
企业使用微服务可以获得多方面的收益。实施微服务架构可以使企业更快地将其应用程序推向市场。对整体应用程序的更改需要重新部署整个应用程序堆栈，从而引入风险和复杂性。相反，服务的更新可以立即提交、测试和部署，对个别服务的更改不会影响系统的其他部分。
在扩展应用程序时，微服务方法也提供了灵活性。单片应用程序要求整个系统及其所有功能同时扩展。使用微服务，只需要缩放需要额外性能的组件或功能。可以通过部署更多微服务实例来扩展服务范围，从而实现更有效的容量规划并降低软件许可成本，从而降低总体拥有成本。
而在使用单体应用程序时，组件的故障可能会危及整个应用程序。在微服务中，每项服务都是隔离的，以防止级联失败导致整个系统崩溃。如果单个微服务的所有实例均失败，则整体服务可能会降级，但其他组件仍可提供有价值的服务。
最重要的是，微服务使技术团队能够与企业需求保持一致，并且可以调整团队的大小以匹配所需的任务。通常，微服务团队规模较小但是跨部门，并专注于整个应用程序的单个组件。通过提供对个人服务的所有权，来打破团队之间的孤岛，并改善协作。这种方法对于分布式和远程团队尤其强大，更加适用于多地办公愈加频繁的当下。
从其本质上来说，微服务的目的就是有效的拆分应用，实现敏捷开发和部署。根据康威定律，系统架构和组织架构会相互影响，在微服务架构的影响下，微服务小组变为了一个独立特性的全功能团队，来面向最终用户需求直接对战。最后，所有的信息和想法都在这个小范围内快速交流，业务价值流动清晰可见，软件与企业和这个瞬息万变的时代一起，实现快速更迭的目标。