【CSDN在線培訓(xùn)QA】漫談云上架構(gòu)與運(yùn)維的藝術(shù)

在7月17日“CSDN在線培訓(xùn)：云上架構(gòu)和運(yùn)維的藝術(shù)”中，UPYUN（又拍云）聯(lián)合創(chuàng)始人兼運(yùn)維總監(jiān)邵海楊，為我們帶來了云上運(yùn)維的趨勢和思考，分享了其多年來在運(yùn)維方面的經(jīng)驗(yàn)。為了幫助大家更好的復(fù)習(xí)本次培訓(xùn)的相關(guān)內(nèi)容，CSDN整理了本次培訓(xùn)最后的QA如下：

Q：在做標(biāo)準(zhǔn)化時(shí)，你是怎樣調(diào)和公司要求開發(fā)快點(diǎn)完成功能，而不能完全符合運(yùn)維現(xiàn)有標(biāo)準(zhǔn)化這個(gè)矛盾問題的？

我們現(xiàn)有的標(biāo)準(zhǔn)化也是從“接盤俠”做起的，所以起初也是根據(jù)之前的遺留情況具體分析，具體應(yīng)對(duì)，通過定制升級(jí)腳本（測試升級(jí)流程無問題后再批量），目的就是通過持續(xù)的改進(jìn)，最終實(shí)現(xiàn)平臺(tái)一致性。所以標(biāo)準(zhǔn)化的過程是個(gè)互相協(xié)商妥協(xié)的交流過程，操作過急并不可取，穩(wěn)中求勝才是第一位。當(dāng)大家磨合一段時(shí)間了，后續(xù)的項(xiàng)目再做標(biāo)準(zhǔn)化就非常順利了，如果真遇到項(xiàng)目趕的時(shí)候，還是要遵循“先完成，再完善，后完美”的原則，只要不是嚴(yán)重拖延癥患者，標(biāo)準(zhǔn)化并不會(huì)花費(fèi)太多的時(shí)候和精力，但是換來的效益是最大的，一定要有防微杜漸的前瞻意識(shí)。

Q：運(yùn)維自動(dòng)化如何更好的維護(hù)? 很多時(shí)候?yàn)榱丝斓脑瓌t，有時(shí)忽略了擴(kuò)展性和重用。

使用gitlab來保存變更代碼，做到追溯可尋，所有人公用一個(gè)代碼倉庫，保證入口準(zhǔn)確和唯一；做到一次編寫，到處運(yùn)行，所以bash/sed/awk的腳本語言移植性極佳，人員互備性也好；使用文本來保存信息，可讀性和移植性有保證；快可以，但要懂得何時(shí)停下來，稍作休整，把不足彌補(bǔ)消化，切記不要日積月累；

Q：又拍IaaS做的多嗎，還是PaaS做得多？

又拍云其實(shí)做的是SaaS服務(wù)，旨在面向移動(dòng)互聯(lián)提供服務(wù)至上的一家集云存儲(chǔ)，云分發(fā)，云處理一站式的云服務(wù)公司。

Q：又拍采用的是什么分布式文件系統(tǒng)呢？

又拍云采用的是基于Erlang并發(fā)語言，參考了Amazon的高可用Dynamo模型，使用KV模型來存儲(chǔ)多副本數(shù)據(jù)對(duì)象，同時(shí)還提供了目錄檢索服務(wù)，基于RESTFul的API調(diào)用，上面還提供了有來自于官方及網(wǎng)友貢獻(xiàn)的各種語言的SDK封裝。

Q：又拍云存儲(chǔ)是怎么做數(shù)據(jù)備份的？

Dynamo高可用存儲(chǔ)模型本身就是設(shè)計(jì)成多副本存儲(chǔ)，P2P哈希一致性，保證數(shù)據(jù)存放在不同的服務(wù)器和不同的磁盤上；機(jī)房目前采用了同城異地+裸光纖直連做災(zāi)備，多機(jī)房多數(shù)據(jù)中心已經(jīng)在開發(fā)中。

Q：怎么樣在不影響用戶使用的情況下，動(dòng)態(tài)去更新部署程序？

在線熱部署熱升級(jí)的秘密在于“盡量保證無單點(diǎn)+熱加載技術(shù)”，如使用DNS輪詢，LVS負(fù)載均衡，Nginx熱升級(jí)，ATS cluster，Redis master/slave多級(jí)緩存。

Q：數(shù)據(jù)庫的讀寫分離，老師有什么好的辦法解決同步延遲對(duì)程序的影響，跟大家分享一下。

我不太明白你的同步延遲要求有多大，但我曾經(jīng)設(shè)計(jì)過Haproxy/LVS+Mysql主從架構(gòu)，用于彩票讀寫密集型場景，采用了Mariadb+Xtradb+SSD，性能和效果還是不錯(cuò)。據(jù)說最新的Mariadb底層服務(wù)框架和Xtradb/Tokudb性能都不錯(cuò)，可以測試一下。

Q：有沒有好的辦法去避免nginx的單點(diǎn)問題？

前面加一層負(fù)載均衡，如LVS,Haproxy，都是不錯(cuò)的選擇。

Q：我們用淘寶的TDDL，做讀寫分離，TDDL的分庫分表怎么做，能不能分享一下？

沒有使用過，如果是自有應(yīng)用，源碼在自己掌握中，我還是建議從程序級(jí)別去區(qū)分讀寫請(qǐng)求，效率最高。這跟公有云開放提供給第三方開發(fā)者的數(shù)據(jù)平臺(tái)是不一樣的設(shè)計(jì)場景，平臺(tái)的智能化是指降低開發(fā)者的門檻，所以，開發(fā)者不需要了解讀寫分離或分庫分表的高深技巧，也能享受平臺(tái)帶來的可擴(kuò)展性優(yōu)勢，但勢必會(huì)帶來一些解析上的開銷，所以要權(quán)衡利弊。

Q：數(shù)據(jù)庫讀寫分離有好的開源框架嗎？數(shù)據(jù)庫中間層處理分庫分表有好的開源代碼嗎？

可以參考阿里的Amoeba或者 360 Atlas。

Q：我是PHP程序員，一般來說擴(kuò)展的瓶頸都在數(shù)據(jù)庫讀取那里，不知道解決這個(gè)瓶頸常見的方法是哪些？

基于機(jī)械磁盤結(jié)構(gòu)的數(shù)據(jù)庫前面都要加層緩存，用于存放熱數(shù)據(jù)，提供給程序調(diào)用，如memcached,redis；后端數(shù)據(jù)庫最好有主從讀寫分離；有條件的話，可以采購一塊SSD，利用flashcache/bcache技術(shù)給sata磁盤做個(gè)熱區(qū)；利用慢查詢工具做好查詢語法的檢查；如果對(duì)實(shí)時(shí)性，如事務(wù)一致性要求不苛刻，可以使用如Mongodb這樣的NoSQL新型數(shù)據(jù)庫；

Q：想問下比如消息隊(duì)列的應(yīng)用生產(chǎn)者和消費(fèi)者如果不能很好的處理消息隊(duì)列的數(shù)據(jù)的話，該如何設(shè)計(jì)才能更好的處理？

如果你已經(jīng)使用了消息隊(duì)列+生產(chǎn)者/消息者解決方案，其實(shí)整個(gè)架構(gòu)已經(jīng)具備了可擴(kuò)展性，理論上可以通過加機(jī)器擴(kuò)展消息隊(duì)列集群，加機(jī)器添加生產(chǎn)者和消息者角色，從而線性擴(kuò)展處理能力。如果研究再深入些，就是里面的數(shù)據(jù)如何壓縮，如何設(shè)計(jì)成更加小巧有效，如何提升帶寬吞吐率。如果壓力還要再大大，就要從設(shè)計(jì)上保證消息隊(duì)列也可以按業(yè)務(wù)做垂直劃分。

Q：請(qǐng)問您對(duì)DevOps這個(gè)職業(yè)怎么看？

這是個(gè)美好的未來，我們要勇敢接受這樣的挑戰(zhàn)和變化。與其在想詢問別人的看法，不如現(xiàn)在就行動(dòng)起來，答案是肯定的。

Q：能談?wù)勥\(yùn)維和DevOps的不同，實(shí)現(xiàn)所謂的DevOps公司文化，運(yùn)維如何更好發(fā)揮作用？

以往運(yùn)維的工作就是部署環(huán)境，發(fā)布上線，監(jiān)控排錯(cuò)以及處理各種疑難雜癥，因?yàn)樯硖幰痪€和最后防線，感覺總是在救火，吃力還不討好。因此我們要轉(zhuǎn)變角色，掌握主動(dòng)權(quán)，如：運(yùn)維自動(dòng)化（開發(fā)運(yùn)維平臺(tái)，操作封裝成web接口，實(shí)現(xiàn)角色分離，權(quán)限分離，操作日志記錄，讓開發(fā)人員也可以自主上線發(fā)布，可追溯），監(jiān)控常態(tài)化（編寫監(jiān)控腳本，實(shí)現(xiàn)自動(dòng)報(bào)警，自動(dòng)隔離故障，為運(yùn)維團(tuán)隊(duì)爭取緩沖時(shí)間， 盡量避免限時(shí)實(shí)時(shí)處理），性能可視化（如全國地圖的業(yè)務(wù)指標(biāo)顯示，性能展示，瓶頸點(diǎn)，利用這些數(shù)據(jù)可以顯而易見的讓每個(gè)人了解實(shí)時(shí)狀態(tài)，也能提供爭取資源的依據(jù)），要做好以上幾點(diǎn)其實(shí)都離不開開發(fā)功底，同時(shí)又需要對(duì)運(yùn)維的深刻理解，所以，我們要有這個(gè)理念，朝著這個(gè)方向努力做好，那我們就可以駕輕就熟的玩轉(zhuǎn)運(yùn)維。

Q：運(yùn)維的抽象業(yè)務(wù)模型是什么，能講個(gè)例子嗎？還有就是運(yùn)維的標(biāo)準(zhǔn)化組件是什么？麻煩也舉個(gè)例子吧

好的，舉個(gè)例子，如果我們要在nginx阻止某些惡意鏈接，我們只需要做二步:
1.  在/etc/upyun.cfg中填寫 NGINX_BAD_SITES="bad.com"
2.  /etc/init.d/nginx config;/etc/init.d/nginx reload
秘密在于config這個(gè)函數(shù)！
config(){
## block bad url
sed -r -i '/#badurl/d' $NGINX_DIR/badurl.conf
STRING=""
for i in $NGINX_BAD_URL;do
  echo "$i"|grep -q "^#"
  [ $? = 0 ] && continue
STRING=$STRING" location /$i/ { #badurl return 444; #badurl access_log off; #badurl } #badurl "
done
echo -e $STRING >> /tmp/.xxx
sed -r -i "/block bad url/r /tmp/.xxx" $NGINX_DIR/badurl.conf
rm -rf /tmp/.xxx
}

Q：如何在不影響業(yè)務(wù)的情況下做變革？ 怎么評(píng)價(jià)監(jiān)控的尺度選取的好壞？比如選的過多，無用等。

循序漸進(jìn)，掌握尺度很重要，尤其是在已經(jīng)穩(wěn)定運(yùn)行甚至盈利的系統(tǒng)上，大刀闊斧的革新并不適用，建議先找出性能瓶頸點(diǎn)，重點(diǎn)突破，先贏取團(tuán)隊(duì)信任，然后再逐步升級(jí)改進(jìn)； 堅(jiān)持 “先完成，再完善，后完美”，項(xiàng)目也是“先能用，再好用，后用好”的實(shí)施方針，包括監(jiān)控指標(biāo)和運(yùn)維平臺(tái)亦是如此，內(nèi)心不要被一些困難或者一時(shí)的挫折打敗，只要堅(jiān)定方向正確，實(shí)施有序，未來肯定是越來越好。

Q：如何針對(duì)多種不同服務(wù)環(huán)境的服務(wù)器進(jìn)行運(yùn)維？如何把這些構(gòu)建在相應(yīng)的平臺(tái)上？

老實(shí)說，抽象業(yè)務(wù)模型需要豐富的實(shí)戰(zhàn)經(jīng)驗(yàn)，如果經(jīng)驗(yàn)不足，還是要虛心多請(qǐng)教前輩，從前人踩過的坑里獲取教訓(xùn)。如果你有不同的服務(wù)器環(huán)境，我建議可以用puppet/saltstack/chef等跨平臺(tái)部署工具來維護(hù)，也可以關(guān)注docker這個(gè)新興的項(xiàng)目，后續(xù)可以直接在統(tǒng)一的平臺(tái)上用docker來虛擬化多平臺(tái)應(yīng)用，也是一種另辟蹊徑的運(yùn)維思路。

Q：運(yùn)維自動(dòng)化的腳本，是運(yùn)維工程師自己編寫還是什么工程師編寫？

運(yùn)維工程師必須要掌握bash/sed/awk三劍客編程語言，并且能夠靈活應(yīng)用各種linux基本命令。但是你不能止步不前，為了迎接DevOps的挑戰(zhàn)，你還需要多掌握一門語言，我推薦是Python/Nodejs，可以一舉多得，打通前后端。

Q：運(yùn)維期間出現(xiàn)的異常故障如何與開發(fā)工程師溝通？如何為開發(fā)工程師提供故障描述？

出錯(cuò)日志，監(jiān)控圖，如果架構(gòu)上沒有單點(diǎn)故障，還可以保留現(xiàn)場提供調(diào)試。

Q：想問一下, 關(guān)于高并發(fā)量，怎樣更好地去預(yù)防它宕機(jī)呢?

我們說在做架構(gòu)的時(shí)候，除了高并發(fā)，高性能，高可擴(kuò)展性，還要考慮隔離機(jī)制，就像汽車一樣，有油門加速，同時(shí)也需要?jiǎng)x車，當(dāng)遇到緊急情況，寧可慢一點(diǎn)也不要撐爆。如在解決在線大并發(fā)請(qǐng)求的時(shí)候，我們建議是松耦合，引入消息隊(duì)列+任務(wù)分發(fā)框架，化并發(fā)無序的請(qǐng)求為有序的請(qǐng)求，再通過可方便水平擴(kuò)展的消費(fèi)者來實(shí)現(xiàn)并發(fā)處理。

Q：請(qǐng)問下，程序員出身，目前兼運(yùn)維這塊，入門的話，有沒有推薦的好書或者一些重點(diǎn)，可以給個(gè)提示嗎？

《鳥哥的私房菜》

Q：Node.js是單進(jìn)程，單CPU的，穩(wěn)定性貌似有問題，而且重重回調(diào)感覺很別扭，請(qǐng)問老師，Node.js最常見的應(yīng)用場景是什么呢？

nodejs考慮到需要回調(diào)，因此會(huì)有一些內(nèi)存持久消耗，建議用在短連接應(yīng)用上，越早釋放內(nèi)存越好，內(nèi)存占用越小越好，不適用復(fù)雜耗時(shí)的復(fù)雜邏輯查詢或者IO密集型應(yīng)用。如nodejs+redis/memcached/mongodb/kv搭配就比較出色，如果要做復(fù)雜查詢，建議通過消息隊(duì)列，或者redis這樣的緩存，與后面的關(guān)系型數(shù)據(jù)庫松耦合。單進(jìn)程可以通過node-cluster模塊獲得多CPU的綁定，性能也能得到提升。

Q：Redis怎么集群化？

Redis 支持多級(jí)緩存和主從復(fù)制，我們用得最多的也就是多級(jí)緩存，基本上3～4級(jí)可以保證夠用了。

Q：Python貌似在運(yùn)維里出現(xiàn)的頻率很高，在運(yùn)維里常用的語言有哪些呢？

除了bash/sed/awk外，不二之選就是python,其次推薦用Node.js/Ruby

Q：技術(shù)選型確實(shí)是一個(gè)很大的問題。如何決斷？考慮的因素有哪些？

話題太大，難于概全，我建議考慮的第一因素，是怎么消滅單點(diǎn)故障，先做到這一點(diǎn)，就能夠讓你臨危不懼，爭取時(shí)間，才能有精力和時(shí)間去消滅更多的性能瓶頸，慢慢完善，架構(gòu)就是一個(gè)不斷演變進(jìn)化的過程，沒必要十全十美再上線。

Q：請(qǐng)老師推薦一款適合大容量，高并發(fā)存儲(chǔ)和讀取的數(shù)據(jù)庫工具，最好適合分布式部署，謝謝！

MongoDB吧。

Q：要搭建適合大量信號(hào)處理運(yùn)算的云計(jì)算平臺(tái)，從性能和功耗考慮推薦什么類型處理集群，謝謝！

用Erlang吧，天生就是并發(fā)的，尤其是在電信領(lǐng)域，原生支持二進(jìn)制傳輸。

Q：有沒有好的運(yùn)維自動(dòng)化的工具推薦？

運(yùn)維自動(dòng)化方面的工具有很多，puppet,chef,saltstack,ansible都是佼佼者，沒有絕對(duì)好用的銀彈，只有靈活應(yīng)用的高手，所以，多比較再選擇。比如說，你的環(huán)境中維護(hù)的服務(wù)器版本各異，跨度很大，那用ansible就比較簡捷，因?yàn)樗恍枰惭b任何agent,直接基于ssh管理。

Q：在企業(yè)環(huán)境中的私有云存儲(chǔ)有哪些應(yīng)用場景呢？采用什么接口，性能如何？有什么云安全檢測工具？

無論什么樣的云存儲(chǔ)，包括私有云，公有云也好，一定要知道關(guān)注的指標(biāo)是什么，如高可靠性，高可用性，高性能，高可擴(kuò)展性，或者安全性。如高可靠性，就需要多副本模型，如ceph,swift等；高可用性，就要用p2p的哈希模型，如riak；高性能的，就要用KV模型；高可擴(kuò)展性，也要用p2p的KV模型，最好能夠提供RestFul的接口，利于水平擴(kuò)展；至于云安全檢測，可以尋找烏云的有償服務(wù)，物有所值。

Q：關(guān)于服務(wù)器的CPU，內(nèi)存監(jiān)控，有沒有較好的工具推薦，能提供性能可視化報(bào)告的？網(wǎng)絡(luò)質(zhì)量監(jiān)控有沒有比較好的工具？例如丟包，網(wǎng)絡(luò)延遲。

zabbix，cacti，nmon都可以提供直觀，高效率的性能監(jiān)控。

Q：我只做過兩臺(tái)服務(wù)器的MySQL，讀寫分離，沒做過一臺(tái)的，一臺(tái)讀寫分離有意義嗎

代碼級(jí)別的讀寫分離意義在于前瞻性和擴(kuò)展性，跟后面到底是一臺(tái)還是多臺(tái)透明無關(guān)，我們所說的架構(gòu)設(shè)計(jì)就在于細(xì)節(jié)的把握，假設(shè)你已經(jīng)事先做了代碼級(jí)的讀寫分離，也許你最初用不上，一旦業(yè)務(wù)量上來后，成敗在此一舉的時(shí)候，你部署好數(shù)據(jù)庫主從+負(fù)載均衡，只需要改變一行代碼中的一個(gè)端口，立即就能輕描淡寫的化解讀寫壓力，這才是高明之處，讓人目瞪口呆，同時(shí)也讓老板對(duì)你刮目相看的最佳機(jī)會(huì)。

Q：如何對(duì)運(yùn)維中積極的人及消極的人進(jìn)行分工？

只有能從痛苦，重復(fù)的工作中，尋找聰明的方法來突破重圍，與他人協(xié)同溝通共同解決問題的人，才能真正為之著迷而堅(jiān)持不懈的奮斗，才能從中得到樂趣，這也是公司希望得到的人才。所以，方法比拼命更重要，何況還不拼命，這樣的人趁早勸退，免得避免整個(gè)團(tuán)隊(duì)的效率。建議看《極客與團(tuán)隊(duì)》《暗時(shí)間》。

免費(fèi)訂閱“CSDN云計(jì)算”微信公眾號(hào)，實(shí)時(shí)掌握第一手云中消息！

CSDN作為國內(nèi)最專業(yè)的云計(jì)算服務(wù)平臺(tái)，提供云計(jì)算、大數(shù)據(jù)、虛擬化、數(shù)據(jù)中心、OpenStack、CloudStack、Hadoop、Spark、機(jī)器學(xué)習(xí)、智能算法等相關(guān)云計(jì)算觀點(diǎn)，云計(jì)算技術(shù)，云計(jì)算平臺(tái)，云計(jì)算實(shí)踐，云計(jì)算產(chǎn)業(yè)資訊等服務(wù)。

生活不易，碼農(nóng)辛苦
如果您覺得本網(wǎng)站對(duì)您的學(xué)習(xí)有所幫助,可以手機(jī)掃描二維碼進(jìn)行捐贈(zèng)