作者：SoarYuan
鏈接：https://juejin.im/post/6854573206700130317
最近一直在看《從0開(kāi)始學(xué)架構(gòu)》這個(gè)技術(shù)專(zhuān)欄，有一些自己的思考，分享給大家，如果在面試中被問(wèn)及這個(gè)問(wèn)題，大家就可以按照這個(gè)思路來(lái)回答。
很多讀者都是移動(dòng)端開(kāi)發(fā)，而市面上的書(shū)或者專(zhuān)欄基本都是后端，難道架構(gòu)是天然為后端而生的嗎？其實(shí)不是，但確實(shí)后端架構(gòu)比客戶端以及前端要復(fù)雜。
經(jīng)過(guò)我的思考，我試圖抽象一些移動(dòng)端架構(gòu)的特性出來(lái)。
高并發(fā)、負(fù)載均衡和容災(zāi)是后端架構(gòu)設(shè)計(jì)的幾個(gè)核心點(diǎn)，但這幾個(gè)點(diǎn)在移動(dòng)端上不存在，原因是所有的請(qǐng)求都會(huì)發(fā)送到同一個(gè)后端，這樣移動(dòng)端和后端就是個(gè)多對(duì)一的關(guān)系，所以移動(dòng)端自然就沒(méi)有高并發(fā)了。
一、移動(dòng)端架構(gòu)設(shè)計(jì)到底做什么？
常規(guī)來(lái)看，基本就是MVC、MVP、MVVM以及組件化的東西，這些東西說(shuō)是架構(gòu)，但本質(zhì)上就是模塊化的變種，這類(lèi)東西主要是做業(yè)務(wù)架構(gòu)，將一個(gè)很大的業(yè)務(wù)劃分為很多小業(yè)務(wù)，每個(gè)小業(yè)務(wù)就是一個(gè)模塊。
另一部分架構(gòu)內(nèi)容則是技術(shù)架構(gòu)，一般是分層的，最底層是基礎(chǔ)框架，包括網(wǎng)絡(luò)、存儲(chǔ)、日志、圖片加載等第三方庫(kù)；中間層則是上層業(yè)務(wù)經(jīng)過(guò)抽象后所形成的公共業(yè)務(wù)層，也可以叫做中臺(tái)，這一塊往往包含賬號(hào)、支付、客服、地圖等相對(duì)獨(dú)立的業(yè)務(wù)；最上層就是核心業(yè)務(wù)了。從變動(dòng)性來(lái)說(shuō)，基礎(chǔ)框架變動(dòng)最低，公共業(yè)務(wù)層次之，上層業(yè)務(wù)變動(dòng)最高。
總結(jié)來(lái)看：移動(dòng)端架構(gòu) = 業(yè)務(wù)架構(gòu)（模塊化） + 技術(shù)架構(gòu)（分層）
二、為什么要做架構(gòu)設(shè)計(jì)？
很多人（包括我）只知道要做架構(gòu)設(shè)計(jì)，但不知道為什么要做，如果非要說(shuō)，大家估計(jì)能總結(jié)為如下幾點(diǎn)：
“為了讓項(xiàng)目看起來(lái)更有技術(shù)含量”
“大家都做架構(gòu)設(shè)計(jì)，我也得做”
“提高程序性能和可擴(kuò)展性，降低后續(xù)的維護(hù)成本”
其實(shí)這些目標(biāo)都比較抽象，不好衡量，做完架構(gòu)設(shè)計(jì)后未必能達(dá)到預(yù)期。
舉個(gè)例子，MVP特別流行，MVP的好處就是降低耦合，降低后續(xù)維護(hù)成本，但事實(shí)上，用了MVP后，代碼極度膨脹，新增了很多類(lèi)，代碼可讀性也差，很多新人上手困難，在一大堆presenter中迷失了，大家想想，這樣做維護(hù)成本是否真的降低了？
三、架構(gòu)設(shè)計(jì)的目標(biāo)
如果讓我再說(shuō)一遍，我想我的看法有所改變。
為了尋找架構(gòu)設(shè)計(jì)的目標(biāo)，我們要尋找當(dāng)前項(xiàng)目中的復(fù)雜度來(lái)源，也就是說(shuō)看看當(dāng)前項(xiàng)目中哪個(gè)方面最痛最急需改進(jìn)，舉個(gè)例子吧，像滴滴出行這種APP，復(fù)雜度來(lái)自于大量相似的業(yè)務(wù)線，而且這些業(yè)務(wù)線又是在不同的團(tuán)隊(duì)開(kāi)發(fā)，那團(tuán)隊(duì)協(xié)作問(wèn)題就極為迫切，那我們的架構(gòu)就要圍繞這個(gè)來(lái)。再比如qunar這種旅行APP，它對(duì)動(dòng)態(tài)性的要求特別高，因此qunar內(nèi)部大量使用了react native。
換言之，架構(gòu)設(shè)計(jì)的目標(biāo)是解決當(dāng)前項(xiàng)目的痛點(diǎn)，如果當(dāng)前項(xiàng)目沒(méi)有痛點(diǎn)，那就先別進(jìn)行架構(gòu)設(shè)計(jì)了。
四、如何做架構(gòu)設(shè)計(jì)
架構(gòu)設(shè)計(jì)要以實(shí)用為目的，不要光想著造一個(gè)世上最牛逼的架構(gòu)，這樣往往是不靠譜的，我們不是救世主?？偨Y(jié)下，架構(gòu)設(shè)計(jì)有三個(gè)基本原則：
1、合適優(yōu)于世界領(lǐng)先
適合自己當(dāng)前業(yè)務(wù)的就好，不要總想搞世界領(lǐng)先的架構(gòu)，比如一個(gè)用戶量100萬(wàn)的系統(tǒng)，光想著對(duì)標(biāo)微信的架構(gòu)，那微信日活上億，適合微信的架構(gòu)未必適合自己。
2、簡(jiǎn)單優(yōu)于復(fù)雜
如同寫(xiě)代碼一樣，代碼量越少越簡(jiǎn)單越好，架構(gòu)設(shè)計(jì)也是一樣，越簡(jiǎn)單的架構(gòu)越牛逼。
3、演進(jìn)優(yōu)于一步到位
可擴(kuò)展性我們當(dāng)然要考慮，但是人不是神，無(wú)論你怎么去預(yù)測(cè)未來(lái)的系統(tǒng)演進(jìn)，總是很大可能會(huì)失算。所以架構(gòu)設(shè)計(jì)優(yōu)先解決當(dāng)下的問(wèn)題，至于后來(lái)的問(wèn)題，到時(shí)候再對(duì)架構(gòu)方案進(jìn)行改進(jìn)。
架構(gòu)設(shè)計(jì)還要考慮成本，你設(shè)計(jì)了一個(gè)很好的架構(gòu)，但是需要投入20個(gè)人，還要項(xiàng)目停止2個(gè)月專(zhuān)門(mén)做架構(gòu)開(kāi)發(fā)，那這種成本就太高，很難推進(jìn)。拿后端來(lái)舉例，你設(shè)計(jì)了一個(gè)巨牛逼有效的架構(gòu)，但需要1000臺(tái)服務(wù)器，然后公司買(mǎi)不起這么多服務(wù)器，那也是白搭。
這三個(gè)原則也是有優(yōu)先級(jí)的，具體是：
合適優(yōu)于先進(jìn) > 演化優(yōu)于一步到位 > 簡(jiǎn)單優(yōu)于復(fù)雜
合適也就是適應(yīng)當(dāng)前需要是首位的，連當(dāng)前需求都滿足不了談不到其他。架構(gòu)整體發(fā)展是要不斷演進(jìn)的，在這個(gè)大前提下，盡量追求簡(jiǎn)單，但也有該復(fù)雜的時(shí)候，就要復(fù)雜，比如生物從單細(xì)胞一直演化到如今，復(fù)雜是避免不了的。
