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 提供了微服务治理所需的全套工具。