微服务体系结构将软件构建为协作服务的套件。

微服务体系结构是在体系结构级别应用单一责任原则的自然结果。与传统的单片体系结构相比，这带来了许多好处，例如不同组件的独立可部署性、语言、平台和技术独立性、不同的可伸缩性轴以及增加的体系结构灵活性。

就规模而言，没有硬性规定。通常，微服务的数量级为数百行，但根据它们所封装的职责，也可以达到数十行或数千行。一个好的，尽管不具体的经验法则是尽可能小，但尽可能大，以表示他们拥有的领域概念。“微服务应该有多大?”有更多细节。

微服务通常使用HTTP上的REST进行集成。通过这种方式，业务域概念被建模为由每个服务管理的一个或多个资源。在最成熟的RESTful系统中，资源是使用超媒体控件链接的，这样每个资源的位置对服务的使用者是不透明的。参见Richardson成熟度模型了解更多细节。

有时会使用其他集成机制，如轻量级消息传递协议、发布-订阅模型或替代传输，如Protobuf或Thrift。

每个微服务可能提供，也可能不提供某种形式的用户界面。

微服务通常可以分成类似的模块


通常，微服务显示由部分或所有显示层组成的类似内部结构。

所采用的任何测试策略都应该旨在为服务的每一层以及层与层之间提供覆盖，同时保持轻量级。

资源充当服务公开的应用程序协议和消息到表示域的对象之间的映射器。通常，它们是瘦的，负责检查请求的完整性，并根据业务事务的结果提供特定于协议的响应。

几乎所有的服务逻辑都驻留在表示业务域的域模型中。在这些对象中，服务跨多个域活动进行协调，而存储库作用于域实体的集合，并且通常支持持久性。

如果一个服务有另一个服务作为协作者，则需要一些逻辑来与外部服务通信。网关用远程服务封装消息传递，对来自域对象的请求和响应进行编组。它很可能使用理解底层协议的客户机来处理请求-响应周期。

除非在最琐碎的情况下，或者当服务充当跨其他服务拥有的资源的聚合器时，微服务将需要能够在请求之间持久保存来自域的对象。这通常是通过使用对象关系映射或更轻量级的数据映射器来实现的，具体取决于持久性需求的复杂性。

微服务通过网络相互连接,并利用“外部”数据存储


微服务通过在每个相关模块之间传递消息以形成响应来处理请求。一个特定的请求可能需要与服务、网关或存储库交互，因此模块之间的连接是松散定义的。

自动化测试应该以尽可能精细的粒度为每一个通信提供覆盖。因此，每个测试都提供了一个集中且快速的反馈循环。

资源接收到请求，一旦验证，就调用域开始处理请求。

如果必须协调许多模块来完成业务事务，则资源将委托给服务。否则，它直接与相关模块通信。

到外部服务的连接需要特别注意，因为它们跨越了网络边界。系统应该对远程组件的中断具有弹性。网关包含处理此类错误情况的逻辑。

通常，与外部服务的通信比进程通信中的等效通信更粗粒度，以防止API的闲聊和延迟。

类似地，与外部数据存储的通信具有不同的设计考虑因素。虽然服务与数据存储的逻辑耦合比与外部服务的逻辑耦合更紧密，但数据存储仍然存在于网络边界之上，这会导致延迟和中断的风险。

网络分区的存在会影响所采用的测试风格。这些模块的测试可能需要较长的执行时间，并且可能会因为团队控制之外的原因而失败。

多个服务作为一个系统一起工作，以提供有业务价值的功能


通常，一个团队将充当一个或多个微服务的监护人。这些服务交换消息以处理更大的业务请求。就交换格式而言，JSON目前是最流行的，尽管有许多替代方案，其中XML是最常见的。

在某些情况下，异步发布-订阅通信机制比同步点对点机制更适合用例。作为实现微服务之间发布-订阅的轻量级方法，Atom联合格式正变得越来越流行。

由于业务请求跨越由网络分区分隔的多个组件，因此必须考虑系统中可能的故障模式。诸如超时、断路器和隔墙等技术可以帮助保持整个系统的正常运行时间，尽管组件中断。

在较大的系统中，通常有多个团队，每个团队负责不同的边界上下文。

外部服务的测试关注点可能与您团队控制下的服务的测试关注点不同，因为对于外部团队服务的接口和可用性的保证更少。

​