宏观角度认识分布式架构

前言

小编最近陆续开启了两个新的篇章，第一个是分布式系统之dubbo，会从他的基本使用（快速上手，dubbo基本理论，企业开发），然后高级应用（负载均衡配置，性能优化，服务降级等等），到核心源码的阅读（注册调用，协议传输等等）；第二个是myBatis源码阅读。对之前的设计模式以及spring应用，会陆续更新，spring这边小编还缺乏aop，beanPostProcesser扩展，还有监听器理论以及对应源码框架的讲解。大家共同进步，如果说喜欢小编的文章，可以一起学习啊，谢谢。
今天咱们讲分布式系统的理论，以及架构演进，缺点和场景架构做一个整体的概述。其实网上也能找到很多相应的文章，小编也看了很多，讲得非常好。这里只是小编的一些理解和总结，更重要的是小编自己学习掌握。如有不足或错误之处，希望大家多多评论。

分布式架构概念

分布式架构：分布式是一个硬件或软件组件分布在不同的网络计算机上，彼此之间仅仅通过消息传递进行通信和协调的系统。简单来说就是一群独立计算机集合共同对外提供服务，但是对于系统的用户来说，就像是一台计算机在提供服务一样。

这边小编的简单理解就是本来有一个系统或节点干的事情，分成多个节点来做。那为什么会出现需要这样的场景呢。咱们继续往下讲

架构演进

小编进入第一家公司的时候是单体应用，单体应用即所有服务放在一台机子上，但当机子里面的某个程序崩溃了整个系统就挂了，为了防止这种情况，使用双机热备。不过同样的产生了其他问题，如性能瓶颈，一台机子处理始终会到达各种瓶颈并发IO等等，如果扩展机子那成本相当高。这个就是单体架构。不过优点就是容易维护。
由于单体应用的缺点，访问量逐渐增大，单体架构增加集群节点带来服务器性能越来越小时，我们通常将应用拆成互不相干的几个应用，这就称之为垂直架构 。单体架构规模的项目为单位进行垂直划分项目，即将一个大项目拆分成一个一个单体结构项目。但是应用与应用之间不能相互调用，导致的代码重复率高，且随着也无增大，开发维护成本也越来越高了。
之后演变成分布式架构，他将一个大的系统划分为多个业务模块，业务模块分别部署在不同的服务器上，各个业务模块之间通过接口进行数据交互。数据库也大量采用分布式数据库。这种架构提供了负载均衡的能力，大大提高了系统负载能力，解决了网站高并发的需求。另外还有以下特点：降低了耦合度：把模块拆分,使用接口通信,降低模块之间的耦合度。责任清晰：把项目拆分成若干个子项目,不同的团队负责不同的子项目。扩展方便：增加功能时只需要再增加一个子项目,调用其他系统的接口就可以。部署方便:可以灵活的进行分布式部署。提高代码的复用性。

下面是小编画的架构演进图，到分布式架构，比较简单，优缺点也比较简单。

架构演进图

以电商为例

分布式架构的缺点

当然任何架构有优点就有缺点。下面说一下分布式架构的缺点：

1、调用成本增加：系统之间的交互要使用远程通信,接口开发增大工作量,非常不好追踪调用链路。
2、分布式事务：分布式事务是指⼀个操作，分成⼏个⼩操作在多个服务器上执⾏，要么都成功，要么都失败。对于单体而言比较简单，但对于服务处于不同的机子上，增大了成本。
3、不允许服务有状态（stateless service）：⽆状态服务是指对单次请求的处理，不依赖其他请求，也就是说，处理⼀次请求所需的全部信息，要么都包含在这个请求⾥，要么可以从外部获取到（⽐如说数据库），服务
器本身不存储任何信息。
4、服务依懒关系复杂： 服务 A --> B–> C 那和服务C 的修改 就可能会影响 B 和C，事实上当服务越来 越多的时 候，C的变动将会越来越困难。
5、部署运维成本增加 不⽤说了，相⽐之前⼏个节点，运维成本的增加必须的。
6、 源码管理成本增加： 原本⼀套或⼏套源码现在拆分成⼏⼗个源码库，其中分⽀、tag都要进⾏相应管理。
7、 分布式JOB： 通常定时任务只需要在⼀台机器上触发执⾏，分布式的情况下在哪台执⾏呢？
8、学习成本增加：考虑负载，容错，降级等技术。

常见分布式架构

1. 基础的远程调⽤分布式架构。
   该架构拥有最基本的远程调⽤功能，能满足小规模系统之间的调⽤。或者对于暴露⼀些简单的 接⼝，常⻅的⽅案如下

协议	描述	优点	缺点
RMI	JAVA 远程⽅法调⽤、使⽤原⽣二进制⽅式进⾏序列化	简单易⽤、SDK⽀持， 提⾼开发效率	不⽀持跨语⾔
Web Service	⽐较早系统调⽤解决⽅案 ，跨语⾔, 其基于WSDL ⽣成 SOAP 进⾏ 消息的传递。	SDK⽀持（不灵活）、 跨语⾔	实现较重，发布繁琐
Http	采⽤http +json 实现	简单、跨语⾔	不⽀持SDK
Hessian	采⽤http +hessian 序列化实现	简单，轻量，容错性⾼	不能跨语⾔

存在的弊端
a. 没有负载均衡：这么多个机器调⽤哪⼀台?
b. 没有健康检测：服务关宕机或恢复后怎么办？
c. 不能容错：如果服务挂断后怎么办？

2. 基于反向代理的集中式分布式架构。
   这是最简单和传统做法，在服务消费者和⽣产者之间，代理作为独⽴⼀层集中部署，由独⽴团队(⼀般是运维或框架)负责治理和运维。常⽤的集中式代理有硬件负载均衡器(如F5)，或者软件负载均衡器(如Nginx)，这种软硬结合两层代理也是业内常见做法，兼顾配置的灵活性(Nginx⽐F5易于配置)。

⽅案总结：
优点：简单快速、⼏乎没有学习成本 适⽤场景：轻量级分布式系统、局部分布式架构。
瓶颈：Nginx中⼼负载、Http传输、JSON序列化、开发效率、运维效率。

3. 嵌⼊应⽤内部的去中⼼化架构
   这是很多互联⽹公司⽐较流⾏的⼀种做法，代理(包括服务发现和负载均衡逻辑)以客户库的形式嵌⼊在应⽤程序中。这种模式⼀般需要独⽴的服务注册中⼼组件配合，服务启动时⾃动注册 到注册中⼼并定期报⼼跳，客户端代理则发现服务并做负载均衡。我们所熟悉的 duboo 和 spring cloud Eureka +Ribbon 都是这种⽅式实现。
   

相⽐第⼀代架构它有以下特点⼏点：
去中⼼化，客户端直连服务端 动态注册和发现服务。
⾼效稳定的⽹络传输 。
⾼效可容错的序列化。

4. 基于独⽴代理进程的架构(Service Mesh)
   这种做法是上⾯两种模式的⼀个折中，代理既不是独⽴集中部署，也不嵌⼊在客户应⽤程序 中，⽽是作为独⽴进程部署在每⼀个主机上，⼀个主机上的多个消费者应⽤可以共⽤这个代 理，实现服务发现和负载均衡，如下图所示。这个模式⼀般也需要独⽴的服务注册中⼼组件配 合，作⽤同第⼆代架构
   
   前三种架构的对比

模式	优点	缺点	适用场景	案例
集中式负载架构 （中⼼化）	简单集中式治理 与语⾔⽆关	配置维护成本⾼多了⼀层IO 单点问题	⼤部分公司都适⽤，对运维有要求	亿⻉、携程、早期互联⽹公司
客户端嵌⼊式架构（去中⼼化）	⽆单点 性能更好	有侵⼊性 客户端复杂 语⾔栈要求	中⼤规模公司、语 ⾔栈统⼀	Dubbo 、 Twitter finagle、 Spring Cloud Ribbon
独⽴进程代理架 构（去中⼼化）	⽆单点 性能更好 与语⾔⽆关	运维部署复杂 开发联调复杂 不成熟	中⼤规模公司 对运维有要求	Smart Stack Service Mesh

总结

以上就是本期小编在宏观角度认识的分布式架构。希望大家有所收过。里面有写到不好的地方希望大家给予建议，也希望大家多多评论。