低并發(fā)編程

戰(zhàn)略上藐視技術(shù)，戰(zhàn)術(shù)上重視技術(shù)

?我是一個服務(wù)，我的名字叫閃客。

我提供的服務(wù)很簡單，給我一個標題，我輸出一篇文章。

?日復(fù)一日，年復(fù)一年。

X

但隨著粉絲數(shù)的不斷增多，我對文章的質(zhì)量也有了更加嚴格的要求，所以我很容易累死，累死了就會鴿文。

為了防止這種情況發(fā)生，我使用了我的技能，分身術(shù)。

我分出了 N 多個和我一模一樣的服務(wù)，平時他們不干活，但當我累死的時候，他們隨時頂上來。

當然，他們也可以和我一起干活，或者幫我干一部分活，分擔(dān)一下我的壓力，減少我累死的概率。

這樣，我通過簡單的分身之術(shù)，就可以輕松駕馭幾千個粉絲的需求啦。

Y

但隨著粉絲數(shù)量的繼續(xù)增多，我發(fā)現(xiàn)我即使再多分身也沒用。

因為慢慢地，事情已經(jīng)不僅僅是寫文章就夠了，文章技術(shù)答疑，廣告對接等等工作。

每一個分身，不再像以前那樣只處理一項工作，因此效率也降低了。

此時我不能再通過分出多個一模一樣的我，來處理相同的事情，必須根據(jù)業(yè)務(wù)進行不同功能的劃分。

?這樣，寫文章的閃客，就專心寫文章，技術(shù)答疑的閃客，就專心進行技術(shù)答疑，做廣告的閃客，就專心數(shù)錢。

每個人的任務(wù)再次變得單一，也專注了起來，效率又上了一個臺階。

此時已經(jīng)可以輕松駕馭上萬個粉絲的需求啦。

Z

但又隨著粉絲數(shù)量的繼續(xù)增長，我發(fā)現(xiàn)，按功能分身也沒用了，因為某個單一的功能，也變得極為復(fù)雜。

比如技術(shù)答疑，有的讀者問的是職業(yè)規(guī)劃，有的讀者問的是技術(shù)細節(jié)，還有的讀者是問我婚否飯否。

負責(zé)技術(shù)答疑的分身，已經(jīng)無法再進行自身業(yè)務(wù)屬性上的拆分了，但又越來越無法招架用戶五花八門的問題，怎么辦呢？

那就根據(jù)用戶的問題繼續(xù)分解我的服務(wù)！

關(guān)心技術(shù)問題的用戶，通通與答疑閃 1 進行對話。

關(guān)心職場術(shù)問題的用戶，通通與答疑閃 2 進行對話。

關(guān)心婚戀問題的用戶，通通與答疑閃 3 進行對話。

這樣，雖然這些服務(wù)都是負責(zé)答疑這個業(yè)務(wù)，但是卻根據(jù)用戶的不同進行劃分，減少了每個服務(wù)的壓力和需要處理的事情。

AKF

上面只是跟大家開個玩笑，下面要嚴肅一些咯。

上面的那一堆胡說八道的廢話，就叫 AKF 可擴展立方體。這個概念出自《架構(gòu)即未來》一書中提出的可擴展模型。

這個立方體有三個軸線 XYZ，每個軸線描述擴展性的一個維度。

X：無差別的克隆服務(wù)和數(shù)據(jù)。

讓請求很均勻的分散在不同的服務(wù)實例上，就像上面我說的第一種分身方式。

?當然還有更具體的。

還記不記得剛剛我說的，我可以讓分身平時不工作，只是隨時待命，等主身掛了再頂上來，這個叫主備模型。

當然我也可以讓分身和我承擔(dān)一樣的工作，無差別地提供服務(wù)，這個叫主主模型。

我還可以讓分身只承擔(dān)部分工作，例如分身只提供讀，而主身提供讀寫，這個叫主從模型。

Y：根據(jù)自身業(yè)務(wù)拆分

提供不同業(yè)務(wù)類型的服務(wù)，就像上面我說的第二種分身方式。

?我們公司里一般按業(yè)務(wù)進行微服務(wù)的拆分，不管是垂直的還是水平的，都是這種 Y 軸的劃分方式。

Z：根據(jù)用戶屬性或數(shù)據(jù)拆分

就像我剛剛說的第三種分身方式。

?這種拆分方式一般是數(shù)據(jù)集的拆分，經(jīng)典的如 Redis 的集群模式，就是按數(shù)據(jù)的哈希值進行分片。

三種方式是可以同時存在的，組合起來就是這樣。

?畫得好丑。

萬物皆可 AKF

剛剛也隱隱約約提到了，我們把這個模型試著往 Redis 里套一下，你就明白了。

Redis

單節(jié)點的 redis 很不穩(wěn)定，所以有了很多保障可用性的擴展方式。

redis 中的主從模式，就是 AKF 中的 X 軸方向的擴展。

redis 中的集群模式（也就是數(shù)據(jù)分片），就是 AKF 中的 Z 軸方向的擴展。

如果你再按照業(yè)務(wù)拆分，比如用戶數(shù)據(jù)訪問 redis1，訂單數(shù)據(jù)訪問 redis2，那你其實相當于在做 AKF 中的 Y 軸方向的擴展。

這是拿中間件舉例。

我們再嘗試著套一下公司中的普通業(yè)務(wù)項目。

普通項目

一個項目部署好幾十臺機器，比如我們的 API 服務(wù)部署了 128 個節(jié)點，那這個其實就是 X 軸。

根據(jù)業(yè)務(wù)劃分了很多微服務(wù)，比如有用戶模塊服務(wù)，訂單模塊服務(wù)，推薦模塊服務(wù)，服務(wù)之間用 rpc 進行通信，這其實就是 Y 軸。

Z 軸一般在業(yè)務(wù)側(cè)比較少，數(shù)據(jù)數(shù)據(jù)集的拆分方式，我們還沒有這樣的拆分，拿 Redis 的集群分片舉例比較合適。

不過你要是說，根據(jù)用戶的 IP 屬性，將請求打在不同機器上，其實也算吧，沒有特別嚴格的定義，只是一種思維方式。

總之，如果你能在架構(gòu)側(cè)擁有 AKF 的思考方式，很多中間件、業(yè)務(wù)、甚至現(xiàn)實生活中的組織架構(gòu)和人員分配的設(shè)置，都可以站在一個更高更全面的視角去看待，這就是一個典型的架構(gòu)思維。

后記

今天這篇文章的 AKF 這個概念，也是我最近才知道的。

這個名詞好多人都沒聽說過，但我了解了它的思想之后越發(fā)覺得對架構(gòu)思維真的有用。之前很多架構(gòu)上的設(shè)計，現(xiàn)在似乎有了一個更高層的理論支撐，這種感覺還是挺爽的，因此當然毫無保留地分享給大家。

其實 AKF 可擴展立方體模型，在《架構(gòu)及未來》一書中的概念更廣義，適用于所有抽象的、具體的組織形式的擴展，只不過用到技術(shù)架構(gòu)上，也剛好合適。

所以這讓我越發(fā)覺得這個思維的牛逼之處，也讓我覺得，有的時候技術(shù)架構(gòu)就是一種管理層面的東西，這么說完全不為過。

OK，今天就分享到這里啦，歡迎大家加我好友（公眾號菜單里有）一起討論技術(shù)，或看我朋友圈里的一驚一乍，下期再見咯。