go micro 學習筆記 1：熟悉micro工具集和go-micro的體系架構

https://micro.mu/blog/2016/03/20/micro.html

https://micro.mu/blog/2016/04/18/micro-architecture.html

https://github.com/micro

1、Micro是一個專注于簡化分布式系統開發的微服務生態系統。

go-micro - A pluggable Go RPC framework for writing a microservice; service discovery, client/server rpc, pub/sub, etc.

go-plugins - Plugins for go-micro including etcd, kubernetes, nats, rabbitmq, grpc, etc.

micro - A microservice toolkit containing traditional entry points; API Gateway, CLI, Slack Bot, Sidecar and Web UI.

2、Where do I start?

Start with go-micro. The readme provides a sample microservice.

Learn more by reading the getting started guide or checkout the examples.

Use the micro toolkit to access microservices via the cli, web ui, slack or api gateway.

3、怎么使用micro

使用go-micro編寫一些services 

然后通過micro工具集訪問他們。（api、web、cli等）

實例：https://github.com/micro/examples/tree/master/greeter

4、使用etcd代替consul

如果您想使用etcd，導入插件并在二進制文件中設置命令行標志。

import (

        _ "github.com/micro/go-plugins/registry/etcd"

)

service --registry=etcd --registry_address=127.0.0.1:2379

5、哪里可以運行Micro

Micro is runtime agnostic. You can run it anywhere you like. On bare metal, on AWS, Google Cloud. On your favourite container orchestration system like Mesos or Kubernetes.

https://github.com/micro/kubernetes

6、API，Web和SRV服務有什么區別？

api.exp.com->micro api -> cunstomer api -> customer srv

web.exp.com->micro web -> cunstomer web -> customer srv

將api、web頁面和后端服務分離

API的服務由micro api提供，默認的命名空間是go.micro.api。 micro api符合API網關模式

https://github.com/micro/micro/tree/master/api

Web服務由micro web提供,默認名稱空間go.micro.web。 我們相信網絡應用程序作為微型服務世界中的一流公民，將微型服務的Web儀表板構建起來。 micro web是反向代理，并將基于路由到服務解析的HTTP請求轉發到適當的網絡應用程序。

https://github.com/micro/micro/tree/master/web

SRV服務基本上是標準的RPC服務，通常是您要編寫的服務。 我們通常稱之為RPC或后端服務，因為它們應該主要是后端架構的一部分，而不是面向公眾。 默認情況下，我們使用命名空間go.micro.srv作為這些，但您應該使用您的域com.example.srv。

7、Micro vs Go-Kit

Go-kit將自己描述為微服務的標準庫。像Go一樣，go-kit為您提供可用于構建應用程序的各種包。 Go-kit是您想要完全控制您如何定義服務的理想選擇。

Go-micro是微服務的可插拔RPC框架。 這是一個有意見的框架，其嘗試簡化分布式系統的通信方面，因此您可以專注于業務邏輯本身。 Go-micro是您想要快速開發和運行的好地方，同時擁有可插拔的功能，可以在沒有代碼更改的情況下切換基礎架構。

Micro是一個微服務工具包。 這就像一個微軟服務的瑞士×××，它搭載在微軟上，提供傳統的入口點，如http api網關，web ui，cli，slack bot等。Micro使用工具來指導您的架構中的問題的邏輯分離，推動您 為公共API創建一個API層的微服務器，并為web UI單獨創建一個WEB層的微服務器。

8、micro簡單介紹

工具集：

Go Micro：

是一個可插拔的RPC框架，用于在Go中編寫微服務。

它提供了用于服務發現，客戶端負載平衡，編碼，同步和異步通信的庫。

Micro API：

是一個API網關或代理，用于提供HTTP并將請求路由到適當的微服務。

它作為單個入口點，可以用作反向代理或將HTTP請求轉換為RPC。

它應該在基礎架構的邊緣運行。

WEB UI：

web版本的go-micro，微型Web應用程序的Web儀表板和反向代理。 我們認為網絡應用程序應該被構建為微服務，因此被視為微服務世界中的一流公民。 它的行為與API反向代理類似，但也包括對Web套接字的支持。

sidecar：

http api版本的go-micro，實現將非go的應用整合到微服務

提供go-micro作為HTTP服務的所有功能。 雖然我們喜歡Go，并相信構建微服務是一種偉大的語言，但您也可能希望使用其他語言，因此Sidecar提供了將其他應用程序集成到Micro世界中的一種方法。

Bot：

A Hubot style bot that sits inside your microservices platform and can be interacted with via Slack, HipChat, XMPP, etc

Micro CLI

go-micro的命令行版本

一個直接的命令行界面，可與您的微服務進行交互。 您可能不想直接連接到服務注冊表，它還允許您利用Sidecar作為代理。

8.0、go-micro（Go-micro是微服務的獨立RPC框架。 它是該工具包的核心）

默認插件

consul或多播DNS用于服務發現

隨機散列客戶端負載均衡

用于消息編碼的JSON-RPC和PROTO-RPC

用于通信的HTTP

broker（異步通信）

可插拔的異步 pub/sub 接口

為消息代理提供了異步 pub/sub 通信的接口

這是事件驅動架構和微服務的基本要求之一。

微服務是事件驅動的架構.

By default we use an inbox style point to point HTTP system to minimise the number of dependencies required to get started. 

implementations include nats, rabbitmq and http (for development) in go-plugins

transport（同步通信）

可插拔的同步的消息點對點傳送的接口，是服務之間的同步請求/響應通信的接口。 它類似于golang網絡包，但提供了更高級別的抽象，它允許我們切換通信機制，例如http，rabbitmq，websockets，NATS。 該傳輸還支持雙向流。 這對于客戶端推送到服務器是強大的

Current implementations are http, rabbitmq and nats

codec（消息編碼/解碼）

用于將消息在傳輸之前編解碼

這可能是json，protobuf，bson，msgpack等。

與大多數其他編×××不同的是，我們實際上也支持這里的RPC格式。 所以我們有JSON-RPC，PROTO-RPC，BSON-RPC等。它將編碼從客戶端/服務器分離，并提供了集成其他系統（如gRPC, Vanadium, etc等）的強大方法

registry（客戶端的服務發現）

可插拔的服務發現的庫。

將服務的名稱解析為地址，可以被consul, etcd, zookeeper, dns, gossip, etc支持

Current implementations are consul, etcd, memory and kubernetes. 

selector（節點過濾和負載平衡）

負載均衡。使用選擇器而不是注冊表registry

server（RPC服務器）

提供構建運行中微服務的接口

編寫服務的構建塊

可以命名您的服務，注冊請求處理程序，添加中間件等

該服務基于上述包，為服務請求提供統一的接口。 內置服務器是RPC系統。 在將來還有其他的實現。 服務器還允許您定義多個編×××來提供不同的編碼消息。

provides a way of serving RPC requests

client（RPC客戶端）

提供一種RPC查詢的方式

客戶端提供了一個接口來對服務進行請求

像服務器一樣，它建立在其他軟件包上，以提供一個統一的接口，通過使用注冊表的名稱查×××，使用選擇器進行負載平衡，使用代理使用傳輸和異步消息的同步請求。

provides retries, timeouts, use of context, etc

service

上述組件在micro的頂層組合成一個服務

綜述：broker transport codec registry selector作為go-micro的底層組件。

例如編寫api 服務：

server 基于上述的組件編寫如srv服務

client 基于上述的組件編寫客戶端來調用服務

而一對一對的server和client組合成了一個個的api service。

micro api來作為唯一入口解析請求來傳遞給對應的service，通過client訪問server

8.1、micro api

將RPC請求從一個服務轉到另一個服務是Go Micro非常容易實現的，但不是外部訪問的理想選擇。 

服務的實例可能會失敗，它們可能在其他地方重新安排，或者最終綁定到任何隨機端口。

API提供了一個單一的入口點來查詢微服務器，應該被用作外部訪問的網關。

micro api是微服務的API網關。 使用API網關模式為您的服務提供單個入口點。 micro api提供HTTP并動態路由到適當的后端服務。

micro api通過service的client來訪問server來實現訪問

8.1.1、/rpc

可以使用/ rpc端點通過RPC查詢各個服務:

curl \

-d "service=go.micro.srv.greeter" \

-d "method=Say.Hello" \

-d "request={\"name\": \"John\"}" \

http://localhost:8080/rpc

{"msg":"Hello John"}

8.1.2 api.Request

API可用于細分由個人微服務提供服務的網址。 這是API組合的強大方法。 這里API使用請求路徑的第一部分以及命名空間組件來確定將請求路由到的服務。 然后將HTTP請求轉換為api.Request并進行適當轉發。

在Micro我們使用創建API微服務的模式來服務邊緣的請求。 分離后端與前端服務的責任。

請求：

GET /greeter/say/hello?name=John

轉變成：

service: go.micro.api.greeter (default namespace go.micro.api is applied)

method: Say.Hello

request {

"method": "GET",

"path": "/greeter/say/hello",

"get": {

"name": "John"

}

}

api.Request和api.Response的結構：

syntax = "proto3";

message Pair {

optional string key = 1;

repeated string values = 2;

}

message Request {

optional string method = 1;   // GET, POST, etc

optional string path = 2;     // e.g /greeter/say/hello

map<string, Pair> header = 3; 

map<string, Pair> get = 4;    // The URI query params

map<string, Pair> post = 5;   // The post body params

optional string body = 6;     // raw request body; if not application/x-www-form-urlencoded

}

message Response {

optional int32 statusCode = 1;

map<string, Pair> header = 2;

optional string body = 3;

}

8.1.3、代理

API的請求處理的最終方法是反向代理。 如上所述，API使用請求路徑和命名空間組件來確定將請求路由到的服務。 通過提供反向代理和微服務請求路由，我們能夠支持REST，這是廣泛追捧的要求。

代理可以通過傳遞--api_handler = proxy標志來啟用。

8.2、micro web ui

Web UI提供了一個簡單的儀表板，用于觀察和與正在運行的系統進行交互。 不僅如此，它還提供了非常像API的反向代理。 我們的目標是使用“Web代理”來實現Web應用程序的開發，作為微服務。 再次，就像API一樣，請求路徑與命名空間一起使用，以確定將請求路由到的服務。 Web代理還支持Web套接字，因為我們看到實時是提供Web應用程序的核心部分。

8.3、micro CLI

CLI是一種命令行工具，可在運行環境中提供觀察，交互和管理服務的方法。 當前的功能集允許您檢查注冊表，檢查服務的基本運行狀況，并對服務本身執行查詢。

9、RPC，REST，Proto ...

所以你可能會想的第一件事是為什么RPC，為什么不REST？

我們相信，RPC是更為合適的跨業務通信選擇。

或者更具體地說RPC使用protobuf編碼和使用protobuf IDL定義的API。

這種組合允許在線上創建強定義的API接口和有效的消息編碼格式。 

RPC是一個直接的，沒有虛擬的通信協議。

Google是創建者protobuf，在內部使用RPC和最近開源的gRPC，一個RPC框架。 

Hailo也是RPC / Protobuf的強力倡導者，在跨系統開發方面比系統性能更受益匪淺。

Uber選擇自己的路徑已經開發了一個稱為TChannel的RPC框架協議。

就個人而言，我們認為未來的API將使用RPC構建，因為它們具有良好的結構化格式，

使用高效編碼協議的傾向，如使用強大定義的API和執行通信的組合的protobuf。

10、HTTP到RPC，API ...

實際上，我們距離RPC在網絡上還有很長的路要走。

雖然它在數據中心內部的完美內容，面向公眾的流量，如網站和移動API，是一個完整的方案。

讓我們面對它，在我們離開HTTP之前，這將是一段時間。

這是微軟包括API網關，服務和翻譯HTTP請求的原因之一。

API網關是用于微服務架構的模式。

它作為外部世界的單個入口點，并根據請求路由到適當的服務。

這允許HTTP API本身由不同的微服務組成。

這是一個強大的架構模式。在API的一部分單一更改可能會降低整個整體的日子已經過去了。

The micro API uses path-to-service resolution so that each unique request path can be served by a different API micro service 。

e.g. /user => user api, /order => order api.

Here’s an example. A request to /customer/orders will be sent to the API service go.micro.api.customer with method Customer.Orders.

11、服務類型

微服務的概念是關于分離問題，借鑒了一貫做好事情的unix理念。 部分原因我們認為需要在不同責任的服務之間建立邏輯和建筑分離。

現在我將承認，這些概念并不是什么新鮮事物，但是由于已經在非常大的成功的技術公司中被證明了這些概念，因此它們是令人信服的 我們的目標是傳播這些發展哲學，并通過工具指導設計決策。

所以這里是我們目前定義的服務類型。

11.1、API

由Micro API提供，API服務位于基礎架構的邊緣，

最有可能為公眾提供流量，以及移動或網絡應用。 

您可以使用HTTP處理程序構建它，并以反向代理模式運行micro api，

或者通過默認處理一個特定的RPC API請求響應格式，

可以在這里找到：https://github.com/micro/micro/blob/master/api/proto/api.proto

11.2、WEB

由micro web服務，Web服務專注于提供html內容和儀表板。 

micro web反向代理HTTP和WebSockets。 這些是目前唯一支持的協議，但將來可能會被擴展

如前所述we believe in web apps as microservices.

11.3、SRV

這些是后端的基于RPC的服務。 

它們主要側重于為您的系統提供核心功能，并且很有可能不會面臨公眾。 

如果您喜歡，還可以通過micro api或web使用/ rpc終端訪問它們，

但是更可能的是，API，Web和其他SRV服務使用go-micro client直接調用它們。

11.4、綜述

根據過去的經驗，我們發現這種類型的架構模式非常強大，可以看到它擴展到數百種服務。 通過將其構建到微架構中，我們認為它為微服務開發提供了良好的基礎。

11.5、命名空間

是什么阻止micro api 和 web services通信，micro web與api services通信。 我們使用邏輯命名空間分隔這些。 通過在服務名稱前面添加一個命名空間，我們清楚地確定它在系統中的目的和位置。 這是一個簡單但有效的模式，為我們服務。

micro api和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可以在運行時配置為路由到您的命名空間。

11.6、同步與異步

對許多人來說，微服務是關于創建事件驅動架構和設計主要通過異步通信進行交互的服務。

micro將異步通信視為一流的公民，是微服務的基礎。

通過異步消息傳遞事件可以讓任何人消費和采取行動。 

可以構建新的獨立服務，而無需對系統的其他方面進行任何修改。 

這是一個強大的設計模式，因此，我們將Broker界面包含在微軟中。

同步和異步通信在Micro中被單獨提出。

The Transport interface用于創建服務之間的點對點連接。 

The go-micro client and server構建在傳輸上以執行請求響應RPC并提供雙向流的能力

在建立系統時，應該使用這兩種通信模式，但是了解每個適當的時間和地點是關鍵。 在很多情況下，沒有對或錯，但是會做出一些權衡。

12、什么定義了微服務

我們涵蓋了Micro工具包為微服務提供的許多工具，

我們已經定義了服務類型（API，WEB，SRV），但實際上并沒有什么真正的微服務器。

我們的信念和我們建立的理念是，微服務是一種專注于單一類型的實體或域的應用程序，它通過強大的API來提供訪問。

版本也是微服務重要的組成部分。go-micro server創建時會定義name和version

13、安裝

13.1、安裝etcd

go get github.com/coreos/etcd

或者.

git clone https://github.com/coreos/etcd.git 放在/wz/gopath/src/github.com/coreos

cd etcd;./build;./bin/etcd

As an example. If you would like to use etcd, import the plugin and set the command line flags on your binary.

_ "github.com/micro/go-plugins/registry/etcdv3"

./main --registry=etcdv3 --registry_address=127.0.0.1:2379

在micro的main.go頁加上etcdv3，然后編譯安裝。

micro --registry=etcdv3 --registry_address=127.0.0.1:2379 api

13.2、go-micro

go get github.com/micro/go-micro

go get github.com/micro/protobuf/{proto,protoc-gen-go}

13.3、工具集

go get github.com/micro/micro

14、容錯

Rationale原理Solution解決方案Usage用法

14.1、心跳（刷新服務發現注冊的機制）

服務在啟動時注冊服務發現，關閉時注銷服務發現。但是意外死亡需要自動刪除的機制

Micro支持寄存器TTL和寄存器間隔的選項。

TTL指定服務注冊的時間，超過這個時間服務會被服務發現移除

interval讓服務在指定時間內重新注冊，保持TTL獲取的注冊時間是有效的。

用法：

micro toolkit：

micro --register_ttl=30 --register_interval=15 api

go-micro：

service := micro.NewService(

        micro.Name("com.example.srv.foo"),

        micro.RegisterTTL(time.Second*30),

        micro.RegisterInterval(time.Second*15),

)

14.2、負載均衡（負載均衡是一種擴展請求負載或維持高可用性的方式）

selector interface

Client side load balancing is built into the go-micro client. This is done automatically

14.3、Retries

The micro client includes a mechanism for retrying requests.

重試可以設置為客戶端的標志或選項。 它默認為1，這意味著1次嘗試請求。

通過標志更改

micro --client_retries=3

設置為選項

client.Init(

client.Retries(3),

)

14.4、Caching Discovery

發現緩存是服務發現信息的客戶端緩存

客戶端緩存是排除服務發現作為瓶頸和單點故障的一種方法

end、常見的缺失：

https://github.com/google/go-genproto

mv go-genproto genproto

https://github.com/golang/text

詳細內容請參考官方文檔：

https://micro.mu/docs/index.html