【go语言微服务实践】#2-进化，变身成微服务

线上答题系统，微服务架构的小小实践，项目代码

一、系统架构

  将版本一的单应用版本分解为基于微服务架构的分模块版本，分为web应用模块，用户模块user、事件模块event、答题模块answer、题目模块problem、联合模块union6个模块。
  由原来的view、controller、model三层架构，变成view、controller、service、model四层。

• view维持原不变，与controller层通过REST API交互，这样可以方便的接受各种不同的前端访问。
• controller层基本也没有大的变动，只是由原来的直接调用model层，变为通过RPC调用service层提供的服务。
• service层则是将系统能提供的各个功能划分为事件服务event service、用户服务user service、问题服务problem service、答题服务answer service、联合服务union service等5个服务，对controller提供接口。每个服务service都是一个单独的应用，可以独立部署和运行，这样当某部分功能访问量增多时，可以灵活地增加该服务。保持对外提供的接口内容不变，单个服务也可以在不影响其他服务的情况下进行修改或增加新功能。service层则是直接调用mocel层进行数据库操作。
• model层也没有什么变化，就是封装相应表的操作给service层调用。这里还进行了一下划分，除了union service外，每个service是能操作特定的model。而一些操作，如联合查询participant和event_problem、problem给用户生成题目，则放在union中。
    这其实也是工作的一点经验，当系统十分的庞大复杂时，服务变多，各个服务能对外提供的能力就会非常多，因此常常还会将各个服务按模块划分，每个模块提供一类功能。模块与模块之间为了安全或便于管理，还会有网络隔离，或者禁止模块间调用。即将系统划分成了不同的模块，每个模块下的服务提供相似的一类功能，同一模块的服务只能操作特定的数据表，模块内的服务可以互相调用，而不可以跨模块调用其他模块的服务。所有需要跨模块提供的功能，都统一放在union service中。因此用户模块就是user service，事件模块event service，题目模块problem service，答题模块由participant service、credit service共同组成，union service提供跨模块服务的调用。
  技术选型
  前端：planeui+jquery
  controller层（页面逻辑处理）：beego
  service层：go-micro
  model层：beego的orm
  服务注册与发现：consul
  数据库：mysql
  其中前端与控制层基于ajax采用REST API进行通信，控制层和服务层采用gRPC+protobuf编码进行通信。

二、技术介绍

2.1 服务间通信

  在单体应用中，各个模块可以通过函数互相调用。而改成微服务后，各个service可以单独的部署在不同机器上，因此通信方式有所改变。每个service对外提供能被调用的API接口，web应用或其他服务再进行调用。服务间通信和调用涉及的的思维导图如上，实现这样的API有两个方面需要考虑，通信机制和媒体风格。服务间发送请求是要同步还是异步，发送请求的内容是基于文本传输还是二进制，这些都是根据具体场景选择相应的工具。
  Go 语言中常用的 API 风格是 RPC 和 REST API，常用的媒体类型是 JSON、XML 和 Pro