文章

透过go-micro来看微服务构架

2018-06-27 | 1 minute read |标签 go-micro micro-service |分类 开发 架构

透过go-micro看微服务架构构架

微服务到底是啥?

最近和同事讨论到微服务,发现一个问题,很多人将多实例部署也看做微服务,这样的误解不在少数,微服务到底是怎么样的一种存在?下面是我在网上找一个定义

微服务就是微小紧凑的服务, 提供统一简捷的 API 供外部访问, 实现一组独立的功能.

我觉得微服务要具有一下特征

1.服务与服务之间按照通用协议(比如RPC,restful)靠网络连接,而不是代码连接

2.服务与服务之间靠统一管理协调服务调用。

3.服务的划分按照功能划分,业务组合(业务编排)靠API-gateway

4.最佳的微服务每个数据库都是分离的,不同微服务数据库之间不存在关联关系,数据组合由api-gateway编排。

5.每个服务容易被替换,而且当期中一个微服务出现问题,不会影响到与该微服务无关服务正常运行。

6.与编程语言无关,每个微服务可以自主选择适合自己的语言开发,最后通过统一协议与其他服务器交互。

到这我们在回头看刚才提到的将多实例部署认为是微服务的误区,很自然多实例不满足以上每条特征

构建一个微服务架构需要哪些基础组件

我们谈论了微服务特征,那为了满足这些特征,我们需要哪些基础组件

1.通用协议

现在用的最多是rpc和restfull,RPC可能很多人不太了解,下面是我在wiki找到的介绍

远程过程调用(英语:Remote Procedure Call,缩写为 RPC)是一个计算机通信协议。该协议允许运行于一台计算机的程序调用另一台计算机的子程序,而程序员无需额外地为这个交互作用编程。如果涉及的软件采用面向对象编程,那么远程过程调用亦可称作远程调用远程方法调用

RPC当前最火当属于google公司的Grpc,它具有XML100倍性能,也比json快20倍左右并且支持多语言。

而restfull由于其通用易用性被现在各种web server,APP,web client 通用性最好,在一个微服务架构里面到底用哪种比较好呢,我觉得这两种不是互斥关系,而应该是互补关系,作为服务间的调用我们应该用RPC,而对外服务考虑通用性,选择restfull json

2.服务管理维护

一个服务上线,下线,异常,将会影响到api-gateway和其他服务的调用,管理服务状态的自然非常重要,现在市面上比较常用的有zookeeper,etcd,consule,作为一个golanger 我很自然选了etcd

3.消息总线

在一些业务无关,也不关心结果的服务,我们可以使用消息总线,这方面也特别多,kafka,rabbitmq,Golang语言本身的channel加reids也很容易改造一个消息总线

4.api-gateway

在实践了api-gateway后,一个简单的gateway 可以由任何一个MVC框架或者http server改造得来,这里我自己是用gin