微服务架构和网络架构(微服务架构和分布式架构)

网络设计 322
今天给各位分享微服务架构和网络架构的知识,其中也会对微服务架构和分布式架构进行解释,如果能碰巧解决你现在面临的问题,别忘了关注本站,现在开始吧!本文目录一览: 1、架构类型以及软件架构逻辑详解

今天给各位分享微服务架构和网络架构的知识,其中也会对微服务架构和分布式架构进行解释,如果能碰巧解决你现在面临的问题,别忘了关注本站,现在开始吧!

本文目录一览:

架构类型以及软件架构逻辑详解

架构类型:分布式、SOA架构、单体式。

分布式架构

分布式应用架构中,相互独立,代码独立开发,独立部署,通过API接口互相通信。通讯协议一般使用HTTP,数据格式是JSON(是一种轻量级的数据交换格式),应用集成方式比较简化。

优点: 应用内部高内聚,独立开发、测试和部署,应用之间松耦合,业务边界清晰,业务依赖明确,支持大项目并行开发。

缺点: API接口需求变化,应用就需要重新部署,通信可靠性和数据的封装性相对于进程内调用比较差。

SOA架构[现在也流程SAAS服务模式架构也称云架构]

SOA也是分布式应用架构一种。

SOA架构提供配套的服务治理,包括服务注册、服务路由、服务授权、服务降级、服务监控等等。

SOA架构既体现业务的拆分,又体现业务的整合,更多地从业务整体上考虑系统拆分。

优点:以服务层为主,聚焦核心业务,同时以提供整个系统共享,服务作为独立的应用,独立部署,接口清晰,很容易做自动化测试和部署,服务是无状态的,很容易做水平扩展;通过容器虚拟化技术,实现故障隔离和***高效利用。

缺点:系统依赖复杂,给开发/测试/部署带来不便,分布式数据一致性和分布式事务支持困难,一般通过最终一致性简化解决。

单体式应用

系统只有一个应用、打包成一个应用;部署在一台机器;在一个DB里存储数据.

单体式应用***用分层架构,一般为表示层、业务层、数据访问层、DB层,表示层负责用户体验,业务层负责业务逻辑,数据访问层负责DB层的数据存取

优点:开发、编译、调试一站式、一个应用程序包含所有功能点,容易测试和部署

缺点:系统逐渐庞大时,代码复杂度高,难以维护,应用扩展水平低,业务和模块职责区分不清晰。

软件架构

一、 微服务架构

微服务架构(microservices architecture)是服务导向架构(service-oriented architecture,缩写 SOA)的升级。

每一个服务就是一个独立的部署单元(separately deployed unit)。这些单元都是分布式的,互相解耦,通过远程通信协议(比如REST、SOAP)联系。

微服务架构分成三种实现模式。

RESTful API 模式 :服务通过 API 提供,云服务就属于这一类

RESTful 应用模式 :服务通过传统的网络协议或者应用协议提供,背后通常是一个多功能的应用程序,常见于企业内部

集中消息模式 :***用消息代理(message broker),可以实现消息队列、负载均衡、统一日志和异常处理,缺点是会出现单点失败,消息代理可能要做成集群

优点

扩展性好,各个服务之间低耦合

容易部署,软件从单一可部署单元,被拆成了多个服务,每个服务都是可部署单元

容易开发,每个组件都可以进行持续集成式的开发,可以做到实时部署,不间断地升级

易于测试,可以单独测试每一个服务

缺点

由于强调互相独立和低耦合,服务可能会拆分得很细。这导致系统依赖大量的微服务,变得很凌乱和笨重,性能也会不佳。

一旦服务之间需要通信(即一个服务要用到另一个服务),整个架构就会变得复杂。典型的例子就是一些通用的 Utility 类,一种解决方案是把它们拷贝到每一个服务中去,用冗余换取架构的简单性。

分布式的本质使得这种架构很难实现原子性操作,交易回滚会比较困难。

二、 ***驱动架构

***(event)是状态发生变化时,软件发出的通知。

***驱动架构(event-driven architecture)就是通过***进行通信的软件架构。它分成四个部分。

***队列(event queue):接收***的入口。

分发器(event mediator):将不同的***分发到不同的业务逻辑单元。

***通道(event channel):分发器与处理器之间的联系渠道。

***处理器(event processor):实现业务逻辑,处理完成后会发出***,触发下一步操作

对于简单的项目,***队列、分发器和***通道,可以合为一体,整个软件就分成***代理和***处理器两部分。

优点

分布式的异步架构,***处理器之间高度解耦,软件的扩展性好;适用性广,各种类型的项目都可以用;性能较好,因为***的异步本质,软件不易产生堵塞;***处理器可以独立地加载和卸载,容易部署

缺点

涉及异步编程(要考虑远程通信、失去响应等情况),开发相对复杂难以支持原子性操作,因为***通过会涉及多个处理器,很难回滚分布式和异步特性导致这个架构较难测试。

三、分层架构。

分层架构(layered architecture)是最常见的软件架构,也是事实上的标准架构。如果你不知道要用什么架构,那就用它。

这种架构将软件分成若干个水平层,每一层都有清晰的角色和分工,不需要知道其他层的细节。层与层之间通过接口通信。

虽然没有明确约定,软件一定要分成多少层,但是四层的结构最常见。

表现层(presentation):用户界面,负责视觉和用户互动。

业务层(business):实现业务逻辑。

持久层(persistence):提供数据,SQL 语句就放在这一层。

数据库(database) :保存数据。

有的软件在逻辑层和持久层之间,加了一个服务层(service),提供不同业务逻辑需要的一些通用接口。

用户的请求将依次通过这四层的处理,不能跳过其中任何一层。

优点

1、结构简单,容易理解和开发。

2、不同技能的程序员可以分工,负责不同的层,天然适合大多数软件公司的组织架构

3、每一层都可以独立测试,其他层的接口通过模拟解决

缺点

1、一旦环境变化,需要代码调整或增加功能时,通常比较麻烦和费时

2、部署比较麻烦,即使只修改一个小地方,往往需要整个软件重新部署,不容易做持续发布

软件升级时,可能需要整个服务暂停

3、扩展性差。用户请求大量增加时,必须依次扩展每一层,由于每一层内部是耦合的,扩展会很困难。

五、 微核架构。

微核架构(microkernel architecture)又称为"插件架构"(plug-in architecture),指的是软件的内核相对较小,主要功能和业务逻辑都通过插件实现。

内核(core)通常只包含系统运行的最小功能。插件则是互相独立的,插件之间的通信,应该减少到最低,避免出现互相依赖的问题。

优点

1、良好的功能延伸性(extensibility),需要什么功能,开发一个插件即可

2、功能之间是隔离的,插件可以独立的加载和卸载,使得它比较容易部署,

3、可定制性高,适应不同的开发需要

4、可以渐进式地开发,逐步增加功能

缺点

1、扩展性(scalability)差,内核通常是一个独立单元,不容易做成分布式

2、开发难度相对较高,因为涉及到插件与内核的通信,以及内部的插件登记机制。

五、 云架构。

云结构(cloud architecture)主要解决扩展性和并发的问题,是最容易扩展的架构。

它的高扩展性,主要原因是没使用中央数据库,而是把数据都***到内存中,变成可***的内存数据单元。然后,业务处理能力封装成一个个处理单元(prcessing unit)。访问量增加,就新建处理单元;访问量减少,就关闭处理单元。由于没有中央数据库,所以扩展性的最大瓶颈消失了。由于每个处理单元的数据都在内存里,最好要进行数据持久化。

这个模式主要分成两部分:处理单元(processing unit)和虚拟中间件(virtualized middleware)。

处理单元:实现业务逻辑

虚拟中间件:负责通信、保持sessions、数据***、分布式处理、处理单元的部署。

微服务架构 vs SOA架构

一、面向服务的架构SOA

面向服务的架构是一种软件体系结构,应用程序的不同组件通过网络上的通信协议向其他组件提供服务。通信可以是简单的数据传递,也可以是两个或多个服务彼此协调连接。这些独特的服务执行一些小功能,例如验证付款、创建用户 帐户 或提供社交登录等。

面向服务的架构不太关于如何对应用程序进行模块化构建,更多的是关于如何通过分布式、单独维护和部署的软件组件的集成来组成应用程序。这些通过技术和标准来实现,通过技术和标准使得组件能够更容易地通过网络(尤其是IP网络)进行通信和协作。

SOA架构中有两个主要角色: 服务提供者(Provider)和服务使用者(Consumer)。 而软件代理则可以 扮演这 两个角色。该Consumer层是用户(人、应用程序或第三方的其它组件)与SOA交互的点,和Provider层则由SOA架构内的所有服务所构成。

SOA首先在90年代中期得名,当时一家名为Gartner Group的公司认识到了这个软件架构的新趋势,并在全球推广。通过这样做,他们设法大大加快了这种架构模式的***用和进一步发展。然而,使用分布式服务作为软件体系结构的最早记录可追溯到二十世纪80年代初。

二、微服务架构

微服务架构在某种程度上是面向服务的架构SOA继续发展的下一步。基本上,这种架构类型是开发软件,网络或移动应用程序作为独立服务套件(又称微服务)的一种特殊方式。这些服务的创建仅限于一个特定的业务功能,如用户管理、用户角色、电子商务车、搜索引擎、社交媒体登录等。此外,它们是完全独立的,也就是说它们可以写入不同的编程语言并使用不同的数据库。集中式服务管理几乎不存在,微服务使用轻量级HTTP、REST或Thrift API进行通信。

这个词本身起源于2011年5月在*** 附近举行的软件架构师研讨会。他们第一次使用“微服务”这个术语来描述参与者看到的一个共同的架构风格,其中许多参会者都在 探索 相似的内容。2012年5月,同一个团队决定将“微服务”作为最合适的名称。然而实际上,微软、亚马逊、Netflix和Facebook等主要的 科技 公司已经在微服务架构方面工作了十多年。

乍一看,微服务架构似乎谈论的是与SOA相同的事情。不过,如果引用微软服务领域的先驱Martin Flower的话,他曾经说过,“我们应该把SOA看作微服务的超集”。

那么,差异在哪里呢?可以说,两种架构比起不同的架构有更多的相似之处,然而,它们是两种不同类型的架构。下面会详细分析这一点。

三、SOA vs. MicroServices

下面进一步解释下表所述的不同之处:

开发方面 - 在这两种体系结构中,可以使用不同的编程语言和工具开发服务,从而将技术多样性带入开发团队。开发可以在多个团队中组织,但是在SOA中,每个团队都需要了解常见的通信机制。另一方面,使用微服务,服务可以独立于其他服务运行和部署。因此,频繁部署新版本的微服务或独立扩展服务会更容易。您可以在这里进一步阅读有关微服务的这些好处。

“上下文边界” - SOA鼓励组件的共享,而微服务尝试通过“上下文边界”来最小化共享。上下文边界是指以最小的依赖关系将组件及其数据耦合为单个单元。由于SOA依靠多个服务来完成业务请求,构建在SOA上的系统可能比微服务要慢。

通信 - 在SOA中, ESB可能成为影响整个系统的单一故障点。由于每个服务都通过ESB进行通信,如果其中一个服务变慢,可能会阻塞ESB并请求该服务。另一方面,微服务在容错方面要好得多。例如,如果一个微服务存在内存错误,那么只有该微服务会受到影响。所有其他微服务将继续定期处理请求。

互操作性 - SOA 通过消息中间件组件促进了多种异构协议的使用。微服务试图通过减少集成选择的数量来简化架构模式。 因此,如果您想要在异构环境中使用不同协议来集成多个系统,则需要考虑SOA。如果您的所有服务都可以通过相同的远程访问协议访问,那么微服务对您来说是一个更好的选择。

大小Size - 最后一点但并非最不重要的一点,SOA和微服务的主要区别在于规模和范围。微服务架构中的前缀“微”是指内部组件的粒度,意味着它们必须比SOA架构的服务往往要小得多。微服务中的服务组件通常有一个单一的目的,他们做得很好。另一方面,在SOA服务中通常包含更多的业务功能,并且通常将它们实现为完整的子系统。

四、结论

我们不能简单地说一种架构比另一种架构更好。这主要取决于您正在构建的应用程序的目的。SOA更适合需要与许多其他应用程序集成的大型复杂企业应用程序环境。这就是说,小型应用程序不适合SOA架构,因为它们不需要消息中间件组件。而微服务架构,在另一方面,是更适合于较小和良好的分割,基于Web的系统。另外,如果您正在开发移动或Web应用程序,那么微服务作为开发人员可以为您提供更大的控制权。最后,我们可以得出结论,因为它们服务于不同的目的,微服务和SOA确实是不同类型的体系结构。

微服务架构是什么?

微服务架构是一项在云中部署应用和服务的新技术。

大部分围绕微服务的争论都集中在容器或其他技术是否能很好的实施微服务,而红帽说API应该是重点。

微服务架构相关介绍:

微服务可以在“自己的程序”中运行,并通过“轻量级设备与HTTP型API进行沟通”。关键在于该服务可以在自己的程序中运行。通过这一点我们就可以将服务公开与微服务架构(在现有系统中分布一个API)区分开来。

在服务公开中,许多服务都可以被内部独立进程所限制。如果其中任何一个服务需要增加某种功能,那么就必须缩小进程范围。在微服务架构中,只需要在特定的某种服务中增加所需功能,而不影响整体进程的架构。

微服务不需要像普通服务那样成为一种独立的功能或者独立的***。定义中称,微服务是需要与业务能力相匹配,这种说法完全正确。不幸的是,仍然意味着,如果能力模型粒度的设计是错误的,那么,我们就必须付出很多代价。

如果你阅读了Fowler的整篇文章,你会发现,其中的指导建议是非常实用的。在决定将所有组件组合到一起时,开发人员需要非常确信这些组件都会有所改变,并且规模也会发生变化。服务粒度越粗,就越难以符合规定原则。

服务粒度越细,就越能够灵活地降低变化和负载所带来的影响。然而,利弊之间的权衡过程是非常复杂的,我们要在配置和资金模型的基础上考虑到基础设施的成本问题。

微服务架构的优缺点

微服务架构的优缺点具体如下:

优点:服务的独立部署:每个服务都是一个独立的项目,可以独立部署,不依赖于其他服务,耦合性低;服务的快速启动:拆分之后服务启动的速度必然要比拆分之前快很多,因为依赖的库少了,代码量也少了。

更加适合敏捷开发:敏捷开发以用户的需求进化为核心,***用迭代、循序渐进的方法进行。服务拆分可以快速发布新版本,修改哪个服务只需要发布对应的服务即可,不用整体重新发布;职责专一,由专门的团队负责专门的服务:业务发展迅速时,研发人员也会越来越多,每个团队可以负责对应的业务线,服务的拆分有利于团队之间的分工。

服务可以动态按需扩容:当某个服务的访问量较大时,我们只需要将这个服务扩容即可;代码的复用:每个服务都提供RESTAPI,所有的基础服务都必须抽出来,很多的底层实现都可以以接口方式提供。

缺点:分布式部署,调用的复杂性高:单体应用的时候,所有模块之前的调用都是在本地进行的,在微服务中,每个模块都是独立部署的,通过HTTP来进行通信,这当中会产生很多问题,比如网络问题、容错问题、调用关系等。

测试的难度提升:服务和服务之间通过接口来交互,当接口有改变的时候,对所有的调用方都是有影响的,这时自动化测试就显得非常重要了,如果要靠人工一个个接口去测试,那工作量就太大了。这里要强调一点,就是API文档的管理尤为重要。

运维难度的提升:在***用传统的单体应用时,我们可能只需要关注一个Tomcat的集群、一个 MySQL的集群就可以了,但这在微服务架构下是行不通的。当业务增加时,服务也将越来越多,服务的部署、监控将变得非常复杂,这个时候对于运维的要求就高了。

微服务架构

是一项在云中围绕业务领域组件来创建和部署应用和服务的新技术,由MartinFowler于2012年提出。微服务架构构建的工具是Seneca,基本思想在于创建的应用可独立地进行开发、管理和加速,在分散的组件中使用微服务云架构和平台,使服务等功能的交付变得更加简单。

微服务架构现状

微服务作为一项在云中部署应用和服务的新技术已成为当下最新的热门话题。但大部分围绕微服务的争论都集中在容器或其他技术是否能很好的实施微服务,而红帽说API应该是重点。

企业和服务提供商正在寻找更好的方法将应用程序部署在云环境中,微服务被认为是未来的方向。通过将应用和服务分解成更小的、松散耦合的组件,它们可以更加容易升级和扩展,理论上是这样。

如何理解微服务架构

一个“微服务”是在一个语境下、一个背景下才有意义的词,尝试独立去定义或解释它是说不清楚的。

微服务架构是一种架构风格(或叫架构模式)、以及一组成功架构实践的总称。有时也代表一种架构思想。

微服务架构就是:以一组“按领域功能解耦的、彼此之间以轻量级通讯框架交互的、可独立开发/测试/发布/部署/升级和替换的、较小粒度的组件”的方式构建应用的架构模式!

1、 按领域功能边界解耦

2、 轻量级通信框架

3、 独立性、自治

4、 小粒度

5、 基础设施自动化,部署一个应用/单元,和部署100个应用/单元,没有显著差别(部署时间、人力等) 《一组成功实践》

6、 面向失败的设计

7、 持续演进

微服务架构是什么

微服务架构,主要是中间层分解,将系统拆分成很多小应用(微服务),微服务可以部署在不同的服务器上,也可以部署在相同的服务器不同的容器上。当应用的故障不会影响到其他应用,单应用的负载也不会影响到其他应用,其代表框架有 Spring cloud、Dubbo 等。

微服务 Microservices 之父,马丁.福勒,对微服务大概的概述如下:就目前而言,对于微服务业界并没有一个统一的、标准的定义(While there is no precise definition of this architectural style ) 。但通常在其而言,微服务架构是一种架构模式或者说是一种架构风格,它提倡将单一应用程序划分成一组小的服务,每个服务运行独立的自己的进程中,服务之间互相协调、互相配合,为用户提供最终价值。服务之间***用轻量级的通信机制互相沟通(通常是基于 HTTP 的 RESTful API ) 。每个服务都围绕着具体业务进行构建,并且能够被独立地部署到生产环境、类生产环境等。另外,应尽量避免统一的、集中式的服务管理机制,对具体的一个服务而言,应根据业务上下文,选择合适的语言、工具对其进行构建,可以有一个非常轻量级的集中式管理来协调这些服务。可以使用不同的语言来编写服务,也可以使用不同的数据存储。

六种常见的微服务架构模式:

1、聚合器微服务设计模式

聚合器调用多个服务实现应用程序所需的功能。它可以是一个简单的Web页面,将检索到的数据进行处理展示。它也可以是一个更高层次的组合微服务,对检索到的数据增加业务逻辑后进一步发布成一个新的微服务,这符合DRY原则。另外,每个服务都有自己的缓存和数据库。如果聚合器是一个组合服务,那么它也有自己的缓存和数据库。聚合器可以沿X轴和Z轴独立扩展。

2、代理微服务设计模式

这是聚合模式的一个变种,在这种情况下,客户端并不聚合数据,但会根据业务需求的差别调用不同的微服务。代理可以仅仅委派请求,也可以进行数据转换工作。

3、链式微服务设计模式

这种模式在接收到请求后会产生一个经过合并的响应,在这种情况下,服务A接收到请求后会与服务B进行通信,类似地,服务B会同服务C进行通信。所有服务都使用同步消息传递。在整个链式调用完成之前,客户端会一直阻塞。因此,服务调用链不宜过长,以免客户端长时间等待。

4、分支微服务设计模式

这种模式是聚合器模式的扩展,允许同时调用两个微服务链。

5、数据共享微服务设计模式

自治是微服务的设计原则之一,就是说微服务是全栈式服务。但在重构现有的“单体应用(monolithic ***lication)”时,SQL数据库反规范化可能会导致数据重复和不一致。因此,在单体应用到微服务架构的过渡阶段,可以使用这种设计模式,在这种情况下,部分微服务可能会共享缓存和数据库存储。不过,这只有在两个服务之间存在强耦合关系时才可以。对于基于微服务的新建应用程序而言,这是一种反模式。

6、异步消息传递微服务设计模式

虽然REST设计模式非常流行,但它是同步的,会造成阻塞。因此部分基于微服务的架构可能会选择使用消息队列代替REST请求/响应。

关于微服务架构和网络架构和微服务架构和分布式架构的介绍到此就结束了,不知道你从中找到你需要的信息了吗 ?如果你还想了解更多这方面的信息,记得收藏关注本站。

扫码二维码