因为 发票云和 集成云 都需要收费，所以我们都没使用，都是自己搞的.
 
 要点一：对外公开接口
		客商剩余额度查询接口：
		客商交易记录查询接口：
		
		一个供应商就是一个交易对手嘛，查询交易对手的额度就是开始会给这个交易对手设置一个额度（交易对手授信评估表），
		然后每次付款申请呀，采购入库呀、销售出库呀什么的都会进行额度校验，
		例：付款申请单付款，我们就在交易对手底表中  做一条该付款申请单的记录，
		然后当你下次还是该交易对手付款的时候，我们就会拿到交易对手底表的记录本次占用金额和交易对手评估表的剩余额度做对比，
		如果剩余额度大于付款申请金额  那就允许它付款，反之不允许
		
		客商嘛，就是供应商和客户，每一个供应商或者客户都是一个交易对手嘛，我们有一个交易对手授信评估表，这个表里面会生成他的这个额度，然后每次进行付款申请呀，
		采购入库呀、销售出库呀，都会去查询他的剩余额度是都满足，如果满足肯定就会继续往下走了嘛，让然后每次交易的时候都会在交易对手底表中插入一条数据
		
		
		
		
要点二：接口集成
		对接企业微信，
		1.比如我们单位的管理系统就是我做了，每天写这个日报，今天做了什么项目了，各个项目花费了多久啊，审批人是谁啊，这个日报你提交之后
		会根据你填写的审批人，到送到对应的审批人企业微信里面，然后审批人选择通过或者不同过嘛，意见什么的嘛，再使用定时任务，获取这个审批意见什么的
		去更新这个日报审批结果。
		2. 统计谁谁谁几天没写日报了啊，群里@一下，
		3.项目上的任务领取了做啦，什么什么任务到什么进度进度了啊，
		
		
		
		
工作流：



业务流：

		
					
要点三：风险管理	
		有一个黑名单，灰名单什么的

要点四：如何提升代码性能	
		优化sql嘛，比如说少用：
						1.Select * ，需要什么字段查询什么字段就可以了
						2.一次性把需要的东西都查询出来吗，
						3.模糊查询的时候，尽量在字段后面使用模糊查询（不要在字段前面使用%）
						4.减少使用or，会导致数据库引擎放弃索引进行全表扫描
						5.总的来说就是如果字段没有设置索引，就少使用，少用来做条件，	
						6.如果走了索引还是慢，那么就看看数据库的数据量是不是太大了，太大了的话就进行分库分表
		
		
				

要点五：自我介绍
		我叫金亮，老家是湖北黄冈的，2020年毕业于武昌职业学院，在学校主修的就是 java 毕业之后，有报了培训机构把java再学了一编
		然后入职了第一家单位叫，西安泰德有限公司，做了有个半年（因为一直不缴纳社社保）所以就来到了我上一家单位，陕西云易贸
		络科技有限公司，在西安科技二路那块，在这家单位我自学了SpringCloud，代码能力得到了提升，也对业务的理解也更深入，更会站在客户的角度去看问题，
		这家单位从去年3月份到现在，前几天离职，因为我想要一份薪资更高的工作。
		

要点六：项目难点
		当时做了一个这个功能，就是上传发票，对发票自动进行识别和查验，并将识别或查验返回的数据生成对应的单据

		因为发票的类型多种多样（比如汽车，飞机，增值税专用发票，全电发票，等等），返回的数据肯定也不一样，为了代码的通用性和灵活性，
		然后我就去创建了一个发票生成单据模版，这个单据模版的话呢，
		一种发票类型对应就是一张发票生成单据模版，这个单据
		模版上指定，单据上的单据头对应哪个json对象，单据体对应哪个jsonArr，子单据体对应的又是哪个jsonArr，然后里面的字段对应的是json对象上的哪个key，缺省值是啥，这个字段如果是
		基础资料类型的，那josn数据对应的value值，是这个基础资料的什么属性，这样就能确定具体到那一条数据，然后代码里面的逻辑就是，获取到这个返回的数据之后，判断是哪种发票类型，
		比如说如果是，增资税发票类型，那么就去查询我这张 发票生成单据模版，查询到了这种发票类型对应的这条数据之后就根据这条数据上的对应关系，一一赋值，这样有一个好处，就是代码
		通用性很高，不管你是什么发票类型，返回的是什么样的json数据，只要能在生成单据模版上找到对应的数据，那么就能根据这个数据上的对应关系就能自动生成对应的单据信息，而且如果
		单据上到字段或者是结构需要修改，只需要修改我这个发票生成模版上的对应关系就好了，不需要动代码
		
		
		
		
		
	
		
可能的提问（关于金蝶）	
MySQL与PostgreSQL作为两种流行的开源关系型数据库管理系统，它们之间的主要区别可以概括为以下几点：
SQL标准与功能：
PostgreSQL更严格地遵循SQL标准，提供了更丰富的数据类型和更完整的功能实现，比如更强大的存储过程支持和物化视图。
MySQL虽然广泛使用，但在某些SQL标准特性和高级功能上可能不如PostgreSQL全面。
数据类型与复杂查询：
PostgreSQL支持更多种类的数据类型，包括数组、JSON、XML等非关系型数据类型，适合处理复杂数据结构。
对于复杂查询和连接操作，PostgreSQL的优化器通常能提供更好的性能。
扩展性与存储过程：
PostgreSQL具有高度的可扩展性，支持用户自定义类型、函数等，适合大规模和复杂应用。
PostgreSQL的存储过程功能更为强大，支持本地缓存执行计划，提高执行效率。
事务处理与并发控制：
PostgreSQL原生支持多版本并发控制(MVCC)，在并发处理和事务一致性方面表现优秀。
MySQL依赖于存储引擎（如InnoDB）来实现事务处理和MVCC，不同的存储引擎性能和特性各异。
高可用与备份恢复：
两者都支持主从复制等高可用方案，但PostgreSQL在时间点恢复(PITR)和工具如pgBackRest方面有较为完善的解决方案。	


	
SpringCloud知识：
	Gateway服务网关的作用是什么：
		1 对所有的请求进行过滤，效验身份，效验权限，（比如效验JWT令牌）

        2 路由和负载均衡，（如果客户要记住我们所有的微服务地址那太难了，负载均衡即使拉取Nacos上面的健康接口，如果有多个实例的话，及进行负载均衡，一般默认的机制都是轮训

        3 跨域，哪些请求可以进去，哪些不行

        4 限流，如果请求太多了，服务器压力太大了嘛，所以要限流
		
		
	
	Feign：
		微服务之前项目调用的嘛
		
		
	Ribbon是什么：
		负载均衡，提升微服务间的交互效率和可靠性，是构建高性能、高可用微服务架构的关键组件之一，就是下拉健康的接口嘛，然后一半策略都是轮训嘛
	
	

	Redis有两种持久化方案：（RDB和AOF一般只使用一种）
        RDB持久化：把内存中的所有数据都记录到磁盘中。当Redis实例（服务器）故障重启后，从磁盘读取快照文件，恢复数据。快照文件称为RDB文件，默认保存在当前运行目录(自动创建dump.rdb文件)，
        RDB原理：1 bgsave命令开始时会fork（拷贝）主进程得到子进程，子进程共享主进程的内存数据。并且子进程会将这些数据写入RDB文件。期间主进程可以做自己的事（写操作）
        持久化触发机制条件可以在redis.conf文件中修改：save 900 1  ，save 300 10  ，save 60 10000

        AOF持久化：每一个写命令都会记录在AOF文件，可以看做是命令日志文件（记录写命令语句，所以会比RDB文件大很多）提示：AOF默认是关闭的，需要修改redis.conf配置文件来开启AOF（记录的每行命令是对key最后的一次操作）AOF默认是关闭的

       区别：
           RDB记录的是数据，RDB因为记录的是数据，所以体积比较相对来说比AOF小，默认60秒保存一次，
           AOF记录的是每一行命令，AOF记录的是整个命令自然体积大，默认是执行一次命令一秒就保存一次