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，但是你知道吗？Stack Exchange在2016年，面对2亿的日访问量，只有4台SQLServer……
好了，现在我要回到题目，说起“微服务”了。
微服务很新，微服务很潮，微服务很高大上。我在面试架构师的时候，很多候选人说到微服务，都可以侃侃而谈，各种新鲜的名词、概念、框架止不住地蹦出来，却没法回答几个问题：为什么微服务会崛起？什么时候应当实行微服务？实行微服务要注意什么？甚至，连微服务与SOA的关系是什么都搞不清楚。
要知道，架构师并不是“框架和解决方案推广落地人员”，他是需要做决策的，软件开发中，架构决策对系统的影响往往是至关重要的，一旦出现问题，后果可能相当严重。所以，合格的架构师对于微服务，不但需要了解现成的方案和概念，更应该真正的问题是什么，决策的依据是什么，然后才能知道，自己的决策是否合理。
在我看来，微服务对SOA既是延续也是更新。在我们谈论SOA的时候，谈得更多的是一种设计理念，它要求脱离软件本身的限制，从抽象的“服务”角度来进行思考和设计。从此，我们可以在更高更抽象的层面上来思考如何用软件解决问题，不再时时处处受到技术的掣肘。然而，SOA谈论了多年，一直没有看到具体的、公认的、合理的落地案例。
许多谈SOA的书里都会讲到一个概念：ESB。希望有一天，软件服务也可以像硬件服务那样，有一条通用的总线，然后各种服务只需要简单接入就可以了。但是这或许只是一个美丽的梦想，真正投入使用的ESB其实相当少。
微服务的兴起，很大程度上对应着我们在探索未知领域、探索未知问题脚步。我们无法全知全能地知道，系统的什么部分、哪个环节，在什么时候会成为障碍或瓶颈，但是，我们又必须迅速地发现这些障碍或瓶颈，解决它们，同时保证整个系统的稳定。把系统拆分为一个个微服务，正是为了解决这样的问题，它让我们可以聚焦在具体部分和环节上，又限制了复杂性，避免了“牵一发而动全身”的尴尬。
仔细思考就会发现，微服务的兴起，也是对ESB思路的颠覆。ESB强调的是“重通讯轻终端”，微服务强调的则是“重终端轻通讯”，数据通讯一般只是通过简单的HTTP进行，终端对于通讯总线并没有特别强的业务依赖。这样确实降低了耦合性，但也对终端提出了更高的要求。
以前大家只习惯于写一点业务逻辑代码，生成几个类库，放到巨大的单体系统里就可以放心了。进行微服务改造之后，你的这点业务逻辑代码只是服务的核心，既然名曰“服务”，就得五脏俱全，既然名曰“微服务”，就得螺蛳壳里做道场。
换句话说，服务必须能独立部署、独立维护、方便扩展。你得在服务的边界清晰和技术限制之间做出权衡，你得搭建完整的监控，你得考虑高可用性，你得选择通讯机制，你得分析负载压力，你还得仔细规划容量…… 身为架构师，一门心思考虑分家，一味鼓吹分家的各种好处，绝对是不称职的：分家过日子当然潇洒，但自己当家却不知道柴米油盐贵，这是绝对要饿死的。
最后讲个有意思的事情，这些年我有好几个技术很好对微服务理解很深刻的朋友，去了创业公司首先做的事情往往都是“技术的倒退”：就这十来个人、七八条枪，还折腾什么微服务？快别扯淡了！
附：原文链接
The Unbunlding of Excel
You are not Google
From Life Sailor, post 从Excel到微服务
家长应当和儿童，尤其是低龄儿童谈论“空气动力学”吗？ 我的答案曾经是非常肯定的：不应当。不要说儿童，就是成年人也不见得理解这些抽象的概念，与儿童谈论这些名词，只会让人望而生畏。身为父母，我们应当做的是，以孩子能理解的、感兴趣的方式谈论相关的具体问题，但绝对不要提这些大词。 不过世界的奇妙就在于，父母对教育并没有绝对的权威，总是需要根据实际情况来修正自己的观点。在“空气动力学”的问题上，我就吃到了教训。 那是一个下午，家里小朋友在iPad上看完他最喜欢的Blippi（这个节目我之前介绍过，对80后父母来说，Blippi可以理解为“带你见识各种新鲜玩意的董浩叔叔”），忽然抬起头来问我：“爸爸，你知道什么是aerodynamics吗？” “什么？你问我知不知道什么是aerodynamics？”我的下巴都要掉下来了。“空气动力学”这种词还是上中学时，身为军迷的我们在《航空知识》上知道的。再往后英语好一些，能看原版科普视频了，才知道“空气动力学”的原文就是aerodynamics。可是，我家这个还没上小学的家伙，竟然就能真诚地瞪大眼睛，一本正经地问我“知不知道什么是aerodynamics”。 (more…)
我本来是不应该认识孟老师的。 2001年，我在寝室夜谈里第一次听到孟老师的名字。当时有同学说“公共选修课的《法学概论》讲得真好，那个老师叫孟繁超”，开始我不怎么在意，慢慢才发现这么说的人还不少。那个年月网上的资料正丰富，出版管制也不那么严格，刚进大学不久的我正自由自在地看得过瘾，心想“大学里的法学概论讲再好，能讲些什么，还不是教科书上老一套”，所以这种课，不听也罢。 但生活就在这么奇妙。那年冬天，有天中午我吃过饭正准备午睡，忽然有人敲门问“计算机系有位叫余晟的同学在这里吗？” 大中午的谁会来找我？我正好奇这个问题，门一推开就有同学喊“孟老师，孟老师来了”。 那是我第一次见到孟老师，中年人，国字脸，身材高大，打扮很精神，披在身后的深色大衣让我一下子想起电影里的斗篷。他笑眯眯地说“你是余晟？听同学说你搞电脑很厉害，我家的电脑坏了，想请你去看看。” (more…)
中国人大概都对历史有一些特别的偏好。对我们普通人来说，历史首先是文化的象征，一个人“懂历史”，基本等于这个人“有文化”；历史也是民族自豪感的来源，哪怕考古上仍然存在争议，但是“五千年文明”的说法是普通人都耳熟能详的。 不过等我长大之后才发现，这种偏好大概还有更深层次的原因，那就是历史看起来有种道德的意味，因为我们从小就熟悉“以史为鉴”的智慧，也熟悉各种“历史的选择”：每当我们对现实感到失望、困惑的时候，我们经常去历史——而不是先贤的智慧中——中寻找解答。找到曾经发生的类似的故事，就可以预言未来的结局。 于是乎，失望也好、困惑也罢，总归会有光明的未来，历史总会给我们支撑的信念。 我曾经很相信，熟谙历史是种智慧，而且是深层次的智慧。但是看得越多、经历得越多，我就越觉得，这很难称之为“智慧”。 为什么？ (more…)
“无人出租车要来了”。以百度“萝卜快跑”为代表的无人出租车，眼看就要在国内多个城市成规模运营。 熟悉IT的人都知道，IT的独特优势就在于“大规模扩展时边际成本极低”。在软件时代，微软开发的Windows，多卖一份的成本只是多刻录一张光盘而已。在无人驾驶时代，从10辆车到10万辆车的成本，也遵循同样的规律。换句话说，一旦模式“跑通”了，就可以迅速大规模铺开。无人出租车的大规模应用，也是“指日可待”了。 只不过，新技术这一次似乎没有那么激动人心，反而引起了很多争议——无人驾驶出租车大规模推广，会不会影响广大出租车、网约车车主的收入甚至生计？如果是，这样的技术进步，真的是我们所需要、所期待的吗？对于这个问题，不同的人有相差迥异的答案。 按照我的观察，许多人对此是相当乐观的。理由在于，“技术的每一次飞跃发展，虽然有阵痛，最终都创造了更多的新岗位”。既如此，无人出租车短期“看似”抢了许多人的饭碗，但也只是短期的“阵痛”而已。看看历史，纺织机的发明，蒸汽机的改良，汽车的诞生，无不证明了“阵痛说”的正确性。 坦白说，这种观点我是怀疑的。 (more…)
因为小朋友放暑假，近期带小朋友回国待了几个礼拜。最深的感受就是标题所说的：松弛一点，愉快一点。 我第一次突出意识到这点，是在上海下飞机乘地铁。当时我们乘的直梯就要关门，远远看见有个年轻小伙子跑过来，我连忙按住开门按钮，并招呼他”别着急，慢慢来“，等他进了轿厢才关门。本来我以为大家起码会打个招呼，露个笑脸，因为我已经习惯如此，但完全出乎我意料的是，他进来之后对我们完全视若不见，自顾自掏出手机，盯着看得入迷。 我继而发现，不管是在电梯里，站台上，还是车厢里，虽然四下里都是广播”请扶好站稳，抓好扶手，不要看手机“，但是似乎人人都盯着自己的手机。年轻人在打手机游戏，年纪大一点的在滑各种小视频，还有不少人在聊天软件里打字如飞……对着屏幕的表情都很生动，可是一旦抬起头来，似乎马上又换了个人。 后来又有一次，我乘地铁的时候，因为比较拥挤，一个小伙子倒退时踩了我一脚，他大概意识到了，很快把脚挪开，脸上闪过一丝不安，马上又恢复正常，我也没有计较。不幸的是，过了十来分钟，他又踩了我一脚，同样是先有一点不安，很快又恢复正常。 这次我忍不了了，于是我开口告诉他：“小伙子，你已经踩了我两脚了。” (more…)
前几天，国内朋友发来一条消息，原来是乌克兰F-16坠落，飞行员丧生的新闻。我本来以为他要讨论此事的真假和原委，他真正的问题却完全出乎我的意料： 新闻里说，飞行员叫阿列克谢·“月鱼”·梅斯，对应原文是Alexei “Moonfish” Mes，为什么会有人把“月鱼”写在自己的名字里，而且还打引号。 之前看新闻，乌克兰还有一个著名的飞行员叫安德烈·“果汁”·皮尔希科夫（Andrii “Juice” Pishchykov），怎么“果汁”也是正式的名字？ 未必Moonfish和Juice之类，还有什么特别的含义吗？…… 这堆问题看的我有点想笑，因为自己以前也很苦恼外国人的名字，只有在国外长期生活，才逐渐搞清楚这其中的名堂。所以，除了解答朋友的问题，我也把自己的解释写下来，搞清楚两个最不容易理解的点，就不会对外国人名有那么多问题了。 (more…)
View Comments