互联网软件架构演变——集群与分布式的区别

互联网软件架构演变

单体架构

一个包含所有功能的应用程序，通常称为单体应用。

优点

1. 便于共享：包含所有功能，便于在团队之间共享。

2. 易于测试：一旦部署，所有服务都可以使用了，简化测试过程，没有额外依赖。

3. 易于部署：只需将单个文件复制到单个目录下。

缺点

1. 复杂性高：由于是单个归档文件，整个项目包含很多模块，模块边界模糊，依赖关系不清晰，代码混轮堆在一起，使得整个项目非常复杂，编译时间更长。

2. 扩展能力受限：单体应用只能作为一个整体进行扩展，无法根据业务模块的需要进行伸缩

集群

多台服务器组成的一组计算机，作为一个整体存在，向用户提供一组网络资源，这些单个的服务器就是集群的节点(node)。

特点：

1. 可扩展性：集群的性能不限制于单一的服务实体，新的服务实体可以动态的添加到集群，从而增强集群的性能。

2. 高可用性：集群当其中一个节点发生故障时，这台节点上面所运行的应用程序将在另一台节点被自动接管，消除单点故障对于增强数据可用性、可达性和可靠性是非常重要的。

能力：

1. 负载均衡：负载均衡把任务比较均匀的分布到集群环境下的计算和网络资源，以提高数据吞吐量。

2. 错误恢复：如果集群中的某一台服务器由于故障或者维护需要无法使用，资源和应用程序将转移到可用的集群节点上。这种由于某个节点的资源不能工作，另一个可用节点中的资源能够透明的接管并继续完成任务的过程，叫做错误恢复。

3. 内部通信：为了能协同工作、实现负载均衡和错误恢复，集群各实体间必须时常通信，比如负载均衡器对服务实体心跳测试信息、服务实体间任务执行上下文信息的通信。

负载均衡和错误恢复要求各服务实体中有执行同一任务的资源存在，而且对于同一任务的各个资源来说，执行任务所需的信息视图必须是相同的。

单体架构缺陷

1、单点故障 单机部署很容易出现服务挂了之后，没有备用节点，从而影响用户使用。单机对外提供服务，风险很大，服务器任何故障都可能引起整个服务的不可用。

2、性能瓶颈 单机遇到资源瓶颈时，要想支持更大的用户量，性能有较大的提升，一般是优化业务和增加服务器配置。然而这么做只能是杯水车薪，成本巨大并且效果非常有限。而集群部署通过部署多个服务节点水平扩展服务的性能，成倍的增加服务器性能，而且支持动态扩展。

集群架构优势

1、高可用性。提高服务的可用性，只要有一个服务可用就能对外提供服务。高可用性是指，在不需要操作者干预的情况下，防止系统发生故障或从故障中自动恢复的能力。通过把故障服务器上的应用程序转移到备份服务器上运行，集群系统能够把正常运行时间提高到大于99.9%，大大减少服务器和应用程序的停机时间。

2、吞吐量。增加吞吐量，并发量，支持更大的用户量。

3、易扩展。也叫可伸缩性，可伸缩性体现在节点数量的调整，在预知流量增大的情况下，可以提前增加节点

分布式

1. 不同的业务模块部署在不同的服务器上或者同一个业务模块分拆多个子业务，部署在不同的服务器上，解决高并发的问题。

2. 分布式的每一个节点，都完成不同的业务，一个节点垮了，那这个业务就不可访问了。

3. 分布式服务顾名思义服务是分散部署在不同的机器上的，一个服务可能负责几个功能，是一种面向SOA架构的，服务之间也是通过rpc来交互或者是webservice来交互的。

4. 逻辑架构设计完后就该做物理架构设计，系统应用部署在超过一台服务器或虚拟机上，且各分开部署的部分彼此通过各种通讯协议交互信息，就可算作分布式部署，生产环境下的微服务肯定是分布式部署的，分布式部署的应用不一定是微服务架构的，比如集群部署，它是把相同应用复制到不同服务器上，但是逻辑功能上还是单体应用。

集群与分布式的区别

正常版

1. 首先从概念上来看，集群就是将全部的服务器都集中起来做同样的事情（集群指的是将几台服务器集中在一起，实现同一业务。），而分布式是将一种业务拆分成其他的部分业务分布在多台服务器上（分布式是指将不同的业务分布在不同的地方。 ）；

2. 分布式中的每一个节点，都可以做集群，而集群并不一定就是分布式的。

3. 集群是个物理形态，而分布式只是个工作方式；集群一般是物理集中，统一管理的，而分布式则不强调这一点，不管放置在哪个位置，只要通过网络连接起来就行。

白话版

1. 小饭店原来只有一个厨师，切菜洗菜备料炒菜全干。
2. 后来客人多了，厨房一个厨师忙不过来，又请了个厨师，两个厨师都能炒一样的菜，这两个厨师的关系是集群。
3. 为了让厨师专心炒菜，把菜做到极致，又请了个配菜师负责切菜，备菜，备料，厨师和配菜师的关系是分布式，一个配菜师也忙不过来了，又请了个配菜师，两个配菜师关系是集群。

集群与分布式的联系

联系1

1. 集群主要的使用场景是为了分担请求的压力，也就是在几个服务器上部署相同的应用程序，来分担客户端请求。

2. 当压力进一步增大的时候，可能在需要存储的部分，mysql无法面对很多的写压力。因为在mysql做成集群之后，主要的写压力还是在master的机器上面，其他slave机器无法分担写压力，从而这个时候，也就引出来分布式。

3. 分布式的主要应用场景是单台机器已经无法满足这种性能的要求，必须要融合多个节点，并且节点之间是相关之间有交互的。相当于在写mysql的时候，每个节点存储部分数据，也就是分布式存储的由来。

联系2

1. 集群主要是简单加机器解决问题，对于问题本身不做任何分解；分布式处理里必然包含任务分解与答案归并。

2. 分布式中的某个子任务节点，可能由一个集群来代替；集群中任一节点，都是做一个完整的任务。

3. 集群和分布式都是由多个节点组成，但是集群之间的通信协调基本不需要；而分布式各个节点的通信协调必不可少。

4. 将一套系统拆分成不同子系统部署在不同服务器上（这叫分布式），然后部署多个相同的子系统在不同的服务器上（这叫集群），部署在不同服务器上的同一个子系统要做负载均衡。

5. 分布式：一个业务分拆多个子业务，部署在不同的服务器上。集群：同一个业务，部署在多个服务器上。

集群，分布式举例

集群举例：

为了计算1+2+3+…+100, 用一台机器就可以完成任务， 需要1s的时间， 现在部署集群10台机器， 那么这10台机器就可以在1s内处理10个这种请求。每台机器是独立服务， 整体构成一个集群。

分布式举例：

为了计算1+2+3+…+100， 可以部署10台机器， 第一台机器计算1+2+3+…+10（需要0.1s）, 第二台机器计算11+12+13+…+20（需要0.1s）, …, 以此类推， 第十台机器计算91+92+93+…+100（需要0.1s）, 最后求和即可。 由于是同时进行计算的， 所以计算1+2+3+…+100只需要大约0.1s

面向服务架构 (SOA)

SOA是按照业务将单体应用垂直拆分多个独立的服务，通过消息总线ESB交互，每个服务还是单体服务

SOA 是面向服务的架构思想，其实微服务也同样，只是两者的侧重点有些差别：

微服务架构更多是指把系统里的公共服务抽取出来单独运维管理的思想。
SOA 架构则是指一种拆分服务并使服务接口访问变得统一的架构思想。
SOA架构中包含了微服务的思想。

微服务架构

1. 微服务架构 = SOA架构 + 水平拆分的架构

2. 微服务架构:其实和 SOA 架构类似,微服务是在 SOA 上做的升华，微服务架构强调的一个重点是“业务需要彻底的组件化和服务化”，原有的单个业务系统会拆分为多个可以独立开发、设计、运行的小应用。这些小应用之间通过服务完成交互和集成。

3. 微服务架构 = 80%的SOA服务架构思想 + 100%的组件化架构思想 + 80%的领域建模思想

微服务架构优点

1 易于开发和维护：一个微服务只会关注一个特定的业务功能，所以业务清晰，代码量较少。开发和维护单个微服务相对简单

2 单个微服务启动较快

3 局部修改容易部署：单体应用只要修改，就要重新部署整个应用。对某个微服务进行修改，只需要重新部署这个服务即可

按需伸缩：可根据需求，实现细粒度的扩展

微服务架构缺点

1 运维需求高

2 使用微服务构建的是分布式系统。系统容错、网络延迟、分布式事务等都会带来巨大问题。

3 接口调整成本高，微服务之间通过接口进行通信。修改某一个微服务的API，可能所有用到这个接口的微服务都需要进行调整。

完整的微服务架构图

go 微服务生态

什么是微服务

使用一套小服务来开发单个应用的方式，每个服务运行在独立的进程里，一般采用轻量级的通讯机制互联，并且它们可以通过自动化的方式部署

微服务的特点

• 单一职责，此时项目专注于登录和注册
• 轻量级的通信，通信与平台和语言无关，http是轻量的，例如java的RMI属于重量的
• 隔离性，数据隔离
• 有自己的数据
• 技术多样性

微服务诞生背景

互联网行业的快速发展，需求变化快，用户数量变化快
敏捷开发深入人心，用最小的代价，做最快的迭代，频繁修改、测试、上线
容器技术的成熟，是微服务的技术基础

微服务架构的优势和不足

优势

• 独立性
• 使用者容易理解
• 技术栈灵活
• 高效团队

不足

• 额外的工作，服务的拆分
• 保证数据一致性
• 增加了沟通成本

微服务生态

硬件层

docker+k8s

通信层

1. 网络传输，用RPC（远程过程调用）
   HTTP传输，GET POST PUT DELETE
   基于TCP，更靠底层，RPC基于TCP，Dubbo（18年底改成支持各种语言），Grpc，Thrift

2. 用服务注册和发现
   需要分布式数据同步：etcd，consul，zk

应用平台层

1. 云管理平台、监控平台、日志管理平台，需要他们支持

2. 服务管理平台，测试发布平台

3. 服务治理平台

微服务层

• 用微服务框架实现业务逻辑

微服务

微服务架构

服务注册和发现

1. 客户端做，需要实现一套注册中心，记录服务地址，知道具体访问哪个，轮询算法去做，加权轮询

2. 服务端做，比较简单，服务端启动，自动注册即可，AWS的ELB去访问

rpc调用和服务监控

RPC相关内容

• 数据传输：JSON Protobuf thrift
• 负载：随机算法 轮询 一致性hash 加权
• 异常容错：健康检测 熔断 限流
  服务监控
• 日志收集
• 打点采样

服务网格

Service Mesh是用于处理服务间通信的基础设施层，用于在云原生应用复杂的服务拓扑中实现可靠的请求传递

微服务更像是一个服务之间的生态，专注于服务治理等方面，而服务网格更专注于服务之间的通信

服务网格是一个基础设施层，用于处理服务间通信。元原生应用有着复杂的服务拓扑，服务网格负责在这些拓扑中实现请求的可靠传递。
在实践中，服务网格通常实现为一组轻量级网络代理，它们与应用程序部署在一起，而对应用程序透明。

服务网格（Service Mesh）是一个专门处理服务通讯的基础设施层。
它的职责是在由云原生应用组成服务的复杂拓扑结构下进行可靠的请求传送。在实践中，它是一组和应用服务部署在一起的轻量级的网络代理，并且对应用服务透明。

服务网格从总体架构上来讲比较简单，不过是一堆紧挨着各项服务的用户代理，外加一组任务管理组件组成。

管理组件被称为控制层或控制平面（control plane），负责与控制平面中的代理通信，下发策略和配置。

代理在服务网格中被称为数据层或数据平面（data plane），直接处理入站和出站数据包，转发、路由、健康检查、负载均衡、认证、鉴权、产生监控数据等。

一个典型的服务网格部署网络结构图如下：

其中绿色方块为应用服务，蓝色方块为 Sidecar Proxy，应用服务之间通过 Sidecar Proxy 进行通信，整个服务通信形成图中的蓝色网络连线，图中所有蓝色部分就形成了 Service Mesh。

ServiceMesh架构

实现业务服务与基础服务解耦，业务团队仅仅关注业务开发即可，基础服务交给基础服务团队完成。

ServiceMesh优点

1 ServiceMesh独立进程，独立升级
2 业务团队专注于业务逻辑本身
3 一套基础设施支持多语言开发
4 业务团队和基础设施团队物理解耦

Istio总体架构

1 Istio服务网格逻辑上分为数据面板（执行者）和控制面板（指挥者）
2 数据面板由一组智能代理（Envoy）组成，代理部署为Sidecar,调解和控制微服务之间所有的网络通信
3 控制面板负责管理和配置代理来路由流量，以及在运行执行策略

完整的服务网格架构