架構是什麼
我們總在說，我要做一個架構師，或者某某系統的架構是什麼什麼等。那麼，架構到底是什麼？
一個項目，總是為了支撐某些業務場景而存在的。概括地來說，技術框架加上業務邏輯，就構成了項目。反過來，把一個項目中的業務邏輯剝離，只留下無關業務的技術框架，那麼，就稱之為架構。架構師的職責，就是運用各種技術或設計方法，把這套技術框架搭建出來。
那麼，該如何搭建一個技術框架呢？
1. 滿足業務場景。我們說，項目是為支持業務場景的，而技術架構，又是為支撐上層業務邏輯的。所以，搭建架構時，第一個要考慮的就是，要滿足業務場景，要考慮到業務的複雜程度，數據規模大小等。
2. 結合實際成本。那是不是說只要滿足業務場景就OK了呢？並不是。假設某種業務場景，比如說商城，可能使用分布式微服務框架才能滿足其高並發和高可用。但奈何老闆原來就是樓下開超市的，對於網際網路的理解僅限於拼多多砍價和觀看美女直播。他只給了你兩個人，並要求一個月上線。那這時候，你再用分布式微服務的架構顯然是不合適的，因為壓根做不完。
所以，在制定架構時，業務場景是一個主要因素，比如業務的複雜程度，但是，也要考慮其他的成本，比如人力成本，時間成本，伺服器開銷等。最終，我們需要把所有的制約因素都考慮到，並進行一個平衡。
這也就是我們常說的，架構沒有最好的，只有最合適的。平衡，是架構師的一門藝術，一個最核心的關鍵詞。
架構的演進
聊到架構的演進是，我們要說的第一個問題是：架構演進的原動力，就是業務場景的催化。當架構無法滿足當前業務場景時，架構師就不得不去嘗試尋找一種新的架構，來代替原來的架構。所以，架構是由業務場景催化而來的。
先來縱觀一下網際網路架構的整體演進進程，如下：
由最早的單體架構，轉到水平分層架構或面向服務的架構，再到微服務架構，到服務網格架構。
單體架構的優勢
單體架構是非常簡單的，通常它會運行在某個容器裡，向上為app，網頁等前端項目提供數據接口，向上則和資料庫等數據存儲做交互，本身則包含一些或簡單或複雜的業務邏輯。它的優點就是：
1. 開發簡單。
2. 測試簡單。
3. 部署簡單。
4. 擴展簡單。
這裡的擴展指的是，我們可以很輕鬆的利用nginx等代理工具，把分布在一臺或多臺伺服器上的單體服務組合成一個整體來對外提供服務，這種方式，可以應對一定的並發，以及提升一定的可用性。
事實上，除了上述優勢外，單體架構還有一個不太容易被發現的隱藏優勢，即性能優勢。為什麼呢？我們先不考慮高並發等場景，單從一個請求的請求鏈路來說，對於單體架構，它的請求鏈路就是最簡單的。其它架構，如微服務，引入了服務之間交互的網絡開銷。所以，就單個請求來說，在不考慮並發的情況下，單體架構的性能一定是最優的。
水平分層架構和面向服務架構
單體架構的優勢就是簡單。但是，當業務場景逐漸複雜化時，單體架構下的項目內部，就會變得臃腫，代碼之間的耦合性也會變得極強，進而導致開發和維護都變得困難。於是，我們自然想到了，要對項目進行拆分。
拆分可以是水平的，也可以是垂直的。
事實上，這和資料庫的拆分的相通的。假設我們的資料庫數據量大，要做拆分時，一種是可以按照業務進行分庫，其實就是垂直拆分，另一種則是對某個單表數據進行分表，也就是水平拆分。
對於架構來說，也是一樣的。對於單體架構，從功能維度進行拆分，也就是水平拆分，就形成了水平分層架構，從業務維度進行垂直拆分，就形成了SOA面向服務架構。這和資料庫的拆分，在思想上其實是一致的。