为满足电信行业大并发及海量数据的数据处理和实时计算需要,需要引入分布式计算、分布式存储、微服务技术、各种开源技术以减少业务支撑成本,但系统复杂性、可靠性、灵活性、资源利用率受到一定影响,因此需要引入一种技术实现资源的弹性伸缩提高资源利用率、故障的自动隔离保障系统稳定性,提升应用标准化发布提高需求上线效率,进而保障系统的稳定性和敏捷性。
电信行业最核心的业务系统BOSS系统,即业务运营支撑系统,包括BSS(营业受理、计费、账务、结算等核心业务系统),OSS(服务开通、激活、资源等核心系统),目前电信行业已经开始了云化改造探索,在传统IOE架构里,开始了去O的进程,同时对业务做了扁平化处理,大量采取了容器的技术,实现了业务的高可用的同时,提升了主机资源的的利用率。
容器是一种轻量级的虚拟化技术,将应用和操作系统封装在一起,它具备资源隔离、性能隔离、故障隔离和网络隔离能力;同时具备快速发布、弹性伸缩和故障自动化恢复的能力,使得复杂的业务支撑微服务架构得以落地生根,进而实现速度快、成本低、资源利用率高、系统稳定等IT支撑目标。
本场电信行业线上活动,社区邀请了红帽的容器专家 沈卫忠 ,为大家分享电信行业BSS/OSS应用基于OpenShift实现容器化改造的解决方案 。同时也邀请了多家电信行业嘉宾进行线上交流互动。精彩回顾:电信行业BSS/OSS应用如何基于OpenShift实现容器化改造在线探讨
**1、容器运维监控;
2、BSS/OSS应用迁移改造
3、容器如何保证业务连续性
4、容器化开发和技能
5、BSS/OSS应用容器化方案评估**
容器化以后,我的理解就拆分成了三层 硬件层, 容器层 ,应用层
各个层如何做横向以及性能管理和故障发现有哪些快速定位手段?
纵向的跨层故障关联如何实现?
回答: 沈卫忠 软件架构设计师 , 红帽企业级开源解决方案中心
就OpenShift容器云平台而言,监控是采用了普罗米修斯和Grafana进行系统监控的。
· 每个节点上都运行一个Node-Exporter的进程,负责监测主机节点的CPU使用率,CPU负载,内存使用率,磁盘空间使用率,磁盘I/O,网络流量,系统进程数等;
· 同时节点上另一个进程Kube-state-metrics负责获取Kubernetes对象相关信息,比如pod的CPU使用率,CPU负载,内存使用等;
· 普罗米修斯通过HTTP采取上述两个进程暴露的信息,存放到时序数据库中去,而 Grafana 负责显示监控信息。 2. 普罗米修斯和Grafana 本身已经内置对硬件和容器的监控,我们也可以扩展增加对应用的监控。 3. 普罗米修斯AlertManager可以根据获取的指标信息发起web hook请求,从而达到自动通知目的(可与已有告警系统集成) 4. 如果底层的硬件坏了比如服务器彻底坏了,openshift能够重新调度所有的Pod到其他节点。如果部分硬件坏掉,OpenShift也可以根据资源使用状况调度一些pod去其他节点。 5. pod如果崩溃或死掉,OpenShift/K8S的LivenessProbe会失败,从而创建pod. 6. 应用本身的日志应该用EFK统一管理,可以帮助故障分析。
回答1:朱祥磊 系统架构师 , 某移动公司
cAdvisor+Influxdb+Grafana是一套为容器集群性能监控设计的开源解决方案,利用cAdvisor 对容器信息的良好监控能力,Influxdb对时间序列数据的快速检索能力,以及Grafana的强大图标展示能力,形成性能数据的实时查看和历史回溯。日志管理方面,当下最主流的容器日志开源工具组合ELK,或者EFK。另外还有prometheus+alertmanager可以实现短信或者发邮件下发告警。总之,容器生态圈有很多的监控工具,客户可以结合自己的业务使用场景,选择自己最适合的工具。
回答2:沈卫忠 软件架构设计师 , 红帽企业级开源解决方案中心
就OpenShift容器云平台而言,是采用了普罗米修斯和Grafana进行系统监控的。每个节点上都运行一个Node-Exporter的进程,负责监测主机节点的CPU使用率,CPU负载,内存使用率,磁盘空间使用率,磁盘I/O,网络流量,系统进程数等;同时节点上另一个进程Kube-state-metrics负责获取Kubernetes对象相关信息,比如pod的CPU使用率,CPU负载,内存使用等;普罗米修斯通过HTTP采取上述两个进程暴露的信息,存放到时序数据库中去,而 Grafana 负责显示监控信息。
回答1:朱祥磊 系统架构师 , 某移动公司
对于容器化故障运维保障,需要做到以下几个方面:
1 对整个集群的状态,做健康检查,目前可以通过prometheus, Grafana监控系统 ,通过prometheus定期抓取指标,设置告警,送到altermanager,altermanager调用短信网关,或者邮件,就可以下发短信,或者邮件告警,这样运维人员可以立马相应处理。
2对于容器化的应用, 很多的微服务,有问题了,定位问题,需要查看日志,而容器日志多,查看日志就需要借助一个ELK或者EFK一整套的日志解决方案。
3 使用自动化的运维工具,提供工作效率。
4 每个微服务要去除对单个节点的强依赖,这样即使一个节点宕机了,对业务也没有影响。
5 对于重要的节点,如k8s的master节点,要做高可用HA,即使一个节点宕机,对集群也没有影响。
5 镜像仓库也要做高可用。即使一个仓库除问题,根据高可用,使用一个虚拟IP,可以漂移到另外一个节点 ,为k8s集群的镜像拉取提供可靠服务。
回答2:沈卫忠 软件架构设计师 , 红帽企业级开源解决方案中心
回答1:eximbank 系统架构师 , 某金融企业
1,技术上是完全可以支撑这种替换,但是更多需要是考虑业务计费系统运行要求,是否满足当下监管的规范和安全体系;
2,传统计费系统架构重塑、梳理、分拆,将传统的大而全的紧耦合数据集交付,梳理分拆成适合微服务化的松耦合分布式数据交付;
3,数据库服务与计费系统逻辑处理服务的松耦合,并且由原来同步交互数据集转变到异步交换同步数据集,也就是有集中统一交付变成送耦合分布式交付,只要确保每一个为服务负责的数据正确,数据链路不中断即可;
4,数据库本身是为业务应用所用,数据库本身被替换并不是存在技术瓶颈,真正的瓶颈是业务-应用系统的要求;尤其很多计费系统不管是业务本身属性有要求,对于监管机构也有要求,这些因素往往是改造和升级的瓶颈,所以梳理和分析这些因素是极其重要的步骤,而且是不够可逾越的步骤。
回答2:朱祥磊 系统架构师 , 某移动公司
计费系统数据库数据量巨大、频繁增改,属于IO密集型,并不建议容器化,但对计费应用来说是可以容器化的。可以考虑内存库替代传统数据库。
回答3:沈卫忠 软件架构设计师 , 红帽企业级开源解决方案中心
回答1:沈卫忠 软件架构设计师 , 红帽企业级开源解决方案中心
云计算、云原生、微服务对于企业的引领作用,大家在互联网行业都看到了,这里面就不多说了。既然电信行业已经不再是一个是垄断行业,而且随着改革开放的深入,我们预期市场竞争也会越来越激烈。所以,电信业务支撑系统BOSS势必要转向云原生,我们要关注的重点是如何转,如何在转型过程中减少风险。
当然,对于某些跟网络侧联系紧密,业务比较稳定,不跟客户端发生关系的稳态O域应用,可以不进行转型。
回答2:boss系统已完成云化改造,但容器化的步伐相对较慢,主要是业务逻辑太复杂,从技术发展趋势看还是有必要的,特别是业务资费开发的部分
回答1:朱祥磊 系统架构师 , 某移动公司
建议采用新旧系统并存方式,新系统为容器化,逐步将相关业务的消息发到新的系统,实现新旧系统替换。
回答2:沈卫忠 软件架构设计师 , 红帽企业级开源解决方案中心
回答1:沈卫忠 软件架构设计师 , 红帽企业级开源解决方案中心
OpenShift从版本4开始推出了快速部署的功能,它的安装模式包括一种IPI(Installer Provisioned Infrastructure)模式,能够支持在裸机、VMWare、 OpenStack和公有云AWS, AZure上同时创建操作系统和OpenShift,基本上是一键式安装,减少了安装复杂度。
回复1:朱祥磊 系统架构师 , 某移动公司
容器化后,应用都是容器化的,也就是以前直接运行在操作系统之上大的单体应用程序,需要根据单体应用架构,拆分为许多微服务,基本上每个微服务都运行在独立的一个容器里面,紧密耦合的微服务,考虑到通信性能,也可以运行在同一个容器里面。通过上面的分析,容器化后,要求运维人员具备docker的诸多知识。还有微服务之间的调度关系, 容器的调度,需要用到容器生态圈里面的容器编排引擎,现在最火的当属kubernetes了。存储镜像使用的镜像仓库,也需要搭建,维护,清理。总之 ,容器化之后,对运维人员提出了新的要求,需要运维人员具备专业的容器化技能,还需要转变原来传统的思维方式。
回复2:沈卫忠 软件架构设计师 , 红帽企业级开源解决方案中心
微服务,容器化的实质是解决了业务复杂性问题(通过微服务降低单模块的复杂度),提高了企业敏捷性,但代价是增加了运维的复杂度,因为微服务是分布式,而分布式是复杂,好在OpenShift/K8S提供了好多工具,能够帮助运维人员面对这种情况。所以运维人员需要具备一些新技能:
新老系统并行,包括传统的soa架构系统,微服务架构系统,业务调用逻辑可能横跨新老系统,由于旧系统业务日志缺失比较厉害,在新老系统并行期间,对业务交易还原存在较大困难,没有一个比较好的方法去梳理业务调用逻辑,还原交易过程缺失的环节。
回复1:沈卫忠 软件架构设计师 , 红帽企业级开源解决方案中心
就OpenShift而言,OpenShift Service Mesh(基于Istio)是用于微服务治理的一个服务网格,这里面的Kiali和Jager可以帮助 梳理业务调用逻辑:
回复:沈卫忠 软件架构设计师 , 红帽企业级开源解决方案中心
DevOps不仅仅是技术层次的东西,而首先是一个组织架构、企业文化,没有组织架构和企业文化的改变,很难能够打造一个DevOps团队。
回复:沈卫忠 软件架构设计师 , 红帽企业级开源解决方案中心
这个问题我的理解是应用的某些技术组件是在容器平台上,另外一些技术组件是在非容器平台上(比如OpenStack或VMWare上面的虚拟机)。在这些的一种情况下,我们可以考虑采用Ansible自动化引擎通过编写playbook来统一编排调度。对于OpenShift和K8S,Ansible都要现成的module,如果这些module某些功能不支持,也可以调用Restful API.
如果想采用K8S原生的方式进行统一编排,可以考虑采用OpenShift或K8S内置的Operator Framework,利用Ansible和Operator-SDK创建一个Operator来统一编排容器外部和内部的应用。
回复1:朱祥磊 系统架构师 , 某移动公司
容器化后,容器之间共享同一个操作系统内核以及其他组件,在收到攻击之类的情况发生时,运行在这个节点上的容器,如果因为宿主机被攻击(甚至宕机),不能正常工作,容器编排引擎如kubernetes,会保证原来定义的副本实例数量,根据调度算法,在合适的其他节点再起新的容器,而且启动速度可以达到秒级启动,传统的宿主机启动则非常慢。而且k8s容器编排引擎还可以根据业务的访问量,进行pod的水平自动扩展(HPA);如果采用传统的宿主机上运行大的单体,一个节点收到攻击,可能影响巨大,而且很难短时间恢复。业务之间可以通过域(namespace)来进行隔离。而且容器本身就已经实现了诸多的隔离功能。目前很多的世界知名企业都开始从传统的单体业务向容器化转型。
回复2:沈卫忠 软件架构设计师 , 红帽企业级开源解决方案中心
一般而言,容器本质上是进程的虚拟化(隔离),但操作系统内核是共享的,所以,在这一点上,容器的安全性没有虚拟机好。但是,我们可以通过以下方法增加安全性:
对于数据隔离,一般而言,需要采取以下措施:
回复:沈卫忠 软件架构设计师 , 红帽企业级开源解决方案中心
对于用状态应用来讲,有三个方面跟无状态应用有着本质区别:
回复1:朱祥磊 系统架构师 , 某移动公司
1、现有应用业务量大、非常关键,彻底改造需要一个长期过程,可以先周边逐步渗透
2、人员技能不满足,传统运维模式,需要一个过程
3、应用改造需要较大的工作量,可能是投入很大的成本,投资收益比是否高,面临阻力
回复2:沈卫忠 软件架构设计师 , 红帽企业级开源解决方案中心
因运营商对业务的稳定性和连续性有比较高的要求,故容器化和微服化的演进路径必然是从边缘业务到核心业务,从简单应用到复杂应用,过于简单、并发度低的系统其实不必要作微服务化。同时相对一般的企业,运营商的硬件投入更大,服务器性能更性。过小过细的微服化不利于发挥硬件性能。容器化并非包治百病的良药,某些对并发吞吐量要求更高的业务,直接运行在裸机上,通过系统调优提高性能,容器化未必是最好的选择。
故如何在运营商容器化和微服化过程中,更好地把握划分的最小粒度是运营商容器化和微服务的一个重要问题。
个人认为至少有以下原则:
1、高并发,多业务聚合的应该坚决拆成容器化、微服务。而低并发,业务相对单一的不需要;
2、高I/O,如文件转移服务的不需要;
3、允分考虑主机性能,以保证业务吞吐量为第一原则来考虑拆分的必要性的粒度。
回复1:朱祥磊 系统架构师 , 某移动公司
微服务并不是越小越好,数量不宜过多,需要充分考虑到功能复用性、压力、开发工作量、团队等因素,以敏捷开发为原则。
回复2:沈卫忠 软件架构设计师 , 红帽企业级开源解决方案中心
就经典微服务设计而言,领域驱动设计(Domain Driven Design)是微服务拆分的常用方法,一般而讲,一个微服务合适的粒度是,有一个所谓的'两个比萨饼'的规则。这个是亚马逊提出的,意思是说一个开发团队不能多到两个披萨饼还不够他们吃的地步,往往是5到7个人。
对运营商业务来讲,微服务改造是一个循序渐进、逐步演进的过程,微服务的粒度也是根据业务要求相决定,有时候一个服务的粒度可能比较大一点,不一定是微服务,也可以是小服务(mini service, 几个微服务组合在一起)。
在电信行业里,BOSS等相关核心业务系统是否成功部署在容器openshfit上边的成功案例?小规模部署也行,如有能否详细介绍下?可否推广?
回复1:朱祥磊 系统架构师 , 某移动公司
某运营商的在线计费系统,已经用了k8s+docker
回复2:沈卫忠 软件架构设计师 , 红帽企业级开源解决方案中心
在国内和国外,BOSS的容器化改造实际上早在一两年前就已经有了,有些运营商也已经上线了在K8S部署的容器化BOSS系统,这个包括咱们国内的某个省的移动公司,这个充分证明了容器化、微服务的BOSS系统是可行的。
回复1:朱祥磊 系统架构师 , 某移动公司
微服务的主要好处是一个服务“类型”可以通过使用多个容器实例和负载均衡来扩展以提供吞吐量。从而保证业务的高并发,稳定性。这也是容器化的一大优点。这个容器化的横向扩展,不是由容器本身实现的,而是通过容器编排引擎如kubernetes来实现的,也就是我们通常所说的pod的水平扩缩容(HPA ),当业务访问量大的时候,起更多的pod来影响用户的业务请求,当访问量小时候,还可以减小pod的数量。对于上面的来说,一般都是针对无状态的服务。而对于有状态的服务,如数据库,则要考虑下面的问题:“服务类型”的多个实例(即容器)共享同一个数据库实例;当在该数据库实例上进行了多个实例写入/读取时,这可能有性能瓶颈。任何事物都有两面性,所以,我们要辩证统一的去看,只有这样,才能让容器微服务更好的服务于我们的业务系统。
回复2:沈卫忠 软件架构设计师 , 红帽企业级开源解决方案中心
在容器云平台中,横向扩展包括两个方面:
回复:沈卫忠 软件架构设计师 , 红帽企业级开源解决方案中心
1.K8S是一个容器编排平台,红帽公司本身是K8S社区的发起者和截止目前第二大社区贡献者,K8S是OpenShift的上游社区。
回复1:sunphil 系统运维工程师 , 某移动
微服务是为了进行能力拆分,打破系统间壁垒,为中台服务,服务更复杂的业务场景需求
回复2:沈卫忠 软件架构设计师 , 红帽企业级开源解决方案中心
回复1:朱祥磊 系统架构师 , 某移动公司
电信行业最核心的业务BOSS系统,即业务支撑系统,包括BSS和OSS,要求业务高可用,实时性,稳定性,安全性,业务需求变更频繁,需要频繁发布版本。传统业务系统存在的问题,一个模块出现问题,影响面很大,隔离性差,不具备快速发布等缺点。
而容器是一种轻量级的虚拟化技术,将应用和操作系统封装在一起,它具备资源隔离,性能隔离,故障隔离和网络隔离能力;同时具备快速发布,弹性伸缩和故障自动化恢复的能力,使得复杂的业务支撑系统得以落地生根,进而实现速度快,成本低,资源利用率高,系统稳定等IT系统支撑目标。
目前的难点:容器化和微服务化后, 应用数量增加,系统管理难度增大,需要积累和储备技术经验做运维开发保障。电信行业业务连续性要求高,现网系统复杂,需要对现网功能和架构做充分的梳理才能迁移业务。需要考虑硬件,操作系统,中间件,数据库的兼容性。
回复2:沈卫忠 软件架构设计师 , 红帽企业级开源解决方案中心
传统单体BOSS系统的主要问题是:
难点主要在于:
如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!
赞3
添加新评论0 条评论