您的位置:首页 > 运维架构

基于阿里云构建可靠懒猪行IT运维平台

2017-09-18 14:16 162 查看
原文地址


背景

以阿里云为代表的云计算平台的出现,给IT系统的运维带来了巨大的便利,我们的项目在14年创立之处就在使用阿里云的ECS。2016年度,我们借助单台ECS实例和精心设计的软件系统,跑出了接近1个亿的销售额,但随着业务规模的快速扩展和IT系统的演进,运维架构也做出了较大的调整。


关键点

将业务分拆为一般重要、关键和既重要又关键的模块
搭建持续集成环境和预发布环境
敲除单点故障,为保证SLA对关键服务做冗余处理
对未来数据规模的预估,并定期归档冷数据
用好内存型NoSQL,例如Redis


业务分拆的原则

业务分拆的方法有很多,微服务架构是其中一种不错的思路之一。但分拆的原则,是先分拆一般但数据量较大的业务模块,其次才会对核心业务模块分拆。

懒猪行S2B系统中的一个比较典型的例子,是消息盒子。最初的设计思路是将其与主体系统耦合在一起,并且把数据与业务数据一起放到MySQL中。但后续评估数据量时,发现消息盒子产生的巨大数据量,占用业务系统的数据库IO开销,对业务稳定性存在潜在的威胁。于是我们决定将其分拆到单台独立的ECS实例中运行,数据库改用Redis,与主业务系统之间通过API接口交互数据。


负载均衡和跨境访问优化

作为一个面向B端商家的跨境旅游项目,要优先保障国内分销商家的访问,同时也要保障境外地接社和游客的访问。

在早期的方案中,我们将服务器放在香港,同时对大陆和境外访问。但随着业务的增长,大陆与香港之前的公网状况已经不允许我们这么做,于是我们把数据迁回大陆,在香港和大陆之间架设专线,然后通过香港的Nginx反向代理把境内服务器转发出去,这样同时满足了境内和境外的访问要求。


懒猪行IT系统架构图(简化版)




数据库读写分类和分库分表原则

对历史数据的处理

懒猪行系统目前的数据规模还不算太大,基于对未来数据量发展的预估和后期维护的敏捷性,我们会定期归档一年前的历史交易数据到MongoDB中长期存储,这样对系统整体性能提升有显著帮助,同时以独立的服务模块维护,向主业务系统提供数据查询接口。

数据库读写分离

读写分离是访问量较大的IT系统都会采用的技术方案,但基于业务系统的特殊性(频繁的数据导出)和对数据分析挖掘(产品销售的关联性分析)的需求,我们采用一主多从的方案。

使用Redis缓存高频数据

操作人员频繁的查看和修改订单,消费、退款等操作,虽然实现了数据库读写分离,但仍然有不小的压力;另外,诸多同行对接API,可能会存在集中式的订单创建。使用内存型Redis缓存,可以减少90%以上的数据库读取操作,并且对较集中的订单创建(例如双11这样的场景)和修改操作“削峰”,提升系统的整体性能和健壮性。

作者信息:刘远程,杭州懒猪行Co-founder兼CTO。知名信息安全企业产品经理出身,曾多次创业并担任技术总监和CTO,具有丰富的互联网产品设计、开发和团队管理经验。

原文地址

内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: