不要迷信微服务，微服务就是个传说

**
自微服务架构兴起以来，它已经被大大小小的科技公司所采用。但是，这些公司真的达到了期望吗，微服务的表现真的比以前的架构更优秀吗，微服务真的无所不能吗？在这篇文章中，我将尽可能地揭示微服务的本质，来客观地看待微服务，了解它的作用和局限，不要被“乱花”迷了眼。

申明一下，我仅仅是一个工作时间较长的技术人员，不敢自诩为“架构师”，当然，也不屑于冒充“架构师”。但我曾主持过几个微服务架构的产品设计，也见证过几个朋友在转型“微服务”时的欢乐，当然，更多的是沮丧，有的甚至陷入了泥潭。基于所见、所闻、所历，从而有所感悟，一家之言，信疑由己。

一、微服务是一项很伟大的技术，它能引领公司走向成功？

谁说的？来来来，看我不打死你！我猜这一定是所谓的“咨询师”、“分析师”、或“讲师”，用来忽悠非专业人士的。

微服务只是分布式架构发展的一个阶段，从软件业的发展历史来看，它远没有C/S架构（客户机-服务器架构，划时代的）、SOA（Service Oriented Architecture，面向服务的架构，革命性的）等的历史地位高。

微服务是SOA的一个分支，其核心思想继承自SOA，但SOA的巅峰期与ERP软件的发展相重合，更多地应用于企业管理软件，不为大众所熟知，而微服务的诞生正值互联网发展到巅峰的时段，伴随着互联网的成功而广为人知，以至于很多不明真相的吃瓜群众把这些互联网公司的成功归功于微服务。
殊不知，阿里、腾讯、百度，乃至Google、微软件等公司，在其关键的发展期，微服务还没有诞生呢，淘宝第一次双十一（2009年），还没有微服务的影子呢，QQ的用户突破1亿时，离微服务的诞生还有4年，百度市值在达到中国第一时，微服务还处于启蒙状态。这充分说明了，微服务绝非成功的关键因素，更不可能是决定因素，它顶多起到了“锦上添花”的作用。

一个公司的成功是由其产品的价值决定的，绝非技术，至于微服务，对公司成功的贡献率绝对不会超过5%。客观地说，微服务确实有它的价值所在，但也要看到，它起的作用主要是战术上的，而非战略上的。它也有着相应的局限和使用场景，不能盲目地使用，要结合自身的业务和产品特色来使用它。

决策者也无须为微服务而烦恼，如果你的开发人员少于100人，或者活跃用户数低于1000万，你根本无须考虑微服务，你应该更多地关注市场和客户，相信我，即使你现在花了很大代价精心设计了很多微服务（这就是俗称的技术过剩），在你的规模扩大以后你依然需要重新设计。

你也无须担心将来向微服务转型有很大的成本，只要你的软件遵从了“组件化”、“平台化”、“SOA”等思想，微服务的改造就会比较顺利，至少技术方面不会有太大代价，主要的工作量来自应用的整合和拆分。

二、微服务架构很难，需要聘请专业的人士来设计？

回答这个问题前，要区分“微服务架构”和“微服务”，“微服务架构”并不是很难，但在微服务架构下，设计出合理的“微服务”确实需要经验和能力。

前者是个纯技术问题，微服务架构已经形成了一定的模式，世界各地的工程师们也贡献了大量的开源框架，像Spring Cloud、Dubbo、Thrift、Redis、MQ等等，依赖这些框架和技术工具，一个有丰富经验的高级设计人员很快就能搭建出一套微服务架构的框架来，事实上，很多中小互联网公司的微服务架构搭建并没有花费多少时间，这些微服务架构也完全满足微服务的特征和要求。

但是，搭建好微服务架构就如同盖房子时盖好了框架，这只是第一步，更复杂的是，每个单元如何划分房间，每个房间承载什么功能，每个房间的家具家电如何布置，地板用什么类型的，墙壁是贴壁纸还是刷漆…。

也就是说，针对你的产品，哪些不使用微服务，哪些使用微服务，划分成多少个微服务，每个微服务做什么，不同的微服务之间如何协作，每个微服务又如何跟外部程序协作，这才是微服务的核心。这不是简单的技术问题，这其中90%的工作要依赖于你对客户、业务、产品的深刻理解，再对资源、成本、工期、运维等进行多方权衡后，才能够设计出合理的微服务来。

至于需要的人才，我相信大多数的CTO或者高级设计师都能轻松完成微服务架构的设计和搭建。你最需要的应该是两类人才，一类是纯技术的，熟练掌握相应的技术栈，如HFS、Zookeeper、Docker、Restful等，能够进行开发层面的落地；另一类是懂业务的设计人员，对客户、业务场景、产品功能等了如指掌，这样才能设计出合理的微服务。

三、所有产品都要微服务化？

这肯定是半懂不懂的“砖家“们说的，真正有经验的CTO肯定会嗤之以鼻，当然，真正的大佬都很忙，没时间听他们瞎扯蛋，也只有我这种”闲人“看不下去，呵呵几声后，优雅地说一句：请你圆润的离开（GUN）。

微服务的核心价值是把不同产品中重复的模块独立出来，成为一个公共的服务，从而减少重复开发和维护。这也是为什么老师讲课时总喜欢拿“用户管理“、”支付管理“举例子，因为这两个模块用途最广、重复度最高。把它们变成标准的微服务后，购物可以用、游戏可以用、交易可以用、教育也可以用…。
你可曾听过老师拿“MRP“、”库存优化“、”运输排程“来举例，没有，因为，如果一个模块只在一个产品中使用，没有其他的产品使用，外部也用不到，那把它包装成微服务的意义是什么呢？总不能为了微服务而微服务吧！

正确的做法是，梳理你的所有产品、所有模块，抽离出那些重复率高的模块，这些模块是需要微服务化的。根据我的经验，这个比例通常不会超过20%，这是针对互联网产品而言的，对于某些企业级应用而言，甚至低于10%。至于其他模块，let be，原来是什么样，就还怎么样吧，别浪费那些个臭氧层次了，它不会有任何的问题。当然，如果您有强迫症，非得追求形式上的统一，也可以把这些模块变成“宏服务”，把它们对外的接口封装一下，变成Restful的，但没必要拆分得那么细，那么精致。

四、微服务要多“微”？

很多人会说，微服务要尽可能的小，越抽象越好，越标准越好。这种脱离了具体的应用场景、脱离了公司的资源、脱离了工期和成本的说法根本就是在耍流氓。

设计微服务时，最重要的工作是把所有产品中重复的模块独立出来并封装，在内部实现相关的业务逻辑，对外部提供相应的接口，并且可以独立部署，其他需要使用这个模块的产品都通过标准的接口访问，这个模块就可以称之为一个微服务。

不同的公司，不同的产品，其抽象出来的微服务是不同的，比如购物网站通常会把用户、商品、支付等封装成微服务，而管理软件则把存货档案、流程引擎、日志管理等封装成微服务。

微服务的大小（或者说边界）取决于业务逻辑的耦合度，一般而言，互联网公司由于业务逻辑较轻，因而可以拆分得细一些，每个微服务小一些，而管理软件由于内部业务逻辑的关联非常密切，就不能分得太小，否则，各个微服务之间存在业务上的交叉，就达不到微服务“独立性”的要求。

根据我的经验，一个成功的产品，通常是80%的宏服务加上20%的微服务，过于精细化的拆分会大大增加设计和管理的复杂度，在应对变化方面的效率反而下降了，最终会变得越来越混乱。

五、为什么转向微服务后，成本反而提高了？工期也变长了？

一点不奇怪，没有足够的规模来分摊额外的成本，总成本肯定是上升的。这也是为什么小公司通常是浅尝则止，而大公司总是大张其鼓的原因。

与传统设计方式相对，微服务要建立单独的工程，内部功能要尽可能地完整，还要考虑通用性、冗余性、扩展性、分布式事务一致性等一系列的问题，大大增加了设计工作量，相应的开发工作量、测试工作量、文档工作量、部署工作量、运维工作量都会随之增加，成本自然水涨船高。

还有一个不可忽视的原因，随着环节的增多，需要的协作大大增加了，这也无形中增加了成本和工期，在有的项目中，差劲的协作导致的成本增加可能比其他因素加起来都要多。

据估计，相同的系统，采用微服务比不采用微服务至少要增加50%_{200%的成本（如果是宏服务，则只有10%}30%的增加）。

这还是建立在一切都顺利的情况下，如果您把不应该设计成微服务的产品变成了微服务，或者是微服务本身的标准化程度不高，或者拆分的过细，这简单就是一场灾难，给企业造成的损失无法估计。而这种情况，每天都在发生着，发生的原因则非常可悲：无视公司所处的阶段和产品特点、盲目追求时髦、急功近利、过于重视理论而忽略了工程层面的问题、缺乏对需求的深刻理解、外行指挥内行！

综上，微服务是建立在规模效应之上的，当某个模块在很多个产品中都需要时，你可以把它设计成微服务，从而节约重复开发的成本，微服务也就具有了经济价值。当你的规模不够大时（参考前文所说的规模标准），一定要特别、特别地谨慎规划微服务的数量和颗粒度。当然，如果您是土豪，只要贵的，不要对的，可另当别论。

六、微服务降低了开发的复杂度？提高了开发效率？

理想很丰满，现实很骨干！当你想主宰生活时，生活总是反过来给你一记响亮的耳光！

上图来自Scott Rogowski所写的一篇文章。左侧是Uber设想的微服务架构图：简单、优雅、易于理解。右侧是Uber 实际的微服务地图。借用作者的一句评论：我敢说 Uber 的任何人都不知道这个架构是如何工作的！

使用微服务架构的大型公司的人都知道，Uber 的经验（或者更应该说教训）不是特例，而是一个普遍现象（悄悄说一句，Uber的一个团队正在把微服务改造成宏服务）。

这其中的重要原因在于，理论总是看上去很美好，但到了现实中，客户和市场总是在变化的，总有新的业务模式，总有新的没完没了的需求，你以为你可以设计很多永远不变的“微服务”，但实现上，过不了几天，客户和市场就会把你的梦想击碎，你的微服务不断地增加新的业务逻辑、新的接口、新的版本。很快，你初始状态的优美的架构会变得越来越丑陋，越来越臃肿，直到某一天，你忍受不下去了，进行了一次彻底的重建。然后，一切都变得美好了？…，当然不可能，你只是开始了一轮新的循环。

这就是软件行业的现状，不管是系统开发还是应用开发，不管是桌面开发还是移动开发，不管是ERP开发还是互联网开发，无不如是。自从软件业诞生以来，这种现象从未改变过，如果说改变过，那也是变得更糟糕！所以，你会发现，微软、Google、Oracle、亚马逊、阿里…等公司的开发人员总是在不断增加，不仅仅是因为新的产品，老的产品线也没有减人。

事物越是精巧，对技术、团队、管理的要求就越高，所以，不要盲从于理论家，更不要听那些半吊子的“专家”胡说八道，要依赖自己的技术团队和管理团队，找到适合自己的“度”！否则，很容易弄巧成拙，事与愿违，甚至自取灭亡！

至于开发速度的提高，有的时候确实会提高，在你需要用到的某个模块或功能恰好原来的某个微服务可以提供时，恭喜你，你可以直接调用即可，不用自己开发了。这种情况下你确实提高了开发效率。
这个技巧实际上在很多年前就开始普遍使用了，比如说开发人员都在使用的“类库”、“模板”、“框架”，比如说ERP厂商一直在使用的“公共模块”、“主数据“、“应用平台”，无不如此，只不过在以前，它们是以别的形态（SOA或别的）存在的，现在则变成了“微服务”的形态而已。

从这个角度看，开发效率的提高主要来自于“组件化”的思想，来自于公共功能的“抽象”与“封装”，微服务只是其中一个比较新的封装形态而已。这些“框架“、“服务“或”微服务“，一部分是由开源的厂商、组织、个人提供的，另外一部分则是由贵公司的公共技术部门提供的。

真正能提高开发效率的是你的基础能力，包括：合理的需求及需求变更、良好的设计、有效的测试、优秀的开发管理，以及价值观趋同、有能力、肯配合的团队！

七、我们应该一开始就设计出一个完美的微服务系统?

这个问题可以用Gall定律来回答：正常运作的复杂系统一定是从一个正常运作的简单系统演变而来的。从头开始设计的复杂系统永远无法正常工作，也无法靠打补丁来正常运作。你必须从一个简单系统起步。

只所以有种种误导，部分原因来自于大家对“最佳实践“的信任和盲从。随着阿里、京东、腾讯等互联网企业的成功，有很多的内部人、外部人总结出大量的”最佳实践“，这些最佳实践有的确实是干货，有的却是道听途说、人云亦云，还有的干脆另有目的，只是为了向你推销他们的云服务、培训、书籍，或者干脆兜售他们自己，以期吸引别人的投资或找到新的工作机会。

即使是那些正确的最佳实践，也只是别人的，是符合别人现在的市场地位、客户价值、产品形态、能力现状的，不见得适合你。这就如同组织架构，一个初创公司，一定是老板兼销售兼技术兼保安，老板娘任CHO兼CFO兼会计兼前台兼行政，难道你要学习上市公司，建立董事会、聘请独立董事、聘任CFO、CIO、CHO等专业岗位吗？

当你是个穷小子时，你可以学习亿万富翁的创业精神，但你没有赚到几个小目标时，你无法承担得起大宅、豪车、名酒、美人，你也无法自己出资拍电影，你无法像他们那样生活，你负担不起！你能做的是学习他们的为人之道、他们的客户之心、他们的坚忍不拔，他们的永不放弃！

不好意思，跑题了。不管怎样，我认为在某些情况下微服务是正确的选择，尤其是你是Google、SAP、Salesforce那样的企业，有着几百种产品、有着亿计的用户，你确实需要精心设计的微服务，你也有实力、有时间来做详细的规划和设计。但如果你不是，你更应该清醒地思考各种方案和假设，错误的决策可能会拖垮公司，还不如顺其自然来的好一些。

八、管理多个服务很容易？

如果你是产品经理，你就会发现，软件工程师的时间和其他人的时间不一样，当他对你说“我这个周末可以完成“、”还差一点点“、”这个很简单，只需要一个礼拜“时，你应该把这个时间乘上一个系数，系数的范围是2到无穷大。我猜，这可能就是相对论吧。

鼓吹微服务的人有着同样的乐观情绪，他们的钟总是走得比其他人的要慢很多。事实上，实践中总有两个问题等着你去解决：这样的问题、那样的问题。

你设计好了微服务的内部逻辑和外部接口，然后大家进行开发、测试，好不容易通过了，game over了？No，No，No，游戏刚开始，A调用者说缺了一个方法，B调用者说参数有问题，C调用者说希望你把结果再封装一下，D调用者说他是移动端，希望你精减返回值以减少网络传输…

测试人员成天抱怨，持续集成没有有效工作，总有人忘记提交代码，测试库的数据被人改动甚至清空了，阻塞型的BUG导致测试举步维艰，性能测试的资源不容易抢到，要测试的场景太多太多…

服务之间的依赖使得“独立部署“毫无意义，你在线上环境中发现的问题永远无法在测试环境中重现，前
端和后端总是在互相推卸责任，安全性和健壮性好像没有以前好了，由于服务间互相调用的影响，单一的性能改进没有反映到客户端…

系统好不容易运转起来了，在数据分析时发现还是不够，缺东少西，没办法，再重新回头，开发下一个迭代版本吧…

总结

在构建大型应用时，微服务确实是一种有效的模式，但是要谨慎地使用它，过度的细化设计会使你陷入进退维艰的境地。当你规模较小时，可以不使用微服务或者使用“微服务架构“+”宏服务“+“小部分微服务”，千万不要因为不可预知的未来在现在投入太多不必要的成本。

总而言之，不要过度迷信微服务，微服务就是个传说！