在現(xiàn)實中，我們會發(fā)現(xiàn)很多從業(yè)人員對軟件架構(gòu)的認(rèn)知有著明顯的局限和偏差，具體體現(xiàn)在以下幾點(diǎn)。
誤區(qū)一：不知道架構(gòu)與設(shè)計的區(qū)別
雖然許多從業(yè)人員的頭銜為“架構(gòu)師”，但是他們并不能回答下面的一些問題：
系統(tǒng)架構(gòu)與設(shè)計有區(qū)別嗎？區(qū)別在哪里呢？
什么樣的人能滿足系統(tǒng)架構(gòu)師的要求？
什么樣的人能滿足設(shè)計人員的要求？
一般地，架構(gòu)師都是技術(shù)出身，他們可能長期從事過編碼、設(shè)計領(lǐng)域的工作。很自然，他們可能認(rèn)為設(shè)計、編碼工作就是軟件架構(gòu)的一切。但是真正的架構(gòu)師必須有長期設(shè)計的工作經(jīng)驗，并在系統(tǒng)化的提升之后才可能成為合格的架構(gòu)師。他們需要考慮商業(yè)概念、商業(yè)運(yùn)作、系統(tǒng)結(jié)構(gòu)、結(jié)構(gòu)優(yōu)化等這些更為宏觀的方面，然后選擇那些最經(jīng)典的實踐參考模型，才能構(gòu)建出合格的軟件架構(gòu)。
誤區(qū)二：不知道系統(tǒng)架構(gòu)該如何做
讓我們回到日常的軟件系統(tǒng)活動中來。其實通過一些實踐，我們已經(jīng)逐步建立起一些對軟件架構(gòu)及設(shè)計活動的認(rèn)知。直覺和經(jīng)驗告訴我們，一個軟件系統(tǒng)或軟件架構(gòu)在構(gòu)建之初就給架構(gòu)師留下了充分的創(chuàng)作空間。但是，一個單純?yōu)榱艘幌盗泄δ艿膶崿F(xiàn)而構(gòu)建的架構(gòu)，還不能稱作嚴(yán)格意義上的軟件架構(gòu)。一個真正意義上的軟件架構(gòu)，是需要考慮如下的一些系統(tǒng)要求：
好的系統(tǒng)，一定是一個架構(gòu)靈活的系統(tǒng)。
我們需要一個方便維護(hù)的系統(tǒng)來滿足可維護(hù)性的要求。
當(dāng)系統(tǒng)用戶數(shù)量隨著業(yè)務(wù)的擴(kuò)展而增加，我們的架構(gòu)還能應(yīng)對。
架構(gòu)設(shè)計人員能夠確定當(dāng)前運(yùn)行系統(tǒng)的下一個時刻的狀態(tài)。
峰值時，系統(tǒng)還能保持運(yùn)行，系統(tǒng)性能不會明顯下降。
我們的系統(tǒng)能夠與其他系統(tǒng)進(jìn)行集成。
但是許多架構(gòu)師并不知道在系統(tǒng)架構(gòu)構(gòu)建時期，他們應(yīng)該完整考慮哪些因素，應(yīng)該采用怎樣的手段，應(yīng)該完成什么任務(wù)，才能夠構(gòu)建出一個久經(jīng)考驗的系統(tǒng)架構(gòu)。
誤區(qū)三：只盲目追隨業(yè)界通用框架
事實上，我們在工作中，也許還會聽到這樣一些聲音：
我們要解決一個分布式的問題，CORBA很好而且還很標(biāo)準(zhǔn)化，用這個架構(gòu)就行了。
我們要做一個電子政務(wù)的應(yīng)用，J2EE框架不就很流行嘛，就選這個架構(gòu)吧。
我們要做一個車載電子系統(tǒng)平臺，OSGI就是一個好的嵌入式平臺，就用它吧。
上述只不過是我們經(jīng)常能見到的一種對框架或中間件的依賴現(xiàn)象。如果我們每開發(fā)一個應(yīng)用或產(chǎn)品，都要自己手工設(shè)計一個框架，確實是一件令人痛苦的事。當(dāng)然，我們承認(rèn)現(xiàn)在有很多產(chǎn)品化的、很成熟的框架或中間件，確實極大方便了我們的應(yīng)用及產(chǎn)品開發(fā)。這似乎給人們一種錯覺，以為應(yīng)用和產(chǎn)品開發(fā)是一件很容易的事。但是，我們也要清醒地認(rèn)識到這些框架或中間件背后實際上隱藏了很多技術(shù)、設(shè)計、應(yīng)用場景，也就是說為設(shè)計開發(fā)人員隱藏了很多系統(tǒng)設(shè)計開發(fā)的復(fù)雜性。于是當(dāng)產(chǎn)品開發(fā)或項目結(jié)束時，你就可能聽到這樣的抱怨：
我們應(yīng)用CORBA架構(gòu)的系統(tǒng)在運(yùn)行時速度很慢，而且很復(fù)雜，出了問題卻不知道癥結(jié)在哪里。
我們的J2EE架構(gòu)讓我們使用了大量的EJB和JavaBean，簡直就是構(gòu)件的海洋，太難維護(hù)了。
我們的車載電子系統(tǒng)根本就不工作，打開汽車車門，插入車鑰匙，點(diǎn)火，需要等上幾十秒，電子系統(tǒng)都沒有反應(yīng)。
所以，系統(tǒng)架構(gòu)并不是簡單地應(yīng)用一個流行的、通用的、看似很唬人的某某通用框架，從而使自己的系統(tǒng)過分地依賴流行的框架或中間件，同時把所有的系統(tǒng)級質(zhì)量要求統(tǒng)統(tǒng)扔給這些框架或中間件，以寄希望于這些通用框架代替你去思考和處理你應(yīng)該解決的問題。
實際上，我們應(yīng)該寄希望于自己來構(gòu)建系統(tǒng)架構(gòu)，使其能夠做到：
即便是峰值運(yùn)行時，系統(tǒng)也要有很好的性能。
當(dāng)系統(tǒng)面對大量并發(fā)事件時，能夠很好地進(jìn)行調(diào)度和并行處理。
當(dāng)系統(tǒng)資源使用頻繁且負(fù)荷增加時，系統(tǒng)能夠很好地協(xié)調(diào)資源的運(yùn)用。
當(dāng)我們設(shè)計的重要實時系統(tǒng)（例如航空管制系統(tǒng)）出現(xiàn)錯誤時，能快速實現(xiàn)系統(tǒng)的自我恢復(fù)。
這些都是軟件架構(gòu)及設(shè)計人員自己應(yīng)該動手解決的問題。引用Frederick P在1986年《No Silver Bullets》一文中說過的一句經(jīng)典名言"Silver bullets do not exist"，即"世上沒有萬能的解藥"。Frank Buschmann也曾經(jīng)說過"Any framework or middleware can only help you in doing your job, but it cannot do your job for you"，即"框架或中間件是用來幫助你的，而不是代替你去思考和工作的"。所以我們必須根據(jù)現(xiàn)實的系統(tǒng)要求（功能和非功能要求），自己去構(gòu)建適合現(xiàn)狀的軟件架構(gòu)！
誤區(qū)一：不知道架構(gòu)與設(shè)計的區(qū)別
雖然許多從業(yè)人員的頭銜為“架構(gòu)師”，但是他們并不能回答下面的一些問題：
系統(tǒng)架構(gòu)與設(shè)計有區(qū)別嗎？區(qū)別在哪里呢？
什么樣的人能滿足系統(tǒng)架構(gòu)師的要求？
什么樣的人能滿足設(shè)計人員的要求？
一般地，架構(gòu)師都是技術(shù)出身，他們可能長期從事過編碼、設(shè)計領(lǐng)域的工作。很自然，他們可能認(rèn)為設(shè)計、編碼工作就是軟件架構(gòu)的一切。但是真正的架構(gòu)師必須有長期設(shè)計的工作經(jīng)驗，并在系統(tǒng)化的提升之后才可能成為合格的架構(gòu)師。他們需要考慮商業(yè)概念、商業(yè)運(yùn)作、系統(tǒng)結(jié)構(gòu)、結(jié)構(gòu)優(yōu)化等這些更為宏觀的方面，然后選擇那些最經(jīng)典的實踐參考模型，才能構(gòu)建出合格的軟件架構(gòu)。
誤區(qū)二：不知道系統(tǒng)架構(gòu)該如何做
讓我們回到日常的軟件系統(tǒng)活動中來。其實通過一些實踐，我們已經(jīng)逐步建立起一些對軟件架構(gòu)及設(shè)計活動的認(rèn)知。直覺和經(jīng)驗告訴我們，一個軟件系統(tǒng)或軟件架構(gòu)在構(gòu)建之初就給架構(gòu)師留下了充分的創(chuàng)作空間。但是，一個單純?yōu)榱艘幌盗泄δ艿膶崿F(xiàn)而構(gòu)建的架構(gòu)，還不能稱作嚴(yán)格意義上的軟件架構(gòu)。一個真正意義上的軟件架構(gòu)，是需要考慮如下的一些系統(tǒng)要求：
好的系統(tǒng)，一定是一個架構(gòu)靈活的系統(tǒng)。
我們需要一個方便維護(hù)的系統(tǒng)來滿足可維護(hù)性的要求。
當(dāng)系統(tǒng)用戶數(shù)量隨著業(yè)務(wù)的擴(kuò)展而增加，我們的架構(gòu)還能應(yīng)對。
架構(gòu)設(shè)計人員能夠確定當(dāng)前運(yùn)行系統(tǒng)的下一個時刻的狀態(tài)。
峰值時，系統(tǒng)還能保持運(yùn)行，系統(tǒng)性能不會明顯下降。
我們的系統(tǒng)能夠與其他系統(tǒng)進(jìn)行集成。
但是許多架構(gòu)師并不知道在系統(tǒng)架構(gòu)構(gòu)建時期，他們應(yīng)該完整考慮哪些因素，應(yīng)該采用怎樣的手段，應(yīng)該完成什么任務(wù)，才能夠構(gòu)建出一個久經(jīng)考驗的系統(tǒng)架構(gòu)。
誤區(qū)三：只盲目追隨業(yè)界通用框架
事實上，我們在工作中，也許還會聽到這樣一些聲音：
我們要解決一個分布式的問題，CORBA很好而且還很標(biāo)準(zhǔn)化，用這個架構(gòu)就行了。
我們要做一個電子政務(wù)的應(yīng)用，J2EE框架不就很流行嘛，就選這個架構(gòu)吧。
我們要做一個車載電子系統(tǒng)平臺，OSGI就是一個好的嵌入式平臺，就用它吧。
上述只不過是我們經(jīng)常能見到的一種對框架或中間件的依賴現(xiàn)象。如果我們每開發(fā)一個應(yīng)用或產(chǎn)品，都要自己手工設(shè)計一個框架，確實是一件令人痛苦的事。當(dāng)然，我們承認(rèn)現(xiàn)在有很多產(chǎn)品化的、很成熟的框架或中間件，確實極大方便了我們的應(yīng)用及產(chǎn)品開發(fā)。這似乎給人們一種錯覺，以為應(yīng)用和產(chǎn)品開發(fā)是一件很容易的事。但是，我們也要清醒地認(rèn)識到這些框架或中間件背后實際上隱藏了很多技術(shù)、設(shè)計、應(yīng)用場景，也就是說為設(shè)計開發(fā)人員隱藏了很多系統(tǒng)設(shè)計開發(fā)的復(fù)雜性。于是當(dāng)產(chǎn)品開發(fā)或項目結(jié)束時，你就可能聽到這樣的抱怨：
我們應(yīng)用CORBA架構(gòu)的系統(tǒng)在運(yùn)行時速度很慢，而且很復(fù)雜，出了問題卻不知道癥結(jié)在哪里。
我們的J2EE架構(gòu)讓我們使用了大量的EJB和JavaBean，簡直就是構(gòu)件的海洋，太難維護(hù)了。
我們的車載電子系統(tǒng)根本就不工作，打開汽車車門，插入車鑰匙，點(diǎn)火，需要等上幾十秒，電子系統(tǒng)都沒有反應(yīng)。
所以，系統(tǒng)架構(gòu)并不是簡單地應(yīng)用一個流行的、通用的、看似很唬人的某某通用框架，從而使自己的系統(tǒng)過分地依賴流行的框架或中間件，同時把所有的系統(tǒng)級質(zhì)量要求統(tǒng)統(tǒng)扔給這些框架或中間件，以寄希望于這些通用框架代替你去思考和處理你應(yīng)該解決的問題。
實際上，我們應(yīng)該寄希望于自己來構(gòu)建系統(tǒng)架構(gòu)，使其能夠做到：
即便是峰值運(yùn)行時，系統(tǒng)也要有很好的性能。
當(dāng)系統(tǒng)面對大量并發(fā)事件時，能夠很好地進(jìn)行調(diào)度和并行處理。
當(dāng)系統(tǒng)資源使用頻繁且負(fù)荷增加時，系統(tǒng)能夠很好地協(xié)調(diào)資源的運(yùn)用。
當(dāng)我們設(shè)計的重要實時系統(tǒng)（例如航空管制系統(tǒng)）出現(xiàn)錯誤時，能快速實現(xiàn)系統(tǒng)的自我恢復(fù)。
這些都是軟件架構(gòu)及設(shè)計人員自己應(yīng)該動手解決的問題。引用Frederick P在1986年《No Silver Bullets》一文中說過的一句經(jīng)典名言"Silver bullets do not exist"，即"世上沒有萬能的解藥"。Frank Buschmann也曾經(jīng)說過"Any framework or middleware can only help you in doing your job, but it cannot do your job for you"，即"框架或中間件是用來幫助你的，而不是代替你去思考和工作的"。所以我們必須根據(jù)現(xiàn)實的系統(tǒng)要求（功能和非功能要求），自己去構(gòu)建適合現(xiàn)狀的軟件架構(gòu)！