微服务基础理论（架构演进、远程调用和CAP）

1、系统架构的演进

随着互联网的发展，网站应用的规模不断扩大，常规的应用架构已无法应对，分布式服务架构以及微服务架构势在必行。下面将用电商系统的演进来举例

1.1 单机架构

Web 应用程序发展的早期，大部分 Web 工程(包含前端页面，web层代码，service层代码，dao层代码)是将所有的功能模块，打包到一起并放在一个web容器中运行，也叫做 All-in-One。

优点：开发简单，适用于小型应用。（配合代码生成工具（mybatis-plus）可以快速开发项目）
缺点：各模块代码紧密耦合，不易扩展、维护

比如早期的电商系统只能卖东西，则系统内包含了：用户、商品、交易业务。

单机架构的问题缺陷（单台机器处理能力有限，高并发下响应速度变慢）：
单机的处理能力有限，只要业务增长到一定程度的时候，单机的硬件资源就会无法满足业务的需求。这个时候就出现了集群架构

1.2 集群架构（单机架构的水平扩展）

把单机系统复制几份，就构成了一个“集群”，集群中每台服务器就叫做这个集群的“节点”。所有节点构成一个集群，每个节点都提供相同的服务，这样我们的系统的处理能力就提高了 N 倍。

在集群架构阶段还出现一个重要的理论：负载均衡

1、当我们有多个相同的节点时，由谁来处理用户发来的请求才显得高效呢？
  显然我们挑选此时负载较小的节点来处理请求更加合适，这样每个节点的压力相对平均。要实现这个功能，需要在所有节点之前增加一个“调度者”的角色，用户的所有请求都先交给它，然后它根据当前所有节点的负载情况，决定将这个请求交给哪个节点处理。这个“调度者”有个牛逼的名字——负载均衡服务器。

（若集群中某个节点长时间负载过高，而其他节点几乎很少工作时，其实就相当于从集群架构退化到了单机架构。请来的帮手不帮忙）

集群架构的问题缺陷（单台机器带不动多业务的系统）：
集群结构的好处就是系统的水平扩展非常容易。如果随着你们系统业务的发展，当前的系统又支撑不住了，那么给这个集群再增加节点就行了。但是&