从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进行，终端对于通讯总线并没有特别强的业务依赖。这样确实降低了耦合性，但也对终端提出了更高的要求。
以前大家只习惯于写一点业务逻辑代码，生成几个类库，放到巨大的单体系统里就可以放心了。进行微服务改造之后，你的这点业务逻辑代码只是服务的核心，既然名曰“服务”，就得五脏俱全，既然名曰“微服务”，就得螺蛳壳里做道场。
换句话说，服务必须能独立部署、独立维护、方便扩展。你得在服务的边界清晰和技术限制之间做出权衡，你得搭建完整的监控，你得考虑高可用性，你得选择通讯机制，你得分析负载压力，你还得仔细规划容量……身为架构师，一门心思考虑分家，一味鼓吹分家的各种好处，绝对是不称职的：分家过日子当然潇洒，但自己当家却不知道柴米油盐贵，这是绝对要饿死的。
最后讲个有意思的事情，这些年我有好几个技术很好对微服务理解很深刻的朋友，去了创业公司首先做的事情往往都是“技术的倒退”：就这十来个人、七八条枪，还折腾什么微服务？快别扯淡了！
