微服务的设计原则

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

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

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

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

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