編者按:這篇文章由樂(lè)毅在高可用性架構(gòu)小組中分享。請(qǐng)指出它來(lái)自高度可用的體系結(jié)構(gòu)“ArchNotes”。

煎餅故事

在花園路住過(guò)一段時(shí)間，最難忘的是路邊的煎餅果子。老板每天晚上都出來(lái)，正好趕上我加班。

往鍋里撒一勺面糊，把刮刀轉(zhuǎn)過(guò)去，再打一個(gè)雞蛋，還是刮平。然后拍一下，抹上辣醬，撒上蔥花?？粘鰜?lái)剝個(gè)火腿腸。最后，把脆度放在上面，把三把鐵鍬切成三條直邊的長(zhǎng)方形，正好可以折疊在手里。辣，一口下去，雞蛋味，辣醬，鮮腸，清脆的聲音和蔥花的驚喜，所有的疲憊都一掃而空。

就像我們談?wù)撆艘粯樱?/p>

我們關(guān)心乳房，

關(guān)心腿，

在意風(fēng)情，

在乎溫柔，

因?yàn)榕瞬灰粯印?/p>

當(dāng)我們欣賞電影時(shí)，

我們關(guān)心男人，

關(guān)心女人，

關(guān)心老人，

關(guān)心孩子，

因?yàn)榻巧煌?/p>

當(dāng)我們走在路上的時(shí)候，

我們關(guān)心行人，

關(guān)心車(chē)輛，

關(guān)心商店，

關(guān)心餐館，

因?yàn)閷?duì)象不同。

當(dāng)我們?cè)O(shè)計(jì)和優(yōu)化系統(tǒng)時(shí)，每個(gè)服務(wù)都獨(dú)立運(yùn)行，各司其職，但是在不同的維度上，它的功能就變得不同了。

這就是為什么我們說(shuō)優(yōu)化要分層次，分架構(gòu)，分算法，分庫(kù)，分OS。當(dāng)我們談?wù)摷軜?gòu)時(shí)，我們首先談?wù)撜w模式，然后是具體的權(quán)衡，實(shí)現(xiàn)的細(xì)節(jié)是最不重要的。

建筑模式

這是因?yàn)轳R克·理查茲寫(xiě)了一本關(guān)于架構(gòu)模式的書(shū)《軟件架構(gòu)模式》。

這本書(shū)總結(jié)和比較了五種模式的優(yōu)缺點(diǎn)，包括分層、事件驅(qū)動(dòng)、微內(nèi)核、微服務(wù)和基于空間的。

文筆簡(jiǎn)單細(xì)膩，推薦閱讀。地址見(jiàn)文末。

還有一種模式，因?yàn)樵谠絹?lái)越多的系統(tǒng)中使用，書(shū)中沒(méi)有(和天基不同)，但我覺(jué)得有必要具體介紹一下。我們開(kāi)始在群發(fā)系統(tǒng)實(shí)施，后來(lái)經(jīng)常在搶購(gòu)、紅包、火車(chē)票的場(chǎng)景中看到。

2013年我們?cè)谖⒉┥献隽艘粋€(gè)粉絲服務(wù)平臺(tái)，類(lèi)似微信微信官方賬號(hào)的群發(fā)系統(tǒng)。但是，比后者更難。當(dāng)時(shí)的產(chǎn)品設(shè)計(jì)并沒(méi)有像微信那樣打造新的用戶系統(tǒng)，而是直接基于微博的粉絲關(guān)系，也就是說(shuō)一篇文章應(yīng)該可以在短時(shí)間內(nèi)支持上億用戶。這種數(shù)量級(jí)的訂戶，就算是看了今天的微信微信官方賬號(hào)，還是難以想象。

當(dāng)時(shí)有一個(gè)老的群發(fā)系統(tǒng)，是基于MySQL收件箱設(shè)計(jì)的。更換SSD硬盤(pán)和批量數(shù)據(jù)庫(kù)操作后，整體寫(xiě)入性能依然只有每秒數(shù)萬(wàn)，也就是說(shuō)1億用戶只能在17分鐘內(nèi)發(fā)送。我們意識(shí)到這個(gè)系統(tǒng)需要重新設(shè)計(jì)。

最后，我們使用了一種新的架構(gòu)，達(dá)到了每秒百萬(wàn)的速度，還可以更高。這種模式就是單元化架構(gòu)。

下面的介紹，我參考架構(gòu)模式的解釋方法，希望能給大家做個(gè)比較。喜歡就一定要說(shuō)好！

單元化建筑

如前所述，選擇單元化的一個(gè)重要目的是為了性能，以及極高的性能。相對(duì)于一般的分層架構(gòu)，會(huì)得到更經(jīng)濟(jì)的效果，但也犧牲了分層架構(gòu)的一些特性，因?yàn)樗娜萘咳Q于單元的大小(后面我會(huì)介紹一些單元等術(shù)語(yǔ))。

雖然支持按單元擴(kuò)容，但各層性能在單元內(nèi)基本固定。這更適合于可預(yù)測(cè)容量的場(chǎng)景，例如，大多數(shù)已經(jīng)變得穩(wěn)定的業(yè)務(wù)。和之前的粉絲服務(wù)平臺(tái)一樣，他發(fā)的消息雖然巨大，但總體來(lái)說(shuō)，因?yàn)槠脚_(tái)的用戶都是VIP用戶，他們的規(guī)?；径荚诎偃f(wàn)，粉絲規(guī)模不太可能超過(guò)一億。

重要的是，基于當(dāng)時(shí)的業(yè)務(wù)數(shù)據(jù)，我們已經(jīng)知道粉絲平均數(shù)量是多少個(gè)數(shù)量級(jí)了。業(yè)務(wù)數(shù)據(jù)是架構(gòu)選擇的重要依據(jù)。商品穗、火車(chē)票高峰等。都一樣。

當(dāng)然也有例外。因?yàn)閱卧軜?gòu)是一種理念，不會(huì)局限于一臺(tái)機(jī)器，一個(gè)機(jī)架，也可以應(yīng)用到一個(gè)機(jī)房。當(dāng)它的等級(jí)變大時(shí)，單位內(nèi)自然會(huì)有空的變化。每一層服務(wù)都可以單獨(dú)擴(kuò)展。在這個(gè)層面上，它的追求可能完全不同。像阿里雙十一服務(wù)轉(zhuǎn)型，會(huì)是為了流量分離，像QQ聊天，會(huì)是為了訪問(wèn)速度。他們的基本想法是一樣的。

至于單元化結(jié)構(gòu)和煎餅果子的關(guān)系，我后面會(huì)回答。

核心概念關(guān)鍵概念

分區(qū)(分片)是整個(gè)數(shù)據(jù)集的子集。如果用尾號(hào)劃分用戶，尾號(hào)相同的用戶可以認(rèn)為是同一個(gè)分區(qū)。

單元是一個(gè)獨(dú)立的安裝，它滿足某個(gè)分區(qū)的所有業(yè)務(wù)操作。我們從并行計(jì)算領(lǐng)域借用了這個(gè)思路，也就是計(jì)算機(jī)體系結(jié)構(gòu)中的Celluar Architecture，Cell是一個(gè)包含線程組件、內(nèi)存和通信組件的計(jì)算節(jié)點(diǎn)。Https://en.m.wikipedia.org/wiki/Cellular_architecture(Cellize):這是我創(chuàng)造的詞，描述了將服務(wù)轉(zhuǎn)換成單元架構(gòu)的過(guò)程。

模式描述

細(xì)胞結(jié)構(gòu)最重要的概念是細(xì)胞和細(xì)胞自治。

你可以把它想象成一個(gè)細(xì)胞。如前所述，每個(gè)單元都是獨(dú)立的，并且有明確的功能。你也可以把它想象成一個(gè)小隔間，就像你去按摩院，每個(gè)小隔間里都有技術(shù)人員和所有的設(shè)備。我沒(méi)有用前者的名字是因?yàn)樗刑珡?qiáng)的生物學(xué)意義，我沒(méi)有用后者是因?yàn)樗刑嗟姆?wù)含義。但是如果你有足夠的想象力，你可以用任何名字。

說(shuō)到單位自治，就是單位之間的自我協(xié)調(diào)和隔離。由于單元是自包含的，所以其中的所有組件，無(wú)論它們?cè)谖锢砩鲜欠癖环殖瑟?dú)立的服務(wù)，都在一個(gè)單元中相互支持，即它們不會(huì)與其他單元中相同或不同的組件通信。這也是與基于空的體系結(jié)構(gòu)的一個(gè)重要區(qū)別，在這種體系結(jié)構(gòu)中，處理單元仍然相互通信并同步信息。

這里的挑戰(zhàn)在于劃分算法。一個(gè)單位會(huì)有很多組成部分，如果業(yè)務(wù)復(fù)雜，會(huì)涉及很多數(shù)據(jù)。為了隔離，每個(gè)組件必須根據(jù)相同的算法進(jìn)行分區(qū)。

本質(zhì)上，每個(gè)單元都是相似的，單元之間的差異取決于請(qǐng)求或數(shù)據(jù)。而且級(jí)別越高，區(qū)分度越低，用戶甚至可以在不同的單位之間漫游。

模式動(dòng)力學(xué)模式動(dòng)力學(xué)

單元架構(gòu)最典型的目的是實(shí)現(xiàn)高性能和高經(jīng)濟(jì)速度。這里我們一方面發(fā)現(xiàn)其他架構(gòu)其實(shí)浪費(fèi)了很多資源，每一層服務(wù)都運(yùn)行在單獨(dú)的操作系統(tǒng)上，必須通過(guò)局域網(wǎng)或者城域網(wǎng)進(jìn)行傳輸。

同時(shí)，傳統(tǒng)的互聯(lián)網(wǎng)服務(wù)仍然希望用一堆具有普通計(jì)算能力的節(jié)點(diǎn)為大量用戶服務(wù)。隨著摩爾定律的推進(jìn)，單機(jī)性能越來(lái)越高，網(wǎng)絡(luò)通信成本變得顯著。這給了我們?cè)诖怪狈较驍U(kuò)張的機(jī)會(huì)和動(dòng)力。

當(dāng)你把更多的組件放在同一個(gè)地方，你也獲得了物理上計(jì)算本地化的優(yōu)勢(shì)。這是我們業(yè)績(jī)提升的根本原因。

服務(wù)分很多單元，但總是需要與外界溝通，這就交給協(xié)調(diào)員了。您可以在內(nèi)部添加存儲(chǔ)、緩存、隊(duì)列和處理器。所有這些非交互組件理論上都是外部資源無(wú)法訪問(wèn)的。

前面說(shuō)過(guò)，單元化過(guò)程也是劃分算法的應(yīng)用過(guò)程。而這個(gè)劃分算法放在哪里是個(gè)問(wèn)題。

我們可以將運(yùn)行時(shí)封裝到客戶端，或者我們可以充當(dāng)內(nèi)置算法的代理層。還有一些服務(wù)因?yàn)闃I(yè)務(wù)需要需要復(fù)制到各個(gè)單元。這是典型的散點(diǎn)-蓋特模型，所以你可能還需要一個(gè)作業(yè)管理系統(tǒng)。這些都是可選的使用方法。

模式分析

整體敏捷性、易部署、高可測(cè)性、高性能、高可擴(kuò)展性、低開(kāi)發(fā)。

出于篇幅的原因，我們就不一一細(xì)說(shuō)了，相信大家可以自行分析。唯一需要強(qiáng)調(diào)的是，運(yùn)維要求比較高。

單元化后，所有服務(wù)放在一起，需要在請(qǐng)求失敗時(shí)快速定位一個(gè)單元，這與層次排除的思想不同。如果運(yùn)維團(tuán)隊(duì)效率不夠，面對(duì)這樣的集群數(shù)量激增(單位服務(wù)數(shù)量相當(dāng)于原集群服務(wù)數(shù)量)，可能會(huì)被大量的工作壓垮；如果運(yùn)維團(tuán)隊(duì)分離明顯，每個(gè)組件都由專門(mén)的團(tuán)隊(duì)維護(hù)(我們?cè)谖⒉┥嫌龅降?，就會(huì)有被拒絕的風(fēng)險(xiǎn)，因?yàn)槊總€(gè)團(tuán)隊(duì)都有自己的權(quán)限和服務(wù)管理習(xí)慣，需要相當(dāng)?shù)膮f(xié)調(diào)，防止相互干擾。

附筆

之前留下的一個(gè)問(wèn)題是煎餅果子和單元化建筑的關(guān)系。答案很簡(jiǎn)單，問(wèn)問(wèn)煎餅攤就知道了。

煎餅分層，煎餅攤單元化。消息服務(wù)是單一的，但是索引維護(hù)是分層的?？茨Ｐ蛠?lái)確定系統(tǒng)的范圍，從不同的角度來(lái)看，同樣的東西有不同的含義。這是建筑師應(yīng)該思考的問(wèn)題。其實(shí)IT系統(tǒng)有幾百萬(wàn)，模型肯定不會(huì)就此止步。然而，對(duì)于基本模式，理解它們之間的異同有助于我們?cè)O(shè)計(jì)自己的系統(tǒng)并考慮權(quán)衡。

問(wèn)答。A

1.單元化設(shè)計(jì)是否類(lèi)似于Docker的集裝箱化思想？有什么區(qū)別？

樂(lè)毅:應(yīng)該是焦點(diǎn)不同，但沒(méi)有沖突。Docker通常是一種將在微服務(wù)架構(gòu)下使用的度量，但這并不意味著它不能在其他架構(gòu)中使用。一個(gè)單元里的各種組件，用什么樣的技術(shù)，都是新的選擇。Docker不錯(cuò)。

2.對(duì)于分布式服務(wù)，單元化架構(gòu)可能會(huì)帶來(lái)數(shù)據(jù)一致性問(wèn)題。如何解決這個(gè)問(wèn)題？

易樂(lè):可能我沒(méi)看懂你的場(chǎng)景。單元化一般不會(huì)帶來(lái)一致性問(wèn)題。因?yàn)榉制?，一個(gè)分區(qū)數(shù)據(jù)塊相當(dāng)于完全屬于一個(gè)單元，其他單元是孤立訪問(wèn)的。

3.單元化架構(gòu)的最小情況是單臺(tái)機(jī)器部署整個(gè)服務(wù)。如何規(guī)劃資源？

樂(lè)毅:這是關(guān)于計(jì)算，也就是容量規(guī)劃，我相信大家都很熟悉。需要注意的一點(diǎn)是，當(dāng)應(yīng)用于可預(yù)測(cè)的整體容量時(shí)，單元化架構(gòu)可以節(jié)省很多東西。鑒于固定和擴(kuò)展分區(qū)算法，其實(shí)可以提前規(guī)劃，在單臺(tái)機(jī)器上混合多個(gè)單元。

4.單元和app集群的關(guān)聯(lián)如何，是注冊(cè)服務(wù)分配的還是hash分配的？如果是哈希分配的，掛了怎么接收？如果是注冊(cè)服務(wù)，如何進(jìn)行相應(yīng)的分配？

樂(lè)毅:簡(jiǎn)單的是哈希賦值，高級(jí)點(diǎn)是注冊(cè)服務(wù)，可以直接參考成熟的分片算法。任務(wù)只要到了單位，就是單位自己的事。如果您的作業(yè)有階段，您可能需要考慮作業(yè)狀態(tài)記錄和請(qǐng)求處理的等同性

5.你認(rèn)為單元化建筑的問(wèn)題是什么？如果讓你重新設(shè)計(jì)，你會(huì)做哪些改進(jìn)？

易樂(lè):這個(gè)問(wèn)題太巧妙了，謝謝！如前所述，單元化架構(gòu)的問(wèn)題有擴(kuò)展問(wèn)題、運(yùn)維問(wèn)題和單點(diǎn)問(wèn)題。如前所述，三年前我們沒(méi)有Docker的時(shí)候，很難隔離我們的服務(wù)，現(xiàn)在也不是以前的樣子了。Docker在手，我全世界都有！對(duì)于單元的單點(diǎn)問(wèn)題，你要考慮單元層面的主從同步，這方面常用的互聯(lián)網(wǎng)技術(shù)都可以。

6.分布式架構(gòu)往往關(guān)注無(wú)狀態(tài)的服務(wù)器，使得單個(gè)服務(wù)器的異常對(duì)整體服務(wù)沒(méi)有影響。但是單位化意味著服務(wù)是有狀態(tài)的。如何保證高可用性？

一樂(lè):無(wú)國(guó)籍只能是業(yè)務(wù)層，數(shù)據(jù)不會(huì)是無(wú)國(guó)籍的，因?yàn)閿?shù)據(jù)是狀態(tài)的記錄。保證高可用性，前面說(shuō)了，先做主從。

7.你仍然在單元中采用層次化的架構(gòu)設(shè)計(jì)，還是僅僅采用一體式架構(gòu)設(shè)計(jì)？

樂(lè)毅:當(dāng)談到單位化時(shí)，單位中的組織模式是不需要的，所以答案是肯定的。

8.除了采用這種統(tǒng)一的架構(gòu)模式之外，“每秒數(shù)百萬(wàn)次的推送”使其成為可能。隊(duì)列db等基礎(chǔ)中間件的架構(gòu)是如何規(guī)劃的？另外需要考慮哪些技術(shù)要點(diǎn)或問(wèn)題？

一樂(lè):排隊(duì)主要是為了防高峰。在高速服務(wù)中，要想再次擴(kuò)容，必須采取先批量的方式。其實(shí)db的規(guī)劃才是重點(diǎn)，蜂窩架構(gòu)其實(shí)就是一個(gè)以數(shù)據(jù)為中心的模型。其實(shí)額外的考慮和之前差不多，只是需要一些特殊的處理，比如冷熱數(shù)據(jù)的分離。