运维体系框架标准化模型简介
为什么要做标准化？
标准化的过程实际上就是对运维对象的识别和建模过程。形成统⼀的对象模型后，各⽅在统⼀的认识下展开有效协作，然后针对不同的运维对象，再抽取出它们所对应的运维场景，接下来才是运维场景的⾃动化实现。
这有点像我们学的⾯向对象编程的思想，其实我们就是需要遵循这样⼀个思路，我们⾯对的就是⼀个个实体和逻辑运维对象。
在标准化的过程中，先识别出各个运维对象，然后我们⽇常做的所有运维⼯作，都应该是针对这些对象的运维。如果运维操作脱离了对象，那就没有任何意义。同样，没有理清楚对象，运维⾃然不得章法。
⽐如我们说扩容，那就要先确定这⾥到底是服务器的扩容，还是应⽤的扩容，还是其它对象的扩容。你会发现，对象不同，扩容这个场景所实施的动作是完全不⼀样的。
如果把服务器的扩容套⽤到应⽤的扩容上去，必然会导致流程错乱。同时对于对象理解上的不⼀致，也会徒增⽆谓的沟通成本，造成效率低下。⾃然地，这种情况下的运维⾃动化不但不能提升效率，还会越⾃动越混乱。
这就是为什么我每次都会连续强调三遍“标准先⾏”的原因。虽然这个事情⽐较枯燥和繁琐，但是于纷繁复杂中抽象出标准规范的东西，是我们后续⼀系列⾃动化和稳定性保障的基础。万丈⾼楼平地起，所以请你⼀定不要忽略这个⼯作。
好，总结⼀下标准化的套路：
第⼀步，识别对象；
第⼆步，识别对象属性；
第三步，识别对象关系；
第四步，识别对象场景。
接下来我们就按照上⾯这个思路，⼀起来分析从基础设施层⾯和应⽤层⾯应该识别出哪些运维对象。
基础设施层⾯的标准化
基础设施层⾯的运维对象应该不难识别，因为都是⼀个个物理存在的实体，我们可以进⾏如下分析。
第⼀步，识别实体对象，主要有服务器、⽹络、IDC、机柜、存储、配件等。
第⼆步，识别对象的属性，⽐如服务器就会有 SN 序列号、IP 地址、⼚商、硬件配置（如 CPU、内存、硬盘、⽹卡、PCIE、BIOS）、维保信息等；⽹络设备如交换机也会有⼚商、型号、带宽等信息。
第三步，识别对象之间的关联关系，⽐如服务器所在的机柜，虚拟机所在的宿主机、机柜所在 IDC 等简单关系；复杂⼀点就会有核⼼交换机、汇聚交换机、接⼊交换机以及机柜和服务器之间的级联关系等，这些相对复杂⼀些，也就是我们常说的⽹络拓扑关系。
把以上信息梳理清楚，通过 ER 建模⼯具进⾏数据建模，再将以上的信息固化到 DB 中，⼀个资源层⾯的信息管理平台就基本成型了。
以服务器为例简单展⽰⼀下，我们的视⾓就是下⾯这样的：
spring系列框架有哪些
但是，信息固化不是⽬的，也没有价值，只有信息动态流转起来才有价值。接下来我们需要做的事情，就是识别出针对运维对象所实施的⽇常运维操作有哪些，也就是识别出运维场景是什么。
第四步，还是以服务器为例，我们针对服务器的⽇常操作有采购、⼊库、安装、配置、上线、下线、维修等等。另外，可能还会有可视化和查询的场景，如拓扑关系的可视化和动态展⽰，交换机与服务器之间的级联关系、状态（正常 or 故障）的展⽰等，这样可以很直观地关注到资源节点的状态。
完成了这些⼯作，接下来才是对上述运维场景的⾃动化开发。所以你看，在真正执⾏去做⼯具和⾃动化平台之前，其实是需要先做好⼤量的基础准备⼯作的。我要再次强调这⼀点，⼀定不能忽视。
应⽤层⾯的标准化
下⾯我们再⼀起看⼀个逻辑上的对象，就是我们前⾯经常提到的运维的核⼼：应⽤。对这个逻辑对象的建模会相对复杂⼀些，不过我们依然可以按照上⾯的套路来。
第⼀步，识别对象。
我们前⾯讲过，这个识别过程是在做微服务架构设计或拆分的时候就确定下来的。所以严格地讲，它不应该是运维阶段才被识别出来的，⽽是在之前设计阶段就被识别和确认下来，然后延伸到运维这⾥才对。
第⼆步，识别对象属性。
⼀个应⽤是业务的抽象逻辑，所以会有业务和运维两个维度的属性。业务属性在业务架构时确定，这主要是需要业务架构师去识别的，但是它的运维属性就应该由运维来识别了。
下⾯我们⼀起来看⼀下，⼀个应⽤应该具备哪些基本的运维属性。
* 应⽤的元数据属性，也就是简单直接地描述⼀个应⽤的信息，如应⽤名、应⽤ Owner、所属业务、是否核⼼链路应⽤以及应⽤功能说明等，这⾥的关键是应⽤名；
* 应⽤代码属性，主要是编程语⾔及版本（决定了后续的构建⽅式），GitLab 地址；
* 应⽤部署模式，涉及到基础软件包，如语⾔包 Java、C++、Go 等；容器如 Tomcat、JBoss 等；
* 应⽤⽬录信息，如运维脚本⽬录、⽇志⽬录、应⽤包⽬录、临时⽬录等；
* 应⽤运⾏脚本，如启停脚本、健康监测脚本；
* 应⽤运⾏时的参数配置，如运⾏端⼝、Java 的 JVM 参数 GC ⽅式、新⽣代、⽼⽣代、永⽣代的堆内存⼤⼩配置等。
从应⽤属性的视⾓，应该是下⾯这样⼀个视图（简单⽰例，不完整）：
第三步，识别对象关系。
也就是应⽤与外部的关系，概括起来有三⼤类：
第⼀类是应⽤与基础设施的关系，包括应⽤与资源、应⽤与 VIP、应⽤与 DNS 等等的关系；
第⼆类是平⾏层⾯的应⽤与应⽤之间的关系，这⾥再细分下去就是应⽤服务或 API 与其它应⽤服务和 API 的依赖关系。如果你有相关的经验，应该会联想到全链路这样的⼯具平台了，没错，这样的平台就是⽤来处理应⽤间关系管理的。
第三类是应⽤与各类基础组件之间的关系，⽐如应⽤与缓存，应⽤与消息、应⽤与 DB 等等之间的关系。
第四步，识别应⽤的运维场景。
这个就会⽐较多了，⽐如应⽤创建、持续集成、持续发布、扩容、缩容、监控等；再复杂点的⽐如容量评估、压测、限流降级等。
好，这⾥我们先收⼀下，聚焦到标准化的层⾯，通过基础设施和应⽤层⾯标准化的⽰例，我想你应该可以掌握基本的建模思路了，这样的思路可以应⽤到其它的运维对象上 。
同时，通过上⾯这些内容，你应该可以⽐较清晰地看到，我们的每⼀个运维操作都是针对某个运维对象的，这⼀点在规划运维体系时⾮常重要。
⽽在这些对象中，应⽤⼜是重中之重，是微服务架构下的核⼼运维对象。
从应⽤标准化的过程中我们也可以看到，针对应⽤的识别和建模，明显复杂很多。所以，后⾯我还会从理论和实践的⾓度来继续强化和分析这个概念。
今天，我继续跟你聊基础架构标准化的问题，但是今天我计划不谈如何进⾏架构标准化的细节，⽽是想强调⼀下基础架构标准化的重要性，因为从我个⼈的经历和我实际观察到的情况来看，这块的问题会更普遍⼀些，⽽这⼀部分⼜影响着后续⼀系列效率和稳定性平台的建设⽅案。
同时，如果说上次我们讲的基础设施和应⽤标准化是运维团队职责的话，那今天的内容就是架构、开发和运维共同的职责。
常见的分布式基础架构组件
让我们先⼀起列⼀下，微服务的分布式架构下，涉及到的主要基础架构组件有哪些。
上⾯是⼏类主要的基础架构组件，为了便于理解我以开源产品举例。但在实际场景中，很多公司为了满⾜业务上的个性化需求，会⾃⼰研发⼀些基础组件，⽐如服务化框架、消息中间件等，这个情况在有⼀定技术实⼒的公司⾥⽐较常见。不过⼤部分情况下，我们会基于这些开源产品做⼀些封装或局部的改造，以适应我们的业务。
基础架构组件的选型问题
关于基础架构组件，业界可供我们选择的解决⽅案和产品是⾮常多的，但是选择多了就容易挑花眼，反⽽不知道从何⼊⼿。我们⼤概都会遇到同样的问题，是⾃研还是选择开源产品？有这么多的开源产品到底该选哪⼀个？
按正常的思路，⼀定是先组织选型调研，然后进⾏⽅案验证和对⽐，最后确认统⼀的解决⽅案。
但是，由于开源产品的便利性，以及开发同学对技术探索的好奇⼼，实际情况往往是，整个⼤的技术团队中，不同的开发团队，甚⾄不同的开发⼈员，会根据开发的需要或个⼈喜好，选择不同的开源产品，在没有严格限制的情况下，甚⾄会尝试去⾃研。
按照我的观察，这个问题特别容易出现在微服务架构引⼊初期。在这个阶段，团队组织架构按照业务领域进⾏切分，产⽣⼀个个与业务架构匹配的⼩规模技术团队。每个⼩团队所负责的业务相对独⽴，⾃主权就会变⼤，如果这个时候整个团队中没有⼀个强有⼒的架构师⾓⾊去做端到端的约束，就极其容易出现上⾯的这个问题，并且会⼀直扩散蔓延下去。
相⽐之下，成规模的⼤公司在这⼀点上做得就相对严格⼀些，当然也可能是因为之前尝过苦头，所以后来变得越来越规范了。所以这⼀点也是每个技术团队在引⼊微服务架构时要提前关注的。
我们以分布式服务化框架为例，我之前遇到的⼀个实际情况就是，整个⼤的技术团队选型时以Java技术栈为主，毕竟这块有很多的业界经验和产品可以借鉴参考。但是有的团队对PHP特别精通熟悉，就想⽤PHP去做微服务，有的团队对Go感兴趣，就想尝试Go的微服务。
从单纯的技术选型上来看，选择什么语⾔并没有严格的标准。⽽且在技术团队中，我们也应该⿎励技术多样性和尝试新技术。不过这⾥要有个度，我暂时先不细说这个度在哪⾥，我们先来看看，假设没有统⼀标准的约束会带来什么问题。
技术的应⽤，⼀般都会随着应⽤场景的逐步深⼊和业务体量的增长，逐步暴露出各种各样的问题，我们分两个层⾯来看。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。