所以，DevOps的推進(jìn)一定要自上而下，憑借挑戰(zhàn)自我，顛覆傳統(tǒng)的勇氣才能去落實(shí)。
好的，下面正式開始。
DevOps的八榮八恥
一、以可配置為榮，以硬編碼為恥
△ 以可配置為榮，以硬編碼為恥
做過開發(fā)的朋友都知道，程序跟變量分離會(huì)出現(xiàn)單獨(dú)的配置文件，所以運(yùn)維要像開發(fā)學(xué)習(xí)，學(xué)會(huì)把軟件和配置分離。
舉個(gè)例子，我們公司第一個(gè)版本自動(dòng)化運(yùn)維時(shí)，把所有的硬參數(shù)配置到upyun.cfg，如上圖。它的好處在于，只要編寫一個(gè)config函數(shù)，就可以把這種文本的運(yùn)行方式，變成右邊nginx所能運(yùn)行的格式。
并且可以用同樣一份配置去適用不同的后端軟件，如用haproxy替換nginx，只要重新寫一下config函數(shù)即可，運(yùn)維和開發(fā)仍然可以使用同一份參數(shù)。
本地配置的文本格式有txt、ini、cfg，但是這些格式都沒有沒有硬性要求，如ini在php里用的多一點(diǎn)，cfg在mysql里用的多一些。
一般配置的文件里面會(huì)包括開關(guān)變量，調(diào)試參數(shù)、可變參數(shù)、權(quán)重，以及關(guān)聯(lián)上下游的參數(shù)，這些都可以放在配置里面，通過程序生成程序的方式完成。
第二代就不再使用它了。我們現(xiàn)在使用Yaml來定義配置文件，通過它動(dòng)態(tài)生成配置文件，這兩者的思路是相同的，都是通過程序生成程序。
除此之外，現(xiàn)在也有一些更加流行的技術(shù)，比如通過etcd或者是consul來實(shí)現(xiàn)服務(wù)的自動(dòng)發(fā)現(xiàn)、自動(dòng)注冊(cè)。
二、以互備為榮，以單點(diǎn)為恥
△ 以互備為榮，以單點(diǎn)為恥
互容互備一直是優(yōu)良架構(gòu)的設(shè)計(jì)重點(diǎn)。
我們?cè)缙谧黾軜?gòu)設(shè)計(jì)，使用了LVS+Keeplived+VRRP做轉(zhuǎn)換，這樣可以方便負(fù)載均衡，動(dòng)態(tài)升級(jí)，隔離故障?，F(xiàn)在第二代，已經(jīng)在部分大節(jié)點(diǎn)使用OSPF和Quagga做等價(jià)路由的負(fù)載均衡和冗余保障。
Nginx可以加Haproxy或LVS做負(fù)載均衡。MySQL可以做主從切換，或者是MMM的高可用成熟解決方案。
我們的消息隊(duì)列之前用rabbitmq做，現(xiàn)在主要是redis和kafka集群化，其中kafka已經(jīng)遷到了Mesos容器平臺(tái)里。
服務(wù)的自動(dòng)發(fā)現(xiàn)、注冊(cè)，我們可以使用consul、etcd、doozer（Heroku公司產(chǎn)品），還有zookeeper。
主要區(qū)別是算法不一樣，zookeeper用的是paxos算法，而consul用的是raft算法。目前看來consul比較流行，因?yàn)閏onsul的自動(dòng)發(fā)現(xiàn)和自動(dòng)注冊(cè)更加容易使用。
etcd主要是CoreOS在主推，CoreOS本身就是一個(gè)滾動(dòng)發(fā)布的針對(duì)分布式部署的操作系統(tǒng)，大家可以去關(guān)注一下它。還有一個(gè)是hadoop和elk，大數(shù)據(jù)平臺(tái)的可擴(kuò)展性是標(biāo)配，很容易互備。
上面是舉了一些常見互備的軟件組件的選型，那我們應(yīng)該如何設(shè)計(jì)一個(gè)無單點(diǎn)的架構(gòu)呢？主要掌握以下幾點(diǎn)：
1. 無狀態(tài)
無狀態(tài)意味著沒有競(jìng)爭(zhēng)，很容易做負(fù)載均衡，負(fù)載均衡的方式有很多種，F(xiàn)5，LVS，Haproxy，總能找到一種適合你的方式。
2. 無共享
以前我們很喜歡用內(nèi)存來保持臨時(shí)信息，如進(jìn)程間的交換，這種方式雖然效率很高，但是對(duì)程序的擴(kuò)展性沒什么好處，尤其是現(xiàn)在的互聯(lián)網(wǎng)體量，光靠單機(jī)或者高性能機(jī)器是明顯玩不轉(zhuǎn)的。
所以我們現(xiàn)在就需要使用類似消息隊(duì)列的組件，把數(shù)據(jù)共享出去，利用多臺(tái)機(jī)器把負(fù)載給承擔(dān)下來。
3. 松耦合/異步處理
以前我們用Gearman這樣的任務(wù)框架。大家可以把任務(wù)丟進(jìn)任務(wù)池里，生成多個(gè)消費(fèi)者去取任務(wù)。當(dāng)我的消費(fèi)不夠用時(shí)，可以平滑增加我的work資源，讓他從更快的去拿任務(wù)。運(yùn)維平臺(tái)這邊以python/celery的組合使用更多。
4. 分布式/集群協(xié)作
像Hadoop這樣的天生大數(shù)據(jù)/數(shù)據(jù)倉庫解決方案，由于先前設(shè)計(jì)比較成熟，一般都是通過很多臺(tái)機(jī)器擴(kuò)容來實(shí)現(xiàn)map/reduce的擴(kuò)展計(jì)算能力。
三、以隨時(shí)重啟為榮，以不能遷移為恥
△ 以隨時(shí)重啟為榮，以不能遷移為恥
關(guān)于這個(gè)點(diǎn)，我們講三個(gè)方面：
1. Pet到Cow觀念的轉(zhuǎn)變
以前我們說機(jī)器是pet，也就是寵物模式，然后花了幾萬塊錢去買的服務(wù)器，當(dāng)寶一般供奉。但事實(shí)上卻并不是這樣，任何電子設(shè)備、服務(wù)器只要一上線，便開始了一個(gè)衰老的過程。
你根本不知道在運(yùn)行過程中會(huì)發(fā)生什么事，比如說質(zhì)量差的電容會(huì)老化爆漿，電子元器件在機(jī)房的惡劣環(huán)境里會(huì)加速損壞，這些變化都是我們無法參與控制的，所以無論我們?cè)趺磁?，都無法保障機(jī)器有多么的牢靠。
谷歌指出的Cow模式就是指農(nóng)場(chǎng)模式。就是要把機(jī)器發(fā)生故障當(dāng)做常態(tài)，打個(gè)比方，比如說這頭牛死了，那我就不要了，因?yàn)槲矣泻芏噙@樣的牛，或者是再拉一頭新的牛。這就是我們軟件開發(fā)和運(yùn)維需要做的轉(zhuǎn)變，去適應(yīng)這種變化。
2. OpenStack虛擬機(jī)的編排
虛擬化是個(gè)好東西，通過OpenStack我們很容易就可以做出一些存儲(chǔ)或者遷移的操作，但是在實(shí)施的過程中，也是一波三折的。
我們從2014年開始在內(nèi)部推動(dòng)OpenStack，當(dāng)然我們也踩過OpenStack網(wǎng)絡(luò)的坑。
那時(shí)候我們用雙千兆的卡做內(nèi)網(wǎng)通訊，因?yàn)槭褂肙penStack實(shí)現(xiàn)虛擬化后，一切都變成了文件，在網(wǎng)絡(luò)上傳輸?shù)脑?，?duì)網(wǎng)絡(luò)的壓力會(huì)非常大，結(jié)果就導(dǎo)致部分服務(wù)響應(yīng)緩慢。
因?yàn)楸旧砭褪菍?shí)驗(yàn)性質(zhì)，所以在硬件上沒有足夠投入，內(nèi)測(cè)時(shí)也沒有推廣，所以影響不大。
2015年我們?cè)偕系腛penStack，全部都用雙萬兆的網(wǎng)卡做bonding，交換機(jī)也是做了端口聚合和堆疊。目前來說，只有云存儲(chǔ)沒有上線，其它云處理，云網(wǎng)絡(luò)的使用還是能夠滿足要求。
3. Docker的導(dǎo)入導(dǎo)出
Docker是更輕量級(jí)的資源隔離和復(fù)用技術(shù)，從2016年開始，又拍云同時(shí)也在嘗試使用Mesos/Docker來實(shí)現(xiàn)云處理的業(yè)務(wù)遷移。
四、以整體交付為榮，以部分交付為恥
△ 以整體交付為榮，以部分交付為恥
以往開發(fā)運(yùn)維要安裝一個(gè)機(jī)器，首先要去申請(qǐng)采購，購買完了還要等待運(yùn)輸，在運(yùn)輸中要花去一天的時(shí)間，之后還需要配交換機(jī)和網(wǎng)絡(luò)。
在這個(gè)過程中你會(huì)發(fā)現(xiàn)，簡(jiǎn)單的給開發(fā)配臺(tái)機(jī)器，光上架就涉及到運(yùn)維的很多環(huán)節(jié)，更不要說系統(tǒng)安裝，優(yōu)化，軟件配置等剩余工作了，所以大多數(shù)情況下你只能做到部分交付。
要如何解決這些問題？
通過OpenStack可以做到云計(jì)算、云網(wǎng)絡(luò)、云存儲(chǔ)這三塊搭建完成之后，進(jìn)行整體交付。
根據(jù)一些經(jīng)驗(yàn)總結(jié)，在整個(gè)云平臺(tái)當(dāng)中，云存儲(chǔ)的坑最多，云計(jì)算、云網(wǎng)絡(luò)相對(duì)來說比較成熟?，F(xiàn)在云計(jì)算的硬件基本上是基于英特爾CPU的虛擬化技術(shù)來硬件指令穿透的，損耗大概2%～5%，這是可以接受的。
至于云網(wǎng)絡(luò)，剛才胡凱（B站運(yùn)維總監(jiān)）提到內(nèi)網(wǎng)包轉(zhuǎn)發(fā)效率，我做過一個(gè)測(cè)試，在OpenStack的內(nèi)網(wǎng)中，如果MTU默認(rèn)是1500，萬兆網(wǎng)卡的轉(zhuǎn)發(fā)率大概為6.7xxGbps。
后來我在優(yōu)化的過程中，也翻查一些文檔，看到的數(shù)據(jù)是可以達(dá)到9.5xxGbps，通過不斷的摸索，對(duì)比測(cè)試后發(fā)現(xiàn)，如果把內(nèi)網(wǎng)的MTU搞成大包，如9000時(shí)，萬兆網(wǎng)卡的存儲(chǔ)量直接達(dá)到了9.72Gbps左右的。
不過，這個(gè)MTU需要提前在宿主機(jī)上調(diào)整好，需要重啟生效。所以，這個(gè)問題發(fā)現(xiàn)得越早越好，這樣就可以做到統(tǒng)一調(diào)度，分配資源。
Docker的好處是可以做到Build、Shipand Run，一氣呵成。無論是對(duì)開發(fā)，測(cè)試，還是運(yùn)維來說，Docker都是同一份Dockerfile清單，所以使用Docker在公司里的推動(dòng)就很順暢。
雖然OpenStack也可以一站式交付，整體交付，使用時(shí)非常方便。但是對(duì)開發(fā)來說，他還是拿到一臺(tái)機(jī)器，還是需要去安裝軟件環(huán)境，配置，上線，運(yùn)行，除了得到機(jī)器快一些，對(duì)上線服務(wù)沒有什么大的幫助。
所以我們現(xiàn)在的Openstack集群一般對(duì)內(nèi)申請(qǐng)開發(fā)測(cè)試用，外網(wǎng)生產(chǎn)環(huán)境還是以Docker容器化部署為主，這也是大家都喜聞樂見的方式。
但前提是開發(fā)那邊能夠適應(yīng)編寫Dockerfile（目前是我在內(nèi)部推動(dòng)這種變革，如新的項(xiàng)目就強(qiáng)制要求用docker）。
五、以無狀態(tài)為榮，以有狀態(tài)為恥
△ 以無狀態(tài)為榮，以有狀態(tài)為恥
有狀態(tài)的服務(wù)真的很麻煩，無論是存在數(shù)據(jù)庫、磁盤開銷，還有各種鎖等資源的競(jìng)爭(zhēng)，橫向擴(kuò)展也很差，不能重啟，也不能互備。
所以，有狀態(tài)的服務(wù)對(duì)于擴(kuò)展原則來說，就是一場(chǎng)惡夢(mèng)。如何解決我們說的這個(gè)問題，那就要使用解耦和負(fù)載均衡的方法去解決問題。
1. 使用可靠的中間件
中間件其實(shí)最早出現(xiàn)在金融公司、證券公司，后來隨著互聯(lián)網(wǎng)行業(yè)不斷壯大以后，就出現(xiàn)了一些高可靠性的號(hào)稱工業(yè)級(jí)的消息隊(duì)列出現(xiàn)，如RabbitMQ，一出來以后，就把中間件拉下神壇。
隨著中間件民用化，互聯(lián)網(wǎng)蓬勃發(fā)展，是可以把一些服務(wù)變成無狀態(tài)，方便擴(kuò)展。
2. 公共資源池
我們可以通過各種云，容器云、彈性云，做計(jì)算單元的彈性擴(kuò)展。
3. 能夠被計(jì)算
如果你不想存狀態(tài)，那也可以被計(jì)算，比如說Ceph存儲(chǔ)，它的創(chuàng)新在于每個(gè)數(shù)據(jù)塊都是可計(jì)算出來的，這就類似無狀態(tài)的，每次都算，反正現(xiàn)在的cpu都這么強(qiáng)悍了。
所以，無狀態(tài)是一個(gè)命題，在做架構(gòu)的時(shí)候，你腦海里一定要有這個(gè)意念，然后再看你用什么樣的方式開動(dòng)腦筋，預(yù)先的跟開發(fā)，運(yùn)維溝通好，把應(yīng)用拆分成一種無狀態(tài)的最佳組合。
六、以標(biāo)準(zhǔn)化為榮，以特殊化為恥
△ 以標(biāo)準(zhǔn)化為榮，以特殊化為恥
在標(biāo)準(zhǔn)化方面，我們?cè)谶@幾個(gè)方面改良：
1. 統(tǒng)一輸入輸出
統(tǒng)一入口是我加入公司后做的第一件事情，我們用一個(gè)統(tǒng)一的文本，到現(xiàn)在也在用，然后推送到所有的邊緣，服務(wù)器上面的組件，要用到的參數(shù)，都能從配置里讀出來。
代碼管理方面我們也使用git，git wiki，批量部署我們用ansible（早在2012年，我做了一些比較后，就在公司里推行ansible，看來還是很明智的決定）。
2. 統(tǒng)一的流程管理
運(yùn)維中使用python最多，所以我們使用了yaml和playbook。我們有自己的跳板機(jī)，通過VPN登陸，目前我們也在試用一個(gè)帶有審計(jì)功能的堡壘機(jī)，可以把每個(gè)人的操作錄制下來，然后再去回放觀察，改進(jìn)我們的工作流程。
3. 抽象底層設(shè)計(jì)和復(fù)用組件
如果是開發(fā)者的話，就會(huì)寫很多的復(fù)用函數(shù)，對(duì)于優(yōu)秀的運(yùn)維人員來說，也要有優(yōu)秀的抽象業(yè)務(wù)的能力，也要去做一些重復(fù)工作的復(fù)用準(zhǔn)備，如頻繁的，繁瑣易出錯(cuò)的手工操作抽象成若干運(yùn)維的腳本化。
最后是巧妙的利用虛擬化、容器服務(wù)、server-less微服務(wù)，這些服務(wù)是可以被備份，還原的，可以保持一個(gè)相對(duì)穩(wěn)定的狀態(tài)，我們要拒絕多的特殊管理操作。
香農(nóng)-信息熵理論里說，變量的不確定性越大，熵就越大，把它搞清楚所需要的信息量也就越大。理論上來說，如果是一個(gè)孤立的系統(tǒng)，他就會(huì)變得越來越亂。
七、以自動(dòng)化工具為榮，以手動(dòng)和人肉為恥
△ 以自動(dòng)化工具為榮，以手動(dòng)和人肉為恥
公司早期，用的是bash、sed、awk，因?yàn)槲抑坝懈闱度胧降谋尘昂徒?jīng)驗(yàn)，對(duì)一個(gè)十幾兆的嵌入式系統(tǒng)來說，上面是不可能有python/perl/nodejs等環(huán)境。
所以我們把服務(wù)器批量安裝，部署，上線，做成了嵌入式的系統(tǒng)后，只要點(diǎn)亮以后，運(yùn)行一個(gè)硬件檢測(cè)的程序，會(huì)把機(jī)器的CPU、內(nèi)存、硬盤大小等都打印出來，供貨商截圖給我看，這個(gè)機(jī)器是否合格。
合格的機(jī)器可以直接發(fā)到機(jī)房去，在機(jī)器到了機(jī)房通上網(wǎng)線以后會(huì)有一個(gè)ansibleplaybook的推動(dòng)。
自從用了這種方法以后，我們?cè)诠纠锩婊旧蠜]有見到服務(wù)器，一般直接產(chǎn)線上檢測(cè)通過后發(fā)到機(jī)房。
然后我們運(yùn)維人員就可以連上去遠(yuǎn)程管理，在過去的三年里我們服務(wù)器平均每年翻了三倍，節(jié)點(diǎn)翻了六倍多，但是人手并沒有增加。
關(guān)于tgz、rpm、pkg的打包部署，我們用的是tgz的打包及docker鏡像。優(yōu)勢(shì)在于，我們自有CDN網(wǎng)絡(luò)，軟件通過推動(dòng)到CDN網(wǎng)絡(luò)下可以加速下發(fā)。
關(guān)于集成測(cè)試、自動(dòng)測(cè)試的發(fā)布，像ELK集中日志的分析、大數(shù)據(jù)的分析，我們現(xiàn)在使用ELK以后，只要有基礎(chǔ)的運(yùn)維技術(shù)知識(shí)便可看懂，不需要高深的運(yùn)維知識(shí)和腳本編輯知識(shí)，大多數(shù)人都可以完成這份工作，好處就是你多了好多眼睛幫你一起來發(fā)現(xiàn)問題，定位問題。
最后是不要圖形，不要交互，不要終端。一旦有了圖形以后，很難實(shí)現(xiàn)自動(dòng)化。原則就是，不要手工hack，最好是用程序生成程序的方式去完成這個(gè)步驟。
八、以無人值守為榮，以人工介入為恥
△ 以無人值守為榮，以人工介入為恥
運(yùn)維部門要做的事情有三件：
1. 運(yùn)維自動(dòng)化
要有一定的業(yè)務(wù)抽象能力，要有標(biāo)準(zhǔn)化的流程。沒有好的自動(dòng)化，就很難把運(yùn)維的工作效率提升了，只要做好這些，就可以節(jié)省時(shí)間，從容應(yīng)對(duì)業(yè)務(wù)增長(zhǎng)。
而且運(yùn)維自動(dòng)化的另一個(gè)好處就是運(yùn)維不會(huì)因?yàn)槿说南才范艿接绊懛€(wěn)定性，比如說我今天心情不好，你讓我裝一臺(tái)機(jī)器我還可以忍，你讓我裝十臺(tái)一百臺(tái)就不行了。但如果公司有了運(yùn)維自動(dòng)化的流程，這個(gè)事情就可以避免，因?yàn)檎l做都一樣。
2. 監(jiān)控要常態(tài)
2016年年初，我們特別成立大數(shù)據(jù)分析部門，我們把日志做了采樣收集和過濾，通過大數(shù)據(jù)平臺(tái)做日志的同構(gòu)數(shù)據(jù)分析，重點(diǎn)關(guān)注4xx/5xx/2xx比例，響應(yīng)時(shí)間分析如100毫秒、200毫秒、500毫秒，還有區(qū)域性的速率分布，講真，這真是一個(gè)好東西。
3. 性能可視化
數(shù)據(jù)的有效展示?，F(xiàn)在ELK對(duì)我們的幫助很大，從監(jiān)控圖上來看相關(guān)的數(shù)據(jù)指標(biāo)，一目了然。這里就不反復(fù)贅述了。
DevOps的本質(zhì)
最后，我們談一談DevOps的本質(zhì)。
1. 彈性
像亞馬遜推云時(shí)，那個(gè)單詞叫elastic，意思是，你要能夠擴(kuò)展，如橫向擴(kuò)展；你要能負(fù)載均衡，如果你是基于openstack/docker資源池，你的資源就可以復(fù)用，可以編排回滾。
比如說OpenStack有模板，我打一個(gè)鏡像包，稍微重了一點(diǎn)，Docker的就輕一點(diǎn)，Docker可以做一個(gè)滾動(dòng)發(fā)布，可以保留原來的程序、原來的容器，你可以做快速切換，這也是一種變化的彈性。
2. 無關(guān)性
如果是虛擬化資源，一切都可以在模板里面設(shè)置，可以把底層的硬件、系統(tǒng)、網(wǎng)絡(luò)撫平差異，比如說不管物理磁盤是1T(市面上缺貨)/4T/6T的盤，都可以劃分100G容量，所以當(dāng)把一切變成按需申請(qǐng)的服務(wù)，無論是開發(fā)還是運(yùn)維，工作都會(huì)比較簡(jiǎn)單，因?yàn)樗臒o關(guān)性。
3. 不可變的基礎(chǔ)設(shè)施
這個(gè)對(duì)傳統(tǒng)運(yùn)維可能是一種打擊，因?yàn)榛A(chǔ)鏡像可能已經(jīng)做的足夠安全，足夠完美，足夠精干，不需要基礎(chǔ)運(yùn)維過多的人工參與。
但我認(rèn)為恰恰能幫助傳統(tǒng)運(yùn)維減輕工作量，反而有更多的精力去迎接虛擬化、容器化，SDN的挑戰(zhàn)，掌握了新技能后，就可以隨取隨用。
我現(xiàn)在是用比較開放的心態(tài)去接受這些變革，比如說像CoreOS這個(gè)操作系統(tǒng)，你到里面去看一下，真的沒什么各種組件，除了最基礎(chǔ)的就只有docker/RKT運(yùn)行環(huán)境。
當(dāng)然，這個(gè)是很極端的例子，但是我覺得當(dāng)?shù)讓拥牟僮飨到y(tǒng)，他可以做到自我更新，足夠安全的時(shí)候，確實(shí)不需要你去操心這個(gè)事情。這跟我們用小U盤做整體升級(jí)的思路是一樣的，但是它那個(gè)更先進(jìn)，更徹底，更值得我們?nèi)W(xué)習(xí)。
Heroku PaaS的12要素宣言
Heroku是業(yè)內(nèi)知名的云應(yīng)用平臺(tái)，從對(duì)外提供服務(wù)以來，他們已經(jīng)有上百萬應(yīng)用的托管和運(yùn)營(yíng)經(jīng)驗(yàn)。前不久，創(chuàng)始人AdamWiggins根據(jù)這些經(jīng)驗(yàn)，發(fā)布了一個(gè)“十二要素應(yīng)用宣言（TheTwelve-Factor App）”
1. 基準(zhǔn)代碼
一份基準(zhǔn)代碼多處部署，這個(gè)就是剛才講的標(biāo)準(zhǔn)化，還有復(fù)用組件，這些是吻合的。
2. 顯式聲明依賴關(guān)系
比如說像nodejs、go、maven，在提供的配置文件上，要標(biāo)明上下游的關(guān)系，標(biāo)明可配參數(shù)。
3. 必須要在環(huán)境中存儲(chǔ)配置
這一點(diǎn)我覺得可以保留，雖然文本文件也適用，但環(huán)境變量有它的好處，一是語言無侵害性，二是代碼無關(guān)性。比如說OpenStack里也有環(huán)境變量，它是會(huì)導(dǎo)入環(huán)境變量的那份文件。
4. 要把后端服務(wù)當(dāng)做一個(gè)附加資源
這就是我們一直在強(qiáng)調(diào)的松耦合，要把后端服務(wù)變成一個(gè)url去調(diào)用，像Mysql，或者是通過消息隊(duì)列或任務(wù)框架?；蛘吒又悄芤稽c(diǎn)，做自動(dòng)的服務(wù)發(fā)現(xiàn)、服務(wù)注冊(cè)，把后端服務(wù)剝離開去。
這樣做的還有一個(gè)好處，就是能夠區(qū)分運(yùn)維工作中哪些是重點(diǎn)資源，哪些是需要更多的人去監(jiān)控后端的服務(wù)，當(dāng)知道這是重中之重的時(shí)候，就可以把有限的運(yùn)維力量投到上面去。
5. 構(gòu)建、發(fā)布和運(yùn)行
用了Docker以后就很容易實(shí)現(xiàn)這個(gè)標(biāo)準(zhǔn)，關(guān)鍵是統(tǒng)一性、標(biāo)準(zhǔn)化和模板或容器格式。
6. 進(jìn)程必須是無狀態(tài)而且無共享
任何需要持久化的數(shù)據(jù)都要存儲(chǔ)在后端服務(wù)里。
7. 要做端口綁定
要通過端口綁定來服務(wù)，你可以基于Restful，也可以基于rpc或者是http，這樣的好處是松耦合和方便負(fù)載均衡，做水平擴(kuò)展。
8. 并發(fā)
要通過進(jìn)程模型進(jìn)行擴(kuò)展，方便擴(kuò)展。
9. 易處理
快速啟動(dòng)和優(yōu)雅終止可最大化健壯性。參考雅虎原則。
對(duì)雅虎來說，如果開發(fā)需要上線服務(wù)，就必須向運(yùn)維提供start、stop、status、reload/restart這幾個(gè)開關(guān)，如果你不提供這些開關(guān)的話，雅虎的運(yùn)維是不允許這個(gè)服務(wù)上線的。
因?yàn)槟芴峁﹕top，那就說明服務(wù)是能被隨時(shí)重啟的最好證明。
10. 開發(fā)環(huán)境與線上環(huán)境等價(jià)
盡可能保持開發(fā)、預(yù)發(fā)布和線上環(huán)境相同。用了Docker以后，這個(gè)事情就不是個(gè)事情。
11. 把日志當(dāng)做一個(gè)事件流
我們現(xiàn)在用logstash和heka去做一些處理。對(duì)云服務(wù)來說，我們現(xiàn)在發(fā)現(xiàn)，日志越來越重要，日志收集對(duì)我們來說價(jià)值非常大。
通過大數(shù)據(jù)分析平臺(tái)，可以做到秒級(jí)分析，秒級(jí)監(jiān)控報(bào)警，秒級(jí)定位問題，甚至我們可以比客戶更早發(fā)現(xiàn)問題，我覺得這是一件非常有意義，值得我們投入精力去做的事情。
12. 管理進(jìn)程
后臺(tái)管理任務(wù)可以當(dāng)做一次性的進(jìn)程運(yùn)行，相當(dāng)于微服務(wù)。
第三十六屆CIO班招生
國(guó)際CIO認(rèn)證培訓(xùn)
首席數(shù)據(jù)官（CDO）認(rèn)證培訓(xùn)
責(zé)編：content
免責(zé)聲明：本網(wǎng)站（http://www.www.gypb.net/）內(nèi)容主要來自原創(chuàng)、合作媒體供稿和第三方投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準(zhǔn)確性及可靠性，但不保證有關(guān)資料的準(zhǔn)確性及可靠性，讀者在使用前請(qǐng)進(jìn)一步核實(shí)，并對(duì)任何自主決定的行為負(fù)責(zé)。本網(wǎng)站對(duì)有關(guān)資料所引致的錯(cuò)誤、不確或遺漏，概不負(fù)任何法律責(zé)任。
本網(wǎng)站刊載的所有內(nèi)容（包括但不僅限文字、圖片、LOGO、音頻、視頻、軟件、程序等）版權(quán)歸原作者所有。任何單位或個(gè)人認(rèn)為本網(wǎng)站中的內(nèi)容可能涉嫌侵犯其知識(shí)產(chǎn)權(quán)或存在不實(shí)內(nèi)容時(shí)，請(qǐng)及時(shí)通知本站，予以刪除。
搶沙發(fā)
