Excel很老，Excel很土，Excel一點也不sexy；微服務新，微服務很潮門，微服務很高大上。那麼(me)，Excel和微服務有什麼(me)關系？

上個月看了篇文章，The Unbunlding of Excel。作者認爲，對(duì)于初創公司（尤其是非“純IT”初創公司）來說(shuō)，Excel幾乎包辦各種(zhǒng)工作。想要計算？請用Excel。想做輕量級的CRM，可用Excel。建立财務分析模型？還(hái)是用Excel。簡單的項目管理？當然Excel。數據分析總攬圖？仍然是Excel。執行簡單的ETL任務？Excel再合适不過(guò)了。

Excel真的這(zhè)麼(me)能(néng)幹嗎？從邏輯上說(shuō)，它是成(chéng)立的。首先公司裡(lǐ)很多業務都(dōu)是基于數據的，其原型都(dōu)是對(duì)表格的操作，Excel“天生”就(jiù)是表格。其次，Excel提供了足夠弱又足夠強的“編程能(néng)力”，Excel中的VBA、透視表等等功能(néng)對(duì)于強大的編程語言來說(shuō)或許不值一提，但許多對(duì)編程語言望而卻步的人卻能(néng)把這(zhè)些功能(néng)運用得無比純熟，玩出的花樣讓很多程序員也歎爲觀止。

更重要的是，初創公司的業務往往是不确定的，業務領域需要探索，業務規則也需要不斷修訂。Excel雖然沒(méi)有量身定制的系統那麼(me)完善，但成(chéng)本相當低廉。對(duì)初創公司來說(shuō)，除非自己養著(zhe)非常厲害的開(kāi)發(fā)團隊，系統又做得足夠高質量足夠靈活，一面(miàn)猛改一面(miàn)還(hái)保持穩定，否則即便“上系統”，也經(jīng)常被系統困住手腳，業務反而受到拖累。

如果你覺得這(zhè)隻是“邏輯上”的分析，我還(hái)可以給出更現實的例子。

如今很多公司都(dōu)知道(dào)要有CRM（客戶關系管理）系統，來處理和彙總與客戶之間的問題。業務還(hái)沒(méi)開(kāi)展，CRM先得買一套或者開(kāi)發(fā)一套，這(zhè)已經(jīng)成(chéng)了流行的思維定勢。但是，買來或者開(kāi)發(fā)的CRM，未必能(néng)很好(hǎo)滿足自己的業務需求，因此踩坑的例子數不勝數。

朋友的一家公司，一開(kāi)始根本沒(méi)有上CRM，隻要求客服每人每天用Excel把回答的問題記下來，每天晚上指定專人彙總，第二天早上把彙總和更新之後(hòu)最新的Excel通過(guò)郵件下發(fā)給所有客服，回答問題的時(shí)候就(jiù)在這(zhè)張表裡(lǐ)用Ctrl+F來尋找關鍵詞。這(zhè)樣的做法雖然看起(qǐ)來很累很煩，卻足夠簡單有效。既不用擔心系統死掉大家都(dōu)幹不了活，也不用擔心問題分類設定不合理無法錄入或者數據格式變化導緻的曆史數據清洗成(chéng)本。

等這(zhè)套流程真正跑順穩定了，公司業務也足夠大了，有時(shí)間有資本把已經(jīng)摸索的客服管理的經(jīng)驗和流程固化到系統裡(lǐ)，CRM系統開(kāi)發(fā)順理成(chéng)章，上線到投入使用相當自然。

我還(hái)見過(guò)一家電商公司，因爲趕上了風口，業務發(fā)展極其迅猛。于是公司也馬上遇到了問題，創始人都(dōu)是做互聯網的出身，對(duì)實業并沒(méi)有多麼(me)豐富的經(jīng)驗，多地倉庫的管理成(chéng)了老大難，庫存經(jīng)常亂套了。

怎麼(me)辦？雖然自己有一支小的開(kāi)發(fā)團隊，但日常業務已經(jīng)足夠他們忙的了，而且倉儲是個專門的領域，即便沒(méi)做過(guò)，專門去看看也知道(dào)水很深，何況倉庫運營的規則和辦法還(hái)在不斷優化，這(zhè)時(shí)候要做出一套好(hǎo)用的倉儲系統，幾乎是癡人說(shuō)夢。然而每次出問題，很多基層員工都(dōu)會(huì)抱怨，要是有系統就(jiù)好(hǎo)了。

創始團隊想到的辦法就(jiù)是Excel，不管倉儲規則怎麼(me)千變萬化，基本的庫存管理，無非是入庫、出庫、盤庫等幾個動作，數據格式是相對(duì)固定的。那麼(me)，每個倉庫每天幹完活，再忙再累再晚，也要把倉儲信息按照約定的Excel模版回傳到總部，由專人統計合并。這(zhè)工作說(shuō)起(qǐ)來簡單，做起(qǐ)來可讓人叫(jiào)苦連天，尤其是還(hái)有些倉庫分布在海外有時(shí)差，每天光是統計合并這(zhè)些數據就(jiù)得一兩(liǎng)天。

既然老大發(fā)了話，下面(miàn)的人有抱怨也不敢發(fā)出來，隻能(néng)老老實實執行。整套流程兩(liǎng)三個禮拜，日常的操作基本都(dōu)不會(huì)出問題，要完善操作流程時(shí)，也大概知道(dào)了該怎麼(me)修改表格。就(jiù)這(zhè)樣邊錄邊改，磨合了大半年，終于把流程基本定下來了。這(zhè)時(shí)候再安排産品經(jīng)理、項目經(jīng)理、程序員進(jìn)場，一看日常用的Excel，數據項、數據項之間的關聯清清楚楚，不清楚的地方問問操作人員也立刻可以得到解答。這(zhè)時(shí)候再安排開(kāi)發(fā)倉儲管理系統，基本不存在什麼(me)領域知識難題，更像是順水推舟的事(shì)情。

仔細觀察這(zhè)兩(liǎng)個例子，你會(huì)發(fā)現，它們的本質是一樣的，即在對(duì)問題域還(hái)不夠了解、問題解法還(hái)沒(méi)有徹底明晰之前，需要一種(zhǒng)具有一定規範性同時(shí)低成(chéng)本的手段，一方面(miàn)對(duì)現有操作進(jìn)行約束，另一方面(miàn)能(néng)持續探索問題、完善已有方案。這(zhè)時(shí)候，他們選擇了Excel。

本來我看完這(zhè)篇講Excel的文章就(jiù)準備談點感想，巧合的是，後(hòu)來又看到一篇“神似”的文章，You are not Google。作者強調的是，别盲目崇拜那些大公司吹得神乎其神的技術，真正重要的是理解你的問題。這(zhè)個主旨，和上面(miàn)文章裡(lǐ)對(duì)Excel的“吹捧“其實是一緻的。

你知道(dào)GFS和Map/Reduce，但是你知道(dào)它們是爲了解決什麼(me)問題的嗎？是爲了計算、存儲、索引所有的網頁（那個時(shí)候大概有8000萬）。你知道(dào)SOA，但是你知道(dào)亞馬遜什麼(me)時(shí)候上的SOA嗎？那時(shí)候亞馬遜已經(jīng)有7800名雇員，年營業額超過(guò)30億美元了。你隻知道(dào)數據庫集群、NoSQL，但是你知道(dào)嗎？StackExchange在2016年，面(miàn)對(duì)2億的日訪問量，隻有4台SQLServer……

好(hǎo)了，現在我要回到題目，說(shuō)起(qǐ)“微服務”了。

微服務很新，微服務很潮，微服務很高大上。我在面(miàn)試架構師的時(shí)候，很多候選人說(shuō)到微服務，都(dōu)可以侃侃而談，各種(zhǒng)新鮮的名詞、概念、框架止不住地蹦出來，卻沒(méi)法回答幾個問題：爲什麼(me)微服務會(huì)崛起(qǐ)？什麼(me)時(shí)候應當實行微服務？實行微服務要注意什麼(me)？甚至，連微服務與SOA的關系是什麼(me)都(dōu)搞不清楚。

要知道(dào)，架構師并不是“框架和解決方案推廣落地人員”，他是需要做決策的，軟件開(kāi)發(fā)中，架構決策對(duì)系統的影響往往是至關重要的，一旦出現問題，後(hòu)果可能(néng)相當嚴重。所以，合格的架構師對(duì)于微服務，不但需要了解現成(chéng)的方案和概念，更應該真正的問題是什麼(me)，決策的依據是什麼(me)，然後(hòu)才能(néng)知道(dào)，自己的決策是否合理。

在我看來，微服務對(duì)SOA既是延續也是更新。在我們談論SOA的時(shí)候，談得更多的是一種(zhǒng)設計理念，它要求脫離軟件本身的限制，從抽象的“服務”角度來進(jìn)行思考和設計。從此，我們可以在更高更抽象的層面(miàn)上來思考如何用軟件解決問題，不再時(shí)時(shí)處處受到技術的掣肘。然而，SOA談論了多年，一直沒(méi)有看到具體的、公認的、合理的落地案例。

許多談SOA的書裡(lǐ)都(dōu)會(huì)講到一個概念：ESB。希望有一天，軟件服務也可以像硬件服務那樣，有一條通用的總線，然後(hòu)各種(zhǒng)服務隻需要簡單接入就(jiù)可以了。但是這(zhè)或許隻是一個美麗的夢想，真正投入使用的ESB其實相當少。

微服務的興起(qǐ)，很大程度上對(duì)應著(zhe)我們在探索未知領域、探索未知問題的腳步。我們無法全知全能(néng)地知道(dào)，系統的什麼(me)部分、哪個環節，在什麼(me)時(shí)候會(huì)成(chéng)爲障礙或瓶頸，但是，我們又必須迅速地發(fā)現這(zhè)些障礙或瓶頸，解決它們，同時(shí)保證整個系統的穩定。把系統拆分爲一個個微服務，正是爲了解決這(zhè)樣的問題，它讓我們可以聚焦在具體部分和環節上，又限制了複雜性，避免了“牽一發(fā)而動全身”的尴尬。

仔細思考就(jiù)會(huì)發(fā)現，微服務的興起(qǐ)，也是對(duì)ESB思路的颠覆。ESB強調的是“重通訊輕終端”，微服務強調的則是“重終端輕通訊”，數據通訊一般隻是通過(guò)簡單的HTTP進(jìn)行，終端對(duì)于通訊總線并沒(méi)有特别強的業務依賴。這(zhè)樣确實降低了耦合性，但也對(duì)終端提出了更高的要求。

以前大家隻習慣于寫一點業務邏輯代碼，生成(chéng)幾個類庫，放到巨大的單體系統裡(lǐ)就(jiù)可以放心了。進(jìn)行微服務改造之後(hòu)，你的這(zhè)點業務邏輯代碼隻是服務的核心，既然名曰“服務”，就(jiù)得五髒俱全，既然名曰“微服務”，就(jiù)得螺蛳殼裡(lǐ)做道(dào)場。

換句話說(shuō)，服務必須能(néng)獨立部署、獨立維護、方便擴展。你得在服務的邊界清晰和技術限制之間做出權衡，你得搭建完整的監控，你得考慮高可用性，你得選擇通訊機制，你得分析負載壓力，你還(hái)得仔細規劃容量……身爲架構師，一門心思考慮分家，一味鼓吹分家的各種(zhǒng)好(hǎo)處，絕對(duì)是不稱職的：分家過(guò)日子當然潇灑，但自己當家卻不知道(dào)柴米油鹽貴，這(zhè)是絕對(duì)要餓死的。

最後(hòu)講個有意思的事(shì)情，這(zhè)些年我有好(hǎo)幾個技術很好(hǎo)對(duì)微服務理解很深刻的朋友，去了創業公司首先做的事(shì)情往往都(dōu)是“技術的倒退”：就(jiù)這(zhè)十來個人、七八條槍，還(hái)折騰什麼(me)微服務？快别扯淡了！

附：原文鏈接
The Unbunlding of Excel
You are not Google