分布式系统与架构

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 的，有时序数据的，有搜索数据的，有队列的……