SpringCloud 微服务最佳开发实践
现在基于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)
3.starter模块
如果你每个服务都需要依赖10几个starter，可以建一个统一的starter模块帮他们统一依赖进来，管理依赖集，简化依赖
4.rate-limit模块
用于放置非通用的自开发组件
5.正确区分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);
}
}
restful设计规范
一个 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
代码实现：
1.get方式{version}可以是任意值，v1,v2均可，如：@getmapping("/{version}/pb/user")
2.post方法强制使用 v1 ,并标记为已废弃，但是仍可使用
@deprecated
@postmapping("/v1/pb/user")
3.post {version}应是当前版本，只能是v2
@postmapping("/{version}/pb/user")
网关
- 可以不承担微服务鉴权功能，由自己服务实现（简单服务可以直接在网关层鉴权）
- 网关鉴权与微服务鉴权的差异在我其他文章中有详细说明，可参考此文：
- 需要实现访问控制权限，结合上文的restful规范，屏蔽
/pv/**等特殊请求 - 需要实现灰度发布功能
开发联调的时候需要将服务器流量导入到本地，结合nacos的元数据与请求头可实现服务实例的筛选。参考此文实现：
到此这篇关于springcloud 微服务最佳开发实践的文章就介绍到这了,更多相关springcloud 微服务内容请搜索以前的文章或继续浏览下面的相关文章希望大家以后多多支持！