转载

产品经理懂点技术（1）：程序员讲的“微服务”到底是什么？

对产品经理来说，了解技术相关基础知识有助于理解需求的实现过程与原理，帮助与研发更好地沟通。而本文主要跟大家分享一下什么是“微服务”，以及它的起源、演化、架构与实践。

前言

这段时间，程序猿哥哥突然主动找到产品汪，希望小汪提供一版最新的产品功能蓝图。小汪好奇向他们打听，结果发现是技术组大佬提出了一个新概念“微服务”，涉及整个系统底层的重构，程序猿们内部也比较迷茫该。于是小汪就找了个机会，向技术组大佬请教了一下，到底什么是“微服务”。

01 研发模式的起点：单体模式

小汪问大佬，什么是“微服务”呀？

大佬回答说，你知道研发都有什么技术架构么？小汪摇了摇头。技术大佬就说：

产品经理懂点技术（1）：程序员讲的“微服务”到底是什么？

一个系统划分为前端和后端，这个你懂吧？前端就是用户看得到、摸得着的，例如APP、小程序、网页等等、管理后台等等；后端是用户看不见的，负责进行逻辑处理和储存各类数据的。

小汪说，这个我知道，我还知道前后端分离呢！

大佬接着说：在系统发展的早期，后端就只有一套系统，所有功能的代码都写在这套系统中，我们称之为“单体模式”。

单体模式的优势：

容易开发 ：不讲究复用、遇到什么新需求都造个新“轮子”，这样最容易开发了；
容易回溯 ：遇到问题的时候很容易定位是哪个新造的“轮子”出了问题；
容易部署 ：也就是大家常说的“发版”，系统新功能上线，因为只有一套后端代码，所以把改过的代码直接发布一次就行了；
容易克隆 ：别人想买这个系统时，直接Ctrl+C，Ctrl+V一下就好了。

随着需求越来越多，功能越来越复杂，单体模式的弊端就会暴露出来：

迭代和维护成本增加 ：系统规模还小时，一个新功能可能只与三五个已有功能关联，所以改动起来很容易。但是随着系统功能越来越多，一个新功能可能跟十几个、甚至几十个已有功能关联时，要改其中一个功能，可谓牵一发而动全身，这下工作量就会变得陡然增加。
工作交接十分困难 ：不同功能由不同的程序员写的，又调用了别的程序员写的代码，交接起来哪些是自己写的可能都分不出来，别人也不知道该怎么维护。
重构难度十分巨大 ：万一哪一天性能或者复杂度到了极限，需要对代码进行优化或重构，旧的代码重度耦合，根本下不去手。

物理学上，两个和两个以上的体系或者两者运动形式之间相互作用而彼此影响以至于联合起来的现象叫做“耦合”。

这里的“耦合”是指系统模块间相互依赖、互相影响的意思。模块间的耦合度是指模块之间的依赖关系，包括控制关系、调用关系、数据传递关系。模块间联系越多，其耦合性越强，同时表明其独立性越差。

02 技术架构演化

由于单体模式长远来看明显弊大于利，所以程序员就开始思考如何有规划的写代码。

1. MVC

MVC全名是Model View Controller，是模型(model)－视图(view)－控制器(controller)的缩写，一种软件设计典范，用一种业务逻辑、数据、界面显示分离的方法组织代码。

产品经理懂点技术（1）：程序员讲的“微服务”到底是什么？

MVC是从代码意义的层面出发，将代码分为了负责调度用的Controller控制器、负责业务逻辑和数据库处理的Model模型、负责最终数据呈现的View视图三部分。

相对于最开始的“一锅粥”的混沌状态，现在代码间有了一些边界，程序员分工、代码定位也更清晰了。

2. 模块化与分布式

MVC解决了代码内部管理的不少问题，但是从整个系统的视角来看，依然是一个单体。随着业务规模越来越大，某几个功能的流量可能占用了服务器绝大部分资源，于是就产生了两个问题：

功能的稳定性如何保障？
单台服务器的处理能力达到瓶颈后如何处理？

聪明的程序员就想到，把关键的业务逻辑和主系统剥离开来，形成独立的模块，这样关键逻辑就能单独运作，不受系统其它逻辑故障的影响。当该模块用户量多的时候，还可以把模块多复制几份同时运行，这样其中一个模块不幸挂了，那么其他模块还能接替他继续运作。

产品经理懂点技术（1）：程序员讲的“微服务”到底是什么？

把多个模块放在同一台服务上，并没有解决服务器处理能力极限的问题，于是就找老板要为这台服务器升级配置，结果一出价格，吓得老板直哆嗦。

配置提高一点，价格就高了很多，花同样的钱能买好几台原来配置一样的机器。如果改成买多几台机器，然后想办法让这些机器处理能力能叠在一起，性能还可以远超升级的配置。

产品经理懂点技术（1）：程序员讲的“微服务”到底是什么？

于是就有了分布式的诞生，多买几台几台服务器，让他们同时工作。服务器还可以选择部署在全国不同的地方，实现了用户的就近区域访问，让不同地区用户都能享受最佳的访问速度。

03 业务导向：微服务

分布式的架构看似帮程序员们解决了很多的问题，但是新的问题又随之而来：

按什么标准去将代码独立成新模块？按技术的喜好、代码的作用、还是按业务模块区分？
未来独立的模块越来越多，那该如何管理？

微服务的到来，就为这些问题打开了新思路。最经典的微服务的概念，是Martin Fowler于2014年的一篇文章《Microservices – the new architectural style》中阐述的：

微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制互相协作（通常是基于HTTP协议的RESTful API）。每个服务都围绕着具体业务进行构建，并且能够被独立的部署到生产环境、类生产环境等。

在阿里云官网，关于微服务的介绍：

微服务能够将业务单元按照独立部署和发布的标准进行抽取和隔离，一个大而全的复杂应用程序能够拆分成几个微小的相互独立的微服务，当其中的某一服务无法支撑时，可以横向水平扩展保证应用的高可用性，具有独立应用生命周期管理、独立版本开发与发布等能力。

从这些定义中，我们可以总结出几个关键词：