【51CTO.com原創(chuàng)稿件】2018年5月18-19日，由51CTO主辦的全球軟件與運(yùn)維技術(shù)峰會(huì)在北京召開。來自全球企業(yè)的技術(shù)精英匯聚北京，暢談軟件技術(shù)前沿，共同探索運(yùn)維技術(shù)的新邊界。而在本次大會(huì)上，除了眾星云集的主論壇環(huán)節(jié)，12場分論壇更是各具特色，分別聚焦了時(shí)下最受關(guān)注的容器、AI、區(qū)塊鏈、大數(shù)據(jù)、物聯(lián)網(wǎng)等技術(shù)領(lǐng)域。

　　在19日下午的“微服務(wù)架構(gòu)設(shè)計(jì)”分論壇現(xiàn)場，阿里巴巴技術(shù)專家徐冬晨擔(dān)任本場論壇的出品人，她與58到家CTO沈劍、餓了么計(jì)算力交付部負(fù)責(zé)人李健、百度云資深研發(fā)工程師何方石分別給場內(nèi)聽眾帶來了四場精彩演講，分享了微服務(wù)架構(gòu)在落地過程的一些可行方案及實(shí)踐思路。

　　58到家沈劍：58速運(yùn)微服務(wù)架構(gòu)解耦***實(shí)踐

　　沈劍首先分享了58速運(yùn)在業(yè)務(wù)開展過程中遇到的運(yùn)維問題。據(jù)他透露，隨著58同城業(yè)務(wù)持續(xù)的發(fā)展，數(shù)據(jù)量也隨之慢慢提升。他們很快就遭遇了一個(gè)很有代表性的挑戰(zhàn)——代碼拷貝導(dǎo)致業(yè)務(wù)痛點(diǎn)。由于業(yè)務(wù)是逐漸增長的，在這個(gè)過程中，不同技術(shù)團(tuán)隊(duì)會(huì)有重復(fù)功能的需求，為了快速上線，不同技術(shù)團(tuán)隊(duì)之間拷貝相同代碼，并在此基礎(chǔ)上借鑒修改。這樣帶來的弊端就是，一旦原來的那套代碼出現(xiàn)問題，其他所有拷貝的地方，全部都需要修改，因?yàn)檫@些拷貝的代碼產(chǎn)生了跨系統(tǒng)、跨業(yè)務(wù)的耦合。

　　不僅如此，被迫聯(lián)動(dòng)升級(jí)也曾困擾過他們。由于數(shù)據(jù)量增多，訪問量也隨之增加，系統(tǒng)中的各個(gè)子系統(tǒng)時(shí)不時(shí)會(huì)出現(xiàn)問題，例如吞吐量過大、新增業(yè)務(wù)場景帶來數(shù)據(jù)庫讀寫壓力、數(shù)據(jù)讀取流程改變等等。漸漸地，底層復(fù)雜性不斷擴(kuò)散到上游業(yè)務(wù)層，導(dǎo)致業(yè)務(wù)層也需要配合修改。

　　***沈劍和技術(shù)團(tuán)隊(duì)決定用微服務(wù)來化解這些困境。微服務(wù)化之后，所有業(yè)務(wù)側(cè)都通過RPC像調(diào)取本地函數(shù)一樣去調(diào)取遠(yuǎn)端的數(shù)據(jù)，至于這個(gè)數(shù)據(jù)是存在哪個(gè)數(shù)據(jù)庫里，還是緩存里，都不需要關(guān)注，他們只需要關(guān)注服務(wù)層，當(dāng)?shù)讓佑猩?jí)的時(shí)候，所有業(yè)務(wù)線都不需要變動(dòng)，只有服務(wù)需要升級(jí)。通過服務(wù)化，他們徹底解決了底層復(fù)雜性的耦合問題。

　　沈劍還給微服務(wù)架構(gòu)設(shè)定了兩條原則，***條原則是數(shù)據(jù)庫私有，任何上游不得繞過服務(wù)層去訪問底層數(shù)據(jù)庫，業(yè)務(wù)部門只能調(diào)用接口，通過接口去訪問。第二條原則是對(duì)上游提供有限且通用的接口，并且服務(wù)層要保證***的性能，確保可以解決業(yè)務(wù)部門關(guān)于吞吐量、訪問量的問題。不過如此一來，服務(wù)層就會(huì)變得非常重要，沈劍建議將公司最基礎(chǔ)的微服務(wù)化放在架構(gòu)部，或者專門成立一個(gè)部門，由比較資深的技術(shù)人員負(fù)責(zé)維護(hù)。

　　改造之后，他們很快就享受到微服務(wù)帶來的好處，例如加強(qiáng)復(fù)用性，消除代碼拷貝耦合，屏蔽復(fù)雜性，消除復(fù)雜性耦合，而且還保證了SQL質(zhì)量，可以給業(yè)務(wù)部門提供有限服務(wù)，***性能。同時(shí)確保系統(tǒng)擴(kuò)展性，消除數(shù)據(jù)庫實(shí)例耦合。更重要的，調(diào)用數(shù)據(jù)更方便了。

　　但是微服務(wù)是一把雙刃劍，有優(yōu)勢(shì)也同樣有弊端。沈劍分享道，微服務(wù)也導(dǎo)致了系統(tǒng)復(fù)雜性上升，讓層次間依賴關(guān)系變得復(fù)雜。與此同時(shí)，運(yùn)維和部署更麻煩，雖然目前58速運(yùn)計(jì)劃在未來開發(fā)自動(dòng)化的運(yùn)維腳本和運(yùn)維平臺(tái)，但如果是小型的研發(fā)團(tuán)隊(duì)，微服務(wù)帶來的運(yùn)維壓力可能會(huì)非常大。系統(tǒng)監(jiān)控和問題定位也遇到同樣的問題，變得非常復(fù)雜。“微服務(wù)，不是簡單引入一個(gè)RPC框架，它需要一系列基礎(chǔ)設(shè)施的支撐。” 沈劍總結(jié)道。

　　阿里巴巴徐冬晨：JVM- sandbox_穩(wěn)定性體系的構(gòu)建

　　徐冬晨認(rèn)為，隨著軟件部署規(guī)模的擴(kuò)大，系統(tǒng)功能的細(xì)化，系統(tǒng)間耦合度和鏈路復(fù)雜度不斷加強(qiáng)。要繼續(xù)保持現(xiàn)有規(guī)模系統(tǒng)的穩(wěn)定性，需要實(shí)現(xiàn)并完善監(jiān)控體系、故障定位分析、流量錄制回放、強(qiáng)弱依賴檢測、故障演練等支撐工具平臺(tái)。出于對(duì)服務(wù)器規(guī)模和業(yè)務(wù)穩(wěn)定性的考量，這些配套工具平臺(tái)需要具備三個(gè)特點(diǎn)，即無侵入、實(shí)時(shí)生效、動(dòng)態(tài)可插拔。

　　要實(shí)現(xiàn)這些，多少都會(huì)觸及到底層技術(shù)——動(dòng)態(tài)字節(jié)碼增強(qiáng)。如果每個(gè)工具都自己實(shí)現(xiàn)一套字節(jié)碼增強(qiáng)邏輯，前期實(shí)現(xiàn)的門檻與后期維護(hù)成本高，且不同工具間相互影響造成不可預(yù)知的風(fēng)險(xiǎn)。如何降低門檻屏蔽風(fēng)險(xiǎn)[鳶瑋1] ，降低研發(fā)運(yùn)維成本，同時(shí)又能支持上層多個(gè)工具平臺(tái)功能的快速實(shí)現(xiàn)和動(dòng)態(tài)管理，成為阿里集團(tuán)的目標(biāo)。在這樣的背景下，JVM-Sandbox 誕生了，這是一套實(shí)時(shí)無侵入的字節(jié)碼增強(qiáng)框架，它可以提供動(dòng)態(tài)增強(qiáng)類指定的類，獲取人們想要方法的參數(shù)、返回值和行信息;提供動(dòng)態(tài)可插拔容器。

　　JVM—Sandbox能處理哪些問題呢?徐冬晨表示，它可以提供線上故障定位、線上系統(tǒng)流量控制、線上故障模擬、性能壓測、錄制回放、鏈路跟蹤六大服務(wù)。徐冬晨列舉了阿里集團(tuán)內(nèi)部的三個(gè)應(yīng)用場景，一是線上故障演練，他們僅用1周時(shí)間就完成了故障注入部分的重構(gòu)，在掛載效率和成功率方面有了明顯的提升，縮短了演練的時(shí)間;二是依賴檢測，利用JVM-Sandbox的模塊容器的特性，阿里技術(shù)團(tuán)隊(duì)將前人開發(fā)的模塊與新增模塊一起掛載共同工作，完成依賴檢測、故障注入等操作;三是錄制隔離回放機(jī)制，即利用JVM-Sandbox的開發(fā)錄制模塊，和回放模塊，實(shí)現(xiàn)線上錄制線下回放，提高回歸效率，拓展測試范圍。

　　據(jù)徐冬晨介紹，JVM-Sandbox基于JVMTI技術(shù)規(guī)范，為觀察和改變代碼運(yùn)行結(jié)果提供了即插即用模塊接口的容器。而且還為AOP提供了一個(gè)新的實(shí)現(xiàn)方案——以插樁代替代理。“在工作中需要使用字節(jié)碼增強(qiáng)技術(shù)，進(jìn)行工具開發(fā)、實(shí)現(xiàn)業(yè)務(wù)功能的開發(fā)、測試的同學(xué)會(huì)非常需要它。”

　　餓了么李健：基于容器的混合云實(shí)踐

　　李健介紹到，管理系統(tǒng)常見的一個(gè)場景就是混合云的管理，在餓了么業(yè)務(wù)快速增長過程中，資源規(guī)模增長也非常迅速，這也導(dǎo)致了服務(wù)器類型繁多，交付需求多樣。為了滿足業(yè)務(wù)的需求，讓應(yīng)用交付更為靈活穩(wěn)定，餓了么想到了一個(gè)新思路，把物理資源抽象，對(duì)計(jì)算力進(jìn)行標(biāo)準(zhǔn)化設(shè)置，統(tǒng)一對(duì)開發(fā)人員輸出。如此一來，可以極大減少交付成本，而且標(biāo)準(zhǔn)化之后可以管理更多IT基礎(chǔ)設(shè)備。

　　在經(jīng)過仔細(xì)技術(shù)對(duì)比之后，餓了么選擇了構(gòu)建eleme[鳶瑋2] 容器平臺(tái)來實(shí)現(xiàn)應(yīng)用交付。具體說來，eleme容器平臺(tái)會(huì)交付三部分內(nèi)容，一是客戶應(yīng)用部署，這個(gè)最常見，業(yè)務(wù)把應(yīng)用交給開發(fā)部門，開發(fā)部門負(fù)責(zé)讓應(yīng)用實(shí)現(xiàn)，提供應(yīng)用服務(wù);二是標(biāo)準(zhǔn)服務(wù)一鍵交付，由于業(yè)務(wù)部門有很多團(tuán)隊(duì)，每個(gè)團(tuán)隊(duì)可能需要一套獨(dú)有的環(huán)境來實(shí)現(xiàn)服務(wù)，但每個(gè)服務(wù)之間又需要建立聯(lián)系，并且具有可復(fù)制性，這就要求技術(shù)團(tuán)隊(duì)必須提供標(biāo)準(zhǔn)服務(wù)，避免搭建復(fù)雜的運(yùn)維環(huán)境。三是服務(wù)器的交付，即對(duì)外輸出計(jì)算力。

　　構(gòu)建容器平臺(tái)離不開技術(shù)選型，李健認(rèn)為，目前無論從生態(tài)還是活躍度來看Kubernetes(Google開源的容器集群管理系統(tǒng))都已成為容器編排事實(shí)上的標(biāo)準(zhǔn)。“雖然企業(yè)在容器化時(shí)遇到的問題不可能完全一樣，技術(shù)選型時(shí)可以根據(jù)實(shí)際情況選擇，但脫離了標(biāo)準(zhǔn)往往意味著成本的大幅上升。”除了標(biāo)準(zhǔn)之外，李健建議技術(shù)選型還需要去重點(diǎn)考慮與自身業(yè)務(wù)的契合度、擴(kuò)展性、生態(tài)發(fā)展、前瞻性。

　　那么Kubernetes落地戶還會(huì)遇到哪些阻礙呢?李健透露，首先是容易遇到Pod(一個(gè)Kubernetes抽象，表示一組一個(gè)或多個(gè)應(yīng)用程序容器以及這些容器的一些共享資源)重啟方式的問題，因?yàn)镻od重啟意味著新建一個(gè)Pod，之前版本就不再使用了，很多企業(yè)環(huán)境是無法接受這個(gè)設(shè)定的。

　　另外一個(gè)問題是Kubernetes無法限制容器系統(tǒng)大小，一旦有企業(yè)混合業(yè)務(wù)時(shí)，容量高達(dá)100G以上，系統(tǒng)會(huì)立刻報(bào)警提示磁盤已滿。這就需要企業(yè)另行開發(fā)修改。

　　***一個(gè)問題是DNS(域名系統(tǒng))改造。很多企業(yè)都有自己的域名區(qū)域，并且希望能夠集成到 Kubernetes DNS 的命名空間去，例如混合云用戶可能希望能在集群內(nèi)解析他們內(nèi)部的 “.corp”，這就需要企業(yè)進(jìn)行DNS改造。

　　百度云何方石：揭秘百度云函數(shù)計(jì)算實(shí)現(xiàn)細(xì)節(jié)

　　何方石在現(xiàn)場向大家揭秘了他和技術(shù)團(tuán)隊(duì)在百度云如何實(shí)現(xiàn)函數(shù)計(jì)算這個(gè)產(chǎn)品。函數(shù)計(jì)算實(shí)際上是一種無服務(wù)器的計(jì)算交付的產(chǎn)品，不需要引入任何框架，用戶只需要在百度云的控制平臺(tái)上或者通過API去編寫自己的函數(shù)。函數(shù)編寫完之后，百度云可以通過云端試點(diǎn)的觸發(fā)器，或者API的調(diào)用來執(zhí)行用戶這段函數(shù)的業(yè)務(wù)邏輯。

　　那么人們可以利用函數(shù)計(jì)算實(shí)現(xiàn)哪些功能呢?一是無服務(wù)器后端，搭配HTTP觸發(fā)器或API Gateway產(chǎn)品可以快速實(shí)現(xiàn)后端API，并無需考慮配置服務(wù)器與運(yùn)維;二是實(shí)時(shí)數(shù)據(jù)流處理，從消息隊(duì)列批量消費(fèi)流數(shù)據(jù)，聚合、整理數(shù)據(jù)并生成指標(biāo)，可以自動(dòng)根據(jù)負(fù)載消費(fèi)數(shù)據(jù);三是IoT后端，與IoT Hub聯(lián)動(dòng)實(shí)現(xiàn)對(duì)IoT設(shè)備的管理能力，服務(wù)可自動(dòng)調(diào)整規(guī)模，應(yīng)對(duì)IoT設(shè)備增長;四是Cloud Native Connector(云原生)，基于event-driven(事件驅(qū)動(dòng)架構(gòu))的云原生時(shí)代，云服務(wù)通過事件+函數(shù)計(jì)算互相打通，形成生態(tài)，更加靈活。

　　演講***，何方石將函數(shù)計(jì)算的特點(diǎn)歸納為“高彈性、低成本、輕量級(jí)、低延遲”。具體來看，首先它是一個(gè)高彈性的服務(wù)，其次它具有比較低的開發(fā)成本，再者由于云平臺(tái)運(yùn)行的是單一計(jì)算的函數(shù)，所以它具備輕量級(jí)的特色，***是低延遲特點(diǎn)，一秒鐘一次調(diào)用和一秒鐘一萬次調(diào)用的頻率對(duì)比，延遲時(shí)間非常接近。

　　以上內(nèi)容是51CTO記者根據(jù)WOT2018全球軟件與運(yùn)維技術(shù)峰會(huì)的《微服務(wù)架構(gòu)設(shè)計(jì)》分論壇演講內(nèi)容整理，更多關(guān)于WOT的內(nèi)容請(qǐng)關(guān)注51cto.com。

【51CTO原創(chuàng)稿件，合作站點(diǎn)轉(zhuǎn)載請(qǐng)注明原文作者和出處為51CTO.com】