✨ Spring Cloud:微服务基础知识

一、系统架构演变1. 单体应用架构2. 垂直应用架构3. 分布式架构4. SOA架构4.1 SOA概念4.2 SOA

5.微服务架构6.SOA和微服务架构的关系

2.分布式核心知识1.分布式中的远程调用1.1RESTFUL接口1.2RPC协议1.3二者的区别与联系

2.分布式中的CAP原理

个人主页:不断前进的皮卡丘

博客描述:梦想也许遥不可及,但重要的是追梦的过程,用博客记录自己的成长,记录自己一步一步向上攀登的印记

个人专栏:微服务专栏

一、系统架构演变

随着互联网的发展,网站应用的规模不断扩大,常规的应用架构已无法应对,分布式服务架构以及微服务架构势在必行,亟需一个治理系统确保架构有条不紊的演进。

1. 单体应用架构

在企业发展的初期,一般公司的网站流量都比较小,只需要一个应用,将所有的功能代码打包成一个服务,部署到服务器上就能支撑公司的业务。这样也能够减少开发、部署和维护的成本。 比如搭建一个电商系统:客户下订单,商品展示,用户管理。这种将所有功能都部署在一个web容器中运行的系统就叫做单体架构。

Web应用程序发展的早期,大部分web工程(包含前端页面,web层代码,service层代码,dao层代码)是将所有的功能模块,打包到一起并放在一个web容器中运行。

单体架构优点 1.所有的功能集成在一个项目工程中 2.项目架构简单,前期开发成本低,周期低,是小型项目的首选

单体架构缺点 1.所有功能集成在一个工程中,对于大型项目不容易开发、扩展和维护,如果需要修改、新增某一个功能的话,需要对整个系统进行测试,重新部署。 2.系统性能扩展只能通过扩展集群节点,成本高,有瓶颈 3.一个模块出现问题,可能导致整个系统崩溃。 4.各个模块使⽤同⼀种技术框架,局限性太大,很难根据业务选择最适合的技术架构。 5.多团队同时对数据进行管理,容易产生安全漏洞。 6.模块内容太复杂,如果员工离职,可能需要很长时间才能完成任务交接。

2. 垂直应用架构

随着企业业务的不断发展,发现单节点的单体应用不足以支撑业务的发展,于是企业会将单体应用部署多份,分别放在不同的服务器上。但是,此时会发现不是所有的模块都会有比较大的访问量。如果想针对项目中的某些模块进行优化和性能提升,此时对于单体应用来说,是做不到的。因此,垂直应用架构诞生了。 垂直应用架构,就是将原来一个项目应用进行拆分,将其拆分为互不想干的几个应用,以此来提升系统的整体性能。

我们将单体应用架构拆分为垂直应用架构之后,一旦访问量变大,我们只需要针对访问量大的业务增加服务器节点即可,无需针对整个项目增加服务器节点了。

优点: 项目架构简单,前期开发成本低,周期短,小型项目的首选。 通过垂直拆分,原来的单体项目不至于无限扩大 不同的项目可采用不同的技术。 各系统能够分担整体访问的流量,解决了并发问题。 一个系统发生了故障,不应用其他系统的运行情况,提高了整体的容错率。 缺点: 拆分后的各系统之间相对比较独立,无法进行互相调用。 各系统难免存在重叠的业务,会存在重复开发的业务,后期维护比较困难。

3. 分布式架构

我们将系统演变为垂直应用架构之后,当垂直应用越来越多,重复编写的业务代码就会越来越多。此时,我们需要将重复的代码抽象出来,形成统一的服务供其他系统或者业务模块来进行调用。此时,系统就会演变为分布式架构。 在分布式架构中,我们会将系统整体拆分为服务层和表现层。服务层封装了具体的业务逻辑供表现层调用,表现层则负责处理与页面的交互操作。

优点:提高代码的复用性 缺点:耦合度变高,调用关系变得复杂

4. SOA架构

4.1 SOA概念

如何通俗易懂地解释什么是SOA? SOA 全称为 Service-Oriented Architecture,即面向服务的架构。它可以根据需求通过网络对松散耦合的粗粒度应用组件(服务)进行分布式部署、组合和使用。一个服务通常以独立的形式存在于操作系统进 程中。 站在功能的角度,把业务逻辑抽象成可复用、可组装的服务,通过服务的编排实现业务的快速再生,目的:把原先固有的业务功能转变为通用的业务服务,实现业务逻辑的快速复用。 通过上面的描述可以发现 SOA 有如下几个特点:分布式、可重用、扩展灵活、松耦合

4.2 SOA

在分布式架构下,当部署的服务越来越多,重复的代码就会越来越多,对于容量的评估,小服务资源的浪费等问题比较严重。此时,我们就需要增加一个统一的调度中心来对集群进行实时管理。此时,系统就会演变为SOA(面向服务)的架构。

优点: 抽取公共的功能为服务,提高开发效率 对不同的服务进行集群化部署解决系统压力 基于ESB/DUBBO减少系统耦合 缺点: 抽取服务的粒度较大 服务提供方与调用方接口耦合度较高

5.微服务架构

微服务是什么 微服务是一种架构模式,它提倡把单一应用程序划分成一组小的服务,服务之间互相协调、互相配合,为用户提供最终价值。每个服务运行在其独立的进程中,服务之间采用轻量级的通信机来互相协作(通常是基于HTTP协议的RESTful API),每一个服务都围绕在具体业务进行构建,并且能够被独立的部署到生产环境、类生产环境等。而且,我们应尽量避免统一的、集中式的服务管理机制,对具体的一个来说,应该要根据业务上下文,选择合适的语言、工具来进行构建。

所谓“服务”,其实指的是项目中的功能模块,它可以帮助用户解决某一个或一组问题,在开发过程中表现为 IDE(集成开发环境,例如 Eclipse 或 IntelliJ IDEA)中的一个工程或 Moudle。 “微小”则强调的是单个服务的大小,主要体现为以下两个方面:

微服务体积小,复杂度低:一个微服务通常只提供单个业务功能的服务,即一个微服务只专注于做好一件事,因此微服务通常代码较少,体积较小,复杂度也较低。微服务团队所需成员少:一般情况下,一个微服务团队只需要 8 到 10 名人员(开发人员 2 到 5 名)即可完成从设计、开发、测试到运维的全部工作。

每个服务都能够独立地部署到各种环境中,例如开发环境、测试环境和生产环境等,每个服务都能独立启动或销毁而不会对其他服务造成影响。

优点:

通过服务的原子化拆分,以及微服务的独立打包、部署和升级,小团队的交付周期将缩短,运维成

本也将大幅度下降

微服务遵循单一原则。微服务之间采用Restful等轻量协议传输。

缺点:

微服务过多,服务治理成本高,不利于系统维护。分布式系统开发的技术成本高(容错、分布式事务等)。如果某个系统的远程调⽤出现问题,导致微服务不可⽤,就有可能产⽣级联反应,造成整个系统的

崩溃。

6.SOA和微服务架构的关系

2.分布式核心知识

1.分布式中的远程调用

在微服务架构中,通常存在多个服务之间的远程调用的需求。远程调用通常包含两个部分:序列化和通 信协议。常见的序列化协议包括json、xml、hession、protobuf、thrift、text、bytes等,目前主流的 远程调用技术有基于HTTP的RESTful接口以及基于TCP的RPC协议。

1.1RESTFUL接口

REST,即Representational State Transfer的缩写,如果一个架构符合REST原则,就称它为RESTful架构。 资源(Resources) 所谓"资源",就是网络上的一个实体,或者说是网络上的一个具体信息。它可以是一段文本、一张图 片、一首歌曲、一种服务,总之就是一个具体的实在。你可以用一个URI(统一资源定位符)指向它, 每种资源对应一个特定的URI。要获取这个资源,访问它的URI就可以,因此URI就成了每一个资源的地 址或独一无二的识别符。REST的名称"表现层状态转化"中,省略了主语。“表现层"其实指的是"资 源”(Resources)的"表现层"。 表现层(Representation) “资源"是一种信息实体,它可以有多种外在表现形式。我们把"资源"具体呈现出来的形式,叫做它的"表现层”(Representation)。比如,文本可以用txt格式表现,也可以用HTML格式、XML格式、JSON格式表现,甚至可以采用二进制格式;图片可以用JPG格式表现,也可以用PNG格式表现。URI只代表资源 的实体,不代表它的形式。严格地说,有些网址最后的".html"后缀名是不必要的,因为这个后缀名表示 格式,属于"表现层"范畴,而URI应该只代表"资源"的位置。 状态转化(State Transfer) 访问一个网站,就代表了客户端和服务器的一个互动过程。在这个过程中,势必涉及到数据和状态的变 化。互联网通信协议HTTP协议,是一个无状态协议。这意味着,所有的状态都保存在服务器端。因 此,如果客户端想要操作服务器,必须通过某种手段,让服务器端发生"状态转化"(State Transfer)。 客户端用到的手段,只能是HTTP协议。具体来说,就是HTTP协议里面,四个表示操作方式的动词: GET、POST、PUT、DELETE。它们分别对应四种基本操作:**GET用来获取资源,POST用来新建资源 **(也可以用于更新资源),PUT用来更新资源,DELETE用来删除资源。

综合上面的解释,我们总结一下什么是RESTful架构:

每一个URI代表一种资源;客户端和服务器之间,传递这种资源的某种表现层;客户端通过四个HTTP动词,对服务器端资源进行操作,实现"表现层状态转化"。

1.2RPC协议

RPC(Remote Procedure Call ) 一种进程间通信方式。允许像调用本地服务一样调用远程服务。RPC 框架的主要目标就是让远程服务调用更简单、透明。RPC框架负责屏蔽底层的传输方式(TCP或者 UDP)、序列化方式(XML/JSON/二进制)和通信细节。开发人员在使用的时候只需要了解谁在什么 位置提供了什么样的远程服务接口即可,并不需要关心底层通信细节和调用过程。

1.3二者的区别与联系

1、HTTP相对更规范,更标准,更通用,无论哪种语言都支持http协议。如果你是对外开放API,例如 开放平台,外部的编程语言多种多样,你无法拒绝对每种语言的支持,现在开源中间件,基本最先支持 的几个协议都包含RESTful。 2、 RPC 框架作为架构微服务化的基础组件,它能大大降低架构微服务化的成本,提高调用方与服务提 供方的研发效率,屏蔽跨进程调用函数(服务)的各类复杂细节。让调用方感觉就像调用本地函数一样 调用远端函数、让服务提供方感觉就像实现一个本地函数一样来实现服务。

2.分布式中的CAP原理

分布式中的CAP原理

1.分布式系统一定是由多个节点组成的系统。其中,节点指的是计算机服务器,而且这些节点一般不是孤立的,而是互通的。 2.这些连通的节点上部署了我们的节点,并且相互的操作会有协同。

分布式系 统的最大难点,就是各个节点的状态如何同步。CAP 定理是这方面的基本定理,也是理解分布式系统的 起点。 CAP理论由 Eric Brewer 在ACM研讨会上提出,而后CAP被奉为分布式领域的重要理论。分布式系统的 CAP理论,首先把分布式系统中的三个特性进行了如下归纳:

通过学习CAP理论,我们得知任何分布式系统只可同时满足二点,没法三者兼顾,既然一个分布式系统无法同时满足一致性、可用性、分区容错性三个特点,所以我们就需要抛弃一样:

文章链接

评论可见,请评论后查看内容,谢谢!!!
 您阅读本篇文章共花了: