系统架构的演变

目录

概述

一、单体应用架构

二、垂直应用架构

三、分布式SOA架构

1、SOA

2、SOA架构

3、分布式中的远程调用

(1)RESTful接口

( 2 )RPC协议

(3)RESTful接口和RPC协议的区别与联系

4、分布式中的CAP原理

四、微服务架构

1、微服务架构

2、常见的微服务架构

(1)Spring Cloud

(2)Service Comb

(3)ZeroC ICE

 总结


概述

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

一、单体应用架构

Web应用程序发展的早期,大部分web工程(包含前端页面、web层代码、service层代码、dao层代码)是将所有的功能模块,打包到一起并放在一个web容器中运行。比如搭建一个电商系统:客户下订单、商品展示和用户管理。这种将所有功能都部署在一个web容器中运行的系统就叫做单体架构。

单体应用架构优点:

(1)所有的功能集成在一个项目工程中;

(2)项目架构简单,前期开发成本低,周期短,小型项目的首选。

单体应用架构缺点:

(1)全部功能集成在一个工程中,对于大型项目不易开发、扩展及维护;

(2)系统性能扩展只能通过扩展集群结点,成本高、有瓶颈;

(3)技术栈受限。

二、垂直应用架构

当访问量逐渐增大,单一应用增加机器带来的加速度越来越小,将应用拆成互不相干的几个应用,以提升效率。

 垂直应用架构优点:

(1)项目架构简单,前期开发成本低,周期短,小型项目的首选;

(2)通过垂直拆分,原来的单体项目不至于无限扩大;

(3)不同的项目可采用不同的技术。

 垂直应用架构缺点:

(1)全部功能集成在一个工程中,对于大型项目不易开发、扩展及维护;

(2)系统性能扩展只能通过扩展集群结点,成本高、有瓶颈。

三、分布式SOA架构

1、SOA

SOA 全称为 Service-Oriented Architecture,即面向服务的架构。它可以根据需求通过网络对松散耦合的粗粒度应用组件(服务)进行分布式部署、组合和使用。一个服务通常以独立的形式存在于操作系统进程中。

站在功能的角度,把业务逻辑抽象成可复用、可组装的服务,通过服务的编排实现业务的快速再生,目的:把原先固有的业务功能转变为通用的业务服务,实现业务逻辑的快速复用

SOA的特点:分布式、可重用、扩展灵活、松耦合。

2、SOA架构

当垂直应用越来越多,应用之间交互不可避免,将核心业务抽取出来,作为独立的服务,逐渐形成稳定的服务中心,使前端应用能更快速的响应多变的市场需求。

 

SOA架构优点:

(1)抽取公共的功能为服务,提高开发效率;

(2)对不同的服务进行集群化部署解决系统压力;

(3)基于ESB/DUBBO减少系统耦合。
SOA架构缺点:

(1)抽取服务的粒度较大;

(2)服务提供方与调用方接口耦合度较高。

3、分布式中的远程调用

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

(1)RESTful接口

REST,即Representational State Transfer的缩写,如果一个架构符合REST原则,就称它为RESTful架构。

RESTful架构:

1)每一个URI代表一种资源;

2)客户端和服务器之间,传递这种资源的某种表现层;

3)客户端通过四个HTTP动词(GET查、 POST增、 PUT改、 DELETE删),对服务器端资源进行操作,实现"表现层状态转化"。

( 2 )RPC协议

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

(3)RESTful接口和RPC协议的区别与联系

1)HTTP相对更规范,更标准,更通用,无论哪种语言都支持http协议。如果你是对外开放API,例如开放平台,外部的编程语言多种多样,你无法拒绝对每种语言的支持,现在开源中间件,基本最先支持 的几个协议都包含RESTful。

2)RPC 框架作为架构微服务化的基础组件,它能大大降低架构微服务化的成本,提高调用方与服务提供方的研发效率,屏蔽跨进程调用函数(服务)的各类复杂细节。让调用方感觉就像调用本地函数一样调用远端函数、让服务提供方感觉就像实现一个本地函数一样来实现服务。

4、分布式中的CAP原理

现如今,对于多数大型互联网应用,分布式系统(distributed system)正变得越来越重要。分布式系统的最大难点,就是各个节点的状态如何同步。CAP 定理是这方面的基本定理,也是理解分布式系统的起点。CAP理论由 Eric Brewer 在ACM研讨会上提出,而后CAP被奉为分布式领域的重要理论。

分布式系统中的三个特性:

Consistency(一致性):数据一致更新,所有数据的变化都是同步的
Availability(可用性):在集群中一部分节点故障后,集群整体是否还能响应客户端的读写请求
Partition tolerance(分区容忍性):某个节点的故障,并不影响整个系统的运行

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

四、微服务架构
1、微服务架构

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

微服务架构优点:

(1)通过服务的原子化拆分,以及微服务的独立打包、部署和升级,小团队的交付周期将缩短,运维成本也将大幅度下降;

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

微服务架构缺点:

(1)微服务过多,服务治理成本高,不利于系统维护;

(2)分布式系统开发的技术成本高(容错、分布式事务等)。

2、常见的微服务架构
(1)Spring Cloud

Spring Cloud是一系列框架的有序集合。它利用Spring Boot的开发便利性巧妙地简化了分布式系统基础设施的开发,如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等,都可以用Spring Boot的开发风格做到一键启动和部署。Spring Cloud并没有重复制造轮子,它只是将各家公司开发的比较成熟、经得起实际考验的服务框架组合起来,通过Spring Boot风格进行再封装屏蔽掉了复杂的配置和实现原理,最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包。

(2)Service Comb

ServiceComb是业界第一个Apache微服务顶级项目, 致力于帮助企业快速构建云原生应用,通过一系列解决方案帮助用户快速开发微服务应用的同时实现对这些微服务应用的高效运维管理。其包括一站式的服务注册、服务治理、动态配置功能,具备服务化契约增强、多语言支持、多通信协议支持等优势特性, 并提供SAGA数据最终一致性方案解决微服务架构数据一致性难题。

(3)ZeroC ICE

ZeroC IceGrid是ZeroC公司的杰作,继承了CORBA的血统,是新一代的面向对象的分布式系统中间件。作为一种微服务架构,它基于RPC框架发展而来,具有良好的性能与分布式能力。

五、SOA与微服务的关系

 总结

单体应用架构 ===> 垂直应用架构 ===> 分布式架构 ===> SOA架构 ===> 微服务架构 ===> 悄然兴起的Service Mesh(服务网格化)。

  • 1
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 1
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值