分布式 - 谈谈你对分布式的理解，为什么引入分布式？

不啰嗦，我们直接开始！

划重点：

1. 真正了解分布式系统的概念，日后工作中具有分布式系统设计思想。
2. 能否在设计中对系统稳定性方面考虑周全。
3. 能构建高 QPS 健壮的系统架构。

1、面试官：那谈谈你对分布式系统的理解

问题分析：

各种分布式框架层出不穷，Spring Cloud，阿里的 Dubbo，无论使用哪一个，原理都相同，考察下基本概念掌握的如何。

答：

为了解决传统单体服务架构带来的各种问题，代码数量庞大，迭代测试维护困难，可能因为一处改动测试不到位造成整个服务瘫痪等问题，分布式系统就是将一个大的服务拆分成几十个甚至上百个微小的服务。如果把单体架构服务器比做篮子，那代码就是鸡蛋，不要让所有鸡蛋别装在一个篮子里，也方便大家分工开发，代码不在一个项目里，也不会冲突，最主要的是项目自己维护，多好。

比如阿里的 Dubbo，还有 Spring 全家桶里的 Spring Cloud，都是解决分布式微服务架构的优秀框架。

2、面试官：那分布式系统环境下各自有什么优缺点？

问题分析：

优点是显而易见的，面试官主要是想看看意识到有哪些缺点和问题，不过好的方面还是要简单带过。

答：

优点很多呀，使用分布式不就是为了解决传统架构各种问题嘛，多人在一个下开发维护难，也不好控制容错能力。拆分成微服务问题就好办多了。主要从 4 个方面简单说下。

1. 系统可用性提升
   一个系统全年可用时间在 99.999%，5 个 9 的服务可用率在设计合理的分布式系统中并不是一个触不可及的数字。
   传统的集中式计算或集中式存储在遇见单点故障时很容易造成整个服务不可用，分布式下的服务体系，单台机器有故障，不致于造成整个服务不可用。
2. 系统并发能力提升
   请求通过 Nginx 负载均衡被分发到不同的服务器上，运行同样代码的服务器可以有 1 台或 N 台，通常情况下会根据实际用户访问量随时增加机器，无论是数据库或者服务，都可以做到随时水平扩展。
   比如双 11 活动，平时订单少 50 台机器就够了，到了 11 订单量剧增，服务器增加到 100 台，每台机器之间相互独立，互不影响。
3. 系统容错能力提升

   

   
   （手里有笔，能给面试官随便画画）
   同一组服务分别部署在北京上海杭州，杭州的机房突发断电或者火灾，杭州机房的流量会被自动分发到北京和上海的机房，不影响用户使用。
4. 低延迟 
   参考上一个图，北京的用户请求自动分发到北京，上海的用户请求被分发到上海，服务器会根据用户的 IP 选择距离自己最近的机房，降低网络延迟。 

面试官：嗯，基本覆盖全面了，继续说说缺点。

凡事具有两面性，分布式服务带来很多好处的同时肯定还会带来麻烦，主要从 3 方面考虑。

1. 分布式服务依赖网络
   服务器间通讯依赖网络，不可靠网络包括网络延时，丢包、中断、异步，一个完整的服务请求依赖一连串服务调用，任意一个服务节点网络出现问题，都可能造成本次请求失败。
2. 维护成本高
   传统单体式服务只需要维护一个站点就可以。
   分布式服务系统被拆分成若干个小服务，服务从 1 变为几十个上百个服务后，增加运维成本。
3. 一致性，可用性，分区容错性无法同时满足
   这个是最主要的，这三种特性就是平时说的 CAP 定理，在分布式系统中，这三种特性最多只能满足两种，无法同时满足，需要根据实际情况去调整牺牲掉其中哪个。

面试官：嗯，最主要的第三点意识到了。（面试官心理：如果能意识到 CAP 问题那就好办多了，提到 CAP，那可以继续聊聊）

成功给自己挖坑，关于 CAP，下一节单独讲解

深入分析：

关于分布式系统，通俗点讲就把整个业务系统拆分成很多的服务，每个服务责任到人，服务之间代码都没有冲突，服务可以自治，每个服务到技术也可以自己选型，只要遵循统一的服务调用协议就可以了。每次发布如果就改动一个服务那就上线一个服务，不用所有人一起联调，这样每次发布牵扯到的改动影响也是可控的。不像传统单体架构服务，动辄几百万行代码融在一起。

这个概念是 Jim Waldo 在 1994 年发表的题为 “ A Note on Distributed Systems ” 的论文中提出的，感兴趣的读者可以看看英文原文。