本次直播課程是由京東雲產品研發部中介軟體負責人李道兵從Cloud Native概念入手到實踐出發，深度解析了Cloud Native年度熱詞背後所隱含的技術特徵。
課程概要
課程從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不是一個軟體，也不是一種框架，而是一堆理念集合，以及圍繞這些理念所產生的一些最佳實踐的工具，最終究竟想解決什麼問題呢？
02 嶄新的分散式架構理念
講到分散式架構的理念，可以從架構變化史方向探討。
期初大部分人開始接觸服務端程式設計都是單一元件的概念，也就是整個服務端服務可以視為一個大程式，然後在此基。礎上鍊接資料庫、快取以及有些複雜的訊息佇列等，這一點與我們經常接觸到的一些語言框架類似，例如早期比較流行的PHP等。總結來看，這類框架在給我們傳達一個理念：除非有必要，我們都應當在單一元件提供某個服務，呈現的形態也是最常規的很多小程式聚合的形態。
從我自身出發，也是慢慢從小規模軟體向大規模軟體變化的。但在大規模軟體的框架下就容易出現很多問題，例如單一軟體需要單一團隊來維護是最佳的狀態，7人合適；但如果一個單一元件的維護需要擴充到20-30人，就必然出現很多管理問題。在此基礎上進行人員拆分，又會出現邊界衝突，工作重複，非常尷尬。也就是說從單一元件到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中的壓力就完全降低了，但是採用服務註冊之後，服務治理方面就會有一定程度的退步，例如缺乏中心，這時我們引入合適的微服務框架來解決很多治理問題就完美了。
有了微服務這個平臺後，我們可以把很多最佳實踐整合進去。例如服務效能不夠好就可以拆分成很多小服務；分析效能不好的關鍵點，例如呼叫鏈分析這類工具就出現了，作為微服務輔助工具來幫助大家解決這些方面問題。
微服務有了更強的治理能力，才有能力把服務拆到最小的粒度，因為更小粒度的時候，工程質量能夠更好地去控制。
另外一方面就是分散式事務。之前的單一元件事務非常簡單，但當服務開始分佈問題就不一樣了 。分散式事務應該怎麼去解決？這又是一個很獨立的或者說很大的話題。
很重要的一點，服務究竟如何被拆分？從哪兒拆比較合適，哪兒是一些好拆分的邊界點，怎麼避免拆分時功能重疊、交叉？應該說其中有很多經驗或者知識。對此我非常想推薦的一本書就是《領域驅動設計》，它會給你一個新視角去理解業務，只有很好地理解業務，才知道應該怎麼去拆分業務，才能做到恰到好處。
03 創新的部署與運維方法論
針對部署和運維的方法論問題，例如部署形態是什麼？其中最早的單機軟體部署最簡單，PHP都認為是部署最簡單的，用SCP或者FTP上傳，新的軟體就部署好了。但也有隱患，這次部署與下次部署怎麼保持完全一致？不一致的東西很多，例如執行時的版本、動態連結庫的版本等，對此都是通過容器化的方式來解決。
此外就是狀態叢集，之前部署過程中一個很大的問題就是非常依賴文件、部署的可線上性，導致同樣裝置一個資料庫，例如MySQL5.6，不同人的實踐結果都有差異；另外就是自研類，可能一些比較大的公司都會有一些自研的KV資料庫、分散式資料庫鞥，這類自研資料庫非常依賴於開發和運維對系統的瞭解程度，以及整個升級務必要有各種回滾預案。
首先在同一個服務中，所有節點都可以根據實際情況進行摘除和及時補充，這一點並不像之前很容易進入不一致的狀態；另外在物理機的時代，線上的服務狀態各種不一致，例如LINUX不一致，空間不一致，日誌滾動的設定不一致，這都是有可能的，而如今做到嚴格一致利用K8s就好了。
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，今年就會增加大量語言的支援，其中函式服務最大的好處是零成本啟動。
如果技術實力比較高的話，可以選擇一些最佳的技術形態或者混合形態去做遷移，這方面更多是實際上對客戶針對具體場景給出一些合理的建議來操作，然後進入Cloud Native的狀態。
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可能已經把這些設定內嵌在配置中。