标签：计划任务 ip） priority 规划 需要 soc pes name 比较
这是一篇很久以前就写在 gists 里的思考。之前可以直接读到的版本近期没了，就贴一篇过来。
Nginx 一直以来都有一个很尴尬地问题——就是为了效率，抛弃了 htaccess 目录配置文件。当一个项目打算使用 Nginx 来提供 HTTP 服务时，就不得不在配置文件中大量地硬编码目录信息，可移植性和可维护性很差。那么，能否找到一种相对变通的方法，来提高可移植性和可维护性？
传统方法中，当一套网络系统需要部署在多个节点配合工作时，节点相互之间的通信必须通过赋予地主机名称完成，而非 IP 。IP 和主机名称的对应关系，由 /etc/hosts 文件负责维护。
其目的，就是遵循解耦地思路，减少程序代码中的硬编码内容（网络节点 IP）。
借鉴这种方法，将项目配置文件都使用符号链接“假装”存放在 Nginx 系统配置目录 /etc/nginx 中，是否可行？
系统配置目录中有一个 conf.d 的子目录，其中后缀名为 .conf 的文件，会在主配置文件的最后（http 块）被加载。
因为 Nginx 不支持动态配置调整，所以一些声明定义在整个配置中地先后顺序，并不影响其功能使用。
那么，一些跨域的公用性配置可以都放在这个目录下。比如 /etc/nginx/conf.d/upstream-php.conf：
upstream php {
server unix:/var/run/php5-fpm.sock;
}理论上，不仅仅是 upstream ，其余所有允许使用在 http 块的通用性指令都可以放在这个目录中。又比如这样一份自定义的 /etc/nginx/conf.d/types.conf（这样可以保护 mime.types 文件不被修改）：
types {
text/html do;
}同样是在系统配置目录，还有两个 sites-available 和 sites-enabled 子目录。而后一目录中的所有文件，都会被加载。
模仿 Nginx 默认 VHOST 的管理方式，我们可以将域配置文件 dummy.local 存放为 sites-available/dummy.local，然后符号链接至 sites-enabled/dummy.local 使其生效。
但在实际生产过程中，比较常见地情况是 dummy.local 会被实际拆分为诸如主域 dummy.local、静态资源子域 s.dummy.local（static）、业务接口子域 api.dummy.local 和数据资源子域 a.dummy.local（asset）。而且，在不同的网络节点中，会选择性地部署其中的一个或多个，以均衡负载或容灾。
因此，最可靠的方式是将每个子域都独立配置（成独立的文件）。虽然全部都会存放在 sites-available 子目录中，但是否需要符号链接至 site-enabled 使其生效，视节点规划而定。
一些情况下，部分配置可能会同时出现在一个主域的不同子域中。如前文中比较个性的文件后缀，又如 CORS ，再比如特殊的 PHP-FPM 配置，等等。
以最粗浅的道理来分析，拆分这些配置有助于提高复用，保障一致性和可靠性。那么它们放在什么地方更合适？
upstreamupstream 被 Nginx 定义为服务器组（server group），只用于被 proxy_pass、fastcgi_pass、uwsgi_pass、scgi_pass 和 memcached_pass 指令所调用。保存在文件 /etc/nginx/conf.d/upstream-php-dummy.local.conf 并不会对全局配置造成干扰或污染。
upstream php-dummy {
server unix:/var/run/php5-fpm.sock;
}建议文件以 <directive>-<purpose>-<root domain>.conf 地形式三段化命名，便于识别和管理。
除上述地 upstream 和 location @name 之外，其它配置都是需要在域配置的相应位置被重复引用加载。所以存放至 /etc/nginx/sites-available/dummy.local.d/cors.conf 是个不错地选择，引用也很方便：
include sites-available/dummy.local.d/cors.conf;建议目录和文件以 sites-available/<root domain>.d/<purpose>.conf 地形式两段命名，便于识别和管理。
在另一些情况下，同一个域的体验表现，其实是由多个项目组合而成。比如：主体是 CMS，而 /bbs/ 则挂上了 BBS 。后者的配置文件应该放在什么地方以便管理？
我个人的做法，是将其存放为 /etc/nginx/sites-available/s.dummy.local.d/50-bbs.sub。这样在域配置文件中所有 location 之前批量引用即可：
include sites-available/s.dummy.local.d/*.sub;建议目录和文件以 sites-available/<sub-domain>.d/<priority>-<root-uri>.sub 地形式三段命名。
加上很尴尬地优先级编号地原因，在于 /bbs/lib/ 子项目的配置一定要在 /bbs/ 子项目配置之前被引用才能正常工作，但批量引用时 bbs-lib.sub 却会晚于 bbs.sub 。而有优先级编号之后，我们就可以确保 05-bbs-lib.sub 是在 50-bbs.sub 之前被引用的。
此时，Nginx 系统配置目录应该是这样的：
/etc/nginx
├── conf.d
│?? ├── upstream-php.conf # 公共配置文件
│?? └── upstream-php-dummy.local.conf # 域 upstream 配置文件
├── sites-available
│?? ├── dummy.local # 主域配置文件
│?? ├── dummy.local.d
│?? │?? ├── 05-bbs-lib.sub # 主域子项目配置文件
│?? │?? ├── 50-bbs.sub # 主域子项目配置文件
│?? │?? └── cors.conf # 域共用配置文件
│?? ├── s.dummy.local # 静态资源子域配置文件
│?? └── s.dummy.local.d
│?? ├── 05-bbs-lib.sub # 静态资源子域子项目配置文件
│?? └── 50-bbs.sub # 静态资源子域子项目配置文件
└── sites-enabled
?? ├── dummy.local # -> ../sites-available/dummy.local
?? └── s.dummy.local # -> ../sites-available/s.dummy.local近几年的时间，我都会参考 Linux 的目录结构，来划分项目代码的目录结构，因为这样最好识别：
PROJECT
├── bin # 可执行程序
├── etc # 配置
│?? ├── cron.d # 计划任务配置
│?? └── nginx # 项目 Nginx 配置
│?? ├── conf.d # 被调用的域共用 Nginx 配置
│?? └── sites-available # 域 Nginx 配置
│?? ├── ROOT-DOMAIN.d # 被引用的共用 Nginx 配置和主域子项目 Nginx 配置
│?? └── SUB-DOMAIN.d # 子域子项目 Nginx 配置
├── include # 第三方代码库
├── lib # 后端程序代码
│?? ├── Controller # 控制器层程序代码
│?? ├── Model # 模型层程序代码
│?? │ └── DAO # 数据访问对象程序代码
│?? ├── Utility # 工具层程序代码
│?? └── View # 视图层程序代码
│?? └── Helper # 视图组件程序代码
├── libexec # XGI 入口程序
├── share # 其它程序代码
│?? ├── cron # 计划任务脚本
│?? ├── public # 主域静态文件
│ │ ├── .cache # -> ../../var/cache
│ │ └── .cgi-bin # -> ../../libexec
│?? ├── scss # 主域 SCSS 样式代码
│?? └── static # 静态资源子域文件
└── var # 数据
├── cache # 静态缓存文件
├── db # 数据库数据
└── log # 日志/var/www在生产节点上部署好之后，就应该是：
/var/www
└── dummy.local # 域目录
├── _bbs.git # 子项目代码检出版本库
│ ├── etc
│ │ └── nginx
│ │ └── sites-available
│ │ ├── dummy.local.d
│ │ │ └── 50-bbs.sub # 子项目主域配置文件
│ │ └── s.dummy.local.d
│ │ └── 50-bbs.sub # 子项目静态资源子域配置文件
│ └── share
│ ├── public # 主域静态文件
│ └── static # 静态资源子域文件
├── _main.git # 主项目代码检出版本库
│ ├── etc
│ │ └── nginx
│ │ └── sites-available
│ │ ├── dummy.local # 主项目主域配置文件
│ │ └── s.dummy.local # 主项目静态资源子域配置文件
│ └── share
│ ├── public # 主项目主域静态文件
│ │ └── bbs # -> ../../../_bbs.git/share/public
│ └── static # 主项目静态资源子域文件
│ └── bbs # -> ../../../_bbs.git/share/static
├── @ # -> _main.git/share/public
├── s # -> _main.git/share/static
├── www # -> @
└── ~log # Nginx 日志目录在域目录中，
_ 符号起始的目录都是代码包；~log 目录用于记录该域的所有 HTTP 日志，以满足数据挖掘工作所需；@ 遵循 DNS 规约习惯作主域（根域）使用，内部文件和结构与实际体验保持一致。但是，如果没有主项目代码检出版本库，该怎么办？照着同样的目录结构，建一个名为 _ 的目录替代就可以了。看着也还算一目了然～
此时对应的 Nginx 系统配置目录文件结构为：
/etc/nginx
├── sites-available
│?? ├── dummy.local # -> /var/www/dummy.local/_main.git/etc/nginx/sites-available/dummy.local
│?? ├── dummy.local.d
│?? │?? └── 50-bbs.sub # -> /var/www/dummy.local/_bbs.git/etc/nginx/sites-available/dummy.local.d/50-bbs.sub
│?? ├── s.dummy.local # -> /var/www/dummy.local/_main.git/etc/nginx/sites-available/s.dummy.local
│?? └── s.dummy.local.d
│?? └── 50-bbs.sub # -> /var/www/dummy.local/_bbs.git/etc/nginx/sites-available/s.dummy.local.d/50-bbs.sub
└── sites-enabled
?? ├── dummy.local # -> ../sites-available/dummy.local
?? └── s.dummy.local # -> ../sites-available/s.dummy.local标签：计划任务 ip） priority 规划 需要 soc pes name 比较
原文地址：http://blog.51cto.com/13886444/2317394
