Java全栈知识点问题汇总(下)(二)

13 分布式

分布式相关。

13.1 一致性算法

什么是分布式系统的副本一致性？有哪些？

分布式系统通过副本控制协议，使得从系统外部读取系统内部各个副本的数据在一定的约束条件下相同，称之为副本一致性(consistency)。副本一致性是针对分布式系统而言的，不是针对某一个副本而言。

强一致性(strong consistency) ：任何时刻任何用户或节点都可以读到最近一次成功更新的副本数据。强一致性是程度最高的一致性要求，也是实践中最难以实现的一致性。

单调一致性(monotonic consistency) ：任何时刻，任何用户一旦读到某个数据在某次更新后的值，这个用户不会再读到比这个值更旧的值。单调一致性是弱于强一致性却非常实用的一种一致性级别。因为通常来说，用户只关心从己方视角观察到的一致性，而不会关注其他用户的一致性情况。

会话一致性(session consistency) ：任何用户在某一次会话内一旦读到某个数据在某次更新后的值，这个用户在这次会话过程中不会再读到比这个值更旧的值。会话一致性通过引入会话的概念，在单调一致性的基础上进一步放松约束，会话一致性只保证单个用户单次会话内数据的单调修改，对于不同用户间的一致性和同一用户不同会话间的一致性没有保障。实践中有许多机制正好对应会话的概念，例如php 中的session 概念。

最终一致性(eventual consistency) ：最终一致性要求一旦更新成功，各个副本上的数据最终将达 到完全一致的状态，但达到完全一致状态所需要的时间不能保障。对于最终一致性系统而言，一个用户只要始终读取某一个副本的数据，则可以实现类似单调一致性的效果，但一旦用户更换读取的副本，则无法保障任何一致性。

弱一致性(week consistency) ：一旦某个更新成功，用户无法在一个确定时间内读到这次更新的值，且即使在某个副本上读到了新的值，也不能保证在其他副本上可以读到新的值。弱一致性系统一般很难在实际中使用，使用弱一致性系统需要应用方做更多的工作从而使得系统可用。

在分布式系统中有哪些常见的一致性算法？

分布式算法 - 一致性Hash算法

• 一致性Hash算法是个经典算法，Hash环的引入是为解决单调性(Monotonicity)的问题；虚拟节点的引入是为了解决平衡性(Balance)问题

分布式算法 - Paxos算法

• Paxos算法是Lamport宗师提出的一种基于消息传递的分布式一致性算法，使其获得2013年图灵奖。自Paxos问世以来就持续垄断了分布式一致性算法，Paxos这个名词几乎等同于分布式一致性, 很多分布式一致性算法都由Paxos演变而来

分布式算法 - Raft算法

• Paxos是出了名的难懂，而Raft正是为了探索一种更易于理解的一致性算法而产生的。它的首要设计目的就是易于理解，所以在选主的冲突处理等方式上它都选择了非常简单明了的解决方案

分布式算法 - ZAB算法

• ZAB 协议全称：Zookeeper Atomic Broadcast（Zookeeper 原子广播协议）, 它应该是所有一致性协议中生产环境中应用最多的了。为什么呢？因为他是为 Zookeeper 设计的分布式一致性协议！

谈谈你对一致性hash算法的理解？

判定哈希算法好坏的四个定义:

• 平衡性(Balance): 平衡性是指哈希的结果能够尽可能分布到所有的缓冲中去，这样可以使得所有的缓冲空间都得到利用。很多哈希算法都能够满足这一条件。
• 单调性(Monotonicity): 单调性是指如果已经有一些内容通过哈希分派到了相应的缓冲中，又有新的缓冲加入到系统中。哈希的结果应能够保证原有已分配的内容可以被映射到原有的或者新的缓冲中去，而不会被映射到旧的缓冲集合中的其他缓冲区。
• 分散性(Spread): 在分布式环境中，终端有可能看不到所有的缓冲，而是只能看到其中的一部分。当终端希望通过哈希过程将内容映射到缓冲上时，由于不同终端所见的缓冲范围有可能不同，从而导致哈希的结果不一致，最终的结果是相同的内容被不同的终端映射到不同的缓冲区中。这种情况显然是应该避免的，因为它导致相同内容被存储到不同缓冲中去，降低了系统存储的效率。分散性的定义就是上述情况发生的严重程度。好的哈希算法应能够尽量避免不一致的情况发生，也就是尽量降低分散性。
• 负载(Load): 负载问题实际上是从另一个角度看待分散性问题。既然不同的终端可能将相同的内容映射到不同的缓冲区中，那么对于一个特定的缓冲区而言，也可能被不同的用户映射为不同 的内容。与分散性一样，这种情况也是应当避免的，因此好的哈希算法应能够尽量降低缓冲的负荷。

什么是Paxos算法？如何实现的？

Paxos算法是Lamport宗师提出的一种基于消息传递的分布式一致性算法，使其获得2013年图灵奖。

• 三个角色？ 可以理解为人大代表(Proposer)在人大向其它代表(Acceptors)提案，通过后让老百姓(Learner)落实

Paxos将系统中的角色分为提议者 (Proposer)，决策者 (Acceptor)，和最终决策学习者 (Learner):

在多副本状态机中，每个副本同时具有Proposer、Acceptor、Learner三种角色。

• 基于消息传递的3个阶段

#sudo sh-c'echo“greater-show-manual-login = true”>> / etc / lightdm / lightdm.conf'

sudo apt-get remove library_name

• 基于一个图解释

• 基于虚拟化角度

Docker的架构？

Docker 使用客户端-服务器 (C/S) 架构模式，使用远程API来管理和创建Docker容器。

• Docker 客户端(Client) : Docker 客户端通过命令行或者其他工具使用 Docker SDK (docs.docker.com/develop/sdk…) 与 Docker 的守护进程通信。
• Docker 主机(Host) ：一个物理或者虚拟的机器用于执行 Docker 守护进程和容器。

Docker 包括三个基本概念:

• 镜像（Image） ：Docker 镜像（Image），就相当于是一个 root 文件系统。比如官方镜像 ubuntu:16.04 就包含了完整的一套 Ubuntu16.04 最小系统的 root 文件系统。
• 容器（Container） ：镜像（Image）和容器（Container）的关系，就像是面向对象程序设计中的类和实例一样，镜像是静态的定义，容器是镜像运行时的实体。容器可以被创建、启动、停止、删除、暂停等。
• 仓库（Repository） ：仓库可看着一个代码控制中心，用来保存镜像。

Docker镜像相关操作有哪些？

# 查找镜像
docker search mysql
​
# 拉取镜像
docker pull mysql
​
# 删除镜像
docker rmi hello-world
​
# 更新镜像
docker commit -m="update test" -a="pdai" 0a1556ca3c27  pdai/ubuntu:v1.0.1
​
# 生成镜像
docker build -t pdai/ubuntu:v2.0.1 .
​
# 镜像标签
docker tag a733d5a264b5 pdai/ubuntu:v3.0.1
​
# 镜像导出
docker save > pdai-ubuntu-v2.0.2.tar 57544a04cd1a
​
# 镜像导入
docker load < pdai-ubuntu-v2.0.2.tar

Docker容器相关操作有哪些？

# 容器查看
docker ps -a
​
# 容器启动
docker run -it pdai/ubuntu:v2.0.1 /bin/bash
​
# 容器停止
docker stop f5332ebce695
​
# 容器再启动
docker start f5332ebce695
​
# 容器重启
docker restart f5332ebce695
​
# 容器导出
docker export f5332ebce695 > ubuntu-pdai-v2.tar
​
# 容器导入
docker import ubuntu-pdai-v2.tar pdai/ubuntu:v2.0.2
​
# 容器强制停止并删除
docker rm -f f5332ebce695
​
# 容器清理
docker container prune
​
# 容器别名操作
docker run -itd --name pdai-ubuntu-202 pdai/ubuntu:v2.0.2 /bin/bash

如何查看Docker容器的日志？

#例：实时查看docker容器名为user-uat的最后10行日志
docker logs -f -t --tail 10 user-uat
​
#例：查看指定时间后的日志，只显示最后100行：
docker logs -f -t --since="2018-02-08" --tail=100 user-uat
​
#例：查看最近30分钟的日志:
docker logs --since 30m user-uat
​
#例：查看某时间之后的日志：
docker logs -t --since="2018-02-08T13:23:37" user-uat
​
#例：查看某时间段日志：
docker logs -t --since="2018-02-08T13:23:37" --until "2018-02-09T12:23:37" user-uat
​
#例：将错误日志写入文件：
docker logs -f -t --since="2018-02-18" user-uat | grep error >> logs_error.txt

如何启动Docker容器？参数含义？

[root@pdai docker-test]# docker run -itd pdai/ubuntu:v2.0.1 /bin/bash

• -it 可以连写的，表示 -i -t
• -t: 在新容器内指定一个伪终端或终端。
• -i: 允许你对容器内的标准输入 (STDIN) 进行交互
• -d: 后台模式

如何进入Docker后台模式？有什么区别？

• 第一种：docker attach

[root@pdai ~]# docker ps
CONTAINER ID        IMAGE                COMMAND             CREATED             STATUS              PORTS               NAMES
f5332ebce695        pdai/ubuntu:v2.0.1   "/bin/bash"         38 minutes ago      Up 2 seconds        22/tcp, 80/tcp      jolly_kepler
[root@pdai ~]# docker attach f5332ebce695
root@f5332ebce695:/# echo 'pdai'
pdai
root@f5332ebce695:/# exit
exit
[root@pdai ~]# docker ps
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES

看到没，使用docker attach进入后，exit便容器也停止了。

• 第二种：docker exec

[root@pdai ~]# docker exec -it f5332ebce695 /bin/bash
Error response from daemon: Container f5332ebce69520fba353f035ccddd4bd42055fbd1e595f916ba7233e26476464 is not running
[root@pdai ~]# docker restart f5332ebce695
f5332ebce695
[root@pdai ~]# docker exec -it f5332ebce695 /bin/bash
root@f5332ebce695:/# exit
exit
[root@pdai ~]# docker ps
CONTAINER ID        IMAGE                COMMAND             CREATED             STATUS              PORTS               NAMES
f5332ebce695        pdai/ubuntu:v2.0.1   "/bin/bash"         42 minutes ago      Up 8 seconds        22/tcp, 80/tcp      jolly_kepler

注意：

• 我特意在容器停止状态下执行了docker exec，是让你看到docker exec是在容器启动状态下用的，且注意下错误信息；
• 推荐大家使用 docker exec 命令，因为此退出容器终端，不会导致容器的停止。

15.3 CI/CD

什么是CI？

CI的英文名称是Continuous Integration，中文翻译为：持续集成。

CI中，开发人员将会频繁地向主干提交代码，这些新提交的代码在最终合并到主干前，需要经过编译和自动化测试流进行验证。 持续集成（CI）是在源代码变更后自动检测、拉取、构建和（在大多数情况下）进行单元测试的过程。持续集成的目标是快速确保开发人员新提交的变更是好的，并且适合在代码库中进一步使用。CI的流程执行和理论实践让我们可以确定新代码和原有代码能否正确地集成在一起。

通俗点讲就是：通过持续集成， 开发人员能够在任何时候多次向仓库提交作品，而不是独立地开发每个功能模块并在开发周期结束时一一提交。这里的一个重要思想就是让开发人员更快更、频繁地做到这一点，从而降低集成的开销。 实际情况中，开发人员在集成时经常会发现新代码和已有代码存在冲突。 如果集成较早并更加频繁，那么冲突将更容易解决且执行成本更低。当然，这里也有一些权衡，这个流程不提供额外的质量保障。 事实上，许多组织发现这样的集成方式开销更大，因为它们依赖人工确保新代码不会引起新的 bug 或者破坏现有代码。 为了减少集成期间的摩擦，持续集成依赖于测试套件和自动化测试。 然而，要认识到自动化测试和持续测试是完全不同的这一点很重要。

CI 的目标是将集成简化成一个简单、易于重复的日常开发任务， 这样有助于降低总体的构建成本并在开发周期的早期发现缺陷。 要想有效地使用 CI 必须转变开发团队的习惯，要鼓励频繁迭代构建， 并且在发现 bug 的早期积极解决。

什么是CD？

这里的CD可对应多个英文名称，持续交付Continuous Delivery和持续部署Continuous Deployment。下面我们分别来看看上面是持续交付和持续部署。

• 持续交付

持续交付（CD）实际上是 CI 的扩展，其中软件交付流程进一步自动化，以便随时轻松地部署到生成环境中。 成熟的持续交付方案也展示了一个始终可部署的代码库。使用 CD 后，软件发布将成为一个没有任何紧张感的例行事件。 开发团队可以在日常开发的任何时间进行产品级的发布，而不需要详细的发布方案或者特殊的后期测试。

完成 CI 中构建及单元测试和集成测试的自动化流程后，持续交付可自动将已验证的代码发布到存储库。为了实现高效的持续交付流程，务必要确保 CI 已内置于开发管道。持续交付的目标是拥有一个可随时部署到生产环境的代码库。

在持续交付中，每个阶段（从代码更改的合并，到生产就绪型构建版本的交付）都涉及测试自动化和代码发布自动化。在流程结束时，运维团队可以快速、轻松地将应用部署到生产环境中或发布给最终使用的用户。

CD 集中依赖于部署流水线，团队通过流水线自动化测试和部署过程。此流水线是一个自动化系统， 可以针对构建执行一组渐进的测试套件。CD 具有高度的自动化，并且在一些云计算环境中也易于配置。在流水线的每个阶段，如果构建无法通过关键测试会向团队发出警报。否则，将继续进入下一个测试， 并在连续通过测试后自动进入下一个阶段。流水线的最后一个部分会将构建部署到和生产环境等效的环境中。 这是一个整体的过程，因为构建、部署和环境都是一起执行和测试的，它能让构建在实际的生产环境可部署和可验证。

• 持续部署

持续部署扩展了持续交付，以便软件构建在通过所有测试时自动部署。在这样的流程中， 不需要人为决定何时及如何投入生产环境。CI/CD 系统的最后一步将在构建后的组件/包退出流水线时自动部署。 此类自动部署可以配置为快速向客户分发组件、功能模块或修复补丁，并准确说明当前提供的内容。采用持续部署的组织可以将新功能快速传递给用户，得到用户对于新版本的快速反馈，并且可以迅速处理任何明显的缺陷。 用户对无用或者误解需求的功能的快速反馈有助于团队规划投入，避免将精力集中于不容易产生回报的地方。

随着 DevOps 的发展，新的用来实现 CI/CD 流水线的自动化工具也在不断涌现。这些工具通常能与各种开发工具配合， 包括像 GitHub 这样的代码仓库和 Jira 这样的 bug 跟踪工具。此外，随着 SaaS 这种交付方式变得更受欢迎， 许多工具都可以在现代开发人员运行应用程序的云环境中运行，例如 GCP 和 AWS。但是对于一个成熟的CI/CD管道（Pipeline）来说，最后的阶段是持续部署。作为持续交付——自动将生产就绪型构建版本发布到代码存储库——的延伸，持续部署可以自动将应用发布到生产环境。

什么是CI/CD的管道？

CI / CD管道是与自动化工具和改进的工作流程集成的部署管道。 如果执行得当，它将最大程度地减少人为错误，并增强整个SDLC的反馈循环，使团队可以在更短的时间内交付较小的发行版。

典型的CI / CD管道必须包括以下阶段：

• 构建阶段
• 测试阶段
• 部署阶段
• 自动化测试阶段
• 部署到生产

如何理解DevOPS?

DevOps是Development和Operations的组合，是一种方法论，是一组过程、方法与系统的统称，用于促进应用开发、应用运维和质量保障（QA）部门之间的沟通、协作与整合。以期打破传统开发和运营之间的壁垒和鸿沟。

CI、CD和DevOps之间的关系 ：

在完全部署到所有用户之前，有哪些方法可以测试部署？

由于必须回滚/撤消对所有用户的部署可能是一种代价高昂的情况（无论是技术上还是用户的感知），已经有许多技术允许“尝试”部署新功能并在发现问题时轻松“撤消”它们。这些包括：

• 蓝/绿测试/部署

在这种部署软件的方法中，维护了两个相同的主机环境 —— 一个“蓝色” 和一个“绿色”。（颜色并不重要，仅作为标识。）对应来说，其中一个是“生产环境”，另一个是“预发布环境”。

在这些实例的前面是调度系统，它们充当产品或应用程序的客户“网关”。通过将调度系统指向蓝色或绿色实例，可以将客户流量引流到期望的部署环境。通过这种方式，切换指向哪个部署实例（蓝色或绿色）对用户来说是快速，简单和透明的。

当新版本准备好进行测试时，可以将其部署到非生产环境中。在经过测试和批准后，可以更改调度系统设置以将传入的线上流量指向它（因此它将成为新的生产站点）。现在，曾作为生产环境实例可供下一次候选发布使用。

同理，如果在最新部署中发现问题并且之前的生产实例仍然可用，则简单的更改可以将客户流量引流回到之前的生产实例 —— 有效地将问题实例“下线”并且回滚到以前的版本。然后有问题的新实例可以在其它区域中修复。

• 金丝雀测试/部署

在某些情况下，通过蓝/绿发布切换整个部署可能不可行或不是期望的那样。另一种方法是为金丝雀测试/部署。在这种模型中，一部分客户流量被重新引流到新的版本部署中。例如，新版本的搜索服务可以与当前服务的生产版本一起部署。然后，可以将 10％ 的搜索查询引流到新版本，以在生产环境中对其进行测试。

如果服务那些流量的新版本没问题，那么可能会有更多的流量会被逐渐引流过去。如果仍然没有问题出现，那么随着时间的推移，可以对新版本增量部署，直到 100％ 的流量都调度到新版本。这有效地“更替”了以前版本的服务，并让新版本对所有客户生效。

• 功能开关

对于可能需要轻松关掉的新功能（如果发现问题），开发人员可以添加功能开关。这是代码中的 if-then 软件功能开关，仅在设置数据值时才激活新代码。此数据值可以是全局可访问的位置，部署的应用程序将检查该位置是否应执行新代码。如果设置了数据值，则执行代码；如果没有，则不执行。

这为开发人员提供了一个远程“终止开关”，以便在部署到生产环境后发现问题时关闭新功能。

• 暗箱发布

在暗箱发布中，代码被逐步测试/部署到生产环境中，但是用户不会看到更改（因此名称中有暗箱一词）。例如，在生产版本中，网页查询的某些部分可能会重定向到查询新数据源的服务。开发人员可收集此信息进行分析，而不会将有关接口，事务或结果的任何信息暴露给用户。

这个想法是想获取候选版本在生产环境负载下如何执行的真实信息，而不会影响用户或改变他们的经验。随着时间的推移，可以调度更多负载，直到遇到问题或认为新功能已准备好供所有人使用。实际上功能开关标志可用于这种暗箱发布机制。

什么是持续测试？

持续测试是一个过程，它将自动化测试作为软件交付通道中内嵌的一部分，以尽快获得软件发布后业务风险的反馈。

持续测试与自动化测试的侧重点？

• 自动化测试旨在生成一组与用户故事或应用程序要求相关的通过/失败的数据点。
• 持续测试侧重于业务风险，并提供有关软件是否可以发布的判断。要实现这一转变，我们需要停止询问“我们是否已完成测试？”而是集中精力在“发布版本是否具有可接受的业务风险级别？”

为什么我们需要持续测试？

今天，整个行业的变化要求测试更多，同时使自动化测试更难实现（至少使用传统工具和方法）：

• 应用程序体系结构越来越分散和复杂，包含云，API，微服务等，并在单个业务事务中创建几乎无限的不同协议和技术组合。
• 由于Agile，DevOps和持续交付，许多应用程序现在每两周发布一次，每天发布数千次。因此，可用于测试设计，维护和特别是执行的时间大大减少。

既然软件是业务的主要接口，那么应用程序故障就是业务失败， 如果它影响用户体验，即使是看似微不足道的小故障也会产生严重后果。因此，与应用相关的风险已成为即使是非技术性商业领袖的主要关注点。

如何做版本管理？

• Master 分支 主分支，这个分支最近发布到生产环境的代码，最近发布的Release， 这个分支只能从其他分支合并，不能在这个分支直接修改
• Develop 分支 这个分支是我们是我们的主开发分支，包含所有要发布到下一个Release的代码，这个主要合并与其他分支，比如Feature分支
• Feature 分支 这个分支主要是用来开发一个新的功能，一旦开发完成，我们合并回Develop分支进入下一个Release
• Release 分支 当你需要发布一个新Release的时候，我们基于Develop分支创建一个Release分支，完成Release后，我们合并到Master和Develop分支
• Hotfix 分支 当我们在Production发现新的Bug时候，我们需要创建一个Hotfix, 完成Hotfix后，我们合并回Master和Develop分支，所以Hotfix的改动会进入下一个Release

15.4 监控体系

为什么要有监控系统？ 谈谈你对监控的理解？

监控的目标？

• 发现问题：当系统发生故障报警，我们会收到故障报警的信息。
• 定位问题：故障邮件一般都会写某某主机故障、具体故障的内容，我们需要对报警内容进行分析。比如一台服务器连不上，我们就需要考虑是网络问题、还是负载太高导致长时间无法连接，又或者某开发触发了防火墙禁止的相关策略等，我们就需要去分析故障具体原因。
• 解决问题：当然我们了解到故障的原因后，就需要通过故障解决的优先级去解决该故障。
• 总结问题：当我们解决完重大故障后，需要对故障原因以及防范进行总结归纳，避免以后重复出现。

具体而言？

• 对系统不间断的实时监控：实际上是对系统不间断的实时监控(这就是监控)；
• 实时反馈系统当前状态：我们监控某个硬件、或者某个系统，都是需要能实时看到当前系统的状态，是正常、异常、或者故障。
• 保证服务可靠性安全性：我们监控的目的就是要保证系统、服务、业务正常运行
• 保证业务持续稳定运行：如果我们的监控做得很完善，即使出现故障，能第一时间接收到故障报警，在第一时间处理解决，从而保证业务持续性的稳定运行。

监控体系监控哪些内容？

1、硬件监控 通过SNMP来进行路由器交换机的监控(这些可以跟一些厂商沟通来了解如何做)、服务器的温度以及其它，可以通过IPMI来实现。当然如果没有硬件全都是云，直接跳过这一步骤。

2、系统监控 如CPU的负载，上下文切换、内存使用率、磁盘读写、磁盘使用率、磁盘inode使用率。当然这些都是需要配置触发器，因为默认太低会频繁报警。

3、服务监控 比如公司用的LNMP架构，Nginx自带Status模块、PHP也有相关的Status、MySQL的话可以通过Percona官方工具来进行监控。Redis这些通过自身的info获取信息进行过滤等。方法都类似。要么服务自带。要么通过脚本来实现想监控的内容，以及报警和图形功能。

4、网络监控 如果是云主机又不是跨机房，那么可以选择不监控网络。当然你说我们是跨机房以及如何如何，推荐使用smokeping来做网络相关的监控，或者直接交给你们的网络工程师来做，因为术业有专攻。

5、安全监控 如果是云主机可以考虑使用自带的安全防护。当然也可以使用iptables。如果是硬件，那么推荐使用硬件防火墙。使用云可以购买防DDOS，避免出现故障导致down机一天。如果是系统，那么权限、密码、备份、恢复等基础方案要做好。Web同时也可以使用Nginx+Lua来实现一个Web层面的防火墙。当然也可以使用集成好的OpenResty。

6、Web监控 Web监控的话题其实还是很多。比如可以使用自带的Web监控来监控页面相关的延迟、js响应时间、下载时间、等等。这里我推荐使用专业的商业软件监控宝或听云来实现。毕竟人家全国各地都有机房（如果本身是多机房那就另说了）。

7、日志监控 如果是Web的话可以使用监控Nginx的50x、40x的错误日志，PHP的ERROR日志。其实这些需求无非是，收集、存储、查询、展示，我们其实可以使用开源的ELKStack来实现。Logstash（收集）、Elasticsearch（存储+搜索）、Kibana（展示）。

8、业务监控 上面做了那么多，其实最终还是保证业务的运行。这样我们做的监控才有意义。所以业务层面这块的监控需要和开发以及总监开会讨论，监控比较重要的业务指标，（需要开会确认）然后通过简单的脚本就可以实现，最后设置触发器即可 。

9、流量分析 平时我们分析日志都是拿awk sed xxx一堆工具来实现。这样对我们统计IP、PV、UV不是很方便。那么可以使用百度统计、Google统计、商业，让开发嵌入代码即可。为了避免隐私也可以使用Piwik来做相关的流量分析。

10、可视化 通过Screen以及引入一些第三方的库来美化界面，同时我们也需要知道，订单量突然增加、突然减少。或者说突然来了一大波流量，这流量从哪儿来，是不是推广了，还是被攻击了。可以结合监控平来梳理各个系统之间的业务关系。

11、自动化监控 如上我们做了那么多的工作，当然不能是一台一台的来加key实现。可以通过Zabbix的主动模式以及被动模式来实现。当然最好还是通过API来实现。

监控一般采用什么样的流程？

• 采集 通过SNMP、Agent、ICMP、SSH、IPMI等对系统进行数据采集
• 存储 各类数据库服务,MySQL、PostgreSQL, 时序库等
• 分析 提供图形及时间线情况信息，方便我们定位故障所在
• 展示 指标信息、指标趋势展示
• 报警 电话、邮件、微信、短信、报警升级机制
• 处理 故障级别判定，找响应人员进行快速处理

16 其他

16.1 设计模式

16.2 开源协议

说说常见的开源协议？

最流行的六种：MIT、Apache、BSD、GPL和LGPL、Mozilla。

GPL协议、LGPL协议与BSD协议的法律区别？

简而言之，GPL协议就是一个开放源代码协议，软件的初始开发者使用了GPL协议并公开软件的源程序后，后续使用该软件源程序开发软件者亦应当根据GPL协议把自己编写的源程序进行公开。GPL协议要求的关键在于开放源程序，但并不排斥软件作者向用户收费。虽然如此，很多大公司对GPL协议还是又爱又恨，爱的是这个协议项下的软件历经众多程序员千锤百炼的修改，已经非常成熟完善，恨的是必须开放自己后续的源程序，导致竞争对手也可以根据自己修改的源程序开发竞争产品。

正因大公司对GPL协议在商业上存在顾虑，因此，另两种协议被采用的更多，第一种是LGPL(亦称GPL V2)协议，可以翻译为更宽松的GPL协议。与GPL协议的区别为，后者如果只是对LGPL软件的程序库的程序进行调用而不是包含其源代码时，相关的源程序无需开源。调用和包含的区别类似在互联网网网页上对他人网页内容的引用: 如果把他人的内容全部或部分复制到自己的网页上，就类似包含，如果只是贴一个他人网页的网址链接而不引用内容，就类似调用。有了这个协议，很多大公司就可以把很多自己后续开发内容的源程序隐藏起来。

第二种是BSD协议(类似的还有MIT协议)。BSD协议鼓励软件的作者公开自己后续开发的源代码，但不强求。在BSD协议项下开发的软件，原始的源程序是开放源代码的，但使用者修改以后，可以自行选择发布源程序或者二进制程序(即目标程序)，当然，使用者有义务把自己原来使用的源程序与BSD协议在软件对外发布时一并发布。因为比较灵活，所以BSD深受大公司的欢迎。

MongoDB修改开源协议？

2018年10月，MongoDB宣布其开源许可证将从GNU AGPLv3，切换到SSPL，新许可证将适用于新版本的MongoDB Community Server以及打过补丁的旧版本。

根据 MongoDB 之前的 GNU AGPLv3 协议，想要将 MongoDB 作为公共服务运行的公司必须将他们的软件开源，或需要从 MongoDB 获得商业许可，”该公司解释说，“然而，MongoDB 的普及使一些组织在违反 GNU AGPLv3 协议的边缘疯狂试探，甚至直接违反了协议。”

尽管 SSPL 与 GNU AGPLv3 没有什么不同，但 SSPL 会明确要求托管 MongoDB 实例的云计算公司要么从 MongoDB 获取商业许可证，要么向社区开源其服务代码。

随后Red Hat宣布，将不会在Red Hat Enterprise Linux或Fedora中使用MongoDB。事实上，MongoDB修改开源协议之后，Red Hat并不是首家弃用的Linux社区。2018年12月5日，Linux发行版Debian在邮件列表中讨论并决定不使用SSPL协议下的软件。2019年1月，Fedora Legal也对SSPL v1协议做出了相关决定，Fedora已确定服务器端公共许可证v1（SSPL）不是自由软件许可证。

16.3 软件理论

什么是CAP理论？

CAP原理指的是，在分布式系统中这三个要素最多只能同时实现两点，不可能三者兼顾。因此在进行分布式架构设计时，必须做出取舍。而对于分布式数据系统，分区容忍性是基本要求，否则就失去了价值。因此设计分布式数据系统，就是在一致性和可用性之间取一个平衡。对于大多数Web应用，其实并不需要强一致性，因此牺牲一致性而换取高可用性，是目前多数分布式数据库产品的方向。

为什么只能同时满足两个？

例如，服务器中原本存储的value=0，当客户端A修改value=1时，为了保证数据的一致性，要写到3个服务器中，当服务器C故障时，数据无法写入服务器C，则导致了此时服务器A、B和C的value是不一致的。这时候要保证分区容错性，即当服务器C故障时，仍然能保持良好的一致性和可用性服务，则Consistency和Availability不能同时满足。为什么呢？

如果满足了一致性，则客户端A的写操作value=1不能成功，这时服务器中所有value=0。 如果满足可用性，即所有客户端都可以提交操作并得到返回的结果，则此时允许客户端A写入服务器A和B，客户端C将得到未修改之前的value=0结果。

什么是BASE理论？

CAP 与 BASE 关系？

BASE是对CAP中一致性和可用性权衡的结果，其来源于对大规模互联网系统分布式实践的结论，是基于CAP定理逐步演化而来的，其核心思想是即使无法做到强一致性（Strong consistency），更具体地说，是对 CAP 中 AP 方案的一个补充。其基本思路就是：通过业务，牺牲强一致性而获得可用性，并允许数据在一段时间内是不一致的，但是最终达到一致性状态。

CAP 与 ACID 关系？

ACID 是传统数据库常用的设计理念，追求强一致性模型。BASE 支持的是大型分布式系统，提出通过牺牲强一致性获得高可用性。

ACID 和 BASE 代表了两种截然相反的设计哲学，在分布式系统设计的场景中，系统组件对一致性要求是不同的，因此 ACID 和 BASE 又会结合使用。

什么是SOLID原则？

• S单一职责SRP Single-Responsibility Principle

一个类,最好只做一件事,只有一个引起它的变化。单一职责原则可以看做是低耦合,高内聚在面向对象原则的引申,将职责定义为引起变化的原因,以提高内聚性减少引起变化的原因。

比如： SpringMVC 中Entity,DAO,Service,Controller, Util等的分离。

• O开放封闭原则OCP Open - Closed Principle

对扩展开放，对修改关闭(设计模式的核心原则)

比如： 设计模式中模板方法模式和观察者模式都是开闭原则的极好体现

• L里氏替换原则LSP Liskov Substitution Principle

任何基类可以出现的地方,子类也可以出现；这一思想表现为对继承机制的约束规范,只有子类能够替换其基类时,才能够保证系统在运行期内识别子类,这是保证继承复用的基础。

比如：正方形是长方形是理解里氏代换原则的经典例子。（讲的是基类和子类的关系，只有这种关系存在时，里氏代换原则才存在）

• I接口隔离法则ISL Interface Segregation Principle

客户端不应该依赖那些它不需要的接口。(接口隔离原则是指使用多个专门的接口，而不使用单一的总接口; 这个法则与迪米特法则是相通的)

• D依赖倒置原则DIP Dependency-Inversion Principle

要依赖抽象,而不要依赖具体的实现, 具体而言就是高层模块不依赖于底层模块,二者共同依赖于抽象。抽象不依赖于具体, 具体依赖于抽象。

什么是合成/聚合复用原则？

Composite/Aggregate ReusePrinciple ，CARP: 要尽量使用对象组合,而不是继承关系达到软件复用的目的。

组合/聚合可以使系统更加灵活，类与类之间的耦合度降低，一个类的变化对其他类造成的影响相对较少，因此一般首选使用组合/聚合来实现复用；其次才考虑继承，在使用继承时，需要严格遵循里氏代换原则，有效使用继承会有助于对问题的理解，降低复杂度，而滥用继承反而会增加系统构建和维护的难度以及系统的复杂度，因此需要慎重使用继承复用。

此原则和里氏代换原则氏相辅相成的,两者都是具体实现"开-闭"原则的规范。违反这一原则，就无法实现"开-闭"原则。

什么是迪米特法则？

Law of Demeter，LoD: 系统中的类,尽量不要与其他类互相作用,减少类之间的耦合度.

又叫最少知识原则(Least Knowledge Principle或简写为LKP).

• 不要和“陌生人”说话。英文定义为: Don't talk to strangers.
• 只与你的直接朋友通信。英文定义为: Talk only to your immediate friends.

比如：外观模式Facade(结构型)

什么是康威定律？

康威在一篇文章中描述： 设计系统的组织，其产生的设计等同于组织之内、组织之间的沟通结构。

• 定律一: 组织沟通方式会通过系统设计表达出来，就是说架构的布局和组织结构会有相似。
• 定律二: 时间再多一件事情也不可能做的完美，但总有时间做完一件事情。一口气吃不成胖子，先搞定能搞定的。
• 定律三: 线型系统和线型组织架构间有潜在的异质同态特性。种瓜得瓜，做独立自治的子系统减少沟通成本。
• 定律四: 大的系统组织总是比小系统更倾向于分解。合久必分，分而治之。

16.4 软件成熟度模型

什么是CMM？

由美国卡内基梅隆大学的软件工程研究所(SEI)创立的CMM(Capability Maturity Model 软件能力成熟度模型)认证评估，在过去的十几年中，对全球的软件产业产生了非常深远的影响。CMM共有五个等级，分别标志着软件企业能力成熟度的五个层次。从低到高，软件开发生产计划精度逐级升高，单位工程生产周期逐级缩短，单位工程成本逐级降低。据SEI统计，通过评估的软件公司对项目的估计与控制能力约提升40%到50%；生产率提高10%到20%，软件产品出错率下降超过1/3。

对一个软件企业来说，达到CMM2就基本上进入了规模开发，基本具备了一个现代化软件企业的基本架构和方法，具备了承接外包项目的能力。CMM3评估则需要对大软件集成的把握，包括整体架构的整合。一般来说，通过CMM认证的级别越高，其越容易获得用户的信任，在国内、国际市场上的竞争力也就越强。因此，是否能够通过CMM认证也成为国际上衡量软件企业工程开发能力的一个重要标志。

CMM是目前世界公认的软件产品进入国际市场的通行证，它不仅仅是对产品质量的认证，更是一种软件过程改善的途径。参与CMM评估的博科负责人表示，通过CMM的评估认证不是目标，它只是推动软件企业在产品的研发、生产、服务和管理上不断成熟和进步的手段，是一种持续提升和完善企业自身能力的过程。此次由美国PIA咨询公司负责评估并最终通过CMM3认证，标志着博科在质量管理的能力已经上升到一个新的高度。

什么是CMMI5 呢？

CMMI全称是Capability Maturity Model Integration, 即软件能力成熟度模型集成模型，是由美国国防部与卡内基-梅隆大学和美国国防工业协会共同开发和研制的。CMMI是一套融合多学科的、可扩充的产品集合， 其研制的初步动机是为了利用两个或多个单一学科的模型实现一个组织的集成化过程改进

CMMI分为五个等级，二十五个过程区域（PA）。

1． 初始级 软件过程是无序的，有时甚至是混乱的，对过程几乎没有定义，成功取决于个人努力。管理是反应式的。

2． 已管理级 建立了基本的项目管理过程来跟踪费用、进度和功能特性。制定了必要的过程纪律，能重复早先类似应用项目取得的成功经验。

3． 已定义级 已将软件管理和工程两方面的过程文档化、标准化，并综合成该组织的标准软件过程。所有项目均使用经批准、剪裁的标准软件过程来开发和维护软件，软件产品的生产在整个软件过程是可见的。

4． 量化管理级 分析对软件过程和产品质量的详细度量数据，对软件过程和产品都有定量的理解与控制。管理有一个作出结论的客观依据，管理能够在定量的范围内预测性能。

5． 优化管理级 过程的量化反馈和先进的新思想、新技术促使过程持续不断改进。

每个等级都被分解为过程域，特殊目标和特殊实践，通用目标、通用实践和共同特性：

每个等级都有几个过程区域组成，这几个过程域共同形成一种软件过程能力。每个过程域，都有一些特殊目标和通用目标，通过相应的特殊实践和通用实践来实现这些目标。当一个过程域的所有特殊实践和通用实践都按要求得到实施，就能实现该过程域的目标。

CMMI与CMM的区别呢？

CMM是指“能力成熟度模型”，其英文全称为Capability Maturity Model for Software；

CMMI 是指“能力成熟度模型集成”，全称为：Capability Maturity Model Integration；

CMMI是系统工程和软件工程的集成成熟度模型，CMMI更适合于信息系统集成企业。CMMI是在CMM基础上发展起来的，它继承并发扬了CMM的优良特性，借鉴了其他模型的优点，融入了新的理论和实际研究成果。它不仅能够应用在软件工程领域，而且可以用于系统工程及其他工程领域。

CMM与ISO9000的主要区别？

1.CMM是专门针对软件产品开发和服务的，而ISO9000涉及的范围则相当宽。

2.CMM强调软件开发过程的成熟度，即过程的不断改进和提高。而ISO9000则强调可接收的质量体系的最低标准。

16.5 等级保护

为什么是做等级保护？

《网络安全法》明确规定信息系统运营、使用单位应当按照网络安全等级保护制度要求，履行安全保护义务，如果拒不履行，将会受到相应处罚。

第二十一条：国家实行网络安全等级保护制度。网络运营者应当按照网络安全等级保护制度的要求，履行下列安全保护义务，保障网络免受干扰、破坏或者未经授权的访问，防止网络数据泄露或者被窃取、篡改。

在金融、电力、广电、医疗、教育等行业，主管单位明确要求从业机构的信息系统（APP）要开展等级保护工作。

信息系统运营、使用单位通过开展等级保护工作可以发现系统内部的安全隐患与不足之处，可通过安全整改提升系统的安全防护能力，降低被攻击的风险。

简单来说，《网络安全法》一直对网站、信息系统、APP有等级保护要求，中小型企业通常是行业要求才意识到问题。

等级保护分为哪些等级？

• 第一级 自主保护级：

（无需备案，对测评周期无要求）此类信息系统受到破坏后，会对公民、法人和其他组织的合法权益造成一般损害，不损害国家安全、社会秩序和公共利益。

• 第二级 指导保护级:

（公安部门备案，建议两年测评一次）此类信息系统受到破坏后，会对公民、法人和其他组织的合法权益造成严重损害。会对社会秩序、公共利益造成一般损害，不损害国家安全。

• 第三级 监督保护级：

（公安部门备案，要求每年测评一次）此类信息系统受到破坏后，会对国家安全、社会秩序造成损害，对公共利益造成严重损害，对公民、法人和其他组织的合法权益造成特别严重的损害。

• 第四级 强制保护级：

（公安部门备案，要求半年一次）此类信息系统受到破坏后，会对国家安全造成严重损害，对社会秩序、公共利益造成特别严重损害。

• 第五级 专控保护级：

（公安部门备案，依据特殊安全需求进行）此类信息系统受到破坏后会对国家安全造成特别严重损害。

怎么做等级保护？

• 等级保护通常需要5个步骤：

• 企业自己如何做等级保护？

整个流程企业自行做等级保护，顺利的话3-4个月完成，如果不熟悉需要半年甚至更久。

等保三的基本要求?

说说等级保护三级的技术要求，主要包含五个部门

• 物理安全

保证物理的安全，比如物理位置，机房的访问安全；涉及访问控制，防火防盗防雷防电磁，保备用电等

• 网络安全

保证网络层面安全，比如访问控制，安全审计，入侵防范，恶意代码防范，设备防范等。

• 主机安全

比如，身份鉴别，访问控制，安全审计，剩余信息保护（比如退出时清理信息），安全审计，入侵防范等。

• 应用安全

比如，数据完整性，数据保密性（加密），数据备份和回复。

16.6 ISO27001

什么是ISO27001？

信息安全管理体系标准（ISO27001)可有效保护信息资源,保护信息化进程健康、有序、可持续发展。ISO27001是信息安全领域的管理体系标准，类似于质量管理体系认证的 ISO9000标准。当您的组织通过了ISO27001的认证,就相当于通过ISO9000的质量认证一般，表示您的组织信息安全管理已建立了一套科学有效的管理体系作为保障。

ISO27001认证流程?

第一阶段：现状调研

从日常运维、管理机制、系统配置等方面对贵公司信息安全管理安全现状进行调研，通过培训使贵公司相关人员全面了解信息安全管理的基本知识。

第二阶段：风险评估

对贵公司信息资产进行资产价值、威胁因素、脆弱性分析，从而评估贵公司信息安全风险，选择适当的措施、方法实现管理风险的目的。

第三阶段：管理策划

根据贵公司对信息安全风险的策略，制定相应信息安全整体规划、管理规划、技术规划等，形成完整的信息安全管理系统。

第四阶段：体系实施

ISMS建立起来（体系文件正式发布实施）之后，要通过一定时间的试运行来检验其有效性和稳定性。

第五阶段：认证审核

经过一定时间运行，ISMS达到一个稳定的状态，各项文档和记录已经建立完备，此时，可以提请进行认证。