阅读 6

架构设计基础:单服务.集群.分布式,基本区别和联系

一、分布式简介

1、架构简介

现在的互联网,几乎常见的复杂系统都会使用分布式架构,如果在不清楚概念之前,刚接触分布式架构这个名词会感觉十分的高大上,其实在对比单服务,集群服务之后,你就会发现本质上都是一样的。

絮叨一句:所谓Java架构师,基本就是看被单服务,集群,分布式不断暴打的频率,架构师因为被虐频率高,自然做出来的系统架构坑少,新手不能做架构的原因,所以你该懂的。

言归正传,分布式架构对于Java开发来说基本算是分水岭,能不能从开发层面跳出来,就看你工作个三五年之后,对分布式系统理解到什么程度。单服务应用,基于单服务做集群化部署,这种操作运维可以自行搭建环境,所以基本对能力要求不算高。但是如何设计出弹性、配置化、分布化、高性能、高容错、安全的分布式系统,的确是一件很有挑战的事情。

2、集群和分布式

首先需要理清楚单服务,集群,分布式这几种不同架构的区别。

单服务和集群

一张图,你品,你细品:

业务体量小,所有服务和应用部署在一台服务上,节省成本,这是单服务结构。当业务量逐渐增大,把一台服务进行水平扩展,做一个服务群,每台服务称为集群的一个节点,到这就是集群服务。集群服务要面对的一个问题就是:请求分配,自然需要一个调度组件来均衡服务器压力,这也被称为负载均衡。

补刀一句:做到集群模式的应用,在程序员面试的时候已经会被拿来做高格调的自吹自擂了,其实单服务和集群的本质区别就是:在处理请求的时候多了一个分配服务的过程,现在你还觉得跟人吹集群很高端吗?

分布式

一张图,你品,你细品:

这个概念解释起来就不容易了,单服务到集群,是部署上的改变,在代码层面改动极小,集群模式会加入更多的服务监控,为了快速的判断哪个服务宕机。

首先要解释一下上图:常见的电商系统架构(部分业务),订单,仓储,物流。

  • 用户在订单服务下单,自然需要校验库存;
  • 下单成功之后,需要追踪订单物流;
  • 商家需要仓储服务管理上架商品,发货等;
  • 如果订单服务出现高并发,可以水平扩展,做订单服务的集群化;

这是一个基础的业务场景,特点:多应用服务,多数据库存储,且服务之间有通信行为,在个别服务压力大的情况下可以水平扩展集群化部署。

分布式结构就是按照业务系统的功能,拆分成独立的子服务,可以独立运行,且服务之间通信和交互。带来的好处也是非常的多,例如:降低业务间的耦合度,方便开发维护,水平扩展,复用性高等等。

补刀一句:不要出现思维上的错觉,认为分布式系统的边界大于集群,如果把一个分布式整体看做一个服务,针对这个分布式服务做集群化部署,逻辑上是说的通的,只是这样违背分布式系统的初衷,比如后台服务,没有那么大的高并发,自然不用浪费资源。

3、一句总结

分布式和集群模式磨刀霍霍的根本原因,都是为了解决两个问题:提高系统吞吐量和高可用性,只是两种模式站在的角度和业务场景不同,例如业务单调的高并发场景,业务复杂但不具备并发的场景,当然也有这两种业务场景同时具备的。

补刀一句:针对系统架构和选型,各大公司也确实没有统一的标准,但是都强调写代码的规范和逻辑,这样做的根本原因就是方便后续的系统架构更改。

二、分布式技术栈

上面聊完了基本概念,现在聊聊分布式系统中的技术体系。这个话题依旧有点飘逸。分布式是一种架构思维和模式,并不一定非要使用特定的框架,现在很火的几个框架,SpringCloud,Dubbo,AliCloud等等,这些的出现都是给架构提供了更多的选择。

补刀一句:架构体系和框架,一定是可以分的开概念,框架更多是方便架构快速落地和实现。

1、服务架构

作为开发人员,分布式系统要处理的问题非常多,但是主流的模块有下面几个:

  • 网关控制

网关主要涉及到请求校验,聚合API,路由配置,鉴权管理,安全,灰度发布等等。常用的Zuul组件。

  • 配置中心

动态资源配置加载,例如运行时流量管理,环境切换,静态资源管理等。常用Nacos和config组件。

  • 服务管理

分布式中最难管理的模块,也最容易出错,首先多服务运行情况下,需要保证服务间的交互正常,避免请求在链路的某个服务上积压,出现异常还要及时熔断,进行服务降级,高并发到峰值时,要配置限流策略,还有最难处理的分布式事务。这里也被称为服务容错设计,常用Eureka、Hystrix、Sentinel、Dubbo等组件。

补刀一句:分布式系统中真正的核心内容,即使一个很牛的架构师,搭建的分布式环境也是在业务发展中不断优化的,不会一成不变。

2、容器化运维

作为运维人员:部署分布式系统的确是一件极其繁杂的事情,这时就应景诞生了容器化运维。

  • 部署环境

有的服务需要部署公有云(就是常说的几家大公司云服务),有的要部署私有云(自己公司搭建,只服务自己业务的云服务),混合云就是上述两种环境都需要部署服务。总之,现在不这么说,会显得自己很低调。

  • 容器化技术

将服务打包部署在Docker容器中,如果需要临时扩展,把Docker容器镜像快速部署到多个服务器上即可,如果对这个概念比较懵,就好比自己电脑里面多个虚拟机,可以基于一个虚拟机镜像文件,快速复制多个。Docker一大特色就是:搭建一次,到处运行。

补刀一句:此处必须要感叹一句,Java一直火那么久是有原因的,后续的很多技术出现都在参考这个基本理念。

  • 环境监控

分布式系统的应用非常复杂,所以要对监控做的非常到位,这里不仅仅要对服务监控,硬件环境同样重要。快速扩展,定位宕机服务。

三、数据存储

上面一直没有提到这个超大模块,意识必须清楚,任何系统最复杂的逻辑莫过于数据存储,从开发层面看:一个架构的核心价值就是在于数据的管理。

1、基础描述

基于上面分布式的概念,数据库的理解方式也是同样。分布式数据库可以解决单个数据库存储的IO或CPU瓶颈而诞生的。常用的模式如下:

  • 关系型

应用集成一个数据库代理的中间件,把数据基于特定策略路由到不同的数据库表中,取数据的时候在以同样的逻辑查询。很经典的sharding-jdbc组件,分库分表的模式。

  • 分布式

上面关系数据库的分库分表处理,是比较显式且刻意的,在分布式数据库中,天然的支持,且具有良好的水平扩展能力。例如:Hbase、mongodb、Greenplum分布式数仓等等。

2、数据库选型

分布式系统架构和分布式数据存储相辅相成,不管架构选型还是存储选型,都没有可建议的标准,这里只能用一句很有用的废话来描述:基于自己的技术认知范围,和业务场景综合考量。

四、最后总结

如何架构分布式系统,这说不好,但是如何判断分布式架构是否好,这很好说:服务良好的扩展性,高可用性,例如高并发业务随时扩展,提高系统可用性,处理能力,这是必须具备的基础特性。

推荐参考文章
微服务架构:项目技术选型简介,架构图解说明
微服务架构:业务架构设计,系统分层管理
微服务架构:数据库选型简介,业务数据规划设计
微服务架构:中间件集成,公共服务封装
微服务架构:SpringCloud 基础组件应用设计
微服务架构:通过业务、应用、技术、存储,聊聊架构
微服务应用:分库分表模式下,数据库扩容方案
微服务应用:Shard-Jdbc分库分表,扩容方案实现
关注下面的标签,发现更多相似文章
评论