当初基于SpringCloud的微服务开发日益风行，网上各种开源我的项目层出不穷。咱们在理论工作中能够参考开源我的项目实现很多开箱即用的性能，然而必须要恪守肯定的约定和标准。
本文联合咱们理论的开发中遇到的一些问题整顿出了一份微服务开发的实际标准，欢送各位大佬拍砖指导。
Maven标准
-
所有我的项目必须要有一个对立的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-serviceaccount-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
代码实现：
- 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，一位三流城市三流公司的三流架构师，如果你喜爱此文，请点赞转发反对一下，谢谢！
当然咯，也心愿各位能动动小指头，关注一下我的公众号！
发表回复