don't go to candy mountain (誤)
i am using this nginx.conf now.
嗯... 現在的作法是，所有的 node 都用完全一樣的設定。
因此在 nginx 裡就先寫好所有的 upstream, 反正沒灌
那些 upstream, 只要沒叫到也都不會有錯誤。
然後 /etc/conf.d/local.start 也照這個作法。
先偵測 service 是否存在，存在則 restart, 否則忽略。
這邊最好全部都寫成會自動偵測的 restart script,
這意味著如果你要整個 node 重開，不用 reboot,
就 sh /etc/conf.d/local.start 就行。
然後這些 config 中央管理，更新時同步 scp? 至
每一個 node 上。至於哪些 node 要灌什麼，則寫在
另一個 config 裡面。同樣一個遠端 script 同步操作。
也許這只是自我感覺良好沒錯...
不過目前對這樣的架構算是滿滿意的。
==
只是還沒實作完畢就是了... 還有一堆工 ><
最近都在忙這些，滿腦子都是這些，
回過神時已經到家了，回過神時已經再不睡不行了
欸，雖然很想繼續把他弄完，但太專注以至於其他的都忽略了。
而且我覺得非常疲倦... 想休息應該無法，還有好多。
最後我要 quote 這句話：
Of course a theoretical “perfect” solution would combine
the pieces and maybe give you better performance at the
end of the day, but that is not the Unix way.
尤其是那句 "the end of the day"
終究 Unix philosophy 才是王道...
翻翻 unicorn 的文件，我覺得感受良多。
難得看軟體使用手冊，會有很有啟發的感覺。
另一方面，passenger 的文件其實也不錯
Passenger architectural overview這篇的 1~4 確實說出了大部份的架構。
unicorn 是 1, 不過用的 format 是 HTTP.
我不清楚 Tomcat 的狀況。passenger 是 2,
web server 和 application server 放在一起。
整個架構發展多年了。看看這些歷史其實是很有趣的。
你可以看到一些學習的脈絡。最有趣的是，我們往往會
碰到類似這樣的歷程：
因為什麼都不會，所以用很簡單直接的方式 ->
學到一些有趣的東西，大量應用，架構複雜化 ->
返樸歸真，回到最簡單直接的方式
看起來一開始跟最後是一樣的，但其實不然。
簡單方式還能活到最後，才是真正被證明穩定正確的方式。
事實上 unicorn 就是這樣，沒什麼神奇的東西。
這篇說了，為什麼我們只需要 HTTP:
the "P" in "HTTP" stands for "protocol"comments 裡有 passenger 作者出來反駁，可以看看。
passenger 本身的程式，可能是 unicorn 的十倍大以上...
unicorn 程式根本沒幾行，一下就能看完了。
unicorn 用對地方，效能驚人... 需要付出的代價是，
找到怎麼用對，是需要一點經驗和時間的。
passenger 是懶人包。隨便裝裝就能有不錯的水準。
mongrel 功不可沒。ruby server 能蓬勃發展，
mongrel 可能是最大的功臣。後來 rack 發展起來，
是第二號功臣？mongrel 是實作上的功臣，rack 是設計上。
有趣的是，passenger 其實是走回頭路。
不過我覺得這條路，最好大概就如此了吧？
python 有 wsgi, 事實上 rack 是模仿他的。
有趣的是，wsgi 倒似乎沒有很流行？但 rack 儼然是標準。
python server 好像選擇也不多？有人知道發展差異嗎？
php 的話，mod_php 似乎也是極限了？perl 完全不熟....
