论高并发下的高可以技术
分布式和微服务的关系随着科技的进步以直播卖货为代表的新的销售渠道也深入人心，新的销售渠道也日新月异，在这样的背景下本人所在的手机制造公司于2019年2月决定开发一套新的电商系统，该系统除了自营电商外还需要全面打通与各直播卖货平台、第三方电商平台、小程序等平台的数据流转，及协调后方相关部门进行高效的动作。本人以平台部门的核心成员加入其中担任系统架构师职务。本文以此项目为例，围绕系统高可用技术的主题，讨论系统设计过程中，根据场景实现情况，结合CDN内容分发技术、负载均衡等应用层、网络层以及数据库层多种常用的高可以方法，合理选择适应的技术来解决项目中遇到的问题并最终实现高可用目标。经过半年多的研发系统顺利上线并接受了检验。
本人所在的公司为南方某手机制造企业，这几年随着国家经济的发展以及科技的进步，移动互联网得到了长足的快速发展，以抖音、快手为代表的短视频平台也快速的崛起，直播卖货为代表的新的销售渠道也深入人心，新的销售渠道也日新月异。抖音、快手等各短视频平台也快速建设了相应的电商系统。直播卖货也成为了各公司新的销售渠道以及新的利润增长点。我公司在各大直播平台也有相应主播进行直播卖货。但是由于涉及的电商平台较多按传统的买家下单后公司需要到各电商后台去查询订单数据手动线下处理，这样严重的影响了发货退货等业务的时效，在这样的背景下为了适应新的业务发展和增强企业的竞争力，公司决定开新发一套新的电商系统。除了满足自营电商的需求外还需要全面打通与抖音、快手、天猫、京东、拼多多、小程序等平台的数据流转。及协调后方销售、财务、工厂、库存中心
、大数据中心等部门高效的进行数据交互。
在项目成立以后，我们立刻对本项目进行了需求分析，系统设计。由于在电商潮汐期将会面临巨大的流量，系统还要接收来自各第三方平台的数据流量。电商系统将不定期举行抢购等活动，因此系统在高并发下的高可用提出了很高的要求。
本系统根据主要使用场景及服务对象，最终将系统分为销售中心、转单中心、结算中心、履约中心、大数据中心、库存中心、售后维修等核心业务服务模块。销售中心及转单中心为系统中的基础模块需要7*24小时连续运行，即要满足自营电商的业务也要支撑起第三方电商平台的数据压力，同时能够经受住电商高峰期数据潮汐的涌入。总结下来，系统必须能够满足以下条件下的高可用：在电商高峰期或者举行抢购等活动时能够支撑百万级数据并发洪峰，数据接收并处理需要在5秒内完成；平常情况下能支持十万级数据并发量，用户的普通请求必须在3秒内得到响应。服务允许降级，但不允许中断。根据实际使用场景，要求系统使用分布式的部署使用多种高可用方案，并提供稳定的接入服务。本系统决定采用基于J2EE的分布式微服务架构进行开发，系统使用当前比较成熟的Spring Cloud全家桶进行开发。使用Eurake做为服务的注册中心，将每个服务模块进行独立开发并运行在独立的进程内，每个服务并采用分布式
部署在云服务器的容器内并在注册中心内进行注册，使用Zuul进行流量保护及限流。
根据本业务的特点，为了达到高可用的目标，首先在应用层用了CDN内容分发技术。CDN全称是Content Deliver Network即内容分发技术，其目的是通过现有的Internet网络中添加一层新的网络架构，将网站的内容分发到离用户最近的网络边缘，CDN系统能实时的根据网络流量和各节点的连接，负载状况以及到设备的距离和相应的时间等综合信息，将设备的请求重新导向离设备最近的服务点节点，使用户可以就近取得所需的内容，解决了Internet的拥塞状况，提高了用户访问网站的响应速度，从技术上全面解决由于网络带宽小，用户访问量大网点分布不均等原因，使用户访问多站的速度得到很大的提供。
当电商销售平台添加了新的需要加速的数据时如商品信息、配置信息等，将这部分数据推送到CDN内容分发系统，内容被迅速的分发到各网络节点上，用户访问时直接从最优、最稳定的节点上快速获取数据。这样大大缩短了用户获取数据的时间，减小了后端服务器的压力，从而有力的保证业务的稳定运行。
在服务部署时，我们采用了负载均衡技术来实现高可用目标，众所周知负载均衡技术有多种实现方式，1)基于http的负载均衡，2)基于DNS的负载均衡,3)基于NAT的负载均衡，4)基于反向代理的负载均衡。其核心其实是冗余持，集技术，由多个集同时对外提供一致的服务，使负载压力相对均匀的由不同的服务主机承担，同时也从性能角度增加计算资源，资源越多可用性越强。当集中的一台主机出现异常时，在这段时间内将由其它主机接替它的工作直到该主机恢复正常，这样大在提高了系统
的高可用性。我们系统的每个微服务都部署在云服务器的容器内实现的。每个容器间是相互隔离的，每个容器有自己的文件系统，容易之间的进行不会相互影响，能区分计算资源，相对于虚拟机，容器能够快速部署及占用资源少。我们将每个微服务打包成一个容器镜像。容器可以快速部署，当集中的服务出现压力时可弹性的增加计算资源。我们使用Kubernetes来管理我们容器，Kubernetes是一个开源的Linux容器编排引擎，它支持自动化部署大规模可伸缩、应用容器化的管理。然后通过内部的负载均衡策略，实现一组应用实例的管理、发现、访问。综上，通过负载均衡的方法，在应用层角度实现了高可用。
系统数据存储是依靠关系型数据库系统，为了实现数据接入读取的高性能、高可用，采取适当的技术是必要的。数据库高可用性通常包括如下几项：1)主从复制，2)分区，3)分表,4)分库,5)缓存。在本项目的应用场景中，需要解决的是系统高并发情况下，数据读写必须保持高可用。在对数据库高可用时，我们采用了分库分表以及Redis缓存方式来解决的。分库分表是通过将一张大表分成若干库中的若干小表，读写业务压力被多个库中的多个表进行分担。实则是通过IO性能的提升，扩大读写能力，从而提升可用性。我们将“订单数据”及”维修工单”数据进行水平分割成十个库，从0号库到9号库，每个库里包含10个同样结构的表，从0号表到9号表，根据用户ID对100求模的值，并将数据写入对应的数据库表中，如果用户ID除以100余36，则将该数据存入3号库的6号表中。这里我们使用轻量级的Java分表分库框架Shard-JDBC来实现数据分库分表。当系统数据洪峰来临时，数据库的写入操作超过设定的阈值
时，接入端应用程序先将并发数据先写入缓存内，能瞬间减轻数据库的负载压力，使其正常运行。缓存接收并发数据的同时，也以轻负载的方式将数据同步到数据库内。同时我们使用Redis非关系型数据库实现各节点的数据共享保证各节点数据的一致性以及促销时的数量控制不超卖。通过以上多种应用方式，在数据库层面也较为成功的实现了高可用目标。
在本项目的建设中，我们运用了多种高可用技术和方法。较为成功的实现了系统的高可用目标。经过一年多的设计开发并成功上线，并顺利的通过了验收。通过该系统的建设，本人也进一步明白了系统高可用设计的重要性，也为以后的工作积累经验。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。