微服务:设计原则。

和数据库设计中的N范式一样,微服务也有一定的设计原则,这些原则指导我们更加合理的架构微服务。

单一职责原则

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

单一职责原则是SOLID原则之一。

服务自治原则

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

轻量级通信机制

微服务之间应该通过轻量级的通信机制进行交互。轻量级的通信机制应具备两点:首先是他的体量较轻;其次是他应该是跨语言、跨平台的。例如我们所熟悉的REST协议,就是一个典型“轻量级通信机制”;而例如Java的RMI则协议就不大符合轻量级通信机制的要求,因为他绑定了Java语言。

微服务架构中,常用的协议有REST、AMQP、STOMP、MQTT等。

微服务粒度

微服务的粒度是难点,也常常是争论的焦点。应当使用合理的粒度划分微服务,而不是一味的把服务做小。代码量的多少不能作为微服务划分的依据,因为不同的微服务本身的业务复杂性不同,代码量也不同。

在微服务的设计阶段,就应该确定其边界。为服务之间应相对独立并保持松耦合。领域驱动设计(Domain Driven Design,简称DDD)中的“界限上下文(Bounded Context)”可作为划分微服务边界、确定微服务粒度的重要依据。同时,在划分微服务的过程中,还应综合考量团队的现状。康威定律(Conway`s Law)相信大家已经很熟悉了。

微服务架构的演进是一个循序渐进的过程。在演进过程中,常常会根据业务的变化,对微服务进行重构,甚至是重新划分,从而让架构更加合理,当微服务的开发、部署、测试以及运维的的效率很高,并且成本很低时,一个好的微服务架构就形成了。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值