從Excel 到微服務

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

　　上個月看了篇文章，The Unbunlding of Excel。做者認爲，對於初創公司（尤爲是非「純IT」初創公司）來講，Excel幾乎包辦各類工做。想要計算？請用Excel。想作輕量級的CRM，可用Excel。創建財務分析模型？仍是用Excel。簡單的項目管理？固然Excel。數據分析總攬圖？仍然是Excel。執行簡單的ETL任務？Excel再合適不過了。

　　Excel真的這麼能幹嘛？從邏輯上說，它是成立的。首先公司裏不少業務都是基於數據的，其原型都是對錶格的操做，Excel「天生」就是表格。其次，Excel提供了足夠弱又足夠強的「編程能力」，Excel中的VBA、透視表等等功能對於強大的編程語言來講或許不值一提，但許多對編程語言望而卻步的人卻能把這些功能運用得無比純熟，玩出的花樣讓不少程序員也歎爲觀止。

　　更重要的是，初創公司的業務每每是不肯定的，業務領域須要探索，業務規則也須要不斷修訂。Excel雖然沒有量身定製的系統那麼完善，但成本至關低廉。對初創公司來講，除非本身養着很是厲害的開發團隊，系統又作得足夠高質量足夠靈活，一面猛改一面還保持穩定，不然即使「上系統」，也常常被系統困住手腳，業務反而受到拖累。

　　若是你以爲這只是「邏輯上」的分析，我還能夠給出更現實的例子。

　　現在不少公司都知道要有CRM（客戶關係管理）系統，來處理和彙總與客戶之間的問題。業務還沒開展，CRM先得買一套或者開發一套，這已經成了流行的思惟定勢。可是，買來或者開發的CRM，未必能很好知足本身的業務需求，所以踩坑的例子數不勝數。

　　朋友的一家公司，一開始根本沒有上CRM，只要求客服每人天天用Excel把回答的問題記下來，天天晚上指定專人彙總，次日早上把彙總和更新以後最新的Excel經過郵件下發給全部客服，回答問題的時候就在這張表裏用Ctrl+F來尋找關鍵詞。這樣的作法雖然看起來很累很煩，卻足夠簡單有效。既不用擔憂系統死掉你們都幹不了活，也不用擔憂問題分類設定不合理沒法錄入或者數據格式變化致使的歷史數據清洗成本。

　　等這套流程真正跑順穩定了，公司業務也足夠大了，有時間有資本把已經摸索的客服管理的經驗和流程固化到系統裏，CRM系統開發瓜熟蒂落，上線到投入使用至關天然。

　　我還見過一家電商公司，由於遇上了風口，業務發展極其迅猛。因而公司也立刻遇到了問題，創始人都是作互聯網的出身，對實業並無多麼豐富的經驗，多地倉庫的管理成了老大難，庫存常常亂套了。

　　怎麼辦？雖然本身有一支小的開發團隊，但平常業務已經足夠他們忙的了，並且倉儲是個專門的領域，即使沒作過，專門去看看也知道水很深，況且倉庫運營的規則和辦法還在不斷優化，這時候要作出一套好用的倉儲系統，幾乎是癡人說夢。然而每次出問題，不少基層員工都會抱怨，要是有系統就行了。

　　創始團隊想到的辦法就是Excel，無論倉儲規則怎麼變幻無窮，基本的庫存管理，無非是入庫、出庫、盤庫等幾個動做，數據格式是相對固定的。那麼，每一個倉庫天天干完活，再忙再累再晚，也要把倉儲信息按照約定的Excel模版回傳到總部，由專人統計合併。這工做提及來簡單，作起來可以讓人叫苦不迭，尤爲是還有些倉庫分佈在海外有時差，天天光是統計合併這些數據就得一兩天。

　　既然老大發了話，下面的人有抱怨也不敢發出來，只能老老實實執行。整套流程兩三個禮拜，平常的操做基本都不會出問題，要完善操做流程時，也大概知道了該怎麼修改表格。就這樣邊錄邊改，磨合了大半年，終於把流程基本定下來了。這時候再安排產品經理、項目經理、程序員進場，一看平常用的Excel，數據項、數據項之間的關聯清清楚楚，不清楚的地方問問操做人員也馬上能夠獲得解答。這時候再安排開發倉儲管理系統，基本不存在什麼領域知識難題，更像是順水推舟的事情。

　　仔細觀察這兩個例子，你會發現，它們的本質是同樣的，即在對問題域還不夠了解、問題解法尚未完全明晰以前，須要一種具備必定規範性同時低成本的手段，一方面對現有操做進行約束，另外一方面能持續探索問題、完善已有方案。這時候，他們選擇了Excel。

　　原本我看完這篇講Excel的文章就準備談點感想，巧合的是，後來又看到一篇「神似」的文章，You are not Google。做者強調的是，別盲目崇拜那些大公司吹得神乎其神的技術，真正重要的是理解你的問題。這個主旨，和上面文章裏對Excel的「吹捧「實際上是一致的。

　　你知道GFS和Map/Reduce，可是你知道它們是爲了解決什麼問題的嗎？是爲了計算、存儲、索引全部的網頁（那個時候大概有8000萬）。你知道SOA，可是你知道亞馬遜何時上的SOA嗎？那時候亞馬遜已經有7800名僱員，年營業額超過30億美圓了。你只知道數據庫集羣、NoSQL，可是你知道嗎？StackExchange在2016年，面對2億的日訪問量，只有4臺SQLServer……

　　好了，如今我要回到題目，提及「微服務」了。

　　微服務很新，微服務很潮，微服務很高大上。我在面試架構師的時候，不少候選人說到微服務，均可以侃侃而談，各類新鮮的名詞、概念、框架止不住地蹦出來，卻無法回答幾個問題：爲何微服務會崛起？何時應當實行微服務？實行微服務要注意什麼？甚至，連微服務與SOA的關係是什麼都搞不清楚。

　　要知道，架構師並非「框架和解決方案推廣落地人員」，他是須要作決策的，軟件開發中，架構決策對系統的影響每每是相當重要的，一旦出現問題，後果可能至關嚴重。因此，合格的架構師對於微服務，不但須要了解現成的方案和概念，更應該真正的問題是什麼，決策的依據是什麼，而後才能知道，本身的決策是否合理。

　　在我看來，微服務對SOA既是延續也是更新。在咱們談論SOA的時候，談得更多的是一種設計理念，它要求脫離軟件自己的限制，從抽象的「服務」角度來進行思考和設計。今後，咱們能夠在更高更抽象的層面上來思考如何用軟件解決問題，再也不時時到處受到技術的掣肘。然而，SOA談論了多年，一直沒有看到具體的、公認的、合理的落地案例。

　　許多談SOA的書裏都會講到一個概念：ESB。但願有一天，軟件服務也能夠像硬件服務那樣，有一條通用的總線，而後各類服務只須要簡單接入就能夠了。可是這或許只是一個美麗的夢想，真正投入使用的ESB其實至關少。

　　微服務的興起，很大程度上對應着咱們在探索未知領域、探索未知問題的腳步。咱們沒法全知全能地知道，系統的什麼部分、哪一個環節，在何時會成爲障礙或瓶頸，可是，咱們又必須迅速地發現這些障礙或瓶頸，解決它們，同時保證整個系統的穩定。把系統拆分爲一個個微服務，正是爲了解決這樣的問題，它讓咱們能夠聚焦在具體部分和環節上，又限制了複雜性，避免了「牽一髮而動全身」的尷尬。

　　仔細思考就會發現，微服務的興起，也是對ESB思路的顛覆。ESB強調的是「重通信輕終端」，微服務強調的則是「重終端輕通信」，數據通信通常只是經過簡單的HTTP進行，終端對於通信總線並無特別強的業務依賴。這樣確實下降了耦合性，但也對終端提出了更高的要求。

　　之前你們只習慣於寫一點業務邏輯代碼，生成幾個類庫，放到巨大的單體系統裏就能夠放心了。進行微服務改造以後，你的這點業務邏輯代碼只是服務的核心，既然名曰「服務」，就得五臟俱全，既然名曰「微服務」，就得螺螄殼裏作道場。

　　換句話說，服務必須能獨立部署、獨立維護、方便擴展。你得在服務的邊界清晰和技術限制之間作出權衡，你得搭建完整的監控，你得考慮高可用性，你得選擇通信機制，你得分析負載壓力，你還得仔細規劃容量……身爲架構師，

一門心思考慮分家，一味鼓吹分家的各類好處，絕對是不稱職的：分家過日子固然瀟灑，但本身當家殊不知道柴米油鹽貴，這是絕對要餓死的。

　　最後講個有意思的事情，這些年我有好幾個技術很好對微服務理解很深入的朋友，去了創業公司首先作的事情每每都是「技術的倒退」：就這十來我的、七八條槍，還折騰什麼微服務？快別扯淡了！