springCloud学习

第一章微服务架构介绍

 

（Spring Cloud 初级）

 

 

1、 单体架构

 

单体架构也称之为单体系统或者是单体应用。就是一种把系统中全部的功能、模块耦合

在一个应用中的架构方式。

 

1 单体架构特色

 

1.1打包成一个独立的单元(导成一个惟一的 jar 包或者是 war 包)

1.2会一个进程的方式来运行

 

 

 

 

 

 

 

2 单体架构的优势、缺点

 

2.1优势

 

　　2.1.1项目易于管理

　　2.1.2部署简单

 

2.2缺点

 

2.2.1测试成本高

• 全部的功能都在一个项目中，好比项目要被迭代，功能要被改变，因为是一个总体，一个部分发送改变，全部部分都要进行测试。不敢保证此次跟新会不会对总体形成影响。

2.2.2可伸缩性差

• 单体架构项目是以一个单进程来运行的，很具有局限性，水平扩展不容易。好比如今对整个系统进行扩展，好比其中一个模块，如商品模块，访问需求量过大，咱们要对她进行集群部署，进行水平扩展。单体架构很难作到，咱们只能对整个项目进行集群部署。

2.2.3可靠性差

• 当前系统，某个模块出现bug，致使整个系统不可用。

2.2.4迭代困难

• 因为全部的模块都在一个项目中，会致使平常迭代很是困难，好比说互联网项目，每月都会进行一次迭代。单体架构会致使分支过多，分支过多在合并代码的时候，会很是痛苦。

2.2.5跨语言程度差

• 因为咱们如今系统的体系愈来愈庞大，需求愈来愈大。这时候单依靠java一门语言，显得有些力不从心。这时候咱们可能还会依靠其余的语言来对项目进行支持。单体架构这时候想加入其余语言就比较难，由于单体架构是耦合在一块儿的。

2.2.6团队协做难

• 整个系统是由一个团队来开发的。单体架构，里面的内容变得很是的庞大的时候，咱们每一个成员就要进行大量的代码。整个团队之间，进行沟通和协做就很困难。不像分布式架构，每一个团队只负责一个模块，不像单体架构沟通那么困难。

 

2、 微服务架构

 

1 什么是微服务

 

　　微服务是一种架构风格。一个大型的复杂软件应用，由一个或多个微服务组成。系统中

的各个微服务可被独立部署，各个微服务之间是松耦合的。每一个微服务仅关注于完成一件任

务并很好的完成该任务。

 

2 架构风格

 

　　项目的一种设计模式。

 

2.1常见的架构风格

 

• 2.1.1客户端与服务端的

 

• 2.1.2基于组件模型的架构（EJB）

 

• 2.1.3分层架构(MVC)

 

• 2.1.4面向服务架构(SOA)

 

3 微服务特色：

 

 

　　3.1系统是由多个服务构成

 

　　3.2每一个服务能够单独独立部署

 

　　3.3每一个服务之间是松耦合的。服务内部是高内聚的，外部是低耦

合的。高内聚就是每一个服务只关注完成一个功能。

 

4 微服务的优势、缺点

 

4.1优势

 

4.1.1测试容易

• 每一个服务的组件都是灵活的，能独立部署，因此说测试起来的时候，对哪一个服务进行了迭代，就能够征对性取进行测试。

 

4.1.2可伸缩性强

 

•  内部高内聚，外部松耦合。每一个服务都能进行相应扩展。

 

4.1.3可靠性强

• 以前讲单体架构也说过，一单项目某个模块出现问题，受影响的是整个项目。可是微服务则否则，并不会由于某个bug而致使整个服务所有宕机。受影响的是某个服务，而不是整个项目。

 

4.1.4跨语言程度会更加灵活

 

• 微服务的架构跟语言无关，咱们能够根据本身的选择或者项目的特色去选择不一样的语言和工具，高效的去完成这个项目。

 

 

4.1.5团队协做容易

• 只作本身某一块的服务，并不须要去关注其余的服务。下降了程序员的学习成本和沟通成本。

 

4.1.6系统迭代容易

 

• 每一个微服务能够根据每一个团队进行相应的独立开发。系统迭代只正对当前的服务就能够了。

 

4.2缺点

 

4.2.1运维成本太高，部署数量较多

 

• 不像单体架构，只有一个项目，咱们只要放入tomcat中运行就能够了。如今把一个项目拆分红多个服务，服务越多，运维的成本就越高。

 

4.2.2接口兼容多版本

• 咱们须要考虑到接口兼容多版本的问题。面向服务开发就是面向接口开发，服务的提供方式就是经过接口来提供的。接口的变动必然会致使多个客户端跟着改，这样就必须作接口的多版本开发。以便于适用于接口的变动。

 

4.2.3分布式系统的复杂性

• 原本是一个系统，如今把他拆分红多个服务。因为网络的延迟性，网络的不稳定，服务的容错性，服务的负载均衡等等，都是咱们咱们在作微服务架构须要考虑到的一个问题。

 

4.2.4分布式事务

• 咱们在作微服务开发的时候，最大的难题就是对分布事务的处理。

 

3、 MVC、RPC、SOA、微服务架构之间的区别

 

 

• 1 MVC 架构

 

其实 MVC 架构就是一个单体架构。

表明技术：Struts二、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 微服务架构

 

微服务就是一个轻量级的服务治理方案。

 

注册中心:比ESB更轻量一些。

 

表明技术：SpringCloud、dubbo 等等

 

 

 

4、 如何设计微服务以及设计原则

 

1) AKF 拆分原则

 

2) 先后端分离原则

 

3) 无状态服务

 

4) RestFul 的通讯风格

 

1 AKF 拆分原则

 

业界对于可扩展的系统架构设计有一个朴素的理念,就是：

经过加机器就能够解决容量和可用性问题。(若是一台不行那就两台)。

我是个段子：（世界上没有什么事是一顿烧烤不能解决的。若是有，那就两

顿。）

这一理念在“云计算”概念疯狂流行的今天，获得了普遍的承认！对于一个规模

迅速增加的系统而言，容量和性能问题固然是首当其冲的。可是随着时间的向前，

系统规模的增加，除了面对性能与容量的问题外，还须要面对功能与模块数量上

的增加带来的系统复杂性问题以及业务的变化带来的提供差别化服务问题。而许

多系统，在架构设计时并未充分考虑到这些问题，致使系统的重构成为常态，从

而影响业务交付能力，还浪费人力财力！对此，《可扩展的艺术》一书提出了一

个更加系统的可扩展模型—— AKF 可扩展立方 （Scalability Cube）。这个立方

体中沿着三个坐标轴设置分别为：X、Y、Z。 

 

 

 

 

Y 轴(功能) —— 关注应用中功能划分，基于不一样的业务拆分

X 轴(水平扩展) —— 关注水平扩展，也就是”加机器解决问题”

Z 轴(数据分区) —— 关注服务和数据的优先级划分，如按地域划分

 

 

1.1 Y 轴(功能)

 

Y 轴扩展会将庞大的总体应用拆分为多个服务。每一个服务实现一组相关的功

能，如订单管理、客户管理等。在工程上常见的方案是 服务化架构(SOA) 。比

如对于一个电子商务平台，咱们能够拆分红不一样的服务，组成下面这样的架构：

 

 

 

但经过观察上图容易发现，当服务数量增多时，服务调用关系变得复杂。为

系统添加一个新功能，要调用的服务数也变得不可控，由此引起了服务管理上的

混乱。因此，通常状况下，须要采用服务注册的机制造成服务网关来进行服务治

理。系统的架构将变成下图所示：

 

 

 

1.2 X 轴(水平扩展)

 

X 轴扩展与咱们前面朴素理念是一致的，经过绝对平等地复制服务与数据，

以解决容量和可用性的问题。其实就是将微服务运行多个实例，作集群加负载均

衡的模式。

为了提高单个服务的可用性和容量， 对每个服务进行 X 轴扩展划分 。

 

 

 

1.3 Z 轴(数据分区)

 

Z 轴扩展一般是指基于请求者或用户独特的需求，进行系统划分，并使得划

分出来的子系统是相互隔离但又是完整的。以生产汽车的工厂来举例：福特公司

为了发展在中国的业务，或者利用中国的廉价劳动力，在中国创建一个完整的子

工厂，与美国工厂同样，负责完整的汽车生产。这就是一种 Z 轴扩展。

1.3.1工程领域常见的 Z 轴扩展有如下两种方案：

1.3.1.1 单元化架构

在分布式服务设计领域，一个单元（Cell）就是知足某个分区全部业务操做

的自包含闭环。如上面咱们说到的 Y 轴扩展的 SOA 架构，客户端对服务端节点

的选择通常是随机的，可是，若是在此加上 Z 轴扩展，那服务节点的选择将再也不

是随机的了，而是每一个单元自成一体。以下图：

 

 

 

1.3.1.2 数据分区

为了性能数据安全上的考虑，咱们将一个完整的数据集按必定的维度划分出

不一样的子集。 一个分区（Shard），就是是总体数据集的一个子集。好比用尾号

来划分用户，那一样尾号的那部分用户就能够认为是一个分区。数据分区为通常

包括如下几种数据划分的方式：

数据类型（如：业务类型）

数据范围（如：时间段，用户 ID）

数据热度（如：用户活跃度，商品热度）

按读写分（如：商品描述，商品库存）

 

 

2 先后端分离原则

 

 

何为先后端分离？先后端原本不就分离么？

这要从尴尬的 jsp 讲起。分工精细化历来都

是蛋糕作大的原则，多个领域工程师最好在不须要接触其余领域知识的状况下合做，才可能

使效率愈来愈高，维护也会变得简单。jsp 的模板技术融合了 html 和 java 代码，使得传统

MVC 开发中的先后端在这里如胶似漆，前端作好页面，后端转成模板，发现问题再找前端，

前端又看不懂 java 代码......先后端分离的目的就是将这尴尬局面打破。

先后端分离原则，简单来说就是前端和后端的代码分离，咱们推荐的模式是最好采用物

理分离的方式部署，进一步促使更完全的分离。若是继续直接使用服务端模板技术，如：jsp，

把 java、js、html、css 都堆到一个页面里，稍微复杂一点的页面就没法维护了。

 

 

 

这种分离方式有几个好处：

 

• 1) 先后端技术分离，能够由各自的专家来对各自的领域进行优化，这样前段的用户体验优化效果更好。
• 2) 分离模式下，先后端交互界面更清晰，就剩下了接口模型，后端的接口简洁明了，更容易维护。
• 3) 前端多渠道集成场景更容易实现，后端服务无需变动，采用统一的数据和模型，能够支持多个前端：例如：微信 h5 前端、PC 前端、安卓前端、IOS 前端。

 

 

3 无状态服务

 

 

 

 

对于无状态服务，首先说一下什么是状态：若是一个数据须要被多个服务共

享，才能完成一笔交易，那么这个数据被称为状态。进而依赖这个“状态”数据的

服务被称为有状态服务，反之称为无状态服务。

 

那么这个无状态服务原则并非说在微服务架构里就不容许存在状态，表达

的真实意思是要把有状态的业务服务改变为无状态的计算类服务，那么状态数据

也就相应的迁移到对应的“有状态数据服务”中。

 

 

场景说明：例如咱们之前在本地内存中创建的数据缓存、Session 缓存，到

如今的微服务架构中就应该把这些数据迁移到分布式缓存中存储，让业务服务变

成一个无状态的计算节点。迁移后，就能够作到按需动态伸缩，微服务应用在运

行时动态增删节点，就再也不须要考虑缓存数据如何同步的问题。

 

4 RestFul 的通信风格

 

 

做为一个原则来说原本应该是个“无状态通讯原则”，在这里咱们直接推荐一

个实践优选的 Restful 通讯风格 ，由于他有不少好处：

 

1) 无状态协议 HTTP，具有先天优点，扩展能力很强。例如须要安全加密，有

现成的成熟方案 HTTPS 便可。

 

2) JSON 报文序列化，轻量简单，人与机器都可读，学习成本低，搜索引擎友

好。

 

 

 

第二章 SpringCloud 入门

 

 

（Spring Cloud 初级）

 

1、 什么是 SpringCloud

 

什么是 SpringCloud：是一个服务治理平台，提供了一些服务框架。包含了：服务注册

与发现、配置中心、消息中心 、负载均衡、数据监控等等。

 

1 概念定义

 

Spring Cloud 是一个微服务框架，相比 Dubbo 等 RPC 框架, Spring Cloud 提

供的全套的分布式系统解决方案。

 

Spring Cloud 对微服务基础框架 Netflix 的多个开源组件进行了封装，同时又实现

了和云端平台以及和 Spring Boot 开发框架的集成。

 

Spring Cloud 为微服务架构开发涉及的 配置管理，服务治理，熔断机制，智能路由，

微代理，控制总线，一次性 token，全局一致性锁，leader 选举，分布式 session，集

群状态管理等操做提供了一种简单的开发方式。

 

Spring Cloud 为开发者提供了快速构建分布式系统的工具，开发者能够快速的启动

服务或构建应用、同时可以快速和云平台资源进行对接。

 

2 Spring Cloud 的项目的位置

 

Sping Cloud 是 Spring 的一个顶级项目与 Spring Boot、Spring Data 位于同一位置。

 

3 Spring Cloud 的子项目

 

Spring Cloud 包含了不少子项目，如：

 

 

3.1Spring Cloud Config：配置管理工具，支持使用 Git 存储配置内容，支持应

用配置的外部化存储，支持客户端配置信息刷新、加解密配置内容等

 

3.2 Spring Cloud Bus：事件、消息总线，用于在集群（例如，配置变化事件）中

传播状态变化，可与 Spring Cloud Config 联合实现热部署。

 

3.3Spring Cloud Netflix：针对多种 Netflix 组件提供的开发工具包，其中包括

Eureka、Hystrix、Zuul、Archaius 等。

 

3.3.1Netflix Eureka：一个基于 rest 服务的服务治理组件，包括服务注册中

心、服务注册与服务发现机制的实现，实现了云端负载均衡和中间层服务器

的故障转移。

 

3.3.2Netflix Hystrix：容错管理工具，实现断路器模式，经过控制服务的节点,

从而对延迟和故障提供更强大的容错能力。

 

3.3.3Netflix Ribbon：客户端负载均衡的服务调用组件。

 

3.3.4Netflix Feign：基于 Ribbon 和 Hystrix 的声明式服务调用组件。

 

3.3.5Netflix Zuul：微服务网关，提供动态路由，访问过滤等服务。

 

3.3.6Netflix Archaius：配置管理 API，包含一系列配置管理 API，提供动

态类型化属性、线程安全配置操做、轮询框架、回调机制等功能。

 

3.4Spring Cloud for Cloud Foundry：经过 Oauth2 协议绑定服务到

CloudFoundry，CloudFoundry 是 VMware 推出的开源 PaaS 云平台。

 

3.5Spring Cloud Sleuth：日志收集工具包，封装了 Dapper,Zipkin 和 HTrace

操做。

 

3.6Spring Cloud Data Flow：大数据操做工具，经过命令行方式操做数据流。

 

3.7Spring Cloud Security：安全工具包，为你的应用程序添加安全控制，主要

是指 OAuth2。

 

3.8Spring Cloud Consul：封装了 Consul 操做，consul 是一个服务发现与配

置工具，与 Docker 容器能够无缝集成。

 

3.9Spring Cloud Zookeeper ：操做 Zookeeper 的 工 具 包 ， 用 于 使 用

zookeeper 方式的服务注册和发现。

 

3.10Spring Cloud Stream：数据流操做开发包，封装了与 Redis,Rabbit、

Kafka 等发送接收消息。

 

3.11Spring Cloud CLI：基于 Spring Boot CLI，可让你以命令行方式快速

创建云组件。

 

2、 SpringCloud 与 Dubbo 的区别

 

 

 

3、 Spring Cloud 版本说明

 

1 常见版本号说明

 

软件版本号：2.0.2.RELEASE

2：主版本号。当功能模块有较大更新或者总体架构发生变化时，主版本号会更新

0：次版本号。次版本表示只是局部的一些变更。

2：修改版本号。通常是 bug 的修复或者是小的变更

RELEASE:希腊字母版本号。次版本号用户标注当前版本的软件处于哪一个开发阶段

 

1.1希腊字母版本号

Base：设计阶段。只有相应的设计没有具体的功能实现。Alpha：软件的初级版本。存在较多的 bug

Bate：表示相对 alpha 有了很大的进步，消除了严重的 bug，还存在一些潜在的 bug。

Release：该版本表示最终版。

 

2 Spring Cloud 版本号说明

 

2.1为何 Spring Cloud 版本用的是单词而不是数字？

设计的目的是为了更好的管理每一个 Spring Cloud 的子项目的清单。避免子的版本号与子

项目的版本号混淆。

 

2.2版本号单词的定义规则

采用伦敦的地铁站名称来做为版本号的命名，根据首字母排序，字母顺序靠后的版本号

越大。

 

2.3版本发布计划说明

 

 

3 Spring Cloud 与子项目版本兼容说明