go-micro 到底是个啥?

go-micro 到底是个啥?这是很多初接触微服务的技术人员想要弄清楚的,但是大多数文章都只告诉你 go-micro 是一个微服务框架,国内大多数作者写出来的文章都只是 go-micro 官网上的示例代码,这样的代码还被随意转载。这让很多初接触微服务和 go-micro 有点摸不到头脑。本文试图说清楚这些事。

go-micro 的确是一个微服务框架,但是为什么我们会需要 go-micro 呢?本文不试图讲解微服务的大篇理论、以及为什么要使用微服务。这样的文章和理论互联网上已经很多了,我们先简要的说明下微服务到底是什么?

微服务就是将单体应用(所有功能揉在一起的应用)拆分成 N 个小型的应用(服务),每个应用只完成很小的一部分服务,拆分的粒度没有硬性标准,一般按照业务边界进行拆分,如订单服务、用户服务这样的垂直拆分。

微服务架构是一个相对复杂的架构,小型团队如果试图将业务系统微服务化简直是噩梦。为什么这么说呢?原本的单体应用所有的业务功能都在一块,比如用 spring、laravel 这样传统 web 框架开发一个小型电商应用,那么订单、用户、支付、商品、后台管理系统等都是在一套代码中,开发起来很方便,代码调用就是函数级别的调用,调用的开销很小,特别适合小团队开发迭代。

如果小团队一开始就试图微服务架构进行开发,是需要慎重考虑的,微服务的实施对架构能力和技术能力是要求比较高的,其次是微服务架构带来的复杂化,如服务间的通信、监控、日志收集、服务治理等都是需要考虑的因素。

什么时候采用微服务架构,以及单体应用如何演进成微服务架构不在本文的讨论范畴。

微服务架构带来的复杂性在哪里呢?如上所述,原本单体应用各个业务之间调用基本都是函数间的本地调用,开发成本和调用成本都很低。但是微服务架构下,各个微服务之间可能都不在一台服务器或不在一个机房内,如何进行调用呢?

比如有 user 和 order 两个服务,这 2 个服务不在一台服务器上,user 怎么调用 order 服务中订单查询功能呢?这就涉及到服务间的通信。

在 RESTful 架构中,我们可以通过 GET /api/user/:id/orders 进行获取数据,然后对数据进行解码(json、xml)等处理再返回给用户,如果是 POST 请求,传递的数据同样也是 json 或 xml 编码协议。

在微服务中,同样也可以通过 RESTful api 进行数据调用,但是服务间走 http 开销太大了,原因是 http 要传递的无用的元数据太多(header 等),再一个就是 http 协议本身比较慢。另外还有一个原因就是 xml 和 json 的编码解码速度效率不算高,编码后的字节较大。

这时候就要走 tcp/udp 协议了,那不能自己对数据进行编码解码这些麻烦的工作吧,所以有了 RPC 框架,比如dubbo、 grpc,rpc 框架可以让你在 A 服务器调用 B 服务器上的函数接口,这中间因为走了网络,所以是没有单体应用中本地函数调用效率高的,但是当业务上规模后,这点损耗是可以忽略的,比如订单查询需求非常大,那么可以部署 50个 order 服务来提供查询,可以进行负载均衡,可以弹性扩展等,这个时候微服务的效果就出来了。

这 50 个 order 服务怎么管理、怎么监控,怎么确定其中某一个是不是挂了?这里面涉及的概念就很多了,服务监控、服务发现、熔断机制等各类名词可能会让人头疼,但是因为服务进行了拆分,服务又分布在不同的位置,所以如果你自己解决这些问题会花费大量的时间和精力,这时候你就需要 go-micro ,go-micro 提供了各类组件,解决微服务架构中的不同问题,英语不好的可以看中文文档

go-micro 提供了微服务实施的基础框架、rpc、web、api 网关等各类工具,方便进行微服务的开发。

一个复杂的项目中,服务可能被拆分成为几十个,假如每个服务由5-7个小组成员进行研发和维护,那么需要上百人的研发团队才能后 hold 住,所以在这一点上小团队实施微服务的困难可想而知。

服务被拆分为几十个甚至上百个后如何进行管理呢?比如服务的伸缩、监控、部署怎么做,这时候可用 google 的 k8s 来进行服务治理,k8s 提供了微服务治理所需的全套工具。

转: https://zhuanlan.zhihu.com/p/58985155

tags: go,go-micro