1、企业开发中，经常需要导入一些Excel数据，并且要管理导入的历史版本，本服务主要抽象出一下几个模块：模板、主表、关联明细表、历史记录等；前端先将Excel上传至OSS，后端根据Ur拉取文件至本地，然后根据模板取解析Excel值内存，最后导入数据库，记录历史版本 2、本人独立负责改服务的所有设计开发工作 3、难点是导入的过程中，会遇到一些非法格式的数据行，导致服务出异常，解决方案是在正式导入前，先根据模板对Excel数据进行格式校验，通过后才能导入

1、客户使用我们平台的产品，需要将其组织架构数据定时同步至我们系统。主要分为数据采集、数据对比分析入库，以及定时任务模块 2、本人独立负责所有模块的设计开发工作，定时任务采用阿里云效实现 3、难点是数据量大的时候会导致Job执行超时，以及需要掌握转换与作业的区别，解决办法是分批执行对应的转换，需要顺序的用作业，否则尽量用转换，保证其性能

1、背景 平台内的原消息通知服务有以下 2 个弊端：第一，配置非常麻烦，需要配置五六张 MySql 表，并且关系 错综复杂；第二，设计思路及架构老旧，维护费劲，日志信息也比较欠缺，出错之后不易定位问题。为了解决以 上问题，决定重新开发一套简单高效且可扩展的消息通知架构。 2、设计 消息通知的本质是：把消息组装好，通过一定的发送渠道，发送到指定的终端，并记录发送日志。 基于此抽象出以下模型：消息模板、数据 Provider、发送器、全局变量、发送日志、布局页。采用订阅 RabbitMQ 消息实现逻辑解耦，以 MongoDB 作为存储。每条消息包含一个模板编号，根据编号得到消息的各组件：模板内容、 模板数据、发送通道、发送人、抄送人等。在收到消息后，需要对其进行一系列的合规校验，如模板是否存在、收 件人是否存在及合法、附件大小是否超限等，这里采用了责任链模式实现。消息渲染使用 RazorEngine 组件，获 取发送器对象采用了简单工厂模式 + 反射 + 缓存 实现(目前支持：邮件、短信、极光推送、*、Webhook、 站内消息，并易于扩展)，具体发送器依赖一个消息对象，而整个构建消息对象的过程采用了 建造者模式 实现。 3、遇到的挑战 问题描述：有个租户需要在每周四下午 5 点，给指定用户发送付款通知邮件，用户的数量大约 1 万 +，这段时间集中式的向 MQ 推送消息，导致 MQ 有大量消息堆积，而且影响到了其他场景下的消息发送，最要命 的是同一条消息会推送多次，这就导致很多客户收到了很多重复的邮件，遭到客户投诉。解决方案：起初采用增加 服务节点数量，来增加消费端能力，但同一消息推送多次未能解决（最后查到是阿里云 RabbitMQ 组件那段时间有 问题），后面将这一业务场景单独调整为引用 DLL 库，直接调用发送方法，构造消息对象采用 享元模式（消息 对象池思想）即保证了性能，也解决了以上问题。 4、项目业绩 通过重构之后新的消息通知架构，在消息配置及维护方面，效率提高了 70%，新租户的消息通知需 求上线时间比原来缩短了 50%。目前公司 80%场景已改造完毕，服务运行一年多时间，经过了几次迭代打磨，功 能变得越来越强大，能满足客户各种刁钻的需求，并且多次得到老板和客户的好评。