傳統企業應用容器化的痛點、坑和解決之道

本次分享將講解容器化技術對傳統企業的價值；傳統企業在應用容器化技術改造核心應用如CRM、BOSS等等，中遇到的問題以及應對措施。

今天我主要跟大家分享一下在平臺性的產品，特別是針對企業平臺性的產品設計過程當中，可能會面臨什么樣的需求，面臨什么樣的問題。同時包括我們自己在面對這些問題時，采取的一些技術選型和思考。

我們先對這個標題做個語法斷句。企業，應用容器化的，痛點、坑、和解決之道。開宗明義，我們是針對企業的。在企業這個背景下，構建平臺性產品，就必須面對權利相關的東西，平臺上多業務融合的東西。就像上一位講師說的，在HOST模式情況下，怎么考慮端口的問題，就必須要考慮。下面我正式開始分享一下我們在這方面的思考。

這是我今天講的內容，首先是技術背景和行業特性的介紹。基于這個背景，分析一下要做一款企業級的平臺性產品的時候，需求來自于哪些方面，以及有一些什么樣的原則。最后我們是我們的產品在設計過程當中的技術方面的選擇和我們的思考。

第一個是技術背景。應該說這幾年，云計算這個領域可以說是精彩紛呈，基本上每年都有1-2個技術的熱點，云計算、大數據、容器。從去年開始容器上升到一個非常高的熱點了，在這方面做研究的，新的產品出來非常快。從我這邊來看，容器不光是Docker，我認為容器主要是兩個內容，一個是鏡像一個是運行時RUNTIME。

我第一次看到Docker提出的build, ship, run口號時，一下就想到了10幾年前，Java當時提供的build once，run anywhere一次構建，處處運行。這么多年過去了，Java也證明個這個口號，也成為了第一大語言。Docker能不能做到build、ship、run，我們還得拭目以待。目前大家對Image認可程度比較高，整個業界對這方面的關注度和爭議性相對也小一點。Image解決什么問題？ 在我看來一個應用從研發分包到分發到運行起來，Image在運行之前做一個界面，定義了一套標準。有了這個標準之后，運行前和運行后兩邊的人就可以很融洽的合作了 。

另一方面，支撐Image能Run的就是Runtime。Docker Engine是目前用的是最多的。當然還有Rkt、LXC等等都在做。 目前Runtime主要支撐如何讓一個應用運行起來 。一個程序的運行，要有CPU、內存、帶寬、存儲。Docker Runtime就是支撐這個，讓這個事情更加順暢。Runtime部署在服務器的每個節點上，它有一定的實效性。相比與Image，它是累積的。一個企業進行技術選型的時候，Runtime這個是可變的，因為它是不可見的。而Runtime相比Engine是可見的。你的程序、業務邏輯成天累月的積累到Image中，如果那天想要把它翻過去，換一個是非常大的成本。技術選型要考慮這樣的因素。

這頁PPT的左邊這三個Kubernetes、Mesosphere、Docker之前關系很融洽，現在已經有一些摩擦了。現在的業務系統越來越復雜，特別是微服務化后，光靠一個Docker Engine Runtime，程序是跑不起來。幾百個程序一起協作才能完成的一件事，必須要有調度，必須要有編排。因此Docker就往上做。Mesosphere原來就是做調度，做編排的。它即缺少底層Runtime，又缺少對應用的支持，所以它既往上做又往下做。 Kubernetes從誕生之初，目標就是支持應用的運行 。所以從一開始，它就內建了很多應用運行時的特性。技術選型過程之中，我們在綜合考慮了以后，在容器支撐應用這兒主要選了Kubernetes。因為它可以更好的支撐應用。至于它不能解決的一些問題，特別是放在整IT的環境下，一些支撐性的功能和基礎，我們選擇了很多技術，對它進行補充。

下面我們看一下行業背景。 2015年的時候，浙江移動DCOS平臺上線，承載了浙江移動CRM業務容器化 。在當年的雙十一大促中表現非常好。在電信行業影響還是挺不錯的。證明了容器在解決運營商的一些典型業務的時候，它是有這個優勢的。

第二個是今年開始，中國移動啟動了容器平臺規范的制定。讓容器這種技術能夠盡快的規范起來，而且讓這個技術盡快推進下去。

第三個中國移動除了制定規范，針對容器技術在其它業務上，還沒有被驗證過的，就開始做一些試點項目，驗證其可行性。包括CRM、BOSS、BOMC等等。這里面CRM已經驗證過的。CRM是屬于交互性的，大家都可以看得到，它有一些典型的互聯網的屬性，比如說秒殺活動、團購活動。短時間內可以有巨大的負載。但是BOSS是不一樣的，它是長期穩定運行，它也有些周期性，但是總體是長期穩定運行。一個BOSS程序跑起來可以使用幾百個G內存、二三十核。在這種情況下Docker還能不能工作？BOMC是電信行業里面的管理型軟件。BOMC本身能不能被容器化，BOMC能不能納入Docker的特性，為其他的平臺提供更好的服務，比如說公共的服務，并考慮未來不同的調度編排平臺之間操作及遷移的問題。綜合來說，容器在電信領域在以后會有一個非常大的應用。

回過頭來我們再看一下，在這個行業里面，它的特殊性在哪里？ 簡單來說，分為三塊，一個是管理者主要就是我們的運營商企業，然后是應用提供商，然后是資源提供商，這三個是分離的 。在互聯網公司和其他的公司，大部分時個這三者可能是合一的。管理方對于資源提供方，應用提供方都有要求。對應用提供方的要求是業務要穩定、特性開發能敏捷，要能快，盡快適應管理者的需求。你是CRM提供商，一個特性能不能10分鐘上線，或者幾天就上線，在大負載、大流量的情況下，能不能穩定持續運行。管理者對資源提供的要求，你能不能少用點資源，能高效，能快速響應。業務提供才對資源提供者也有要求，秒殺來了，能不能一下子擴充，能不能動態給我提供資源，怎么讓我自動或者是主動獲取到這些資源。

雖然角色只有三個，但是一般來說都是非常多的廠家在參與的。運營商需要一個規范的標準平臺，把這三個拉到上面去，在平臺上滿足大家的需求。

我們現在來看一下容器技術能給這三者關系帶來什么樣的一些改變？

第一個，容器鏡像封裝了應用在運行過程當中的依賴包也好，程序邏輯也好。這樣應用它就可以用標準的協議交付第三方。應用開發商開發完了就可以交給資源提供者，平臺只需要把它運行起來。大家之間不存在角色模糊或者邊界相互有重疊的情況。

第二個，資源提供者可以無差別的對待資源需求。以前CRM上線了，一定要單獨的資源。因為我要配一些特殊的東西，我的東西跟別的東西可能有沖突，不隔離沒有辦法放在一起用。單獨只運行一個應用就存在資源浪費的問題。現在有了鏡像，有了容器技術。就想船上放貨柜，貨柜有大小之分，但是沒有本質區分。這時候可以混合編排，混合部署，一個設備上可以部署很多業務，這樣可以提高業務的部署密度和資源的使用率。同時，因為有了這個，就為我們構建統一的平臺提供了可行性。

第三個，是研發流程和上線流程就可以做到自動化了，因為這些都是標準的，都是可編程的，可以通過程序的方式來做了。

第四個，是應用模式化。我們開發程序的都知道，Java有20多個設計模式。實際上程序本身在部署運行過程當中也是有模式可循的，不是一點共通性都沒有。比如典型的Web應用，就可以分為接入層、業務邏輯層、數據持久層。在典型應用中發現模式，模式被發現之后，在構建的平臺上，你的應用以后就可以遵循這樣的規范，共享這樣的能力。最近這幾年微服務比較流行，可以更加細粒度控制程序的架構和控制程序的交付方式，它也更適合使用容器的技術。

最后，因為有了前面的這些技術的改變，我們就可以構建標準化、自動化、可編程華響應非常快的，整個業務開發、交付、上線、運營整個的流程。

當然，構建一個容器平臺是面臨很多的挑戰的。

第一，是所有平臺化產品都會面臨的問題。平臺化要定標準。目前來說，容器的標準相對統一（Image、Runtime），但是容器管理平臺的標準至少有三家（Kubernetes、Docker Swarm、Mesos)在做，誰能占上風，目前也沒有一個絕對的，新的產品和技術可能也會冒出來。標準不統一，導致大家在使用過程當中，技術選型的時候會有挑戰。

第二，容器的技術涉及到資源，涉及到應用內部結構，所以它具有一定的侵入性。不像是虛擬機，交付完成后，在虛所機內部怎么搞平臺就不管了。容器要關心這個問題，否則就沒有辦法做模式化了，不做模式化的話，平臺的很多東西都沒有辦法構建了。

第三，大量傳統應用需要改造。運營商市場有幾百，上千個應用。這些應用估計都是幾百上千億的投資，不可能這批應用都不用了，全部改成容器。而且容器也不是銀彈可以解決所有的問題。傳統應用的改造適合什么樣的技術，怎么改變，這就是我們非常大的挑戰。這些挑戰在我們產品技術選型時，能多多少少都會涉及一些。

綜合上面的一些分析，我們認為這三個角色的基本的需求，可能就是這樣的。對于管理者、運營商來說，需要一個多租戶、分權分域、多應用，對使用者安全的平臺。在平臺上所做的操作也好，所產生的一些事情也好，可以做到審計、追溯。最好做到提前預判、預警。程序的架構，包括技術方案應該具有一定的可演進性，不能說隔幾個月就發現你的技術要革命性的推翻。一定要有演進和延續性。

作為資源提供者，首先要支持異構資源，不能只跑在戴爾服務器或者別人的服務器，存儲只能選某個牌子。要做到同種資源要做同一化處理，異種資源要相互兼容。資源使用最好能高效，能達到90%這就是非常厲害的了。最后對所有的資源要進行監管和監控。監管和監控的數據，也可以輸出來滿足管理者關于審計、分析需求。

作為應用提供者來說，首先你能提供可靠的容器，這個容器不能三天兩頭就出問題。對于有狀態的應用、無狀態的應用，包括一些特殊應用，要有足夠的兼容性，要能容納、支持它們。對應用配置元數據的管理，平臺能提供相對統一的方式方法。我的應用能通過編排的方式在你的平臺正常運行。我的東西托管給你了，你要負責運行的狀態，以及出了問題，你能提供我手段分析、發現并最終解決問題。比如說你把你的程序跑到某一個平臺上，出了問題，平臺不管，然后得你自己想辦法解決。這樣的話，你肯定不愿意用。至少能讓用戶訪問它的日志和內部的數據，平臺得提供相應的功能和手段。但是因為有一些安全性和權限相關的控制，你也不能說無限制開放。平臺上面是業務混合部署，上面可能有很多人在操作，很多業務的應用，權限開放太大，萬一操作不慎出了問題也是很麻煩的。既要管，又要放，這就是矛盾的地方。

總體來說，我們需要一個橋梁，這個橋梁既能連接應用和資源，也能連接老的應用模式和新的應用模式，同時把所有參與者容納在上面，這個橋梁就是容器平臺。

我們構建平臺和構建產品的時候，以及技術選型時有一些原則。產品構建時，第一要緊貼用戶需求，我們的技術和功能設計出來肯定要解決用戶的問題。做一個東西，這個東西有什么場景在使用，可能在什么時候？我們要有一些預見性，也要貼近實際。

第二要有可擴展，也不能說跟客戶要求的一模一樣，這個就不是產品了，這個就是一個項目。產品要解決共性問題，要有可復制性。我們需要提取公共的部分，把他們的需求作為我們的產品功能。

最后一個是實用。

技術選取也有三個原則。 第一是可控 ，選擇的技術要有一定的前瞻性，它即不是處在非常萌芽的狀態，因為萌芽狀態需要探索，變化太大。我們自己本身也做預研性探索。但產品中使用技術，一定得是可控的，已經摸索熟練的。不能說出了問題沒有解決辦法。

第二技術可復用，任何技術的使用選擇都是有投資的，投資下去以后，我希望利用率越高越好，在不同的場景下可使用的情況越多越好。

第三技術可演進，明天可以增加，后天還可以再增加。一年過去了，回過頭發現，這個技術跟之前有了一個本質性的變化。但是這個技術是一點一點迭代的，不一是革命性一夜就蹦出來。

基于上面的分析，下面我講一下面對管理者、應用提供者、資源提供者他們的需求，我們的產品構建以及我們的技術選擇。

管理者的需求最主要有兩塊，一個是權限，一個是安全。我們對容器倉庫要做一個很好的權限方面的管理，我們要支持公共倉庫，我也得能支持私有倉庫。私有倉庫就是某個業務專用的，或者是某個部門也好，對別人不開放，但是擁有者有權限訪問。包括公共倉庫也要支持多租戶的，是有可訪問范圍的控制。這個平臺是多個業務在上面運行的，大家要有隔離性。然后是RBAC細力度訪問控制。

安全這塊合規檢查我們選擇了clair。安全這個事沒有大小之分。鏡像做好以后，一定要做一個合規性檢查，是不是滿足通用的安全管理規范。

容器應用上線以后一定要有隔離性，我們主要說的是網絡隔離性，通過網絡的技術，讓不同的應用之間做到物理層面的一些隔離。總歸放到安全這個大話題之下。

關于租戶以及權利，基于Keystone我們開發了SAS的服務。用戶、組織機構、角色以及權限控制，都會放在SAS上。我們產品中其它所有服務都要接入這個體系，服務本身有什么樣的訪問權限，你的人員在訪問系統的時候，能在那個子系統里面執行什么樣的操作，都是需要受SAS服務控制的。為什么選Keystone呢？ 第一我們對Keystone研究比較多，第二Keystone是從OpenStack來的，天生可以直接接入OpenStack 。OpenStack在企業用戶的部署慢慢會越來越多，我們希望有一套整體的解決方案解決這個問題。不管你是普通的物理設備的，還是虛擬化管理的OpenStack，還是以后的容器，我們用一套權限體系統一納歸到一起來。

鏡像管理，我們使用了VMware Habor開源組件。私有倉庫是我們自己做的，Habor提供給我們的是多倉庫鏡像同步。

這是涉及到網絡這塊，大家做過IaaS的估計都看到了Neutron。我們把Neutron嫁接到了Project，容器網絡、容器安全組都歸結到Neutron特性上。通常我們實施過程當中，主機都掛在管理網絡，主要做主機之間的互動，作為管理層的內網。第二個是存儲網，容器本身也要寫數據，我們會有專門的存儲網。生產網是一組，不同的容器，不同的業務，甚至不同的用戶，可以放在不同的生產網絡里面。他們可以使用vlan, vxlan等等技術進行二次隔離。就算你知道我容器的密碼你進去了，但是通過網絡攻擊的方式訪問它也是非常困難的。包括容器本身我們有一些QOS的限制，帶寬、可訪問端口我們都會有限制。

這頁鏡像管理子系統。我們把鏡像掃描加入到鏡像構建流程中，鏡像構建以后要做安全掃描，掃描完以后告訴你是不是合規的。報告已經掃出來了。鏡像進入到鏡像管理子系統以后，鏡像本身就會有一個安全評級和掃描報告。如果所有的東西都沒有問題就可以到上線。鏡像有多種方式進入，你可以Push你的鏡像，你可以上傳你的鏡像。鏡像在生成運行態變成容器的時候，我們也要進行訪問控制，只能暴露部分端口。容器本身還有一些QOS策略，是1M的還是10M的帶寬。一般來說，業務不是放在一個網里就完事了，甚至有的時候一個業務本身要放到好多的網里，之間也是有網絡隔離的，這些都是在運營商應用體系里面常規的要求。

上面是管理者的需求，側重權限和安全。對于應用提供者來說，他們對平臺有什么需求？一個應用開發到上線到你的平臺首先有一個過程，容器化。如果是一個新的程序，非常好，直接可以按容器的方式來做。寫編排文件就可以直接了。如果是老應用，要先有容器化的過程。 這個過程大致可以分為拆分、改造、合并三個階段 。拆分的時候要分析老應用，它原來是單體應用，或者是個很復雜的應用，那各個模塊有什么樣的調用關系，每個模塊的職責是否單一？層次結構是否清晰，各層之間界限是不是清楚的，他們相互之間有什么樣的依賴，分析完之后就知道怎么分解了。

把它分解成很多小服務，這時候就需要為每個服務做鏡像改造。還可以跟研發代碼過程聯系起來，做持續集成。可能的話，把應用改成無狀態的。比如原來有一些Session，會話之類的數據，是不是可以把它遷到別的地方？有的應用不能這么改。 它本身就是產生狀態，產生數據的 。這時候就要考慮，它的數據怎么存儲。比如說能不能約定數據共享存儲。如果可行，能不能把應用的數據寫到S3之類的分布式存儲里面。如果應用只能寫文件系統，應用能不能使數據存儲目錄是動態的，如果可以動態就好辦了。平臺可以提供存儲能力，應用只需要集成存儲能力，就可以記數據和可執行邏輯分離。最后，一個應用的改造要看場景，具體應用有很多細節的情況，不一而足，需要單獨分析。

當應用改造完以后，手里就有一堆小服務，調用關系也是非常清楚的時候，你就要合并了。通過編排的方式把它們再組合到一起。A應用怎么發現B應用，就存在服務發現的問題，一個應用里面可能會有很多運行實體，這時候就有一個單一訪問的問題，是不是要考慮負載均衡。如果可以的話，業務是不是可以不用再維護開發某些通用共性的組件了，如數據庫、消息處理等等。由平臺來提供，應用只管用就可以了。現在互聯網上提供很多SaaS服務就是解決這方面的問題。

總的來說，我們最終把應用分成了4個概念，容器，主要解決是打包和運行時依賴的問題。POD解決多進程協作問題。有的應用沒有辦法放到兩個容器里，這時候我只能放到多進程一起跑，包括容器的網絡，IP的問題，存儲的問題都在POD里面解決。服務就是微服務的概念，微服務有同構性、可拓展性，很多微服務就可以構成一個大的應用。

應用最終就是兩個階段，運行前和運行中。運行前要做編排和初始的配置，存儲的計劃。運行中，應用提供的服務怎么讓別人訪問到，負載怎么調度起來，資源狀態調整的問題，應用出了問題如何分析定位、解決以后如何升級。運行期占應用整個生命周期最長的，這才是平臺最重點需要關注和解決的地方。

應用初始主要是配置問題，有一些應用，有一些初始配置。比如應用研發中有兩個環節，一個測試環節，一個開發環節。在兩個階段，應用都需要往數據庫里面寫數據。那如何發現數據庫呢？可以利用兩套DNS，這樣應用遷移到新環境時不需要配置變更。但需要管理DNS。也可以做成初始配置，不同環境使用不同的配置。 我們重點解決的是應用里面靜態的配置問題，以及應用元數據的問題 。這里我們復用了OpenStack Metadata服務，并做了增強改造。可以兼容Kubernetes ConfigMag格式。配置服務里面存儲的元數據既可以用到編排文件里面去，也可以應用到容器環境變量里面去，也可以在業務運行起來之后通過我們的公共的服務API就可以訪問容器里面的信息。這個API會告訴訪問者，你是誰，你屬于哪個應用，你屬于哪個用戶，你屬于什么環境，配置的內容是什么……這些信息應用可以用來做自身判斷。這是關于配置方面的。

這一頁是存儲這塊的。我們選擇使用Cinder。在我們的平臺上，用戶根據業務需求的不同可以選擇不同的設備。可以選擇像NFS，如果只是存儲大量冷數據。也可以選擇塊設備，如果業務需要有大量的存儲IO。把應用的存儲的信息放到配置文件里面去。Kubernetes運行的時候，就可以把存儲塊掛到相應的位置上。如果不是主機的本地硬盤，直接通過存儲網寫過去就可以使用了。這樣業務的數據就可以寫到外面來了。容器里面寫數據是挺危險的事。

這一頁是關于動態資源調整這塊，容器能提供給我們的主要是CPU和內存。 一個應用在運行過程，僅靠這兩個指標并不一定能做出準確的判斷 。比如說網絡應用，鏈接數可能是很重要的指標，但是放入通過容器Docker是拿不到的。有一些應用，壓根跟用戶不打交道，自發性的。我們曾經有一個運營商的應用，這個應用本身是做網元采集的，需要采集幾千個網元。關于資源調度考慮的不僅僅是幾個指標，要靠一個很復雜的算法。一些因子如還有多少網元沒有采，單個采集任務的消耗量是多少，現在有多少并發采集，有沒有線性采集的。還有些網元有特殊性，比如說12點之前不把數據采集來就沒有了。這些通過一個通用的CPU+內存是解決不了的。所以，在設計時，我們的平臺提供了擴展的接口。一方面，應用可以實現我們規定的接口。平臺通過這個接口可以拿到鏈接數這種標準的數據。我們拿到這些數據，也可以通過我們下面說的動態資源調整API，把數據回饋給應用。應用通過自身的邏輯算法來確定是否要動態的調整資源。當然，基礎的基于CPU和內存負載動態的調整做為基本功能，平臺也是支持的。

服務發現我們提供了三種一個是Kubernetes的Service，還有Neutron LBaaS，最后我們做了一個HWLB的擴展，應用要放到公網，或者直接面對終端用戶，從可靠性，性能等方面要考慮。

日志這塊主要是三個，容器Console日志，從持續性上，從清晰度上可能會亂。我們就有一個日志目錄，應用持載并寫日志，平臺能嚴格保證日志的持續性和文件的結構性。最終通過我們底層的平臺處理完以后，用戶什么時候想要，我們就給。并且保證你原來的目錄結構和原來的時序都可以保障。平臺本身也提供了查詢，但是不一定滿足，特別復雜的分析。我們也提供了下載功能和對外輸出。

資源提供者這塊，主要是四塊，一塊是監控，各種各樣指標的收集。第二就是高效，響應速度要快，要資源立馬能給，使用率要高，CPU、內存使用率，對資源的消耗要高。第三審計和分析，不僅對常見的東西做出告警。最好能做到異常發現。第四異構，企業里面有很多固定資產，必然面臨異構的問題。我們寫了很多技術選型和方案，下面都像個倒樹的分支，要解決異構性的問題。最終是多種資源混合管理，同種資源一致化。

資源管理監控，我們用的是Ceilometer，我們存儲后端使用的是HBase。我們對存儲后端和API接入方式都進行了大量的擴充。可以說除了Ceilometer這個名子，已經差別很大的。主要解決了性能和穩定性的問題。監控分析子系統，分析數據的結果有幾個用途，一個就是產生報表，最重要的是實時分析負載，這個分析結果會影響我們調度系統，關于容器調度的結果。

多個進程的容器怎么處理？我們碰到這么一個案例，兩個進程必須得跑在一個主機上。程序是非常重量級的，非常不好改。我們對Kubernetes做了一些增強，我們加了一個IPC調度。運行過程當中，A程序聲明依賴于XXX命名空間，B程序聲明能提供XXX命名空間。在調度時，如果一個容器上已經有了一個XXX的消費者的時候，就不會往上面做調度了。如果還沒有XXX提供者，就先pending A程序的調度。

容器無差別調度的時候，有一些容器業務要求IO非常高，會把一些機器壓死。我們用了資源分區的方式，對主機做了很多標簽。這個容器希望什么標簽，就往這個容器調度什么。容器不喜歡什么標簽，就不要往這個容器上進行調度。通過親全性、反親合性的組合使用。以及主機標簽的設置和自動發現，來讓資源需求和提供達到最佳的適配。

還有過一個故障，程序總體運行是正常的。但是仔細觀察，發現有一些業務的抖動。后來才發現是程序會崩潰掉。平臺對服務有自恢復機制，一死就拉起來了。所以總體上看，沒有反饋出來程序的問題。總體看起來不錯，實際上內部是有問題的。我們通過平臺上的pod_time和service_pod_avg_up_time這兩個指標最后發現。然后通過日志進行分析，才最終定位了崩潰的原因。

最后，這一頁，我們用了很多技術，從技術架構上就做出了這么一個東西，我們能夠對容器進行統一的管理和調度，并且共享了很多公共的技術，這個架構還可以繼續往下延續。

這是我們做出來的產品，我們的宣傳冊也有相應的介紹。我們產品的目標就是最新的技術更好支撐應用的運行以及應用的運維。讓應用的運行和維護更簡單和可靠。我主要介紹的就這么多！謝謝大家。

Q&A

Q：我聽了以后很過癮，您講的很深也很全。我關注的是數據庫軟件和Docker的融合，好像沒有這方面的內容。數據庫的特點體積比較龐大，跟容器類的解決方案組合到一起的話，會不會像您說的對應用支撐更好，能不能往這個趨勢上走？

A：這個問題非常好。關于平臺上的能力，關于數據庫這些東西，我們平臺本身已經做了一部分，有的已經上線了，比如說MySQL已經上線了，我們做的是MySQL的主備方案。測試環境下效率和穩定性還是比較好的。原來從裝機開始，虛擬機做模板很麻煩，開機需要幾分鐘、十分鐘，這會只需要點一下，一分鐘不到就可以直接用了。MySQL比如說HA，我們需要更深入的測試一下。目前我們的HA方案共享存儲的方式。后面考慮集群模式，要借助MySQL galera中間件。我知道他們已經做了，上面有一個代理，所有的流量通過它，解決數據一致性和完整性的問題。

Q：有沒有數據用了以后和以前，性能上有一些數據對比嗎？

A：數據的詳細對比，我手里暫時沒有，但是我們正在做，很快會發布。

Q：像您的產品有高端用戶在用，當初打動他們的點是什么？

A：一個是整體性，不管怎么說，容器是IT技術的一環，我考慮的是整個IT如何完整進行支撐，或者IT是一個演進式的發展，企業和互聯網公司巨大的區別，互聯網公司的IT是自建自用，本身具有延續性的，企業用戶一般走的都是項目采購的方式，采購這一家的，隔幾年可能換一家的。前后兩家不可能做一模一樣的產品。如何產品不能從全局考慮，不具有延續性，過幾年肯定得淘汰了。對產品的延續性，整體思考性，整體性解決能力要強一點。

Q：天云軟件有沒有對混合云、企業私有服務進行容器化支持？

A：這個分兩塊，首先我們有一款IaaS產品，CMP，本身就是企業私有云混合管理的解決方案。我們做的容器產品，目前我們對CMP有一定依賴，IaaS的混合和IaaS層的異構支持就是基于那個產品。IaaS層面，我們的CMP的產品是非常全面的。

Q：您說微服務，物理機最多跑2個容器，如果我其中一個容器死了，我怎么做，我是新創一個容器加進來還是怎么做？

A：Kubernetes有一個RC機制，如果你的容器死掉了，立馬生成一個給你替換掉。這個對無狀態支持是非常好的，如果你是有狀態的，數據狀態的，寫數據，這個問題我們已經解決了，需要把數據遷移走。因為數據是放在外面，不是放在容器里面的。還有一些非常敏感的應用，還有身份的問題。應用內部生成一個ID做唯一的憑證。如果死了，再起一個容器，ID變了，不叫這個名和IP了，應用就不認了。這種情況需要有一個身份保持的問題。目前，我們已經解決的網絡層面IP保持的問題。如果容器死了，我再生成一個，它起來一個，我保證原來的IP不變。從外部性來看，它還是那個容器。身份狀態嚴格保持的技術，目前正在試驗。如果程序里面有一些特殊的東西，這個就需要再看一下，具體問題具體分析。暫時還沒有通用的方案。

Q：如果這臺死了，只能保證宿主機的IP加一個端口。容器里面跑一個程序，我跑物理機只需要提供物理機的客戶端的端口，五可以通過端口監控，我不能在容器里面加一個客戶端？

A：平臺只能監控到容器外部的CPU這些東西，如果需要在容器里面監控更多的東西，采用我們的方式，是可以做的。如何應用沒有辦法改造，你剛才說的，從解決問題的角度來說不是不可以，也可以解決問題，只是感覺不太好用。但是總能拿到這個數據。如果你的應用不具有安全性的一些特殊設置，可以嘗試HOST模式，就不存在這個問題。但是如果一定要用了Docker的方式隔離，暫時就沒有辦法了。

Q：現在你們BOSS系統和網管做到什么程度了？

A：BOSS已經上線運行了，但是還沒有大范圍推廣。BOMC研發已經結束了，快上線的狀態。具體的項目不方便在這里說。

Q：BOSS系統里面有好多模塊，和模塊掛在一起，怎么處理異常情況？

A：一般來說，我們系統能支持到的，可能大部分都是一些通用的模式，如果在這種模式范圍之內，我們都會放在平臺上去做，但是平臺也不是萬能的。很多情況下，只能依賴于應用自身的改造。平臺可以做監控或者重啟并且恢復狀態，但是你的程序本身要具有一定的容錯性。你掛了，我把你拉起來，你得自己能工作，你能加入到原來工作的序列里去。如果我把你拉起來，你業務本身不支持這種模式的話，你只能支持我原來配置的模式的話，就要改一下了。

 

 

 

來自：http://mp.weixin.qq.com/s?__biz=MzA5OTAyNzQ2OA==&mid=2649692052&idx=1&sn=413fe320f15560d60a72f132a0572576&chksm=889328f7bfe4a1e10662c8b2593bdc89e314c92e795d3e493f29ab5e3137ff71b5fd054ac50c&mpshare=1&scene=1&srcid=1008FejOKbJqktdJq2z6xeAJ#rd