技術(shù)架構(gòu)住涉，是將產(chǎn)品需求轉(zhuǎn)變?yōu)榧夹g(shù)實現(xiàn)的過程战惊。技術(shù)架構(gòu)解決的問題包括了如何進(jìn)行純技術(shù)層面的分層缩挑、開發(fā)框架選擇但两、語言選擇（這里以 JAVA 語言為主）、涉及到各自非功能性需求的技術(shù)點（安全供置、性能谨湘、大數(shù)據(jù)）。技術(shù)架構(gòu)是確定組成應(yīng)用系統(tǒng)實際運行的技術(shù)組件芥丧、技術(shù)組件之間的關(guān)系紧阔，以及部署到硬件的策略。

技術(shù)架構(gòu)面臨最大的挑戰(zhàn)是“不確定性”续担。在技術(shù)架構(gòu)上擅耽，很多時候就會面臨這種選擇。是要選擇業(yè)界最新的技術(shù)物遇？還是選擇團(tuán)隊最熟悉的技術(shù)乖仇？如果選擇最新的技術(shù)憾儒，遇到新技術(shù)出了問題怎么解決？如果選擇目前熟悉的技術(shù)乃沙，后續(xù)技術(shù)演進(jìn)怎么辦航夺？這些都是架構(gòu)師在做技術(shù)架構(gòu)過程中需要考慮的。

業(yè)務(wù)在千變?nèi)f化崔涂、技術(shù)在層出不窮阳掐，沒有一套通用的技術(shù)架構(gòu)模式來適用所有的系統(tǒng)。那么冷蚂，我們?nèi)绾伪ＷC在做技術(shù)架構(gòu)時缭保，能夠?qū)崿F(xiàn)一個穩(wěn)定、出色的系統(tǒng)蝙茶。面對這些“不確定性”時的架構(gòu)設(shè)計問題艺骂，這里從戰(zhàn)略和戰(zhàn)術(shù)兩個層面來提供一些設(shè)計原則。戰(zhàn)略層提供的是技術(shù)架構(gòu)的方法和思路隆夯，屬于頂層設(shè)計钳恕；戰(zhàn)術(shù)層提供的是技術(shù)架構(gòu)的技術(shù)實踐方式，更偏向詳細(xì)設(shè)計蹄衷。

戰(zhàn)略層設(shè)計原則

戰(zhàn)略層的設(shè)計原則就是：合適原則忧额、簡單原則途事、演化原則电爹。

1.1 合適原則

技術(shù)人員有一種很強(qiáng)的技術(shù)情懷，就是在做設(shè)計的過程中母市，很希望挑戰(zhàn)新的技術(shù)耍属、在項目中采用最新的框架托嚣、或者自己重造一個比業(yè)界的還要牛的輪子。這樣才能夠顯示出自己的優(yōu)秀厚骗，以至于不讓自己顯的那么平庸示启。比如，在項目中重新造一個能夠解決億萬級數(shù)據(jù)的新的 xx 流式計算技術(shù)领舰，比 flink 還要牛一百倍夫嗓；有或者在項目中使用最新的 xx 技術(shù)，能讓系統(tǒng)承擔(dān)億級用戶的訪問提揍。

那么現(xiàn)實是啤月，如果在設(shè)計過程中一味追求新技術(shù)，往往失敗的可能性很高劳跃。

沒有那么多人谎仲，卻想干那么多活

現(xiàn)實環(huán)境中我們一個業(yè)務(wù)團(tuán)隊可能就十幾個人，項目工期短刨仑、上線要求快郑诺。在這種情況下夹姥，如果還要抽調(diào)幾個人去研究、搭建辙诞、維護(hù)新的技術(shù)框架辙售，對于項目勢必會造成延期的影響。

沒有那么多積累飞涂，卻想一步登天

很多業(yè)界領(lǐng)先的方案旦部，不是一幫優(yōu)秀的開發(fā)加在一起，加班加點就能做出來的较店。而是經(jīng)過幾年時間的發(fā)展才逐步完善和初具規(guī)模士八。如果我們也想自己做一套類似的技術(shù)，不是說不可能梁呈。我們需要集合當(dāng)下的技術(shù)實力婚度、技術(shù)積累，做出適合自己團(tuán)隊情況的技術(shù)評估官卡。

沒有最新蝗茁，只要最合適

所有新的技術(shù)剛出來都是打著比舊技術(shù)擁有更加出色的性能、提供更加優(yōu)秀的擴(kuò)展性寻咒。是不是使用新技術(shù)哮翘，就能解決一切問題了？新技術(shù)的出道仔涩，勢必是解決某一場景下的問題忍坷，并不是一味萬能良藥。只有了解清楚每種技術(shù)的產(chǎn)生背景熔脂，適用場景，才能出一個對自己項目最優(yōu)的選擇柑肴。技術(shù)選型沒有最新霞揉，只有最合適。

總結(jié)一下晰骑，合適原則就是適合優(yōu)于業(yè)界領(lǐng)先适秩。

1.2 簡單原則

我們總是希望能將我們的軟件設(shè)計的精美、宏大硕舆，這樣才能彰顯我們系統(tǒng)的復(fù)雜度和難度秽荞。我們是不是會遇到這樣的場景，在做設(shè)計方案的時候抚官，如果一個解決方案很簡單扬跋，而且能很快的滿足需求。在評審方案時凌节，就會有人覺得這個方案是不是太簡單了钦听，沒有什么技術(shù)含量洒试，是不是需要再設(shè)計的復(fù)雜一點。

系統(tǒng)是不是一定要設(shè)計的復(fù)雜朴上？在回答這個問題前垒棋，我們先看下軟件領(lǐng)域的結(jié)構(gòu)復(fù)雜性和邏輯復(fù)雜性。

（1）結(jié)構(gòu)復(fù)雜性

結(jié)構(gòu)復(fù)雜的系統(tǒng)有兩個特點：第一痪宰，組成的組件數(shù)量很多叼架；第二，這些組件之間的關(guān)系很復(fù)雜衣撬。如下圖：

圖 1

結(jié)構(gòu)上的復(fù)雜性存在的第一個問題是碉碉，組件越多，就越有可能其中某個組件出現(xiàn)故障淮韭，從而導(dǎo)致系統(tǒng)故障垢粮。假設(shè)組件的故障概率是 1%（有 1% 的時間不可用），那么 2 個組件的系統(tǒng)可用性是 99%*99%=98%靠粪，5 個組件的系統(tǒng)可用性是 99%*99%*99%*99%*99%=95%蜡吧，兩者相差 3%。說明組件越多占键，系統(tǒng)穩(wěn)定性就越差昔善。

結(jié)構(gòu)上的復(fù)雜性存在的第二個問題是，某個組件改動畔乙，會影響關(guān)聯(lián)的組件君仆。比如上圖中 C 組件發(fā)生改動，會影響 A牲距、B返咱、D，而 A 有會影響 E牍鞠。這樣就會形成一連串的多比諾效應(yīng)咖摹。

?（2）邏輯復(fù)雜性

意識到結(jié)構(gòu)復(fù)雜性的問題后，只要減少組件就能讓系統(tǒng)結(jié)構(gòu)變簡單难述？這樣做還是行不通萤晴，原因在于除了結(jié)構(gòu)的復(fù)雜性，還有邏輯的復(fù)雜性胁后，如果一個組件的邏輯太復(fù)雜店读，通用會帶來問題。

我們試想一下攀芯，把淘寶的所有功能都在一個組件中實現(xiàn)屯断，可以想象這個系統(tǒng)要有多龐大：幾百人維護(hù)一個系統(tǒng)、代碼分支幾十個、需求變更應(yīng)接不暇裹纳、不同分支的回歸測試择葡、修改一段代碼可能影響整個系統(tǒng)的運行等等。這些場景相信大家都不希望看到的剃氧。

總結(jié)一下敏储，簡單原則就是大道至簡。

1.3 演化原則

軟件架構(gòu)和建筑架構(gòu)很多相同的地方朋鞍，架構(gòu)這個詞也是從建筑領(lǐng)域借鑒過來的已添。比如，軟件架構(gòu)描述的是系統(tǒng)的結(jié)構(gòu)滥酥、以及各模塊之間的關(guān)系更舞。而建筑結(jié)構(gòu)描述的是一幢建筑的結(jié)構(gòu)，以及建筑內(nèi)部各部件如何有機(jī)的組成坎吻。

但是缆蝉，軟件架構(gòu)和建筑架構(gòu)有一個本質(zhì)上的差異：那就是建筑一旦完成就不會再變，而軟件卻需要根據(jù)業(yè)務(wù)的發(fā)展不斷的變化瘦真。對于建筑來說刊头，永恒是主題；而對于軟件來說诸尽，變化才是主題原杂。

如果沒有意識到“軟件架構(gòu)需要根據(jù)業(yè)務(wù)發(fā)展不斷變化”這個本質(zhì)，在做架構(gòu)設(shè)計的時候很容易陷入一個誤區(qū)：試圖一步到位設(shè)計一個軟件架構(gòu)您机，期望不管業(yè)務(wù)如何變化穿肄，架構(gòu)都穩(wěn)如磐石。如果是按照這樣的目標(biāo)是設(shè)計际看，一開始上來就做出一套看似是終極的方案咸产，投入龐大的資源做各種預(yù)測、分析仿村。結(jié)果是投入巨大的資源锐朴、開發(fā)周期漫長，最終跌跌撞撞落地的系統(tǒng)蔼囊，卻發(fā)現(xiàn)已經(jīng)無法很好的滿足現(xiàn)有的業(yè)務(wù)。

所以技術(shù)架構(gòu)設(shè)計需要一個過程：

首先衣迷，要滿足當(dāng)前的業(yè)務(wù)需求進(jìn)行技術(shù)架構(gòu)設(shè)計

其次畏鼓，架構(gòu)要不斷地在實際應(yīng)用過程中迭代，保留優(yōu)秀的設(shè)計壶谒，修復(fù)有缺陷的設(shè)計云矫，改正錯誤的設(shè)計，去掉無用的設(shè)計汗菜，使架構(gòu)逐漸完善让禀。

第三挑社，當(dāng)業(yè)務(wù)發(fā)生變化時，架構(gòu)要擴(kuò)展巡揍、重構(gòu)痛阻、甚至重寫；代碼也許會重寫腮敌，但有價值的經(jīng)驗阱当、教訓(xùn)、邏輯糜工、設(shè)計卻可以在新架構(gòu)中延續(xù)弊添。

總結(jié)一下，演化原則就是演化優(yōu)于一步到位捌木。

戰(zhàn)術(shù)層設(shè)計原則

戰(zhàn)術(shù)層的設(shè)計原則分為 3 部分：高并發(fā)原則油坝、高可用原則、業(yè)務(wù)設(shè)計原則刨裆。這些原則是對技術(shù)架構(gòu)設(shè)計過程中提供詳細(xì)的指導(dǎo)思路澈圈，幫助你做技術(shù)選型、技術(shù)拆分崔拥。

2.1 高并發(fā)原則

設(shè)計高并發(fā)的系統(tǒng)极舔，需要考慮以下幾個方面的設(shè)計：無狀態(tài)、拆分链瓦、服務(wù)化拆魏、消息隊列、數(shù)據(jù)異構(gòu)慈俯、緩存渤刃。

（1）無狀態(tài)

無狀態(tài)應(yīng)用，便于水平擴(kuò)展贴膘。

有狀態(tài)配置可通過配置中心實現(xiàn)無狀

（2）?拆分

系統(tǒng)維度：按照系統(tǒng)功能卖子、業(yè)務(wù)拆分，比如購物車刑峡、結(jié)算洋闽、訂單等。

功能維度：對系統(tǒng)功能再做細(xì)粒度拆分突梦。

讀寫維度：根據(jù)讀寫比例特征拆分诫舅；讀多，可考慮多級緩存宫患；寫多刊懈，可考慮分庫分表。

AOP 維度：根據(jù)訪問特征，按照 AOP 進(jìn)行拆分.

模塊維度：對整體代碼結(jié)構(gòu)劃分 web虚汛、service匾浪、dao。

（3）服務(wù)化

服務(wù)化演進(jìn)：進(jìn)程內(nèi)服務(wù) - 單機(jī)遠(yuǎn)程服務(wù) - 集群手動注冊服務(wù) - 自動注冊和發(fā)現(xiàn)服務(wù) - 服務(wù)的分組卷哩、隔離蛋辈、路由 - 服務(wù)治理。

考慮服務(wù)分組殉疼、隔離梯浪、限流、黑白名單瓢娜、超時挂洛、重試機(jī)制、路由眠砾、故障補(bǔ)償?shù)取?/p>

（4）消息隊列

目的：服務(wù)解耦（一對多消費）虏劲、異步處理、流量削峰緩沖等褒颈。

大流量緩沖：犧牲強(qiáng)一致性柒巫，保障最終一致性。

數(shù)據(jù)校對：解決異步消息機(jī)制下消息丟失問題谷丸。

（5）數(shù)據(jù)異構(gòu)

數(shù)據(jù)異構(gòu)：通過消息隊列機(jī)制接受數(shù)據(jù)變更堡掏，原子化存儲。

數(shù)據(jù)閉環(huán)：屏蔽多重數(shù)據(jù)來源刨疼，將數(shù)據(jù)異構(gòu)存儲泉唁，形成閉環(huán)。

?（6）緩存

用戶層：DNS 緩存揩慕、瀏覽器 DNS 緩存亭畜、操作系統(tǒng) DNS 緩存、本地 DNS 服務(wù)商緩存迎卤、DNS 服務(wù)器緩存拴鸵、客戶端緩存、瀏覽器緩存蜗搔、APP 客戶端緩存劲藐。

代理層：CDN 緩存（一般基于 ATS、Varnish樟凄、Nginx瘩燥、Squid 等構(gòu)建，邊緣節(jié)點 - 二級節(jié)點 - 中心節(jié)點 - 源站）

接入層：Nginx 的 Proxy_cache 代理緩存不同，或者 Nginx+Lua+Redis 做業(yè)務(wù)數(shù)據(jù)緩存。

應(yīng)用層：頁面靜態(tài)化、業(yè)務(wù)數(shù)據(jù)緩存（Redis/Memcache/ 本地文件等）二拐、消息隊列

數(shù)據(jù)層：NoSQL（Redis服鹅、Memcache、SSDB 等）

2.2 高可用原則

1. 降級

降級開關(guān)集中化管理：將開關(guān)配置信息推送到各個應(yīng)用百新。

可降級的多級讀服務(wù)：如服務(wù)調(diào)用降級為只讀本地緩存企软。

開關(guān)前置化：如 Nginx+Lua 配置降級策略，引流流量饭望；可基于此做灰度策略仗哨。

業(yè)務(wù)降級：高并發(fā)下，保證核心功能铅辞，次要功能可由同步改為異步策略或屏蔽功能厌漂。

搜索公眾號Java后端棧回復(fù)“面試”斟珊，送你一份驚喜禮包苇倡。

2. 限流

目的：防止惡意請求攻擊或超過系統(tǒng)峰值

惡意請求流量只訪問到 Cache

穿透后端應(yīng)用的流量 Nginx 的 limit 處理

惡意 Ip 使用 Nginx Deny 策略或者 iptables 拒絕

3. 可回滾

發(fā)布版本失敗時，可隨時快速回退到上一個穩(wěn)定版本囤踩。

2.3 業(yè)務(wù)設(shè)計原則

防重設(shè)計

冪等設(shè)計

流程定義

狀態(tài)與狀態(tài)機(jī)

后臺系統(tǒng)操作可反饋

后臺系統(tǒng)審批化

文檔注釋

備份

技術(shù)架構(gòu)圖

技術(shù)架構(gòu)圖是將系統(tǒng)的技術(shù)方案旨椒、技術(shù)選型通過視圖的方式進(jìn)行展現(xiàn)。技術(shù)架構(gòu)圖分為兩類：一類堵漱，功能需求技術(shù)架構(gòu)圖（邏輯架構(gòu)圖）综慎，是描繪如何通過技術(shù)組件來實現(xiàn)系統(tǒng)產(chǎn)品功能的圖。另一來勤庐，非功能需求技術(shù)架構(gòu)圖（物理架構(gòu)圖）示惊，是描繪如何通過物理部署的來實現(xiàn)系統(tǒng)運行的圖。

3.1 邏輯架構(gòu)圖

功能需求技術(shù)架構(gòu)圖以產(chǎn)品架構(gòu)圖和應(yīng)用架構(gòu)圖為基礎(chǔ)埃元。實現(xiàn)每個功能點需要使用什么技術(shù)涝涤、技術(shù)實現(xiàn)邏輯如何，就提現(xiàn)在技術(shù)架構(gòu)圖上岛杀。功能需要技術(shù)架構(gòu)圖繪制可以按照“整體 - 局部 - 整體”的思路實現(xiàn)阔拳。

?1. 整體

首先可以按照應(yīng)用架構(gòu)圖的應(yīng)用分布得到應(yīng)用分布框架。如下：

圖 2

2. 局部

在整體框架的基礎(chǔ)上类嗤，對每一個局部的子系統(tǒng)進(jìn)行詳細(xì)的技術(shù)實現(xiàn)的表達(dá)糊肠。子系統(tǒng)的技術(shù)架構(gòu)圖中需要展示每個子系統(tǒng)使用的技術(shù)組件，比如（緩存技術(shù)遗锣、消息中間件货裹、流程引擎、流式計算框架等等）精偿。同時弧圆，這些技術(shù)組件是如何實現(xiàn)業(yè)務(wù)功能赋兵，需要清晰的展示技術(shù)實現(xiàn)邏輯。

下圖是對風(fēng)控系統(tǒng)中的實時引擎搔预、離線引擎霹期、準(zhǔn)實時引擎三個子系統(tǒng)的進(jìn)行的技術(shù)架構(gòu)。在實時引擎中拯田，主要使用 RuleEngine（規(guī)則引擎）作為技術(shù)特點历造，這里就重點列出 RuleEngine。準(zhǔn)實時引擎使用 Blink 作為流計算的技術(shù)框架船庇，并概要的展示了計算邏輯吭产。

圖 3

?3. 整體

在完成每個子系統(tǒng)的技術(shù)實現(xiàn)后，最終進(jìn)行一次整合鸭轮，繪制一張總體的系統(tǒng)技術(shù)架構(gòu)圖臣淤。各子系統(tǒng)之間通過服務(wù)接口、數(shù)據(jù)庫张弛、緩存或消息中間等技術(shù)實現(xiàn)數(shù)據(jù)交互荒典，以此將打通各個子系統(tǒng)，實現(xiàn)最終整個產(chǎn)品從數(shù)據(jù)吞鸭、技術(shù)的串聯(lián)寺董。

圖 4

3.2 物理架構(gòu)圖

物理架構(gòu)偏重于網(wǎng)絡(luò)設(shè)計、集群設(shè)計刻剥、中間件設(shè)計遮咖、數(shù)據(jù)存儲設(shè)計等基礎(chǔ)軟硬件的設(shè)計架構(gòu)。非功能需求的技術(shù)架構(gòu)圖重點在于展示企業(yè)系統(tǒng)在物理上是如何部署造虏。物理架構(gòu)規(guī)定了組成系統(tǒng)的物理元素御吞、物理元素之間的關(guān)系以及他們的部署策略。物理架構(gòu)反映出軟件系統(tǒng)動態(tài)運行時的組織情況漓藕。從物理架構(gòu)圖中陶珠，我們能夠全局的得知整個系統(tǒng)是如何從流量訪問、數(shù)據(jù)流轉(zhuǎn)享钞、數(shù)據(jù)存儲到技術(shù)組件的運轉(zhuǎn)揍诽。

圖?5

總? 結(jié)

我們從架構(gòu)的本質(zhì)開始，分別對業(yè)務(wù)架構(gòu)栗竖、產(chǎn)品架構(gòu)暑脆、數(shù)據(jù)架構(gòu)、應(yīng)用架構(gòu)狐肢、技術(shù)架構(gòu)的設(shè)計提供了一些思路和原則添吗。這些思路和原則在進(jìn)行架構(gòu)設(shè)計和畫架構(gòu)圖的過程中提供一些指導(dǎo)幫助。最后我們再來思考一個問題份名，好的軟件架構(gòu)是規(guī)劃還是演化出來碟联？

架構(gòu)規(guī)劃對架構(gòu)的影響是很重大的妓美。首先，好的架構(gòu)是設(shè)計出來的玄帕。好的架構(gòu)部脚，系統(tǒng)的性能和質(zhì)量都將很高。架構(gòu)設(shè)計的質(zhì)量直接影響架構(gòu)后續(xù)向好的方向演化的難易程度裤纹。架構(gòu)設(shè)計如同城市規(guī)劃一樣，缺少規(guī)劃將難于演化丧没。

圖 6

演化是一個過程鹰椒，這個過程或長或短，所以演化需要考慮系統(tǒng)的生命周期呕童。如果演化的過程非常漫長漆际，超出了軟件的生命周期，即使架構(gòu)越來越優(yōu)化夺饲，對于產(chǎn)品或者項目的幫助也將有限奸汇，所以時間這個約束條件是非常苛刻的往声。

在現(xiàn)有規(guī)劃的基礎(chǔ)上進(jìn)行演化擂找，我們無法得到普適的架構(gòu)，但可以得到確定領(lǐng)域的通用架構(gòu)浩销，可以在特定領(lǐng)域通過演化使架構(gòu)逐步優(yōu)化贯涎，幫助業(yè)務(wù)快速的發(fā)展。

?作者簡介

胡斌慢洋，菜鳥網(wǎng)絡(luò)技術(shù)專家塘雳，目前負(fù)責(zé)菜鳥風(fēng)控系統(tǒng)的建設(shè)。曾在淘寶技術(shù)部先后負(fù)責(zé)賣家平臺普筹、商家運營等領(lǐng)域败明。在大規(guī)模分布式應(yīng)用、大數(shù)據(jù)太防、架構(gòu)領(lǐng)域有多年的開發(fā)和管理經(jīng)驗妻顶。

原地址：https://mp.weixin.qq.com/s/O9EOqzyxp8uBjHqMKeFgIg