本文講的是
傳統企業應用容器化的痛點、坑和解決之道【編者的話】本次分享将講解容器化技術對傳統企業的價值；傳統企業在應用容器化技術改造核心應用如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：一般來說，我們系統能支援到的，可能大部分都是一些通用的模式，如果在這種模式範圍之内，我們都會放在平台上去做，但是平台也不是萬能的。很多情況下，隻能依賴于應用自身的改造。平台可以做監控或者重新開機并且恢複狀态，但是你的程式本身要具有一定的容錯性。你挂了，我把你拉起來，你得自己能工作，你能加入到原來工作的序列裡去。如果我把你拉起來，你業務本身不支援這種模式的話，你隻能支援我原來配置的模式的話，就要改一下了。
本文根據9月24日沙龍講師演講内容整理而成，講師介紹：劉春陽，北京天雲融創軟體技術有限公司 研發總監。負責公司容器化平台産品的規劃和研發。對Docker、Kubernetes、OpenStack等有豐富工作經驗。
原文釋出時間為：2016-09-29
本文作者：劉春陽
本文來自雲栖社群合作夥伴Dockerone.io，了解相關資訊可以關注Dockerone.io。
原文标題：傳統企業應用容器化的痛點、坑和解決之道