服务化设计模式实践

这篇文章主要是想介绍我们团队在业务发展中业务服务的架构模式变迁,以及服务之前通信的方式变化。

服务化实现

点评在2012年左右就推荐一些共用系统服务化,到2015年公司全面推进服务化建设,业务逻辑几乎全部沉淀到后台服务,前台的web只提供简单的http 接口,而APP则只负责展示功能。

因此,在我们开始开发时就采用全部服务化的方法。点评自己开发了一套RPC框架——pigeon,这个在之前的博客RPC是什么 有过详细的介绍。

我们需要什么样的微服务

微服务到底应该是多大,一种简单的划分方法是项目代码在100-300行。这个划分方式肯定是不合理的,但也表现了微服务的一个核心思想——服务尽量的小。

1. 微服务架构的特点

领域驱动设计

单一职责原则:每个服务只负责自己单独的部分,这也是SOLID原则之一;

明确发布接口:每个服务都会发布一个定义明确的接口,消费者只需要关心接口即可;

独立部署、升级、扩展和替换:每个服务都可以单独部署及重新部署而不影响整个系统。这使得服务很容易升级;

服务相互解耦;

轻量级通信:服务通信使用轻量级的通信协议,例如,同步的REST,异步的AMQP、STOMP、MQTT等。

这些使得微服......