关于项目架构的一些想法

       最近，公司手头连续有多个项目，然后其中一个项目就落到了我的头上。好在该项目内的算法部分也是本人所开发，稍微迁移一下改一改，问题不算是很大，近一段时间以来，主要也就围绕性能、准确性这些指标上做一些优化和调整。
       至于为什么会谈到架构上来呢，说个很丢人的事情，因为是小公司，所以在项目开发之前，并没有系统化的做包括软硬件、网络等各方面的架构搭建，完全相当于从demo一步跨越到整个项目，细想起来，这其实是很恐怖的。
       也因为没有完整的项目开发流程，缺少项目的总体架构搭建，当遇到高并发任务的时候，程序就出现了死亡bug，为这个问题直接头疼了近半个月。
       什么问题呢？其实，如果做过架构或者了解一些的，其实这个问题应该很容易解决。需求是这样的，在2块CPU，多块RTX3090，320G内存，一块960G硬盘的服务器上，程序需要拉取64路摄像头的视频流数据，对视频帧进行目标检测、分类、分割等一系列算法分析，当视频流中出现违规信息时，程序要能及时将违规信息进行上传报警，除此之外最离谱的是还需要留存事件发生前后各10秒合计20秒500帧的MP4视频文件证据并且上传云。

       凭自己经验，320G内存按道理来说，跑64路程序应该是没什么问题的，然而，还是低估了程序的造孽能力。由于主进程搞了64路，保存视频的进程我怕只有1个，它处理不过来，我还开了4个队列，4个进程用来往本地写视频每个进程开了若干线程，然而它还是扛不住，怎么回事呢？

        64路程序当每一路都不产生报警事件的时候，程序相当稳定，跑多久估计都没事，但一旦64路同时产生了多个事件，它就会堆满。什么意思？当1路程序在0时刻产生了3个事件的时候，其他63路也产生同样的情况，那么他们就会触发留存视频的机制，也就是原先起的4个保存视频的进程，每个进程接受到了16*3个视频保存事件，那么我么算一下，此时他占用了多少内存吧。

        1帧1080P的视频帧图片假设控制在1M的话，那么一个20秒的视频就有500M，那么64*3*500就占用了96个G左右的内存，吓不吓人。然后，我们想一下，如果在事件密集的情况下，消费者还没有吃完，生产者又生产了一堆，是不是很快盘子就不够了。320G也经不起再来几次，好巧不巧我找的视频还是事件一个接一个一直不断的。很多人说这是CPU不够，当然，确实如此，如果我有N块CPU这些根本不是问题，但在有限资源下，我们只能更多地压榨它。

      这个时候搭建一套合理的架构是非常有必要的，从上面我的描述就能看出，其实以上述的框架去跑64路，正常情况下，不涉及如此多占用内存的程序，它也是能够正常跑一段时间的，但是，时间一长，他还是会挂。就像此程序，我也能让他连续跑20个小时，也能让他跑几天，但是事件一密集就傻眼。

       从开发的角度看来讲，肯定是多花时间设计得越细致越好，但是很显然从销售角度，他不会给你很多时间，这就是一个矛盾。快是可以快，但是首先得把钢筋脚手搭好搭稳，不能一边竖钢筋一边就开始浇混凝土吧！

       系统架构是最难的，逻辑架构一般是结构化的表示，而系统架构除了系统的结构化表示外，还需要处理非功能性的要求。例如以上实例，就需要利用架构解决高并发问题。而高并发其实算性能要求，这属于系统架构需要讨论的事情。系统架构一般需要考虑如下特性：

性能要求
伸缩性要求
安全性要求
时延要求
可靠性要求
       但系统架构不是独立存在的，它需要根据这些特性要求，有效地协调逻辑架构和物理架构。能做好系统架构的人技术素质特别过硬，对于软件、硬件、业务的理解要十分到位。