微服务的设计原则

设计原则是从CSDN上吸取的其他大神的经验，记个笔记。

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

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

三 、轻量级通信原则微服务之间应该通过轻量级通信机制进行交互。轻量级通信机制应该具备两点：首先是它的体量较轻；其次是它应该是跨语言、跨平台的。例如我们所熟悉的REST协议，就是一个典型的“轻量级通信机制”；而例如Java的RMI协议则就不符合轻量级通信要求，应该它绑定了Jave语言。楼主之前在某互联网大厂的视频部门的时候，就发现使用的是RMI协议，配置起来较为繁琐，且太重了。我们一般都是使用REST协议。

四 、微服务粒度微服务的粒度是难点，也常常是争论的焦点。应当使用合理的粒度划分微服务，而不是一味将服务做小。代码量的多少不能作为微服务划分的依据，因为不同的服务本身的业务复杂性不同，代码量也不同。在微服务的设计阶段，就应确定其边界。微服务之间应该相对独立并保持松耦合。领域驱动设计中的“界限上下文”可作为微服务边界、确定微服务粒度的重要依据。微服务架构的演进是一个循序渐进的过程。在演进过程中，常常会根据业务的变化，对微服务进行重构，甚至是重新划分，从而让架构更加合理。这也是目前楼主比较痛苦的地方，楼主的项目组已经经过了两次微服务调整了。最终，当微服务的开发、部署、测试以及运维效率很高，并且成本很低，一个好的微服务架构就形成了。