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

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

以下是他的現(xiàn)場演講實錄：

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

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

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

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

我們再看一個現(xiàn)象，2014年很多人認(rèn)為是企業(yè)上云的元年，在2014年的時候幾乎沒有人考慮我想上docker上我的生產(chǎn)環(huán)境，用容器上我的生產(chǎn)環(huán)境，絕對不會有人這么考慮?；蛘哒f2014年容器根本不可能進(jìn)入企業(yè)級IT的選擇名單范圍之內(nèi)。到了2015年的時候，所有人都會把這個容器列為技術(shù)研究的一個方向?，F(xiàn)在到了2016年的時候我們更看的很清楚了，很多企業(yè)級的IT項目現(xiàn)在已經(jīng)開始嘗試在生產(chǎn)環(huán)境下使用容器了。

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

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

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

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

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

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

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

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

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

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

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

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

所以這么來看的話，一個版本的PaaS平臺，它的最小范圍是這個。我們這里說的是最小范圍，PaaS平臺是什么，或者微服務(wù)是什么，現(xiàn)在沒有一個邏輯公眾的標(biāo)準(zhǔn)。但是如果你想達(dá)到預(yù)期的目的，就是說我們用一個平臺能夠整個管理起來微服務(wù)，讓我們的微服務(wù)在里面能夠很好的運行，如果想達(dá)到這個目的，這樣一個系統(tǒng)應(yīng)該說是一個最小的集合了。

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

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

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

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

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

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

我們看一下微服務(wù)的實現(xiàn)模式，這個跟剛才容器的概念可以有相關(guān)了?；旧鲜莾煞N模式，一個就是Chassis，所謂的底座模式，底座模式的意思是說我們想實現(xiàn)一個微服務(wù)，沒有問題，這個微服務(wù)它從一個普通應(yīng)用變成一個微服務(wù)，必然有些特殊的東西。我們?nèi)绻胱约喝崿F(xiàn)這些特殊的東西，也可以，有這些東西你要去做，包括服務(wù)發(fā)現(xiàn)、熔斷容錯、負(fù)載均衡、自動化的配置，包括這種通過心跳的方式來報告自己的健康情況，

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

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

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

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

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

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

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

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

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

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

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

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

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

(結(jié)束)