我對(duì)架構(gòu)定義的理解

大概在7~8年前懂鸵，我曾經(jīng)有一個(gè)美國(guó)對(duì)口的架構(gòu)師導(dǎo)師，他對(duì)我講架構(gòu)其實(shí)是發(fā)現(xiàn)利益相關(guān)者（stakeholder）行疏，然后解決他們的關(guān)注點(diǎn)（concerns）匆光，后來我讀到一本書《軟件系統(tǒng)架構(gòu):使用視點(diǎn)和視角與利益相關(guān)者合作》，里面提到的理念也是這樣說：系統(tǒng)架構(gòu)的目標(biāo)是解決利益相關(guān)者的關(guān)注點(diǎn)酿联。

這是從那本書里頭的一張截圖终息，我之前公司分享架構(gòu)定義常常用這張圖，架構(gòu)是這樣定義的：

1.每個(gè)系統(tǒng)都有一個(gè)架構(gòu)

2.架構(gòu)由架構(gòu)元素以及相互之間的關(guān)系構(gòu)成

3.系統(tǒng)是為了滿足利益相關(guān)者（stakeholder）的需求而構(gòu)建的

4.利益相關(guān)者都有自己的關(guān)注點(diǎn)（concerns）

5.架構(gòu)由架構(gòu)文檔描述

6.架構(gòu)文檔描述了一系列的架構(gòu)視角

7.每個(gè)視角都解決并且對(duì)應(yīng)到利益相關(guān)者的關(guān)注點(diǎn)贞让。

架構(gòu)系統(tǒng)前周崭，架構(gòu)師的首要任務(wù)是盡最大可能找出所有利益相關(guān)者，業(yè)務(wù)方喳张，產(chǎn)品經(jīng)理续镇，客戶/用戶，開發(fā)經(jīng)理销部，工程師摸航，項(xiàng)目經(jīng)理，測(cè)試人員舅桩，運(yùn)維人員酱虎，產(chǎn)品運(yùn)營(yíng)人員等等都有可能是利益相關(guān)者，架構(gòu)師要充分和利益相關(guān)者溝通擂涛，深入理解他們的關(guān)注點(diǎn)和痛點(diǎn)读串，并出架構(gòu)解決這些關(guān)注點(diǎn)。

架構(gòu)師常犯錯(cuò)誤是漏掉重要的利益相關(guān)者，溝通不充分恢暖，都會(huì)造成架構(gòu)有欠缺排监，不能滿足利益相關(guān)者的需求。利益相關(guān)者的關(guān)注點(diǎn)是有可能沖突的杰捂，比如管理層（可管理性）vs技術(shù)方（性能）社露，業(yè)務(wù)方（多快好省）vs 技術(shù)方（可靠穩(wěn)定）琼娘，這需要架構(gòu)師去靈活平衡峭弟，如何平衡體現(xiàn)了架構(gòu)師的水平和價(jià)值。

關(guān)于架構(gòu)的第二點(diǎn)定義是說架構(gòu)主要關(guān)注非功能性需求（non-functional requirements）脱拼，即所謂的-abilities瞒瘸。

這個(gè)是我上次公司內(nèi)分享的一個(gè)圖。

這個(gè)是slideshare一個(gè)ppt里頭截取的熄浓，兩個(gè)圖都是列出了架構(gòu)的非功能性關(guān)注點(diǎn)情臭；關(guān)于架構(gòu)的水平該如何衡量，去年我看到一句話赌蔑，對(duì)我影響很大俯在。

Architecture represents the significant design decisions that shape a system, where significant is measured by cost of change.

翻譯為中文就是，架構(gòu)表示對(duì)一個(gè)系統(tǒng)的成型起關(guān)鍵作用的設(shè)計(jì)決策娃惯，架構(gòu)定系統(tǒng)基本就成型了跷乐，這里的關(guān)鍵性可以由變化的成本來決定。這句話是Grady Booch說的趾浅，他是UML的創(chuàng)始人之一愕提。

進(jìn)一步展開講，架構(gòu)的目標(biāo)是用于管理復(fù)雜性皿哨、易變性和不確定性浅侨，以確保在長(zhǎng)期的系統(tǒng)演化過程中，一部分架構(gòu)的變化不會(huì)對(duì)架構(gòu)的其它部分產(chǎn)生不必要的負(fù)面影響证膨。這樣做可以確保業(yè)務(wù)和研發(fā)效率的敏捷如输，讓應(yīng)用的易變部分能夠頻繁地變化，對(duì)應(yīng)用的其它部分的影響盡可能的小央勒。

我剛?cè)胲浖_發(fā)這個(gè)行業(yè)之初不见，談的架構(gòu)主要是性能，高可用等等《┩幔現(xiàn)在脖祈，見過無數(shù)遺留系統(tǒng)肆捕，特別是國(guó)內(nèi)企業(yè)IT的現(xiàn)狀刷晋，無數(shù)高耦合的遺留系統(tǒng)，不良的架構(gòu)像手銬一樣牢牢地限制住業(yè)務(wù)，升級(jí)替換成本非常巨大眼虱， 所以我更加關(guān)注可理解喻奥，可維護(hù)性，可擴(kuò)展性捏悬，成本 撞蚕。我想補(bǔ)充一句，創(chuàng)業(yè)公司創(chuàng)業(yè)之初獲得好的架構(gòu)師或技術(shù)CTO非常重要过牙。

架構(gòu)的迭代和演化性

我是屬于老一代的架構(gòu)師甥厦，99年參加工作。職業(yè)初學(xué)了很多RUP寇钉，統(tǒng)一軟件過程的理念刀疙。RUP的理念對(duì)我的架構(gòu)有很深的影響，RUP總結(jié)起來就是三個(gè)特點(diǎn)：

1.用例和風(fēng)險(xiǎn)驅(qū)動(dòng)Use Case and risk driven

2.架構(gòu)中心Architecture centric

3.迭代和增量Iterative and incremental

RUP很注重架構(gòu)扫倡，提倡以架構(gòu)和風(fēng)險(xiǎn)驅(qū)動(dòng)谦秧，項(xiàng)目開始一定要做端到端的原型（prototype）；通過壓測(cè)驗(yàn)證架構(gòu)可行性撵溃，然后在原型基礎(chǔ)上持續(xù)迭代和增量式開發(fā)疚鲤，開發(fā)->測(cè)試->調(diào)整架構(gòu)->開發(fā)，循環(huán)缘挑，如下圖所示：

從上圖可以看出架構(gòu)師要盡可能寫代碼集歇，做測(cè)試，紙上談兵式做架構(gòu)而后丟給團(tuán)隊(duì)的作法非常不靠譜（除非是已經(jīng)非常清晰成熟的領(lǐng)域）语淘。另外鬼悠，做技術(shù)架構(gòu)的都有點(diǎn)完美主義傾向，一開始往往喜歡求大求全亏娜，忽視架構(gòu)的演化和迭代性焕窝，這種傾向易造產(chǎn)品和用戶之間不能形成有效快速的反饋，產(chǎn)品不滿足最終用戶需求维贺，繼續(xù)看下面兩個(gè)圖：

第一個(gè)圖是講最小可用產(chǎn)品（Minimum Viable Product它掂， MVP）理念，做出最小可用產(chǎn)品溯泣，盡快丟給用戶試用虐秋，快速獲取客戶反饋，在此基礎(chǔ)上不斷迭代和演化架構(gòu)和產(chǎn)品垃沦。

第二個(gè)圖是過度工程（Over Engineering）的問題客给，其實(shí)也是講產(chǎn)品架構(gòu)和用戶之間沒有形成有效的反饋閉環(huán)，架構(gòu)師想的和客戶想的不在一個(gè)方向上肢簿，通過最小可用產(chǎn)品靶剑，快速迭代反饋的策略蜻拨，可以避免這種問題。

注意桩引，在系統(tǒng)真正地投入生產(chǎn)使用之前缎讼，再好的架構(gòu)都只是假設(shè)，產(chǎn)品越晚被使用者使用坑匠，失敗的成本和風(fēng)險(xiǎn)就越高血崭，而小步行進(jìn)，通過MVP快速實(shí)驗(yàn)厘灼，獲取客戶反饋夹纫，迭代演化產(chǎn)品，能有效地減少失敗的成本和風(fēng)險(xiǎn)设凹。

在這里順便給大家推薦一個(gè)架構(gòu)交流群：948368769捷凄，里面會(huì)分享一些資深架構(gòu)師錄制的視頻錄像：有Spring，MyBatis围来，Netty源碼分析跺涤，高并發(fā)、高性能监透、分布式桶错、微服務(wù)架構(gòu)的原理，JVM性能優(yōu)化這些成為架構(gòu)師必備的知識(shí)體系胀蛮。還能領(lǐng)取免費(fèi)的學(xué)習(xí)資源院刁。相信對(duì)于已經(jīng)工作和遇到技術(shù)瓶頸的碼友，在這個(gè)群里會(huì)有你需要的內(nèi)容粪狼。

另外退腥，多年的經(jīng)驗(yàn)告訴我，架構(gòu)再榄，平臺(tái)不是買來的狡刘，也不是用一個(gè)開源就能獲得的，也不是設(shè)計(jì)出來困鸥，而是長(zhǎng)期演化才能落地生根的嗅蔬。

構(gòu)建閉環(huán)反饋架構(gòu)

先分享一個(gè)鏈接，這幾年對(duì)我架構(gòu)影響最深的一篇文章疾就。這篇文章是關(guān)于DevOps的澜术，但對(duì)系統(tǒng)架構(gòu)同樣適用：

http://itrevolution.com /the- three- ways- principles- underpinning- devops/

這篇文章講述了企業(yè)通向DevOps的三條必經(jīng)之路，我們來看看這三條道路對(duì)架構(gòu)師的啟示猬腰。

第一條道路鸟废，系統(tǒng)思維，開發(fā)驅(qū)動(dòng)的組織機(jī)體姑荷，其能力不是制作軟件盒延，而是持續(xù)的交付客戶價(jià)值缩擂，架構(gòu)師需要有全局視角和系統(tǒng)思維（System Thinking），深入理解整個(gè)價(jià)值交付鏈兰英，從業(yè)務(wù)需求撇叁、研發(fā)供鸠、測(cè)試畦贸、集成，到部署運(yùn)維楞捂，這條價(jià)值鏈的效率并不依賴于單個(gè)或者幾個(gè)環(huán)節(jié)薄坏，局部?jī)?yōu)化的結(jié)果往往是全局受損，架構(gòu)師要站在系統(tǒng)高度去優(yōu)化整個(gè)價(jià)值交付鏈寨闹，讓企業(yè)和客戶之間形成快速和高效的價(jià)值傳遞胶坠。

第二條道路，強(qiáng)化反饋環(huán)繁堡，任何過程改進(jìn)的目標(biāo)都是加強(qiáng)和縮短反饋環(huán)沈善。剛?cè)胄械墓こ處煟彩侵袊?guó)學(xué)生的普遍問題椭蹄，就是生產(chǎn)運(yùn)維意識(shí)不足（監(jiān)控是系統(tǒng)反饋的重要環(huán)節(jié)）闻牡。有兩句話是這樣講的：

1.no measurement, no improvement沒有測(cè)量，就沒有改進(jìn)和提升

2.What your measure is what you get你測(cè)量什么绳矩，就得到什么

沒有監(jiān)控或者監(jiān)控不完善的系統(tǒng)相當(dāng)于裸奔罩润，開車上高速無儀表盤。有一篇很不錯(cuò)的關(guān)于測(cè)量驅(qū)動(dòng)開發(fā)的文章翼馆，在InfoQ上的割以，向大家推薦：

http://www.infoq.com /cn/ articles /metrics -driven- development

這篇文章提出了度量驅(qū)動(dòng)開發(fā)的理念，即所謂MDD应媚，在系統(tǒng)严沥，應(yīng)用和業(yè)務(wù)三個(gè)層次，通過三級(jí)監(jiān)控中姜，構(gòu)建三個(gè)反饋環(huán)祝峻，在監(jiān)控測(cè)量基礎(chǔ)上持續(xù)改進(jìn)系統(tǒng)和架構(gòu)，我最近也在參考這個(gè)理念設(shè)計(jì)一個(gè)電商平臺(tái)的技術(shù)架構(gòu)扎筒，見下圖：

這是一個(gè)電商平臺(tái)的架構(gòu)莱找，整個(gè)體現(xiàn)了閉環(huán)架構(gòu)的思想，右側(cè)是整個(gè)平臺(tái)的反饋監(jiān)控環(huán)節(jié)嗜桌。具體如下：

1.系統(tǒng)層監(jiān)控計(jì)算網(wǎng)絡(luò)存儲(chǔ)奥溺，構(gòu)建系統(tǒng)層的反饋環(huán)

2.應(yīng)用服務(wù)層，監(jiān)控業(yè)務(wù)骨宠、應(yīng)用浮定、服務(wù)相满，甚至整個(gè)研發(fā)流程，構(gòu)建應(yīng)用和服務(wù)層的反饋環(huán)

3.客戶體驗(yàn)層桦卒，監(jiān)控端用戶和分析網(wǎng)站用戶的行為立美，構(gòu)建和客戶的反饋環(huán)

下面這個(gè)圖展示了系統(tǒng)提升和改進(jìn)的一般方法：

收集->測(cè)量->調(diào)整->閉環(huán)重復(fù)，在有測(cè)量數(shù)據(jù)和反饋的基礎(chǔ)上方灾，系統(tǒng)建蹄、應(yīng)用、流程和客戶體驗(yàn)才有可能獲得持續(xù)的提升和改善裕偿，否則沒有數(shù)據(jù)的所謂改進(jìn)只能靠拍腦袋或者說猜測(cè)洞慎。

第三條道路，鼓勵(lì)勇于承擔(dān)責(zé)任嘿棘，冒險(xiǎn)試錯(cuò)和持續(xù)提升的文化劲腿。這點(diǎn)是最難的，一般和企業(yè)人才密度有關(guān)鸟妙。工具焦人，技術(shù)，流程只是一個(gè)公司的冰山浮出水面的部分重父，而真正對(duì)企業(yè)效能影響大的則是冰山水下的部分花椭，即企業(yè)的人和文化，架構(gòu)師作為技術(shù)和架構(gòu)的布道者坪郭，有責(zé)任義務(wù)鼓勵(lì)和推動(dòng)試錯(cuò)文化个从。

架構(gòu)師要深入領(lǐng)會(huì)這三條道路，關(guān)注整個(gè)價(jià)值交付鏈的效率歪沃，關(guān)注每個(gè)環(huán)節(jié)的閉環(huán)反饋嗦锐，鼓勵(lì)和推動(dòng)公司的試錯(cuò)文化，打造全系統(tǒng)的閉環(huán)架構(gòu)（Architecting for closed loop feedback）沪曙，提升整個(gè)系統(tǒng)效能奕污。下圖的DevOps和每日交付是每一個(gè)互聯(lián)網(wǎng)系統(tǒng)架構(gòu)師的夢(mèng)想和努力的方向。

談?wù)勎⒎?wù)架構(gòu)

微服務(wù)我想大家都聽得很多了液走，我本人也非常關(guān)注和推崇微服務(wù)碳默，從技術(shù)角度講，我認(rèn)為微服務(wù)主要體現(xiàn)的是單一職責(zé)和關(guān)注分離的思想缘眶，從單進(jìn)程模塊化進(jìn)一步拓展到跨進(jìn)程分布式的模塊化嘱根。微服務(wù)是獨(dú)立的開發(fā)、測(cè)試巷懈、部署和升級(jí)單元该抒，正如我在第一點(diǎn)架構(gòu)定義中提到的，微服務(wù)中每個(gè)服務(wù)可以獨(dú)立演變顶燕，它的cost of change比較小凑保，整體架構(gòu)比較靈活冈爹，是一種支持創(chuàng)新的演化式架構(gòu)。

去年MartinFowler寫了兩篇文章欧引，給微服務(wù)潑冷水的频伤，建議大家好好讀下。

1.http://martinfowler.com /bliki /MicroservicePrerequisites.html

2.http://martinfowler.com /bliki /MicroservicePremium.html

這個(gè)圖講什么時(shí)候該引入微服務(wù)芝此。微服務(wù)有額外成本的憋肖，需要搭建框架、發(fā)布癌蓖、監(jiān)控等基礎(chǔ)設(shè)施瞬哼。初創(chuàng)和小規(guī)模團(tuán)隊(duì)不建議采用婚肆。主要決定是因素系統(tǒng)復(fù)雜性和團(tuán)隊(duì)規(guī)模租副，當(dāng)?shù)竭_(dá)一個(gè)點(diǎn)，單塊架構(gòu)嚴(yán)重影響效率才考慮 较性。另外補(bǔ)充一點(diǎn)用僧，微服務(wù)更多是關(guān)于組織和團(tuán)隊(duì)，而不是技術(shù)赞咙。

架構(gòu)和組織文化關(guān)系

再談一下康威定律：

Conway’s law: Organizations which design systems [...] are constrained to produce designs which are copies of the communication structures of these organizations.

（設(shè)計(jì)系統(tǒng)的組織责循，其產(chǎn)生的設(shè)計(jì)和架構(gòu)等價(jià)于組織間的溝通結(jié)構(gòu)。 )

從單塊架構(gòu)到微服務(wù)架構(gòu)是這個(gè)定律的很好體現(xiàn)攀操。

團(tuán)隊(duì)是分布式的院仿，系統(tǒng)架構(gòu)是單塊的，開發(fā)速和，測(cè)試歹垫，部署協(xié)調(diào)溝通成本大，嚴(yán)重影響效率颠放，嚴(yán)重時(shí)團(tuán)隊(duì)之間還容易起沖突排惨。

將單塊架構(gòu)解耦成微服務(wù)，每個(gè)團(tuán)隊(duì)開發(fā)碰凶，測(cè)試和發(fā)布自己負(fù)責(zé)的微服務(wù)暮芭，互不干擾，系統(tǒng)效率得到提升欲低。

可見辕宏，組織和系統(tǒng)架構(gòu)之間有一個(gè)映射關(guān)系（1 ~ 1 mapping），兩者不對(duì)齊就會(huì)出各種各樣的問題砾莱，一方面瑞筐，如果你的組織結(jié)構(gòu)和文化結(jié)構(gòu)不支持，你也無法成功建立高效的系統(tǒng)架構(gòu)恤磷，例如集中式和嚴(yán)格職能（業(yè)務(wù), Dev, QA, Deployment, Ops）的企業(yè)面哼，很難推行微服務(wù)和DevOps野宜，推行Docker/PaaS平臺(tái)也會(huì)比較困難，這樣的組織職能之間都傾向于局部?jī)?yōu)化（local optimization）魔策，無法形成有效的合作和閉環(huán)匈子。

反過來也是成立的，如果你的系統(tǒng)設(shè)計(jì)或者架構(gòu)不支持闯袒，那么你就無法成功建立一個(gè)有效的組織虎敦；作為系統(tǒng)架構(gòu)師，一定要深入領(lǐng)會(huì)康威定律政敢，設(shè)計(jì)系統(tǒng)架構(gòu)之前其徙，先看清組織結(jié)構(gòu)，也要看組織文化（民主合作式喷户，集權(quán)式唾那，叢林法則式，人才密度）褪尝，再根據(jù)情況調(diào)整系統(tǒng)架構(gòu)或者組織架構(gòu)闹获。

架構(gòu)師心態(tài)和軟技能

空杯，或者說開放心態(tài)（open minded）是一個(gè)成熟架構(gòu)師的應(yīng)有心態(tài)河哑，stay hungry, stay foolish避诽， 心態(tài)有多開放，視野就有多開闊璃谨。來自《高效能人士的七個(gè)習(xí)慣~史蒂芬~柯維》的一句話送給每一個(gè)架構(gòu)師 :

如果一位具有相當(dāng)聰明才智的人跟我意見不同沙庐，那么對(duì)方的主張必有我尚未體會(huì)的奧秘，值得加以了解佳吞。與人合作最重要的是拱雏，重視不同個(gè)體的不同心理、情緒與智能容达，以及個(gè)人眼中所見的不同世界古涧。與所見略同的人溝通，益處不大花盐，要有分歧才有收獲羡滑。

另外再推薦一個(gè)本書《軟件架構(gòu)師的12項(xiàng)修煉》，這書中三個(gè)觀點(diǎn)很值得每個(gè)架構(gòu)師學(xué)習(xí)領(lǐng)會(huì):

1.soft skills are always hard than hard skills算芯，軟技能比硬技能難

2.choosing relationship over correctness 柒昏，注重關(guān)系重于誰(shuí)對(duì)誰(shuí)錯(cuò)

3.架構(gòu)的政治性，在中大型公司里工作的架構(gòu)師尤其要學(xué)習(xí)

政治指的是和他人協(xié)作將事情搞定的藝術(shù)熙揍，架構(gòu)是一種社交活動(dòng)职祷，在技術(shù)的世界里，個(gè)人主義很容易被打敗，即使你的目的是好的技術(shù)是最優(yōu)的有梆，技術(shù)決策是政治決策（technical decisions are political decisions）是尖，一個(gè)技術(shù)產(chǎn)品，一波人可以做泥耀，另一波人也可以做饺汹，到底誰(shuí)做的好，真不好說痰催，不管誰(shuí)做兜辞，都給業(yè)務(wù)套上了一副手銬。

架構(gòu)師如何提升夸溶？實(shí)戰(zhàn)逸吵，實(shí)戰(zhàn)，實(shí)戰(zhàn)缝裁！規(guī)劃職業(yè)扫皱，找好的團(tuán)隊(duì)和項(xiàng)目，總結(jié)分享压语，學(xué)習(xí)GitHub開源項(xiàng)目啸罢，盡可能參與和開創(chuàng)自己的開源項(xiàng)目和產(chǎn)品编检，并長(zhǎng)期積累胎食。

我對(duì)一些架構(gòu)師爭(zhēng)議主題的看法

主要爭(zhēng)議是兩個(gè)話題：

1.技術(shù)和業(yè)務(wù)的關(guān)系。

2.架構(gòu)師要寫代碼嗎允懂？

架構(gòu)師怎么回答這類問題厕怜？一個(gè)成熟架構(gòu)師的口頭禪：視情況而定，不一定蕾总，是也不是粥航，it depends。技術(shù)和業(yè)務(wù)生百，架構(gòu)師要理解業(yè)務(wù)嗎递雀？看產(chǎn)品和客戶，如果是業(yè)務(wù)性產(chǎn)品蚀浆，肯定要理解業(yè)務(wù)缀程，如果是技術(shù)型產(chǎn)品，就不一定市俊。

架構(gòu)師要寫代碼杨凑？也不一定，個(gè)人覺得盡可能要寫摆昧，如果你寫過十年以上代碼了撩满，每年不少于2萬(wàn)行，都玩通了，可以不寫伺帘。另外架構(gòu)師如果寫代碼昭躺，要把控度，不要一頭鉆入代碼伪嫁，花大量時(shí)間解決細(xì)節(jié)和復(fù)雜性問題窍仰，忽視全局和系統(tǒng)性問題。

最后

我想說中國(guó)現(xiàn)在的互聯(lián)網(wǎng)發(fā)展趨勢(shì)很好礼殊，越來越多的人加入架構(gòu)師這個(gè)行業(yè)驹吮，這個(gè)行業(yè)正在“萬(wàn)物生長(zhǎng)”。 但是我們現(xiàn)在還沒有馬丁福勒晶伦，adrian cockcroft這樣的架構(gòu)牛人物碟狞，我輩需不斷努力，期待中國(guó)10~20年后出現(xiàn)超過十個(gè)馬丁福勒婚陪，adrian cockcroft這樣的大牛神級(jí)人物族沃。我們必不可停止探索，而一切探索的盡頭泌参，就是重回起點(diǎn)脆淹，并對(duì)起點(diǎn)有首次般的認(rèn)識(shí)。

主人公介紹

具有超過10年的互聯(lián)網(wǎng)分布式系統(tǒng)研發(fā)和架構(gòu)經(jīng)驗(yàn)沽一，曾先后就職于：eBay中國(guó)研發(fā)中心（eBay CDC）盖溺，任資深研發(fā)工程師，參與億貝開放API平臺(tái)研發(fā)铣缠，攜程旅游網(wǎng)（Ctrip）烘嘱，任技術(shù)研發(fā)總監(jiān)，主導(dǎo)攜程大規(guī)模SOA體系建設(shè)蝗蛙，唯品會(huì)（VIPShop）蝇庭，任資深云平臺(tái)架構(gòu)師，負(fù)責(zé)容器PaaS平臺(tái)的調(diào)研和架構(gòu)捡硅，目前就職于法國(guó)LVMH集團(tuán)中國(guó)區(qū)的垂直電商部門哮内，任職電商首席架構(gòu)師，幫助傳統(tǒng)IT向互聯(lián)網(wǎng)轉(zhuǎn)型壮韭。

架構(gòu)師之路（思維導(dǎo)圖如下）

今天免費(fèi)分享 免費(fèi)分享北发！

要求：轉(zhuǎn)發(fā)，轉(zhuǎn)發(fā)泰涂，轉(zhuǎn)發(fā)鲫竞！

轉(zhuǎn)發(fā)后：加我的裙 ：948368769即可獲取架構(gòu)師之路（思維導(dǎo)圖里面的資源)

猪落，獻(xiàn)給還在迷惘中的你寞秃，需要的朋友不要錯(cuò)過了哦秃殉。

（本學(xué)習(xí)資料只分享給2-10年Java開發(fā)工作的朋友，小白 學(xué)生繞道 謝謝配合）