（本文首发于同名微信公众号：稳健程序袁，转载请注明,原文链接mp.weixin.qq.com/s?__biz=Mzg… ）

  时至今日，微服务（Micro Service）已经不再是什么新兴概念，特别是在互联网公司，微服务已经成为了实质上的架构设计标准，互联网公司的开发人员对于运用微服务带来的优势就像体验呼吸一样自然。作为一条老腊肉，有幸在前公司--某家银行总行科技部经历了单体应用（Monolithic Application）开发，也参与了整个公司云转型的架构设计，进入互联网公司接触微服务后，让我更深切感受到微服务很多的优势。那么究竟什么是微服务，它究竟带来了什么样的好处呢，我们就来一起聊一聊。本文面向微服务新同学，不涉及具体技术细节。

举个栗子

  写文档我喜欢用白话来解释概念，不用那些高大上的术语。互联网人擅长包装概念，玄而又玄的概念如果不能深入浅出的说明，那代表着我还理解不够到位，会督促我更深入的学习。

  首先我们用一个电商网站作为例子，解释服务架构的发展历史，通过这一段虚拟的发展历史，让大家感受到微服务的需求是如何产生的。内容不是很严谨，仅供理解。网上很多文章都是这种介绍方式，这部分如果已经理解的同学可以跳过，内容基本上大同小异。

1.懵懂期

  某一天，村头小卖部老王希望借助网上冲浪的热潮，扩展自己的售卖渠道，老袁我虎躯一震，抓住这个机遇开发了一个商品展示网站，提供图片展示、价格展示、联系方式展示三大功能，前后端的功能及存储都在我的台式机里面。

2.创业期

  不久，村里的服装店、菜店啊也联系我，要在网站上放上他们的产品，各种图片啊，联系信息啊翻了好几倍，容量高达256M的硬盘已经装不下了，网站打开速度也越来越慢，没法办，我给自己的台式机加了硬盘和内存。随着更多店的加入，我的台式电脑逐渐力不从心，于是我走上了持续不断升级机器的道路，一路从台式机发展到了工作站。

3.发展期

  随着接入用户越来越多，我的一个个大胆的想法也付诸实践，招了几个村里的大学生做开发，加入了购物车、支付、快递等功能，开发团队也越来越大。在此期间，我赶时髦做了前端、后端、数据库应用独立部署。这个时期的服务架构简单而单纯，职责分明且条理清晰，遇到性能不足就加CPU加硬盘加内存，但是单机性能瓶颈的隐患也在逐步出现。

4.爆发期

  网站实在太火爆，服务器特别是后端应用服务器，在客户老爷们各种层出不穷的花式逻辑下不堪重负，经常是刚买的机器没用多久就撑不住了，直接买最好的我又没钱，只能逐步升级。每次去那些奸商那里买机器时，我都是不耐烦的喊道"shut up and take my money!"。就这样，终于是熬到了市面上最好的机器也不满足我的需求了，公司发展受到了严重的影响。

  关键时刻，团队里有人去国外论坛转了一圈，发现了一个解决方案 -- 我们把展示、购物车、支付、快递这些功能都设计成一个个单独的应用，分布式部署到不同的应用服务器中，使用定制化的协议进行通讯，可以大大降低单台机器的压力，代价嘛就是多买点机器，跟收益相比不值一提。

  到这里单体应用的生命也就走到了尽头，服务发展中的一个重要里程碑也出现了，就是功能垂直切分。所谓垂直切分，就是把业务的一部分从前端到后端到数据库都独立出来，形成新的应用，例如购物车功能。当然一般来说，后端和数据库独立出来就足以满足性能要求。这个阶段的代表就是SOA（Service-Oriented Architecture），不要被这个名字给唬住了，什么面向服务的架构，其实就是把一堆分布式部署的功能用某种协议来相互调用，实现一个系统的功能。什么是协议，听起来高大上，其实就是约定，我跟你约定，听我摔杯为号，你立马带领五百刀斧手剁碎他。
  SOA已经有了一定的微服务雏形，我个人也一直认为微服务是SOA随着软硬件技术发展的天然延伸。SOA跟微服务的一个显著区别，就是典型的SOA架构具有一个中心化的ESB（Enterprise Service Bus）企业服务总线，而微服务是去中心化的。什么是单体应用，原来住一个寝室的小伙伴，大家合作写一篇论文只要相互传阅就行了；毕业后大家各自成家，分布到五湖四海，这时候再想找大家帮忙，得通过邮寄了，这就是SOA。邮件要寄到谁那，需要他家的地址，而且可能他毕业后留洋多年把中文忘记了，邮件内容需要来回翻译，得有个专门的机构帮你做这些事情，这就是ESB。

5.爆炸期

  业务在继续发展，但是开发同学已经怨声载道。支付团队有几十号人共同维护着一个支付功能，需求对于机器性能的无限压榨，使得为了精简而独立出来的支付系统变得极度臃肿，曾经屠龙的少年最终变成了恶龙。

  另一方面，功能繁多的代码，应用动不动就因为某个人不经意的失误而出错。如果错误隐藏很深，整个支付团队都要一起排查问题，惹人心烦且影响效率。这样的事故每天都在上演，服务的SLA（Service Level Agreement）岌岌可危，负责人每天看着报警统计战战兢兢如履薄冰。

  这个时候，继续垂直切分还能苟延残喘一段时间，但是相对于业务的高速发展只是饮鸩止渴，而无休止的拆分，会引入更大的复杂度，没有统一的管理，只会导致雪崩效应。我们迫切需要一种思想，一种能指导大家从被动切分转变到主动把服务设计成规模可控、管理方便的技巧。

  在大家的一片争吵之中，突然又有同学去国外论坛转了一圈（国外论坛是个好东西～～），发现微服务思想有点东西！一番论证之后，各个团队进行了大刀阔斧的改革，各自形成了数个新的微服务团队，每个团队维护自己的相对独立的功能，同时又提供多种访问方式供其他应用调用。巨大的代码库被拆分为了好几个小库，各个应用部署独立，不会因为一个功能的修改上线导致其他功能被动重新部署。团队内部，因为维护的是一个可以独立对外服务的功能，所以相互关系更加紧密；团队之间，因为没有了直接联系，所以相互关系更加松散。

2014年，Martin Fowler 与 James Lewis 共同提出了微服务的概念，定义了微服务是由以单一应用程序构成的小服务，自己拥有自己的行程与轻量化处理，服务依业务功能设计，以全自动的方式部署，与其他服务使用HTTP API通信。同时服务会使用最小的规模的集中管理 (例如 Docker) 能力，服务可以用不同的编程语言与数据库等组件实现。 zh.wikipedia.org/wiki/%E5%BE…

  微服务不是一种特定的技术规范，而是一种思想，维基百科的资料如上。大佬的语言总是晦涩难懂，那是因为他们严谨而专业，不过毕竟这是六年前的定义，现在服务调用也不仅仅是HTTP这一种手段，不用深究概念。
  同时接触过单体应用、SOA和微服务开发，个人觉得SOA和微服务的关系就像马车和汽车。两者一脉相承，都是车，都有动力系统和四个轮子。但是从组成上讲，马车可能由几百个比较粗的零件组成，轮子、轴、车厢，当然还有马。而汽车呢，可能由几十万个精细的零件组成，但是这些零件不是直接组成了汽车，而是组成了好几个部分，例如动力系统、空调系统、音响系统。马车零件少，坏了一个可能就要散架，汽车系统多，音响坏了也不影响我漂移。驾驶马车需要你有一定的技巧，而开车则要简单得多，这就是技术的进步让系统在更复杂的情况下使用变简单了。微小和简单并不是伴生关系，只不过微服务的复杂性被一堆管理工具隐藏起来了，这也是一系列微服务组件的重要意义，没有这些组件，微服务只会更加难以驯服。

6.展望期

  故事到这里，基本上服务发展就到了现在互联网的常见形态，一个个小而精的团队组成了可以支撑复杂功能的大型电商网站应用，满足业务发展规模不再是驱动服务架构变化的主要因素，如何在保证服务质量的前提下降低成本，成为了新的重点，也是技术团队永恒的目标。作为其中一个重要的发展方向，云计算与云原生，也是这两年大火的概念，关于云计算是什么，另一篇同样不讲技术的文章正在构思中，敬请期待。

微服务的劣势

  微服务的劣势，上面也提到过，千言万语汇总来说就是复杂二字，切分复杂、通讯复杂、运维复杂，还有各种框架级的支撑服务，总而言之除了开发简单，几乎什么都复杂。所以微服务一般需要公司级别或者平台级别提供基础设施及服务团队的支持，不然让业务团队来操心这些事情，那就会鸡飞狗跳，得不偿失。所以在发展的最初阶段，比较推荐使用单体服务开发模式，业务量上去了、团队技术积累到位了，再重构为微服务模式。

微服务的优势

  网上对微服务的优点总结很多，别人珠玉在前，我也就不班门弄斧了。但是作为技术人员，要学会跳出技术细节，从更高层面来看问题，下面是我在不同公司呆过后的一些思考。

1. 成本

  利益永远是驱动技术发展的源动力，技术不是。在微服务出现以前，小公司应用部署在x86服务器上，大公司则使用IOE三件套，用上小型机（Mini Computer）例如AS/400；少有的几家超大规模土豪公司使用大型机（Mainframe），《人月神话》这本书中作为项目背景的SYSTEM/360就是大型机。

  系统可靠性逐级上升，采购及维护费用也水涨船高，一般公司根本负担不起。大型国有银行每年在服务器维护及软件许可证上的开销就是九位数、十位数以上，就在刚刚过去的11月份，浦发银行就采购了一份价值9000多万的Oracle维保合同，这还没有统计人力等成本。

  为什么这么贵，原因无他，过往的技术路线决定，应用就是这么一个大家伙，哪天他罢工了，客户就都没法使用了。假设哪天全国的工行网点都没法取款、转账了，哪怕只有几个小时，负责科技的行长估计都会掉乌纱帽，国外大公司掐准了这一点，下手那是相当的黑。当然，付出了这么巨大的代价，大公司系统的稳定性基本也得到了保证，像微信以及支付宝等曾经出现过的长时间大面积不可用的生产事故，在银行基本没有出现过，综合声誉风险等考量下来，也算物有所值吧。

  微服务出现以后，对机器的要求变低了。集群部署多实例高可用概念的引入，单服务器的可靠性不再是应用的生命线，质量不够数量来凑，小型机被替换为大量高性价比的x86服务器，Oracle被替换为开源免费的Mysql，服务器和软件相关的成本大大下降，加上公有云服务的发展，让人人都能负担得起应用运维的费用，更多有创意的应用走进了大众视野，迅猛发展。

2.敏捷

  微服务带来的第二个好处就是团队更加小了，团队内部向高内聚，低耦合的软件开发理想模式转变。原本大团队尾大不掉难以转身的缺点消失了，取而代之的是快速迭代、快速试错的优点，在机会转瞬即逝的互联网时代，给了初创团队更大的生存概率。

  来一个例子对比，张一鸣在创建字节跳动后，一口气开发了12款应用投入到市场，最终其中一款应用活了下来，就是“今日头条”，当然这时候没有微服务什么事。也许是受了创业初期的启发，后面字节跳动有着“APP工厂”的称号，各种APP不停的往外冒，这其中就有微服务的小团队带来的好处。多个团队聚在一起做一个应用，有的提供算法，有的提供前端，有的提供存储，应用没火起来，各个团队立马转向其他应用中继续发挥自己的专长，就在这样的氛围下才有了抖音视频的后来居上，以及西瓜视频，火山视频等的爆发。可见在互联网大厂，微服务能够带来巨大的敏捷生产力。

  作为对比，手机银行APP的发展怎一个慢字了得。曾今因为工作原因下载了几乎所有银行的APP，2016年以前的手机银行APP几乎是一成不变的丑、难用、设计反人类。特别吐槽一下农行，当年我打开农行APP时看到那么巨大的图标和杂乱无章的页面设计，仿佛看到了十年前的WAP版手机QQ。作为曾经的银行科技人员，我其实很理解他们的困境，不是不想用新方案，而是背后的依赖错综复杂。一个改动带来的影响无法评估，而且想要合作方配合，他们也面临同样的痛苦，相互纠缠之下，优化往往不如推倒重来。因此银行系统的质量都是飞跃式的增长，一个系统用十年，然后重新开发一套系统继续用十年，这就是典型的大公司老模式的慢。随着金融科技改革的深入，微服务体系也正在逐步向银行核心系统渗透，至少这个十年里，我相信银行系统会逐步实现微服务化甚至云化的转型。

3.趋势

  如果说以前微服务还只是一种设计理念的话，近几年的技术发展则是围绕微服务形成了一个强大的生态圈。DevOps、Docker、k8s、云计算，各种概念层出不穷，罗列起来三天三夜也说不完，但是简单理解就是利用微服务对于硬件的最低需求极度低下的特性，一大波聪明绝顶的工程师都在这个生态圈里努力突破极限，这股合力给软件开发行业带来了深刻的变革。

  以前开发软件是一项贵族运动，服务器软硬件授权、IDC托管、聘请运维，一行代码没写，几十万就得先掏出来，还是按年收费过期不候。我开发了一个小游戏，老袁农场，只要1核2G就能运行，结果去市场一看，对不起，租一个应用服务器256核起步（这里是夸张的说法，大家理解这个困境就行），创意不错公司没钱，卒，眼睁睁的看着企鹅的开心农场收割市场。

  现在呢，因为微服务的崛起。软硬件供应商都不再那么傲慢，有了docker的支持，机器可以越来越小，还有一帮大公司为创业者构建了一个非常廉价的运维环境--你甚至都不需要自己购买服务器，会写代码就能部署应用，你敢部署，微服务生态就敢运行。不仅仅是创业者，小、中、大型公司都因为这种变化，降低了成本，微服务带来的弹性扩容，关键时刻可以从外部买算力，避免了公司为了应付流量高峰买来的机器日常时间吃灰，而且少量的专业运维人员用几个软件就把整个服务集群治理得服服帖帖，云计算更是把成本降到了极致。

  技术进步引发的革命是不可逆转的，汽车的发明注定了马车要退出历史舞台，也是趋势，也是客观规律。

结束语

  洋洋洒洒写了五千多字，回头看看好像说了很多，又什么都没说的样子。微服务就是这样，横看成岭侧成峰，有人看到微服务的廉价，有人看到微服务的灵活，有人看到微服务的简便，不管各自看到了什么，微服务都代表着业界对于成本压缩和效率提升的追求。像单体应用、SOA一样，都是服务发展道路上的不同阶段，相互没有优劣之分。它既不是恶魔也不是银弹，了解并掌握它，让它成为自己工具箱中的一员，才是正确的心态。

  最后总结一下，本文没有讲任何微服务相关的技术细节，也不是告诉大家如何开发微服务应用，希望能够让微服务的新同学们了解到，微服务是怎么来的，同时能够在合适的场景下，想到还有微服务这项工具可以使用。如何掌握微服务，这就要靠大家各自努力了，与君共勉。