Micro 架构与设计
注： 原文作者即 Micro 框架的开发者。
过去几个月中，我们收到了很多关于 micro 的微服务架构和设计模式的问题。所以今天我们试着解释一下这两方面的问题。
关于 Micro
Micro 是一个微服务工具集。它被用来实现它的特性和接口，同时提供强大的可插拔的架构来保证基础组件可以被替换掉。
Micro 专注于解决构建微服务系统的基础需求。它采用了深思熟虑地富有预见性的方式来实现它的设计。
如果你想深入研究 Micro 工具集请点这里查看上一篇博客，或者如果你想学习微服务的基本概念请查看这里
在我们开始讨论 Micro 的架构之前，我们将快速的介绍一下 Micro 的特性.
工具集
Go Micro
Go Micro是一个用 GO 来写微服务的、可插拔的 RPC 框架。它提供了服务发现，客户端负载均衡，编码，同步异步通讯等功能的库。
Micro API
Micro API 是为访问微服务提供了 HTTP 服务和路由功能的 API 网管。在 Micro 中，它提供一个单一的入口，它可以被用作反向代理，或者将 HTTP 请求转换成 RPC.
Micro Web
Micro Web 是微型网络应用(micro web application)的仪表盘和反向代理。我们相信 web 应用应该被构建成微服务因此应被看做微服务世界的一等公民。它像一个 API 的反向代理但它同时提供对 web socket 的支持。
Micro Sidecar
Micro Sidecar 提供将 go-micro 用作 HTTP 服务的所有功能。Sidecar 提供使用其他语言写微服务应用的途径。
Micro CLI
Micro CLI 是和你的微服务们交互的命令行接口。它还可以让你在不想直接连接服务的时候使用 Sidecar 作为一个代理。
下面让我们更深入的了解。
RPC, REST, Proto...
你的第一个疑问可能就是，为什么是 RPC 而不是 REST? 我们认为 RPC 更适合内部服务通信的场景。或者更具体的， 使用 protobuf 编码并且用 protobuf IDL 定义 API 的 RPC。联合使用这些技术能够很方便的创建强定义的 API 接口和有效的消息编码。RPC 是非常直观的通信协议。
我们并不是这一信条的独立拥护者。
Google 是 protobuf 的创造者，在内部使用 RPC 并且最近开源的 RPC 框架 gRPC. Hailo 同样也是 RPC/Protobuf 的强烈倡导者，并从中受益匪浅，更有趣的是在跨团队协助方面获得的收益比系统性能上的收益更多。Uber 正则开发资金的 PRC 框架协议 TChannel。
我个人认为未来的 API 应该是使用 RPC 构建的，因为它有诸如 protobuf 这类的有良好的结构化的格式，有易用高效的编码方法的协议，从而能构建强定义的 API 和高效的通讯。
HTTP 到 RPC, API...
然而在现实中，在 web 上使用 RPC 还有很长的路要走。尽管在数据中心内部使用 RPC 很完美，但是支撑高并发的网站和移动 API 又是另一回事。好吧，完全从 HTTP 切换到 RPC 来由很长的路要走。这也是为什么 micro 提供了 API 网关组件，来支撑和转换 HTTP 请求。
API gateway 是微服务架构中使用的一种模式。它是微服务和外界沟通的唯一入口，它根据 HTTP 请求调用对应的服务。API gateway 使一个 HTTP API 能够组合调用多个不同的微服务。
这是一个很强大的模式。因 API 一部分的更改导致整个单一部署的服务挂掉的日子将一去不复返。
微服务 API 使用 路径-服务 的解决方案，因此每个请求路径能够调用不同的微服务 API，例如 /user => user api， /order => order api
举个例子，到 /customer/orders 的请求将被带着方法名 Customer.Orders 转发到 API go.micro.api.customer 。
你可能好奇， API 服务到底是什么。现在我们来讨论不同类型的服务。
微服务的类型
微服务的概念主要是按关注点分离 -- 从著名的 unix 哲学 doing one thing and doing it well 中借鉴了很多。出于这个原因，我们认为有必要从逻辑上和架构上将拥有不同任务的服务分离。
这些概念并不是什么新的概念，最近变得很引人注目是因为它被一些非常成功的技术公司证明是可行的。我们的目标是推广这些开发哲学并通过构建工具链来指导设计决策。
以下是我们定义的服务的类型。
API - 基于 micro api，API 服务在设施的最顶端，一般直接支撑你的移动或 web 应用。你可以使用 HTTP handler 建造它然后使用反向代理模式启动 micro api，或者，默认情况下处理这种专门格式的 RPC API 请求和响应。
Web - 基于 micro web， 专门用来提供 html 内容和管理面板访问的 Web 服务。micro web 为 HTTP 和 WebSockets 提供反向代理。目前，仅支持这两周格式，未来可能会支持更多的格式。就像之前提到过的那样，我们相信 “web 应用即微服务”。
SRV - 基于 RPC 的后端服务。它们主要关注于为你的系统提供核心功能并且大多数情况下不会对外开放。如果你愿意，你仍可以使用 micro api 或 micro web 使用 /rpc 路径来访问它，但一般使用 go-micro 客户端来直接调用它们。
基于以往的经验，我们发现这种架构模式及其强大并且见到过使用它支撑数百个微服务的系统。
Namespacing（命名空间）
你可能会好奇，如何隔断 micro api 和 micro web 之间的通信？我们使用逻辑命名空间里做分离。通过给服务名加前缀(prefix)我们清晰的确定它的意图以及它在系统中的位置。这个简单但有效的模式让我们受益良多。
micro api 和 micro web 将组成由命名空间和请求路径的第一个路径组成的服务名称。例如，访问 api/customer 的请求变为 go.micro.api.customer。
默认的命名空间为：
- API - go.micro.api
- Web - go.micro.web
- SRV - go.micro.srv
你应该为你自己的域名设定这些命名空间： com.example.{api, web, srv}。micro api 和 micro web 能够配置成在运行时路由到你的命名空间。
同步和异步
我们经常听到微服务和响应式模式一同出现。对于大多数来说，微服务是创建事件驱动的架构，并且主要通过异步通信的服务。
Micro 将异步通信作为一等公民对待并且将其构建成为微服务的基础组成部分之一。通过与事件异步通信的方式允许任何人消费这些事件，并针对这些事件执行自己的任务。可以在此基础上新的单独部署的服务而不需要需改他们的其他任何方面。这是一个强大的设计模式并且正由于此我们在 go-micro 中实现了一个异步的 broker 接口。
在 Micro 中，同步和异步通信被放到隔离的需求中。Transport 接口用来创建服务间点对点的连接。构建在 transport 基础上的 go-micro 客户端和服务器能够提供请求-响应模式的 RPC 调用，也可以提供双向流模式下的调用。
在构建系统时两种通信模型都应该被使用，但关键是要理解什么时候，在哪儿用哪种方式更合适。很多