技术还是思想？

 我总是遇到一些问题，这些问题是由于基本的问题没有引起重视或者是没有深入研究问题在哪里。导致做出了技术栈改变甚至架构改变。我记得以前在一个群里，一个小伙伴又发了一个连接，这个讲述了一个新的概念和技术栈。小伙伴说我刚学会了这个。这时候群里一位资深的技术领导说到：“我们要学习的是一种编程思想，而不是一种技术。”这里就引出一个问题，因为我们IT系统是唯一一个比时装界概念还多的领域。这个我之前有公众号写过的，感兴趣去的可以去看看。技术是层出不穷的，尤其是最近10几年，大数据、AI、区块链、机器学习、微服务、中台等等。这里这些技术不是适合每个公司的，而且有些技术实际上对于不少公司来说就是坑，或者完全不适用。比如有些大公司最后放弃了微服务。请看连接。https://blog.csdn.net/k6T9Q8XKs6iIkZPPIFq/article/details/115152912

   我们引入一种技术基本是为了解决某种问题，但是如果这种问题本身是现在技术人员技术基本功不扎实导致的，那么引入技术的就变成了回避问题后增加了新的问题。比如我一再说的，1000万的表查询慢这明显是SQL的问题，不是数据库的问题。改成分库分表以后只是将数据库进行了切分，看上去是N分之一的数据，但是随着数据堆积再次会达到每个N分之一到了1000万，问题再次回到了原点。再次切分？不要相信（很轻易的）水平扩展，这种水平扩展，不是动态无感知的。redis做reblance的时候都要卡一下。

   还有由于有错误的认知，认为数据库写入来不及处理，所以引入了消息队列。如果这个消息队列是为了削峰填谷也是可以理解的，但是几乎我见过的是为了过一道而过一道居多，因为通常只有几秒一条或者一秒几条。每秒上万条的，可能又不选择消息队列了。而这只是刚到了数据库性能的半山腰，甚至膝盖，距离数据库天花板还早着呢。就这样使得整个系统多了一个技术环节而导致架构的复杂、而且多了一个环节导致继续慢了。我这里不是说消息队列不行，而是要达到一定程度的消息队列处理能力的硬件（SSD）等，成本是巨大的。迄今为止一般中小公司，很少能有每秒1万左右的事务在线业务写入。

   还由于对缓存和大数据的迷信。把不管有没有必要的都放到redis中，增加了redis的负担。以及不管逻辑全表查询（上亿数据）来提醒大数据的价值，总有一天数据积累到了，一个命令下去系统会故障的时候。

   与其把架构搞得复杂以后还是回答原点，那么不如我们一开始就找到这个问题点，解决掉。我有一次就和一位领导说，我相信15年前中国的三大运营商和五大行的业务量，都比我们99.99%的企业的业务量大（不要不承认）。那时候，没有大数据业务也没受影响；那时候，没有微服务系统开发也没什么问题；那时候，没有中台系统也能运行挺好。当然这里没有说这几个不行，没有这个意思。只是结合实际来说看看是不是真的适合。

   我们真的可以编写一段程序计算1+2+3.。。。+100  1000或者1万。 但是如果我真实环境真的是只要1+2+3.那么编一段程序的代价比直接运算要大。

   如果真的要运行，那么是不是一定要傻算？参考我以前的一篇文章。https://mp.weixin.qq.com/s/3x2GsCohBy_4AXf4DbQk5w