DevOps

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

单体架构+瀑布模式

单体应用架构为 LNMP，这个时候只有 DEV 没有 OPS，DEV 就是全栈，就跟我们上大学玩的 demo 一样，项目开发好，找台服务器安装好环境，把 jar 包 scp 到远程服务器，放上去开启服务就可以。

这个时候服务监控也简单，服务出了问题，直接去线上看一下运行日志，为了解放双手监控服务，开发者会写一些脚本分析日志，服务器少，部署简单，通常开发就可以完成运维的工作，不需要专门的运维来做部署，所以开发模式很简答，直接按照瀑布流方式开发就可。

分体架构+敏捷开发

随着业务量越来越大,一台机器扛不住那么就需要加机器,单机变多机器,业务架构也开始加入了nginx,cdn缓存等通用基础服务,业务变多肯定会招人,涉及到多人开发协同,多人多机器模式

先说说多人协同开发问题，人员一多，为了更好的分工，大多会将项目进行拆分，每个人负责专注于一部分，有点包干到户的感觉，敏捷开发的核心理念就是既然我们无法充分了解用户的真实需求是怎样的，将一个大的目标不断拆解，把它变成一个个可交付的小目标，然后通过不断迭代，以小步快跑的方式持续开发。。另外，一个项目是很大的，为了保证项目质量，测试环节不可减少，为了加快速度增大开发效率，QA的工作最好是和开发同步交替进行的，需要将测试环节从后面注入到整个开发环节当中，每次可交付的都是一个可用的功能集合，对开发交付的内容进行持续验证。这样开发产品的可控性也更强，遇到了sb甲方的时候，阶段性的让他检验一下项目成果，防止画鸡成鸭。

再说说多机器问题，之前机器很少架构简单的时候，开发就可以干运维的活，就算加了几台服务器，那也是脚本将 JAR 包同时发布到这些机器上，好像也挺简单，但是会有两个人同时上线部署被覆盖的问题，所以大家在上线之前可能会去群里吆喝一声，”我要上线了，大家先别上线哈“，可想而知这样效率也很低下。

公司业务一大，像大公司的动不动就是几千台服务器，就需要专门的运维介入了，一方面是因为开发分工每个人都专注于自己的事情，不会那么用心进行维护，另一方面是运维的学习成本确实变高了，开发人质量参差不齐，服务器要是每个人都可以上估计领导每天晚上都要做噩梦。但是这个时候也不是 DEVOPS，而是 DEV+OPS，这时 Ops 的主要职责就是：硬件维护、网络设备维护、DBA 、基础服务维护、数据监控等，运维们擅长写各种部署，监控脚本，减少机械的重复工作，开发模式变成了敏捷开发模式。

开发和运维角色的天生对立问题：

加入运维，就要协调人员配合，运维的宿命就是维稳，他们是很讨厌变动的；开发的天职确是不断地推代码上线，进行代码变动，更替迭代，这两个工种天生就是对立的。

很多大公司有那种，开发人员想要上线，需要提交各种审批，层层签字画押，多少人的上线激情被一句冷冰冰的‘还没到窗口发布期’给泼的透心凉。所以，敏捷开发解决了协同开发和多机器部署开发问题，但是没有解决内部人员的矛盾，留着这个矛盾在公司，开发和运维随时都可能约‘生死架’。

微服务架构+DEVOPS

第一，公司发展到BAT这种体量，会招很多人，JAVA，PHP，GO 技术栈都会有，需要协调技术栈；第二，项目到后期往往会变得很大，全部都兑到一个项目里，最直接的后果就是项目变得很大，上线项目启动时间变长，一个BUG可能导致整个业务全线崩溃，最终的后果就是项目变得越来越难以维护，加一个改一个东西几乎搞不动，而且还越来越难重构，牵一发而动全身

所以，拆分解耦是最终的出路，将项目拆成一个个小的服务单独部署，以电商项目为例如图，将整个项目拆分为用户服务，商品服务，订单服务，积分服务......每个服务单独部署，之间通过互相调用的方式来交互，而且可以将一些基础服务例如上传图片，发送短信等很多服务都需要的基础东西，抽象到一个单独的服务，也就是前些年鼓吹的很厉害的‘中台服务’。

拆分部署催生出DEVOPS 再看看这种架构下的开发模式DEVOPS，运维需要做的上线工作，主要就是将代码部署到对应的机器里面，微服务有那么多的服务，每个大点的公司几百个服务不算多，而且还可能随时搞一个服务出来，如果还按照原始的脚本部署方式，可能最后连是哪个脚本都找不到。而且，如果每个服务上线都需要运维来同意，开发也太卑微了，估计要天天求着运维同意发布，运维也会烦不胜烦。

那么为何不能再远程部署一些机器，专门用来管理代码，进行上线工作，由运维事先把上线的规则都给定义好了，开发只要按照他的规则都访问这台服务器进行各自的代码合成和发布，自己上线呢，能用代码自动完成的事情就绝不要手动解决，这是每个开发人员都在想的东西。运维需要做的事情，慢慢的都沉淀到了各个平台上面，例如监控，有专门的监控组件和可视化，基础服务例如服务器，CDN，负载均衡等基础服务可以外包到云服务厂商，日志也有专门的日志工具，链路追踪也有专门的组件和可视化，还有网关等，渐渐的，只要这些都配置好了，开发也可以做运维的部分工作，毕竟开发才是最了解代码的人，哪里出了问题看看监控日志，可以最快速度定位到问题，于是DEVOPS开发模式诞生了，开发也是运维。

作者：小龙飞
链接：https://www.zhihu.com/question/58702398/answer/1755254160
来源：知乎

K8S

前言

k8s全称kubernetes，这个名字大家应该都不陌生，k8s是为容器服务而生的一个可移植容器的编排管理工具，越来越多的公司正在拥抱k8s，并且当前k8s已经主导了云业务流程，推动了微服务架构等热门技术的普及和落地，正在如火如荼的发展。那么称霸容器领域的k8s究竟是有什么魔力呢？

首先，我们从容器技术谈起，在容器技术之前，大家开发用虚拟机比较多，比如vmware和openstack，我们可以使用虚拟机在我们的操作系统中模拟出多台子电脑（Linux），子电脑之间是相互隔离的，但是虚拟机对于开发和运维人员而言，存在启动慢，占用空间大，不易迁移的缺点。举一个我亲身经历过的场景吧，之前在vmware中开发了一个线下平台，为了保证每次能够顺利使用，我们就把这个虚拟机导出为OVF，然后随身携带，用的时候在服务器中部署，这里就充分体现了虚拟机的缺点。

接着，容器化技术应运而生，它不需要虚拟出整个操作系统，只需要虚拟一个小规模的环境即可，而且启动速度很快，除了运行其中应用以外，基本不消耗额外的系统资源。Docker是应用最为广泛的容器技术，通过打包镜像，启动容器来创建一个服务。但是随着应用越来越复杂，容器的数量也越来越多，由此衍生了管理运维容器的重大问题，而且随着云计算的发展，云端最大的挑战，容器在漂移。在此业务驱动下，k8s问世，提出了一套全新的基于容器技术的分布式架构领先方案，在整个容器技术领域的发展是一个重大突破与创新。

那么，K8S实现了什么？

就在Docker容器技术被炒得热火朝天之时，大家发现，如果想要将Docker应用于具体的业务实现，是存在困难的——编排、管理和调度等各个方面，都不容易。于是，人们迫切需要一套管理系统，对Docker及容器进行更高级更灵活的管理。

简介

K8s系统通常称为一个K8s集群,这个集群主要包括俩个部分,一个master和一群node节点

一看就明白：Master节点主要还是负责管理和控制。Node节点是工作负载节点，里面是具体的容器。

Master节点包括API Server、Scheduler、Controller manager、etcd。

API Server是整个系统的对外接口，供客户端和其它组件调用，相当于“营业厅”。

Scheduler负责对集群内部的资源进行调度，相当于“调度室”。

Controller manager负责管理控制器，相当于“大总管”。

然后是Node节点。

Node节点包括Docker、kubelet、kube-proxy、Fluentd、kube-dns（可选），还有就是Pod。

Pod是Kubernetes最基本的操作单元。一个Pod代表着集群中运行的一个进程，它内部封装了一个或多个紧密相关的容器。除了Pod之外，K8S还有一个Service的概念，一个Service可以看作一组提供相同服务的Pod的对外访问接口。这段不太好理解，跳过吧。

Docker，不用说了，创建容器的。

Kubelet，主要负责监视指派到它所在Node上的Pod，包括创建、修改、监控、删除等。

Kube-proxy，主要负责为Pod对象提供代理。

Fluentd，主要负责日志收集、存储与查询。