騰訊QQ團隊將于12月4日開源一個服務開發(fā)運營框架被去，叫做毫秒服務引擎（Mass Service Engine in Cluster，MSEC）奖唯，它集RPC惨缆、名字發(fā)現(xiàn)服務、負載均衡丰捷、業(yè)務監(jiān)控坯墨、灰度發(fā)布、容量管理病往、日志管理捣染、Key-Value存儲于一體，目的是提高開發(fā)與運營的效率和質(zhì)量停巷。
毫秒服務引擎的創(chuàng)作沖動和構建經(jīng)驗耍攘，來自QQ后臺團隊超過10年的運營思考。它是一整套解決方案畔勤，但也可以拆分來使用其中的監(jiān)控蕾各、Key-Value存儲單品。
典型用戶群體
毫秒服務引擎非常容易搭建和上手庆揪，使用它式曲，初學者從零開始開發(fā)一個分布式后臺demo并運行起來，只需要2個小時缸榛×咝撸基本上是一個小時完成框架搭建，一個小時完成開發(fā)上線内颗，特別適合互聯(lián)網(wǎng)初創(chuàng)公司钧排。
功能與優(yōu)勢
模塊間訪問采用RPC的方式，開發(fā)者不用關注網(wǎng)絡與報文格式起暮，像寫單機程序一樣開發(fā)分布式服務卖氨。
- 負載自動均衡與容錯，對于單機故障负懦、局部網(wǎng)絡波動等狀況自動應對筒捺，服務高可用性。
- 支持C/C++纸厉、Java系吭、PHP語言，馬上還會推出支持Python語言颗品；如果選擇C/C++語言肯尺，支持協(xié)程沃缘，兼具開發(fā)和運行效率。
- Web化的管理界面则吟，在Web界面完成配置槐臀、發(fā)布、監(jiān)控氓仲、日志水慨、Key-Value存儲集群管理等所有操作。
- 需要復雜部署的服務器都采用Docker鏡像的方式安裝敬扛，使得部署與上手非常容易晰洒。
- 相比使用其他開源組件拼湊起來的解決方案，毫秒服務引擎更加的體系化啥箭，對團隊的規(guī)范更加到位谍珊。
毫秒服務引擎設計背景
對于互聯(lián)網(wǎng)服務后臺團隊，開發(fā)框架的選擇是非常關鍵的問題急侥，10年的海量服務經(jīng)驗和教訓使得我們團隊深刻認識到：
- 要盡早規(guī)范團隊的開發(fā)服務框架砌滞，避免到了后期，各種開發(fā)語言混雜缆巧、各類存儲組件充斥布持、重復編碼、每個模塊形態(tài)不統(tǒng)一陕悬、文檔缺失题暖、監(jiān)控癱瘓、人員離職造成大量信息丟失捉超，最后積重難返胧卤、痛苦不堪；
- 沒有框架來規(guī)范拼岳，團隊的隨意性就太大枝誊，合作效率就大打折扣，甚至于內(nèi)耗惜纸、反復的挖坑填坑叶撒，系統(tǒng)的成敗過于依靠人的意識和水平；
- 規(guī)范耐版，不能靠文檔祠够、不能靠勞動紀律、不能靠苦口婆心粪牲、不能靠人員意識古瓤、不能靠運動式的整頓，要靠技術框架上切實的限制與貼心保護。
如果有機會從零開始定義一個理想的開發(fā)框架落君，我們覺得需要考慮下面9點穿香。
- 同步編碼異步執(zhí)行。兼顧運行效率和編碼效率绎速，希望代碼寫起來是同步和順序的皮获，而執(zhí)行的時候是異步的。
- IDL/RPC朝氓。支持IDL（接口描述語言）和RPC魔市，減少網(wǎng)絡協(xié)議相關的重復工作，協(xié)議有比較好的擴展性赵哲；遠程調(diào)用友好且高效，做到覆蓋主要的開發(fā)語言君丁。
- LB枫夺。對服務間的調(diào)用選路進行統(tǒng)一的管理，對單機故障和網(wǎng)絡波動等常見情況有自動容錯绘闷，我們簡稱load balance（LB）橡庞。
- 存儲服務化。這個其實和開發(fā)框架關系不太緊密印蔗，這里提一下扒最，強調(diào)存儲應該有統(tǒng)一的組件且由專業(yè)的團隊運維，就像共有云一樣华嘹。
- 過載保護吧趣。框架必須有成熟自帶的過載保護機制耙厚，不需要業(yè)務開發(fā)人員關注或者關注很少强挫。
- 基礎的監(jiān)控和告警。RPC調(diào)用薛躬、機器的CPU/網(wǎng)絡活動俯渤、任務并發(fā)度、時延型宝、進程監(jiān)控和秒起等基礎信息八匠，要有上報、統(tǒng)計和告警趴酣，不需要業(yè)務開發(fā)人員關注梨树。
- 完整的業(yè)務流轉(zhuǎn)呈現(xiàn)。統(tǒng)一日志价卤，在一個地方能夠清晰的呈現(xiàn)某次業(yè)務處理過程的流轉(zhuǎn)詳細情況：經(jīng)過了哪些模塊間調(diào)用劝萤，調(diào)用參數(shù)是怎樣的，每個模塊處理的重要分支和結果是怎樣的慎璧，最好圖形化呈現(xiàn)。支持染色和不同的日志詳細級別拐迁。
- 中央總控窗宇。整個系統(tǒng)的配置和文檔等重要信息，例如每個模塊有哪些機器鳖谈，分布在哪些機房、容量冗余情況阔涉、模塊間調(diào)用關系缆娃、訪問控制的配置動態(tài)管理甚至電子流，都希望能統(tǒng)一在一個地方Web化的管理起來瑰排，并且與運營的系統(tǒng)是直接聯(lián)系直接生效的贯要。
- 云調(diào)度。容量的自動調(diào)度椭住。例如要進行某個運營活動需要大量的擴容崇渗，只需要把設備放進去，就能自動的擴縮容京郑。當某個城市機房故障宅广，能夠自動調(diào)度容量到其他城市。
毫秒服務引擎架構
整個系統(tǒng)由下面幾部分組成些举，如圖所示跟狱。
Web Console：整個系統(tǒng)的運營管理中心，包括：
Tomcat提供Web管理界面户魏，管理的數(shù)據(jù)保存在MySQL里驶臊。
LB是名字發(fā)現(xiàn)服務和負載均衡，remote_shell是遠程文件傳輸與遠程命令執(zhí)行服務绪抛。
Log服務器：提供業(yè)務Log的存儲和查詢服務资铡。Log存儲在MySQL表里。
Monitor服務器：提供業(yè)務上報信息的存儲和查詢服務幢码。業(yè)務上報信息存儲在內(nèi)存里笤休，推薦內(nèi)存8G~16G。定時dump到磁盤的方式防止數(shù)據(jù)掉電丟失症副。
業(yè)務運營服務器：部署開發(fā)框架和業(yè)務邏輯代碼店雅，處理業(yè)務請求。
key-value存儲服務：相對整個框架比較獨立贞铣，按需選用闹啦。
服務標準化運營
一套互聯(lián)網(wǎng)后臺服務的開發(fā)和運營涉及非常多的細節(jié)。
訪問其他服務模塊辕坝，服務端IP如何管理窍奋？網(wǎng)絡報文格式是怎樣的？
有哪些配置文件？ 用到哪些第三方的庫琳袄？
業(yè)務邏輯和基礎框架是如何分離的江场？
對外提供怎樣的網(wǎng)絡接口？怎么對外提供接口API和文檔窖逗？
運營機器上的安裝目錄準備怎么安排址否？ 有哪些運維腳本和工具？
應該監(jiān)控哪些指標碎紊？應該記錄哪些日志佑附？
還有很多…
上面種種細節(jié)，每個程序員實現(xiàn)起來都有不同的做法仗考。經(jīng)驗證明音同，如果后臺各個模塊沒有標準化和規(guī)范化，可能導致：同一個團隊開發(fā)的服務秃嗜，千差萬別千奇百怪瘟斜，負責運維的同事面對的多個模塊“長”的都不一樣，程序框架完全不一樣痪寻，安裝目錄亂七八糟，無法規(guī)乃洳眩化的高效運維橡类。
服務的質(zhì)量完全依賴團隊成員的技能和意識，有的成員可能會做得比較好芽唇，配置文件命名易懂顾画、文檔及時更新與代碼保持一致、有對服務做細致的監(jiān)控上報和日志記錄匆笤，提供了運維腳本研侣，但是也有的成員的工作讓人抓狂。
每當有團隊成員離職和工作交接炮捧，交接本身就是工作量很大庶诡，交接時間長，交接質(zhì)量不好咆课，文檔缺失末誓，很多信息在交接過程中丟失，運營事故往往頻發(fā)书蚪。
經(jīng)驗難以得到傳承喇澡，一塊石頭反復絆倒各個成員和業(yè)務模塊，運營事故雷同殊校、頻出晴玖，團隊挫折感倍增、服務可用性低下。
也曾經(jīng)有過做事比較規(guī)范的時候呕屎，但是這些規(guī)范通橙貌荆靠耳提面命、人口相傳榨惰，靠管理者運動式的整頓拜英，有時候管理焦點沒有持續(xù)跟進，或者隨著人員更替琅催，團隊又把這些寶貴的經(jīng)驗丟棄了居凶，變得無序。
所以服務標準化是后臺技術團隊組建開始的第一要務藤抡。
兩個誤區(qū)
誤區(qū)一：找?guī)讉€開源的組件用起來就好了唄侠碧。
- 通常的開源的組件，只是在某一方面上規(guī)范了服務缠黍，有的是規(guī)范了網(wǎng)絡調(diào)用弄兜，有的是規(guī)范了如何監(jiān)控，有的是規(guī)范了如何記錄遠程記錄瓷式，其實這還遠遠不夠替饿，例如配置文件、接口定義贸典、使用到的外部庫视卢、安裝目錄的結構等非常多的細節(jié)，必須統(tǒng)一管理廊驼、有唯一出處据过。
誤區(qū)二：你說的我都懂，我們團隊剛起步妒挎，業(yè)務需求多绳锅，時間緊，先野蠻生長酝掩，打破條條框框鳞芙，后面再規(guī)范再改。
- 一開始沒有標準化庸队，后面當代碼和模塊都多起來了积蜻，且都處于運營狀態(tài)，再改再標準化彻消，難度非常大竿拆，成本非常大，風險非常大宾尚；另外工欲善其事必先利其器丙笋，一開始就標準化好谢澈，其實可以讓業(yè)務跑的更快。
如何實現(xiàn)服務標準化御板？
首先锥忿，每個服務的配置都Web化、集中管理起來怠肋。
部署在哪些IP上钉答？
有且只有一個配置文件。
Protocol buffer的接口定義文件右蹦。
引用了哪些外部庫豹储？例如openssl颂翼。
業(yè)務邏輯和基礎框架分離，業(yè)務邏輯以插件形式提供呻疹。
然后刽锤，每個業(yè)務模塊部署的目錄結構都是確定的并思。
如上圖所示：
業(yè)務部署的目錄都是/msec/一級業(yè)務名/二級業(yè)務名宋彼；
都包含bin etc log 等幾個目錄音婶；
bin里面是啟停腳本、業(yè)務插件msec.so和外部庫（如果有）；
etc里面是配置文件config.ini螟深；
Log里面是本地的日志文件。
另外垢箕，程序員不能隨意打破上面的方式条获。例如臨時的另外搞一個自己配置文件什么的，他如果這樣做帅掘，那下次發(fā)布的時候目錄會被覆蓋，個性化的東西會被刪除掉修档。
后臺服務的RPC和路由管理
互聯(lián)網(wǎng)服務的后臺，硬件通常是由大量的廉價機器組成吱窝；軟件架構通常采取大系統(tǒng)小做、分而治之的思想迫靖。這就決定了業(yè)務邏輯涉及到大量的網(wǎng)路IO，同時單機故障系宜、網(wǎng)絡局部故障是運營的常態(tài)欠母。那么赏淌，RPC和路由管理就顯得尤其重要了。毫秒服務引擎為此提供了一個完整的解決方案辣卒。
RPC的概念其實出現(xiàn)已經(jīng)很久了掷贾，記得筆者讀大學的時候，接觸到RPC的概念荣茫，總覺得不重要想帅，多此一舉。
我掌握好Socket通信這個利器和TCP/IP協(xié)議族原理啡莉，什么功能不能實現(xiàn)港准？RPC就跟本地函數(shù)調(diào)用一樣寫代碼，確實開發(fā)效率比較高咧欣；我自己把Socket相關函數(shù)好好封裝一下浅缸，讓代碼復用起來，開發(fā)效率也很高魄咕。
不懂或者不關注網(wǎng)絡通信底層原理衩椒，光會函數(shù)調(diào)來調(diào)去，這樣的程序員太沒有出息了哮兰！
后來毛萌，筆者開始帶團隊，親身經(jīng)歷了一些團隊協(xié)作和IT服務運營過程中的故事喝滞，才發(fā)現(xiàn)RPC非常關鍵朝聋。如果沒有很好的實現(xiàn)RPC和路由管理，IT系統(tǒng)服務質(zhì)量會過度的依賴人的意識囤躁，而這個通常成本非常高、效果也不好荔睹。
毫秒服務引擎是怎么做的狸演？
首先，毫秒服務引擎將每個服務部署在哪些IP上這些信息集中管理起來僻他，即使是調(diào)用外部的非標準服務（我們叫異構服務）宵距，也需要將該外部服務的接口IP配置到毫秒服務引擎管理系統(tǒng)里。這樣涉及到的IP信息就不會散落在代碼和各種配置文件里了吨拗。
服務之間的調(diào)用满哪，統(tǒng)一采用CallMethod()函數(shù)的方式婿斥，避免代碼千奇百怪；按服務名字調(diào)用和接口名調(diào)用哨鸭。
RPC背后的路由算法對于單機故障民宿、網(wǎng)絡局部波動等異常活鹰，自動容錯。簡單的說志群，路由算法按一定的規(guī)則輪轉(zhuǎn)的選擇被調(diào)用模塊的接口機蛔钙，并統(tǒng)計過去一段時間的調(diào)用成功率、時延信息桑涎，根據(jù)這些信息調(diào)整該接口機被選擇到的比例。如果某個接口機故障了石洗，那么就不會發(fā)送請求給它，從而實現(xiàn)自動容錯紧显。
毫秒服務引擎框架本身讲衫，在RPC執(zhí)行的時候，就上報了很多基礎屬性和日志孵班，這樣保證了服務監(jiān)控和告警等運營措施不依賴與人的意識涉兽。下圖是叫做getMP3List這樣一個RPC調(diào)用的請求數(shù)和成功數(shù)，這些是不需要業(yè)務開發(fā)者工作就自動上報篙程。
每個請求有唯一ID來標識枷畏，通過該ID，毫秒服務引擎可以在框圖中直觀的呈現(xiàn)該請求經(jīng)過的模塊虱饿、模塊間的RPC名字等信息拥诡，這個同樣不需要業(yè)務開發(fā)者的工作就自動實現(xiàn)。
后臺服務的灰度發(fā)布與監(jiān)控
灰度發(fā)布和監(jiān)控是互聯(lián)網(wǎng)海量服務必備的兩大利器氮发，能夠極大提高后臺服務可用性和運營水平渴肉，背后的哲學是持續(xù)交付、用戶測試和盡在掌控爽冕。
在騰訊仇祭，有一個課程系列，叫做《海量服務之道》颈畸，包含十多門課程和方法論乌奇，是技術同事必修和必知必會的没讲，其中兩門課程就是《灰度發(fā)布》和《全方位監(jiān)控》。
筆者在加入騰訊QQ后臺團隊之前礁苗，曾經(jīng)在電信行業(yè)爬凑、金融行業(yè)做過幾年開發(fā)工作。剛進入騰訊時寂屏，覺得技術上很多地方讓人耳目一新贰谣。
后臺系統(tǒng)都是部署在非常多的廉價服務器上，每個人都會管理非常多的機器迁霎，讓人覺得很有成就感很富有考廉。
有比較精確的設備預算計算模型昌粤，每個服務器的性能在考慮容災冗余的前提下凄贩，通常被壓榨到剛剛好疲扎，負責人會深入的洞悉整個系統(tǒng)的性能椒丧、容災壶熏、柔性等方方面面。能負責一個海量的系統(tǒng)是很榮耀的一件事情帽哑。
沒有專職的測試人員，經(jīng)過開發(fā)者自測后她肯，灰度發(fā)布加詳細的監(jiān)控晴氨，主要的系統(tǒng)幾乎每兩周都會被發(fā)布一輪籽前，作為后臺技術人員肄梨，自己的工作直接影響數(shù)以億計的用戶众羡，有點手握核彈處于上帝視角的感覺粱侣。
監(jiān)控系統(tǒng)（我們內(nèi)部一個叫monitor的系統(tǒng)）真的是太方便了齐婴，一條條曲線直觀的展示整個系統(tǒng)運作的各種指標，如果有異常短信和電話就會響起來嚣州，讓人覺得一切盡在掌控该肴，有一種面對著大量儀表盤操控著航母游弋或者是戰(zhàn)斗機掛著核彈翱翔的感覺匀哄。
好了涎嚼，趕緊結束程序員意淫的美好感覺法梯，我想說的重點是：灰度發(fā)布和監(jiān)控真的是互聯(lián)網(wǎng)海量服務必備的兩大利器夜惭，能夠極大的提高后臺服務可用性和運營水平诈茧。
當然敢会，灰度發(fā)布不只是一部分一部分的發(fā)布新代碼鸥昏，監(jiān)控也不只是繪制曲線和告警短信那么簡單互广，這里面深究下去會有很多東西，背后的哲學是持續(xù)交付尤莺、用戶測試和盡在掌控颤霎。
說到這里順便給大家推薦一個Java架構方面的交流學習群：956011797晴音，點擊立即加入里面會免費分享一些資深架構師錄制的視頻錄像：有Spring锤躁，MyBatis系羞，Netty源碼分析椒振，高并發(fā)澎迎、高性能辑莫、分布式、微服務架構的原理袁铐，JVM性能優(yōu)化這些成為架構師必備的知識體系剔桨。還能領取免費的學習資源和前輩的面試經(jīng)驗和面試題洒缀，相信對于已經(jīng)工作和遇到技術瓶頸的碼友，在這個群里會有你需要的內(nèi)容饺饭。
毫秒服務引擎是怎么做的瘫俊？
灰度發(fā)布
在服務配置管理頁點擊“制定發(fā)布計劃”扛芽。
選擇這一次灰度要發(fā)布的目標機器和發(fā)布類型川尖。
在接下來的向?qū)е羞x擇正確版本的配置文件空厌、外部庫、業(yè)務插件等赋朦，這樣就完成了發(fā)布計劃的制作宠哄。
接著诽俯，點擊菜單 “運維->發(fā)布”暴区，可以查詢所有發(fā)布計劃，對于已經(jīng)發(fā)布的計劃伐割，可以做回滾操作隔心。點擊詳情可以查看發(fā)布計劃更詳細信息，并執(zhí)行發(fā)布须尚。
監(jiān)控
關于監(jiān)控耐床，在“RPC和路由管理”那里講得已經(jīng)比較詳細了撩轰，這里不贅述。只說明一下：除了RPC和框架本身自動上報的一些信息皆串，還支持業(yè)務自定義上報信息（例如我想上報第28級VIP用戶登錄的次數(shù)）恶复，且支持對于關鍵指標的波動谤牡、最大值翅萤、最小值設置告警流纹。
KV存儲集群的設計要點
Key-Value存儲系統(tǒng)疮蹦，是非常普遍的需求阵苇，幾乎每個在線的互聯(lián)網(wǎng)后臺服務都需要KV存儲绅项，我們團隊在KV存儲方面，經(jīng)歷過幾個時期掀亥，我自己深感要做好不容易妥色。
第一個時期搪花，很早期的時候，我們的數(shù)據(jù)存儲在MySQL表里嘹害，按照用戶賬號簡單的分庫分表撮竿，為了保證訪問高并發(fā)，利用每個MySQL服務器的內(nèi)存做數(shù)據(jù)緩存笔呀；主備兩套分布在不同IDC幢踏，業(yè)務邏輯自己做副本同步。當時主要的問題是：內(nèi)存的數(shù)據(jù)結構擴展困難许师、運維工作瑣碎惨驶、數(shù)據(jù)同步機制本身的缺陷導致不能做異地IDC部署攻臀，這些缺點對于業(yè)務飛速發(fā)展设联、一地機房已經(jīng)不夠用的局面非常被動宫蛆。
第二個時期，我們設計了新的KV存儲系統(tǒng)，其用戶數(shù)據(jù)結構容易擴展震庭、具備可以多地部署的數(shù)據(jù)同步機制氓栈，很好的應對了新時期業(yè)務發(fā)展的需要提完。為了設備成本考慮打肝，我們把數(shù)據(jù)做冷熱分離妄讯，訪問頻繁的數(shù)據(jù)會加載到專門的Cache層，且對于不同的訪問模型，掛載不同架構的Cache介杆，另外一個File層專門做數(shù)據(jù)持久化臭胜。這樣的設計胳徽，使得架構太復雜箫爷，bug收斂速度慢柱徙，運維工作相比以前甚至更復雜了弧岳。
第三個時期乐设，為了應對普遍的KV存儲需求，我們以公共組件的形式重新設計了KV存儲帝牡，作為團隊標準的組件之一娘香，得到了大規(guī)模的應用歇式。結合同期抽象出來的邏輯層框架、路由管理等其他組件恭应，團隊的公共基礎組件和運維設施建設的比較完備了，整個業(yè)務的開發(fā)和運維實現(xiàn)了標準化冷离。但這個階段就用了我們團隊足足2年多時間。
不同于無數(shù)據(jù)的邏輯層框架，KV存儲系統(tǒng)的架構設計會更復雜易结、運維工作更繁瑣、運營過程中可能出現(xiàn)的狀況更多柜候、bug收斂時間會更長搞动。一句話：團隊自己做一個KV存儲系統(tǒng)是成本很高的，而且也有比較高的技術門檻渣刷。
設計一個KV存儲鹦肿，需要考慮至少這些方面。
如何組織機器的存儲介質(zhì)辅柴，通常是內(nèi)存箩溃、磁盤文件；例如用hash的方式組織內(nèi)存碌嘀。
如何設計用戶的數(shù)據(jù)結構涣旨，使得通用、易于擴展股冗、存儲利用率高霹陡；例如PB序列化、Json魁瞪、XML方式穆律。
友好的訪問接口惠呼，而不只是get/set一整個value导俘。
如何做集群分布、如何sharding剔蹋、如何做到方便的擴縮容旅薄；例如一致性hash算法。
如何做數(shù)據(jù)冗余、副本間如何同步少梁、一致性問題洛口；副本間如何選舉master。
備份與恢復凯沪、數(shù)據(jù)校驗與容錯第焰。
讀寫性能。
其他可能的特殊需求：例如我們設計過一個KV存儲妨马，用于存儲一些公眾號的個數(shù)不受限粉絲列表挺举。
上面8點，業(yè)內(nèi)的KV存儲組件一般都會考慮到烘跺，或者各有特色湘纵，各自優(yōu)勢在伯仲之間。但是綜合過去的經(jīng)驗教訓滤淳，我們覺得有一點很容易被忽視：可運維性梧喷、運維自動化、黑盒化運維脖咐。
舉一個例子铺敌，前面提到的我們第二個時期的KV存儲系統(tǒng)，剛開始應用的時候屁擅，一次擴容過程會有10多步的運維操作适刀，包括load數(shù)據(jù)、做增量同步煤蹭、多次修改機器狀態(tài)笔喉、數(shù)據(jù)比對等等，需要運維同事以高度的責任心來完成硝皂。另外就是運維同事必須如該KV存儲架構設計者一樣深刻理解系統(tǒng)背后的原理和細節(jié)常挚，否則就不能很好的執(zhí)行運維操作，這個要求也非常高稽物，新老交接周期長奄毡，還容易出運維事故。
基于上面的考慮贝或，同事為了讓用戶更容易學習和接受吼过，毫秒服務引擎在Redis Cluster的基礎上，實現(xiàn)了運維Web化咪奖，并加上了集群的監(jiān)控盗忱。
通過Web界面方便進行
集群概要狀態(tài)查看。
可以在Web上方便的完成日常的運維操作：新搭集群羊赵、擴縮容趟佃、故障機器的恢復。
請求量、內(nèi)存使用闲昭、CPU等各種狀態(tài)信息可直觀監(jiān)控罐寨，也可以按IP粒度查看。
讀者福利
針對于上面的文章我總結出了互聯(lián)網(wǎng)公司java程序員面試涉及到的絕大部分面試題及答案做成了文檔和架構視頻資料免費分享給大家（包括Dubbo序矩、Redis鸯绿、Netty、zookeeper簸淀、Spring cloud楞慈、分布式、高并發(fā)等架構技術資料）啃擦，希望能幫助到您面試前的復習且找到一個好的工作囊蓝，也節(jié)省大家在網(wǎng)上搜索資料的時間來學習。
資料獲取方式：加qun群：956011797 找管理小姐姐免費獲攘铗取聚霜！
合理利用自己每一分每一秒的時間來學習提升自己，不要再用"沒有時間“來掩飾自己思想上的懶惰珠叔！趁年輕蝎宇，使勁拼，給未來的自己一個交代祷安！
