大家是否思考過，為什么大部分程序員很難真正成為一個架構師?

他們很多也是好的大學，計算機科班專業畢業，計算機基礎知識技能沒有任何問題，工作也足夠的努力，但是仍然很多人無法真正成為一個合格的架構師。

從學徒到工匠，從工匠到大師，難的往往就是層層躍遷的質變點。而真正影響這個質變點的，仍然是你個人獨立解決問題的能力，思維能力的培養。

認知升級-從外到內，從現象到抽象

我前面經常會舉對汽車觀察認知的例子。即使大部分人實際并不會去關心汽車內部結構和汽車的運行機理，只需要知道汽車的外部組成，知道如何讓汽車動起來就足夠了。

這個有沒有錯?

說實話，這個在大部分場景下并沒有發生過。

人的精力是有限的，你不可能對所有的新事物，新問題都去刨根究底，搞清事物內在本質。但是回到你自己的專業領域就不一樣的。

當面對你自己的專業領域的時候，一定要從浪漫派轉變為古典派，要去挖掘事物內在本質和運作機理。只有這樣你才可能抽象普適性的規律，在后續新問題解決中去應用。

當你深入問題內部的時候，自然將專業知識的廣度轉變為了知識的深度。

而知識深度對你來說才是最有價值的。

一個人能夠解決復雜問題，往往僅僅是因為自己見過，而不是因為本身具備了問題分析和匹配的能力。

對于這類人當面臨一個全新的領域，全新的問題的時候往往無從下手。

因為沒有掌握一種在自己專業領域普適性的問題分析和解決方法。

拿企業的業務流程來說，這些流程千變萬化，但是當流程分解后你會發現，所有的流程都是由底層的200到300個原子業務活動組裝出來的。對于某一類技術問題同樣道理，雖然你面對問題都不相同，但是分解后都是共性的原子能力。

一個問題的解決往往涉及三個方面。

• 問題的定義，目標的分解
• 你已有的原子能力儲備
• 利用原子能力去匹配并向上整合解決問題

你會發現問題分解并沒太多難度，真正的難點是在你原子可復用能力的儲備，其二是這些能力究竟應該如何組合。

如何提升這個能力呢?

其一就是每當你解決一個新問題后，你會通過復盤去思考，解決這個問題的方法中應該拆分哪些可復用的經驗點。

其二是養成周期性深度復盤的習慣，即定期的會回顧是否出現過類似的場景或問題，這些問題群或問題列表，我會作為一個問題域來研究，去抽象這類問題分析解決的通用思路。找尋問題抽象后的本質屬性。

比如我前面談到過性能問題的解決問題。

當你經常面對業務系統性能問題需要解決的時候，你會發現類似JVM內存模型，查找內存泄漏方法工具，Linux進程和常用分析命令等都需要學習。你也會發現影響到性能了包括了硬件資源，數據庫，中間件，應用程序，數據量諸多原因。

通過周期性復盤你才會形成一個通用的性能問題分析和診斷模型。

而不是一遇到性能問題就去重啟服務器。

對于軟件開發來說，為何經常會強調去研究和學習一些主流開源軟件的源代碼，也是同樣的道理。程序員要走向架構師，一定要從軟件開發表象走向內在原理和運作機制的研究，知其然并知其所以然。

很多程序員為何每天都在做簡單的CRUD增刪改查功能，原因也是相同的。大部分人并不去思考事物的內在運行本質。

一個最簡單的CRUD功能也涉及到開發框架和基礎類庫，那么能否對這些內容進行研究，了解一個軟件功能實現出來的內部原理。同樣，任何一個CRUD功能也涉及到高可用和高性能，那么能否對相關的數據結構和算法進一步研究等。

在多年前我當項目經理的時候，對團隊里面的開發人員進行觀察，也是同樣的道理。

一個大的業務系統往往分解為了多個業務功能模塊，但是大部分人往往只熟悉自己的功能模塊，對其它模塊一無所知。而少量的人往往是自己花時間去熟悉整個系統，熟悉自己主管的各個模塊，并去了解各個模塊之間的協同關系。

跳出盒子很多時候不是技術問題，而是思維意識問題。

不是要求所有的人都能夠探求事物內在原理和本質，但是如果你要實現技能階層躍遷，那么必須從外走向內，從現場到本質。

從萬物窮盡到能夠總結出一套適合自己的規律和方法論。

大項目實踐的機會，可遇不可求

如果我們說微服務架構框架，你如果原來本身就對Java軟件開發熟悉。

那么你可能花1到2周的時間就能夠采用開源的SpringCloud搭建好微服務開發框架，并對里面的注冊中心，網關，限流熔斷，鏈路監控，安全等都進行自我測試和驗證。

當然你也可以將微服務框架應用到你當前開發的小產品中。

那么這樣持續2到3年，你能夠算對微服務架構精通嗎?

顯然不能。

其最大的一個原因就是當你的項目沒有達到一定規模，實際的業務系統沒有達到一定的用戶數和并發量的時候，很多架構層面的應用問題你根本就無法遇到。

典型的包括了應用性能問題，復雜Bug的快速定位排查，安全問題，應用本身的高可用問題等。這些內容實際你很難通過理論學習完全掌握。

海量高并發架構設計的書你可能看了很多，即使書里面也會講到一些關鍵經驗點，但是你原來沒有實踐遇到過，你并不會產生共鳴，這些書里面的經驗總結并不會因為你閱讀了書籍就直接轉換為了你自己的內在經驗。

理論的學習無法轉變為你自己的經驗，唯有實踐。

你只有通過大項目的實踐，在實踐過程中通過不斷地遇到新問題，解決新問題，你的技能和經驗才能夠不斷提升，并最終轉換為你自己的經驗模式。

沒有大項目實踐，實際你很難完成這種轉變。

沒有大項目實踐，即使你把所有的微服務技術原理的書全部看了，但是無法在實際項目中應用，最終仍然會逐步遺忘，這些知識并不會轉變為你內在經驗模式。

所以當你有這種大項目機會的時候一定不要放過，如果在一個企業多年也沒有這種機會你也可以考慮是否找 一個新的工作機會去鍛煉。

我在前面寫過很多私有云PaaS平臺，SOA架構設計，平臺性能優化，SOA治理方面的文章，這些文章總結本身即來源于大項目實踐。

通過大項目實踐，你才有機會提升你這塊的架構設計能力。要明白架構設計過程本身也是一個迭代演進的過程，沒有最優的架構，只有面對當前場景最適用的架構。

就拿我們SOA項目一個接口服務運行實例日志存儲。從最開始的數據庫分表，再到Solr全文建設，再到轉到HBase的分布式存儲庫，本身就是基于場景不斷演進的過程。

架構設計一定不是你懂搭建某個技術框架，這不能叫架構。

真正的架構是你面對業務場景和問題領域的時候采用最佳技術方案去解決問題的能力。

要做到這點。

• 其一是要熟悉你所在的業務場景和業務流程。
• 其二是能夠將技術能力匹配到業務上。

總結為一句話就是模式應用能力，即當你面對不同的業務場景和問題域的時候，應該采用什么最合適的技術來解決。你需要的是這種匹配能力。

真正的實踐過程就是不斷地去提煉這種可復用的匹配能力。