截止到本文发布时，Go-Micro在github上的star数达到了10.8k，也已经累计发布了v1、v2、v3这三个大版本，目前前两个已经停止维护。
本文主要以最新的技术视角去看待这个框架，所以会集中目光在v3版本。本文包含大量个人的主观观点，请大家选择性听取，更欢迎与我讨论。
概览
Micro is a distributed cloud operating system built for real world programming.
Micro框架的定义里有个关键词：distributed cloud operating system - 分布式云操作系统。这是一个很重量级的定义，我们根据它的官方介绍了解，从这10个核心模块入手，理解这个框架的功能。
本人对这个框架研究不深，主要参考官方提供的资料，如果有认知偏差，欢迎大家多多指正~
Micro的十大核心模块
1. Auth 认证授权
认证授权是一个很基础的模块，但放在一个微服务的框架里，我个人认为不太合适。为什么呢？
- 大部分的微服务的Auth模块，往往是网关层的一种能力。也就是说，一般我们在请求入口处做一次Auth即可，接下来我们就认为消息可靠、无需检查；
- 如果Auth模块必须嵌入到每个服务，更应该采用Service Mesh的side-car模式。借用Istio的能力，尽可能不要侵入应用的代码；
- Auth会有很多方式，ACL/RBAC/ABAC，往往会和公司内部的系统强结合（如人员管理），抽象为一个组件很难满足通用性和扩展性；
所以，常规的微服务框架中，会有个专门的Auth服务，管理权限、认证等功能。
2.Build编译模块
编译功能放在微服务框架不合适，它更应该与CICD结合起来，交由专门的编译部署平台，实现快速交付。
3.Broker消息管道
从官方的介绍来看，Broker基本与MQ的功能一致，即发布和订阅消息。
作为跨服务异步通信的主流方式，MQ在中大型工程中被广泛使用，Broker概念的抽象可以让使用者不用过于关心底层具体采用的技术。
4.Config动态配置
Config定义为动态配置和密码，可类比为配置中心，或者K8s中的ConfigMap与Secret。这个模块的功能更多的是对配置能力的抽象。
5.Events事件流
事件流中有三个关键词：顺序、重放和持久化。这三个特性与MQ的特性基本一致，可以认为是Broker一个具体的实践。
这里抽象出一个事件流的概念，主要强调的是 可靠性。
6.Network网络
网络是计算机中很大的一块，这里特指服务内的网络隔离与路由。我个人认为个定义过于宽泛，很容易引起误解。
从云原生的划分来看，这块更应该放在Service Mesh部分。
7.Registry注册
服务注册这部分包括两块：
- 服务提供方把服务信息注册到中心节点
- 服务调用方从中心节点获取服务提供方的信息进行调用
这服务注册与发现的工作，K8s等这类Paas平台已经封装得很完善了；而如果公司没有提供Paas平台，也可以通过etcd等注册中心快速实现。这部分也不建议重复建设。
8.Runtime运行时
云时代以容器为核心构建服务，进程的声明周期就可以通过Pod快捷管理。官方对Runtime的描述，更像是CICD K8s调度服务的综合描述。
9.Store存储
官方定义为支持过期 CRUD的K-V存储，用来保证无状态性。
我们可以很直接地与Redis类比，相当于把有状态的数据放在公共的缓存里。
10.Plugins插件化
插件化的概念很宽，框架并没有明确说明。
从实现来说，任何一个组件最好都可以支持插件化，如router、存储、消息通知等，可以支持自定义log plugins。
模块总览
前面的十大模块有很多与云平台的基础功能重合。为了更具有针对性地讨论，我们先聊清楚前提，这样才能更聚焦于框架上。
前提
从当前主流与未来趋势来看，微服务框架应基于基础云平台能力，不应有过多的交集。基础平台能力主要包括两块：
- 整套Devops流程（如代码版本管理、编译、部署、运行）
- 基础的云Paas平台（以k8s为代表）
虽然对很多基础建设不完善的团队来说，上面两者的落地会有挑战，但从长远发展来看，不应将由基础平台的维护的功能交由微服务框架。 而如果追求短期内快速落地项目，我更建议这些团队借主流公有云服务的能力。
三大分类
- 不合适引入到微服务框架中：Build、Config、Runtime
- 通过Service Mesh实现：Auth、Network、Registry
- 微服务框架的关键特性：Broker、Events、Store、Plugins
思考
Micro框架提供了二进制工具micro，可以查看server、config、store等信息。虽然看起来使用起来很方便，但其实有诸多限制；比如说，线上环境的服务器，开发者往往没有权限登录。
从整体来说，Micro是一个限制性很大的框架，主要特点是：
- 适合基础平台不完善的团队，框架提供了很多基础平台的功能；
- 使用框架的初始成本低，但后续切换成本、排查问题成本极高，高度依赖micro的生态；
- Micro屏蔽了底层实现细节，虽然能在一定程度上提效，但遇到性能、扩展性、底层原理等问题时，很难解决。
小结
整体来说，我不建议以Micro作为新项目切入时的框架。如果用一个词概括原因，我会用 - 不够透明。一方面，Micro的门槛不低、需要了解它一整套特有的概念；另一方面，后续团队的维护成本也很高，对个人提升也很有限。
维护成本这个概念也许有的同学不能理解，我以Store为例（假设背后选用Redis作为存储）
- 如果采用Micro框架，我们必须阅读相关代码（重点是封装部分），了解它的封装与底层，结合micro redis工具排查
- 如果调用的是Redis的官方库，那只要保证调用方式正确，那就只需要你掌握Redis的原理即可
前者的排查链路需要框架 redis，后者只需要排查redis。我个人对编程语言框架有一个认知：不应过度屏蔽通用中间件的细节，如Redis、Kafka、MySQL等，往往直接在中间件查询问题，比通过框架查询问题更为高效。
参考资料
Github - https://github.com/micro/micro
文档 - https://micro.mu/introduction
