微服务是"银弹"吗？

前言：所谓"银弹",本意是用金属银做成的子弹；在古老的传说里它是杀死狼人的有效武器。在著作《人月神话》也有描述。微服务是当前软件界流行的名词，那么它能成为像银弹一样厉害的武器，解决软件开发过程中的难题吗？本文将围绕这个主题进行论述。一家之言，纯属个人感悟，仅此而已。

微服务是什么？

无论你使用Google或者Baidu，都无法找到一个准确的定义。事实上，在业界还是在学术界，也没有对微服务下个准确而权威的定义。微服务到底是什么？至今为此，我们仍然很迷惑，但是作为深陷其中的我们，不会因为它的神秘色彩，而放弃对它的探索，用一个流行的词来说，盘它！

微服务看上去像女神一样骄傲，神秘又高不可攀，可是我们可以通过一些基本面来了解它。首先看字面意思，微代表小，再加些形容词，价值小，小而精，小而细等等，但不要把它和小朋友的小联系起来。这里的"小"代表的是独立，自我完善，而且是浓缩的精华；再看"服务"二字，代表着你能获得的某种结果。连起来说，微服务就是低成本获取某种结果的东西。

举个例子来说，你入住酒店，需要凌晨4点有人叫你起床，早上4:20有人陪你晨跑，早上6:00有人陪你吃早餐，你可能还需要有人帮你叫车…不胜枚举。那么叫你起床，陪你跑步，帮你叫车，这些就可以叫做微服务；这些微服务组合起来，就构成了你作为一个进步青年早上的生活场景，它解决了你在早上这段时间所需要得到的辅助。只是在现实生活中这些服务都是由人提供的。

让我们把思维切换到软件的世界，在软件的世界里，微服务长什么样子呢？如果你现在要送一车货给销售商，那么你是否希望知道最近的仓库在哪里？最短的行车路线是什么？仓库是否有足够的储位等信息，甚至你还想知道最近的加油站在哪里？万一油不够了呢？同样的道理，查询仓库的位置，储位，获取最短的行车路线这些就是微服务，它们组合在一起，协助你漂亮的完成送货任务。不同的是，这些服务是由某个软件厂商提供给你使用的…

到此，微服务是什么？你明白了吗？

突然，一个入门不到一年的软件工程师对于以上的论述开始露出了鄙视的表情。但他是个很有礼貌的人，尽量压制自己的怒火之后，说到：对于你以上的论述我给60分吧，因为我没有发现如你所说的"微服务像女神一样骄傲，神秘而又高不可攀" ，她很普通呀，我随便写个送货系统，包括以上几个功能，对标你的服务，也是可以的啊？

我突然感到后背一股冷风，顿时让我清醒起来。确实！这是个非常好的质疑，暂且不论对错，我们继续，稍后来消除质疑。

微服务从哪里来？

再不上干货，那我离挨打只差0.1毫米了。那我们来说说微服务的诞生历史。为省篇幅，尽量简单说，如果要把每一段历史说清楚，那么请先泡壶茶，说它个三天三夜。

首先说单体应用(Monolithic App)，它由一个或一组特定的功能合成的系统。为了更好的可维护性，通常我们会采用原始的分层架构模式，即用表示层，业务逻辑层，数据访问层进行分而治之。现在开始回想，这种架构模式下，当需求变化后，是否有牵一发动全身的切肤之痛，你是否体验过呢？

基于组件(Component-based)的架构模式，正是历经了牵一发动全身的切肤之痛后，软件开发者作为以睿智著称的代表们发誓，绝不能在同一条阴沟里掉两次。于是将层次拆分为模块，让模块独立为组件，在组件之间进行调用和通信。当需求变化后，只需要修改某一个模块，不会影响其它模块。干得漂亮！有没有？的确，这解决了需求变化带来的修改问题。但是需求总是变化的。新的需求，需要你的系统与其它的系统进行对接，或者和原有系统进行整合，别的系统需要你的系统暴露接口，就是通常说的服务。就像握手一样，当别人伸出手时，你却手插在裤兜里，这样很不礼貌，也完不成握手这件事情。

面向服务的体系架构( SOA )，为了系统与系统之间能够愉快的握手，需要各自暴露服务，于是SOA应运而生，典型的SOA产品就是企业服务总线。似乎到此历史说完了。系统之间功能打通了，数据共享了。还需要微服务吗？

当然，也不当然需要使用微服务。取决于系统面临的规模，如果无法预估系统的并发用户数量，突然涌入，或者高峰时段的用户规模数，事先无法确认需要准备多少数量的服务器等场景，那么你需要采用微服务架构。

先总结一下，到此我们是在说微服务的历史吗？可以明确的说，我没有说微服务的历史，我说的是架构演变的历史。我感觉离挨打只差0.01毫米了。回过头去看，SOA中也提到了服务，从业界或者学术界也没有对SOA中的服务下定义，从业界的实践来看，可以认为它是一种大颗粒的服务。这种大颗粒带来服务拆分的困难，比如前文提到的查询是否有足够的储位，而服务加载的却是整个仓库管理系统。为了避免这种大而全的服务，特意提出微服务的概念，除了强调小而精，还在于强调要告别依赖于动态链接库的时代，转向为依赖于服务的新风向。

随着微服务的提出，相应的也产生了新的名词，比如微服务架构，微服务框架等，持续集成，持续发布，持续运维，微服务治理，容器，微服务编排，等等词汇也被提到了新的高度；同时，在云计算如火如荼的当下，如何去使用云计算的海量计算资源，系统如何应对海量用户的突发访问而不宕机，是微服务架构诞生的起因。而微服务框架则是微服务架构模式下一种具体的服务提供方式。

到目前为止，可以回答那位工程师的质疑，我认为你说对了一半，单从提供功能来说，微服务能提供的，和传统方式没有区别。但是在应对海量计算资源，海量用户的场景下，微服务具有天然的优势。

那么回到本文的主题，微服务是银弹吗？值得注意的是，标题中提及的微服务并不是狭义的服务，而是涵盖前文提及的一系列相关的概念。

再说点干货

软件产品的本质是解决各种需求问题，使得产品能卖的出去，增加销售额。软件开发的本质是解决低成本制造产品的问题，降低损耗的费用。如何低成本制作产品，需要优秀的系统设计，优秀的系统设计需要高内聚，低耦合的思想。分享潘加宇老师总结的一个公式：

利润=需求-设计

简单来看要使得利润越高，那么需要需求越多，设计越少。但是很遗憾，需求越多，越需要优秀的设计，越需要高内聚低耦合的思想辅助。越优秀的设计越花时间和精力，这是内功的修炼。好比北京奥运的会徽，舞动的北京一样，多达几十个GB的样稿资料才最终设计而成。

微服务的设计对比舞动的北京也是有异曲同工之处。到此，微服务是否能成为银弹？不在于微服务本身，而在于以下三个必备条件：

首先，是人的维度，微服务需要优秀的人才，如优秀的产品经理，优秀的需求工程师，优秀的软件工程师，优秀的人机交互工程师，优秀的测试工程师，优秀的行业专家共同协作的结果。需要从传统的软件开发思维向敏捷软件开发思维转变。

第二，是团队的维度，当有优秀的人才聚集之后，相应的团队结构也是需要转变的。过往的团队组织形式是人以类聚，软件工程师们组成软件开发团队，测试工程师们组成测试团队。在新的形势下，需要更高效的沟通，更快速的迭代，更快速的纠错。那么团队的组织需要融合，不再由一种职能的人组成，而是将需求，设计，开发，测试，交付各种技能的人组织在一起合成一个团队。这好像特种部队的编制，一只特种部队，由爆破，狙击，医疗，火力支援，侦察，掩护，指挥等各种技能的人才组成的，才会具备强大的战斗力。

第三，是软件资产累积的维度，除了人的思维，团队组织的转变，还要一项特别重要资产，那就是公司多年发展积累下来的，各种成型的解决方案，软件代码中的各种公用库。传统软件依赖于各种动态链接库，现代软件需要依赖的是服务。换了一种形式，动态链接库的原始积累也是必不可少的选项。

因此，微服务能否成为银弹，需要从上面三个维度来评分，得分越低，越需要厉兵秣马，砥砺前行；得分高也不是一件骄傲的事情，微服务无止境。