經過了十個城市的路演，華為HDG線下沙龍終于來到了首都。在北京，開發人員之多，關注的技術領域之廣，討論的話題之深入，堪稱HDG歷屆參與討論者之最。

作為另一位華為PaaS高級工程師，張琦的演講內容可以說是得到了開發者極大的關注。在《基于容器的企業級微服務平臺》的主題講解中，張琦總結了華為在微服務構建中的思考和實踐，并且結合PaaS平臺總結了如何在Kubernetes的容器平臺上實現典型的微服務模式。另外對于微服務實施后帶來的問題也進行了總結并提供了參考解決方案。

以下是他的現場演講實錄：

今天我講的主要是微服務，還有企業級、微服務、容器這樣一些關鍵字。在講這個之前我說一下，現在微服務特別火，不管是企業還是各種技術社區，微服務這個概念都特別火。我不知道大家了不了解我為什么要做微服務，或者我的應用為什么要上微服務，這個問題不知道大家有沒有思考過。我剛開始接這個任務，去設計整個微服務平臺的時候，對這個問題的概念還是有一點點模糊的。自從有一天我突然看到我這件事情，我不知道大家有沒有人騎摩托車，看我后面的衣服，速度***，安全第二。應該不是這樣的。

Martn Fowler提出一個觀點，跟我的觀點非常契合。微服務要解決的問題是什么?***是速度，第二是安全，出發點是速度***。為什么是速度***呢，它說的速度并不是我用了微服務之后我的程序運行更快了，不是這樣的。它說的是我的業務要更快的發生變革，我的新業務要更快的上線，基于這個契機才出現了微服務這個東西，才更多的人越來越喜歡微服務，越來越想去實踐微服務。第二是安全，它說的安全，我們看微服務，包括看Cloud Native的應用，所謂的安全不是單點安全，不是一個應用就一定要做成最安全的，而是說我整體系統最安全，這里的安全說的是可靠運行，說整體的系統要可靠運行。再細講有幾個方面，一個是可控的，另外就是要有更好的容錯、隔離這些機制。所有剛才說的快速開發、快速上線，業務快速變更，保證整體系統的安全、可靠、運行，整體的這一套東西是想你去實踐微服務，或者我們看到微服務這個圈子的東西。這是一個題外話，當然這是我的一個思考，不知道在大家的想法里面微服務到底是什么東西，將來大家可以多多交流。

今天我來講一下華為在微服務，還有基于容器構建這樣一個企業級的微服務的運行平臺，這里的一些實踐，還有一些我們的想法。因為這個講到了企業級，所以今天的議題是這樣的，首先是一個業界技術發展的趨勢，還有挑戰。另外還有微服務，還有PaaS平臺。大家都知道華為的PaaS底下是基于Cloud Native來做的，Cloud Native和微服務有什么關系，怎么變成企業級的平臺，這一塊會有一些講解。還有大家很多時候被忽略的一個問題，大家很多時候會認為我上了微服務萬事大吉，實際不是這樣的。實際上了微服務之后，你剛剛給自己挖了一個坑，后面還有很多很多需要你處理的東西，會帶來很多很多的負面效果，這一塊我們介紹一下。

首先看一下企業IT技術的應用曲線，這是原圖，沒有打星的，沒關系。我們看這個趨勢是這樣的，一個新技術出來的時候，企業級的IT對于新技術接受度一直是要遲鈍很多的。在企業級之外的，互聯網或者其他的一些行業，它會首先接受這個新技術。但是這里面最最重要的是，在接受了一段時間以后，企業級的IT最終或者無奈的接受這種新技術，改造他們的系統，這是一個企業級的IT技術的發展趨勢。

我們再看一個現象，2014年很多人認為是企業上云的元年，在2014年的時候幾乎沒有人考慮我想上docker上我的生產環境，用容器上我的生產環境，絕對不會有人這么考慮。或者說2014年容器根本不可能進入企業級IT的選擇名單范圍之內。到了2015年的時候，所有人都會把這個容器列為技術研究的一個方向。現在到了2016年的時候我們更看的很清楚了，很多企業級的IT項目現在已經開始嘗試在生產環境下使用容器了。

另外的一個趨勢是2016年的時候，可以在網上找到這個技術趨勢，技術熱度的報告。微服務這個詞，或者這個技術，已經成為僅次于物聯網和認知計算的第三熱門的技術。雖然它不是那么高深，那么大的一個東西，但是它已經被列為第三熱門的技術。

我們就看這張圖，怎么會出現微服務，在微服務出現之前是什么樣子的，到底有哪些問題需要解決，所以才出現微服務，就是這條曲線。我們傳統的應用大家應該非常清楚，我說的這些產生應用更多的是基于這個企業級的，企業這個領域里面來看的。在企業級的IT的應用里面，它之前的一個應用開發狀態基本來說是這樣的，首先制定一個統一的產品發布計劃，分到各個組，或者是對一個大項目的話，如果我們看到銀行項目，看到電信項目，可能各個模塊會有不同的承包商，不同的ISV，到一個公司里面可能有不同的開發小組，來承接，來開發。開發完了之后，會有一個集成開發的階段，大家所有人起來的模塊拿到一塊再集成開發，經過一輪集成。到***測試發布，發布完的產品要統一找一個產品替換掉在線運行的系統，來統一的找一個時間窗口來進行升級，這是我們在之前的一二十年里面，或者大多數人更熟悉的軟件開發或者發布模式。

這里面可以看到一些問題，一個就是我們的產品發布計劃肯定是統一執行，統一制定的，到執行的時候又是分開執行，到***又有一個集成的過程。在這個里面，首先各種各樣的協調，各種各樣的組織，會耗費很大的精力，是一個很大的成本。另外你***要集成到一起，通常大家的開發都會基于一個相同的技術來進行開發，或者相同的技術鏈，或者相同的語言進行開發，這樣才能讓你后來好集成。***一個問題，最重要的一個問題，我們很難做到系統永遠在線，我們走是需要一個窗口進行隔接也好，升級也好，總是需要做這些。這是傳統的系統開發看到的問題。

我們看看微服務化的軟件開發，在微服務化的系統開發里面它整個的流程是這樣的步驟。首先就是產品發布計劃是各個微服務自己來制定的，每一個微服務都按照自己的產品發布計劃，自己升級，自己演繹。每一個微服務開發技術都是各種各樣的，用不同的技術來開發應用。到***通過DevOps的方式部署生產環境，部署的時候要同步灰度發布或者滾動更新這樣的技術，讓我整個的系統永遠在線。通過這種方式，可以很好的解決剛才說的那些問題。啊

所以我們可以看到Martn Fowler對微服務的總結，微服務的概念最開始的提出是Martn Fowler，但這只是說他對這個概念有一個很好的總結。但實際上在2009年的時候已經實踐了微服務，就已經實踐的非常好了。我們看Martn Fowler對它的總結是什么呢?服務模塊的邊界更清晰，這是獨立部署，允許技術多樣性，這是微服務帶來的一些好處。

現在大多數的宣傳，大多數技術的講座，大家都在講微服務的好處，或者你怎么做到微服務。實際微服務帶來的壞處，Martn Fowler同樣也有很多的總結。這里列舉了一些，比如說分布式編程的大，有風險。首先我們說微服務，我們把一個單體應用拆成一個微服務。其實這件事情并沒有那么高深，我們就是把一個普通的應用進行分布式化了。實際上我們就是在構建一個完全的分布式系統。所以對于一個分布式系統來說，對它的管理，對整個分布式系統的開發難度是非常大的。

另外需要處理分布式系統的一致性，普通時候我們做一個單體應用，數據一致性通常是通過數據庫的事務解決的。數據庫事務很簡單，我們只要把所有變化的數據都用一個數據庫來解決，靠數據庫系統提供的事務就可以保證各個表里面數據的一致性了。變成了分布式系統以后，別說我們用的不是同一個數據庫，有可能我們用的都不是數據庫，我們有可能一部分數據存在文件里面，另外一部分存在數據庫里面。下一個微服務，它的數據可能存在一個MangoDB里面。在這種情況下我怎么保證那個數據的一致性，這是一個非常麻煩的事情。

另外增加運維的復雜性，當然這個還是說一個單體的應用拆成一個分布式系統以后，原來只需要管一個應用，我現在要變成整個系統里面那么多應用，我要管那么多的應用。原來我手工敲一敲命令就可以，現在我管幾百個應用，在那兒部署著，在那兒跑著，我敲一敲命令，工作量就變得非常大。這就是微服務同時會增加運維的復雜性。

我們看這個，這是一個(12：55)對于PaaS，還有微服務的一個總結，這張圖也非常經典，我看國內有很多公司也會引用這張圖。這張圖講的非常清楚，這是整個PaaS系統，包括微服務在整個PaaS系統中的位置。它分成幾部分，***部分是所謂的接入層，它包括像ELB、APIgetway。我們的數據請求從前面進來以后，到接入層，繼續往后走，再往后有一個(13：38)。這個圖是一個邏輯分布圖，在實際的運行中有可能整個1和2合成了一個組件，這都是有可能的，但這是一個邏輯的分層。

再往里面走這就是微服務整個的一套的運行環境，3這一塊稱為源數據管理，源數據管理其實也就是我們非常熟悉的，微服務注冊的信息，它的配置管理信息，類似于這樣的一些管理組件。4這邊是微服務的運行態，就是它的運行時。我們可以看到，這個非常小，就是所謂的負載均衡。在負載均衡微服務的實踐里面，很多時候又叫服務發現。就是我想訪問一個微服務的時候，這個微服務有10個事例讓我選擇，我具體訪問哪一個事例。這個問題很多時候也可以叫做負載均衡，我就是按照這個負載均衡的策略去訪問其中的事例就好了，實際這也是一個服務發現的過程。后面我會詳細講一下。

我們再看看5里面。在一個PaaS系統里面有非常多的服務，剛才我們說的微服務是構成你應用的一個單元。在這里還有一個所謂的后臺服務，或者平臺服務。如果大家熟悉(16：10)，它對這個平臺服務有一個非常好的抽象，就是它通過Service Broker的方式，接入平臺外的服務。也就是說一個服務對于一個平臺來說，它有自己的生命周期，包括服務的創建，服務和應用的綁定，所有的這一系列的生命周期，它用后面的Service Broker的方式管起來。實際上是一個PaaS平臺，它的service更多的是路由的概念，不是平臺服務的概念，確實沒有。你如果去查CNCF社區，在CNCF基金會里面已經定義了這一套的標準。所以這個PaaS和微服務的模型是非常嚴謹的。

講了這些以后，下面這一塊，6是所謂的自動化的流程。自動化這一塊包括部署自動化、運維自動化，把所有的這些東西都給，直接就叫自動化了，但是這塊打開的話還是有非常非常多的東西。7這邊是一個遙感，用這個詞我覺得特別形象，遙感系統是什么呢?比如說我們的月球車，我們把月球車放到月球上以后，我們對這個月球車撞開的監控，對它出了問題要指揮它修復，不可能人上去再去修復，再去監控，我們必須得靠事先做好的程序去控制它，去做這件事情，這是一種遙感。我們的應用部署以后，跑起來以后也是相同的情況。這個應用只要是運行起來了，就好像我們把這個月球車放到月球上去是一樣的。這個時候對于運行著的應用，對于它狀態的監控，對它出現故障以后對它的修復，對它一些運行參數的調整，其實就是類似于一個遙感的過程。實際對于微服務來說還有很多微服務相關的監控指標的收集，這個后面也會有一些介紹。我們看***一個，8就是整個系統認證、健全這樣的service。

所以這么來看的話，一個版本的PaaS平臺，它的最小范圍是這個。我們這里說的是最小范圍，PaaS平臺是什么，或者微服務是什么，現在沒有一個邏輯公眾的標準。但是如果你想達到預期的目的，就是說我們用一個平臺能夠整個管理起來微服務，讓我們的微服務在里面能夠很好的運行，如果想達到這個目的，這樣一個系統應該說是一個最小的集合了。

下面我來介紹一下用Kuberentes來構建微服務的平臺。剛才介紹的是PaaS平臺，最開始我又介紹了微服務，為什么現在帶出來這個PaaS平臺，帶出了微服務以下的這個東西。其實是因為我們看到在一個普通應用變成微服務之后，會帶來各種各樣的麻煩，各種各樣的問題。我們如果還是想用傳統的方法去解決這些問題，去管理你的應用，去管理你這個分布式化的應用，實際上難度是非常大的。所以在這種情況下，包括業界很多的公司，它要變成微服務的前提是要把它的東西上云，要把它的東西放到AWS上面去。所以現在的這些云技術，我們總說容器是微服務***的載體，但實際上在實踐中你會發現，你基本上是缺不了它的，如果你缺少一個下面的平臺，這樣的PaaS系統的話，你的系統會變得非常非常復雜，非常非常難以管理，是這樣的一個情況。

所以我們來看一下Kuberentes來構建這樣一個微服務的運行平臺，它有什么好處，或者我們怎么用它來構建微服務的運行平臺。上面這個是Kuberentes的一些基本概念，我不知道大家有多少人熟悉這個，人不太多啊，下面我簡單的介紹一下Kuberentes。Kuberentes里面有很多概念，我主要介紹一下它對于應用的封裝，對于系統的封裝，運行時的這些概念，它的管理組件的概念不詳細介紹了。Kuberentes跟原生容器不一樣的地方，它是一個從出生開始就是為企業級的應用構建來考慮的一個容器平臺。所以它對復雜應用，從最開始的設計就進行非常好的考慮。

一個例子，看我們的調度單元，在Kuberentes最小的調度單元不是容器，是一個pod，這一個pod里面可以包含多個容器。這多個容器是共享網絡，它們之間可以互相進行一些數據的共享。所以它把它最小的調度單元做成了pod，一個pod里有多個容器，這個就很好玩了，這塊可以帶來更多的一些設計模式。下面我講微服務的實現方式里面，也可以借用這樣的模式。舉一個例子，大家都說容器推薦的是一個容器里面跑一個進程，你實際到生產環境下一個應用不可能只有一個進程的，至少還得有一個agent收集一些運行的情況，至少還得有一個agent去收集日志吧，這種情況下怎么辦。實際上Kuberentes用pod的概念可以封裝對于這種問題的解決，就是你的主業務在一個Container里面，你的agent在另外一個容器里面，你就可以把多個容器打成一個pod，這就是一個最小的調度單元。

從運行時來說，最主要的概念就是pod，當然它在pod之上還有一些概念，比如說ReplcaSet，原來叫Replcacion Controler 現在新的叫ReplcaSet。它對pod又有一層管理，實際上我們可以認為這是一個pod的動態伸縮管理器。就是一個pod只是一個運行時，我想讓這個pod有多少個事例來運行，這是靠ReplcaSet來做的。在這里面定義了我這個調用單元要跑5個事例，就會一直保證它一定是有5事例在跑，如果有更多的事例在跑就殺掉，如果有哪個事例死了，它會再拉起來，這是ReplcaSet。再往上的一層概念就是service，在Kuberentes里面的service，如果我們把它看成路由的話會更好理解。它實際是定義了我的這個應用，我的這個pod怎么被外面，或者怎么被其他的pod發現和來訪問的問題。這一塊有一點點像微服務里面的服務發現了，這個下面有很多規律，介紹一下。這里面的概念非常多，基本上我們主要理解Container和pod的關系，包括上面Replcacion Controler的概念，還有KPSservice到底是什么東西，基本在Kuberentes里面構建微服務相關的概念就有了。

構建一個微服務，我再講其他的后面的構建方式之前，要非常非常強調這一點，就是APIfirst，這個有很多人提，但是在很多的微服務框架里面都沒有強調這一點，包括國內用的比較多的doubleX，包括現在(27：21)。微服務它聲稱的一個好處就是，我的每一個微服務都可以用不同的語言去開發。在這種情況下，我在整個系統里面就要有一種定義統一的服務契約的方式。我的這個服務契約是什么呢?就是我作為一個服務的提供者，我能夠提供什么樣的方式，我這個服務的接口是什么樣的，你能通過什么方式來調用，這是整個服務契約。在整個系統里面，如果你用的技術棧也不一樣，每個微服務的開發時間點也不一樣，你想讓整個系統協調在一起的話，特別是一個復雜的大型的系統，API或者服務契約是最最重要的一點。所以這一點要先提。

現在大家用的比較多的一些服務開發框架，可能更多的是靠java的作為一個服務契約的。你想享受到每個微服務由每個技術去開發的話，顯然你不可能在開始的時候你的整個系統只有java語言。所以在這一塊我們是用IDL，就是谷歌的，用它來做服務契約的定義。用了這種語言中立的方式來定義以后，不管是C語言，JAVA語言，都可以通過這一個契約來進行通信。我們的使用方式在華為微服務的系統里面，我們的使用方式是這樣的，我先定義用這種IDL這種方式來定義服務接口，定義完了之后我們有一個自己的編譯器，會把它生成相應的各種語言的(29：46)。這塊大家熟悉的話能夠想到GIPC，實際上GIPC也是類似的方式，但是我們沒有用GIPC的原因是說，如果你嘗試一下GIPC會發現，它生成的代碼可讀性非常差，它是包含了服務契約，還有服務通信，所有的東西都砸到里面去了，那個東西是非常難以維護的。實際上我們只是想要一個服務契約而已，在JAVA世界里面***的服務契約就是一個pojo，我們就是想要一個pojo而已，我要那么復雜的東西干嗎呢。所以在這里面我們是用了自己的手段，用自己的方式，前面來的服務契約對于java來說就是一個pojo，對于C來說就是一個結構體，我們就是要用這種干凈的方式來構建微服務。

我們看一下微服務的實現模式，這個跟剛才容器的概念可以有相關了。基本上是兩種模式，一個就是Chassis，所謂的底座模式，底座模式的意思是說我們想實現一個微服務，沒有問題，這個微服務它從一個普通應用變成一個微服務，必然有些特殊的東西。我們如果想自己去實現這些特殊的東西，也可以，有這些東西你要去做，包括服務發現、熔斷容錯、負載均衡、自動化的配置，包括這種通過心跳的方式來報告自己的健康情況，

還有一種模式是Side-car模式，大家知道tricycle ，三輪摩托車，邊上的那個邊斗，就是Side-car。Side-car用到了剛才我們說的pod的概念，當然這不是強相關的，但是Side-car這種模式的由來是從這塊提出來的。它的基本意思就是說我所有做這些東西不用放到我的應用程序進程里面，也就是說我不用你的SDK，我用一個單獨的進程做所有的這些事情，你自己的業務邏輯，你自己的應用程序，通過某種約定好的接口，跟我這個獨立的進程進行通訊，然后我幫你去做所有的這些事情。所以這種方式在KBS里面是非常方便做的，就是說我可以把這兩個東西都可以放在一個pod里面，作為一個最小的調度單元一起進行調度，這一個pod里面的一個容器是我自己的業務邏輯，另外一個容器是我的Side-car。這種方式據我了解在國內也有很多實踐。公司名字就不說了，大家如果查網上的技術文章可以看到大家分享的實現方式，國內是有人在這么做。所以我們基本是兩種方式都做了，兩種方式都用，這種方式更適合的是如果你是一個新的應用，你要開發一個新的業務，完全沒有一些負債，你要用全新的方式來做，你當然可以用新的SDK，用新的開發方式來做。如果你有一些遺留系統，有一些遺留資產，遺留代碼，你要把它進行微服務化，用這種Side-car模式可能更方便一點，因為你不用一個SDK侵入到你的程序里面，你只要讓你的移動應用跟Side-car約定好的這種通訊方式、接口方式來進行通訊就可以了。

微服務里面還有一個比較重要的點，就是所謂的服務注冊的方式。這里面就說到服務，一個是應用的自注冊，一個是平臺注冊，這兩種方式。我們剛才講KBS里面的服務，實際上KBS里面的服務是屬于平臺注冊的方式。就是說你在Kuberentes里面可以創建一個應用，創建完應用之后，你再創建一個service對象，就會把這個應用變成一個服務，完全你不需要你應用做什么事情，是平臺做的事情。自注冊的方式就是你自己的應用，你自己去注冊。因為我們剛才有SDK了，在SDK里面處理這個邏輯，我自己上線以后，自己把自己注冊上來，變成一個微服務，這就是所謂的應用自注冊的方式。

還有注冊完之后就要被發現，這邊就是說到服務發現的實現方式，實際也是兩種，一種是所謂的客戶端發現。客戶端發現，就是說我的兩個微服務之間的通信全都是點對點的，我作為服務的消費者想去找一個服務的提供者的時候，我自己能拿到服務提供者的10個事例，我自己選擇一個我這次的通信的事例，跟它建立連接，跟它通信，這是所謂的客戶端發現。所謂的服務端發現，就是我自己沒有那個邏輯，作為服務的消費者來說，我沒有那個邏輯，我不用管這次要跟哪個具體的事例建立連接。我只是把我的請求直接丟給一個中間點，說我要消費一個B服務，你給我找一個建立連接，剩下的它就不管了。

我們看到這種其實更多的是體現了服務自治的概念，每個服務都自治，在運行期間不依賴于任何一個中間節點，這是微服務提倡的一點。而這種方式是依賴(37：34)跟你做服務發現。在寫新應用的時候更多的是出現這種方式，如果你是遺留應用，自己本身并不具備服務發現的能力，或者說剛才的幾種模式，其中的SDK是剛開始只提供一種語言的，你想用另外一個語言，也要變成微服務。更方便的方式就是這種方式，你不用做系統改善，你只要把請求丟給中間做就可以。KBS里面微服務的實現更多的是這種比較通用的方式，不需要對應用做任何改造的方式。當然各自有各自的好處，所以我們一個完整的微服務解決方案的時候，通常兩種都會有。

這塊就是一個統一的服務平臺，我們構建的，因為在華為公司，它的部門非常多，它的產品非常復雜，剛才我們說的所有的服務注冊模式，服務發現模式，都會有適用的場景，所以我們需要構建一個統一的平臺，能夠支持不同的服務注冊方式和服務的發現方式。這塊我們就是在Container，借鑒了Container自己服務端服務發現的能力，并且我們做一個自己的Controller，意思就是說Container里面的服務跟我們的客戶端發現的，或者是自注冊的服務做了一個調節，把兩種方式調節到一起，做到兩類不同的服務可以互相發現，互相通信的東西，這是我們在Container里面做的東西。好像很多人都不是特別熟悉Container，如果感興趣的話可以看一看Container自己的結構，都是通過Contreller，APIserver，Contreller(40：09)APIserver去感知到某個對象的創建，自己去為這個對象做一些工作，然后再去改變它的狀態，都是這樣的一個工作模式。大家感興趣的話可以看一下。

另外就是在微服務里面要講應用和配置分離，保證我們的程序可以在不同的環境下來部署，但是不用把包拆開，再去改里面的配置文件。所以我們一般的做法都是會有一個統一的配置中間，來專門管理配置信息。

作為一個企業級的平臺，實際還有一些額外的東西需要考慮，就是我們部署的時候有親和性和非親和性的調度問題。就是我有些部署要做親和性，就是我要節省資源，讓我的部署密度更大。另外一些應用我想用反親和性，就是想讓我的可用性變得更高，大家雞蛋不要放在一個籃子里面，這是我們在KBS里面通過親和性和反親和性調度，來滿足這種場景。

還有一個是Kuberentes的集群聯邦，在華為內部的一些應用里面，它的規模是非常大的，而對于Kuberentes來說，社區里現在應該是做到了兩千，下個應該要做到五千這樣級別的一個node，它的一個noed就是一個虛擬機，在這個虛擬機里面去啟容器，當然這個規模是不夠的。另外我們會有一些跨云使用的場景，就是一個集群是在私有云里面，另外一個集群是在公有云里面，我要跨云進行交互，這個用到KBS的集群聯邦。現在這個集群聯邦也是我們團隊在Container社區里面來主導的一個開源項目。當然在***的relesage里面就已經有了，1.4里面就已經有了。

下一個我快速過一下，我們剛才講到了一些用Kuberentes去構建一個微服務平臺需要注意的一些關鍵的點。就像我剛才說的咱們我們管殺不管埋，我們構建了微服務，我的微服務跑起來了，你在前期就要想要它會帶來很多問題，最主要的問題就是性能的下降。你把一個單體的服務，之前的業務調用全都是進程間調用，把它變成了分布式系統，跨網絡的調用。但是你不管用rest也好，還是用其他的方式也好，網絡傳輸的性能損耗是一定比進程內調用損耗要大的，所以你這個要慎重的考慮選擇微服務之間的通信方式。這個圖是我從網上找的，它列舉了各種不同的通信方式，它的網絡傳輸的效率，包括JIPC，我們可以看到JIPC是這個顏色的，它的性能差距是非常非常大的。所以在你考慮你系統的開放性，和你系統的傳輸效率來說，你就要做一個權衡。最開始要考慮好到底用什么方式來構建你微服務的之間的通信。

這個沒有時間詳細講了，就是我們做微服務的時候要考慮，最開始的時候也說到了，要考慮數據的一致性。我們做普通的單體應用的時候，更多用的是強一致性，也就是數據庫的事務。我們到了微服務的時代，用什么方式保證數據一致性的。當然強一致性也可以用，在JAVA世界里面，有WSAT標準，可以使用這種強一致性的事務保障，是這樣的原理。大體的原理是兩階段提交，都是兩階段提交，***階段鎖表，第二階段大家一起提交，中間任何一個地方出錯，大家一起回滾，是這樣的原理。這種方式一般來說在商業的中間鍵里面會提供，(46：55)會提供。如果你想用這種方式的話，也可以看開源的選擇，包括我們是基于開源來實現強一致性的事務的保證。如果你阿里的實現，在阿里***的Etas里面，是叫阿里where還是什么，也提供了這種強一致性的保證。在企業應用里面，強一致性還是很重要的。

另外在微服務的世界里面，除了強一致性以外，大家更提倡的是用最終一致性的解決方案，而不是強一致性。因為強一致性，剛才我們講的兩階段提交，它對性能的損失是非常大的。***階段要把所有的資源都鎖住，第二階段提交成功以后再把資源都打開，在這個過程中你的資源都是鎖定的，對性能的影響是非常非常大的。在最終一致性里面，***種方式就是TGC，就是所謂自己補償的最終一致性方案，你要自己去處理三個階段，在不同的階段去考慮到上一個階段出錯了，自己怎么補償，自己寫補償的邏輯。實際在金融系統里面，如果大家做過銀行的系統，金融系統，其實之前很多年數據一致性大家都是這么做的，都是要自己先寫一個正處理，再寫一個反處理，都是需要這么做的，這就是所謂的TCC的最終一致性。

還有一個是Event Driven，Event Driven就是通過消息隊列來實現數據的最終一致性。中間的過程不詳細講了，但是有兩點需要考慮的地方，一個就是我怎么保證數據的原子性。就是我一個變化發生了，我要通知另外一邊也發生變化，我要把這個變化丟到數據隊列里面。我怎么保證在這個變化發生了，本地的數據庫已經更新了，還沒有往這個隊列里面丟，這個時候中間出現錯誤了，那怎么辦，這個數據就不能統一了。所以這塊是保證每一個變化操作的原子性，就是自己的變化和變化已經通知出去了，這個過程的原子性，這塊是你需要考慮的點。

基本就是這樣，我講的這些點比較離散，但是是我認為最重要的點，在一個PaaS平臺上或者在Kuberentes容器平臺上怎么實現微服務中的比較重要的一些點。這塊我也總結了一下，是我們對微服務的實現，在我們華為里面對于微服務的實現里面來說，除了剛才說的那些那么重要的點，那些最最重要的點以外，還有這么多點你需要去考慮，是有非常非常多點的。你要把所有的這些點都考慮到了以后，都去想好怎么實現以后，這是一個完整的微服務平臺。謝謝大家，基本就是這樣。

(結束)