辞职在家,理理东西,理什么了,就cdn吧
对于CDN,汉语为内容分发网络,即Content Distribute Network,其用途为将资源内容,.从服务器传递到用户端,认识之前,应该要先说说互联网了吧,互联网我的理解是以tcp/ip为基础的狭义网络和由www构成的万维网构成,tcp/ip 用于计算机之间的互联,用于将各种信息以极低的成本进行传递,也就是自来水中的管道了,而以www组成的万维网,应该就是我们日常生活中,所见到的b/s了,也就是应用层http了,而http和tcp的差别在于,http是建立在tcp之上,是应用交互协议,http好比孩子,而tcp好比父亲,像后面的多媒体分发网络,其协议也是基于tcp/ip
而在传统的bs应用中,我所知道的哈,会经历以下几个瓶颈
1. 服务器的宽带,宽带决定了该服务器的 访问速度和并发访问量,用户越多,出口带宽要求就越大,如果不够,将会导致性能瓶颈
2. 服务器本身的处理能力,在以前,能充分利用多核,个人觉得是件不简单的事情,现在也觉得也是件不简单的事情,怎么说呢,我所遇到的和见到的,主程根据业务设计时,锁很频繁,各个环节之间,扣得很厉害,对于常驻式线程池,多线程争取同一份资源时,会有等待,也就导致了,该线程处于阻塞中,如果其他与该资源无关的任务到达,是不能及时处理了,这也就导致了延迟,而这个延迟在很大程度上是由设计者决定的.有时候在想,如果通过一个任务到来,一个就开启一个线程处理这样能力用多核,但是线程的开启并非想象中的那么轻量,有时候在想,如果在开始时,一次向开启两千或者更多的线程组成常驻式线程池,进行处理任务,可以在一定程度上避免上面的问题,但是还是有几率出现(思考中,好像不能避免上面的状况),而且线程越多,cpu调度压力就越大,在很大程度上,也是损失了性能,而在综合考虑下,驻留式处理池是最好的,意思是任务到来,会先去驻留式池子中看看,有没有还没退出的线程,如果有,则通过制定的queue 发布任务,然后处理,如果没有则新开启,也是上面这个原因,所以我选择了协程,作为任务处理器单元,因为协程的开启很轻量,但不是越多越好,因为协程越多,调度的压力就越大,所造成的延迟也就上来了,因此这也是我为什么决定去做go的原因,也是通过了前面的思想,实现了驻留式的协程池
3. 用户的接入宽带.
4. 如果是微服务,还得看看要经历哪些结点,经历的结点越多也就越慢了(这个是和业务关系,纯属架构了)