去年，微服務(wù)架構(gòu)領(lǐng)域發(fā)生了幾個引人注目的事件。首先，才剛剛接管Twitter的Elon Musk對該平臺的開發(fā)團隊進行了一番“批評”。他對Twitter在許多國家的運行速度緩慢表示抱歉。造成這種情況的原因是應(yīng)用程序需要執(zhí)行超過1000個“糟糕”的批處理RPC，而這僅僅是為了渲染主頁的時間線。Musk表示：“今天我們將關(guān)閉那些龐大的‘微服務(wù)’，事實上，Twitter只需要其中不到20%的微服務(wù)來運行?！?br>

其次，GitHub前CTO Jason Warner在社交媒體上表示：“我相信，在過去十年里，全面采用微服務(wù)是最大的架構(gòu)錯誤之一?！?“任何有經(jīng)驗構(gòu)建大型分布式系統(tǒng)的人都知道它們并不真正起作用，但還是得去適應(yīng)它?！蹦敲?，微服務(wù)架構(gòu)是否是一個錯誤，或者說微服務(wù)已經(jīng)過時了呢？

首先推薦一下中培IT學院的微服務(wù)及高并發(fā)、高可用架構(gòu)設(shè)計與最佳實踐培訓班，本課程對微服務(wù)及相關(guān)技術(shù)核心做了全面的講解，詳情可以咨詢客服

1.微服務(wù)是否必要？

微服務(wù)架構(gòu)的起源可以追溯到2005年，當時Peter Rodgers博士提出了Micro-Web-Service的概念，即將應(yīng)用程序設(shè)計成細粒度的Web服務(wù)。然而，微服務(wù)的概念真正開始引起廣泛關(guān)注是在2014年，當時Martin Fowler和James Lewis首次正式提出了微服務(wù)的定義。他們將微服務(wù)架構(gòu)描述為一種方法，通過以開發(fā)一組小型服務(wù)的方式來構(gòu)建獨立的應(yīng)用系統(tǒng)。每個服務(wù)都以獨立的進程方式運行，并使用輕量級通信機制（如RPC或HTTP）與其他服務(wù)進行通信。這些微服務(wù)是圍繞業(yè)務(wù)功能構(gòu)建的，可以使用不同的編程語言來實現(xiàn)。

微服務(wù)的興起與發(fā)展與CICD（持續(xù)集成和持續(xù)交付）以及基礎(chǔ)設(shè)施即代碼（Infrastructure as Code）的發(fā)展有密切關(guān)系。這些技術(shù)的出現(xiàn)簡化了基礎(chǔ)設(shè)施管理，加快了功能迭代，從而促進了微服務(wù)架構(gòu)的進一步發(fā)展和應(yīng)用。

然而，微服務(wù)架構(gòu)并不是適合所有情況的銀彈。盡管微服務(wù)可以為業(yè)務(wù)帶來好處，但也會帶來一些挑戰(zhàn)和副作用。關(guān)鍵在于在適當?shù)臅r機采用微服務(wù)架構(gòu)，合理決定微服務(wù)的拆分粒度，以及選擇適當?shù)奈⒎?wù)技術(shù)。不應(yīng)該盲目跟風，也不應(yīng)該大肆批評微服務(wù)的必要性，或者呼吁回到單體架構(gòu)時代。GitHub的前CTO Jason Warner提出的觀點強調(diào)了從單體應(yīng)用向微服務(wù)的有序遷移，同時也強調(diào)了微服務(wù)的數(shù)量應(yīng)該適合組織的規(guī)模。他鼓勵企業(yè)根據(jù)自身情況來做出選擇，而不是盲目追隨潮流。這與前文提到的觀點是一致的。微服務(wù)架構(gòu)的成功與否在很大程度上取決于如何明智地應(yīng)用它，而不是一味地擁護或反對。

（1）在合適的階段采用微服務(wù)架構(gòu)

根據(jù)觀察和經(jīng)驗，成功的微服務(wù)架構(gòu)往往是從一個龐大的單體架構(gòu)逐漸演化而來的。在面對新產(chǎn)品和領(lǐng)域時，很難一開始就完全理解業(yè)務(wù)需求，通常需要經(jīng)過一段時間的探索和學習，才能逐步轉(zhuǎn)向微服務(wù)架構(gòu)。此外，在資源有限的情況下，采用微服務(wù)架構(gòu)可能存在一定的風險，特別是當技術(shù)選型不當時，可能會凸顯出微服務(wù)性能方面的劣勢。

在劃分微服務(wù)之前，確保公司內(nèi)部的基礎(chǔ)設(shè)施和公共基礎(chǔ)服務(wù)已經(jīng)做好準備非常重要。這包括通過監(jiān)控組件和產(chǎn)品快速定位服務(wù)故障、通過工具實現(xiàn)自動化部署和管理服務(wù)、通過一站式開發(fā)框架降低服務(wù)開發(fā)成本、通過灰度發(fā)布和泳道驗證提高服務(wù)的可用性、通過資源調(diào)度平臺快速獲取和釋放資源以及通過彈性伸縮服務(wù)快速擴展應(yīng)用等方面的能力。這些都是確保微服務(wù)架構(gòu)能夠有效運作和發(fā)揮優(yōu)勢的關(guān)鍵因素。

（2）合理決定微服務(wù)架構(gòu)的拆分粒度

微服務(wù)架構(gòu)的拆分粒度應(yīng)當注重合理性，不僅僅追求粒度越小越好或者越多越好。相反，我們需要追求一個適中的粒度。如果粒度過小，微服務(wù)架構(gòu)的缺點將被放大，那么微服務(wù)相對于原先的單體架構(gòu)的弊端將會更加明顯。而如果粒度不夠細，單體架構(gòu)的缺點依然存在，同時微服務(wù)的優(yōu)勢也無法充分展現(xiàn)，這也是不合理的。

微服務(wù)架構(gòu)的粒度拆分是一項復(fù)雜的任務(wù)，對于對業(yè)務(wù)和組織架構(gòu)理解不深的新人或外部人員來說，很難判斷出合理的微服務(wù)拆分粒度。

隨著業(yè)務(wù)的發(fā)展、組織架構(gòu)的變化以及團隊開發(fā)人員水平的提高，微服務(wù)架構(gòu)的粒度可能會發(fā)生變化。這是一個持續(xù)演進的過程，沒有絕對的對錯。微服務(wù)架構(gòu)的設(shè)計和微服務(wù)的拆分應(yīng)當遵循康威定律，即微服務(wù)架構(gòu)應(yīng)與產(chǎn)生這些設(shè)計的組織架構(gòu)保持一致，甚至保持動態(tài)一致。

當然，僅僅熟悉業(yè)務(wù)和組織架構(gòu)是不夠的，我們還需要采用合理的微服務(wù)拆分策略。例如，對于相對獨立的新業(yè)務(wù)，可以優(yōu)先考慮采用微服務(wù)架構(gòu)；對于具有通用性的功能，可以優(yōu)先進行抽象為通用服務(wù)；對于邊界比較清晰的模塊，可以優(yōu)先進行抽象；對于具有獨立屬性的服務(wù)，也可以優(yōu)先進行抽象。最后，建議優(yōu)先抽象核心服務(wù)，因為微服務(wù)的運維成本較高，并不是所有的地方都需要進行拆分。此外，隨著時間的推移，業(yè)務(wù)可能會發(fā)生變化，而核心服務(wù)相對來說比較穩(wěn)定，因此不需要進行過大的調(diào)整。

（3）恰當?shù)奈⒎?wù)技術(shù)選型

決定采用微服務(wù)架構(gòu)后，選擇合適的微服務(wù)框架變得至關(guān)重要。微服務(wù)框架可以封裝和抽象分布式場景下常見的通用能力，如負載均衡、服務(wù)注冊與發(fā)現(xiàn)、容錯機制以及基本的遠程通信能力，從而使開發(fā)人員能夠快速開發(fā)高質(zhì)量的服務(wù)。因此，在采用微服務(wù)之前，應(yīng)該仔細考慮開發(fā)語言的選擇以及對應(yīng)微服務(wù)框架的選型和試用。

那么，如何才能選擇合適的微服務(wù)框架呢？我建議從擴展性、易用性、功能豐富度和性能這四個角度進行評估。

首先是擴展性。一個開源框架如果與內(nèi)部能力緊密耦合、只支持特定場景且無法進行擴展，那么在企業(yè)內(nèi)部定制化的需求下很難應(yīng)用。因此，選擇的框架應(yīng)該具備良好的擴展性，能夠支持各種定制化場景的落地。

其次是易用性。業(yè)務(wù)開發(fā)者希望能夠?qū)Ｗ⒂跇I(yè)務(wù)開發(fā)，而不必過多關(guān)注底層框架的細節(jié)。因此，選擇的框架應(yīng)該足夠簡單易用。另一方面，對于基于框架進行二次開發(fā)的開發(fā)者來說，他們需要框架提供一定程度的定制支持。如果框架的擴展能力過于寬泛導致擴展成本很高，或者可擴展的能力不夠多，那么這個框架也會有局限性。

再次是功能豐富度。雖然通過擴展性可以對框架進行定制，但并非所有開發(fā)者都有足夠的資源和精力進行定制開發(fā)。因此，選擇的框架應(yīng)該在自身內(nèi)部提供不同選擇的擴展能力，使開發(fā)者能夠根據(jù)自己的基礎(chǔ)設(shè)施需求進行組合，并在其所處的環(huán)境中運行。

前面三點是在微服務(wù)轉(zhuǎn)型初期選擇微服務(wù)框架時需要重點關(guān)注的指標。但隨著服務(wù)規(guī)模和資源消耗的增加，性能問題變得不容忽視。從長遠來看，選擇框架時必須考慮性能因素，否則后續(xù)可能面臨框架替換的巨大成本或被迫進行定制優(yōu)化和維護的問題。

總而言之，微服務(wù)并非解決所有問題的銀彈，但單體架構(gòu)同樣存在許多缺陷。微服務(wù)是在單體架構(gòu)基礎(chǔ)上自然演化而來的一種現(xiàn)代化且云原生的架構(gòu)，是未來趨勢。然而，業(yè)務(wù)需要在適當?shù)碾A段采用微服務(wù)架構(gòu)，并合理決策微服務(wù)的拆分粒度以及進行恰當?shù)奈⒎?wù)技術(shù)選型。如果過于急躁，服務(wù)拆分不合理或技術(shù)選型出錯，可能會導致架構(gòu)需要回退到單體架構(gòu)，這只是個別案例，但我們?nèi)孕杈璨⒁詾榻洹?/p>

2.如何應(yīng)對微服務(wù)深入發(fā)展的挑戰(zhàn)？

近十年來，微服務(wù)架構(gòu)在業(yè)界掀起了一股熱潮。伴隨著微服務(wù)的興起，涌現(xiàn)出許多技術(shù)創(chuàng)新和開源項目，許多企業(yè)也在內(nèi)部積極推進微服務(wù)的落地和推廣。以字節(jié)跳動為例，該公司在近年內(nèi)微服務(wù)的數(shù)量和規(guī)模都迎來了快速的發(fā)展。2018年，字節(jié)跳動的在線微服務(wù)數(shù)量約為7000-8000個，而到了2021年底，這一數(shù)字已經(jīng)突破了10萬個。在企業(yè)內(nèi)部，能夠達到如此規(guī)模的微服務(wù)體系相當罕見，但這也反映出字節(jié)跳動在微服務(wù)領(lǐng)域取得了深刻的發(fā)展。那么，微服務(wù)在未來將朝著怎樣的方向發(fā)展呢？

結(jié)合字節(jié)跳動服務(wù)框架團隊的實踐經(jīng)驗和業(yè)界趨勢，我們認為微服務(wù)的未來發(fā)展將主要集中在安全性提升、穩(wěn)定性保障、成本優(yōu)化、為服務(wù)治理標準化幾個方面。

（1）微服務(wù)安全

在微服務(wù)架構(gòu)中，微服務(wù)的數(shù)量會隨著業(yè)務(wù)的細分和增長而迅速增加。由于這些微服務(wù)分布在不同的服務(wù)器上，相較于傳統(tǒng)的單一平臺實現(xiàn)，它們通常會面臨更廣泛和多樣化的潛在攻擊風險，這使得及時發(fā)現(xiàn)和修復(fù)漏洞變得更加復(fù)雜。因此，每個微服務(wù)都需要對用戶進行身份驗證和授權(quán)，以確保當前訪問的用戶的身份和權(quán)限級別明確。同時，整個系統(tǒng)可能還需要向外部提供服務(wù)，如第三方登錄授權(quán)等。在這種情況下，要求每個微服務(wù)都獨立實現(xiàn)用戶信息管理系統(tǒng)既增加了開發(fā)工作量，也增加了出錯的風險。因此，統(tǒng)一的身份認證和授權(quán)以及支持按需啟用 mTLS（雙向傳輸層安全）變得尤為重要。

服務(wù)鑒定是一種微服務(wù)訪問控制能力，它基于身份標識來驗證請求的合法性。通過為具體方法或通用方法配置全局開關(guān)，可以實現(xiàn)強制身份驗證的效果。為了滿足合規(guī)要求，字節(jié)跳動進行了跨業(yè)務(wù)線數(shù)據(jù)訪問的專項治理。在這一治理中，一個重要前提是實現(xiàn)零信任（Zero Trust）的服務(wù)身份，以識別數(shù)據(jù)請求的可信身份，進一步實現(xiàn)細粒度的訪問控制，以滿足用戶隱私合規(guī)要求，確保微服務(wù)接口的安全性，以防止類似刪庫這樣的誤操作。

嚴格授權(quán)是一種微服務(wù)訪問控制能力，它基于允許訪問列表和不允許訪問列表。通過為具體方法或通配方法配置對上游服務(wù)的具體集群或通配集群的授權(quán)，結(jié)合全局開關(guān)為開啟狀態(tài)，可以實現(xiàn)嚴格的訪問控制效果。

一些RPC框架本身也具備嚴格授權(quán)的能力，但不同框架的實現(xiàn)方式不一致，難以滿足業(yè)務(wù)的配置需求。字節(jié)跳動利用服務(wù)網(wǎng)格技術(shù)（ByteMesh）實現(xiàn)了統(tǒng)一的嚴格授權(quán)能力，這得益于服務(wù)網(wǎng)格技術(shù)在字節(jié)跳動內(nèi)部已經(jīng)全面落地實施。

（2）微服務(wù)穩(wěn)定性

線上服務(wù)的穩(wěn)定性對于互聯(lián)網(wǎng)應(yīng)用來說至關(guān)重要。如果服務(wù)的穩(wěn)定性不好，將給用戶帶來不良的使用體驗，甚至給企業(yè)直接造成經(jīng)濟損失。衡量服務(wù)穩(wěn)定性的一個重要指標是SLO（Service-Level Objectives），它代表了服務(wù)可用水平的目標。例如，將服務(wù)接口的成功率SLO設(shè)定為99.99%，意味著在一周內(nèi)低于這個基準的不可用時長應(yīng)該少于X小時，超過X小時就表示該服務(wù)的穩(wěn)定性不達標。通常情況下，微服務(wù)的治理能力如超時、重試、容錯和限流等可以滿足大多數(shù)情況需求，并提高微服務(wù)的穩(wěn)定性。在字節(jié)跳動內(nèi)部，我們實現(xiàn)了高水平的微服務(wù)化和規(guī)?；渴?，在精細化的服務(wù)治理方面誕生了許多解決方案，如單實例治理和動態(tài)過載保護等，進一步提升了微服務(wù)的穩(wěn)定性。

微服務(wù)化和大規(guī)模分布式部署帶來了一定的運維負擔，有時候甚至會導致難以區(qū)分問題是基礎(chǔ)設(shè)施問題還是業(yè)務(wù)自身問題。其中，最常見且通常不需要業(yè)務(wù)感知的問題是單實例故障導致服務(wù)SLA抖動。我們將這類問題統(tǒng)稱為單實例問題。單實例問題的成因復(fù)雜，涉及到物理和業(yè)務(wù)等多個方面的因素，幾乎無法完全消除。

為了降低對業(yè)務(wù)的感知程度并提升業(yè)務(wù)核心服務(wù)的服務(wù)水平協(xié)議（SLA），字節(jié)跳動服務(wù)框架團隊基于服務(wù)網(wǎng)格ByteMesh的動態(tài)負載均衡能力開發(fā)了解決單實例問題抖動的解決方案。該方案通過收集ByteMesh數(shù)據(jù)面上報的RPC指標（如延遲、錯誤率）和服務(wù)端實例的負載指標（如排隊時間、CPU/MEM/IO使用率），動態(tài)更新服務(wù)端實例的權(quán)重，以實現(xiàn)更平均的服務(wù)負載效果。這個中心化的控制方案在抖音電商等業(yè)務(wù)中經(jīng)過了大規(guī)模的驗證，有效提高了故障識別的效率。以某個具體的服務(wù)為例，當發(fā)生單實例故障時，默認配置會在1分鐘內(nèi)執(zhí)行服務(wù)發(fā)現(xiàn)的降權(quán)或摘除操作，從而將服務(wù)不可用時長控制在1分鐘以內(nèi)。同時，我們還提供了單實例治理摘除大盤，方便排查單實例問題。

（3）微服務(wù)成本優(yōu)化

在云原生時代，隨著微服務(wù)的拆分和增長，微服務(wù)過微成為一個不可避免的問題。這導致了額外的延遲和資源消耗等缺點變得更加明顯。有人呼吁回歸單體架構(gòu)，但是這并不是解決之道，因為回歸單體無法符合業(yè)務(wù)發(fā)展趨勢。為了優(yōu)化微服務(wù)的成本，字節(jié)跳動探索了許多路徑，包括合并部署、JSON序列化優(yōu)化和開發(fā)框架開銷優(yōu)化等。此外，在推進成本優(yōu)化的背景下，服務(wù)框架團隊與業(yè)務(wù)和其他基礎(chǔ)團隊合作，以挖掘更多性能優(yōu)化點。

合并部署：字節(jié)跳動在微服務(wù)架構(gòu)上進行了深入研究，探索了多種合并部署方案。雖然其他公司也嘗試過合并部署，但是現(xiàn)有方案在編譯、部署、監(jiān)控、服務(wù)治理和服務(wù)隔離等方面對現(xiàn)有體系造成了較大沖擊，無法很好地支持現(xiàn)有體系。此外，部署會相互影響，導致協(xié)作效率降低。為解決這個問題，基礎(chǔ)架構(gòu)團隊提出了一種新的合并部署方案，結(jié)合容器親和性調(diào)度、流量調(diào)度計算和更高效的本地通信。通過將原本需要跨機進行的網(wǎng)絡(luò)通信轉(zhuǎn)變?yōu)橥瑱C進程間調(diào)用，該方案既能與現(xiàn)有體系融合，又能減少微服務(wù)鏈路帶來的性能損耗?；A(chǔ)架構(gòu)服務(wù)框架團隊在QCon 2021上分享了《字節(jié)跳動微服務(wù)合并部署實踐》，引起了其他公司的廣泛關(guān)注。經(jīng)過落地測試，合并部署方案在CPU降低30% - 40%的同時，也提升了穩(wěn)定性和解決了波動問題。目前合并部署已經(jīng)在字節(jié)跳動的多個業(yè)務(wù)方中實施，并在進一步優(yōu)化后，有望在全公司范圍內(nèi)大規(guī)模推行。

JSON序列化優(yōu)化：JSON作為一種簡潔且具有靈活自描述能力的協(xié)議，在各個互聯(lián)網(wǎng)業(yè)務(wù)中被廣泛應(yīng)用。然而，由于JSON本質(zhì)上是一種文本協(xié)議，并且缺乏類似Protobuf的強制模型約束，導致其編解碼效率較低。加上一些業(yè)務(wù)開發(fā)人員對JSON庫選擇和使用不當，最終導致服務(wù)性能急劇下降。字節(jié)跳動也面臨了這些問題。根據(jù)之前對公司CPU占比TOP 50服務(wù)的性能分析數(shù)據(jù)統(tǒng)計，JSON編解碼開銷總體接近10％，某些業(yè)務(wù)甚至超過了40％。因此，提升JSON庫的性能變得非常重要。為此，字節(jié)跳動自研了一套高性能的JSON編解碼庫sonic-go，并適用于C/C++服務(wù)的sonic-cpp，并已在Bytedance GitHub組織下開源。

在設(shè)計sonic-go時，團隊借鑒了其他領(lǐng)域/語言的優(yōu)化思想，并將其融合到各個處理環(huán)節(jié)中。其中核心技術(shù)包括JIT、lazy-load和SIMD。除了上述技術(shù)外，sonic還進行了許多細節(jié)優(yōu)化，例如使用RCU替換sync.Map以提升codec緩存的加載速度，使用內(nèi)存池減少encode buffer的內(nèi)存分配等。自2021年7月發(fā)布以來，sonic-go已被抖音、今日頭條等許多業(yè)務(wù)采用，并為字節(jié)跳動節(jié)省了數(shù)十萬個CPU核心。目前，sonic-go v2正在設(shè)計和開發(fā)中，預(yù)計將帶來更大的性能提升。

而sonic-cpp整合了rapidjson、yyjson和simdjson三者的優(yōu)點，并進一步進行優(yōu)化。在實現(xiàn)過程中，主要利用向量化（SIMD）指令、優(yōu)化內(nèi)存布局和按需解析等關(guān)鍵技術(shù)，使得序列化、反序列化和增刪改查的性能達到極致。自sonic-cpp在字節(jié)跳動內(nèi)部上線以來，已為抖音、今日頭條等核心業(yè)務(wù)節(jié)省了數(shù)十萬個CPU核心。

sonic-go和sonic-cpp都兼容常見JSON庫的所有接口，改造成本很低，方便現(xiàn)有服務(wù)的快速遷移。隨著業(yè)務(wù)規(guī)模的增大，遷移到sonic-go和sonic-cpp帶來的收益也越多。

開發(fā)框架開銷優(yōu)化：對于業(yè)務(wù)而言，選擇高性能的編程語言非常重要，但往往受限于研發(fā)團隊的技術(shù)棧和歷史背景。同時，語言遷移的成本很高，需要有足夠的動力來推動。對于一些創(chuàng)業(yè)公司或者具有一定規(guī)模的公司的新增業(yè)務(wù)線來說，Golang是云原生時代最好的選擇之一，因為它的學習成本不高，對云原生生態(tài)友好，并具有較高的性能表現(xiàn)。

2014年，字節(jié)跳動引入了Golang，以解決長連接推送業(yè)務(wù)面臨的高并發(fā)問題。隨后，技術(shù)團隊推出了Kite和Ginex（基于Gin的擴展）框架，這兩個原始框架的推出極大推動了Golang在公司內(nèi)部的應(yīng)用。然而，由于很多功能版本過低，包括Thrift當時只有v0.9.2，這兩個框架存在許多問題，同時Golang也迎來了數(shù)輪大版本迭代，導致Kite和Ginex在性能和可維護性上存在較大問題。因此，服務(wù)框架團隊正式啟動了Kite的重構(gòu)，新框架命名為Kitex。這是一個自下而上的整體升級重構(gòu)，旨在提高性能和可擴展性。類似的設(shè)計思路和底層模塊也被應(yīng)用在字節(jié)跳動自研的Golang HTTP框架Hertz上，該項目具有高性能和高可擴展性。之后，Kitex和Hertz進入了大規(guī)模落地階段，并持續(xù)進行性能和擴展性方面的迭代和優(yōu)化。2022年，Kitex啟動了序列化和Thrift的專項優(yōu)化，進一步提高了內(nèi)容拷貝和IO操作的性能開銷。

選擇適合的Golang微服務(wù)框架在選擇Golang的前提下非常重要。如前所述，最合適的微服務(wù)框架應(yīng)具備高可擴展性、高易用性、高性能和豐富的內(nèi)置功能。CloudWeGo就是這樣的開源微服務(wù)框架和中間件集合，其中包括字節(jié)跳動開源的Kitex和Hertz，并且是Golang領(lǐng)域和CNCF Landscape推薦的微服務(wù)框架。

（4）微服務(wù)治理標準化

微服務(wù)架構(gòu)離不開配套的治理能力。這些治理能力包括服務(wù)可觀測、全鏈路壓測與灰度、注冊發(fā)現(xiàn)、配置中心等，它們的實現(xiàn)依賴于服務(wù)框架、SDK、Java Agent以及服務(wù)網(wǎng)格等技術(shù)。隨著這些技術(shù)的發(fā)展，業(yè)界出現(xiàn)了各種不同的開發(fā)語言、框架和架構(gòu)，給企業(yè)帶來了維護負擔和技術(shù)選型上的困擾。不同框架之間的互通也存在一些問題，如損耗和高復(fù)雜度等。不同微服務(wù)開發(fā)框架和工具鏈對于服務(wù)治理體系的理解和實現(xiàn)也存在差異性，這不利于微服務(wù)技術(shù)的沉淀和長期發(fā)展。為了解決這些問題，終端用戶必須在不同的基礎(chǔ)設(shè)施和適當?shù)墓ぞ咧g做出抉擇，增加了企業(yè)在微服務(wù)架構(gòu)落地過程中的成本。

為了應(yīng)對這個挑戰(zhàn)，2022年誕生了兩套微服務(wù)治理標準化方案。這些方案面向多語言、多框架和異構(gòu)基礎(chǔ)設(shè)施，涵蓋了流量治理、服務(wù)容錯、服務(wù)元信息治理、安全治理等關(guān)鍵治理領(lǐng)域，提供了一系列的治理能力與標準、生態(tài)適配與最佳實踐。

在2022年3月，NextArch基金會正式宣布成立微服務(wù)SIG。該小組由來自騰訊、字節(jié)跳動、七牛云、快手、BIGO、好未來和藍色光標等多家企業(yè)的技術(shù)專家組成。該小組致力于推動微服務(wù)技術(shù)及其開源生態(tài)的持續(xù)發(fā)展。他們將面向企業(yè)在微服務(wù)生產(chǎn)實踐中遇到的問題，為不同行業(yè)和應(yīng)用場景提供標準化解決方案，并與PolatisMesh、TARS、go-zero、GoFrame、CloudWeGo和Spring Cloud Tencent等開源社區(qū)合作，提供開箱即用的實現(xiàn)，以降低微服務(wù)用戶的落地門檻。根據(jù)各自企業(yè)在分布式或微服務(wù)生產(chǎn)實踐中的經(jīng)驗和痛點，他們針對不同行業(yè)和應(yīng)用場景輸出了微服務(wù)落地的標準化方案，并依托相關(guān)開源社區(qū)提供了推薦的實現(xiàn)，方便終端用戶實施。

同樣在2022年4月，微服務(wù)治理規(guī)范OpenSergo項目正式開源。OpenSergo是一個開放通用的微服務(wù)治理項目，覆蓋微服務(wù)及上下游關(guān)聯(lián)組件。該項目從微服務(wù)的角度出發(fā)，涵蓋了流量治理、服務(wù)容錯、服務(wù)元信息治理、安全治理等關(guān)鍵治理領(lǐng)域，提供了一系列的治理能力與標準、生態(tài)適配與最佳實踐，并支持Java、Go、Rust等多語言生態(tài)。OpenSergo項目由阿里巴巴、bilibili、中國移動、SphereEx等企業(yè)以及Kratos、CloudWeGo、ShardingSphere、Database Mesh、Spring Cloud Alibaba、Apache Dubbo等社區(qū)共同發(fā)起，共同推動微服務(wù)治理標準建設(shè)與能力演進。OpenSergo的最大特點在于使用統(tǒng)一的一套配置/DSL/協(xié)議定義服務(wù)治理規(guī)則，面向多語言異構(gòu)化架構(gòu)，覆蓋微服務(wù)框架及上下游關(guān)聯(lián)組件。

總體而言，微服務(wù)治理標準仍處于早期建設(shè)階段。從微服務(wù)治理標準定義到控制面的實現(xiàn)，再到各個語言SDK和治理功能的實現(xiàn)，以及微服務(wù)生態(tài)的整合和落地，都需要進一步的演進和完善。

3.對微服務(wù)未來的展望

微服務(wù)是一種不斷發(fā)展的軟件架構(gòu)模式，它并沒有解決所有的問題，但也不會過時。盡管微服務(wù)在實施過程中存在挑戰(zhàn)，但它已經(jīng)成為云計算基礎(chǔ)設(shè)施的一部分，和計算、存儲、網(wǎng)絡(luò)、數(shù)據(jù)庫以及安全同等重要。不同階段的發(fā)展給微服務(wù)帶來了不同的挑戰(zhàn)。在云原生普及之前，開發(fā)者關(guān)注微服務(wù)的架構(gòu)設(shè)計、迭代、交付和運維。隨著云原生技術(shù)的成熟，微服務(wù)也開始向云原生化方向發(fā)展，這時開發(fā)者和架構(gòu)師更加注重如何利用云計算的優(yōu)勢簡化微服務(wù)的治理和運維，并提高業(yè)務(wù)交付效率。選擇和遷移高性能的服務(wù)框架，標準化微服務(wù)治理也成為微服務(wù)發(fā)展的重要方向。

隨著云原生和微服務(wù)的發(fā)展，高并發(fā)、高可用架構(gòu)設(shè)計等技術(shù)也將持續(xù)受到重視。在這種運營環(huán)境中，采用傳統(tǒng)的集中式系統(tǒng)架構(gòu)越來越不能使用未來的發(fā)展，整個產(chǎn)業(yè)開始向分布式系統(tǒng)轉(zhuǎn)型。然而，在分布式系統(tǒng)轉(zhuǎn)型過程中，有許許多多的分布式技術(shù)千差萬別，并且要按不同場景去運用不同的分布式技術(shù)。為此開展微服務(wù)及高并發(fā)、高可用架構(gòu)設(shè)計與最佳實踐培訓班，課程理論與實踐相結(jié)合、案例分析與行業(yè)應(yīng)用穿插進行，通過全面知識理解、專題技能演示和實踐引導學員掌握微服務(wù)中的核心知識與技術(shù)，適合一般軟件企業(yè)的設(shè)計人員和初級架構(gòu)師,以及資深程序員參與學習。

關(guān)于微服務(wù)實踐提升課程詳情，可直接咨詢中培IT學院客服