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到微服务
之前我写了一篇《坚持了两年之后，小朋友突然不想去打冰球了…》，本来是无心之作，没想到收到了很多留言，我自己也获益不少。 本来，我以为解决了小朋友的问题，此事就这样过去了。没想到的是，暑假过后，冰球训练重开，他又老调重弹：“我不去了，我不想打冰球了……”。 这可叫我如何是好？听到他嘟嘟囔囔说这一切的时候，我心里百感交集。 成年人的生活里总是有忙不完的事情，对应的，也希望一切井井有条、按部就班。因此，这样“意外”的变数，总是第一时间让人心生无奈和烦恼：天哪，怎么会这样呢？为什么会这样呢？ 不过，基于之前的经验，借鉴大家的留言，这次我显然更有心理准备一些，起码不会慌乱。 之前我写过，如果父母多阅读一些高质量的育儿专著，有助于把自己的期望水平“降”到合适的程度，就不会那么焦虑甚至抓狂。 (more…)
认识Michael很偶然，但我也很幸运，因为我见证了一个“打冰球的好孩子”的成长。 最早认识Michael是在冰球队的夏季体能训练上。那时候这群孩子还只有六岁左右，每次训练都是家长送来，在旁边观看陪伴，再接回家。但是，我很快发现有个孩子不一样，家长送他来就回家，他靠自己换好全身装备，训练完自己洗澡更衣，再由家长接回去。看起来，他好像完全没有其他孩子那种“害怕独处”的感觉。 于是我问他：“小朋友，你这么勇敢，你叫什么名字呀？” 他说：Michael。 我尝试复述他的名字，好几遍都不成功，因为我总听成“米歇”，最后他耐着性子慢慢说，我仔细听才发现最后还有个音节，嘴要更扁一点，舌头往上垫，才可以念出来，类似“米歇-厄尔”。其实这个名字写出来大家都认识，英文里读作“迈克尔”，无奈德语的发音规则很严格，字母i不会像英文那样有两种读音，结尾的el又一定要发音，所以就成了“米歇-埃尔”。 (more…)
偶然刷到一篇文章，说的是“贵族家长”群体给小朋友安排的活动：冰球、马术…… 我有点诧异，原来“冰球”也被贴上了“身份”的标签。想想自家小朋友的情况：赶上打折花了400多欧元买的全套护具，80元买的二手冰球包，每个月60欧元的俱乐部费用……想了想，似乎很难和“贵族”联系起来。 只不过，他已经坚持打冰球到了第四年，我们的生活确实有不小的变化。写下来，既是对自己有个交代，也可以作为“贵族运动”的现身说法。因为在我看来，如果非要说它是“贵族”运动，也只能“贵”在高（时间）投入、高产出而已。细细想来，我们的生活，已经被冰球深深的影响了。 (more…)
一 很多人关心，我们父子给M写了道歉信之后，对方是否有回应。 答案是：到目前为止，还没有任何回应。不过比较特殊的是，写完信之后德国小学就开始放秋假，学生不用去学校，既然见不到，也就不可能收到任何回应。 老实说，我觉得对方父母是有点反应过度的。这些年我的一条深刻经验是，如果出现分歧、矛盾，越早、在越低的层面直接面对，就越容易解决。许多小的矛盾之所以越闹越大甚至无法收场，往往都是经过了很多演绎、传话，而没有在一开始就开诚布公地面对。 试想，如果自己的孩子收到写着“我要杀了你”的信件，哪怕一开始很惊慌甚至愤怒，但仔细想一想，毕竟还有很多信息是未知的——比如对方是谁，平时言行如何，为何要写这样的信…… 更好的办法或许是先去直接寻求这些问题的答案，而不是直接把信交给家长委员会，走“公事公办”的路子。 我当然承认，“公事公办”无可厚非，对方家长也有这样的权利——所谓权利，就是“有资格做对方不喜欢的事情，人家还拿你没办法”。既然有这样的权利，就需要尊重。 所以，“严于律己，宽于待人”的确是与人相处的重要法则：我不会选择这么做，但我能理解和尊重你这么做的权利。 也有人问，那将来你遇到M的父母，会不会紧张？ 答案是：不会。 (more…)
一 收到S老师邮件的时候，我刚刚胆战心惊地做完第一次德语技术分享，还在享受着同事们的鼓励。猛然间就收到一封邮件：“您的孩子在学校参与了一起性质严重的事件，您必须来学校面谈，请从以下时间段中选择……” 什么？“性质严重的事件”？我揉了揉眼睛，确认自己没有看错。再把这段文字贴到谷歌翻译里，确认自己没有理解错。 我没有看错，也没有理解错，就是“性质严重的事件”。好吧，既然“性质严重”，那谈话肯定是越早越好，最早的日期是第三天。我紧赶慢赶，回信确认了最早可能的谈话时间，虽然德国人通常都不期待能这么快收到回复。 去接他回来的路上，我发现他一切正常，完全看不出任何异样。于是，我也没有表现出任何异样，只是依照惯例，问他当天发生了什么，在学校开心不开心。 得到肯定的答复之后，我心生疑惑，看起来和“性质严重”完全不搭边。那会是什么事情呢？ 我又问他，有没有和同学吵架、打架，是不是被人欺负了不敢说。但是，答案全都是“没有”。 我满心怀疑，又按捺不住，直接问：“既然一切都挺好，为什么S老师给我发信，说让我来学校跟她谈话呢？”我担心“性质严重”会吓到他，故意隐去了这个词。 他的满面春风在那瞬间凝固了，喃喃低语道：“好吧，原来是那件事，我还以为她不会跟你说。” (more…)
在2024年之前，我从来没想过自己有一天还可以加入乐团，甚至参加音乐会演奏。我只是个普通中年人，在之前文章里说过，上世纪八十年代随大流弹了十年手风琴，考过六级（当时最高八级）之后就彻底放弃了。直到二十多年后，在上海工作时才重新开始弹琴，当时有幸跟夏老师学了两年，打开了感官，懂得了音乐的世界远远比考级要广阔和美妙。再往后，就是自己看Youtube学习了一些乐理知识。因为德国几乎每个城市都有很多音乐学校，2023年末，我给本市的音乐学校写信，询问是否可以参加手风琴课程。通过回信我才知道，原来不只是“每个城市都有很多音乐学校”，而且“每个城市都有很多乐团”，哪怕是手风琴乐团。就这样，阴差阳错的，2024年初，经过简单的试奏，我加入了本市的手风琴乐团。虽然我是乐团新人，仍然有很多要学习的，但是一年下来，确实有不少感受。如果读者朋友也对音乐感兴趣，或者想让孩子学习音乐，也许我的感受可以提供一些参考。 (more…)
View Comments