精华内容
下载资源
问答
  • 2018-05-11 15:13:04

    转载自:http://geek.csdn.net/news/detail/73332

    无架构,不系统,架构是大型系统的关键。从形上看,架构是系统的骨架,支撑和链接各个部分;从神上看,架构是系统的灵魂,深刻体现业务本质。

    架构可细分为业务架构、应用架构、技术架构,业务架构是战略,应用架构是战术,技术架构是装备。其中应用架构承上启下,一方面承接业务架构的落地,另一方面影响技术选型。

    如何针对当前需求,选择合适的应用架构,如何面向未来,保证架构平滑过渡,这个是软件开发者,特别是架构师,都需要深入思考的问题。本文基于作者在大型互联网系统的实践和思考,和大家一起探讨应用架构的选型。

    本文主要内容包括:

    应用架构本质
    单体式
    分布式
    SOA架构
    SOA落地方式
    应用架构进化
    应用架构本质

    应用作为独立可部署的单元,为系统划分了明确的边界,深刻影响系统功能组织、代码开发、部署和运维等各方面,应用架构定义系统有哪些应用、以及应用之间如何分工和合作。

    分有两种方式,一种是水平分,按照功能处理顺序划分应用,比如把系统分为web前端/中间服务/后台任务,这是面向业务深度的划分。另一种是垂直分,按照不同的业务类型划分应用,比如进销存系统可以划分为三个独立的应用,这是面向业务广度的划分。

    应用的合反映应用之间如何协作,共同完成复杂的业务case,主要体现在应用之间的通讯机制和数据格式,通讯机制可以是同步调用/异步消息/共享DB访问等,数据格式可以是文本/XML/JSON/二进制等。

    应用的分偏向于业务,反映业务架构,应用的合偏向于技术,影响技术架构。分降低了业务复杂度,系统更有序,合增加了技术复杂度,系统更无序。

    应用架构的本质是通过系统拆分,平衡业务和技术复杂性,保证系统形散神不散。

    系统采用什么样的应用架构,受业务复杂性影响,包括企业发展阶段和业务特点;同时受技术复杂性影响,包括IT技术发展阶段和内部技术人员水平。业务复杂性(包括业务量大)必然带来技术复杂性,应用架构目标是解决业务复杂性的同时,避免技术太复杂,确保业务架构落地。

    常见的应用架构有多种,下面根据系统拆分方式,以及如何平衡业务与技术的角度进行分析,讨论各自的适用性,给企业应用架构选型提供参考。

    单体式应用
    架构模型
    系统只有一个应用,相应地,代码放在一个工程里管理;打包成一个应用;部署在一台机器;在一个DB里存储数据。单体式应用的架构如下图所示:

    图片描述

    单体式应用采用分层架构,按照调用顺序,从上到下一般为表示层、业务层、数据访问层、DB层,表示层负责用户体验,业务层负责业务逻辑,数据访问层负责DB层的数据存取。

    单体应用在水平方向上,上下层之间职责划分清晰;但垂直方向上缺乏清晰的边界,上下层模块之间是多对多的依赖关系,比如业务模块1 (图中BO1)可能调用数据层所有模块DAO1~3, DAO1也可能被业务层所有模块BO1~3调用。

    单体应用通过水平分层,降低了业务复杂性;同时模块之间是进程内部调用,技术实现简单。

    但单体应用对系统的切分不彻底,只有水平切分,并且是逻辑上,因此适合业务比较单一,但深度上比较复杂的系统,比如TCP/IP网络通讯,从应用层/传输层/网络层/链路层,层层推进,类似这样的系统可以方便地增加水平层次去适配。

    对于广度上复杂的业务,由于缺乏垂直切分,强行把不同业务绑定在一起,整个系统神散形不散,带来一系列问题。比如OTA网站包含机票/酒店/旅游等多个垂直业务板块,每块都比较独立,就不适合放在一起开发维护。

    单体式应用的优点明显:

    现有IDE都是集成开发环境,非常适合单体式应用,开发、编译、调试一站式搞定。
    一个应用包含所有功能,容易测试和部署。
    运行在一个物理节点,环境单一,运行稳定,故障恢复简单。
    单体式应用的缺点也明显:

    业务边界模糊,模块职责不清晰,当系统逐渐变大,代码依赖复杂,难以维护。
    所有人同时在一个工程上开发,容易发生代码修改冲突,依赖复杂导致项目协调困难,并且局部修改影响不可知,需要全覆盖测试,需要重新部署,难以支持大团队并行开发。
    当系统很大时,编译和部署耗时。
    应用水平扩展难,一方面状态在应用内部管理,无法透明路由;另一方面,不同模块对资源需求差异大,当业务量增大时,一视同仁地为所有模块增加机器导致硬件浪费。
    作者之前曾在一家大型电商公司工作,当时整个网站是一个单体应用,有数百万行代码,有专门的团队负责代码合并,有专门的团队负责编译脚本开发,有一套复杂的火车模型协调不同团队,整套流程体系很精密很复杂,但这何尝不是单体应用的无奈和代价。

    分布式架构应用

    在分布式应用架构中,应用相互独立,每个应用代码独立开发,独立部署,应用通过有限的API接口互相关联。API接口属于应用一部分,一般和表示层处于同一层次,两者共享业务逻辑层,API和表示层采用同样的web端技术,通讯协议一般使用HTTP,数据格式是JSON,应用集成方式比较简化。

    分布式架构首先对系统按照业务进行垂直切分,对广度上复杂的业务实现物理解耦,应用内部还是水平切分,对深度上复杂的业务实现逻辑解耦。分布式架构也可以解决业务量大的问题,对于某些高并发/大流量系统,把系统切分为不同应用,针对资源需求特点(比如CPU/IO/存储密集型),通过加强硬件配置满足不同应用的需求,避免一刀切方式带来的资源浪费。

    技术上,API采用标准的HTTP/JSON进行通讯,调用双方实现难度都不大,但是API
    一般是“裸奔”的,在系统层面,调用依赖关系不透明,调用可靠性缺乏保障,因此只适用应用之间依赖链路少,调用量不大的系统,即应用之间耦合确实够松的系统。

    优缺点
    分布式架构每个应用内部高内聚,独立开发、测试和部署,支持开发敏捷;同时应用之间松耦合,业务边界清晰,业务依赖明确,支持大项目并行开发,实现业务敏捷。

    在分布式架构中,应用的表示层和API没有物理分离,需要同时满足自身业务需求和关联业务需求,相互影响,比如API接口会随着外部应用的需求经常变化,这会导致整个应用重新部署。

    运行时,API以HTTP/REST方式通过网络对外提供接口,其通信可靠性和数据的封装性相对于进程内调用比较差,如果没有一些可靠的技术机制,如路由保障/失败重试/监控等, 裸奔的API方式将严重影响系统整体可用性。

    SOA架构
    架构模型
    图片描述

    广义上,SOA也是分布式应用架构一种,但内涵不同。

    这里有两种类型“应用”,应用1~N是前端应用,面向用户,服务1~N是service,只提供业务逻辑和数据。这些应用都是独立部署,前端应用不再通过API直接关联,而是通过后端服务共享业务逻辑。

    此外相对于“裸奔”的API,SOA架构提供配套的服务治理,包括服务注册、服务路由、服务授权、服务降级、服务监控等等。这些功能通过专门的中间件支持,有中心化和去中心化两种方式,具体技术实现机制和适用场景,网上有很多专门介绍,这里就不展开了。

    SOA架构在分布式架构垂直切分的基础上,进一步把原来单体应用的业务逻辑层独立成service,做到物理上的彻底分离。

    每个service专注于特定职责,实现系统核心业务逻辑,service之间通过互相调用,可以完成复杂业务逻辑,解决业务深度上的问题;同时service面向众多的应用,以共享的方式支持逻辑复用。所以,SOA架构既体现业务的分,又体现业务的合,更多地从业务整体上考虑系统拆分。

    相比分布式应用架构,基于SOA的系统有大量的service应用,整个系统基于服务调用,所以对服务依赖的透明性和服务调用的可靠性提出很高要求,需要专门的SOA框架支持,还需要配套的监控体系和自动化的运维系统支持,技术复杂性高,SOA架构可以集中体现一个企业的IT技术能力。

    优缺点
    SOA架构优缺点如下图所示:

    图片描述

    相比较普通API方式,SOA架构更进一步:

    1)每个service都是浓缩的精华,聚焦某方面核心业务,同时以复用的方式供整个系统共享。
    2)服务作为独立的应用,独立部署,接口清晰,很容易做自动化测试和部署。
    3)服务是无状态的,很容易做水平扩展;通过容器虚拟化技术,实现故障隔离和资源高效利用,业务量大的时候,加机器即可。
    4)基于SOA的系统可以根据服务运行情况,灵活调控服务资源,包括服务上下架、服务升降级等,使系统真正具备可运营的能力。

    当然天下没有免费的午餐,SOA也带来了额外复杂性和弊端:

    1)系统依赖复杂,给开发/测试/部署带来一系列挑战。
    2)端到端的调用链路长,可靠性降低,依赖网络状况、服务框架及具体service的质量。
    3)分布式数据一致性和分布式事务支持困难,一般通过最终一致性简化解决。
    4)端到端的测试和排障复杂,SOA对运维提出更高要求。

    SOA落地方式
    在实践中,SOA架构不断深入发展,具体落地形式也多种多样。

    1)面向外部SOA

    SOA的前身是web service,web service初衷是企业之间通过Internet进行互联,如下图所示:

    图片描述

    每个公司把自己的优势资源通过web service发布,如图中天气服务/机票服务/酒店预订服务来自不同公司,其他企业可以直接调用服务或整合多个服务,实现企业间资源共享。

    2)面向应用SOA

    面向应用SOA把原单体应用里的业务逻辑层剥离出来,作为单独的服务对外提供。
    举一个电商的例子,这里有两个应用,顾客使用的商品详情页,展示商品的信息、商品库存,商品价格;内部客服人员使用的客服系统,根据顾客来电要求,修改订单,同时也需要获取商品的基本信息、价格信息等。

    经过SOA改造后,应用架构如下图所示:

    图片描述

    这里的service实现底层数据对于前端页面的透明化,表示层和业务逻辑各自独立维护,同时全部业务逻辑对其他应用开放,新应用可以自由整合来自多个服务的接口,快速支持业务创新。

    面向应用的SOA架构对系统进行物理上的水平切分,结果是表示层单飞,逻辑层对外全开放。但每个service是原系统业务逻辑的封装,接口设计面向原应用的业务case,如果其它应用的需求有差异,则自己创建service访问底层数据。如此导致service职责不够聚焦,类似的接口分散化,同时底层数据表被多方访问,数据模型修改困难,数据一致性难以保障。

    最终系统整体依赖复杂,容易形成网状结构,修改时,往往牵一发动全身。

    3)微内核SOA
    每个企业都有自己的核心数据,比如对于电商系统来说,用户/商品/订单/库存/价格都是核心数据,称之为主数据。微内核SOA聚焦各类主数据,封装相关表的所有访问,架构示意如下:

    图片描述

    每个服务独占式地封装对应主数据表的访问,这些服务构成系统的基础服务,一起组成系统的微内核,供所有上层应用共享。

    微内核服务是原子服务,接口粒度比较细,可以在其上构造聚合服务,为上层应用提供粗粒度服务。可以是信息聚合,比如图中商品聚合服务整合商品的基本信息/库存/价格;也可以是流程聚合,比如下单接口,调用来自多个服务的接口,共同完成复杂的下单操作。

    这里服务是分层次的,聚合服务是上层,基础服务是底层,依赖规则如下:

    上层服务可以调用同层服务和基础服务
    基础服务是原子服务,不可相互调用
    前端应用可调用聚合服务和跨层调用基础服务
    微内核的微表示服务数量有限,接口粒度细;内核表示这些基础服务处于调用底层,负责核心数据和业务,这和操作系统的内核概念上类似,主数据相当于核心的硬件,如cpu/内存/外存等,微内核的各个基础服务分别负责这些核心资源的管理,屏蔽底层的复杂性,对上层应用提供统一入口和透明化访问。

    最近微服务很火,其特征是职责单一、接口粒度细、轻量级通讯协议等,微内核SOA架构有微服务的形,同时有业务内核的神,是架构形散神不散思想的很好体现,这个在淘宝、京东、一号店等大型电商系统都已有丰富实践。

    4)方式比较

    面向企业外部SOA,业务场景有特殊性,不深入分析,这里主要比较面向应用SOA和微内核SOA的区别,一个大型B2C电商系统,应用和主数据是多对多依赖关系,如下图所示:

    图片描述

    面向应用的服务从特定应用出发,整合应用对相关数据的访问需求;微内核服务从特定主数据为中心,收敛各个业务对数据的访问需求。

    在面向应用的服务设计下,数据表的访问入口是发散的,来自多个应用,这带来一系列弊端:
    1)数据模型碎片化
    每个应用都会基于自己的需求,往表里加字段,很多电商的商品表/订单表有多达200个字段,都是野蛮增长,缺少控制的结果。
    2)数据模型修改困难
    类似的访问需求散布在多个服务,缺乏整合,同时表schema修改会影响很多服务和应用。
    3)连接资源利用率低
    多个服务直连数据库,并且每个服务会尽可能多地配置连接数,在应用数量多,业务并发量大的情况下,往往导致数据库连接数不够。

    微内核SOA通过收敛对主数据的访问,保证数据模型一致性、优化接口和有效利用数据库连接资源。同时通过服务分层,简化系统依赖关系。更为重要的是,微内核服务保证了业务模型的一致性,比如电商系统的商品体系,包含单品/系列商品/组合商品/搭售商品/虚拟商品等一系列复杂概念,这些复杂逻辑在基础商品服务里处理,对上层业务透明一致。

    如果业务模式简单,应用数量少,特定主数据的访问绝大多数(比如说80%)来自某个应用,则服务设计以应用为中心是可以的,不利影响比较小。

    对于大型互联网系统,业务广度和深度都复杂,但无论多复杂的系统,主数据类型都是有限的,可以通过聚焦有限的基础业务,以此支持无限的应用业务,结果是底层业务模型稳定,上层业务可以灵活扩展。

    面向应用的服务设计是SOA初级阶段,从具体业务着手,自底向上,难度小;微内核服务设计是SOA高级阶段,从全局着手,对业务和数据模型高度抽象,自顶向下,难度大。

    值得注意的是,在提供基础服务同时,每个应用也可以创建自己需要的服务(但主数据的访问必须通过基础服务),所以微内核的服务和面向应用的服务可以有机结合在一起,当业务应用变得很多,并且不断增长,可以考虑逐步往基础服务过渡,整合特定主数据有关的业务逻辑。

    顺便提一下,应用架构会影响组织架构,如果采用面向应用的服务设计,具体service一般由相关应用的团队负责;如果是微内核的服务设计,一般由单独的共享服务部门负责所有基础服务开发,和各个业务研发部门并列,保证设计的中立性和需求响应的及时性。

    应用架构的进化
    软件是人类活动的虚拟,业务架构是生产活动的体现,应用架构是具体分工合作关系的体现。
    单体应用类似原始氏族时代,氏族内部有简单分工,氏族之间没有联系;分布式架构类似封建社会,每个家庭自给自足,家庭之间有少量交换关系;SOA架构类似工业时代,企业提供各种成品服务,我为人人,人人为我,相互依赖。微内核的SOA架构类似后工业时代,有些企业聚焦提供水电煤等基础设施服务,其他企业在之上提供生活服务,依赖有层次。

    业务架构是生产力,应用架构是生产关系,技术架构是生产工具。业务架构决定应用架构,应用架构需要适配业务架构,并随着业务架构不断进化,同时应用架构依托技术架构最终落地。

    企业一开始业务比较简单,比如进销存,此时面向内部用户,提供简单的信息管理系统(MIS),支持数据增删改查即可,单体应用可以满足要求。

    随着业务深入,进销存每块业务都变复杂,同时新增客户关系管理,以更好支持营销,业务的深度和广度都增加,这时需要对系统按照业务拆分,变成一个分布式系统。

    更进一步,企业转向互联网+战略,拓展在线交易,线上系统和内部系统业务类似,没必要重做一套,此时把内部系统的逻辑做服务化改造,同时供线上线下系统使用,变成一个简单的SOA架构。

    紧接着业务模式越来越复杂,订单、商品、库存、价格每块玩法都很深入,比如价格区分会员等级,访问渠道(无线还是PC),销售方式(团购还是普通)等,还有大量的价格促销,这些规则很复杂,容易相互冲突,需要把分散到各个业务的价格逻辑进行统一管理,以基础价格服务的方式透明地提供给上层应用,变成一个微内核的SOA架构。

    同时不管是企业内部用户,还是外部顾客所需要的功能,都由很多细分的应用提供支持,需要提供portal,集成相关应用,为不同用户提供统一视图,顶层变成一个AOA的架构(application orientated architecture)。

    随着业务和系统不断进化,最后一个比较完善的大型互联网应用架构如下图所示:

    图片描述

    最终整个系统化整为零,形神兼备,支持积木式拼装,支持开发敏捷和业务敏捷。

    应用架构,需要站在业务和技术中间,在正确的时间点做正确的架构选择,保证系统有序进化。

    更多相关内容
  • 分布式系统架构设计

    2021-02-24 05:09:37
    SOA全称(ServiceOrientedArchitecture)中文意思为面相服务架构,他是一种设计方法,轻重包含多个服务服务之间通过相互依赖最终提供一系列的功能,一个服务通常以独立的形式存在与操作系统进程中,各个服务之间...
  • #资源达人分享计划#
  • 微服务(Microservices)是一种架构风格,一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署,各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。在所有...

    微服务(Microservices)

    在过去的 2016 年和 2017 年,微服务技术迅猛普及,和容器技术一起成为这两年中最吸引眼球的技术热点。而以 Spring Cloud 为代表的传统侵入式开发框架,占据着微服务市场的主流地位。

    微服务(Microservices)是一种架构风格,一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署,各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。在所有情况下,每个任务代表着一个小的业务能力。

    形像一点来说,微服务架构就像搭积木,每个微服务都是一个零件,并使用这些零件组装出不同的形状。通俗来说,微服务架构就是把一个大系统按业务功能分解成多个职责单一的小系统,并利用简单的方法使多个小系统相互协作,组合成一个大系统。

    如果学科派一点,微服务架构就是把因相同原因而变化的功能聚合到一起,而把因不同原因而变化的功能分离开,并利用轻量化机制(通常为 HTTP RESTful API)实现通信。

    微服务架构 ≈ 模块化开发 + 分布式计算。

    需要注意的是**“微服务**”与“微服务架构”是有本质区别的。“微服务”强调的是服务的大小,它关注的是某一个点。而“微服务架构”则是一种架构思想,需要从整体上对软件系统进行通盘的考虑。

    微服务架构示意图:
    在这里插入图片描述

    常见的微服务组件及概念:

    服务注册:服务提供方将自己调用地址注册到服务注册中心,让服务调用方能够方便地找到自己。
    服务发现:服务调用方从服务注册中心找到自己需要调用的服务的地址。
    负载均衡:服务提供方一般以多实例的形式提供服务,负载均衡功能能够让服务调用方连接到合适的服务节点。并且,节点选择的工作对服务调用方来说是透明的。
    服务网关:服务网关是服务调用的唯一入口,可以在这个组件是实现用户鉴权、动态路由、灰度发布、A/B 测试、负载限流等功能。
    配置中心:将本地化的配置信息(properties, xml, yaml 等)注册到配置中心,实现程序包在开发、测试、生产环境的无差别性,方便程序包的迁移。
    API 管理:以方便的形式编写及更新 API 文档,并以方便的形式供调用者查看和测试。
    集成框架:微服务组件都以职责单一的程序包对外提供服务,集成框架以配置的形式将所有微服务组件(特别是管理端组件)集成到统一的界面框架下,让用户能够在统一的界面中使用系统。
    分布式事务:对于重要的业务,需要通过分布式事务技术(TCC、高可用消息服务、最大努力通知)保证数据的一致性。
    调用链:记录完成一个业务逻辑时调用到的微服务,并将这种串行或并行的调用关系展示出来。在系统出错时,可以方便地找到出错点。
    支撑平台:系统微服务化后,系统变得更加碎片化,系统的部署、运维、监控等都比单体架构更加复杂,那么,就需要将大部分的工作自动化。现在,可以通过 Docker 等工具来中和这些微服务架构带来的弊端。 例如持续集成、蓝绿发布、健康检查、性能健康等等。严重点,以我们两年的实践经验,可以这么说,如果没有合适的支撑平台或工具,就不要使用微服务架构。

    微服务架构的优点:

    降低系统复杂度:每个服务都比较简单,只关注于一个业务功能。
    松耦合:微服务架构方式是松耦合的,每个微服务可由不同团队独立开发,互不影响。
    跨语言:只要符合服务 API 契约,开发人员可以自由选择开发技术。这就意味着开发人员可以采用新技术编写或重构服务,由于服务相对较小,所以这并不会对整体应用造成太大影响。
    独立部署:微服务架构可以使每个微服务独立部署。开发人员无需协调对服务升级或更改的部署。这些更改可以在测试通过后立即部署。所以微服务架构也使得 CI/CD 成为可能。
    Docker 容器:和 Docker 容器结合的更好。
    DDD 领域驱动设计:和 DDD 的概念契合,结合开发会更好。

    微服务架构的缺点:

    微服务强调了服务大小,但实际上这并没有一个统一的标准:业务逻辑应该按照什么规则划分为微服务,这本身就是一个经验工程。有些开发者主张 10-100 行代码就应该建立一个微服务。虽然建立小型服务是微服务架构崇尚的,但要记住,微服务是达到目的的手段,而不是目标。微服务的目标是充分分解应用程序,以促进敏捷开发和持续集成部署。
    微服务的分布式特点带来的复杂性:开发人员需要基于 RPC 或者消息实现微服务之间的调用和通信,而这就使得服务之间的发现、服务调用链的跟踪和质量问题变得的相当棘手。
    分区的数据库体系和分布式事务:更新多个业务实体的业务交易相当普遍,不同服务可能拥有不同的数据库。CAP 原理的约束,使得我们不得不放弃传统的强一致性,而转而追求最终一致性,这个对开发人员来说是一个挑战。
    测试挑战:传统的单体WEB应用只需测试单一的 REST API 即可,而对微服务进行测试,需要启动它依赖的所有其他服务。这种复杂性不可低估。
    跨多个服务的更改:比如在传统单体应用中,若有 A、B、C 三个服务需要更改,A 依赖 B,B 依赖 C。我们只需更改相应的模块,然后一次性部署即可。但是在微服务架构中,我们需要仔细规划和协调每个服务的变更部署。我们需要先更新 C,然后更新 B,最后更新 A。
    部署复杂:微服务由不同的大量服务构成。每种服务可能拥有自己的配置、应用实例数量以及基础服务地址。这里就需要不同的配置、部署、扩展和监控组件。此外,我们还需要服务发现机制,以便服务可以发现与其通信的其他服务的地址。因此,成功部署微服务应用需要开发人员有更好地部署策略和高度自动化的水平。
    总的来说(问题和挑战):API Gateway、服务间调用、服务发现、服务容错、服务部署、数据调用。
    不过,现在很多微服务的框架(比如 Spring Cloud、Dubbo)已经很好的解决了上面的问题。

    服务网格(Service Mesh)

    2017 年底,非侵入式的 Service Mesh 技术从萌芽到走向了成熟。

    Service Mesh 又译作“服务网格”,作为服务间通信的基础设施层。

    如果用一句话来解释什么是 Service Mesh,可以将它比作是应用程序或者说微服务间的 TCP/IP,负责服务之间的网络调用、限流、熔断和监控。对于编写应用程序来说一般无须关心 TCP/IP 这一层(比如通过 HTTP 协议的 RESTful 应用),同样使用 Service Mesh 也就无须关系服务之间的那些原来是通过应用程序或者其他框架实现的事情,比如 Spring Cloud、OSS,现在只要交给 Service Mesh 就可以了。

    Service Mesh 的来龙去脉:

    1. 从最原始的主机之间直接使用网线相连
    2. 网络层的出现
    3. 集成到应用程序内部的控制流
    4. 分解到应用程序外部的控制流
    5. 应用程序的中集成服务发现和断路器
    6. 出现了专门用于服务发现和断路器的软件包/库,如 Twitter 的 Finagle 和 Facebook 的 Proxygen,这时候还是集成在应用程序内部
    7. 出现了专门用于服务发现和断路器的开源软件,如 Netflix OSS、Airbnb 的 synapse 和 nerve
    8. 最后作为微服务的中间层 Service Mesh 出现

    Service Mesh 有如下几个特点:

    应用程序间通讯的中间层
    轻量级网络代理
    应用程序无感知
    解耦应用程序的重试/超时、监控、追踪和服务发现

    Service Mesh 架构图:
    在这里插入图片描述

    目前流行的 Service Mesh 开源软件有 Linkerd、Envoy 和 Istio,而最近 Buoyant(开源 Linkerd 的公司)又发布了基于 Kubernetes 的 Service Mesh 开源项目 Conduit。

    Service Mesh 开源项目简介:

    Linkerd:第一代 Service Mesh,2016 年 1 月 15 日首发布,业界第一个 Service Mesh 项目,由 Buoyant 创业小公司开发(前 Twitter 工程师),2017 年 7 月 11 日,宣布和 Istio 集成,成为 Istio 的数据面板。
    Envoy:第一代 Service Mesh,2016 年 9 月 13 日首发布,由 Matt Klein 个人开发(Lyft 工程师),之后默默发展,版本较稳定。
    Istio:第二代 Service Mesh,2017 年 5 月 24 日首发布,由 Google、IBM 和 Lyft 联合开发,只支持 Kubernetes 平台,2017 年 11 月 30 日发布 0.3 版本,开始支持非 Kubernetes 平台,之后稳定的开发和发布。
    Conduit:第二代 Service Mesh,2017 年 12 月 5 日首发布,由 Buoyant 公司开发(借鉴 Istio 整体架构,部分进行了优化),对抗 Istio 压力山大,也期待 Buoyant 公司的毅力。
    nginMesh:2017 年 9 月首发布,由 Nginx 开发,定位是作为 Istio 的服务代理,也就是替代 Envoy,思路跟 Linkerd 之前和 Istio 集成很相似,极度低调,GitHub 上的 star 也只有不到 100。
    Kong:比 nginMesh 更加低调,默默发展中。

    关于微服务和服务网格的区别,我的一些理解:微服务更像是一个服务之间的生态,专注于服务治理等方面,而服务网格更专注于服务之间的通信,以及和 DevOps 更好的结合。

    展开全文
  • 使用蓝牙LE网状网络的分布式聊天Messenger。 完全分散的架构,无需服务器或Internet连接 消息缓存,延迟传输 公共私有端到端加密消息通道 语音留言,图像,文件联系人附件 具有可配置节点,链接更多功能的...
  • 汽车服务架构(SOA)开发设计

    千次阅读 2022-02-23 16:51:42
    以在企业内部跨企业创建新业务功能方面重用重新组合服务,SOA很好的做到了“粗粒度”“松散耦合”的特点,相较于当前分布式物理架构具有更大的灵活性。SOA 最佳实践创建包含业务流程的设计—— 并增强将流程...

    目录

    汽车服务架构(SOA)开发设计

    1.什么是SOA

    1.1 SOA优缺点

    1.2 SOA 应用优势

    1.3 服务的基本结构

    1.4 SOA架构的核心要素

    1.5 SOA服务架构开发趋势

    1.6 SOA与E/E架构

    1.6.1 域控制为核心的架构

    1.6.2 区域控制为核心的SOA架构

    1.7 以服务为核心的SOA开发思路

    1.7.1 AP(Adaptive Platform)的开发

    a. 定义服务内容

    b. 定义服务接口

    c. 配置服务关系

    d. 通讯协议设计

    2. SOA设计

    2.1  SOA 设计原则

    2.2  服务构件与传统构件

    2.3  关键技术

    2.3.1  UDDI 

    2.3.2 WSDL 

    2.3.3 SOAP

    2.3.4 REST 

    2.3.5 ESB

    2.4 SOA实现

    2.4.1  Web Service

    2.4.2 服务注册表

    2.4.3 企业服务总线

    2.5 SOA实现基础

    2.6 开发流程

    2.7 开发工具链

    2.8 SOA的应用实例

    3. 汽车SOA开发

    3.1面向服务架构的汽车软件及开发方法

    3.1.1 如何分析和设计服务架构

    3.1.2 如何建模和记录面向服务的架构

    3.1.3 如何部署和实现面向服务的软件

    3.1.4 SOA汽车软件创新平台

    3.2 面向服务架构的汽车软件分析和设计

    3.2.1 系统需求分析

    3.2.2 系统功能分析

    3.2.3 候选服务分析

    3.2.4 系统架构设计

    3.2.5 软件架构设计

    3.3 面向服务架构(SOA)的汽车软件实现和部署

    3.3.1 满足 SOA 架构的服务组件架构SCA

    (Service-Component-Architecture)

    3.3.2 服务组件架构SCA的配置描述

    3.3.3 汽车SOA软件的实现方案

    3.3.4 SOA服务组件实现和部署的具体步骤

    3.4 核心模型设计

    3.5 图表设计

    3.6 服务设计

    3.7 AP平台SOA相关技术规范概述

    4. SOA流程开发在自动驾驶车企中布局

    5. 企业管理开发流程与SOA软件架构开发之间的关系

    6. SOA的两种不同开发模式原理

    6.1业务驱动型开发

    6.2平台驱动型开发

    7. 基于AUTOSAR的SOA开发

    7.1 基于AUTOSAR的SOA软件架构

    7.2 基于SOA构建软件设计方法

    7.3 系统架构-虚拟功能总线

    7.4 SOA软件分层

    7.4.1 应用软件

    7.4.2 实时运行环境

    7.4.3 基础软件

    7.5 基于AUTOSAR的SOA服务

    7.6 硬件抽象

    7.7 基于AUTOSAR的SOA系统配置

    8.总结

    1.什么是SOA

    SOA (服务导向架构,Service Oriented Architecture)  作为一种架构范式,展示了技术中立的最佳实践。其建立在标准之上,可在供应商的广泛支持下在全球范围内实现经济高效的实施。以在企业内部和跨企业创建新业务功能方面重用和重新组合服务,SOA很好的做到了“粗粒度”和“松散耦合”的特点,相较于当前分布式物理架构具有更大的灵活性。SOA 最佳实践创建包含业务流程的设计 —— 并增强将流程外包和扩展给业务合作伙伴的能力。此外,SOA也可以复用已有的系统和流程,与传统的基于孤岛的应用程序开发更具战术性的本质形成对比,可以保留和增强现有投资承建的架构、软件等实现的部分有用性。

    1.1 SOA优缺点

    优点:

    1. 扩展方便:可针对单个服务提供资源扩展
    2. 语言通用:接口通用,服务可以基于任何语言
    3. 新人友好:单一模块服务理解透彻即可服务此模块,不必理会架构
    4. 发版方便:可更新单一模块,不影响架构

    缺点:

    1. 问题排查不便:功能调用服务多,很难直接定位问题点
    2. 沟通不便:模块独立,不确定其他模块状态
    3. 性能问题:通信时间损耗
    4. 关系混乱:服务越来越多,调用方越来越多的时候,就会比较混乱
    5. 运维难度:随着服务的增多,系统架构会越发复杂,这就给运维层面带来了挑战
    6. 数据一致性问题:单体项目因为数据都在同一个数据库里面,不需要过多的关注分布式事务等问题,SOA就需要关心了

    1.2 SOA 应用优势

    早期的车内嵌入式软件没有统一标准,基础软件和应用软件强耦合,不具可移植性;AUTOSAR Classic 的应用,对嵌入式基础软件的接口进行标准化,让应用开发者基于统一的基础软件接口进行应用开发。目前采用SOA软件服务架构的应用打通了车内的电子电气架构的壁垒,进一步对嵌入式应用软件的接口(即服务接口)进行了标准化,让APP开发者基于统一基础服务接口进行应用的迭代开发,隐藏了不同车型配置下应用软件的差异,真正做到了整车级软件接口的"标准"和"开放"。

    平台架构升级更便于实现,通过服务设计的方式,能够有效降低架构升级带来的复杂度;同时,由于操作系统跨平台的难度大幅度降低,能够大幅提升用户体验,能够实现更为便捷的联网功能,实现不同平台间的各种APP共享等功能;

    通过“服务Hub”区域控制器的引入,各种新功能能够灵活地与其他域功能,乃至互联网接口集成,而无需各个控制器各自进行信号到服务的转换; 

    一些相对独立的域开发能够打破界限,找到新的上限,例如自动驾驶功能不再是电子电气架构“孤岛”,通过区域控制器进行服务互通,可以轻松实现高清地图的创建、更新及路线预测等功能,便于实现车辆信息的上传及云端指令的下达。

    1.3 服务的基本结构

    独立的服务结构如下图

    服务模型的表示层从逻辑层分离出来,增加了服务对外的接口层。通过对服务接口的标准化描述,使得服务可以提供给在任何异构平台和任何用户接口使用。这允许并支持基于服务的系统成为松散耦合、面向构件和跨技术实现,服务请求者很可能根本不知道服务在哪里运行、是由哪种语言编写的,以及消息的传输路径,而是只需要提出服务请求,然后就会得到答案。

    1.4 SOA架构的核心要素

    要准确全面理解SOA,首先必须理解SOA的核心要素:

    SOA的目标就是实现灵活可变的IT系统。要达到灵活性,通过三个途径来解决:标准化封装、复用、松耦合可编排。


    互操作(标准化封装)、复用、松耦合等SOA技术的内在机制,也是中间件技术和产品的本质特征。


    标准化封装(互操作性)


    传统软件架构,因为封装的技术和平台依赖性,一直没有彻底解决互操作问题。互联网前所未有的开放性意味着各节点可能 采用不同的组件、平台技术,对技术细节进 行了私有化的约束,构件模型和架构没有统一标准,从而导致架构平台自身在组件描述、发布、发现、调用、互操作协议及数据传输等方面呈现出巨大的异构性。各种不良技术约束的结果是软件系统跨互 联网进行交互变得困难重重,最终导致了跨企业/部门的业务集成和重组难以灵活快速的进行。


    在软件的互操作方面,传统中间件只是实现了访问互操作,即通过标准化的API实现了同类系统之间的调用互操作,而连接互 操作还是依赖于特定的访问协议,如JAVA使用RMI,CORBA使用IIOP等。而SOA通过标准的、支持Internet、与操作系统无 关的SOAP协议实现了连接互操作。而且,服务的封装是采用XML协议,具有自解析和自定义的特性,这样,基于SOA的中间 件还可以实现语义互操作。


    SOA要实现互操作,就是通过一系列的标准族,来实现访问、连接和语义等各种层面的互操作。


    软件复用


    软件复用,即软件的重用,也叫再用,是指同一事物不作修改或稍加改动就多次重复使用。从软件复用技术的发展来看,就 是不断提升抽象级别,扩大复用范围。最早 的复用技术是子程序,人们发明子程序,就可以在不同系统之间进行复用了。但 是,子程序是最原始的复用,因为这种复用范围是一个可执行程序内复用,静态开发 期复用,如果子程序修改,意味着所有 调用这个子程序的系统必须重新编译、测试和发布。

    SOA的复用

    为了解决这个问题,人们发明了组件(或者叫控件),如MS操作系统下的DLL组件。组件将复用提升了一个层次,因为组件可以在一个系统内复用(同一种操作系统),而且是动态、运行期复用。这样组件可以单独发展,组件与组件调用者之间的耦合度降低。


    为解决分布式网络计算之间的组件复用,人们发明了企业对象组件,如(Com+,.NET,EJB等),或者叫分布式组件。通过远程对象代理,来实现企业网络内复用,不同系统之间复用。


    传统架构的核心是组件对象的管理。但分布式组件也是严重依赖其计算环境,由于构件实现和运行支撑技术之间存在着较大的 异构性,不同技术设计和实现的构件之间无法直接组装式复用。


    而现代SOA的重要特征就是以服务为核心,如WebService,SCA/SDO等。通过服务,或者服务组件来实现更高层次的复用、 解耦和互操作,即SOA架构中间件。


    因为服务是通过标准封装,服务组件之间的组装、编排和重组,来实现服务的复用。而且这种复用,可以在不同企业之间,全球复用,达到复用的最高级别,并且是动态可配置的复用。


    耦合关系


    SOA架构在松耦合解耦过程也发展到了最后的境界。传统软件将软件之中核心三部分网络连接、数据转换、业务逻辑全部耦 合在一个整体之中,形成“铁板一块”的软件, “牵一发而动全身”,软件就难以适应变化。分布式对象技术将连接逻辑进行分 离,消息中间件将连接逻辑进行异步处理,增加了更大的灵活性。消息代理和一些分 布式对象中间件将数据转换也进行了分 离。而SOA架构,通过服务的封装,实现了业务逻辑与网络连接、数据转换等进行完全的解耦。

    SOA不断解耦的过程


    总之,从科学哲学的角度来看,SOA是一个不断解构的过程,传统软件强调系统性,耦合度过高,所以需要松耦合(解耦);SOA也是一个组件粒度的平衡,集成电路趋势是集成度越来越高,软件发展的趋势是相反的过程;SOA是架构,更是 方法,反映了人们对哲学思想的追求的原动力。


    按照这个特性,SOA基本上来说与WebService并不是同一个概念,SOA并不一定需要WebService实现,理论上可以在其他技 术体系下,实现SOA。但事实上,到目前为止,能够实现SOA架构风格的技术就是WebService,因为它的特性和厂商的支持 力度,使得WebService成为了实现SOA实现技术的事实标准。也正因为WebService技术的成熟,才使得已经提出10多年了的 SOA思想和概念,得以能够实现落地,成为一种可以使用的技术。这也就是回答了SOA和WebService的关系。

    1.5 SOA服务架构开发趋势

    传统汽车使用由上百个ECU组成的分布式EE架构,OEM定义对各ECU的功能需求,由不同供应商负责最终功能实现。这种架构导致大量功能控制逻辑在子节点ECU内部完成,传感器、执行器信号被掩埋在分布网络下,仅通过在局部网络的ECU部署基于服务的通讯,无法实现对整车硬件能力的充分暴露。且考虑到基于SOA软件平台,未来SOP后的车型也需具备硬件冗余能力以应对OTA软件升级,上百个ECU的冗余设计将极大增加成本支出,也导致跨域功能OTA的实现将涉及数量众多的ECU。
       随着车载芯片算力的提升和高带宽、低时延车载以太网通讯技术的落地,EE架构已从分布式演进至域集中 (Domain Centralized),并向整车集中+区域 (Vehicle Computer & Zonal)、整车集中 (Vehicle Centralized)不断进化。在高集成度的EE架构下,域控制器将承担整车主要逻辑,而执行器、传感器将成为纯粹的执行机构,执行控制命令或是提供环境感知数据。
       基于整车集中EE架构的“硬地基”, SOA在域控制器上的部署才能够实现整车能力的资源获取,并将其封装为标准的服务和接口向应用层开放。

    1.6 SOA与E/E架构

    1.6.1 域控制为核心的架构

    电子电气架构的概念从总线引入汽车开始就不断更新和演化,如今一套完整的整车数字架构所考虑的内容除了传统的拓扑、网络、线束与电气分配、逻辑功能分配,还需结合整车的功能/信息安全架构、数据架构、计算架构,以及实现通讯架构与软件架构的协同,功能架构与服务架构的协同,车内服务与云端服务的协同。
    如图所示:域集中架构在连接上由功能域控制器,分别通过子网与各功能域内ECU相连接,而域控制器之间则修建通讯“高速公路”,通过高带宽的骨干网络相连。拓扑结构只是架构的表象,而表象背后的核心特征是功能逻辑被抽象上移至功能域控制器中。每个域控制器有对应的集成的(Signal to Services), 在域控制器中进行功能的分配、功能的集成。而某个域控制器作为云端链接的桥梁,将平行的几个域控制器的逻辑运算功能输入到云端。功能逻辑运算服务的重心在域控制器中。

    1.6.2 区域控制为核心的SOA架构

    如图所示:整车集中和区域架构在连接上是通过分布在车内各物理区域的区域网关/控制器将车内物理I/O分别就近连接和控制,形成整车数字系统的“手”和“脚”,然后通过骨干网络与系统中的“大脑”控制单元进行连接。连接关系同样只是表象,而核心价值在于将车内软件(运算)和硬件解耦,彻底实现软件独立“生长”(或者说算力架构可以迭代,共享算力变成了可能),而硬件同样可以独立“生长”(跨车型平台,或者在车辆生命周期内为用户提供升级服务,而这些在传统架构中实现的成本是不可控的)。

    1.7 以服务为核心的SOA开发思路

    虽然电子电气架构开发从理论上是正向开发,但实际上一款车型的开发并不是完全从零开始的,很多功能方案会沿用老款车型。这样的后果是,系统和软件模块已经固定,即无法通过正向设计的思路拆解逻辑,设计服务。考虑这种情况,服务设计可以分为以下两种方法。


    (1)自下而上的方法


    适用于现有平台上已实现的功能或系统。此种方法的基础是,功能的网络分配,通信,ECU软件架构,功能规范和使用场景等都已经有明确定义。我们可以利用现有的这些输入,完成将原有功能对SOA的转换。

    适用功能和系统:

    1. 车身舒适的大部分功能,如车门,车窗,座椅,空调等,功能逻辑没有太大争议,就可以通过现有子系统规范和网络信号清单,进行服务接口设计。
    2. 动力和底盘系统。这是整车中对安全要求最高的两个系统,因此一般来说,我们在设计第一代SOA架构时。这两个系统更适合自下而上的方法,通过对已有功能的提取,转换为服务接口,接入整车服务系统。
    3. 传感器和执行器资源。汽车上的每个元件都代表了一种基础能力。基于整车传感器和执行器清单,能够快速形成一份基础服务清单。由此出发,再通过功能梳理,层层往上,可以形成更加丰富多层次的服务列表。


    (2)自上而下的方法


    自上而下的方法即为正向设计方法。在基于SOA的电子电气架构开发中,对于复杂功能,或者引入到平台中的新功能和新系统,必须遵循这种方法完成服务设计。基于上述所介绍的开发流程,从需求出发,进行逻辑拆解,服务拆解,软件架构搭建,系统设计等。这个方法所依赖的输入一般是功能需求表和用户场景。


    不管使用哪种方法,通常服务的设计是在单个功能或系统级别定义的,最后需要架构师综合考虑整车系统,将高度复用性的服务归类为平台级通用服务。通用服务池子是“生态共创”的基础。


    服务的分类:

    1. 硬件抽象服务根据ECU的功能和硬件外围设备(传感器和执行器),定义硬件抽象服务。这些服务同时属于平台级核心服务。示例:Camera interface,Rain sensor interface
    2. 平台级核心服务在应用程序集群和域之间通用的所有服务。示例:Power mode,Vehicle speed,Key status
    3. 域级核心服务在域内的应用程序集群内不同应用程序之间通用的服务。示例:Front vehicle distance calculate,Front obstacles
    4. 应用服务为每个特定的应用程序或系统功能服务的服务。示例:Enable ACC,AEB system status


    服务设计的输入要求:

    (1)应用级别的服务

    1. 功能和系统描述,用户场景描述
    2. 功能和系统需求
    3. 功能和系统逻辑架构

    (2)平台级别的服务

    1. 跨域的系统设计文档
    2. 跨域的功能清单
    3. 网络拓扑
    4. 传感器和执行器列表(用于提取硬件抽象服务)

    因此,服务设计的输出主要为:
    (1)服务的定义

    1. 服务接口的定义
    2. 服务提供方和消费方信息
    3. 软件模块信息

    对应的输出文档可以分为:

    1. 服务定义矩阵
    2. 服务详细设计文档(包含软件实现信息)
    3. 服务数据库ARXML(涵盖通讯、服务、软件部署等信息)

    1.7.1 AP(Adaptive Platform)的开发

    a. 定义服务内容

    此步骤实际上就是搭建了一个系统功能架构,从整车层面即是按照功能需求定义并划分服务。对于SOA中的服务表示了一种独立的功能单元,一个服务可以包含其他子服务单元,使用标准接口进行通讯,将内部信息封装成一个黑盒子,实现子服务的重用性。上层服务可以通过该标准接口调用下层服务封装的子服务内容。同时,整体的服务内容可以被操控单元远程访问和独立更改或更新。同时,对于SOA来说,需要通过服务编排来定义清楚服务之间的相互关系。
    简单地说服务对于智能驾驶汽车而言就是定义产品,对其中产品的能力进行描述,这里的产品能力我们称之为PC(Product Capability)。实现这种产品能力需要从下至上定义硬件抽象服务、平台核心服务、域核心服务、应用程序服务。而每一个服务内容对应着一个或多个实现的软件模块,这里我们称之为SWC(Software Capability)

    产品能力 (PC) 描述了系统所需的一些高级功能。区别于系统设计,PC是用来分配职责的,所以很清楚哪个SWC Module软件模块(如摄像头识别模块、雷达识别模块、中央域控制器模块)应该实现什么。它们在功能设计时由功能负责人识别和请求。一些系统相关的PC也可以由系统架构师或模块负责人直接识别,在模块架构工作中映射PC时,模块所有者还可以确定对更多 PC 的需求。
    在确定并决定添加 PC 后,对应的软件模块拥有该 PC,模块所有者负责将其实施到正确的版本,并在平台的整个生命周期内维护/发展 PC。

    b. 定义服务接口

        服务接口是一种通信内容定义,其目的在于将服务从功能架构过渡到软件技术架构,且软件模块之间的关系需要被清晰的定义出来,过程中将服务内容封装成相应的接口被实际调用。这种接口定义是独立于通信协议的抽象实体,这种接口可以建立任何两个服务间的通信能力,而使用合适的工具链可以由此生成基于特定协议的接口。
    服务接口可分为方法(Method)、属性(Property)、事件(Event)三种类型。以智能驾驶的一个子功能执行接口服务为例,假设需要获取摄像头传感器探测的环境数据,而需要进行定义的服务接口中方法是要对传感器的参数进行后融合,那么就需要其底层服务提供摄像头处理的基础函数(如ISP、深度学习函数、BEV函数等)。而服务接口的属性则是通过一定的方法操作(如get/set)来获取该服务函数,这种服务属性可以对上层调用的服务部分可见,底层服务有变动上层的调用方式也会随之变动,这种变动所带来的更新会由服务底层决定何时发送给上层调用它的服务单元。
    服务接口定义完整后,开发人员可以根据该接口定义对其中的函数进行定义开发了。

    c. 配置服务关系

        此过程会建立软硬件之间的映射关系,实现从抽象的服务定义到软件层面的推导,从而方便实现软件驱动或调用硬件实现单元,这种结果是实现服务与中间件或底层硬件ECU之间的映射关系。从整个SOA的架构模型中我们知道服务需要从通用服务平台开始进行底层驱动,然后对上层传感器执行器的控制管理进行驱动。由于AP直接支持服务接口,可以直接面向上层应用层,CP仍然是对常用的底层应用服务的驱动映射,因此,两层驱动分别对应着经典的CP Autosar中间件调用和AP Autosar模式。

    d. 通讯协议设计

        智能网联汽车的SOA架构设计需要强大的环境感知、信息处理、实施决策、控制能力可以把智能交通、地图、定位、通讯、云、大数据等进行系统集成,故车端与云端、车辆与车辆之间、车辆内部的各个ECU之间通信的速率和数据量都比传统汽车高出几个数量级,这些需要由多种复杂的硬件、软件和高速通信总线共同实现,并在很大程度上决定智能汽车的功能实现和扩展的可靠性。车载以太网能够很好的解决大数据量的信息交互,整个通信协议的定义包括虚拟以太网VLAN,以太网交换机Switch,套接字Socket,基于IP的可扩展面向服务的中间件SOME/IP,SD等。而基于AVB的下一代协议TSN(时间敏感网络)可以提供非常优秀的实时性。


        以太网通讯设计过程包含对服务实例进行通讯协议相关的信息配置。由于SOA架构中包含多个应用实体之间的多通路通信过程,且这些通信通常是网状通信,因此需要在各个实体节点之间建立中间路由、转化等。区别于传统总线(Can/Lin),在软件架构设计过程中,开发人员需要设计具体的服务类型、服务ID、服务数据类型、服务角色等。

    详细内容见下面链接:

    汽车服务架构(SOA)开发设计https://download.csdn.net/download/ChrisKKC/82048291

    【积分下载】软件定义汽车服务API-第一部分:原子服务API参考https://download.csdn.net/download/ChrisKKC/85089142【积分下载】软件定义汽车服务API-第一部分:原子服务API参考 变更说明https://download.csdn.net/download/ChrisKKC/85089150【积分下载】软件定义汽车服务API-第二部分:设备抽象API参考https://download.csdn.net/download/ChrisKKC/85089177【积分下载】软件定义汽车服务API-第二部分:设备抽象API参考变更说明1、软件定义汽车服务2、SOA架构3、API接口参考4、设备抽象API5、变更说明更多下载资源、学习资料请访问CSDN下载频道.https://download.csdn.net/download/ChrisKKC/85089158

    展开全文
  • 什么是分布式架构2.SOA架构和微服务架构2.1 SOA架构2.2 MSA 微服务架构微服务特征2.3 SOA 架构和微服务架构的区别3.节点与网络3.1 节点3.2 网络4.分布式架构的演进4.1 初始阶段4.2 应用服务和数据服务分离4.3 使用...

    1.什么是分布式架构

    在这里插入图片描述

    分布式系统(distributed system)是建立在网络之上的软件系统,它有两个特性:

    • 1.内聚性
      数据库分布节点高度自治,有本地的数据库管理系统
    • 2.透明性
      每一个数据库分布节点对用户的应用来说都是透明的,看不出是本地还是远程

    在分布式数据库系统中,用户感觉不到数据是分布的,即用户不须知道关系是否分割、有无副本、数据存于哪个站点以及事务在哪个站点上执行等。
    简单来讲:在一个分布式系统中,一组独立的计算机展现给用户的是一个统一的整体,就好像是一个系统似的
    在这里插入图片描述

    在上图中,提到了一个SOA架构,那么这个SOA是什么呢?
    这是一个主流的架构模型,与其功能类似也是我们经常听到用到的是微服务架构

    2.SOA架构和微服务架构

    2.1 SOA架构

    SOA全称(Service Oriented Architecture) 中文意思为 面相服务的架构,他是一种设计方法,包含多个服务,服务之间通过相互依赖最终提供一系列的功能, 一个服务通常以独立的形式存在与操作系统进程中,各个服务之间通过网络调用

    跟SOA相提并论的还有ESB(企业服务总线),简单来说ESB就是管道,链接各个服务节点,为了集成不同系统和不同协议,ESB做消息的转化解释和路由的工作。让不同的服务连通。
    在未使用SOA架构时,系统初期:
    在这里插入图片描述

    随着业务的增长,系统后来就变成这个样子:
    在这里插入图片描述

    看起来是不是很糟糕,此时SOA架构应运而生,有了SOA之后就变成这个样子:
    在这里插入图片描述

    是不是看起来好多啦
    分布式架构的设计思路就是当业务发展到一定程度后,需要对服务进行解耦,进而把一个单一的大系统按逻辑拆分成不同的子系统,通过服务接口来通讯。
    面向服务的设计模式,最终需要总线集成服务,而且大部分时候还共享数据库,出现单点故障时会导致总线层面的故障,更进一步可能会把数据库拖垮,所以才有了更加独立的设计方案的出现。

    所以SOA解决了:

    • 1.系统集成,站在系统的角度,解决企业系统间的通信问题,把原先散乱无规划的系统间的网状结构,梳理成规划,可治理的系统间星型结构。 这一步需要引入一些产品,例如 ESB,以及技术规范,服务管理规范,这一步解决的核心问题是 有序
    • 系统的服务化 ,站在功能的角度,把业务逻辑抽象成可复用可组装的服务,通过服务的编排和实现业务的快速再生,目的:把原先固有的业务功能变为通用的业务服务,实现业务逻辑的快速复用,这步解决的核心问题是 复用
    • 3.业务的服务化,站在企业的角度,把企业只能抽象成可复用 可组装的服务,把原先职能化的企业架构转为变为服务花的企业架构,进一步提升企业的对外服务能力,前两步都是技术层面来解决系统调用,系统功能复用的问题,第三步 则是以业务驱动把一个业务单元封装成一项服务,这一步解决的核心问题是 高效

    2.2 MSA 微服务架构

    微服务是真正意义上的独立服务,从服务入口到数据持久层,逻辑上都是独立隔离的,无需服务总线来接入,但同时也增加了整个分布式系统的搭建和管理难度,需要对服务进行编排和管理,所以伴随着微服务的兴起,微服务生态的整套技术栈也需要无缝接入,才能支撑起微服务的治理理念。
    微服务架构和SOA架构类似,微服务架构是在SOA上做的升华,微服务架构强调的一个重点是“业务需要彻底的组件化和服务化”,原有的单个业务系统会拆分为多个可以独立开发设计运行的小应用。这些小应用之间通过服务完成交互和集成。
    组件表示一个可以独立更换和升级的单元,像 PC机中的 CPU 内存,显卡 等 独立且可以更换升级而不影响其他单元,如果我们把PC机作为组件以服务的方式构建,那么这台PC只需要维护主板和一些必要的外部设备,CPU ,内存,硬盘 都是以组件方式提供服务,PC需要调用CPU做计算机处理,只需要知道CPU这个组件的地址即可。
    如果一个分布式系统具备如下特点,则可以称之为“微服务架构”:

    • 1、任何一个服务都由多个独立的进程提供服务,这些进程可以分布在多台物理机上,任何进程宕机都不会影响系统提供服务;
    • 2、整个系统是由多个微服务有机组成的一个分布式系统,换而言之,不是一个巨大的单体应用。

    微服务特征

    • 1.通过服务实现组件化
    • 2.按业务能力来划分服务和开发团队
    • 3.去中心化
    • 4, 基础设施自动化(devops ,自动化部署)

    2.3 SOA 架构和微服务架构的区别

    • 1,微服务不在强调传统的SOA架构里面比较重的ESB企业服务总线,同时SOA的思想进入到单个业务系统内部实现真正的组件化。
    • 2,Docker 容器技术的出现,为微服务提供了便利的条件,比如更小的部署单元,每个服务都可以通过类似的Node或者Spring boot 等技术跑在自己的进程中,
    • 3,SOA 注重的系统集成方面,而微服务关注的是完全分离

    提到分布式,就不得不说一下节点的概念

    3.节点与网络

    3.1 节点

    传统的节点也就是一台单体的物理机,所有的服务都揉进去包括服务和数据库;
    随着虚拟化的发展,单台物理机往往可以分成多台虚拟机,实现资源利用的最大化,节点的概念也变成单台虚拟机上面服务;
    近几年容器技术逐渐成熟后,服务已经彻底容器化,也就是节点只是轻量级的容器服务。
    总体来说,节点就是能提供单位服务的逻辑计算资源的集合

    3.2 网络

    分布式架构的根基就是网络,不管是局域网还是公网,没有网络就无法把计算机联合在一起工作,但是网络也带来了一系列的问题。
    网络消息的传播有先后,消息丢失和延迟是经常发生的事情,我们定义了三种网络工作模式:

    • 同步网络

      • 节点同步执行
      • 消息延迟有限
      • 高效全局锁
    • 半同步网络

      • 锁范围放宽
    • 异步网络

      • 节点独立执行
      • 消息延迟无上限
      • 无全局锁
      • 部分算法不可行

    常用网络传输层有两大协议的特点简介:

    • TCP 协议
      • 首先 tcp 协议传输可靠,尽管其他的协议可以更快传输
      • tcp 解决重复和乱序问题
    • UDP 协议
      • 常量数据流
      • 丢包不致命

    4.分布式架构的演进

    4.1 初始阶段

    在这里插入图片描述

    初始阶段 的小型系统 应用程序、数据库、文件等所有的资源都在一台服务器上通俗称为LAMP

    4.2 应用服务和数据服务分离

    在这里插入图片描述

    应用程序、数据库、文件分别部署在独立的资源上
    好景不长,发现随着系统访问量的再度增加,webserver机器的压力在高峰期会上升到比较高,这个时候开始考虑增加一台webserver

    4.3 使用缓存改善性能

    在这里插入图片描述

    缓存是分布式系统中的重要组件,主要解决高并发,大数据场景下,热点数据访问的性能问题。
    提供高性能的数据快速访问。你可以理解为从磁盘里取出来数据,暂时存放在内存,以待后面处理来读取。而能存放在缓存的数据,通常是频繁访问的,不会经常修改的数据。

    系统访问特点遵循二八定律,即80%的业务访问集中在20%的数据上。缓存分为本地缓存和远程分布式缓存,本地缓存访问速度更快但缓存数据量有限,同时存在与应用程序争用内存的情况。

    数据库中访问较集中的一小部分数据存储在缓存服务器中,减少数据库的访问次数,降低数据库的访问压力

    对于不熟悉业务代码或算法的优化者,显然加一层缓存的复杂度和风险更低,而这一层看似简单的缓存,它给系统带来的性能优化有可能大大超过前者)
    在WebServer和DB之间加一层cache,这层cache一般选取的介质是内存,因为我们都知道存入数据库的数据都具有持久化的特点,那么读写会有磁盘IO的操作,内存的读写速度远比磁盘快得多。(选用存储介质,提高访问速度:内存>>磁盘;减少磁盘IO的操作,减少重复查询,提高吞吐量)

    缓存的业务场景

    常见的缓存有:

    • 1.浏览器缓存
      浏览器可以缓存一些静态资源,比如图片、js、css等,这些都是不常变化的内容,所以没有必要每次都去请求。(减少网络IO消耗,提高访问速度)
    • 2.CPU缓存
      是位于CPU与内存之间的临时存储器,它的容量比内存小的多但是交换 速度却比内存要快得多。
    • 3.数据库缓存
      • 将数据写入/读取速度更快的存储(设备);
      • 将数据缓存到离应用最近的位置;
      • 将数据缓存到离用户最近的位置。

    缓存系统常用的缓存淘汰策略:

    • 1、Least Frequently Used(LFU)策略
      计算使用频率,优先淘汰最不常用的缓存条目,CPU的cache所采用的淘汰策略即为LFU策略;
    • 2、Least Recently Used(LRU)策略–淘汰最近最少使用的条目;
    • 3、Adaptive Replacement Cache(ARC)策略–该策略由两个LRU组成,第1个LRU包含的条目是最近只被使用过一次的条目,第2个LRU包含的是最近被使用过二次的条目;
    • 4、其他还有一些基于缓存时间的淘汰策略,比如淘汰存活时间超过5分钟的缓存条目。

    分布式缓存都采用Hash算法进行数据分片,将数量庞大的缓存项均匀分布到集群中的每个节点上,比如Redis3.0开始实现的分布式集群功能就采用了Hash算法,将缓存项均匀分布到16384个Slot上去。
    以Redis2.x为基础改造的Codis是国内分布式缓存开源的一个典范,出自豆瓣网。
    Memcache本身并没有提供集群功能,但很多客户端Driver实现了Hash算法分配逻辑,因此也可以看成是一种分布式缓存的解决方案。
    内存计算产品:商业的SAP Hana、开源的VoltDB等。VoltDB是一种开源的高性能的内存关系型数据库,提供社区版和商业版,是一种NewSql,是一个借鉴并基于HSQL的分配内存数据库集群。
    更多分布式缓存信息点击此处查看

    4.4 应用服务集群

    在这里插入图片描述

    使用集群是系统解决高并发、海量数据问题的常用手段。通过向集群中追加资源,提升系统的并发处理能力,使得服务器的负载压力不再成为整个系统的瓶颈。

    同时多台服务器通过负载均衡同时向外部提供服务,解决单台服务器处理能力和存储空间上限的问题。

    4.5 数据库读写分离

    享受了一段时间的系统访问量高速增长的幸福后,发现系统又开始变慢了,这次又是什么状况呢,经过查找,发现数据库写入、更新的这些操作的部分数据库连接的资源竞争非常激烈,导致了系统变慢,至此我们可以通过设计数据集群,以及数据库的主从库,主负责写入,从库负责读取
    在这里插入图片描述

    4.6 反向代理和CDN加锁

    在这里插入图片描述

    为了应付复杂的网络环境和不同地区用户的访问,通过CDN和反向代理加快用户访问的速度,同时减轻后端服务器的负载压力。CDN与反向代理的基本原理都是缓存。
    不知道CDN是啥的,可以参考博文秒杀系统面试-2.1小节

    4.7 分布式文件系统和分布式数据库

    在这里插入图片描述

    任何强大的单一服务器都满足不了大型系统持续增长的业务需求,数据库读写分离随着业务的发展最终也将无法满足需求,需要使用分布式数据库及分布式文件系统来支撑。
    分布式数据库是系统数据库拆分的最后方法,只有在单表数据规模非常庞大的时候才使用,更常用的数据库拆分手段是业务分库,将不同的业务数据库部署在不同的物理服务器上。
    常见的分布式缓存,数据库,文件系统如下:
    在这里插入图片描述

    4.8 通过DNS轮询实现机房间的负载均衡

    在这里插入图片描述

    在DNS服务器中可配置一个域名对应多个IP地址,每个IP地址对应到不同的机房里的虚拟IP。当用户访问www.taobao.com时,DNS服务器会使用轮询策略或其他策略,来选择某个IP供用户访问。此方式能实现机房间的负载均衡,至此,系统可做到机房级别的水平扩展,千万级到亿级的并发量都可通过增加机房来解决,系统入口处的请求并发量不再是问题。

    4.9 引入noSQL和搜索引擎

    在这里插入图片描述

    当数据库中的数据多到一定规模时,数据库就不适用于复杂的查询了,往往只能满足普通查询的场景。对于统计报表场景,在数据量大时不一定能跑出结果,而且在跑复杂查询时会导致其他查询变慢,对于全文检索、可变数据结构等场景,数据库天生不适用。因此需要针对特定的场景,引入合适的解决方案。
    如对于海量文件存储,可通过分布式文件系统HDFS解决,对于key value类型的数据,可通过HBase和Redis等方案解决,对于全文检索场景,可通过搜索引擎如ElasticSearch解决,对于多维分析场景,可通过Kylin或Druid等方案解决。

    下面我重点讲解一下nosql

    nosql、sql

    概念:

    • SQL (Structured Query Language) 数据库,指关系型数据库。主要代表:SQL Server,Oracle,MySQL(开源),PostgreSQL(开源)。
    • NoSQL(Not Only SQL)泛指非关系型数据库。主要代表:MongoDB,Redis,CouchDB。

    两者的区别:

    • 1.存储方式不同
      SQL数据存在特定结构的表中;
      NoSQL则更加灵活和可扩展,存储方式可以省是JSON文档、哈希表或者其他方式。
    • 2.表/数据集合的数据的关系
      SQL:必须定义好表和字段结构后才能添加
      NoSQL:数据可以在任何时候任何地方添加,不需要先定义表
    • 3.外部数据存储
      SQL:增加外部关联数据的话,规范化做法是在原表中增加一个外键,关联外部数据表。
      NoSQL中除了这种规范化的外部数据表做法以外,我们还能用如下的非规范化方式把外部数据直接放到原数据集中,以提高查询效率
    • 4.SQL中的JOIN查询
      SQL中可以使用JOIN表链接方式将多个关系数据表中的数据用一条简单的查询语句查询出来。
      NoSQL暂未提供类似JOIN的查询方式对多个数据集中的数据做查询。所以大部分NoSQL使用非规范化的数据存储方式存储数据。
    • 5.数据耦合性
      SQL中不允许删除已经被使用的外部数据
      NoSQL中则没有这种强耦合的概念,可以随时删除任何数据。
    • 6.事务
      SQL中如果多张表数据需要同批次被更新,即如果其中一张表更新失败的话其他表也不能更新成功。这种场景可以通过事务来控制,可以在所有命令完成后再统一提交事务。
      NoSQL中没有事务这个概念,每一个数据集的操作都是原子级的。
    • 7.增删改查语法不同
    • 8.查询性能不同
      在相同水平的系统设计的前提下,因为NoSQL中省略了JOIN查询的消耗,故理论上性能上是优于SQL的。

    搜索引擎

    • Lucence Core:Java编写的核心类库,提供全文检索功能的底层API与SDK。
    • Solr:基于Lucence Core开发的高性能搜索服务,提供了REST API的高层封装接口,还提供了一个Web管理界面。
    • PyLucene:一个Python版的Lucene Core的高仿实现。
    • ElasticSearch:也是基于Lucence的分布式全文检索中间件。

    4.10 业务拆分

    在这里插入图片描述

    系统上按照业务进行拆分改造,应用服务器按照业务区分进行分别部署。

    • 纵向拆分:将一个大应用拆分为多个小应用,如果新业务较为独立,那么就直接将其设计部署为一个独立的Web应用系统
    • 横向拆分:将复用的业务拆分出来,独立部署为分布式服务,新增业务只需要调用这些分布式服务

    4.11 复用的功能抽离成微服务

    在这里插入图片描述

    如用户管理、订单、支付、鉴权等功能在多个应用中都存在,那么可以把这些功能的代码单独抽取出来形成一个单独的服务来管理,这样的服务就是所谓的微服务,应用和服务之间通过HTTP、TCP或RPC请求等多种方式来访问公共服务,每个单独的服务都可以由单独的团队来管理。
    此外,可以通过Dubbo、SpringCloud等框架实现服务治理、限流、熔断、降级等功能,提高服务的稳定性和可用性。

    4.12 引入企业服务总线ESB屏蔽服务接口的访问差异

    在这里插入图片描述

    通过ESB统一进行访问协议转换,应用统一通过ESB来访问后端服务,服务与服务之间也通过ESB来相互调用,以此降低系统的耦合程度。
    这种单个应用拆分为多个应用,公共服务单独抽取出来来管理,并使用企业消息总线来解除服务之间耦合问题的架构,就是所谓的SOA(面向服务)架构,这种架构与微服务架构容易混淆,因为表现形式十分相似。
    微服务架构更多是指把系统里的公共服务抽取出来单独运维管理的思想,而SOA架构则是指一种拆分服务并使服务接口访问变得统一的架构思想,SOA架构中包含了微服务的思想。

    业务不断发展,应用和服务都会不断变多,应用和服务的部署变得复杂,同一台服务器上部署多个服务还要解决运行环境冲突的问题,此外,对于如大促这类需要动态扩缩容的场景,需要水平扩展服务的性能,就需要在新增的服务上准备运行环境,部署服务等,运维将变得十分困难

    4.13 引入容器化技术实现运行环境隔离与动态服务管理

    在这里插入图片描述

    目前最流行的容器化技术是Docker,最流行的容器管理服务是Kubernetes(K8S),应用/服务可以打包为Docker镜像,通过K8S来动态分发和部署镜像。
    Docker镜像可理解为一个能运行你的应用/服务的最小的操作系统,里面放着应用/服务的运行代码,运行环境根据实际的需要设置好。
    把整个“操作系统”打包为一个镜像后,就可以分发到需要部署相关服务的机器上,直接启动Docker镜像就可以把服务起起来,使服务的部署和运维变得简单。

    在大促的之前,可以在现有的机器集群上划分出服务器来启动Docker镜像,增强服务的性能,大促过后就可以关闭镜像,对机器上的其他服务不造成影响。

    4.14 以云平台承载系统

    在这里插入图片描述

    系统可部署到公有云上,利用公有云的海量机器资源,解决动态硬件资源的问题,在大促的时间段里,在云平台中临时申请更多的资源,结合Docker和K8S来快速部署服务,在大促结束后释放资源,真正做到按需付费,资源利用率大大提高,同时大大降低了运维成本。

    所谓的云平台,就是把海量机器资源,通过统一的资源管理,抽象为一个资源整体,在之上可按需动态申请硬件资源(如CPU、内存、网络等),并且之上提供通用的操作系统,提供常用的技术组件(如Hadoop技术栈,MPP数据库等)供用户使用,甚至提供开发好的应用,用户不需要关系应用内部使用了什么技术,就能够解决需求(如音视频转码服务、邮件服务、个人博客等)。在云平台中会涉及如下几个概念:

    • IaaS:基础设施即服务。对应于上面所说的机器资源统一为资源整体,可动态申请硬件资源的层面;
    • PaaS:平台即服务。对应于上面所说的提供常用的技术组件方便系统的开发和维护;
    • SaaS:软件即服务。对应于上面所说的提供开发好的应用或服务,按功能或性能要求付费。

    至此,以上所提到的从高并发访问问题,到服务的架构和系统实施的层面都有了各自的解决方案,但同时也应该意识到,在上面的介绍中,其实是有意忽略了诸如跨机房数据同步、分布式事务实现等等的实际问题。

    5.分布式服务可能会面临的问题

    • 当服务越来越多时,服务URL配置管理变得非常困难,F5硬件负载均衡器的单点压力也越来越大。
    • 当进一步发展,服务间依赖关系变得错踪复杂,甚至分不清哪个应用要在哪个应用之前启动,架构师都不能完整的描述应用的架构关系.
    • 服务多了,沟通成本也开始上升,调某个服务失败该找谁?服务的参数都有什么约定?
    • 接着,服务的调用量越来越大,服务的容量问题就暴露出来,这个服务需要多少机器支撑?什么时候该加机器?

    6.分布式事务

    在了解分布式事务之前,我先引入一个概念:时间与顺序

    6.1 时间

    对于串行的事务来说,很简单的就是跟着时间的脚步走就可以,先来后到的发生。而后我们发明了时钟来刻画以往发生的时间点,时钟让这个世界井然有序。但是对于分布式世界来说,跟时间打交道着实是一件痛苦的事情。
    分布式世界里面,我们要协调不同节点之间的先来后到关系,不同节点本身承认的时间又各执己见,于是我们创造了**网络时间协议(NTP)**试图来解决不同节点之间的标准时间,但是 NTP 本身表现并不尽如人意,所以我们又构造出了逻辑时钟,最后改进为向量时钟:

    • NTP 的一些缺点,无法完全满足分布式下并发任务的协调问题
      • 节点间时间不同步
      • 硬件时钟漂移
      • 线程可能休眠
      • 操作系统休眠
      • 硬件休眠

    • 逻辑时钟
      • 定义事件先来后到
      • t’ = max(t, t_msg + 1)
    • 原子钟

    6.2 顺序

    有了衡量时间的工具,解决顺序问题自然就是水到渠成了。
    因为整个分布式的理论基础就是如何协商不同节点的一致性问题,而顺序则是一致性理论的基本概念。
    有了上面信息的一些基础认知之后,我们开始正式描述分布式的事务理论

    6.3 一致性理论

    主要通过三个非常重要的理论来进行刻画

    • 1.强一致性 ACID
    • 2.分布式一致性 CAP
    • 3.弱一致性 BASE

    首先我们先看一下ACID理论

    数据库本地事务:强一致性 ACID

    单机环境下我们对传统关系型数据库有苛刻的要求,由于存在网络的延迟和消息丢失,ACID 便是保证事务的原则,这四大原则便是:

    • Atomicity:原子性,一个事务中的所有操作,要么全部完成,要么全部不完成,不会结束在中间某个环节;保证了事务操作的整体性
      Consistency:一致性,在事务开始之前和事务结束以后,数据库的完整性没有被破坏;事务操作下数据的正确性
      Isolation:隔离性,数据库允许多个并发事务同时对其数据进行读写和修改的能力,隔离性可以防止多个事务并发执行时,由于交叉执行而导致数据的不一致;保证了事务并发操作下数据的正确性
      Durabilit:持久性,事务处理结束后,对数据的修改就是永久的,即便系统故障也不会丢失。保证了事务对数据修改的可靠性

    请大家务必牢记
    ACID是数据库的本地事务,而事务的ACID是通过InnoDB日志和锁来保证

    • 事务的隔离性是通过数据库锁的机制实现的
    • 持久性通过redo log(重做日志)来实现
    • 原子性和一致性通过Undo log来实现

    分布式事务理论–CAP

    • Consistency:一致性,数据一致更新,所有数据变动都是同步的。
    • Availability:可用性,好的响应性能,非故障的节点在合理的时间内返回合理的响应。
    • Partition tolerance:分区容错性,可靠性当出现网络分区后,系统能够继续工作。

    分布式系统理论上不可能选择 CA (一致性 + 可用性)架构,只能选择 CP(一致性 + 分区容忍性) 或者 AP (可用性 + 分区容忍性)架构,在一致性和可用性做折中选择。

    另外,只能选择CP或者AP是指系统发生分区现象时无法同时保证C(一致性)和A(可用性),但不是意味着什么都不做,当分区故障解决后,系统还是要保持保证CA

    弱一致性 BASE

    多数情况下,其实我们也并非一定要求强一致性,部分业务可以容忍一定程度的延迟一致,所以为了兼顾效率,发展出来了最终一致性理论 BASE。BASE 是指

    • BA:基本可用(Basically Available),分布式系统在出现故障的时候,允许损失部分可用性,即保证核心可用;
    • S:软状态( Soft State),允许系统存在中间状态,而该中间状态不会影响系统整体可用性。
    • E:最终一致性( Eventual Consistency),最终一致性是指系统中的所有数据副本经过一定时间后,最终能够达到一致的状态。弱一致性和强一致性相反,最终一致性是弱一致性的一种特殊情况。

    CAP 理论是忽略延时的,而实际应用中延时是无法避免的,这一点就意味着完美的 CP 场景是不存在的,即使是几毫秒的数据复制延迟,在这几毫秒时间间隔内,系统是不符合 CP 要求的。因此 CAP 中的 CP 方案,实际上也是实现了最终一致性,只是“一定时间”是指几毫秒而已。
    同时方案中牺牲一致性只是指发生分区故障期间,而不是永远放弃一致性,这一点其实就是 BASE 理论延伸的地方,分区期间牺牲一致性,但分区故障恢复后,系统应该达到最终一致性。
    总结: BASE解决了CAP中理论没有网络延迟,在BASE中用软状态和最终一致,保证了延迟后的一致性。BASE和 ACID 是相反的,它完全不同于ACID的强一致性模型,而是通过牺牲强一致性来获得可用性,并允许数据在一段时间内是不一致的,但最终达到一致状态。

    强一致性、弱一致性、最终一致性

    • 强一致性
      要求无论更新操作是在哪个数据副本上执行,之后所有的读操作都要能获得最新的数据。
      对于单副本数据来说,读写操作是在同一数据上执行的,容易保证强一致性。对多副本数据来说,则需要使用分布式事务协议。
    • 弱一致性
      在这种一致性下,用户读到某一操作对系统特定数据的更新需要一段时间,我们将这段时间称为"不一致性窗口"。
    • 最终一致性
      它是弱一致性的一种特例,在这种一致性下系统保证用户最终能够读取到某操作对系统特定数据的更新(读取操作之前没有该数据的其他更新操作)。"不一致性窗口"的大小依赖于交互延迟、系统的负载,以及数据的副本数等。

    有了这些分布式事务的理论,我们再接着聊聊分布式事务解决方案

    6.4 分布式事务解决方案

    2PC方案

    在这里插入图片描述

    二阶段提交协议(Two-phase Commit,即2PC)是常用的分布式事务解决方案,即将事务的提交过程分为两个阶段来进行处理:准备阶段和提交阶段。

    • 准备阶段:
      协调者向所有参与者发送事务内容,询问是否可以提交事务,并等待所有参与者答复。
      各参与者执行事务操作,将undo和redo信息记入事务日志中(但不提交事务)。
      如参与者执行成功,给协调者反馈yes,即可以提交;如执行失败,给协调者反馈no,即不可提交。
    • 提交阶段:
      如果协调者收到了参与者的失败消息或者超时,直接给每个参与者发送回滚(rollback)消息;否则,发送提交(commit)消息;参与者根据协调者的指令执行提交或者回滚操作,释放所有事务处理过程中使用的锁资源。

    核心思想就是对每一个事务都采用先尝试后提交的处理方式,处理后所有的读操作都要能获得最新的数据,因此也可以将二阶段提交看作是一个强一致性算法。
    简单理解就是:

    • 第一阶段:事务管理器要求每个涉及到事务的数据库预提交(precommit)此操作,并反映是否可以提交
    • 第二阶段:事务协调器要求每个数据库提交数据,或者回滚数据

    但是2PC方案也会面临很多问题

    • 单点问题:事务管理器在整个流程中扮演的角色很关键,如果其宕机,比如在第一阶段已经完成,在第二阶段正准备提交的时候事务管理器宕机,资源管理器就会一直阻塞,导致数据库无法使用。
    • 同步阻塞:在准备就绪之后,资源管理器中的资源一直处于阻塞,直到提交完成,释放资源。
    • 数据不一致:两阶段提交协议虽然为分布式数据强一致性所设计,但仍然存在数据不一致性的可能,比如在第二阶段中,假设协调者发出了事务commit的通知,但是因为网络问题该通知仅被一部分参与者所收到并执行了commit操作,其余的参与者则因为没有收到通知一直处于阻塞状态,这时候就产生了数据的不一致性。

    7.架构设计总结

    • 架构的调整是否必须按照上述演变路径进行?

      不是的,以上所说的架构演变顺序只是针对某个侧面进行单独的改进,在实际场景中,可能同一时间会有几个问题需要解决,或者可能先达到瓶颈的是另外的方面,这时候就应该按照实际问题实际解决。如在政府类的并发量可能不大,但业务可能很丰富的场景,高并发就不是重点解决的问题,此时优先需要的可能会是丰富需求的解决方案。

    • 对于将要实施的系统,架构应该设计到什么程度?

      对于单次实施并且性能指标明确的系统,架构设计到能够支持系统的性能指标要求就足够了,但要留有扩展架构的接口以便不备之需。对于不断发展的系统,如电商平台,应设计到能满足下一阶段用户量和性能指标要求的程度,并根据业务的增长不断的迭代升级架构,以支持更高的并发和更丰富的业务。

    • 服务端架构和大数据架构有什么区别?

      所谓的“大数据”其实是海量数据采集清洗转换、数据存储、数据分析、数据服务等场景解决方案的一个统称,在每一个场景都包含了多种可选的技术,如:

      • 数据采集有Flume、Sqoop、Kettle等
      • 数据存储有分布式文件系统HDFS、FastDFS
      • NoSQL数据库HBase、MongoDB等
      • 数据分析有Spark技术栈、机器学习算法等。

      总的来说大数据架构就是根据业务的需求,整合各种大数据组件组合而成的架构,一般会提供分布式存储、分布式计算、多维分析、数据仓库、机器学习算法等能力。而服务端架构更多指的是应用组织层面的架构,底层能力往往是由大数据架构来提供。

    8.分布式架构设计原则

    • N+1设计。系统中的每个组件都应做到没有单点故障;
    • 回滚设计。确保系统可以向前兼容,在系统升级时应能有办法回滚版本;
    • 禁用设计。应该提供控制具体功能是否可用的配置,在系统出现故障时能够快速下线功能;
    • 监控设计。在设计阶段就要考虑监控的手段;
    • 多活数据中心设计。若系统需要极高的高可用,应考虑在多地实施数据中心进行多活,至少在一个机房断电的情况下系统依然可用;
    • 采用成熟的技术。刚开发的或开源的技术往往存在很多隐藏的bug,出了问题没有商业支持可能会是一个灾难;
    • 资源隔离设计。应避免单一业务占用全部资源;
    • 架构应能水平扩展。系统只有做到能水平扩展,才能有效避免瓶颈问题;
    • 非核心则购买。非核心功能若需要占用大量的研发资源才能解决,则考虑购买成熟的产品;
    • 使用商用硬件。商用硬件能有效降低硬件故障的机率;
    • 快速迭代。系统应该快速开发小功能模块,尽快上线进行验证,早日发现问题大大降低系统交付的风险;
    • 无状态设计。服务接口应该做成无状态的,当前接口的访问不依赖于接口上次访问的状态。

    至此分布式的基础理论就到此结束啦,接下来我们谈一谈分布式在具体通过业务场景浅谈分布式设计思路

    展开全文
  • Java开发网站架构演变过程,到目前为止,大致分为5个阶段,分别为单体架构、集群架构、分布式架构、SOA架构和微服务架构。下面玄武老师来给大家详细介绍下这5种架构模式的发展背景、各自优缺点以及涉及到的一些技术...
  • 中国移动一级业务支撑系统做为中国移动的管理中心和全网业务的核心系统,有内容计费,网状网,BBOSS,统一电渠,一级营销,一级客服等系统,业务模式涵盖了交易、计费、服务等各种移动核心业务模式,系统功能各异...
  • 数据中心IRF2虚拟化网络架构应用 文/刘新民 网络已经成为企业IT运行的基石随着IT业务的不断发展企业的基础网络架构也不断调整演化以支持上层不断变化的应用要求 在传统数据中心网络的性能安全永续基础上随着企业...
  • 例如,对于BR/EDR,它定义了一个蓝牙设备,包括无线电、基带、链接管理器、L2CAP和服务发现协议功能;对于LE,它定义了物理功能层、链接层、L2CAP、安全管理器、属性协议和通用属性协议。这将所有不同的层连接在一起...
  • 互联网应用架构逐渐向分层分布式架构发展,再此提出个人的互联网应用结构的理解图示。 注意:同一层次内应尽可能不出现相互调用的情况,便面业务逻辑混乱。 ...
  • SOA 是一种应用程序架构,在这种架构中,所有功能都定义为独立的服务,这些服务带有定义明确的可调用接口,能够以定义好的顺序调用这些服务来形成业务流程。 (2)Service-architecture.com 的定义 服务是精确定义 ...
  • 架构可细分为业务架构、应用架构、技术架构,业务架构是战略,应用架构是战术,技术架构是装备。其中应用架构承上启下,一方面承接业务架构的落地,另一方面影响技术选型。如何针对当前需求,选择合适...
  •   是建立在Internet上的一种网络服务,为浏览者在Internet上查找浏览信息提供了图形化的、易于访问的直观界面,其中的文档及超链接将Internet上的信息节点组织成一个互为关联的网状结构,是运行在互联网上的一种...
  • 从单一应用,到垂直拆分,到分布式服务,到SOA,以及现在火热的微服务架构,还有在Google带领下来势汹涌的Service Mesh。我们到底是该乘坐微服务的船只驶向远方,还是偏安一隅得过且过? 其实生活不止眼前的苟且,...
  • 基于微服务架构和Docker容器技术的PaaS云平台建设目标是给我们的开发人员提供一套服务快速开发、部署、运维管理、持续开发持续集成的流程。平台提供基础设施、中间件、数据服务、云服务器等资源,开发人员只需要开发...
  • 面向服务架构 1 SOA 概述 1. 服务的基本结构 2.SOA 设计原则 3. 服务构件与传统构件 2 SOA 的关键技术 1. UDDI 2.WSDL 3.SOAP 4.REST 3 SOA 的实现方法 1.Web Service 2. 服务注册表 3. ...
  • SOA/软件架构设计---面向服务架构(SOA详细解释)

    万次阅读 多人点赞 2019-03-06 16:53:53
    文章比较多,但干货慢慢,请耐心阅读 面向服务架构 迄今为止,对于面向服务架构... (1)W3C 的定义:SOA 是一种应用程序架构,在这种架构中,所有功能都定义为独立的服务,这些服务带有定义明确的可调用接口...
  • SOA架构和微服务架构的区别

    万次阅读 多人点赞 2019-07-21 20:24:13
    假如这个页面所展示的信息,都来自各个不同的系统/应用,我们通过各个接口把这些数据展示出来。如果我们现在要在前端页面展示这几项数据的话,我们应该怎么去展示呢? 在这种情况下,我们不可能让客户端与6个不同...
  • 摘 要: 目前, 无线局域网由于相对有线网络的...考虑到无线网状组网技术在当前市场上的应用,其业务支持能力性能方面的优势, 证明了想法提出的合理性及可行性。基于WiFi 的无线网状(M esh) 组网技术不仅具有WiF
  • 1.SOA架构和微服务架构的区别 首先SOA和微服务架构一个层面的东西,而对于ESB和微服务网关是一个层面的东西,一个谈到是架构风格和方法,一个谈的是实现工具或组件。 (1)SOA(Service Oriented Architecture)...
  • 第一代单体应用架构 这里放一个图,图中可以看到,所有模块都打包到一起,并且公用一个数据库。这种架构就是单体应用架构,也叫巨石应用。在开发小型项目上有独特的优势,易于调试、部署、运维方便,给个人开发应用...
  • 应用架构设计

    2018-02-28 23:37:00
    http://blog.csdn.net/ShareUs/article/details/51404728如何实现大型网站架构设计的负载均衡- http://blog.csdn.net/t4i2b10X4c22nF6A/article/details/79062766大型网站负载均衡的利器:全局负载均衡系统(GSLB)...
  • Ergo Framework实现了诸如GenServer / Supervisor / Application类的OTP设计模式,并使您能够创建与Erlang基础架构进行本地集成的高性能可靠的应用程序 产品特点 Erlang节点(运行单节点/) (以摆脱erlang的...
  • SOA 是一种在计算环境中设计、开发、部署管理离散逻辑单元(服务)模型的方法。 SOA 并不是一个新鲜事物,而只是面向对象模型的一种替代。虽然基于 SOA 的系统并不排除使用 OOD 来构建单个服务,但是其整体设计却...
  • 网络已经成为企业IT运行的基石,随着IT业务的不断发展,企业的基础网络架构也不断调整演化,以支持上层不断变化的应用要求。  在传统数据中心网络的性能、安全、永续基础上,随着企业IT应用的展开,业务类型快速...
  • 数据流风格架构又可以细分两种具体的架构风格:批处理序列管道过滤器。 批处理序列 批处理风格通常会由总体协调安排批处理过程,保证其每-处理都是独立的,并且顺序执行。具体来看有以下特点: ●强时间顺序:只有...
  • 类型1:卡牌、跑酷等弱交互服务端卡牌跑酷类因为交互弱,玩家玩家之间不需要实时面对面PK,打一下对方的离线数据,计算下排行榜,买卖下道具即可,所以实现往往使用简单的 HTTP服务器: 登录时可以使用非对称...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 9,753
精华内容 3,901
关键字:

网状应用和服务架构