|
这里给出我们的技术栈选型框架(仅限我们熟悉的内容)，暂时不涉及技术框架的对比说明。
- 服务开发框架：springboot，dubbo，grpc，ServiceMesh(基于ServiceMesh的开发服务框架)
- 分布式存储/注册中心：Zookeeper，Consul，Eureka，Etcd
- 服务网关：Kong，Openresty，Spring cloud Zuul，Spring cloud gateway
- 负载均衡：nginx，spring cloud Ribbon，haproxy，Kubernetes service
- 服务远程调用：Spring cloud feign
- 缓存服务：memchace，redis
- 数据库：mariadb，mysql
- 消息服务：RabbitMQ，NATS，Kafka
- 配置中心：spring cloud config，Apollo，Consul
- 事件机制：Cloud Event
- 服务编排：Conductor ，Kubernetes
- 服务治理：spring cloud，Dubbo，ServiceMesh
基于消息机制的分布式事务处理(遵循CAP或者BASE理论模型的实现)
- 业务运行工具：jvm，nginx或者其他可运行环境支撑
- 开发编译工具：Jenkins，maven，gitlab
- 接口文档：Swagger
- 部署工具：物理部署(jar包或者可运行的编译的二进制文件)虚拟化部署(虚拟镜像模板)容器化部署(Docker)
我们在落地的过程中，根据团队技术特点开发阶段重点选择了Spring Cloud中涵盖的技术栈。方便易用，能够快速入手。运行阶段选择具备服务编排能力的Kubernetes容器化运行环境，并且结合Devops工具链能够快速迭代部署。
服务接口设计
服务接口是对外展现业务逻辑的唯一入口，接口定义的规范与否也是微服务落地的关键指标之一，我们在实践的过程中参考了多个开源项目的接口设计，针对任何一个资源对象，整体分为几类场景：资源集合类操作，资源实体操作，异常处理，参数处理，统一数据返回，审计日志以及其他具体场景。
统一的接口请求与响应标准
其中业务单元绝大多数端口围绕着资源集合类、资源实体类进行操作，因此我们从restful接口规范出发，结合具体场景，规范了请求方式，请求url，请求参数，请求header，响应header，响应值等信息。
请求参数涵盖默认语义，包括：Get(获取信息)，Post(创建)，Put(全量修改)，Patch(部分修改)，Delete(删除)
以Students实体对象的新建为例，给出请求与响应标准。
URL
URL请求包括三部分：请求方式，统一前缀以及具体url，统一前缀具备一定含义的命名规则，包括api申明，供应商标识，版本说明等必要信息，例如：
Post /api/cloud/v1/students?exist={skip,replace}
请求header
- type
- aplication/json：用于single和bulk时，用来表示请求数据为json格式
- application/vnd.ms-excel：从excel格式的文件导入创建
- Accept
- aplication/json：接受json格式的响应数据
- Authorization
- Oauth2.0的access token(bearer token)
- Accept-Language(可选)
- 可接受的语言，国际化，en-US表示美国英语
请求数据格式+类型
- json格式：{items:[]}
- 请求创建students对象json(表达)：
- 请求(批量)创建student对象列表json(表达)
- 请求(批量)创建student信息excel文
响应header
- Content-Type
- aplication/json
- Content-Language(可选)
- 内容语言
- Last-Modified
- 数据最近一次修改的时间戳信息
响应值
- Success message：多种类型
- Error message：多种类型
- Exception：多种类型
统一异常处理
统一异常处理包括状态码以及状态码涵盖的异常信息，具体部分定义如下：
- 200/201+success message(含资源数量信息+uri信息)：创建成功，适用于数量不多(比如小于500)的创建操作，大于设定的值时进行异步处理，参加返回值202
- 202+success message with status uri：异步处理，返回进度查询资源uri(/api/vendor/v1/status/{id})
- 400+success+errors(含出错项index的错误列表)：批量创建时部分成功，返回成功信息和错误信息
- 401+exception{error_code+message}：缺乏认证信息
- 403+exception{error_code+message}：未授权访问，访问被拒绝
- 406+exception{ error_code+message}：不支持client要求的格式或语言时返回该信息(Not Acceptable)
- 415+exception{error_code+message}:请求中的文档格式不支持
- 422+exception{error_code+message}：不能处理的数据，比如json格式错误、文件内容项错误或会破坏业务规则
- 429+exception{ error_code+message}：太多请求，流控时使用
- 500+exception{error_code+message}：服务器内部错误
统一日志拦截
基于AOP模式拦截所有请求，在请求入站与出站的时候，做统一日志记录以及需要的其他非业务处理(例如鉴权)
统一的数据返回标准
我们参考Restful数据返回标准，封装我们自己的数据返回格式：code，message，body，error，统一的数据返回格式可以在接口层做统一的拦截处理。实现返回数据的标准化。
- code：返回状态码
- message：返回响应结果的语义解释
- body：响应的具体数据信息，包括metada信息，具体响应数据以及请求连接
- error：代表返回的错误信息
（编辑：晋中站长网）
【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!
|
