【总结】前置机项目的总结

学习这件事，不在乎有没有人教你，最重要的是在于你自己有没有觉悟和恒心。

祝大家都能抢到回家的年票!

何为前置机

前置机要分为2个部分解释：前置和机。

机：一个可以运行应用程序的服务器，可以是windows服务器，也可以是linux服务器。
前置: 由于商家提供的服务器并没有公网的IP和端口，我们程序写好之后，要想连接到商家的数据库，只能把应用部署到商家给提供的服务器里。也就是说程序前置到商家服务器里。前置机程序的业务很简单，就是获取商家的商品、价格、库存、促销、会员等数据通过中台提供的http/https接口，传输到云中台系统。

为什么要总结前置机项目

前置机的业务的确很简单，就是查询数据-传输数据，没有特别复杂的业务。但是就是这个简简单单的业务，却包含了一些技术思考和业务思考。用一句俗语来说，就是“麻雀虽小，五脏俱全”。因为只有保证了前置机的可靠、稳定的数据传输，才能及时保证商家在线数据的准确性，才不会造成商家的损失。所以如何写好一个可靠、稳定、快速的前置机数据传输系统，也是需要我们不断思考和实践的。

目前经过多次迭代，基本是自己从0到1的设计、开发了云前置机，所以此次想分享下前置机的整体迭代过程，也算是一个自我的总结。特别感谢下环宇大哥，给我提供了很多技术选项以及架构上的设计思想。才给大家展现出一个可靠的云数据传输前置机。下面我将从业务上和技术上，将我开发过程中设计思想记录下来，给大家分享下，可能不是最好的，但是是目前最适合前置机的。本文不涉及具体的技术讲读，只是简单介绍下为什么用这个，而不是用其他？

前置机技术选项

SSM与 springboot的选择

SSM的缺点：

1 大量的XML配置
2 Spring与Servlet API 耦合，难以脱离容器（如tomcat）独立运行，所以每次都得在前置机上在部署tomcat容器

springboot2的优点：

1 Spring Boot可以以jar包的形式进行独立的运行，内嵌的Servlet容器,不需要独立的部署tomcat容器，可以让项目快速运行。部署简单
2 Spring Boot提供了一系列的starter pom用来简化我们的Maven依赖
3 自带应用监控
4 Spring Boot 会根据在类路径中的 jar 包、类，为 jar 包里的类自动配置 Bean，这样会极大地减少我们要使用的配置
5 无代码生成和 xml 配置。Spring Boot 不需要任何 xml 配置即可实现 Spring 的所有配置。

最后选择springboot,开发、打包、编译、部署、运行就是比以前很香。

swagger2 和前端页面的选择

自助收银时代，如果想随便同步传输任务，需要单独写页面，由于我前端水平不好，只能写出很简单的页面，这个都是需要开发时间的。

后来了解下， swagger2 一个在线API文档，并且内部支持curl的http访问，结合我需要查询数据、手动同步数据的实际情况，云中台前置机便选择了swagger2。只需要简单的配置，不需要写什么页面，便可生成在线API文档，并支持离线导出。

如果有的商家提供公网IP和端口，那我们开发人员或者产品运营、测试同学也可以随时随地的访问此页面，查询对应的商家底层erp数据。大大的提高了开发效率和运营效率。

最后选择swagger2.

数据库持久化重试与spring retry

因为传输数据的时候，可能由于网络原因、连接超时等网络异原因，导致数据传输失败，这个时候就需要重试。

spring retry

springboot整合spring retry 重试机制

Retryable方法只有直接通过代理对象调用时才会生效，通过其他方法间接调用不生效（所有基于AOP的注解都一样）温馨提示：在Spring中，只有需要用到Aop代理的类才会生成代理对象，不需要Aop的直接返回原生对象

一、基于JDK动态代理时，只代理接口中的方法，所以需要注意以下事项

@Retryable或者@Recover修饰的方法一定要在接口中声明
@Retryable可以修饰在接口的方法声明上，也可以修饰在方法实现上
@Recover注解只能修饰在接口的方法声明中（具体原因尚未分析）
【Recover修饰在方法实现上时会提示: Cannot locate recovery method】

二、基于CGLIB动态代理时，可以代理目标类所有可继承方法

@Retryable或者@Recover修饰的方法必须可以被继承（不能用final，private修饰）
@Retryable与 @Recover直接修饰在方法实现上

依靠数据库的重试

在数据库加了个重试次数（tryCount）与同步状态(synStatus)字段，当时失败的时候，重试次数+1，重试到指定次数还失败的话，便不在重试，DB记录失败原因，发出告警邮件,通知项目负责人处理。

最后选择DB重试

log4j2远程日志

在商家前置机查询日志的缺点：

慢、卡由于要先通过向日葵或者tm等远程连接工具，连接上商家的前置机，然后才能打开日志文件查看，但是由于网络问题，连接上前置机是很慢的。打开日志文件也很慢，
最长一次从连接前置机到打开日志文件用了8分钟左右。
然后即使我们好不容易打开了日志文件，查看的时候也是很慢的。所以有了想把前置机日志同步到我们自己的服务器的想法，因为我们日志系统查询是基于elk的，可以快速的查询日志。

所以便接入了log4j2的http传输日志,按照商家账号分割日志文件

 <Http name="Http" url="xx">
            <JsonLayout properties="true"/>
            <Property name="orgCode" value="123456" />
</Http>
复制代码

spring quartz与spring boot的@Scheduled

之前集成的是spring quartz,每个业务模块都需要手动的写一些代码处理。

spring quartz

最后选择spring boot的@Scheduled，只需要简单的注解配置和并行执行任务的配置，就可使用。

spring admin 监控

ring admin 是监控springboot项目，可以很方便让我了解前置机的运行情况以及配置情况。另外可借用其动态修改日志级别的功能，在出问题的时候，可以切换日志级别，查看日志

本地缓存的选择

本地缓存：这个是因为有一个全部刷全部门店数据的后门功能，考虑到其他人误点的话，就会导致数据全刷一遍，所以加了个邮箱验证，提前生成一个验证码放到缓存里，如果用map做缓存的话，还要考虑缓存失效等问题，所以便用了Guava 的cache。

使用google guava做内存缓存

限流

因为初期各个业务系统的性能问题，前置机大量数据的传输，会超过他们业务系统的处理承受能力，基于此考虑前置机在调用http接口传输数据的时候，也做个限流，保证调用服务的正常运行。便选择了Guava的RateLimiter

使用Guava实现限流器

运维维护上的减负

springboo2 外部配置文件

之前的时候，把商家每个数据库连接地址，都在代码里配置，这样每次上线一个新的门店的时候，都需要反复的配置-编译-打包-远程传送文件-部署启动，这一个步骤，现在采用外部配置文件的形式，项目启动的时候引用外部的配置文件，不采用项目内的配置，这样有新的门店的时候，只需要修改文件，重启应用即可。而且不管研发、还是项目经理都可以简单的操作。也减轻了开发人员的负担。

 
 -jar D:\jddj-2\jddj-start.jar --spring.profiles.active=product --spring.config.location=D:\jddj-2\application-product-2.yaml

复制代码

远程查询erp数据

有时候，我们需要查询商家底层erp数据库的原始数据，之前的话，都是项目经理提供商品编码给到研发，然后研发在连接到前置机系统里去查询，然后在返回给项目经理。

这一来一回需要耗时5分钟左右，随着商家接入的越来越多，研发个人维护的时间也越来越长，所以开发远程查询很有必要。后决定通过轮询的方式，开发远程查询。

开发过程idea插件推荐

1 MyBatisCodeHelper-Pro

这是一款我认为最好的mybatis扩展插件，虽然收费，但是也就是一包烟钱。目前我们组我已经推荐了3个人使用。

2 Jrebel热部署插件

这个真的真的特别好用，在我用springboot开发的时候，我不需要每次频繁的关闭重启项目，我修改完东西，直接重新编译下就行，大大的提高了效率。

3 Maven Helper 分析maven以来冲突

解决maven冲突的插件，一直在用。

4 GenerateAllSetter 插件

这个是一键生成对象的所有属性set方法,使用Alt+enter，即可。

君辰 | 文【原创】

互相讨论、共同进步

文章如有失误，请指出。

大周末还是祝大家都能抢到回家的年票吧!