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

具体的响应格式如下所示：

{ 
"code": 200, 
"message": "获取学生列表成功", 
"body": { 
"links": [ 
{ 
"rel": "self", 
"href": "http://localhost:8080/api/clou ... t%3D0{&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/clou ... ot%3B, 
"hreflang": null, 
"media": null, 
"title": null, 
"type": null, 
"deprecation": null 
} 
] 
} 
] 
} 
"errors": {} 
} 

服务接口的设计一定是围绕标准化的规则进行的，这样才能在后期减少因为接口变动导致不断出现的前后端联调问题。因为在实践中我们经常遇到格式不统一导致web要写不同的数据解析方式，从而造成大量重复的工作。

遗留问题

当然我们落地过程的选择也不一定尽善尽美，也有很多随着业务处理能力的加强而在之前没有考虑到的问题，例如：

• 各个服务自身并发数据支撑能力
• 服务交互的内部代码瓶颈，包括调用链路冗余，，响应偏慢等
• 数据库的并发支撑与性能优化
• 与容器服务集成的参数配置，开发与部署环境的转变
• 调用链路可能出现的回环问题，交叉的业务单元调用，导致调用链路混乱
• 数据的缓存设计，加快业务响应速率

这些问题我们在后续不断深入地理解和探索中会找到相应的解决方案，大家可以在后续继续关注我们的微服务解决方案。

（编辑：网站开发网_马鞍山站长网）

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