第一，它解决了复杂性的问题。它将一个可怕的、庞大的整体应用分解成一组服务。在整体的功能没有改变的同时，应用程序已经被分解成可管理的模块或服务。每个服务有以 RPC 或者消息驱动 API形式定义清楚的界限。微服务架构模式加强了一定程度的模块化，这在整体应用程序中是很难实现的。因此单个的服务可以更快的开发，更简单的理解和维护。
第二，这种架构使得每个服务可以由单独的团队独立开发，这些团队可以专注于某个服务。开发者可以自由地选择合理的技术，只要服务遵守 API 约定即可。当然大部分组织想要避免混乱地完全无限制的技术选择。然后这种自由意味着开发者不在受限于使用可能过时的技术开始新的项目。当开始写一个新服务的时候，他们可以选择使用当前的技术。而且因为服务相对较小，所以使用当前的技术重写老服务是可行的。
第三，微服务架构模式使得每一个微服务能被独立部署。开发者再也不需要调整本地对其服务的更变而进行部署。各种类型的变更能在他们测试时立即部署。UI 团队也可以这样做，举例来说，当 UI 发生改变时，能执行 A|B 测试并快速迭代。微服务架构模式让持续部署成为可能。
最后，微服务架构模式使得每一个服务都可以被独立扩展。你可以部署大量恰好符合要求容量和有效约束条件的服务实例。此外，你可以使用最匹配服务资源要求的硬件。例如，你可以在计算优化过的 EC2上部署一个密集CPU 镜像处理服务实例，还可以在内存优化的 EC2 上部署内存数据库服务实例。
东软 SaCa ACAP 基于微服务架构和相关技术，提供一种包括开发方法论、技术支撑和最佳实践在内的产品研发全新模式