技術架構，是將產品需求轉變為技術實現的過程。技術架構解決的問題包括了如何進行純技術層面的分層、開發框架選擇、語言選擇（這裡以 JAVA 語言為主）、涉及到各自非功能性需求的技術點（安全、效能、大資料）。技術架構是確定組成應用系統實際執行的技術元件、技術元件之間的關係，以及部署到硬體的策略。

技術架構面臨最大的挑戰是“不確定性”。 在技術架構上，很多時候就會面臨這種選擇。是要選擇業界最新的技術？還是選擇團隊最熟悉的技術？如果選擇最新的技術，遇到新技術出了問題怎麼解決？如果選擇目前熟悉的技術，後續技術演進怎麼辦？這些都是架構師在做技術架構過程中需要考慮的。

業務在千變萬化、技術在層出不窮，沒有一套通用的技術架構模式來適用所有的系統。那麼，我們如何保證在做技術架構時，能夠實現一個穩定、出色的系統。面對這些“不確定性”時的架構設計問題，這裡從戰略和戰術兩個層面來提供一些設計原則。戰略層提供的是技術架構的方法和思路，屬於頂層設計；戰術層提供的是技術架構的技術實踐方式，更偏向詳細設計。

1. 戰略層設計原則

戰略層的設計原則就是：合適原則、簡單原則、演化原則。

1.1 合適原則

技術人員有一種很強的技術情懷，就是在做設計的過程中，很希望挑戰新的技術、在專案中採用最新的框架、或者自己重造一個比業界的還要牛的輪子。這樣才能夠顯示出自己的優秀，以至於不讓自己顯的那麼平庸。比如，在專案中重新造一個能夠解決億萬級資料的新的 xx 流式計算技術，比 flink 還要牛一百倍；有或者在專案中使用最新的 xx 技術，能讓系統承擔億級使用者的訪問。

那麼現實是，如果在設計過程中一味追求新技術，往往失敗的可能性很高。

1.1.1 沒有那麼多人，卻想幹那麼多活

現實環境中我們一個業務團隊可能就十幾個人，專案工期短、上線要求快。在這種情況下，如果還要抽調幾個人去研究、搭建、維護新的技術框架，對於專案勢必會造成延期的影響。

1.1.2 沒有那麼多積累，卻想一步登天

很多業界領先的方案，不是一幫優秀的開發加在一起，加班加點就能做出來的。而是經過幾年時間的發展才逐步完善和初具規模。如果我們也想自己做一套類似的技術，不是說不可能。我們需要集合當下的技術實力、技術積累，做出適合自己團隊情況的技術評估。

1.1.3沒有最新，只要最合適

所有新的技術剛出來都是打著比舊技術擁有更加出色的效能、提供更加優秀的擴充套件性。是不是使用新技術，就能解決一切問題了？新技術的出道，勢必是解決某一場景下的問題，並不是一味萬能良藥。只有了解清楚每種技術的產生背景，適用場景，才能出一個對自己專案最優的選擇。技術選型沒有最新，只有最合適。

總結一下，合適原則就是適合優於業界領先。

1.2 簡單原則

系統是不是一定要設計的複雜？在回答這個問題前，我們先看下軟體領域的結構複雜性和邏輯複雜性。

1.2.1 結構複雜性

結構複雜的系統有兩個特點：第一，組成的元件數量很多；第二，這些元件之間的關係很複雜。如下圖：

結構上的複雜性存在的第一個問題是，元件越多，就越有可能其中某個元件出現故障，從而導致系統故障。假設元件的故障概率是 1%（有 1% 的時間不可用），那麼 2 個元件的系統可用性是 99%*99%=98%，5 個元件的系統可用性是 99%*99%*99%*99%*99%=95%，兩者相差 3%。說明元件越多，系統穩定性就越差。

結構上的複雜性存在的第二個問題是，某個元件改動，會影響關聯的元件。比如上圖中 C 元件發生改動，會影響 A、B、D，而 A 有會影響 E。這樣就會形成一連串的多比諾效應。

1.2.2邏輯複雜性

意識到結構複雜性的問題後，只要減少元件就能讓系統結構變簡單？這樣做還是行不通，原因在於除了結構的複雜性，還有邏輯的複雜性，如果一個元件的邏輯太複雜，通用會帶來問題。

我們試想一下，把淘寶的所有功能都在一個元件中實現，可以想象這個系統要有多龐大：幾百人維護一個系統、程式碼分支幾十個、需求變更應接不暇、不同分支的迴歸測試、修改一段程式碼可能影響整個系統的執行等等。這些場景相信大家都不希望看到的。

總結一下，簡單原則就是大道至簡。

1.3 演化原則

軟體架構和建築架構很多相同的地方，架構這個詞也是從建築領域借鑑過來的。比如，軟體架構描述的是系統的結構、以及各模組之間的關係。而建築結構描述的是一幢建築的結構，以及建築內部各部件如何有機的組成。

但是，軟體架構和建築架構有一個本質上的差異：那就是建築一旦完成就不會再變，而軟體卻需要根據業務的發展不斷的變化。對於建築來說，永恆是主題；而對於軟體來說，變化才是主題。

如果沒有意識到“軟體架構需要根據業務發展不斷變化”這個本質，在做架構設計的時候很容易陷入一個誤區：試圖一步到位設計一個軟體架構，期望不管業務如何變化，架構都穩如磐石。如果是按照這樣的目標是設計，一開始上來就做出一套看似是終極的方案，投入龐大的資源做各種預測、分析。結果是投入巨大的資源、開發週期漫長，最終跌跌撞撞落地的系統，卻發現已經無法很好的滿足現有的業務。

所以技術架構設計需要一個過程：

首先，要滿足當前的業務需求進行技術架構設計

其次，架構要不斷地在實際應用過程中迭代，保留優秀的設計，修復有缺陷的設計，改正錯誤的設計，去掉無用的設計，使架構逐漸完善。

第三，當業務發生變化時，架構要擴充套件、重構、甚至重寫；程式碼也許會重寫，但有價值的經驗、教訓、邏輯、設計卻可以在新架構中延續。

總結一下，演化原則就是演化優於一步到位。

2. 戰術層設計原則

戰術層的設計原則分為 3 部分：高併發原則、高可用原則、業務設計原則。這些原則是對技術架構設計過程中提供詳細的指導思路，幫助你做技術選型、技術拆分。

2.1 高併發原則

設計高併發的系統，需要考慮以下幾個方面的設計：無狀態、拆分、服務化、訊息佇列、資料異構、快取。

2.1.1 無狀態

無狀態應用，便於水平擴充套件。有狀態配置可通過配置中心實現無狀態

2.1.2 拆分

系統維度：按照系統功能、業務拆分，比如購物車、結算、訂單等。功能維度：對系統功能再做細粒度拆分。讀寫維度：根據讀寫比例特徵拆分；讀多，可考慮多級快取；寫多，可考慮分庫分表。AOP 維度：根據訪問特徵，按照 AOP 進行拆分.模組維度：對整體程式碼結構劃分 web、service、dao。

2.1.3 服務化

服務化演進：程序內服務 - 單機遠端服務 - 叢集手動註冊服務 - 自動註冊和發現服務 - 服務的分組、隔離、路由 - 服務治理。考慮服務分組、隔離、限流、黑白名單、超時、重試機制、路由、故障補償等。

2.1.4 訊息佇列

目的：服務解耦（一對多消費）、非同步處理、流量削峰緩衝等。大流量緩衝：犧牲強一致性，保障最終一致性。資料校對：解決非同步訊息機制下訊息丟失問題。

2.1.5 資料異構

資料異構：通過訊息佇列機制接受資料變更，原子化儲存。資料閉環：遮蔽多重資料來源，將資料異構儲存，形成閉環。

2.1.6 快取

使用者層：DNS 快取、瀏覽器 DNS 快取、作業系統 DNS 快取、本地 DNS 服務商快取、DNS 伺服器快取、客戶端快取、瀏覽器快取、APP 客戶端快取。代理層：CDN 快取（一般基於 ATS、Varnish、Nginx、Squid 等構建，邊緣節點 - 二級節點 - 中心節點 - 源站）接入層：Nginx 的 Proxy_cache 代理快取，或者 Nginx+Lua+Redis 做業務資料快取。應用層：頁面靜態化、業務資料快取（Redis/Memcache/ 本地檔案等）、訊息佇列資料層：NoSQL（Redis、Memcache、SSDB 等）

2.2 高可用原則

2.2.1 降級

降級開關集中化管理：將開關配置資訊推送到各個應用。可降級的多級讀服務：如服務呼叫降級為只讀本地快取。開關前置化：如 Nginx+Lua 配置降級策略，引流流量；可基於此做灰度策略。業務降級：高併發下，保證核心功能，次要功能可由同步改為非同步策略或遮蔽功能。

2.2.2 限流

目的：防止惡意請求攻擊或超過系統峰值惡意請求流量只訪問到 Cache穿透後端應用的流量 Nginx 的 limit 處理惡意 Ip 使用 Nginx Deny 策略或者 iptables 拒絕

2.2.3 可回滾

釋出版本失敗時，可隨時快速回退到上一個穩定版本。

2.3 業務設計原則

防重設計冪等設計流程定義狀態與狀態機後臺系統操作可反饋後臺系統審批化文件註釋備份3. 技術架構圖

技術架構圖是將系統的技術方案、技術選型通過檢視的方式進行展現。技術架構圖分為兩類：一類，功能需求技術架構圖（邏輯架構圖），是描繪如何通過技術元件來實現系統產品功能的圖。另一來，非功能需求技術架構圖（物理架構圖），是描繪如何通過物理部署的來實現系統執行的圖。

3.1 邏輯架構圖

功能需求技術架構圖以產品架構圖和應用架構圖為基礎。實現每個功能點需要使用什麼技術、技術實現邏輯如何，就提現在技術架構圖上。功能需要技術架構圖繪製可以按照“整體 - 區域性 - 整體”的思路實現。

整體

首先可以按照應用架構圖的應用分佈得到應用分佈框架。如下：

區域性

在整體框架的基礎上，對每一個區域性的子系統進行詳細的技術實現的表達。子系統的技術架構圖中需要展示每個子系統使用的技術元件，比如（快取技術、訊息中介軟體、流程引擎、流式計算框架等等）。同時，這些技術元件是如何實現業務功能，需要清晰的展示技術實現邏輯。

下圖是對風控系統中的實時引擎、離線引擎、準實時引擎三個子系統的進行的技術架構。在實時引擎中，主要使用 RuleEngine（規則引擎）作為技術特點，這裡就重點列出 RuleEngine。準實時引擎使用 Blink 作為流計算的技術框架，並概要的展示了計算邏輯。

整體

在完成每個子系統的技術實現後，最終進行一次整合，繪製一張總體的系統技術架構圖。各子系統之間通過服務介面、資料庫、快取或訊息中間等技術實現資料互動，以此將打通各個子系統，實現最終整個產品從資料、技術的串聯。

3.2 物理架構圖

物理架構偏重於網路設計、叢集設計、中介軟體設計、資料儲存設計等基礎軟硬體的設計架構。非功能需求的技術架構圖重點在於展示企業系統在物理上是如何部署。物理架構規定了組成系統的物理元素、物理元素之間的關係以及他們的部署策略。物理架構反映出軟體系統動態執行時的組織情況。從物理架構圖中，我們能夠全域性的得知整個系統是如何從流量訪問、資料流轉、資料儲存到技術元件的運轉。

4. 總結

我們從架構的本質開始，分別對業務架構、產品架構、資料架構、應用架構、技術架構的設計提供了一些思路和原則。這些思路和原則在進行架構設計和畫架構圖的過程中提供一些指導幫助。最後我們再來思考一個問題，好的軟體架構是規劃還是演化出來？

架構規劃對架構的影響是很重大的。首先，好的架構是設計出來的。好的架構，系統的效能和品質都將很高。架構設計的品質直接影響架構後續向好的方向演化的難易程度。架構設計如同城市規劃一樣，缺少規劃將難於演化。

演化是一個過程，這個過程或長或短，所以演化需要考慮系統的生命週期。如果演化的過程非常漫長，超出了軟體的生命週期，即使架構越來越優化，對於產品或者專案的幫助也將有限，所以時間這個約束條件是非常苛刻的。

在現有規劃的基礎上進行演化，我們無法得到普適的架構，但可以得到確定領域的通用架構，可以在特定領域通過演化使架構逐步優化，幫助業務快速的發展。

作者簡介

胡斌，菜鳥網路技術專家，目前負責菜鳥風控系統的建設。曾在淘寶技術部先後負責賣家平臺、商家運營等領域。在大規模分散式應用、大資料、架構領域有多年的開發和管理經驗。