一、微服务架构介绍
1.单体架构
单体架构也被称为单体应用,它是将所有的功能模块全部耦合在一个项目中
1.1 单体架构特点
1.最终会被打包成一个独立的单元(一个唯一 的jar包或war包)
2.会以一个进程的方式来运行
1.2 单体架构的优点与缺点
优点
- 项目易于管理
- 部署简单
缺点
- 测试成本高
- 可伸缩性差
- 可靠性差
- 迭代困难
- 跨语言程度差
- 团队协作难
2.微服务架构
2.1 什么是微服务
微服务是一种架构风格。一个大型的复杂软件应用,由一个或多个微服务组成。系统中 的各个微服务可被独立部署,各个微服务之间是松耦合的。每个微服务仅关注于完成一件任 务并很好的完成该任务。
2.2 常见的架构风格
- 客户端与服务端的
- 基于组件模型的架构(EJB)
- 分层架构(MVC)
- 面向服务架构(SOA)
2.3 微服务的特点
- 系统是由多个服务构成
- 每个服务可以单独独立部署
- 每个服务之间是松耦合的,服务内部高内聚,服务外部低耦合,高内聚就是一个项目专注的完成一个功能
2.4 微服务的优点与缺点
优点:
- 容易测试
- 可伸缩性强
- 可靠性强
- 跨语言程度更加灵活
- 团队协作容易
- 系统迭代容易
缺点:
- 运维成本过高,部署的数量较多
- 接口兼容多版本
- 分布式系统的复杂性
- 分布式事务
二、MVC、RPC、SOA、微服务架构之间的区别
1.MVC架构
其实MVC就是传统的单体架构
代表技术: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 等等
三、微服务的设计原则
- AKF拆分原则
- 前后端分离原则
- 无状态服务
- 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轴扩展。
工程领域常见的 Z 轴扩展有以下两种方案:
-
单元化架构
在分布式服务设计领域,一个单元(Cell)就是满足某个分区所有业务操作 的自包含闭环。如上面我们说到的Y轴扩展的 SOA 架构,客户端对服务端节点 的选择一般是随机的,但是,如果在此加上Z轴扩展,那服务节点的选择将不再是随机的了,而是每个单元自成一体。如下图:
-
数据分区
为了性能数据安全上的考虑,我们将一个完整的数据集按一定的维度划分出 不同的子集。 一个分区(Shard),就是是整体数据集的一个子集。比如用尾号 来划分用户,那同样尾号的那部分用户就可以认为是一个分区。数据分区为一般 包括以下几种数据划分的方式:
- 数据类型(如:业务类型)
- 数据范围(如:时间段,用户 ID)
- 数据热度(如:用户活跃度,商品热度)
- 按读写分(如:商品描述,商品库存)
2. 前后端分离原则
何为前后端分离?前后端本来不就分离么?这要从尴尬的 jsp 讲起。分工精细化从来都 是蛋糕做大的原则,多个领域工程师最好在不需要接触其他领域知识的情况下合作,才可能 使效率越来越高,维护也会变得简单。jsp 的模板技术融合了 html 和 java 代码,使得传统 MVC 开发中的前后端在这里如胶似漆,前端做好页面,后端转成模板,发现问题再找前端, 前端又看不懂 java 代码…前后端分离的目的就是将这尴尬局面打破。 前后端分离原则,简单来讲就是前端和后端的代码分离,我们推荐的模式是最好采用物 理分离的方式部署,进一步促使更彻底的分离。如果继续直接使用服务端模板技术,如:jsp, 把 java、js、html、css 都堆到一个页面里,稍微复杂一点的页面就无法维护了。
这种分离方式有几个好处:
- 前后端技术分离,可以由各自的专家来对各自的领域进行优化,这样前段的用户体 验优化效果更好。
- 分离模式下,前后端交互界面更清晰,就剩下了接口模型,后端的接口简洁明了, 更容易维护。
- 前端多渠道集成场景更容易实现,后端服务无需变更,采用统一的数据和模型,可 以支持多个前端:例如:微信 h5 前端、PC 前端、安卓前端、IOS 前端。
3. 无状态服务
对于无状态服务,首先说一下什么是状态:如果一个数据需要被多个服务共 享,才能完成一笔交易,那么这个数据被称为状态。进而依赖这个“状态”数据的 服务被称为有状态服务,反之称为无状态服务。
那么这个无状态服务原则并不是说在微服务架构里就不允许存在状态,表达 的真实意思是要把有状态的业务服务改变为无状态的计算类服务,那么状态数据 也就相应的迁移到对应的“有状态数据服务”中。
场景说明:例如我们以前在本地内存中建立的数据缓存、Session 缓存,到 现在的微服务架构中就应该把这些数据迁移到分布式缓存中存储,让业务服务变 成一个无状态的计算节点。迁移后,就可以做到按需动态伸缩,微服务应用在运 行时动态增删节点,就不再需要考虑缓存数据如何同步的问题。
4. RestFul的通讯风格
作为一个原则来讲本来应该是个“无状态通信原则”,在这里我们直接推荐一 个实践优选的 Restful 通信风格 ,因为他有很多好处:
- 无状态协议 HTTP,具备先天优势,扩展能力很强。例如需要安全加密,有 现成的成熟方案 HTTPS 即可。
- JSON 报文序列化,轻量简单,人与机器均可读,学习成本低,搜索引擎友好。
- 语言无关,各大热门语言都提供成熟的 Restful API 框架,相对其他的一些 RPC 框架生态更完善。
四、SpringCloud简介
1.什么是SpringCloud
SpringCloud是一个服务治理平台,提供了一些服务框架。包含了:服务注册 与发现、配置中心、消息中心 、负载均衡、数据监控等等。
Spring Cloud 是一个微服务框架,**相比 Dubbo 等 RPC 框架, Spring Cloud 提 供的全套的分布式系统解决方案。 **
Spring Cloud 对微服务基础框架 Netflix 的多个开源组件进行了封装,同时又实现 了和云端平台以及和 Spring Boot 开发框架的集成。
Spring Cloud 为微服务架构开发涉及的配置管理,服务治理,熔断机制,智能路由, 微代理,控制总线,一次性 token,全局一致性锁,leader 选举,分布式 session,集 群状态管理等操作提供了一种简单的开发方式。
Spring Cloud 为开发者提供了快速构建分布式系统的工具,开发者可以快速的启动 服务或构建应用、同时能够快速和云平台资源进行对接。
2. SpringCloud的项目的位置
SpingCloud是Spring 的一个顶级项目与 SpringBoot、SpringData 位于同一位置。
3.SpringCloud的子项目
3.1 SpringCloud Config
配置管理工具,支持使用 Git 存储配置内容,支持应 用配置的外部化存储,支持客户端配置信息刷新、加解密配置内容等
3.2 SpringCloud Bus
事件、消息总线,用于在集群(例如,配置变化事件)中 传播状态变化,可与 Spring Cloud Config 联合实现热部署。
3.3 Spring Cloud Netflix>
**针对多种 Netflix 组件提供的开发工具包,其中包括 Eureka、Hystrix、Zuul、Archaius 等。 **
-
Netflix Eureka
一个基于 rest 服务的服务治理组件,包括服务注册中心、服务注册与服务发现机制的实现,实现了云端负载均衡和中间层服务器的故障转移。
-
Netflix Hystrix
容错管理工具,实现断路器模式,通过控制服务的节点, 从而对延迟和故障提供更强大的容错能力。
-
Netflix Ribbon
客户端负载均衡的服务调用组件。
-
Netflix Feign
基于Ribbon和Hystrix的声明式服务调用组件。
-
Netflix Zuul
微服务网关,提供动态路由,访问过滤等服务。
-
Netflix Archaius:
配置管理 API,包含一系列配置管理 API,提供动 态类型化属性、线程安全配置操作、轮询框架、回调机制等功能。
3.4 Spring Cloud for Cloud Foundry
通过 Oauth2 协议绑定服务到 CloudFoundry,CloudFoundry 是 VMware 推出的开源 PaaS 云平台。
3.5 Spring Cloud Sleuth
日志收集工具包,封装了 Dapper,Zipkin 和 HTrace 操作。
3.6 Spring Cloud Data Flow
大数据操作工具,通过命令行方式操作数据流。
3.7 Spring Cloud Security
安全工具包,为你的应用程序添加安全控制,主要是指OAuth2。
3.8 Spring Cloud Consul
封装了Consul操作,consul是一个服务发现与配置工具,与Docker容器可以无缝集成。
3.9 Spring Cloud Zookeeper
操作Zookeeper的工具包 , 用使用zookeeper方式的服务注册和发现。
3.10 Spring Cloud Stream:
数据流操作开发包,封装了Redis、Rabbit、Kafka 等发送接收消息。
3.11 Spring Cloud CLI
基于 Spring Boot CLI,可以让你以命令行方式快速建立云组件。
五、SpringCloud与Dubbo的区别
六、 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 版本发布计划说明
七、RabbitMQ
1.什么是RabbitMQ
MQ全称Message Queue(消息队列),是一种应用程序与应用程序之间通信的一种方式,应用程序可以通过向消息队列中读写消息进行信息的交互,而不是以应用相互调用的方式进行通信。
2.安装RabbitMQ
2.1 安装rabbitmq所需要的依赖包
yum install build-essential openssl openssl-devel unixODBC unixODBC-devel make gcc gcc-c++ kernel-devel m4 ncurses-devel tk tc xz
2.2 下载安装包(cd /usr/local/software)
wget www.rabbitmq.com/releases/erlang/erlang-18.3-1.el7.centos.x86_64.rpm
wget http://repo.iotti.biz/CentOS/7/x86_64/socat-1.7.3.2-5.el7.lux.x86_64.rpm
wget www.rabbitmq.com/releases/rabbitmq-server/v3.6.5/rabbitmq-server-3.6.5-1.noarch.rpm
2.3 安装服务命令
#第一步:安装erlang语言环境
rpm -ivh erlang-18.3-1.el7.centos.x86_64.rpm
#第二步:安装socat加解密软件
rpm -ivh socat-1.7.3.2-5.el7.lux.x86_64.rpm
#第三步:最后安装rabbitmq
rpm -ivh rabbitmq-server-3.6.5-1.noarch.rpm
2.4 修改集群用户与连接心跳检测
**注意修改vim /usr/lib/rabbitmq/lib/rabbitmq_server-3.6.5/ebin/rabbit.app文件 **
修改:loopback_users 中的 <<“guest”>>,只保留guest(不修改只能通过localhost访问)
2.5 修改本机系统文件
#修改
vim /etc/rabbitmq/rabbitmq-env.conf
添加:NODENAME=rabbit
#修改
vim /etc/hostname
#修改本地文件
vim /etc/hosts
#验证服务器是可用的
rabbitmq-server start &
**执行管控台插件 **
rabbitmq-plugins enable rabbitmq_management
#检查端口
lsof -i:5672
#通过
ps -ef|grep rabbitmq
访问地址:http://192.168.159.8:15672
#下载延时插件:
wget https://dl.bintray.com/rabbitmq/communityplugins/3.6.x/rabbitmq_delayed_message_exchange/rabbitmq_delayed_message_exchange-20171215- 3.6.x.zip
#解压延时插件
unzip rabbitmq_delayed_message_exchange-20171215-3.6.x.zip
#把延时插件拷贝到指定目录下
cp rabbitmq_delayed_message_exchange-20171215-3.6.x.ez /usr/lib/rabbitmq/lib/rabbitmq_server-3.7.5/plugins
#启动延时插件
rabbitmq-plugins enable rabbitmq_delayed_message_exchange
3.命令行和管控台
**开启管控台插件 rabbitmq-plugus rabbitmq_management 来开启管控台 **
测试连接: http://ip:15672(来访问) 用户名密码 guest/guest
3.1 管理控制台命令
a.起停服务命令
#启动服务
rabbitmqctl start_app
启动rabbitmq节点保证需要erlang虚拟机节点起来才能执行)
#停止服务
rabbitmqctl stop_app
停止rabbtimq节点,但是不会停止erlang节点rabbitmqctl stop都会停止
#查看服务状态
rabbtimqctl status
b. 用户操作命令
#查看所有用户列表
rabbitmqctl list_users
#添加用户
rabbitmqctl add_user luyi luyi
#设置rabbitmq用户的角色
rabbitmqctl set_user_tags luyi administrator