基於DevOps、微服務以及k8s的高可用架構探索與實現

前言

本文給你們分享的題目是《基於DevOps、微服務以及K8S的高可用架構探索與實現》。整個企業的高可用架構面臨不少的挑戰，面向微服務、容器化以及敏態交付，是咱們如今的三駕馬車，而今天提到的一個比較接近的概念叫Kubernetes、DevOps和微服務這三駕馬車也可以幫助企業級應用解決他們傳統的一些問題。
本文給你們分享的主要內容都是從金融和通訊領域中的具體案例總結而來，經過此次分享但願對你們能有所借鑑。主要內容包括企業級高可用性架構面臨的挑戰，面臨這些內憂外患的挑戰咱們應該怎樣作才能突破這樣的困境，有哪些原則和方法。

而後Kubernetes、DevOps和微服務這三架馬車如何各司其職爲咱們帶來很好的高可用性架構，以及你們也知道面臨的各類彈性的擴容需求。好比說咱們的客戶在517電信日的時候，他們的需求多是平時業務量的120多倍，這樣的狀況下咱們怎樣進行彈性擴容，這都是我要跟你們分享的內容。

企業級高可用性架構的挑戰

企業級高可用架構面臨哪些挑戰，其實有不少，可能有遇到天災的挑戰。

好比說2011年311大地震的時候我正好在東京，當時在作一個金融系統的相關工做。那次大地震致使不少不少的問題，雖然大地震不是在東京發生，可是仍是給咱們的系統形成了影響。

當時根據咱們的系統和容災備份中心進行合理調整，保證了咱們的客戶，由於咱們的客戶也是整個亞洲很大的一家銀行，保證他的業務正常運行，這一切都是咱們提早須要考慮才能作到的。

除此以外還可能有不少人爲的Miss帶來的問題。好比說，咱們的一個銀行客戶，誤刪除根目錄，這樣的事情在十年以內發生了兩次，其實只要保證節點的冗餘性，就不難解決。

咱們說企業級高可用性架構面臨的天災人禍的挑戰，咱們怎樣才能保障它。

咱們要事前考慮好這些因素。好比說咱們可能會有應用程序的異常退出、有操做系統宕機、服務器的宕機、停電、大地震、人爲操做失誤、訪問量忽然增大，本來是沒有問題的，咱們企業是高可用的，可是忽然業務擴展了100多倍。

咱們在設計時是有一個原則，好比按照10倍設計，按照1.5倍測試，按照1.2倍發佈這樣都是能夠的。可是忽然擴大100多倍個人架構是很難實現的，因此動態擴容也是一個重要的課題。

這些挑戰有這麼多，其實咱們還能夠把總體的變得更加複雜。整個系統很是很是複雜，在整個金融領域當中能夠看到複雜的架構比比皆是，複雜到什麼程度呢？

舉個簡單的例子，日本超大銀行的核心外匯系統來講，它大概有1500萬行代碼，咱們以前還討論過1500萬行代碼是什麼量級。2006年我在作松下手機的開發時，總的代碼大概是600萬行，因此是3個手機的量，咱們並行編譯須要8小時，有4種操做系統，5種編程語言，倒不是說設計架構時就要變成這樣，是由於很複雜的業務結合在一塊兒就已是這樣的現狀。

整個這樣的一個系統，怎樣才能保證高可用，咱們有不少不一樣系統的集羣，整個結合起來這麼複雜、龐大的金融怎樣才能保證總體的可用性，並且咱們還要重構。這些給咱們帶來都是很是大的挑戰，並且變動愈來愈多，頻度也愈來愈大，還要求穩定性，由於咱們的客戶都會要求，你又要快又要好。

他們的要求也不過度，可是對於咱們的實現來講，這實際上是很難的。客戶有的時候說我就改了一個Bug爲何不讓我上線。這麼大的架構我全編譯都要8個小時，你改了這一行bug，那編譯的過程你看不見嗎，1500萬行代碼，要編譯3個安卓手機。可是這些客戶不會說，他會說個人同行他們作的就這麼快，這都是咱們面臨的壓力。

今天我也會給你們舉一些案例，金融我我的接觸的行業中也分爲到兩種，有傳統的金融，他們仍是以穩爲主，今天的一些案例中就是一些穩的，還有一些是快的。因此咱們的容器化並不必定都是須要快。

咱們講三架馬車，這三架馬車到底怎樣開，開起來穩不穩，怎樣進行擴展，這過程當中咱們須要注意什麼，咱們有些實踐，不敢說最好的，可是能夠給你們帶來借鑑。

高可用性架構總體設計

整個來講高可用有這麼多的挑戰，如何進行總體的設計和架構。我這裏的話列出了一些簡單的點。

高可用性架構目標

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

因此咱們講總體業務的連續性和穩定性，對於咱們高可用性架構是最重要的。

咱們業界常常說幾個9的目標，咱們講99%實際上是系統基本可用。99.9%，這個系統是具備高可用性的特色，這是說，咱們一年能夠有8.8個小時能夠把咱們的系統停下來。更多來講，好比說銀行，咱們更可能是作到4個9。這也結合了2017devops現狀調查報告來講，高績效的企業，他的業界banch
mark，平均下來他的MTTR的時間大概在一小時，也就是你的系統停一次，一年大概保4個9，若是停兩次的話，那4個9的高可用就保不住了。

可是咱們不必定要咱們的系統必定是爲了衝幾個9，要看業務需求是否須要達到這個狀況。我給客戶作的時候，會跟他說你的高可用目標，爲何先列目標，由於目標定下來後，你的成本就會出現，若是1500萬行代碼所有要4個9或者5個9的，其實咱們是作不到的。咱們核心的系統、關鍵的領域，甚至是2個9都無所謂。

有一個二八定律，80%的功能客戶基本上不多用，咱們作的很複雜的功能，客戶都不用，這也是一個現狀。因此那些東西並不必定要達到4個9的可用性，因此目標設定很是重要。

除此以外，RPO和 RTO，從業務恢復的角度以及數據連續性的角度，對咱們高可用性進行總體的規劃。咱們國家2007年發佈了容災備份相關信息產業的標準，將RPO和RTO分紅六級，你們有興趣的能夠看一下，其實不一樣行業在作的時候應該是先定目標，這個成本就出來了，而後再往下作高可用架構的設計，這樣才能往下細分。

好比咱們要達到5個9，你一年只有5分鐘，我要這樣作。好比說咱們的應用程序忽然停了，既然停了把它重啓起來就能夠了，不管哪一種方式都是這樣的。可是關鍵是你是5個9，一年只有5分鐘怎麼辦？你的策略就不同，你是否是應該保證兩個方式雙方都能正常運行的時候你再起另一個。因此總體策略不一樣，成本也會不一樣。

高可用策略和手段

總體的策略和手段有不少。咱們提升可用最重要的一點是冗餘。

咱們會使用冗餘的方式，你的一個application宕了，它要能訪問，那必定是在另外一個地方有備份，客戶纔會訪問到。若是你的Note也宕了，必定是其餘的地方也有備份。咱們保證Application在一臺機器上有多重運行，若是這臺機器宕了的話，在另外一臺上也有運行，不管是哪一種方式，它都是基礎的策略。

除此以外，咱們會結合成本，作Active-Standby或Active-Active的方式，而後咱們作高可用的架構實際上是說，咱們的兩臺機器都放上去，一臺機器一直是作一主一備，這對客戶來講成本投入沒有這麼好，我看不到收益，因此咱們通常作Active-Active雙活。

好比咱們作集羣是保證節點級別的可用性。咱們作服務多重化是保證應用層級的高可用性。咱們作容災備份，就像剛纔給你們舉的例子，2011年日本大地震，若是咱們給客戶沒有作容災備份的東西，他不可能依然能保證在整個過程當中是可用的。

雖然是一主一從，可是二者相互結合仍是能保證他的服務正常運行。可是除此以外，還有不少的因素。成本是無處不在。並且咱們的客戶也會知道，容災備份中心作成兩活實際上是更好，可是成本會發生更大的變化。

另外咱們平時的訓練，由於這跟技術無關，可是又很是的重要，由於我看過不少的系統，他們作得都很好，可是爲何他不敢切。

我看過太多很好的系統，可是有的系統我也沒見過，像2015年左右，紐約交易所停了218分鐘，這麼龐大的一個系統停了218分鐘，後來我查了緣由，他們說是由於技術的緣由，後來我就沒看出由於什麼技術的緣由。

可是我相信他必定會有容災備份的策略，可是爲何不切。實際我接觸過不少企業，他們訓練不到位，致使他們不敢切，切過去OK，切回來怎麼辦？可能就會出問題。

除此以外，還有橫向的擴容，咱們的波峯來了，咱們何時才能進行擴容，因此這個時候咱們須要考慮。咱們講跟DevOps進行結合，咱們監控作到咱們可以肯定何時進行橫向擴容。

好比說DevOps的透明化和咱們總體的可視化結合起來，而後這些可以保證咱們系統的高可用性進行很好地對應，這是總體的策略和手段，固然還有不少，我只是列出了這幾個常見且重要的點。

要素和原則

咱們叫容器化、微服務和DevOps，是咱們如今應用容器化的三架馬車可能更敏捷的對應。由於K8S自己就是容器和容器編輯的平臺，能夠很好地進行管理。咱們使用這三架馬車如何才能保證咱們的系統更加可用、方便和靈活。K8S是用什麼樣的方式來保證它的高可用性，首先有三個重要的點：

• 第一點，K8S是以容器化爲基礎的，運行在它上面的應該是一些容器，以容器形式存在的這些服務，K8S 平臺保證了這些服務它自己是可用的。咱們傳統的，本身寫SOA其實也是同樣的，只是k8s作的更好，它把這些變成透明化了。
• 第二點，咱們保證K8S自己是可用的，由於K8S保證它的集羣運行在這之上的服務是ok的，可是同時，怎樣才能保證K8S它也是高可用的，消除這些單點咱們也會說到這些。
• 第三點，當咱們業務的波峯來的時候咱們如何處理。

而後咱們講微服務，微服務爲何要引入，各個企業有本身的想法。咱們引入微服務有不少本身的想法，好比要簡化，要解耦，要使咱們的服務可以獨立部署，它要可以進行整個是無狀態可回滾的，整個來講咱們是爲了讓容器化變得更加簡單，這些微服務要按照這樣的策略進行設計。

咱們講DevOps是怎樣作成橋樑和紐帶在微服務和K8S之間進行溝通。首先咱們使用DevOps的理念，微服務的一旦落地，它帶來的好處同時也給咱們的部署也帶來有壓力，因此咱們如何作持續集成和持續交付，使得這些部署，應微服務帶來的部署這種壓力獲得緩解，這是咱們Devops實踐須要考慮的事情。

同時，咱們經過環境的一致性，經過考慮安全的因素，使咱們高可用性在不少方面獲得總體的考慮。咱們提到DevOps跟K8S自動的可動態的橫向的調整，K8S如何才能知道咱們何時進行橫向調整。咱們須要監控的機制，而咱們DevOps的實踐中，咱們須要讓整個的過程是透明的，可視的，因此咱們經過使咱們的系統具備總體監控的能力，讓咱們知道何時該橫向擴容。

這是一個很簡單的例子，咱們說總體的作一主多從的K8S架構的話，能夠看出，這就是簡單的K8S的構成。K8S能夠作成一主多從，同時咱們的ETCD使用集羣的方式來保證它的服務OK。消除單點的話就是Master一主多備，這是很是典型的很簡單的思路。不管哪一種方式，咱們都是要保證它的冗餘度獲得保證。

如何使得咱們的微服務更加專一於業務的開發，咱們在與咱們的客戶進行實際應用時也使用一些傳統開箱即用的，好比說Spring Cloud等一些組件。幫助他總體的下面的框架基本上就不用再進行開發了。

咱們傳統用Tuxedo時，都是要本身寫。忽然會發現壓力一下所有減輕了，咱們只須要注重業務的開發，忽然發現很是順暢。

咱們講DevOps他更多地是一種融合，因此咱們最佳實踐進行結合，經過自動化流水線，保證了自動部署和自動集成的穩定性。

經過可視化的監控來確認咱們何時能夠動態擴容，經過一致性的環境來保證整個的流程是更加順暢的。

因此這是咱們總體的一個架構和思路。在不少的系統之中和客戶進行推薦的時候咱們基本上都是用這樣的方式。

Kubernetes的基礎服務

下面咱們講三架馬車第一架Kubernetes如何提供基礎服務。這些都是Kubernetes的基礎知識，咱們能夠很容易地獲得，可是咱們講使用Kubernetes的時候，在整個的架構中起到什麼做用，仍是剛纔提到這三點。

第一點，咱們使用Kubernetes的RC或Daemonset這些東西，咱們保證了這些服務是能夠自愈的，簡單來講就是有人幫我檢測、重啓，這些策略均可以進行調整的。

第二點，Kubernetes自己是須要ETCD和Master始終是可用的，因此咱們須要經過具體的策略來保證咱們的K8S自己也是可用的，因此這兩點能保證整個集羣是OK的。咱們Kubernetes提供基礎的平臺和服務，可是若是你的平臺和服務它自己是不穩定的，也是沒法達到整個系統高可用的。咱們講這個平臺應該比較厚重，同時也要比較穩靠，這是咱們須要考慮的，咱們實際跟客戶落地的時候，這些點都須要考慮，我列出了其中重要的幾點。

咱們消除單點的ETCD。ETCD是CoreOS發佈的關於鍵值的分佈式數據存儲。在Kubernetes之中，咱們使用apiserver跟它進行交互，若是它不穩定，咱們數據的保存就沒有保障，因此咱們要消除它的單點，那作一個集羣就能夠了。

咱們作一主多備的Master。咱們的Active Master一旦壞掉了切到另一個，很簡單就是冗餘，多放兩個在那裏，壞了就切過去。理論上來講都很是簡單和單純，可是就用靠這種單純和簡單的方式，就能保證咱們的客戶的總體系統比較穩定。

就像在311地震的時候，咱們給一個日本的核心銀行的系統，作了一主一從的方式就能保證系統是高可用，因此咱們事前須要考慮，同時考慮成本和總體策略，而後給客戶提供一個價錢和其餘東西結合的一個方案。

第三點，就是Kubernetes可以應付如今傳統金融在作動態擴容時很難作到的一點。使用傳統的方式，當客戶想追加節點的時候很困難。客戶想增長一個節點時會發現很是困難。

咱們傳統的方式作集羣的話，咱們能夠作雙機或者多機，或者是作其它的均可以跑。可是我要加一個節點很困難，你們知道若是咱們開始作架構時，上來就是說你使用了Kubernetes這種神器，或者是你程序自己都是容器化的，你就碰不到這種困難。

可是若是你從十幾年前開始作架構，會看到傳統的這種架構一步步怎樣走過來的時候你就會發現，這些真的是很厲害的神器。

爲何傳統金融在往這方面靠的緣由，咱們加一個Node的時候，作一個雙機集羣，咱們要本身劃磁盤，本身劃磁盤的仲裁，作心跳線，作設定。雖然作得很快可是也特別費工夫，關鍵的是對客戶來講，你要把這些機器停下，這些是要命的，並且花了不少的錢，並且對於K8S平臺來講這些都是透明的。

這是對客戶來講很是有意義的點。也是咱們推它的緣由。在使用監控，首先第一步看到整個的趨勢，問題會不會出現警告。同時對咱們的動態擴容提供輸入。

對動態擴容提供輸入，咱們整個動態擴容怎麼作？咱們作了簡單的整理。其實一旦你把全部的條件作好，剩下的都很是簡單了。

咱們有些通訊的客戶可能在波峯的時候可能他的具體的業務量達到平時的一百多倍，這種狀況下怎麼辦，找到時間點擴容就能夠了。

咱們仍是按照步驟，定義業務、系統資源的指標，在這種狀況下擴幾個pod，而後採集數據。那咱們怎麼知道這些是能夠進行擴展的，而後具體的監控是實現說我看系統的日誌和業務的日誌咱們能夠擴了。在Kubernetes或Swarm層上面一條命令就能夠作到了，這就已經很簡單了。

可是最關鍵的是咱們以前須要作的這些，監控怎樣作好，咱們給客戶的最佳實際案例是這樣作的，不要上來就開始作這個自動。自動化其實能夠作到最後再作，咱們要保證整個流程是平穩的。

好比說舉個簡單的例子，咱們在金融的系統是這樣作的，咱們若是想作什麼樣的調整，好比說我要作這樣的動態調整，我會把整個的東西打到日誌，把空跑的狀態確認出來，而後根據過後咱們進行分析他算錯沒算錯。作完以後，再作動態的擴展，動態擴展至關於一個利器，很好用，可是用壞了也很危險，在具體實踐的時候，咱們跟客戶實踐了之後纔會作。

若是Kubernetes提供了這樣一個基礎服務，微服務就很輕鬆了。好比說咱們傳統在作Tuxedo架構的時候，咱們作微服務的自動重啓，壞掉了怎麼辦？若是使用本身的SOA架構，你在裏面寫循環，你本身總不能啓本身，須要有一個守護進程在後面作，守護進程宕了怎麼辦？由於企業級高可用架構，尤爲是銀行不可能像目前初創公司的作法，他要求他的系統必定是很是穩定的，你守護進程壞掉我也得保證，因此咱們通常會再寫一個，再壞了怎麼辦，沒完沒了的，因此那個要靠監控來作。

你要使用Tuxedo的話，就很簡單，在裏面設定一個何時這個Sever等於Y，這個架構基本能夠保證服務的多重化或者節點之間的控制。可是有一個很很差作的東西時什麼呢。這是一個總體的SOA架構，你要進行所有編譯，這意味着你作服務動態調整要經過編譯來作，這就很麻煩了。這個相對於Kubernetes的方式很不靈活。

專一於業務實現的微服務架構

使用了Kubernetes這種方式後，就會更加靈活，使咱們的服務專一於服務的架構開發。

即便是這樣，咱們依然有不少的東西須要考慮，咱們爲何進行微服務的設計和架構，這有不少不少的痛點。

就是說咱們大型的系統一旦出來，就像多米諾骨牌同樣，你拉其中的一塊，就會整個轟塌。以我十幾年的工程師經驗，這個過程是很是痛苦的，痛苦的人都知道怎麼來的。

我只改了一行代碼，爲何整個程序宕了，整個應用毀了，這種狀況會出現的。由於隨着年久失修，這些大型的系統，它會成爲巨石同樣存在，誰都不敢改，改起來成本又很是大，維護的成本也很是高。

我接觸過不少大型項目，跟他們一塊兒作他們作得很是優秀，可是即便這麼優秀的企業咱們仍是發現了不少有意思的事情。

好比說當年Alpha推出市場的時候，本來在Alpha上運行的話咱們轉到Hpux上，固然有一部分跑到了IBM的AIX上，可是不管你跑在哪一種上面，若是有C這種經過編譯型語言的話，你要進行從新編譯和優化。

一個頗有趣的規律就是超過百萬行級的代碼咱們都會發現很是低級的bug，無論系統多麼優秀。有一條到如今沒破，咱們知道像C這種父子語句和判斷語句確定會有用混的，If寫成父子語句的，有專門的把兩行寫成一行，就是爲了省一行空間的寫法也有。咱們明明確確的根據上下文判斷就是一個進或不進，改不改。這就陷入兩難，由於它有上百萬的代碼。

一個工程師我只負責之前在Alpha上面跑，如今在Hpux上跑，大家不是跟我說，我只是換一個機器，剩下都OK嗎，爲何不OK了？因此咱們不敢改，由於不少時候時錯錯得正，你改了這個地方其它地方還有一個錯，最後結果正確的我怎麼知道。

這個難點在於，仍是整個的耦合度沒有拆分，這種狀況下若是你的功能很小的話那就很好辦了。若是部署可以獨立化，解耦作得很好，簡化作得很好，規模又小型化，這樣咱們知道這塊影響到哪兒，大不了我把它從新用backup運行。我知道它影響到哪一個地方，只有不知道，咱們才懼怕，並且不知道可能真會出現各類問題。

因此這個纔是咱們實際與企業級客戶在推的時候遇到的問題，企業級用戶痛點也在這裏，由於客戶不少時候就問我，我改一行代碼爲何要花這麼長的時間，我跟他說一天爲何花這麼長的時間。確實要花這麼長時間，由於你係統太複雜了。咱們解耦之後能夠治這個病，可是整個的過程也會帶來其餘的問題。因此咱們整個過程須要進行考慮。

咱們使用Spring Cloud，可使咱們過程當中更加方便。經過適當冗餘，使用多個Eureka服務端，這樣就能保證保證服務註冊不會中止。若是咱們作Tuxedo的架構話要本身寫，咱們使用Eureka就更加方便。

咱們還要考慮負載均衡，像Ribbon這種客戶端。我想你們作過SOA開發，對這種策略都不難進行，就是有所反饋。好比說咱們就講，我壞了應該怎樣重啓，要加權、隨機要重啓，這臺壞掉了我看另一臺機器有幾個，跑在另一臺機器上，本身寫這個很痛苦的。這些若是使用了開箱即用的東西會總體地加快咱們的速度。

除此之外還有不少，我再列舉一個配置中心。我爲何提它呢。咱們講三架馬車，最終一架是DevOps，像Spring Cloud也好，咱們推DevOps時，咱們推薦使用一套的部署機制，你不一樣的環境能夠經過不一樣的配置來實現，咱們認爲Spring Cloud是它對DevOps的一種微服務發佈方式，咱們經過總體的具體實踐進行結合使得發佈更加方便和順暢，更多地是與DevOps進行結合。

有這樣的東西開箱即用，對於微服務，咱們就很容易寫咱們的SQL語句，實現業務邏輯，就會很是簡單，實際在使用的時候，尤爲是容器化的過程當中IP會變來變去，這些問題都會帶來困難的點。可是想一想你要從零開始建立這些東西，它的成本是值得的。雖然有些人說你沒辦法作這些東西，可是你看看傳統企業痛苦的程度。

DevOps助力全生命週期的高可用性

咱們講DevOps可以在其中起到橋樑和紐帶的做用，輔助咱們三架馬車，容器化的服務可以更好的落地實踐。具體地有哪些點，我列出了這樣一些點。

環境一致性

咱們強調開發和測試環境、生產環境的一致性。由於開發環境，常常會有不一樣環境的開發，可能會帶來不少的問題。測試環境的話，因爲測試和開發環境的不一樣也會帶來問題，好比說你測試的代碼和開發的版本不同，這些沒必要要的消費都會帶來沒必要要的時間。

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

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

2014年的Heartbleed你們印象很深入，那個心臟流血的，那個一直在流血，心臟就會失血而死亡，你可能就要搭橋，全部的買單都是企業級的客戶來作，它要爲你對安全的忽視來買單，這一切有多是咱們不能承受的，由於它在心臟上。我建議你們必定要下這樣的東西看一下到底有多少的CVE。

而後生產環境保持一致性，這是理想的，但至少要達到 Infrastructure as Code。這考慮到什麼呢，若是你的生產環境的一個節點忽然壞掉怎麼辦？尤爲是那些年久失修的系統，客戶說給你拿一個機器給我當即換上，這是很簡單的事情，那有太多的手工做業，你把這些手工做業所有都變成代碼放到你的SVN或Git上，必定要這樣作，咱們在推這樣的實踐過程當中也碰到不少的慣性的阻力，可是咱們認爲這樣的實踐很重要。

可定製流水線

咱們講可定製的流水線是很是重要的，安全檢查也很是重要。能夠定製的，能夠提升咱們CI/CD的流水線。可使用開源的工具，也可使用商用的工具。根據DORA調查，你使用可定製的話能夠帶來更好的效果。

可視化

監控，可使得彈性擴容更加容易。

咱們的一些客戶，咱們平時的業務量跟波峯的業務量相比是1%甚至更多，這種狀況下怎麼辦？

彈性擴容需求下的高可用性

咱們講的三架馬車每塊須要作什麼事情，在容器化的基礎之上進行解耦和優化，同時DevOps要監控、判斷，同時最重要的一點，咱們要強調一下DevOps咱們提倡的理念是Fail Fast，我我的認爲這不是爲了讓咱們die fast，你要作好咱們的Plan B，咱們recover plan，若是一旦失敗了怎麼辦，若是事前不想好那真的有可能die fast。

因此咱們提倡跟客戶說你要Fail Fast，要戴好安全帶，這點很是重要。根據DORA的調查，2017比2016年相比，咱們的速度獲得了明顯的提升，可是那些低績效的企業，他們在MTTR的修復時間比去年還要惡劣，這爲何？快了可是沒考慮穩。

咱們使用K8S可以很容易的進行橫向擴展。具體的策略，經過肯定交易的指標和資源使用狀況，確認何時進行水平擴容，取一下業務日誌和系統日誌進行監控和計算而後告訴K8S擴容它就擴容，就是這麼簡單，可是實際應用的時候有不少的項，你在這個過程要保證安全，穩定地擴容。

案例分享

案例 1

咱們經過應用的多重啓動，來保證應用的可靠。Front office和back office 進行前端的業務和後端的審批，這都很是常見，大部分都執行這樣的作法。

另外，咱們過去傳統來作，能夠看到總體的集羣很是複雜，你有文件集羣、應用集羣、認證集羣、RAC集羣。並且這些資源相互之間協調很是痛苦，若是你出了問題了，依然有很大程度的可用性。

但全壞掉了，咱們經過什麼辦法。經過共享存儲和網絡結合起來，跟容災備份中心結合起來，它的數據一旦過去以後，另一套系統結合起來，可使它可以保證數據中心級別的可用性。

應用級別可用性，節點級別的可用性以及數據中心級別的可用性，咱們都能達到。同時，這種傳統的問題點，客戶也問過我這個問題，他說，我加一個node，大家爲何花我這麼多錢。

有一次，咱們跟他說應用級別的資源不夠了，加一個resource吧，他的文件集羣依然有resource，你告訴我應用集羣不夠了，你用它的很差嗎。我說，做爲一個工程師來講，這個很難。他說我無論爲何難，我只看到個人系統，它依然有一部分是閒的，你沒有作到。它作不到並不表示其餘作不到，好比K8S就能夠作到。

案例 2

這是一個典型的案例，是跟咱們通訊領域的一個客戶作的在PaaS平臺上運行微服務的架構。咱們也實現了多Kubernetes集羣的狀態下，咱們的雙中心的這樣一個應用。雙中心雙活，總體的話與剛纔那個例子相比是有優勢的。同時咱們講咱們實現了按需擴容，怎樣進行按需擴容，其實就是監控，監控的過程當中注意安全，咱們按期對客戶安全進行掃描。但願你們注重安全，不要認爲官方鏡像的就很可靠。

咱們會根據咱們業務的，好比說咱們達到300單/每秒業務的要求就會擴容。你CPU連續超過一段時間都超過了75%，那好生成一個Pod。很簡單，全部這一切源於需求。咱們剛剛提到了517電信日，訂單的業務量增長126倍；京東618訂單量也至關於平時10倍，這些都是給咱們傳統方式帶來挑戰的。像剛纔金融的方式，就很難解決這個問題。

咱們能夠看到在應用級別的可用性，以及節點級別的可用性和數據中心的可用性，咱們均可以以簡單的例子進行分享。其實咱們與電信客戶作了不少的設計，跟金融的也有不少，今天舉出這兩個例子，主要是讓你們進行對比。不少時候，咱們在進行一個轉型，轉型的過程當中怎樣進行參照和思考，這是我今天給你們帶來的分享的主要內容。

轉載網址：https://mp.weixin.qq.com/s/7L...