Kubernetes中文社区
当我们站在全局的角度，观看整理后的服务，发现了一个及其优美的图形化结构，各个节点的边界清晰，职责分明；节点间的链路畅通，协议规整。这时我们知道我们终于走在了正确的道路上。
服务网关：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）
以Students实体对象的新建为例，给出请求与响应标准。
application/vnd.ms-excel：从excel格式的文件导入创建
Accept
aplication/json：接受json格式的响应数据
Authorization
Oauth2.0的access token（bearer token）
Accept-Language（可选）
可接受的语言，国际化，en-US表示美国英语
请求（批量）创建student对象列表json（表达）
请求（批量）创建student信息excel文
Content-Language（可选）
内容语言
Last-Modified
数据最近一次修改的时间戳信息
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}：服务器内部错误
message：返回响应结果的语义解释
body：响应的具体数据信息，包括metada信息，具体响应数据以及请求连接
error：代表返回的错误信息
具体的响应格式如下所示：
{
“code”: 200,
“message”: “获取学生列表成功”,
“body”: {
“links”: [
{
“rel”: “self”,
“href”: “http://localhost:8080/api/cloud/v1/students?name=test&startDate=2019-01-01&endDate=2019-09-01&style=normal&sort=asc&limit=10&offset=0{&fields}”,
“hreflang”: null,
“media”: null,
“title”: null,
“type”: null,
“deprecation”: null
}
],
“metadata”: []
“content”: [
{
“id”: 1,
“name”: “test3”,
“status”: “running”,
“props”: “test”,
“remark”: “test”,
“ownerId”: 1,
“createrId”: 1,
“menderId”: 1,
“gmtCreate”: “2019-03-11 10:42:15”,
“gmtModify”: null,
“startDate”: null,
“endDate”: null,
“links”: [
{
“rel”: “self”,
“href”: “http://localhost:8080/api/cloud/v1/students/1?style=normal&fields=”,
“hreflang”: null,
“media”: null,
“title”: null,
“type”: null,
“deprecation”: null
}
]
}
]
}
“errors”: {}
}
- 各个服务自身并发数据支撑能力
- 服务交互的内部代码瓶颈，包括调用链路冗余，响应偏慢等
- 数据库的并发支撑与性能优化
- 与容器服务集成的参数配置，开发与部署环境的转变
- 调用链路可能出现的回环问题，交叉的业务单元调用，导致调用链路混乱
- 数据的缓存设计，加快业务响应速率
这些问题我们在后续不断深入地理解和探索中会找到相应的解决方案，大家可以在后续继续关注我们的微服务解决方案。
