技術架構，是將產品需求轉變爲技術實現的過程。技術架構解決的問題包括瞭如何進行純技術層面的分層、開發框架選擇、語言選擇（這裏以 JAVA 語言爲主）、涉及到各自非功能性需求的技術點（安全、性能、大數據）。技術架構是肯定組成應用系統實際運行的技術組件、技術組件之間的關係，以及部署到硬件的策略。web
技術架構面臨最大的挑戰是「不肯定性」。在技術架構上，不少時候就會面臨這種選擇。是要選擇業界最新的技術？仍是選擇團隊最熟悉的技術？若是選擇最新的技術，遇到新技術出了問題怎麼解決？若是選擇目前熟悉的技術，後續技術演進怎麼辦？這些都是架構師在作技術架構過程當中須要考慮的。數據庫
業務在變幻無窮、技術在層出不窮，沒有一套通用的技術架構模式來適用全部的系統。那麼，咱們如何保證在作技術架構時，可以實現一個穩定、出色的系統。面對這些「不肯定性」時的架構設計問題，這裏從戰略和戰術兩個層面來提供一些設計原則。戰略層提供的是技術架構的方法和思路，屬於頂層設計；戰術層提供的是技術架構的技術實踐方式，更偏向詳細設計。後端
1. 戰略層設計原則
戰略層的設計原則就是：合適原則、簡單原則、演化原則。瀏覽器
1.1 合適原則
技術人員有一種很強的技術情懷，就是在作設計的過程當中，很但願挑戰新的技術、在項目中採用最新的框架、或者本身重造一個比業界的還要牛的輪子。這樣纔可以顯示出本身的優秀，以致於不讓本身顯的那麼平庸。好比，在項目中從新造一個可以解決億萬級數據的新的 xx 流式計算技術，比 flink 還要牛一百倍；有或者在項目中使用最新的 xx 技術，能讓系統承擔億級用戶的訪問。緩存
那麼現實是，若是在設計過程當中一味追求新技術，每每失敗的可能性很高。安全
沒有那麼多人，卻想幹那麼多活服務器
現實環境中咱們一個業務團隊可能就十幾我的，項目工期短、上線要求快。在這種狀況下，若是還要抽調幾我的去研究、搭建、維護新的技術框架，對於項目勢必會形成延期的影響。微信
沒有那麼多積累，卻想一步登天網絡
不少業界領先的方案，不是一幫優秀的開發加在一塊兒，加班加點就能作出來的。而是通過幾年時間的發展才逐步完善和初具規模。若是咱們也想本身作一套相似的技術，不是說不可能。咱們須要集合當下的技術實力、技術積累，作出適合本身團隊狀況的技術評估。架構
沒有最新，只要最合適
全部新的技術剛出來都是打着比舊技術擁有更加出色的性能、提供更加優秀的擴展性。是否是使用新技術，就能解決一切問題了？新技術的出道，勢必是解決某一場景下的問題，並非一味萬能良藥。只有瞭解清楚每種技術的產生背景，適用場景，才能出一個對本身項目最優的選擇。技術選型沒有最新，只有最合適。
總結一下，合適原則就是適合優於業界領先。
1.2 簡單原則
咱們老是但願能將咱們的軟件設計的精美、宏大，這樣才能彰顯咱們系統的複雜度和難度。咱們是否是會遇到這樣的場景，在作設計方案的時候，若是一個解決方案很簡單，並且能很快的知足需求。在評審方案時，就會有人以爲這個方案是否是太簡單了，沒有什麼技術含量，是否是須要再設計的複雜一點。
系統是否是必定要設計的複雜？在回答這個問題前，咱們先看下軟件領域的結構複雜性和邏輯複雜性。
結構複雜性
結構複雜的系統有兩個特色：第一，組成的組件數量不少；第二，這些組件之間的關係很複雜。以下圖：
結構上的複雜性存在的第一個問題是，組件越多，就越有可能其中某個組件出現故障，從而致使系統故障。假設組件的故障機率是 1%（有 1% 的時間不可用），那麼 2 個組件的系統可用性是 99%*99%=98%，5 個組件的系統可用性是 99%*99%*99%*99%*99%=95%，二者相差 3%。說明組件越多，系統穩定性就越差。
結構上的複雜性存在的第二個問題是，某個組件改動，會影響關聯的組件。好比上圖中 C 組件發生改動，會影響 A、B、D，而 A 有會影響 E。這樣就會造成一連串的多比諾效應。
邏輯複雜性
意識到結構複雜性的問題後，只要減小組件就能讓系統結構變簡單？這樣作仍是行不通，緣由在於除告終構的複雜性，還有邏輯的複雜性，若是一個組件的邏輯太複雜，通用會帶來問題。
咱們試想一下，把淘寶的全部功能都在一個組件中實現，能夠想象這個系統要有多龐大：幾百人維護一個系統、代碼分支幾十個、需求變動目不暇接、不一樣分支的迴歸測試、修改一段代碼可能影響整個系統的運行等等。這些場景相信你們都不但願看到的。
總結一下，簡單原則就是大道至簡。
1.3 演化原則
軟件架構和建築架構不少相同的地方，架構這個詞也是從建築領域借鑑過來的。好比，軟件架構描述的是系統的結構、以及各模塊之間的關係。而建築結構描述的是一幢建築的結構，以及建築內部各部件如何有機的組成。
可是，軟件架構和建築架構有一個本質上的差別：那就是建築一旦完成就不會再變，而軟件卻須要根據業務的發展不斷的變化。對於建築來講，永恆是主題；而對於軟件來講，變化纔是主題。
若是沒有意識到「軟件架構須要根據業務發展不斷變化」這個本質，在作架構設計的時候很容易陷入一個誤區：試圖一步到位設計一個軟件架構，指望無論業務如何變化，架構都穩如磐石。若是是按照這樣的目標是設計，一開始上來就作出一套看似是終極的方案，投入龐大的資源作各類預測、分析。結果是投入巨大的資源、開發週期漫長，最終跌跌撞撞落地的系統，卻發現已經沒法很好的知足現有的業務。
因此技術架構設計須要一個過程：
首先，要知足當前的業務需求進行技術架構設計
其次，架構要不斷地在實際應用過程當中迭代，保留優秀的設計，修復有缺陷的設計，改正錯誤的設計，去掉無用的設計，使架構逐漸完善。
第三，當業務發生變化時，架構要擴展、重構、甚至重寫；代碼也許會重寫，但有價值的經驗、教訓、邏輯、設計卻能夠在新架構中延續。
總結一下，演化原則就是演化優於一步到位。
2. 戰術層設計原則
戰術層的設計原則分爲 3 部分：高併發原則、高可用原則、業務設計原則。這些原則是對技術架構設計過程當中提供詳細的指導思路，幫助你作技術選型、技術拆分。
2.1 高併發原則
設計高併發的系統，須要考慮如下幾個方面的設計：無狀態、拆分、服務化、消息隊列、數據異構、緩存。
無狀態
無狀態應用，便於水平擴展。
有狀態配置可經過配置中心實現無狀態
拆分
系統維度：按照系統功能、業務拆分，好比購物車、結算、訂單等。
功能維度：對系統功能再作細粒度拆分。
讀寫維度：根據讀寫比例特徵拆分；讀多，可考慮多級緩存；寫多，可考慮分庫分表。
AOP 維度：根據訪問特徵，按照 AOP 進行拆分.
模塊維度：對總體代碼結構劃分 web、service、dao。
服務化
服務化演進：進程內服務 - 單機遠程服務 - 集羣手動註冊服務 - 自動註冊和發現服務 - 服務的分組、隔離、路由 - 服務治理。
考慮服務分組、隔離、限流、黑白名單、超時、重試機制、路由、故障補償等。
消息隊列
目的：服務解耦（一對多消費）、異步處理、流量削峯緩衝等。
大流量緩衝：犧牲強一致性，保障最終一致性。
數據校對：解決異步消息機制下消息丟失問題。
數據異構
數據異構：經過消息隊列機制接受數據變動，原子化存儲。
數據閉環：屏蔽多重數據來源，將數據異構存儲，造成閉環。
緩存
用戶層：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 高可用原則
降級
降級開關集中化管理：將開關配置信息推送到各個應用。
可降級的多級讀服務：如服務調用降級爲只讀本地緩存。
開關前置化：如 Nginx+Lua 配置降級策略，引流流量；可基於此作灰度策略。
業務降級：高併發下，保證核心功能，次要功能可由同步改成異步策略或屏蔽功能。
限流
目的：防止惡意請求攻擊或超過系統峯值
惡意請求流量只訪問到 Cache
穿透後端應用的流量 Nginx 的 limit 處理
惡意 Ip 使用 Nginx Deny 策略或者 iptables 拒絕
可回滾
發佈版本失敗時，可隨時快速回退到上一個穩定版本。
2.3 業務設計原則
防重設計
冪等設計
流程定義
狀態與狀態機
後臺系統操做可反饋
後臺系統審批化
文檔註釋
備份
3. 技術架構圖
技術架構圖是將系統的技術方案、技術選型經過視圖的方式進行展示。技術架構圖分爲兩類：一類，功能需求技術架構圖（邏輯架構圖），是描繪如何經過技術組件來實現系統產品功能的圖。另外一來，非功能需求技術架構圖（物理架構圖），是描繪如何經過物理部署的來實現系統運行的圖。
3.1 邏輯架構圖
功能需求技術架構圖以產品架構圖和應用架構圖爲基礎。實現每一個功能點須要使用什麼技術、技術實現邏輯如何，就提如今技術架構圖上。功能須要技術架構圖繪製能夠按照「總體 - 局部 - 總體」的思路實現。
總體
首先能夠按照應用架構圖的應用分佈獲得應用分佈框架。以下：
局部
在總體框架的基礎上，對每個局部的子系統進行詳細的技術實現的表達。子系統的技術架構圖中須要展現每一個子系統使用的技術組件，好比（緩存技術、消息中間件、流程引擎、流式計算框架等等）。同時，這些技術組件是如何實現業務功能，須要清晰的展現技術實現邏輯。
下圖是對風控系統中的實時引擎、離線引擎、準實時引擎三個子系統的進行的技術架構。在實時引擎中，主要使用 RuleEngine（規則引擎）做爲技術特色，這裏就重點列出 RuleEngine。準實時引擎使用 Blink 做爲流計算的技術框架，並概要的展現了計算邏輯。
總體
在完成每一個子系統的技術實現後，最終進行一次整合，繪製一張整體的系統技術架構圖。各子系統之間經過服務接口、數據庫、緩存或消息中間等技術實現數據交互，以此將打通各個子系統，實現最終整個產品從數據、技術的串聯。
3.2 物理架構圖
物理架構偏重於網絡設計、集羣設計、中間件設計、數據存儲設計等基礎軟硬件的設計架構。非功能需求的技術架構圖重點在於展現企業系統在物理上是如何部署。物理架構規定了組成系統的物理元素、物理元素之間的關係以及他們的部署策略。物理架構反映出軟件系統動態運行時的組織狀況。從物理架構圖中，咱們可以全局的得知整個系統是如何從流量訪問、數據流轉、數據存儲到技術組件的運轉。
4. 總結
咱們從架構的本質開始，分別對業務架構、產品架構、數據架構、應用架構、技術架構的設計提供了一些思路和原則。這些思路和原則在進行架構設計和畫架構圖的過程當中提供一些指導幫助。最後咱們再來思考一個問題，好的軟件架構是規劃仍是演化出來？
架構規劃對架構的影響是很重大的。首先，好的架構是設計出來的。好的架構，系統的性能和質量都將很高。架構設計的質量直接影響架構後續向好的方向演化的難易程度。架構設計如同城市規劃同樣，缺乏規劃將難於演化。
演化是一個過程，這個過程或長或短，因此演化須要考慮系統的生命週期。若是演化的過程很是漫長，超出了軟件的生命週期，即便架構愈來愈優化，對於產品或者項目的幫助也將有限，因此時間這個約束條件是很是苛刻的。
在現有規劃的基礎上進行演化，咱們沒法獲得普適的架構，但能夠獲得肯定領域的通用架構，能夠在特定領域經過演化使架構逐步優化，幫助業務快速的發展。
相關閱讀：
本文分享自微信公衆號 - 互聯網後端架構（fullstack888）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。