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

1、技術(shù)架構(gòu)的戰(zhàn)略和戰(zhàn)術(shù)原則技術(shù)架構(gòu)，是將產(chǎn)品需求轉(zhuǎn)變?yōu)榧夹g(shù)實現(xiàn)的過程。技術(shù)架構(gòu)解決的問題包括了如何進行純技術(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ù)？還是選擇團隊最熟悉的技術(shù)？如果選擇最新的技術(shù)，遇到新技術(shù)出了問題怎么解決？如果選擇目前熟悉的技術(shù)，后續(xù)技術(shù)演進怎么辦？這些都是架構(gòu)師在做技術(shù)架構(gòu)過程中需要考慮的。業(yè)務(wù)在千變?nèi)f化、技術(shù)在層出

2、不窮，沒有一套通用的技術(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ù)實踐方式，更偏向詳細設(shè)計。戰(zhàn)略層設(shè)計原則戰(zhàn)略層的設(shè)計原則就是：合適原則、簡單原則、演化原則。合適原則技術(shù)人員有一種很強的技術(shù)情懷，就是在做設(shè)計的過程中，很希望挑戰(zhàn)新的技術(shù)、在項目中采用最新的框架、或者自己重造一個比業(yè)界的還要牛的輪子。這樣才能夠顯示出自己的優(yōu)秀，以至于不讓自己顯的那么平庸。比如，在項目中重新造一個能夠解決億萬

3、級數(shù)據(jù)的新的xx流式計算技術(shù)，比flink還要牛一百倍；有或者在項目中使用最新的xx技術(shù)，能讓系統(tǒng)承擔(dān)億級用戶的訪問。那么現(xiàn)實是，如果在設(shè)計過程中一味追求新技術(shù)，往往失敗的可能性很高。沒有那么多人，卻想干那么多活現(xiàn)實環(huán)境中我們一個業(yè)務(wù)團隊可能就十幾個人，項目工期短、上線要求快。在這種情況下，如果還要抽調(diào)幾個人去研究、搭建、維護新的技術(shù)框架，對于項目勢必會造成延期的影響。1.沒有那么多積累，卻想一步登天很多業(yè)界領(lǐng)先的方案，不是一幫優(yōu)秀的開發(fā)加在一起，加班加點就能做出來的。而是經(jīng)過幾年時間的發(fā)展才逐步完善和初具規(guī)模。如果我們也想自己做一套類似的技術(shù)，不是說不可能。我們需要集合當(dāng)下的技術(shù)實力、技術(shù)積

4、累，做出適合自己團隊情況的技術(shù)評估。1.沒有最新，只要最合適所有新的技術(shù)剛出來都是打著比舊技術(shù)擁有更加出色的性能、提供更加優(yōu)秀的擴展性。是不是使用新技術(shù)，就能解決一切問題了？新技術(shù)的出道，勢必是解決某一場景下的問題，并不是一味萬能良藥。只有了解清楚每種技術(shù)的產(chǎn)生背景，適用場景，才能出一個對自己項目最優(yōu)的選擇。技術(shù)選型沒有最新，只有最合適?？偨Y(jié)一下，合適原則就是適合優(yōu)于業(yè)界領(lǐng)先。簡單原則我們總是希望能將我們的軟件設(shè)計的精美、宏大，這樣才能彰顯我們系統(tǒng)的復(fù)雜度和難度。我們是不是會遇到這樣的場景，在做設(shè)計方案的時候，如果一個解決方案很簡單，而且能很快的滿足需求。在評審方案時，就會有人覺得這個方案是不

5、是太簡單了，沒有什么技術(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ù)雜。結(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ù)雜性存在的第二個問題是，某個組件改

6、動，會影響關(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)要有多龐大：幾百人維護一個系統(tǒng)、代碼分支幾十個、需求變更應(yīng)接不暇、不同分支的回歸測試、修改一段代碼可能影響整個系統(tǒng)的運行等等。這些場景相信大家都不希望看到的?？偨Y(jié)一下，簡單原則就是大道至簡。演化原則軟件架構(gòu)和建筑架構(gòu)很多相同的地方，架構(gòu)這個詞

7、也是從建筑領(lǐng)域借鑒過來的。比如，軟件架構(gòu)描述的是系統(tǒng)的結(jié)構(gòu)、以及各模塊之間的關(guān)系。而建筑結(jié)構(gòu)描述的是一幢建筑的結(jié)構(gòu)，以及建筑內(nèi)部各部件如何有機的組成。但是，軟件架構(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)如磐石。如果是按照這樣的目標是設(shè)計，一開始上來就做出一套看似是終極的方案，投入龐大的資源做各種預(yù)測、分析。結(jié)果是投入巨大的資

8、源、開發(fā)周期漫長，最終跌跌撞撞落地的系統(tǒng)，卻發(fā)現(xiàn)已經(jīng)無法很好的滿足現(xiàn)有的業(yè)務(wù)。所以技術(shù)架構(gòu)設(shè)計需要一個過程：首先，要滿足當(dāng)前的業(yè)務(wù)需求進行技術(shù)架構(gòu)設(shè)計其次，架構(gòu)要不斷地在實際應(yīng)用過程中迭代，保留優(yōu)秀的設(shè)計，修復(fù)有缺陷的設(shè)計，改正錯誤的設(shè)計，去掉無用的設(shè)計，使架構(gòu)逐漸完善。第三，當(dāng)業(yè)務(wù)發(fā)生變化時，架構(gòu)要擴展、重構(gòu)、甚至重寫；代碼也許會重寫，但有價值的經(jīng)驗、教訓(xùn)、邏輯、設(shè)計卻可以在新架構(gòu)中延續(xù)?？偨Y(jié)一下，演化原則就是演化優(yōu)于一步到位。戰(zhàn)術(shù)層設(shè)計原則戰(zhàn)術(shù)層的設(shè)計原則分為3部分：高并發(fā)原則、高可用原則、業(yè)務(wù)設(shè)計原則。這些原則是對技術(shù)架構(gòu)設(shè)計過程中提供詳細的指導(dǎo)思路，幫助你做技術(shù)選型、技術(shù)拆分。2.1高

9、并發(fā)原則設(shè)計高并發(fā)的系統(tǒng)，需要考慮以下幾個方面的設(shè)計：無狀態(tài)、拆分、服務(wù)化、消息隊列、數(shù)據(jù)異構(gòu)、緩存。（1）無狀態(tài)無狀態(tài)應(yīng)用，便于水平擴展。有狀態(tài)配置可通過配置中心實現(xiàn)無狀2）拆分系統(tǒng)維度：按照系統(tǒng)功能、業(yè)務(wù)拆分，比如購物車、結(jié)算、訂單等。功能維度：對系統(tǒng)功能再做細粒度拆分。讀寫維度：根據(jù)讀寫比例特征拆分；讀多，可考慮多級緩存；寫多，可考慮分庫分表。AOP維度：根據(jù)訪問特征，按照AOP進行拆分.模塊維度：對整體代碼結(jié)構(gòu)劃分web、service、dao。（3）服務(wù)化服務(wù)化演進：進程內(nèi)服務(wù)-單機遠程服務(wù)-集群手動注冊服務(wù)-自動注冊和發(fā)現(xiàn)服務(wù)-服務(wù)的分組、隔離、路由-服務(wù)治理?？紤]服務(wù)分組、隔離、

10、限流、黑白名單、超時、重試機制、路由、故障補償?shù)取?）消息隊列目的：服務(wù)解耦（一對多消費）、異步處理、流量削峰緩沖等。大流量緩沖：犧牲強一致性，保障最終一致性。數(shù)據(jù)校對：解決異步消息機制下消息丟失問題。5）數(shù)據(jù)異構(gòu)數(shù)據(jù)異構(gòu)：通過消息隊列機制接受數(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é)點-源站）接入層：Ng

11、inx的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)用?？山导壍亩嗉壸x服務(wù)：如服務(wù)調(diào)用降級為只讀本地緩存。開關(guān)前置化：如Nginx+Lua配置降級策略，引流流量；可基于此做灰度策略。業(yè)務(wù)降級：高并發(fā)下，保證核心功能，次要功能可由同步改為異步策略或屏蔽功能。限流目的：防止惡意請求攻擊或超過系統(tǒng)峰值惡意請求流量只訪問到Cache穿透后端應(yīng)用的流量

12、Nginx的limit處理惡意Ip使用NginxDeny策略或者iptables拒絕可回滾發(fā)布版本失敗時，可隨時快速回退到上一個穩(wěn)定版本。2.3業(yè)務(wù)設(shè)計原則防重設(shè)計幕等設(shè)計流程定義狀態(tài)與狀態(tài)機后臺系統(tǒng)操作可反饋后臺系統(tǒng)審批化文檔注釋備份技術(shù)架構(gòu)圖技術(shù)架構(gòu)圖是將系統(tǒng)的技術(shù)方案、技術(shù)選型通過視圖的方式進行展現(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ù)、

13、技術(shù)實現(xiàn)邏輯如何，就提現(xiàn)在技術(shù)架構(gòu)圖上。功能需要技術(shù)架構(gòu)圖繪制可以按照“整體-局部-整體”的思路實現(xiàn)。1.整體首先可以按照應(yīng)用架構(gòu)圖的應(yīng)用分布得到應(yīng)用分布框架。如下：I風(fēng)I蚓華I軸犯準實磚濰贈能!4aar,M：nnA1_諦料!處置中*心事件itl1111i2.局部0則以心i在整體框架的基礎(chǔ)上，對每一個局部的子系統(tǒng)進行詳細的技術(shù)實現(xiàn)的表達。子系統(tǒng)的技術(shù)架構(gòu)圖中需要展示每個子系統(tǒng)使用的技術(shù)組件，比如（緩存技術(shù)、消息中間件、流程引擎、流式計算框架等等）。同時，這些技術(shù)組件是如何實現(xiàn)業(yè)務(wù)功能，需要清晰的展示技術(shù)實現(xiàn)邏輯。下圖是對風(fēng)控系統(tǒng)中的實時引擎、離線引擎、準實時引擎三個子系統(tǒng)的進行的技術(shù)架構(gòu)。在實

14、時引擎中，主要使用RuleEngine（規(guī)則引擎）作為技術(shù)特點，這里就重點列出RuleEngine。準實時引擎使用Blink作為流計算的技術(shù)框架，并概要的展示了計算邏輯。II撲民佝ZDB粥引IF腰旳引舉iteEngineOOPS財和*msci*爐湧弓r】革層F.fdlKEDBD2(i業(yè)靈強遡艦cpensesic-m.SM也心在完成每個子系統(tǒng)的技術(shù)實現(xià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)。Id5:TTII撲民佝ZII撲民佝Z*IiIIIIllIRuleEngiBsourceiiBndr：ivratbni50UKE異常方件DE爭跡自訓(xùn)*塔蒯litII撲民佝ZII撲民佝Z物理架構(gòu)偏重于網(wǎng)絡(luò)設(shè)計統(tǒng)在物理上是如何部署。行時的組織情況。從物理集群設(shè)計、中間件設(shè)計、上是如何部署?？椙樾?。從物理勺圖中，我們能，IDa0地拠帕如:I(硬件的設(shè)計架構(gòu)。非功能需求的技術(shù)架構(gòu)圖重點在于展示企業(yè)系間的關(guān)系以及他們的部署策略。物理架構(gòu)反映出軟件系統(tǒng)動態(tài)運、流量訪問、數(shù)據(jù)流轉(zhuǎn)、數(shù)據(jù)存儲到技術(shù)組件的運轉(zhuǎn)。*昨-宦時礦砸苗:：*煙卜起fffiS*DB3.2物NgnxNgir:;我們從架構(gòu)的本質(zhì)開始，分別對