從Excel到微服務(wù)
Excel很老，Excel很土，Excel一點(diǎn)也不sexy；微服務(wù)新，微服務(wù)很潮門，微服務(wù)很高大上。那么，Excel和微服務(wù)有什么關(guān)系？
上個(gè)月看了篇文章，The Unbunlding of Excel。作者認(rèn)為，對(duì)于初創(chuàng)公司（尤其是非“純IT”初創(chuàng)公司）來說，Excel幾乎包辦各種工作。想要計(jì)算？請(qǐng)用Excel。想做輕量級(jí)的CRM，可用Excel。建立財(cái)務(wù)分析模型？還是用Excel。簡(jiǎn)單的項(xiàng)目管理？當(dāng)然Excel。數(shù)據(jù)分析總攬圖？仍然是Excel。執(zhí)行簡(jiǎn)單的ETL任務(wù)？Excel再合適不過了。
Excel真的這么能干嗎？從邏輯上說，它是成立的。首先公司里很多業(yè)務(wù)都是基于數(shù)據(jù)的，其原型都是對(duì)表格的操作，Excel“天生”就是表格。其次，Excel提供了足夠弱又足夠強(qiáng)的“編程能力”，Excel中的VBA、透視表等等功能對(duì)于強(qiáng)大的編程語言來說或許不值一提，但許多對(duì)編程語言望而卻步的人卻能把這些功能運(yùn)用得無比純熟，玩出的花樣讓很多程序員也嘆為觀止。
更重要的是，初創(chuàng)公司的業(yè)務(wù)往往是不確定的，業(yè)務(wù)領(lǐng)域需要探索，業(yè)務(wù)規(guī)則也需要不斷修訂。Excel雖然沒有量身定制的系統(tǒng)那么完善，但成本相當(dāng)?shù)土?。?duì)初創(chuàng)公司來說，除非自己養(yǎng)著非常厲害的開發(fā)團(tuán)隊(duì)，系統(tǒng)又做得足夠高質(zhì)量足夠靈活，一面猛改一面還保持穩(wěn)定，否則即便“上系統(tǒng)”，也經(jīng)常被系統(tǒng)困住手腳，業(yè)務(wù)反而受到拖累。
如果你覺得這只是“邏輯上”的分析，我還可以給出更現(xiàn)實(shí)的例子。
如今很多公司都知道要有CRM（客戶關(guān)系管理）系統(tǒng)，來處理和匯總與客戶之間的問題。業(yè)務(wù)還沒開展，CRM先得買一套或者開發(fā)一套，這已經(jīng)成了流行的思維定勢(shì)。但是，買來或者開發(fā)的CRM，未必能很好滿足自己的業(yè)務(wù)需求，因此踩坑的例子數(shù)不勝數(shù)。
朋友的一家公司，一開始根本沒有上CRM，只要求客服每人每天用Excel把回答的問題記下來，每天晚上指定專人匯總，第二天早上把匯總和更新之后最新的Excel通過郵件下發(fā)給所有客服，回答問題的時(shí)候就在這張表里用Ctrl+F來尋找關(guān)鍵詞。這樣的做法雖然看起來很累很煩，卻足夠簡(jiǎn)單有效。既不用擔(dān)心系統(tǒng)死掉大家都干不了活，也不用擔(dān)心問題分類設(shè)定不合理無法錄入或者數(shù)據(jù)格式變化導(dǎo)致的歷史數(shù)據(jù)清洗成本。
等這套流程真正跑順穩(wěn)定了，公司業(yè)務(wù)也足夠大了，有時(shí)間有資本把已經(jīng)摸索的客服管理的經(jīng)驗(yàn)和流程固化到系統(tǒng)里，CRM系統(tǒng)開發(fā)順理成章，上線到投入使用相當(dāng)自然。
我還見過一家電商公司，因?yàn)橼s上了風(fēng)口，業(yè)務(wù)發(fā)展極其迅猛。于是公司也馬上遇到了問題，創(chuàng)始人都是做互聯(lián)網(wǎng)的出身，對(duì)實(shí)業(yè)并沒有多么豐富的經(jīng)驗(yàn)，多地倉庫的管理成了老大難，庫存經(jīng)常亂套了。
怎么辦？雖然自己有一支小的開發(fā)團(tuán)隊(duì)，但日常業(yè)務(wù)已經(jīng)足夠他們忙的了，而且倉儲(chǔ)是個(gè)專門的領(lǐng)域，即便沒做過，專門去看看也知道水很深，何況倉庫運(yùn)營的規(guī)則和辦法還在不斷優(yōu)化，這時(shí)候要做出一套好用的倉儲(chǔ)系統(tǒng)，幾乎是癡人說夢(mèng)。然而每次出問題，很多基層員工都會(huì)抱怨，要是有系統(tǒng)就好了。
創(chuàng)始團(tuán)隊(duì)想到的辦法就是Excel，不管倉儲(chǔ)規(guī)則怎么千變?nèi)f化，基本的庫存管理，無非是入庫、出庫、盤庫等幾個(gè)動(dòng)作，數(shù)據(jù)格式是相對(duì)固定的。那么，每個(gè)倉庫每天干完活，再忙再累再晚，也要把倉儲(chǔ)信息按照約定的Excel模版回傳到總部，由專人統(tǒng)計(jì)合并。這工作說起來簡(jiǎn)單，做起來可讓人叫苦連天，尤其是還有些倉庫分布在海外有時(shí)差，每天光是統(tǒng)計(jì)合并這些數(shù)據(jù)就得一兩天。
既然老大發(fā)了話，下面的人有抱怨也不敢發(fā)出來，只能老老實(shí)實(shí)執(zhí)行。整套流程兩三個(gè)禮拜，日常的操作基本都不會(huì)出問題，要完善操作流程時(shí)，也大概知道了該怎么修改表格。就這樣邊錄邊改，磨合了大半年，終于把流程基本定下來了。這時(shí)候再安排產(chǎn)品經(jīng)理、項(xiàng)目經(jīng)理、程序員進(jìn)場(chǎng)，一看日常用的Excel，數(shù)據(jù)項(xiàng)、數(shù)據(jù)項(xiàng)之間的關(guān)聯(lián)清清楚楚，不清楚的地方問問操作人員也立刻可以得到解答。這時(shí)候再安排開發(fā)倉儲(chǔ)管理系統(tǒng)，基本不存在什么領(lǐng)域知識(shí)難題，更像是順?biāo)浦鄣氖虑椤?/p>
仔細(xì)觀察這兩個(gè)例子，你會(huì)發(fā)現(xiàn)，它們的本質(zhì)是一樣的，即在對(duì)問題域還不夠了解、問題解法還沒有徹底明晰之前，需要一種具有一定規(guī)范性同時(shí)低成本的手段，一方面對(duì)現(xiàn)有操作進(jìn)行約束，另一方面能持續(xù)探索問題、完善已有方案。這時(shí)候，他們選擇了Excel。
本來我看完這篇講Excel的文章就準(zhǔn)備談點(diǎn)感想，巧合的是，后來又看到一篇“神似”的文章，You are not Google。作者強(qiáng)調(diào)的是，別盲目崇拜那些大公司吹得神乎其神的技術(shù)，真正重要的是理解你的問題。這個(gè)主旨，和上面文章里對(duì)Excel的“吹捧“其實(shí)是一致的。
你知道GFS和Map/Reduce，但是你知道它們是為了解決什么問題的嗎？是為了計(jì)算、存儲(chǔ)、索引所有的網(wǎng)頁（那個(gè)時(shí)候大概有8000萬）。你知道SOA，但是你知道亞馬遜什么時(shí)候上的SOA嗎？那時(shí)候亞馬遜已經(jīng)有7800名雇員，年?duì)I業(yè)額超過30億美元了。你只知道數(shù)據(jù)庫集群、NoSQL，但是你知道嗎？StackExchange在2016年，面對(duì)2億的日訪問量，只有4臺(tái)SQLServer……
好了，現(xiàn)在我要回到題目，說起“微服務(wù)”了。
微服務(wù)很新，微服務(wù)很潮，微服務(wù)很高大上。我在面試架構(gòu)師的時(shí)候，很多候選人說到微服務(wù)，都可以侃侃而談，各種新鮮的名詞、概念、框架止不住地蹦出來，卻沒法回答幾個(gè)問題：為什么微服務(wù)會(huì)崛起？什么時(shí)候應(yīng)當(dāng)實(shí)行微服務(wù)？實(shí)行微服務(wù)要注意什么？甚至，連微服務(wù)與SOA的關(guān)系是什么都搞不清楚。
要知道，架構(gòu)師并不是“框架和解決方案推廣落地人員”，他是需要做決策的，軟件開發(fā)中，架構(gòu)決策對(duì)系統(tǒng)的影響往往是至關(guān)重要的，一旦出現(xiàn)問題，后果可能相當(dāng)嚴(yán)重。所以，合格的架構(gòu)師對(duì)于微服務(wù)，不但需要了解現(xiàn)成的方案和概念，更應(yīng)該真正的問題是什么，決策的依據(jù)是什么，然后才能知道，自己的決策是否合理。
在我看來，微服務(wù)對(duì)SOA既是延續(xù)也是更新。在我們談?wù)揝OA的時(shí)候，談得更多的是一種設(shè)計(jì)理念，它要求脫離軟件本身的限制，從抽象的“服務(wù)”角度來進(jìn)行思考和設(shè)計(jì)。從此，我們可以在更高更抽象的層面上來思考如何用軟件解決問題，不再時(shí)時(shí)處處受到技術(shù)的掣肘。然而，SOA談?wù)摿硕嗄?，一直沒有看到具體的、公認(rèn)的、合理的落地案例。
許多談SOA的書里都會(huì)講到一個(gè)概念：ESB。希望有一天，軟件服務(wù)也可以像硬件服務(wù)那樣，有一條通用的總線，然后各種服務(wù)只需要簡(jiǎn)單接入就可以了。但是這或許只是一個(gè)美麗的夢(mèng)想，真正投入使用的ESB其實(shí)相當(dāng)少。
微服務(wù)的興起，很大程度上對(duì)應(yīng)著我們?cè)谔剿魑粗I(lǐng)域、探索未知問題的腳步。我們無法全知全能地知道，系統(tǒng)的什么部分、哪個(gè)環(huán)節(jié)，在什么時(shí)候會(huì)成為障礙或瓶頸，但是，我們又必須迅速地發(fā)現(xiàn)這些障礙或瓶頸，解決它們，同時(shí)保證整個(gè)系統(tǒng)的穩(wěn)定。把系統(tǒng)拆分為一個(gè)個(gè)微服務(wù)，正是為了解決這樣的問題，它讓我們可以聚焦在具體部分和環(huán)節(jié)上，又限制了復(fù)雜性，避免了“牽一發(fā)而動(dòng)全身”的尷尬。
仔細(xì)思考就會(huì)發(fā)現(xiàn)，微服務(wù)的興起，也是對(duì)ESB思路的顛覆。ESB強(qiáng)調(diào)的是“重通訊輕終端”，微服務(wù)強(qiáng)調(diào)的則是“重終端輕通訊”，數(shù)據(jù)通訊一般只是通過簡(jiǎn)單的HTTP進(jìn)行，終端對(duì)于通訊總線并沒有特別強(qiáng)的業(yè)務(wù)依賴。這樣確實(shí)降低了耦合性，但也對(duì)終端提出了更高的要求。
以前大家只習(xí)慣于寫一點(diǎn)業(yè)務(wù)邏輯代碼，生成幾個(gè)類庫，放到巨大的單體系統(tǒng)里就可以放心了。進(jìn)行微服務(wù)改造之后，你的這點(diǎn)業(yè)務(wù)邏輯代碼只是服務(wù)的核心，既然名曰“服務(wù)”，就得五臟俱全，既然名曰“微服務(wù)”，就得螺螄殼里做道場(chǎng)。
換句話說，服務(wù)必須能獨(dú)立部署、獨(dú)立維護(hù)、方便擴(kuò)展。你得在服務(wù)的邊界清晰和技術(shù)限制之間做出權(quán)衡，你得搭建完整的監(jiān)控，你得考慮高可用性，你得選擇通訊機(jī)制，你得分析負(fù)載壓力，你還得仔細(xì)規(guī)劃容量……身為架構(gòu)師，一門心思考慮分家，一味鼓吹分家的各種好處，絕對(duì)是不稱職的：分家過日子當(dāng)然瀟灑，但自己當(dāng)家卻不知道柴米油鹽貴，這是絕對(duì)要餓死的。
最后講個(gè)有意思的事情，這些年我有好幾個(gè)技術(shù)很好對(duì)微服務(wù)理解很深刻的朋友，去了創(chuàng)業(yè)公司首先做的事情往往都是“技術(shù)的倒退”：就這十來個(gè)人、七八條槍，還折騰什么微服務(wù)？快別扯淡了！
附：原文鏈接
The Unbunlding of Excel
You are not Google