基于CSE的微服务工程实践-Native API先行

【摘要】本文介绍了先写Native API的实践经验，介绍了在Native API先行的情况下，如何由设计人员定义面向JAVA语言的SDK包。
Open API 采用Swagger进行描述，能够灵活的支持RPC风格和REST风格的接口定义，并且考虑了跨平台接口定义要求。使用Swagger进行接口开发代码，需要熟悉这个规范，并理解和代码逻辑之间的约束关系，对于一些初步接触的设计人员来讲，这个过程会比较痛苦。在不写Swagger的情况下，CSE推荐设计者可以先结合自己熟悉的开发语言，使用接口的方式定义RPC或者REST接口。本文以JAVA语言为例，描述设计者如何定义接口。

微服务架构下，所有微服务之间都通过暴露REST接口进行访问。从管理/设计者的视角，通常期望系统的边界清晰，规格可控，因此接口的开发是独立受控的。早期JAVA标准，比如JSR Validation API等，都通过API包的方式供实现者使用。借鉴这个思路，设计者在设计微服务的时候，也可以将微服务的接口在独立的jar包项目中提供，实现者应用这个jar包即可。

使用CSE设计公共的接口，建议设计者提供两个类：

· Service: 一个JAVA接口，这个接口可以由开发者实现。

· Endpoint: 接口的REST描述。

举个例子，Service定义了开发者如何实现这个服务，开发者可以看不到REST标签，不用思考和HTTP的映射关系。

public interface UserService {public SessionInfo login(String userName,String password);public SessionInfo getSession(String sessionId);public String ping(String message);
}

Endpoint定义这个服务对外暴露的REST接口，可以采用Spring MVC或者JAX RS两种方式进行描述。Endpoint是一个具体实现类，但是其实现逻辑，全部代理给Service的实现。

@RestSchema(schemaId = "user")
@RequestMapping(path = "/")
@SwaggerDefinition(info = @Info(description = "用户认证、会话等管理", title = "用户管理接口", version = "v1"), basePath = "/")
public class UserEndpoint {@Autowiredprivate UserService userService;@PostMapping(path = "/v1/user/login", produces = MediaType.APPLICATION_JSON_VALUE)@ApiOperation(value = "登录")public SessionInfo login(@RequestParam(name = "userName") String userName,@RequestParam(name = "password") String password) {return userService.login(userName, password);}@GetMapping(path = "/v1/user/session", produces = MediaType.APPLICATION_JSON_VALUE)@ApiOperation(value = "查询会话")public SessionInfo getSession(@RequestParam(name = "sessionId") String sessionId) {return userService.getSession(sessionId);}@GetMapping(path = "/v1/user/ping", produces = MediaType.APPLICATION_JSON_VALUE)@ApiOperation(value = "系统测试接口")public String ping(@RequestParam(name = "message") String message) {return userService.ping(message);}
}

porter例子展现了这个设计思路。

接口定义的一些注意事项和讨论

上诉方式是在实践中探索的一种比较好的接口组织形式，当然可以有其他各种形式。比较常见的辩论形式有直接定义Endpoint接口，所有的标签写到Endpoint上，开发者只需要实现Endpoint即可。这种形式看起来更加的简洁，但是CSE没有提供这种开发方式的支持，即REST的标签必须在实现类上，不能出现在实现类的父类或者实现接口上。CSE考虑过是否提供这种开发模式的支持，后面放弃了。主要的原因是因为JAVA在语言机制上，并没有提供annotation的继承机制（class的annotation可以通过@Inherited继承，但是Method没有）。当然通过反射遍历也是可以获取到父类的annotation的，把技术建立在一个不可靠的技术基础上，会带来大量的问题。当然放弃这种模式还有其他原因，关于是否共享Interface供服务实现者实现和客户端开发引用存在大量的争论，感兴趣的开发者可以搜索网络，查询这方面的设计讨论。

注意事项

由于@RestSchema也是一个bean，在所有微服务的接口定义都在一个common jar包里面时，要避免一个微服务加载所有的bean。所以需要把不同服务的定义放到不同的package里面，通过ComponentScan控制加载范围或者创建不同的jar包，完全不引用。

来源：华为云社区原创作者：liubao68

基于CSE的微服务工程实践-Native API先行相关推荐

基于CSE的微服务工程实践-多微服务框架演进
[摘要] 本文介绍了在微服务架构持续演进过程中,如何解决多种REST开发框架并存的问题.重点描述了网关在将请求转发给不同框架的微服务实例时,治理能力的差异:描述了CSE在提供第三方微服务访问方面的治理 ...
Kratos技术系列｜从Kratos设计看Go微服务工程实践
导读 github.com/go-kratos/kratos(以下简称Kratos)是一套轻量级 Go 微服务框架,致力于提供完整的微服务研发体验,整合相关框架及周边工具后,微服务治理相关部分可对整体 ...
SpringBoot集成gRPC微服务工程搭建实践
前言本文将使用Maven.gRPC.Protocol buffers.Docker.Envoy等工具构建一个简单微服务工程,笔者所使用的示例工程是以前写的一个Java后端工程,因为最近都在学习微服 ...
基于CSE的微服务架构实践-轻量级架构技术选型
[摘要] 本文在前一篇"基于CSE的微服务架构实践-基础架构"基础上,介绍了使用CSE进行轻量级架构的技术选型参考.文末提供了基于JWT的微服务认证鉴权方案. 轻量级架构模式下,可 ...
基于CSE的微服务架构实践-Spring Boot技术栈选型
[摘要] 本文在前一篇"基于CSE的微服务架构实践-基础架构"基础上,介绍了在Spring Boot中集成CSE的技术选型参考.本文介绍了Spring Boot集成CSE的基本原理 ...
基于CSE的微服务架构实践-Spring Cloud技术栈选型
[摘要] 本文介绍了CSE和Spring Cloud的关系,在技术选型上的差异.介绍了Spring Cloud用户使用Spring Cloud物理多租和进行CSE开发的两种策略. 当Spring Cl ...
微服务工程消费dubbo服务的配置
1. 应用场景微服务工程,按规范不做xml文件的配置,同时需要调用其他工程提供的dubbo服务 2. 接口引入方式 l Jar包引入方式通过maven pom文件,引入其他工程的api jar包. ...
Rest 微服务工程搭建03——工程重构
cloud-api-commons 的pom文件 <?xml version="1.0" encoding="UTF-8"?> <projec ...
Rest 微服务工程搭建02——微服务消费者订单Module模块 || @RequestBody 的重要作用
restTemplate的使用 https://docs.spring.io/spring-framework/docs/5.2.2.RELEASE/javadoc-api/org/springfra ...

基于CSE的微服务工程实践-Native API先行

基于CSE的微服务工程实践-Native API先行相关推荐

最新文章

热门文章