架构说明
存在的问题:
- 代码耦合,开发维护困难
- 无法针对不同模块进行针对性优化
- 无法水平扩展
- 单点容错率低,并发能力差
优点:
- 系统拆分实现了流量分担,解决了并发问题
- 可以针对不同模块进行优化
- 方便水平扩展,负载均衡,容错率提高
缺点:
- 系统间相互独立,会有很多重复开发工作,影响开发效率
优点:
- 将基础服务进行了抽取,系统间相互调用,提高了代码复用和开发效率
缺点:
-
系统间耦合度变高,调用关系错综复杂,难以维护
-
以前出现了什么问题? -
服务越来越多,需要管理每个服务的地址
-
调用关系错综复杂,难以理清依赖关系
-
服务过多,服务状态难以管理,无法根据服务情况动态管理
服务治理要做什么?
- 服务注册中心,实现服务自动注册和发现,无需人为记录服务地址
- 服务自动订阅,服务列表自动推送,服务调用透明化,无需关心依赖关系
- 动态监控服务状态监控报告,人为控制服务状态
缺点:
- 服务间会有依赖关系,一旦某个环节出错会影响较大
- 服务关系复杂,运维、测试部署困难,不符合DevOps思想
微服务
前面说的SOA,英文翻译过来是面向服务。微服务,似乎也是服务,都是对系统进行拆分。因此两者非常容易混淆,但其实却有一些差别:
微服务的特点:
- 单一职责:微服务中每一个服务都对应唯一的业务能力,做到单一职责
- 微:微服务的服务拆分粒度很小,例如一个用户管理就可以作为一个服务。每个服务虽小,但“五脏俱全”。
- 面向服务:面向服务是说每个服务都要对外暴露Rest风格服务接口API。并不关心服务的技术实现,做到与平台和语言无关,也不限定用什么技术实现,只要提供Rest的接口即可。
- 自治:自治是说服务间互相独立,互不干扰
- 团队独立:每个服务都是一个独立的开发团队,人数不能过多。
- 技术独立:因为是面向服务,提供Rest接口,使用什么技术没有别人干涉
- 前后端分离:采用前后端分离开发,提供统一Rest接口,后端不用再为PC、移动段开发不同接口
- 数据库分离:每个服务都使用自己的数据源
- 部署独立,服务间虽然有调用,但要做到服务重启不影响其它服务。有利于持续集成和持续交付。每个服务都是独立的组件,可复用,可替换,降低耦合,易维护
架构的演变 传统架构–>水平拆分–>垂直拆分(最早的分布式)–>soa(dubbo)–>微服务(springCloud)
spring公司的核心产品,如图
我们也可以到它的官网去看,百度我就不贴图了,spring全家桶😀
项目启动 搭建 Eureka注册中心
为什么要搭建Eureka注册中心,Eureka是Netflix开发的服务发现框架,本身是一个基于REST的服务,主要用于定位运行在AWS域中的中间层服务,以达到负载均衡和中间层服务故障转移的目的。
Eureka Server提供服务注册服务,各个节点启动后,会在Eureka Server中进行注册,这样Eureka Server中的服务注册表中将会存储所有可用服务节点的信息,服务节点的信息可以在界面中直观的看到。Eureka Server本身也是一个服务,默认情况下会自动注册到Eureka注册中心。,去官方可以看下对应版本号
pringCloud将它集成在其子项目spring-cloud-netflix中,以实现SpringCloud的服务发现功能。
这里可以使用IDEA的spring的 initalizr搭建
不过也可以使用官网的快速开始来,搭建,我这里就用官网的开始搭建
进入到这里,点击start.spring.io
如图所示,最右边呢可以换背景
添加依赖这里我稍微改了下,这里搭建 注册中心服务端,所以只需要一个 Eureka Server
选错了,点这里可以删除掉
键盘输入Ctrl + 回车,下载下来之后,解压,导入进去
只需要找到刚刚解压的项目的pom.xml,点击ok
默认下一步,就好了,初始了一个springboot的项目,springboot的一个