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