大家好，歡迎來到Tlog4J課堂，我是Jensen。

大家或許會很好奇——架構(gòu)師關(guān)注的點到底在哪里?平時具體應(yīng)用到的“術(shù)語”有哪些?

在這里，我整理一份架構(gòu)師技術(shù)語言，希望大家看完以后可以逆向推導出架構(gòu)師需要關(guān)注的重點，掌握了這些技術(shù)語言，咱們可以在技術(shù)交流中，把它們作為有力的理論支撐依據(jù)。

架構(gòu)技術(shù)的思維與衡量指標

一、ROI

ROI一般指投資回報率，投資回報率=年利潤或年均利潤/投資總額×100%，比如投入100元，獲得利潤10,000元，那ROI就是10,000/100*100%=10,000%，如果ROI小于100%，那意味著投入100元，獲得的利潤少于100元，大家都知道，這是一個不劃算的買賣。

此外，ROI可以作為企業(yè)生產(chǎn)的一個基礎(chǔ)指標，我們可以把ROI理解為投入產(chǎn)出比——在做任何決策之前，先考慮清楚這件事值不值得去做，我們可以通過經(jīng)驗預判或數(shù)據(jù)分析得出結(jié)論，前輩告訴我們：在錯誤的方向上努力只會讓你輸?shù)酶鼞K，所以為什么說選擇比努力更重要，其中就是這個道理。

比如說，如果花費一個月時間去優(yōu)化一個簡單的客服系統(tǒng)，只是為了讓客服體驗更好，并沒有對客戶留存、轉(zhuǎn)化交易起任何效果，也沒有大幅提升客服效率，那做這個事情就不劃算，ROI小于1，價值點不高。

當然，ROI指標的不足之處是缺乏全局觀念，因為我們還需要考慮投資的隱性回報，比如營銷部門在一次營銷活動中投放CPS信息流，投入總成本10萬元，共賺取利潤10萬元，并獲客1萬，單從金錢成本上看是沒有任何效益的，但這次營銷活動相當于免費獲客1萬，這些客戶后續(xù)是可以在商城內(nèi)二次交易的，那么從全局上看，總的ROI就大于100%。

ROI在架構(gòu)上常用于判斷技術(shù)決策、項目決策等等在當前階段值不值得投入人力、時間成本去執(zhí)行。

二、SOLID

SOLID原則包括以下五個：

1、單一職責原則(SRP)

表明一個類有且只有一個職責。一個類就像容器一樣，它能添加任意數(shù)量的屬性、方法等。

2、開放封閉原則(OCP)

一個類應(yīng)該對擴展開放，對修改關(guān)閉。這意味一旦創(chuàng)建了一個類并且應(yīng)用程序的其他部分開始使用它，就不應(yīng)該修改它。簡單地說：就是當別人要修改軟件功能的時候，使得他不能修改我們原有代碼，只能新增代碼實現(xiàn)軟件功能修改的目的。

3、里氏替換原則(LSP)

派生的子類應(yīng)該是可替換基類的，也就是說任何基類可以出現(xiàn)的地方，子類一定可以出現(xiàn)。值得注意的是，當通過繼承實現(xiàn)多態(tài)行為時，如果派生類沒有遵守LSP，可能會讓系統(tǒng)引發(fā)異常。

4、接口隔離原則(ISP)

表明類不應(yīng)該被迫依賴他們不使用的方法，也就是說一個接口應(yīng)該擁有盡可能少的行為，它是精簡的，也是單一的。

5、依賴倒置原則(DIP)

表明高層模塊不應(yīng)該依賴低層模塊，相反，他們應(yīng)該依賴抽象類或者接口。這意味著不應(yīng)該在高層模塊中使用具體的低層模塊。

我們就來盤一盤他們之間的關(guān)系：

• 單一職責是所有設(shè)計原則的基礎(chǔ)，開閉原則是設(shè)計的終極目標。
• 里氏替換原則強調(diào)的是子類替換父類后程序運行時的正確性，它用來幫助實現(xiàn)開閉原則。
• 而接口隔離原則用來幫助實現(xiàn)里氏替換原則，同時它也體現(xiàn)了單一職責。
• 依賴倒置原則是過程式編程與面向?qū)ο缶幊痰姆炙畮X，同時它也被用來指導接口隔離原則。

簡單來說，就是——

依賴倒置原則告訴我們要面向接口編程;當我們面向接口編程之后，接口隔離原則和單一職責原則又告訴我們要注意職責的劃分，不要什么東西都塞在一起;當我們職責捋得差不多的時候，里氏替換原則告訴我們在使用繼承的時候，要注意遵守父類的約定;而上面說的這四個原則，它們的最終目標都是為了實現(xiàn)開閉原則。

三、拆分/解耦思維

拆分常用于描述組織拆分、業(yè)務(wù)拆分、數(shù)據(jù)拆分、服務(wù)拆分等，其中的拆分依據(jù)和拆分粒度是我們需要關(guān)注的重點，也就是說——為什么這么拆?要拆成什么樣才算合理?

“合起來不是挺好的嗎，為什么要拆?拆了還會有一堆問題，整體復雜度還變高了!”

乍一聽覺得這么質(zhì)疑挺合理的，但咱們從整體上考慮，或許就變得不那么合理了。

我們從團隊、產(chǎn)品、交付、技術(shù)以及業(yè)務(wù)方面分析一下系統(tǒng)拆分的需求：

1、組織結(jié)構(gòu)變化

從最初的一個團隊逐漸成長并拆分為幾個團隊，團隊按照業(yè)務(wù)線不同進行劃分，為了減少各個業(yè)務(wù)系統(tǒng)和代碼間的關(guān)聯(lián)和耦合，幾個團隊不再可能共同向一個代碼庫中提交代碼，必須對原有系統(tǒng)進行拆分，以減少團隊間的干擾。

2、安全性

這里所指的安全不是系統(tǒng)級別的安全，而是指代碼或成果的安全，尤其是對于很多具有核心算法的系統(tǒng)，為了代碼不被泄露，需要對相關(guān)系統(tǒng)進行模塊化拆分，隔離核心功能，保護知識產(chǎn)權(quán)。

3、替換性

有些產(chǎn)品為了提供差異化的服務(wù)，需要產(chǎn)品具有可定制功能，根據(jù)用戶的選擇自由組合為一個完整的系統(tǒng)，比如一些模塊，免費用戶使用的功能與收費用戶使用的功能肯定是不一樣的，這就需要這些模塊具有替換性，判斷是免費用戶還是收費用戶使用不同的模塊組裝，這也需要對系統(tǒng)進行模塊化拆分。

4、交付速度

單體程序最大的問題在于系統(tǒng)錯綜復雜，牽一發(fā)而動全身，也許一個小的改動就造成很多功能沒辦法正常工作，極大的降低了軟件的交付速度，因為每次改動都需要大量的回歸測試確保每個模塊都能正確工作，因為我們不清楚改動會影響到什么，所以需要做大量重復工作，增加了測試成本，這時候就需要對系統(tǒng)進行拆分，理清各個功能間的關(guān)系并解耦。

5、技術(shù)需求

1)單體應(yīng)用由于技術(shù)棧固定，尤其是比較龐大的系統(tǒng)，不能很方便地進行技術(shù)升級，或者說對引入新技術(shù)或框架等處于封閉狀態(tài)，而每種語言都有自己的特點，單體程序沒有辦法享受到其它語言帶來的便利，對應(yīng)到團隊中，團隊技術(shù)相對比較單一。

2)相比于基于業(yè)務(wù)的垂直拆分，基于技術(shù)的橫向拆分也很重要，使用數(shù)據(jù)訪問層可以很好的隱藏對數(shù)據(jù)庫的直接訪問、減少數(shù)據(jù)庫連接數(shù)、增加數(shù)據(jù)使用效率等;橫向拆分可以極大地提高各個層級模塊的重用性。

6、業(yè)務(wù)需求

由于業(yè)務(wù)上的某些特殊要求，比如對某個功能或模塊的高可用性、高性能、可伸縮性等方面的要求，雖然也可以將單體整體部署到分布式環(huán)境中實現(xiàn)高可用、高性能等，但是從系統(tǒng)維護的角度來考慮，每次改動都要重新部署所有節(jié)點，顯然會增加很多潛在的風險和不確定性因素，所以有時候不得不選擇將那些有特殊要求的功能從系統(tǒng)中抽取出來，獨立部署和擴展。

從更大的范圍來看，拆分可以分為兩種：縱向和橫向。

縱向拆分主要從業(yè)務(wù)角度進行，根據(jù)業(yè)務(wù)分割為不同的子系統(tǒng);而橫向拆分側(cè)重于技術(shù)的分層，每個層級的技術(shù)側(cè)重點不同，可以充分發(fā)揮和培養(yǎng)團隊中每個人的技術(shù)特長。

四、隔離思維

我們再來聊聊隔離思維，我們做技術(shù)的一定要有隔離思維，不要把多件事情混為一談，這樣我們才能聚焦重點。

隔離設(shè)置，源于輪船的設(shè)計，在輪船設(shè)計中，我們常常會設(shè)計多個船艙，每個船艙都是獨立的空間，這樣子，當輪船在行駛過程中，即便某個船艙遭受破壞進水，也有船艙能夠正常工作，從而保證整個輪船不會沉沒。

每一位架構(gòu)師、程序員、運維工程師都必須懂得隔離設(shè)計，在分布式系統(tǒng)中，隔離設(shè)計的實現(xiàn)有兩種不同的方式，一是系統(tǒng)隔離，二是用戶隔離。

1、系統(tǒng)隔離

在分布式系統(tǒng)中，我們常常把不同的模塊部署到不同的機器上面，避免不同的模塊彼此之間受到影響(每臺計算機的資源都是有限的，特別是IO密集型、CPU密集型的模塊，容易拖垮其他業(yè)務(wù))。

除此之外，我們還要對底層的存儲與上層的接入層進行分離。

在實際的應(yīng)用中，我們通常會對不同的不同業(yè)務(wù)的存儲進行數(shù)據(jù)庫拆分，而在接入層，常常為了節(jié)約成本，而使用限流設(shè)計。

2、用戶隔離

另外一種方式，我們常常根據(jù)用戶進行隔離，不同的用戶訪問不同的運行實例，這種在大型互聯(lián)網(wǎng)公司也是非常常見的，例如阿里巴巴有北京、上海、杭州、深圳等多個不同的數(shù)據(jù)中心，不同的用戶訪問不同的系統(tǒng)實例。

不同的用戶群訪問不同的實例群，可以讓隔離做得更加徹底，但同時也是伴隨著非常大的挑戰(zhàn)，比如我們會面臨著存儲、不同實例間的通信等多種問題。

而隔離的底層邏輯，映射到計算機系統(tǒng)層面，都是對CPU、內(nèi)存、網(wǎng)絡(luò)、IO或存儲層面的隔離，避免計算機資源互相干擾。

在我們?nèi)粘５募夹g(shù)交流中，我們通過隔離性來判斷業(yè)務(wù)、系統(tǒng)以及代碼之間會不會互相產(chǎn)生影響、系統(tǒng)的邊界是否清晰，最終讓我們實現(xiàn)的系統(tǒng)更加穩(wěn)定。

五、ACID

ACID指的是事務(wù)的四個特征，分別是原子性(Atomicity)、一致性(Consistency)、隔離性(Isolation) 和持久性(Durability)，簡稱為事務(wù)的ACID特性，狹義的ACID指的是數(shù)據(jù)庫事務(wù)的ACID。

1、原子性(Atomicity)

一個事務(wù)必須被視為一個不可分割的最小工作單元，整個事務(wù)中的所有操作要么全部提交成功，要么全部失敗回滾，不可能停滯在中間某個環(huán)節(jié)，對于一個事務(wù)來說，不可能只執(zhí)行其中的一部分操作。

2、一致性(Consistency)

數(shù)據(jù)庫總是從一個一致性的狀態(tài)轉(zhuǎn)換到另一個一致性的狀態(tài)。

3、隔離性(Isolation)

通常來說，一個事務(wù)所做的修改在最終提交以前，對其他事務(wù)是不可見的(在并發(fā)環(huán)境中，并發(fā)的事務(wù)是相互隔離的，事務(wù)之間互不干擾)，隔離性可以防止多個事務(wù)并發(fā)執(zhí)行時由于交叉執(zhí)行而導致數(shù)據(jù)的不一致。

針對不同的業(yè)務(wù)需求，隔離性分為4個級別：讀未提交、讀已提交、可重復讀、串行化。

這4個級別的隔離性依次增強，事務(wù)隔離級別越高，就越能保證數(shù)據(jù)的完整性和一致性，但同時對并發(fā)性能的影響也越大。

4、持久性(Durability)

通常來說，一旦事務(wù)提交，則其所做的修改會永久保存到數(shù)據(jù)庫，即使系統(tǒng)崩潰，修改的數(shù)據(jù)也不會丟失。

在我們的實際應(yīng)用中，我們大可以通過數(shù)據(jù)庫事務(wù)的ACID特性來滿足實際業(yè)務(wù)場景，所以咱們做技術(shù)的一定要把ACID牢記于心，隨時調(diào)用。

六、CAP、BASE

有一句話不知道大家有沒有聽過，叫做“CAP走天下”，CAP為何如此重要呢?

這里先科普一下：

CAP定理表示在分布式系統(tǒng)中的三大特性：一致性(Consistency)、可用性(Availability)和分區(qū)容錯性(Partition tolerance)，三者之間形成一個不可能三角，即在一個分布式系統(tǒng)內(nèi)不能同時滿足強一致、高可用和分區(qū)容錯。

CAP定理

CAP定理在分布式架構(gòu)上指導我們，系統(tǒng)應(yīng)該如何在CP和AP中進行權(quán)衡，因為分布式系統(tǒng)做了分區(qū)，一定是先滿足分區(qū)容錯性的。

比如說常用的分布式配置中心與服務(wù)注冊中心，我們允許系統(tǒng)之間存在短暫的數(shù)據(jù)不一致，也要保證系統(tǒng)的高可用，以免影響系統(tǒng)的正常運作，所以這種分布式系統(tǒng)可以采用AP+最終一致的方案去設(shè)計;至于涉及到交易場景的業(yè)務(wù)，比如銀行轉(zhuǎn)賬這類交易場景，以CP的方式去設(shè)計更加嚴謹。

那CP系統(tǒng)就不能保證高可用了嗎?當然不是。

咱們對于可用性也有別的方法去實現(xiàn)，比如在CP之上嵌套使用AP系統(tǒng)負責CP系統(tǒng)的高可用，在一個大型分布式系統(tǒng)中，都是CP+AP相互結(jié)合使用的。

那BASE又是什么呢?

BASE理論是Basically Available(基本可用)，Soft State(軟狀態(tài))和Eventually Consistent(最終一致性)三個短語的縮寫，它是對CAP定理中一致性和可用性權(quán)衡的結(jié)果，其來源于對大規(guī)?；ヂ?lián)網(wǎng)分布式系統(tǒng)實踐的總結(jié)。

BASE理論的底層邏輯是這樣的：通過基本可用、軟狀態(tài)來犧牲CAP中的可用性，通過最終一致性來犧牲CAP中的強一致性。

BASE是基于CAP逐步演化而來的：即使無法做到強一致性，但應(yīng)用可以采用適合的方式達到最終一致性，CAP中提到的一致性是強一致性，所謂“犧牲一致性”指犧牲強一致性保證弱一致性。

七、分布式事務(wù)

隨著架構(gòu)的演進，系統(tǒng)與數(shù)據(jù)庫進行了不同程度的拆分，系統(tǒng)之間由進程內(nèi)通訊變成通過網(wǎng)絡(luò)IO通訊，相應(yīng)地，事務(wù)的ACID也被散落到各個單體應(yīng)用中，不再能夠服務(wù)于有ACID需求的業(yè)務(wù)場景。

我們此時就需要有一個能滿足ACID特性的分布式事務(wù)解決方案，來解決業(yè)務(wù)場景。

怎么辦呢，數(shù)據(jù)庫的ACID是在進程內(nèi)通訊的，因為在一個單體應(yīng)用中，這很好辦到，那在分布式系統(tǒng)也可以做到類似的設(shè)計，區(qū)別在于通訊方式由進程內(nèi)通訊變成了網(wǎng)絡(luò)IO通訊，由此前輩們提出了一些分布式事務(wù)解決方案。

我們把事務(wù)的范圍上升到分布式系統(tǒng)的一個“上帝視角”，那么單體事務(wù)就變成了全局事務(wù)，以下是X/Open組織提出的DTP模型：

DTP模型

在DTP分布式事務(wù)模型中，XA規(guī)范除了定義的RM-TM交互的接口，即TM與數(shù)據(jù)庫之間的接口規(guī)范，TM還用它來通知數(shù)據(jù)庫事務(wù)的開始、結(jié)束以及提交、回滾等;而XA接口函數(shù)由數(shù)據(jù)庫廠商提供。

分布式通信協(xié)議XA規(guī)范：

• 第一步：AP創(chuàng)建了RM1 RM2的JDBC連接。
• 第二步：AP通知生成全局事務(wù)ID，并把RM1 RM2注冊到全局事務(wù)ID。
• 第三步：執(zhí)行二階段協(xié)議中的第一階段prepare。
• 第四步：根據(jù)第一階段中的prepare情況，決定整體提交或回滾。

在XA規(guī)范中大致分為兩部分：事務(wù)管理器和本地資源管理器。

其中本地資源管理器往往由數(shù)據(jù)庫實現(xiàn)，比如Oracle、DB2這些商業(yè)數(shù)據(jù)庫都實現(xiàn)了XA接口，而事務(wù)管理器作為全局的調(diào)度者，負責各個本地資源的提交和回滾。

兩階段提交(2PC)、三段式提交(3PC)就是基于XA規(guī)范落地的，此外還有TCC協(xié)議，也能滿足我們實際的業(yè)務(wù)場景。

八、系統(tǒng)容量預估

系統(tǒng)容量指系統(tǒng)所能承受的最大訪問量，而系統(tǒng)容量預估則是在峰值流量到達之前系統(tǒng)架構(gòu)師所給出的若干技術(shù)指標值，它是架構(gòu)師必備的技能之一。

常用的技術(shù)指標值有：QPS、PV、UV、并發(fā)量、帶寬、CPU使用率、內(nèi)存硬盤占用率等。

QPS(Query Per Second)表示每秒查詢量，在分布式系統(tǒng)中 QPS 的定義是，單個進程每秒請求服務(wù)器的成功次數(shù)，QPS一般可以通過壓力測試工具測得，例如 LoadRunner、Apache JMeter、NeoLoad、http_load等。

QPS = 總請求數(shù) / 進程總數(shù) / 請求時間 = 總請求數(shù) / ( 進程總數(shù) * 請求時間 )

UV(Unique Visitor)表示獨立訪客數(shù)量，指一定時間范圍內(nèi)站點訪問所來自的IP數(shù)量，同一IP多次訪問站點只計算一次，一般以24小時計算。

PV(Page View)表示頁面訪問量，指一定時間范圍內(nèi)打開或刷新頁面的次數(shù)，一般以24小時計算。

那并發(fā)量、帶寬這些具體有沒有可量化的公式呢?答案是YES。

1、帶寬計算

平均帶寬的計算公式為：

平均帶寬 = 總流量數(shù)(bit) / 產(chǎn)生這些流量的時長(秒)=(PV * 頁面平均大小 * 8) / 統(tǒng)計時間(秒)

公式中的 8 指的是將 Byte 轉(zhuǎn)換為 bit，即 8b/B，因為帶寬的單位是 bps(比特率)，即bit per second，每秒二進制位數(shù)，而容量單位一般使用 Byte。

假設(shè)某站點的日均 PV 是 10w，頁面平均大小 0.4 M，那么其平均帶寬需求是：

平均帶寬 = (10w * 0.4M * 8) / (60 * 60 * 24) = 3.7 Mbps

以上計算的僅僅是平均帶寬，我們在進行容量預估時需要的是峰值帶寬，即必須要保證站點在峰值流量時能夠正常運轉(zhuǎn)。

假設(shè)峰值流量是平均流量的5倍，這個5倍稱為峰值因子，按照這個計算，實際需要的帶寬大約在 3.7 Mbps * 5=18.5 Mbps 。

帶寬需求 = 平均帶寬 * 峰值因子

2、并發(fā)量計算

并發(fā)量，也稱為并發(fā)連接數(shù)，一般是指單臺服務(wù)器每秒處理的連接數(shù)。

平均并發(fā)連接數(shù)的計算公式是：

平均并發(fā)連接數(shù) = (站點 PV * 頁面平均衍生連接數(shù))/(統(tǒng)計時間 * web 服務(wù)器數(shù)量)

頁面平均衍生連接數(shù)是指，一個頁面請求所產(chǎn)生的 http 連接數(shù)量，如對靜態(tài)資源的 css、 js、 images 等的請求數(shù)量，這個值需要根據(jù)實際情況而定。

例如，一個由5臺web主機構(gòu)成的集群，其日均PV是50w，每個頁面平均30個衍生連接，則其平均并發(fā)連接數(shù)為：

平均并發(fā)量 = (50w * 30) / (60 * 60 * 24 * 5) = 35

若峰值因子為 6，則峰值并發(fā)量為：

峰值并發(fā)量 = 平均并發(fā)量 * 峰值因子 = 35 * 6 = 210

3、服務(wù)器預估量

根據(jù)往年同期活動獲得的日均 PV、并發(fā)量、頁面衍生連接數(shù)，及公司業(yè)務(wù)擴展所帶來的流量增長率，就可以計算出服務(wù)器預估值。

服務(wù)器預估值 = 站點每秒處理的總連接數(shù) / 單機并發(fā)連接數(shù) = (PV * 頁面衍生連接數(shù)*(1 + 增長率)) / 統(tǒng)計時間 / 單機并發(fā)連接數(shù)

注：統(tǒng)計時間，即 PV 的統(tǒng)計時間，一般為一天。

寫在最后

本文簡單梳理了一些常用架構(gòu)師術(shù)語，并沒有深入展開去聊，只為打開大家的技術(shù)視野，僅憑短短一個篇幅是不足以了解技術(shù)全貌的。