Java五年了接触的都是十来万小项目，感觉水平很差咋办？

joytrian

发布于 2023-10-12 11:10

浏览

0收藏

免责声明~
任何文章不要过度深思（万事万物都经不起审视，因为世上没有同样的成长环境，也没有同样的认知水平，更「没有适用于所有人的解决方案」；不要急着评判文章列出的观点，只需代入其中，适度审视一番自己即可，能「跳脱出来从外人的角度看看现在的自己处在什么样的阶段」才不为俗人。怎么想、怎么做，全在乎自己「不断实践中寻找适合自己的大道」）

1 前言

很多年前，流行做公众号，扫个码就能下单，并发量基本个位数，两台机器够用，说是分布式架构，也就一个controller层另外一个service层，数据库上4C16G MySQL，Redis都省去了，项目就能run。

你基本遇不到性能问题，有生产问题直接终端看日志，面试常客cat、grep、less、more核心命令一把梭。也就都没啥值得深入的技术点。

Java五年了接触的都是十来万小项目，感觉水平很差咋办？-鸿蒙开发者社区

但到了大厂，量变引起质变，就有了深入方向。人们口中的互联网大厂项目到底和小厂项目有啥本质区别呢，为啥大厂工程师说话做事都能一套套的呢？

Java五年了接触的都是十来万小项目，感觉水平很差咋办？-鸿蒙开发者社区

2 大厂数据量大

在大厂里面如果出了问题，可不是你搂日志就能解决。

一个service类型的服务达到几十甚至上百个，你怎么去搜日志信息？每天产生的日志量达到TB级别，你要出问题了去搜这些日志信息，一天就光在倒腾日志了。

那么这就涉及到日志的统一搜集管理了？如何管理？这就需要使用常用的elastic数据库了，这个数据库的存储量巨大，支持聚合分组等搜索，光是学会这个你也够优势了吧。

其次是表的大小，我们都知道互联网企业都喜欢用MySQL数据库，原因大家都清楚了，开源免费，大厂的表起码都要达到千万级别，而MySQL的表达到两千万以上就要考虑分库分表了，分库分表要怎么分？用什么工具？数据如何同步？一致性如何保证？如何快速响应等等一系列的问题就来了。

所以你可以假设你们的服务数据量也达到这个级别了，能撑住吗？如果撑不住，有没有什么更好的解决方案呢？多思考，就知道自己应该学习什么了，知道怎么提高了。。

3 大厂并发量高

如果你现在的QPS个位数，那看不出大问题，一次请求查一下数据库行，无任何问题，但是并发量大了问题就很大了，MySQL是非常脆的，经不起任何的风吹雨打，你要是在MySQL里面弄个锁表的命令，那整个系统就要崩溃了。

大并发咋办？那么就需要多层负载均衡，四层负载均衡和7层负载均衡，这样一套环境部署下来你又能学习到不少东西吧，其次流量的毛刺如何削峰？服务的性能不同步如何解耦？MySQL很脆的问题如何解决，使用redis？redis也达到瓶颈了呢，redis也仅仅支持单库10w的并发，如果你需要1千个w的并发呢？集群部署？集群部署后流量分发用什么机制呢？热点key怎么解决呢？缓存一致性有什么好办法呢？

java我们都知道是自动内存管理，流量小的时候体会不到，但是流量大了就体会很明显了，经常间歇性卡顿、频繁死锁、内存溢出、过高的gc等等问题都会接踵而来，你如何处理呢？如果没有对JVM底层理解深入怎么办？

所以你平时要多思考，流量一旦大了，你的系统能够撑的住吗？你的jvm参数设置合理吗？你的数据库设计合理吗？你的机器稳定性坚挺吗？

4 大厂复杂性强

复杂性指的是业务的复杂性，业务复杂性强了必定会导致环境部署的复杂性增强。比如你的用户属性多了、比如你的商品详情复杂了、比如你的下单流程经过的系统要多了，这些都是问题，而且很多时候，用户的数据、商户的数据、商品的数据、订单的数据都分散到不同的团队在管理，这个时候这些数据如何同步？如何保持一致性？比如用户注销了，用户的订单能够保证全部删除吗？比如商户注销了，订单系统能够保证订单都全部完成了吗？这些就需要部门和部门之间的同步需要到位，要么成功，要么全部回滚，涉及到大事务如何使用分布式事务？分布式锁还能解决这样的大分布式事务的问题吗？一个小时才能执行完成的分布式事务，使用分布式锁会有什么问题？

这种复杂性，就会导致你排查问题极为困难，一个下单失败了，失败在哪个环节呢？一次订单的生产，需要经历几十个服务上百台机器，而这些机器一天有万亿级别的数据在跑，你如何去找到这一条数据？

如果突然下单的接口变慢了呢？是整体变慢了，你怎么去排查？有些达到上万甚至几十万QPS的接口，一下子突然整体慢了一秒，怎么办？如何排查？

所以这些问题你都要去思考总结，思考多了，自然水平也就提高了。