受宠的微服务火了这么多年，没想到被一个不懂软件研发的马斯克戳破了越来越膨胀的气球。
马斯克的话有没有道理？
我对Twitter内部的架构不了解，没有发言权，但我觉得大概率是对的，很有可能微服务在Twitter已经被滥用了。至于他说的20%微服务有价值，呵呵，这压根儿就是马斯克拍脑袋随意给出来的，哪有什么科学依据！大概还是80/20原则在作祟吧。
马斯克此言一出，一石激起千层浪，最高兴的大约就是曾经“喷”过微服务的人了吧。
我不知道他喷微服务的观点是什么。可一个“喷”字体现批斗精神，让我心里不爽。
任何技术必有双面性。我们对比单体和微服务，就会发现单体的优势恰是微服务之劣势，而微服务之优势又恰是单体之劣势，哪有绝对正确、绝对优势的技术存在？还是咨询师爱说的一句话——看情况嘛！在技术决策中，哪里需要彼之仇寇我之英雄呢？
也有人间清醒，例如：
归根结底，微服务只是一种架构模式，有它适用之处，自然就有它不适用的场景。这几年，国内的IT公司对微服务确实到了迷信的地步。
最可笑的是不懂技术的领导们非要跳进来刷自己的存在感。我曾经看到一份某政府部门的采购文件，针对某环保软件系统，采购文件明确要求软件必须采用微服务。我看了就笑了。一个地区级的环保平台，并发量不高，业务也不复杂，采购居然要求必须是微服务架构。这不就是为了微服务而微服务吗？
我的一位客户曾经求教我，他的甲方要求他们必须将原来的单体架构改为微服务，而该单体已经开发多年，运行也是稳定的，根本没有必要微服务，问我该怎么办？我说，既然不需要微服务，你又无法说服甲方，那就把整个单体运行在Spring Cloud之上，象征性地拆出一两个服务，不就可以交差了！——你以为那些领导真的懂微服务吗？可能在他们心目中，微服务就等于Spring Cloud，就等于Dubbo吧！
正如《人月神话》的作者Brooks所说，软件没有银弹！然而现实却是，只要一个概念火了，就一定会大行其道，以为它就是银弹。——哪有什么银弹！
我在编写应用现代化白皮书的时候，用了“开放能力”一词作为架构的基本单元。没有使用微服务，就是不希望在设计之初就绑定在具体的架构模式上。我在白皮书中写道：
开放能力作为一个自治单元，组成了应用架构最基本的架构元素。
能力化的好处在于它一方面遵循了软件设计原则，体现了“以应用为中心“的应用现代化设计理念，另一方面又因为它的抽象性，使得它的物理粒度并未确定，从而可以延迟技术决策，保证了技术架构的开放性，使其能够灵活地应对敏态业务的变化需求。
软件设计没有非此即彼的选项。难道除了单体，就只有微服务可选吗？我们也可以根据不同需要设计为宏服务（macro service），设计为迷你服务（mini service），甚至设计为纳米服务（nano service = function）。
现在，微服务被马斯克这么一怼，我又产生另外一个担心：微服务会不会成为过街老鼠，大家一拥而上，又开始去微服务化了？
这让我不得不想到曾经名噪一时的“中台”。最红火的时候，各种中台会议、中台书籍如雨后春笋，许多企业蜂拥而至，纷纷开始企业内部的中台化。
我有一家客户是某行业的大型集团公司，几年前，他们就雄赳赳气昂昂地说要上中台。我说：你们所有的IT系统都不是自己开发的，IT系统的供应商就有几十家，还有一两家牛逼哄哄的供应商，连系统产生的数据都不提供给你，你怎么搞中台啊？
随着阿里开始淡化中台这个词儿之后，又有不少企业跟风，开始去中台化了，如这位哥们所说：
可中台真的就是坑人的吗？
有一次，我在了解某企业内部的IT生态时，团队给我描绘的一幅蓝图，就是典型的烟囱（竖井）系统。这就是缺乏企业级战略规划的产物，IT研发团队与外包团队被分为每个项目组，项目组与烟囱系统一一对应。
该如何解决这个问题呢？我脑海中首先浮现出来的词语，就是中台——通过对整个企业进行战略规划，然后以中台建设思维，识别和定义可复用的业务能力，在其上，则以应用为中心，通过对业务能力进行编排或组合，快速打造小前台满足应用场景的需求。请问，这一设计思想有什么错？
显然，错的不是中台，错的不是微服务，错的是做出技术决策的人，错的是不懂技术却为了盲目跟风的决策层领导！
