程序的本质 | Venture 的博客

type

status

date

slug

summary

理解本质的重要性

理解本质可以对工作有着指导作用。能够帮你竖起一个灯塔，每当你在编程中茫无头绪或者需要做选择的时候，回过头看程序的本质，你就能够做出正确的判断。

程序的本质是什么？

答案不是唯一的，像光的波粒二象性，你从不同的角度观察它会有不同的答案。

我自己的答案：

从机器世界的角度看：

程序，总是建立在硬件之上，并且大部分情况下，是通过操作系统提供的API的调用，来实现对硬件基础设备的控制。

你的程序更强，有更好的并发或者更好的伸缩，不是看你做对了什么，而是看你少浪费了什么，因为硬件摆在哪里，CPU、内存、硬盘、网络带宽等等，你利用的够不够高，能决定你的程序是不是能应对更复杂的场景。

程序的本质（机器侧）解高并发

协程的应用场景

在Java中的servlet这个设计模式，每个请求来都会开一个线程，假如有5000个并发，极端情况下就会开5000个线程，但是硬件一个CPU可能只有16核32核。这里就会出现一个问题，线程是软件层虚拟出来的，可以开5000个，可以开1W个，但是对CPU来说只能同时做16件事或者32件事，那中间有没有地方浪费，就是说你没有充分发挥机器的性能，你用软件的设计虚拟的5000个线程，在硬件中不能一一对应，5000个线程在进行切换，还有在做CPU争用时会产生不少的上下文切换的开销。这就是一种浪费。

微服务的应用场景

微服务解决高并发的问题，微服务的提出不是应对高并发问题。微服务能不能解决高并发问题呢？得看什么情况，这里得看实现微服务的框架具不具备高并发方面的考量，其实与其说是微服务解决高并发问题，倒不如说分布式解决高并发问题，为什么？显而易见，如果你还是单机，无论你服务拆的再多，也不会有什么实质上的变化；但是，因为你上了微服务，你的程序从一台电脑，变成了多台电脑。从单机变成了分布式，你的硬件先天发送了编程，你的CPU、内存、硬盘、网络都在成倍的增长，当然会对你的程序有一定的积极作用。

但是微服务有没有浪费什么？他肯定有浪费，因为他为了从管理上获取对一个服务的抽象，方便对一个服务的管理，方便规划一个服务的边界，引入了很多新的机制。比如说注册中心，这些东西其实和硬件本身是没有直接关系的，是因为你引入了管理这个概念，你引入这个框架所带来的的东西。我认识它是一种浪费，但是说它是浪费有点绝对，不如说它是一种牺牲，一种取舍。舍弃掉一定的性能，换来的是服务的治理，换来团队协助的方便。这是微服务的价值。

你的性能遇到瓶颈是，一定要回过头来看，你有没有浪费你的硬件资源。

数据库的瓶颈

这个时候会提出：分库分表。分表能对业务查询产生速度上的提升吗？不应该，硬件没有变，CPU、IO磁盘还是这些速度，为什么你分了表，你的查询就会变快呢？分表后更容易命中CPU的多核并行计算。

什么情况下分表能带来真正的性能提升，当你有多快磁盘时，你分表后，把你分的表放在多块磁盘上。