分布式、微服务（概念）

（一）分布式

传统的单体架构模式简单方便，但是在如今高并发的应用场景中，单体架构已不适用，而且单体架构也有明显的缺点

• 存在单点故障导致整体不可用
• 全部任务都在同一服务器（节点）处理，响应慢、压力大

 

所以现在将系统进行拆分，消去中心化管理，那么怎么拆？

• 既然单个节点隐患大，那就将其划分，分别运行在不同的服务器（节点）上，形成集群。

注意这里的集群概念并不等同于redis中的“集群”（最简：3主3从）

redis中的“集群”是这里的分布式和集群的整合（1主1从为这里的一个集群）

• 又考虑到每个服务器（节点）同样需要处理相同繁重任务，所以再将系统按照业务的不同进行划分，这就是分布式。

比如即使使用了集群，分担了高并发下的压力，但是不同业务对于数据库都有写操作

而集群中只有master机才可以实现写作，所操以master机的压力依然没法得到缓解。

将业务划分后，不同业务有不同的集群，每个集群都有一个master机，所以写操作的请求被划分到不同业务对应的master机上，也就分担了请求压力。

 

简单地说：

• 集群：   多个服务器处理同一事件（水平划分）
• 分布式：多个服务器处理不同的事件（垂直划分）

 

现在的分布式架构系统

• 通过垂直划分，将系统按照不同的业务进行划分，分开部署
• 再通过水平划分，对于同一业务功能，为减缓单机的压力，提高此业务功能的稳定性和可用性，可以使用多个服务器（节点）一起处理（负载均衡处理），即每一个业务都有自己的集群。
  • 当然也不是说所有的分布式系统中，每一个业务都需要多个服务器（节点）构成相关集群，有可能某一业务只需一个服务器（节点），这一个节点自己构成一个集群。

 

 

分布式架构特点

• 去中心化，解决当体故障问题
• 拆分的各个节点独立却也又相互联系（独立不孤立）
  • 独立：个体故障不会影响整体
  • 联系：个体与整体之间有数据传输
• 将系统划分为各模块，模块重用性高
• 系统模块划分明确，模块扩展性高
• 通过多个节点处理，响应速度快、稳定性强、可用性高
• 当然了，实现复杂。为了上面的功能，数据必定冗余，所以在数据存储和传输方面是一大笔开销。同时还需要考虑事务机制等问题。

 

在分布式系统中，常用zookeeper+dubbo组合。而SpringBoot则推荐使用全栈的Spring：SpringBoot + SpringCloud。

 

（二）微服务

      简单地说，就是将系统分为很小的服务，小到每一个功能作为一个服务。而每一个服务都可以独立开发、测试、部署、上线运行，即每一个服务之间是松耦合的，每个服务都可以由独立的团队负责，各个服务之间通过RPC框架或REST API来交互。

 

   特点

• 由于服务松耦合，所以某个模块的升级和BUG不会影响现有的系统业务。
• 每个服务模块易于开发和维护，但是服务之间的接口调用复杂度高，维护成本高

 

   区分和联系：分布式和微服务

• 两者是不同的概念，分布式是系统部署方式，微服务是架构设计方式
• 微服务通常离不开分布式，生产环境下的微服务肯定是分布式部署的。而分布式部署的应用不一定是微服务架构的，比如集群部署，但是逻辑功能上并没有细分服务。

 

 

 

（三）RPC

RPC（Remote Procedure Call）远程过程调用，可以通过网络从远程计算机程序上请求服务，不需要了解底层网络技术的思想。

 

RPC 框架的重要组成

• 客户端(Client)：服务调用方。
• 客户端存根(Client Stub)：存放服务端地址信息，将客户端的请求参数数据信息打包成网络消息，再通过网络传输发送给服务端。
• 服务端存根(Server Stub)：接收客户端发送过来的请求消息并进行解包，然后再调用本地服务进行处理。
• 服务端(Server)：服务的真正提供者。
• Network Service：底层传输，可以是 TCP 或 HTTP。

 

常见的RPC框架由：Dubbo、Spring Cloud等等。

 

（先到这，RPC有点复杂， 之后再具体补充）