微服务概述

什么是“微”服务？

如果你仔细观察，会发现我在上一行的标题中，将“微”打了个引号。

如果我们暂时去掉这个’’微”字理解，微服务就是我们熟知的“服务端” 或者 “后端”。

现在让我们把微字加回来:-)

“微服务”(Microservices)由马丁·福勒（Martin Fowler）提出的一种架构理念，原文)发表于2014年。

微服务是一种架构模式或者说是一种架构风格，它提倡将单一应用程序划分成一组小的服务，每个服务运行独立的自己的进程中，服务之间互相协调、互相配合，为用户提供最终价值。

我们抓三个关键点来理解：

单一应用划分为一组更小的服务：将一个较大的、复杂的应用，拆分为多个小的服务。你可能会问：“这样不会增加复杂度么”？是的，会增加。但这种拆分也会带来明显的优点，我们后面会提到。
独立的进程：每个微服务独立运行在自己的进程中，互不干扰。虽然这里并没有限制进程的部署方式，但可以想见，经过”划分”后的微服务，势必会产生众多进程。微服务是拆分而来的，他们之间势必存在逻辑的耦合。由此，会产生新的问题”微服务间的通信”。
相互协调、配合：微服务的进程间需要通信、交互。从理论而言，所有IPC(Inter-Process Communacation，进程间通信)的方式都可以完成这个过程。但微服务的进程众多，很难完整地部署在同一台机器上，这势必产生跨主机的网络通信。所以，在微服务中，多采用RPC(Reomote Procedure Call，远程过程调用)的方式来完成通信。

上图展示了单体服务和微服务的区别。

在前文中，我们挖了一个坑：’微服务的划分会导致复杂度上升’，为什么还要使用一项有缺陷的技术呢？

我们先讲第一个故事。

小张入职了一家互联网创业公司，一开始只有3个后端程序员，每天的工作是：和产品经理讨(si)论(bi)需求、写代(b)码(ug)，改Bug，工作紧张但规律。服务端的上线窗口是周五下午：合并分支、代码Review、推送线上，一气呵成，不仅能准点下班，还能去吃个火锅。

过了两个月，行业赶上了风口，公司的业务快速发展，后端团队也快速膨胀到20人。然而，麻烦也接踵而至：大家修改的是同一个仓库下的服务端代码，”解冲突”成为了家常便饭，还发生了几次”一个小修改，破坏了其他业务主流程“的严重线上事故。

为了改善这种情况，老板招聘了2位QA(质量保证，测试)人员，由他们负责测试工作。然而，一个很小的改动都需要对整个后端服务的case进行全量回归测试。一个功能的开发需要1天，测试却耗费1周，迫于老板的压力，研发同学只能安慰自己：XX功能简单，不需要测试了，直接上线。

最终，周五成为了”噩梦日”：周四晚上要提前开一个Excel表、统计好第二天要上线的需求，并按优先级排定顺序。周五全员提前1小时来公司，开始逐个逐个需求的”合并代码””、”解冲突”，“上线”、”观察” 、“回滚”、“修改代码”……

上线结束的收工时间从6点变成了9点，又逐渐拖到了11点，最后索性全员加班、通宵上线。技术团队的每一位同学，都感到身心俱疲。

听完这个故事，你是否有”似曾相识”的感觉？

科普一下，上述故事中的服务一般称作“单体服务” 或者 “巨石服务”(Monoliths)。

接下来，是第二个故事。

由于工作强度大、线上故障频发、团队士气低落，老板请来了老刘担任技术经理。

第一周：老刘带领团队将复杂、臃肿的”巨型服务”拆分成了“用户”、“订单”、“服务”三个微服务。

第二周：老刘将团队进行了上述类似的拆分，也分成了三个小组。

第三周：事情有了微妙的变化。分组后，合并代码引发的冲突减少了。开发业务时，多数的改动都封闭在单独的微服务内，改动造成的影响范围减少了，测试周期缩短了。

……

三个月后的一个周五的下午，（得益于提高的交付质量，以及微服务的独立并行上线），团队提前2小时完成了上线，距离上一次故障通报已经过去了两个月。

研发讨论群里，小张发了一条消息：“今天居然可以正点下班了，老刘真厉害！”

老刘回复：这是大家的努力的结果，真正“厉害”的应该是“微服务”。

听完这两个故事，我们来总结下微服务架构的两个优点：）

在故事之外，微服务架构还具有以下的优点：

伸缩性强：相对于庞大的巨石服务，微服务更加独立，可以针对不同的性能需求，有选择的对不同微服务进行伸缩。举个栗子：明天有大促，产品预测：注册功能提升10倍，其他功能无波动。针对巨石服务，我们只能整体扩容10倍；微服务架构下，我们只需要10倍扩容用户微服务。
技术异构性：每个微服务内可以使用不同的技术栈，甚至不同的开发语言。只要微服务之间使用统一的通信方式即可。

微服务架构有很多优势，那团队抓紧上马微服务吧？