如何设计具备高并发能力的后端系统？

不同的技术专家或者架构师，对于高并发架构的理解都不一样，每个人都会有自己的哈姆雷特，没有谁对或者错，但是有一点是一样的，你的高并发架构是为了提高后端系统的高并发能力的，也就是说你只要能够提高这种能力，那就是好的高并发架构方案，只要能够解决问题就行。

这样和大家说，可能理解有点费劲，我讲一个故事吧，很多技术人可能认为高并发架构必须要用很牛逼的技术，越牛越好，这才能彰显自己的牛逼，什么缓存架构设计，异步架构设计，什么梳理后端业务逻辑很蠢，这些都是没啥价值的，尤其是那些CRUD接口的业务逻辑，更LOW。

但是在资深技术专家的眼中，这些工作反而是提高后端系统高并发能力的最有效的手段。你或许都不需要引入牛逼的技术，或者扩容再多的服务节点，就可以将你后端系统的并发能力，提升好几个量级，比如从1000TPS提升到5000TPS。

然而有些刚步入技术专家或者架构师这个级别的技术人就很容易犯这种好高骛远的错误，就是一味的去追求最牛逼的技术，自己也会深挖相关技术的细节，并逼着自己的项目团队去用这些技术，从而产生很多技术代差和隔离沟通的矛盾，也就是你认为很重要，但是人家认为没必要，你自己又不能落地，但是你又得用嘴去说服人家去帮你落地，人家又不买帐，你能咋办？你总不能大骂吧！

我见过很多比较牛逼的专家和架构师，或许自己很牛，但是一旦空降到一个业务团队，就会出现水土不服，没办法融入到一线业务团队中，自己的技术优势没办法发挥出来，也不能给团队带来实质性的改变。

好吧，好吧我说了这么多，好像是偏离今天要聊的主题啦，后端系统的高并发能力是非常重要的，那么你要去设计一个具备高并发能力的后端系统，你就必须要设定一个目标，比如要从100TPS提升到500TPS，当然这个100TPS是现状，你必须要利用技术工具去度量，至于这个100TPS是取平均呢，还是最高，又或者是最低，这个就需要你自己去评判。

一般按照木桶理论，我们都会取你后端系统中TPS能力最低的后端服务的并发能力值，这样你才不会误判，还有你也会联想到，你去定你的目标值时，也会取后端系统中流量最大的后端服务的高并发能力值，尤其是核心后端服务。总之一句话，你做的任何决定都要有理有据，要拿的出手，让人家信服你，而不是你一言堂，直接就说，我要高并发的能力达到10000TPS，那是毫无道理的，换成教员说的，我们一切决策都要实际求是，实践才是检验一切的真理。

有了目标，你才会依据目标去做目标分解及实现目标的有效规划，比如我梳理业务逻辑及后端系统中的后端服务的依赖关系，还有核心服务与非核心服务的调用关系，你需要一周的时间，好吧，排期，并行的梳理的同时，你也可以提前规划和落地，异步设计及缓存设计的相关改造的准备工作，你要做到心里有数。

当你想着，你的目标是什么，你自己在日常的工作过程中，就会有意的去穿插一些辅助性的前期准备工作，这些都是为后续提高并发能力做准备的。

我列举一个简单的例子，你现在准备在做一些新的需求，但是呢？这个新需求的任务紧急性没那么高，这个时候呢？你就要意识到，我是不是可以在这个需求中为后端系统引入Redis分布式缓存， 并快速的用最短的时间和成本上线这次技术改造任务，一般你做高并发改造，肯定是会引入一些Bug的，但是没关系，新需求的业务沉淀没那么多，你还是有时间去解决这些技术问题的，并且影响程度也没那么大（相比较于老业务来说），我只是抛砖引玉哈，大家可以自己认真思考一下，我们平常业务开发的过程中，是真的没有时间去做技术改造吗？

或许又有人会问？要是领导不允许你去增加成本，去解决高并发性问题呢？也就是不能够再增加服务器节点去搭建啥Redis集群，毕竟这样一来，几万块钱就没啦，你是花老板的钱不心疼哈。你是搞技术的，你一定会想出折中的方案出来，这个时候，你就会想到本地缓存哈，引入一些高性能的本地缓存框架（Guava等）以及结合现有的技术去做一些优化，脑子要灵活一点。

这里我不给大家讲搞并发技术的细节，而只是讲一些思路，或者是我做高并发架构的思路，主要还是因为，现在网上的技术方案太多了，再加上AI输出文案确实太方便了，也不需要我去娓娓道来啦！

大家也不要觉得阿里巴巴的P8和P9的技术专家真的有多厉害，人家更不是啥技术都懂，而是人家会想，会思考，会做，外加上有大平台加持，有更多的伸展这些思维的机会，如此而已。

人都是那个样子，当没有驱动力时，就算是神仙也会变的懒惰，在那种高压环境下，就算是普通人，也要被逼成专家，除非你不想在那里混了。

好吧继续聊高并发架构，后端系统，你记住是一个整体，什么叫整体，那就是你现在公司线上运行的APP应用，那么支撑这个APP应用的所有后端服务就是一个整体，很多时候，不是说你将某一个后端服务，比如订单服务的TPS提升到10000啦，就没问题了。

相反如果你只考虑订单服务的高并发，而不去考虑其他的服务，或者是跨部门的后端服务，比如大数据部门的数据服务等，往往你做高并发架构设计中，最后压垮最后一根稻草的往往是那些你认为不重要的服务，它不可用了，就像滚雪球一样，就会殃及城池。

你能够抗打了，能够抗高并发流量啦！但是不代表你的亲戚，你的朋友，和你有关系的人都有，后端系统也是一样的，一个后端服务的高并发能力起来啦，不代表别的可以处理这些流量，用更直白的话去说，核心订单服务可以处理1万TPS啦，但是你所依赖的存储设备及相关服务不能处理这么大的流量，那么就你强有啥用呢？

解决高并发问题，就像一个公司的人才培养一样，就你是高级人才，你下面的都强依赖你，那你累死也带不动，是吧，就这么简单。

未完待续，请读者们关注我的视频号和公众号“架构随笔录”，我再下一篇文章中和大家继续娓娓道来。