随着互联网的发展,网站应用的规模也在不断的扩大,进而导致系统架构也在不断的进行变化。 从互联网早起到现在,系统架构大体经历了下面几个过程: 单体应用架构--->垂直应用架构--->分布式架构--->SOA架构--->微服务架构,当然还有悄然兴起的Service Mesh(服务网格化)。
接下来我们就来了解一下每种系统架构是什么样子的, 以及各有什么优缺点。
互联网早期,一般的网站应用流量较小,只需一个应用,将所有功能代码都部署在一起就可以,这样可以减少开发、部署和维护的成本。
比如说一个电商系统,里面会包含很多用户管理,,商品管理,订单管理,物流管理等等很多模块, 我们会把它们做成一个web项目,然后部署到一台tomcat服务器上。
优点:
缺点:
随着访问量的逐渐增大,单一应用只能依靠增加节点来应对,但是这时候会发现并不是所有的模块 都会有比较大的访问量.
还是以上面的电商为例子, 用户访问量的增加可能影响的只是用户和订单模块, 但是对消息模块的影响就比较小. 那么此时我们希望只多增加几个订单模块, 而不增加消息模块. 此时单体应用就做不到了, 垂直应用就应运而生了.
所谓的垂直应用架构,就是将原来的一个应用拆成互不相干的几个应用,以提升效率。比如我们可 以将上面电商的单体应用拆分成:
电商系统(用户管理 商品管理 订单管理)
后台系统(用户管理 订单管理 客户管理)
CMS系统(广告管理 营销管理)
这样拆分完毕之后,一旦用户访问量变大,只需要增加电商系统的节点就可以了,而无需增加后台 和CMS的节点。建立三个工程。
优点:
缺点:
当垂直应用越来越多,重复的业务代码就会越来越多。这时候,我们就思考可不可以将重复的代码 抽取出来,做成统一的业务层作为独立的服务(service),然后由前端控制层(controller)调用不同的业务层服务呢?
这就产生了新的分布式系统架构。它将把工程拆分成表现层controller和服务层service两个部分,服务层中包含业务 逻辑。表现层只需要处理和页面的交互,业务逻辑都是调用服务层的服务来实现。
优点:
缺点:
在分布式架构下,当服务越来越多,容量的评估,小服务资源的浪费等问题逐渐显现,此时需增加一个调度中心对集群进行实时管理。此时,用于资源调度和治理中心(SOA Service Oriented Architecture,面向服务的架构)是关键。
优点:
缺点:
微服务架构在某种程度上是面向服务的架构SOA继续发展的下一步,它更加强调服务的"彻底拆分"---->必须要springboot(独立的系统) 必须依赖于springboot技术。Springcloud如果没有springboot 那么springcloud也无法使用。 springboot可以独立使用。因为springboot里面内置了tomcat 独立运行。Java -jar xxx.jar
只适合大工程。移动互联网 电商项目 p2p 等,
系统管理--->系统微服务 入库管理 -----入库微服务
优点:
缺点: 小型项目----微服务架构不合适。仓库系统---微服务。
微服务架构, 简单的说就是将单体应用进一步拆分,拆分成更小的服务,每个服务都是一个可以独立运行的项目。
针对每个问题使用不同的组件来讲解。
一旦采用微服务系统架构,就势必会遇到这样几个问题:
Springcloud微服务就是针对上面这些问题 提出的解决方案。
对于上面的问题,是任何一个微服务设计者都不能绕过去的,因此大部分的微服务产品都针对每一个问题提供了相应的组件来解决它们。---学习如何解决上面的问题==组件。
服务治理就是进行服务的自动化管理,其核心是服务的自动注册与发现。
服务注册:服务实例将自身服务信息注册到注册中心。
服务发现:服务实例通过注册中心,获取到注册到其中的服务实例的信息,通过这些信息去请求它们提供的服务。
服务剔除:服务注册中心将出问题的服务自动剔除到可用列表之外,使其不会被调用到。
在微服务架构中,通常存在多个服务之间的远程调用的需求。目前主流的远程调用技术有基于HTTP的RESTful接口以及基于TCP的RPC协议。
REST(Representational State Transfer)
这是一种HTTP调用的格式,更标准,更通用,无论哪种语言都支持http协议。
RPC(Remote Promote Call)
Rpc @Autowire Bservice bservice.方法()
一种进程间通信方式。允许像调用本地服务一样调用远程服务。RPC框架的主要目标就是让远程服务调用更简单、透明。RPC框架负责屏蔽底层的传输方式、序列化方式和通信细节。开发人员在使用的时候只需要了解谁在什么位置提供了什么样的远程服务接口即可,并不需要关心底层通信细节和调用过程。
区别与联系
随着微服务的不断增多,不同的微服务一般会有不同的网络地址,而外部客户端可能需要调用多个服务的接口才能完成一个业务需求,如果让客户端直接与各个微服务通信可能出现:
针对这些问题,API网关顺势而生。
API网关直面意思是将所有API调用统一接入到API网关层,由网关层统一接入和输出。一个网关的基本功能有:统一接入、安全防护、协议适配、流量管控、长短链接支持、容错能力。有了网关之后,各个API服务提供团队可以专注于自己的的业务逻辑处理,而API网关更专注于安全、流量、路由等问题。
在微服务当中,一个请求经常会涉及到调用几个服务,如果其中某个服务不可用,没有做服务容错的话,极有可能会造成一连串的服务不可用,这就是雪崩效应。
我们没法预防雪崩效应的发生,只能尽可能去做好容错。服务容错的三个核心思想是:
在微服务当中,一个请求经常会涉及到调用几个服务,如果其中某个服务不可用,没有做服务容错的话,极有可能会造成一连串的服务不可用,这就是雪崩效应。
我们没法预防雪崩效应的发生,只能尽可能去做好容错。服务容错的三个核心思想是:
随着微服务架构的流行,服务按照不同的维度进行拆分,一次请求往往需要涉及到多个服务。互联网应用构建在不同的软件模块集上,这些软件模块,有可能是由不同的团队开发、可能使用不同的编程语言来实现、有可能布在了几千台服务器,横跨多个不同的数据中心。
因此,就需要对一次请求涉及的多个服务链路进行日志记录,性能监控即链路追踪
Apache ServiceComb,前身是华为云的微服务引擎 CSE (Cloud Service Engine) 云服务,是全球首个Apache微服务顶级项目。它提供了一站式的微服务开源解决方案,致力于帮助企业、用户和开发者将企业应用轻松微服务化上云,并实现对微服务应用的高效运维管理.
SpringCloud (springcloud 很多组件都是拿的是Netflix公司,这家公司这些组件停止维护和更新。)
Spring Cloud是一系列框架的集合。它利用Spring Boot的开发便利性巧妙地简化了分布式系统基础设施的开发,如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等,都可以用Spring Boot的开发风格做到一键启动和部署。
Spring Cloud并没有重复制造轮子,它只是将目前各家公司开发的比较成熟、经得起实际考验的服务框架组合起来,通过Spring Boot风格进行再封装屏蔽掉了复杂的配置和实现原理,最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包。
目前已经停更了。Euruka(注册中),feign远程调用,hystrix 容错,zuul网关
Spring Cloud Alibaba 致力于提供微服务开发的一站式解决方案。此项目包含开发分布式应用微服务的必需组件,方便开发者通过 Spring Cloud 编程模型轻松使用这些组件来开发分布式应用服务。
Spring Cloud Alibaba 致力于提供微服务开发的一站式解决方案。此项目包含开发分布式应用微服务的必需组件,方便开发者通过 Spring Cloud 编程模型轻松使用这些组件来开发分布式应用服务。
依托 Spring Cloud Alibaba,您只需要添加一些注解和少量配置,就可以将 Spring Cloud 应用接入阿里微服务解决方案,通过阿里中间件来迅速搭建分布式应用系统。
服务限流降级:默认支持 WebServlet、WebFlux, OpenFeign、RestTemplate、Spring Cloud
Gateway, Zuul, Dubbo 和 RocketMQ 限流降级功能的接入,可以在运行时通过控制台实时修
改限流降级规则,还支持查看限流降级 Metrics 监控。
服务注册与发现:适配 Spring Cloud 服务注册与发现标准nacos,默认集成了 Ribbon 的支持。
分布式配置管理:支持分布式系统中的外部化配置,配置更改时自动刷新。
消息驱动能力:基于 Spring Cloud Stream 为微服务应用构建消息驱动能力。
分布式事务:使用 @GlobalTransactional 注解, 高效并且对业务零侵入地解决分布式事务问题。
阿里云对象存储:阿里云提供的海量、安全、低成本、高可靠的云存储服务。支持在任何应用、任
何时间、任何地点存储和访问任意类型的数据。
分布式任务调度:提供秒级、精准、高可靠、高可用的定时(基于 Cron 表达式)任务调度服务。
同时提供分布式的任务执行模型,如网格任务。网格任务支持海量子任务均匀分配到所有
Worker(schedulerx-client)上执行。
阿里云短信服务:覆盖全球的短信服务,友好、高效、智能的互联化通讯能力,帮助企业迅速搭建
客户触达通道。
Sentinel:把流量作为切入点,从流量控制、熔断降级、系统负载保护等多个维度保护服务的稳
定性。
Nacos:一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台。
RocketMQ:一款开源的分布式消息系统,基于高可用分布式集群技术,提供低延时的、高可靠
的消息发布与订阅服务。
Dubbo:Apache Dubbo™ 是一款高性能 Java RPC 框架。
Seata:阿里巴巴开源产品,一个易于使用的高性能微服务分布式事务解决方案。
Alibaba Cloud ACM:一款在分布式架构环境中对应用配置进行集中管理和推送的应用配置中心
产品。
Alibaba Cloud OSS: 阿里云对象存储服务(Object Storage Service,简称 OSS),是阿里云提
供的海量、安全、低成本、高可靠的云存储服务。您可以在任何应用、任何时间、任何地点存储和
访问任意类型的数据。
Alibaba Cloud SchedulerX: 阿里中间件团队开发的一款分布式任务调度产品,提供秒级、精
准、高可靠、高可用的定时(基于 Cron 表达式)任务调度服务。
Alibaba Cloud SMS: 覆盖全球的短信服务,友好、高效、智能的互联化通讯能力,帮助企业迅速
搭建客户触达通道。
理论好好读读。
之前你维护的一体化架构就像是一个大的蜘蛛网,不同功能模块错综复杂地交织在一起,方法之间调用关系非常的复杂,导致你修复了一个 Bug 可能会引起另外多个 Bug,整体的维护成本非常高。同时,数据库较弱的扩展性也限制了服务的扩展能力
出于上述考虑,你要对架构做拆分。但拆分并不像听上去那么简单,这其实就是将整体工程重构甚至重写的过程。你需要将代码拆分到若干个子工程里面,再将这些子工程通过一些通信方式组装起来,这对架构是很大的调整,需要跨多个团队协作完成。
所以在开始拆分之前你需要明确几个拆分的原则,否则就会事倍功半甚至对整体项目产生不利的影响
原则一,做到单一服务内部功能的高内聚和低耦合。
也就是说每个服务只完成自己职责之内的任务,对于不是自己职责的功能交给其它服务来完成。说起来你可能觉得理所当然对这一点不屑一顾,但很多人在实际开发中,经常会出现一些问题。
比如,我之前的项目中有用户服务和内容服务,用户信息中有“是否为认证用户”字段。组内有个同事在内容服务里有这么一段逻辑:如果用户认证字段等于 1,代表是认证用户,那么就把内容权重提升。问题是判断用户是否为认证用户的逻辑应该内聚在用户服务内部,而不应该由内容服务判断,否则认证的逻辑一旦变更内容服务也需要一同跟着变更,这就不满足高内聚、低耦合的要求了。所幸我们在 Review 代码时及时发现了这个问题,并在服务上线之前修复了它。
原则二,你需要关注服务拆分的粒度,先粗略拆分再逐渐细化。
在服务拆分的初期,你其实很难确定服务究竟要拆分成什么样。但是从“微服务”这几个字来看,服务的粒度貌似应该足够小,甚至有“一方法一服务”的说法。不过服务多了也会带来问题,像是服务个数的增加会增加运维的成本。再比如原本一次请求只需要调用进程内的多个方法,现在则需要跨网络调用多个 RPC 服务,在性能上肯定会有所下降。
所以我推荐的做法是:拆分初期可以把服务粒度拆得粗一些,后面随着团队对于业务和微服务理解的加深,再考虑把服务粒度细化。比如对于一个社区系统来说,你可以先把和用户关系相关的业务逻辑,都拆分到用户关系服务中,之后,再把比如黑名单的逻辑独立成黑名单服务。
原则三,拆分的过程,要尽量避免影响产品的日常功能迭代。
也就是说,要一边做产品功能迭代,一边完成服务化拆分。
还是拿我之前维护的一个项目举例。我曾经在竞品对手快速发展的时期做了服务的拆分,拆分的方式是停掉所有业务开发全盘推翻重构,结果错失了产品发展的最佳机会,最终败给了竞争对手。
因此,我们的拆分只能在现有一体化系统的基础上不断剥离业务独立部署,剥离的顺序你可以参考以下几点:
1. 优先剥离比较独立的边界服务(比如短信服务、地理位置服务),从非核心的服务出发减少拆分对现有业务的影响,也给团队一个练习、试错的机会;
2. 当两个服务存在依赖关系时优先拆分被依赖的服务。比如内容服务依赖于用户服务获取用户的基本信息,那么如果先把内容服务拆分出来,内容服务就会依赖于一体化架构中的用户模块,这样还是无法保证内容服务的快速部署能力。
所以正确的做法是理清服务之间的调用关系,比如内容服务会依赖用户服务获取用户信息,互动服务会依赖内容服务,所以要按照先用户服务再内容服务,最后互动服务的顺序来进行拆分。
原则四,服务接口的定义要具备可扩展性。
服务拆分之后,由于服务是以独立进程的方式部署,所以服务之间通信就不再是进程内部的方法调用而是跨进程的网络通信了。在这种通信模型下服务接口的定义要具备可扩展性,否则在服务变更时会造成意想不到的错误。
在之前的项目中,某一个微服务的接口有三个参数,在一次业务需求开发中,组内的一个同学将这个接口的参数调整为了四个,接口被调用的地方也做了修改,结果上线这个服务后却不断报错,无奈只能回滚。
这是因为这个接口先上线后参数变更成了四个,但是调用方还未变更还是在调用三个参数的接口,那就肯定会报错了。所以服务接口的参数类型最好是封装类,这样如果增加参数就不必变更接口的签名,而只需要在类中添加字段就可以了。
我们本次是使用的电商项目中的商品微服务、订单微服务为案例进行讲解。
2.1.1技术选型
maven:3.5.0+
数据库:MySQL 5.7 以上
持久层: Mybatis-plus 《Mybatis Mapper Mybatis-plus》
其他: SpringCloud Alibaba 技术栈 druid
springcloud-alibaba 父工程 ----jar的版本管理 公共jar的引入
shop-common 公共模块【实体类】 《实体类,公共依赖,工具类。》
shop-product 商品微服务 【端口: 8080~8089 搭建集群】
shop-order 订单微服务 【端口: 8090~8099 搭建集群】
在微服务架构中,最常见的场景就是微服务之间的相互调用。我们以电商系统中常见的用户下单为
例来演示微服务的调用:客户向订单微服务发起一个下单的请求,在进行保存订单之前需要调用商品微服务查询商品的信息。
我们一般把服务的主动调用方称为服务消费者,把服务的被调用方称为服务提供者。
在这种场景下,订单微服务就是一个服务消费者, 商品微服务就是一个服务提供者。
创建一个maven工程,然后在pom.xml文件中添加下面内容
https://github.com/alibaba/spring-cloud-alibaba/wiki/%E7%89%88%E6%9C%AC%E8%AF%B4%E6%98%8E
4.0.0
com.ykq
springcloud-alibaba
1.0-SNAPSHOT
org.springframework.boot
spring-boot-starter-parent
2.3.2.RELEASE
1.8
UTF-8
UTF- 8
Hoxton.SR8
2.2.3.RELEASE
org.springframework.cloud
spring-cloud-dependencies
${spring-cloud.version}
pom
import
com.alibaba.cloud
spring-cloud-alibaba-dependencies
${spring-cloud-alibaba.version}
pom
import
版本对应:
1 创建 shop-common 模块,在pom.xml中添加依赖
springcloud-alibaba
com.ykq
1.0-SNAPSHOT
4.0.0
shop-common
com.baomidou
mybatis-plus-boot-starter
3.4.1
org.projectlombok
lombok
com.alibaba
fastjson
1.2.56
mysql
mysql-connector-java
2 创建实体类(entity)
分别是product类和order类
@Data
@TableName(value="shop_product")
public class Product {
@TableId(type= IdType.AUTO)
private Integer pid;
private String pname;//商品名称
private Double pprice;//商品价格
private Integer stock;//库存
}
@Data
@TableName("shop_order")
public class Order {
@TableId(type = IdType.AUTO)
private Long oid; //订单id
private Integer uid;//用户id
private String username;//用户名
private Integer pid;//商品id
private String pname;//商品名称
private Double pprice;//商品价格
private Integer number;//购买数量
}
步骤:
1 创建模块 导入依赖
2 创建SpringBoot主类
3 加入配置文件
4 创建必要的接口和实现类(controller service dao)
新建一个 springcloud-product 模块,然后进行下面操作
1 创建pom.xml
springcloud-alibaba
com.ykq
1.0-SNAPSHOT
4.0.0
shop-user
com.ykq
shop-common
1.0-SNAPSHOT
2 编写主启动类
@SpringBootApplication
public class ProductApplication {
public static void main(String[] args) {
SpringApplication.run(ProductApplication.class,args);
}
}
3 创建配置文件
server:
port: 8081
spring:
application:
name: springcloud-product
# 配置数据源
datasource:
url: jdbc:mysql://localhost:3306/shop?serverTimezone=UTC&useUnicode=true&characterEncoding=utf-8&useSSL=true
driver-class-name: com.mysql.cj.jdbc.Driver
username: root
password: root
jpa:
properties:
hibernate:
hbm2ddl:
auto: update
dialect: org.hibernate.dialect.MySQL5InnoDBDialect
4 创建ProductDao接口
@Mapper
public interface ProductMapper extends BaseMapper {
}
5 创建ProductService接口
public interface ProductService {
CommonResult findProductByPid(Integer pid);
}
6 创建ProductServiceImpl实现类
@Service
public class ProductServiceImpl {
@Autowired
private ProductMapper productMapper;
public CommonResult findProductByPid(Integer pid){
Product product = productMapper.selectById(pid);
if(product != null){
return new CommonResult(2000,"查找商品成功",product);
}
return new CommonResult(5000,"查找商品失败",null);
}
}
7 创建ProductController类
@RestController
@RequestMapping(value = "product")
public class ProductController {
@Autowired
private ProductServiceImpl productService;
//根据商品id查找商品信息
@RequestMapping(value ="/findProductByPid/{pid}")
public CommonResult findProductByPid(@PathVariable Integer pid){
return productService.findProductByPid(pid);
}
}
1. 创建一个名为 springcloud-order 的模块,并添加springboot依赖
springcloud-alibaba
com.ykq
1.0-SNAPSHOT
4.0.0
shop-product
com.ykq
shop-common
1.0-SNAPSHOT
org.springframework.boot
spring-boot-starter-web
2 创建工程的主启动类
@SpringBootApplication
public class OrderApplication {
public static void main(String[] args) {
SpringApplication.run(OrderApplication.class,args);
}
}
3 创建配置文件application.yml
spring:
datasource:
driver-class-name: com.mysql.cj.jdbc.Driver
url: jdbc:mysql://localhost:3306/springcloud?serverTimezone=Asia/Shanghai
username: root
password: root
server:
port: 8091
4 创建OrdertDao接口
@Mapper
public interface OrderMapper extends BaseMapper {
}
5. 创建OrderService接口
public interface ProductService {
public CommonResult insertOrder(Integer pid);
}
6.创建OrderServiceImpl实现类
public CommonResult insertOrder(Integer pid,Integer num ) {
order order = new order();
order.setNumber(num);
order.setUid(1);
order.setUsername("annie");
System.out.println("开始生成订单");
System.out.println(productFeign+"dddddddddddddddddddd");
CommonResult forObject = productFeign.findProductByPid(pid);
System.out.println("7777777777777777777"+forObject);
Object data = forObject.getData();
Map map = (Map) data;
System.out.println(map+"ddddddddddddd");
String pname = (String) map.get("pname");
Double pprice = (Double) map.get("pprice");
Integer pid1 = (Integer) map.get("pid");
order.setPname(pname);
order.setPprice(pprice);
order.setPid(pid1);
final int insert = orderMapper.insert(order);
if(insert>0){
return new CommonResult(2000,"增加订单成功",null);
}
return new CommonResult(5000,"增加订单失败",null);
}
}
7 创建OrderController类
@RestController
@RequestMapping(value = "order")
public class OrderController {
@Autowired
private OrderServiceImpl orderService;
@RequestMapping(value = "insertOrder/{pid}/{num}")
public CommonResult insertOrder(@PathVariable Integer pid,@PathVariable Integer num){
return orderService.insertOrder(pid,num);
}
}
8 启动工程,等到数据库表创建完毕之后,加入测试数据
INSERT INTO shop_product VALUE(NULL,'小米','1000','5000');
INSERT INTO shop_product VALUE(NULL,'华为','2000','5000');
INSERT INTO shop_product VALUE(NULL,'苹果','3000','5000');
INSERT INTO shop_product VALUE(NULL,'OPPO','4000','5000');
9.通过浏览器访问服务
未完待续.............