转载

分布式与系统架构的演变

编辑推荐:

本文主要简单以一个商城系统架构发展作为例子,简单分析了系统架构的演变,希望对您的学习有所帮助。

来自于CSDN,由火龙果软件Alice编辑、推荐。

分布式

分布式就是把计算机通过网络连接起来协同工作。由多台计算机负责完成同一件事。

分布式与系统架构的演变

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

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

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

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

优点:

把公共功能抽取出来形成一个个可复用的服务。提高开发效率。

可以对不同的服务根据实际情况进行不同力度的集群化部署,解决系统压力。比如某个服务访问量大,就集群化力度大,某个服务访问量较小,就集群化力度比较小,实现比较灵活的性能扩展。

基于ESB总线或者Dubbo等框架,减小系统间的耦合。

缺点:

抽取服务的力度较大。

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

分布式架构要解决的问题:

任务分解

如何把本身单体的系统架构拆分成一个个独立部署的节点。可以通过领域模型进行拆分。

节点通信

各个节点之间进行通信,才能保证系统正常运行。可以通过RPC框架(Dubbo)或者消息中间件(ActiveMQ等)进行节点通信。

分布式和集群的关系

分布式就是把一个业务拆分成多个子系统。部署在不同的服务器上。各个子系统之间通过网络进行通信,协调完成业务。对外呈现出的是一个整体。

集群是把同一子系统部署多个服务器上,通过负载均衡等方案对系统进行访问。达到系统性能扩展和实现高可用。

系统架构的演变

以一个商城系统架构发展作为例子。系统有用户模块,商品模块,订单模块。

第一版

由于项目初期,用户量少

使用到的架构:

容器:tomcat,jsp/servlet。

数据库:mysql。

分布式与系统架构的演变

第二版

随着用户数增多,单机负载越来越大,将数据库服务器与应用服务器分离。

分布式与系统架构的演变

第三版

随着访问量的继续增多,一台应用服务器不能处理达到瓶颈,就对应用服务器进行集群部署。

分布式与系统架构的演变

这也引出了一些问题:比如Session共享等。可以使用 cookie、session集中存储等方案解决。

第四版:

随着访问量的继续增多,单台数据库达到了瓶颈,使用数据库读写分离和数据同步。

分布式与系统架构的演变

这时又引出一些问题:

比如:

数据库读写分离如何实现。mysql主从模式。

数据同步如何实现。mysql主从模式。

数据库路由。mycat

第五版

商品搜索如何实现高效率,高相关检索,就引入了搜索引擎,ES等。

分布式与系统架构的演变

又引入问题:

搜索引擎索引数据如果同步,实时增量同步还是定时全量同步。

第六版

访问量持续增大,引入缓存机制。redis等。

分布式与系统架构的演变

第七版:

数据库数据量过大,进行垂直/水平拆分。拆分成订单数据库。用户数据库,商品数据库等。

分布式与系统架构的演变

第八版

访问量,数据量,持续增大,对应用进行拆分成多个没有关联的应用,比如把原本一个应用拆分成三个应用,用户系统、订单系统。

分布式与系统架构的演变

这个与分布式架构还是有点区别的,因为拆分的应用都是没有关系的,各自完成相应的功能,没有进行通信。这种架构会存在冗余的代码,比如订单系统会涉及商品跟用户,所以订单系统里面就会有相应的关于用户和商品相关的代码。

第九版

访问量,数据量,业务复杂度,持续增大,对各个模块按照一定业务,一定粒度进行抽取成一个个服务/组件,各个服务之间通过网络进行通信,完成相应业务,该架构就是分布式架构。

分布式与系统架构的演变

此时每种业务都被抽取出来独立运行,系统之间相互通信,比如订单系统用到了用户相关的,就通过与用户服务组件进行通信进行调用,完成业务逻辑处理。

原文  http://www.uml.org.cn/zjjs/2020061821.asp?artid=23402
正文到此结束
Loading...