1月13日榔昔，中國(guó)雙態(tài)運(yùn)維用戶大會(huì)在北京舉辦。來(lái)自銀行定硝、保險(xiǎn)皿桑、證券、政府、央企等多個(gè)行業(yè)的330多位企業(yè)用戶參加诲侮，其中工商銀行信息科技部副總經(jīng)理張艷镀虐，國(guó)泰君安信息技術(shù)部總經(jīng)理俞楓、海關(guān)總署科技發(fā)展司運(yùn)行安全處處長(zhǎng)張芳沟绪、平安科技系統(tǒng)運(yùn)營(yíng)部總經(jīng)理陳亞殊等分別發(fā)表了演講刮便。本文為數(shù)人云CEO王璞在雙態(tài)運(yùn)維用戶大會(huì)DevOps、容器與微服務(wù)分論壇上的演講實(shí)錄绽慈。演講結(jié)束恨旱，與在座金融客戶展開了精彩的Q&A分享。

容器坝疼、微服務(wù)搜贤、DevOps三者，業(yè)內(nèi)的共識(shí)是密不可分钝凶。沒(méi)有微服務(wù)仪芒，DevOps落地不下去，沒(méi)有容器耕陷，DevOps也無(wú)法真正實(shí)現(xiàn)敏捷運(yùn)維掂名、自動(dòng)化運(yùn)維。DevOps啃炸、容器铆隘、微服務(wù)為更好的構(gòu)建PaaS提供了方法論和技術(shù)手段卓舵。

1
PaaS之承上啟下

PaaS作為云計(jì)算的承上啟下要素南用，向上支撐各環(huán)境應(yīng)用，向下跟IaaS掏湾、計(jì)算環(huán)境裹虫、計(jì)算資源對(duì)接，是企業(yè)云化的必由之路融击。

PaaS三大技術(shù)趨勢(shì)

1.應(yīng)用容器化筑公，容器正在成為云計(jì)算原生應(yīng)用的標(biāo)準(zhǔn)交付方式。

2.微服務(wù)網(wǎng)格化尊浪，隨著企業(yè)對(duì)微服務(wù)的認(rèn)知越來(lái)越深入匣屡，下一代微服務(wù)著重把應(yīng)用管理作為核心。因?yàn)槠髽I(yè)應(yīng)用一定要有很強(qiáng)的管理在微服務(wù)架構(gòu)上拇涤，不能讓應(yīng)用去“裸奔”捣作。數(shù)人云沒(méi)有提微服務(wù)化，因?yàn)槲⒎?wù)化已經(jīng)是不爭(zhēng)的事實(shí)鹅士。應(yīng)用微服務(wù)缺乏強(qiáng)大的管理券躁，需要服務(wù)網(wǎng)格這樣的下一代微服務(wù)技術(shù)。

3.行業(yè)生態(tài)化，PaaS技術(shù)本質(zhì)上是支持應(yīng)用的也拜，應(yīng)用跟業(yè)務(wù)緊密結(jié)合以舒，所以PaaS最終是要和業(yè)務(wù)層面融合，行業(yè)需要生態(tài)化慢哈。

PaaS落地三大要素：

PaaS要在企業(yè)客戶方面落地不可或缺三要素:規(guī)穆樱化、統(tǒng)一化岸军、標(biāo)準(zhǔn)化奋刽。企業(yè)客戶落地云計(jì)算平臺(tái)、技術(shù)艰赞，本質(zhì)上是希望提高效率佣谐，對(duì)業(yè)務(wù)有更好的敏捷支撐。

所有應(yīng)用方妖，比如容器應(yīng)用狭魂、微服務(wù)應(yīng)用，都實(shí)現(xiàn)標(biāo)準(zhǔn)化党觅。標(biāo)準(zhǔn)化以后進(jìn)行統(tǒng)一化管理雌澄，包括部署、發(fā)布杯瞻、故障恢復(fù)镐牺、監(jiān)控告警等都實(shí)現(xiàn)統(tǒng)一化管理。最后實(shí)現(xiàn)模塊化魁莉，整個(gè)系統(tǒng)都是輕量的睬涧，微小模塊化的。只有基于這三點(diǎn)的PaaS平臺(tái)和云計(jì)算平臺(tái)旗唁，才能夠讓IT系統(tǒng)真正實(shí)現(xiàn)敏捷輕量畦浓，提高IT對(duì)業(yè)務(wù)支撐的效果。

2检疫、企業(yè)IT架構(gòu)轉(zhuǎn)型之開發(fā)&運(yùn)維

企業(yè)客戶目前在架構(gòu)轉(zhuǎn)型應(yīng)用中面臨的現(xiàn)狀是讶请，企業(yè)里大量傳統(tǒng)應(yīng)用，客戶希望先實(shí)現(xiàn)輕量的單體架構(gòu)屎媳，即擺脫很多中間件夺溢，擺脫外部服務(wù)，MVC架構(gòu)烛谊、單體復(fù)雜架構(gòu)等首先實(shí)現(xiàn)輕量化风响。

數(shù)人云日常接觸的客戶中，走的比較靠前的客戶已經(jīng)在用Spring Cloud晒来、Dubbo等架構(gòu)钞诡，部分客戶相當(dāng)數(shù)量的應(yīng)用已經(jīng)微服務(wù)化，不過(guò)處于中間狀態(tài)，正在考慮評(píng)估微服務(wù)架構(gòu)的客戶比例還是最大荧降〗芋铮總之，企業(yè)目前的現(xiàn)狀是為服務(wù)應(yīng)用朵诫、輕量單體應(yīng)用辛友，以及傳統(tǒng)的巨石應(yīng)用并存。

在架構(gòu)轉(zhuǎn)型過(guò)程中剪返，正確和常態(tài)的路徑一定是一步步走過(guò)來(lái)废累，而不是傳統(tǒng)架構(gòu)丟掉直接上微服務(wù)。

DevOps和容器@輕量單體

應(yīng)體應(yīng)用架構(gòu)下脱盲，DevOps邑滨、容器幫助企業(yè)實(shí)現(xiàn)敏捷IT。首先钱反，持續(xù)集成持續(xù)交付CI/CD掖看，只要應(yīng)用是相對(duì)輕量的，就能加快中間件應(yīng)用面哥。CI/CD其中重要的一點(diǎn)是變更發(fā)布管理哎壳。

數(shù)人云某客戶上了容器的應(yīng)用都是輕量化的，基于 Tomcat 和微服務(wù)的應(yīng)用尚卫。當(dāng)基于容器實(shí)現(xiàn)快速發(fā)布以后归榕，企業(yè)發(fā)現(xiàn)，所有發(fā)布里有一半的發(fā)布失敗是由于配置不正確引起的吱涉。所以刹泄，如果沒(méi)有發(fā)布變更管理，發(fā)布失敗的中間環(huán)節(jié)有方方面面的因素邑飒。

當(dāng)基于容器實(shí)現(xiàn)快速發(fā)布之后循签，容器對(duì)環(huán)境的異構(gòu)做了一層屏蔽级乐，這時(shí)如果出現(xiàn)處理的問(wèn)題就是配置管理的問(wèn)題了疙咸，由于涉及不同的環(huán)境和應(yīng)用，配置環(huán)境變成應(yīng)用發(fā)布很容易出錯(cuò)的環(huán)節(jié)风科。

DevOps和容器@微服務(wù)應(yīng)用架構(gòu)

數(shù)人云做了企業(yè)客戶微服務(wù)落地狀況的調(diào)研撒轮，在報(bào)告中，有15%左右的企業(yè)引入了Spring Cloud贼穆、Dubbo题山。微服務(wù)在企業(yè)里首當(dāng)其沖的是敏捷開發(fā)，因?yàn)槲⒎?wù)是一種切實(shí)的敏捷開發(fā)的方法故痊。

敏捷開發(fā)在IT界已經(jīng)推廣多年顶瞳，但很多時(shí)候敏捷開發(fā)推的都是方法論，比如Scrum。微服務(wù)是一套切實(shí)能夠落地到IT人員慨菱、開發(fā)人員開發(fā)過(guò)程中的實(shí)踐方法焰络，這是微服務(wù)首當(dāng)其沖的好處，很多企業(yè)的開發(fā)部門對(duì)微服務(wù)非常歡迎符喝。不過(guò)闪彼，15%還是偏小的一個(gè)采用比例，微服務(wù)還不是企業(yè)客戶主流的IT架構(gòu)协饲。

開發(fā)人員都比較歡迎微服務(wù)畏腕，因?yàn)槟軌蛱嵘_發(fā)效率，落地敏捷開發(fā)茉稠，但微服務(wù)的阻礙還是不小的描馅，微服務(wù)對(duì)開發(fā)運(yùn)維來(lái)說(shuō)，帶來(lái)的復(fù)雜度急劇上升而线。傳統(tǒng)運(yùn)維管理的服務(wù)器數(shù)量流昏、應(yīng)用數(shù)量有限。企業(yè)決定采用微服務(wù)本身就表明業(yè)務(wù)很復(fù)雜吞获，單體應(yīng)用做傳統(tǒng)的瀑布式開發(fā)效率太低况凉，微服務(wù)將應(yīng)用拆分成較小的模塊，因此微服務(wù)應(yīng)用一旦上線各拷，程序的數(shù)量呈現(xiàn)爆炸式增長(zhǎng)刁绒。

例如，數(shù)人云某個(gè)傳統(tǒng)企業(yè)的客戶烤黍，目前部署了微服務(wù)相關(guān)的應(yīng)用知市，基于Spring Cloud、Spring Boot速蕊，跑在幾千個(gè)容器上嫂丙，幾千個(gè)容器如果通過(guò)傳統(tǒng)運(yùn)維方式去管理的話幾乎是不可能的。這就是很多微服務(wù)無(wú)法落地的原因——很多企業(yè)客戶缺乏相應(yīng)的運(yùn)維能力规哲，沒(méi)有相應(yīng)的平臺(tái)跟啤、工具、方式唉锌、方法管理微服務(wù)應(yīng)用隅肥。

微服務(wù)落地的必要條件

微服務(wù)應(yīng)用落地，首當(dāng)其沖是配套工具鏈的完善袄简。開發(fā)人員采用微服務(wù)的影響相對(duì)改變小一些腥放。采用SpringCloud或者Dubbo、gRPC等绿语，只是開發(fā)框架上的并更秃症。其他開發(fā)流程如代碼托管候址、代碼審查、測(cè)試等并不涉及种柑，所以開發(fā)流程相對(duì)簡(jiǎn)單宗雇。但微服務(wù)對(duì)運(yùn)維功能的要求就會(huì)復(fù)雜，相應(yīng)的快速配置能力莹规、完備的監(jiān)控能力赔蒲、快速部署能力等對(duì)傳統(tǒng)運(yùn)維來(lái)說(shuō)都是缺失的，容器能夠補(bǔ)足這方面的能力良漱，讓運(yùn)維部門具有DevOps的能力舞虱。

關(guān)于微服務(wù)的拆分，其實(shí)是業(yè)務(wù)部門需要真正解決的問(wèn)題母市。微服務(wù)對(duì)組織上也有變更矾兜，將團(tuán)隊(duì)化整為零。通常每個(gè)單獨(dú)的微服務(wù)程序都由7-10人的小團(tuán)隊(duì)來(lái)負(fù)責(zé)維護(hù)患久，這些都是微服務(wù)落地的必要條件椅寺。

對(duì)于數(shù)人云來(lái)說(shuō)，直接能夠給客戶提供的幫助蒋失，首先是工具鏈方面返帕，數(shù)人云產(chǎn)品層面具備豐富的微服務(wù)配套工具鏈，從監(jiān)控篙挽、日志荆萤、調(diào)度、故障自動(dòng)化修復(fù)等等都有完備的工具鏈铣卡。在落地方法上链韭，數(shù)人云搭建了自己的生態(tài)圈，和很多合作伙伴合作煮落，例如跟埃森哲公司在合作敞峭，幫助企業(yè)客戶落地微服務(wù)，進(jìn)行業(yè)務(wù)的梳理蝉仇。

容器和微服務(wù)共生

容器技術(shù)補(bǔ)齊了微服務(wù)相關(guān)的工具鏈旋讹，對(duì)企業(yè)全面向云計(jì)算轉(zhuǎn)型提供了很大幫助。應(yīng)用架構(gòu)是微服務(wù)分布式的量淌，相應(yīng)的運(yùn)維也要有自動(dòng)化骗村、敏捷運(yùn)維的能力嫌褪。微服務(wù)跑在容器上才能發(fā)揮它最好的特性呀枢。容器是目前最流行的應(yīng)用環(huán)境，基于容器的微服務(wù)部署和更新更快笼痛，更輕量裙秋，服務(wù)之間的調(diào)用琅拌、服務(wù)發(fā)現(xiàn)、負(fù)載均衡等更靈活摘刑。

不過(guò)进宝，微服務(wù)不是萬(wàn)能的。簡(jiǎn)單的業(yè)務(wù)場(chǎng)景單體應(yīng)用其實(shí)足夠枷恕，微服務(wù)一定是應(yīng)用在復(fù)雜的業(yè)務(wù)場(chǎng)景下党晋，只有復(fù)雜的業(yè)務(wù)場(chǎng)景才有很大的維護(hù)成本、維護(hù)壓力徐块，微服務(wù)是用來(lái)降低復(fù)雜業(yè)務(wù)場(chǎng)景的維護(hù)成本未玻。

基于容器云的微服務(wù)運(yùn)行時(shí)管理體系

一個(gè)完整的微服務(wù)管理體系，除了開發(fā)框架之外胡控，對(duì)運(yùn)維部門來(lái)說(shuō)扳剿，運(yùn)維微服務(wù)應(yīng)用最基本的路由、負(fù)載均衡等功能昼激，容器可以提供庇绽，不過(guò)容器提供的只是一部分跟微服務(wù)相關(guān)的能力和工具鏈。周圍還有一大批需要配套的工具橙困，比如配置管理瞧掺、API網(wǎng)關(guān)、注冊(cè)發(fā)現(xiàn)凡傅、應(yīng)用監(jiān)控等等夸盟。這里的監(jiān)控不是容器CPU內(nèi)存的監(jiān)控，而是業(yè)務(wù)邏輯的監(jiān)控像捶，更準(zhǔn)確一點(diǎn)是全鏈路跟蹤的全鏈路監(jiān)控上陕。容器滿足了微服務(wù)運(yùn)行時(shí)管理的需求，不過(guò)周邊許多權(quán)限拓春、網(wǎng)關(guān)释簿、配置等尚無(wú)余力滿足。

統(tǒng)一配置中心是微服務(wù)體系的核心

統(tǒng)一配置管理硼莽，是微服務(wù)落地時(shí)很核心的點(diǎn)庶溶。要在平臺(tái)工具上落地微服務(wù)首先要具備快速配置能力，因?yàn)榭蛻舨捎梦⒎?wù)和容器平臺(tái)以后懂鸵，很快會(huì)發(fā)現(xiàn)50%以上的發(fā)布失敗是因?yàn)榕渲脹](méi)搞對(duì)偏螺，因此配置管理是微服務(wù)里首當(dāng)其沖的問(wèn)題。

因?yàn)槊總€(gè)企業(yè)客戶都有開發(fā)環(huán)境匆光、測(cè)試環(huán)境套像、生產(chǎn)環(huán)境等很多環(huán)境，同一個(gè)應(yīng)用不同版本在不同環(huán)境下的配置不同终息。幾何級(jí)數(shù)的配置項(xiàng)夺巩、配置元素的增長(zhǎng)會(huì)導(dǎo)致配置管理的復(fù)雜度急劇上升贞让，需要統(tǒng)一的配置中心進(jìn)行管理。數(shù)人云在幫助企業(yè)客戶落地微服務(wù)時(shí)柳譬，首先會(huì)做的是把配置搞定喳张，沒(méi)有靈活快速的配置管理能力，微服務(wù)運(yùn)行不起來(lái)美澳。

變更發(fā)布管理（灰度發(fā)布 v.s. 藍(lán)綠部署）

在發(fā)布管理方面销部，數(shù)人云幫助企業(yè)落地的發(fā)布管理主要是藍(lán)綠部署，因?yàn)楹芏嗥髽I(yè)的應(yīng)用本身不支持灰度發(fā)布制跟。藍(lán)綠部署也是切切實(shí)實(shí)的快速發(fā)布柴墩，發(fā)布用變更窗口的方式來(lái)實(shí)現(xiàn)。

例如凫岖，周五晚上12點(diǎn)起進(jìn)行發(fā)布變更江咳，12點(diǎn)就要停服務(wù)中心。藍(lán)綠部署可以顯著地縮短服務(wù)不可用的變更窗口哥放。怎么做呢歼指？客戶在線上有兩個(gè)版本，藍(lán)版本和綠版本∩瘢現(xiàn)在負(fù)載均衡器將流量指向?qū)ν馓峁┓?wù)的綠版本踩身，藍(lán)版本作為備用的方案。同時(shí)社露，新程序往藍(lán)版本上部署推送挟阻，更新時(shí)只需要把流量切換到藍(lán)版本。發(fā)布流程最后簡(jiǎn)化為只需要進(jìn)行流量的切換峭弟。流量可以快速切換附鸽，中間的窗口期只有短短幾分鐘，如果流量切換過(guò)來(lái)一切正常發(fā)布即完成瞒瘸，如果流量切換過(guò)來(lái)發(fā)現(xiàn)問(wèn)題坷备，可以再將流量切回去。這樣開發(fā)人員情臭、運(yùn)維人員不必當(dāng)場(chǎng)熬夜去修復(fù)省撑，極大地減輕了發(fā)布的壓力。

傳統(tǒng)發(fā)布方式下俯在，每次變更窗口有好幾個(gè)應(yīng)用排隊(duì)發(fā)布竟秫，一個(gè)應(yīng)用發(fā)布完成后才可以發(fā)布下一個(gè)應(yīng)用，一旦中間某一個(gè)應(yīng)用發(fā)布失敗現(xiàn)場(chǎng)修復(fù)的壓力非常大跷乐，短短的發(fā)布窗口需要幾個(gè)小時(shí)內(nèi)完成搶修肥败，非常不可控，團(tuán)隊(duì)經(jīng)常需要晚上熬夜排隊(duì)。而結(jié)果往往等了半天拙吉，前面的應(yīng)用沒(méi)發(fā)布成功潮孽，后面的還得繼續(xù)排隊(duì)等揪荣。

3金融行業(yè)之踐行漸進(jìn)

數(shù)人云在金融筷黔、能源、制造仗颈、快消佛舱、政企等行業(yè)的基礎(chǔ)上，繼續(xù)深耕強(qiáng)監(jiān)管挨决、強(qiáng)安全请祖，高復(fù)雜度的金融行業(yè)。以某商業(yè)銀行為例脖祈，數(shù)人云幫助落地了大規(guī)模微服務(wù)容器平臺(tái)肆捕。該商業(yè)銀行近年來(lái)互聯(lián)網(wǎng)業(yè)務(wù)發(fā)展迅猛，原有系統(tǒng)架構(gòu)無(wú)法支撐其未來(lái)規(guī)劃盖高。2016年6月開始全面實(shí)施應(yīng)用微服務(wù)化慎陵，已實(shí)現(xiàn)藍(lán)綠發(fā)布。

首先喻奥，營(yíng)銷系統(tǒng)全部是輕量化的應(yīng)用席纽，基于Spring Boot、Tomcat撞蚕、SpringCloud等润梯，跑在容器平臺(tái)上。該銀行對(duì)外營(yíng)銷頻次非常高甥厦，通過(guò)線上微信公眾號(hào)纺铭、手機(jī)APP、線上門戶刀疙、合作伙伴等渠道彤蔽，每月對(duì)外營(yíng)銷達(dá)上百場(chǎng)。

每次營(yíng)銷活動(dòng)或多或少都對(duì)IT系統(tǒng)有變更庙洼，哪怕是配置變更顿痪，因此每次營(yíng)銷活動(dòng)對(duì)IT系統(tǒng)都是一次不小的挑戰(zhàn)。發(fā)布的時(shí)候僅僅靠容器是不夠的油够，需要實(shí)現(xiàn)模板的批量發(fā)布蚁袭。每次發(fā)布看起來(lái)只是一個(gè)個(gè)的容器程序，實(shí)則不然石咬，其實(shí)是一組組一批批的容器揩悄，只有幫客戶做到批量的應(yīng)用發(fā)布，才能顯著提升發(fā)布效率鬼悠。

藍(lán)綠部署方面删性，該銀行密集的線上營(yíng)銷中亏娜，每一天會(huì)有一個(gè)重點(diǎn)營(yíng)銷活動(dòng)，那么營(yíng)銷活動(dòng)的流量如何分到特別的人群蹬挺、區(qū)域维贺？在后臺(tái)應(yīng)用的上千個(gè)實(shí)例中，并不是每一個(gè)實(shí)例都分配同等的流量巴帮，要通過(guò)流量分發(fā)溯泣，做線上流量控制。數(shù)人云借鑒Google做灰度發(fā)布的方式為客戶提供圖形化的流量控制榕茧，這和微服務(wù)實(shí)施后的限流分流是息息相關(guān)的垃沦。

另外，該銀行客戶的數(shù)據(jù)流量非常大用押，對(duì)日志收集帶來(lái)非常大的的壓力肢簿。數(shù)人云建議客戶將應(yīng)用程序的日志全部交給Kafka采集，Kafka可以做到很大數(shù)據(jù)流量的分布式消息應(yīng)用蜻拨。

分布式數(shù)據(jù)傳輸分布式消息應(yīng)用很難保證每一個(gè)消息都可靠地傳遞池充。Kafka有兩種模式：一種保證消息傳遞至少一次，但也可能多次官觅，對(duì)很大的日志量來(lái)說(shuō)偶爾丟一兩條可以忽略不計(jì)纵菌。Kafka的并發(fā)量很大，可能帶來(lái)偶爾很小的數(shù)據(jù)量丟失休涤，也可能帶來(lái)日志的亂序咱圆，這在分布式系統(tǒng)下都是可以容忍的，“魚和熊掌不可兼得”功氨。

關(guān)于快速建立支撐微服務(wù)體系序苏，數(shù)人云有幾點(diǎn)總結(jié)：

1.開發(fā)框架不能用重量級(jí)的應(yīng)用體系，要么是輕量化單體架構(gòu)的Tomcat等捷凄，要么采用Spring Cloud等微服務(wù)架構(gòu)忱详。2.要有微服務(wù)平臺(tái)，具備快速配置管理能力跺涤、部署能力匈睁、監(jiān)控能力、應(yīng)用管理能力等配套管理能力桶错。很多企業(yè)的痛點(diǎn)是航唆，開發(fā)人員快速學(xué)習(xí)微服務(wù)開發(fā)技術(shù)，基于Spring Cloud做業(yè)務(wù)系統(tǒng)后院刁，業(yè)務(wù)系統(tǒng)無(wú)法上線糯钙，因?yàn)檫\(yùn)維部門缺乏配套的工具、平臺(tái)支撐微服務(wù)線上運(yùn)行管理。3.DevOps融合任岸，平臺(tái)管理需要把鏈條全打通再榄，實(shí)現(xiàn)快速發(fā)布、快速上線享潜、自動(dòng)修復(fù)等困鸥。容器經(jīng)過(guò)幾年的普及企業(yè)已經(jīng)相對(duì)了解，但容器本身是純技術(shù)平臺(tái)米碰，基于容器窝革、DevOps的落地還有很長(zhǎng)的路要走购城。

數(shù)人云微服務(wù)On PaaS 產(chǎn)品體系

數(shù)人云現(xiàn)在的重點(diǎn)是微服務(wù)吕座、輕量單體應(yīng)用。以前數(shù)人云幫企業(yè)客戶落地重應(yīng)用的容器平臺(tái)瘪板，但后來(lái)發(fā)現(xiàn)價(jià)值不大吴趴，反而對(duì)企業(yè)來(lái)說(shuō)，除了維護(hù)重的應(yīng)用外還需要維護(hù)容器侮攀，容器平臺(tái)并不能實(shí)現(xiàn)自動(dòng)化運(yùn)維锣枝。經(jīng)過(guò)幾年的實(shí)踐和摸索，數(shù)人云跟企業(yè)客戶達(dá)成的共識(shí)是兰英，傳統(tǒng)應(yīng)用不經(jīng)過(guò)改造無(wú)法上到云PaaS平臺(tái)撇叁。

輕量架構(gòu)下的應(yīng)用如何基于PaaS平臺(tái)支撐？以敏捷開發(fā)為例畦贸，企業(yè)客戶通常選擇 Spring Cloud陨闹、gRPC 等主流的開發(fā)框架，然后在微服務(wù)工具鏈層面配置監(jiān)控薄坏、報(bào)警趋厉、部署、快速發(fā)布等方方面面的能力胶坠，最下面承載的則是容器平臺(tái)君账。

數(shù)人云現(xiàn)在還可以幫助客戶落地服務(wù)網(wǎng)格化技術(shù)。它能夠進(jìn)行異構(gòu)架構(gòu)的兼容沈善，gRPC就是服務(wù)網(wǎng)格的一部分乡数，Google推的 Istio，Linkerd的Kubernetes 都支持 gRPC闻牡，gRPC成為通訊協(xié)議的一部分净赴。基于通訊協(xié)議相應(yīng)周邊的管理澈侠，在服務(wù)網(wǎng)格這一層可以做灰度發(fā)布劫侧、A/B測(cè)試、流量控制、高級(jí)熔斷烧栋、加密写妥、白/黑名單機(jī)制、權(quán)限訪問(wèn)控制等等审姓。

服務(wù)網(wǎng)格被稱作下一代的微服務(wù)珍特，因?yàn)橛昧朔?wù)網(wǎng)格以后，所有微服務(wù)管理的訴求都自動(dòng)化地滿足了魔吐。80%-90%的應(yīng)用管理需求都在服務(wù)網(wǎng)格里自動(dòng)涵蓋扎筒。這對(duì)開發(fā)人員來(lái)講，微服務(wù)開發(fā)的門檻急劇降低酬姆，不需要考慮未來(lái)應(yīng)用上線時(shí)流量控制嗜桌、灰度發(fā)布等等，只需要考慮業(yè)務(wù)辞色。數(shù)人云微服務(wù)On PaaS 目的就是幫助企業(yè)客戶降低微服務(wù)架構(gòu)骨宠、上云轉(zhuǎn)型的門檻。

Q&A

Q1：感覺(jué)對(duì)DevOps的理解不太到位相满，能不能具體地講一下层亿？

A1：DevOps準(zhǔn)確來(lái)講，現(xiàn)在業(yè)內(nèi)還沒(méi)有統(tǒng)一的認(rèn)識(shí)立美∧溆郑互聯(lián)網(wǎng)公司的DevOps目前是比較統(tǒng)一的，比如Goolge建蹄，但是互聯(lián)網(wǎng)公司的DevOps碌更，我個(gè)人理解沒(méi)辦法在企業(yè)直接落地。

在Google躲撰，程序員不止要負(fù)責(zé)應(yīng)用的開發(fā)针贬，還要負(fù)責(zé)相應(yīng)的測(cè)試，單元測(cè)試拢蛋、集成測(cè)試等等桦他。另外，應(yīng)用的部署谆棱、發(fā)布快压、上線也是開發(fā)人員自己做。所以互聯(lián)網(wǎng)公司講DevOps垃瞧，更多講的是開發(fā)運(yùn)維的融合蔫劣。我之前在Google時(shí)，不僅要做代碼開發(fā)个从，也要把測(cè)試的代碼全寫出來(lái)脉幢。

Google有一個(gè)理念歪沃，開發(fā)人員每寫一行業(yè)務(wù)代碼，測(cè)試代碼要寫十行嫌松。然后沪曙，開發(fā)人員利用各種發(fā)布平臺(tái)定期發(fā)布，比如每周做發(fā)布萎羔，在Google 運(yùn)維的人員叫“SRE”液走。SRE部門準(zhǔn)備好各種平臺(tái)，開發(fā)人員可以用這些平臺(tái)做發(fā)布贾陷、監(jiān)控缘眶、日志管理等工作。

Google目前有三萬(wàn)名左右的IT人員髓废，其中SRE的運(yùn)維人員只有一千多巷懈，比例很低。所以在Google運(yùn)維人員不可能幫每一個(gè)開發(fā)人員或者業(yè)務(wù)部門做上線瓦哎。像傳統(tǒng)IT開發(fā)人員提工單給運(yùn)維砸喻，在Google是不可能的柔逼。Google這種做法蒋譬，它讓開發(fā)做更多的事情，運(yùn)維人員很少愉适，只是負(fù)責(zé)維護(hù)平臺(tái)犯助。所以，Google一千多人管理著幾百萬(wàn)臺(tái)服務(wù)器维咸，平均每人管兩千臺(tái)剂买。

但傳統(tǒng)企業(yè)目前不是這樣，傳統(tǒng)企業(yè)開發(fā)和運(yùn)維之間壁壘比較大癌蓖。數(shù)人云幫助客戶落地DevOps 時(shí)瞬哼，基于的理念是，不要破壞現(xiàn)有開發(fā)的流程租副。DevOps應(yīng)該是開發(fā)和運(yùn)維深度融合才能做到的坐慰。講DevOps，首先要講理念用僧、組織的變革结胀，但是要想把文化變革、組織變革打破要很長(zhǎng)時(shí)間责循。

從落地的角度糟港，DevOps更多落地在運(yùn)維部門，很具象的工作就是院仿，幫助運(yùn)維部門去實(shí)現(xiàn)DevOps的能力秸抚，比如快速部署速和、快速上線，應(yīng)用的快速配置剥汤，自動(dòng)化管理能力健芭、故障的自動(dòng)化處理等等。把以前的運(yùn)維工作盡可能的自動(dòng)化秀姐，提高效率慈迈，這是狹義的DevOps理念，也是我們現(xiàn)在接觸到的省有。數(shù)人云不會(huì)幫客戶落地像互聯(lián)網(wǎng)公司那樣的DevOps痒留，開發(fā)做很多事情，運(yùn)維可做的很少蠢沿，并不是這樣的伸头。

Q2：微服務(wù)適合復(fù)雜的場(chǎng)景，那么一個(gè)簡(jiǎn)單的促銷是不是適合舷蟀？微服務(wù)有多“微”呢恤磷？微服務(wù)和ESB 服務(wù)相比，有什么差別野宜？

A2：第一個(gè)促銷場(chǎng)景扫步，促銷場(chǎng)景本身有些條件，促銷很重要一點(diǎn)就是必須特別頻繁匈子，促銷內(nèi)容在平臺(tái)要發(fā)生變化河胎。比如，今天的促銷內(nèi)容和明天的不太一樣虎敦，或者這周的促銷和下周的不太一樣游岳，業(yè)務(wù)平臺(tái)需要頻繁變更，這時(shí)候微服務(wù)是適合的其徙。

因?yàn)槲⒎?wù)是一種敏捷開發(fā)的落地實(shí)踐方法胚迫，只要業(yè)務(wù)頻繁變更，對(duì)開發(fā)的要求就必須敏捷開發(fā)唾那，快速實(shí)現(xiàn)访锻。所以，只要業(yè)務(wù)場(chǎng)景在不停地快速變化通贞，促銷又是互聯(lián)網(wǎng)線上的方式朗若，肯定是適合的。

關(guān)于復(fù)雜性昌罩，如果業(yè)務(wù)邏輯簡(jiǎn)單哭懈，邏輯變化少，并不適合微服務(wù)茎用。比如數(shù)人云和很多銀行客戶合作遣总，銀行核心系統(tǒng)很復(fù)雜睬罗，但是銀行系統(tǒng)并不是需求頻繁變化的場(chǎng)景。很多銀行在做“瘦核心系統(tǒng)”旭斥，就是銀行核心系統(tǒng)的功能越來(lái)越單一容达，越來(lái)越瘦，并不是把復(fù)雜的周邊的業(yè)務(wù)也放到銀行核心系統(tǒng)里垂券。銀行核心系統(tǒng)雖然復(fù)雜花盐，但業(yè)務(wù)不會(huì)頻繁變化，也不一定要上到微服務(wù)場(chǎng)景下菇爪。復(fù)雜的業(yè)務(wù)系統(tǒng)算芯，業(yè)務(wù)需求又不停變化，這種場(chǎng)景適合微服務(wù)凳宙。

第二個(gè)問(wèn)題是和ESB 比熙揍，服務(wù)網(wǎng)格和 ESB 有很多相像的地方。ESB有業(yè)務(wù)邏輯串起來(lái)氏涩，很多不同的業(yè)務(wù)系統(tǒng)都上到ESB届囚，互相的權(quán)限通過(guò)ESB打通。從功能角度講是尖，ESB和服務(wù)網(wǎng)格之間很相像意系，不同點(diǎn)在于ESB是傳統(tǒng)架構(gòu)下的，并沒(méi)有考慮頻繁迭代析砸、流量集中爆發(fā)等問(wèn)題昔字。

但是微服務(wù)情況下，整個(gè)之間的互相請(qǐng)求首繁、依賴、通訊等等都會(huì)進(jìn)行統(tǒng)一的管理陨囊，這種情況下也很像ESB把不同業(yè)務(wù)之間的流量進(jìn)行統(tǒng)一管理弦疮，但是服務(wù)網(wǎng)格更看重的是面向大規(guī)模的控制，那流量突發(fā)怎么做限流蜘醋，或者突然故障怎么做熔斷等等胁塞。最本質(zhì)的問(wèn)題是類似的，但是具體的問(wèn)題表象和需求不同压语。

Q3：在實(shí)際部署過(guò)程中啸罢，PaaS平臺(tái)在底層資源的調(diào)用一定要用分布式云架構(gòu)，傳統(tǒng)主機(jī)是否可以胎食？?jī)烧咴谧詈笮Ч嫌袥](méi)有什么異同扰才？

A3：數(shù)人云當(dāng)初兩種情況都有，有些場(chǎng)景比如業(yè)務(wù)量比較大厕怜，企業(yè)客戶為了減少?gòu)?fù)雜度衩匣，容器PaaS平臺(tái)直接落地到物理服務(wù)器上。還有客戶為了方便管理，把PaaS落地到IaaS上付魔，兩種情況都有孙蒙。

這其中的考慮是，首先業(yè)務(wù)量大如果再引入虛擬化這一層會(huì)引來(lái)額外的復(fù)雜度柄延，此時(shí)用物理服務(wù)器更好蚀浆。其次，客戶有很大規(guī)模的物理服務(wù)器搜吧，直接在上面部署PaaS蜡坊，在物理服務(wù)器上去調(diào)用。

第三種赎败，資源動(dòng)態(tài)的調(diào)整或資源頻繁調(diào)配秕衙，這個(gè)場(chǎng)景很常見，需要IaaS僵刮。比如銀行客戶据忘，內(nèi)部業(yè)務(wù)系統(tǒng)分不同的域，不同域的業(yè)務(wù)復(fù)雜性隨時(shí)間變化經(jīng)常會(huì)發(fā)生變化搞糕，需要不停地做資源動(dòng)態(tài)的調(diào)整勇吊。如果用物理機(jī)太麻煩，企業(yè)客戶會(huì)選擇下面有一層IaaS來(lái)做窍仰。

基于PaaS也能做一部分的資源動(dòng)態(tài)調(diào)配汉规，但是調(diào)配維度不同。數(shù)人云幫客戶落地PaaS時(shí)會(huì)做資源的整合驹吮。從劃分的維度针史，PaaS平臺(tái)是按照應(yīng)用程序來(lái)劃分，IaaS的資源劃分是按照業(yè)務(wù)系統(tǒng)碟狞。

Q4：微服務(wù)重新開發(fā)啄枕，最佳的開發(fā)框架或者實(shí)踐有什么可以分享的？第二族沃，舊有的系統(tǒng)改造到微服務(wù)這塊有沒(méi)有什么經(jīng)驗(yàn)频祝？第三，DevOps以前也有很多像敏捷開發(fā)的方法論脆淹，它們之間有沒(méi)有什么關(guān)系常空？

A4：首先第一個(gè)問(wèn)題，微服務(wù)的開發(fā)框架盖溺。企業(yè)客戶在做選擇時(shí)都希望降低風(fēng)險(xiǎn)漓糙，選最主流的框架，現(xiàn)在看最主流的開發(fā)框架就是Spring cloud咐柜，這也是業(yè)界的自然選擇結(jié)果兼蜈。其他語(yǔ)言也都有些微服務(wù)開發(fā)攘残，但是用的人少一些。如果是Java應(yīng)用为狸，目前比較好的選擇是Spring Cloud歼郭，也有很多客戶用了Dubbo，其他架構(gòu)都是偏小眾的架構(gòu)辐棒，主要還是看客戶自己的需求病曾。

第二個(gè)問(wèn)題，傳統(tǒng)業(yè)務(wù)要轉(zhuǎn)到微服務(wù)架構(gòu)上漾根，一定要循序漸進(jìn)泰涂。比如Java應(yīng)用，首先Java中間件的應(yīng)用辐怕，先脫掉逼蒙，不要再基于這么重的Java中間件。目前相對(duì)流行的是Spring Boot這套邏輯寄疏。

有了輕量的單體化應(yīng)用之后（基于Tomcat）是牢，往后走基于微服務(wù)的框架，上到Spring Boot陕截，再上到Spring Cloud驳棱，這是比較平滑的方式。Spring Boot 在很企業(yè)客戶中用的非常多农曲，是很方便的一套單體開發(fā)架構(gòu)社搅。

企業(yè)客戶目前的現(xiàn)狀是老的應(yīng)用很多，不會(huì)一次就改造完乳规，傳統(tǒng)的應(yīng)用可以先選擇一部分容易轉(zhuǎn)的轉(zhuǎn)到輕量單體架構(gòu)上形葬，然后再轉(zhuǎn)到微服務(wù)框架上。目前企業(yè)客戶是輕量的單體架構(gòu)驯妄、微服務(wù)架構(gòu)荷并，以及大量傳統(tǒng)的架構(gòu)應(yīng)用并存。老的架構(gòu)應(yīng)用目前上不到PaaS平臺(tái)青扔，只有輕量的單體化加微服務(wù)應(yīng)用才能上到PaaS平臺(tái)。

現(xiàn)在業(yè)內(nèi)的共識(shí)是翩伪，微服務(wù)微猖、容器、DevOps這三者是密不可分的缘屹。微服務(wù)更多是針對(duì)開發(fā)人員凛剥，是一種真正落地的云開發(fā)方法。很多企業(yè)客戶也講敏捷開發(fā)轻姿，派團(tuán)隊(duì)成員學(xué)習(xí)敏捷開發(fā)的方法論犁珠，但是敏捷開發(fā)仍然無(wú)法在企業(yè)當(dāng)中落地逻炊。

這是因?yàn)椋粚W(xué)會(huì)了方法犁享，但沒(méi)辦法落地到具體的編程余素，即開發(fā)環(huán)節(jié)上去，自然沒(méi)辦法做到敏捷開發(fā)炊昆。很多開發(fā)者回來(lái)寫的程序依然是J2EE桨吊。J2EE 編程的理念和方法并不是敏捷開發(fā)的，是偏向于瀑布式的凤巨。

微服務(wù)是具體的開發(fā)環(huán)節(jié)上的敏捷開發(fā)方法视乐，開發(fā)能力化整為零，每個(gè)團(tuán)隊(duì)做簡(jiǎn)單敢茁、具象佑淀、單一的邏輯。微服務(wù)首先是一個(gè)具像的敏捷開發(fā)方法彰檬，實(shí)踐方法伸刃。

微服務(wù)在落地時(shí)，比如程序運(yùn)行時(shí)僧叉，復(fù)雜度很高奕枝，因?yàn)椴皇且粋€(gè)程序，是一批程序一起運(yùn)行瓶堕，對(duì)運(yùn)維的管理就比較復(fù)雜隘道，這時(shí)候可以利用容器實(shí)現(xiàn)微服務(wù)應(yīng)用的自動(dòng)化管理。微服務(wù)一般都會(huì)上到容器郎笆，因?yàn)槲⒎?wù)應(yīng)用不再是單體的部署方式谭梗，不再是部署到Java中間件上⊥痱荆基于微服務(wù)架構(gòu)激捏，幾百個(gè)進(jìn)程進(jìn)來(lái)，用容器的方式實(shí)現(xiàn)快速部署動(dòng)態(tài)調(diào)度凄吏，微服務(wù)部署到容器上远舅，實(shí)現(xiàn)基礎(chǔ)的輕量化運(yùn)維。

輕量化運(yùn)維痕钢，快速部署图柏、自動(dòng)化調(diào)度，逐步往DevOps方向走任连。DevOps更多強(qiáng)調(diào)自動(dòng)化的運(yùn)維能力蚤吹，提高運(yùn)維的效率，快速部署，出了問(wèn)題自動(dòng)化修復(fù)裁着。需要用到工具和平臺(tái)繁涂，這就是數(shù)人云現(xiàn)在幫客戶去做的。

把微服務(wù)業(yè)務(wù)在運(yùn)行時(shí)缺失的管理方式方法二驰、工具平臺(tái)扔罪，工具鏈補(bǔ)齊。首先是配置管理能力诸蚕、完備的監(jiān)控能力等等步势，普及之后運(yùn)維人員就有能力來(lái)管微服務(wù)應(yīng)用。這其實(shí)是DevOps里面最狹義的背犯，讓運(yùn)維的能力變得輕量坏瘩。

如果要真正實(shí)現(xiàn)DevOps，就像目前一些互聯(lián)網(wǎng)公司做到的漠魏，開發(fā)和運(yùn)維真正的深度融合在一起倔矾。企業(yè)目前的運(yùn)維一般不具有編程能力，所以真正的DevOps還需要很長(zhǎng)時(shí)間去落地柱锹。