大企业级应用架构什么的是啥玩意

[yuan46720]

已经干了大于 5 年的开发了，前端后端都弄过，写的都是后台管理系统，大屏啥的，或一些节日微信小活动，对于传统行业企业的复杂业务和互联网企业的高访问量场景都没写过没见过， 可以聊下真实高并发和复杂业务的难点和解决经验 只提出场景问题也行，因为没遇到过，连想象都想象不到

[peteretep]

1 、用户有 1 亿
2 、页面查询名字带“张伟”的人

你怎么设计后端服务？

[realpg]

给自己做的系统的所有接口加 10000QPS 的模拟负载 24 小时添加 生产环境也添加 就 curl 外部调用就行
看看能不能扛过一个工作日

[4seasons]

实际上 99%的企业都遇不到，大部分遇到了，也只是因为测试心血来潮，给 request 循环写了个 9999999 。

[aqqwiyth]

说下你能接触到的衣食住行

支付场景： 每秒 1w 个用户生成付款二维码
支付场景： 每秒 1w 个用户发送给银行扣款,1% 几率的银行接口超时处理
...
滴滴出行： 每秒 1w 个用户(不同位置)发起打车
滴滴出行： 每秒 1w 个车主上报车辆位置
...

[midsolo]

电商-交易业务线，10 年老项目重构。

交易业务线中的 "收付、核算、核销、对账、结算" 这几个核心业务，一共有 70 多万行的存储过程，项目文档不全，SQL 注释很少，数据量最大的表有 17 亿条记录，字段最多的表有 490 个字段，现在要使用 OOAD + DDD 的方式进行系统重构。

你来设计一个方案？

[ZGame]

@peteretep 才一亿 直接查！

[peteretep]

@ZGame #6 今天面试就到这里吧，领导今天不在，等他回来通知你

[firefox12]

其实你去 也摸不到这些设计，我也没看到那个新人来就让他设计整个架构的。 就算挖来的人 也做不了这个，因为原来比如 tx 的系统 拿过来也没办法用，要把现在这个扔掉。扔掉 其实是个业务取舍。

一般来说 网上大部分的大规模项目 都能用， 分流 缓存 mq 分库 一把所下来就差不多了。大家愁的是没这么大的业务请求，现在的大部分架构 加几个机器就可以了。

[KingHL]

@midsolo 你说的是真实案例吗，还是自己编的

[litchinn]

一致性，顺序性
由于要提高系统的吞吐量，你开始使用分布式，由于高可用，你开始搭建集群
然后你面临着各种各样的问题，你先下了一笔订单，然后很短时间内想取消它，但是系统告诉你订单找不到，那么就产生了很多可能，两笔订单被分给不同的节点，它们数据还未同步，也有可能在经过前期验证处理后，取消订单被先于下单送达执行节点，但此时根本没有这个单子，所以找不到

为了解决这些问题你开始尝试使用一些解决方案，包括但不限于这里提及的一些内容 https://aeron.io/docs/distributed-systems-basics/logical-clocks/

但这些技术又引入了更多的复杂性，你开始陷入一个泥潭，头发狂掉

[killva4624]

从抽象的角度上说，应用架构上就是找到当前存在瓶颈以及不能横向扩容的地方，然后做加速和拆分，以及应急预案；
比如读写分离，增加读请求的吞吐量；
比如存储分离，把用户数据分表、文件分架分区，用增加复杂度来增加可横向扩展性；
剩下的就是扩容扩容扩容扩容扩容扩容扩容扩容，裁撤裁撤裁撤裁撤裁撤裁撤裁撤裁撤裁撤，限速限速限速限速限速限速限速限速限速限速限速限速...

[midsolo]

@KingHL 真实的，把存储过程翻译成代码就花了整整 9 个月，目前已经重构了 2 年。

[midsolo]

@KingHL 有 7 张表的数据量达到了 10 亿条以上，比如交易流水表、收款表等，如果数据只是 append only ，那么 MySQL 单表存 10 亿条数据没什么压力。

[craftsmanship]

@midsolo 太 NB 了 居然真的有勇气重构。。

[KingHL]

@midsolo 我搞了很多年电商交易相关业务，这种场景我还是真没见过（这么多字段的表，和这么多的存储过程使用，只在某些银行业务听说过），数据量的话对电商场景来说并不算大，十年前电商交易架构已经比较成熟了，非常好奇为什么迭代成这种现状，方便的话可以再介绍下

[JYii]

@midsolo #13 这量级为嘛没拆出来呢，表结构估计一点不敢动吧，只增不改不减是吧，加个索引 DBA 要疯

[aqqwiyth]

@midsolo 阿里去 IOE 都是历史书上的事情了。 你们是那个大厂

[midsolo]

@KingHL #15 @JYii @aqqwiyth 跨境的，不要问我为什么要这样设计，我也不知道，我入职后看到的就是个这样的项目，很久才缓过劲来。

[JYii]

@midsolo #18 理解。我接触的业务量级勉强到亿级，你司又让我对 MySQL 刮目相看。再有面试问 MySQL 性能的就应该抽他，表结构不好，sql 写的不好，怪人家 MySQL 。

[midsolo]

@JYii #19 运维能力强，DBA 团队给力，表也设计的好，1 个联合索引覆盖了 70% 的查询，2 个单独的索引抗住 30% 的查询，剩下的就是堆机器了。