相较于单体应用，微服务架构在提升开发、部署等环节灵活性的同时，也提升了在运维、监控环节的复杂性。结合实践总结，微服务架构的设计有以下四条设计约束遵循：
(1)微服务个体约束
一个设计良好的微服务应用，所完成的功能在业务领域的划分上应互相独立。微服务的微，应用是按照问题域对单体应用做合理的拆分。
微服务还应该具备正交分解特性，在职责划分上专注于特定业务，即遵守SOLID 原则中的 单一职责原则 （Single Responsibility Principle，SRP），微服务修改或者发布时，不应影响到另外一个服务的交互。
(2)微服务之间的横向关系
微服务的横向关系包括两个方面: 可发现性、可交互性。
可发现性是指， 当服务A发布或者扩缩容时，依赖服务A的服务X如何在保持运行的前提下自动感知到服务A的变化。这里需要引入第三方服务注册中心来实现服务的可发现性。
可交互性是指， 服务A采用什么方式才可以调用服务X，由于服务自治的约束 ，服务之间的调用需要采用开发语言无关的远程调用协议。现在业界大部分的微服务架构通常采用基于 IDL （Interactive Data Language， 交互式数据语言）的二进制协议进行交互，为了进一步实现解构，微服务体系还需要一个独立的元数据中心，由它来存储服务的元数据信息，服务通过查询该中心的定义来实现发起调用的细节。
此外，由于服务链路的复杂性，微服务架构也随之变的脆弱，因此面向失败的设计原则在微服务体系中就变得尤为重要。类似 限流、熔断、隔仓、负载均衡等增强服务韧性的可靠性设计也成为微服务架构的标配。
(3)微服务与数据层的纵向约束
微服务领域提倡数据存储隔离(Data Storage Segregation, DSS) 原则，即数据是微服务的私有资产，必须通过当前微服务提供的API来访问数据，避免数据层产生耦合。
同样，由于容器调度会对底层设施的稳定性产生不可预知的影响，在设计微服务时，应当遵守无状态服务设计原则，与底层基础设施解耦，从而实现在不同容器之间自由调度。对于有状态的微服务而言，通常使用计算与存储分类的方式，将数据下层到分布式存储方案中，从而一定程度上实现服务无状态化。
(4)全局视角下的微服务分布式约束
在设计微服务架构的开始阶段，就要考虑两个重要问题，如何实现高效的运维以及微服务体系的可观测能力。
- 如何设计提升开发效率的全自动化的CI/CD流水线，并在这个基础之上支持蓝绿部署、灰度发布、金丝雀发布等不同策略。以满足业务对发布稳定性的诉求。
- 全链路、实时和多维度的可观测性应是标配设计。在微服务的运维中，发现故障的时效性和根本原因分析的精确性是开发、运维的核心诉求。