这是一个创建于 2008 天前的主题，其中的信息可能已经有所发展或是发生改变。
场景如下:
SpringCloud 全套, 数据库未分库,主从读写分离;
网关进来根据 api 进 微信微服务 手机 app 微服务, 后台微服务 等, 由这些微服务调用底层的 订单微服务 会员微服务等来完成业务逻辑或者组装数据;
现在后台微服务中的导出会员接口没有控制条数, 一下导出 30w+的会员数据(每个会员还要统计订单情况等), 导致会员微服务挂掉, 进而导致微信微服务无法获取会员信息,无法完成业务(业务要求可用性较高)
我的疑问是: 底层的订单微服务 会员微服务等 是否应该拆成两, 一个给业务使用, 一个给后台管理系统使用, 且部署分开. 现在比如会员微服务下 MemberController 里面就既有后台增删改查的 又有业务上比如支付时扣减用户余额的, 是否拆开好一点(再次强调:业务要求可用性较高!)?求解答, 谢谢!
SpringCloud 全套, 数据库未分库,主从读写分离;
网关进来根据 api 进 微信微服务 手机 app 微服务, 后台微服务 等, 由这些微服务调用底层的 订单微服务 会员微服务等来完成业务逻辑或者组装数据;
现在后台微服务中的导出会员接口没有控制条数, 一下导出 30w+的会员数据(每个会员还要统计订单情况等), 导致会员微服务挂掉, 进而导致微信微服务无法获取会员信息,无法完成业务(业务要求可用性较高)
我的疑问是: 底层的订单微服务 会员微服务等 是否应该拆成两, 一个给业务使用, 一个给后台管理系统使用, 且部署分开. 现在比如会员微服务下 MemberController 里面就既有后台增删改查的 又有业务上比如支付时扣减用户余额的, 是否拆开好一点(再次强调:业务要求可用性较高!)?求解答, 谢谢!
 | 1 snappyone 2020-06-01 20:17:47 +08:00 via Android 30 万分成每次 1000 条就好了 |
 | 2 matrix67 2020-06-01 20:18:47 +08:00 分页 |
 | 4 optional 2020-06-01 20:26:13 +08:00 再加一台 slave 为后台专用。 |
 | 6 levelworm 2020-06-01 20:36:33 +08:00 via Android 说分页的未必合乎后台业务需求啊，有时候后台的确需要批量处理，你分页是方便你自己了，但是后台就得写脚本自己抓数据了。对我就这么干过。最好还是分开来，后台专门有台机器。 |
 | 7 Jooooooooo 2020-06-01 20:38:39 +08:00 拆分数据库, 实时交易库和导出类的库分开 然后再去优化业务 |
 | 8 857681664 2020-06-01 20:39:52 +08:00 via Android 导出可以异步放消息队列里，用独立服务处理，我的想法是这样 |
 | 9 leaderhyh OP @Jooooooooo 目前数据库不是痛点且架构师不想动数据库 |
 | 10 CoderGeek 2020-06-01 20:54:20 +08:00 运营与对外分离 |
 | 11 night98 2020-06-01 20:55:10 +08:00 可以起两个服务，但是可以使用分批写入的方式，一次读取一千条左右，写到文件中，参考 http://poi.apache.org/components/spreadsheet/how-to.html#sxssf 如果说内存足够的话，只是说数据库容易被拖死的话，可以单独起一个从库专门用于后台管理系统的导出，然后使用 mysql 自带的 sql 导出到硬盘目录，再用服务器转移到对象存储等文件服务上面 |
| 12 Jooooooooo 2020-06-01 22:01:16 +08:00 @leaderhyh 不是动架构. 只需要多一个从库然后导出专门连这个从库就行. |
 | 13 yeqizhang 2020-06-01 22:11:41 +08:00 数据库倒不用分离吧，毕竟后台系统不就是操作对外的一些数据。 不针对你现在的问题来说，系统也最好分开两个系统部署不同的机器，这是前期规划没做好呀！ |
 | 14 arrow8899 2020-06-01 22:43:19 +08:00 你这里的导出可以看做是一种报表业务吧，每次导出再去计算成本太大了。通常的做法是用流式处理框架 Flink,Strom 等实时汇总，把计算成本分摊到每一次业务处理上，导出的时候直接读取就行。 |
 | 15 namelosw 2020-06-01 23:05:58 +08:00  1 微服务挂掉，不用 SQL 全读到内存计算了？那假如你是因为内存计算卡死的话 0. 看看能不能把内存计算变成 SQL query，如果不能看下面 0. 看看能不能改成异步 Job，如果不能看下面 1. 最简单的建议单独分微服务出去 2. 如果分出去微服务接着发现数据库也是瓶颈，把数据库用 CDC 之类的弄一个同步，只用来做查询 3. 再不行就 Flint 或者 Spark，这些是大量内存计算的正规军 |
| 16 leaderhyh OP @Jooooooooo 这个已经做了 |
 | 20 wangyzj 2020-06-01 23:57:47 +08:00 微服务挂掉？ 内存炸了？ 少量多次吧 |
 | 21 neptuno 2020-06-01 23:59:53 +08:00 via Android 搞个从库 |
 | 22 coderabbit 2020-06-02 01:06:53 +08:00 via Android 我 mysql 实时同步 mongo.50 万数据 20 秒左右导出。一点不拖累服务！ |
 | 25 xuanbg 2020-06-02 08:39:18 +08:00 可以按导出需求做个小小的数仓，然后从数仓导出数据就不会影响到业务，而且导出速度也能提升到毫秒级。 |
 | 26 ytmsdy 2020-06-02 10:19:15 +08:00 1 一次性导出 30w+的会员数量这个操作，应该是规避的高风险操作吧。 毕竟一次性导出这么多数据，除了拿出去卖，我想不到还有什么场景会用到这么多数据。 |
 | 27 arthas2234 2020-06-02 10:42:59 +08:00 你如果是需要频繁导出的话，最好单独做一张表用来保存这些数据，到时候直接查出来就行了 |
 | 28 zoharSoul 2020-06-02 11:25:03 +08:00 会员微服务挂掉 是什么意思? 内存溢出了? |
 | 29 EastLord 2020-06-02 13:58:18 +08:00 流式下载不行吗 |
Select Language