组件开发 三

思考步骤：

    任务-组件-调研-组件

    1、接受任务后，发现没有类似的任务，也没有类似的组件。

    2、想想是个性任务还是通用性任务，是否需要组件化。

    3、组件化实现要先调研，不可直接用当前理解的技术直接实现。

    4、调研后，需要对组件的定义做调整。更通用即可。

案例：

    任务是记录某操作的执行情况。

    1、这个任务主要是对低频的重要操作进行记录，可以在操作失败时有办法查询到，与日志类似。但当前实现的日志设计上未考虑到统计和记录操作结果，组件化不可行。

    2、考虑到，支付回调、购买赠送礼品、与三方的发货信息同步、每日的定时任务、微服务启动时的配置加载等，都需要记录执行结果，及时发现问题所在。

    3、实现方法很多，直接操作数据库、通过redis实现、通过kafaka实现、redis 队列实现、mongodb也可以实现。

    4、实现逻辑，可以是操作开始插入一条记录，再在实现完后改变一下状态。 这种想法一闪而过（此处后来经过优化后被采用）。为什么呢，这里特别说下，两个弊端一个是不利于保存中间环节情况，再有需要查询定位，不利于做并发优化。

    5、接下来就是考虑采用每一步添加一条的策略，再通过定义每一步的数值来判断是否正常完成操作，如，开始定义为 0 ，成功完成定义为9 中间环节在0-9中间取值，最好别超过9步，步骤太多就会有太多的不稳定因素。 统计的时候通过 操作辨识groupby 分组， 取步骤最大值，和步骤最小值，最大值不为 9 就特别现实处理（最后考虑到这个更适合全部日志的处理及非实时的监控，主要考虑实施成本比较高）。

    6、考虑到对这部分操作的统计及展示也同时适用于其他操作日志，尽量形成统一的数据形态。

    7、特点持续日增数量，异常时才有用。使用频率少，近期1到3个月的甚至只有当天的才有用。

    8、考虑最终汇集到日志形态。缓存中判断异常数据存储，其他数据输出到日志或抛弃（产生操作同时日志记录）（此处考虑。。。？）。会漏掉调用失败的情况？如何取舍？（此处产生了犹豫）

    9、突然分析是不是，需要一个异常记录的功能？

    10、考虑到日志的处理及统计及监控等急迫度还不能此时实现。

    11、redis hset +  step ++ ->. end remove .    // 定时 判断 redis 是否有未处理内容， 未处理便是异常内容。

定时任务，可以另启动一个定时任务，hset key ， 至于中间环节，只能通过日志记录查询。 此处关注点在及时报警。

— 优势，redis操作快捷稳定不易出错，容易统计，及时性强，配合异步持久化组件。

如果不想持久保存，也可以保存到redis中， 用定时任务来判断，后发短信报警， 提供手工处理redis内容即可。

— kafka等的应用大部分暂时用不上，实施时间及部署都需要一定的时间和精力。不适合快速满足当前任务需求。

4、调研后，我们将组件功能定义为，

   初期想法：低频操作日志，使用kafka，为日志分析做基础。

   最终想法：异常记录及报警组件，用于，支付回调、三方发货同步。

具体实现会在后期文章中体现。