搭个微服务（一）微服务初探

前言

好久没写博客了，最近主导了一个产品的后端设计。沉迷于微服务不可自拔呀（改BUG改的不可自拔：P）。准备写一个系列，用来记录这个产品从无到有的心路历程。也作为本菜鸟的一个笔记吧。
口水话不说了。进入正题。

为什么选择微服务

在《微服务架构》这本书中，作者已明确：微服务不是银弹。相反，它解决很多问题的同时，也会引入更多的问题。在近一年的实践中，微服务至少带来了这几个好处：

1. 方便分布式部署，集中优势资源给重要的功能
2. 解放思维，单一职责，方便开发和有序增加新功能
3. 方便测试
4. 对重要服务（比如微信转账）加以保护，更安全

微服务至少带来了以下几个坏处：
1. 更复杂的设计（容错，幂等）
2. 函数调用转为api调用的性能开销

一般来说，大型项目重构进行服务化是一个比较好的思路（比如后期把存储，消息等拆出来）。但是一开始就使用微服务的思想来设计项目，也不是什么问题，更早的享受它带来的优势岂不美哉。

选择的技术

本项目是一个新闻APP的后端，使用python3和go做为主打语言。这样能兼顾快速上线和性能。事实上，python3的性能并没有想象中那么差。6个进程handle近5000W/day的请求量轻轻松松。除了内存耗费多一点。
具体配置：
语言： python3，go
数据库:mysql
缓存：redis
使用python库：aiohttp,aioredis,aiomysql,sanic
使用go的库：github.com/go-sql-driver/mysql， github.com/gomodule/redigo/redis， github.com/gorilla/mux

sanic+aio库极大的提高了吞吐。不得不说是神器。喜欢python的同学一定要试试。

总则

要搭建微服务，一定要确立起规矩，否则必然陷入混乱。在搭建微服务的时候有几条简单的规则：
1. 同一张表，只能由一个微服务进行读写。其它服务必须通过该服务暴露的接口进行访问
2. 服务内部保持ACID，对外接口保证幂等
3. 所有服务采用同样的结构
4. 所有的服务都必须小到能在一周内重写

http还是rpc？

微服务间的相互调用，使用http还是RPC，这是个见仁见智的问题，在实践中，最后确定为服务间使用http调用，http相比rpc至少有以下几个好处：
1. 方便接口测试
2. 方便客户端和各服务间的相互兼容和对接（用过RPC的就知道，会被各协议版本和各种不同的通讯端搞蒙）
当然坏处只有一个：性能。但是很多情况下，性能的瓶颈不会因为没有用RPC。一切对非瓶颈的优化，都是幻觉。

要不要restful?

很多人觉得restful是一种比较落后的思想。但本项目的各接口最终采用的restful的设计。它至少有以下几个好处：
1. get,post,delete各司其职，同一个接口（资源）可以有多种功能
2. 以资源为视角，至少不用为接口想名字了。懒人必备。
3. 统一整洁就是美
在实践restful中，一定要转变思维，从资源出发。比如 /login 接口怎样变为restful接口？实质上，调用/login接口会改变并返回用户预留的token。所以这个接口的本质是 POST /user/token?pwd=xxx&id=xxx。

这些都是在实践中慢慢确立下来的一些经验，有了这些前题，就能开始撸起来了。