摘要：前言本文給大家分享的題目是基于微服務(wù)以及的高可用架構(gòu)探索與實現(xiàn)。比如說年大地震的時候我正好在東京，當(dāng)時在做一個金融系統(tǒng)的相關(guān)工作。那次大地震導(dǎo)致很多很多的問題，雖然大地震不是在東京發(fā)生，但是還是給我們的系統(tǒng)造成了影響。

本文給大家分享的題目是《基于DevOps、微服務(wù)以及K8S的高可用架構(gòu)探索與實現(xiàn)》。整個企業(yè)的高可用架構(gòu)面臨很多的挑戰(zhàn)，面向微服務(wù)、容器化以及敏態(tài)交付，是我們現(xiàn)在的三駕馬車，而今天提到的一個比較接近的概念叫Kubernetes、DevOps和微服務(wù)這三駕馬車也能夠幫助企業(yè)級應(yīng)用解決他們傳統(tǒng)的一些問題。
本文給大家分享的主要內(nèi)容都是從金融和通信領(lǐng)域中的具體案例總結(jié)而來，通過這次分享希望對大家能有所借鑒。主要內(nèi)容包括企業(yè)級高可用性架構(gòu)面臨的挑戰(zhàn)，面臨這些內(nèi)憂外患的挑戰(zhàn)我們應(yīng)該怎樣做才能突破這樣的困境，有哪些原則和方法。

然后Kubernetes、DevOps和微服務(wù)這三架馬車如何各司其職為我們帶來很好的高可用性架構(gòu)，以及大家也知道面臨的各種彈性的擴容需求。比如說我們的客戶在517電信日的時候，他們的需求可能是平時業(yè)務(wù)量的120多倍，這樣的情況下我們怎樣進行彈性擴容，這都是我要跟大家分享的內(nèi)容。

企業(yè)級高可用架構(gòu)面臨哪些挑戰(zhàn)，其實有很多，可能有遇到天災(zāi)的挑戰(zhàn)。

比如說2011年311大地震的時候我正好在東京，當(dāng)時在做一個金融系統(tǒng)的相關(guān)工作。那次大地震導(dǎo)致很多很多的問題，雖然大地震不是在東京發(fā)生，但是還是給我們的系統(tǒng)造成了影響。

當(dāng)時根據(jù)我們的系統(tǒng)和容災(zāi)備份中心進行合理調(diào)整，保證了我們的客戶，因為我們的客戶也是整個亞洲很大的一家銀行，保證他的業(yè)務(wù)正常運行，這一切都是我們提前需要考慮才能做到的。

除此之外還可能有很多人為的Miss帶來的問題。比如說，我們的一個銀行客戶，誤刪除根目錄，這樣的事情在十年之內(nèi)發(fā)生了兩次，其實只要保證節(jié)點的冗余性，就不難解決。

我們說企業(yè)級高可用性架構(gòu)面臨的天災(zāi)人禍的挑戰(zhàn)，我們怎樣才能保障它。

我們要事前考慮好這些因素。比如說我們可能會有應(yīng)用程序的異常退出、有操作系統(tǒng)宕機、服務(wù)器的宕機、停電、大地震、人為操作失誤、訪問量突然增大，原本是沒有問題的，我們企業(yè)是高可用的，但是突然業(yè)務(wù)擴展了100多倍。
我們在設(shè)計時是有一個原則，比如按照10倍設(shè)計，按照1.5倍測試，按照1.2倍發(fā)布這樣都是可以的。但是突然擴大100多倍我的架構(gòu)是很難實現(xiàn)的，所以動態(tài)擴容也是一個重要的課題。

這些挑戰(zhàn)有這么多，其實我們還可以把整體的變得更加復(fù)雜。整個系統(tǒng)非常非常復(fù)雜，在整個金融領(lǐng)域當(dāng)中可以看到復(fù)雜的架構(gòu)比比皆是，復(fù)雜到什么程度呢？

舉個簡單的例子，日本超大銀行的核心外匯系統(tǒng)來說，它大概有1500萬行代碼，我們之前還討論過1500萬行代碼是什么量級。2006年我在做松下手機的開發(fā)時，總的代碼大概是600萬行，所以是3個手機的量，我們并行編譯需要8小時，有4種操作系統(tǒng)，5種編程語言，倒不是說設(shè)計架構(gòu)時就要變成這樣，是因為很復(fù)雜的業(yè)務(wù)結(jié)合在一起就已經(jīng)是這樣的現(xiàn)狀。

整個這樣的一個系統(tǒng)，怎樣才能保證高可用，我們有很多不同系統(tǒng)的集群，整個結(jié)合起來這么復(fù)雜、龐大的金融怎樣才能保證整體的可用性，而且我們還要重構(gòu)。這些給我們帶來都是非常大的挑戰(zhàn)，而且變更越來越多，頻度也越來越大，還要求穩(wěn)定性，因為我們的客戶都會要求，你又要快又要好。

他們的要求也不過分，但是對于我們的實現(xiàn)來說，這其實是很難的。客戶有的時候說我就改了一個Bug為什么不讓我上線。這么大的架構(gòu)我全編譯都要8個小時，你改了這一行bug，那編譯的過程你看不見嗎，1500萬行代碼，要編譯3個安卓手機。但是這些客戶不會說，他會說我的同行他們做的就這么快，這都是我們面臨的壓力。

今天我也會給大家舉一些案例，金融我個人接觸的行業(yè)中也分為到兩種，有傳統(tǒng)的金融，他們還是以穩(wěn)為主，今天的一些案例中就是一些穩(wěn)的，還有一些是快的。所以我們的容器化并不一定都是需要快。

我們講三架馬車，這三架馬車到底怎樣開，開起來穩(wěn)不穩(wěn)，怎樣進行擴展，這過程中我們需要注意什么，我們有些實踐，不敢說最好的，但是可以給大家?guī)斫梃b。

整個來說高可用有這么多的挑戰(zhàn)，如何進行整體的設(shè)計和架構(gòu)。我這里的話列出了一些簡單的點。

我們說一個系統(tǒng)比較好的可用性，我們說它有良好的擴展性，整體是容易維護的，最重要的對客戶來說，我這個系統(tǒng)是隨時用都是可用的，很簡單，我的系統(tǒng)拿出去至少能夠跑起來，客戶能訪問。

所以我們講整體業(yè)務(wù)的連續(xù)性和穩(wěn)定性，對于我們高可用性架構(gòu)是最重要的。

我們業(yè)界經(jīng)常說幾個9的目標，我們講99%其實是系統(tǒng)基本可用。99.9%，這個系統(tǒng)是具有高可用性的特點，這是說，我們一年可以有8.8個小時可以把我們的系統(tǒng)停下來。更多來說，比如說銀行，我們更多是做到4個9。這也結(jié)合了2017devops現(xiàn)狀調(diào)查報告來說，高績效的企業(yè)，他的業(yè)界banch
mark，平均下來他的MTTR的時間大概在一小時，也就是你的系統(tǒng)停一次，一年大概保4個9，如果停兩次的話，那4個9的高可用就保不住了。

但是我們不一定要我們的系統(tǒng)一定是為了沖幾個9，要看業(yè)務(wù)需求是否需要達到這個情況。我給客戶做的時候，會跟他說你的高可用目標，為什么先列目標，因為目標定下來后，你的成本就會出現(xiàn)，如果1500萬行代碼全部要4個9或者5個9的，其實我們是做不到的。我們核心的系統(tǒng)、關(guān)鍵的領(lǐng)域，甚至是2個9都無所謂。

有一個二八定律，80%的功能客戶基本上很少用，我們做的很復(fù)雜的功能，客戶都不用，這也是一個現(xiàn)狀。所以那些東西并不一定要達到4個9的可用性，所以目標設(shè)定非常重要。

除此之外，RPO和 RTO，從業(yè)務(wù)恢復(fù)的角度以及數(shù)據(jù)連續(xù)性的角度，對我們高可用性進行整體的規(guī)劃。我們國家2007年發(fā)布了容災(zāi)備份相關(guān)信息產(chǎn)業(yè)的標準，將RPO和RTO分成六級，大家有興趣的可以看一下，其實不同行業(yè)在做的時候應(yīng)該是先定目標，這個成本就出來了，然后再往下做高可用架構(gòu)的設(shè)計，這樣才能往下細分。

比如我們要達到5個9，你一年只有5分鐘，我要這樣做。比如說我們的應(yīng)用程序突然停了，既然停了把它重啟起來就可以了，無論哪種方式都是這樣的。但是關(guān)鍵是你是5個9，一年只有5分鐘怎么辦？你的策略就不一樣，你是不是應(yīng)該保證兩個方式雙方都能正常運行的時候你再起另外一個。所以整體策略不同，成本也會不同。

整體的策略和手段有很多。我們提高可用最重要的一點是冗余。

我們會使用冗余的方式，你的一個application宕了，它要能訪問，那一定是在另一個地方有備份，客戶才會訪問到。如果你的Note也宕了，一定是其他的地方也有備份。我們保證Application在一臺機器上有多重運行，如果這臺機器宕了的話，在另一臺上也有運行，無論是哪種方式，它都是基礎(chǔ)的策略。

除此之外，我們會結(jié)合成本，做Active-Standby或Active-Active的方式，然后我們做高可用的架構(gòu)其實是說，我們的兩臺機器都放上去，一臺機器一直是做一主一備，這對客戶來說成本投入沒有這么好，我看不到收益，所以我們一般做Active-Active雙活。

比如我們做集群是保證節(jié)點級別的可用性。我們做服務(wù)多重化是保證應(yīng)用層級的高可用性。我們做容災(zāi)備份，就像剛才給大家舉的例子，2011年日本大地震，如果我們給客戶沒有做容災(zāi)備份的東西，他不可能依然能保證在整個過程中是可用的。

雖然是一主一從，但是兩者相互結(jié)合還是能保證他的服務(wù)正常運行。但是除此之外，還有很多的因素。成本是無處不在。而且我們的客戶也會知道，容災(zāi)備份中心做成兩活其實是更好，但是成本會發(fā)生更大的變化。

另外我們平時的訓(xùn)練，因為這跟技術(shù)無關(guān)，但是又非常的重要，因為我看過很多的系統(tǒng)，他們做得都很好，但是為什么他不敢切。

我看過太多很好的系統(tǒng)，但是有的系統(tǒng)我也沒見過，像2015年左右，紐約交易所停了218分鐘，這么龐大的一個系統(tǒng)停了218分鐘，后來我查了原因，他們說是因為技術(shù)的原因，后來我就沒看出因為什么技術(shù)的原因。

但是我相信他一定會有容災(zāi)備份的策略，但是為什么不切。實際我接觸過很多企業(yè)，他們訓(xùn)練不到位，導(dǎo)致他們不敢切，切過去OK，切回來怎么辦？可能就會出問題。

除此之外，還有橫向的擴容，我們的波峰來了，我們什么時候才能進行擴容，所以這個時候我們需要考慮。我們講跟DevOps進行結(jié)合，我們監(jiān)控做到我們能夠確定什么時候進行橫向擴容。

比如說DevOps的透明化和我們整體的可視化結(jié)合起來，然后這些能夠保證我們系統(tǒng)的高可用性進行很好地對應(yīng)，這是整體的策略和手段，當(dāng)然還有很多，我只是列出了這幾個常見且重要的點。

我們叫容器化、微服務(wù)和DevOps，是我們現(xiàn)在應(yīng)用容器化的三架馬車可能更敏捷的對應(yīng)。因為K8S本身就是容器和容器編輯的平臺，可以很好地進行管理。我們使用這三架馬車如何才能保證我們的系統(tǒng)更加可用、方便和靈活。K8S是用什么樣的方式來保證它的高可用性，首先有三個重要的點：

第一點，K8S是以容器化為基礎(chǔ)的，運行在它上面的應(yīng)該是一些容器，以容器形式存在的這些服務(wù)，K8S 平臺保證了這些服務(wù)它本身是可用的。我們傳統(tǒng)的，自己寫SOA其實也是一樣的，只是k8s做的更好，它把這些變成透明化了。

第二點，我們保證K8S本身是可用的，因為K8S保證它的集群運行在這之上的服務(wù)是ok的，但是同時，怎樣才能保證K8S它也是高可用的，消除這些單點我們也會說到這些。

第三點，當(dāng)我們業(yè)務(wù)的波峰來的時候我們?nèi)绾翁幚怼?/p>

然后我們講微服務(wù)，微服務(wù)為什么要引入，各個企業(yè)有自己的想法。我們引入微服務(wù)有很多自己的想法，比如要簡化，要解耦，要使我們的服務(wù)能夠獨立部署，它要能夠進行整個是無狀態(tài)可回滾的，整個來說我們是為了讓容器化變得更加簡單，這些微服務(wù)要按照這樣的策略進行設(shè)計。

我們講DevOps是怎樣做成橋梁和紐帶在微服務(wù)和K8S之間進行溝通。首先我們使用DevOps的理念，微服務(wù)的一旦落地，它帶來的好處同時也給我們的部署也帶來有壓力，所以我們?nèi)绾巫龀掷m(xù)集成和持續(xù)交付，使得這些部署，應(yīng)微服務(wù)帶來的部署這種壓力得到緩解，這是我們Devops實踐需要考慮的事情。

同時，我們通過環(huán)境的一致性，通過考慮安全的因素，使我們高可用性在很多方面得到整體的考慮。我們提到DevOps跟K8S自動的可動態(tài)的橫向的調(diào)整，K8S如何才能知道我們什么時候進行橫向調(diào)整。我們需要監(jiān)控的機制，而我們DevOps的實踐中，我們需要讓整個的過程是透明的，可視的，所以我們通過使我們的系統(tǒng)具有整體監(jiān)控的能力，讓我們知道什么時候該橫向擴容。

這是一個很簡單的例子，我們說整體的做一主多從的K8S架構(gòu)的話，可以看出，這就是簡單的K8S的構(gòu)成。K8S可以做成一主多從，同時我們的ETCD使用集群的方式來保證它的服務(wù)OK。消除單點的話就是Master一主多備，這是非常典型的很簡單的思路。無論哪種方式，我們都是要保證它的冗余度得到保證。

如何使得我們的微服務(wù)更加專注于業(yè)務(wù)的開發(fā)，我們在與我們的客戶進行實際應(yīng)用時也使用一些傳統(tǒng)開箱即用的，比如說Spring Cloud等一些組件。幫助他整體的下面的框架基本上就不用再進行開發(fā)了。

我們傳統(tǒng)用Tuxedo時，都是要自己寫。突然會發(fā)現(xiàn)壓力一下全部減輕了，我們只需要注重業(yè)務(wù)的開發(fā)，突然發(fā)現(xiàn)非常順暢。

我們講DevOps他更多地是一種融合，所以我們最佳實踐進行結(jié)合，通過自動化流水線，保證了自動部署和自動集成的穩(wěn)定性。

通過可視化的監(jiān)控來確認我們什么時候可以動態(tài)擴容，通過一致性的環(huán)境來保證整個的流程是更加順暢的。

所以這是我們整體的一個架構(gòu)和思路。在很多的系統(tǒng)之中和客戶進行推薦的時候我們基本上都是用這樣的方式。

下面我們講三架馬車第一架Kubernetes如何提供基礎(chǔ)服務(wù)。這些都是Kubernetes的基礎(chǔ)知識，我們可以很容易地得到，但是我們講使用Kubernetes的時候，在整個的架構(gòu)中起到什么作用，還是剛才提到這三點。

第一點，我們使用Kubernetes的RC或Daemonset這些東西，我們保證了這些服務(wù)是可以自愈的，簡單來說就是有人幫我檢測、重啟，這些策略都可以進行調(diào)整的。

第二點，Kubernetes本身是需要ETCD和Master始終是可用的，所以我們需要通過具體的策略來保證我們的K8S本身也是可用的，所以這兩點能保證整個集群是OK的。我們Kubernetes提供基礎(chǔ)的平臺和服務(wù)，但是如果你的平臺和服務(wù)它本身是不穩(wěn)定的，也是無法達到整個系統(tǒng)高可用的。我們講這個平臺應(yīng)該比較厚重，同時也要比較穩(wěn)靠，這是我們需要考慮的，我們實際跟客戶落地的時候，這些點都需要考慮，我列出了其中重要的幾點。

我們消除單點的ETCD。ETCD是CoreOS發(fā)布的關(guān)于鍵值的分布式數(shù)據(jù)存儲。在Kubernetes之中，我們使用apiserver跟它進行交互，如果它不穩(wěn)定，我們數(shù)據(jù)的保存就沒有保障，所以我們要消除它的單點，那做一個集群就可以了。

我們做一主多備的Master。我們的Active Master一旦壞掉了切到另外一個，很簡單就是冗余，多放兩個在那里，壞了就切過去。理論上來說都非常簡單和單純，但是就用靠這種單純和簡單的方式，就能保證我們的客戶的整體系統(tǒng)比較穩(wěn)定。

就像在311地震的時候，我們給一個日本的核心銀行的系統(tǒng)，做了一主一從的方式就能保證系統(tǒng)是高可用，所以我們事前需要考慮，同時考慮成本和整體策略，然后給客戶提供一個價錢和其他東西結(jié)合的一個方案。

第三點，就是Kubernetes能夠應(yīng)付現(xiàn)在傳統(tǒng)金融在做動態(tài)擴容時很難做到的一點。使用傳統(tǒng)的方式，當(dāng)客戶想追加節(jié)點的時候很困難。客戶想增加一個節(jié)點時會發(fā)現(xiàn)非常困難。

我們傳統(tǒng)的方式做集群的話，我們可以做雙機或者多機，或者是做其它的都可以跑。但是我要加一個節(jié)點很困難，大家知道如果我們開始做架構(gòu)時，上來就是說你使用了Kubernetes這種神器，或者是你程序本身都是容器化的，你就碰不到這種困難。

但是如果你從十幾年前開始做架構(gòu)，會看到傳統(tǒng)的這種架構(gòu)一步步怎樣走過來的時候你就會發(fā)現(xiàn)，這些真的是很厲害的神器。

為什么傳統(tǒng)金融在往這方面靠的原因，我們加一個Node的時候，做一個雙機集群，我們要自己劃磁盤，自己劃磁盤的仲裁，做心跳線，做設(shè)定。雖然做得很快但是也特別費工夫，關(guān)鍵的是對客戶來說，你要把這些機器停下，這些是要命的，而且花了很多的錢，而且對于K8S平臺來說這些都是透明的。

這是對客戶來說非常有意義的點。也是我們推它的原因。在使用監(jiān)控，首先第一步看到整個的趨勢，問題會不會出現(xiàn)警告。同時對我們的動態(tài)擴容提供輸入。

對動態(tài)擴容提供輸入，我們整個動態(tài)擴容怎么做？我們做了簡單的整理。其實一旦你把所有的條件做好，剩下的都非常簡單了。

我們有些通信的客戶可能在波峰的時候可能他的具體的業(yè)務(wù)量達到平時的一百多倍，這種情況下怎么辦，找到時間點擴容就可以了。

我們還是按照步驟，定義業(yè)務(wù)、系統(tǒng)資源的指標，在這種情況下擴幾個pod，然后采集數(shù)據(jù)。那我們怎么知道這些是可以進行擴展的，然后具體的監(jiān)控是實現(xiàn)說我看系統(tǒng)的日志和業(yè)務(wù)的日志我們可以擴了。在Kubernetes或Swarm層上面一條命令就可以做到了，這就已經(jīng)很簡單了。

但是最關(guān)鍵的是我們之前需要做的這些，監(jiān)控怎樣做好，我們給客戶的最佳實際案例是這樣做的，不要上來就開始做這個自動。自動化其實可以做到最后再做，我們要保證整個流程是平穩(wěn)的。

比如說舉個簡單的例子，我們在金融的系統(tǒng)是這樣做的，我們?nèi)绻胱鍪裁礃拥恼{(diào)整，比如說我要做這樣的動態(tài)調(diào)整，我會把整個的東西打到日志，把空跑的狀態(tài)確認出來，然后根據(jù)事后我們進行分析他算錯沒算錯。做完之后，再做動態(tài)的擴展，動態(tài)擴展相當(dāng)于一個利器，很好用，但是用壞了也很危險，在具體實踐的時候，我們跟客戶實踐了以后才會做。

如果Kubernetes提供了這樣一個基礎(chǔ)服務(wù)，微服務(wù)就很輕松了。比如說我們傳統(tǒng)在做Tuxedo架構(gòu)的時候，我們做微服務(wù)的自動重啟，壞掉了怎么辦？如果使用自己的SOA架構(gòu)，你在里面寫循環(huán)，你自己總不能啟自己，需要有一個守護進程在后面做，守護進程宕了怎么辦？因為企業(yè)級高可用架構(gòu)，尤其是銀行不可能像目前初創(chuàng)公司的做法，他要求他的系統(tǒng)一定是非常穩(wěn)定的，你守護進程壞掉我也得保證，所以我們一般會再寫一個，再壞了怎么辦，沒完沒了的，所以那個要靠監(jiān)控來做。

你要使用Tuxedo的話，就很簡單，在里面設(shè)定一個什么時候這個Sever等于Y，這個架構(gòu)基本可以保證服務(wù)的多重化或者節(jié)點之間的控制。但是有一個很不好做的東西時什么呢。這是一個整體的SOA架構(gòu)，你要進行全部編譯，這意味著你做服務(wù)動態(tài)調(diào)整要通過編譯來做，這就很麻煩了。這個相對于Kubernetes的方式很不靈活。

使用了Kubernetes這種方式后，就會更加靈活，使我們的服務(wù)專注于服務(wù)的架構(gòu)開發(fā)。

即使是這樣，我們依然有很多的東西需要考慮，我們?yōu)槭裁催M行微服務(wù)的設(shè)計和架構(gòu)，這有很多很多的痛點。

就是說我們大型的系統(tǒng)一旦出來，就像多米諾骨牌一樣，你拉其中的一塊，就會整個轟塌。以我十幾年的工程師經(jīng)驗，這個過程是非常痛苦的，痛苦的人都知道怎么來的。

我只改了一行代碼，為什么整個程序宕了，整個應(yīng)用毀了，這種情況會出現(xiàn)的。因為隨著年久失修，這些大型的系統(tǒng)，它會成為巨石一樣存在，誰都不敢改，改起來成本又非常大，維護的成本也非常高。

我接觸過很多大型項目，跟他們一起做他們做得非常優(yōu)秀，但是即使這么優(yōu)秀的企業(yè)我們還是發(fā)現(xiàn)了很多有意思的事情。

比如說當(dāng)年Alpha推出市場的時候，原本在Alpha上運行的話我們轉(zhuǎn)到Hpux上，當(dāng)然有一部分跑到了IBM的AIX上，但是無論你跑在哪種上面，如果有C這種通過編譯型語言的話，你要進行重新編譯和優(yōu)化。

一個很有趣的規(guī)律就是超過百萬行級的代碼我們都會發(fā)現(xiàn)非常低級的bug，不管系統(tǒng)多么優(yōu)秀。有一條到現(xiàn)在沒破，我們知道像C這種父子語句和判斷語句肯定會有用混的，If寫成父子語句的，有專門的把兩行寫成一行，就是為了省一行空間的寫法也有。我們明明確確的根據(jù)上下文判斷就是一個進或不進，改不改。這就陷入兩難，因為它有上百萬的代碼。

一個工程師我只負責(zé)以前在Alpha上面跑，現(xiàn)在在Hpux上跑，你們不是跟我說，我只是換一個機器，剩下都OK嗎，為什么不OK了？所以我們不敢改，因為很多時候時錯錯得正，你改了這個地方其它地方還有一個錯，最后結(jié)果正確的我怎么知道。

這個難點在于，還是整個的耦合度沒有拆分，這種情況下如果你的功能很小的話那就很好辦了。如果部署能夠獨立化，解耦做得很好，簡化做得很好，規(guī)模又小型化，這樣我們知道這塊影響到哪兒，大不了我把它重新用backup運行。我知道它影響到哪個地方，只有不知道，我們才害怕，而且不知道可能真會出現(xiàn)各種問題。

所以這個才是我們實際與企業(yè)級客戶在推的時候遇到的問題，企業(yè)級用戶痛點也在這里，因為客戶很多時候就問我，我改一行代碼為什么要花這么長的時間，我跟他說一天為什么花這么長的時間。確實要花這么長時間，因為你系統(tǒng)太復(fù)雜了。我們解耦以后可以治這個病，但是整個的過程也會帶來其他的問題。所以我們整個過程需要進行考慮。

我們使用Spring Cloud，可以使我們過程中更加方便。通過適當(dāng)冗余，使用多個Eureka服務(wù)端，這樣就能保證保證服務(wù)注冊不會停止。如果我們做Tuxedo的架構(gòu)話要自己寫，我們使用Eureka就更加方便。

我們還要考慮負載均衡，像Ribbon這種客戶端。我想大家做過SOA開發(fā)，對這種策略都不難進行，就是有所反饋。比如說我們就講，我壞了應(yīng)該怎樣重啟，要加權(quán)、隨機要重啟，這臺壞掉了我看另外一臺機器有幾個，跑在另外一臺機器上，自己寫這個很痛苦的。這些如果使用了開箱即用的東西會整體地加快我們的速度。

除此以外還有很多，我再列舉一個配置中心。我為什么提它呢。我們講三架馬車，最終一架是DevOps，像Spring Cloud也好，我們推DevOps時，我們推薦使用一套的部署機制，你不同的環(huán)境可以通過不同的配置來實現(xiàn)，我們認為Spring Cloud是它對DevOps的一種微服務(wù)發(fā)布方式，我們通過整體的具體實踐進行結(jié)合使得發(fā)布更加方便和順暢，更多地是與DevOps進行結(jié)合。

有這樣的東西開箱即用，對于微服務(wù)，我們就很容易寫我們的SQL語句，實現(xiàn)業(yè)務(wù)邏輯，就會非常簡單，實際在使用的時候，尤其是容器化的過程中IP會變來變?nèi)ィ@些問題都會帶來困難的點。但是想想你要從零開始創(chuàng)建這些東西，它的成本是值得的。雖然有些人說你沒辦法做這些東西，但是你看看傳統(tǒng)企業(yè)痛苦的程度。

我們講DevOps能夠在其中起到橋梁和紐帶的作用，輔助我們?nèi)荞R車，容器化的服務(wù)能夠更好的落地實踐。具體地有哪些點，我列出了這樣一些點。

我們強調(diào)開發(fā)和測試環(huán)境、生產(chǎn)環(huán)境的一致性。因為開發(fā)環(huán)境，經(jīng)常會有不同環(huán)境的開發(fā)，可能會帶來很多的問題。測試環(huán)境的話，由于測試和開發(fā)環(huán)境的不同也會帶來問題，比如說你測試的代碼和開發(fā)的版本不一樣，這些不必要的消費都會帶來不必要的時間。

所以這些都是需要我們考慮的，另外我們引入安全掃描的機制。因為2015年左右我看過一個研究，對于Docker Hub上面的鏡像進行分析，大概有30%-40%的鏡像是不安全的。

從今年開始Docker也是在最貴的那版里面引入鏡像掃描的機制，同時CoreOS也提出了Clair，所以建議大家有空回去下一個，像Clair這樣的東西對你的鏡像掃描一下。

2014年的Heartbleed大家印象很深刻，那個心臟流血的，那個一直在流血，心臟就會失血而死亡，你可能就要搭橋，所有的買單都是企業(yè)級的客戶來做，它要為你對安全的忽視來買單，這一切有可能是我們不能承受的，因為它在心臟上。我建議大家一定要下這樣的東西看一下到底有多少的CVE。

然后生產(chǎn)環(huán)境保持一致性，這是理想的，但至少要達到 Infrastructure as Code。這考慮到什么呢，如果你的生產(chǎn)環(huán)境的一個節(jié)點突然壞掉怎么辦？尤其是那些年久失修的系統(tǒng)，客戶說給你拿一個機器給我立即換上，這是很簡單的事情，那有太多的手工作業(yè)，你把這些手工作業(yè)全部都變成代碼放到你的SVN或Git上，一定要這樣做，我們在推這樣的實踐過程中也碰到很多的慣性的阻力，但是我們認為這樣的實踐很重要。

我們講可定制的流水線是非常重要的，安全檢查也非常重要。可以定制的，可以提高我們CI/CD的流水線。可以使用開源的工具，也可以使用商用的工具。根據(jù)DORA調(diào)查，你使用可定制的話可以帶來更好的效果。

監(jiān)控，可以使得彈性擴容更加容易。

我們的一些客戶，我們平時的業(yè)務(wù)量跟波峰的業(yè)務(wù)量相比是1%甚至更多，這種情況下怎么辦？

我們講的三架馬車每塊需要做什么事情，在容器化的基礎(chǔ)之上進行解耦和優(yōu)化，同時DevOps要監(jiān)控、判斷，同時最重要的一點，我們要強調(diào)一下DevOps我們提倡的理念是Fail Fast，我個人認為這不是為了讓我們die fast，你要做好我們的Plan B，我們recover plan，如果一旦失敗了怎么辦，如果事前不想好那真的有可能die fast。

所以我們提倡跟客戶說你要Fail Fast，要戴好安全帶，這點非常重要。根據(jù)DORA的調(diào)查，2017比2016年相比，我們的速度得到了明顯的提高，但是那些低績效的企業(yè)，他們在MTTR的修復(fù)時間比去年還要惡劣，這為什么？快了但是沒考慮穩(wěn)。

我們使用K8S能夠很容易的進行橫向擴展。具體的策略，通過確定交易的指標和資源使用情況，確認什么時候進行水平擴容，取一下業(yè)務(wù)日志和系統(tǒng)日志進行監(jiān)控和計算然后告訴K8S擴容它就擴容，就是這么簡單，但是實際應(yīng)用的時候有很多的項，你在這個過程要保證安全，穩(wěn)定地擴容。

我們通過應(yīng)用的多重啟動，來保證應(yīng)用的可靠。Front office和back office 進行前端的業(yè)務(wù)和后端的審批，這都非常常見，大部分都執(zhí)行這樣的做法。

另外，我們過去傳統(tǒng)來做，可以看到整體的集群非常復(fù)雜，你有文件集群、應(yīng)用集群、認證集群、RAC集群。而且這些資源相互之間協(xié)調(diào)非常痛苦，如果你出了問題了，依然有很大程度的可用性。

但全壞掉了，我們通過什么辦法。通過共享存儲和網(wǎng)絡(luò)結(jié)合起來，跟容災(zāi)備份中心結(jié)合起來，它的數(shù)據(jù)一旦過去之后，另外一套系統(tǒng)結(jié)合起來，可以使它能夠保證數(shù)據(jù)中心級別的可用性。

應(yīng)用級別可用性，節(jié)點級別的可用性以及數(shù)據(jù)中心級別的可用性，我們都能達到。同時，這種傳統(tǒng)的問題點，客戶也問過我這個問題，他說，我加一個node，你們?yōu)槭裁椿ㄎ疫@么多錢。

有一次，我們跟他說應(yīng)用級別的資源不夠了，加一個resource吧，他的文件集群依然有resource，你告訴我應(yīng)用集群不夠了，你用它的不好嗎。我說，作為一個工程師來說，這個很難。他說我不管為什么難，我只看到我的系統(tǒng)，它依然有一部分是閑的，你沒有做到。它做不到并不表示其他做不到，比如K8S就可以做到。

這是一個典型的案例，是跟我們通信領(lǐng)域的一個客戶做的在PaaS平臺上運行微服務(wù)的架構(gòu)。我們也實現(xiàn)了多Kubernetes集群的狀態(tài)下，我們的雙中心的這樣一個應(yīng)用。雙中心雙活，整體的話與剛才那個例子相比是有優(yōu)點的。同時我們講我們實現(xiàn)了按需擴容，怎樣進行按需擴容，其實就是監(jiān)控，監(jiān)控的過程中注意安全，我們定期對客戶安全進行掃描。希望大家注重安全，不要認為官方鏡像的就很可靠。

我們會根據(jù)我們業(yè)務(wù)的，比如說我們達到300單/每秒業(yè)務(wù)的要求就會擴容。你CPU連續(xù)超過一段時間都超過了75%，那好生成一個Pod。很簡單，所有這一切源于需求。我們剛剛提到了517電信日，訂單的業(yè)務(wù)量增加126倍；京東618訂單量也相當(dāng)于平時10倍，這些都是給我們傳統(tǒng)方式帶來挑戰(zhàn)的。像剛才金融的方式，就很難解決這個問題。

我們可以看到在應(yīng)用級別的可用性，以及節(jié)點級別的可用性和數(shù)據(jù)中心的可用性，我們都可以以簡單的例子進行分享。其實我們與電信客戶做了很多的設(shè)計，跟金融的也有很多，今天舉出這兩個例子，主要是讓大家進行對比。很多時候，我們在進行一個轉(zhuǎn)型，轉(zhuǎn)型的過程中怎樣進行參照和思考，這是我今天給大家?guī)淼姆窒淼闹饕獌?nèi)容。

轉(zhuǎn)載網(wǎng)址：https://mp.weixin.qq.com/s/7L...