分布式系统与架构

1. 分布式系统架构有哪些优势？

    1）增大系统容量

    2）加强系统可用性

    3）因为模块化，所以系统模块重用度更高

    4）因为软件模块化被拆分，开发和发布速度可以并发而变得更快

    5）系统扩展性更高

    6）团队协作流程也会得到改善

2. 分布式系统架构有哪些劣势？

    1）架构设计变得复杂（尤其是其中的分布式事务）

    2）部署单个服务会比较快，但如果一次部署多个服务，流程会变得复杂

    3）系统的吞吐量会变大，但响应时间会边长。

    4）运维复杂度会因为服务变多而变得复杂

    5）架构复杂导致学习曲线变大

    6）测试和查错的复杂度增大

    7）技术多元化，这会带来维护和运维的复杂度

    8）管理分布式系统中的服务和调度变得困难和复杂

3. 分布式系统中有哪些需要注意的问题？

    1）异构系统的不标准问题：软件、应用、通讯协议、数据格式、开发和运维的过程。需要统一标准。

    2）服务架构中的系统依赖问题（业务隔离；数据库隔离，不同业务有自己不同的数据库；主要的业务调用路径图）

          a. 如果非关键业务被关键业务所依赖，会导致非关键衣物变成一个关键业务

          b. 服务依赖链中，出现“木桶短板效应” -- 整个SLA（Service Level Agreement，服务级别协议是指提供服务的企业与客户之间就服务的品质、水准、性能等方面所达成的双方共同认可的协议或契约）由最差的那个服务决定。

    3）故障发生的概率更大

          a. 出现故障不可怕，故障恢复时间过长才可怕（怎么避免？）

          b. 出现故障不可怕，故障影响面过大才可怕（怎么避免？）

          需要我们在设计或运维系统时都要为这些故障考虑，即所谓 Design for Failure。在设计时就要考虑如何减轻故障。如果无法避免，也要使用自动化的方式恢复故障，减少故障影响面。

    4）多层架构的运维复杂度更大

          a. 任何一层的问题都会导致整体的问题

          b. 没有统一的视图和管理，导致运维被割裂开来，造成更大的复杂度

   分工不是问题，问题是分工后的协作是否统一和规范。

4. 使用分布式系统的主要目的是什么？

    1）大流量处理：通过集群技术把大规模并发请求的负载分散到不同的机器上。

    2）关键业务保护：提高后来服务的可用性，把故障隔离起来阻止多米诺骨牌效应（雪崩效应）。如果流量过大需要，需要对业务降级，以保护关键业务流转。

5. 怎样提高系统架构的性能？

    1）加缓冲：缓存系统（缓存分区，缓存更新，缓存命中）

    2）负载均衡：网关系统（负载均衡，服务路由，服务发现）

    3）异步调用：异步系统（消息队列，消息持久，异步事务）

    4）数据镜像：数据镜像（数据同步，读写分离，数据一致性）

    5）数据分区：数据分区（分区策略，数据访问层，数据一致性）

6. 怎样提高架构的稳定性？

    1）服务拆分：服务治理，服务调用，服务依赖，服务隔离

    2）服务冗余：服务调度，弹性伸缩，故障迁移，服务发现

    3）限流降级：异步队列，降级控制，服务熔断

    4）高可用架构：多租户系统，灾备多活，高可用服务

    5）高可用运维：运维系统，全栈监控，Devops，自动化运维

7. 分布式服务有哪些关键技术？

    1）服务治理

    2）架构软件管理

    3）DevOps

    4）自动化运维

    5）资源调度管理

    6）整体架构监控

    7）流量控制

8. 分布式系统的纲

    1）全栈系统监控

    2）服务/资源调度

    3）流量调度

    4）状态/数据调度

    5）开发和运维的自动化

9. 全栈监控主要监控哪些方面？

    1）基础层：监控主机和底层资源。如：CPU、内存、网络吞吐、硬盘I/O、硬盘使用等

    2）中间层：就是中间件的监控。如：Nginx、Redis、ActiveMQ、Kafka、MySQL、Tomcat 等

    3）应用层：监控应用层的使用。如：HTTP访问的吞吐量、响应时间、返回码，调用链路分析、性能瓶颈，还包括用户端的监控。

10. 监控系统有哪些常见问题？

    1）监控数据是隔离开来的

    2）监控的数据项太多

11. 监控系统的主要应用场景有哪些？

    1）体检：

          a. 容量管理：提供一个全局的运行时数据展示，可以让工程师团队知道是否需要增加机器或其他资源。

          b. 性能管理：可以通过查看大盘，找到系统瓶颈，并有针对性的优化系统和响应代码。

    2）急诊：

          a. 定位问题

          b. 性能分析：

12. 一个好的监控系统应该实现哪些功能？

     1）服务调用链跟踪：

     2）服务调用时长分布：使用 Zipkin，可以看到一个服务调用链上的时间分布，这样有助于我们知道最耗时的服务是什么。下图是 Zipkin 的服务调用时间分布。

     3）服务的TOP N视图：所谓 TOP N 视图就是一个系统请求的排名情况。一般来说，这个排名会有三种排名的方法：a）按调用量排名，b) 按请求最耗时排名，c）按热点排名（一个时间段内的请求次数的响应时间和）。

     4）数据库操作关联：

     5）服务资源跟踪：我们的服务可能运行在物理机上，也可能运行在虚拟机里，还可能运行在一个 Docker 的容器里，Docker 容器又运行在物理机或是虚拟机上。我们需要把服务运行的机器节点上的数据（如 CPU、MEM、I/O、DISK、NETWORK）关联起来。

13. 我们需要通过监控系统，达成什么样的目标？

     1）当一台机器挂掉是因为 CPU 或 I/O 过高的时候，我们马上可以知道其会影响到哪些对外服务的 API。

     2）当一个服务响应过慢的时候，我们马上能关联出来是否在做 Java GC，或是其所在的计算结点上是否有资源不足的情况，或是依赖的服务是否出现了问题。

     3）当发现一个 SQL 操作过慢的时候，我们能马上知道其会影响哪个对外服务的 API。

     4）当发现一个消息队列拥塞的时候，我们能马上知道其会影响哪些对外服务的 API。

14. 关于服务调度，我们有哪些能做的？

     1）服务关键程度和服务的依赖关系：

     2）服务状态和生命周期的管理：整个架构中有多少种服务？这些服务的版本是什么样的？每个服务的实例数有多少个，它们的状态是什么样的?每个服务的状态是什么样的？是在部署中，运行中，故障中，升级中，还是在回滚中，伸缩中，或者是在下线中……

     3）整个架构的版本管理

     4）资源和服务调度：

           a. 服务状态的维持和拟合

           b. 服务的弹性伸缩和故障迁移

           c. 服务工作流和编排

15. 流量调度应该具有哪些功能？

     1）依据系统运行情况，自动地进行流量调度，在无需人工干预的情况下，提升整个系统的稳定性。

     2）让系统应对爆品等突发事件时，在弹性计算扩缩容的较长时间窗口内或底层资源消耗殆尽的情况下，保护系统平稳运行。

     3）服务流控：服务发现、服务路由、服务降级、服务熔断、服务保护等。

     4）流量控制：负载均衡、流量分配、流量控制、异地灾备（多活）等。

     5）流量管理：协议转换、请求校验、数据缓存、数据计算等。

16. 流量与数据调度：

      1）状态数据调度：一般来说，我们会通过“转移问题”的方法来让服务变成“无状态的服务”。也就是说，会把这些有状态的东西存储到第三方服务上，比如 Redis、MySQL、ZooKeeper，或是 NFS、Ceph 的文件系统中。

      2）分布式事务一致性的问题：

           a. Master-Slave 方案。

           b. Master-Master 方案。

           c. 两阶段和三阶段提交方案。

           d. Paxos 方案。

           现在，很多公司的分布式系统事务基本上都是两阶段提交的变种。比如：阿里推出的 TCC–Try–Confirm–Cancel，或是我在亚马逊见到的 Plan–Reserve–Confirm 的方式，等等。凡是通过业务补偿，或是在业务应用层上做的分布式事务的玩法，基本上都是两阶段提交，或是两阶段提交的变种。

      3）数据结点的分布式方案

17. 状态数据调度小结：

       1）对于应用层上的分布式事务一致性，只有两阶段提交这样的方式。

       2）底层存储可以解决这个问题的方式是通过一些像 Paxos、Raft 或是 NWR 这样的算法和模型来解决。

       3）状态数据调度应该是由分布式存储系统来解决的，这样会更为完美。但是因为数据存储的 Scheme 太多，所以，导致我们有各式各样的分布式存储系统，有文件对象的，有关系型数据库的，有 NoSQL 的，有时序数据的，有搜索数据的，有队列的……