一個程序員對架構的認識

最近訂閱了一些架構方面的資料，閱讀後獲益匪淺，想着整理一些本身的體會與思考，造成架構方面的讀書筆記，一來與你們交流，二來經過文字的形式檢查本身到底收穫多少！

「咱們系統是MVC架構的」

「淘寶的架構好屌」

「最近在學習MySQL的架構」

「這個系統開發咱們要用MVC框架來進行開發」

• • • -

咱們經常聽到上面關於架構的各類描述，那麼架構究竟是指什麼？系統、框架、架構三者之間是一個什麼樣的關係？下面讓咱們結合實際的例子一塊兒來探究下。

架構的含義

小石最近加入了一家生鮮電商公司。公司如今的首要任務是把電商系統給作出來，讓用戶可以經過PC、App購買公司的生鮮產品。

關鍵詞： 系統，所謂系統能夠簡單理解爲咱們平時所說的應用，固然系統能夠包含多個小系統，這裏爲了簡單起見，咱們就先假設只開發這樣一個單體應用，包含了用戶下單購買的基本功能。

小石經過分析其餘電商系統，知道至少須要 用戶註冊登陸模塊、用戶信息模塊、商品模塊、訂單模塊 系統纔可以進行運轉。

系統的功能肯定了，該選擇用什麼樣的語言進行開發呢？選擇什麼樣的方式進行開發呢？與你們一塊兒討論後，你們認爲如今階段的首要目標是快速作出系統來，所以你們決定採用PHP來開發，並決定使用 Yii2 框架，數據庫方面使用 MySQL，WebService使用Nginx。

關鍵詞： 框架，爲了快速完成系統的開發，咱們會採用一些已被業內實踐確認的規範來進行，好比這裏採用 YII2 框架，也就是採用了業內的 MVC 規範。因此能夠認爲所謂的框架就是肯定了一些業內規範，從某種程度上對你們造成約束或者造成都能理解的規定。

從開始到如今，尚未寫一行代碼，一直在進行設計與討論，討論須要哪些功能，設計採用什麼 結構，而這裏的結構主要包括了兩方面：邏輯的結構與物理的結構。所謂邏輯結構就是指系統是按照什麼樣的流程來運轉，須要哪些功能來支持。所謂物理，就是當編碼完成全部的邏輯後，系統採用什麼形式來部署運行。

那麼到底什麼是架構呢？我理解的架構：在系統誕生之初，對系統進行的邏輯設計與物理設計。他是系統的草圖，能夠類比爲建築領域的設計圖。這張圖須要肯定：

• 業務須要的功能模塊劃分（建築設計須要劃分區域功能）
• 技術選型，用什麼框架、什麼存儲、什麼緩存（建築領域也要確認框架結構仍是框剪結構）

架構是進化的

一個架構的0.1版本絕對不會是完美的，世界上也不存在完美的架構。像上面的小故事，咱們採用最簡單的架構，以下圖（物理角度）：

咱們把全部的功能寫在一份代碼裏，全部的數據存在一個庫裏，全部的代碼部署在同一個Nginx上，甚至還可能咱們的Nginx、MySQL都部署在同一臺機器上。

公司業務得以發展，人員得以增長，系統變得更加複雜。這個時候原來的架構，一沒法知足業務快速發展，二沒法讓多人開發變得愉快。由於幾十我的在同一份代碼裏進行編碼，想一下都是頭大。文件衝突、功能依賴、bug排查、測試功能，這些都沒法愉快的解決。這時就得根據新的狀況從新設計架構。

咱們將代碼功能進行拆分，將之前的模塊拆分紅獨立的系統，將MySQL進行主從設計，利用Nginx作負載等等。

那麼爲何不一上來就進行拆分呢？由於一開始人手不足，拆分過細，開發週期慢，業務也不須要如此細緻的劃分。

總結

架構是一個系統的草圖（邏輯+物理角度），它是有生命的，隨着業務的變化會不斷演進。沒有完美的架構只有合適的架構。