看到很多人抛开一切去学一堆基于swoole的框架，真的没必要。这些框架本质上是swoole的apicaller+composer第三方库集成商。并不是说这些框架没有学习价值，只是核心的东西是swoole本身，而不是基于swoole的框架。搞清楚swoole为什么高效之后，这些框架就可以信手拈来了，自己开发一个也不难。phpfpm传统的工作方式，nginx+phpfpm，nginx转发给phpfpm，phpfpm一般监听9000端口，master+N个worker进程接收nginx转发的请求，master调度worker进程进行处理。我们的请求一般会和mysql、redis、elasticsearch、rabitmq等服务器进行交互。需要建立一堆连接，worker进程每次处理请求都会释放这些连接资源。当下一个请求到来时，循环会重复。在上面的工作流程中，大家很容易看出问题所在。每次发出请求，都必须建立和释放连接。这是一项耗时且不必要的操作。再者，如果你请求一个web服务，比如你调用一个接口查看天气，当响应时间比较长的时候，整个worker进程都被阻塞了，当N个worker进程都被阻塞时，下一个请求就无法响应了.整个系统的响应时间会很长。为了解决这两个问题，对应的方法就出来了，资源常驻内存+协程。服务器启动的时候建立一堆连接资源，处理完请求的时候不会释放这些资源，下次继续重用。访问web服务时，使用swoole提供的协程http客户端，不阻塞进程。当下一个请求进来时，swoole调度器调度下一个协程占用CPU资源进行工作。所以如果使用协程，客户端是不会感觉到访问速度提高的。你是什??么意思？比如你去银行柜台办事，传统的做法是柜员一个一个办理，你要等到最后一个人的业务处理完。coroutine的方法是事情不由柜员处理，柜员交给其他人。完成后，您将独自一人，出纳员将继续为下一个人服务。当你的工作做完了，负责人会通知柜员，柜员会再打电话给你，给你反馈结果。显然，第二种方式，对于工作人员来说，看似服务效率更高，但实际上你等待的时间是一样的。协程解决的IO密集型问题不是CPU密集型问题。95%以上的互联网应用场景都是IO密集型的。所以swoole之所以这么高效，是因为它基本等同于nginx+go，利用epoll技术承载大量并发，将资源连接到常驻内存，利用协程避免调用web服务造成的进程阻塞。这里我只提web服务，因为redis、mysql服务器和应用服务器通常在同一个局域网。传统的方式其实效率很高，不能突出协程的优势。而当你调用外网的web服务时，一般响应时间会很长，协程的优势才能体现出来。当然，这只是个人观点，不代表所有人。希望能带来一些启发。韩朵写了《PHP并发IO编程之路》关于PHP程序员的技术职业规划和学习其他优秀语言。他注重基础知识，并花费大量时间学习新框架。个人认为意义不大。
