什麼是架構？
說到架構，這個概念沒有很清晰的範圍劃分，也沒有一個标準的定義，每個人的了解可能都不一樣。
架構在百度百科中是這樣定義的：架構，又名軟體架構，是有關軟體整體結構與元件的抽象描述，用于指導大型軟體系統各個方面的設計。
我們可以了解為：架構設計的主要目的是為了解決軟體系統複雜度帶來的問題。
卡内基·梅隆大學的瑪麗·肖（Mary Shaw）和戴維·加蘭（David Garlan）在文章《軟體架構介紹》（An Introduction to Software Architecture）中寫到：
“When systems are constructed from many components, the organization of the overall system-the software architecture-presents a new set of design problems.”
譯：随着軟體系統規模的增加，計算相關的算法和資料結構不再構成主要的設計問題；當系統由許多部分組成時，整個系統的組織，也就是所說的“軟體架構”，導緻了一系列新的設計問題。
軟體架構的核心價值，即是控制系統的複雜性，将核心業務邏輯和技術細節的分離與解耦。
架構師的職責是努力訓練自己的思維，用它去了解複雜的系統，通過合理的分解和抽象，了解并解析需求，建立有用的模型，确認、細化并擴充模型，管理架構；能夠進行系統分解形成整體架構，能夠正确的技術選型，能夠制定技術規格說明并有效推動實施落地。
架構分類
在我的認知體系中，将架構分為業務架構、應用架構、技術架構。當然也聽說過資料架構，但大資料領域超出了我的知識範圍，并不打算作深入的學習。
我們來了解一下業務架構、應用架構和技術架構。
在需求初期，業務的需求描述往往比較模糊。但是大方向上，業務需求是由公司戰略決定的。這些戰略所産生的一系統需求，需要業務架構師來進行業務落地，重點在于講清楚這些需求背後的處理過程，定義各個業務子產品的互相關系。
而應用架構、技術架構是為支撐業務架構的落地而存在的。它們的關系環環相扣，上層驅動下層，下層支撐上層。
舉一個拍電影的例子。
業務架構定義了這個電影的故事情節和場景安排；應用架構定義了有哪些角色及其職責，在每個場景中，這些角色是如何互動的；技術架構确定這些角色由誰來表演，實體場景上是怎麼布置的，以此保證整個拍攝能夠順利完成。
再舉一個電商的例子。
一個商品業務，可能對應 3 個應用，一個前台商品展示應用、一個背景商品管理應用，以及一個商品基礎服務。業務架構定義了一個下單的具體流程；應用架構定義了下單有哪些應用參與以及它們如何協作；技術架構要保障相關的應用能夠處理高并發，進而保證大促順利進行。
業務架構
說到業務啊，那就不得不提産品經理。産品經理的職責就是：告訴使用者，系統長什麼樣子；告訴開發，他要實作什麼功能。比如說，我們現在要設計一個電商系統，使用者想在我們系統上買東西，一個典型的購物流程，包括商品浏覽、加入購物車、下單、支付。
産品經理首先要把每個步驟具體化為頁面原型。在原型中，直覺的給出各個步驟的輸入或輸出，以及使用者的操作過程，最後再把這些頁面串起來，形成一個業務流程。
業務架構師要設計一個購物流程子產品，裡面包含商品查詢、添加購物車、下單和支付接口，來分别對應流程裡的 4 個業務步驟。
說起來倒是挺簡單的，要實作這個購物流程，其實是考驗業務架構師的功力的。
首先，業務架構師要掌握不同子產品的業務和資料模型。這會同時涉及商品、購物車、下單和支付四個業務，業務架構師要同時非常清楚這四部分的資料模型和業務邏輯。
其次，這個子產品要設計的足夠靈活。如果一個業務領域的需求發生了變化，比如說，訂單要增加一個新的狀态，那麼所有涉及該訂單的子產品都要知道這個變化，并要做出相應的調整。
下面畫出了電商系統的業務架構圖，僅供參考：
應用架構
應用架構就是講清楚系統内部是怎麼組織的，互相間是怎麼調用的。我們熟知的應用架構有：MVC架構、分層架構、六邊形架構。
從單個應用層面講，應用架構定義了項目包的結構，比如分層應用架構，我在這篇文章《基于 start.spring.io，我實作了 Java 腳手架定制》中介紹了實作分層應用架構的過程，它的分層結構如下圖所示：
從系統層面講，應用架構定義了各個程序間的調用與互動。下面畫出了電商系統的分層架構圖，僅供參考：
技術架構
技術架構就是對在業務架構中提出的功能進行技術方案的實作。關鍵就是講清楚系統由哪些硬體、作業系統和中間件組成，它們是如何與我們開發的應用一起配合，應對各種異常情況，保持系統的穩定可用。
這同樣要求技術架構師在計算機技術方面有深厚的功力，第一大挑戰就是：硬體。
從技術架構的角度，提升硬體的處理能力一般有兩種方式：Scale Up 和 Scale Out。垂直擴充有實體上的瓶頸或成本的問題。受硬體的實體限制，機器的性能是有天花闆的。水準擴充如何有效地管理大量的機器，硬體不是 100% 的可靠，它本身也會出問題。
第二大挑戰：軟體。
這裡的軟體，主要說的是各種中間件和系統級軟體。軟體在填硬體的各種坑的同時，也給系統挖了新的坑。
舉個例子，Redis 叢集的多節點，它解決了單節點處理能力問題，但同時也帶來了新的問題，比如 Redis 資料的多副本，它解決了單台伺服器故障帶來的可用性問題，但同時也帶來了資料的一緻性問題。
下面畫出了電商系統的技術架構圖，僅供參考：
封面
相關文章
也許你對下面文章也感興趣。
- 基于 start.spring.io，我實作了 Java 腳手架定制
- Nacos 配置中心落地與實踐