/首页
/开源
/关于
《GM技术这两年》之我与甲方不得不说的故事（二）
发表@2018-12-16 10:47:56
更新@2023-01-21 22:47:40
好景不长，果不其然，再经历漫长的一个月后，GM糟糕的API代码终于再次濒临崩溃了，还好老子多年丰富的接外包的经验，上次修复问题前已经义正言辞地告诉吴亦超了：“反正修也仅仅是能顶一时，过不了两三周肯定还得出问题，收你们这点儿钱也只能临时顶这么长时间”，也算严格执行了“拿人钱财，替人消灾”，同时也达到了外包中“又不是不能用”的及格标准。 #### 下面是标准的接外包骗钱的开发与甲方之间不得不说的故事：          #### 钱能骗多少属于水平问题，但是骗了后干不干活纯属道德问题。 吴亦超忧心忡忡地找到我跟于巨蛀说“ 咋办？是不是只能重写了？ ”，我义正言辞地点了点头，于巨蛀也表示附和。其实，不是我想骗钱了，而是这东西真的不重写是不行了，举个例子：一般说来，API的开发大多数都是属于C\S结构，而不是B\S结构，比如用户认证机制大多都是都是token形式，简单地说就是token对应一个用户，识别用户根据token来。然而，我眼下手里这坨代码，APP和API用的是cookie和session来验证用户...  然而，即便如此，我当时是不太想接这单子的，因为钱太少了。原因说来也简单，做为跨界过来新手，吴亦超被上一波儿狗开发骗的太狠了，手里没几个子儿了，再加上他告诉我们好几遍“我们出去拿种子轮可就全看这个了！”。 “钱少事儿多责任大”，老子不爱干。 然而，最终我还是选择接重构项目！并不是因为钱，钱算什么东西，钱就不是个东西，这点儿钱压根就收买不了我，别跟我提钱！我接这个完全就是因为“现在的我”穿越回去告诉那时正在犹豫的我“你得接啊，不然你还怎么写小说？！”，于是我就接了。  ### 如果选择重构，除了API代码要全部修改外，还需要用LNMP代替LAMP。 仔细看了看主要是第二个字母不一样，那么，Nginx到底和Apache有啥不一样？我认为还是值得分析一下的。 Nginx实际上是英文Engine X的简称，但是这个东西却是老毛子发明的。按照国际上的一贯套路，老毛子造的玩意一般都是“傻大黑粗猛”的标准，比如类似于下图这种，你们感受一下：  但是Nginx却不然，相对于Apache来说，体积小巧玲珑，然而各项性能指标都是吊打Apache，神不神奇。其实说到底也没啥神奇的，nginx屌完全是归功于epoll，epoll是什么？你理（bei）解（song）一下：就是一种多路复用技术，简单说就是利用少量进程或线程就可以实现高IO。多路是指很多个IO（比如过万），复用则是指复用这几个进程（线程）。总之，这项技术使得Nginx只需要配置与CPU核心数相同的进程数就可以轻松实现连接过万，相比之下，GM现在用的Apache MPM-prefork方式只能是一个进程只能同时只能干一个活儿。 Nginx的进程模型非常粗暴，Master进程-多Worker进程方式，也就是Master进程会按照配置fork出N个Worker进程，一般说来配置推荐Worker进程数量和CPU核数保持一致即可。 - Master进程职责：fork Worker进程；监控Worker进程，当某个Worker异常挂了后，Master进程负责重新拉起一个；接受外界信号，进行启动、重启、停止；还可以给Worker进程发信号。 - Worker进程职责：总体说来就一个，那就是accept客户端请求，完成请求，数据返回给客户端。  #### Nginx老军医，专治疑难杂症，并发轻松过万！ #### BUT！为毛我们公司用的就是Nginx+PHP，但是ab压测QPS也就是100个左右啊！？？说好的并发过万呢？说好的要做彼此的天使呢～～～ 此事，必有蹊跷。 首先，我认为我们应该分析一下一个HTTP请求被Nginx的Worker进程收到后，是如何解析PHP代码的。反正Nginx自己不会解析PHP... ... 实际上Nginx解析PHP代码靠还是PHP解析器，当然了，我认为这是废话。一般说来，当Nginx收到一个http请求后，就会调用一次PHP解析器对PHP代码进行解析，然后将结果再吐给客户端。听起来和GM现在用的Apache那种CGI方式调用PHP很像啊！这种方式不是说好了的是很LOW逼的么？ 是的，PHP的CGI调用确实比较LOW逼，所以有人新发明了一个玩意叫做fast-CGI，听名字就很牛X，毕竟前面都加上fast四个字母了。和CGI一样，fast-CGI就是一个协议，这个很重要，你们记住了，\*CGI就是协议，而不是一种具体的实现！这种概念是通用的，在全球各地的各行各业都是通用的，就是标准协议归标准协议，依照标准协议做出来的东西叫做具体实现。那么PHP对于fast-CGI协议具体实现就是耳熟能详的PHP-FPM！ PHP-FPM的全称叫做PHP FastCGI Process Manager，中文就是PHP快速CGI进程管理器，妈的，又是进程... ... php-fpm的进程模型和nginx一模一样，就是一个Master进程按照配置fork出Worker进程，不同的是，fpm的worker进程没有“powered by epoll”，每个worker进程内都内嵌了php解析器用来解析php代码，一个fpm进程在已经干活的时候拒绝接受新的请求，是完完全全的基于同步阻塞的工作方式，只有活干完了才会接受新的请求。图我就不画了，贴个ps -ef的图你们感受下：  为毛fast-CGI要比CGI ? ? 呢？因为CGI不涉及进程管理，PHP解析器被调用完一次后，就销毁掉了，下次调用需要重新初始化；而fastCGI涉及到了进程管理，携带着PHP解析器功能的FPM进程是常驻内存的，解析完毕后就一直静静地还在那里，等你来... 然后，重点来了：Nginx和php-FPM之间是如何通信的？其实就是靠socket。一般说来，很多人在搭建环境的时候都会从网上大量复制粘贴Nginx的配置，其中有一个很常见的就是127.0.0.1:9000。php-PFM会监听在回环地址的9000端口上，然后Nginx会将解析PHP的请求发到9000端口上...除了回环地址的9000端口外，Nginx还可以通过本地unixsocket的方式与php-FPM进行通信。 所以，一切都了然了吧？ Nginx自己是可以轻松过万的，但是FPM可不是能轻松过万的...  想了想，我并不算用LNMP方式来重构GM，怎么着都是放开玩了，索性连裤子都不要了，上swoole！
