【CSDN在線培訓QA】漫談云上架構與運維的藝術

在7月17日“CSDN在線培訓：云上架構和運維的藝術”中，UPYUN（又拍云）聯合創始人兼運維總監邵海楊，為我們帶來了云上運維的趨勢和思考，分享了其多年來在運維方面的經驗。為了幫助大家更好的復習本次培訓的相關內容，CSDN整理了本次培訓最后的QA如下：

Q：在做標準化時，你是怎樣調和公司要求開發快點完成功能，而不能完全符合運維現有標準化這個矛盾問題的？

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

Q：運維自動化如何更好的維護? 很多時候為了快的原則，有時忽略了擴展性和重用。

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

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

又拍云其實做的是SaaS服務，旨在面向移動互聯提供服務至上的一家集云存儲，云分發，云處理一站式的云服務公司。

Q：又拍采用的是什么分布式文件系統呢？

又拍云采用的是基于Erlang并發語言，參考了Amazon的高可用Dynamo模型，使用KV模型來存儲多副本數據對象，同時還提供了目錄檢索服務，基于RESTFul的API調用，上面還提供了有來自于官方及網友貢獻的各種語言的SDK封裝。

Q：又拍云存儲是怎么做數據備份的？

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

Q：怎么樣在不影響用戶使用的情況下，動態去更新部署程序？

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

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

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

Q：有沒有好的辦法去避免nginx的單點問題？

前面加一層負載均衡，如LVS,Haproxy，都是不錯的選擇。

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

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

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

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

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

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

Q：想問下比如消息隊列的應用生產者和消費者如果不能很好的處理消息隊列的數據的話，該如何設計才能更好的處理？

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

Q：請問您對DevOps這個職業怎么看？

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

Q：能談談運維和DevOps的不同，實現所謂的DevOps公司文化，運維如何更好發揮作用？

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

Q：運維的抽象業務模型是什么，能講個例子嗎？還有就是運維的標準化組件是什么？麻煩也舉個例子吧

好的，舉個例子，如果我們要在nginx阻止某些惡意鏈接，我們只需要做二步:
1.  在/etc/upyun.cfg中填寫 NGINX_BAD_SITES="bad.com"
2.  /etc/init.d/nginx config;/etc/init.d/nginx reload
秘密在于config這個函數！
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：如何在不影響業務的情況下做變革？ 怎么評價監控的尺度選取的好壞？比如選的過多，無用等。

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

Q：如何針對多種不同服務環境的服務器進行運維？如何把這些構建在相應的平臺上？

老實說，抽象業務模型需要豐富的實戰經驗，如果經驗不足，還是要虛心多請教前輩，從前人踩過的坑里獲取教訓。如果你有不同的服務器環境，我建議可以用puppet/saltstack/chef等跨平臺部署工具來維護，也可以關注docker這個新興的項目，后續可以直接在統一的平臺上用docker來虛擬化多平臺應用，也是一種另辟蹊徑的運維思路。

Q：運維自動化的腳本，是運維工程師自己編寫還是什么工程師編寫？

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

Q：運維期間出現的異常故障如何與開發工程師溝通？如何為開發工程師提供故障描述？

出錯日志，監控圖，如果架構上沒有單點故障，還可以保留現場提供調試。

Q：想問一下, 關于高并發量，怎樣更好地去預防它宕機呢?

我們說在做架構的時候，除了高并發，高性能，高可擴展性，還要考慮隔離機制，就像汽車一樣，有油門加速，同時也需要剎車，當遇到緊急情況，寧可慢一點也不要撐爆。如在解決在線大并發請求的時候，我們建議是松耦合，引入消息隊列+任務分發框架，化并發無序的請求為有序的請求，再通過可方便水平擴展的消費者來實現并發處理。

Q：請問下，程序員出身，目前兼運維這塊，入門的話，有沒有推薦的好書或者一些重點，可以給個提示嗎？

《鳥哥的私房菜》

Q：Node.js是單進程，單CPU的，穩定性貌似有問題，而且重重回調感覺很別扭，請問老師，Node.js最常見的應用場景是什么呢？

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

Q：Redis怎么集群化？

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

Q：Python貌似在運維里出現的頻率很高，在運維里常用的語言有哪些呢？

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

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

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

Q：請老師推薦一款適合大容量，高并發存儲和讀取的數據庫工具，最好適合分布式部署，謝謝！

MongoDB吧。

Q：要搭建適合大量信號處理運算的云計算平臺，從性能和功耗考慮推薦什么類型處理集群，謝謝！

用Erlang吧，天生就是并發的，尤其是在電信領域，原生支持二進制傳輸。

Q：有沒有好的運維自動化的工具推薦？

運維自動化方面的工具有很多，puppet,chef,saltstack,ansible都是佼佼者，沒有絕對好用的銀彈，只有靈活應用的高手，所以，多比較再選擇。比如說，你的環境中維護的服務器版本各異，跨度很大，那用ansible就比較簡捷，因為它不需要安裝任何agent,直接基于ssh管理。

Q：在企業環境中的私有云存儲有哪些應用場景呢？采用什么接口，性能如何？有什么云安全檢測工具？

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

Q：關于服務器的CPU，內存監控，有沒有較好的工具推薦，能提供性能可視化報告的？網絡質量監控有沒有比較好的工具？例如丟包，網絡延遲。

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

Q：我只做過兩臺服務器的MySQL，讀寫分離，沒做過一臺的，一臺讀寫分離有意義嗎

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

Q：如何對運維中積極的人及消極的人進行分工？

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

免費訂閱“CSDN云計算”微信公眾號，實時掌握第一手云中消息！

CSDN作為國內最專業的云計算服務平臺，提供云計算、大數據、虛擬化、數據中心、OpenStack、CloudStack、Hadoop、Spark、機器學習、智能算法等相關云計算觀點，云計算技術，云計算平臺，云計算實踐，云計算產業資訊等服務。

生活不易，碼農辛苦
如果您覺得本網站對您的學習有所幫助,可以手機掃描二維碼進行捐贈