從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進行，終端對于通訊總線并沒有特別強的業務依賴。這樣確實降低了耦合性，但也對終端提出了更高的要求。
以前大家只習慣于寫一點業務邏輯代碼，生成幾個類庫，放到巨大的單體系統里就可以放心了。進行微服務改造之后，你的這點業務邏輯代碼只是服務的核心，既然名曰“服務”，就得五臟俱全，既然名曰“微服務”，就得螺螄殼里做道場。
換句話說，服務必須能獨立部署、獨立維護、方便擴展。你得在服務的邊界清晰和技術限制之間做出權衡，你得搭建完整的監控，你得考慮高可用性，你得選擇通訊機制，你得分析負載壓力，你還得仔細規劃容量……身為架構師，一門心思考慮分家，一味鼓吹分家的各種好處，絕對是不稱職的：分家過日子當然瀟灑，但自己當家卻不知道柴米油鹽貴，這是絕對要餓死的。
最后講個有意思的事情，這些年我有好幾個技術很好對微服務理解很深刻的朋友，去了創業公司首先做的事情往往都是“技術的倒退”：就這十來個人、七八條槍，還折騰什么微服務？快別扯淡了！
留言列表
