首页 > 代码库 > 云平台架构变迁

云平台架构变迁

特来电云平台从创立到现在已有2年多时间,总结来说,我们主要有2个阶段的发展:

1.2015年是云平台发展的元年,在这一年我们快速搭建了充电系统,因为公司成立不久,我们没有专业的公共技术团队,在技术架构上做的不好。在1.0研发的过程中,我们也意识到了这个问题的严重性,所以在15年下半年组建公共技术团队,专攻基础组件和技术平台。

2.2016年是第二个阶段:在这一年中公共技术平台有了跨越式的发展,我们先后开发了多个服务平台:比如服务网关、服务框架、监控预警平台。这些平台上线后,立即进行了业务迁移。通过技术平台的开发:我们期望在业务急速增长的过程中,可以通过追加机器的方式,快速实现系统的平滑、水平扩容。

技术分享

云平台1.0的架构比较简单,是一个三层架构。通过这个图可以看到,整个架构中没有公共技术的位置。在这个模式下,业务系统对技术的复用度比较低。应用的架构、模式都是自由发挥的。这样每个系统在开发的过程中,都要实现业务特性和技术特性。容易形成:业务不专,技术不强的情况,并且各个程序对分布式、高可用实现的程度参差不齐。

技术分享

在1.0的架构下,我们遇到了非常多的问题!

技术分享

基于1.0的这些问题,我们在15年底就开始思考解决方案。首先,我们分析了特来电业务系统的特点。我们公司的充电业务是典型的互联网应用,对可用性、并发性等要求都非常高。传统的1.0的这种“烟囱式”的开发,很难达到互联网应用的要求。所以,公共技术的平台化是我们发展的的一个必然方向。基于此,我们重构了特来电业务系统的技术架构,下面是我们2.0的架构:

技术分享

2.0架构的核心是平台化。在新的架构中,我们把系统分为了四层:前端、服务网关、服务平台、基础组件,并提供了集中化配置和监控预警。通过服务网关、服务平台、基础组件,我们规划了服务端的开发。通过配置中心和监控预警来提供系统的运维能力。

通过2016年的努力,我们做到了:

1.建立了结构完整、功能完备的服务端开发、运维框架,实现服务端开发、运行的全平台化。

2.服务端程序的运维基本做到了360度、无死角监控。

云平台架构变迁