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

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

• 服务开发框架：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表示美国英语

（编辑：西安站长网）

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