本文是有道科技CTO黎明在《云上运维与研发***实践》活动中的内容分享。本文结合微服务架构的特点，讲解如何搭建高效的运维管理平台。李明带领团队自主研发了全栈DevOps运维管理平台——EasyOps，是目前业界领先的智能运维管理平台。作为原腾讯运维研发负责人，黎明主导开发了多个运维系统、舆情监测、大数据监测平台、CMDB、实时日志分析平台、织云、客户端体验监测等.这篇文章的内容有三点：1、微服务架构的特点及其与传统单体架构的区别，以及传统运维工具面临的挑战；2、面向微服务的运维平台架构；3、运维平台的微服务演进。一、微服务架构和单体架构的区别“微服务”和“单体架构”不是对立的，而是针对不同场景的解决方案。Monolith架构是指将所有的“大脑”集合在一起，以CS架构为代表，将所有的逻辑放在一个应用程序中，然后添加前端UI组件、Service、MVC架构、数据库等部分。其技术架构不复杂，易于调试、部署和管理，是适用于大多数系统的解决方案。然而，在互联网要求“更多、更快、更好、更便宜”的应用场景下，“单体架构”面临诸多挑战。多：上网人数庞大，达到***在线；快：服务请求的响应速度应在一秒以内，甚至更快；good：服务质量的稳定性要高；经济的：硬件成本的增加应该低于用户数量的增加速度。如何解决这四个问题——增强整个平台的灵活性。平台扩展能力1、并行扩展：一般的无状态服务器可以通过服务器扩展进行并行扩展；2.分区：对于有状态的服务，可以通过分区来增强平台的灵活性，比如：南北用户分别属于A和B的不同集群。平台上扩展的“单体架构”可以适配，但扩展的功能适配难度较大。功能扩展能力在功能维度上，如何让系统更加和谐？1.灵活控制成本：局部调整，改变模块和逻辑，而不是修改整个系统。Monolith架构的所有模块都捆绑在一起。扩容时，由于每个模块体积庞大，只能并行扩容，成本高。微服务架构下模块产品的服务器分布非常灵活，扩容成本低。现在我们选择将服务端模块进行微服务化改造，提升平台支撑能力。2、如何搭建微服务架构下的运维管理平台。以上描述了微服务架构和单体架构的区别。接下来学习如何搭建运维管理平台。运维平台管理最重要的是应用。对于应用运维来说，系统前端对接的官网、中间逻辑服务、后端的存储和缓存属于不同的运维。将运维平台拆分为工作对应的三个具体组件。运维平台内部应用和内部依赖有哪些？——支撑运维平台作为互联网应用的程序、配置文件、计算资源有哪些？——内存和CPU运维平台依赖的资源有哪些？——系统镜像是CMDBIT资源管理系统必须承载的。当涉及到自动扩容和环境部署时，只有了解了这些数据，上层系统才能知道如何构建应用。很多运维团队只实现了“工具化”，而没有与“资源管理配置”挂钩。对资源进行有效管理之后，就是研发、运维等行动管理。如：版本更新、迁移服务、搭建测试环境等标准化动作。有了资源和动作之后，就实现了自动化运维的闭环。运维人员只需提前维护准确的资源配置数据（CMDB），其余的动作系统自行完成。如果资源和动作混合使用，资源每次使用都需要定制专门的发布脚本和构建脚本。除了资源和动作管理，还有状态（监控）管理。每个公司都会有一个“监控”系统。这里需要强调的是意识问题，因为在整个上层和应用层的监控设计中都考虑了“自动容灾切换”能力，所以我们不需要关注底层监控。只要应用层没有告警，底层服务器、机房是否宕机都无所谓。刚开始工作的时候，系统经常报警，半夜不得不起床重启机器，删除文件。现在运维只会收到一个通知，告诉服务器挂掉，确认一下，没有实时处理。按照这个逻辑，我们的系统在业务没有告警的情况下是正常的。一个完整的运维管理平台，可以对资源、动作、状态进行合理的协调和管理。这张图对上面的简单图进行了扩展和细分。顶部是运维统一运维入口，包括运维、开发者服务目录、日常任务中心、状态中心。下面是调度编排系统。根据不同的行业和业务特点，产品扩展提出不同的编排需求，并固化这些不同的需求选项。中间是运维平台的核心，执行层的系统。抛开灰色的传统API模块，我们现在在日常运维中使用持续交付平台、统一监控平台、ITOA运行分析平台这三个维度的监控体系，通过它来实现动作和状态的管理。针对基础设施、平台系统、应用层、服务层乃至更高层的需求，提供不同精度和优先级的接口。底层是CMDB资源管理。传统的CMDB管理对象属于硬件资产。云技术发展之后，会越来越弱。应用运维无需过多关注。这里CMDB包括业务信息管理、应用包、配置、计划任务、流程、工具、权限、系统配置等基础资源。3、运维平台的微服务演进伴随着公司业务的发展。如何优化或规划应用系统的架构？1、技术选型首先，微服务和基础设施的区别在于，微服务的组件是拆分出来的，通过网络传输。因此，通信标准应该做出合理的选择。微服务的架构通常是异构架构。比如我们的平台使用了Python、JAVA、PHP等语言，我们必须选择兼容多种语言的协议。就像我们之前选择protobuf的时候，发现Python自带的库还不够成熟，无法兼容Linux系统。在不同的场景下，微服务的技术选型需要有很强的兼容性。其次是语言的选择。微服务强调接口的稳定性，在保证服务稳定性的同时，可以自由选择熟悉的语言。2.微服务规划单一职责原则：每个服务应该负责单独的一部分功能。明确发布接口：每个服务都会发布一个定义良好的接口，并且保持不变。消费者只关心接口，对消费的服务没有操作依赖；独立部署、升级、扩展和替换：每个服务都可以独立部署和重新部署，而不影响整个系统，这使得服务易于升级和扩展。3.平台建设平台架构通过以下两个模块进行说明。1）如何对CMDB系统进行简单的拆分，使其更易于维护？CMDB是一个数据库管理系统，可以查询和修改大量的配置系统。它包括模型管理、配置管理和自动发现。a)模型管理在CMDB中，我们会管理大量随着产品技术站的演进而动态变化的资源和不同的动作，因此我们需要将模型管理模块分离出来，以保证CMDB可以动态调整。B)配置管理由于CMDB信息的高度敏感性，很多公司要求将敏感的业务信息，特别是与应用程序和IP相关的信息存储在其中。C)自动发现如果CMDB没有完善的自动发现机制，它失败的概率会很高。就像传统的CMDB在严格的审批机制下有一个配置变更流程。但是，即使配置与现网一致，仍然需要每六个月进行一次资产整合，对信息进行更正。对于一个海量业务的系统，没有“自动发现”能力的CMDB是不合格的。通过“自动发现”，服务器带宽、网卡速度、内存、磁盘空间、进程等信息由CMDB自动收集和管理。模块管理相对传统，“自动发现”是CMDB的核心。当同时管理数十万台服务器时，只能通过“自动发现”的检测来进行自动维护。2）持续部署系统持续部署系统负责自动化发布。上图将持续部署系统的平台搭建分为多个子模块。A)构建管理构建是指部署对象，主要包括静态图片、业务程序、配置文件。根据DevOps中的原则，一切都需要进行版本控制。所以需要一个构建库来管理所有发布到生产环境的资源。通过统一的建库，对所有发布到在线网络的数据进行标准化管理，使原有系统在其他机房快速重建。同时，它还具有信息共享功能。过去，运维合同签发后很难追踪。现在研发人员只需要将版本信息输入构建库，运维就可以从构建库中导出。b)任务管理任务库，负责存放日常发布任务，满足自动化发布的需要。以往，很多研发人员出于方便的考虑，会选择直接在现网修改系统。记录信息的混乱变化不利于任务管理的日常分配。经常出错，所以我们不采用“任务下发后，系统设置自动更新”的设计。当上层管理系统不可信任时，需要对现网信息和数据进行实时扫描和上报。为保证信息发布的顺利进行，必须以代理人上报的信息为准。由于配置信息中存在大量的变更条目，系统设计时不能保证条目唯一。命令通道和数据通道是上层系统除构建库、任务库、实例库外的基本组成部分。首先，命令通道和数据通道需要分开管理。腾讯曾经需要向2000台服务器发送1G文件，一周一次，一周一次，不断重试失败。后来命令和数据分离了，每次只传输几十K的命令脚本，服务器就不再堵了。开源解决方案中的一些问题仍然无法解决。与目前的异构网络一样，在混合云场景下，必须保证网络的互通性，才能实现直连。可以选择自己编写Agent，通过反向通道连接到中央管理服务器来解决这个问题。微服务架构下平台架构底层基础服务1.名称服务名称服务是指通过配置文件中的匹配名称查找IP端口的服务，可以选择合适的开源方案。如果自研，可以灵活划分业务。比如深圳的服务器A访问B，B在深圳和上海都部署，我们只需要在名称服务中连接CMDB，使用深圳的服务器访问深圳的IP即可实现同城访问影响。该操作在开源方案中无法完全实现。2、状态监控需要应用层监控可以到达接口，即调用数据采集。通过访问量、成功率、平均延迟这三个核心指标，可以低成本地抓住大部分需求。以访问量为例，当访问失败率上升并触发告警时，直接触发名称服务联动，自动移除故障节点。3、负载均衡当系统规模扩大，节点数量激增时，增加中间代理的方法会增加系统内部压力。如果登陆Agent，通过名称服务查询IP列表，合并状态信息，均衡节点请求，可以更好的实现负载均衡。负载平衡的极端是灾难恢复。一般情况下，保证每个节点根据性能状态处理适量的请求即可。这三点是运维平台或业务生产系统中的核心能力。包括腾讯在内的运维平台都是基于这三项服务闭环运作的。只有做到这三点，才能解决系统异常，维持系统正常运行。微服务运维平台的迭代重点其实我们在搭建平台的时候，在整个平台演进的过程中，其实是要有轻重缓急，有取舍的。一般来说，优先解决我们的瓶颈问题。然后是并行扩展的能力，以及考虑服务复用的能力，甚至是一些开源方案的利用。但是开源，我从来不认为是大家可以把一堆开源工具一起使用，组成一个很好的运维平台。你应该使用这些开源能力，这些单独的微服务，核心架构在这里必须有你自己的控制权。例如：监控。很多开源系统都是比较侧重于执行层的工具，但是核心的CMDB和核心的流程控制还是需要我们去构建。本文转载自雷锋网。如需转载，请在雷锋网官网申请授权。
