背景

Kerberos 是一種網(wǎng)絡(luò)認(rèn)證協(xié)議，其設(shè)計(jì)目標(biāo)是通過(guò)密鑰系統(tǒng)為客戶端、服務(wù)器端的應(yīng)用程序提供強(qiáng)大的認(rèn)證服務(wù)。

作為一種可信任的第三方認(rèn)證服務(wù)，Kerberos是通過(guò)傳統(tǒng)的密碼技術(shù)（如：共享密鑰）執(zhí)行認(rèn)證服務(wù)的，被Client和Server同時(shí)信任。KDC是對(duì)該協(xié)議中第三方認(rèn)證服務(wù)的一種具體實(shí)現(xiàn)，一直以來(lái)都是美團(tuán)數(shù)據(jù)平臺(tái)的核心服務(wù)之一，在Hive、HDFS、YARN等開(kāi)源組件的權(quán)限認(rèn)證方面有著廣泛的應(yīng)用。該服務(wù)將認(rèn)證的密鑰事先部署在集群的節(jié)點(diǎn)上，集群或者新節(jié)點(diǎn)啟動(dòng)時(shí)，相應(yīng)節(jié)點(diǎn)使用密鑰得到認(rèn)證。只有被認(rèn)證過(guò)節(jié)點(diǎn)才能被集群所接納。企圖冒充的節(jié)點(diǎn)由于沒(méi)有相關(guān)密鑰信息，無(wú)法與集群內(nèi)部的節(jié)點(diǎn)通信，從而有效的確保了數(shù)據(jù)的安全性、節(jié)點(diǎn)的可信賴性。

但隨著平臺(tái)業(yè)務(wù)的快速增長(zhǎng)，當(dāng)前線上KDC的處理能力不足和不能可靠監(jiān)控的問(wèn)題被凸顯的日益嚴(yán)重：線上單臺(tái)KDC服務(wù)器最大承受QPS是多少？哪臺(tái)KDC的服務(wù)即將出現(xiàn)壓力過(guò)大的問(wèn)題？為什么機(jī)器的資源非常空閑，KDC的壓力卻會(huì)過(guò)大？如何優(yōu)化？優(yōu)化后瓶頸在哪兒？如何保證監(jiān)控指標(biāo)的全面性、可靠性和準(zhǔn)確性？這都是本文需要回答的問(wèn)題。從本次優(yōu)化工作達(dá)成的最終結(jié)果上來(lái)看，單臺(tái)服務(wù)器每秒的處理性能提升16倍左右，另外通過(guò)共享內(nèi)存的方式設(shè)計(jì)了一個(gè)獲取KDC各項(xiàng)核心指標(biāo)的接口，使得服務(wù)的可用性進(jìn)一步提升。

為方便大家，表1總結(jié)并解釋了本文中后續(xù)會(huì)涉及到一些專業(yè)名詞的簡(jiǎn)稱：

圖1為美團(tuán)數(shù)據(jù)平臺(tái)KDC當(dāng)前服務(wù)架構(gòu)，目前整個(gè)KDC服務(wù)部署在同一個(gè)IDC。

KDC原理介紹

Client、 KDC和Server在認(rèn)證階段主要有Client和KDC的AS、Client和KDC的TGS以及Client和Server的交互三個(gè)過(guò)程，下文將詳細(xì)介紹三個(gè)過(guò)程的交互，其中圖2中的步驟1和2、3和4、5和6分別對(duì)應(yīng)下文的A、B、C三部分：

A. Client和AS的交互

用戶以明文的形式發(fā)送自己的信息、以及想要申請(qǐng)的TGT Principal（默認(rèn)為KDC的TGT：krbtgt/REALM@REALM）等信息給AS服務(wù)；

AS服務(wù)驗(yàn)證該用戶信息存在數(shù)據(jù)庫(kù)中后，給客戶端返回兩大塊信息：

• 使用用戶的密鑰加密其申請(qǐng)的TGT和一個(gè)Session Key返回用戶,用戶得到加密信息后，使用自己密鑰解密得到其申請(qǐng)的TGT和Session Key（后續(xù)都簡(jiǎn)稱 SK_CandK）。
• 以KDC自身密鑰加密用戶申請(qǐng)的TGT、SK_CandK、用戶自己信息等；簡(jiǎn)稱{TGT}K_tgs，該部分信息被Client保存在本地。

B. Client和TGS的交互

Client訪問(wèn)TGS獲取訪問(wèn)網(wǎng)路中某一Server的ticket請(qǐng)求。Client端會(huì)把第一部分中保存在本地的{TGT}K_tgs和用SK_CandK加密的客戶端信息發(fā)送KDC的TGS模塊；

TGS收到請(qǐng)求后，檢查請(qǐng)求Server存在數(shù)據(jù)庫(kù)中后，用自己的密鑰解密得到TGT中的SK_CandK，然后便可以解密得到用戶的信息并驗(yàn)證其合法性；通過(guò)后，TGS會(huì)生成一個(gè)新的Session Key，簡(jiǎn)稱SK_CandS；同時(shí)返回兩部分信息：

• 用SK_CandK加密的SK_CandS、能夠訪問(wèn)Service的ticket等信息。
• 用Service密鑰加密的Client info、SK_CandS等信息，簡(jiǎn)稱{ T_Service }K_Service。

C. Client和Server的交互

Client拿到訪問(wèn)Service的ticket后，向Service發(fā)起請(qǐng)求，同時(shí)將兩部分信息發(fā)送給Server：1）通過(guò)SK_CandS加密的Client info等信息。2）第二部分TGS返回客戶端的{ T_Service }K _Service； =1>

Server端收到Client的請(qǐng)求信息后，用自己的密鑰解密獲取到T_Service信息，就能夠解密SK_CandS加密的客戶端信息，和T_Service中的客戶端信息進(jìn)行對(duì)比，通過(guò)后，整個(gè)KDC認(rèn)證過(guò)程結(jié)束，Client和Service進(jìn)行正常的服務(wù)通信。

主要優(yōu)化工作

通過(guò)對(duì)KDC原理的分析，很容易判斷只有前兩部分才可能直接給KDC服務(wù)帶來(lái)壓力，因此本文涉及到的工作都將圍繞上一部分的前兩個(gè)環(huán)節(jié)展開(kāi)分析。本次優(yōu)化工作采用Grinder這一開(kāi)源壓測(cè)工具，分別對(duì)AS、TGS兩個(gè)請(qǐng)求過(guò)程，采用相同機(jī)型（保證硬件的一致性）在不同場(chǎng)景下進(jìn)行了壓力測(cè)試。

優(yōu)化之前，線上KDC服務(wù)啟動(dòng)的單進(jìn)程；為最低風(fēng)險(xiǎn)的完成美團(tuán)和點(diǎn)評(píng)數(shù)據(jù)的融合，KDC中keytab都開(kāi)啟了PREAUTH屬性；承載KDC服務(wù)的部分服務(wù)器沒(méi)有做RAID。KDC服務(wù)出現(xiàn)故障時(shí)，機(jī)器整體資源空閑，懷疑是單進(jìn)程的處理能力達(dá)到上限；PREAUTH屬性進(jìn)一步保證提升了KDC服務(wù)的安全性，但可能帶來(lái)一定的性能開(kāi)銷；如果線上服務(wù)器只加載了少量的keytab信息，那么沒(méi)有被加載到內(nèi)存的數(shù)據(jù)必然讀取磁盤，從而帶來(lái)一定的IO損耗。

因此本文中，對(duì)以下三個(gè)條件進(jìn)行變動(dòng)，分別進(jìn)行了測(cè)試：

對(duì)承載KDC服務(wù)的物理機(jī)型是否做RAID10；

請(qǐng)求的keytab在庫(kù)中是否帶有PRAUTH屬性；

KDC是否啟動(dòng)多進(jìn)程（多進(jìn)程設(shè)置數(shù)目和物理機(jī)核數(shù)一致）。（實(shí)際測(cè)試工作中進(jìn)行了多次測(cè)試）

A. Client和AS交互過(guò)程的壓測(cè)

表2為AS壓測(cè)的一組平均水平的測(cè)試數(shù)據(jù)，使用的物理機(jī)有40核，因此多進(jìn)程測(cè)試啟動(dòng)40個(gè)進(jìn)程。

分析表2中的數(shù)據(jù)，很容易提出如下問(wèn)題從而需要進(jìn)一步探索：

1. 比較表2中第一行和第二行、第三行和第四行，主機(jī)做不做RAID為什么對(duì)結(jié)果幾乎無(wú)影響？

該四組（測(cè)試結(jié)果為49、53、100和104所在表2中的行）數(shù)據(jù)均在達(dá)到處理能力上限一段時(shí)間后產(chǎn)生認(rèn)證失敗，分析機(jī)器的性能數(shù)據(jù)，內(nèi)存、網(wǎng)卡、磁盤資源均沒(méi)有成為系統(tǒng)的瓶頸，CPU資源除了某個(gè)CPU偶爾被打滿，其他均很空閑。分析客戶端和服務(wù)端的認(rèn)證日志，服務(wù)端未見(jiàn)明顯異常，但是客戶端發(fā)現(xiàn)大量的Socket Timeout錯(cuò)誤（測(cè)試設(shè)置的Socket超時(shí)時(shí)間為30s）。由于測(cè)試過(guò)程中，客戶端輸出的壓力始終大于KDC的最大處理能力，導(dǎo)致KDC端的AS始終處于滿負(fù)荷狀態(tài)，暫時(shí)處理不了的請(qǐng)求必然導(dǎo)致排隊(duì)；當(dāng)排隊(duì)的請(qǐng)求等待時(shí)間超過(guò)設(shè)置的30s后便會(huì)開(kāi)始超時(shí)從而認(rèn)證出錯(cuò)，且伴隨機(jī)器某一CPU被打滿（如圖3）。 顯然KDC單進(jìn)程服務(wù)的處理能力已經(jīng)達(dá)到瓶頸且瓶頸存在單核CPU的處理能力，從而決定向多進(jìn)程方向進(jìn)行優(yōu)化測(cè)試。

圖4為本次壓力測(cè)試的一個(gè)通用模型，假設(shè)KDC單位時(shí)間內(nèi)的最大處理能力是A，來(lái)自客戶端的請(qǐng)求速率穩(wěn)定為B且 B>A ；圖中黃色區(qū)域?yàn)榕抨?duì)的請(qǐng)求數(shù)，當(dāng)某一請(qǐng)求排隊(duì)超過(guò)30s，便會(huì)導(dǎo)致Socket Timedout錯(cuò)誤。

2. 比較表2中第1和3行、第2和4行、第7和8行相比，為什么有PREAUTH屬性的認(rèn)證QPS大致是無(wú)該屬性處理能力的一半？

如果Client的keytab在KDC的庫(kù)中不帶有PREAUTH這一屬性，Client發(fā)送請(qǐng)求，KDC的AS模塊驗(yàn)證其合法性之后返回正確的結(jié)果；整個(gè)過(guò)程只需要兩次建立鏈接進(jìn)行交互便可完成。如果帶有PREAUTH屬性，意味著該keytab的認(rèn)證啟動(dòng)了Kerberos 5協(xié)議中的 pre-authentication概念：當(dāng)AS模塊收到Client的請(qǐng)求信息后；故意給Client返回一個(gè)錯(cuò)誤的請(qǐng)求包，Client會(huì)“領(lǐng)悟到”這是KDC的AS端需要進(jìn)行提前認(rèn)證；從而Client獲取自己服務(wù)器的時(shí)間戳并用自己的密鑰加密發(fā)送KDC，KDC解密后和自身所在服務(wù)器的時(shí)間進(jìn)行對(duì)比，如果誤差在能容忍的范圍內(nèi)；返回給Client正確的TGT響應(yīng)包；過(guò)程如圖5所示。

3. 根據(jù)對(duì)問(wèn)題2的分析，表2中第5和7行的值的比例應(yīng)該近似為1:2，為什么第5行的值只有115，結(jié)果和理論差距如此之大？

KDC的庫(kù)中對(duì)客戶端的keytab開(kāi)啟PREAUTH屬性，客戶端每認(rèn)證一次，KDC需要將該次認(rèn)證的時(shí)間戳等信息寫到本次磁盤的BDB數(shù)據(jù)庫(kù)的Log中；而關(guān)閉PREAUTH屬性后，每次認(rèn)證只需要從庫(kù)中讀取數(shù)據(jù)，只要給BDB數(shù)據(jù)庫(kù)分配的內(nèi)存足夠大，就可以最大程度的減少和本次磁盤的交互。KDC40進(jìn)程且開(kāi)啟PRAUTH，其AS處理能力的QPS只有115，分析機(jī)器性能的相關(guān)指標(biāo)，發(fā)現(xiàn)瓶頸果然是單盤的IO，如圖6所示。使用BDB提供的工具，查看美團(tuán)數(shù)據(jù)平臺(tái)KDC服務(wù)的BDB緩存命中率為99%，如圖7所示：

4. KDC AS處理能力在多進(jìn)程做RAID條件下，有無(wú)preauth屬性，KDC服務(wù)是否有瓶頸？如果有在哪里？

經(jīng)多次實(shí)驗(yàn)，KDC的AS處理能力受目前物理機(jī)CPU處理能力的限制，圖8為有PREAUTH屬性的CPU使用情況截圖，無(wú)PREAUTH結(jié)果一致。

B. Client和TGS交互過(guò)程的壓測(cè)

表3為TGS壓測(cè)的一組平均水平的測(cè)試數(shù)據(jù)：

分析表3中的數(shù)據(jù)，可以發(fā)現(xiàn)KDC對(duì)TGS請(qǐng)求的處理能力和主機(jī)是否做RAID無(wú)關(guān),結(jié)合KDC中TGS的請(qǐng)求原理，就較容易理解在BDB緩存命中率足夠高的條件下，TGS的請(qǐng)求不需要和本次磁盤交互；進(jìn)一步做實(shí)驗(yàn)，也充分驗(yàn)證了這一點(diǎn)，機(jī)器的磁盤IO在整個(gè)測(cè)試過(guò)程中，沒(méi)有大的變化，如圖9所示，操作系統(tǒng)本身偶爾產(chǎn)生的IO完全構(gòu)不成KDC的服務(wù)瓶頸。KDC單進(jìn)程多進(jìn)程的對(duì)比，其處理瓶頸和AS一致，均受到CPU處理能力的限制（單進(jìn)程打滿某一CPU，多進(jìn)程幾乎占用整臺(tái)機(jī)器的CPU資源）。從Kerberos的設(shè)計(jì)原理分析，很容易理解，無(wú)論KDC庫(kù)中的keytab是否帶有PREAUTH屬性，對(duì)TGS的處理邏輯幾乎沒(méi)有影響，壓測(cè)的數(shù)據(jù)結(jié)果從實(shí)際角度驗(yàn)證了這一點(diǎn)。

C. 其他問(wèn)題

Client和KDC的交互，支持TCP和UDP兩種協(xié)議。在網(wǎng)絡(luò)環(huán)境良好的情況下，兩種協(xié)議的KDC的測(cè)試結(jié)果理論上和實(shí)際中幾乎一致。但是在原生代碼中，使用TCP協(xié)議，在客戶端給KDC造成一定壓力持續(xù)6s左右，客戶端開(kāi)始認(rèn)證出錯(cuò)，在遠(yuǎn)未達(dá)到超時(shí)時(shí)限的情況下，Client出現(xiàn)了socket reset類的錯(cuò)誤。KDC查看內(nèi)核日志，發(fā)現(xiàn)大量possible SYN flooding on port 8089(KDC的服務(wù)端口). Sending cookies，且通過(guò)netstat -s發(fā)現(xiàn)機(jī)器的xxxx times the listen queue of a socket overflowed異常增高，種種現(xiàn)象表明可能是服務(wù)端的半連接隊(duì)列、全連接隊(duì)列中的一個(gè)或者全部被打滿。主要原理如圖10所示：

發(fā)現(xiàn)KDC服務(wù)所在服務(wù)器：半隊(duì)列/proc/sys/net/ipv4/tcp_max_syn_backlog為2048。

全隊(duì)列：1）系統(tǒng)參數(shù)/proc/sys/net/core/somaxconn＝65535，查看代碼listen()函數(shù)的傳入值為5。

故而判斷TCP的瓶頸在于全隊(duì)列，因此目標(biāo)為將listen函數(shù)的第二個(gè)backlog參數(shù)變成可控可傳入。

KDC可監(jiān)控的設(shè)計(jì)和實(shí)現(xiàn)

開(kāi)源社區(qū)對(duì)Kerberos實(shí)現(xiàn)的KDC完全沒(méi)有對(duì)外暴露可監(jiān)控的接口，最初線上的場(chǎng)景主要通過(guò)檢索Log進(jìn)行相關(guān)指標(biāo)的監(jiān)控，在統(tǒng)計(jì)服務(wù)QPS、各種錯(cuò)誤的監(jiān)控等方面，存在準(zhǔn)確準(zhǔn)確監(jiān)控難的尷尬局面。為了實(shí)現(xiàn)對(duì)KDC準(zhǔn)確、較全面的監(jiān)控，對(duì)KDC進(jìn)行了二次開(kāi)發(fā)，設(shè)計(jì)一個(gè)獲取監(jiān)控指標(biāo)的接口。對(duì)監(jiān)控的設(shè)計(jì)，主要從以下三個(gè)方面進(jìn)行了考慮和設(shè)計(jì)。

A. 設(shè)計(jì)上的權(quán)衡

監(jiān)控的設(shè)計(jì)無(wú)論在什么場(chǎng)景下，都應(yīng)該盡可能的不去或者最小程度的影響線上的服務(wù)，本文最終采用建立一塊共享內(nèi)存的方式，記錄各個(gè)KDC進(jìn)程的打點(diǎn)信息，實(shí)現(xiàn)的架構(gòu)如圖11所示。每個(gè)KDC進(jìn)程對(duì)應(yīng)共享內(nèi)存中的一塊區(qū)域，通過(guò)n個(gè)數(shù)組來(lái)存儲(chǔ)KDC n個(gè)進(jìn)程的服務(wù)指標(biāo)：當(dāng)某個(gè)KDC進(jìn)程處理一個(gè)請(qǐng)求后，該請(qǐng)求對(duì)監(jiān)控指標(biāo)的影響會(huì)直接打點(diǎn)更新到其對(duì)應(yīng)的Slot 數(shù)組中。更新的過(guò)程不受鎖等待更新的影響，KDC對(duì)監(jiān)控打點(diǎn)的調(diào)用僅僅是內(nèi)存塊中的更新，對(duì)服務(wù)的影響幾乎可以忽略不計(jì)。相比其他方式，在實(shí)現(xiàn)上也更加簡(jiǎn)單、易理解。

紀(jì)錄每個(gè)KDC進(jìn)程的服務(wù)情況，便于準(zhǔn)確查看每個(gè)進(jìn)程的對(duì)請(qǐng)求的處理情況，有助于定位問(wèn)題多種情況下出現(xiàn)的異常，縮短故障的定位時(shí)間。例如：能夠準(zhǔn)確的反應(yīng)出每個(gè)進(jìn)程的請(qǐng)求分布是否均勻、請(qǐng)求處理出現(xiàn)異常能夠定位到具體是某個(gè)進(jìn)程出現(xiàn)異常還是整體均有異常。

B. 程序的可擴(kuò)展性

任何指標(biāo)的采集都是隨著需求進(jìn)行變更的，如果程序設(shè)計(jì)上不具有良好的擴(kuò)展性，會(huì)后續(xù)的指標(biāo)擴(kuò)展帶來(lái)很大的困擾。第一版KDC監(jiān)控指標(biāo)的采集只區(qū)分請(qǐng)求的成功與失敗兩種類型，美團(tuán)數(shù)據(jù)平臺(tái)KDC庫(kù)中所有的keytab都具有PREAUTH屬性。根據(jù)上文可知，去掉PREAUTH屬性后，AS請(qǐng)求的QPS能夠提升一倍。后續(xù)隨著服務(wù)規(guī)模的進(jìn)一步增長(zhǎng)，如果AS請(qǐng)求的處理能力逐步成為瓶頸，會(huì)考慮去掉PREAUTH屬性。為了準(zhǔn)確監(jiān)控去掉PREAUTH屬性這一過(guò)程是否有、有多少請(qǐng)求出現(xiàn)錯(cuò)誤，需要擴(kuò)展一個(gè)監(jiān)控指標(biāo)，因此有了KDC監(jiān)控的第二版。整個(gè)過(guò)程只需要修改三個(gè)地方，完成兩個(gè)功能的實(shí)現(xiàn)：

添加指標(biāo) ；

打點(diǎn)邏輯的添加。

整個(gè)修改過(guò)程簡(jiǎn)單明了，因此，該KDC監(jiān)控程序的設(shè)計(jì)具有非常好的擴(kuò)展性。圖12為監(jiān)控指標(biāo)的羅列和注釋：

C. 接口工具kstat的設(shè)計(jì)

獲取KDC監(jiān)控指標(biāo)的接口工具主要分為兩種：

獲取當(dāng)前每個(gè)KDC進(jìn)程對(duì)各個(gè)指標(biāo)的累積值，該功能是為了和新美大的監(jiān)控平臺(tái)Falcon結(jié)合，方便實(shí)現(xiàn)指標(biāo)的上報(bào)實(shí)現(xiàn)累加值和分鐘級(jí)別速率值的處理；

獲取制定次數(shù)在制定時(shí)間間隔內(nèi)每個(gè)進(jìn)程監(jiān)控指標(biāo)的瞬時(shí)速率，最小統(tǒng)計(jì)間隔可達(dá)秒級(jí)，方便運(yùn)維人員登陸機(jī)器無(wú)延遲的查看當(dāng)前KDC的服務(wù)情況，使其在公司監(jiān)控系統(tǒng)不可用的情況下分析服務(wù)的當(dāng)前問(wèn)題。具體使用見(jiàn)圖13 。

總結(jié)

通過(guò)本次對(duì)KDC服務(wù)的壓測(cè)實(shí)驗(yàn)和分析，總結(jié)出KDC最優(yōu)性能的調(diào)整方案為：

KDC服務(wù)本身需要開(kāi)啟多進(jìn)程和以充分利用多核機(jī)器的CPU資源，同時(shí)確保BDB的內(nèi)存資源足夠，保證其緩存命中率達(dá)到一定比例（越高越好，否則查詢庫(kù)會(huì)帶來(lái)大量的磁盤讀IO）；

選擇的物理機(jī)要做RAID，否則在庫(kù)中keytab帶有PREAUTH屬性的條件下，會(huì)帶來(lái)大量的寫，容易導(dǎo)致磁盤成為KDC的性能瓶頸。通過(guò)建立一塊共享內(nèi)存無(wú)鎖的實(shí)現(xiàn)了KDC多進(jìn)程指標(biāo)的收集，加上其良好的擴(kuò)展性和數(shù)據(jù)的精確性，極大的提高了KDC服務(wù)的可靠性。

相比原來(lái)線上單進(jìn)程的處理能力，目前單臺(tái)服務(wù)器的處理性能提升10+倍以上。本次工作沒(méi)有詳細(xì)的論述TCP協(xié)議中半隊(duì)列、全隊(duì)列的相關(guān)參數(shù)應(yīng)該如何設(shè)定才能達(dá)到最優(yōu)，和服務(wù)本身結(jié)合到一起，每個(gè)參數(shù)的變更帶來(lái)的影響具體是啥？考慮到TCP本身的復(fù)雜性，我們將在未來(lái)的文章中詳細(xì)討論這個(gè)問(wèn)題。

參考文檔

• http://blog.csdn.net/m1213642578/article/details/52370705
• http://grinder.sourceforge.net/
• http://www.cnblogs.com/Orgliny/p/5780796.html
• http://www.zeroshell.org/kerberos/Kerberos-operation/
• http://blog.csdn.net/wulantian/article/details/42418231

作者簡(jiǎn)介

• 鵬飛，美團(tuán)基礎(chǔ)數(shù)據(jù)部數(shù)據(jù)平臺(tái)大數(shù)據(jù)SRE組，離線計(jì)算組SRE負(fù)責(zé)人，2015年11月加入美團(tuán)。

招聘信息

如果你對(duì)如何保證海量數(shù)據(jù)服務(wù)的穩(wěn)定性、海量服務(wù)器大規(guī)模運(yùn)維感興趣，想親歷互聯(lián)網(wǎng)大數(shù)據(jù)的爆發(fā)式增長(zhǎng)，請(qǐng)和我們一起。歡迎加入美團(tuán)數(shù)據(jù)平臺(tái)大數(shù)據(jù)SRE組。有興趣的同學(xué)可以發(fā)送簡(jiǎn)歷到：chenpengfei#meituan.com。

創(chuàng)作挑戰(zhàn)賽新人創(chuàng)作獎(jiǎng)勵(lì)來(lái)咯，堅(jiān)持創(chuàng)作打卡瓜分現(xiàn)金大獎(jiǎng)

總結(jié)

以上是生活随笔為你收集整理的美团数据平台Kerberos优化实战的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。