时间：2022/02/10 PM 13:40 ~ 15:30

内容：java 后端 ihive 3.0 「上」

参考资料

devlop-doc ，重要：表结构设计 Java开发 相关规范 初始数据

分系统而不是系统

每一个单独的业务系统，都对应一个单独的库，独立的表设计文档；

核心系统 itsys（称为中台或者平台），基于mysql的数据库；
mis、智慧营业厅基于oracle的数据库，电子合同mysql的库；
部分项目混用了数据库。

需求、设计、兼容（业务模型：事物的描述，数据的存储，数据库的类型等等）；

表结构Excel文档的用法，以及EXcel的能力

修改：表结构的样子不能乱动，增加表可以复制tab栏，粘贴到新建的tab栏；
服务器缓存：比较消耗内存。
虽然redis也是缓存，但是redis做过优化：建议使用redi缓存。
数据日志：针对小表：变更前，变更后的内容存储下来。

pk自动生成组件，ua1、ua2会生成联合唯一组件。
注意：

  1. 表结构字段之间不能插入空行。
  2. mysql与orcal是不同的模板，用vba生成。
  3. WPS 或者 Excel 需要支持宏。（宏用来生成简单的建表脚本，直接复制粘贴运行就能建表）
    单独的语言或者技能是敲门砖，不能局限于此。人应该追去全局的编程思想，善与总结，提高自己综合解决问题的能力。人需要不断的跌到爬起才能成长，而不是停留在舒适区。————廖总语录

模块的设计文档，究竟是用来解决什么问题？ 统一工作开发。

个人认为：根据模块来分工作带来什么问题？对开发要求比较高，啥都得会，啥都得操心，今儿可能会降低开发效率。
开发不应该根据模块来分工作，而是根据feature（特征）,每一个人专注于解决某一块的具体问题。

架构师让我们开发干活，三要素：
表结构设计文档，模块设计文档，接口设计文档。

内部api提供给web、app项目等，不提供给第三方，只能走openApi;
部分企业也可以通过appid来与我们的openApi交互。
所有的请求用post，只有文件下载用get，为什么？就这么设计。
所有的编码utf-8，所有数据交换都用json。

数据分发：zuul网关，nacos，nginx提供转发，server就是走zuul网关，底层还是基于springboot内置的tomcat。

服务器不做状态管理，无状态。

错误码最常见的是 20007；
注意：抛出异常，文案非常重要。

crud query请求设计：为何这样设计？权限的问题本质上还是安全的问题，这样设计还能提前预防。

delete 相关api，一定要尽可能的说明那些情况不能调用

虽然能用，但是我还是觉得不够完美，前端的角度提出几个问题：

  1. 对于通用的表结构，通用的SQL，我们一般是怎么处理的？
  2. 我们没有文档管理系统，目前的文档格式复杂、不太容易维护、也不健壮，我们为什么不开发一套，或者使用现代化成熟的在线文档管理系统？
  3. 对于业务数据查询速度慢的情况，在不放到缓存的情况下，能否在SQL上下功夫？
  4. 如果一定要使用内存，那该如何解决内存不够的问题？（空间换时间，是否会增加成本？）
  5. 数据变更日志，市面上应该存在相关成熟解决方案。我们是否在重复造轮子？
  6. 都说程序设计没有银弹，那我们整套产品解决方案算不算自来水工程业界的银弹？到底有没有银弹？
  7. 如何看待新技术（新思想）与老技术（老思想）的碰撞？如何把握平衡？

时间：2022/02/10 PM 15:40 ~ 17:30

内容：java 后端 ihive 3.0「下」

ihive基于微服务架构，Ihive作为一个中心系统对待，是一个整体的概念，它是把基础的、共享的东西剥离出来，抽象成一个新的产品。
服务于服务之间的通讯：与前端一样，通过webapi（类似业界的 restful 风格，但不是）

jar包分为两种
前缀为istys：分系统；
前缀为ihive：给其他项目用的工具包；

common 包最重要，最常用，是关于基类、实体的封装。

geteway 比 zuul快很多；

openfeign：提供对类，方法的动态调用的能力；

outsidedb：以前用dblink，配置繁琐，现在更加方便的使用外部数据库。

quartz：调度器，3.0重大变化，增加界面注册功能。

test：以前是拷一遍，现在是抽成了此独立的test包，基于junit5。

花时间最多的地方就是数据库，数据库一定要分层，

  1. webapi层包括servelet、拦截器、过滤器（基于tomcat，属于j2ee的范畴），一般使用spring的servelet；
  2. 业务层：通俗来讲也叫服务层，上层业务，没有事务；
  3. 服务层：下层服务，有事务，spring帮我们解决了事务处理的老大难题。
  4. 数据访问层：Dao层，没有；
  5. 数据存储：跟我们这边无关；

我们目前代码的业务只涉及到前三层。
分层调用原则，依赖关系从上到下，绝对禁止从下到上，否则会出现死循环的BUG。
同层可以互相依赖，尽量避免跨层依赖。
若有做不到的需求，需要找廖总讨论。

其他：

异常统一友好处理。
标准的权限有5个，一般没必要修改权限方法，想要修改继承重写即可。

廖总谈代码的哲学

菜鸟喜欢用一个对象实现所有的东西。这种行为不可取，尽量拆到小而美，尽量不要超过200行。
写代码比较简单，清晰的思路，以及解决问题的思想比较难得。