【系统优化升级】分布式系统架构升级

背景

项目使用的技术比较早了，所有功能都在一个war包中（jsp/js/java），防止出现单机故障，也做了高可用，通过redis做了Tomcat session共享。随着系统使用量、访问越来越高，用户使用卡顿严重，经过分析发现，占用系统资源主要在数据访问服务、数据ETL两个功能模块上。

数据访问服务功能主要是将系统集成的数据发布成可供调用的接口

数据ETL功能主要是按规定流程将数据从原始库表抽取、清洗、整合后进入目标库

这两大块功能消耗了系统的大量资源，导致用户在使用的时候，系统响应延迟甚至超时。

目标

针对数据ETL的调度时间错开，预估任务执行所需时间，合理配置分片数，调度周期。防止多任务同时执行，大量占用资源。就像双十一、618促销，这里所需的资源在平时也都是需要释放的，详情可以考虑弹性扩缩容相关概念。同理调度任务不执行的时候，为了避免浪费资源，把任务调度匀开。这是可以通过对运维人员进行规范化培训来约束的，但是，系统发布的服务，被第三方申请了之后，什么时间调用、调用频率多少，都是不可控的。紧接着，就有了小小的优化后的期望。

1，数据访问服务、数据ETL资源使用独立不能对其他资源有影响

2，当资源使用到瓶颈的时候，能快速方便进行扩容

3，系统业务更新时，不相互影响

按照初步的需求期望，我们必然需要将这两个功能拆分，同时拆分重构要适度，要权衡，防止过渡投入和后期运维困难。感兴趣的可以研究研究服务拆分原则，微服务等相关概念。

《高可用可伸缩微服务架构：基于Dubbo、Spring Cloud和Service Mesh》

《微服务设计》

《微服务架构设计模式》

《大型网站技术架构演进与性能优化》

《企业IT架构转型之道 阿里巴巴中台战略思想与架构实战》

《演进式架构》

业务流程

 参看上面的流程图，可以了解到，整个执行过程和数据库交互比较频繁，服务高并发访问时，业务库会成为瓶颈。随着调用量增长，日志量不到半年就有上亿的数据，数据库中对调用日志的任何查询统计都是灾难性的。

做了次压测，压200，就会有超时响应异常，平台响应缓慢。在服务拆分改造升级的时候，做好优化。

服务调用控制：

1）每日服务调用次数，如：500，或者不限制。

2）服务访问间隔多少秒，默认不限制0s，如果设置为5s，则表明两次调用间隔至少5s中，这里的间隔和每秒访问数注意区分。

改造思路

1. 鉴权信息缓存，从业务角度分析，用户申请访问授权后，鉴权信息生成后不会变，除非服务强制下架停用（删除缓存里相关联的授权信息）。下架停用后，原来的申请失效，需要重新申请。系统有集成ehcache缓存，但上述流程中，并未缓存验证信息。
2. 服务调用控制，优化原有系统通过更新库表上一次访问记录和当前调用次数来验证下次服务访问。
3. 服务元数据配置缓存，服务生成后，业务上也是不会有变更的。
4. 日志优化，原有系统操作日志流程为，服务进入后，先插入日志，然后鉴权、查询等，将结果整合后，再更新到数据库中。

系统架构图

 

 第一阶段改造完后，数据查询服务，在局域网通过Nginx做代理，挂载和移除可以通过Nginx操作。（Nginx配置的是轮询策略）

改造升级后，项目进入运维大概一年多的时间，每日的服务访问量最高接近200万，最少也有20来万，日平均访问量50万，而且访问时间段较为集中，大都集中在上午8点30到11点30之间。2个节点，可以轻松做到2000并发，同时不会对应用产生任何影响。服务器硬件配置、内存分配等这里就不细表。

可能有人会有疑问，就算不拆分，增加缓存、减少数据库交互、优化日志，原有系统应该也不会受影响，为什么一定要拆分？

核心原因是项目上老旧版本缺失源代码、内容定制化等导致很难再其基础上进行升级改造。不得不把最影响性能，但是又非核心业务的模块拆除来，和源系统解耦无依赖，达到重新部署启动就可使用。即使项目上无硬件负载均衡，也可以统一使用Nginx进行代理转发。

可能存在的需求扩展

1. 对系统数据查询服务做限流，当并发数异常激增时，系统依然稳定提供服务
2. 调用日志分析，提供日志分析看板（数据量半年约1亿）
3. 为了保障mysql能提供稳定服务，做HA和读写分离（shardingsphere）