领导让我做个独立服务

好久不见，我是阿呆

如题，这季度要做的需求，是一个独立模块，但是由于项目越来越大，模块间的结构越来越复杂，不得不面临的一个问题就是服务拆分，当然，在拆分之前，新加的模块，最好还是直接做成一个独立的服务，这不，要把本季度的需求，单独做一个服务出来，因为这是项目的第一个独立服务，所以要考虑和准备不少东西，蛮有挑战性的，在这里总结下我对微服务浅陋的见解。

01

GATEWAY

网关路由

要想做一个独立的服务出来，首先需要解决的就是服务间的路由问题，因为当前只有一个服务，所有的API都指向这个服务，当有另外一个服务之后，就需要解决API层的路由问题。

比如说，当前的项目服务是ServiceA，服务域名是www.service.com，所有访问该服务的API都以/A开头，即http://www.service.com/A，这个时候加入一个ServiceB，所有的API都以/B开头，那么访问服务B的URL就是http://www.service.com/B，说起来很简单，但是服务器怎么知道/A就是ServiceA，/B是ServiceB呢，这时候就需要一个网关的角色，来做这个路由：

后续如果有ServiceC的话，直接在网关服务中配置对应的路由即可。

02

SERVICE-REGISTER

服务注册中心

有了路由之后，似乎还有另外一个问题，网关也是一个服务，那冥冥之中，网关去哪里能找ServiceA和ServiceB呢，所以需要有一个集中管理这些服务的地方，即服务注册中心，网关服务、ServiceA、ServiceB都向这个注册中心注册服务，这样这些服务都是一家人了，网关服务当然就能找到它的家人了：

后续如果有新的服务ServiceC，那只需将ServiceC也注册到注册中心即可。

03

COMMUNICATION

服务间通信

到这里，似乎一切都很完美了，吗？并没有，如果ServiceA和ServiceB之间想通信怎么办？似乎没有考虑到哦。

服务间的调用，是不可以走网关的，只能通过彼此的客户端调用，客户端调用有两种方式，一种是RestTemplate，一种是Feign，这两种方式就不展开讲了，知道有这么回事就行了（因为我也不会

）。

那么这样的话，这个图就变成了这个样子：

04

TECHNOLOGY

技术选型

基本的思路有了之后，就要选择具体的实现框架，对于网关，可以选择Zuul或者SpringCloud Gateway，我们的项目选择后者，对于注册中心，可以选择Eureka，或Consul，或Zookeeper，或者阿里的新型框架，Nacos，我们项目选择Nacos，服务调用就用Feign，就这么定了，谁说都不好使的那种。

05

Database

数据库表间解耦

既然拆分了服务出来，那么数据库表自然要解耦，不管分不分库出来，解耦是一定要做的，数据库层的解耦，体现在不改变原表结构的情况下，完成新表的设计，同时不能使用外键关联，尽管多几张关联表。

06

LAST

最后

最后，的最后，记录几点微服务拆分的规范：

微服务拆分规范

1、服务拆分最多三层，两次调用；

2、服务间仅仅单向调用，严禁循环调用；

3、将串行调用改为并行调用，或者异步调用；

4、接口应该实现幂等；

5、接口数据定义严禁内嵌、透传；

6、规范化工程名；