go 语言微服务实践
简介
近一两年来，微服务架构已经成为热门话题(microservices.io)，与传统的一体化应用架构相比，微服务架构在开发、测试、部署方面都有众多吸引人之处，越来越多没有历史包袱的新项目都启用微服务架构的模式来开发。
我们这个团队经过深入思考之后，决定在一起美这个APP的后端开发中，选择go作为开发语言，采用微服务模式来实现，经过近半年的实践，形成了一些心得，简单总结后分享出来，希望能够给大家一些帮助。
框架选择
不同的团队在选择基础框架(库)时考虑的要素不同，我们团队更喜欢小而美的框架，尽可能不要让框架侵入业务，易于升级、维护和替换，所以我们更愿意选择Library而不是Framework。
在web方面，我们选择了negroni作为middleware库，采用性能不错的httprouter替换go标准库的mux，而没有用任何web相关的框架。
在微服务之间的rpc调用方面，为了将来的扩展性、跨语言调用等因素，我们没有直接用go标准库的rpc模块，而是采纳了google最新推出的grpc。但grpc本身属于比较重型的rpc框架，对业务代码有一定的侵入性，我们做了一系列的库(包括worpc、worc、wonaming等)来屏蔽这些不必要的业务代码侵入，保持了业务代码本身的整洁。
微服务划分
在微服务体系中，如何切分微服务也是一个重要的话题，在我们的实践中，我们遵循了如下一些原则：
- 逻辑独立、边界清晰的模块作为一个独立的微服务
- 每个table只由一个微服务操作(包括插入、读取、更改、删除等)
- table之间不引入外键约束，id字段全部采用uuid
- 将需要保持数据一致性的操作放在一个微服务中，避免跨服务带来的数据一致性难题
- 微服务之间的通信，尽可能采用消息队列实现松耦合，当需要同步调用时再借助于rpc
- 微服务独立部署，通过etcd实现服务的注册与发现
总体架构
Gateway
Gateway是微服务对外提供服务的一个屏障，它的核心点在于：
- 屏蔽微服务之间通过消息队列、rpc等通信方式，为Web页面和移动APP提供基于HTTP协议的RESTful API接口
- 对每一个http业务请求进行必要的鉴权和数据完整性、合法性检查，以减少微服务的负担，让微服务的代码更纯粹
- 微服务部署体系中，每个微服务可能会部署多个实例，Gateway还承担着在这些实例中进行负载均衡的功能
- 进行必要的日志输出、监控打点等功能，对每一个来自于APP和页面的http请求，生成一个唯一的trace id，并将trace id传导到每一个后续的微服务中，以便后续的查错和性能调优
- Gateway的每一个http请求都是无状态的，采用JWT(Json Web Token)机制实现一个客户端的请求状态信息的传递
服务的注册与发现wonaming
微服务体系中，服务的注册和发现对整体架构非常重要，尤其对于同步的rpc调用，每个服务有多少实例，每个实例的地址等，都需要有一个统一的管理。我们采用etcd保存服务信息，同时封装了wonaming作为微服务注册和发现的中间件，它的主要功能包括：
- 服务在启动时，调用wonaming向etcd注册包含TTL的服务“索引”、
- 注册后，服务与etcd保持定时心跳，当微服务主动退出或超时，服务解注册并“下线”
- 在Gateway中，通过resolver进行服务发现，配合grpc提供的balancer实现负载均衡，resolver启动后会对etcd中的 /wonaming 目录进行监控，当有服务注册或者解注册时，动态维护可用服务清单。
r := wonaming.NewResolver(name) b := grpc.RoundRobin(r) conn, err := grpc.Dial(etcd, grpc.WithInsecure(), grpc.WithBalancer(b))服务的rpc调用worc
grpc是一个比较重的rpc框架，当客户端通过grpc调用服务端时，需要大量的重复性代码来建立连接、调用、处理错误返回等，影响业务代码的整洁性，并且对业务代码具有很强的侵入性，为了规避这个问题，我们封装了worc，以实现便捷的grpc调用：
resp, err := worc.CallRPC(ctx,"hello
