Spring 必会之微服务篇(2)
经过上一篇文章的介绍,应该对微服务有了基本的认识,以及为什么要用微服务和微服务要面临的挑战和对应的解决问题,这一期继续聊聊关于微服务的相关知识。
服务拆分
为什么拆
对于大多数的小型项目来说,一般是先采用单体架构,但是随着后面的用户规模变大,业务越来越复杂,维护成本变高,我们要逐渐拆分为微服务架构。但是在拆分的过程中可能会遇到很多代码的耦合问题,所以我们需要明确一个单体架构的项目如何一步步拆分为微服务项目,以及要遵循哪些原则;
拆分思想
“高内聚,低耦合”一直是项目开发的规范,拆分微服务的时候同样要按照这个原则来:
- 高内聚:每个微服务的职责要尽量单一,包含的业务相关的互联度和完整度要高。
- 低耦合:每个微服务的功能要相对独立,尽量减少对其他服务的依赖,或者依赖接口的稳定性要强。
“高内聚”首先是单一职责,但不能说一个微服务就只有一个接口,而是要保证微服务内部业务的完整性为前提。目标是当我们要修改某个业务的时候,最好只修改当前微服务,这样变更的成本就更低。一旦微服务做到了高内聚,那么之间的耦合度自然就降低了;
拆分方法
对于拆分的方式我们可以通过横向拆分和纵向拆分两种方式:
- 纵向拆分:按照代码的功能模块进行拆分为一个个服务,这种拆分模式可以尽可能的提高服务的内聚性;
- 横向拆分:看各个功能模块之间有没有公共的部分,如果有的话就抽取出来作为通用服务。这样可以提高业务的复用性,避免重复开发,同时通用业务一般接口的稳定性也很强,也不会使得服务之间过分耦合;
服务注册和发现
当服务拆分之后,不可避免的会出现跨微服务的业务,比如某个服务业务中需要实现的逻辑在另一个服务才实现,此时微服务之间就需要进行远程调用(RPC),而远程调用对本质就是访问对应接口的 URL 发起请求然后获取响应,我们可以通过基于 Http 协议和 Dubbo 协议的方式实现 RPC,大部分情况下使用的是 Http 的方式,这种方式不关心服务提供者的具体技术实现,只要对外暴露 Http 接口就行了,更符合微服务的需要;
在 Java 中发送 Http 请求可以使用 Spring 提供的 RestTemplate ,使用的时候我们需要先注册 RestTemplate 到 Spring 容器中,然后再调用其 API 发起请求,以下是常见方法:
- g