Serverless?時代下大規(guī)模微服務應用運維的最佳實踐
時間：2021-10-08 17:01:11
手機看文章
掃描二維碼
隨時隨地手機看文章
[導讀]微服務架構的優(yōu)點和痛點Aliware1微服務架構的誕生背景回到互聯(lián)網早期時代，也就是web1.0時代，當時主要是一些門戶網站，單體應用是當時的主流應用，研發(fā)團隊相對較小，這時候的挑戰(zhàn)在于技術的復雜度，以及技術人員的匱乏。到了新世紀互聯(lián)網時代，出現(xiàn)了較大規(guī)模的一些應用，比如社交、電...
微服務架構的優(yōu)點和痛點
Aliware
1
微服務架構的誕生背景
回到互聯(lián)網早期時代，也就是web1.0時代，當時主要是一些門戶網站，單體應用是當時的主流應用，研發(fā)團隊相對較小，這時候的挑戰(zhàn)在于技術的復雜度，以及技術人員的匱乏。
到了新世紀互聯(lián)網時代，出現(xiàn)了較大規(guī)模的一些應用，比如社交、電商等，流量和業(yè)務的復雜度也大幅增加，出現(xiàn)了幾百甚至上千人的研發(fā)團隊，研發(fā)團隊擴大之后，協(xié)作問題成為困擾。SOA 解決方案是互聯(lián)網的產物，其核心在于分布式、拆分等。但是因為 ESB 這樣一些單點的組件，所以沒有得到很好的推廣。阿里巴巴在當時推出的 HSF、開源的Dubbo 等技術，其實是類似于分布式的一個解決方案，當時就已經有了微服務架構的理念。
微服務架構正式名稱的誕生是在移動互聯(lián)網時代，這時的生活已經實現(xiàn)全面互聯(lián)網化，各種各樣的生活類 APP 涌現(xiàn)，網民以及流量復雜度相對于新世紀互聯(lián)網時代顯著增強。另外，較大規(guī)模的研發(fā)團隊也已成為主流。這時候，大家普遍都對效率有了更高的追求，而不只是原來只有幾個巨頭需要有這方面的技術。微服務架構以及微服務技術的推出，如 Spring ?Cloud、Dubbo 等框架的普及，極大地推廣了微服務技術。
現(xiàn)在我們已經進入全面的數(shù)字化時代，社會全面互聯(lián)網化，各種各樣的單位（包括政企、相對傳統(tǒng)的單位）都需要較強的研發(fā)能力。流量的挑戰(zhàn)及傳統(tǒng)業(yè)務復雜度的挑戰(zhàn)、研發(fā)團隊的擴大等，使得大家對效率有了更高的要求。這時候微服務架構得到了進一步的推廣和普及。
微服務架構經過這么多年的發(fā)展，是經久不衰的一項技術，為什么它能夠有這樣持續(xù)的發(fā)展？
2
微服務架構的優(yōu)點
我們來回顧一下微服務架構和單體架構的區(qū)別，以及微服務架構的核心優(yōu)勢。
單體架構核心的問題在于沖突域太大，包括共享代碼庫。在研發(fā)過程中特別容易沖突；邊界和模塊的規(guī)模不清，使得團隊效率也會降低。
而在微服務架構下，核心就在于拆分，包括解耦的研發(fā)態(tài)，解耦的部署態(tài)，極大地釋放了團隊的研發(fā)效率。大道至簡，這也是微服務架構為什么能夠持續(xù)發(fā)展的一個原因。
根據(jù)復雜性守恒定律，我們解決了一個問題，問題會以另一種形式出現(xiàn)，我們又需要去解決?？梢钥吹?，微服務時代下會引入非常多的一些痛點，核心就是穩(wěn)定性。因為從原來的一些本地調用改成遠程調用以后，可能會發(fā)生穩(wěn)定性的點激增，包括調度放大，即可能因為底層的一些遠程調用問題，造成上層的一些不穩(wěn)定，以及期間需要做的限流降級、調用鏈等。
在微服務時代定位一個問題的復雜度，也會成指數(shù)級的一個增長，這里面可能還需要服務治理。另外如果沒有較好的設計和預先的一些設想，可能會出現(xiàn)微服務應用的爆炸，包括研發(fā)人員和測試人員之間的協(xié)作也都會成問題。
微服務技術經過這么多年的發(fā)展，業(yè)界其實已經有了一些解決方案。
如上圖顯示，如果要比較好地玩轉微服務技術，除了開發(fā)自己的業(yè)務系統(tǒng)以外，可能還要配套地搭建多個系統(tǒng)，包括CI/CD、發(fā)布系統(tǒng)、研發(fā)流程、微服務組件相關的一些工具，以及可觀測性相關的實時監(jiān)控、告警系統(tǒng)、服務治理、調用鏈等等，還需要運維基礎的 IaaS 資源。在這個時代，為了更好地運維 IaaS 資源，可能還需要自己維護一個K8s 集群。
所以說，在這樣的背景下，很多企業(yè)會選擇搭建一個運維團隊，或者中間件團隊，或者說由一些后端研發(fā)同學兼職。但是試想，有多少企業(yè)對自己內部搭建的這套系統(tǒng)是滿意的？系統(tǒng)的迭代效率是多少，有沒有踩到過一些開源的坑，這些坑現(xiàn)在有沒有解決？這些應該是在企業(yè)的CTO、架構師心中一個持續(xù)的痛點。
Serverless時代下的解決方案
Aliware
1
Serverless時代
Serverless 從2012年第一次提出，到 2014年 推出了 Lambda 這樣一個引爆性的產品后，短暫地達到了一個影響力的頂峰。但是這樣一個新生事物，突然到真實的、復雜的生產環(huán)境中，其實有許多不適應，包括需要改善的地方，所以后續(xù)幾年它可能要進入一個低谷。
但是，Serverless 的“將簡單交給用戶，復雜留給平臺”的理念，其實是非常正確的一個方向。所以在開源界包括業(yè)界，其實都在持續(xù)性地進行 Serverless 方面的一些探索和發(fā)展。
阿里云在2017年推出了函數(shù)計算（Function Compute，F(xiàn)C），在2018年推出了Serverless應用引擎 SAE，在 2019年以及后續(xù)的這些年，阿里云持續(xù)地在 Serverless 領域進行投入，支持了包括鏡像部署、預留實力、微服務場景等。
2
Serverless 市場概況
在2021年最新的 Forrester 評測中，阿里云 Serverless 產品能力是中國第一、全球領先，阿里云的 Serverless 用戶占比也是中國第一。這側面說明了阿里云 Serverless 是已經越來越多地進入到企業(yè)真實的生產環(huán)境中，越來越多的企業(yè)認可 Serverless 以及阿里云 Serverless 的能力和價值。
3
SAE解決方案
可以看到，在傳統(tǒng)的微服務架構下面，企業(yè)要用好微服務相關的技術需要自己研發(fā)非常多的解決方案，那么在 Serverless 時代下，在 SAE 這個產品里面是怎么解決的？
我們可以看到，SAE 將 Serverless 這個理念發(fā)揚到了極致，不僅僅托管了 IaaS 資源，包括上層的 K8s，另外還集成了白屏化的 PaaS 以及企業(yè)級微服務相關的套件和可觀測相關的套件。在 SAE 整體解決方案里面，針對這些都進行了很好的集成，給用戶提供了一個開箱即用的微服務解決方案，讓企業(yè)和開發(fā)者能夠很簡單地使用微服務。
1、0 門檻 PaaS
圖中可以看到，SAE 在最上層給用戶提供的是一個白屏化的操作系統(tǒng)，它的設計理念非常符合企業(yè)一般的 PaaS 系統(tǒng)，包括發(fā)布系統(tǒng)或者一些開源的 PaaS 系統(tǒng)，這樣極大地降低了企業(yè)上手 SAE 的門檻，甚至可以說零門檻，包括它也集成了阿里巴巴最佳的一些發(fā)布，即發(fā)布三板斧——可觀測、可灰度、可回滾。
另外它也提供了一些企業(yè)級能力的增強，包括命名空間環(huán)境隔離、細粒度的權限控制等等。從圖中可以看到，在一個企業(yè)里面，如果有兩個相互比較獨立的模塊，完全可以通過命名空間進程進行隔離。
2、微服務治理增強
在微服務治理增強方面，特別是在 Java 語言，SAE 采用了一個 agent，對用戶來說相當于是無侵入、無感知、零升級，而且 agent 的全面兼容開源，使用戶幾乎在無修改的情況下，就可以使用無損下限、API 管理、限流降級、鏈路追蹤等等能力。
3、前后端全鏈路灰度
這里展開兩個能力，第一個能力是前后端全鏈路灰度。SAE 借助前面提到的 agent 技術，從 web請求到網關到 consumer 到 provide 進行了一個全鏈路的打通，使用戶可以通過很簡單的白屏化配置，就可以實現(xiàn)一個灰度發(fā)布場景。而這樣的技術如果企業(yè)需要自建，這里面的復雜度大家應該是非常清楚的。
4、CloudToolkit 端云聯(lián)調
第二個能力就是 CloudToolkit 的端云聯(lián)調。大家都知道微服務的場景下面應用數(shù)量是呈現(xiàn)一個爆炸的趨勢，如果本地需要開發(fā)，需要啟動那么多的應用，如何能夠安全便捷地聯(lián)調云上的一個服務？現(xiàn)在借助 CloudToolkit，用戶可以很簡單地在本地就打通云上的環(huán)境，進行一個端云聯(lián)調，極大地降低開發(fā)測試的門檻。
5、強大的應用監(jiān)控
下載文檔
