中间件能力

Posted 2021-04-10 CoderBuff

    中间件指与业务不相关的软件或者系统，例如数据库、消息队列，这些都是与业务不想关作为公共服务使用的软件、系统。

    当然从业务角度来阐述中间件，也称为“业务中间件”。例如，电商系统中有N条业务线，但他们最后都会通过“订单系统”进行下单操作，这里的“订单系统”实际上也可以理解为一个业务中间件，或者需要把它抽象称为一个业务中间件，以便能在新增业务线的时候，“订单系统”能够快速支撑，而不必进行二次开发。

    上面都是从宏观角度对中间件的理解，具体到编码的实际工作中，一般观点认为能写中间件的人都是牛人，认为写业务代码都是低级别的开发工作。我借用“中间件”的观点，认为无论是从事的中间件开发，还是业务代码开发，中间件能力都是必不可少的一个抽象能力。

何为“中间件能力”，我在这里把中间件能力定义为“抽象能力”以及扎实的基本功。

例如以下几个场景：

    1. 重要的业务系统通常都会有报警系统，业务出现可用率下降的时候会以邮件、短信等形式通知到相关人员。这就需要对关键方法、代码加入监控。这个监控如何做实际上就是我本文提到的“中间件”能力。通常这会以工具包的形式嵌入到业务代码中，而如何“嵌入”则是最大的考验。如果能最大限度的避免侵入到业务代码，则可以使用Spring的AOP来完成这一工作，当然也可以通过表达式来完成这一工作，但我相信通过注解虽然有一点侵入性，但也带来更高的可读性。

    2. 日志。日志是每个系统中的重中之重，你是否陷入过过遇到问题时因为没有日志，还得去加一行日志重现打印出来的尴尬境地。日志怎么打也是一个“中间件”问题，日志同样也是和业务不相干的一个模块，通常的做法是在类中通过log4j定义一个日志变量，在需要打印的地方打印出来。RPC调用中最重要的日志莫非与出参、入参，在每一个接口方法中显示的写下logger.info，甚至还需要判断是否开启INFO级别的日志才打印，无疑又是无限的重复工作，并且会伴随着不同的开发人员，日志格式也层出不穷，甚至出现在打印日志的时候出现空指针异常。

更好的方式，原理同样同上，通过使用Spring的AOP特性，在这里结合注解将入参日志剥离出业务系统。

    3. 接口返回值。RPC调用，无论成功与否，作为被调用方，我们都需要将详细的调用结果返回给调用方，便于调用方排查问题解决问题以及对于不同的返回结果进行相应的处理。RPC调用不同于传统的垂直架构模型，一层一层往下调返回信息也单调，RPC调用需要有统一的返回类，类中有调用结果、错误码、错误信息等。

    以上只是简单举了3个小例子，这几个场景看似很普通，和“中间件”这种高大上的沾上边。而在这里，我的理解并不是只有写中间件才能写出大牛，大牛同样是从这些简单的场景一点一点码出来的。并且，可以看到上面的例子用到了AOP，而AOP在实际开发中用得并不是那么多，至少不是在工程中所占的比例不大，用的机会少自然就觉得难，另外有泛型的使用，这些都是难点，同样也是重点。

    接下来我会顺着这个“中间件”主题逐一解析如何构建“中间件能力”。