微服务架构跨库分页解决的四种方案

微服务架构是一项在云中部署应用和服务的新技术。大部分围绕微服务的争论都集中在容器或其他技术是否能很好的实施微服务，而红帽说API应该是重点。

微服务可以在“自己的程序”中运行，并通过“轻量级设备与HTTP型API进行沟通”。关键在于该服务可以在自己的程序中运行。通过这一点我们就可以将服务公开与微服务架构（在现有系统中分布一个API）区分开来。在服务公开中，许多服务都可以被内部独立进程所限制。如果其中任何一个服务需要增加某种功能，那么就必须缩小进程范围。在微服务架构中，只需要在特定的某种服务中增加所需功能，而不影响整体进程。

微服务架构跨库分页解决的四种方案

一、需求缘起

分页需求

互联网很多业务都有分页拉取数据的需求，例如：

（1）微信消息过多时，拉取第N页消息

（2）京东下单过多时，拉取第N页订单

（3）浏览58同城，查看第N页帖子

这些业务场景对应的消息表，订单表，帖子表分页拉取需求有这样一些特点：

（1）有一个业务主键id, 例如msg_id,order_id,tiezi_id

（2）分页排序是按照非业务主键id来排序的，业务中经常按照时间time来排序order by

在数据量不大时，可以通过在排序字段time上建立索引，利用SQL提供的offset/limit功能就能满足分页查询需求：

select * from t_msg order by time offset 200 limit 100