文字遊戲
以題引題，“ 我們永遠無法構建一個高併發系統 ”，因爲這是一個僞命題。高併發並不適合用來描述一個系統的特點，它只是說的這個系統適用的場景是高併發環境。高併發指的是我們的系統可以同時併發的處理多個任務請求，在這種場景下，依然能保持系統穩定高效。這絕不是一個文字遊戲，做任何事情之前我們首先應該搞清楚一件事情的概念定義，讓各個角色各司其職，這樣我們才能找準方向正確的推動一件事情的發展，架構甚是如此。
架構是什麼
描述一個架構的特點應該是從可伸縮、高可用、高性能等幾個方面出發，從這些特點去衡量一個架構的好壞。一個架構要看這個架構可伸縮性強不強，是否能在緊急情況下快速擴容。比如我們我們一個商城網站，在國慶春節的時候用戶流量會成幾倍的增長，這時候原有的架構規模可能無法支撐如此規模的業務處理，我們的架構應該具有可快速擴容的能力，在短時間內達到滿足場景的架構擴張，而在活動結束後爲了節省服務器資源，這一切應該在用戶無感知的情況下悄悄的恢復，當然在有了容器化之後這些都變的不在複雜。再有一個特點我們會經常拿TPS、QPS去衡量一個系統的吞吐性能，這些指標可以表示一個系統的性能高低，同樣是我們常用來衡量性能好壞的標準。但是一個系統單從某一點都無法說明其架構的好壞與否，需要綜合各方面的因素評定，沒有最好的架構只有最合適的架構，架構合適了，一切才能正常的發展。
如何做合適的架構
適應當前組織結構的真實情況，能夠恰好滿足當前體系要求的架構纔是合適的架構。大部分人認爲我們需要爲未來做長久規劃，這自然正確，但是往往絕大部分情況我們都無法預測未來的發展。社會在變化，組織在變化，那自然應該允許我們的架構也發生變化以適應所需。這兩種方向並不是兩個極端，任何事情之間都需要一個權衡取捨，我們所說的trade-off。
阿里架構發展
阿里最初也是從最簡的LAMP架構起家，2003年靠從買來的一套系統部署在幾臺簡單的服務器上做起了業務，這套架構是適合他們當時情況的最合適的架構，因爲那時沒有知道以後的世界怎麼樣。
04年開始，瘋狂的數據增長，發現這一套架構在難以滿足現有的需求，阿里嘗試過把mysql更換爲Oracle，後又將開發語言換位java等等，因爲當時的技術瓶頸受限於sun，這對此時也是最合適的架構了。再到後來阿里自研了各種技術與中間件，經歷集羣負載、SOA 到分佈式微服務逐漸到今天構建起強大的技術帝國，在技術領域內佔據着舉足輕重的位置。爲什麼他們不一開始直接上來微服務分佈式？當時的技術大環境也沒有這些東西啊，阿里已經幾乎可以代表當時技術的頂尖水平了。
維基百科
與之形成對比的由我們熟悉的維基百科，它是全球第六大最受歡迎網站，靠一個非營利的基金會來運營，整個技術團隊十幾個人組成，並且完全自發。維基百科技術架構相比於阿里並沒有如此龐大的遍佈全球的集羣服務器支撐，技術規模也遠遠不足，但是依然佔據着舉足輕重的地位。
如上便是維基百科的規模與使用的技術，其中的技術大部分我們都有所熟知，但是就是這些看不起眼的組件服務支撐着全球的流量。並不是最先進、最龐大的的技術羣就一定構建起最好的架構，而最適合的架構才稱得上是最好的架構。
真正的架構
生活中的一切都需要架構，並不僅僅是技術。有了合適的大體的框架，才能順着整體架構健康發展。例如一個公司的組織架構，如果沒有合適的規劃，人員組織混亂，勢必難以發展壯大。優秀的架構才能吸引來優秀的員工，而優秀的員工加優秀的架構才能創建出優秀的企業。
最後
總要有最後，說到了最後才發現這個文章架構規劃的不是太好。我想表達的事情很多，什麼是架構、架構的發展史，又想拿比如阿里，維基百科等等去舉例子談一下他們架構的演變與發展，後面又去談了公司的人員組織架構和我們的生活架構，規劃了很多很大。可是我根本沒有這麼足夠的時間去說，或是我根本沒有準備的那麼充分，因爲這裏每一個的細節說起來都可以成爲一個長篇小說了，顯然我這樣的架構思路規劃就是不友好的，並不是一個好的架構規劃。所有的一切通過一個不着邊際的題目，其實主要說只有最合適的架構纔是最好的架構。
