1. 系统架构演进

1.1 单体应用架构

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

比如搭建一个电商系统：客户下订单，商品展示，用户管理。这种将所有功能都部署在一个web容器中运行的系统就叫做单体架构。

优点：简单易构。
缺点：资源有限，不支持高可用，高性能，高并发。

1.2 垂直应用架构

当访问量逐渐增大，单一应用增加机器带来的加速度越来越小，将应用拆成互不相干的几个应用，以提升效率。

优点：比单体稍复杂，任然简单易构。
缺点：资源有限，不支持高可用，高性能，高并发。

1.3 SOA架构

SOA 全称为 Service-Oriented Architecture，即面向服务的架构。它可以根据需求通过网络对松散耦合的粗粒度应用组件(服务)进行分布式部署、组合和使用。一个服务通常以独立的形式存在于操作系统进程中。

站在功能的角度，把业务逻辑抽象成可复用、可组装的服务，通过服务的编排实现业务的快速再生。目的是把原先固有的业务功能转变为通用的业务服务，实现业务逻辑的快速复用。

SOA实质就把各个重用的服务单独抽离出来对外提供服务。类似于中台架构。

SOA 特点：分布式、可重用、扩展灵活、松耦合
优点：降低了耦合性，提高了并发能力。
缺点：抽取服务粒度大。

1.4 微服务架构

各个模块拆分成独立的服务，每个独立的服务在通过分布式集群架构实现高可用，高性能，高并发。
优点：实现高可用，高性能，高并发。
缺点：服务过多，技术门槛高，维护成本高。

1.5 SOA与微服务的关系

SOA（ Service Oriented Architecture ）“面向服务的架构”:他是一种设计方法，其中包含多个服务， 服务之间通过相互依赖最终提供一系列的功能。一个服务 通常以独立的形式存在与操作系统进程中。各个服务之间 通过网络调用。

微服务架构:其实和 SOA 架构类似,微服务是在 SOA 上做的升华，微服务架构强调的一个重点是“业务需要彻底的组件化和服务化”，原有的单个业务系统会拆分为多个可以独立开发、设计、运行的小应用。这些小应用之间通过服务完成交互和集成。

2. 分布式核心功能

2.1 远程调用

REST，即Representational State Transfer的缩写，如果一个架构符合REST原则，就称它为RESTful架构。

RPC（Remote Procedure Call ） 一种进程间通信方式。允许像调用本地服务一样调用远程服务。RPC框架的主要目标就是让远程服务调用更简单、透明。RPC框架负责屏蔽底层的传输方式（TCP或者UDP）、序列化方式（XML/JSON/二进制）和通信细节。开发人员在使用的时候只需要了解谁在什么位置提供了什么样的远程服务接口即可，并不需要关心底层通信细节和调用过程。

1、HTTP相对更规范，更标准，更通用，无论哪种语言都支持http协议。如果你是对外开放API，例如开放平台，外部的编程语言多种多样，你无法拒绝对每种语言的支持，现在开源中间件，基本最先支持的几个协议都包含RESTful。
2、 RPC 框架作为架构微服务化的基础组件，它能大大降低架构微服务化的成本，提高调用方与服务提供方的研发效率，屏蔽跨进程调用函数（服务）的各类复杂细节。让调用方感觉就像调用本地函数一样调用远端函数、让服务提供方感觉就像实现一个本地函数一样来实现服务。

2.2. CAP原理

分布式系统的最大难点，就是各个节点的状态如何同步。CAP 定理是这方面的基本定理，也是理解分布式系统的起点。
CAP理论由 Eric Brewer 在ACM研讨会上提出，而后CAP被奉为分布式领域的重要理论。

Consistency（一致性）：数据一致更新，所有数据的变化都是同步的。
Availability（可用性）：在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。
Partition tolerance（分区容忍性）：某个节点的故障，并不影响整个系统的运行。

CAP理论就是任何分布式系统只可同时满足二点，没法三者兼顾，既然一个分布式系统无法同时满足一致性、可用性、分区容错性三个特点，所以我们就需要抛弃一样：

需要明确一点的是，在一个分布式系统当中，分区容忍性和可用性是最基本的需求，所以在分布是系统中，我们的系统最当关注的就是A（可用性）P（容忍性），通过补偿的机制寻求数据的一致性。

3. SpringCloud三种架构方案

架构是个比较大的概念，目前市场上架构设计方案也百花齐放，任何一种架构都是演进的结果，都是特定时间，特定场景，特定问题的解决方案，不同时间，不同行业，不同业务场景都有自己独具特色的架构设计方案，没有什么是最好，也不是说使用什么架构就是厉害，只有适合自己的才是最好的。

目前市场上常见的三种微服务架构解决方案：
第一套微服务架构解决方案：Spring Boot + Spring Cloud Netflix
第二套微服务架构解决方案：Spring Boot + Spring Cloud Alibaba
第三套微服务架构解决方案：Spring Boot + Dubbo + Zookeeper

springcloud官网提供方案参考：https://spring.io/projects/spring-cloud

3.1 Spring Boot + Spring Cloud Netflix

第一套微服务架构解决方案：Spring Boot + Spring Cloud Netflix

Spring Cloud Netflix 提供了一整套 快速构建分布式系统中一些常见模式的工具，可以快速地支持实现这些模式的服务和应用程序。

Spring Cloud Netflix 的核心组件

Eureka：服务注册于发现。
Feign：基于动态代理机制，根据注解和选择的机器，拼接请求 url 地址，发起请求。
Ribbon：实现负载均衡，从一个服务的多台机器中选择一台。
Hystrix：提供线程池，不同的服务走不同的线程池，实现了不同服务调用的隔离，避免了服务雪崩的问题。
Zuul：网关管理，由 Zuul 网关转发请求给对应的服务。
config: 分布式配置。

注意：
2018 年 12 月 12 日，Netflix 宣布 Spring Cloud Netflix 系列技术栈进入维护模式（不再添加新特性）将模块置于维护模式，
意味着 Spring Cloud 团队将不会再向模块添加新功能。我们将修复 block 级别的 bug 以及安全问题，我们也会考虑并审查社区的小型 pull request。

3.2 Spring Boot + Spring Cloud Alibaba

第二套微服务架构解决方案：Spring Boot + Spring Cloud Alibaba

Spring Cloud Alibaba 致力于提供 微服务开发的 一站式解决方案。

此项目包含开发分布式应用微服务的必需组件，方便开发者通过 Spring Cloud 编程模型轻松使用这些组件来开发分布式应用服务。
依托 Spring Cloud Alibaba，您只需要添加一些注解和少量配置，就可以将 Spring Cloud 应用接入阿里微服务解决方案，通过阿里中间件来迅速搭建分布式应用系统。

Spring Cloud Alibaba 核心组件

Sentinel：把流量作为切入点，从流量控制、熔断降级、系统负载等多个维度保护服务的稳定性。
Nacos：  服务注册与发现、配置管理和服务管理平台。
RocketMQ：一款开源的分布式消息系统，基于分布式集群技术，提供高可用、低延时的的消息发布与订阅服务。
Alibaba Cloud ACM：一款在分布式架构环境中对应用配置进行集中管理和推送的应用配置中心产品。
Alibaba Cloud OSS: 阿里云对象存储服务（Object Storage Service，简称 OSS），是阿里云提供的海量、安全、低成本、高可靠的云存储服务。您可以在任何应用、任何时间、任何地点存储和访问任意类型的数据。
Alibaba Cloud SchedulerX: 阿里中间件团队开发的一款分布式任务调度产品，提供秒级、精准、高可靠、高可用的定时（基于 Cron 表达式）任务调度服务。

3.3 Spring Boot + Dubbo + Zookeeper

第三套微服务架构解决方案：Spring Boot + Dubbo + Zookeeper

Apache Dubbo (incubating) |ˈdʌbəʊ| 是一款高性能、轻量级的开源 Java RPC 框架。

ZooKeeper 是一种分布式协调服务，用于管理大型主机。在分布式环境中协调和管理服务是一个复杂的过程。

高性能 Java RPC 框架 Dubbo
Apache Dubbo (incubating) |ˈdʌbəʊ| 是一款高性能、轻量级的开源 Java RPC 分布式服务框架。

它提供了三大核心能力：
面向接口的远程方法调用，智能容错和负载均衡，以及服务自动注册和发现。

最大的特点是按照分层的方式来架构，使用这种方式可以使各个层之间解耦合（或者最大限度地松耦合）。从服务模型的角度来看，Dubbo 采用的是一种非常简单的模型，要么是提供方提供服务，要么是消费方消费服务，所以基于这一点可以抽象出服务提供方（Provider）和服务消费方（Consumer）两个角色。

Zookeeper 分布式协调服务框架。--具体参照zookeeper章节