go微服务框架go-micro深度学习（⼀）整体架构介绍产品嘴⾥的⼀个⼩项⽬，从⽴项到开发上线，随着时间和需求的不断激增，会越来越复杂，变成⼀个⼤项⽬，如果前期项⽬架构没设计
的不好，代码会越来越臃肿，难以维护，后期的每次产品迭代上线都会牵⼀发⽽动全⾝。项⽬微服务化，松耦合模块间的关系，是⼀个很好的选择，随然增加了维护成本，但是还是很值得的。
微服务化项⽬除了稳定性我个⼈还⽐较关⼼的⼏个问题：
⼀: 服务间数据传输的效率和安全性。
⼆: 服务的动态扩充，也就是服务的注册和发现，服务集化。
三: 微服务功能的可订制化，因为并不是所有的功能都会很符合你的需求，难免需要根据⾃⼰的需要⼆次开发⼀些功能。
go-micro是go语⾔下的⼀个很好的rpc微服务框架，功能很完善，⽽且我关⼼的⼏个问题也解决的很好：
⼀：服务间传输格式为protobuf，效率上没的说，⾮常的快，也很安全。
⼆：go-micro的服务注册和发现是多种多样的。我个⼈⽐较喜欢etcdv3的服务服务发现和注册。
三：主要的功能都有相应的接⼝，只要实现相应的接⼝，就可以根据⾃⼰的需要订制插件。
业余时间把go-micro的源码系统地读了⼀遍，越读越感觉这个框架写的好，从中也学到了很多东西。就想整理⼀系列的帖⼦，把学习go-micro的⼼得和⼤家分享。
通信流程
go-micro的通信流程⼤⾄如下
Server监听客户端的调⽤，和Brocker推送过来的信息进⾏处理。并且Server端需要向Register注册⾃⼰的存在或消亡，这样Client才能知道⾃⼰的状态。
Register服务的注册的发现。
Client端从Register中得到Server的信息，然后每次调⽤都根据算法选择⼀个的Server进⾏通信，当然通信是要经过编码/解码，选择传输协议等⼀系列过程的。
如果有需要通知所有的Server端可以使⽤Brocker进⾏信息的推送。
Brocker 信息队列进⾏信息的接收和发布。
go-micro之所以可以⾼度订制和他的框架结构是分不开的，go-micro由8个关键的interface组成，每⼀个interface都可以根据⾃⼰的需求重新实现，这8个主要的inteface也构成了go-micro的框架结构。
这些接⼝go-micir都有他⾃⼰默认的实现⽅式，还有⼀个go-plugins是对这些接⼝实现的可替换项。你也可以根据需求实现⾃⼰的插件。
这篇帖⼦主要是给⼤家介绍go-micro的主体结构和这些接⼝的功能，具体细节以后的⽂章我们再慢慢说：
Transort
服务之间通信的接⼝。也就是服务发送和接收的最终实现⽅式，是由这些接⼝定制的。
源码：
type Socket interface {
Recv(*Message) error
Send(*Message) error
Close() error
}
nodeselectortype Client interface {
Socket
}
type Listener interface {
Addr() string
Close() error
Accept(func(Socket)) error
}
type Transport interface {
Dial(addr string, opts ...DialOption) (Client, error)
Listen(addr string, opts ...ListenOption) (Listener, error)
String() string
}
Transport 的Listen⽅法是⼀般是Server端进⾏调⽤的，他监听⼀个端⼝，等待客户端调⽤。
Transport 的Dial就是客户端进⾏连接服务的⽅法。他返回⼀个Client接⼝，这个接⼝返回⼀个Client接⼝，这个Client嵌⼊了Socket接⼝，这个接⼝的⽅法就是具体发送和接收通信的信息。
http传输是go-micro默认的同步通信机制。当然还有很多其他的插件：grpc,nats,tcp,udp,rabbitmq,nats，都是⽬前已经实现了的⽅式。在go-plugins⾥你都可以到。
Codec
有了传输⽅式，下⾯要解决的就是传输编码和解码问题，go-micro有很多种编码解码⽅式，默认的实现⽅式是protobuf，当然也有其他的实现⽅式，json、protobuf、jsonrpc、mercury等等。
源码
type Codec interface {
ReadHeader(*Message, MessageType) error
ReadBody(interface{}) error
Write(*Message, interface{}) error
Close() error
String() string
}
type Message struct {
Id    uint64
Type  MessageType
Target string
Method string
Error  string
Header map[string]string
}
Codec接⼝的Write⽅法就是编码过程，两个Read是解码过程。
Registry
服务的注册和发现，⽬前实现的consul,mdns, etcd,etcdv3,zookeeper,kubernetes.等等，
type Registry interface {
Register(*Service, ...RegisterOption) error
Deregister(*Service) error
GetService(string) ([]*Service, error)
ListServices() ([]*Service, error)
Watch(...WatchOption) (Watcher, error)
String() string
Options() Options
}
简单来说，就是Service 进⾏Register，来进⾏注册，Client 使⽤watch⽅法进⾏监控，当有服务加⼊或者删除时这个⽅法会被触发，以提醒客户端更新Service信息。
默认的是服务注册和发现是consul，但是个⼈不推荐使⽤，因为你不能直接使⽤consul集
我个⼈⽐较喜欢etcdv3集。⼤家可以根据⾃⼰的喜好选择。
Selector
以Registry为基础，Selector 是客户端级别的负载均衡，当有客户端向服务发送请求时， selector根据不同的算法从Registery中的主机列表，得到可⽤的Service节点，进⾏通信。⽬前实现的有循环算法和随机算法，默认的是随机算法。
源码：
type Selector interface {
Init(opts ...Option) error
Options() Options
// Select returns a function which should return the next node
Select(service string, opts ...SelectOption) (Next, error)
// Mark sets the success/error against a node
Mark(service string, node *registry.Node, err error)
// Reset returns state back to zero for a service
Reset(service string)
// Close renders the selector unusable
Close() error
// Name of the selector
String() string
}
默认的是实现是本地缓存，当前实现的有blacklist,label,named等⽅式。
Broker
Broker是消息发布和订阅的接⼝。很简单的⼀个例⼦，因为服务的节点是不固定的，如果有需要修改所
有服务⾏为的需求，可以使服务订阅某个主题，当有信息发布时，所有的监听服务都会收到信息，根据你的需要做相应的⾏为。
源码
type Broker interface {
Options() Options
Address() string
Connect() error
Disconnect() error
Init(...Option) error
Publish(string, *Message, ...PublishOption) error
Subscribe(string, Handler, ...SubscribeOption) (Subscriber, error)
String() string
}
Broker默认的实现⽅式是http⽅式，但是这种⽅式不要在⽣产环境⽤。go-plugins⾥有很多成熟的消息队列实现⽅式，有kafka、nsq、rabbitmq、redis，等等。
Client
Client是请求服务的接⼝，他封装Transport和Codec进⾏rpc调⽤，也封装了Brocker进⾏信息的发布。
源码
type Client interface {
Init(...Option) error
Options() Options
NewMessage(topic string, msg interface{}, opts ...MessageOption) Message
NewRequest(service, method string, req interface{}, reqOpts ...RequestOption) Request
Call(ctx context.Context, req Request, rsp interface{}, opts ...CallOption) error
Stream(ctx context.Context, req Request, opts ...CallOption) (Stream, error)
Publish(ctx context.Context, msg Message, opts ...PublishOption) error
String() string
}
当然他也⽀持双⼯通信 Stream 这些具体的实现⽅式和使⽤⽅式，以后会详细解说。
默认的是rpc实现⽅式，他还有grpc和http⽅式，在go-plugins⾥可以到
Server
Server看名字⼤家也知道是做什么的了。监听等待rpc请求。监听broker的订阅信息，等待信息队列的推送等。
源码
type Server interface {
Options() Options
Init(...Option) error
Handle(Handler) error
NewHandler(interface{}, ...HandlerOption) Handler
NewSubscriber(string, interface{}, ...SubscriberOption) Subscriber
Subscribe(Subscriber) error
Register() error
Deregister() error
Start() error
Stop() error
String() string
}
默认的是rpc实现⽅式，他还有grpc和http⽅式，在go-plugins⾥可以到
Service
Service是Client和Server的封装，他包含了⼀系列的⽅法使⽤初始值去初始化Service和Client，使我们可以很简单的创建⼀个rpc服务。源码：
type Service interface {
Init(...Option)
Options() Options
Client() client.Client
Server() server.Server
Run() error
String() string
}
具体的细节，我以后的帖⼦会给⼤家⼀⼀展开，希望这篇帖⼦，可以帮助你对go-micro的整体框架有个初步了解

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。