我们通过一个系列文章跟大家详细展示一个 go-zero 微服务实例，整个系列分十三篇文章，目录结构如下：
- go-zero 实战 - 服务划分与项目创建
- go-zero 实战 - User API Gateway
- go-zero 实战 - User Login
- go-zero 实战 - User Register
- go-zero 实战 - User Userinfo
- go-zero 实战 - Food API Gateway
- go-zero 实战 - Food Search
- go-zero 实战 - Food AddFood
- go-zero 实战 - Food DeleteFood
- go-zero 实战 - Food Foodlist
- go-zero 实战进阶 - rpc 服务
- go-zero 实战进阶 - 用户管理 rpc 服务
- go-zero 实战进阶 - 食材管理 rpc 服务
期望通过本系列文章带你在本地利用 go-zero 快速开发一个《食谱指南》系统，让你快速上手微服务。
概述
在本系列开头的文章 go-zero 实战 - 服务划分与项目创建 中我们曾提到，每个服务都可以再分为 api 服务和 rpc 服务。 api 服务对外，可提供给 App 调用。rpc 服务则是对内的，可提供给内部 api 服务或其他 rpc 服务调用。
如果我们把该项目《食谱指南》比作一家餐厅，api 服务相当于餐厅的服务员，服务员主要服务的对象是店里的食客，而 rpc 相当于餐厅厨师，理想中厨师主要面向的对象是服务员，一般不直接面对食客。
我们以前面介绍的 AddFood 接口为例，客户端发起该接口请求时，会将要请求的需求告知 api 服务，api 服务再将客户端需求告知 rpc 服务。rpc 服务处理好后将请求结果回传到 api 服务，最后由 api 服务将请求结果交给客户端。用餐厅的例子类比，即顾客通过服务员（类比 api 服务）点餐后，由服务员将菜单交给厨师（类比 rpc 服务），待厨师做好菜品后，再交给服务员，最后由服务员将做好的菜品端到食客餐桌上，形成一个闭环。
在前十篇内容我们搭建的接口都是基于 api 服务实现的，这就相当于是厨师直接面向的是顾客，虽然这样效率高出很多，但仅限于简单的场景。如果碰到顾客发现菜里有蚊虫等问题，直接让顾客去后厨找厨师理论的话，不但影响双方心情，也会影响其他顾客的上菜速度，对餐厅来说是个不好的影响。这时候就需要服务员出场了，她们会将顾客反馈的问题通知到厨师，再由厨师解决处理。虽然中间多了一道程序，但无论出现什么意外状况，餐厅都能保证井然有序的进行。
有了上面的描述，相信你对 rpc 服务有了一个初步的了解。接下来我们将在原来项目的基础上，加入 rpc 服务，让我们清楚了解到服务流程上处理的差异。为了不影响阅读的连贯性，在接下来的文章中会重复加入 api 服务的介绍，如想了解更详细的搭建流程，请查阅本系列之前的文章。
服务划分
用户管理服务（usermanage）
| api 服务 | 端口：8888 | rpc 服务 | 端口: 9999 |
|---|---|---|---|
| login | 用户登录接口 | login | 用户登录接口 |
| register | 用户注册接口 | register | 用户注册接口 |
| userinfo | 用户信息接口 | userinfo | 用户信息接口 |
食物管理服务（foodmanage）
| api 服务 | 端口：8889 | rpc 服务 | 端口：9998 |
|---|---|---|---|
| search | 食材搜索接口 | search | 食材搜索接口 |
| addfood | 新增食材接口 | addfood | 新增食材接口 |
| deletefood | 删除食材接口 | deletefood | 删除食材接口 |
| foodlist | 食材列表接口 | foodlist | 食材列表接口 |
创建 usermanage rpc，foodmanage rpc 目录
$ cd FoodGuides/service
$ mkdir -p usermanage/rpc
$ mkdir -p foodmanage/rpc
最终 FoodGuides 项目目录如下所示：
➜ FoodGuides：
$ tree
.
├── common # 通用库
├── service # 服务
│ ├── foodmanage
│ │ ├── api # food api 服务
│ │ ├── model # food 数据模型
│ │ └── rpc # food rpc 服务
│ └── usermanage
│ ├── api # user api 服务
│ ├── model # user 数据模型
│ └── rpc # user rpc 服务
└── go.mod
一些思考
微服务拆分并没有统一的标准，相同的业务在不同的公司很可能拆分方式会有所区别，用户规模、团队大小、组员能力等都会是考虑因素。但我们还是有一些基本原则可以遵循：
- 由粗到细，避免过度拆分，遵循渐进式演进的原则
- 不同服务之间应该是正交的，不要你中有我我中有你
- 避免环形依赖，服务依赖关系应该是有向无环图
- 避免不同服务之间共享同一个数据库
go-zero 也是一个渐进式微服务框架，你可以在业务早期使用单体来快速满足业务，当业务增长并有需要的时候，做最小的改动即可做到渐进式的服务拆分。
