一 、微服务架构介绍
1.单体架构：
单体架构也称之为单体系统或者是单体应用。就是一种把系统中所有的功能、模块耦合在一个应用中的架构方式。
- 单体架构的特点：
打包成一个独立的单元( 导成一个唯一的 的jar 包或者是 是war 包）；回一个进程的方式来运行。
- 单体架构的优缺点：
| 优点 | 缺点 |
|---|---|
| 项目易于管理 | 测试成本高、可伸缩性差、可靠性差 |
| 部署简单 | 迭代困难、跨语言程度差、团队协作难 |
2.微服务架构：
微服务是一种架构风格。一个大型的复杂软件应用，由一个或多个微服务组成。系统中
的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任
务并很好的完成该任务。
- 常见的架构风格：
（1） 客户端与服务端的
（2） 基于组件模型的架构（EJB ）
（3）分层架构(MVC)
（4） 面向服务架构(SOA) - 微服务的特点：
系统是由多个服务构成
每个服务可以单独独立部署；
每个服务之间是松耦合的，服务内部是高内聚的，外部是低耦合的。高内聚就是每个服务只关注完成一个功能。
- 微服务的优缺点：
| 优点 | 缺点 |
|---|---|
| 测试容易、可伸缩性强、可靠性强 | 运维成本过高，部署数量较多 |
| 跨语言程度会更加灵活、团队协作容易、系统迭代容易 | 接口兼容多版本、分布式系统的复杂性、分布式事务 |
3.MVC、RPC、SOA、微服务架构之间的区别：
（1）MVC架构：
其实 MVC 架构就是一个单体架构。
代表技术：Struts2、SpringMVC、Spring、Mybatis 等等。
（2）RPC架构：
RPC(Remote Procedure Call)：远程过程调用。他一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。
代表技术：Thrift、Hessian 等等。
（3）SOA架构：
SOA(Service oriented Architecture):面向服务架构。
ESB(Enterparise Servce Bus):企业服务总线，服务中介。主要是提供了一个服务于服务之间的交互。
ESB 包含的功能如：负载均衡，流量控制，加密处理，服务的监控，异常处理，监控告急等等。
代表技术：Mule、WSO2。
（4）微服务：
微服务就是一个轻量级的服务治理方案。
代表技术：SpringCloud、dubbo 等等。
4.如何设计微服务和设计原则：
（1）AKF 拆分原则
（2）前后端分离原则
（3）无状态服务
（4）RestFul 的通信风格
4.1AKF拆分原则：
业界对于可扩展的系统架构设计有一个朴素的理念,就是：通过加机器就可以解决容量和可用性问题 。( 如果一台不行那就两台) 。
这一理念在“云计算”概念疯狂流行的今天，得到了广泛的认可！对于一个规模迅速增长的系统而言，容量和性能问题当然是首当其冲的。但是随着时间的向前，系统规模的增长，除了面对性能与容量的问题外，还需要面对功能与模块数量上的增长带来的系统复杂性问题以及业务的变化带来的提供差异化服务问题。而许多系统，在架构设计时并未充分考虑到这些问题，导致系统的重构成为常态，从而影响业务交付能力，还浪费人力财力！对此，《可扩展的艺术》一书提出了一个更加系统的可扩展模型—— AKF 可扩展立方（Scalability Cube）。这个立方体中沿着三个坐标轴设置分别为：X、Y、Z。
*（1）Y 轴(功能) —— 关注应用中功能划分，基于不同的业务拆分Y 轴扩展会将庞大的整体应用拆分为多个服务。每个服务实现一组相关的功能，如订单管理、客户管理等。在工程上常见的方案是 服务化架构(SOA) 。比如对于一个电子商务平台，我们可以拆分成不同的服务，组成下面这样的架构：
（2）X 轴(水平扩展) —— 关注水平扩展，也就是”加机器解决问题”。X 轴扩展与我们前面朴素理念是一致的，通过绝对平等地复制服务与数据，以解决容量和可用性的问题。其实就是将微服务运行多个实例，做集群加负载均衡的模式。为了提升单个服务的可用性和容量， 对每一个服务进行 X 轴扩展划分 。
（3）Z 轴(数据分区) —— 关注服务和数据的优先级划分，如按地域划分。Z 轴扩展通常是指基于请求者或用户独特的需求，进行系统划分，并使得划分出来的子系统是相互隔离但又是完整的。以生产汽车的工厂来举例：福特公司为了发展在中国的业务，或者利用中国的廉价劳动力，在中国建立一个完整的子工厂，与美国工厂一样，负责完整的汽车生产。这就是一种 Z 轴扩展。
4.2前后端分离原则：
前后端分离原则，简单来讲就是前端和后端的代码分离，我们推荐的模式是最好采用物理分离的方式部署，进一步促使更彻底的分离。如果继续直接使用服务端模板技术，如：jsp，把 java、js、html、css 都堆到一个页面里，稍微复杂一点的页面就无法维护了。
- 前后端分离的优点：
（1）前后端技术分离，可以由各自的专家来对各自的领域进行优化，这样前段的用户体验优化效果更好。
（2）分离模式下，前后端交互界面更清晰，就剩下了接口模型，后端的接口简洁明了，
更容易维护。
（3）前端多渠道集成场景更容易实现，后端服务无需变更，采用统一的数据和模型，可
以支持多个前端：例如：微信 h5 前端、PC 前端、安卓前端、IOS 前端。
4.3无状态服务：
- 什么是状态？
如果一个数据需要被多个服务共享，才能完成一笔交易，那么这个数据被称为状态。进而依赖这个“状态”数据的服务被称为有状态服务，反之称为无状态服务。
- 应用场景：
例如我们以前在本地内存中建立的数据缓存、Session 缓存，到现在的微服务架构中就应该把这些数据迁移到分布式缓存中存储，让业务服务变成一个无状态的计算节点。迁移后，就可以做到按需动态伸缩，微服务应用在运行时动态增删节点，就不再需要考虑缓存数据如何同步的问题。
4.4RestFul的通信风格：
- 使用Restful的好处：
（1）无状态协议 HTTP，具备先天优势，扩展能力很强。例如需要安全加密，有现成的成熟方案 HTTPS 即可。
（2）JSON 报文序列化，轻量简单，人与机器均可读，学习成本低，搜索引擎友好。
（3）语言无关，各大热门语言都提供成熟的 Restful API 框架，相对其他的一些RPC 框架生态更完善。
二、Spring Cloud入门
1.Spring Cloud的概念：
SpringCloud 是一个服务治理平台，提供了一些服务框架。包含了：服务注册与发现、配置中心、消息中心 、负载均衡、数据监控等等。
（1）Spring Cloud 是一个微服务框架，相比 Dubbo 等 RPC 框架, Spring Cloud 提供的全套的分布式系统解决方案。
（2）Spring Cloud 对微服务基础框架 Netflix 的多个开源组件进行了封装，同时又实现了和云端平台以及和 Spring Boot 开发框架的集成。
（3）Spring Cloud 为微服务架构开发涉及的 配置管理， ， 服务治理， ， 熔断机制， ， 智能路由 ，微代理 ， 控制总线 ，性 一次性 token，全局一致性锁 ，leader 选举 ，式 分布式 session ， 集群状态管理等操作提供了一种简单的开发方式。
（4）Spring Cloud 为开发者提供了快速构建 分布式系统的工具，开发者可以快速的启动服务或构建应用、同时能够快速和云平台资源进行对接。
- Spring Cloud的子项目：
Sping Cloud 是 Spring 的一个顶级项目与 Spring Boot、Spring Data 位于同一位置。Spring Cloud 包含了很多子项目，如：
| 子项目 | 作用 |
|---|---|
| Spring Cloud Config | 配置管理工具，支持使用 Git 存储配置内容，支持应用配置的外部化存储，支持客户端配置信息刷新、加解密配置内容等 |
| Spring Cloud Netflix | 针对多种 Netflix 组件提供的开发工具包，其中包 括Eureka 、Hystrix 、Zuul 、Archaius 等。 |
| Spring Cloud Bus | 事件、消息总线，用于在集群（例如，配置变化事件）中与 传播状态变化，可与 Spring Cloud Config 联合实现热部署 |
| Spring Cloud for Cloud Foundry | 过 ： 通 过 Oauth2 协 议 绑 定 服 务 到CloudFoundry ，CloudFoundry 是 是 VMware 推出的开源 PaaS 云平台 |
| Spring Cloud Sleuth | 日志收集工具包,了 封装了 Dapper,Zipkin 和 HTrace操作 |
| Spring Cloud Data Flow | 大数据操作工具，通过命令行方式操作数据流 |
| Spring Cloud Security | 安全工具包，为你的应用程序添加安全控制，主要指 是指 OAuth2 |
| Spring Cloud Consul | 封装了 Consul 操作，consul 是一个服务发现与配与 置工具，与 Docker 容器可以无缝集成 |
| Spring Cloud Zookeeper | 作操 作 Zookeeper 的 工 具 包 ， 用 于使 用zookeeper 方式的服务注册和发现。 |
| Spring Cloud Stream | 数据流操作开发包，封装了与 Redis,Rabbit 、Kafka 等发送接收消息。 |
| Spring Cloud CLI | 基于 Spring Boot CLI ，可以让你以命令行方式快速建立云组件。 |
- Spring Cloud Netflix：
| 组件 | 功能 |
|---|---|
| Netflix Archaius | 配置管理 API ，包含一系列配置管理 API ，提供动态类型化属性、线程安全配置操作、轮询框架、回调机制等功能 |
| Netflix Eureka | 一个基于 rest 服务的服务治理组件，包括服务注册中心 、 服务注册与服务发现机制的实现 ， 实现了云端负载均衡和中间层服务器的故障转移。 |
| Netflix Hystrix | 容错管理工具，实现断路器模式，通过控制服务的节点,从而对延迟和故障提供更强大的容错能力。 |
| Netflix Ribbon | 客户端负载均衡的服务调用组件。 |
| Netflix Feign | 基于 Ribbon 和 和 Hystrix 的声明式服务调用组件。 |
| Netflix Zuul | 微服务网关，提供动态路由，访问过滤等服务。 |
2.Spring Cloud与Dubbo的区别：
![]()
示例
3.Spring Cloud版本说明：
软件版本号：2.0.2.RELEASE
2：主版本号。当功能模块有较大更新或者整体架构发生变化时，主版本号会更新。
0：次版本号。次版本表示只是局部的一些变动。
2：修改版本号。一般是 bug 的修复或者是小的变动。
RELEASE:希腊字母版本号。次版本号用户标注当前版本的软件处于哪个开发阶段。
- 希腊字母版本号：
（1）Base：设计阶段。只有相应的设计没有具体的功能实现。
（2）Alpha：软件的初级版本。存在较多的 bug
（3）Bate：表示相对 alpha 有了很大的进步，消除了严重的 bug，还存在一些潜在的 bug。
（4）Release：该版本表示最终版。
- 使用单词而不是数字的目的：
设计的目的是为了更好的管理每个 Spring Cloud 的子项目的清单。避免子的版本号与子项目的版本号混淆。
- 命名的规则：
采用伦敦的地铁站名称来作为版本号的命名，根据首字母排序，字母顺序靠后的版本号越大。
4.版本发布计划说明：
| 版本号 | 版本 | 作用 |
|---|---|---|
| DUILD-XXX | 开发版 | 一般是开发团队内部使用 |
| GA | 稳定版 | 一般是内部开发到了一定阶段了，各个模块集成后，经过全面测试发现没有问题，可以对外发行了。这个时候就叫（General Availability） |
| PRE | 里程碑版 | 主要是对GA里面一些功能的完善和bug修复，一个AG后会有多个里程碑版，例如：M1，M2，M3... |
| RC | 候选发布版 | 从BUILD到GA再到M基本上系统就算定型了，这个时候系统就进入Release Candidate（候选发布版），该版本的软件类似于最终发行前的一个观察期，该期间只对一些发现的等级高的bug进行修复 |
| SR | 正式发布版 | 公开正式发布，正式发布版发布版一般也有多个发布，例如：SR1、SR2、SR3等等，一般是用来来修复大bug或者优化 |
- Spring Cloud学习网站：
