（这几天比较懒，几天的笔记一块写了）
吐槽系统架构的一个设计
竟然把数据库异常给埋了，不告知你异常，就执行结果返回错误值。异常内容在哪里看呢？文本日志里面看。
虽然，把程序的异常拦截，给用户友好的提示，是一种标准的程序设计。而这个场景不一样了，直接把异常给埋了，程序没法知道，只能开发人员去看日志。
换句话说，数据库异常有两种可能：
（1）SQL语句错误，这种异常是不允许存在的，开发过程就必须处理掉的，这类异常影响不大。
（2）数据库连接失败：这种因数据库环境问题造成的异常，是有可能（不定时）会出现的，这类异常不告知程序，程序就没法直接友好的提示给系统管理员了。除非配套日志分析系统。
另外呢，数据库异常被埋，对数据库事务的操作很有影响，就是每次要对返回值做判断，才能决定是否回滚之前的数据库执行。而如果数据库异常不被埋的话，直接抛出，程序可以根据需要在适当的位置catch和回滚之前的执行，而不必每次返回值做判断。
虽然吐槽，但这个架构设计还是有自己的理念的，读写分离和主库+扩展库模式等，还是有自己的优点的，不过我不习惯而已吧。
至于为什么吐槽了，我周四时候被误导了。
周三时候需要排查数据出不来的原因，但网络隔离，不能直接debug，只好从远程导了一份数据过来本地还原处理。而我本地数据库，非公司开发测试库，没有同步更新，存在数据表缺失的情况。
结果呢，周三导入数据后排查出了问题，周四要修正程序的时候，我忘记切换回公司开发测试库了，运行程序的时候，页面一直出不来数据。我蒙圈了，因为就简单把原先发送的数据从200改成700左右，功能就不支持了？然后一直加载中，感觉特别灵异，然后做各种性能优化，还是没效果。
跟H公司的联调催得有点急，我也就先硬头皮把生成的数据报文发给H公司的X。
幸好给数据给他，然后他发现问题了，说数据跟昨天的一样的。
what？
我才记得，我用的是本地电脑库，不是测试库。再（没经验）看一下异常日志，才发现里面一堆异常内容。
因为我本地不是最新的表结构，生成报文的时候，一直报数据库错误，系统肯定慢了。
哎，一则架构设计的问题，二则对这个架构使用不习惯。
一事一毕，多事二（懵）逼
这几天事情挺杂的，我本想一件一件事情解决了，这样效率高点。因为H系统涉及多方，想优先解决。
结果S系统要求改航班到达提示，M系统还在催进度，L哥的一个项目要服务器数量估算。
我开始微信跟L哥说晚点再给他服务器数量的估算，他同意了，结果下午又过来催问。
反正搞定了，但工作时候，多件事情切换真累。
我是不是有毒
跟H公司联调一系统，对方公司有网络规定，不能电脑微信。有问题，因为手机码字慢，就直接微信语音电话。
我就不习惯了，反手给他推荐了蓝牙键盘，可以连接手机打字那种。
结果，他真的买了。
后面，又跟他推荐蓝牙鼠标，他拒绝了。
凌晨故障电话
今天凌晨S系统运维给我电话，说数据出不来。
通过电话一通指导，搞定了。
因为之前遇到过类似的问题，根据经验直接处理即可。
但，问题来了。
这类问题，我写过维护文档提交给他们的。估计文档太多，事情太急，他们没时间和心情去翻看。
如果S系统有费用和升级的时候，我想内建一个知识库，把这类问题放到知识库里面，有快捷的归类和索引，他们能快速的索引和定位到文档内容，根据文档指引处理算了，争取脱维。
我觉得这是系统运维一种理念的问题，反正我遇到过有些同事，不重视这类问题，就专心搬砖和挖坑。这类问题，偶发性，被坑第一次正常。如果频发，这种时间、沟通和精力的损失太大了。
至少3点多就被闹醒起来，我今早就不太敢跑步了。
