您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码:  验证码,看不清楚?请点击刷新验证码 必填



  求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Model Center   Code  
会员   
   
 
     
   
 订阅
  捐助
微服务架构下的运维平台构建
 
作者: 黎明
  672  次浏览      51
 2020-1-9
 
编辑推荐:
本文主要包含微服务架构与巨石架构的差异、微服务架构下如何构建一个运维管理平台,运维平台的微服务进化,微服务架构下平台架构的底层基础服务,希望对您的学习有所帮助。
本文来自于又拍云,由火龙果软件Delores编辑、推荐。

一、微服务架构与巨石架构的差异

“微服务”与“巨石架构”两者并非对立,而是分别针对不同场景的解决方案。

巨石架构指将所有“大脑”集中在一起,以 CS 架构为代表,将所有的逻辑放在唯一应用中,再加入前端 UI 组件、Service、MVC 架构、数据库等部分。它的技术架构不复杂,调试、部署、管理方便,是适用于绝大部分系统的解决方案。

但是在互联网要求“多、快、好、省”的应用场景下,“巨石架构”面临诸多挑战。

多:互联网用户量巨大,达百万级在线量;

快:服务请求反应速度要在一秒以内甚至更快;

好:服务质量稳定性要高;

省:硬件成本增长要低于用户量增长速度。

如何解决这四个问题——增强整个平台的灵活性。

平台扩展能力

1.平行扩展:一般的无状态服务器可以通过服务器扩容完成平行扩展;

2.分区:对于有状态的服务可以通过分区增强平台灵活性,如:南北方用户分属 A、B 不同集群。

平台上的扩展“巨石架构”可以适应,但是功能上的扩展却比较难适应。

功能扩展能力

功能维度上,如何使系统变得更融洽?

1.灵活控制成本:局部调整,变更模块、逻辑,而不是修改整个系统。

巨石架构的所有模块都捆绑在一起,进行扩展时,由于每个模块巨大,只能高成本平行整体扩容。

微服务架构下模块产品的服务器分布非常灵活,扩容成本低,现在都会选择将服务器模块切分,进行微服务化改造,提升平台支撑能力。

二、微服务架构下如何构建一个运维管理平台

运维平台管理最重要的是运用。对于应用运维来说,系统的前端所接入的官网、中间的逻辑服务,后端的存储、缓存,分属于不同的运维。

把运维平台拆分成三块具体化部件对应到工作中。

运维平台的内部应用、内部依赖是什么?——程序、配置文件、计算的资源

是什么支撑运维平台作为一个互联网应用?——内存、CPU

运维平台依赖的资源有哪些?——系统镜像

这是 CMDB IT 资源管理系统所要承载的,在自动化扩容、环境部署时,只有了解这些数据,上层系统才能知道如何构建这个应用。

很多运维团队,仅仅做到“工具化”,却没有跟“资源管理配置”联动起来。

资源有效管理之后,是研发、运维这类的动作管理,如版本更新,迁移服务、搭建测试环境等标准化的动作。

在拥有资源和动作,达成自动化运维的闭环后。运维人员只需事前维护好准确的资源配置数据(CMDB),余下动作系统会自驱完成。如果把资源跟动作相混杂,每次运用都需要耗费资源定制专用的发布脚本、构建脚本。除了资源跟动作管理,还有状态(监控)管理。

这里需要强调的是意识的问题,因为在整个上层、应用层监控设计中考虑了“自动容灾切换”能力,所以我们不需要关注底层的监控。只要应用层没有告警,不用管底层服务器和机房是否挂掉。

我刚参加工作时,系统经常告警,需要半夜爬起来重启机器、删文件。现在运维只会接到通知,告知服务器挂掉,进行确认,不用实时处理。基于这个逻辑,在业务没有告警的情况下,我们系统就是正常的。完善的运维管理平台能够合理的把资源、动作、状态协调管理。

如图所示,最上面是面向运维,包含运维、研发者的服务目录和日常任务中心、状态中心的统一运维门户。

下面是调度编排系统,产品扩展根据不同行业及其业务特性,做出不同编排需求,将这些不同的需求选项进行固化。

中间是运维平台的核心,执行层的系统。忽略灰色的传统 API 模块,现在我们运维日常使用的就是这个包括持续交付平台、统一监控平台和 ITOA 运营分析平台在内的立体化监控系统,通过它实现动作、状态管理。针对基础设施、平台系统、应用级、服务级甚至更高层的需求,提供精确度、优先级不同的接口。

底层是 CMDB 资源管理。传统 CMDB 管理对象,属于硬件资产。在云化技术发展之后,会越来越弱化。应用运维就不需要关注太多。这里CMDB 包含了业务信息管理、应用程序包、配置、定时调度任务、流程、工具、权限、系统配置等基础资源。

三、运维平台的微服务进化

随着公司业务的发展,如何将正在应用的系统进行架构上的优化或规划?

技术选型

首先,微服务跟基础架构的区别在于,微服务的组件拆分后是通过网络传输的。因此通讯标准要做出合理的选型。

微服务的架构,通常是异构架构。比如我们的平台运用了 JSON、JAVA、PSP 等语言,必须选择同时兼容多种语言的协议。就像我们之前选用 Protobuf 时,发现它兼容 Linux 系统的库不成熟。在不同场景下,微服务的技术选型需要有较强的兼容性。

其次是语言的选择。微服务强调接口的稳定性,在保证服务稳定的情况下,可以自由选择熟悉的语言。

微服务的规划

单一职责原则:每个服务应该负责该功能的一个单独的部分。

明确发布接口:每个服务都会发布定义明确的接口,而且保持不变,消费者只关心接口而对于被消费的服务没有任何运行依赖;

独立部署、升级、扩展和替换:每个服务都可以单独部署及重新部署而不影响整个系统,这使得服务很容易升级与扩展。

平台构建

通过下面的两个模块来讲解平台的架构。

1.CMDB 系统怎样做简单的分拆,使之更容易维护?

CMDB 是一个有大量配置系统存在的可以进行查询、修改的数据库管理系统,它的内部包含模型管理,配置管理、自动发现。

a)模型管理

CMDB 中,我们会管理大量随着产品技术站演进动态变化的资源和相异的动作,所以要独立出模型管理的模块,保证 CMDB 动态可调整。

b)配置管理

由于 CMDB 的信息敏感度高,很多公司要求,把像“应用”和“IP”关联关系的敏感业务信息保存在其中。

c)自动发现

如果 CMDB 没有完善的自动发现机制,它失败的概率会非常高。就像传统 CMDB 有一个在严谨的审批机制运行下的配置变更流程。但是即使在配置跟现网一致的情况下,还是需要每半年进行一次资产盘整,对信息进行纠正。对于有海量业务的系统来说,没有“自动发现”能力的CMDB 是不合格的。

通过“自动发现”,去自动化采集服务器带宽、网卡速度、内存、磁盘空间、进程等信息,由 CMDB 进行管理。模块管理相对传统,“自动发现”是 CMDB 的核心,在同时管理数十万台服务器时,只能通过“自动发现”的探侦才能进行自动化维护。

2.持续部署系统

持续部署系统负责自动化发布。

上图将持续部署系统的平台构建分为多个子模块。

a) 构建管理

构建即以静态图片、业务程序、配置文件等为主的部署对象。根据 DevOps 中的原则,需要将一切版本化。所以需要一个构建库负责管理所有发布到生产环境的资源。

通过统一的构建库,对所有发布到线网上的数据进行标准化管理,以此可以快速在其他机房重建原系统等。同时它还拥有信息共享功能,过去运维发包之后跟踪困难,现在研发人员只需向构建库输入版本信息,运维从构建库中导出就好了。

b) 任务管理

任务库:负责存储日常发布任务,满足自动化发布需求。

实例库:曾经由于很多研发人员贪图方便,选择在线网直接更改系统,使记录上的信息是错误的,所以我们不使用“任务下发完成之后,系统设置自动更新”这种设计。在无法信任上层管理系统的情况下,现网信息、数据必须实时扫描上报。

为了保证信息的发布成功,必须以 Agent 上报的信息为准。

因为配置信息存在大量变更入口,在无法保证唯一入口的情况下,不能想当然地设计系统。

命令通道与数据通道是除了构建库、任务库、实例库之外的上层系统的基本构成。

首先命令通道与数据通道需要分开管理。腾讯曾经需要将 1G 的文件发送到两千台服务器,频率达到一周一次,一次一周,不断重试、失败。后来将命令与数据切开,每次只传输几十K的命令脚本,服务器再也没有阻塞。

开源方案部分问题依旧无法解决,像现在的异构网络,在混合云的场景下,必须保证网络互通,才能做到直连。大家可以选择自己去编写 Agent 练手,通过反向通道连接中心管理服务器去解决此问题。

四、微服务架构下平台架构的底层基础服务

名字服务

名字服务指通过配置文件中匹配的名字查 IP 端口的服务,可以选择合适的开源方案。如果自研的话,可以对服务进行灵活分区等。如深圳的服务器 A 访问在深圳、上海两地均部署服务的 B,我们只需要在名字服务中与 CMDB 打通,使用深圳的服务器访问深圳的 IP,达到同城访问的效果。这个操作在开源方案中就无法完美实现。

状态监控

要求能达到接口即调用数据采集的应用层监控。

通过访问量、成功率、平均时延这三个核心指标,低成本把握绝大部分需求。以访问量为例,当访问失败率上升告警时,直接触发名字服务联动,将故障节点自动摘除。

负载均衡

当系统规模扩大,节点剧增时,增加中间代理的方法会增加系统内部压力。

如果落地到Agent,通过名字服务查询 IP 列表,合并状态信息,均衡节点请求,可以更好的达到负载均衡。

负载均衡的极端就是容灾,正常情况下根据性能状况保证每个节点处理合适的请求量即可。

这三点是运维平台或业务生产的系统中的核心能力。包括腾讯在内的运维平台都是基于这三个服务闭环去运行的。只有在做到这三点,才能解决系统异常,维持系统的正常运转。

五、微服务运维平台的迭代重心

我们在整个平台进化的过程中,其实是要有优先级和取舍的。

总的来说,优先要解决我们的瓶颈问题。比如我们发布系统有性能问题的时候去,那个发布系统现在还是一个巨石架构,做了那个调整没有问题,就这个样子了。然后是平行扩展的能力,还有考虑服务复用的能力,甚至是一些开源解决方案的利用。但是开源这个东西,我不认为把一堆的开源工具用在一起,能够形成一个很好的一个运维平台。大家应该把这些开源的能力,这些一个个的微服务,核心的这个架构还是必须要有自己的控制力在这里。比如:监控。很多开源的系统,它是更偏重于执行层的工具,但是核心的CMDB,核心的流程控制还是需要我们去建设的。

 
   
672 次浏览       51
相关文章

DevOps转型融入到企业文化
DevOps 能力模型、演进及案例剖析
基于 DevOps 理念的私有 PaaS 平台实践
微软开发团队的DevOps实践启示
相关文档

DevOps驱动应用运维变革与创新
运维管理规划
如何实现企业应用部署自动化
运维自动化实践之路
相关课程

自动化运维工具(基于DevOps)
互联网运维与DevOps
MySQL性能优化及运维培训
IT系统运维管理