devops 框架,devops开发运维一体化定义
00-1010
单体架构
在了解DevOps和微服务之前，我们需要了解什么是单片应用/单片架构。简单来说，就像学校里的一些小项目一样，写项目的Demo。找一个服务器安装环境，然后远程加载jar包到服务器，然后运行它来服务。这时，进行简单的服务监控并不困难。如果项目出了问题，检查运行日志以了解哪个步骤出了问题。如果懂一些脚本，也可以写一些脚本分析日志，腾出手来监控服务器。这种单一架构采用瀑布式开发，服务流程为：设计-开发-测试-部署。
00-1010在微服务和DevOps出现之前，一个Web应用启动的时候，一般都是把所有的功能打包在一起，也就是都在一个项目包里，然后把项目打包在一个服务器上运行。当时的B/S应用架构是单一架构，结构图如下：
00-1010如果某个服务器因为用户访问量增加而无法支持，那么就需要添加服务器进行负载均衡。这时的架构形式是：单B/S负载均衡。
00-1010经过一段时间的负载均衡，发现通过CDN手段，静态文件可以独立，可以加快服务，提高应用速度，于是单一架构进一步演变为：B/S前端分离(CDN)
00-1010上面说的架构都是单个应用，只是部署形式的某些方面做了优化和改变，所以单个应用的通病到最后还是避免不了：
单体
1.代码量大，应用启动时间长。2.测试周期长，需要对所有业务进行回归测试来改bug。3.应用程序容错性差，某个程序出问题，整个项目业务就瘫痪了。4.可扩展性很难，只能扩展整个应用，浪费资源。5.很难发展合作。项目人员都在维护一套代码，所以协作周期长，难度大。
00-1010
单体架构是什么
DevOps:开发和运营的结合体，是一种重视“软件开发人员”和“IT运维技术人员”之间交流与合作的文化、运动或惯例。通过自动化“软件交付”和“架构变更”的过程，可以更快、更频繁、更可靠地构建、测试和发布软件。
00-1010上面提到的单体架构，业务流量越来越大，几台服务器不够用是肯定的。这时候就会增加很多服务器机器，Nignx、CDN、cache、message queue等技术栈。也将被添加。同时也会有更多的开发者。这时候就是多人多机协同开发的问题了。
00-1010这个时候大部分项目都会拆分，每个人负责专注开发一部分业务。敏捷开发的核心思想是，由于在超高的业务流下无法完全了解用户的真实需求是什么，所以它会不断拆解一个大的目标，将其变成小的可交付成果和项目，然后通过不断的迭代继续小步开发。
另外，这个时候项目非常大。为了保证工程质量，检测环节不能减少。为了加快开发效率，测试工作应与开发同步交替进行。需要从后面把测试环节注入到整个开发环节中，每一个可交付成果都是一个可用的功能集，这样开发交付的内容才能得到持续的验证。这样开发出来的产品可控性更强，项目成果可以定期测试。
00-1010年之前，机器很少有简单的架构，开发可以做运维工作。即使添加了几个服务器，也是一个脚本将jar包发布到这些机器上，这看起来相当简单。不过会有两个人同时在线部署被覆盖的问题，但这些都不是问题。只是同意错开上线部署的时间。
但如果从几千台服务器入手，就需要专门的运维人员进行维护项目，因为开发事业部的每个人都会专注于自己的业务，不会那么勤于维护。另一方面，运维的学习成本确实变高了，开发者素质参差不齐。如果服务器出了问题，那可不是小事。
不过这次也不是Dev Ops，而是DevOps，还没有整合。此时Ops的主要职责是：硬件维护、网络设备维护、DBA、基础服务维护、数据监控等。运维人员擅长写各种部署，监控脚本，减少机械的重复性工作，开发模式变成了敏捷开发模式。
这时的开发设计流程大致是这样的。
这里还没有介绍DevOps，但是我们要插入微服务来更好的解释DevOps是怎么理解的。
00-1010
单体B/S架构
微服务是一种软件架构。它基于专注于单一责任和功能的小构建块，并以模块化方式组合复杂的大规模应用程序。每个功能块使用语言独立/语言不可知的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一些常用组件：
DevOps+微服务：拆分解耦
了解完上述全部之后，假设当原本是单体架构的公司发展到非常大规模的时候，会有很多程序员、服务器等等，所以一个项目里面，什么语言、技术栈都会有，Java、Go、Python肯定是数不胜数的，所以，这个时候需要协调技术栈，并且项目后期肯定会变得非常大，全部都兑到一个项目里，最直接的后果就是项目变得很大，上线项目启动时间变长，一个BUG可能导致整个业务全线崩溃，最终的后果就是项目变得越来越难以维护，加一个改一个东西几乎搞不动，而且还越来越难重构。
所以，拆分解耦是最终的出路，将项目拆成一个个小的服务单独部署，以电商项目为例，将整个项目拆分为用户服务、商品服务、订单服务，积分服务、支付服务每个服务单独部署，之间通过互相调用的方式来交互，而且可以将一些基础服务例如上传图片，发送短信等很多服务都需要的基础服务，抽象到一个单独的整合服务，也就是之前所谓的中台服务。
拆分解耦演化催生DevOps
按照上述说的微服务架构进行开发DevOps的话，运维需要做的上线工作，主要就是将代码部署到对应的机器里面，微服务有那么多的服务，每个大点的公司几百个服务不算多，而且还可能随时搞一个服务出来，如果还按照原始的脚本部署方式，可能最后连是哪个脚本都找不到。而且，如果每个服务上线都需要运维来同意，开发会非常难受，需要天天找运维同意发布，运维也会增加繁琐的工作量。
所以，开始演化出远程部署一些机器，专门用来管理代码，进行上线工作，由运维事先把上线的规则都给定义好了，开发只要按照他的规则都访问这台服务器进行各自的代码合成和发布，自己上线呢，能用代码自动完成的事情就绝不要手动解决，这是每个开发人员都在想的东西。运维需要做的事情，慢慢的都沉淀到了各个平台上面，例如监控，有专门的监控组件和可视化，基础服务例如服务器，CDN，负载均衡等基础服务可以外包到云服务厂商，日志也有专门的日志工具，链路追踪也有专门的组件和可视化，还有网关等，渐渐的，只要这些都配置好了，开发也可以做运维的部分工作，毕竟开发才是最了解代码的人，哪里出了问题看看监控日志，可以最快速度定位到问题，于是DevOps开发模式诞生了，开发也是运维。
早期的DevOps，大部分指的都是开发运维一体化。
而现在的DevOps，概念上已经扩大到端到端的概念了。
实现DevOps：DevOps搭建工具
综上所示：DevOps 的三大支柱之中，即人（People）、流程（Process）和平台（Platform）。
项目管理（PM）：Jira。运营可以上去提问题，可以看到各个问题的完整的工作流，待解决未解决等；代码管理：Gitlab。jenkins或者K8S都可以集成gitlab，进行代码管理，上线，回滚等；持续集成CI（Continuous Integration）：gitlab ci。开发人员提交了新代码之后，立刻进行构建、（单元）测试。根据测试结果，我们可以确定新代码和原有代码能否正确地集成在一起。持续交付CD（Continuous Delivery）：gitlab cd。完成单元测试后，可以把代码部署到连接数据库的 Staging 环境中更多的测试。如果代码没有问题，可以继续手动部署到生产环境中。镜像仓库：VMware Harbor，私服nexus。容器：Docker。编排：K8S。服务治理：Consul。脚本语言：Python。日志管理：Cat+Sentry，还有种常用的是ELK。系统监控：Prometheus。负载均衡：Nginx。网关：Kong，zuul。链路追踪：Zipkin。产品和UI图：蓝湖。
参考文章：1、知乎：什么是DevOps？ 作者：小龙飞2、知乎：微服务入门 作者：未知
到此这篇关于深入理解DevOps+微服务的文章就介绍到这了,更多相关DevOps微服务内容请搜索盛行IT以前的文章或继续浏览下面的相关文章希望大家以后多多支持盛行IT！
郑重声明：本文由网友发布，不代表盛行IT的观点，版权归原作者所有，仅为传播更多信息之目的，如有侵权请联系，我们将第一时间修改或删除，多谢。