★OCES架构系列★

之 架构结构演进概述

经过连续一周的深夜切割数据验证,2018年8月底,OCES的重大改进版本终于成功上线。又经历了一周跟踪总结后,系统功能基本稳定,初步达到了预期效果。

工程中心希望把这次OCES架构的演进过程做一个简单的总结,分享给各位同仁。为此,OCES项目组对OCES架构进行了梳理,形成了系列文章。本篇文章为这个系列的第一篇,对OCES架构演进过程做一个简单的回顾,后续我们还将发布系列OCES架构技术文章,敬请各位技术达人期待。

工程中心

出发点:

我们为何要做OCES架构演进

公司的OES平台,承接着公司网络学历教育这一主营业务,已成功运行了十余年的时光。从2016年起,公司提出对OES平台的全新改版,研发新的OCES平台,以更好的服务公司的上百万用户。

在研发和上线运营OCES平台的过程中,受国家相关政策、合作的各网络学院教学需求,IT技术的飞速发展,以及公司为网络学历教育用户提供更好的支持服务的强大内在动力等各方面因素的共同影响,OCES平台一直在不断的改版升级。这一过程中,我们面临着下面这些困难。

第一,平台面临着业务需求一直不间断大量迭代和OES教务改造的双重任务压力,在原有的架构下,平台一直存在需要停机发布和难以在业务运行时进行个别模块bug修复或更新等问题。

第二,随着开发团队和开发规模的扩大,原有架构也无法满足多组多模块同步协调开发、根据模块业务量灵活调度软硬件资源和分布演进式改造旧OES系统的需求。

为了解决以上难题,2018年年初工程中心领导设定了OCES架构按照分布式服务和分布式站点改造的目标,OCES团队在高总、贾总的支持下,在架构组的协助下,经过近半年的努力,终于顺利完成了分布式服务和分布式站点改造的目标,实现了本次重大版本发布!

改进方式:

持续改进,迭代改进

没有一个完美的架构能一成不变地应对业务的所有情况,时代在发展,业务在变化,需求上的持续改变,时间累积久了,就会因为量变而发生质的变化,所以,在不同的阶段需要不同的架构。

对于小公司而言,业务还处于发展期,QPS 很低,暂时不会面临架构的调整优化问题,即便要做优化他们可能也没有环境及条件;而对于大公司,服务器等硬件条件不是主要关注的问题,主要需要考虑的是要不断调优以及应对急剧提升的访问压力,改善基础设施以提供更稳定的开发环境。在公司及业务的发展过程中,架构演进是一个动态的持续过程,没有终点。

那什么时候需要做架构上的改造呢?当突然发现系统问题越来越多,经常出现事故或者报警特别多,沟通的效率降低等问题,很有可能就是架构的问题了。这是要着重关注架构的梳理与调整优化。

架构的模式思路定下来,随着业务的增长,包袱会越来越大,做过基础设施的人都有这样的体验:有一个好的想法很容易,但做一个好用软件却有很多的困难,因为改动软件架构有一个问题,它改动的周期相对比较长,一般以年为单位。所以不要企图做特别完美的架构,我们只要保持敏捷演进就好了,让架构迭代更快一点,记住,让架构迭代更快一点!

以上是关于架构演进的一些总结,关于架构的技术探讨在此先不做大幅描述,敬请期待后期的技术总结分享,下文将就OCES平架构结构的演进过程进行一下简要的总结和说明。

题外话:

做为系统架构团队,需要应对服务稳定性、迭代速度、服务质量三方面的压力。

服务稳定性 ——接口的稳定性,让服务更可靠。

迭代速度 ——迭代速度是必须要保证的,时间窗是决定业务能否成功的重要因素。

改造前阶段:

分布式烟囱结构

改造前的oes平台采用的是典型的烟囱式单体结构(all in one),这是一种集成负载均衡的集群服务器式部署结构。

这样的部署结构很好的解决了较高QPS的访问压力,但随着用户量的持续增长及跨团队开发的形成,此架构无法适应中心的业务和技术发展需求,所以工程中心于2016年提出了微服务化改造的技术方向,并在接下来的一年多时间里进行了后端服务拆分改造,从而形成了过渡阶段的架构结构。

过渡阶段:

后端微服务化结构

后端微服务化解决了我们两个关键的瓶颈点:解耦(一个服务会依赖另外一个服务、模块或子服务的概念),轻量(开发部署轻量化,减轻维护成本)。

过渡阶段结构中,后端采用微服务化结构,实现了各核心功能以及各业务逻辑的解耦,使得各业务逻辑与诸如通信、服务治理等非业务逻辑进行彻底解耦,各个核心功能进行了重构实现,实现了轻量级微服务模块。但是,平台中,前端站点仍然为单体站点。所以,此时平台的结构是一个混合式的结构,平台仍然存在需要停机发布和难以在业务运行时个别模块bug修复和更新问题。

针对上述情况,2018年上半年,工程中心组织完成了《OCES重构-单点登录服务暨OCES单点接入项目》和《OCES重构-OCES站点拆分项目》两个项目,并在8月底成功完成项目并发布上线。至此,OCES平台进入了现阶段—分布式服务和分布式站点结构。

图1 服务微服务化系统结构示意图

现阶段:

分布式服务和分布式站点结构

如下图为OCES平台的结构,现结构将站点按照业务模块或者项目独立开发部署,最终通过单点登录实现集成,将OES站点也按照子站点方式接入到整个平台,为各站点独立部署和发布提供了基础!与此同时,公司IT运营与安全中心进行了devops的推进,通过《脚手架工程及持续集成自动化V1.0》项目,实现了通过IT工单自助服务自动创建和自动部署预生产,并最终实现了自动发布上线。在以上工作的共同作用下,解决了平台一直存在需要停机发布、难以在业务运行时个别模块bug修复和更新,以及跨团队协调开发等一系列难题,更为领域模型系统设计奠定了技术架构基础。

图2  OCES平台结构图

参考文章:

现阶段的架构—分布式服务和分布式站点结构,肯定也不是完美的,还需要考虑系统的安全性、数据分析、监控、devops、服务化、消息队列、任务调度、多机房等等方面的要求,需要后期继续持续优化改进。

架构演进是根据实际的业务场景和发展情况,一步一步的发展演变而来的,在不同的阶段,会使用的不同的技术,不同的架构来解决实际的问题,所以说,高大上的项目技术架构和开发设计实现不是一蹴而就的。在架构演进的过程中,小到核心模块代码,大到核心架构,都会不断演进的,这个过程值得我们去深入学习和思考。

让我们一起加油,持续改进我们的架构!

敬请期待以下系列技术分享

《工程中心注册中心和配置中心实现介绍》

《工程中心统一认证及单点登录的实现介绍》

《OCES平台日志和监控体系》

《工程中心注册中心和配置中心实现介绍》