架构发展历程
单体架构(Monolithic)
单体应用时代:应用程序无论如何分层,都是一个解决方案,或者说都是一个项目,这里的“解决方案”和“项目”不是我们使用的Visual Studio里面的概念,最终的程序代码都会在一个进程里运行
优点:开发简单,集中管理,没有分布式的损耗,都是系统进程内的通信。
缺点:不好维护,升级困难,耦合严重,无法应付高并发和大数据场景,无法快捷迭代。
- 只能采用同一种技术,很难用不同的语言或者相同语言不同版本开发不同模块。
- 系统耦合性太强,其中一个模块有问题,这个系统就会瘫痪,一个模块升级,整个系统就得停机维护。
- 要上线,必须一起上线,互相等待,无法快速相应市场需求。
- 集群负担大,如果想要集群,只能对整个系统进行集群,即使一个模块有压力。
垂直拆分
随着业务规模的越来越庞大,系统设计就越来越复杂,大的系统就开始进行业务的垂直拆分。比如:有专门做商品秒杀的部门,有专门做生鲜商品的部门,有专门做超市的部门,等等,当然这是根据部门天生划分的,也有根据业务需求进行系统划分的。
优点:垂直拆分,系统独立部署和维护,每个系统在自己进程内执行,分而治之。
缺点:拆分越多,存储越复杂,系统间重复的东西也越多,单个系统还是单体模式。
分布式服务
随着业务系统的越来越庞大,软件系统设计起来越来越复杂。为了避免过度复杂的业务需求,开始对业务系统的进行垂直拆分,形成多个独立的业务系统,如果多个系统之间要通信,可以通过跨进程的技术完成通讯。但是垂直拆分也导致了大量重复代码、重复模块的产生,比如:用户模块、日志模块、支付模块、认证授权模块等,这样分散的代码也给系统的维护和升级带来了困难。我们对业务重新划分,把独立的模块接口化、服务化,提高重用,这个时候,我们就开始进入了分布式服务的时代。(分布式的第一要务就是不要分布式)如图:
优点:
- 独立进程部署,独立进程运行,独立演化。服务之间可以做到高内聚,低耦合。
- 独立开发和维护,业务解耦,无论是业务系统还是分布式服务都独立演化。
- 分布式管理
- 隔离性增强
- 由一系列服务组装成系统,不用重复建设,模块、代码可以复用。
缺点:
- 数据一致性(多服务完成一个任务)和系统的可用性(集群)成为问题
- 数据库也进行了拆分
- 维护、设计、架构成本增加,调试、纠错更难
- 网络传输分布式损耗成本
- 不适合高并发和大数据的环境
微服务架构
微服务的出现时分布式架构已经很成熟了,架构中各种问题已经有了很成熟的解决方案,对于现在的业务系统来说,分布式架构已经变成了一种常规手段,这个时候,微服务就出现了。微服务架构是一个用分布式服务拆分业务逻辑,完成解耦的架构模式(架构风格)。微服务肯定是分布式的一种,是在分布式技术成熟之后,然后把分布式当成解耦手段来架构系统——因为拆分的服务很细致,服务数量规模开始变多了,服务的体量开始缩小了,由以前几个大的服务,转变为多个独立运行的、原子性质的服务。如图:
微服务最重要的特性是:
- 可用性:描述一个系统在一段时间内提供有用资源的能力,从而减少停工时间,而保持其服务的高度可用性。
- 伸缩性:根据需求动态添加和删除系统中资源的能力,是水平或垂直扩展的专门实现。
集群(负载均衡)可以解决系统的高可用和伸缩特性。
优点:
- 可以使用不同语言或者相同语言的不同版本开发各个模块。
- 系统耦合性低,各个模块分而治之,独立部署,独立发布,独立维护。
- 可以更快的相应市场的需求,更符合敏捷开发。
- 可以对不同模块使用集群策略,哪里有问题治哪里。
缺点:
- 开发难度更大,系统结构更复杂。
- 运行效率低,网络调用成本很大。
SOA
SOA----面向服务架构,实际上强调的是软件的一种架构,一种支撑软件运行的相对稳定的结构,表面含义如此,其实SOA是一种通过服务整合来解决系统集成的一种思想。不是具体的技术,本质上是一种策略、思想。
SOA作为一种面向服务的架构,是一种软件架构设计的模型和方法论。从业务角度来看,一切以最大化“服务”的价值为出发点,SOA利用企业现有的各种软件体系,重新整合并构建起一套新的软件架构。这套软件架构能够随着业务的变化,随时灵活地结合现有服务,组成新软件,共同服务于整个企业的业务体系。简单的理解,我们可以把SOA看作是模块化的组件,每个模块都可以实现独立功能,而不同模块之间的结合则可以提供不同的服务,模块之间的接口遵循统一标准,可以实现低成本的重构和重组。在SOA的技术框架下,可以把杂乱无章的庞大系统整合成一个全面有序的系统,从而增加企业在业务发展过程中应用系统的灵活性,实现最大的IT资产利用率。
SOA是一种理念,有去中心化和中心化两种实现方式,ESB是SOA的中心化实现
1、SOA是一种理念,它的主要特性--面向服务的分布式计算,服务间松散耦合,支持服务的封装,服务注册和自动发现,以服务契约方式定义服务交互方式。但是,SOA并没有定义出具体的实现方式,目前有两套SOA理念的实现方式:中心化和去中心化,这两套架构并没有优劣之分,还是要针对企业的根本诉求。
2、SOA中心化的实现方式就是ESB,ESB的根本诉求是为了解决异构系统之间的连通性,通过协议转换、消息解析、消息路由把服务提供者的数据传送到服务消费者。所以,ESB是中心化的,很重,有一定的逻辑,但它的确可以解决一些公用逻辑的问题。
3、SOA去中心化的实现方式的根本诉求是扩展性,实现方式就是微服务。分布式服务框架,主要有dubbox、spring cloud,实现后端服务治理的功能。
4、接下来再细看一下微服务,它的典型特征包括--分布式服务组成的系统,按照业务而不是技术来划分组织,做有生命的产品而不是项目,智能化服务端点与傻瓜式服务编排,自动化运维,系统容错,服务快速演化。微服务就是要去ESB,把所有的“思考”逻辑包括路由、消息解析等放在服务内部,去掉一个大一统的ESB,服务间轻通信,是比SOA更彻底的拆分。
5、微服务数量很大,客户端如何访问这些服务:在N个微服务和UI之间一般会一个代理或者叫API Gateway,他的作用包括:提供统一服务入口,让微服务对前台透明;聚合后台的服务,节省流量,提升性能;提供安全,过滤,流控等API管理功能。他们最重要的作用是为前台(通常是移动应用)提供后台服务的聚合,提供一个统一的服务出口,解除他们之间的耦合,不过API Gateway也有可能成为单点故障点或者性能的瓶颈。
8、微服务不是免费的午餐,带来好处的同时,也带来一系列问题,需要一个专业的团队和平台来保障微服务架构的成功落地。微服务的优点:开发简单,技术栈灵活,服务独立无依赖,独立按需扩展,可用性高;微服务的缺点(挑战):多服务运维难度,系统部署依赖,服务间通信成本,数据一致性,系统集成测试,性能监控。
**实际上SOA只是一种架构设计模式,而SOAP、REST、RPC就是根据这种设计模式构建出来的规范,**其中SOAP通俗理解就是http+xml的形式,REST就是http+json的形式,RPC是基于socket的形式。上文提到的CXF就是典型的SOAP/REST框架,dubbo就是典型的RPC框架,而SpringCloud就是遵守REST规范的生态系统。
SOA的特征:
1、可重用。解决了分布式的缺点。不同的web层可以共用一个服务层。
2、松耦合。服务请求者到服务提供者的绑定与服务之间是松耦合的,服务请求者不需要知道服务提供者实现的技术细节。
3、明确定义的接口。
4、无状态的服务设计。服务不应该依赖其他服务的上下文和状态。当产生依赖时,他们可以定义成通用的业务流程,函数和数据模型。
5、基于开放标准。
SOA体系结构中的角色包括:
1、服务请求者
是一个应用程序、一个软件模块、另一个服务。他发起对注册中心的服务的查询,通过传输绑定服务、并且执行服务功能,服务请求者根据接口契约来执行服务。
2、服务提供者
是一个可通过网络寻址的实体,他接受和执行来自请求者的请求,他将自己的服务和接口契约发布到服务注册中心。
3、服务注册中心
是服务发现的支持者,他包含一个可用服务的存储库,并运行感兴趣的服务请求者查询服务提供者接口。
ESB
ESB----企业服务总线,像一根“聪明”的管道,用来连接各个“愚笨”的节点。为了集成不同系统,不同协议的服务,ESB做了消息的转换解释与路由等工作,让不同的服务互联互通。
分布式
分布式系统面向的是运维,更多的是考虑系统性能和部署环境之间的问题,通过分布式解决在没有大型主机的部署环境情况下,系统性能的高可用和吞吐量,是个一个很早就提出来的一个概念,是由集中式系统过渡来的,随着计算机系统向网络化和微型化的发展日趋明显,同时业务的发展,传统的集中式处理模式越来越不能适应人们的需求,学习成本高,大型主机贵、容错性差,扩容困难。
为了解决业务快速发展给IT系统带来的巨大挑战,从2009年开始,阿里集团启动了去IOE计划,其电商系统开始正式迈入分布式系统时代。
在《分布式系统概念与设计》生一书中,对分布式系统做了如下定义:
「分布式系统是一个硬件或软件组件分布在不同的网络计算机上,彼此之间仅仅通过消息传递进行通信和协调的系统。」
微服务
微服务 (Microservices) 是一种软体架构风格,它是以专注于单一责任与功能的小型功能区块 (Small Building Blocks) 为基础,利用模组化的方式组合出复杂的大型应用程式,各功能区块使用与语言无关 (Language-Independent/Language agnostic) 的API 集相互通讯。 微服务的起源是由 Peter Rodgers 博士于 2005 年度云端运算博览会提出的微 Web 服务 (Micro-Web-Service) 开始,Juval Löwy 则是与他有类似的前导想法,将类别变成细粒服务 (granular services),以作为 Microsoft 下一阶段的软体架构,其核心想法是让服务是由类似 Unix 管道的存取方式使用,而且复杂的服务背后是使用简单 URI 来开放介面,任何服务,任何细粒都能被开放 (exposed)。这个设计在 HP 的实验室被实现,具有改变复杂软体系统的强大力量。 2014年,Martin Fowler 与James Lewis共同提出了微服务的概念,定义了微服务是由以单一应用程式构成的小服务,自己拥有自己的行程与轻量化处理,服务依业务功能设计,以全自动的方式部署,与其他服务使用 HTTP API 通讯。同时服务会使用最小的规模的集中管理 (例如 Docker) 能力,服务可以用不同的程序语言与资料库等元件协作。
微服务架构更多的是面向开发,更多的是考虑编码和项目业务之间的问题,根据功能把应用拆分为服务。解决的是开发问题和应用复杂性,是在对于业务的快速发展中单体应用不能满足需要的时候,提出来的一个概念,
在《微服务架构设计模式》一书中对微服务架构做如下定义:
「把应用程序功能性分解为一组服务的架构风格。」 (很直白的一句话,不需要多解释,对于大型系统而言,模块化是必不可少的,相信小伙伴也做过类似的项目,微服务架可以看做是模块化的一种形式)
分布式与集群的区别与关系
一句话,就是:“分头做事”与“一堆人”的区别
分布式是指将不同的业务分布在不同的地方。 而集群指的是将几台服务器集中在一起,实现同一业务。分布式中的每一个节点,都可以做集群。 而集群并不一定就是分布式的。
分布式的每一个节点,都完成不同的业务,一个节点垮了,哪这个业务就不可访问了。
用一个大家都看得懂的例子来结尾吧~
小饭店原来只有一个厨师,切菜洗菜备料炒菜全干。后来客人多了,厨房一个厨师忙不过来,又请了个厨师,两个厨师都能炒一样的菜,这两个厨师的关系是集群。为了让厨师专心炒菜,把菜做到极致,又请了个配菜师负责切菜,备菜,备料,厨师和配菜师的关系是分布式,一个配菜师也忙不过来了,又请了个配菜师,两个配菜师关系是集群。
SOA,ESB,微服务的区别和关系
我们看到微服务架构的些特点与 SOA 服务化架构相似, 事实上微服务架构与 SOA服务化架构并不冲突,它们一脉相承,却略有不同:
-
目的不同
微服务使用 系列的微小服务来实现整体的业务流程,目的是有效地拆分应用,实现敏捷开发和部署,在每个微小服务的团队里,减少了跨团队的沟通,让专业的人做专业的事,缩小变更和迭代影响的范围,并达到单一微服务更容易水平扩展的目的。
SOA 服务化涉及的范围更广 些,强调不同的异构服务之间的协作和契约 ,并强调有效集成、业务流程编排、历史应用集成等,典型代表为 Web Service 和ESB。
-
部署不同
微服务将完整的应用拆分成多个细小的服务,通常使用敏捷扩容、缩容的 Docker 技术来实现自动化的容器管理 每个微服务运行在单 的进程内,微服务中的部署互相独立互不影响。
SOA 服务化通常将多个业务服务通过组件化模块方式打包在 War 包里,然后统部署在一个应用服务器上。
-
服务粒度不同
微服务倡导将服务拆分成更细的粒度,通过多个服务组合来实现业务流程的处理,拆到职责单一,甚至小到不能再进行拆分。
SOA对粒度没有要求,在实践中服务通常是粗粒度的,强调接口契约的规范化,内部实现可以更粗粒度。
1、SOA是一种理念,它的主要特性--面向服务的分布式计算,服务间松散耦合,支持服务的封装,服务注册和自动发现,以服务契约方式定义服务交互方式。但是,SOA并没有定义出具体的实现方式,目前有两套SOA理念的实现方式:中心化和去中心化,这两套架构并没有优劣之分,还是要针对企业的根本诉求。
2、SOA中心化的实现方式就是ESB,ESB的根本诉求是为了解决异构系统之间的连通性,通过协议转换、消息解析、消息路由把服务提供者的数据传送到服务消费者。所以,ESB是中心化的,很重,有一定的逻辑,但它的确可以解决一些公用逻辑的问题。
3、SOA去中心化的实现方式的根本诉求是扩展性,实现方式就是微服务。
分布式服务框架,主要有dubbo、spring cloud,实现后端服务治理的功能。
分布式与微服务之间的区别于关系
从应用程序的扩展角度考虑
微服务和分布式都是对大型应用程序的扩展,内部都需要通信交互,只是扩展方向不同:
「分布式系统」 更多是偏水平扩展,在ops方面的解决办法,利用部署系统环境的空间分布性,比如SOA架构中利用分布式集成大型、复杂的单体应用程序;比如对实例进行克隆,以副本的形式对应用的数据和服务提供一种冗余方式(数据副本和服务副本),从而对外提供高可用,高并发的服务。分布式需要解决分布式数据一致性以及分布式环境通信异常、网络分区等问题。比如通过Zookeeper解决分布式数据一致性的问题。分布式系统可以理解为以解决硬件层面的压力从而对应用进行扩展。
「微服务架构」 更多的是垂直方向的扩展,在dev方面解决问题,利用应用程序的功能性分解,,把应用拆分为一组服务,每个服务负责特定的功能。每个服务都相对较小并容易维护,使大型的复杂应用程序可以持续交付和持续部署。服务可以独立部署、可以独立扩展。同时微服务架构可以实现团队的自治。更容易实验和采纳新的技术。更好的容错性。即服务之间松耦合,但是单个服务又是高内聚的。微服务架构可以理解为解决软件层面的压力对应用进行扩展。
两者不属于包含关系,都是对于应用扩展的不同解决办法。一般情况下,微服务架构的应用一般为分布式系统。但分布式系统不一定是微服务架构。
评论区