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

吳建林是華為PaaS高級工程師，在他《華為全球IT系統(tǒng)基于PaaS的實踐分享》的主題演講中，絕大部分內(nèi)容都是之前沒有公開過的，例如FusionStage在流程IT內(nèi)部的跨數(shù)據(jù)中心解決方案、華為全球分布式路由方案、萬級容器管理規(guī)模設(shè)計等等。在演講中，針對開發(fā)者在傳統(tǒng)IT領(lǐng)域開發(fā)、測試、運維所遇到的各種問題，以及在新一代PaaS架構(gòu)下的解決方案，吳建林詳細闡述了云化、容器化能給企業(yè)、個人帶來的價值。

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

首先在這里代表華為公司感謝大家今天過來參加HDG的北京站。在開始講之前我想先問大家?guī)讉€問題，因為我后面講的內(nèi)容可能會跟這個內(nèi)容有關(guān)系，大家能舉個手讓我看一下用過Kuberentes和docker的人嗎。這么少，4個。還是說我要問一下沒有用過的人。

剛才趙陽已經(jīng)介紹了我們在公有云場景的一些應用，早上的話題主要還是偏應用。我們知道最牛逼的技術(shù)如果沒有應用場景，還是成就不了生產(chǎn)力。所以我這邊要講的是一個私有云的場景，私有云的場景主要是介紹華為內(nèi)部IT。華為內(nèi)部IT系統(tǒng)是相對比較復雜一點的。我先簡單介紹一下，我叫吳建林，現(xiàn)在是PaaS落地華為IT落地的主要負責人。

今天主要介紹幾個內(nèi)容，相信應該有一些是企業(yè)用戶過來的。所以我想講的是，對于我們這種大型的企業(yè)，傳統(tǒng)的IT，是怎么往云化做一些遷移，以及我們在這個遷移過程中會遇到什么樣的問題，我們是怎么樣解決的。

這里先簡單介紹一下華為的IT系統(tǒng)。華為的IT系統(tǒng)非常復雜，主要以流程和辦公兩個為主。其中辦公大家相對比較容易理解一點，就是正常的E-mail，或者大家在溝通通訊的esbas(音)，還有公司內(nèi)部自己會自研一些辦公的軟件。第二個是流程，流程有一個公司比較大的，號稱公司內(nèi)部業(yè)務的五朵云，像供應鏈、財經(jīng)、銷售這些的?；究梢赃@樣理解，華為所有這些業(yè)務的運轉(zhuǎn)全部都是靠整個華為IT支撐起來的，如果說用一句話來描述，華為IT應該就算是華為公司背后的那個男人，當然還有人種。

因為這樣復雜的系統(tǒng)，現(xiàn)在的部署規(guī)模非常大，已經(jīng)有8個數(shù)據(jù)中心，單虛擬機的個數(shù)就達到數(shù)10萬臺。應該在座的企業(yè)，你們企業(yè)跟這個規(guī)模是一樣的，數(shù)10萬臺的虛擬機規(guī)模?？偣驳挠脩?，就是固定的用戶，因為是服務華為內(nèi)部的，現(xiàn)在固定用戶差不多有17萬家左右。如果再算上一些合作方和一些其他的外部用戶，就更多了。應用總共有800多個，當然這個應用是我們重新抽象過的一層。舉個例子，剛才像趙陽講的華為商城的應用，在這邊最多就是1到5個應用，所以說它總共有800多個，中間這個系統(tǒng)是非常的大。

正是因為這么復雜的系統(tǒng)，所以它在整個云化的過程會遇到很多的挑戰(zhàn)，或者說在傳統(tǒng)的IT領(lǐng)域里面有很多的問題。這里面我只舉了六點。第一點就是傳統(tǒng)IT的模式不夠敏捷。我們都知道很多傳統(tǒng)的IT領(lǐng)域都是走人工流程的，你可能做一件事情需要很多的審批流程，包括你去申請一些資源，你做開發(fā)，都需要很多的審批流程。所以正是因為這些流程，包括你這個過程中，可能非常復雜，在整個申請過程，或者包括開發(fā)迭代過程沒有快速的迭代。

第二個問題是資源規(guī)模的問題，因為涉及到八大數(shù)據(jù)中心。大家知道一旦涉及跨數(shù)據(jù)中心的系統(tǒng)，都是非常復雜的，因為它要解決數(shù)據(jù)中心給大家?guī)淼暮芏鄦栴}。

第三個問題也是我們今天下午要介紹的應用微服務化。微服務化會帶來一個比較大的挑戰(zhàn)，就是原有的系統(tǒng)變成微服務以后，就會非常的多。差不多現(xiàn)在統(tǒng)計過的有將近3倍以上，因為我們傳統(tǒng)的很多IT都是基于openstack，這種IaaS的彈性擴縮，這種速度已經(jīng)沒有辦法完成這種微服務的改造了。

第四個問題也是很多企業(yè)關(guān)注的點，就是它自有利用率很低。我們正常的一個企業(yè)可能一臺虛擬機上面就布一個應用，而且還是獨占的，可能就是搭一個(05：40)，這樣你整個資源是沒有達到一個充分的利用。而且虛擬機的虛擬化成本還是相對比較高的，可以占到15%到25%之間。

第五個問題是全球的應用訪問體驗，因為我們知道八大數(shù)據(jù)中心，但是你的業(yè)務又必須有一個集中點，所以很多對于路由上的一些控制會比較復雜一點。以前傳統(tǒng)的IT可能就是每個立方做一個自己的。

第六個是平臺異構(gòu)，對于我們來說很多的企業(yè)可能已經(jīng)有原有的很多系統(tǒng)，或者很多語言，包括它底下的平臺都是不一樣的。所以給PaaS的支撐帶來很大的問題。

接下來要講一下整個完整的，就是華為IT，現(xiàn)在PaaS在整個華為IT的內(nèi)部架構(gòu)?？梢韵葟纳厦骈_始看起，最上層這層是屬于業(yè)務層，也就是企業(yè)內(nèi)部會有很多自己的應用，自己的內(nèi)部應用是部署在TaaS層的。再下來的這一層是屬于(07：06)流水線，就是說這一曾是整個開發(fā)過程中最核心的內(nèi)容。這一層的保障是由PaaS的核心層，我們這邊也稱3+1的能力。所謂3+1，第一個叫做應用調(diào)度與安排，下午還會詳細再講，第二個是微服務，也是下午會講，開發(fā)流水線，剛好這三個記錄框架都是下午的議題。這三個基礎(chǔ)的框架，再加上一組中間鍵服務。這里中間鍵服務起到非常關(guān)鍵的作用，就是可以把整個基礎(chǔ)框架，把整個TaaS-Por的核心層全部都串在一起。下面底層主要還是涉及到跟I層對接。我們以前傳統(tǒng)IaaS就是VMware、openstack應用比較多。但是(08：01)這一塊是屬于混合云的東西，現(xiàn)在我們正在構(gòu)建。。

上層，對接I層這層的東西，會有很多企業(yè)級的應用他要求做同城生活、異地災備。所以在這個地方，Kuberentes我們是做很多擴展。前面這一層基本是屬于一個PaaS的核心部件。因為有很多SB的用戶，他可能自己在TaaS的基礎(chǔ)上，自己再封裝一層能力出去，自己做一些流量統(tǒng)計，計費要怎么計，比如底下要拿虛擬機賣錢，或者拿容器賣錢，怎么計。每個企業(yè)都有自己的一套統(tǒng)計方式，所以這一塊的能力是我們開放出去的接口，可以允許用戶自己再做一個自定義的過程。

在這里分享一下對這種復雜的大型系統(tǒng)，包括跨數(shù)據(jù)中心架構(gòu)設(shè)計的解決方案。這里我總結(jié)了一下，中央集權(quán)，地方自治和層級管理。這是什么意思呢?因為我們要管理的數(shù)據(jù)中心非常多，像華為里面有八大數(shù)據(jù)中心，如果你沒有一個統(tǒng)一管理點，就會變得很分散。很少一個管理者要看的話，可能就要通過不同數(shù)據(jù)中心的東西去匯總，或者去看，沒有一個統(tǒng)一的匯集點。這樣會導致你沒有一個非常好的大的視角，去看你所有的資源。地方自治指的是，因為我們有很多東西，舉個例子，路由，比如在英國的用戶你肯定更希望我直接住在英國，訪問我英國的應用就好了，不要跳到深圳過來，網(wǎng)絡(luò)時延就很長。所以自己的地方需要有一套自己自治的機構(gòu)，也就是說能把你整個應用自維護。他可能知道的這個概念比較淺一點，就是一個簡單的執(zhí)行者，再加上一個故障恢復的人。但是往后到最后我們會有一個真正的大腦，也就是我們中央集權(quán)主站點的地方會做所有的任務，包括我們整個完整的東西，一個統(tǒng)籌。

底下就是介紹幾個，要做到這個程度我們需要做的幾件事情。第一件事情是資源的抽象化，我們知道像AWS內(nèi)部會有很多資源的概念，比如說哪塊區(qū)域，哪個(11：06)。因為中間你要做很多的應用調(diào)度和編排，這一層能力都是要基于你現(xiàn)有的平臺，你把你底下的這些資源全部都抽象化成你的概念，所以這個地方你要對所有的資源做一層建模。這一塊的建模能力是要非常清晰的。而且建模可能每一個公司也會建的不一樣，對于我們來說中間建了很多，比如說最上層可能就是一個區(qū)域，區(qū)域比如說是大中華區(qū)，下來有分多個數(shù)據(jù)中心，哪一個里面的，你到時候要做很多的調(diào)度，這是一個資源的抽象化。

第二件事情就是任務的消息化，我們知道任務一定要是非常可靠的，不然你任務發(fā)過去最后都沒有回來，或者這個任務沒有被你不同的數(shù)據(jù)中心接收到，就會導致你整個平臺數(shù)據(jù)是不一致的。這是任務的消息化。

消息要異步化，就是說我們不可能，比如在這個地方發(fā)一條信息，發(fā)一個任務到巴西那邊，因為它時延非常長，不能同步的等待。如果你同步等待的話，會遇到很多問題，中間有可能直接堵塞在那兒了。

往下是整個管理的模塊全部都要模塊化，就是你所有的東西全部都是要按模塊來的，這個跟我們微服務框架是有點像的。往下的話是運用一體化，對于一個運維來說他想要看到的一定是全局的視角，而不是簡單單純的我單看一個數(shù)據(jù)中心，或者我看一個機房之間的監(jiān)控情況，所以一定要有一個非常全局的觀念。

這是我們fusionstage整個在華為內(nèi)部IT的上線情況，我們這個做的也相對比較晚一點，是去年2月份才開始做一些試點。一開始做的話主要還是做一些改造，10月份的時候上生產(chǎn)環(huán)節(jié)，規(guī)模相對比較小一點，有1千臺虛擬機左右。今年的10月份是開始大規(guī)模的推廣，現(xiàn)在所有的虛機情況有將近4千臺。當然這個地方有很多集群，不是一套集群管4千臺?，F(xiàn)在這塊的東西，能力上我們驗證到的就是內(nèi)部的集群可以達到2千臺左右的規(guī)模，單集群的。

接下來我會根據(jù)不同的角色，今天在座的大部分都是這上面的一些角色，比如說業(yè)務開發(fā)、測試運維。像業(yè)務這邊，對業(yè)務來說他最想的一件事情是什么，他可能每次直接去跟客戶交流，或者跟外面其他人交流，就突然來了一個idea，回去就告訴研發(fā)這個idea一定要馬上給我實現(xiàn)，所以他要求的就是一個字，快。開發(fā)這邊，很多開發(fā)像我們傳統(tǒng)的這樣，把時間浪費在有點像后臺的資源申請，或者你自己還要搞很多的環(huán)境。其實你更應該專注于，你既然是開發(fā)，就需要把功能和特性能夠做出來，這樣能提高很多的生產(chǎn)力。然后是測試，因為我們有很多自動化手動的測試能力，或者自己有時候要寫，非常的繁雜。然后是運維，運維就看剛才的那個數(shù)10萬臺的虛擬機，每天手機收到的就像運維人員每天收到的報警有上千條，就是上千條的報警會發(fā)到你手機或者E-mail上。所以一旦你整個規(guī)模大上去以后，運維是非常大的問題。

為了解決現(xiàn)有這些角色用戶的問題，這個地方fusionstage有一些需求的實踐。就是在做云化的過程中，從個人理解到的，至少在華為內(nèi)部IT做的第一件事情就是先把流量統(tǒng)一了。為什么先把流量統(tǒng)一了，因為我們都知道業(yè)務在一定的情況下，顯示的是以流量的方式來給大家展示的，因為你所有的流量對于業(yè)務來說都是非常重要的。所以只有你把流量給統(tǒng)一了，你底端要怎么改，隨便你怎么改。原因是我們中間這個地方有一個ELB，我們提供了很多的特性，就是你的路由怎么走，全部都由我們PaaS來控制，中間我們做一些灰度發(fā)布的功能。這個功能做出來以后，你以前比如說已經(jīng)有一些很老的系統(tǒng)，或者跑在虛擬機上面，跑在其他地方的應用，可以原封不動，你可以保留著，只是我中間在路由層這一塊給你做控制，你到底是要切到新的系統(tǒng)，還是繼續(xù)往老的繼續(xù)遷。中間這一層我做了控制以后，當然很多用戶可能一開始的時候不愿意這樣做微服務化改造，或者容器改造，原因就是因為怕影響我們的應用。但是我們做了這一層路由的切換灰度發(fā)布以后，你再新增出來一個新的應用，如果你掛了，大不了你路由我?guī)湍闱谢厝ヒ郧袄系?。所以這樣子對于應用來說他其實是無感知的。

中間我們主要是用Nginx、Lua和redis來做的，redis主要是存一些配置信息，比如說我們正常的策略，比如你這個應用允許哪一個用戶訪問，后臺對接到哪一些服務器，這些數(shù)據(jù)全部傳到redis。Nginx里面的Lua的插件會往redis里面把這些所有的數(shù)據(jù)都讀走，讀走完了之后就可以做負載。中間這個地方我們做了一些很多像Nginx里面上用版本的功能，比如說像名信、健康保持等等非常多。還有一個比較大的特性，它能做到動態(tài)生效，就是動態(tài)路由，你不用重啟Nginx，因為我所有的配置都在redis。比如說你現(xiàn)在新增了一個容器，我只需要把新增的容器的實驗感知，最后把這個地址刷到redis上面去，Lua會自己把Nginx上面的數(shù)據(jù)拿過來，放到Nginx上面去，自動繪幫你做負載，這一塊是完全無感知的，而且是全自動化的。

現(xiàn)在中間鍵在華為內(nèi)部IT已經(jīng)上線了260多位了，基本上華為內(nèi)部IT所有的流量，大部分還是用現(xiàn)有的ESB來做的，所以我們中間要怎么做，策略還是比較簡單一點的。平均的訪問流量能夠達到1億次每天，但是1億次每天跟我們正常的搶購，華為商城搶購的場景，這個流量還是有些不能比。因為像在企業(yè)內(nèi)部里面，更多要求是它的可靠性，而不是一些訪問流量非常大的，或者是防攻擊、防牛這種的，相對要求會比較低一點，因為畢竟都是內(nèi)部的客戶。

講一下第二個需求，這個剛才有人提問到這個問題，我們這邊是有一個應用的概念。剛才說了開發(fā)其實很多不想去解決你后臺的問題，所以這個地方我們做了一個一鍵式應用發(fā)布的特性。一鍵式應用發(fā)布就是你應用開發(fā)或者是應用本身，你自己只需要做你的應用就行了，不用去管后臺的。比如你拿一個java的萬包(音)或者拿一個降包傳給我，完事之后我會跟你做一些自動化構(gòu)建，打成一個docker的容器鏡像。這個鏡像會發(fā)布到我們對應的，像測試或者是生產(chǎn)的鏡像倉庫上面去，做一層保留。到用戶那邊你可以選擇部署，或者也可以選擇用流水線的方式自動觸發(fā)你構(gòu)建的應用去自動部署到生產(chǎn)環(huán)境、測試環(huán)境，或者是開包環(huán)境。中間還有兩個比較大的特性，一個是安全掃描，因為我們知道很多鏡像，你在內(nèi)部用戶隨便給你傳了一個鏡像，上面打了很多bug上去，或者上面有很多的病毒。這種中間我們會有一個安全中心，但是這個安全中心現(xiàn)在只能是掃描一些現(xiàn)有已經(jīng)知道的漏洞庫。

后面還有一個比較大的，就是全球的鏡像同步，因為我的應用要部署到海外的BC上去。所以這個地方你必須在本地構(gòu)建的鏡像能夠直接發(fā)到不同的數(shù)據(jù)中心。這個地方是用MQ來保證它的可靠的。中間正是做了這一層一鍵式應用發(fā)布，再加上流水線的結(jié)合，所以整個我們原有以前部署效率，以前我第一次申請資源的時候花了接近我5周的時間，到最后面我茶不5分鐘，我的應用就可以完成，資源什么的直接是一鍵式就能申請下來的。

第二個需求剛才趙陽已經(jīng)有講過了，就是一個混合編排。我們在Kuberentes這邊做了一個比較大的擺動，就是多增加了一個抽象概念，這塊主要是為了兼容以前像進程的管理。比如以前大家都是軟件包直接部署在虛擬機上面的，所以你這邊可以創(chuàng)建pro在里面。一個pro里面可以管理很多進程，現(xiàn)在只支持一個。底下是可以支持容器、物理機、虛擬機上面的應用和部署。但是這個地方我們需要提供一個軟件倉庫的功能，因為我們的軟件包全部都是統(tǒng)一放在一個地方的。

下面這個主要涉及到剛才講到了webIDE，就可以通過拖拽的方式，整個部署一個環(huán)境，這個剛才已經(jīng)講過了，我就不講了。再下來講一下我們這種監(jiān)控，我們知道你的虛擬機跟容器一旦量大上去以后，監(jiān)控對于大家來說都非常的重要，而且也非常的慢。主要有幾點問題，一點是正常我們底下采集端的能力有點問題，因為我們以前傳統(tǒng)大家都覺得，可能把采集到的監(jiān)控信息，包括日日信息，一股腦的直接往你的服務端算。但是你的服務端是沒有辦法去控制的，因為你的服務端那邊不知道底下會有多少人給你刷，這是有點向客戶端主動上報，所以這個會帶來一些問題。

這個地方我們做了幾層改造，第一層改造是它的采集端，采集端我們采用像普羅米修斯，能夠兼容普羅米修斯，能夠自動往每一臺服務器上面拉的方式。就不是底下自己報給我的，當然報給我的方式在這里也是支持的，就是給用戶提供更多的支持力度。這是第一個問題。第二個問題是大家以前舊的系統(tǒng)肯定都打了很多的azen，azen是非常麻煩的問題，因為你azen還要解決它的升級版本管理，很多的問題，包括你到時候可能azen要卸載，或者要更新，問題非常多。 我這邊基于原本(28：17)，去做了一個叫(24：21)的東西，就是可以管理你底下所有的azen，包括比如你監(jiān)控的日志，還有一些部署的azen，所有的azen都按照一定的架構(gòu)把它放到一起，升級更新管理這些統(tǒng)一由X-lind來管理。

還有一個是我們服務端的壓力比較大，所以我們把服務端這一塊的消息全部都扔到kafika上面去了，kafika這邊你后臺的服務端就變成可擴展的，你可以隨便的讀。讀完之后，這邊主要做幾個處理，一個是存儲，存儲的話這邊監(jiān)控是用openTSDB，日志這一塊主要還是用Hbes和ES，后臺會做一些展示，展示這邊主要還是對接這些數(shù)據(jù)庫去拿數(shù)據(jù)。

后面還有一個是策略中心，因為我們要做告警和自預，所以你所有監(jiān)控的信息最后都必須要報出來。而且這個地方大家會發(fā)現(xiàn)告警非常的多，因為這個地方只是做一個比較簡單的告警。簡單一點的告警就是正常預知的告警，到最后會到我們的大數(shù)據(jù)平臺里面去做一些智能分析，就是把你整個告警聚合到一起，最后再形成一定的事件，去做自動擴縮容，或者是抬。

現(xiàn)在已經(jīng)能承受到整個，因為我們現(xiàn)在容器的數(shù)量是非常大的，包括以前已有的虛擬機的方案，整個可以達到萬級的級別，都是沒有問題的。

這個是我們整個頁面的展示情況，就是一些我們自有資源展示的頁面，還有CPU內(nèi)存。

再講一下調(diào)度方面的，調(diào)度方面有做一些親和和反親和的，主要是跨數(shù)據(jù)中心的。在跨數(shù)據(jù)中心外會做一層，到單數(shù)據(jù)中心內(nèi)部還會再做一層。數(shù)據(jù)中心內(nèi)部做的這一層，主要是像以前的CPU余量和內(nèi)存余量，主要是fusionstage它原生支持的。我們新增的幾個比如說像鏡像緩存，因為我們部署的時候要更快，所以一定是要先把它盡量往已有的鏡像緩存的機器上面做調(diào)度。

再講一下應用的灰度發(fā)布和彈性擴縮的事情。我們這邊的擴縮容可以做到幾點，一點是對接IaaS做擴縮容，一點是容器自己做的一層容器的擴縮容個。應用的升級基本上都是灰度升級，兩種方式。一種是替換式的，比如說你多個版本，你先構(gòu)建出一套新的版本，把路由接上，接完之后，再把老的版本全干掉。還有一種是滾動式的升級，就是你起來一個新的，干掉一個老的，你可以體驗一下新的到底怎么樣。然后再起來一個新的，再干掉一個老的，這個策略是可以垂直的。

這個地方還有幾個我們對docker做的改造，剛才看了一下用docker的人比較少一點，我就簡單掠過就好了。我們這個地方私人云場景里面會做一個類似于容器里面，你能跟傳統(tǒng)的虛擬機一樣，直接用sh登錄下去，但是這一塊不是用shd來做的。因為我們?nèi)萜骼锩嬉蛞恍I(yè)務，還有監(jiān)控之類的，所以它是多進程。日志的持久化是通過掛盤的方式存儲到外面。還有一些docker可以設(shè)定獨立的IP。包括hosd，容器會給它做一端口分配。

這是整個fusionstage云化改造完之后，能給傳統(tǒng)IT帶來多大的價值，虛擬機個數(shù)直接降下去了，但是容器的個數(shù)上去了，容器對于我們來說相對更容易一點運維一點。然后虛擬化成本降低了將近一半。還有一個是彈性時間現(xiàn)在可以到5分錢，以前真的是1周，我一開始過去申請的話就是1周。下面就是一個CBD還有一些跨站點的支持，這個對于我們來說產(chǎn)生的效力還是比較高的。

下來是幾個遇到的問題。第一KBS原本的service性能會相對比較差一點，因為它每次去創(chuàng)建一個service的話，后臺都會去創(chuàng)建4條Iptable，而且還是在每一個虛擬機上都會創(chuàng)建相應的Iptale。之前我們在線上的問題是1千個節(jié)點，600個service，4千個cord，所以導致我們后面每一臺機器上面有1萬8條的Iptale，更新一次需要接近5秒到10秒的時間，這個時間對于業(yè)務來說是不可忍受的。所以后來我們做了一層改造，這個也是在KBS上面改的，基于KBS我們做了一層端口的管理，也就是說把原有的service的方式盡量少用它，改成這種服務志發(fā)現(xiàn)的模式。在每一臺機器上我做原有docker端口的管理，管理完之后我會把它對應的IP地址直接刷到容器里面。如果你應用在容器里面啟動的話，你可以拿黃金變量，直接拿自己的IP和端口做服務發(fā)現(xiàn)，放到你自己的服務注冊中心上面去，這樣你所有的容器可以跟以前虛擬機的方案全部都打通了。因為你以前部署在虛擬機上面，所以容器這邊變成我們用了它虛擬機上面這一層網(wǎng)絡(luò)的影射。

第二個問題是我們遇到的也算比較大的問題，這一塊是一個優(yōu)化。大家不管你寫代碼寫的多牛逼，到最后肯定會有一定的bug。或者你的OS太就沒有啟動了，沒有重啟了，也可能帶來很多的問題。所以我們這里做了一個重啟的特性，所謂的就是重啟大法。你以前的那些操作系統(tǒng)很多，比如說要涉及到操作系統(tǒng)，要升級，或者你的容器都要升級。這個地方也是需要把虛機去重啟一下的，所以我們這邊做了一個試練場。以前像KBS這邊我們會讓它先把容器遷走，遷完之后，再把虛擬機重啟掉。所以我們所有的機器一直是在重啟的，這樣能減少很多的問題。有時候代碼跑久了，會有很多奇奇怪怪的問題，可能再牛的人也解決不了這樣的問題。所以這層是我們做的一層運維上面的優(yōu)化。

今天要講的內(nèi)容差不多就是這么多，下面是我們?nèi)A為開發(fā)者社區(qū)的LOGO和我個人的二維碼。如果有問題，后面要做交流的，也都可以加我的微信。我今天就講這么多。

(結(jié)束)