在设计基于微服务的系统时，衡量和优化正确的指标至关重要。为每个微代码库和微团队设计本地边界绝对很容易。但是，要构建一个完整系统，我们必须将系统级别设计也考虑在内。微服务与系统级别的设计有关，而不是仅仅与单个服务有关。
在基于微服务的系统中，我们通过最小化服务的公共接口（使之成为微服务）来平衡本地和全球的复杂性。您公开的服务越小，其实现越简单，因此其本地复杂性也就越低。从全局复杂性的角度来看，较小的公共接口在服务之间产生较少的依赖关系和连接。
这种方法听起来似乎很简单。如果微服务只是具有微公共接口的服务，那么我们可以将公共接口限制为仅有一种方法的接口。不能比这更小了，那应该这就是是完美的微服务吗？
并非如此。为了形成系统，服务必须彼此交互并共享对每个服务状态的更改。因为服务接口只有一个方法，这个方法只是本地功能操作，无法与其他服务交互，因此，我们必须使用用于在服务之间集成的公共方法来实现这种更改，那么这种调用就变成蜘蛛网式的调用：
全局复杂性开始增加，不仅最终的系统陷入了混乱，而且为了集成的目的，我们还不得不将公共接口扩展到我们最初的意图之外。这将我们带到了重要的一点：
对于集成功能比业务相关的功能更重要的的服务来说，这是一种不断增长的分布式大泥球。
因此，可以将服务的公共接口最小化的阈值不仅取决于服务本身，而且还主要取决于该服务所属的系统。对微服务的适当分解应该平衡系统的全局复杂性和服务的局部复杂性。
设计服务边界
设计微服务的边界很困难，而且可能不可能在第一时间就正确。这使得设计相当复杂的基于微服务的系统成为一个迭代过程。
因此，更安全的方法是从更宽的边界开始，可能是适当的有界上下文的边界，然后随着对系统及其业务领域的更多了解，将它们分解为微服务。它与包含核心业务领域的服务特别相关。
这就是全部吗？
尽管最小化服务的公共接口是设计微服务的良好指导原则，但这仍然只是一种启发，并不能取代常识。实际上，微接口只是对更基本但更复杂的设计原理（耦合和内聚）的一种抽象。
例如，如果两个服务具有微公共接口，但是必须在分布式事务中进行协调，则它们之间仍然彼此高度耦合。
也就是说，针对微接口仍然是一种强大的启发式方法，可以解决不同类型的耦合问题，例如功能，开发和语义。但这是另一个博客的主题。