微服务设计原则--笔记

微服务设计原则–笔记

单一职责原则

单一职责原则指的是一个单元（类、方法或者服务等）只应关注系统功能中单独、有界限的一部分。单一职责原则可以帮助我们优雅的开发、敏捷的交付。单一职责也是SOLID原则之一。

接口隔离原则

服务之间的交互应该基于明确定义的接口，而不是共享底层实现。应该尽可能减少服务与服务之间的耦合度

服务自治原则

服务自治是指每个微服务应具备独立的业务能力、依赖与运行环境。在微服务架构中，服务是独立的业务单元，应该与其他服务高度解耦。每个微服务从开发、测试、构建、部署，都应当独立运行。

轻量级通信机制

微服务之间应通过轻量级的通信机制进行交互。
轻量级的通信机制的特点是体量较轻、跨语言、跨平台。
常用的轻量级通信协议有：
REST协议，AMQP协议、STOMP协议、MQTT协议

微服务粒度

应当使用合理的粒度划分微服务，而不是一味的把服务做小。在微服务设计阶段，就应确定其边界，微服务之间应相对独立并保持松耦合，可以使用DDD领域驱动设计中的【界限上下文】划分微服务边界、确定微服务粒度。但DDD不是银弹，实际开发还要结合具体业务场景进行微服务粒度设计。

无状态原则

每个微服务应该是无状态的，即在处理请求时不依赖于之前的请求状态。这有助于实现横向扩展和容错。

面向服务的架构

微服务应该按照业务领域划分，并设计成可以独立部署的服务。每个服务都应该有自己的数据库以及处理数据的逻辑。

可拓展性和可伸缩性

微服务应该优先考虑可拓展性，它应该能够方便地增加或移除服务实例以适应流量变化

健壮性和容错能力

微服务系统应对故障有所准备。这包括设计失败时的重试、降级及恢复策略等。

DevOps

DevOps文化可以确保开发人员和运维人员之间的紧密协作和合作。这样能够加快开发周期，提高微服务系统的稳定性和安全性

---

以上是一些常见的微服务设计原则，需要根据实际情况进行具体的应用和调整。