从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进行，终端对于通信总线并无特别强的业务依赖。这样确实下降了耦合性，但也对终端提出了更高的要求。

　　之前你们只习惯于写一点业务逻辑代码，生成几个类库，放到巨大的单体系统里就能够放心了。进行微服务改造以后，你的这点业务逻辑代码只是服务的核心，既然名曰“服务”，就得五脏俱全，既然名曰“微服务”，就得螺蛳壳里作道场。

　　换句话说，服务必须能独立部署、独立维护、方便扩展。你得在服务的边界清晰和技术限制之间作出权衡，你得搭建完整的监控，你得考虑高可用性，你得选择通信机制，你得分析负载压力，你还得仔细规划容量……身为架构师，

一门心思考虑分家，一味鼓吹分家的各类好处，绝对是不称职的：分家过日子固然潇洒，但本身当家殊不知道柴米油盐贵，这是绝对要饿死的。

　　最后讲个有意思的事情，这些年我有好几个技术很好对微服务理解很深入的朋友，去了创业公司首先作的事情每每都是“技术的倒退”：就这十来我的、七八条枪，还折腾什么微服务？快别扯淡了！