從理論走向實踐，多角度詳解Cloud Native

本次直播課程是由京東雲產品研發部中間件負責人李道兵從Cloud Native概念入手到實踐出發，深度解析了Cloud Native年度熱詞背後所隱含的技術特徵。

咱們將整理後的視頻及內容資料在這裏分享給你們，沒能到場的小夥伴能夠經過這些資料來學習和了解課程內容。 視頻觀看地址： mp.weixin.qq.com/s?__biz=MzU…

課程概要

課程從Cloud Native的服務治理、京東雲助力中小企業Cloud Native所得出的實踐經驗以及Cloud Native與雲平臺之間密切的技術關聯着眼，全面解讀Cloud Native在服務高可用、可伸縮、易運維等方面的優點。

如下是李道兵老師分享的所有內容，但願給各位開發者帶來更多幫助：

從理論走向實踐，多角度詳解Cloud Native

01 關於Cloud Native

衆所周知2013年算是架構史上比較重要的年份之一，這一年咱們看到有一些新名詞逐漸涌現，例如Docker，隨後出現的Docker Swarm以及各類Mesos，固然最近也有一些，其中Cloud Native就慢慢變成了熱詞之一。

針對熱詞，個人觀點是，關注一個技術詞彙以前首先要思考解決的問題、如何解決等層面，一個詞彙會引入一個嶄新的視角，以此爲基礎才能判斷先後發生了怎樣的變化，針對Cloud Native也是如此。

通過分析，其實Cloud Native與以前的不少熱詞本質不一樣，區別在哪裏？例如Docker，它是一個很具體的軟件，能夠在Linux或者mac平臺中探討容器化的Linux，具有相對獨立的環境，這一點一樣適用於Docker Swarms、Mesos、k8s等。

相比之下，Cloud Native不是一個軟件，也不是一種框架，而是一堆理念集合，以及圍繞這些理念所產生的一些最佳實踐的工具，最終究竟想解決什麼問題呢？

首先就是分佈式架構理念，例如SOA、EDS、EDA等。如何理解微服務是目前所見的一種很好的架構的形式？在整個架構形式下，會有一些比較好的服務分拆，那服務的治理方案究竟該怎麼去作？第二，當咱們提到分佈式架構時，最初被認爲是成品，但如何從源代碼進化到能夠運行的階段，須要一套部署與運維的方法論，又是什麼呢？第三，Cloud Native力推的是一套新的運行組織方法，本質上是容器化，實際上能夠解決不少問題，例如如何提供一個一致的運行環境？

以前一般認爲用鏡像加上虛擬機也能解決一致性問題，可是虛擬機的啓動速度很是慢，可能到分鐘級別並且性能損失很大，解決快速啓動效果並不出色。試想一下，若是採用容器是否是能夠達到更高性能，甚至幾乎無損？這就是Cloud Native。

02 嶄新的分佈式架構理念

講到分佈式架構的理念，能夠從架構變化史方向探討。

期初大部分人開始接觸服務端編程都是單一組件的概念，也就是整個服務端服務能夠視爲一個大程序，而後在此基。礎上連接數據庫、緩存以及有些複雜的消息隊列等，這一點與咱們常常接觸到的一些語言框架相似，例如早期比較流行的PHP等。總結來看，這類框架在給咱們傳達一個理念：除非有必要，咱們都應當在單一組件提供某個服務，呈現的形態也是最常規的不少小程序聚合的形態。

從我自身出發，也是慢慢從小規模軟件向大規模軟件變化的。但在大規模軟件的框架下就容易出現不少問題，例如單一軟件須要單一團隊來維護是最佳的狀態，7人合適；但若是一個單一組件的維護須要擴充到20-30人，就必然出現不少管理問題。在此基礎上進行人員拆分，又會出現邊界衝突，工做重複，很是尷尬。也就是說從單一組件到SOA，面向服務的架構體系，縱然能夠將總體服務按照功能拆分，服務之間再經過一些好接口實現調用，可是過程十分複雜。

另外一方面，向SOA中遷移的時候，很重要的一點是能夠複用這個模塊；但當爲一個單一組件的時候，複用也就不切實際了。

此外，這也是不少小團隊在快速成長中常常遇到的問題。在已知架構出現問題時，但由於被業務驅動沒法着手修改，因此選擇使用SOA作一些拆分工做。拆分以後，上層業務模塊就交付給了業務團隊去作更多迭代；底層團隊一樣能夠比較專一，進而完成一些穩定性以及性能優化方面的提高。

但與此同時就會發生隨着業務規模持續增加，服務愈來愈多的同時，服務治理就會出現相應的問題。若是以多個APP相互調用來解決，就會出現不少痛點。

在受權問題上，計費模塊或者用戶模塊中，天然不但願全部應用的權限被隨便調用，但限制權限如何去作？此外，若是APP須要在線完成擴容以及收容的操做，又應該怎樣通知調閱方呢？APP自己須要在接口方面作一些升級更新等，又將如何着手相應的管理工做？

這些問題的解決若是在SOA體系下，若是引入不適當的治理手段就會讓總體變得異常混亂，還會致使大量的安全問題。

此時咱們須要引入的第一個解決方手段一般被稱爲ESB，也就是企業級服務總線，Enterprise Service Bus來解決。針對剛纔提到的諸多問題，例如A服務調用B服務，針對B服務來講哦，如何在A的配置中寫入B的IP？

B服務在擴容以後，A中就有可能出現調用失效或者並未充分利用B資源等，致使擴容以後的新服務器用不上，收容以後的某些請求中斷，甚至產生錯誤結果等，這是萬萬不能接受的。再者，若是用A的配置寫入B的域名，再去解析，就頗有可能出現延遲以及 故障點的問題，甚至解析域名還會出現均衡問題，而這些出現都是急需解決的。

做爲技術人員，常規狀況下當一個問題很難被解決，天然就會引入新詞彙將複雜的問題簡單化，ESB就是如此。

在服務總線指導下，A無論須要調用哪一個服務均可以直接去調用服務總線；服務總線能夠明確過載、擴容、收容節點等具體細節；此外調用ESB，首先須要明確身份對其進行總控的措施，例如認證、受權、審計等。

企業級ESB，也就是Enterprise Service Bus，一般成本不低。在考慮成本的基礎上最簡單的方法就是中間配置一個Nginx，用兩臺服務器作一個簡單或者用LVS將它們連接起來，而後在上面配置一個後面掛服務的Nginx，再創建一套機制，力圖作服務擴容的過程當中得以於Nginx中自動作一些簡單的動態調整。

但引入ESB以後自己就比較容易出現新的瓶頸。一般狀況下企業內部服務在不接入大量外部服務的前提下，實際壓力並不高，這對於低壓力的企業問題不大，但對於互聯網應用來講一般沒法忍受。

固然若是解決此類服務調用採起註冊機制的話，整個數據中心天然不通過中心節點，ESB中的壓力就徹底下降了，可是採用服務註冊以後，服務治理方面就會有必定程度的退步，例如缺少中心，這時咱們引入合適的微服務框架來解決不少治理問題就完美了。

例如配置統一的註冊中心，就至關於將以前提到的服務註冊中心進行搬遷；另外使用同一的配置中心就至關於對依賴配置的部分能夠不用手動部署就自動劃歸到中內心；以前涉及到的受權問題，就能夠採用統一的受權以及鑑權體系來完成。針對過載，能夠提供不少贊成的熔斷以及伸縮手段去解決，再經過統一日誌來進行性能分析。

有了微服務這個平臺後，咱們能夠把不少最佳實踐整合進去。例如服務性能不夠好就能夠拆分紅不少小服務；分析性能很差的關鍵點，例如調用鏈分析這類工具就出現了，做爲微服務輔助工具來幫助你們解決這些方面問題。

微服務有了更強的治理能力，纔有能力把服務拆到最小的粒度，由於更小粒度的時候，工程質量可以更好地去控制。

固然針對微服務還有許多值得學習的地方。例如微服務的調用不少，服務之間的調用協議設計就很重要，這可能會關乎到一些API設計的知識。所謂API設計，你們比較認同的有REST API的設計以及一些基礎性理念，如何保證在API升級過程當中，整個客戶不受影響？又如何保證遷移成本更低？這些都須要實際解決。

另一方面就是分佈式事務。以前的單一組件事務很是簡單，但當服務開始分佈問題就不同了 。分佈式事務應該怎麼去解決？這又是一個很獨立的或者說很大的話題。

很重要的一點，服務究竟如何被拆分？從哪兒拆比較合適，哪兒是一些好拆分的邊界點，怎麼避免拆分時功能重疊、交叉？應該說其中有不少經驗或者知識。對此我很是想推薦的一本書就是《領域驅動設計》，它會給你一個新視角去理解業務，只有很好地理解業務，才知道應該怎麼去拆分業務，才能作到恰到好處。

整體來看，微服務很強大但其實仍是有些遺留的問題，例如DevOps流程應該怎樣？服務器上要運行大量異構服務，怎麼避免互相干擾拆？微服務拆分多細顆粒度才較合適？這些問題有一些部分仍是讓Cloud Native着手解決吧！

03 創新的部署與運維方法論

針對部署和運維的方法論問題，例如部署形態是什麼？其中最先的單機軟件部署最簡單，PHP都認爲是部署最簡單的，用SCP或者FTP上傳，新的軟件就部署好了。但也有隱患，此次部署與下次部署怎麼保持徹底一致？不一致的東西不少，例如運行時的版本、動態連接庫的版本等，對此都是經過容器化的方式來解決。

從部署形態的集羣來講，第一種最簡單的就是無狀態集羣，有狀態集羣應該是少數特例。無狀態集羣通常都是同構的，沒有特別關注只要水平部署就能夠，只須要注意擴容與收容，這方面即使是在Cloud Native的概念出現以前，其實不少團隊已經作得很好了，例如特定時間點的擴容，如何根據線上壓力去作一些自動擴容等。

此外就是狀態集羣，以前部署過程當中一個很大的問題就是很是依賴文檔、部署的可在線性，致使一樣裝置一個數據庫，例如MySQL5.6，不一樣人的實踐結果都有差別；另外就是自研類，可能一些比較大的公司都會有一些自研的KV數據庫、分佈式數據庫鞥，這類自研數據庫很是依賴於開發和運維對系統的瞭解程度，以及整個升級務必要有各類回滾預案。

最麻煩的是什麼？升級之後回滾其實超級難以創新，而k8s這類容器編排能很好地解決這些問題。如此看來K8s的出現幫助咱們迎來了一個新的、怎樣的運維狀態？與以前有何不一樣？

首先在同一個服務中，全部節點均可以根據實際狀況進行摘除和及時補充，這一點並不像以前很容易進入不一致的狀態；另外在物理機的時代，線上的服務狀態各類不一致，例如LINUX不一致，空間不一致，日誌滾動的設置不一致，這都是有可能的，而現在作到嚴格一致利用K8s就行了。

還有一點，在K8s中取消了服務器的形態，這是運維工做或者是系統管理員工做的一大進步；沒有服務器就意味着系統管理員以前在服務器中作的全部的工做沒有了操做的對象，運維人員或者SRE人員就可以在一個更高的維度去保障服務質量。最後一點更安全。自己入侵到容器自己所形成的危害更小，還能夠捉到能夠按期重置，以此能夠持續下降被攻擊的風險。

04 Cloud Native落地的幾種形態

首先對於新項目來講，若是技術實力稍弱，建議推薦採用微服務或者Spring Cloud這種方式落地。這種方式須要管理的事務較少，只要順着思路寫代碼就能夠了，若是能匹配雲上的最佳服務實踐就更贊。

對於技術實力稍強的能夠考慮使用K8s，將整個業務管理起來，採用Service Mesh的方式落地，十分不錯，固然這兩種方式彼此並不排斥。對於一些特定的項目來講，例如事件驅動或者物聯網項目、或者平時沒有任何響應卻忽然有請求的，量大能夠採用Serverless的架構，也就是函數服務的方式支持。

對於老項目，須要在逐漸演化的過程當中按部就班。對於技術實力相對較弱的狀況，能夠積極改善自動化的運維流程，儘量達到容器化，充分利用雲或者其餘平臺提供伸縮或者服務治理能力，而後根據團隊狀況考察K8s和Spring Cloud，逐步作一些遷移。

而技術實力比較強的能夠直接利用Service Mesh逐步改造現有的項目。由於Service Mesh的一個好處就是對原來的服務器不侵入，也就是原來的服務能夠不作任何遷移改造等，可是對技術能力要求較高。

05 京東雲對Cloud Native的支持

京東雲做爲一個服務提供方，在微服務方面已經提供了一套微服務的服務框架，框架中支持Spring Cloud項目，也支持Dubbo項目。

圍繞它來說，會提供一些註冊中心、配置中心、網關支持，還有調用鏈以及部署支持。也就是說用了京東雲提供的微服務，Spring Cloud運維起來更輕鬆，關注點更多集中在業務領域；還有一個K8s方案，幫助完成資源的調度工做，至關於每一個服務都會有一個新原生容器去承載服務。

第三個是基於Serverless的一些落地方案，京東雲Serverless2018年纔開始公測，如今只支持Python3，今年就會增長大量語言的支持，其中函數服務最大的好處是零成本啓動。

最後是漸進式的落地方案，怎麼落地呢？例如對一些無狀態的服務要逐步作到容器化，對於有狀態的服務儘量替代爲雲提供產品；若是自己對k8s支持比較好，能夠改形成一些高可用的形態；若是沒法作到高可用，就儘量作到自動化或者一鍵修復。

若是技術實力比較高的話，能夠選擇一些最佳的技術形態或者混合形態去作遷移，這方面更可能是實際上對客戶針對具體場景給出一些合理的建議來操做，而後進入Cloud Native的狀態。

最後須要強調的是，Cloud Native就是一種理念，並非一個具體的軟件；使用Cloud Native系統管理員的工做可能就會消失掉，由於沒有服務器，也就沒有所謂的服務器管理員了；此外針對完美擴容的實現以及平滑的回滾流程，甚至包括各類部署等，Cloud Native都會提供一套合適的解決方案來幫助解決。

以上爲公開課的全部內容。

在公衆號內回覆「PPT0319」得到公開課完整PPT

Q&A 課程問答

Q1 雲原生與前端技術開發的結合點可能會在哪些方向？ A1 坦白講這個問題尚未好好想過，應該說前端開發在哪一個階段，不管是基於API，仍是服務端頁面渲染等，其實都已經進入到一個嶄新的狀態，這個狀態與雲原生很是契合。

Q2 隨着雲原生的發展，將來還有哪些須要解決的問題？ A2 坦白講，首先須要一個最佳形態的指導。如今雲原生的落地形態其實是一個相對分裂的狀態，例如Service Mesh和K8s，究竟哪一種技術會成爲主導？如今還不肯定。 從這個角度出發，其實對雲原生並無實質性的幫助，咱們都但願能夠從社區的角度解決此類問題。另一個問題，K8s和Service Mesh的進入門檻還較高，怎麼去解決這個問題？也許隨着社區的進一步發展，你們對這個瞭解程度提升後就會有所改觀。

Q3 使用Cloud Native能實現哪些簡單的應用？ A3 須要從K8s學起，若是你學會用K8s去開發一些小應用，對Cloud Native就有了一個最基本的理解。用好K8s以後，要去學習如何去作拆分，要學好如何在一個沒有事務的狀況下實現這個事務，也就是分佈式事務必定要學，從這種角度入門比較合適。若是K8s這關過了，剩下的其實隨着經驗的慢慢提高也會慢慢學會的。

Q4 雲原生和多雲環境是什麼關係？ A4 當咱們討論雲原生時，其實對多雲沒有任何涉及，這應該算是另一個問題。 如何想要實現多雲或者多活，首先須要儘可能減小有狀態的組件；第二，要明確想實現的目標，是須要將雲端SQL的修改同步到另外一側嗎？關於這一點，主要仍是一些基於事件或者日誌方面的操做，或者直接經過分析驅動將MySQL映射到對面。第三，還要作好各類緩存更新以及清理工做，須要特別注意多雲或者ADC多活。

Q5 雲原生落地和iPaaS關聯大不大？ A5 其實Redis組件和MySQL組件很是但願被採用雲上的版本，能夠高效幫助解決傳統問題、性能問題和運維問題。 若是是在私有化或者Open Stack上部署的話，要多看看這些組件有沒有對已經配置好的一些K8s配置產生做用。由於K8s的配置可以幫助下降不少調優或者運維上的困難，例如Redis宕機了，究竟應該怎麼處理？K8s可能已經把這些設置內嵌在配置中。

原文連接： mp.weixin.qq.com/s?__biz=MzU…