关于springboot:SpringCloud-微服务最佳开发实践

6次阅读

共计 3100 个字符，预计需要花费 8 分钟才能阅读完成。

当初基于 SpringCloud 的微服务开发日益风行，网上各种开源我的项目层出不穷。咱们在理论工作中能够参考开源我的项目实现很多开箱即用的性能，然而必须要恪守肯定的约定和标准。

本文联合咱们理论的开发中遇到的一些问题整顿出了一份微服务开发的实际标准，欢送各位大佬拍砖指导。

所有我的项目必须要有一个对立的 parent 模块

所有微服务工程都依赖这个 parent，parent 用于治理依赖版本，maven 仓库，jar 版本的对立降级保护

在 parent 上层能够有 core，starter，rate-limit 等自定义模块
core 外围包的作用：

以 POJO 模式约定各种开发标准；如 BaseEntity，对立入参，返参
各种二方、三方组件开箱即用 AutoConfig；
各种进步开发效率的帮忙类等 XXXUtil

留神：core 包所有依赖的 scope 必须是 provided，防止传递依赖，同时配合 Condition 注解按条件加载 Bean 如 @ConditionalOnClass(Ribbon.class)，@ConditionalOnBean(StringRedisTemplete.class)

starter 模块

如果你每个服务都须要依赖 10 几个 starter，能够建一个对立的 starter 模块帮他们对立依赖进来，治理依赖集，简化依赖
rate-limit 模块

用于搁置非通用的自开发组件
正确区分 Release 版本和 Snapshot 版本

阐明：如果是 Snapshot 版本，那么在mvn deploy 时会主动公布到 快照版本库 中，而应用 快照版本 的模块，在 不更改版本号 的状况下，间接编译打包时，Maven会 主动从镜像服务器上下载最新的快照版本。

如果是 Release 版本，那么在mvn deploy 时会主动公布到 正式版本库 中，而应用 正式版本 的模块，在 不更改版本号 的状况下，编译打包时如果本地曾经存在该版本的模块则 不会被动去镜像服务器上下载。

简而言之：

Release : 正式版，有 bug 不能再持续应用这个版本号

Snapshot：快照版，有 bug 能够持续应用同一版本号，能够主动降级，举荐应用

服务间通过引入 sdk 调用，服务消费者须要依赖生产者提供的 api，配合 snapshot 不便降级

account
    account-api
    account-service

account-api 模块中放生产方须要用到的货色，api 接口，vo，入参等 …

public interface AccountApi {...}

account-service 实现 account-api 提供的接口

@RestController
@Log4j2
@Api(tags = "用户接口")
@RequiredArgsConstructor(onConstructor = @__(@Autowired))
public class AccountController implements AccountApi {...}

消费者通过 feign 调用生产者，间接集成生产者提供的接口并解决熔断

@Component
@FeignClient(name = "account-service",fallbackFactory = AccountClientFallbackFactory.class)
public interface AccountClient extends AccountApi {...}

@Component
public class AccountClientFallbackFactory implements FallbackFactory<AccountClient> {

    @Override
    public AccountClient create(Throwable throwable) {AccountClientFallback accountClientFallback = new AccountClientFallback();
        accountClientFallback.setCause(throwable);
        return accountClientFallback;
    }

}

@Slf4j
public class AccountClientFallback implements AccountClient {
    @Setter
    private Throwable cause;

    @Override
    public ResultData<AccountDTO> getByCode(String accountCode) {log.error("查问失败, 接口异样" ,cause);
        AccountDTO account = new AccountDTO();
        account.setAccountCode("000");
        account.setAccountName("测试 Feign");
        return ResultData.success(account);
    }

}

一个 API 是一个开发者的 UI – 就像其余任何 UI 一样, 确保用户体验被认真的思考过是很重要的！

能够应用以下两种格局：

/ 版本 / 访问控制 / 域对象
/ 版本 / 访问控制 / 域对象 / 动作

域对象须要遵循以下几条束缚：

域对象用名词而非动词
间接应用域对象名应用 /ticket 而不是复数 /tickets
域对象关系表白最大不超过 2 层，如 /ticket/12/message
须要正确区分 GET PUT POST DELETE 申请办法
无奈用名词 + 申请办法表述的能够扩大为 / 域对象 / 动词如 POST /user/login

在网关层对接口进行访问控制，访问控制的规定分为：

pb – public 所有申请均可拜访

pt – protected 须要进行 token 认证通过前方可拜访

pv – private 无奈通过网关拜访，只能微服务外部调用

df – default 网关申请 token 认证，并且申请参数和返回后果进行加解密

版本：

以微服务为力度，整个服务进行降级

例如，一个微服务有如下 API

GET /v1/pb/user

POST /v1/pb/user

PUT /v1/pb/user

如果 POST /v1/pb/user 须要降级，则须要将整个微服务 /v1 降级到 /v2，同时保障版本兼容的 api 老版本能够持续拜访

GET /v2/pb/user 等价于 GET /v1/pb/user

POST /v1/pb/user 标记为已废除

POST /v2/pb/user

PUT /v2/pb/user 等价于 PUT /v1/pb/user

代码实现：

GET 形式 {version} 能够是任意值，v1,v2 均可，如：@GetMapping(“/{version}/pb/user”)
POST 办法强制应用 V1 , 并标记为已废除，然而仍可应用

@Deprecated
@PostMapping("/v1/pb/user")

POST {version}应是以后版本，只能是 v2

@PostMapping("/{version}/pb/user")

能够不承当微服务鉴权性能，由本人服务实现（简略服务能够间接在网关层鉴权）
网关鉴权与微服务鉴权的差别在我其余文章中有具体阐明，可参考此文：http://t.hk.uy/2c3
须要实现访问控制权限，联合上文的 Restful 标准，屏蔽/pv/** 等非凡申请
须要实现灰度公布性能
开发联调的时候须要将服务器流量导入到本地，联合 nacos 的元数据与申请头可实现服务实例的筛选。参考此文实现：http://t.hk.uy/2c6

飘渺 Jam，一位三流城市三流公司的三流架构师，如果你喜爱此文，请点赞转发反对一下，谢谢！

当然咯，也心愿各位能动动小指头，关注一下我的公众号！

正文完