架构设计基础（单服务.集群.分布式，基本区别和联系）业务.方案.架构

一、分布式简介 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分库分表，扩容方案实现