演化原則：演化優於一步到位
總結
成為架構師是每個程式設計師的夢想，但並不意味著把程式設計做好就能夠自然而然地成為乙個架構師，優秀程式設計師和架構師之間還有乙個明顯的鴻溝需要跨越，這個鴻溝就是「不確定性」。可是一旦涉及「選擇」，就很容易讓架構師陷入兩難的境地，例如：
還有很多類似的問題和困惑，關鍵原因在於架構設計領域並沒有一套通用的規範來指導架構師進行架構設計，更多是依賴架構師的經驗和直覺，因此架構設計有時候也會被看作一項比較神秘的工作。
架構設計隱含的三個共性原則
為什麼會這樣的？再好的夢想，也需要腳踏實地實現！羅馬不是一天建成的冰山下面才是關鍵
所以，真正優秀的架構都是在企業當前人力、條件、業務等各種約束下設計出來的，能夠合理地將資源整合在一起並發揮出最大功效，並且能夠快速落地。這也是很多 bat 出來的架構師到了小公司或者創業團隊反而做不出成績的原因，因為沒有了大公司的平台、資源、積累，只是生搬硬套大公司的做法，失敗的概率非常高。
剛才我聊的這些原因，會在潛意識層面促使初出茅廬的架構師，不自覺地追求架構的複雜性。然而，「複雜」在製造領域代表先進，在建築領域代表領先，但在軟體領域，卻恰恰相反，代表的是「問題」。軟體領域的複雜性體現在兩個方面：
結構的複雜性的系統幾乎毫無例外具備兩個特點：
我以圖形的方式來說明複雜性：
2個元件組成的系統
3個元件組成的系統
4個元件組成的系統
5個元件組成的系統
最簡單的結構當然就是整個系統只有乙個元件，即系統本身，所有的功能和邏輯都在這乙個元件中實現。不幸的是，這樣做是行不通的，原因在於除了結構的複雜性，還有邏輯的複雜性，即如果某個元件的邏輯太複雜，一樣會帶來各種問題。邏輯複雜的元件，乙個典型特徵就是單個元件承擔了太多的功能。以電商業務為例，常見的功能有：商品管理、商品搜尋、商品展示、訂單管理、使用者管理、支付、發貨、客服……把這些功能全部在乙個元件中實現，就是典型的邏輯複雜性。
邏輯複雜幾乎會導致軟體工程的每個環節都有問題，假設現在**將這些功能全部在單一的元件中實現，可以想象一下這個恐怖的場景：
不用多說，肯定誰都無法忍受這樣的場景。
為什麼複雜的電路就意味更強大的功能，而複雜的架構卻有很多問題呢？
根本原因在於電路一旦設計好後進入生產，就不會再變，複雜性只是在設計時帶來影響；而乙個軟體系統在投入使用後，後續還有源源不斷的需求要實現，因此要不斷地修改系統，複雜性在整個系統生命週期中都有很大影響。
功能複雜的元件，另外乙個典型特徵就是採用了複雜的演算法。複雜演算法導致的問題主要是難以理解，進而導致難以實現、難以修改，並且出了問題難以快速解決。
以 zookeeper 為例，zookeeper 本身的功能主要就是選舉，為了實現分布式下的選舉，採用了 zab 協議，所以 zookeeper 功能雖然相對簡單，但系統實現卻比較複雜。相比之下，etcd 就要簡單一些，因為 etcd 採用的是 raft 演算法，相比 zab 協議，raft 演算法更加容易理解，更加容易實現。
綜合前面的分析，我們可以看到，無論是結構的複雜性，還是邏輯的複雜性，都會存在各種問題，所以架構設計時如果簡單的方案和複雜的方案都可以滿足需求，最好選擇簡單的方案。《unix 程式設計藝術》總結的 kiss（keep it ******, stupid!）原則一樣適應於架構設計。軟體架構從字面意思理解和建築結構非常類似，事實上「架構」這個詞就是建築領域的專業名詞，維基百科對「軟體架構」的定義中有一段話描述了這種相似性：
從和目的、主題、材料和結構的聯絡上來說，軟體架構可以和建築物的架構相比擬。例如，軟體架構描述的是乙個軟體系統的結構，包括各個模組，以及這些模組的關係；建築架構描述的是一幢建築的結構，包括各個部件，以及這些部件如何有機地組成成一幢完美的建築。然而，字面意思上的相似性卻掩蓋了乙個本質上的差異：建築一旦完成（甚至一旦開建）就不可再變，而軟體卻需要根據業務的發展不斷地變化！
對比一下，我們來看看軟體架構。
windows 系統的發展歷史：
如果對比 windows 8 的架構和 windows 1.0 的架構，就會發現它們其實是兩個不同的系統了！
android 的發展歷史：
同樣，android 6.0 和 android 1.6 的差異也很大。
對於建築來說，永恆是主題；而對於軟體來說，變化才是主題。軟體架構需要根據業務的發展而不斷變化。設計 windows 和 android 的人都是頂尖的天才，即便如此，他們也不可能在 1985 年設計出 windows 8，不可能在 2009 年設計出 android 6.0。
如果沒有把握「軟體架構需要根據業務發展不斷變化」這個本質，在做架構設計的時候就很容易陷入乙個誤區：試圖一步到位設計乙個軟體架構，期望不管業務如何變化，架構都穩如磐石。
為了實現這樣的目標，要麼照搬業界大公司公開發表的方案；要麼投入龐大的資源和時間來做各種各樣的**、分析、設計。無論哪種做法，後果都很明顯：投入巨大，落地遙遙無期。更讓人沮喪的是，就算跌跌撞撞拼死拼活終於落地，卻發現很多**和分析都是不靠譜的。
考慮到軟體架構需要根據業務發展不斷變化這個本質特點，軟體架構設計其實更加類似於大自然「設計」乙個生物，通過演化讓生物適應環境，逐步變得更加強大：
軟體架構設計同樣是類似的過程：
架構師在進行架構設計時需要牢記這個原則，時刻提醒自己不要貪大求全，或者盲目照搬大公司的做法。應該認真分析當前業務的特點，明確業務面臨的主要問題，設計合理的架構，快速落地以滿足業務需要，然後在執行過程中不斷完善架構，不斷隨著業務演化架構。今天介紹了面對「不確定性」時架構設計的三原則，分別是合適優於業界領先，簡單優於複雜和演化優於一步到位，希望對你有所幫助。謝即使是大公司的團隊，在設計乙個新系統的架構時，也需要遵循演化的原則，而不應該認為團隊人員多、資源多，不管什麼系統上來就要一步到位，因為業務的發展和變化是很快的，不管多牛的團隊，也不可能完美**所有的業務發展和變化路徑。
關於移動廣告平台，你不知道的那些事
移動網際網路進入存量博弈時代。智慧型手機出貨量下降，使用者增速放緩，使用者時長逐漸見頂 營銷人員紛紛採取更加激進的廣告營銷策略獲取使用者。但面對日益繁多的移動廣告平台，廣告主在選擇變多的同時也對其選擇高效平台的能力提出了更多的挑戰。尤其是在應對精細化運營的要求下，什麼樣的平台獲客轉化更好，什麼樣的平...
關於提單，你不知道的事！
提單bill of lading b l 就代表貨物，一定要對提單有足夠的了解。基本知識和注意點 提單通常是3正3副，也有2正3副的。假如信用證有要求的話，要和貨代特別說明。t t付款方式時，理論上只需要一張正本就可以了 提貨後其他正本自動失效，副本不能提貨 t t收到全部貨款後，給客人寄正本時可以...
define與enum，你不知道的那些事
什麼時候需要用到enum呢,就是變數的數值在幾個範圍之間.red,blue,black.這樣用enum比較好.當然也可以用define.但是define維護起來比較麻煩.define 適合比較少的變數的時候.用enum關鍵字說明常量 即說明列舉常量 有以下幾點好處 1 使程式更容易維護，因為列舉常量...