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

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

马尔文·康威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官方文档：

https://spring.io/cloud

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

题图来自Unsplash，基于CC0协议