技術(shù)架構(gòu)的戰(zhàn)略和戰(zhàn)術(shù)原則，挺全乎。

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

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

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

戰(zhàn)略層的設(shè)計(jì)原則就是：合適原則、簡(jiǎn)單原則、演化原則。

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

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

1. 沒(méi)有那么多人，卻想干那么多活

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

1. 沒(méi)有那么多積累，卻想一步登天

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

1. 沒(méi)有最新，只要最合適

所有新的技術(shù)剛出來(lái)都是打著比舊技術(shù)擁有更加出色的性能、提供更加優(yōu)秀的擴(kuò)展性。是不是使用新技術(shù)，就能解決一切問(wèn)題了？新技術(shù)的出道，勢(shì)必是解決某一場(chǎng)景下的問(wèn)題，并不是一味萬(wàn)能良藥。只有了解清楚每種技術(shù)的產(chǎn)生背景，適用場(chǎng)景，才能出一個(gè)對(duì)自己項(xiàng)目最優(yōu)的選擇。技術(shù)選型沒(méi)有最新，只有最合適。

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

我們總是希望能將我們的軟件設(shè)計(jì)的精美、宏大，這樣才能彰顯我們系統(tǒng)的復(fù)雜度和難度。我們是不是會(huì)遇到這樣的場(chǎng)景，在做設(shè)計(jì)方案的時(shí)候，如果一個(gè)解決方案很簡(jiǎn)單，而且能很快的滿足需求。在評(píng)審方案時(shí)，就會(huì)有人覺(jué)得這個(gè)方案是不是太簡(jiǎn)單了，沒(méi)有什么技術(shù)含量，是不是需要再設(shè)計(jì)的復(fù)雜一點(diǎn)。

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

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

圖 1

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

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

意識(shí)到結(jié)構(gòu)復(fù)雜性的問(wèn)題后，只要減少組件就能讓系統(tǒng)結(jié)構(gòu)變簡(jiǎn)單？這樣做還是行不通，原因在于除了結(jié)構(gòu)的復(fù)雜性，還有邏輯的復(fù)雜性，如果一個(gè)組件的邏輯太復(fù)雜，通用會(huì)帶來(lái)問(wèn)題。

我們?cè)囅胍幌拢烟詫毜乃泄δ芏荚谝粋€(gè)組件中實(shí)現(xiàn)，可以想象這個(gè)系統(tǒng)要有多龐大：幾百人維護(hù)一個(gè)系統(tǒng)、代碼分支幾十個(gè)、需求變更應(yīng)接不暇、不同分支的回歸測(cè)試、修改一段代碼可能影響整個(gè)系統(tǒng)的運(yùn)行等等。這些場(chǎng)景相信大家都不希望看到的。

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

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

但是，軟件架構(gòu)和建筑架構(gòu)有一個(gè)本質(zhì)上的差異：那就是建筑一旦完成就不會(huì)再變，而軟件卻需要根據(jù)業(yè)務(wù)的發(fā)展不斷的變化。對(duì)于建筑來(lái)說(shuō)，永恒是主題；而對(duì)于軟件來(lái)說(shuō)，變化才是主題。

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

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

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

其次，架構(gòu)要不斷地在實(shí)際應(yīng)用過(guò)程中迭代，保留優(yōu)秀的設(shè)計(jì)，修復(fù)有缺陷的設(shè)計(jì)，改正錯(cuò)誤的設(shè)計(jì)，去掉無(wú)用的設(shè)計(jì)，使架構(gòu)逐漸完善。

第三，當(dāng)業(yè)務(wù)發(fā)生變化時(shí)，架構(gòu)要擴(kuò)展、重構(gòu)、甚至重寫；代碼也許會(huì)重寫，但有價(jià)值的經(jīng)驗(yàn)、教訓(xùn)、邏輯、設(shè)計(jì)卻可以在新架構(gòu)中延續(xù)。

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

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

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

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

• 有狀態(tài)配置可通過(guò)配置中心實(shí)現(xiàn)無(wú)狀態(tài)

• 系統(tǒng)維度：按照系統(tǒng)功能、業(yè)務(wù)拆分，比如購(gòu)物車、結(jié)算、訂單等。

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

• 讀寫維度：根據(jù)讀寫比例特征拆分；讀多，可考慮多級(jí)緩存；寫多，可考慮分庫(kù)分表。

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

• 模塊維度：對(duì)整體代碼結(jié)構(gòu)劃分 web、service、dao。

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

• 考慮服務(wù)分組、隔離、限流、黑白名單、超時(shí)、重試機(jī)制、路由、故障補(bǔ)償?shù)取?/p>

• 目的：服務(wù)解耦（一對(duì)多消費(fèi)）、異步處理、流量削峰緩沖等。

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

• 數(shù)據(jù)校對(duì)：解決異步消息機(jī)制下消息丟失問(wèn)題。

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

• 數(shù)據(jù)閉環(huán)：屏蔽多重?cái)?shù)據(jù)來(lái)源，將數(shù)據(jù)異構(gòu)存儲(chǔ)，形成閉環(huán)。

• 用戶層：DNS 緩存、瀏覽器 DNS 緩存、操作系統(tǒng) DNS 緩存、本地 DNS 服務(wù)商緩存、DNS 服務(wù)器緩存、客戶端緩存、瀏覽器緩存、APP 客戶端緩存。

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

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

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

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

• 降級(jí)開(kāi)關(guān)集中化管理：將開(kāi)關(guān)配置信息推送到各個(gè)應(yīng)用。

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

• 開(kāi)關(guān)前置化：如 Nginx+Lua 配置降級(jí)策略，引流流量；可基于此做灰度策略。

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

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

• 惡意請(qǐng)求流量只訪問(wèn)到 Cache

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

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

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

• 防重設(shè)計(jì)

• 冪等設(shè)計(jì)

• 流程定義

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

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

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

• 文檔注釋

• 備份

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

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

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

圖 2

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

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

圖 3

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

圖 4

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

圖 5

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

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

圖 6

演化是一個(gè)過(guò)程，這個(gè)過(guò)程或長(zhǎng)或短，所以演化需要考慮系統(tǒng)的生命周期。如果演化的過(guò)程非常漫長(zhǎng)，超出了軟件的生命周期，即使架構(gòu)越來(lái)越優(yōu)化，對(duì)于產(chǎn)品或者項(xiàng)目的幫助也將有限，所以時(shí)間這個(gè)約束條件是非常苛刻的。

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

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

到此文章就結(jié)束了。如果今天的文章對(duì)你在進(jìn)階架構(gòu)師的路上有新的啟發(fā)和進(jìn)步，歡迎轉(zhuǎn)發(fā)給更多人。歡迎加入架構(gòu)師社區(qū)技術(shù)交流群，眾多大咖帶你進(jìn)階架構(gòu)師，在后臺(tái)回復(fù)“加群”即可入群。

這些年小編給你分享過(guò)的干貨

1.SpringBoot物流管理項(xiàng)目，拿去學(xué)習(xí)吧（附源碼）

2.ERP系統(tǒng)，自帶進(jìn)銷存+財(cái)務(wù)+生產(chǎn)功能，拿來(lái)即用（附源碼）

3.帶工作流的SpringBoot后臺(tái)管理項(xiàng)目快速開(kāi)發(fā)（附源碼）
4.最好的OA系統(tǒng)，拿來(lái)即用，非常方便（附源碼）

5.SpringBoot+Vue完整的外賣系統(tǒng)，手機(jī)端和后臺(tái)管理，附源碼！

6.SpringBoot+Vue 可視化拖拽編輯的大屏項(xiàng)目（附源碼）

轉(zhuǎn)發(fā)在看就是最大的支持??