【云原生-白皮书】简章2：深入理解DevOps+微服务_微服务部署demo 运维(1)

为了做好运维面试路上的助攻手，特整理了上百道 【运维技术栈面试题集锦】 ，让你面试不慌心不跳，高薪offer怀里抱！

这次整理的面试题，小到shell、MySQL，大到K8s等云原生技术栈，不仅适合运维新人入行面试需要，还适用于想提升进阶跳槽加薪的运维朋友。

本份面试集锦涵盖了

• 174 道运维工程师面试题
• 128道k8s面试题
• 108道shell脚本面试题
• 200道Linux面试题
• 51道docker面试题
• 35道Jenkis面试题
• 78道MongoDB面试题
• 17道ansible面试题
• 60道dubbo面试题
• 53道kafka面试
• 18道mysql面试题
• 40道nginx面试题
• 77道redis面试题
• 28道zookeeper

总计 1000+ 道面试题， 内容 又全含金量又高

• 174道运维工程师面试题

1、什么是运维?

2、在工作中，运维人员经常需要跟运营人员打交道，请问运营人员是做什么工作的?

3、现在给你三百台服务器，你怎么对他们进行管理?

4、简述raid0 raid1raid5二种工作模式的工作原理及特点

5、LVS、Nginx、HAproxy有什么区别?工作中你怎么选择?

6、Squid、Varinsh和Nginx有什么区别，工作中你怎么选择?

7、Tomcat和Resin有什么区别，工作中你怎么选择?

8、什么是中间件?什么是jdk?

9、讲述一下Tomcat8005、8009、8080三个端口的含义？

10、什么叫CDN?

11、什么叫网站灰度发布?

12、简述DNS进行域名解析的过程?

13、RabbitMQ是什么东西?

14、讲一下Keepalived的工作原理?

15、讲述一下LVS三种模式的工作过程?

16、mysql的innodb如何定位锁问题，mysql如何减少主从复制延迟?

17、如何重置mysql root密码?

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以点击这里获取！

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

单体架构

单体架构是什么

在搞懂DevOps和微服务之前，需要先搞懂什么是单体应用/单体架构。简单来说，就跟在校的一些小项目一样，项目的Demo写好了，找一台服务器安装环境，然后把jar包远程上服务器，然后跑起来服务就可以了。这个时候进行简单的服务监控也不难，如果项目出了问题，查看一下运行日志，就可以知道哪一步出问题了。如果懂一些脚本，也可以写一些脚本分析日志，解放双手监控服务器。这种单体架构就是采用瀑布流方式开发的，服务的流程就是：设计 -> 开发 -> 测试 -> 部署 。

单体B/S架构

在还没有微服务和DevOps之前，一个Web应用的上线，一般都是将所有的功能都打包在一起，也就是都在一个项目包里面，然后将项目打包到一个服务器上跑起来就可以了，那个时候的B/S应用架构就是单体架构，结构图如下：

单体B/S+负载均衡

如果当用户访问量变大导致一台服务器无法支撑时，就需要加服务器进行负载均衡，这个时候架构的形式就是：单体B/S+负载均衡

单体B/S+前后端分离(CDN)

用了一段时间负载均衡之后，发现通过CDN手段，把静态文件独立，可以加速服务，提升应用速度，所以单体架构就进一步演变成了：B/S+前后端分离(CDN)

单体架构总结

上面所说的架构都是单体应用，只是某方面的部署形式进行了优化与改动，所以最终都避免不了单体应用的普遍缺陷：

单体

1、代码量大，应用启动时间较长。
2、测试周期长，更改Bug需要对全部业务进行回归测试。
3、应用容错性差，当某个程序出错后，导致整个项目业务宕机。
4、伸缩性困难，只能整个应用进行扩展，浪费资源。
5、开发协作性困难，项目人员都在维护一套代码，协作周期长、难度大。

DevOps

DevOps是什么

DevOps：Development和Operations的组合词，是一种重视“软件开发人员（Dev）”和“IT运维技术人员（Ops）”之间沟通合作的文化、运动或惯例。透过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。

分布式架构+敏捷开发模式

随着上述说的单体架构时，业务流量越来越大，那么肯定几台服务器是不够用的，这个时候就会加很多服务器机器，也会加入Nignx、CDN、缓存、消息队列等技术栈，同时开发人员也会变多，这个时候就是 多人多机协同开发问题。

多人协同开发的问题

这个时候，大多会将项目进行拆分，每个人负责专注于开发一部分业务，敏捷开发的核心理念就是既然无法充分了解超高业务流量下的用户的真实需求是怎样的，就将一个大的目标不断拆解，把它变成一个个可交付的小目标、小项目，然后通过不断迭代，以小步快跑的方式持续开发
。

此外，这个时候项目是非常大的，为保证项目质量，测试环节不可减少，为了加快速度增大开发效率，测试的工作最好是和开发同步交替进行的，需要将测试环节从后面注入到整个开发环节当中，每次可交付的都是一个可用的功能集合，对开发交付的内容进行持续验证。这样开发产品的可控性也更强，可以阶段性的检验一下项目成果。

多机器问题

之前机器很少架构简单的时候，开发就可以干运维的活，就算加了几台服务器，那也是脚本将 jar包 发布到这些机器上，好像也挺简单，但是会有两个人同时上线部署被覆盖的问题，但这些都不是问题，只要约定好错开时间进行上线部署就可以了。

但你如果是几千台服务器起步，那就需要专门的运维人员进行维护项目了，因为开发分工每个人都专注于自己的事情，不会那么用心进行维护，另一方面是运维的学习成本确实变高了，开发人质量参差不齐，如果服务器出问题那就不是小事。

但是这个时候也不是 DevOps，而是 Dev+Ops，还没有融合在一起。这时 Ops 的主要职责就是：硬件维护、网络设备维护、DBA 、基础服务维护、数据监控等，运维们擅长写各种部署，监控脚本，减少机械的重复工作，开发模式变成了敏捷开发模式。

这个时候，开发设计流程大致是这样。

到这里了，还没有引入到DevOps，还要先再插入讲讲微服务，才能更好的说明DevOps到底怎么理解。

微服务

微服务是什么

微服务（Microservices）是一种软件架构，它是以专注于单一责任与功能的小型功能区块 (Small Building Blocks) 为基础，利用模块化的方式组合出复杂的大型应用程序，各功能区块使用与语言无关 (Language-Independent/Language agnostic）的API集相互通信。

微服务的出现就是因为原来单体应用架构已经无法满足当前互联网产品的技术需求。

那么，到底什么样的服务才能算是微服务？
1、单一职责的。一个微服务应该都是单一职责的，这才是“微”的体现，一个微服务解决一个业务问题（注意是一个业务问题而不是一个接口）。
2、面向服务的。将自己的业务能力封装并对外提供服务，这是继承SOA的核心思想，一个微服务本身也可能使用到其它微服务的能力。
（有点像SOA的演进）

微服务架构

微服务架构，核心是为了解决应用微服务化之后的服务治理问题。

应用微服务化之后，首先遇到的第一个问题就是服务发现问题，一个微服务如何发现其他微服务呢？最简单的方式就是每个微服务里面配置其他微服务的地址，但是当微服务数量众多的时候，这样做明显不现实。所以需要使用到微服务架构中的一个最重要的组件：服务注册中心，所有服务都注册到服务注册中心，同时也可以从服务注册中心获取当前可用的服务清单：

解决服务发现问题后，接着需要解决微服务分布式部署带来的第二个问题：服务配置管理的问题。当服务数量超过一定程度之后，如果需要在每个服务里面分别维护每一个服务的配置文件，运维人员估计要哭了。那么，就需要用到微服务架构里面第二个重要的组件：配置中心，微服务架构就变成下面这样了：

以上应用内部的服务治理，当客户端或外部应用调用服务的时候怎么处理呢？服务A可能有多个节点，服务A、服务B和服务C的服务地址都不同，服务授权验证在哪里做？这时，就需要使用到服务网关提供统一的服务入口，最终形成典型微服务架构：

上面是一个典型的微服务架构，当然微服务的服务治理还涉及很多内容，比如：

1、通过熔断、限流等机制保证高可用；
2、微服务之间调用的负载均衡；
3、分布式事务（2PC、3PC、TCC、LCN等）；
4、服务调用链跟踪等等。

主流的微服务框架

目前国内企业使用的微服务框架主要是Spring Cloud和Dubbo（或者DubboX），Spring Cloud已经逐渐成为主流，比较两个框架的优劣势的文章在网上有很多，这里就不重复了，选择什么框架还是按业务需求来吧，业务框架决定技术框架。

Spring Cloud全家桶提供了各种各样的组件，基本可以覆盖微服务的服务治理的方方面面，以下列出了Spring Cloud一些常用组件：

最后的话

最近很多小伙伴找我要Linux学习资料，于是我翻箱倒柜，整理了一些优质资源，涵盖视频、电子书、PPT等共享给大家！

资料预览

给大家整理的视频资料：

给大家整理的电子书资料：

如果本文对你有帮助，欢迎点赞、收藏、转发给朋友，让我有持续创作的动力！

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以点击这里获取！

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。**

需要这份系统化的资料的朋友，可以点击这里获取！

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！