微服务其实就是那种不停重复做好一件小事，别想太多复杂的东西

（根据知乎用户“说点大白话”的高赞回答整理）

微服务这个东西,听起来挺高大上的，对吧？感觉又是一帮顶尖程序员搞出来的、普通人难以理解的复杂架构，但我跟你讲，它的核心思想，要是用大白话来说，真的就是“一个团队，就只负责不停地、专心地把一件特别小的事情做到极致，别的乱七八糟的闲事一概别管”。

这就像我们小时候家门口那条街上的老手艺人,你记不记得，以前有条街，东头是张师傅专修自行车，他那个摊子就只干修车这一件事，补胎、换链条、调刹车，手艺炉火纯青，你车有任何毛病，他听个声儿都能知道问题在哪儿，西头是李阿姨的包子铺，一天从早到晚就和面、拌馅、蒸包子，她蒸的包子就是整条街最好吃的，皮薄馅大，火候永远正好，中间还有个王大爷，开了个小小的报刊亭，就卖报纸杂志和烟，你要问他别的东西哪儿买，他一准儿给你指得明明白白。

你看,这条街就是一个完整的“系统”，张师傅不用操心今天包子馅是猪肉白菜还是牛肉大葱，李阿姨也不用学会补自行车胎，王大爷更不用自己去印报纸，他们每个人，就是一个“微服务”，他们的共同特点是：第一，职责极其单一且明确，修车的绝不卖报纸，卖报纸的绝不蒸包子，第二，他们都把自己的那份小事做到了行业标杆级别，因为精力不分散，第三，他们之间需要协作吗？需要，你想啊，你骑自行车去买包子，车链子掉了，你肯定推去找张师傅，修好了再去李阿姨那儿，这就是服务之间的“调用”，但这个过程很自然，张师傅修车的时候不会跑去指挥李阿姨怎么放盐，李阿姨也不会干涉张师傅用哪种型号的扳手，他们之间通过“街坊邻居的默契”（也就是简单的协议）来协作。

反过来,如果你非要把他们仨凑在一起，开一个“社区综合服务中心”，要求张师傅既要会修车，又要学着包包子，还得记住报纸的版面安排，李阿姨和王大爷也一样，都得成为全能选手，结果会怎样？肯定是哪样都做不精，张师傅可能因为分心去记报纸价格，给人家修车时上错了螺丝；李阿姨可能因为要帮忙卖烟，导致包子火候过了头，整个系统的效率和品质都会急剧下降，这个“综合服务中心”，就是我们所反对的“单体架构”——一个巨大、臃肿、什么都想干、结果什么都干不好的庞然大物。

做微服务,第一要诀就是“拆”，把那个巨大的“综合服务中心”拆掉，还原成一个个专注的“手艺人店铺”，一个服务只负责一个很小的、边界清晰的业务能力，比如用户管理，它就只负责用户的注册、登录、信息查询，它别去管商品库存有多少；订单服务就只管生成订单、流转订单，它别去计算应该给用户打多少折扣，每个小团队就像张师傅一样，对自己那块“一亩三分地”拥有绝对的主权和技术选择权，可以用自己最擅长的方式把活儿干到最好。

第二要诀是“别瞎操心”，微服务之间不要有“剪不断理还乱”的复杂关系，最好就像街坊邻居一样，通过简单明了的“打招呼”方式来沟通，订单服务需要知道某个用户的信息，它不用直接去用户服务的数据库里翻箱倒柜（那会造成紧耦合，就像张师傅擅自跑到李阿姨厨房里拿面粉一样不礼貌），它只需要对着用户服务的“门口”喊一声：“喂，帮我查一下用户张三的信息！”然后用户服务听到后，把自己门口一块写有张三信息的“牌子”（也就是API接口响应）亮出来给订单服务看就行了，这个过程简单、直接、互不侵犯内政。

这么干之后,会带来一些新的“小事”需要专门的人去做，整条街上需要有个指路牌，告诉新来的客人修车铺在东头，包子铺在西头，这就是“服务发现”，可能还需要个热心肠的居委会大妈（API网关），外来的人统一先找她，她再指引到具体的店铺，这样店铺就不用各自应付问路的人了，这些就是为了让众多“手艺人”能高效协作而诞生的支撑性“小服务”。

真别把微服务想得太神秘,它的本质就是一种社会分工思想在软件世界的映射，其成功的秘诀，不在于用了多炫的技术，而在于整个团队能否克制住“想做大做全”的欲望，踏踏实实地回归到“工匠精神”，承认复杂性，然后通过拆解和隔离来化解复杂性，你不是在建造一个无所不能的宇宙飞船，你是在培育一条生机勃勃、分工明确的“手艺街”，每个团队的目标，就是成为这条街上那个无可替代的“张师傅”、“李阿姨”或“王大爷”，把自己那件小事，重复做，用心做，做到无人能及。