浅谈 DevOps 框架
希望打开这篇能对你有所帮助。
这两天如果有关注我的朋友应该会发现，好像缓更了哈。其实不然，让我们透过现象看本质。你们打开我置顶的那一篇，我对以往的博客做了很大的整合与优化，优化完都放那篇《导航》里面去了。
文章目录
什么是 DevOps 框架？
本定义来自《百度百科》，包括文中的图。（这没什么不好意思的哈，我一直认为，学习一样东西，最难的一步在于知道要学这个东西。我这一个part的价值就在于帮大家把百度百科上的东西搬到你们面前，如果搬到脑子里那就更好了）
DevOps （过程、方法与系统的统称）
它是一种重视“软件开发人员（Dev）”和“IT运维技术人员（Ops）”之间沟通合作的文化、运动或惯例。透过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。
架构演变过程
1、单体架构。
在项目初期，为了产品快速上线、快速验证，架构是比较简单直接的，就是单体架构，如下图：
就我以前画的哪些，勉强能够得上吧。
这儿就不用别人的图了，献丑了。
单体架构快速了实现了产品的核心功能，可以提供给种子用户快速验证。但是随着业务的扩大，渐渐的问题就会暴露出来了。
业务服务和基础功能服务需要解耦（我处理好了的）
业务服务中有不少长耗时的任务，这些都影响了业务服务的横向扩展，长耗时任务也必须从业务服务解耦（我上一个项目就处理了这个）
应用服务和基础服务拆分后，也需要机制保障通信（这个我，后面有）
服务必须可扩展（这个我前一个项目就做了）
一旦大范围使用，单点服务不足以应对，一定要集群（这个我，后面有）架构演进五条原则
确定当前的架构现状：每次架构演进，一定是针对当前架构的，所以必须非常清楚当前的架构现状和问题。
确定重构的目的和必要性：架构重构的原因是什么？除了架构重构之外，是否有别的备选方案？
定义“重构完成”的标准：为每一次架构演进定义清晰的重构目标和成功标尺。
渐进式重构：为每一个模块配备基准测试。最好在模块开发前先把测试脚本开发好，至少文档要先出，如果让我带团队的话。
远离虚的东西：例如使用热门的技术，使用不成熟的技术。要脚踏实地，根据实际需要以及团队的技术背景，合理的选择重构方案。2、集群架构 emmm，我这个图要结合前面那张图来看。
第一次画集群架构，没什么经验，不要笑哈。
再看看人家的吧，对比一下：
各有千秋哈。
实现了集群架构以后，服务的能力，稳定性和可靠性都上了一个台阶，但是随着用户的使用越来越深入，平台提供的服务越来越多，集群架构的问题也逐步开始显现：
平台提供的服务能力越来越多，业务越来越复杂
简单的说，一个服务dump了，集群全都有可能挂了，因为集群上的每台机子都有这个服务。
平台服务要提供集成与被集成的能力，与其他的CI服务集成，与测试平台集成
平台要与其他产品打通 - 与运维产品打通，获取客户运维数据，做到DevOps闭环，通过反馈和运维数据反向推动产品持续迭代改进
平台要对外开放，面向生态合作伙伴提供服务能力，对外开放，第一步就是要让用户能进来，这就涉及到整个用户中心体系的建立，用户管理、统一身份认证等。
虽然集群架构已大大提高了可靠性和可用性，但是随着服务的深入使用和用户规模的不断增长，对可靠性和可用性的要求也越来越高，对平台服务以及服务资源的运维也变得越来越重要和紧迫面对上述问题，需要对服务进行拆分，治理，提供服务和资源的运维、监控能力，而都需要架构
3、微服务架构
那微服务我还没体验过，就没自己的图了。
微服务架构的特点如下：
提炼CI引擎，丰富集成能力
服务按领域拆分，提供服务治理能力
服务运维能力，提供监控、告警、统计分析
提供日志服务，便于错误分析和运营分析
提供统一的容器云服务， 提供高可用、可伸缩的容器应用管理从来没有一个完美的架构能够一直支撑业务的发展，架构是动态的、变化的，随着业务的发展不断演进的，不同的阶段需要不同的架构 。
什么是 DevOps？
所以，说了这么多，到底什么是 DevOps？
想要将DevOps真正落地，首先第一点，是思维转变。
在DevOps的流程下，运维人员会在项目开发期间就介入到开发过程中，了解开发人员使用的系统架构和技术路线，从而制定适当的运维方案。而开发人员也会在运维的初期参与到系统部署中，并提供系统部署的优化建议。 （是不是这样：我第一次开始带团队的时候，团队就由一个服务端、两个客户端、一个测试人员组成）
（哦，我们那个式敏捷开发啊）
腾讯云开发者
