一、超乎想象

一入佛门深似海，这个系统刚开始做时只是觉得就一个普通的爬虫项目，有近百个爬虫项目经验的我，自然认为小菜一碟。当入坑后才发现事情没那么简单。商业公司提供流向查询的方式主要有：

1. 网站查询

   提供地址和账号密码，可随时查询，但是近500个网站登录方式==简直就是百花齐放，多姿多彩==，有的要验证码，有的还需要手机短信验证，有的还要扫码验证，而且导出的数据还不一定是标准的excel格式。有不少网站登录密码还进行了加密，花了不少时间才分析出加密算法。

• 软件查询

  需安装客户端软件，大概50多个。系统要求还有区别，有的要求win7，有的要求win10，各种环境要求，.net frameWork ,java JDK等，有的还在用foxpro...

• 数据直连

  对方不提供网站查询，也没有客户端，但允许你在他们内网电脑或服务器上安装一个数据直连插件，定时向我们的后台上报流向数据。大概有70多家商业公司采用这种方式对接，需要一家一家的沟通联系，有的还不一定配合，浪费不少时间。

  直连插件需要自己开发，要求适应不同的系统，不同的环境，还要熟悉对方的ERP系统及数据库（oracle，sql Server，mySql等），通常要自己分析出库、入库、库存查询的sql语句。有的商业公司没有IT人员，连ERP用的是什么都不知道，数据库信息更别谈了，需要自己想办法获取。

  虽然签了保密协议，但是这种对接方式其实不安全，插件在对方服务器里运行着，要是给心术不正的人，那真的可以说是==为所欲为了==。当然，部分有专业IT人员的商业公司，还会通过视图和权限做限制，这个相对安全很多。

  这种方式对接稳定性还是可以的，除非对方服务器较较差，或者对方不配合，把插件关了。

• API接口，大概10来个，这种最方便，拿到文档和密钥可以直接开干。但是也遇到了一些问题，比如广州交通物流有限公司做的接口很烂，对接文档连时间格式也没有说明，只能靠猜，提供的密钥信息也不完整（实际上对方没配置好权限，让我折腾了很久），还只能查询一个月内的数据！

• 其它

  小程序、邮件、FTP等，这些对接方式不超过10家，可忽略。

上面这些五花八门的对接方式，做起来非常耗时，既是脑力劳动，要分析各平台情况，又是体力活，一一核对字段，数据的准确性。曾经，我都想放弃了:cry:，还好坚持了下来!

nginx中转发某个后端应用，配置如下：

location  /web/sys/Login/ {
            proxy_pass http://ip:9999/back/sys/tLogin/;
        }

从配置可以看到，所有匹配了/web/sys/Login/的路径都会被转发到http://ip:9999/back/sys/tLogin/,即使==/web/sys/Login/==后面有xxx也会被转发，也会带上。比如/web/sys/Login/dingtalk/callback?code=xxx，转发到后端时，路径会变成 http://ip:9999/back/sys/tLogin/callback?code=xxx。

但是在caddy中，如果只是简单的将proxy_pass改为reverse_proxy，那么很不幸你将会在caddy日志里看到如下报错：

Error during parsing: for now, URLs for proxy upstreams only support scheme, host, and port components

大概意思是reverse_proxy暂不支持主机或端口后带路径的写法，查了一圈官方文档，再试了rewrite和uri两个指令，再不断抓包测试，终于实现完美转换，最终配置如下：

用cerbot自动更新docker里caddy的证书

一、背景

一个小项目，使用了ssl加密访问web服务。之前用nginx+zeroSSl来免费白嫖证书，每三个月换一次，用了大概一年左右，这次再续期时，竟然提示我You have reached the maximum amount of 90-day certificates allowed on the Free Plan.。好家伙，不给你玩了！

image-20230909230913151

为了这不赚钱的小项目去买证书是不可能的，转caddy去，之前用v2xx+caddy+ssl搭建科学上网就很好的解决了证书问题。不过那都是在主机里运行的，这次有点不一样，caddy是运行在docker里的。

一、项目背景

随着国家对药品流通的监管力度日益加强，药品生产厂家不能再直接供货给终端（医院、诊所、零售药店等），需要经过配送商业来进行药品的配送。而全国各省市有很多不同的配送商业，有的终端是从不同的商业公司拿货，有的终端是通过二级商业甚至三级商业拿货的，而且药品流通是需要一段时间的，这就给药企运营决策带来很大的挑战：如何快速掌握药品从出库到商业公司，最后到达终端的数据？如何知道商业公司手上的库存情况？如何防止串货甚至数据造假的情况。。。

要解决上述痛点，需要向每家商业公司获取流向数据，包括采购入库、销售出库以及库存情况，然后再做汇总，最后出报告。通俗点就是要向商业公司获取他们内部ERP或进销存里系统里的运营数据。由于每个商业公司使用的系统不同，技术也参差不齐，提供的流向数据格式也不一样。在没有==流向查询系统==支撑的原始时代，一个医药公司需要找3个甚至10几个员工，专门花一周甚至更多的时间来手工处理流向数据。由于是人工处理，避免不了出错的题，比如复制少了某一行，漏了某一个商业的流向，或者重复计算等，数据的准确率难以得到保障，医药公司的运营决策以及销售人员的业绩考核都难以实施！

了解甲方爸爸的需求后，决定开发一套自动化系统来解决甲方爸爸遇到的难题。在夜深人静中不是敲代码就是沉思苦想，经历数百个这样的夜晚后，我终于带来了乐琪药品流向数据查询管理系统，实现90%以上（大概500多家）商业公司进行自动化数据对接。系统上线后，甲方随时可以查询流向数据，掌握一线销售情况，并且极大程度减少了药品串货和数据造假的情况。
先上一张效果图：

image-20230913005732737

这才是真正的js获取任意两个日期间的所有月份

js setFullYear与setMonth的坑

系统上线后，突然收到妹子的反馈，销售汇总查询报表页面显示的月份与实际销售月份不一致！我随即登上系统，按妹子的查询条件，查询数据，然后再查询实际销售数据，果然如妹子所说的，数据有问题，难道逻辑出错？然后我再导出报表对比，数据没问题，那好办，应该是前端展示错了。

为了再印证一下判断，浏览器F12开发者模式，抓了一下包，返回的数据正常，那么这回肯定是前端的锅了。话说前端也是我写的 :laughing:。很快定位到getMonthBetween，之前偷懒使用CV大法从网上抄来简单改改就用了，还好没变成自主创新。