容器、微服務、DevOps三者，業內的共識是密不可分。沒有微服務，DevOps落地不下去，沒有容器，DevOps也無法真正實現敏捷運維、自動化運維。DevOps、容器、微服務爲更好的構建PaaS提供了方法論和技術手段。
1
PaaS之承上啓下
PaaS作爲雲計算的承上啓下要素，向上支撐各環境應用，向下跟IaaS、計算環境、計算資源對接，是企業雲化的必由之路。
PaaS三大技術趨勢
1.應用容器化，容器正在成爲雲計算原生應用的標準交付方式。
2.微服務網格化，隨着企業對微服務的認知越來越深入，下一代微服務着重把應用管理作爲核心。因爲企業應用一定要有很強的管理在微服務架構上，不能讓應用去“裸奔”。數人云沒有提微服務化，因爲微服務化已經是不爭的事實。應用微服務缺乏強大的管理，需要服務網格這樣的下一代微服務技術。
3.行業生態化，PaaS技術本質上是支持應用的，應用跟業務緊密結合，所以PaaS最終是要和業務層面融合，行業需要生態化。
PaaS落地三大要素：
PaaS要在企業客戶方面落地不可或缺三要素:規模化、統一化、標準化。企業客戶落地雲計算平臺、技術，本質上是希望提高效率，對業務有更好的敏捷支撐。
所有應用，比如容器應用、微服務應用，都實現標準化。標準化以後進行統一化管理，包括部署、發佈、故障恢復、監控告警等都實現統一化管理。最後實現模塊化，整個系統都是輕量的，微小模塊化的。只有基於這三點的PaaS平臺和雲計算平臺，才能夠讓IT系統真正實現敏捷輕量，提高IT對業務支撐的效果。
2
企業IT架構轉型之開發&運維
企業客戶目前在架構轉型應用中面臨的現狀是，企業裏大量傳統應用，客戶希望先實現輕量的單體架構，即擺脫很多中間件，擺脫外部服務，MVC架構、單體複雜架構等首先實現輕量化。
數人云日常接觸的客戶中，走的比較靠前的客戶已經在用Spring Cloud、Dubbo等架構，部分客戶相當數量的應用已經微服務化，不過處於中間狀態，正在考慮評估微服務架構的客戶比例還是最大。總之，企業目前的現狀是爲服務應用、輕量單體應用，以及傳統的巨石應用並存。
在架構轉型過程中，正確和常態的路徑一定是一步步走過來，而不是傳統架構丟掉直接上微服務。
DevOps和容器@輕量單體應用架構
在單體應用架構下，DevOps、容器幫助企業實現敏捷IT。首先，持續集成持續交付CI/CD，只要應用是相對輕量的，就能加快中間件應用。CI/CD其中重要的一點是變更發佈管理。
數人云某客戶上了容器的應用都是輕量化的，基於 Tomcat 和微服務的應用。當基於容器實現快速發佈以後，企業發現，所有發佈裏有一半的發佈失敗是由於配置不正確引起的。所以，如果沒有發佈變更管理，發佈失敗的中間環節有方方面面的因素。
當基於容器實現快速發佈之後，容器對環境的異構做了一層屏蔽，這時如果出現處理的問題就是配置管理的問題了，由於涉及不同的環境和應用，配置環境變成應用發佈很容易出錯的環節。
DevOps和容器@微服務應用架構
數人云做了企業客戶微服務落地狀況的調研（微服務2017年度報告出爐：4大客戶畫像，15%傳統企業已領跑），在報告中，有15%左右的企業引入了Spring Cloud、Dubbo。微服務在企業裏首當其衝的是敏捷開發，因爲微服務是一種切實的敏捷開發的方法。
敏捷開發在IT界已經推廣多年，但很多時候敏捷開發推的都是方法論，比如Scrum。微服務是一套切實能夠落地到IT人員、開發人員開發過程中的實踐方法，這是微服務首當其衝的好處，很多企業的開發部門對微服務非常歡迎。不過，15%還是偏小的一個採用比例，微服務還不是企業客戶主流的IT架構。
開發人員都比較歡迎微服務，因爲能夠提升開發效率，落地敏捷開發，但微服務的阻礙還是不小的，微服務對開發運維來說，帶來的複雜度急劇上升。傳統運維管理的服務器數量、應用數量有限。企業決定採用微服務本身就表明業務很複雜，單體應用做傳統的瀑布式開發效率太低，微服務將應用拆分成較小的模塊，因此微服務應用一旦上線，程序的數量呈現爆炸式增長。
例如，數人云某個傳統企業的客戶，目前部署了微服務相關的應用，基於Spring Cloud、Spring Boot，跑在幾千個容器上，幾千個容器如果通過傳統運維方式去管理的話幾乎是不可能的。這就是很多微服務無法落地的原因——很多企業客戶缺乏相應的運維能力，沒有相應的平臺、工具、方式、方法管理微服務應用。
微服務落地的必要條件
微服務應用落地，首當其衝是配套工具鏈的完善。開發人員採用微服務的影響相對改變小一些。採用SpringCloud或者Dubbo、gRPC等，只是開發框架上的並更。其他開發流程如代碼託管、代碼審查、測試等並不涉及，所以開發流程相對簡單。但微服務對運維功能的要求就會複雜，相應的快速配置能力、完備的監控能力、快速部署能力等對傳統運維來說都是缺失的，容器能夠補足這方面的能力，讓運維部門具有DevOps的能力。
關於微服務的拆分，其實是業務部門需要真正解決的問題。微服務對組織上也有變更，將團隊化整爲零。通常每個單獨的微服務程序都由7-10人的小團隊來負責維護，這些都是微服務落地的必要條件。
對於數人云來說，直接能夠給客戶提供的幫助，首先是工具鏈方面，數人云產品層面具備豐富的微服務配套工具鏈，從監控、日誌、調度、故障自動化修復等等都有完備的工具鏈。在落地方法上，數人云搭建了自己的生態圈，和很多合作伙伴合作，例如跟埃森哲公司在合作，幫助企業客戶落地微服務，進行業務的梳理。
容器和微服務共生
容器技術補齊了微服務相關的工具鏈，對企業全面向雲計算轉型提供了很大幫助。應用架構是微服務分佈式的，相應的運維也要有自動化、敏捷運維的能力。微服務跑在容器上才能發揮它最好的特性。容器是目前最流行的應用環境，基於容器的微服務部署和更新更快，更輕量，服務之間的調用、服務發現、負載均衡等更靈活。
不過，微服務不是萬能的。簡單的業務場景單體應用其實足夠，微服務一定是應用在複雜的業務場景下，只有複雜的業務場景纔有很大的維護成本、維護壓力，微服務是用來降低複雜業務場景的維護成本。
基於容器雲的微服務運行時管理體系
一個完整的微服務管理體系，除了開發框架之外，對運維部門來說，運維微服務應用最基本的路由、負載均衡等功能，容器可以提供，不過容器提供的只是一部分跟微服務相關的能力和工具鏈。周圍還有一大批需要配套的工具，比如配置管理、API網關、註冊發現、應用監控等等。這裏的監控不是容器CPU內存的監控，而是業務邏輯的監控，更準確一點是全鏈路跟蹤的全鏈路監控。容器滿足了微服務運行時管理的需求，不過周邊許多權限、網關、配置等尚無餘力滿足。
統一配置中心是微服務體系的核心
統一配置管理，是微服務落地時很核心的點。要在平臺工具上落地微服務首先要具備快速配置能力，因爲客戶採用微服務和容器平臺以後，很快會發現50%以上的發佈失敗是因爲配置沒搞對，因此配置管理是微服務裏首當其衝的問題。
因爲每個企業客戶都有開發環境、測試環境、生產環境等很多環境，同一個應用不同版本在不同環境下的配置不同。幾何級數的配置項、配置元素的增長會導致配置管理的複雜度急劇上升，需要統一的配置中心進行管理。數人云在幫助企業客戶落地微服務時，首先會做的是把配置搞定，沒有靈活快速的配置管理能力，微服務運行不起來。
變更發佈管理（灰度發佈 v.s. 藍綠部署）
在發佈管理方面，數人云幫助企業落地的發佈管理主要是藍綠部署，因爲很多企業的應用本身不支持灰度發佈。藍綠部署也是切切實實的快速發佈，發佈用變更窗口的方式來實現。
例如，週五晚上12點起進行發佈變更，12點就要停服務中心。藍綠部署可以顯著地縮短服務不可用的變更窗口。怎麼做呢？客戶在線上有兩個版本，藍版本和綠版本。現在負載均衡器將流量指向對外提供服務的綠版本，藍版本作爲備用的方案。同時，新程序往藍版本上部署推送，更新時只需要把流量切換到藍版本。發佈流程最後簡化爲只需要進行流量的切換。流量可以快速切換，中間的窗口期只有短短幾分鐘，如果流量切換過來一切正常發佈即完成，如果流量切換過來發現問題，可以再將流量切回去。這樣開發人員、運維人員不必當場熬夜去修復，極大地減輕了發佈的壓力。
傳統發佈方式下，每次變更窗口有好幾個應用排隊發佈，一個應用發佈完成後纔可以發佈下一個應用，一旦中間某一個應用發佈失敗現場修復的壓力非常大，短短的發佈窗口需要幾個小時內完成搶修，非常不可控，團隊經常需要晚上熬夜排隊。而結果往往等了半天，前面的應用沒發佈成功，後面的還得繼續排隊等。
3
金融行業之踐行漸進
數人云在金融、能源、製造、快消、政企等行業的基礎上，繼續深耕強監管、強安全，高複雜度的金融行業。以某商業銀行爲例，數人云幫助落地了大規模微服務容器平臺。該商業銀行近年來互聯網業務發展迅猛，原有系統架構無法支撐其未來規劃。2016年6月開始全面實施應用微服務化，已實現藍綠髮布。
首先，營銷系統全部是輕量化的應用，基於Spring Boot、Tomcat、SpringCloud等，跑在容器平臺上。該銀行對外營銷頻次非常高，通過線上微信公衆號、手機APP、線上門戶、合作伙伴等渠道，每月對外營銷達上百場。
客戶背景和規
每次營銷活動或多或少都對IT系統有變更，哪怕是配置變更，因此每次營銷活動對IT系統都是一次不小的挑戰。發佈的時候僅僅靠容器是不夠的，需要實現模板的批量發佈。每次發佈看起來只是一個個的容器程序，實則不然，其實是一組組一批批的容器，只有幫客戶做到批量的應用發佈，才能顯著提升發佈效率。
藍綠部署方面，該銀行密集的線上營銷中，每一天會有一個重點營銷活動，那麼營銷活動的流量如何分到特別的人羣、區域？在後臺應用的上千個實例中，並不是每一個實例都分配同等的流量，要通過流量分發，做線上流量控制。數人云借鑑Google做灰度發佈的方式爲客戶提供圖形化的流量控制，這和微服務實施後的限流分流是息息相關的。
另外，該銀行客戶的數據流量非常大，對日誌收集帶來非常大的的壓力。數人云建議客戶將應用程序的日誌全部交給Kafka採集，Kafka可以做到很大數據流量的分佈式消息應用。
分佈式數據傳輸分佈式消息應用很難保證每一個消息都可靠地傳遞。Kafka有兩種模式：一種保證消息傳遞至少一次，但也可能多次，對很大的日誌量來說偶爾丟一兩條可以忽略不計。Kafka的併發量很大，可能帶來偶爾很小的數據量丟失，也可能帶來日誌的亂序，這在分佈式系統下都是可以容忍的，“魚和熊掌不可兼得”。
關於快速建立支撐微服務體系，數人云有幾點總結：
>>>>數人云微服務On PaaS 產品體系
數人云現在的重點是微服務、輕量單體應用。以前數人云幫企業客戶落地重應用的容器平臺，但後來發現價值不大，反而對企業來說，除了維護重的應用外還需要維護容器，容器平臺並不能實現自動化運維。經過幾年的實踐和摸索，數人云跟企業客戶達成的共識是，傳統應用不經過改造無法上到雲PaaS平臺。
輕量架構下的應用如何基於PaaS平臺支撐？以敏捷開發爲例，企業客戶通常選擇 Spring Cloud、gRPC 等主流的開發框架，然後在微服務工具鏈層面配置監控、報警、部署、快速發佈等方方面面的能力，最下面承載的則是容器平臺。
數人云現在還可以幫助客戶落地服務網格化技術。它能夠進行異構架構的兼容，gRPC就是服務網格的一部分，Google推的 Istio，Linkerd的Kubernetes 都支持 gRPC，gRPC成爲通訊協議的一部分。基於通訊協議相應周邊的管理，在服務網格這一層可以做灰度發佈、A/B測試、流量控制、高級熔斷、加密、白/黑名單機制、權限訪問控制等等。
服務網格被稱作下一代的微服務，因爲用了服務網格以後，所有微服務管理的訴求都自動化地滿足了。80%-90%的應用管理需求都在服務網格里自動涵蓋。這對開發人員來講，微服務開發的門檻急劇降低，不需要考慮未來應用上線時流量控制、灰度發佈等等，只需要考慮業務。數人云微服務On PaaS 目的就是幫助企業客戶降低微服務架構、上雲轉型的門檻。
A1：DevOps準確來講，現在業內還沒有統一的認識。互聯網公司的DevOps目前是比較統一的，比如Goolge，但是互聯網公司的DevOps，我個人理解沒辦法在企業直接落地。
在Google，程序員不止要負責應用的開發，還要負責相應的測試，單元測試、集成測試等等。另外，應用的部署、發佈、上線也是開發人員自己做。所以互聯網公司講DevOps，更多講的是開發運維的融合。我之前在Google時，不僅要做代碼開發，也要把測試的代碼全寫出來。
Google有一個理念，開發人員每寫一行業務代碼，測試代碼要寫十行。然後，開發人員利用各種發佈平臺定期發佈，比如每週做發佈，在Google 運維的人員叫“SRE”。SRE部門準備好各種平臺，開發人員可以用這些平臺做發佈、監控、日誌管理等工作。
Google目前有三萬名左右的IT人員，其中SRE的運維人員只有一千多，比例很低。所以在Google運維人員不可能幫每一個開發人員或者業務部門做上線。像傳統IT開發人員提工單給運維，在Google是不可能的。Google這種做法，它讓開發做更多的事情，運維人員很少，只是負責維護平臺。所以，Google一千多人管理着幾百萬臺服務器，平均每人管兩千臺。
但傳統企業目前不是這樣，傳統企業開發和運維之間壁壘比較大。數人云幫助客戶落地DevOps 時，基於的理念是，不要破壞現有開發的流程。DevOps應該是開發和運維深度融合才能做到的。講DevOps，首先要講理念、組織的變革，但是要想把文化變革、組織變革打破要很長時間。
從落地的角度，DevOps更多落地在運維部門，很具象的工作就是，幫助運維部門去實現DevOps的能力，比如快速部署、快速上線，應用的快速配置，自動化管理能力、故障的自動化處理等等。把以前的運維工作儘可能的自動化，提高效率，這是狹義的DevOps理念，也是我們現在接觸到的。數人云不會幫客戶落地像互聯網公司那樣的DevOps，開發做很多事情，運維可做的很少，並不是這樣的。
A2：第一個促銷場景，促銷場景本身有些條件，促銷很重要一點就是必須特別頻繁，促銷內容在平臺要發生變化。比如，今天的促銷內容和明天的不太一樣，或者這周的促銷和下週的不太一樣，業務平臺需要頻繁變更，這時候微服務是適合的。
因爲微服務是一種敏捷開發的落地實踐方法，只要業務頻繁變更，對開發的要求就必須敏捷開發，快速實現。所以，只要業務場景在不停地快速變化，促銷又是互聯網線上的方式，肯定是適合的。
關於複雜性，如果業務邏輯簡單，邏輯變化少，並不適合微服務。比如數人云和很多銀行客戶合作，銀行核心系統很複雜，但是銀行系統並不是需求頻繁變化的場景。很多銀行在做“瘦核心系統”，就是銀行核心系統的功能越來越單一，越來越瘦，並不是把複雜的周邊的業務也放到銀行核心系統裏。銀行核心系統雖然複雜，但業務不會頻繁變化，也不一定要上到微服務場景下。複雜的業務系統，業務需求又不停變化，這種場景適合微服務。
第二個問題是和ESB 比，服務網格和 ESB 有很多相像的地方。ESB有業務邏輯串起來，很多不同的業務系統都上到ESB，互相的權限通過ESB打通。從功能角度講，ESB和服務網格之間很相像，不同點在於ESB是傳統架構下的，並沒有考慮頻繁迭代、流量集中爆發等問題。
但是微服務情況下，整個之間的互相請求、依賴、通訊等等都會進行統一的管理，這種情況下也很像ESB把不同業務之間的流量進行統一管理，但是服務網格更看重的是面向大規模的控制，那流量突發怎麼做限流，或者突然故障怎麼做熔斷等等。最本質的問題是類似的，但是具體的問題表象和需求不同。
A3：數人云當初兩種情況都有，有些場景比如業務量比較大，企業客戶爲了減少複雜度，容器PaaS平臺直接落地到物理服務器上。還有客戶爲了方便管理，把PaaS落地到IaaS上，兩種情況都有。
這其中的考慮是，首先業務量大如果再引入虛擬化這一層會引來額外的複雜度，此時用物理服務器更好。其次，客戶有很大規模的物理服務器，直接在上面部署PaaS，在物理服務器上去調用。
第三種，資源動態的調整或資源頻繁調配，這個場景很常見，需要IaaS。比如銀行客戶，內部業務系統分不同的域，不同域的業務複雜性隨時間變化經常會發生變化，需要不停地做資源動態的調整。如果用物理機太麻煩，企業客戶會選擇下面有一層IaaS來做。
基於PaaS也能做一部分的資源動態調配，但是調配維度不同。數人云幫客戶落地PaaS時會做資源的整合。從劃分的維度，PaaS平臺是按照應用程序來劃分，IaaS的資源劃分是按照業務系統。
A4：首先第一個問題，微服務的開發框架。企業客戶在做選擇時都希望降低風險，選最主流的框架，現在看最主流的開發框架就是Spring cloud，這也是業界的自然選擇結果。其他語言也都有些微服務開發，但是用的人少一些。如果是Java應用，目前比較好的選擇是Spring Cloud，也有很多客戶用了Dubbo，其他架構都是偏小衆的架構，主要還是看客戶自己的需求。
第二個問題，傳統業務要轉到微服務架構上，一定要循序漸進。比如Java應用，首先Java中間件的應用，先脫掉，不要再基於這麼重的Java中間件。目前相對流行的是Spring Boot這套邏輯。
有了輕量的單體化應用之後（基於Tomcat），往後走基於微服務的框架，上到Spring Boot，再上到Spring Cloud，這是比較平滑的方式。Spring Boot 在很企業客戶中用的非常多，是很方便的一套單體開發架構。
企業客戶目前的現狀是老的應用很多，不會一次就改造完，傳統的應用可以先選擇一部分容易轉的轉到輕量單體架構上，然後再轉到微服務框架上。目前企業客戶是輕量的單體架構、微服務架構，以及大量傳統的架構應用並存。老的架構應用目前上不到PaaS平臺，只有輕量的單體化加微服務應用才能上到PaaS平臺。
現在業內的共識是，微服務、容器、DevOps這三者是密不可分的。微服務更多是針對開發人員，是一種真正落地的雲開發方法。很多企業客戶也講敏捷開發，派團隊成員學習敏捷開發的方法論，但是敏捷開發仍然無法在企業當中落地。
這是因爲，只學會了方法，但沒辦法落地到具體的編程，即開發環節上去，自然沒辦法做到敏捷開發。很多開發者回來寫的程序依然是J2EE。J2EE 編程的理念和方法並不是敏捷開發的，是偏向於瀑布式的。
微服務是具體的開發環節上的敏捷開發方法，開發能力化整爲零，每個團隊做簡單、具象、單一的邏輯。微服務首先是一個具像的敏捷開發方法，實踐方法。
微服務在落地時，比如程序運行時，複雜度很高，因爲不是一個程序，是一批程序一起運行，對運維的管理就比較複雜，這時候可以利用容器實現微服務應用的自動化管理。微服務一般都會上到容器，因爲微服務應用不再是單體的部署方式，不再是部署到Java中間件上。基於微服務架構，幾百個進程進來，用容器的方式實現快速部署動態調度，微服務部署到容器上，實現基礎的輕量化運維。
輕量化運維，快速部署、自動化調度，逐步往DevOps方向走。DevOps更多強調自動化的運維能力，提高運維的效率，快速部署，出了問題自動化修復。需要用到工具和平臺，這就是數人云現在幫客戶去做的。
把微服務業務在運行時缺失的管理方式方法、工具平臺，工具鏈補齊。首先是配置管理能力、完備的監控能力等等，普及之後運維人員就有能力來管微服務應用。這其實是DevOps裏面最狹義的，讓運維的能力變得輕量。
如果要真正實現DevOps，就像目前一些互聯網公司做到的，開發和運維真正的深度融合在一起。企業目前的運維一般不具有編程能力，所以真正的DevOps還需要很長時間去落地。
PPT下載：
在數人云公衆號後臺回覆“0113”，即可獲得本次演講PPT。
