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

前言

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

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

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

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

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

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

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

单体模式的优势：

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

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

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

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

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

02 技术架构演化

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

1. MVC

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

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

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

2. 模块化与分布式

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

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

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

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

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

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

03 业务导向：微服务

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

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

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

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

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

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

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

小：将大系统拆成一组小的服务独立：每个服务互相独立轻：我们可以简单理解为代码之间通过一套标准化、大众化的方式互相沟通业务：服务围绕着业务进行构建。这里要介绍一个概念“康威定律”，这就是为什么微服务最终选择了以业务结构作为其服务划分的依据原因。

马尔文·康威1967提出的：“设计系统的架构受制于产生这些设计的组织的沟通结构。”通俗的来讲：产品必然是其（人员）组织沟通结构的缩影。

04 微服务架构

微服务其实是对模块化和分布式的一种升级。

首先，后端增加了统一的“门面”——网关。有了网关之后，前端就不需要知道众多的服务他们分布在哪里，只需要请求网关，由网关将需求传递到相应的服务中。网关还能自动帮前端找到最快且稳定的服务节点，让前端体验更胜一筹。

诸多的服务分散在不同的地方，为了将这些服务组织管理起来，知道他们用途、状态信息，避免后续发展成一共有多少个服务都无法统计，就诞生了服务池的“管理机构”。所有服务都必须在管理机构内注册登记、及时上报自身情况。

稍微复杂点的功能，都需要多个服务互相配合才能完成的。单体模式时代，由于只有一套系统，程序员顺藤摸瓜就能找到bug出在哪。现在存在多个独立的服务，程序员必须每个服务逐一排查故障，这就让找bug根源问题变得非常困难，于是就需要一套故障追踪机制，记录前端请求在后端实现的全链路，以便发现问题出在哪。

05 微服务实践

为了让程序员可以更好将系统架构向微服务迁移，于是就衍生出了微服务的代码框架，其中比较出名的方案有SpringCloud、Dubbo两家，我们来简单看看他们他们的官方示例图。

SpringCloud的架构图 翻译by iCheer

从SpringCloud的架构中不难看出微服务的相对于原有的分布式架构的新特征：

网关：对前后端的沟通进行统一的管理。注册中心：用于对所有服务进行管理，服务必须在注册中心注册登记才能使用配置中心：每个服务的配置不是在各自服务内进行，而是统一放在“配置中心”便于管理分布式追踪器：就是用来配合程序员定位一个功能链条中是哪个环节出了问题

Dubbo的架构路线图 翻译by iCheer

里面有一些比较专业名词，未来有机会再另外讲解

从Dubbo的架构路线图里，我们能更直观的看到上文讲的技术架构演化历程：从单一架构到MVC，再到分布式，然后把分布的服务进行统一管理。

06 总结

通过对微服务的学习，不难发现：

微服务其实不是一种具体的技术，不是某家公司出品的软件（如Docker）或语言（如Java、Python）。微服务也没有形成一个标准的定义（如C/S、B/S）或设计模式（如MVC），事实上，研发行业内许多大牛都对微服务有着自己的见解。

其实在早在十多年前（就是这么早）一些公司就开始尝试将大系统不断的进行拆解探索，最著名的案例其一就是Netflix网飞，自2009年开始对系统进行拆分、上云，微服务的概念就在这些公司的不断探索中逐渐成型、完善。

微服务更像是技术架构的一种新思潮，一种正在不断迭代的、用业务的思想解决技术问题的思路，你也可以认为这是程序员们对“人人都是产品经理”的一种侧面实践。

业务驱动下产生的微服务，无疑让写代码这件事变得更具挑战性，但却让程序更能直接表达其价值，能让企业的业务更好、更快的发展。

下期预告：如果说“微服务”其实是一种技术思潮，那产品经理为何要了解微服务，微服务对产品设计有何帮助？

参考文章

《微服务架构定义那点事》作者：时间的朋友

《什么是微服务架构》作者：老刘

《微服务入门这一篇就够了》作者：centychen

《微服务写的最全的一篇文章》作者：AI乔治

《微服务（Microservice）那点事》作者：小云栖

《解析微服务架构（一）单块架构系统以及其面临的挑战》作者：王磊

参考书籍

《微服务架构与实践》作者：王磊

SpringCloud、Dubbo官方文档：

本文由 @iCheer 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议