微服务：设计原则。
和数据库设计中的N范式一样，微服务也有一定的设计原则，这些原则指导我们更加合理的架构微服务。
单一职责原则
单一职责原则指的是一个单元（类、方法或者服务等）只应关注整个系统功能中单独、有界限的一部分。单一职责原则可以帮助我们更优雅的开发、更敏捷的交付。
单一职责原则是SOLID原则之一。
服务自治原则
服务自治是指每个微服务应具备独立的业务能力、依赖与运行环境。在微服务架构中，服务是独立的业务单元，应该与其他服务高度解耦。每个微服务从开发、测试、构建、部署，都应当可以独立运行，而不应该依赖其他的服务。
轻量级通信机制
微服务之间应该通过轻量级的通信机制进行交互。轻量级的通信机制应具备两点：首先是他的体量较轻；其次是他应该是跨语言、跨平台的。例如我们所熟悉的REST协议，就是一个典型“轻量级通信机制”；而例如Java的RMI则协议就不大符合轻量级通信机制的要求，因为他绑定了Java语言。
微服务架构中，常用的协议有REST、AMQP、STOMP、MQTT等。
微服务粒度
微服务的粒度是难点，也常常是争论的焦点。应当使用合理的粒度划分微服务，而不是一味的把服务做小。代码量的多少不能作为微服务划分的依据，因为不同的微服务本身的业务复杂性不同，代码量也不同。
在微服务的设计阶段，就应该确定其边界。为服务之间应相对独立并保持松耦合。领域驱动设计（Domain Driven Design，简称DDD）中的“界限上下文（Bounded Context）”可作为划分微服务边界、确定微服务粒度的重要依据。同时，在划分微服务的过程中，还应综合考量团队的现状。康威定律（Conway`s Law）相信大家已经很熟悉了。
微服务架构的演进是一个循序渐进的过程。在演进过程中，常常会根据业务的变化，对微服务进行重构，甚至是重新划分，从而让架构更加合理，当微服务的开发、部署、测试以及运维的的效率很高，并且成本很低时，一个好的微服务架构就形成了。
深碍√TFBOYSˉ_
今天药忘吃喽~
淩亂°似流年
╰+攻爆jí腚メ
还没有评论，来说两句吧...