SpringCloud微服务开发最佳实践规范,请查阅!

本文涉及的产品
访问控制,不限时长
简介: SpringCloud微服务开发最佳实践规范,请查阅!

大家好,我是飘渺Jam,一名来自三流城市三流公司的三流程序员,这是我们的第161篇原创文章,如果你喜欢我的文章请点赞转发支持一下。 


现在基于SpringCloud的微服务开发日益流行,网上各种开源项目层出不穷。我们在实际工作中可以参考开源项目实现很多开箱即用的功能,但是必须要遵守一定的约定和规范。


本文结合我们实际的开发中遇到的一些问题整理出了一份微服务开发的实践规范,欢迎各位大佬拍砖指点。


Maven规范


  1. 所有项目必须要有一个统一的parent模块
    所有微服务工程都依赖这个parent,parent用于管理依赖版本,maven仓库,jar版本的统一升级维护
    在parent下层可以有 core,starter,rate-limit 等自定义模块
  2. core 核心包的作用:
  • 以POJO形式约定各种开发规范;如BaseEntity,统一入参,返参
  • 各种二方、三方组件开箱即用AutoConfig;
  • 各种提高开发效率的帮助类等  XXXUtil

注意:core包所有依赖的scope必须是provided,避免传递依赖,同时配合Condition注解按条件加载Bean 如 @ConditionalOnClass(Ribbon.class),@ConditionalOnBean(StringRedisTemplete.class)

  1. starter模块
    如果你每个服务都需要依赖10几个starter,可以建一个统一的starter模块帮他们统一依赖进来,管理依赖集,简化依赖
  2. rate-limit模块
    用于放置非通用的自开发组件
  3. 正确区分Release版本 和 Snapshot版本

说明:如果是Snapshot版本,那么在mvn deploy时会自动发布到快照版本库中,而使用快照版本的模块,在不更改版本号的情况下,直接编译打包时,Maven自动从镜像服务器上下载最新的快照版本

如果是Release版本,那么在mvn deploy时会自动发布到正式版本库中,而使用正式版本的模块,在不更改版本号的情况下,编译打包时如果本地已经存在该版本的模块则不会主动去镜像服务器上下载

  1. 简而言之:
    Release : 正式版,有bug不能再继续使用这个版本号
    Snapshot:快照版,有bug可以继续使用同一版本号,可以自动升级,推荐使用


服务调用规范


  1. 服务间通过引入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 {
    ...
}


  1. 消费者通过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);
    }
}


Restful设计规范


一个 API 是一个开发者的 UI - 就像其他任何 UI 一样, 确保用户体验被认真的考虑过是很重要的!

restful接口可以使用以下两种格式:

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


域对象需要遵循以下几条约束:

  1. 域对象 用名词而非动词
  2. 直接使用域对象名  使用/ticket而不是复数/tickets
  3. 域对象关系表达   最大不超过2层,如/ticket/12/message
  4. 需要正确区分 GET PUT POST DELETE 请求方法
  5. 无法用名词 + 请求方法表述的可以扩展为 /域对象/动词  如 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

代码实现:

  1. GET方式{version}可以是任意值,v1,v2均可,如:@GetMapping("/{version}/pb/user")
  2. POST方法强制使用 V1 ,并标记为已废弃,但是仍可使用
@Deprecated
@PostMapping("/v1/pb/user")


  1. POST {version}应是当前版本,只能是v2
@PostMapping("/{version}/pb/user")



网关


  1. 可以不承担微服务鉴权功能,由自己服务实现(简单服务可以直接在网关层鉴权)
    网关鉴权与微服务鉴权的差异在我其他文章中有详细说明,可参考此文:微服务网关授权VS微服务授权
  2. 需要实现访问控制权限,结合上文的Restful规范,屏蔽 /pv/** 等特殊请求
  3. 需要实现灰度发布功能
    开发联调的时候需要将服务器流量导入到本地,结合nacos的元数据与请求头可实现服务实例的筛选。参考此文实现:SpringCloud 实现网关的灰度发布
相关实践学习
消息队列+Serverless+Tablestore:实现高弹性的电商订单系统
基于消息队列以及函数计算,快速部署一个高弹性的商品订单系统,能够应对抢购场景下的高并发情况。
云安全基础课 - 访问控制概述
课程大纲 课程目标和内容介绍视频时长 访问控制概述视频时长 身份标识和认证技术视频时长 授权机制视频时长 访问控制的常见攻击视频时长
目录
相关文章
|
11天前
|
JSON Java API
利用Spring Cloud Gateway Predicate优化微服务路由策略
Spring Cloud Gateway 的路由配置中,`predicates`​(断言)用于定义哪些请求应该匹配特定的路由规则。 断言是Gateway在进行路由时,根据具体的请求信息如请求路径、请求方法、请求参数等进行匹配的规则。当一个请求的信息符合断言设置的条件时,Gateway就会将该请求路由到对应的服务上。
112 69
利用Spring Cloud Gateway Predicate优化微服务路由策略
|
30天前
|
Java 开发者 微服务
从单体到微服务:如何借助 Spring Cloud 实现架构转型
**Spring Cloud** 是一套基于 Spring 框架的**微服务架构解决方案**,它提供了一系列的工具和组件,帮助开发者快速构建分布式系统,尤其是微服务架构。
160 69
从单体到微服务:如何借助 Spring Cloud 实现架构转型
|
27天前
|
Java Nacos Sentinel
Spring Cloud Alibaba:一站式微服务解决方案
Spring Cloud Alibaba(简称SCA) 是一个基于 Spring Cloud 构建的开源微服务框架,专为解决分布式系统中的服务治理、配置管理、服务发现、消息总线等问题而设计。
216 13
Spring Cloud Alibaba:一站式微服务解决方案
|
14天前
|
Java 关系型数据库 Nacos
微服务SpringCloud链路追踪之Micrometer+Zipkin
SpringCloud+Openfeign远程调用,并用Mircrometer+Zipkin进行链路追踪
134 20
|
3天前
|
Java 关系型数据库 数据库
微服务SpringCloud分布式事务之Seata
SpringCloud+SpringCloudAlibaba的Seata实现分布式事务,步骤超详细,附带视频教程
15 1
|
2月前
|
设计模式 Java API
微服务架构演变与架构设计深度解析
【11月更文挑战第14天】在当今的IT行业中,微服务架构已经成为构建大型、复杂系统的重要范式。本文将从微服务架构的背景、业务场景、功能点、底层原理、实战、设计模式等多个方面进行深度解析,并结合京东电商的案例,探讨微服务架构在实际应用中的实施与效果。
145 6
|
2月前
|
设计模式 Java API
微服务架构演变与架构设计深度解析
【11月更文挑战第14天】在当今的IT行业中,微服务架构已经成为构建大型、复杂系统的重要范式。本文将从微服务架构的背景、业务场景、功能点、底层原理、实战、设计模式等多个方面进行深度解析,并结合京东电商的案例,探讨微服务架构在实际应用中的实施与效果。
55 1
|
29天前
|
运维 监控 持续交付
微服务架构解析:跨越传统架构的技术革命
微服务架构(Microservices Architecture)是一种软件架构风格,它将一个大型的单体应用拆分为多个小而独立的服务,每个服务都可以独立开发、部署和扩展。
180 36
微服务架构解析:跨越传统架构的技术革命
|
4月前
|
安全 应用服务中间件 API
微服务分布式系统架构之zookeeper与dubbo-2
微服务分布式系统架构之zookeeper与dubbo-2
|
4月前
|
负载均衡 Java 应用服务中间件
微服务分布式系统架构之zookeeper与dubbor-1
微服务分布式系统架构之zookeeper与dubbor-1