携程运维架构揭秘:高可用架构最佳实践之路

www.net130.com     日期:2017-10-9    浏览次数:
作者:周源    出处:博学网

携程的架构经历了长期的演变和迭代,其中多个产品已经历了 5 次以上的更新换代。每次迭代都有其背景和出发点,都解决了前一个版本的痛点又不可避免带来一些新的问题或遗漏一些问题。
这种迭代过去、现在、将来一直持续着,其中经历可圈可点,值得技术人细细品味。

本文先从总体介绍携程架构的组成,接着以发布系统、配置管理和 SOA 三个实际案例详细介绍架构迭代,最后以自己做的一个项目具体介绍携程架构亮点的点滴。</P>

 

架构组成

总体来说,携程的架构由三部分组成:运维、框架、应用。

01运维

谈到高可用和稳定性,我们首先想到的肯定是运维。携程的运维是应用和架构坚强的后盾,主要有四大亮点。

集群管理策略

携程的 Web 集群有 slb 控制流量,根据 healcheck 的结果可以自动拉出和拉入。发布和扩容过程对开发透明,当机器 check 成功且没有报错时,机器将拉入集群。当 check 失败或单位时间报错超过阀值,机器将自动拉出集群。

FullDR 机制

Web、DB、Redis 集群都有长效的 FullDR 机制,当一个 IDC 完全挂掉,比如网络故障、网线拔断等发生时,FullDR 将发挥功效。携程定期对 FullDR 进行演练,以确定DR对订单的影响。

DBA 策略

数据的安全是重中之重,携程将用户数据放在稳定的首位。我们使用 M-S 机制和 FullDR 结合保证数据的高可用。

同时为了顺应互联网的发展,我们将 MSSQL 的数据无缝迁移至 MySQL,虽然花费了很多时间和成本,但是为了稳定,投入也是值得的。同时我们保证迁移过程对用户是透明的。

SQL+NoSQL 的结合是互联网发展的趋势,而携程的数据存储更是包含 MSSQL、MySQL、Redis、Hive、ES 等多种方式和技术,保证数据的高可用、最终一致性。

NOC 机制

在携程,作为开发负责人是非常艰苦的,因为如果你负责的应用一旦出现异常,NOC 7*24 小时都可能联系你。

NOC 通过专门的订单大图和异常图表监控所有应用的运行状态。订单量同比、环比的上升、下降都会被严密的监控。


02框架

框架是应用的基石,而携程框架更是经历过且正在经历着演变和迭代。其中特别值得分享的包括:

SOA&Gateway

SOA&Gateway 是服务的治理平台,它有着非常悠久的历史,后面会详细展开。

发布系统

携程的发布系统集成了很多特色功能,比如刹车、回退、版本切换、共用 dll 打包、pom 检测等等。

发布系统经历了历史上最严重的灾难性故障,在故障中浴火重生,非常值得给大家分享其演变和迭代。

消息队列

市面上开源的消息队列工具非常多,包括 Storm、MSMQ、ActiveMQ、RabbitMQ 等。

携程结合各第三方的优点,加以融合,结合自身情况,自主研发了消息队列。核心功能有 Partition 有序、异步补偿和消息生命周期跟踪。

配置管理

配置管理在任何规模的公司都会做,而对配置而言最重要的不外乎是便捷、高效和高性能。携程配置管理的演变恰恰反映了这种趋势。

03应用

经过和多家知名互联网企业架构师沟通,我们发现大家的应用架构都是比较相近的,一般都会用到 PreLoading&LayerLoading、Sharding、熔断、限流、降级等技术。

而经过无数经验证明,上述措施确实极大的提升了网站和 APP 的稳定性。比如,当灾难发生时,PreLoading 可以保证用户可以看到预设的内容;而网络情况较差情况下,LayerLoading 可以保证用户操作不卡顿。

本新闻共3页,当前在第1页  1  2  3  

分享道
相关新闻