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

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

架构演变

01发布系统

携程发布系统至今大体经历了如下四个“年代”:

  • ITSM。
  • CITSM。
  • CRoller(ROP)。
  • Tars(CD)。

说到发布,一定要提一下 “最传统”的发布方式。传统公司会有专门的售后团队负责部署、或直接由开发人员负责发布。发布方式简单粗暴,直接登录到服务器上覆盖文件。

携程作为互联网企业,第一代发布系统已经做到了开发和发布隔离,使用一个 C/S 的软件 ITSM 做发布,发布人员只需要简单点击按钮就可以完成发布。

但是那个年代,一旦提到发布,我们往往就先要买第二天的早饭了。因为一个集群上的若干应用发布是排队的,必须一个应用发布且验证完毕才发第二个。同时因为是 C/S 结构,需要发布人员做本地安装,使得协同工作特别困难。

鉴于 ITSM 不断被诟病,携程自主开发了 CITSM 发布系统,功能和 ITSM 相似,但用 B/S 实现,协同发布变成可能,且将发布系统与框架其他系统进行整合,为开发人员提供了极大的便利。同时引入版本管理和回退机制,形成了一个飞跃。

第三代的发布系统进一步收紧了开发人员的权限,引入了 All In One、Config Gen、自动加载等。

所谓All In One,是将原本配置在 database.config 中的内容,由发布系统实现,开发不再需要知道 DB 的连接字符串信息,取而代之的是获得一个 Key,在代码中配置这个 Key,由发布系统在发布过程中将这个 Key 翻译成 DB 连接字符串。

但第三代发布系统因为集成功能太多,自身权限过大,最终导致了一个重大的生产故障,该故障以后第三代发布系统连人带系统都被淘汰了。

取而代之的是第四代发布系统,被取名叫 Tars(又名 CD)。针对前三代发布系统最致命的漏洞:发布都是本地备份。Tars 引入了异地备份,即使本地磁盘整个被清空,仍可以从远程恢复,网站的稳定性又得到了质的飞跃。

02配置管理

 

其次值得一提的就是配置管理,携程的配置管理大体也经历了四个时代:

  • 第一代配置系统,将 web.config 做了简单的封装,提供 Web 页供开发人员做编辑,故有简单便捷等优点。对开发人员非常友好。
  • 第二代配置系统恰相反,将 config 的修改集成在发布中,直接导致 config 等于一个全局变量。这样避免了网站的重启,对用户很友好。但开发也就不用 config 了。
  • 第三代配置系统是颠覆性的,一改传统 config 的缺陷,改为在应用启动时通过服务获取配置信息,加载到内存中。当配置发生变化时,触发监听机制更新。但第三代配置系统仅支持开和关两个状态。
  • 第四代配置系统支持 Json 等主流格式,且优化了监听机制,并做了开源。

03SOA

SOA 在携程一直有着特殊的地位,在历史上也有更多有趣的故事。其演变和迭代过程值得我们细细品味。

传统的 API 调用,是一种网状结构,难以管理和控制,故障的排查也异常的困难。如果处理不当可能出现循环调用的情况,当服务端地址变化对客户端将是一场灾难。

携程作为互联网企业,吸取上述教训,在第一代 SOA 就引入了治理平台,统一管理服务的地址,并推出一个称为 ESB 总线的服务,所有调用方都请求 ESB,由 ESB 负责寻址和分发。

此种架构开始十分优美和清晰,但却有个致命的问题,ESB 总线是那个最大的瓶颈。那个年代,90% 的故障来自于 ESB 总线。

第二代 SOA 主要就是为了解决第一代 SOA 瓶颈问题,改为服务直连。SOA 仅作为治理和注册,在调用方应用启动时从治理平台获取服务端的 URL,并存到内存中,之后调用方就可以直接调用,第二代 SOA 的口号是“直连和去 ESB”。

随着时间的推移,公司逐渐意识到在 SOA 层面可以做更多,比如熔断、限流、动态路由等。

熔断即治理平台会根据服务提供方的异常情况,决定是否回应调用方的请求,如果服务提供方异常,有返回默认值、返回空值、直接报错几种可能。

限流则重点监控服务提供方的连接数,如果超过阀值,则开启队列模式,阻止之后的请求。

第三代 SOA 集成了大量实用功能,且做了大量监控、埋点,逐渐得到大家认可。

而进入无线时代后,H5 和 APP 和服务端的交互成为了业界研究热点,而 Gate Way 这次就呼之欲出了。Gate Way取代了原先的 Mobile Service 设计,加入了反爬和 Auth 认证,使得 SOA 的使用范围进一步提升。

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

分享道
相关新闻