精华内容
下载资源
问答
  • 《从分层架构微服务架构》是一系列介绍《Fundamentals of Software Architecture》中提到的8种架构模式的文章,这里不会事无巨细地介绍所有的细节,而是会挑选其中关键内容,更多详情请阅读原书。 前言 谈到软件...

    《从分层架构到微服务架构》是一系列介绍《Fundamentals of Software Architecture》中提到的8种架构模式的文章,这里不会事无巨细地介绍所有的细节,而是会挑选其中关键内容,更多详情请阅读原书。

    前言

    谈到软件系统设计的方法论,在代码层面,有我们熟悉的23种设计模式(design pattern),对应到架构层面,则有所谓的架构模式(architecture pattern)。它们分别从微观和宏观的角度指导着我们设计出良好的软件系统,因此,作为一个软件工程师,我们不仅要熟悉设计模式,对常见的架构模式也要熟稔于心。正如看到一个设计模式的名字脑里就能浮现出大致的结构图,当我们看到一个架构模式的名字时,也要马上想到对应的架构图及其基本特点。比如,当谈到分层架构时,我们就应该想起它的架构图是怎样的、有哪些出色的架构特征(architecture characteristics)、系统是如何部署的、数据存储的策略是哪种、等等。

    一般地,架构模式大致可以分成两类,单体架构(monolithic architecture)和分布式架构(distributed architecture)。本系列文章将会介绍以下8种常用的架构模式:

    单体架构

    • 分层架构(Layered architecture)
    • 管道架构(Pipeline architecture)
    • 微内核架构(Microkernel architecture)

    分布式架构

    • 基于服务的架构(Service-based architecture)
    • 事件驱动架构(Event-driven architecture)
    • 基于空间的架构(Space-based architecture)
    • 面向服务的架构(Service-oriented architecture)
    • 微服务架构(Microservices architecture)

    软件设计中的谬误

    在介绍架构模式前,我们先谈谈软件设计中的谬误(fallacy)。所谓谬误,就是在设计软件系统,特别是分布式系统时,我们先入为主地假设它们是正确,但实际上并非如此的一些观念。这些观念都是我们在设计软件时考虑不周的体现。

    谬误1:网络是可靠的

    网络是不可靠的

    很多软件工程师常常假设网络是可靠的,但实际并非如此。相比20年前,现在的网络会可靠很多,但是仍然具有很大的不确定性。如上图所述,Serivce B可能完全是正常运行的,但是因为网络的问题,Service A发出的请求无法到达Service B。一种更糟糕的场景是,Service B可以收到Service A的请求,并处理了相关的数据,但是网络问题导致了Service A无法收到Service B的响应,从而造成了数据不一致。网络的不可靠也是为什么系统中常常出现服务通信超时、服务熔断等的原因。

    总而言之,如果假设网络是可靠的,那么我们设计出来的软件系统将会是不可靠的。

    谬误2:时延是0

    时延不为0

    如上图所示,服务内组件间的函数/方法级别的调用,耗时是微妙,甚至是纳秒级别;但是服务间的远程调用(比如REST、消息队列、RPC),耗时会是微秒级别,甚至在异常场景会达到了秒级!在设计系统,特别是分布式系统时,时延是一个无法被忽视的因素,我们必须清楚系统的平均时延,否则设计出来的方案可能根本不可行。比如,假设系统中服务间通信时延为100ms,如果一个请求的调用链涉及到10个服务,那么该请求的时延将会是1000ms!这么高的平均时延对于一般系统来说是完全无法接受的。

    进行系统设计时,考虑平均时延还不够,更重要的是95th和99th百分点。一个系统的平均时延可能仅仅只有数十毫秒,但是95th百分点的时延却达到了数百毫秒,很多时候,这也恰恰成为了拖垮整系统性能的那块“短板”。

    谬误3:带宽是无限的

    带宽是有限的

    在单体架构中,业务流程都在单服务内闭环,消耗的带宽很少甚至为0,因此带宽并不是主要关注点。一旦将系统拆分成分布式架构,一个业务流程可能涉及多个服务间的通信,带宽就成了必须考虑的因素。带宽的不足,会导致网络变慢,从而影响系统的时延(谬误2:时延是0)和可靠性(谬误1:网络是可靠的

    如上图所示,假设在一个Web系统中,Service A负责处理前端请求,Service B负责管理用户信息(包括姓名、性别、年龄等45个属性)。Service A每处理一个请求都需要向Service B查询用户姓名(200 bytes),而在一次请求中,Service B却返回了用户的所有信息(500 kb)。如果系统每秒处理2000次请求,每次请求消耗500 kb带宽,那么每秒消耗的总带宽会是1 Gb!如果Service B仅仅返回必须的姓名,那么同等条件下,每秒消耗的总带宽仅仅是400 kb。

    此类问题就是所谓的stamp coupling,解决方法也很多,比如在请求中添加属性选择,使用GraphQL替代REST。相比于这些技术手段,更重要的是确定服务间通信所需的最小数据集,并在进行系统设计时将其作为一个重点关注的因素

    谬误4:网络是安全的

    网络是不安全的

    VPN、防火墙等的广泛使用,使得很多工程师在设计系统时忽略了“网络是不安全的”这一重要原则。特别是从单体架构演进到分布式架构以后,系统被攻击的概率将会大大增加。因此,在分布式系统中,每个服务都必须是安全的endpoint,这样才能确保任何未知或恶意的请求都被拦截掉。当然,安全是有代价的,这也是像微服务架构这类细服务粒度的系统,一次业务请求中调用链过长后性能极速下降的重要原因。

    谬误5:网络拓扑一成不变

    网络拓扑是时常变化的

    这里的网络拓扑指的是系统运行时所涉及到的网络设备,包括所有的路由器、防火墙、集线器、交换机等。很多工程师会假设网络拓扑是固定的,然而并非如此。

    假设如下场景,为架构师的你在周一早上回到公司后,发现组内同事都在为系统中所有的服务间通信都在不断出现响应超时现象而抓狂,但奇怪的是周末并没有做服务变更。经过几个小时的攻关后,你发现周一凌晨2点时有过一次网络升级,而恰恰是这次“次要”的网络升级,推翻之前设计系统时的时延假设,从而触发了本次事故。

    因此,软件工程师也需要与网络管理员时常联系,确保在每次网络升级前都明确网络拓扑的变更点,从而做出相应的调整

    谬误6:只有一个网络管理员

    不只有一个网络管理员

    网络管理员往往不止有一个,特别是在“云”时代,数据中心分散在多个地域,理所当然也存在着多个局域网。运行在“云”上的系统很有可能跨越多个数据中心,因此工程师们应当感知各个数据中心的网络管理员对网络的相关操作,提前做出应对措施,避免出现因网络拓扑变更(谬误5:网络拓扑一成不变)而导致的服务通信超时,甚至触发服务熔断。

    谬误7:通信成本为0

    通信成本不为0

    这里的通信成本并非指网络时延,而是指每增加一次服务间调用所导致的的花销。很多工程师在设计系统时常常忽视掉通信成本,大家都在鼓吹分布式架构相对了单体架构的优越性,却忘记了它带来的服务器、防火墙、网关等硬件的数量增加,这些都是白花花的银子。

    因此,在进行系统设计时,我们也应该将硬件资源和网络拓扑纳入考虑因素。

    谬误8:网络是同质的

    网络并非同质的

    很多工程师都会假设网络是同质的,也就是所有的网络设备都来自同一硬件厂商,这当然也是一个谬误。实际上,一个大的通信网络中,硬件设备往往来自于不同的厂商,这得益于网络协议标准的统一。厂商间设备的协作测试毕竟不会太充分,在一些特殊场景下极有可能存在网络丢包,从而影响了网络的可靠性(谬误1:网络是可靠的)、时延(谬误2:时延是0)以及带宽(谬误3:带宽是无限的)。

    一切从“大泥球”开始

    “大泥球”架构

    “大泥球”架构是著名的反模式架构,最初在1997年由Brian Foote 和 Joseph Yoder提出。在“大泥球”架构里,系统没有进行内部的模块划分,代码耦合严重,调用关系混乱,就像一个大的泥球。如上图所示,每一个点代表一个类,红线则表示类之间的耦合关系。这样的架构对需求变更极不友好,往往牵一发而动全身,而且在部署、可测试性、性能等方面也存在着很多问题。所有的架构师都在极力避免“大泥球”的出现,但很不幸的是,它仍然在实际项目中很常见,特别是项目伊始,代码质量和结构还没被严格管控起来前。

    有反模式的出现,必然就有解决它的方法,这便是架构模式,从下一篇文章开始,我们将逐个介绍常见的8种架构模式。

    总结

    跟设计模式类似,架构模式是软件工程师们多年来在架构设计方面的经验总结。每种架构模式并没有绝对的优劣之分,我们不能说微服务架构就一定比单体分层架构优越,它们都有着各自的应用场景。分布式架构比单体架构有着更好的可扩展性、容错性,但也带来了更高的复杂性,比如分布式事务。因此,我们应该熟知各个架构模式的特点,这样才能在特定的业务场景使用合适的架构模式。


    展开全文
  • DDD 分层架构 整洁架构 整洁架构又名“洋葱架构”。为什么叫它洋葱架构?看看下面这张图你就明白了。整洁架构的层就像洋葱片一样,它体现了分层的设计思想。 整洁架构最主要的原则是依赖原则,它定义了各层的依赖...

    DDD 分层架构

    在这里插入图片描述

    整洁架构

    整洁架构又名“洋葱架构”。为什么叫它洋葱架构?看看下面这张图你就明白了。整洁架构的层就像洋葱片一样,它体现了分层的设计思想。

    整洁架构最主要的原则是依赖原则,它定义了各层的依赖关系,越往里依赖越低,代码级别越高,越是核心能力。外圆代码依赖只能指向内圆,内圆不需要知道外圆的任何情况。

    在这里插入图片描述

    六边形架构

    六边形架构又名“端口适配器架构”。追溯微服务架构的渊源,一般都会涉及到六边形架构。

    六边形架构的核心理念是:应用是通过端口与外部进行交互的。我想这也是微服务架构下 API 网关盛行的主要原因吧。

    在这里插入图片描述
    记得点赞收藏加关注哦 ,需要下载PDF版本和获取更多知识点、面试题的朋友可以点一点下方链接免费领取

    链接:点这里!!! 暗号:CSDN

    在这里插入图片描述

    三种微服务架构模型的对比和分析

    在这里插入图片描述
    这三种架构都考虑了前端需求的变与领域模型的不变。

    DDD 分层架构、整洁架构、六边形架构都是以领域模型为核心,实行分层架构,内部核心业务逻辑与外部应用、资源隔离并解耦。请务必记好这个设计思想,今后会有大用处。

    项目级微服务

    项目级微服务的内部遵循分层架构模型就可以了。领域模型的核心逻辑在领域层实现,服务的组合和编排在应用层实现,通过 API 网关为前台应用提供服务,实现前后端分离。但项目级的微服务可能会调用其它微服务,你看在下面这张图中,比如某个项目级微服务 B 调用认证微服务 A,完成登录和权限认证。

    在这里插入图片描述

    企业级中台微服务

    我们可以在中台微服务之上增加一层,你看下面这张图,增加的这一层就位于红色框内,它的主要职能就是处理跨中台微服务的服务组合和编排,以及微服务之间的协调,它还可以完成前端不同渠道应用的适配。如果再将它的业务范围扩大一些,我可以将它做成一个面向不同行业和渠道的服务平台。

    在这里插入图片描述
    BFF 微服务与其它微服务存在较大的差异,就是它没有领域模型,因此这个微服务内也不会有领域层。BFF 微服务可以承担应用层和用户接口层的主要职能,完成各个中台微服务的服务组合和编排,可以适配不同前端和渠道的要求。

    总结

    我这里也准备了一线大厂面试资料和超硬核PDF技术文档,以及我为大家精心准备的多套简历模板(不断更新中),希望大家都能找到心仪的工作!

    有需要的朋友可以点一点下方链接免费领取

    链接:点这里!!! 暗号:CSDN

    在这里插入图片描述

    展开全文
  • 《从分层架构微服务架构》是一系列介绍《Fundamentals of Software Architecture》中提到的8种架构模式的文章,这里不会事无巨细地介绍所有的细节,而是会挑选其中关键内容,更多详情请阅读原书。 往期精彩: 从...

    《从分层架构到微服务架构》是一系列介绍《Fundamentals of Software Architecture》中提到的8种架构模式的文章,这里不会事无巨细地介绍所有的细节,而是会挑选其中关键内容,更多详情请阅读原书。

    往期精彩:

    前言

    管道架构(Pipeline Architecture),通常也被称为管道-过滤器架构(Pipes and Filter Architecture),是最常用的架构模式之一。大部分软件工程师都是通过Unix终端初次接触到该架构模式,Unix终端的Shell语言,对管道-过滤器有着原生的支持。

    比如,现在需要实现这样的一个功能:读取一个文本文件的内容,找到使用频率最高的5个单词,并按照使用频率的大小顺序打印出单词及其使用频率

    那么,使用Shell可以这样来实现:

    cat content.txt |     # step1: 读取文件内容
    tr -cs A-Za-z '\n' |  # step2: 将单词按行输出
    tr A-Z a-z |          # step3: 将所有单词转换为
    sort |                # step4: 对单词进行排序
    uniq -c |             # step5: 计算出单词的频率
    sort -rn |            # step6: 按照频率对单词进行排序
    head -n 5             # step7: 获取排序前5的单词
    # 输出结果示例:
       4 to
       4 and
       3 the
       3 networks
       3 linux
    

    这段Shell代码就是一个简单的管道架构实现,其中|表示管道pipe,每一个step就相当于一个过滤器filter。每个filter都将上一个filter的输出结果作为输入数据,对数据进行处理后再将结果输出到管道中。

    除了Shell语言之外,MapReduce也是基于管道架构搭建,其中的mapreduce可以看成是过滤器,只是它们通信的管道为HDFS。

    Shell语言和MapReduce编程模型都可以看成是管道架构的low-level实现,当然,它也能应用于higher-level的系统应用上,下面我们来介绍管道架构模式的架构视图。

    架构视图

    管道架构由管道pipe和过滤器filter组成:

    管道架构架构视图

    pipe作为filter之间的数据传输通道,通常都是单向、点对点通信的,这样的设计不仅实现简单,在性能上也能取得较好的效果。另外,pipe上传输的数据并没有统一的格式,每个系统都可以根据自身的特点选择合适的数据结构。

    filter作为数据处理的组件,通常是无状态的。每个filter都应当只完成一项工作,满足单一职责原则,复杂的工作流应该由多个filter组合而成。一般地,我们将filter分成以下几种类型:

    • Producer: 有时候也称为Source,是整个pipeline的start point,负责从数据源中接收数据,并将数据输出到pipe中。
    • Transformer: 从pipe中接收输入数据,然后对部分或全部数据进按照一定的规则行转换,并将结果输出到pipe中。在函数式编程里,该步骤通常被称为map
    • Tester: 从pipe中接收数据,然后对数据进行一些条件判断,并根据判断结果选择是否将数据传递到下游的pipe中。需要注意的是,tester并未对数据进行任何修改
    • Consumer: 是整个pipeline的end point,通常将从pipe中读取到的数据持久化到数据库或呈现到用户界面上。

    一个系统中可以有多个producer和consumer,比如我们可以同时通过Kafka和REST接口接收输入数据,经过系统的处理后,将结果数据存储到MySQL中,同时也传递一份到数据仓库上用作数据分析。总之,管道架构模式有着很大的灵活性

    应用例子

    管道架构模式被广泛应用在很多应用上,下面我们以一个ETL系统作为例子来理解该模式的运作方式。

    ETLExtract, Transform, Load)是将业务系统的数据经过抽取、清洗转换之后加载到数据仓库的过程,目的是将企业中的分散、零乱、标准不统一的数据整合到一起,为企业的决策提供分析依据。

    管道架构模式应用例子

    业务应用系统在运行过程中会产生各种各样的数据输出到kafka中,ETL系统会消费相关数据,并在经过处理后将结果存储到数据库上。在上图的ETL系统里,各个过滤器的作用如下所述:

    • Service Info Capture: 订阅kafka的topic,从中消费业务系统产生的数据,然后通过pipe传送到下游filter。
    • Duration Filter: 判断数据是否与计算服务请求的处理时长(duration)指标相关,是则将数据传递给Duration Calculator,否则传递给Uptime Filter。
    • Duration Calculator: 计算服务请求的处理时长,并将计算结果传递给Database Output。
    • Uptime Filter: 判断数据是否与计算系统正常运行时长(uptime)指标相关,是则将数据传递给Uptime Calculator,否则认为数据并非本ETL系统所关系,结束数据流程。
    • Uptime Calculator: 计算系统正常运行时长,并将结果传递给Database Output。
    • Database Output: 将数据持久化到MongoDB中。

    上述的ETL系统由1个producer filter,2个tester filter,2个transform filter和1个consumer filter组成,主要的数据处理逻辑是计算系统的遥测指标。系统在架构上具有很高的可扩展性,比如后续想要新增一个指标计算,我们可以在Uptime Filter之后加上新的tester和transform,系统原有的指标计算无需改动;又比如系统后续打算用HBase替换MongoDB,那么我们可以新开发一个HBase Output替换掉原有的Database Output,系统的其他流程同样无需改动。

    架构评分

    管道架构模式的架构评分

    管道架构模式通常被实现为单体架构,同分层架构模式一样,因为单体架构本身的劣势,其在Elasticity、Fault tolerance、Scalability方面都具有很低的评分。Simplicity是管道架构模式的主要优点之一,filter和pipe实现简单,可以快速构建起一个基于管道架构风格的系统,因此也具有很高的Overall cost评分。

    另外,相比于分层架构模式,管道架构模式在Modularity、Evolutionary和Testability上都有着较高的评分,这得益于filter之间的松耦合,我们可以很容易扩展系统的filter,以及对单个filter进行测试

    总结

    本文主要介绍了管道架构模式,它由管道pipe和过滤器filter组成。根据具体的数据处理逻辑,它将filter划分为producer、transformer、tester和consumer四种类型,是一种典型的technical partition软件架构风格。管道架构模式因为其可扩展性很高的特点而被广泛应用,其中不乏有Shell语言这种low-level的实现,也有ETL系统这种high-level的实现。

    虽说该模式通常被实现为单体架构,但也有像MapReduce这种基于分布式系统的编程模式实现,总之,如果你需要为一个数据处理型的系统选型,那么可以认真地考虑是否采用管道架构模式。

    每种架构模式都有其合适的应用场景,只有熟悉常用的几种架构模式,才能设计出更好的软件系统。下一篇文章,我们将继续介绍微内核架构


    展开全文
  • 但通在其常而言,微服务架构是一种架构模式或者说是一种架构风格,它提倡将单一应用程序划分成一组小的服务,每个服务运行独立的自己的进程中,服务之间互相协调、互相配合,为用户提供最终价值。服务之间采用轻量...

    什么是微服务?

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

    小服务

    小服务,没有特定的标准或者规范,但他在总体规范上一定是小的

    独立进程

    每一组服务都是独立运行的,可能我这个服务运行在tomcat容器,而另一个服务运行在jetty上。可以通过进程方式,不断的横向扩展整个服务

    通信

    过去的协议都是很重的,就像ESB,就像SOAP,轻通信,这意味着相比过去更智能更轻量的服务相互调用,就所谓 smart endpoints and dumb pipes,这些endpoint都是解耦的,完成一个业务通信调用串起这些微服务就像是linux系统中通过管道串起一系列命令业务。过去的业务,我们通常会考虑各种各样的依赖关系,考虑系统耦合带来的问题。微服务,可以让开发者更专注于业务的逻辑开发

    部署

    不止业务要独立,部署也要独立。不过这也意味着,传统的开发流程会出现一定程度的改变,开发的适合也要有一定的运维指责,这使得运维人员要更加专业和被重视

    管理

    传统的企业级SOA服务往往很大,不易于管理,耦合性高,团队开发成本比较大。微服务,可以让团队各思其政的选择技术实现,不同的service可以根据各自的需要选择不同的技术栈来实现其业务逻辑

     

    微服务的利与弊

    优点:

    • 每个服务足够内聚,足够小,代码容易理解这样能聚焦一个指定的业务功能或业务需求
    • 开发简单、开发效率提高,一个服务可能就是专一的只干一件事
    • 微服务能够被小团队单独开发,这个小团队是 2 到 5 人的开发人员组成
    • 微服务是松藕合的,是有功能意义的服务,无论是在开发阶段或部署阶段都是独立的
    • 微服务能使用不同的语言开发
    • 易于和第三方集成,微服务允许容易且灵活的方式集成自动部署,通过持续集成工具,如Jenkins,Hudson,bamboo
    • 微服务易于被一个开发人员理解,修改和维护,这样小团队能够更关注自己的工作成果。无需- - 通过合作才能体现价值。微服务允许你利用融合最新技术
    • 微服务只是业务逻辑的代码,不会和 HTML,CSS或其他界面组件混合
    • 每个微服务都有自己的存储能力,可以有自己的数据库。也可以有统一数据库

    总的来说,微服务的优势,就是在于,面对大的系统,可以有效的减少复杂程度,使服务架构的逻辑更清晰明了

    缺点:

    分布式环境下的数据一致性,测试的复杂性,运维的复杂性

    什么组织适合使用微服务?

    架构演化

    架构是不断演化出来的,微服务也是这样,当从各大科技公司,规模大到一定程度,完全需要演化成更进一步管理的技术架构体系

    传统的团队,都是面向过程化的,产品想完了去找策划,策划完了找开发,接着顺着一步一步找。我们做技术都是为了产品的,一旦过程出来了什么问题,回溯寻找问题会非常耗时

    使用了微服务架构体系,团队组织方式需要转变成跨职能团队,即每个团队都有产品专家,策划专家,开发专家,运维专家,他们使用API方式发布他们的功能,而平台使用他们的功能发布产品

     

     

    微服务技术架构体系

    微服务技术架构体系

    服务发现

    第一种,开发人员开发了程序以后,会找运维配一个域名,服务的话通过dns就能找到我们对应的服务

    缺点是,由于服务没有负载均衡功能,对负载均衡服务,可能会有相当大的性能问题

    第二种,是目前普遍的做法,每一个服务都通过服务端内置的功能注册到注册中心,服务消费者不断轮询注册中心发现对应的服务,使用内置负载均衡调用服务

    缺点是,对多语言环境不是很好,你需要单独给消费者的客户端开发服务发现和负载均衡功能。当然了,这个方法通常都是用在spring cloud上的

    第三种,是将客户端和负载均衡放在同一个主机,而不是同一个进程内。

    这种方法相对第一种,第二种方法来说,改善了他们的缺点,但是会极大增加运维成本

     

    网关

    微服务的网关是什么?

    举个生活中的例子:每一个大的公司,都会有一偏属于自己的建筑区,而这建筑区内,都有不少的门卫。如果有外来人员进入公司,会先和门卫打好招呼,才能进去,这就是跟网关差不多的概念

    • 反向路由:很多时候,公司不想让外部人员看到我们公司的内部,就需要网关来进行反向路由。即将外部请求转换成内部具体服务调用
    • 安全认证:网络中会有很多恶意访问,譬如爬虫,譬如黑客攻击,网关维护安全功能
    • 限流熔断:当请求很多服务不堪重负,会让我们的服务自动关闭,导致不能用服务。限流熔断可以有效的避免这类问题
    • 日志监控:所有的外面的请求都会经过网关,这样我们就可以使用网关来记录日志信息
    • 灰度发布,蓝绿部署。是指能够平滑过渡的一种发布方式。在其上可以进行A/B testing,即让一部分用户继续用产品特性A,一部分用户开始用产品特性B,如果用户对B没有什么反对意见,那么逐步扩大范围,把所有用户都迁移到B上面来

    开源网关Zuul架构

    zuul网关核心其实是一个servlet,所有请求都会经过zuul servlet传到zuulFilter Runner,然后分发到三种过滤器

    先说说架构图左半部分,分别是使用Groovy实现的前置路由过滤器,路由过滤器,后置路由过滤器。一般请求都会先经过前置路由过滤器处理,一般的自定义java封装逻辑也会在这里实现。

    路由过滤器,实现的是找到对应的微服务进行调用。调用完了,响应回来,会经过后置路由过滤器,通过后置路由过滤器我们可以封装日志审计的处理

    可以说zuul网关最大的特色就是它三层过滤器

    架构图右半部分,是zuul网关设计的自定义过滤器加载机制。网关内部会有生产者消费者模型,自动的将过滤器脚本发布到zuul网关读取加载运行

    配置中心

    以前,开发人员把配置文件放在开发文件里面,这样会有很多隐患。譬如,配置规范不同,无法追溯配置人员。一旦需要大规模改动配置,改动时间会很长,无法追溯配置人员,从而影响整个产品,后果是我们承担不起的,现在的开源中心有百度配置中心 Disconf,spring cloud config,Apollo,今天重点说说现在应用质量不错的配置中心阿波罗

    携程开源的Apollo

    开源地址:https://github.com/ctripcorp/apollo

    apollo的配置中心规模比较大,本地应用会有响应的配置中心客户端,可以定时同步配置中心里的配置。如果配置中心怠机,会使用缓存来进行配置

    通讯方式

    通讯方式,一般市面也就是两种远程调用方式

    对比项RPCREST
    耦合性强耦合松散耦合
    消息协议TCPHTTP
    通讯协议二进制文本XML,JSON
    性能低于RPC
    接口契约IDLthrift,protobuf,IdlSwagger
    客户端强类型客户端,一般自动生成一般HTTP可访问,生成强类型客户端,多语言支持好
    案例Dubbo,Dubbox,motan,tars,grpc,thriftspring boot,tax-rs,dropwizard
    开发者友好客户端比较方面,二进制消息不能读可读消息
    对外开放一般需要转成REST / 文本协议可直接对外开放

    监控预警

    监控预警对于微服务很重要,一个可靠的监控预警体系对微服务运行至关重要。一般监控分为如下层次

    从基础设施到用户端,层层有监控,全方位,多角度,每一个层面都很重要。总体来说,微服务可分5个监控点:日志监控Metrics监控健康检查调用链检查告警系统

     

    监控架构

    下图是大部分公司的一种监控架构图。每一个服务都有一个agentagent收集到关键信息,会传到一些MQ中,为了解耦。同时将日志传入ELK,将Metrics传入InfluxDB 时间序列库。而像nagios,可以定期向 agent 发起信息检查微服务

    调用链监控APM

    很多公司都有调用链监控,就譬如阿里有鹰眼监控,点评的Cat,大部分调用链监控(没错,指的Zipkin)架构是这样的

    当请求进入Web容器的时候,会经过创建 Tracer,连接spans(模拟潜在的分布式工作的延迟,该模块还包含在系统网络间传递跟踪上下文信息的工具包,如通过http headers)。Spans有一个上下文,其中包含tracer标识符,将其放在表示分布式操作的树的正确位置。当我们把图中的各种span放到后端的时候,我们的服务调用链会动态的生成调用链

    下面是一些市场上用的比较多的调用链监控

    1、Pinpoint github地址:GitHub - naver/pinpoint: Pinpoint is an open source APM (Application Performance Management) tool for large-scale distributed systems written in Java. 对java领域的性能分析有兴趣的朋友都应该看看这个开源项目,这个是一个韩国团队开源出来的,通过JavaAgent的机制来做字节码代码植入,实现加入traceid和抓取性能数据的目的。 NewRelic、Oneapm之类的工具在java平台上的性能分析也是类似的机制

    2、SkyWalking github地址:wu-sheng/sky-walking 这是国内一位叫吴晟的兄弟开源的,也是一个对JAVA分布式应用程序集群的业务运行情况进行追踪、告警和分析的系统,在github上也有400多颗星了。 功能相对pinpoint还是稍弱一些,插件还没那么丰富,不过也很难得了

    3、Zipkin 官网:OpenZipkin · A distributed tracing system github地址:GitHub - openzipkin/zipkin: Zipkin is a distributed tracing system 这个是twitter开源出来的,也是参考Dapper的体系来做的

    Zipkin的java应用端是通过一个叫Brave的组件来实现对应用内部的性能分析数据采集。 Brave的github地址:github.com/openzipkin/… 这个组件通过实现一系列的java拦截器,来做到对http/servlet请求、数据库访问的调用过程跟踪。 然后通过在spring之类的配置文件里加入这些拦截器,完成对java应用的性能数据采集

    4、CAT github地址:GitHub - dianping/cat: Central Application Tracking 这个是大众点评开源出来的,实现的功能也还是蛮丰富的,国内也有一些公司在用了。 不过他实现跟踪的手段,是要在代码里硬编码写一些“埋点”,也就是侵入式的。 这样做有利有弊,好处是可以在自己需要的地方加埋点,比较有针对性;坏处是必须改动现有系统,很多开发团队不愿意

     catzipkinpinpointskywalking
    依赖
    • Java 6、 7 、8
    • Maven 3.2.3+
    • mysql 5.6
    • Linux 2.6以及之上(2.6内核才可以支持epoll)
    • Java 6、 7 、8
    • Maven 3.2+
    • rabbitMQ
    • Java 6、 7 、8
    • Maven 3+
    • Hbase 0.94+
    • Java 6、 7 、8
    • Maven 3.0+
    • nodejs
    • zookeeper
    • elasticsearch
    实现方式代码埋点(拦截器、注解、过滤器等)拦截请求、发送(HTTP,MQ)数据至zipkin服务java 探针、字节码增强java探针,字节码增强
    存储选择mysql、hdfsin-memory,mysql,Cassandra,ElasticsearchHBaseElasticsearch,H2
    通信方式——http  MQ thriftGRPC
    MQ监控不支持不支持不支持支持(RocketMQ、kafka)
    全局调用统计支持不支持支持支持
    trace 查询不支持支持不支持支持
    报警支持不支持支持支持
    JVM 监控不支持不支持支持支持
    star数4.5K7.9K5.6K2.8K
    优点功能完善spring-cloud-sleuth 可以很好的集成zipkin、代码无浸入、集成非常简单、社区更加活跃,对外提供有query接口,更加容易二次开发完全无浸入,仅需修改启动方式,界面完善,功能细致完全无侵入,界面完善,支持应用拓扑图及单个调用链查询,功能比较完善(zipkin + pinpoint)
    缺点
    • 代码侵入性较强,需要埋点
    • 文档比较混乱,文档与发布版本的符合性较低,需要依赖点评私服(或者需要把他私服上的jar手动下载下来,然后上传到我们的私服上去)
    • 默认使用的是http请求向zipkin上报信息,耗性能
    • 跟sleuth结合可以使用rabbitMQ的方式异步来做,增加了复杂度,需要引入rabbitMQ
    • 数据分析比较简单
    • 不支持查询单个调用链,对外表现的是整个应用的调用生态
    • 二次开发难度较高

     

    • 3.2版本之前BUG较多,网上反映兼容性较差,3.2新版本的反映情况较少
    • 依赖较多
    文档网上资料较少,仅官网提供的文档,比较乱文档完善文档完善文档完善
    开发者大众点评twitternaver吴晟(华为开发者),目前已经加入Apache孵化器
    使用公司大众点评,携程,陆金所,同程旅游,猎聘网twitternaver华为软件开发云,天源迪科,当当网,京东金融

    熔断、隔离、限流、降级

    面对巨大的突发流量下,大型公司一般会采用一系列的熔断(系统自动将服务关闭防止让出现的问题最大化)、隔离(将服务和服务隔离,防止一个服务挂了其他服务不能访问)、限流(单位时间内之允许一定数量用户访问)、降级(当整个微服务架构整体的负载超出了预设的上限阈值或即将到来的流量预计将会超过预设的阈值时,为了保证重要或基本的服务能正常运行,我们可以将一些 不重要或 不紧急 的服务或任务进行服务的 延迟使用 或 暂停使用)措施

    每一个微服务调用时,都会使用hystrixcommand方式(上图的左上角那个),然后使用command同步的,或者是响应式的,或者是异步的,判断电路是否熔断(顺着图从左往右看),如果断路则走降级fallback;

    如果这个线闭合着,但是线程资源没了,队列满了,则走限流措施(看图的第5步);如果走完了,执行成功了,则走run()方法,获取response,但是这个过程如果出错了,则继续走降级fallback,同时,看图最上面有一个后缀是health的,这是一个计算整个链路是否健康的组件,每一步操作都被它记录着

     

    容器与服务编排引擎

    从物理机到虚拟机,从虚拟机到容器;从物理集群到open stackopen stackkubernetes;科技不断的变化,我们的认知也在一直刷新

    从容器开始说起,它首先是一个相对独立的运行环境,在这一点有点类似于虚拟机,但是不像虚拟机那样彻底。  虚拟机会将虚拟硬件、内核(即操作系统)以及用户空间打包在新虚拟机当中,虚拟机能够利用“虚拟机管理程序”运行在物理设备之上。虚拟机依赖于hypervisor,其通常被安装在“裸金属”系统硬件之上,这导致hypervisor在某些方面被认为是一种操作系统。一旦 hypervisor安装完成, 就可以从系统可用计算资源当中分配虚拟机实例了,每台虚拟机都能够获得唯一的操作系统和负载(应用程序)。简言之,虚拟机先需要虚拟一个物理环境,然后构建一个完整的操作系统,再搭建一层Runtime,然后供应用程序运行

    对于容器环境来说,不需要安装主机操作系统,直接将容器层(比如LXC或libcontainer)安装在主机操作系统(通常是Linux变种)之上。在安装完容器层之后,就可以从系统可用计算资源当中分配容器实例了,并且企业应用可以被部署在容器当中。但是,每个容器化应用都会共享相同的操作系统(单个主机操作系统)。容器可以看成一个装好了一组特定应用的虚拟机,它直接利用了宿主机的内核,抽象层比虚拟机更少,更加轻量化,启动速度极快

    相比于虚拟机,容器拥有更高的资源使用效率,因为它并不需要为每个应用分配单独的操作系统——实例规模更小、创建和迁移速度也更快。这意味相比于虚拟机,单个操作系统能够承载更多的容器。云提供商十分热衷于容器技术,因为在相同的硬件设备当中,可以部署数量更多的容器实例。此外,容器易于迁移,但是只能被迁移到具有兼容操作系统内核的其他服务器当中,这样就会给迁移选择带来限制。因为容器不像虚拟机那样同样对内核或者虚拟硬件进行打包,所以每套容器都拥有自己的隔离化用户空间,从而使得多套容器能够运行在同一主机系统之上。我们可以看到全部操作系统层级的架构都可实现跨容器共享,惟一需要独立构建的就是二进制文件与库。正因为如此,容器才拥有极为出色的轻量化特性

    最常用的容器是docker,网址如下 https://www.docker.com/

    容器编排

    过去虚拟机可以通过云平台open stack管理虚拟化,容器时代如何管理容器呢?这就要看看容器编排引擎

    Apache mesos

    mesos是基于master,slave架构,框架决定如何利用资源,master负责管理机器,slave会定期的将机器情况报告给master,master再将信息给框架。master是高可用的,因为zk,也有leader的存在

    kubernetes

    kubernetes是最近十分火热的开源容器编排引擎,具体可以参考 kubernetes中文文档

    Kubernetes设计理念和功能其实就是一个类似Linux的分层架构,每一个Kubernetes节点内部,kubelet管理全局全局pod,而每一个pod承载着一个或多个容器,kube-proxy负责网络代理和负载均衡 

    Kubernetes节点外部,则是对应的控制管理服务器,负责统一管理各个节点调度分配与运行

    展开全文
  • 分层架构 传统的mvc三层架构,上层依赖于下层,层与层之间有严格的界限。但是一旦业务庞大起来后,为了业务需要,就会增加新的层。新层往往有边界模糊等问题。此外,因为上层依赖于下层,当数据来源出现变更的时候...
  • 微服务之服务分层

    2020-12-29 01:09:12
    我觉得说微服务的服务分层前,有必要说一下微服务的演进历史和微服务架构的一些常用设计模式一、微服务演进历史MVC (Modle View Controller) 架构: 当业务规模很小时,将所有功能都部署在同一个进程中,通过双机...
  • 微服务架构

    2021-01-22 19:43:47
    一、微服务架构: 一组小的服务;独立的进程;轻量级通信;基于业务能力;独立部署;无集中式管理; 二、微服务利弊: 利: 1、强模块化边界; 2、可独立部署; 3、技术多样性; 弊: 1、分布式复杂性...
  • DDD 分层架构 整洁架构 整洁架构又名“洋葱架构”。为什么叫它洋葱架构?看看下面这张图你就明白了。整洁架构的层就像洋葱片一样,它体现了分层的设计思想。 整洁架构最主要的原则是依赖原则,它定义了各层的...
  • Spring Cloud 微服务总体架构

    千次阅读 2021-01-21 23:02:15
    微服务架构中,根据业务来拆分成一个个的服务,服务与服务之间可以相互调用(RPC),在Spring Cloud可以用RestTemplate+Ribbon和Feign来调用。为了保证其高可用,单个服务通常会集群部署。由于网络原因或者自身的...
  • 微服务架构演变过程

    2021-02-08 23:28:33
    微服务架构演变过程微服务架构演变过程1、传统架构2、分布式架构3、SOA面向服务架构4、微服务架构微服务架构产生的原因微服务架构基本概念微服务架构与SOA架构的不同微服务架构会产生哪些问题为什么我们要使用...
  • 文章目录一、MVC1.MVC介绍2.MVC分析3.MVC执行流程4.MV分层的优点二、MVP1.MVP介绍2.MVP优点三、阿里分层架构四、DDD微服务 一、MVC 绝大多数现行的分层架构,都是在MVC分层架构的基础之上不断完善,针对特定的需求...
  • 上一次我们简单介绍了什么是微服务(.NET Core with 微服务 - 什么是微服务)。介绍了微服务的来龙去脉,一些基础性的概念。有大佬在评论区指出说这根本不是微服务。由于本人的能力有...
  • DDD 分层架构的重要原则 在《实现领域驱动设计》书中提到,DDD 分层架构有一个重要的依赖原则:“每层只 能与位于其下方的层发生耦合。” ...
  • 随着互联网的发展已经很难满足市场对技术的需求,于是我们从单独架构发展到分布式架构,又从分布式架构发展到 SOA 架构,服务不断的被拆分和分解,粒度也越来越小,直到微服务架构的诞生。 微服务架构是一种架构模式...
  • 摘要:一般地,架构模式大致可以分成两类,单体架构(monolithic architecture)和分布式架构(distributed architecture)。 前言 谈到软件系统设计的方法论,在代码层面,有我们熟悉的23种设计模式(design ...
  • 微服务架构·网关

    2021-03-29 15:24:41
    学习目标: 了解常用filter常用的功能,对gateway有一定的认知,根据业务痛点,成本做出服务的网关选择 ...微服务架构将单体应用,按照业务领域拆分为多个高内聚低耦合的小型服务,每个小服务运行在独立进程,由不同
  • 微服务在近几年来可以说是十分火爆,我们应该知道微服务的发展历程大致分为6个阶段分别是:单体应用阶段提、垂直应用阶段、分布式系统阶段、服务治理阶段、微服务阶段、最后到服务网格阶段。 既然谈到微服务...
  • 通过采用微服务架构,企业最大的收益是帮助内部IT建设沿着可演进的方向发展、支持灵活扩展、降低运维成本、快速响应业务变化。这些底层技术能力的提升让业务更加敏捷、成本可控,企业也可以从中获得技...
  • 《从分层架构微服务架构》是一系列介绍《Fundamentals of Software Architecture》中提到的8种架构模式的文章,这里不会事无巨细地介绍所有的细节,而是会挑选其中关键内容,更多详情请阅读原书。 往期精彩: 从...
  • 一 软件架构的4+1模型 先上图,软件架构的4+1模型如图1.1所示 图1.1 4+1模型 注:上图中的元素一词来源于软件架构的定义 计算机系统的软件架构是构建这个系统所需要的一组架构,包括软件元素、它们...
  • 高并发微服务架构设计作为一个 IT 从业人员,我们经常会碰到类似于下面的一些问题:单个项目巨大而沉重,难以维护。系统稳定性得不到更有效的保证。怎样才能持续地提升系统的性能。怎样才能快速地响应需求的变更,...
  • 图片来源:pexels.com近几年,微服务架构迅速在整个技术社区窜红,被认为是 IT 软件架构的未来方向。但我发现,我每次跟朋友提到微服务,他们的反映都是既兴奋又无奈——兴奋的是看到了微...
  • 微服务架构讲解:那叫一个通俗易懂

    千次阅读 多人点赞 2021-01-04 14:00:33
    点击上方Java后端,选择设为星标优质文章,及时送达目录如下:一、微服务架构介绍二、出现和发展三、传统开发模式和微服务的区别四、微服务的具体特征五、SOA和微服务的区别六、如何具体实...
  • 微服务核心架构20讲 chapter 1 什么是微服务 Martin Fowler ⻢丁·福勒为微服务下了这样的几个定义: #mermaid-svg-BUoHxDK3x25hQZdd .label{font-family:'trebuchet ms', verdana, arial;font-family:var(--mermaid...
  • 包括如下目录学习笔记:14、服务化:微服务架构,究竟解决什么问题?15、服务化:微服务架构,粒度多少合适?16、服务化:微服务架构,必须搞定高可用!17、服务化:微服务架构,必须搞定高并发!18、服务化:微服务...
  • 一、什么是微服务架构 1、由一组小的服务组成,例如将单体架构应用进行拆分成多块小的独立服务,服务有多小具体看业务进行划分。 2、每个服务都是运行在独立的进程之中,以进程的方式去进行横向扩展。 3、服务...
  • 前言 谈到软件系统设计的方法论,在代码层面,有我们熟悉的23种设计模式(design pattern),对应到架构层面,则有所谓的架构模式(architecture...比如,当谈到分层架构时,我们就应该想起它的架构图是怎样的、有哪些
  • 微服务架构诞生的今世前生大揭秘

    千次阅读 多人点赞 2020-12-20 20:48:40
    微服务架构介绍 微服务架构出现 微服务架构流派 云原生与微服务 总结 福利 近年来,微服务架构一直是互联网技术圈的热点之一,越来越多的互联网应用都采用了微服务架构作为系统构建的基础,很多新技术和理念如 ...
  • 微服务架构微服务架构最强讲解,那叫一个通俗易懂! 目录如下: 一、微服务架构介绍 二、出现和发展 三、传统开发模式和微服务的区别 四、微服务的具体特征 五、SOA和微服务的区别 六、如何具体实践微服务 七、常见...
  • 一、微服务架构介绍二、出现和发展三、传统开发模式和微服务的区别四、微服务的具体特征五、SOA和微服务的区别六、如何具体实践微服务七、常见的微服务设计模式和应用八、微服务的优点和缺点九、思考...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 16,995
精华内容 6,798
关键字:

微服务分层架构

友情链接: Color image encryptionn.rar