建站
咨詢
售后
建站咨詢
新聞中心
一、從一個典型的案例談起
1.微服務開發(fā)不簡單
隨著微服務技術的發(fā)展，微服務(MicroServices) 的概念早已深入人心，越來越多的公司開始使?微服務架構來開發(fā)業(yè)務應用。
創(chuàng)新互聯(lián)建站是一家專業(yè)提供哈巴河企業(yè)網(wǎng)站建設,專注與做網(wǎng)站、網(wǎng)站制作、H5高端網(wǎng)站建設、小程序制作等業(yè)務。10年已為哈巴河眾多企業(yè)、政府機構等服務。創(chuàng)新互聯(lián)專業(yè)網(wǎng)站建設公司優(yōu)惠進行中。
如果采?得當，微服務架構可以帶來?常?的優(yōu)勢。微服務架構的最大的好處是它可以提升開發(fā)效率和系統(tǒng)整體的穩(wěn)定性：
- 開發(fā)和部署相對簡單：單個微服務的功能可以更快地更改，因為可以獨立部署，影響范圍更小，啟動和調(diào)試單個微服務的時間成本相比于單體應用也大大減少。
- 橫向擴展簡單：根據(jù)業(yè)務的高峰低谷周期快速的橫向擴展非常簡單，因為單個微服務通常很小，可以隨著系統(tǒng)整體負載的變化更快地啟動和停止。
- 架構升級靈活：單個微服務的內(nèi)部架構可以迅速升級，因為微服務之間是松散耦合的，只面向定義好的通訊接口進行編程。這使開發(fā)團隊能夠基于自身的技術背景和偏好靈活選擇，而不會直接影響其他應用程序、服務或團隊。
- 更好的容錯性：微服務之間可以實現(xiàn)更好的故障隔離，單個服務內(nèi)的內(nèi)存泄露等故障不容易影響其他服務，相比單體應用?個組件故障會拖垮整個系統(tǒng)。
但是微服務在實施過程中，也很容易遇到一些難點。如果微服務治理得不恰當，反而有可能適得其反，不僅不能享受到微服務架構帶來的好處，反而會因為微服務帶來的系統(tǒng)復雜性，造成開發(fā)、運維部署的復雜度增加，進而影響開發(fā)迭代的速度，甚至影響系統(tǒng)的整體穩(wěn)定性。
我們總結(jié)了?些微服務開發(fā)實施過程中常見的問題：
- 服務之間使用遠程調(diào)用進行通訊，這比進程內(nèi)的直接調(diào)用復雜很多。由于通訊鏈路的復雜性，可能會出現(xiàn)很多不確定的問題，會出現(xiàn)遠程調(diào)用不可用或者延遲較高的情況，開發(fā)?員需要能夠處理這些偶發(fā)問題，避免影響業(yè)務。
- 隨著業(yè)務的發(fā)展，微服務之間的拓撲圖開始變得復雜，排查問題變得困難，搭建完整的開發(fā)測試環(huán)境成本也越來越大。
- 當功能涉及到多個微服務模塊時，迭代時需要謹慎地協(xié)調(diào)多個開發(fā)團隊的迭代排期，才能保證迭代能夠按時交付，達到敏捷開發(fā)的效果。
2.?個微服務成功落地的典型案例
觀察了阿里云眾多客戶之后，我們總結(jié)了?個微服務成功落地的典型案例，某公司借助于微服務架構的紅利，實現(xiàn)了業(yè)務快速增長：主要會分析在業(yè)務發(fā)展的不同階段，該公司在微服務實施過程遇到的問題，以及如何通過微服務治理來解決這些問題，從而享受到了微服務帶來的開發(fā)效率和業(yè)務穩(wěn)定性提升的紅利，進而促進業(yè)務快速發(fā)展。
（1）業(yè)務孵化期
初創(chuàng)公司在剛起步時，雖然業(yè)務量比較小、業(yè)務模式比較簡單，但是為了在后續(xù)的快速發(fā)展中能夠快速迭代，同時公司的人才儲備也滿足微服務開發(fā)的條件，于是在初創(chuàng)期就選擇了使用微服務架構進行業(yè)務開發(fā)。
在技術選型方面，如果公司創(chuàng)始員工是技術出身，那么會比較傾向于使用自己擅長的微服務框架，如創(chuàng)始人是 Dubbo 的 contributor ，或者是 Spring Cloud 社區(qū)的大咖或者 Spring Cloud Alibaba 的contributor，又或者是 Service Mesh 社區(qū)的大咖，?般都會選用自己所擅長的微服務框架類型。還有一種選擇是選用市面上最流行的微服務框架，如 Java 體系，會選擇 Spring Cloud 和 Dubbo。在目前的招聘市場上也容易招聘到熟悉相關領域的人，從初學者到專家級的候選人都能很容易招聘到。
選定了技術選型后，基于開源的框架，很容易就能開發(fā)好最初的業(yè)務應用系統(tǒng)，跑通業(yè)務流程。這?階段組件也很簡單。簡單的兩三個應用，用戶系統(tǒng)、業(yè)務系統(tǒng)、支持系統(tǒng)，再加上注冊中心、數(shù)據(jù)庫、緩存，就可以開發(fā)完全部的應用。
對于一個生產(chǎn)級別的系統(tǒng)來說，在將整套系統(tǒng)部署上線之前，還需要建設監(jiān)控報警系統(tǒng)。監(jiān)控報警系統(tǒng)能夠幫助我們實時監(jiān)控機器和應用的狀態(tài)。我們可以配置預設的報警規(guī)則，在出現(xiàn)機器資源不足，業(yè)務出現(xiàn)異常報錯時這些情況時主動報警，提醒我們盡快處理系統(tǒng)中的風險和異常。保留問題的現(xiàn)場，并幫助我們快速地定位和排查問題也同樣重要，阿里云應用實時監(jiān)控服務 ARMS 和日志服務 SLS 能夠在這些場景提供很大的幫助。
采用 ARMS + SLS 完成監(jiān)控報警系統(tǒng)建設之后，將業(yè)務系統(tǒng)部署上線，完成第一次成功上線，業(yè)務開始正常運行起來了。
但是業(yè)務的開發(fā)和運營從來都不是?帆風順的，在這個過程中，肯定也會遇到很多問題，我們先總結(jié)?下這個階段常見的問題及應對方案：
1） 因為代碼本身邏輯出錯導致業(yè)務異常：這時可以通過 SLS 查詢?nèi)罩?，結(jié)合 ARMS 分析錯誤堆棧找到根因，修改完代碼后，重新發(fā)布來修復問題。
2） 遇到性能瓶頸：則直接擴容操作，如水平擴容應用，或者升級數(shù)據(jù)庫。
3） 發(fā)布新版本影響到用戶：因為用戶數(shù)和請求數(shù)都不算多，很容易就可以找到業(yè)務低峰期，在業(yè)務低峰期進行發(fā)布。
4）如何確保新版本的正確性：因為業(yè)務場景不復雜，內(nèi)部測試就能覆蓋所有的場景，測試通過就可以直接上線。那如何識別自身的業(yè)務是否處于這個階段呢?有?系列典型的特征：應用不超過 4 個，應用節(jié)點總數(shù)不超過 10 個，最高峰時候的 QPS 不超過 10。
（2）業(yè)務快速發(fā)展期
度過初創(chuàng)期之后，公司的業(yè)務很受用戶和市場的歡迎，注冊的用戶越來越多，用戶使用的時長和功能點也越來越多，日活數(shù)越來越大，甚至市場中還出現(xiàn)了其他競爭者開始抄襲公司的業(yè)務，一些巨頭還親自下場參與競爭。公司業(yè)務發(fā)展得非常順利，這也意味著系統(tǒng)進入了快速發(fā)展時期。
市場發(fā)展很迅速，注冊用戶數(shù)、日活這些數(shù)據(jù)也是節(jié)節(jié)攀升，所有統(tǒng)計報表的數(shù)字都是一片向好。但是帶來的挑戰(zhàn)也越來越大，這個時期也是最危險的時期：在業(yè)務快速發(fā)展中，既要保證好已有業(yè)務的穩(wěn)定性，又要快速地迭代新功能，還要克服團隊招聘節(jié)奏跟不上業(yè)務發(fā)展的問題。
這個階段典型的特征是應用個數(shù)在 5 到 50 個，QPS 在 10 到 1000。這個時期經(jīng)常會遇到的問題概括起來就是兩個：穩(wěn)定性問題和開發(fā)效率問題。
穩(wěn)定性的問題：用戶數(shù)多起來之后，系統(tǒng)的穩(wěn)定性就顯得比較重要，無論是用戶在某段時間遇到異常報錯增多，還是某?個功能點持續(xù)性地報錯，再大到系統(tǒng)有?段時間完全不可用，這些都會影響產(chǎn)品在用戶中的口碑，最后這種完全不可用的場景，甚至還可能成為微博等社交網(wǎng)絡上的輿論熱點。
開發(fā)效率的問題：隨著用戶的增多，相應的需求也越來越多，業(yè)務場景也越來越復雜，在這個時候測試可不是內(nèi)部測試就能覆蓋所有的場景，需要加大在測試上的投入。雖然功能需求越來越多，但是迭代的速度卻要求越來越快，因為市場中已經(jīng)出現(xiàn)了競爭者，如果他們抄得快，新功能也上得快，業(yè)務有可能會競爭不過，特別是當巨頭親自下場的時候，更需要跑得更快，開發(fā)節(jié)奏要快，測試節(jié)奏要快，發(fā)版節(jié)奏也要快。
那么如何去解決這兩個場景的痛點呢，這時候可以要借助微服務治理的能力來解決。
1）開發(fā)測試提效
a.【開發(fā)環(huán)境隔離】傳統(tǒng)的多套開發(fā)環(huán)境，需要使用多套的物理環(huán)境，才能實現(xiàn)多套環(huán)境各自獨立互不干擾，但是多套物理環(huán)境的隔離的機器成本是很高的，基本上不?能接受。但通過全鏈路灰度這種邏輯隔離的方式實現(xiàn)開發(fā)環(huán)境隔離，可以在不增加成本的情況下增加多套開發(fā)測試環(huán)境，助你實現(xiàn)敏捷開發(fā)。
b.【自動化回歸測試】自動化回歸測試功能，可以將多個測試用例串聯(lián)成測試用例集，將上?條測試的返回值作為下?跳測試入?yún)ⅲ?lián)成具體的業(yè)務場景并沉淀到自動化回歸測試中，在每?次的發(fā)版之前都跑?次自動化回歸來驗證功能的正確性，這樣就可以大大節(jié)省測試的人力成本。更進?步，還可以通過流量錄制回放功能，將線上的真實流量錄制下來，并沉淀成自動化回歸用例集，在測試環(huán)境進行流量回放，更進?步地提升測試 case 的覆蓋率。
c.【服務契約】功能越來越多，迭代越來越快，API 越來越復雜，團隊之間溝通的效率越來越低，API 文檔嚴重過期。如果自動生成服務契約，可以有效地避免文檔腐化造成的開發(fā)效率低下的問題。
使用上面三點之后，可以在低成本的條件下支持多套開發(fā)測試環(huán)境，實現(xiàn)自動化回歸測試，實現(xiàn)開發(fā)節(jié)奏和測試節(jié)奏的大大提效。
2）安全發(fā)布
a.【無損下線】無損下線問題的根本原因是開源的微服務體系沒有確保應用提供者節(jié)點在停止服務前確保已經(jīng)通知到所有消費者不再調(diào)用自己，也無法確保在處理完所有請求之后再停?應用。所以新發(fā)版的應用，即使業(yè)務代碼沒有任何問題，也可能在發(fā)布過程影響用戶的體驗。
b.【無損上線】無損上線問題出現(xiàn)的原因是因為在某些場景下服務提供者，需要經(jīng)過?段時間才能正常地接收大流量的請求并成功返回。同時在 K8s 場景下，還需要和 K8s 中的 readiness 、滾動發(fā)布等?命周期緊密結(jié)合，才能確保應用發(fā)布過程中能不出現(xiàn)業(yè)務報錯。
c.【全鏈路灰度】新功能上線之后，可以通過灰度規(guī)則控制哪些?戶可以使用。這樣可以先選擇讓內(nèi)部用戶使用，測試新功能的正確性。當內(nèi)部用戶驗證通過后，再漸漸地擴大灰度范圍，確保每個功能都經(jīng)過充分驗證后再全量開放給客戶，屏蔽掉發(fā)布新功能的風險。而且當出現(xiàn)問題時，可以通過修改灰度規(guī)則來實現(xiàn)快速回滾，做到新版本發(fā)版時幾乎無風險。
使用以上幾點之后，可以確保新版本的發(fā)布不出問題，而且可以做到白天在大流量場景下也輕松發(fā)布，在實現(xiàn)白天輕松發(fā)布之后，?天就可以發(fā)布多次，提升發(fā)布時候的穩(wěn)定性和發(fā)版的效率。
3）屏蔽偶發(fā)異常導致的風險
a.【離群實例摘除】對于這些偶發(fā)的異常問題，離群摘除功能可以智能判斷應用中的服務提供者某個出現(xiàn)了問題，智能地在?段時間內(nèi)屏蔽掉這個服務提供者，保證業(yè)務的正常，等這個服務提供者恢復過來之后再進行調(diào)用?？梢栽趹霉?jié)點出現(xiàn)偶發(fā)異常時，智能屏蔽掉此節(jié)點，以免影響業(yè)務，等此節(jié)點恢復后再繼續(xù)提供服務，從而屏蔽偶發(fā)異常導致的風險。
據(jù)統(tǒng)計數(shù)據(jù)顯示，有將近 90% 的線上故障是由于發(fā)版過程中出現(xiàn)的，剩下的 10% 左右的線上問題，可能是由于?些偶然的原因?qū)е碌?。如偶然的網(wǎng)絡故障、機器 I/O 出現(xiàn)問題、或者是某臺機器負載過高等。在解決了發(fā)布時候的穩(wěn)定性問題和偶發(fā)異常導致的風險后，基本能夠確保線上業(yè)務不會出現(xiàn)災難性的問題。
在業(yè)務快速發(fā)展的生死存亡期，需要借助于這些微服務治理能力，確保業(yè)務能夠又快又穩(wěn)地增長，度過這段生死存亡期，成為這個領域的重要玩家。
（3）業(yè)務成熟期
當業(yè)務進入成熟期之后，業(yè)務的開發(fā)進入了新的階段，這時候，雖然快速發(fā)展過程中的問題仍舊存在，但是會因為業(yè)務量上來之后，遇到新的問題。
低成本創(chuàng)新：雖然發(fā)展不像原來那么迅速，但是業(yè)務創(chuàng)新探索的訴求仍舊存在，由于業(yè)務規(guī)模的擴大，創(chuàng)新的成本也在增加。這個時候不僅是需要快速開發(fā)迭代，更大的需求是用盡可能小的成本進行創(chuàng)新探索測試，有時候還需要使用上 AB 測試的手段進行實驗比較。
容災多活：由于業(yè)務規(guī)模已經(jīng)很大了，治理中的穩(wěn)定性的訴求更加強烈，而且隨著業(yè)務范圍的擴大，應?也開始在多個地域、多個云產(chǎn)品中進行部署。同城容災、異地多活這類需求也開始出現(xiàn)。
問題定位：出現(xiàn)任何問題都必須徹查。雖然出現(xiàn)問題時，業(yè)務恢復仍舊排查第?位，但是業(yè)務恢復之后的問題根因定位也是不能少的，因為如果不徹查，難免后續(xù)出現(xiàn)同樣的問題。
風險預案：緊急預案、風險預防也變得非常重要，需要提前做好業(yè)務的保護和降級的埋點演練，在遇到絕大多數(shù)可預見問題可以緊急修復，出現(xiàn)不可控問題時，可以通過預案手段執(zhí)行預案，確保整體業(yè)務的可控性。
從這個典型的案例中，我們可以看到，微服務的成功落地和業(yè)務的快速發(fā)展，離不開微服務治理的支持。在業(yè)務發(fā)展的不同階段，會遇到不同的微服務問題，需要借助于治理的能力，為業(yè)務的又快又穩(wěn)發(fā)展保駕護航。
二、微服務治理在云原生場景下的挑戰(zhàn)
1.企業(yè)上云的四個階段
隨著云原生時代的到來，越來越多的應用生在云上，長在云上，且隨著越來越多的企業(yè)開始上云，云原生也是企業(yè)落地微服務的最佳伴侶。我們分析了阿里云典型客戶的實踐經(jīng)歷，業(yè)務上云通常劃分為 4 個階段：云上部署、云原生部署、微服務化、服務治理。
（1）云上部署
這?階段我們解決的問題，如何把傳統(tǒng)業(yè)務，原來是跑在自建 IDC 機房的業(yè)務，能夠原封不動地遷移到云上。通常云廠商提供了豐富的計算、存儲、網(wǎng)絡等資源可供選擇，以虛擬化技術，神龍裸金屬服務為代表的硬件可以滿足企業(yè)客戶上云搬遷的豐富需求，這?階段關注的焦點是資源，對于業(yè)務并無任何的改造，只需要從本地原樣搬遷到云上即可。
（2）云原生部署
云原生是釋放云計算價值的最短路徑，以容器技術為代表，云原生提供了強大的調(diào)度、彈性等能力，極大地降低了上云的成本。這?階段我們關注的目標主要是業(yè)務進行云原生化改造，隨著 Kubernetes 作為容器編排市場的事實標準，我們需要把業(yè)務從原來的的虛擬機部署方式改造成容器化方式，部署并運行在 K8s 之上，最大限度享受到云原生帶來的技術紅利。這?階段核心關注目標以容器為核心。
（3）微服務化
當我們的業(yè)務規(guī)模逐步擴大，傳統(tǒng)單體應用很難進?步支撐業(yè)務的發(fā)展，業(yè)務的迭代速度已經(jīng)無法滿足業(yè)務的增長，此時我們就需要進行微服務化的改造，降低業(yè)務的耦合度，提升開發(fā)迭代的效率，讓開發(fā)更加敏捷。這?階段我們聚焦以應用為核心。
（4）服務治理
當微服務的規(guī)模也越來越大的時候，如果對微服務不加以規(guī)范和整治，很容易出現(xiàn)問題。例如，每個微服務都有獨立的團隊來維護，他們之間如果依賴沒有整理清楚，可能會出現(xiàn)架構上循環(huán)依賴等問題。從我們的數(shù)據(jù)觀察來看，當微服務的節(jié)點數(shù)超過數(shù)十個的情況下，我們通常就需要引入服務治理，通常需要關注的是開發(fā)、測試、線上運維，安全等多方面考慮，這?階段我們聚焦以業(yè)務為核心，核心目標是進?步提高開發(fā)效率，提高線上業(yè)務的穩(wěn)定性。
2.微服務治理在云原生下的挑戰(zhàn)
隨著企業(yè)微服務化進程的逐深入，微服務的云原生化逐步進?深水區(qū)，在這個微服務深化的過程中，我們逐步會面臨?系列的挑戰(zhàn)，總的而言，我們將這些挑戰(zhàn)分為三個大的層面，分別是效率、穩(wěn)定和成本。我們進行微服務化，本身的使命是讓業(yè)務的迭代更加高效，但當我們的微服務數(shù)量逐步增多，鏈路越來越長，如果不進行進?步的治理，那么引發(fā)的效率問題可能會大于微服務架構本身帶來的架構紅利。在微服務實施的不同階段，遇到的問題也不盡相同。目前阿里巴巴內(nèi)部的微服務節(jié)點數(shù)量是在百萬級別，在這個過程我們也積累了非常多的治理經(jīng)驗。
（1）在效率上面臨的挑戰(zhàn)
在效率方面需要追求的目標是，在開發(fā)、線上運維、SDK 升級等方面更加高效。
- 在開發(fā)階段，我們需要考慮的是，業(yè)務應用上云之后，如何讓本地開發(fā)的應用，很好的部署云上的業(yè)務進行聯(lián)調(diào)?通常我們的微服務不可能在本地完整的部署?整套系統(tǒng)，所以本地開發(fā)的應用只是整個微服務鏈路的?小部分，這包括我們的流量需要能夠輕松的從云上，引導到本地，便于我們做開發(fā)調(diào)試，或者我們在本地能夠很方便的調(diào)用云上部署的微服務進行聯(lián)調(diào)。這在微服務上云之后，比原來在自身機房進行開發(fā)聯(lián)調(diào)更加困難。
- 在線上運維方面，我們通常需要頻繁的對微服務進行變更，這些變更通常就會引發(fā)?系列的問題，例如在白天高峰期做發(fā)布，通常都會導致業(yè)務流量出現(xiàn)損失，我們的研發(fā)人員不得不選擇在晚上業(yè)務低峰期做變更，這大大降低了研發(fā)人員的幸福指數(shù)，因為他們不得不面臨熬夜加班的困境。如果能在白天大流量高峰期也能進行流量無損的變更，那么這對于研發(fā)?員來說將是大大提升研發(fā)效率的事情。
- 微服務框架通常會引入服務治理的邏輯，而這些邏輯通常會以 SDK 的方式被業(yè)務代碼所依賴，而這些邏輯的變更和升級，都需要每?個微服務業(yè)務通過修改代碼的方式來實現(xiàn)，這樣的變更造成了非常大的升級成本。以阿里巴巴為例，阿里內(nèi)部?個中間件 SDK 的升級，如果要在整個集團鋪開，通常需要消耗的時間以年為單位進行統(tǒng)計，這里面也會消耗每個微服務應用的研發(fā)、測試等龐大的資源，效率非常低下，如果能夠以無侵入的方式實現(xiàn)中間件 SDK 的升級，那么將會是?件非常高效的事情。
- 進入云原生體系之后，以 K8s 為主的云原生體系強調(diào)集群之間的靈活調(diào)度型，以 POD 為單位任意的調(diào)度資源，在被調(diào)度后 POD 的 IP 也將相應地發(fā)?變化，傳統(tǒng)的服務治理體系，通常以 IP 為維度進行治理策略的配置，例如黑白名單策略等，但是當進入云原生場景后，這些傳統(tǒng)的治理策略都會面臨失效的問題，因為 POD ?旦被重新調(diào)度，原來的治理策略都將不再使用，如何能讓服務治理體系更加適應云原生體系，也是我們要面臨的?大挑戰(zhàn)。
（2）在穩(wěn)定上面臨的挑戰(zhàn)
穩(wěn)定大于?切，在微服務上云之后，業(yè)務高可用是我們必須要解決的問題，因此通常會在同?個地域的多個可用區(qū)內(nèi)進行部署，在多可用區(qū)部署的情況下，跨可用區(qū)的延時就是不可忽視的問題，我們需要思考的是業(yè)務流量需要能夠盡量在同?個可用區(qū)內(nèi)進?流轉(zhuǎn)，同時也需要考慮的是如果?個可?區(qū)出現(xiàn)問題，業(yè)務流量能夠盡可能快的流轉(zhuǎn)到正常的可用區(qū)，這就對我們的微服務框架的路由能力提出了挑戰(zhàn)。
當然，我們的業(yè)務不僅需要在同?個地域里保證高可用，也需要考慮?個地域出問題的時候，保證業(yè)務的高可用，這時我們就需要考慮業(yè)務實現(xiàn)同城雙活，甚至是異地多活，這對我們來說也是一大挑戰(zhàn)。
第三，微服務之間的調(diào)用也需要更加的安全可信，近期層出不窮的安全漏洞，?定程度上也反映出當前上云階段在安全方便暴露出的問題還是非常多，每次安全漏洞出現(xiàn)之后，中間件 SDK 的升級也是困擾業(yè)務多年的問題;同時，?些敏感的數(shù)據(jù)，即使在數(shù)據(jù)庫層做了非常多的權限管控，由于微服務被授予了數(shù)據(jù)訪問的較高權限，如果微服務的調(diào)用被惡意攻擊，也可能會造成敏感數(shù)據(jù)的泄露。微服務之間的調(diào)用需要更加可靠可信。
（3）在成本上面臨的挑戰(zhàn)
首先，在成本方面，業(yè)務上云遇到的最?問題就是如果最低成本的把業(yè)務遷移上云，對于?個在線業(yè)務，如果要進行停機遷移，那么遷移的成本會顯得非常高，對于客戶的體驗也會收到影響，要在不中斷業(yè)務的情況下，實現(xiàn)平滑遷移上云，還是有非常大的挑戰(zhàn)的。
其次，當我們在業(yè)務面臨極速增長的流量時，迫切的需要快速的彈性，補充更多的資源以承載業(yè)務的高峰，當我們進入業(yè)務低峰的時候，又希望能夠縮小容量，節(jié)省資源，因此云產(chǎn)品提供的快速靈活的彈性機制，是微服務上云之后?項急需的能力。
本文標題：從一個微服務應用的成功落地，談企業(yè)需要什么樣的微服務治理
轉(zhuǎn)載來源：http://www.5511xx.com/article/cohscdi.html
