在线公开课 | 从理论走向实践，多角度详解Cloud Native
戳藍字“CSDN云計算”關注我們哦！
本次直播課程是由京東云產品研發部中間件負責人李道兵從Cloud Native概念入手到實踐出發，深度解析了Cloud Native年度熱詞背后所隱含的技術特征。
我們將整理后的視頻及內容資料在這里分享給大家，沒能到場的小伙伴可以通過這些資料來學習和了解課程內容。
課程從Cloud Native的服務治理、京東云助力中小企業Cloud Native所得出的實踐經驗以及Cloud Native與云平臺之間密切的技術關聯著眼，全面解讀Cloud Native在服務高可用、可伸縮、易運維等方面的優勢。?
以下是李道兵老師分享的全部內容，希望給各位開發者帶來更多幫助：
從理論走向實踐，多角度詳解Cloud Native
— 京東云產品研發部中間件負責人? ?李道兵—
（建議在Wi-Fi環境下觀看）
眾所周知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著手解決吧！
? ??
針對部署和運維的方法論問題，例如部署形態是什么？其中最早的單機軟件部署最簡單，PHP都認為是部署最簡單的，用SCP或者FTP上傳，新的軟件就部署好了。但也有隱患，這次部署與下次部署怎么保持完全一致？不一致的東西很多，例如運行時的版本、動態鏈接庫的版本等，對此都是通過容器化的方式來解決。
從部署形態的集群來說，第一種最簡單的就是無狀態集群，有狀態集群應該是少數特例。無狀態集群一般都是同構的，沒有特別關注只要水平部署就可以，只需要注意擴容與收容，這方面即便是在Cloud?Native的概念出現之前，其實很多團隊已經做得很好了，例如特定時間點的擴容，如何根據線上壓力去做一些自動擴容等。
????
此外就是狀態集群，之前部署過程中一個很大的問題就是非常依賴文檔、部署的可在線性，導致同樣裝置一個數據庫，例如MySQL5.6，不同人的實踐結果都有差異；另外就是自研類，可能一些比較大的公司都會有一些自研的KV數據庫、分布式數據庫鞥，這類自研數據庫非常依賴于開發和運維對系統的了解程度，以及整個升級務必要有各種回滾預案。
最麻煩的是什么？升級以后回滾其實超級難以創新，而k8s這類容器編排能很好地解決這些問題。如此看來K8s的出現幫助我們迎來了一個新的、怎樣的運維狀態？與之前有何不同？
首先在同一個服務中，所有節點都可以根據實際情況進行摘除和及時補充，這一點并不像之前很容易進入不一致的狀態；另外在物理機的時代，線上的服務狀態各種不一致，例如LINUX不一致，空間不一致，日志滾動的設置不一致，這都是有可能的，而如今做到嚴格一致利用K8s就好了。
??
還有一點，在K8s中取消了服務器的形態，這是運維工作或者是系統管理員工作的一大進步；沒有服務器就意味著系統管理員之前在服務器中做的所有的工作沒有了操作的對象，運維人員或者SRE人員就能夠在一個更高的維度去保障服務質量。最后一點更安全。本身入侵到容器本身所造成的危害更小，還可以捉到可以定期重置，以此可以持續降低被攻擊的風險。
? ?
04Cloud 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都會提供一套合適的解決方案來幫助解決。
? ??
以上為公開課的所有內容。本周日（3月24日），我們會有一個線下沙龍，屆時會詳細講一講京東云的K8s，如何幫助落地，京東云的微服務提供了一些怎樣的功能以及有關Serverless方面的技術實踐，此外還會有一個關于開源軟件的主題！
點擊“閱讀原文”即刻報名！
在“京東云開發者社區公眾號”內回復“PPT0319”獲得公開課完整PPT
課程問答
云原生與前端技術開發的結合點可能會在哪些方向？
A坦白講這個問題還沒有好好想過，應該說前端開發在哪個階段，無論是基于API，還是服務端頁面渲染等，其實都已經進入到一個嶄新的狀態，這個狀態與云原生非常契合。
坦白講，首先需要一個最佳形態的指導。現在云原生的落地形態實際上是一個相對分裂的狀態，例如Service Mesh和K8s，究竟哪種技術會成為主導？現在還不確定。
從這個角度出發，其實對云原生并沒有實質性的幫助，我們都希望可以從社區的角度解決此類問題。另外一個問題，K8s和Service Mesh的進入門檻還較高，怎么去解決這個問題？也許隨著社區的進一步發展，大家對這個了解程度提高后就會有所改觀。
????
使用Cloud Native能實現哪些簡單的應用？
????
A需要從K8s學起，如果你學會用K8s去開發一些小應用，對Cloud Native就有了一個最基本的理解。用好K8s之后，要去學習如何去做拆分，要學好如何在一個沒有事務的情況下實現這個事務，也就是分布式事務一定要學，從這種角度入門比較合適。如果K8s這關過了，剩下的其實隨著經驗的慢慢提升也會慢慢學會的。
當我們討論云原生時，其實對多云沒有任何涉及，這應該算是另外一個問題。
如何想要實現多云或者多活，首先需要盡量減少有狀態的組件；第二，要明確想實現的目標，是需要將云端SQL的修改同步到另一側嗎？關于這一點，主要還是一些基于事件或者日志方面的操作，或者直接通過分析驅動將MySQL映射到對面。第三，還要做好各種緩存更新以及清理工作，需要特別注意多云或者ADC多活。
其實Redis組件和MySQL組件非常希望被采用云上的版本，可以高效幫助解決傳統問題、性能問題和運維問題。
如果是在私有化或者Open Stack上部署的話，要多看看這些組件有沒有對已經配置好的一些K8s配置產生作用。因為K8s的配置能夠幫助降低很多調優或者運維上的困難，例如Redis宕機了，究竟應該怎么處理？K8s可能已經把這些設置內嵌在配置中。
福利
掃描添加小編微信，備注“姓名+公司職位”，加入【云計算學習交流群】，和志同道合的朋友們共同打卡學習！
推薦閱讀：
都道業務提升坑大事兒多，但英特爾云方案卻說“簡單”
云有約 | 螞蟻金服bPaaS究竟是什么？
再不編程就老了！05 后比特幣專家準備賺個 134,000,000 元！
Pig變飛機？AI為什么這么蠢 | Adversarial Attack
互聯網沒有春天
麥克阿瑟獎得主Dawn Song：區塊鏈能保密和保護隱私？圖樣圖森破！
2019年最值得關注的五大微服務發展趨勢
喜歡就點擊“好看”吧
總結
以上是生活随笔為你收集整理的在线公开课 | 从理论走向实践，多角度详解Cloud Native的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 揭密｜淘宝服务端千万级高并发架构的演进之
- 下一篇： boost::callable_trai