微服务落地，我们在考虑什么？

这里给出我们的技术栈选型框架(仅限我们熟悉的内容)，暂时不涉及技术框架的对比说明。

• 服务开发框架：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：代表返回的错误信息

（编辑：PHP编程网 - 黄冈站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!