微服务的由来
微服务的由来（入门）
本教程适用人群：1. 产品经理 2. 入门微服务架构的后端同学
感谢小红书用户“产品Ailie有话说”，原文链接
一、研发模式的起点：单体模式
众所周知，Web开发的系统分为前端和后端，在早年间就已经实现了前后端分离。
在系统发展的早期，后端只有一套系统，所有功能的代码都写在这套系统中，我们称之为“单体模式”。
单体模式不区分业务逻辑和功能逻辑，是一个比较简单的系统，因此优势和劣势都很明显：
优势
容易开发、容易回溯、容易部署、容易克隆
适合需求简单，功能少的系统
劣势
对于复杂的系统来说，单体模式的耦合度相当高：
迭代和维护成本增加：随着系统功能越来越多，一个新功能可能跟十几个、几十个已有功能相关联，改一个功能，需要牵一发而动全身，工作量陡然增加。
工作交接困难：各个功能相互交错，而又看不懂别人的代码，沟通整合相当困难
重构难度非常大：重度耦合的代码，在重构性能时非常困难
二、技术架构演化
由于单体模式长远来看弊大于利，因此程序员开始思考如何有规划的写代码
1. MVC架构
MVC将代码分为了三部分：
负责调度用的
Controller控制器负责业务逻辑和数据库处理的
Model模型负责最终数据呈现的
View试图
我们之前用过 SpringMVC，这里不再赘述。
2. 模块化与分布式
MVC解决了代码内部管理的不少问题，但是从整个系统的视角来看，依然是一个单体，随着业务规模越来越大，某几个牛马功能的流量可能非常大，占用了服务器绝大部分资源。这时我们需要解决两个问题：
不要让后端程序崩：这些牛马功能（比如抢单、pdd的广告）流量大的时候，我想让【后端程序】其他功能（如注册、登录）的稳定性得到保障
不要让服务器崩：当这些牛马功能占用服务器资源过大，达到了服务器处理的瓶颈能力，这时就算分开了牛马功能，它们也让后端程序把服务器弄挂了
我们逐个解决。
模块化：保证后端程序稳定运行
把关键的业务逻辑和主系统剥离开来，形成独立的模块。这样关键逻辑就能单独运作，不受系统其它逻辑故障的影响 
当该模块用户量多的时候，还可以把模块看多复制几份同时运行，这样如果其中一个模块不幸挂了，那么其它同类的模块还可以接替他继续工作。
分布式：保证服务器总能提供服务
服务器挂了，说明程序到达了服务器处理的极限。假如我们有一台【2核2GB】的服务器，需要升级，下面是两种解决方案：
将这台服务器升级为【4核4GB】，所需费用20000元；
再购买3台【2核2GB】的服务器，所需费用6000 * 3 = 18000元，而且如果想办法让这些机器处理能力能叠在一起，性能远超方案一升级的配置
你把这两种方案报给老板，老板只要不傻肯定会去选第二种，但是老板会问你，你怎么想办法让这些不同的服务器处理能力能叠在一起呢？
于是，分布式便诞生了：多买几台服务器，让他们同时工作。 
服务器还可以选择部署在全国不同的地方，实现了用户的就近区域访问，让不同地区用户都能享受最佳的访问速度。
三、业务导向：微服务
分布式的架构看似帮程序员们解决了很多的问题，但是新的问题又来了：
按什么标准将代码独立成新模块？按技术的喜好、代码的作用、还是按业务模块区分？
未来独立的模块越来越多，那该如何管理？
微服务
微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的微服务，服务之间互相协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制互相协作（通常是基于HTTP协议的RESTful API）。每个服务都围绕着具体业务进行构建，并且能够被独立的部署到生产环境、类生产环境等。
当其中的某一服务无法支撑时，可以横向水平扩展保证应用的高可用性，具有独立应用生命周期管理、独立版本开发与发布等能力
从以上定义，我们可以提取四个关键词：
小：将大系统拆成一组小的服务
独立：每个服务互相独立
轻：简单理解为代码之间通过一套标准化、大众化的方式互相沟通
业务：服务围绕着业务进行构建。
拓展阅读：可以看一看“康威定律”： 微服务架构的理论基础 - 康威定律
四、微服务架构
以下是一种常见的微服务架构：
微服务实际上是对模块化和分布式的一种升级，除了刚才提到的这两个方面，我们还需要这几个模块：
网关
首先，后端增加了统一的“门面”————网关。有了网关之后，前端就不需要知道众多的服务分布在哪里，只需要请求网关，由网关将需求传递到相应的服务中。
网关还能自动帮前端找到最快且最稳定的服务节点，让前端体验更胜一筹。
服务管理机构
诸多的服务分散在不同的地方，假如服务足够多，这里举一个例子：我们怎么样才能统计一共有多少个服务呢？我们怎么知道哪个服务是做什么的，是不是挂了？挂了多少？
为了将这些服务组织管理起来，知道他们的用途和状态信息，就诞生了服务池的“管理机构”。
所有服务都必须在管理机构内注册登记、及时上报自身情况。
故障追踪机制
单体模式时代，由于只有一套系统，程序员顺藤摸瓜就能找到bug在哪里。然而到了微服务，稍微复杂一些的功能都需要多个服务相互配合完成，如果出现bug，程序员必须每个服务逐一排查故障，这就让找到bug根源问题变得非常困难。
于是就需要一套故障追踪机制，记录前端请求在后端实现的全链路，以便发现问题。
五、微服务实践
微服务的实践现在已经很多，这里列举几家最出名的：
SpringCloud
接口网关 API Gateway: 统一分配管理前后端沟通
注册中心 breaker dashboard: 用于对所有服务进行管理，服务必须在注册中心注册登记才能使用
配置中心 config dashboard: 每个服务的配置不是在各自服务内进行，而是统一放在“配置中心”便于管理
分布式追踪器 distributed tracing: 就是用来配合程序员定位一个功能链条中哪个环节出了问题
微服务 microservices
消息代理 message brokers: 与消息队列相关
总结
微服务不是一种具体的技术，不是某家公司出名的软件（如Docker）或语言（如Java、Python）。微服务也没有形成一个标准的定义（如C/S、B/S）或设计模式（如MVC），事实上，研发行业内许多大牛都对微服务有着自己的见解。
微服务更像是技术架构的一种新思潮，一种正在不断迭代的、用业务的思想解决技术问题的思路。
