今年被称为直播元年，有直播就有聊天，如果你这时候还不接触下websocket，那就太 out 了。

我们下面则将一些实际场景都添加进去，比如用户身份的验证，游客只能浏览不能发言，多房间（频道）的聊天。

该博客非常适合和我一样的 Java 新手，非常适合作为学习 Java 的切入点，不需要考虑tomcat、spring、mybatis等。

对epoll、poll、select深入浅出的理解，作为了一个伪架构师吹牛的必备技能包。很多文章，大多以纯文字的介绍，感觉好似空中楼阁，说得再形象，却没有代码配合，再好的戏也出不来。

本篇则是记录自己在学习过程中在思维上和代码实现上的遇到的一些问题，确切的将纯文字介绍和打比方的介绍以代码的形式落地。代码中配以注释，相信耐心的人都能看懂。

苹果支付的逻辑如下

1. 首先客户端先请求苹果支付中心，支付中心返回给客户端一堆加密的数据。

2. 然后客户端把这段加密的数据 base64之后传给后端。

3. 最后由后端再去请求苹果支付中心来验证这次购买是否成功。验证通过，服务器端对业务逻辑进行处理（增加应用内的金币等）。

去年年底因为使用了云存储和其他方面的原因，计划的将服务器缩减一个机柜出来。这样今年每月机房的费用可以减少1万左右。

前前后后抽空在弄这个任务，现做个笔记小结下。以redis服务和图片存储服务器的下架为主。

今天周末去机房，迁移完毕，自己也如释重负，梳理一些旧的没有文档的业务的确是挺费时费力。

在阅读下面的内容之前，我们假定你已经对 PHP 7 基本的数据结构 都有大致的了解了，这是下面内容阅读的前提。

我们分为两大块：

首先实现一个自定义的文件打开、读取、写入、关闭的文件操作扩展；

然后分析各个操作背后的实现原理，其中某些部分的实现我会和 PHP 5.3 使用资源包裹第三方扩展源码解读 对比分析。

在讨论 FastCGI 之前，不得不说传统的 CGI 的工作原理，同时应该大概了解 CGI 1.1 协议

传统 CGI 工作原理分析

客户端访问某个 URL 地址之后，通过 GET/POST/PUT 等方式提交数据，并通过 HTTP 协议向 Web 服务器发出请求，服务器端的 HTTP Daemon（守护进程）将 HTTP 请求里描述的信息通过标准输入 stdin 和环境变量(environment variable)传递给主页指定的 CGI 程序，并启动此应用程序进行处理（包括对数据库的处理），处理结果通过标准输出 stdout 返回给 HTTP Daemon 守护进程，再由 HTTP Daemon 进程通过 HTTP 协议返回给客户端。

云时代，为了提升静态资源的加载速度，大伙都是拼了。这促使近些年国内 CDN 的使用逐步普及。而作为一家以图片分享社区为核心业务的公司，图片 CDN 的使用比较多，下面梳理下自己的一些经验。闭门造车，如有勘误，大家多多包涵。

主要包括以下内容：

1. CDN使用背景，图片的分布式存储

2. 批量添加 CDN 的步骤和注意事项

3. 多 CDN 切换的步骤和注意事项

4. CDN 访问故障分析

5. CDN 相关知识普及

REST是一种软件架构风格。RESTful Api 是基于 HTTP 协议的 Api，是无状态传输。它的核心是将所有的 Api 都理解为一个网络资源。将所有的客户端和服务器的状态转移（动作）封装到 HTTP 请求的 Method  之中。

详情可以阅读 http://mengkang.net/620.html 。

而本篇文章则主要是讨论 RESTful Api 身份认证安全性设计。

没有绝对的安全，这个话题很深，下文都是自己的一些理解，水平有限，如有勘误，希望大家予以指正。

由于 RESTful Api 是基于 Http 协议的 Api，是无状态传输，所以只要和用户身份有关的请求都会带上身份认证信息。（很多时候客户端事先并不知道某个 api 后期会不会加入身份判断，所以我们一般都会选择每个请求都会带上认证信息，如果有的话。）

一些常见的误解

不要以为 RESTful Api  就是设计得像便于 SEO 的伪静态，例如一篇博客资源 http://xxx.com/blog/1 ，我们可以通过浏览器访问该 URL 而读取文章，但是这并不代表着它就是 RESTful Api 。也不要认为URL 里有 queryString 就不是 RESTful Api ，例如 http://xxx.com/blogs/?page=10&page_size=30

更不要认为 HTTP + JSON 就是 RESTful ApI 了。

RESTful Api 与 SOAP Web API 在 URL 形式上的对比

从设计一个删除评论的 api 说起 我们可以这样设计成类似于：

http://api.mengkang.net/?method=comment.del&id=x ^①

http://mengkang.net/comment/del/id/x ^②

或者其他形式的 url。而 RESTful Api 则是：

[DELETE] http://mengkang.net/comments/1 ^③

我们对比可以发现①和② URL 中，都有del的动作指示。

SOAP Web API采用RPC风格，它采用面向功能的架构，所以我们在设计SOAP Web API的时候首相考虑的是应高提供怎样的功能（或者操作）。

而 RESTful Api 是面向资源的架构。是查询、新增、修改、删除，都该资源无关。

所以我们在③ URL 中没有看到del的关键字，对比②和③最为明显。

马上就 2016 年了，总结优化这一年的 Java Web Server 代码，整理了实际开发中遇到的各种框架上的业务逻辑，分享给大家。是对自己2015的一个交代，也是送给小伙伴们2016的一份礼物。

项目基于netty，所以只需要执行一个shell脚本即可启动，无需配合tomcat或者nginx等。

如果你是一个后端程序员，想快速了解掌握 Java 在Web Server 的开发，这真是一个不错的学习 demo，欢迎大家 star，一起交流学习。

我会由浅入深的打多个tag，这样方便大家阅读、学习。

后面我会补充一张图，描述我的整个框架逻辑。

Github 项目地址：https://github.com/zhoumengkang/netty-restful-server

之前切换 cdn 都是运维主导工作，他来负责流量带宽的监控，回源监控。我仅仅需要听候调遣，配合修改业务代码即可。这次由我自己一个人弄，正好就做做笔记。

需求

把网宿 maa 的 cdn 切 400M 到蓝讯 mplus 上。

切换原理

最初，我们配置了n （比如 n=100）个二级域名，然后把这 n 个域名中的一半解析到网宿，另一半解析到蓝讯。比如：

a001.zhoumengkang.com 解析到了蓝讯，回源的地址为y.a001.zhoumengkang.com；

a001.mengkang.net 解析到了蓝讯，回源的地址为y.a001.mengkang.net；

图片资源是分布式存储存储在各个主机上，要确保上面两个回源域名指向的服务以及服务器路径是一样的。这样，这两个域名就可以相互切换了，但是切换的时候需要观察回源的压力。

这里说的“切”是从我们自身的业务代码动刀，而不是切换和 cdn 的域名解析合作。图片资源在数据库有全局唯一的uuid，然后根据该uuid生成url，只需要在这里控制url的域名输出即可。

执行步骤

1. 查看网宿 maa 下各个域名的流量请求带宽。

2. 查看网宿 maa 和蓝讯 mplus 回源地址相同的对应域名。

3. 统计该域名下的热点资源地址，然后到即将切换的 cdn 服务商做预加载，否则客户端加载时，即使回源带宽不至于打满，但是会出现请求时间过长，图片无法显示的情况。

4. 修改业务代码，减掉网宿 maa 的图片地址的输出，替换为蓝讯 mplus 的域名。逐步替换，单域名下流量过大，还需要慢慢降权重转移，而不是一次性，以防回源压力过大，导致源站无法承受。

5. 监控两边 cdn 带宽，新 cdn 的缓存命中率，源站带宽和服务器负载、I/O以及前端图片服务器负载均衡服务器总带宽。

github 项目地址: https://github.com/zhoumengkang/yar-java-client 

简介

Yar 是一个轻量级, 高效的 RPC 框架, 它提供了一种简单方法来让 PHP 项目之间可以互相远程调用对方的本地方法. 并且 Yar 也提供了并行调用的能力. 可以支持同时调用多个远程服务的方法.

Yar 鸟哥博客介绍 http://www.laruence.com/2012/09/15/2779.html

Yar 鸟哥原始项目 https://github.com/laruence/yar

Yar Java Client 则实现了跨语言的远程调用。使得 Java 客户端能够调用 Yar PHP 服务器端本地的方法。

特性

1. 执行速度快，框架轻，使用简单

2. 支持并行的 RPC 调用

3. Api 的使用和参数的和 PHP 版本保持一致

前面需要了解的两个概念

什么是RPC

RPC (Remote Procedure Call)是一个计算机通信协议，该协议允许运行于一台计算机的程序调用另一台计算机的子程序，而程序员无需额外地为这个交互作用编程。RPC是一个分布式计算的CS模式，总是由Client向Server发出一个执行若干过程请求，Server接受请求，使用客户端提供的参数，计算完成之后将结果返回给客户端。RPC的协议有很多，比如最早的CORBA，Java RMI，Web Service的RPC风格，Hessian，Thrift，甚至Rest API。

什么是 Yar

Yar 是一个轻量级的框架, 支持多种打包协议(msgpack, json, php), 并且最重要的一个特点是, 它是可并行化执行。

使用 PRC 的场景举例

简单概述下我当前RPC 使用的场景，给客户端提供的 api 逻辑保持不变，但是后端业务策略改动频繁。可能这句话表达的太过于抽象，为了说的更加具体，所以允许我唠叨下工作的需求：

1. 当用户的 feed 收到点赞时：收到1个赞时，发放10金币；收到5个赞时，发放10金币；收到10个赞时，发放10金币；从10~50个赞每多10个赞，发放10金币；50个赞以后每多50个赞，发放10金币。

2. 当用户评论时，每天的第一次评论送2金币，第二次评论送5金币;

3. 当用户添加 feed 时，每天的第一次添加图片 feed 送5金币，添加视频 feed 送10金币；

4. 当用户 feed 被系统推荐时，送20金币。

如果将这一些运营业务都写在 api 里面，是不是显得很乱呢？一方面导致代码越堆越多，逻辑越来越乱；另一方面，每一次的改动都会涉及 api 的频繁上线，提心吊胆。

我们可以明显的可以看出，这一套运营部门激励用户的需求都是和金币直接相关的，应该解耦出来单独成为了一个金币服务。

揭开 Yar 神秘面纱

RPC 采用客户端/服务器模式。首先，客户机调用进程发送一个有进程参数的调用信息到服务进程，然后等待应答信息。在服务器端，进程保持睡眠状态直到调用信息的到达为止。当一个调用信息到达，服务器获得进程参数，计算结果，发送答复信息，然后等待下一个调用信息，最后，客户端调用进程接收答复信息，获得进程结果，然后调用执行继续进行。

这和我们外网 api 的原理不都一个样么？那么我们一起看看高大上的 Yar 是怎么在玩。

在php里面有fopen,返回值是一个文件资源的指针，在Unix C里面使用open或者create返回的则是一个文件描述符，那么文件描述符到底是个什么东西呢？紧紧局限于文字的描述，记忆还是不深刻，理解不透彻。

本篇是我自己根据《UNIX环境高级编程》第三章文件I/O做的笔记。

书上说：对内核而言，所有打开的文件都是通过文件描述符引用，文件描述符是一个非负整数。当打开一个现有文件或创建一个新文件时，内核向进程反悔一个文件描述符。我的理解，只要用到文件描述符的位置，就可以认为是在对一个文件在操作，下图是表示两个进程对同一个文件进行操作时。

心得体会：

1. 一个进程可能打开很多文件，每一个进程就有自身的一个文件描述符表，文件描述符表以非负整数来索引在该进程中打开的文件。这里说的fd标志，也就是我们在打开一个文件时的模式，比如只读，只写，读写，追加写等等。文件描述符表的每一项还有一个文件指针，指向文件表。

2. 说文件表，上面这个图片也是正好说明了，两个进程打开了同一个文件，每个进程都会活的各自的一个文件表，这也比较好理解，因为两个进程，对同一个文件的操作可能不一样，文件表里记录着文件状态标志，如果一个读，一个写，当然各有不同。再说当前文件偏移量，比如对文件执行追加写(O_APPEND)，那么此时文件的偏移量就是整个文件的长度。

什么是守护进程？

1. 守护进程是再后台运行不受终端控制的进程，通常情况下守护进程在系统启动时运行；

2. 守护进程的名称通常以d结尾，比如httpd,sshd等。

今天对比参考了下《UNIX 环境高级编程》，书上在创建的步骤更加细致，比如需要调用umask，通过getrlimit获取最高文件描述符值，下面的演示代码中，由于知道就三个文件描述符就没有写那么仔细，更加权威的还是要参考《UNIX 环境高级编程》（2015.10.17）

如何才能创建守护进程？

1. 调用fork创建新进程，这个子进程的就是将会成为守护进程的进程；

2. 在主进程中调用exit；

3. 在子进程中调用setsid创建新的会话期；

4. 将当前目录改为根目录（如果把当前目录作为守护进程的目录，当前目录不能被卸载，它作为守护进程的工作目录了）。

5. 将标准输入，标准输出，标准错误重定向到/dev/null