微服务设计原则--笔记
微服务设计原则–笔记
单一职责原则
单一职责原则指的是一个单元（类、方法或者服务等）只应关注系统功能中单独、有界限的一部分。单一职责原则可以帮助我们优雅的开发、敏捷的交付。单一职责也是SOLID原则之一。
接口隔离原则
服务之间的交互应该基于明确定义的接口，而不是共享底层实现。应该尽可能减少服务与服务之间的耦合度
服务自治原则
服务自治是指每个微服务应具备独立的业务能力、依赖与运行环境。在微服务架构中，服务是独立的业务单元，应该与其他服务高度解耦。每个微服务从开发、测试、构建、部署，都应当独立运行。
轻量级通信机制
微服务之间应通过轻量级的通信机制进行交互。
轻量级的通信机制的特点是体量较轻、跨语言、跨平台。
常用的轻量级通信协议有：
REST协议，AMQP协议、STOMP协议、MQTT协议
微服务粒度
应当使用合理的粒度划分微服务，而不是一味的把服务做小。在微服务设计阶段，就应确定其边界，微服务之间应相对独立并保持松耦合，可以使用DDD领域驱动设计中的【界限上下文】划分微服务边界、确定微服务粒度。但DDD不是银弹，实际开发还要结合具体业务场景进行微服务粒度设计。
无状态原则
每个微服务应该是无状态的，即在处理请求时不依赖于之前的请求状态。这有助于实现横向扩展和容错。
面向服务的架构
微服务应该按照业务领域划分，并设计成可以独立部署的服务。每个服务都应该有自己的数据库以及处理数据的逻辑。
可拓展性和可伸缩性
微服务应该优先考虑可拓展性，它应该能够方便地增加或移除服务实例以适应流量变化
健壮性和容错能力
微服务系统应对故障有所准备。这包括设计失败时的重试、降级及恢复策略等。
DevOps
DevOps文化可以确保开发人员和运维人员之间的紧密协作和合作。这样能够加快开发周期，提高微服务系统的稳定性和安全性
以上是一些常见的微服务设计原则，需要根据实际情况进行具体的应用和调整。
深碍√TFBOYSˉ_
骑猪看日落
淩亂°似流年
╰+攻爆jí腚メ
还没有评论，来说两句吧...