一, 分布式简介
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, 数据库选型
分布式系统架构和分布式数据存储相辅相成, 不管架构选型还是存储选型, 都没有可建议的标准, 这里只能用一句很有用的废话来描述: 基于自己的技术认知范围, 和业务场景综合考量.
四, 最后总结
如何架构分布式系统, 这说不好, 但是如何判断分布式架构是否好, 这很好说: 服务良好的扩展性, 高可用性, 例如高并发业务随时扩展, 提高系统可用性, 处理能力, 这是必须具备的基础特性.
来源: https://www.cnblogs.com/cicada-smile/p/12716752.html