從單體應用到微服務的開發旅程

特別說明

這是一個由simviso團隊進行的關於架構演進的雲原生分享的翻譯文檔，這個主要是關於Service Mesh 的分享，分享者是Kong這家公司的CTO。 這家公司有一個著名的開源項目：github.com/Kong/kong

讓 咱們一塊兒來學習下這家CTO是如何從單體應用架構過渡到微服務架構的，Kong又作了哪些事，K8S在其中又作了什麼角色，什麼是狀態機（基於事件架構獲得一種設計），在這個過程當中又會遇到哪些坑，哪些經驗，盡在視頻分享中

視頻地址：

【國外前沿技術分享-雲原生專題-中文字幕】從單體應用到微服務的開發旅程-上

【國外前沿技術分享-雲原生專題-中文字幕】從單體應用到微服務的開發旅程-下

視頻翻譯文字版權歸 simviso全部：

順帶推薦一個專業的程序員後端微信羣的圈子：

前言

我叫Marco Palladino，我是Kong的創始人，同時也是這家公司的CTO

如他所說，我來自San Francisco California， 今天我想和你們討論下Service Mesh

爲了打造出適合現代化的架構體系，咱們的架構組織採用了Service Mesh來作過渡

我想說的是，當咱們的企業變大並經過拆分變成分佈式管理以後，那這個企業組織就會變得像多細胞生物同樣複雜 （由一個單細胞的形式分裂成多細胞進行協做，總體上看去仍是這一個生命體）

事實上，不管是咱們的團隊仍是軟件，一旦複雜了，都會去作解耦並進行分佈式化管理

能夠想象一下，在使用service mesh實現架構現代化的過程當中，它不只僅只是技術採用這麼簡單

咱們的軟件開發方式也由於如下三個方向而發生着改變

其中一種是技術上的更新換代

第二種是組織結構上的過渡

因此架構組織該如何去改變才能去應對新的微服務架構

也就是說，咱們以前對單體架構系統所作的操做模式必須進行改變。即咱們不能以以前的方式去部署，擴展，版本化和文檔化這個全新的微服務架構

這三個方向正在改變咱們開發軟件的方式

隨着docker和kubernetes在2013和2014年的前後發佈，一場真正的軟件革命也就開始了

Docker和 kubernetes爲咱們提供了一種全新的建立應用的方式 隨着時間的推動，基於它們，咱們能夠以更好的方式來對這些應用進行拓展 不只僅是從技術上帶來的好處，更重要的是能夠做爲咱們業務拓展的首選

事實上除了技術層面，在這場演講中我會來談下咱們想要實現的業務目標

若是咱們不能在實現業務目標的同時協調新技術的使用，那麼咱們也就沒辦法在技術轉型上走下去

在這個過程當中，咱們必須變得更加務實才行

這是一個從單體架構服務到聚合服務（好比Maven多模塊）再到微服務化的過程 Service Mesh就好像一個口袋 口袋裏裝了一堆的糖果，每一個糖果都是一個微服務，每個微服務多是咱們正常實現的服務，也有多是由函數式實現的服務

同時，API也會改變它們在咱們系統中的角色

咱們一般以API爲粒度進行APM（Application performance monitoring）性能監控管理。 自從2007-2008年移動端問世起，咱們須要一種方式去和咱們單體應用進行交互。因而咱們纔有了north-south traffic（南北交換，一般指多端與服務器之間的數據交互，也就是說咱們能夠經過外部開發者或移動端APP或外部其餘形式來訪問服務器，重點是外部）

咱們要對咱們的軟件進行功能解耦，此時API在咱們的系統中扮演的角色也就愈來愈重要

East-west traffic（東西交換，和上面相比，重點是內部），這個一般是指咱們不一樣團隊所開發的系統以及不一樣系統產品之間所產生的數據交互 接下來，咱們將討論使用 Service Mesh來對數據層和控制層進行分離，以此來不斷的優化擴展咱們的系統

過渡微服務的一些相關要點

1 What does it mean?

但退一步來說，從務實的角度出發，爲何要用Service Mesh來進行微服務的過渡

咱們重構單體應用的目的是能夠釋放團隊生產力以及提升業務的可擴展性

此時整個過渡的關鍵在於團隊生產力以及相關業務的可擴展性

在向微服務過渡的過程當中，若是咱們沒有作到這二者中的任何一點，那能夠這麼說，咱們在作的不過是依葫蘆畫瓢 因此在作這個事以前咱們必須捫心自問，咱們究竟是在爲生產而使用，仍是爲了用這個技術而用

在這個過程當中，業務應該是首要驅動力，由於咱們寫項目的目的就是爲了實現業務目標 在肯定業務策略而後採用微服務架構來實現，接下來，咱們要肯定從何時開始，更重要的是到何時結束

2 should we do it？

接下來第二個問題，也是那些想要將項目轉向微服務的人想要問的 咱們是否應該這麼作，是否應該轉向微服務，是否應該放棄如今原有的架構？

從技術趨勢而言，咱們不得不問本身，一項技術，咱們是基於實際須要採用，仍是由於這個技術很成熟纔去採用

過渡到微服務的過程，這可要比跑單體應用複雜得多。它難就難在一個系統包含了全部的功能，而後咱們將其裂變成一羣具備單一功能的系統

目前而言，咱們如今幾乎再也不以同一種方式部署或者擴展大型單體應用 但咱們能夠經過將一個完整的系統拆分紅成百上千個具備不一樣功能的單體系統來實現本來的功能

若是說目前微服務沒法去解決咱們在管理單體應用上的問題，那麼它就會使狀況變得更加糟糕

所以技術架構和團隊成員必須足夠成熟，才能確實的去解決存在的問題

事實上，我真的很推薦在這個過程當中採起步步爲營的方式過渡到微服務

基於如下幾個理由。首先，經過一步步的去實現階段性的目標，這能增加團隊的信心讓他們以爲這件事他們能夠駕馭 同時，咱們在這個過程當中也能夠去適應並隨時改變咱們的流程

同時，業務領導者也會隨着過渡而變得愈加自信，由於整個過渡是朝着正確的方向進行，隨着時間的推移來擴展和讓業務變得更加與時俱進

事實上，當咱們來看微服務，來看那些大公司例如Netflix，或者Amazon 它們其實很早以前就已經轉型微服務，甚至那時候kubernetes和docker都不存在

究竟是什麼在驅動這些公司去作這樣的轉型？

就拿Netflix而言，爲了擴展它的業務規模並再也不拘泥於一個國家和單一的用戶體系，它想向全世界邁進，因此它改變了

因此這也是他們的商業目標

對於想要達成的業務需求而言，他們以前的架構並不能知足。所以他們轉向了微服務架構以知足業務需求

Amazon一樣如此，由於它不僅僅知足於賣一種東西，它更傾向於商品的多元性，所以架構的改變才能知足更爲複雜的須要

所以微服務牢牢地圍繞着這些業務需求。爲了完成咱們的目標 咱們不能各自孤軍奮戰不管是開發團隊或者是管理層。拿Amazon舉例，它就是微服務的成功例子

那大家誰知道，是誰決定了讓Amazon向微服務去轉型？

Amazon CEO Jeff Bezos曾強制推行了六個原則，若是不聽從這些原則 那這些人就能夠直接被炒了（這段話實際上是講02年貝佐斯對員工提出必需要遵照的原則性問題）

這種改變很難相信竟然不是開發團隊提出的，而是他們的CEO提出的改變

做爲企業的領導者經過逐步的改變去完成目標，同時這樣能讓他們變得更加自信，這纔是正確前進的方法

從上面的全部狀況來看，爲了達到目標，咱們將要經歷無數的艱難險阻

咱們能夠依據複雜性來決定微服務是大是小

事實上，這些微服務的大小都由業務自己需求所決定，適合就行

3 Let's do it!

但只有當咱們以爲微服務是咱們所須要的，同時咱們所選擇的路線也是正確的，那麼咱們才能繼續轉型

在轉換到微服務的過程當中 ，我定義了兩種不一樣的策略 其中一種我稱之爲挖冰淇淋，若是有一大桶冰淇淋，就能夠從中一勺勺的挖出大家想要的， 大桶冰淇淋能夠挖出各自的服務和業務邏輯，而後就能夠在不一樣的流程中單獨執行和部署

第二種則是樂高法（搭積木），這意味着咱們並不會徹底擺脫本來的單體應用，這種一般適用於比較老舊的項目

但新的功能將會以新的架構進行打造

因此你必須找到一種可以讓微服務與過去老的應用從新創建聯繫的方法，否則這將很難過渡

第三種我稱之爲nuclear法，這也意味着咱們從頭開始打造一切

在轉型爲微服務架構的過程當中，咱們須要去維護本來的單體應用

從向微服務轉型的第一天開始起，咱們就不能從零開始開發，由於它是最差的選擇

這須要一支實力強勁的技術團隊，同時也須要根據實際狀況來肯定技術邊界 當你有兩個不一樣的團隊同時工做的時候，一個能夠持續交付，另外一個團隊則將項目重構並微服務化

當咱們從新構建這個新的代碼庫時，會將舊代碼庫的功能重構到新代碼庫中，這裏 問題來了，咱們該在哪裏去建立新功能，由於此時咱們的業務依然基於老代碼庫運行，並無使用新代碼庫

也就是說，咱們遇到了一個很複雜的狀況，難以解決，因此，咱們千萬不要拋棄一切，從0開始。接下來就是咱們今天要探討的冰淇淋策略

舉個例子，咱們有一個面向對象的單體服務架構，它具備咱們所須要的全部的功能，這些功能經過不一樣對象和類在這個單體服務架構去交互實現

不一樣的服務共用了同一個數據庫。若是想要擴展這個單體應用，那麼咱們只能部署更多這個單體應用的實例 （爲了緩解某個擴展服務的壓力，其餘服務被動進行沒必要要的水平擴展，增長了複雜性）

若是這個單體應用是個電商網站，好比咱們常見的amazon.com，那咱們會有不少不一樣的服務，好比用戶管理，訂單管理，庫存管理，站內搜索等

這就是一個典型的單體服務架構案例，在這張圖裏，每一個單獨的方塊表明了一個不一樣的業務邏輯

由於這是一個規模很大的單體服務架構，咱們須要不少團隊一塊兒去維護它 在這個案例中，有三個不一樣的團隊在對這個單體應用進行維護，爲其建立新功能並將它們投入到生產環境中

如今相信大家如今也知道了單體架構和微服務架構的一些利弊。在單體架構中，會出現一個問題 若是其中一個開發團隊對其進行頻繁的修改提交，那麼就須要在其餘團隊之間進行大量的協調，以便在生產環境中正確部署這些改變

隨着代碼庫變得愈來愈大，產品開發團隊也一樣如此。隨着時間的推移，問題會變得愈加嚴重。這會嚴重影響咱們新版本發佈週期的效率

當團隊2（有多個團隊一塊兒開發）也開始頻繁的變動代碼的時候。遇到的問題更復雜，此時，咱們該如何改變現狀？

由於團隊2在爲搜索服務，庫存以及其餘模塊進行開發工做，若是某個模塊須要不少迭代，咱們該怎樣將這個模塊抽取出來（進行單獨開發）

因此咱們所用的冰淇淋策略就是從單體架構中提取出業務邏輯，並將其獨立出來

這些服務都很是重要，但它們並非微服務。這就是今天咱們須要作的工做即將它們逐漸改形成微服務

咱們要確保所抽取出來的新服務可以不依賴本來老系統所使用的數據庫

咱們的初衷是但願所抽取的新服務真正的獨立

若是老系統對數據庫進行了過多的請求

那麼數據庫將變得不可用

由於咱們不想讓服務受到影響，因此咱們想要對服務進行分拆和隔離

而後咱們在生產環境下試運行，接着，當遇到一個或多個部分（這裏指圖中的方塊）也須要進行大量修改的時候，指出並將它們抽取出來

因此咱們如今有三個不一樣的服務（如圖所示），一個是咱們的老系統，其次是一個稍大的服務，最後是一個小服務

從實際出發，經過一次又一次從單體應用中進行這種服務抽取的操做 或者是從已分離的服務中進一步抽取使之粒度變得更小，以此來解決咱們當下所面臨的問題

整個迭代過程不可能一次所有完成，咱們只能以務實的態度去一步一步針對所抽取的業務進行敏捷開發

經過這種按部就班的過程，咱們能夠順帶去修改這個項目組織中的其餘相關邏輯

以此來給項目的後續迭代提供更多的解耦支持

實際上，在過渡的過程當中，這就是一個重構，相似於咱們之前在單體服務架構內部進行服務的重構。在這咱們有一些事須要去明確

第一件事，咱們須要理解這個模型是什麼。若是咱們都不理解這些代碼作了什麼，那對咱們而言就很難去肯定服務邊界

大家知道大部分的單體架構服務的邏輯都過於耦合。正因如此，咱們才須要去明確服務邊界並解耦服務 若是咱們都不知道這些，那咱們就根本不可能抽取出來

爲了可以重構老系統，咱們也須要去理解如今系統中使用的client，以及若是當錯誤發生時，會對客戶端產生什麼樣的影響

在微服務轉型前，咱們須要知道哪些服務會受到影響

咱們因此作的第三件事就是像其餘全部重構同樣，須要經過集成測試去驗證咱們想要修改的邏輯是否正確 以此來確保咱們的重構不會對本來的系統產生影響

咱們但願在不影響系統內部運行的狀況下，來擴展咱們的系統

咱們不想要中斷(影響）必要的服務，至少咱們不能同時去擴展或者改變業務邏輯，這隻能一步一步來

當老系統在運行時，有一些事情，可能就是一個小方法的改變，那麼咱們就沒有必要去將它和以前同樣去進行相同的擴展

好比，升級咱們的客戶端或者爲了將請求正確路由到不一樣的服務而去更新路由

客戶端會對咱們的單體應用進行請求，但如今那些請求再也不由咱們的單體系統處理而是經過其餘服務去處理。因此咱們該如何從新路由這些請求？

在傳統業務模型中，咱們會在客戶端與服務端之間放置一個負載均衡器（好比nginx）

好比咱們的客戶端能夠是個移動端程序，當咱們部署單體系統的時候，咱們只需在負載均衡器以後運行此應用的多個實例

但隨着咱們系統一步步抽取解耦造成不少微服務，咱們就須要將整個運行架構的某些方面更加智能化才行

首當其衝的一件事就是須要採用一個靈敏的API網關

若是這個網關能作到智能化負載均衡

那麼當咱們解耦服務後，咱們就能將API網關做爲服務端與客戶端之間的代理並實現功能路由。 這就可使得咱們無須升級客戶端便可將請求路由到這些新的服務下。這對咱們而言十分重要 若是咱們不這麼作，那就必須升級客戶端，原有的版本就會出問題，客戶體驗就不好，也就說會對咱們的業務產生很很差的影響

客戶端到服務端之間的代理也就是網關，它必須足夠智能化纔可以幫助咱們處理咱們架構上的一些操做 像我以前說的向微服務過渡，這並不只僅是技術上的採用例如咱們說的kubernetes，同時也是運營管理上的過渡

咱們不能以部署單體應用的方式來部署微服務架構和SOA架構

咱們須要經過一些策略來下降風險

好比，一個服務的新版本出來了，咱們能夠經過使用灰度發佈的策略將10%的流量導向新版本的服務

只有當穩定了，咱們才能將流量徹底的導向新版本的服務上同時擺脫掉舊版本服務 與此同時咱們也須要繼續保持舊版本的運行，以防咱們須要回滾到前一個版本

在深刻探究微服務和service mesh以前，我想花點時間去闡述下hybrid和multi-cloud

當微服務化的時候，咱們就須要採用像kubernetes這樣的平臺來運行咱們的服務

由於咱們還有很多服務還在老系統上運行，因此咱們不會在kubernetes中運行全部的服務 咱們仍然會將老系統在咱們以前使用的平臺運行，例如虛擬機

當咱們計劃向微服務轉型的時候，咱們必須制定一個策略來將新老應用平臺進行一個有效的鏈接

咱們沒有辦法在一晚上之間將全部東西都運行在Kubernetes之上

因此，咱們該怎麼作才能將kubernetes上運行的服務和本來的老系統的相關依賴服務從新創建聯繫

就如我以前所說，這裏將整個組織想象成一個複雜的人體組織 那麼咱們能夠想到，不一樣的團隊，產品以及業務需求，它們共同的目標都是（所開發的程序單元）要成爲彼此獨立的存在

從更高層次的角度來看，整個組織不必非要用hybrid ，也不必非要用Multicloud，這須要有一個自上而下的決定

一些公司的項目組織已經運行在不一樣的雲平臺上，之因此採用了hybrid 和 Multicloud 也就意味着隨着時間的推移，這些不一樣的團隊根據項目組織的須要選擇了不一樣的雲平臺

從更高層次的角度來看這些公司的整個項目組織，它們爲何採用hybrid cloud,這已經不是由於他們想要用，而是他們不得不用

從理想的角度而言，咱們想將全部的服務都放在同一個平臺運行

但咱們仍是要面對現實，當下的狀況是，咱們須要將多個系統運行在各個地方 因此咱們須要有一個抽象級別更高的架構，在這裏咱們須要有工具能夠管理這個項目組織下的 Multicloud與hybrid

4 服務粒度

隨着咱們從這個單體服務架構中抽取出愈來愈多的微服務

我要給一條建議，結合當下的目標，以合理的方式來肯定微服務邊界 我認爲是十分重要的。這是我在那些已經十分紅功的抽取案例中所獲得的經驗

就像我以前的例子，咱們不能將微服務化一步到位 咱們能夠將一個相對較大的服務抽取出來，而後隨着時間的推移一步步解耦它，使之變得愈來愈小

當咱們在看待Service mesh和微服務架構時，理想狀況下，這些服務都應該是很小的 而且會以相同的方式互相鏈接起來。

但現實是，這些服務的大小都取決於咱們以最好的方式來達成的業務目標所產生的規模

咱們不要爲了追求微服務而強行使用微服務，有時候咱們須要的多是一個比較大的服務

5 網絡

ok，如今咱們經過解耦獲得了不少微服務，這些解耦的微服務由不一樣的團隊獨立建立並獨立部署 須要強調的是，這些服務不能單獨存在，它們須要經過彼此交流才能運行

so，咱們將放棄在單體應用中一些使用方式。咱們基於代碼庫中的對象（這裏的對象是指接口實現類，不是咱們的POJO） 接口和函數調用，經過完美執行這些函數調用，咱們能夠調用和訪問不一樣的對象

可是當咱們將它們解耦成微服務時，這些接口實現類對象變成了服務

接口仍然存在，但全部微服務間的訪問將經過網絡來進行

舉個例子，在一個Java單體應用中，當執行一個函數調用時（調用所定義接口中的方法） 由於底層是基於JVM，咱們徹底無須擔憂這個調用，它會被成功處理， java虛擬機將接收調用，並將該調用路由到正確的實現類中

可是在微服務中，咱們將沒法作到前面這種

由於咱們將經過網絡來進行函數調用，因此咱們將沒法保證這種函數請求會在網絡中具體哪一個地方進行調用

在咱們的系統中，網絡是一個很是不可靠的因素。網絡可能會很慢，有延遲也有可能宕機 總之網絡和單體應用層面不一樣的是它會有各類各樣的問題來影響咱們的系統服務

在微服務架構體系中，咱們會有不一樣的團隊來運行和部署這些服務

團隊的思惟方式也須要進行改變

在單體應用中，它有兩種狀態，工做或者宕機

可是在微服務中，任什麼時候候，若是一個服務在運行過程當中出現了問題 此時，咱們應該改變思惟方式，即這裏應該有一個服務降級，也就是咱們的架構中應該有服務降級這一部分

由於這些不一樣服務中的每個都會出現問題，咱們會建立的越多降級服務，團隊能夠將它們各自進行獨立部署

同時，在組織結構上，咱們的項目團隊也要改變相應的思惟模式

在某個時刻，服務一旦發生問題，服務降級系統必須制定該如何進行處理，同時爲終端用戶提供一個很是好的體驗

爲終端用戶所作的這些全部事情，並非爲了咱們本身，咱們這麼作是爲了給終端用戶提供一個更好的產品體驗

延遲

接下來說延遲，API 間調用產生的延遲咱們我沒法忽略

咱們都知道，網絡延時十分重要，對於傳統的移動端到單體應用訪問來講

若是移動端App訪問咱們的系統時延遲達到數百毫秒，這個對咱們而言 情況並不樂觀，咱們能夠經過CDN或者緩存來下降延遲，改善網絡處理的速度

在微服務中，延時的產生是因爲不一樣的微服務間的相互的請求愈來愈多，服務A在消費 服務B在消費，服務C也在消費，能夠看到，這就會產生服務間相互調用的延時問題

在微服務中傳輸架構中，一旦一個基礎服務發生了服務宕機,調用宕機服務的調用方也會所以而發生新的宕機 在一個單體的服務架構中，一旦一個服務產生異常則和它相關的調用都會發生異常

在微服務中，當產生響應超時，這會影響其餘相關微服務，產生鏈式反應，狀況就好像整個系統再也不工做同樣

因此延遲是咱們須要去解決的首要問題，這不是咱們過後想fix就fix的 就像安全和性能，這兩個不是功能組件，咱們沒辦法後續添加 咱們只有在編寫系統的時候時刻保持這個意識，如何寫才能保證性能，如何寫才能保證系統安全

安全也成爲其中的另外一個組成部分（如圖所示），因此如今咱們在網絡上擁有的全部這些通訊，咱們但願可以加密並保護這些交互

例如，經過強制實施雙向TLS或者在不一樣服務間使用你所知道的方式來加密網絡通訊

順帶說一下，這些服務不必非要經過restful api來運行

咱們能夠去使用任何一種對咱們所在場景有利的傳輸協議，大家能夠用rest或者gRPC或者其餘任何一種傳輸協議

咱們不受限於任何一種特定的傳輸方式或者協議，咱們須要知道該如何去透明地保護和加密這些全部的通訊

就像我以前提到的路由，如今咱們有不一樣的服務，咱們該怎樣在一個系統的某個地方設定路由服務 路由到咱們不一樣版本的服務上，將請求路由到那些咱們部署在不一樣雲主機的微服務

一樣若是咱們的服務再也不運行的時候，此時咱們須要進行異常處理 咱們須要可以將請求到這些不工做的實例或者服務的通訊打斷。因此在這裏咱們須要斷路器和health check

在單體服務架構下，咱們沒有必要非要設定斷路器或者是health check 但當規模達到必定程度例如跑一千個單體應用的時候，它們就變得極爲重要 若是從一開始咱們沒有這麼作，那麼咱們在過渡到微服務這條路上就會變得朝不保夕

一樣，可觀測性也和以前在單體架構服務中不一樣 在單體架構中，咱們不須要關心請求會去向哪裏（由於很明確）, 可是如今在微服務架構中，咱們必須知道

由於咱們須要可以去定位咱們微服務架構中的薄弱環節 因此咱們須要追蹤從一個服務到另外一個服務的請求，以及收集性能指標和日誌 這樣才能便於咱們理解在任什麼時候候微服務作了什麼，以及若是出現問題的話，定位出錯的位置

在沒有肯定服務邊界的狀況下，很難去向微服務過渡 由於在某一點上不可避免地會出現問題，而咱們將沒法使用合適的工具來挖掘並找到問題所在

Service Mesh Pattern

讓咱們接着討論Service Mesh

首先，Service Mesh並非一種技術，而是一種設計模式，咱們能夠經過各類各樣不一樣的方式來實現Service Mesh

可是一般，咱們會有一個代理與咱們的服務一塊兒運行，經過這些代理能夠將不可靠的網絡變得可靠

基於此，咱們在構建咱們的服務時就不須要擔憂如何處理延遲問題、observability(可觀測性)和雙向的TLS等等

由於鏈接點再也不是服務到服務，而是Data Plane（DP,數據平面）到 Data Plane

這些點經過外部網絡進行聯繫，其實就是這些鏈接點經過Data Plane進行通訊

同時，因爲Data Plane能夠在服務無感知的狀況下執行邏輯，那麼咱們能夠在此進行異常，延遲以及可觀測性處理

在一個Service Mesh中，Data Plane既是代理也是反向代理，這取決於請求的去向

例如，若是這個服務想要調用那個服務，那麼這個Data Plane將做爲一個代理 由於（這個）服務正進行的請求將經過那個Data Plane進行代理

可是當那個Data Plane收到請求，那個Data Plane將充當一個反向代理，它將接收請求並將其代理到與之關聯的服務

咱們須要有一個Data Plane，咱們能夠經過不一樣的方式來實現Service mesh 每一個底層虛擬機或者每一個你正在運行的服務的副本均可以擁有一個Data Plane

後者被稱爲Sidecar循環代理，由於咱們將爲每個服務器上的服務實例提供一個Data Plane實例

這裏會有一個觀點，不論咱們每一個副本擁有一個Data Plane，仍是每一個底層虛擬機擁有一個Data Plane都是同樣的 這個觀點就是，每當有一個服務到服務的通訊，首先會將通訊轉到Data Plane，而後由Data Plane接收

這些服務再也不是直接相互通訊，而是必須經過這個不同的系統（Data Plane） 這容許咱們在Data Plane中實現額外的邏輯，也就是說服務無感知是最好的 由於全部雙向TLS、全部的可觀察性操做都是開箱即用的，團隊無須在服務中構建它們

如你所見，這些Data Plane做爲聯繫點，經過這些鏈接點咱們能夠作很任何事 包括將數據庫歸入這個系統管理中。也是由於當一個服務使用數據庫時，咱們仍然想要這個使用過程進行觀察 咱們仍但願擁有Data Plane提供的全部功能，這樣一切都將經過Data Plane進行交流

所以，咱們經過分散代理在不一樣服務中進行着大量的網絡調用

之因此被稱爲分散式，是由於不像傳統的ESB那樣，咱們沒有將代理實例中心化，而是分散到各個服務中

Kubernetes的定義

so，我剛纔提到的Sidecar代理，這會咱們應該知道它是什麼了吧。接下來，咱們回到關於Kubernetes的定義上來

Kubernetes將咱們在底層虛擬機上部署Pods的方式進行了抽象

咱們經過使用kubernetes來把咱們的虛擬機羣變得看起來就像一臺主機來使用

Kubernetes將決定這些Pods的去向

當咱們告訴kubernetes我但願這個代理是一個sidecar容器

對於這種指定服務容器的其餘pods來講 咱們告訴kubernetes我想要將這個代理部署在這些服務所在的底層虛擬機上（即每個服務所在的pod中都有一個sidecar容器）

咱們但願Sidecar代理始終部署在底層虛擬機上，由於咱們但願服務和代理之間的通訊始終在localhost上（適用於每個副本）

假設是由於在localhost中它（通訊）的成功率老是100%

由於咱們沒有離開這裏（進入到外部網絡）而是一直在虛擬機中

在這裏和那裏之間的網絡問題將由Data Plane處理 （譯者特別說明：sidecar是用於Kubernetes的，而Data Plane用於service mesh二者所處位置不一樣，請注意）

咱們將擁有該代理的一個實例，融合了咱們服務的每一個實例的Sidecar模型

如今，這增長了Data Plane中的問題，Data Plane真的要保持很小的資源利用率，而且在佔用上必須很是小

由於咱們將在咱們的系統中爲每一個服務的每一個副本都運行一個（代理） 這意味着若是代理自己消耗了許多資源，咱們將耗盡內存資源（例如在底層虛擬機中）

因此若是咱們採用的循環代理越多，咱們就要確保這個代理很是很是小，資源佔用很小

順便說一下，對於咱們本身的服務一樣如此，不能佔用太多的內存 不然，要麼咱們運行在很是大（內存）的虛擬機，要麼咱們將很快耗盡內存

所以，在資源利用方面，服務和代理都必須很是的小

這也是爲何不能將ESB放在那裏的緣由

你能夠想象爲每一個服務實例運行一個ESB實例，你的服務就甭期望工做了

如今，咱們但願這些不一樣的服務都運行在不一樣的Data Plane上，而後咱們須要儘快對這些Data Plane進行配置

當咱們的服務在進行通訊的時候，其實就是這些Data Plane在依賴咱們設定的協議證書進行交流 從總體來看，整個協議很複雜，咱們本身很難去和它們作交流（咱們須要作不少潛在準備，一不當心就容易出問題）

因此，咱們不但願經過人工的方式來將配置推送到這些不一樣的Data Plane上

這裏咱們說的就是Control Plane（控制層）了

Data Plane和Control Plane在網絡層處理這塊兒是很是很是有名的

（例如）你在數據中心運行了一堆Cisco交換機，而且你想要將你的配置推送到這些Casco交換機上

因而咱們想要一個能夠容許咱們這樣作的Control Plane

把相同的概念應用到軟件上來

咱們經過一個Control Plane把配置推到每個Data Plane中

或者是這個Control Plane可讓Data Plane從一個統一的地方獲取這個配置

但它也能夠成爲咱們收集指標（運行參數）的一種方式

如今，Data Plane正在一次性收集全部的這些流量（通訊行爲） 咱們但願有一個組件，容許咱們收集日誌、收集指標，而且仍然是在Control Plane上

Data Plane位於請求的執行路徑上

Control Plane僅用於配置，它僅用於獲取這些指標，Control Plane它永遠不會在咱們的API請求的執行路徑上

基本上，咱們的north-south gateway只是成爲了另外一種Data Plane，是另一種代理 它不是咱們的Data Plane，可是容許咱們與底層Data Plane進行通訊

由於它們都是這個Mesh中的一部分，咱們能夠在這些不一樣的Data Plane間強制實施雙向TLS，確保咱們的系統受到保護

即使沒有service mesh咱們依然能夠作這些事情，那這樣的話，咱們就不得不在本身的服務中經過構建來作這些事兒了

從技術上來說，微服務並不必定要必須經過Service mesh來作。但問題在於，若是你想擁有這些優勢，就必須本身構建它們

而且在service mesh中也不必定須要Kubernetes，但service mesh的理念可以應用於任何平臺

kubernetes 只是讓咱們更容易大規模地運行微服務，但沒有什麼能阻止咱們跨虛擬機來運行service mesh

咱們只須要在服務運行的虛擬機上部署咱們的data plane實例，這樣咱們就擁有了一個跑在虛擬機上的service mesh

事實上，咱們更想要的是service mesh可以運行在Kubernetes 中

但就像以前說的，咱們目前依舊有單體應用運行在虛擬機或遺留的平臺上

並但願它經過某種方式可以成爲serivce mesh中的一部分 因此咱們但願數據平臺不只僅是在kubernetes 中，還要運行在咱們單體應用的環境中

咱們但願這種模式（上述的單體應用）也能夠成爲service mesh的一部分

若是你想讓轉移到微服務變得更加實際，那麼平臺無關性無疑是很是重要的

就像以前說的，不一樣的服務能夠創建在不一樣的語言上，這就是微服務的優點之一

由於咱們能夠將依賴性很小和功能獨立的服務構建在data plane上，這意味着咱們不用重複的去作相同邏輯的事了

在兩種不一樣的技術編寫的兩個微服務中，data plane就屬於一個對外處理的代理，它和對應的微服務一塊兒運行在同一個虛擬機中

基於事件的架構

我再花點時間來談下基於事件的架構

當咱們討論 service mesh ，即在討論微服務時，一般會討論服務之間的通訊，但這不是實現這些系統的惟一方式

還有另外一種方式是採用基於事件的體系結構來建立它們

這意味着，咱們將在架構中傳播一個事件，用更有效的方式來處理諸如捕獲狀態之類的事情

這裏假設有兩個不一樣的微服務，一個作訂單和一個開發票

每次咱們建立訂單，再開一張發票，聽起來不錯

可是，若是一些緣由致使發票微服務變得不可用了，咱們會繼續重試直至請求超時

最終發票不會被建立成功，固然最好不要出現這種狀況

若是它真的發生了，那麼系統中狀態的傳播就會被中斷，過後須要花很大的代價去修復

所以對於上述案例用狀態進行傳播的方式，咱們能夠考慮使用事件

例如讓發票的微服務就緒以後再去處理訂單建立事件，這樣咱們的狀態就不會丟失了

這種方式的風險在於，咱們能夠用例如kafka之類的當作事件收集器，但系統中的其餘服務可能真的會發生一些異常狀況

因此但願在這些服務前面有一個data plane，由於咱們想要確保服務事件可以到達事件收集器（kafka）

因此咱們能夠採用Kafka或某種日誌收集器來處理咱們的一些用例，固然必須確保日誌收集器可用，不會發生故障

一般咱們更容易將精力用於保證一項服務的正常運行（例如日誌收集），而不是將它放在給每一個服務傳播狀態信息上

由於咱們只有一個組件的話只須要確保它能正確持續運行，相反，若是組件不少，那麼全部的組件都必須處於正常運行 咱們能夠集中精力讓運行變得更加可靠一點，使得狀態的傳播也變得更加可靠

就像我所說的企業組織架構正在轉變，而咱們的系統也逐漸往一個複雜的生命體方向靠攏，所以我很喜歡用神經系統來作比喻

咱們的身體由大腦中的CNS(中樞神經系統)和PNS(周圍神經系統)兩個不一樣組成部分組成

周圍神經系統將咱們身體可以理解的全部信息存起來，而後將它們傳遞給CNS(中樞神經系統),以便CNS(中樞神經系統)能夠處理它們

這與 control plane 和 data plane 的概念很是類似

data plane將位於咱們每一個服務，每一個單體應用的外圍，以及每一個函數式（例如lambdas）的外圍

可是相關配置，監控以及可觀察性，都將由control plane處理

Kong作了什麼

我以前說過 我是Kong的聯合創始人兼CTO， Kong提供了一個有效地開源 control plane和data plane，能夠容許在組織中進行不一樣架構的管理

在全球範圍內運行着超過一百萬的Kong實例來幫助開發者進行data plane管理 咱們給那些須要進行架構轉變的團隊提供了技術支持以幫助他們從單體架構到微服務到 Service Mesh 到Serverless的過渡

過渡到微服務是一個很複雜的課題，由於它影響了三個不一樣的方面

但更重要的是咱們必須將這個過程和咱們要達成的業務目標相結合，否則就像我說的，它只是依葫蘆畫瓢，爲了使用微服務而微服務

首先是業務轉型

咱們必須實事求是，若是沒有必要，咱們不須要立馬轉型微服務或者當即擁有數千個微服務

主要在於咱們老是有時間來將服務變得愈來愈小

所以，沒必要那麼着急，先將服務提取到中等大小，而後隨着時間的推移使其變得更小

事實上，我想說只有當服務須要變得更小的時候，那麼咱們才能將它變得更小。這纔是最好的過渡方式

由於它既能夠提升咱們的生產力，也加強了咱們的業務

經過採起使用技術的方式，使咱們可以向這些新架構微服務過渡

但也可經過一個很是務實的方式鏈接如今正在提供業務服務的老應用程序（程序待重構）

那些仍然是最關鍵的組件，將它們與咱們新的greenfield （新開發的）微服物架構鏈接起來，這將成咱們系統的將來

因此這須要在新舊之間創建聯繫

感謝你們的傾聽

提問

因此大家還有其餘問題嗎？

提問部分：就好比說又一個單體應用，按照演講者以前講的意思將服務逐步解耦使之變得愈來愈小 Amazon就表示對他們來講這樣作就會代價很大，因而他們就中途放棄 直接從新開始，直接開始全面微服務（拋棄原有的系統），對此你有什麼見解

就像我說的，這其實也是一種選擇。只要企業/開發團隊已經準備好能作全面微服務化的準備 同時也有着清晰的思路，那麼這種過渡到微服務的方案也是可取的

在採用那個方案的時候，咱們必須分析利弊。固然，Amazon經過分析他們的利弊 若是選擇從新打造而不是從單體應用慢慢過渡到微服務，這種狀況下，利遠大於弊

在我看來，它仍然是一個不多有公司可以成功過渡到微服務的策略

固然這些事情咱們也須要歸入考慮

提問部分大體意思：微服務間存在着大量的調用 然而咱們經過Data Plane進行網絡通訊的延遲遠高於服務與服務之間的本地調用，有沒有什麼下降延遲的辦法？

系統能夠爲咱們提供指標，用以瞭解延遲瓶頸的正確位置 因此若是咱們須要經過網絡，咱們將獲得比經過本地函數調用更多的延遲，這是可行的

實際上，若是代理沒有正確創建，這個網絡處理就會增長更多的延遲

由於你知道的雙向TLS 以及可觀測性操做都會在咱們的處理過程當中增長延遲

因此咱們能夠作的就是在Data Plane層緩存一些信息，這樣請求可能就不須要進入到外部網絡中，因此我想到的是 在這些不一樣的服務間組織實現某種意義上的全局緩存，假設這的方式是可行的，由於對於某些用例（場景）咱們是沒法實現（緩存）的

而對於其餘人而言，他們徹底接受了最終一致架構的概念，延遲只是它的一部分

而且客戶端就是這樣創建起來的，他們考慮到了這一點，因此一切最終都是一致的，會有一點延遲 咱們將在客戶端看到信息，它不必定是最新的，但它最終會保持一致

在考慮延遲問題的時候，Service mesh可以經過一系列方法來幫助咱們定位延遲問題，這不只僅只是網絡延遲，一樣也多是服務延遲

咱們爲了可以肯定是否必須對那些已經對其餘服務產生性能瓶頸的服務進行升級，因此須要一種觀察的機制 這樣在實際使用中，這也能讓咱們實現一些緩存方法去提升咱們架構的性能

固然，由於咱們是基於網絡去請求，因此咱們應該從實際出發 去分辨哪些延遲是正常的，哪些是不正常的。若是不正常 那麼咱們就必須確保系統的最終一致性，並以此爲前提，咱們來構建咱們的客戶端