但是，速度并不是以这种方式设计服务的唯一价值。一种常见的新兴组织模型是将跨职能的团队聚集在业务问题，服务或产品上。微服务模型非常适合这种趋势，因为它使组织能够围绕一项服务或一组服务创建跨职能的小型团队，并使它们以敏捷的方式运作。

最后，服务的小规模加上清晰的边界和沟通模式，使新团队成员更容易理解代码库并快速做出贡献，这在速度和员工士气方面均具有明显的好处。

在传统的n层体系结构模式中，应用程序通常共享一个公共堆栈，而大型关系数据库支持整个应用程序。这种方法有几个明显的缺点-最主要的缺点是，即使对于某些元素有一个清晰，更好的工具，应用程序的每个组件也必须共享一个公共的堆栈，数据模型和数据库。它造成了糟糕的体系结构，并且使开发人员感到沮丧，他们不断意识到可以使用更好，更有效的方式来构建这些组件。

相比之下，在微服务模型中，组件是独立部署的，并通过REST，事件流和消息代理的某种组合进行通信-因此，可以针对该服务优化每个单独服务的堆栈。技术一直在变化，由多个较小的服务组成的应用程序随着更理想的技术的发展而变得更容易且成本更低。

使用微服务，可以单独部署单个服务，但是也可以单独扩展它们。由此带来的好处是显而易见的：如果正确完成，微服务比单片应用程序所需的基础结构要少，因为微服务仅支持对需要它的组件进行精确缩放，而对于单片应用程序则不需要整个应用程序。

尽管几乎任何现代工具或语言都可以在微服务体系结构中使用，但仍有一些核心工具已成为微服务必不可少的基本定义：

微服务的关键要素之一是它通常很小。（没有任意数量的代码来确定某项内容是否为微服务，但名称中恰好有“微”字。）

当Docker的容器技术迎来了2013年，它也推出了计算模型，将成为微服务最密切相关。由于单个容器没有自己操作系统的开销，因此它们比传统虚拟机更小，更轻，并且可以更快地上下旋转，从而使其与微服务架构中的更小，更轻便的服务完美匹配。

随着服务和容器的激增，对大型容器进行编排和管理很快成为关键挑战之一。Kubernetes已经成为世界上最受欢迎的容器编排 技术之一，因为它做得很好。

微服务通常通过API进行通信，尤其是在首次建立状态时。虽然确实可以实现客户端和服务之间的直接通信，但API网关通常是有用的中介层，尤其是随着应用程序中服务数量的不断增长。API网关通过路由请求，将请求散布到多个服务中并提供额外的安全性和身份验证，充当客户端的反向代理。

有迹象表明，可用于执行API网关，包括API管理平台的多种技术，但如果正在使用集装箱和Kubernetes实现的微服务架构中，网关使用的入口或更近，通常实现Istio。

尽管最佳实践可能是设计无状态服务，但是状态仍然存在，服务需要意识到这一点。尽管API调用通常是初始为给定服务建立状态的有效方法，但它并不是保持最新状态的特别有效方法。

相反，必须将建立状态的API调用与消息传递或事件流耦合在一起，以便服务可以广播状态更改，而其他相关方可以侦听这些更改并相应地进行调整。这项工作可能最适合于通用消息代理，但是在某些情况下，事件流传输平台（例如Apache Kafka）可能是一个很好的选择。

无服务器架构将某些核心云和微服务模式纳入其逻辑结论。在无服务器的情况下，执行单元不仅是一个小型服务，而且是一个功能，通常只能是几行代码。无服务器功能与微服务之间的界线模糊，但通常认为功能甚至比微服务小。

无服务器架构和功能即服务（FaaS）平台与微服务共享相似性的地方在于，它们都对创建更小的部署单位以及根据需求进行精确扩展感兴趣。

在微服务架构中，有许多常见且有用的设计，通信和集成模式可帮助解决一些更常见的挑战和机遇，包括以下内容：

尽管有许多很好地完成微服务的模式，但也有相当数量的模式可以使任何开发团队迅速陷入困境。其中一些（表述为微服务“不要”）如下：