菜鸟网络技术专家:技术架构的战略和战术原则
點(diǎn)擊上方“朱小廝的博客”,選擇“設(shè)為星標(biāo)”
后臺回復(fù)"書",獲取
作者丨胡斌
策劃丨小智
技術(shù)架構(gòu),是將產(chǎn)品需求轉(zhuǎn)變?yōu)榧夹g(shù)實(shí)現(xiàn)的過程。技術(shù)架構(gòu)解決的問題包括了如何進(jìn)行純技術(shù)層面的分層、開發(fā)框架選擇、語言選擇(這里以 JAVA 語言為主)、涉及到各自非功能性需求的技術(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)上,很多時候就會面臨這種選擇。是要選擇業(yè)界最新的技術(shù)?還是選擇團(tuán)隊(duì)最熟悉的技術(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)绾伪WC在做技術(shù)架構(gòu)時,能夠?qū)崿F(xiàn)一個穩(wěn)定、出色的系統(tǒng)。面對這些“不確定性”時的架構(gòu)設(shè)計(jì)問題,這里從戰(zhàn)略和戰(zhàn)術(shù)兩個層面來提供一些設(shè)計(jì)原則。戰(zhàn)略層提供的是技術(shù)架構(gòu)的方法和思路,屬于頂層設(shè)計(jì);戰(zhàn)術(shù)層提供的是技術(shù)架構(gòu)的技術(shù)實(shí)踐方式,更偏向詳細(xì)設(shè)計(jì)。
戰(zhàn)略層設(shè)計(jì)原則
戰(zhàn)略層的設(shè)計(jì)原則就是:合適原則、簡單原則、演化原則。
1.1 合適原則
技術(shù)人員有一種很強(qiáng)的技術(shù)情懷,就是在做設(shè)計(jì)的過程中,很希望挑戰(zhàn)新的技術(shù)、在項(xiàng)目中采用最新的框架、或者自己重造一個比業(yè)界的還要牛的輪子。這樣才能夠顯示出自己的優(yōu)秀,以至于不讓自己顯的那么平庸。比如,在項(xiàng)目中重新造一個能夠解決億萬級數(shù)據(jù)的新的 xx 流式計(jì)算技術(shù),比 flink 還要牛一百倍;有或者在項(xiàng)目中使用最新的 xx 技術(shù),能讓系統(tǒng)承擔(dān)億級用戶的訪問。
那么現(xiàn)實(shí)是,如果在設(shè)計(jì)過程中一味追求新技術(shù),往往失敗的可能性很高。
沒有那么多人,卻想干那么多活
現(xiàn)實(shí)環(huán)境中我們一個業(yè)務(wù)團(tuán)隊(duì)可能就十幾個人,項(xiàng)目工期短、上線要求快。在這種情況下,如果還要抽調(diào)幾個人去研究、搭建、維護(hù)新的技術(shù)框架,對于項(xiàng)目勢必會造成延期的影響。
沒有那么多積累,卻想一步登天
很多業(yè)界領(lǐng)先的方案,不是一幫優(yōu)秀的開發(fā)加在一起,加班加點(diǎn)就能做出來的。而是經(jīng)過幾年時間的發(fā)展才逐步完善和初具規(guī)模。如果我們也想自己做一套類似的技術(shù),不是說不可能。我們需要集合當(dāng)下的技術(shù)實(shí)力、技術(shù)積累,做出適合自己團(tuán)隊(duì)情況的技術(shù)評估。
沒有最新,只要最合適
所有新的技術(shù)剛出來都是打著比舊技術(shù)擁有更加出色的性能、提供更加優(yōu)秀的擴(kuò)展性。是不是使用新技術(shù),就能解決一切問題了?新技術(shù)的出道,勢必是解決某一場景下的問題,并不是一味萬能良藥。只有了解清楚每種技術(shù)的產(chǎn)生背景,適用場景,才能出一個對自己項(xiàng)目最優(yōu)的選擇。技術(shù)選型沒有最新,只有最合適。
總結(jié)一下,合適原則就是適合優(yōu)于業(yè)界領(lǐng)先。
1.2 簡單原則
我們總是希望能將我們的軟件設(shè)計(jì)的精美、宏大,這樣才能彰顯我們系統(tǒng)的復(fù)雜度和難度。我們是不是會遇到這樣的場景,在做設(shè)計(jì)方案的時候,如果一個解決方案很簡單,而且能很快的滿足需求。在評審方案時,就會有人覺得這個方案是不是太簡單了,沒有什么技術(shù)含量,是不是需要再設(shè)計(jì)的復(fù)雜一點(diǎn)。
系統(tǒng)是不是一定要設(shè)計(jì)的復(fù)雜?在回答這個問題前,我們先看下軟件領(lǐng)域的結(jié)構(gòu)復(fù)雜性和邏輯復(fù)雜性。
?1. 結(jié)構(gòu)復(fù)雜性
結(jié)構(gòu)復(fù)雜的系統(tǒng)有兩個特點(diǎn):第一,組成的組件數(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ù)雜,通用會帶來問題。
我們試想一下,把淘寶的所有功能都在一個組件中實(shí)現(xiàn),可以想象這個系統(tǒng)要有多龐大:幾百人維護(hù)一個系統(tǒng)、代碼分支幾十個、需求變更應(yīng)接不暇、不同分支的回歸測試、修改一段代碼可能影響整個系統(tǒng)的運(yùn)行等等。這些場景相信大家都不希望看到的。
總結(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è)計(jì)的時候很容易陷入一個誤區(qū):試圖一步到位設(shè)計(jì)一個軟件架構(gòu),期望不管業(yè)務(wù)如何變化,架構(gòu)都穩(wěn)如磐石。如果是按照這樣的目標(biāo)是設(shè)計(jì),一開始上來就做出一套看似是終極的方案,投入龐大的資源做各種預(yù)測、分析。結(jié)果是投入巨大的資源、開發(fā)周期漫長,最終跌跌撞撞落地的系統(tǒng),卻發(fā)現(xiàn)已經(jīng)無法很好的滿足現(xiàn)有的業(yè)務(wù)。
所以技術(shù)架構(gòu)設(shè)計(jì)需要一個過程:
首先,要滿足當(dāng)前的業(yè)務(wù)需求進(jìn)行技術(shù)架構(gòu)設(shè)計(jì)
其次,架構(gòu)要不斷地在實(shí)際應(yīng)用過程中迭代,保留優(yōu)秀的設(shè)計(jì),修復(fù)有缺陷的設(shè)計(jì),改正錯誤的設(shè)計(jì),去掉無用的設(shè)計(jì),使架構(gòu)逐漸完善。
第三,當(dāng)業(yè)務(wù)發(fā)生變化時,架構(gòu)要擴(kuò)展、重構(gòu)、甚至重寫;代碼也許會重寫,但有價值的經(jīng)驗(yàn)、教訓(xùn)、邏輯、設(shè)計(jì)卻可以在新架構(gòu)中延續(xù)。
總結(jié)一下,演化原則就是演化優(yōu)于一步到位。
戰(zhàn)術(shù)層設(shè)計(jì)原則
戰(zhàn)術(shù)層的設(shè)計(jì)原則分為 3 部分:高并發(fā)原則、高可用原則、業(yè)務(wù)設(shè)計(jì)原則。這些原則是對技術(shù)架構(gòu)設(shè)計(jì)過程中提供詳細(xì)的指導(dǎo)思路,幫助你做技術(shù)選型、技術(shù)拆分。
2.1 高并發(fā)原則
設(shè)計(jì)高并發(fā)的系統(tǒng),需要考慮以下幾個方面的設(shè)計(jì):無狀態(tài)、拆分、服務(wù)化、消息隊(duì)列、數(shù)據(jù)異構(gòu)、緩存。
?1. 無狀態(tài)
- 無狀態(tài)應(yīng)用,便于水平擴(kuò)展。 
- 有狀態(tài)配置可通過配置中心實(shí)現(xiàn)無狀態(tài) 
?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. 消息隊(duì)列
- 目的:服務(wù)解耦(一對多消費(fèi))、異步處理、流量削峰緩沖等。 
- 大流量緩沖:犧牲強(qiáng)一致性,保障最終一致性。 
- 數(shù)據(jù)校對:解決異步消息機(jī)制下消息丟失問題。 
?5. 數(shù)據(jù)異構(gòu)
- 數(shù)據(jù)異構(gòu):通過消息隊(duì)列機(jī)制接受數(shù)據(jù)變更,原子化存儲。 
- 數(shù)據(jù)閉環(huán):屏蔽多重?cái)?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é)點(diǎn) - 二級節(jié)點(diǎn) - 中心節(jié)點(diǎn) - 源站) 
- 接入層:Nginx 的 Proxy_cache 代理緩存,或者 Nginx+Lua+Redis 做業(yè)務(wù)數(shù)據(jù)緩存。 
- 應(yīng)用層:頁面靜態(tài)化、業(yè)務(wù)數(shù)據(jù)緩存(Redis/Memcache/ 本地文件等)、消息隊(duì)列 
- 數(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ā)下,保證核心功能,次要功能可由同步改為異步策略或屏蔽功能。 
?2. 限流
- 目的:防止惡意請求攻擊或超過系統(tǒng)峰值 
- 惡意請求流量只訪問到 Cache 
- 穿透后端應(yīng)用的流量 Nginx 的 limit 處理 
- 惡意 Ip 使用 Nginx Deny 策略或者 iptables 拒絕 
?3. 可回滾
- 發(fā)布版本失敗時,可隨時快速回退到上一個穩(wěn)定版本。 
2.3 業(yè)務(wù)設(shè)計(jì)原則
- 防重設(shè)計(jì) 
- 冪等設(shè)計(jì) 
- 流程定義 
- 狀態(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ù)組件來實(shí)現(xiàn)系統(tǒng)產(chǎn)品功能的圖。另一來,非功能需求技術(shù)架構(gòu)圖(物理架構(gòu)圖),是描繪如何通過物理部署的來實(shí)現(xiàn)系統(tǒng)運(yùn)行的圖。
3.1 邏輯架構(gòu)圖
功能需求技術(shù)架構(gòu)圖以產(chǎn)品架構(gòu)圖和應(yīng)用架構(gòu)圖為基礎(chǔ)。實(shí)現(xiàn)每個功能點(diǎn)需要使用什么技術(shù)、技術(shù)實(shí)現(xiàn)邏輯如何,就提現(xiàn)在技術(shù)架構(gòu)圖上。功能需要技術(shù)架構(gòu)圖繪制可以按照“整體 - 局部 - 整體”的思路實(shí)現(xiàn)。
?1. 整體
首先可以按照應(yīng)用架構(gòu)圖的應(yīng)用分布得到應(yīng)用分布框架。如下:
圖 2
?2. 局部
在整體框架的基礎(chǔ)上,對每一個局部的子系統(tǒng)進(jìn)行詳細(xì)的技術(shù)實(shí)現(xiàn)的表達(dá)。子系統(tǒng)的技術(shù)架構(gòu)圖中需要展示每個子系統(tǒng)使用的技術(shù)組件,比如(緩存技術(shù)、消息中間件、流程引擎、流式計(jì)算框架等等)。同時,這些技術(shù)組件是如何實(shí)現(xiàn)業(yè)務(wù)功能,需要清晰的展示技術(shù)實(shí)現(xiàn)邏輯。
下圖是對風(fēng)控系統(tǒng)中的實(shí)時引擎、離線引擎、準(zhǔn)實(shí)時引擎三個子系統(tǒng)的進(jìn)行的技術(shù)架構(gòu)。在實(shí)時引擎中,主要使用 RuleEngine(規(guī)則引擎)作為技術(shù)特點(diǎn),這里就重點(diǎn)列出 RuleEngine。準(zhǔn)實(shí)時引擎使用 Blink 作為流計(jì)算的技術(shù)框架,并概要的展示了計(jì)算邏輯。
圖 3
?3. 整體
在完成每個子系統(tǒng)的技術(shù)實(shí)現(xiàn)后,最終進(jìn)行一次整合,繪制一張總體的系統(tǒng)技術(shù)架構(gòu)圖。各子系統(tǒng)之間通過服務(wù)接口、數(shù)據(jù)庫、緩存或消息中間等技術(shù)實(shí)現(xiàn)數(shù)據(jù)交互,以此將打通各個子系統(tǒng),實(shí)現(xiàn)最終整個產(chǎn)品從數(shù)據(jù)、技術(shù)的串聯(lián)。
圖 4
3.2 物理架構(gòu)圖
物理架構(gòu)偏重于網(wǎng)絡(luò)設(shè)計(jì)、集群設(shè)計(jì)、中間件設(shè)計(jì)、數(shù)據(jù)存儲設(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)動態(tài)運(yùn)行時的組織情況。從物理架構(gòu)圖中,我們能夠全局的得知整個系統(tǒng)是如何從流量訪問、數(shù)據(jù)流轉(zhuǎn)、數(shù)據(jù)存儲到技術(shù)組件的運(yùn)轉(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ì)提供了一些思路和原則。這些思路和原則在進(jìn)行架構(gòu)設(shè)計(jì)和畫架構(gòu)圖的過程中提供一些指導(dǎo)幫助。最后我們再來思考一個問題,好的軟件架構(gòu)是規(guī)劃還是演化出來?
架構(gòu)規(guī)劃對架構(gòu)的影響是很重大的。首先,好的架構(gòu)是設(shè)計(jì)出來的。好的架構(gòu),系統(tǒng)的性能和質(zhì)量都將很高。架構(gòu)設(shè)計(jì)的質(zhì)量直接影響架構(gòu)后續(xù)向好的方向演化的難易程度。架構(gòu)設(shè)計(jì)如同城市規(guī)劃一樣,缺少規(guī)劃將難于演化。
圖 6
演化是一個過程,這個過程或長或短,所以演化需要考慮系統(tǒng)的生命周期。如果演化的過程非常漫長,超出了軟件的生命周期,即使架構(gòu)越來越優(yōu)化,對于產(chǎn)品或者項(xiàng)目的幫助也將有限,所以時間這個約束條件是非常苛刻的。
在現(xiàn)有規(guī)劃的基礎(chǔ)上進(jìn)行演化,我們無法得到普適的架構(gòu),但可以得到確定領(lǐng)域的通用架構(gòu),可以在特定領(lǐng)域通過演化使架構(gòu)逐步優(yōu)化,幫助業(yè)務(wù)快速的發(fā)展。
想知道更多?掃描下面的二維碼關(guān)注我
后臺回復(fù)"技術(shù)",加入技術(shù)群
當(dāng)當(dāng)實(shí)付滿200-40優(yōu)惠碼:NBHH2P
【精彩推薦】
- 超清晰的DNS入門指南
- 深入理解Java Stream流水線
- 如何用ELK搭建TB級的日志系統(tǒng)
- 深度好文:Linux系統(tǒng)內(nèi)存知識
- 日志系統(tǒng)新貴Loki,確實(shí)比笨重的ELK輕
- 日志采集系統(tǒng)都用到哪些技術(shù)?
- 面試官:為什么HashMap的加載因子是0.75?
- 原創(chuàng)|OpenAPI標(biāo)準(zhǔn)規(guī)范
- Linux系統(tǒng)內(nèi)存知識總結(jié)
- 深度好文|奈飛微服務(wù)架構(gòu)解析
- 耗時3天,上億數(shù)據(jù)如何做到秒級查詢
點(diǎn)個贊+在看,少個 bug?????
超強(qiáng)干貨來襲 云風(fēng)專訪:近40年碼齡,通宵達(dá)旦的技術(shù)人生總結(jié)
以上是生活随笔為你收集整理的菜鸟网络技术专家:技术架构的战略和战术原则的全部內(nèi)容,希望文章能夠幫你解決所遇到的問題。
 
                            
                        - 上一篇: 老司机给我们解读 Spring Boot
- 下一篇: ClickHouse到底是什么?凭啥这么
