談談架構設計的目的

今天主要談談這麼幾個問題?

第一、架構設計的目的是什麼？

第二、架構設計的常見誤區？

1.不做架構設計的系統難道就跑不起來嗎?

2.設計良好的架構能促進業務發展嗎?

第三、不是每個系統都需要做架構設計?

第四、為了高效能、高可用、可擴充套件，所以要做架構設計?

這四個問題摘自李運華先生在極客時間中的《從0開始學架構》專欄。

針對這四個問題，我想談談我的看法。因為在公司我的職責之一就是架構師，當然了，這個架構師並不是十分的專業。另外，對於架構師這個職位，沒有個五到六年的積累稱不上真正的架構師。

一、架構設計的目的是什麼

針對這個問題，在我看來，為什麼要架構設計，用一句話來概括就是:"架構設計的真正目的是為了解決軟體系統的複雜度帶來的問題"。

任何系統最開始都是非常簡單的，比如像我在這家公司開發的第一個專案智慧酒店系統，最開始僅僅只是房態圖、會員、預定、報表、房價方案、房型、酒店、角色、員工、部門等不是特別複雜的功能，這些不是特別複雜的功能在現有的開源專案，有不少可以找到現成的解決方案可以節省很多時間。最早期看起有點複雜，實則不是特別複雜，到後來與對應的智慧門鎖系統繫結在一起，就慢慢變的開始複雜起來。當系統越來越龐大變的耦合性高、效能低下時，這時就不得考慮重構。即便是重構也需要十分謹慎，因為既要保證重構能解決這個問題，同時也要保證專案在線上的正常服務，所以這個過程就需要循序漸進。在這個循序漸進的過程中，一開始就得仔細設計。

怎麼個仔細設計法?

我個人結合之前的經驗，歸納為如下幾個辦法?

1.流程的梳理(主要是理清邏輯，看那些流程可以剔除或者是優化，除此之外，最好還是結合資料庫，將表的邏輯理清，利於分庫分表方案的進行);

2.根據最開始的文案(什麼可行性方案、需求分析、概要設計、詳細設計等)，重新審慎;

3.程式碼結構梳理(主要是專案結構(一些分包之類是否合理，比如像filter的話，通常放在cn.companyname.projectname.filter這個包下,同時也包括程式碼是否規範,這個可以參考現有的阿里巴巴Java開發手冊)，同時這個梳理也是為了衡量是否有分模組的必要或者是是否放棄單體轉向微服務的必要，當然了，也包括如果要這樣做，所花費的成本是否值得;

二、架構設計的常見誤區

1.不做架構設計的系統難道就跑不起來嗎?

不做架構設計的系統同樣也是跑的起來的，也能正常提供服務。比如敏捷開發為例，敏捷開發以使用者的需求進化為核心，一開始並沒有一個整體的架構思路，誰都不知道最後的專案會變成怎麼樣，因為一切以使用者的需求進化為主。比如當初在開發智慧酒店系統的時候，我們誰都沒有想到將其與智慧門鎖繫結在一起。

另外順便說說敏捷開發的核心原則，給大家普及一下。

敏捷開發的核心原則有這麼幾個?

（1）主張簡單；

（2）擁抱變化;

（3）可持續;

（4）遞增變化;

（5）投資最大化;

（6）有目的的建模;

（7）快速反饋;

（8）輕裝前行;

2.設計良好的架構能促進業務發展嗎?

這個問題可以分兩個角度來看，好的和壞的。

好的角度來看，專案之初，良好的架構可以促進專案的良性發展，人無遠慮必有近憂，設計之初將遠的近的都考慮進來，最後會使得專案朝著好的方向發展，同時也會降低專案所投入的時間、金錢、人員等成本。

壞的角度來看，對於軟體這個多變的玩意而言，很少有人能將所有的方面考慮到，即便考慮到了，還會有些遺漏，有一句話說的好，計劃跟不上變化。就比如之前某家公司產品經理要求該程式設計師做出app背景根據手機殼來變色那樣的變態需求。從這個例子可以看出，需求具有不確定性，這個不確定性不僅僅與人員有關，也與業務在實際上為客戶服務有關。比如淘寶為例，淘寶剛開始，肯定沒有現在的高效能、高併發、高可用等。演變都是根據實際情況而定，根據實際的情況採取不同的措施。

比如在上家公司做的是辦公系統，辦公系統對於效能方面的要求肯定不及電商。如果對一個對效能要求不高的系統採用高效能、高併發相關的措施是不是有點不合適宜，因為這些都是要燒錢的，從老闆的角度看，最大程度降低成本，做出客戶滿意的產品。至於效能方面的(只要達到使用者的期望，用的時候不卡頓就行)要求不高。

三、不是每個系統都需要做架構設計?

這裡我引用李運華先生的觀點。李運華先生對此是這樣理解的？

他認為這是知其然不知其所以然，系統的確是要做架構設計，但卻不知道為什麼要做架構設計，反正就覺得大家都要做架構設計，所以做架構設計肯定沒錯。

這樣的架構師或者設計師容易走入生搬硬套業界其他公司已有的架構歧路。一旦強行引入，很大可能會發現架構水土不服，或者執行起來很彆扭，最後往往不得善終，要麼推到重來，要麼不斷重構。

以此可以回答，系統是需要做架構設計的，前面說過架構設計是為了解決軟體複雜度問題，專案之初，軟體架構應該是簡單、能實現業務這兩個目的。再比如晚清時期洋務運動的失敗，根本原因是因為不適合當時的中國國情。對於架構師而言，業界的確有很多不同或者大體相似的解決方案，但是究竟適合不適合公司，需要慎思。

四、為了高效能、高可用、可擴充套件，所以要做架構設計?

通常有這種觀點的人，不算是真正的架構師，因為不是每一個系統都需要達到這三個條件，或者是就算系統達到這三個條件，最終不讓客戶或者是老闆滿意，那也是白搭。

 李運華先生，對此的看法是:如果架構師往往有“為了高效能、高可用、可擴充套件，所以要做架構設計”這樣的想法並在實際當中這麼做，那麼將非常有可能會給專案帶來巨大的災難。

為什麼會這樣呢?因為這類架構師不管三七二十一，不管什麼系統，也不管什麼業務，上來就要去“高效能、高可用、高擴充套件”，結果就會出現架構設計複雜無比，專案落地遙遙無期，團隊天天吵翻天等各種糟糕的現象，費盡千辛萬苦，費盡九牛二虎之力將系統整上線，卻發現執行不夠穩定、經常出問題，出了問題難以解決，排查問題困難，加個功能要改一個月或者兩個月。

我想有部分公司經常加班，與這個也許有一定的關係。

小結：

最後還是覺得要強調最開始說的那句話，架構設計的真正目的是為了解決軟體系統的複雜度帶來的問題。同時補充一句，不是為了追求所謂的高大尚。