一、前言

成為架構師是每個程式設計師的夢想，但是程式設計師和架構師之間有一個巨大的鴻溝，需要程式設計師去跨域方能成為架構師，那就是“不確認性”。

對於程式設計而言，其結果是確定的，但是對於架構是不確定的。架構沒有程式設計那麼的的約束，可以使用這種方式去實現，而對各種選擇，我們就容易迷茫，到底是選擇業務最先進的技術，還是開源、商業的…,面對各種選擇，架構師可以遵循下面三個原則來做出選擇，那就是：

• 合適原則
• 簡單原則
• 演化原則

二、合適原則

合適原則的宣言:"合適優於業界領先"

很多技術人員有很強的技術情節，每次都想挑戰自己，想達到甚至超越業界領先水平。但是一般這樣做下去的結果就是失敗。幾個人的團隊想要做出QQ、微信這個體量的應用，那是不可能的，為什麼呢?

• 將軍不打無兵之仗

  大公司分工很細，一個小系統可能就有十幾個人負責，整個研發團隊有上百人，但是小公司的話，整個團隊才十幾個人。十幾個想做幾十人的活，並且還想做的更好，不能說絕對不可能，但是難度會非常大。

  沒那麼多個卻想幹那麼多人的活，是失敗的主要原因。

• 羅馬不是一天建成的

  業界領先的方案並不是某個天才忽然間想到的，而是經過不斷的發展才不斷完善的。阿里中介軟體團隊 2008 年成立，發展到現在已經有十年了。我們只知道他們抗住了多少次“雙 11”，做了多少優秀的系統，但經歷了什麼樣的挑戰、踩了什麼樣的坑，只有他們自己知道。！這些挑戰和踩坑，都是架構設計非常關鍵的促進因素，單純靠拍腦腦袋或者頭腦風暴，是不可能和真正實戰相比的。

  沒有那麼多的積累，卻想一步登天，是失敗的第二個原因。

• 冰山下面才是關鍵
  業務領先方案不是天才想出來的，而是業務倒逼出來的。業務發展到一定階段，舊的方案已經不適合於現在的業務場景,需要一個新的方案來滿足業務。通過創新和嘗試才會有新的方案。

  沒有那麼卓越的業務場景，卻幻想靈光一現成為天才，是失敗的第三個原因。

  所以說，真正優秀的架構是在公司現有人才、業務、條件等約束下，能夠合理的整合資源，發揮出最大的功效，並且能夠快速落地。

三、簡單原則

簡單原則的宣言：簡單優於複雜

軟體架構的一門技術活，很多人都會把軟體架構與傳統的建築做對比，它們二者間有很多的相似之處。但是它們有很大的區別，建築追求的是不變，可以追求複雜，而軟體追求的是變。建築建好以後，幾十年上百年都可能不會發生改變，但是軟體的話，會跟著需求不段的發生變化。複雜在建築領域代表的是先進，但是在軟體領域代表的則是問題。
軟體領域的複雜主要體現在下面幾個方面：

• 結構複雜性

  • 組成複雜系統的元件多
  • 元件間的關係複雜

• 邏輯複雜性

  意識到結構複雜性後，我們的第一反應就是減小元件，但是減小元件會有另外一個問題，那就是元件邏輯複雜。假如我們把電商的所有模組(登入、註冊、購物車、商品、支付、訂單)放在一個元件，那就是典型的邏輯複雜性。
  把這些放在一起會有什麼樣的問題呢？

  • 程式碼體量大，每次clone程式碼都要好久
  • 每次部署都花費很久、每次修改都要重新部署
  • 生產定位問題困難，並且每次出問題都要拉上所有的小夥伴。
  • 需求滿天飛，因為所有的業務都在一個系統裡，每天都在開會、開會中。
  • 版本太多，每天都要上線很多個版本，系統每天要重啟十幾次。

  不用多想，出現這樣的問題，每個人都會受不了。
  功能複雜的另一個特點，就是演算法複雜。演算法複雜的一個問題就是定位問題困難。

  無論是結構複雜還是邏輯複雜，都會改系統帶來很大問題，所有在做架構時，在有複雜方案和簡單方案可以選擇時，儘量選擇簡單方案。

四、演化原則

演化原則的原則是：演化優於一步到位。

上文提到過，建築是不變的，而軟體是不斷變的。我們不可能在現在就設計出十年後的系統，就像window作業系統不可能一開始就做出win10來，而是從win1.0慢慢演化而來的。
軟體架構的設計應該遵循一個這樣的規律：

• 首先，設計出一個滿足現有業務的架構
• 架構要在實際應用中不斷的優化，保留其優秀的部分,修改有缺陷的設計、改正錯誤的設計、去掉無用的設計，使得架構不斷完善。
• 當業務發展時，舊的架構可以要重構、甚至重寫。但是有價值的經驗、教訓卻會在新的架構中體現。

五、小結

本文主要講了架構設計的三原則：合適優於業界領先、簡單優於複雜、演化優於一步到位。