618将至，电商企业如何构建＂新基建＂应对流量洪峰？

（原标题：618将至，电商企业如何构建＂新基建＂应对流量洪峰？）

这个场景，很多电商人并不陌生：

在大促活动中，若订单系统出现故障，从顾客抱怨，到层层上报，再到故障排查和处理，2个小时过去了。但在这2个小时里，成百上千的顾客在竞争对手那里购买了产品，损失严重，还有被媒体曝光的风险。

不得不承认，即使是灾备能力最强的 IT 环境，也必然会在某个时刻遇到问题。当这些问题发生的时候，解决问题的速度就是决定企业综合实力的关键。

下一个"618"大促就要来了，这对于电商平台来说，是个让人激动却也提心吊胆的日子。电商业务的特点比较明显：短期指数级业务波峰，从前端展示、业务处理、库存变动等方面都需要全天应对海量用户访问的冲击。而支持电商业务的关键，就在于后台系统是否具备稳定性、可扩展性和安全性。

同时，随着5G、VR、AR、AI 等新技术愈发广泛的应用，更高品质的内容、更强烈的社交属性、观众使用场景都出现突破性扩展，这也将促进用户数量和使用时长的进一步增加，对基础技术能力的要求进一步提高。

电商上云，不得不做

多数平台创业之初的重点是业务的快速上线，会选择简单粗暴的低成本管理方式，一个网站、一台服务器就够了。但随着业务体量的大幅上升，企业开始堆硬件、做结构化拆分。然而，资源层容量和性能的瓶颈终会到来，这该怎么调整？

平台调整组织和技术架构的原则是：

1.应用层采用服务框架

2.系统层采用异步消息

3.数据层可以无限扩容

在应用层，一个简单的电商系统，包含用户模块、库存模块、订单模块、支付模块。创业之初的单体应用复杂性高、交付效率低、扩展性和可靠性差，并且技术栈的限制也在阻碍着技术创新。而在微服务架构中可以划分出不同的业务板块，每个业务板块都可以独立开发、部署和上线，对应独立数据库，由独立团队维护，各司其职。

在系统层，异步消息系统可以使主要业务异步化，增加系统的容错性，避免因业务调用接口不成功导致的交易失败。当用户下单时，仓储和配送对实时性要求并不高，订单消息可以发到异步消息队列系统，若投递不成功可以等待下次投递。

在数据层，为了应对瞬间的海量访问，系统需要极强的可伸缩性。随着数据量增大，需要对数据库进行弹性扩容，灵活配置资源、匹配业务需求。

基于电商行业的业务特点和技术诉求，电商上云是需要先解决问题再开源节流的。而理想的云计算是随取随用的 IT 基础设施，云计算服务的性能决定了电商企业能提升的效率幅度和降本程度。那么，企业该如何选择？

·一看云厂商的底层能力：是否在存储、服务器领域有优势，是否具备自主研发能力，整体的机制、运营模式、服务质量是否优质，稳定性如何等；

·二看性价比：电商业务场景需要满足的弹性伸缩、存储于计算分离等需求，是否能通过更低的价格实现；

·三看服务的持续性：包括网络性能、稳定性、安全性等方面。

"弹性扩容 + 存算分离"，解决电商的技术资源瓶颈

从资源到应用，端到端弹性扩容怎么做？

虽然云的确在成本、扩展、灵活性、快捷等方面有很大优势。但是，对云产品、云架构的灵活运用，是有一定技术门槛的。这时，如果可以根据实际业务需求按需进行存储和计算资源的弹性伸缩，就能使资源利用率大幅提升，也就是我们说的容器化改造。

从技术角度，容器化改造是对应用整体微服务架构改造，再容器化，这样做可以带来如下好处。

·单独扩展：拆分为微服务后，可单独增加或缩减每个微服务的实例数量。

·提升开发速度：各微服务之间解耦，某个微服务的代码开发不影响其他微服务。

·通过隔离确保安全：整体应用中，若存在安全漏洞，会获得所有功能的权限。微服务架构中，若攻击了某个服务，只可获得该服务的访问权限，无法入侵其他服务。

·隔离崩溃：如果其中一个微服务崩溃，其它微服务还可以持续正常运行。

整体应用容器化改造的流程包括6个步骤：应用分析、准备应用运行环境、编写开机运行脚本、编写 Dockerfile 文件、制作并上传镜像、创建容器工作负载。具体流程图如下：