由于快递行业的高速发展，每年购物“节日”的层出不穷，每天的快递数量越来越多，朋友公司是做快递驿站系统的，最近就碰到了系统上的瓶颈，由每天处理几万件到现在每天要处理百万件，到了双十一这样的节日，可能最大峰值要达到每天处理千万的量级别。
目前的系统是由Spring MVC + Spring + MyBatis 技术构建的，数据库用的是 mysql，对快递订单根据月份进行分表，平淡季节还能勉强维持，一到618，双11这样的节假日快递数量急增的时候，导致每张表中的数据分布不均，清淡月份数据很少，繁忙月份表中数据超过亿级，处理的速度明显变慢，甚至出现了执行业务逻辑超时的严重事故，导致系统崩溃，驿站不能入件，客户也无法取件的窘况。
为了改善目前的情况，我们将定制了三步走的方案。
一、优化现有系统，让老系统继续能处理当前业务，给新系统的开发迎来时间
由于快递业务的特殊性，现在连过年的时候快递都开始不放假了，所以驿站系统是不能停的，那要修改软件系统去适应目前可能达到一天千万级的，每月亿级别的数据处理流量，那是不可能的事情，修改的地方太多了，加之时间紧急，最终决定还是先考虑在硬件上进行扩容，原先系统也是搭建在阿里云上的，通过对服务器的扩容，Redis的优化，SQL语句的优化，暂时能缓解，但是随着每年快递数量的不断增长，现有系统始终是无法承受的。因此在维护现有系统的情况下，使用阿里云云原生平台对系统进行重构和升级。
二、利用阿里云平台技术对系统进行重构和升级（使用微服务架构，开发新系统）
1、对目前的业务逻辑进行拆分，将原有的SSH框架替换成 微服务框架；
根据现有的业务逻辑和新增的产品需求进行梳理，拆分成多个服务，利用微服务架构进行新系统的构建，画出架构图（如下图），整理出所需要的技术点，并利用阿里云平台所提供的先进技术，更加方便简洁的实现本次重构和升级。
之前系统是单体架构，事务处理也比较简单，针对增删改的操作，直接用Spring提供的@Transactional的注解即可，系统改成分布式微服务架构后，数据要进行分库分表，要保证一致性，事务处理的方式 不仅是单纯的用 注解即可完成，分布式事务处理的方式有很多种，开源产品有Himly、Seata等项目，各有各个的优势，最终我们讨论决定的是使用阿里云的全局事务服务GTS来实现分布式事务处理，保证数据的一致性。
GTS的开通和使用，请参看以下文章：
使用阿里云的GTS，进行全局分布式事务处理
2、对老数据库的数据进行梳理，哪些是需要分库分表的，怎么划分？哪些数据是热数据，哪些是冷数据，怎么存储？
针对目前每天需要处理几百万的订单数据、通知数据、日志数据等，还要考虑哪些老数据需要迁移到新的平台，哪些数据是需要分库分表的，如何进行划分，技术上用mycat、shardingjdbc还是用PolarDB-X组件进行分库分表也需要选型确定，哪些数据是需要经常查询的数据，哪些数据是不太用的数据，如何保存等等，技术上选用什么产品进行保存都要明确。
因此一个系统的重构和业务的复杂性密切相关，尤其要梳理好业务逻辑，明确数据的用途和分类。
经过讨论，将数据分为三类：
1）热数据——3个月之内的数据；实时操作
2）较冷数据——3-12个月的数据；
3）冷数据——12个月以上的数据；
热数据存储选用阿里云的PolarDB，数据量大的表，使用PolarDB-X中间件进行分库分表；
热+较冷数据存储在 阿里云的AnalyticDB中，实时从PolarDB中同步，使用QuickBI组件对数据进行分析和处理，展示完美漂亮的图表；
冷数据（基本不查）存储在HBase中，用于降低费用成本；
关于具体的方案，请参看以下文章：
使用阿里云的PolarDB数据库进行数据的存储和管理，并使用PolarDB-X中间件进行分库分表
3、现有自己搭建的MQ队列 替换成 阿里云上的 RocketMQ；
之前的老系统是运维在ecs中自己搭建的RabbitMQ，虽说没什么大问题，但也碰到了一些难以排查的小问题，而已也要运维去查找问题所在，不仅费时费力，沟通也费心。使用阿里云云原生的RocketMQ中间件，稳定性好，使用性能高，提供丰富的消息类型，同时安全性又高，也减轻公司的运维压力，所以决定，消息队列使用阿里云的RocketMQ组件实现。
关于具体的RocketMQ中间件的使用，请参看以下文章：
使用阿里云的RocketMQ中间件，进行消息的通知和处理
4、原有是运维搭建docker的方式进行系统的部署，现在通过EDAS中结合ACK容器进行一键式部署；
系统由之前的SSH单体架构，更新成SpringCloud + Nacos的微服务架构，部署的时候，Nacos这样的产品需要运维去买3台服务器搭建3个节点，而且万一出什么问题，还需要排查，耗时耗力，讨论决定使用阿里云的EDAS进行开发部署，EDAS优势还很多，比如EDAS上面有命名空间，可以方便不同开发人员创建自己的命名空间，调试环境逻辑隔离，服务不会乱串，调试更加安心省事，再者也允许开发人员，使用最新的Java开发IDE IntelliJ IDEA安装Alibaba Cloud Toolkit插件，可以直接部署到EDAS进行调试开发，非常的方便省心。
具体EDAS的使用，请参看以下文章：
使用阿里云的EDAS进行微服务的开发、部署和监控
5、通过云效平台进行DevOps管理，通过ARMS平台进行监控，及时发现问题，简化运维人员的工作量；
老系统的问题一直都是由运维工程师去维护和管理的，发现问题后再和开发人员沟通，DevOps重点突出软件开发人员和运维人员的沟通合作，通过一些自动化流程来使得软件构建、测试、发布更加快捷、频繁和可靠。DevOps希望做到的是软件产品交付过程中IT工具链的打通，使得各个团队减少时间损耗，更加高效地协同工作。很多专家们一起总结出了下面这个DevOps展示图，我的理解就是把开发和运维之间的围墙打通，形成闭环。
要提高运维和开发人员的工作效率，最终决定使用阿里云的云效来进行软件项目的统一管理，云效就是企业级一站式DevOps平台，提供从「需求->开发->测试->发布->运维->运营」端到端的协同服务和研发工具，帮助开发者提升研发效能，持续交付有效价值。
关于云效的使用，请参见以下文章：
阿里云云效(1)——简介和基本使用介绍；
阿里云云效(2)——测试管理Testhub；
阿里云云效(3)——流水线Flow；
应用实时监控也是运维工作的重要环节，之前老系统都是运维自行搭建的，新系统我们决定使用阿里云的应用实时监控服务 ARMS 来协助运维人员，对软件项目进行实时监控，能有效的帮助企业实现全栈式的性能监控和端到端的全链路追踪诊断，简化运维人员工作量，及时定位到问题所在，方便高效。
关于ARMS的应用，请参见以下文章：
使用阿里云的ARMS平台进行业务的实时监控
三、新老系统切换，数据迁移，实现平稳过渡
新系统开发完成后，订单等重要的数据通过DTS方式切换到PolarDB中，12个月以上的数据迁移到HBase中，3-12个月数据同时备份到AnalyticDB，用户数据、门店数据的迁移，则由用户自行一键切换，方案：在老系统中登录时，提示老系统剩余使用时间，用户点击按钮切换，数据自动切换到新系统，老系统数据停用，这样一来让用户了解到新老系统切换的时间，再者，用户数据不用同时迁移，由用户自行决定，操作方便节省时间，同时避开切换的数据拥堵情况，最终达到用户提前知晓，新老系统切换，数据平稳迁移过渡的目的。
总结：整个快递驿站项目重构是从2020年9月开始，我利用业余时间参与了项目的开始阶段，协助分析问题，理清思路，对接产品需求，进行新系统技术架构的选型和微服务框架的搭建，整个新系统产品线中使用到了阿里云云原生应用平台，借助该平台，通过产品选择或组合搭建，轻松完成应用与运行环境解耦，研发运维效率10倍提升，应用全生命周期托管及诊断运维智能化，让企业一站式享受云计算弹性及分布式架构的技术红利。
具体的技术文章将在后续的文章中展开介绍，欢迎各位大神大牛一起讨论互动。