分布式相关概念整理

1、微服务

  微服务作为当前企业级应用最常见的架构，其设计理念的确非常巧妙。首先回顾一下个人搭建的博客系统，其显著特点就是所有功能集中在一个服务器或者说一个项目中，极易造成系统级灾难，相信大家都会有所感受，一个细节出现bug，整个项目随之崩溃。不光如此，也极难定位错误（如果日志不够完善），完全不符合“低耦合，高内聚”这一原理。
  微服务则完全不同，它将不同的功能封装为“服务”，使其运行在不同的服务器（或者项目，下文不在赘述）中，使得服务间相互独立，有效降低了耦合性。同时，由于不同服务可运行在不同的服务器上（怪不得叫服务器，以前倒是完全没有意识到），也使得分布式成为可能。服务之间可以相互调用，已完成项目需求。

2、分布式

  这个概念很常见，和linux多用户的理念恰巧相反，多用户是实际上有很多用户在使用同一台服务器，但是用户感觉自己独占了一台服务器。分布式是实际上存在多台服务器，但是用户感觉自己只使用了一台服务器。分布式是若干独立计算机的集合，可以通俗的理解为：现在有许多服务需要完成，我们可以将这些服务部署在不同计算机上以便提高服务能力，同时也优化了系统的结构。最典型的情况是：一台服务器上部署一个服务，不同服务器上部署同的服务，但是有时一台服务器不能提供某个服务所需的内存或者算力，此时就需要把同一服务部署在不同的服务器上，即通常所说的业务集群。
  同一服务部署在不同服务器上的优势有很多：某台服务器出现故障仍后可保证一定的服务能力，以及上文中说的提高性能等等。但是在调用服务时，我们应该如何选择呢？

  如上图所示，serviceA要调用serviceB，此时serviceB处在三个服务器上，合理的进行选择也是一个问题，我们通常称之为，负载均衡。典型的负载均衡策略有轮询，最小连接数，随机等等，从字面意思即可理解这些策略。这几天在听同学们的汇报时，听到一个接入网方面的负载均衡策略：当选择一个目标后，将其计数加一，一直选择最小的计数目标。起初我还以为是什么新的均衡策略，没有仔细听。现在一想就是最小连接数法，不过是在其他方面换了个名字而已。
  既然提到调用，那么serviceA和serviceB是处在不同的服务器之间的，他们如何进行调用呢？下面就来讲讲远程过程调用

远程过程调用（RPC）

  远程过程调用专门解决不同服务器间的通信问题，调用者提出请求，经过该协议通知服务，然后服务处理该请求，接着返回相应结构即可。这部分内容，建议去阿里看看dubbo的架构，讲解的很清楚，dubbo是一个典型的RPC应用。如果对dubbo感兴趣，也可以参加了解一下往年阿里的中间件比赛，我今年本来准备参加，但是又突然改成了云原生的比赛。有兴趣的可以参加一下。

结束语

  整理东西真是累啊，艹！