浅谈 DevOps 框架

希望打开这篇能对你有所帮助。

这两天如果有关注我的朋友应该会发现，好像缓更了哈。其实不然，让我们透过现象看本质。你们打开我置顶的那一篇，我对以往的博客做了很大的整合与优化，优化完都放那篇《导航》里面去了。

@[toc]

什么是 DevOps 框架？

==本定义来自《百度百科》，包括文中的图==。（这没什么不好意思的哈，我一直认为，学习一样东西，最难的一步在于知道要学这个东西。我这一个part的价值就在于帮大家把百度百科上的东西搬到你们面前，如果搬到脑子里那就更好了）

DevOps （过程、方法与系统的统称）

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

架构演变过程

1、单体架构。

在项目初期，为了产品快速上线、快速验证，架构是比较简单直接的，就是单体架构，如下图：

就我以前画的哪些，勉强能够得上吧。

这儿就不用别人的图了，献丑了。

单体架构快速了实现了产品的核心功能，可以提供给种子用户快速验证。但是随着业务的扩大，渐渐的问题就会暴露出来了。

业务服务和基础功能服务需要解耦（我处理好了的）
业务服务中有不少长耗时的任务，这些都影响了业务服务的横向扩展，长耗时任务也必须从业务服务解耦（我上一个项目就处理了这个）
应用服务和基础服务拆分后，也需要机制保障通信（这个我，后面有）
服务必须可扩展（这个我前一个项目就做了）
一旦大范围使用，单点服务不足以应对，一定要集群（这个我，后面有）

架构演进五条原则

确定当前的架构现状：每次架构演进，一定是针对当前架构的，所以必须非常清楚当前的架构现状和问题。
确定重构的目的和必要性：架构重构的原因是什么？除了架构重构之外，是否有别的备选方案？
定义“重构完成”的标准：为每一次架构演进定义清晰的重构目标和成功标尺。
渐进式重构：为每一个模块配备基准测试。最好在模块开发前先把测试脚本开发好，至少文档要先出，如果让我带团队的话。
远离虚的东西：例如使用热门的技术，使用不成熟的技术。要脚踏实地，根据实际需要以及团队的技术背景，合理的选择重构方案。

2、集群架构
emmm，我这个图要结合前面那张图来看。

第一次画集群架构，没什么经验，不要笑哈。

再看看人家的吧，对比一下：

各有千秋哈。

实现了集群架构以后，服务的能力，稳定性和可靠性都上了一个台阶，但是随着用户的使用越来越深入，平台提供的服务越来越多，集群架构的问题也逐步开始显现：

平台提供的服务能力越来越多，业务越来越复杂
简单的说，一个服务dump了，集群全都有可能挂了，因为集群上的每台机子都有这个服务。
平台服务要提供集成与被集成的能力，与其他的CI服务集成，与测试平台集成
平台要与其他产品打通 - 与运维产品打通，获取客户运维数据，做到DevOps闭环，通过反馈和运维数据反向推动产品持续迭代改进
平台要对外开放，面向生态合作伙伴提供服务能力，对外开放，第一步就是要让用户能进来，这就涉及到整个用户中心体系的建立，用户管理、统一身份认证等。
虽然集群架构已大大提高了可靠性和可用性，但是随着服务的深入使用和用户规模的不断增长，对可靠性和可用性的要求也越来越高，对平台服务以及服务资源的运维也变得越来越重要和紧迫

面对上述问题，需要对服务进行拆分，治理，提供服务和资源的运维、监控能力，而都需要架构

3、微服务架构

那微服务我还没体验过，就没自己的图了。

微服务架构的特点如下：

提炼CI引擎，丰富集成能力
服务按领域拆分，提供服务治理能力
服务运维能力，提供监控、告警、统计分析
提供日志服务，便于错误分析和运营分析
提供统一的容器云服务， 提供高可用、可伸缩的容器应用管理

从来没有一个完美的架构能够一直支撑业务的发展，架构是动态的、变化的，随着业务的发展不断演进的，不同的阶段需要不同的架构 。

什么是 DevOps？

所以，说了这么多，到底什么是 DevOps？

想要将DevOps真正落地，首先第一点，是思维转变。

在DevOps的流程下，运维人员会在项目开发期间就介入到开发过程中，了解开发人员使用的系统架构和技术路线，从而制定适当的运维方案。而开发人员也会在运维的初期参与到系统部署中，并提供系统部署的优化建议。
（是不是这样：我第一次开始带团队的时候，团队就由一个服务端、两个客户端、一个测试人员组成）

（哦，我们那个式敏捷开发啊）