架构演变进程:单体 -> 分布式系统(微服务架构)

一、单体应用架构

1.概念:一个应用中包含了应用程序所有的功能(比如:页面、代码、配置等)把应用程序打包成war包、jar包部署到Tomcat中,通常称之为单体架构;

2.优缺点:

(1)优点:便于共享,易于测试,易于部署;

(2)缺点:代码间关系复杂,难以理解和维护;项目体积变大,开发、测试、部署的过程都无比困难;无法使用新框架;可靠性下降。

3.解决单体应用缺点方案:——一个单体应用拆分成多个服务,每个服务有自己独立的数据库;单个服务的复杂度降低;服务与服务之间需要通信,协调。

二、微服务架构

1.概念:微服务架构风格这种开发方法,是以开发一组小型服务的方式来开发一个独立的应用系统。其中每个小型服务都运行在自己的进程中,并经常采用HTTP资源API这样轻量的机制来相互通信。这些服务围绕业务功能进行构建,并能通过全自动的部署机制来进行独立部署。这些微服务可以使用不同的语言来编写,并且可以使用不同的数据存储技术。对这些微服务,我们仅做最低限度的集中管理。                                                                —— 世界级软件架构大师 Martin Fowler

架构演变进程:单体 -> 分布式系统(微服务架构)_第1张图片

 2.优点:

        (1)易于开发和维护:一个微服务只会关注一个特定的业务功能,所以业务清晰、代码量较少。开发和维护单个微服务相对简单。
        (2)单个微服务启动较快
        (3)局部修改容易部署:单体应用只要有修改,就得重新部署整个应用。微服务解决了这样的问题。一般来说,对某个微服务进行修改,只需要重新部署这个服务即可。
        (4)技术栈不受限制:在微服务架构中,可以结合项目业务及团队的特点,合理的选择技术栈。
        (5)按需伸缩:可根据需求,实现细粒度的扩展。

3.缺点:

        (1)运维要求高:更多的服务意味着要投入更多的运维。
        (2)分布式固有的复杂性:使用微服务构建的是分布式系统。对于一个分布式系统,系统容错、网络延迟、分布式事务等都会带来巨大的问题。
        (3)接口调整成本高:微服务之间通过接口进行通信。如果修改某一个微服务的API,可能所有用到这个接口的微服务都需要进行调整。

三、分布式系统

1。概念:分布式系统就是一组部署在同一个网络下的多个通过网络来通信和协调的组件,对外部而言表现的如同一个系统

2.分类:

        (1)可以指多个不同组件分布在网络上互相协作,比如前例所说的电商网站;

架构演变进程:单体 -> 分布式系统(微服务架构)_第2张图片

 

        (2)也可以一个组件的多个副本组成集群,互相协作如同一个组件,比如数据存储服务中为了数据不丢失而采取的多个服务备份冗余,当数据修改时也需要通信来复制数据

架构演变进程:单体 -> 分布式系统(微服务架构)_第3张图片

 3.结论:

        (1)微服务架构 是 分布式系统,分布式系统不一定是微服务架构;

        (2)应用系统当中,这两种的集群模式都有出现。

四、CAP原理

1.概念:1998年,加州大学的计算机科学家 Eric Brewer 提出,分布式系统有三个指标,CAP,而这三个指标无法同时满足,这个结论称为CAP定理。

2.三大指标:Consistency 一致性、Availability 可用性、Partition tolerance 分区容错性;

架构演变进程:单体 -> 分布式系统(微服务架构)_第4张图片

 2.1、Consistency——一致性

        致性是指,在分布式系统中的所有数据备份,在同一时刻是否同样的值。(等同于访问任一节点得到的都是最新的数据副本)。

架构演变进程:单体 -> 分布式系统(微服务架构)_第5张图片

  2.2、Availability——可用性

        可用性是指,在集群中一部分节点故障后,集群整体是否还能正常响应客户端的读写请求。(对数据更新具备高可用性)。

架构演变进程:单体 -> 分布式系统(微服务架构)_第6张图片

 2.3、Partition tolerance——分区容错性

        分区容错性是指 系统必须能够处理组件之间因为通信失败(或者延迟)而造成分区的情况。通信出现故障就会形成多个分区,此时系统无法同时保证数据的一致性和可用性。

(例)继续以三个节点的存储系统为例,若是S1与另外两个节点的通信出现问题,那么就形成了S1和S2+S3两个分区,此时数据必然无法达成一致性。

此时有两个解决方案

一是暂停或关闭所有节点,等待网络恢复,数据达成一致,这样保证了数据一致性。

另一个是继续提供服务,保证可用性,那么访问S1和访问S2、S3得到的将会不同的数据,不满足一致性

无论使用哪一种方案,都无法保证CAP同时成立。

架构演变进程:单体 -> 分布式系统(微服务架构)_第7张图片

 五、BASE原理

        Basically Available(基本可用)

        Soft state(软状态)

        Eventually consistent(最终一致性)

        在分布式系统设计中引入柔性因素,降低设计和实现的难度,但又不影响基本使用;

        设计上的妥协和折中

六、Spring-Cloud

1、概念:微服务架构工具集,提供了搭建微服务架构所需用的各种工具,借由这些工具,开发人员可以快速的搭建一个微服务架构。

 Spring Cloud 为开发者提供了工具来快速构建分布式系统中的一些常见模式(例如配置管理、服务发现、断路器、智能路由、微代理、控制总线、一次性令牌、全局锁、领导选举、分布式会话,集群状态)。分布式系统协调存在一些通用模式,使用 Spring Cloud 开发人员可以快速建立实现这些模式的服务和应用程序。它们在任何分布式环境中都能很好地工作,包括开发人员自己的笔记本电脑、裸机数据中心以及 Cloud Foundry 等托管平台。

Spring Cloud称为 伞形项目,由多个子项目组成

2、Spring Cloud下的三个重要子项目:

        (1)spring-cloud-netflix——spring-cloud第一个子项目,应用广泛;

        (2)spring-cloud-alibaba——阿里巴巴出品,国产,中文,符合中国国情,在国内采用比较多;

        (3)spring-cloud官方组件

3、项目技术选型:

  • 服务发现: nacos
  • 负载均衡: ribbon
  • 服务容错:sentinel
  • 配置管理:nacos
  • 服务调用:openfeign
  • 服务网关: spring-cloud-gateway
  • 分布式事务:seata
  • 消息队列:rocketmq
  • 搜索引擎: elasticsearch
  • 服务追踪: zipkin
  • 部署:docker + k8s

注:选用不同子项目的不同组件来搭建架构,不同组件之间是兼容的(都在spring-cloud之下)。

你可能感兴趣的:(Java微服务,分布式,架构,java)