doc第一次建立

.gitignore

@@ -0,0 +1,75 @@
+# ---> JetBrains
+# Covers JetBrains IDEs: IntelliJ, RubyMine, PhpStorm, AppCode, PyCharm, CLion, Android Studio
+
+*.iml
+
+## Directory-based project format:
+.idea/
+# if you remove the above rule, at least ignore the following:
+
+# User-specific stuff:
+# .idea/workspace.xml
+# .idea/tasks.xml
+# .idea/dictionaries
+
+# Sensitive or high-churn files:
+# .idea/dataSources.ids
+# .idea/dataSources.xml
+# .idea/sqlDataSources.xml
+# .idea/dynamic.xml
+# .idea/uiDesigner.xml
+
+# Gradle:
+# .idea/gradle.xml
+# .idea/libraries
+
+# Mongo Explorer plugin:
+# .idea/mongoSettings.xml
+
+## File-based project format:
+*.ipr
+*.iws
+
+## Plugin-specific files:
+
+# IntelliJ
+/out/
+
+# mpeltonen/sbt-idea plugin
+.idea_modules/
+
+# JIRA plugin
+atlassian-ide-plugin.xml
+
+# Crashlytics plugin (for Android Studio and IntelliJ)
+com_crashlytics_export_strings.xml
+crashlytics.properties
+crashlytics-build.properties
+
+# ---> macOS
+.DS_Store
+.AppleDouble
+.LSOverride
+
+# Icon must end with two \r
+Icon
+
+
+# Thumbnails
+._*
+
+# Files that might appear in the root of a volume
+.DocumentRevisions-V100
+.fseventsd
+.Spotlight-V100
+.TemporaryItems
+.Trashes
+.VolumeIcon.icns
+
+# Directories potentially created on remote AFP share
+.AppleDB
+.AppleDesktop
+Network Trash Folder
+Temporary Items
+.apdisk
+

README.md

@@ -0,0 +1,5 @@
+# doc
+
+文档
+
+test

技术分享/MybatisPlus动态schema.md

@@ -0,0 +1,17 @@
+# MybatisPlus动态schema
+
+## 使用方式
+1. 配置需要使用动态schema的表名
+在`MybatisPlusConfig.DYNAMIC_SCHEMA_ENTITY_NAMES`中添加需要使用动态schema的表名.
+
+2. 调用
+在调用数据库查询前 调用 `DYNAMIC_SCHEMA_CONTEXT.set(schemaName)`
+在调用数据库查询后 调用 `DYNAMIC_SCHEMA_CONTEXT.remove()`
+
+## 实现原理
+* mybatis-plus DynamicTableNameInnerInterceptor
+* ThreadLocal
+
+## 未来计划
+* 提供注解`@EnableDynamicSchema`,在entity上添加注解, 来配置需要使用动态schema的表名
+* 提供注解`@Schema("#param1")`, 在方法上添加注解, 来指定该方法中的数据库操作使用指定的动态schema

技术分享/clickhouse笔记.md

@@ -0,0 +1,147 @@
+# clickhouse笔记
+
+https://developer.aliyun.com/article/762097?spm=a2c6h.14164896.0.0.bf39420cnHkODH
+
+https://help.aliyun.com/document_detail/156340.html?spm=a2c4g.11186623.6.610.47ce6bcft384OY
+
+https://clickhouse.tech/docs/zh/engines/table-engines/mergetree-family/mergetree/
+
+
+复制表、分布式表机制. 分片方式.
+https://blog.csdn.net/nazeniwaresakini/article/details/105858390
+
+## 能力
+* 数据类型:整数/浮点/decimal/字符串/时间/boolean/数组/元组/domain
+* 可用JDBC连接
+* TTL: 设定数据过期时间,并自动归档
+* 参数设置: 
+    config.xml或user.xml,需重启集群.
+    云数据库ClickHouse仅支持user.xml里的参数设置
+* 数据库引擎:延迟引擎/mysql/自带数据库引擎
+* 表引擎: ClickHouse表引擎一共分为四个系列，分别是Log、MergeTree、Integration、Special。其中包含了两种特殊的表引擎Replicated、Distributed，功能上与其他表引擎正交，根据场景组合使用
+* 本地表,分布式表;  单机表,复制表.
+* 分区, 分片
+
+## 阿里云提供
+高可用集群与单副本集群,高可用集群每个分片至少有两个副本, 所以成本至少是两倍.
+集群监控与报警
+使用DMS进行数据管理
+开源测试集导入以及性能测试
+慢sql
+正在运行的SQL管理
+
+## 前端
+阿里云quickBI
+grafana, 使用grafana可使用类sql快速搭建图表,还可以以iframe嵌入到其他系统中.
+
+
+## 阿里云功能限制
+高可用集群必须用复制表引擎；
+DDL操作需要使用ON CLUSTER default语句在所有server上执行。
+只支持分布式表，也即多台ClickHouse server会自动组成分布式集群，不支持单机表；默认所有server都会自动组成名字为default的集群，DDL需要使用ON ClUSTER default语句在所有server上执行。
+不支持用户自行配置remote cluster。
+不支持File、URL table engine。
+不支持file、url等table function。
+不支持用户自定义profile。
+
+## 表
+从数据分布上，可以分为本地表、分布式表两种类型。
+从存储引擎上，可以分为单机表、复制表两种类型。
+
+![表](../开发文档/C综合需求/meida/clickhouse01.png)
+
+参考 https://blog.csdn.net/nazeniwaresakini/article/details/105858390
+
+### Partitioning分区
+分区是在 建表 时通过 PARTITION BY expr 子句指定的.
+新数据插入到表中时，这些数据会存储为按主键排序的新片段（块）。插入后 10-15 分钟，同一分区的各个片段会合并为一整个片段。
+分区优点:
+    * 可以充分利用多核cpu能力, 同时在多个分区中进行查询, 或者根据分区key, 只查询需要的分区.
+    * 对partition进行TTL管理，淘汰过期的分区数据
+
+### Sharding分片
+* 分布式集群分片模式:
+    1. random随机分片：写入数据会被随机分发到分布式集群中的某个节点上。
+    2. constant固定分片：写入数据会被分发到固定一个节点上。
+    3. column value分片：按照某一列的值进行hash分片。
+    4. 自定义表达式分片：指定任意合法表达式，根据表达式被计算后的值进行hash分片。
+
+* 分布式写入:
+    * 直接写分布式表的优点自然是可以让ClickHouse控制数据到分片的路由，缺点就多一些：
+        数据是先写到一个分布式表的实例中并缓存起来，再逐渐分发到各个分片上去，实际是双写了数据（写入放大），浪费资源；
+        数据写入默认是异步的，短时间内可能造成不一致；
+        目标表中会产生较多的小parts，使merge（即compaction）过程压力增大。
+    * 直接写本地表是同步操作，更快，parts的大小也比较合适，但是就要求应用层额外实现sharding和路由逻辑，如轮询或者随机等。
+    * 在生产环境中总是推荐写本地表、读分布式表
+
+### Replicated复制
+工作在表级别，而不是集群级别.
+目前支持复制表的引擎是ReplicatedMergeTree引擎族，它与平时最常用的MergeTree引擎族是正交的
+
+## mergetree表引擎细分
+[引擎选择](https://help.aliyun.com/document_detail/156340.html?spm=a2c4g.11186623.6.610.47ce6bcft384OY)
+
+数据分区、存储有序、主键索引、稀疏索引、数据TTL
+主键并不用于去重,主要作用是加速查询
+由于MergeTree采用类似LSM tree的结构，很多存储层处理逻辑直到Compaction期间才会发生
+
+### ReplacingMergeTree
+根据主键对数据进行去重
+
+虽然ReplacingMergeTree提供了主键去重的能力，但是仍旧有以下限制：
+在没有彻底optimize之前，可能无法达到主键去重的效果，比如部分数据已经被去重，而另外一部分数据仍旧有主键重复。
+在分布式场景下，相同primary key的数据可能被sharding到不同节点上，不同shard间可能无法去重。
+optimize是后台动作，无法预测具体执行时间点。
+手动执行optimize在海量数据场景下要消耗大量时间，无法满足业务即时查询的需求。
+因此ReplacingMergeTree更多被用于确保数据最终被去重，而无法保证查询过程中主键不重复。
+
+### CollapsingMergeTree
+ClickHouse实现了CollapsingMergeTree来消除ReplacingMergeTree的功能限制.
+该引擎要求在建表语句中指定一个标记列Sign，后台Compaction时会将主键相同、Sign相反的行进行折叠，也即删除。
+Sign=1的行称之为状态行，Sign=-1的行称之为取消行
+不在同一节点上的数据无法折叠
+为了获得正确结果，业务层需要改写SQL，将count()、sum(col)分别改写为sum(Sign)、sum(col * Sign)。
+CollapsingMergeTree虽然解决了主键相同的数据即时删除的问题，但是状态持续变化且多线程并行写入情况下，状态行与取消行位置可能乱序，导致无法正常折叠。
+
+### VersionedCollapsingMergeTree
+为了解决CollapsingMergeTree乱序写入情况下无法正常折叠问题，VersionedCollapsingMergeTree表引擎在建表语句中新增了一列Version，用于在乱序情况下记录状态行与取消行的对应关系。主键相同，且Version相同、Sign相反的行，在Compaction时会被删除。
+
+### SummingMergeTree
+支持对主键列进行预先聚合.会将主键相同的多行进行sum求和，然后使用一行数据取而代之，从而大幅度降低存储空间占用，提升聚合计算性能
+ClickHouse只在后台Compaction时才会进行数据的预先聚合，而compaction的执行时机无法预测，所以可能存在部分数据已经被预先聚合、部分数据尚未被聚合的情况。因此，在执行聚合计算时，SQL中仍需要使用GROUP BY子句。
+在预先聚合时，ClickHouse会对主键列之外的其他所有列进行预聚合。如果这些列是可聚合的（比如数值类型），则直接sum；如果不可聚合（比如String类型），则随机选择一个值。
+通常建议将SummingMergeTree与MergeTree配合使用，使用MergeTree来存储具体明细，使用SummingMergeTree来存储预先聚合的结果加速查询。
+
+
+### AggregatingMergeTree
+AggregatingMergeTree也是预先聚合引擎的一种，用于提升聚合计算的性能。与SummingMergeTree的区别在于：SummingMergeTree对非主键列进行sum聚合，而AggregatingMergeTree则可以指定各种聚合函数。
+
+## mergetree
+[mergetree](https://clickhouse.tech/docs/zh/engines/table-engines/mergetree-family/mergetree/)
+ORDER BY
+    排序,可以是一组列的元组或任意的表达式
+PARTITION BY
+    分区
+PRIMARY KEY
+    主键
+SAMPLE BY 
+    用于抽样的表达式
+TTL
+    定行存储的持续时间并定义数据片段在硬盘和卷上的移动逻辑的规则列表, 表和列可分别设置TTL
+
+长的主键会对插入性能和内存消耗有负面影响，但主键中额外的列并不影响 SELECT 查询的性能。
+可以使用 ORDER BY tuple() 语法创建没有主键的表。
+
+使用具有多个块的设备进行数据存储, 为热数据使用sdd,为冷数据使用普通硬盘. 
+default 存储策略意味着只使用一个卷，这个卷只包含一个在 <path> 中定义的磁盘。表创建后，它的存储策略就不能改变了。
+
+
+## 问题
+* 分布式表,不建议直接写入分布式表, 而是写入本地表, 那么写入本地表的负载均衡策略如何保持一致?
+分片规则用于写入路由, 不用于读路由. 无论分片规则是什么, 总是读所有分片,无论数据如何分布, 查询总是可以正常工作.
+
+* 现在是asin + createtime 作为primarykey和orderby, 是否会有性能问题?
+
+* 当前以database=company, table=站点, 为了让不同站点的数据更均衡的分布在各个分片上. 是否有必要这样做?
+
+* TTL数据归档方案, 冷热数据存储方案.

技术分享/spring boot 服务优雅停机.md

@@ -0,0 +1,26 @@
+# spring boot 服务优雅停机
+
+## 方法一:使用kill 而不是kill -9
+
+### kill
+kill 对应的是kill -15 ,kill 程序时有以下特点
+
+* 系统会发送一个SIGTERM的信号给对应的程序。当程序接收到该signal后，将会发生以下的事情
+    * 程序立刻停止
+    * 当程序释放相应资源后再停止
+    * 程序可能仍然继续运行
+    * 大部分程序接收到SIGTERM信号后，会先释放自己的资源，然后在停止。但是也有程序可以在接受到信号量后，做一些其他的事情，并且这些事情是可以配置的。如果程序正在等待IO，可能就不会立马做出相应。也就是说，SIGTERM多半是会被阻塞的、忽略
+
+### kill -9 
+强制停止命令
+
+## 方法二:spring actuator
+开放`shutdown`endpoint,通过发送向该endpoint发送http请求来停机.
+`curl -X Post localhost:8080/actuator/shutdown`
+
+
+## amazon-subscription优雅停机方案
+amazon-subscription在监控amazon aws消息队列, 消费后生成的数据会保存到clickhouse中, 但是由于clickhouse最高只支持100个并发,所以需要批量插入数据. 数据会缓存在内存中, 定时向clickhouse插入.
+当服务被kill时, 如果内存中的数据不能被及时写入到clickhouse, 就会永远丢失. 解决方案如下:
+* 使用优雅停机, 保证服务在关闭前,有时间进行处理.
+* 监听spring事件`ContextClosedEvent`, 关闭listener, 再把缓存中的数据写入到clickhouse.

技术分享/系统中的多时区.md

@@ -0,0 +1,27 @@
+# 系统中的多时区
+
+## mysql
+当写入时间时, mysql会判断当前mysql时区,并对写入时间进行转换, 然后写入datetime或timestamp.
+读取datatime和timestamp的时候, mysql会判断当前mysq时区,并对读取时间进行转换.
+
+datetime中不存储时区,所以datetime的时区就是mysql时区. 
+timesteamp中储存时区, 所以timestamp的时区不会随着mysql时区的调整和变化.
+所以,当mysql时区调整后, 从数据库中读出的时间,datetime会与之前不一致,timestamp与之前一直.
+
+## 解决方案
+当一套系统要为多个时区提供服务时,有两种处理方式
+* 时间全部使用timestamp存储.
+
+* 所有系统内部的时区都设置为UTC时区, 即+00:00.
+    *  数据库
+    *  运行环境(windows,linux).在容器中,可以通过环境变量设置容器的时区.
+    *  jvm时区默认与运行环境的时区保持一致.
+    *  时间格式化工具的时区. java中Date是UTC时间, 没有时区的概念. 在格式化时,指定时区.
+    *  序列化工具. 如jackson等
+
+``` 
+spring.jackson.date-format=yyyy-MM-dd HH:mm:ss Z
+spring.jackson.time-zone=GMT+0
+```
+
+所有的后端系统统一使用UTC时间, 与外部系统进行数据交互时,时间需携带时区.例如向前端返回时间数据, 应该携带时区.

规范制度/codereview使用.md

@@ -0,0 +1,22 @@
+# code review
+使用`upsource`作为code review工具. 具备review协同功能.
+
+# 准备
+
+1. 向管理员申请账号, 并在浏览器中登录.
+   upsource地址: http://192.168.0.59/
+2. IDEA 安装`upsource`插件, 并重启
+3. IDEA -> Preference -> upsource ->connection . 输入`http://192.168.0.59/`
+
+## 代码审阅者
+1. 在页面上对指定的commit,创建`review`,每个`review`有唯一ID.
+2. 在IDE中切换对代码进行comment, 并指定`review`ID.
+3. 该commit作者的IDEA将收到通知.
+4. 等待作者修改完成后, 对代码进行查询,并`close review`.
+
+## review接受者
+在IDEA下方的`Reviews`窗口, 根据所需条件搜索任意review, 推荐搜索`metion me`, 即`提到我的review`.
+对review中的与自己相关的comment, 进行代码修改, 确认问题修改完成后, 点击`resolve`.
+
+
+

规范制度/代码分支管理.md

@@ -0,0 +1,73 @@
+# Git 工作流管理
+
+Git 使用规范
+![](media/Git工作流管理1.jpg)
+
+## 研发阶段
+共享版本库在 http://git.businessmatics.io/gogs，我们通过 GitLab（开源）搭建了 git 版本库管理平台；
+
+在每个项目中，会有一个常设的 master 分支，该分支作为每个项目的开发主干，一般来说，主干上的代码都应该保持干净，可用，尽量跟线上版本一致；
+
+上图显示了在我们选用的 git flow 工作流；
+
+接到一个新的项目需求，第一步的工作是创建一个特性分支（feature），分支的命名规则一般1~2个单词，不要使用缩写，尽可能保持字面意思，让别人看懂，分支需要被推送到中央版本库；
+
+主要负责该需求的程序员在该分支上开发，谨记经常提交代码，确保代码不要遗失，如果有共同合作人，应该尽可能频繁地把变更推送到中央版本库，确保合作人能尽可能早地知道你的变化；
+
+应该至少每天同步（sync）一次主干的变化，方法是在你的分支下，首先执行git fetch将远程代码下载到本地，然后执行git merge master或者git rebase master，（推荐后者，可以产生线性的提交历史，不强制）；
+
+特性开发完毕后，提交代码到中央版本库，commit message按照规范关联需求，测试平台会自动生成对应的测试任务，辅助以提测邮件自动通知测试进行测试；
+
+## 测试到发布
+
+测试对分支进行测试和集成测试；
+
+分支测试完毕后，开发人员将分支提交merge request到主干，由系统的研发负责人进行一次code review并同意合并主干。因为merge会产生一个commit，强制留痕，可以帮助我们记住一个特性分支是何时添加到主干的；
+
+一旦一个分支合并入主干后，约定分支不会被再次使用，如果该分支合并主干后有bug，则重新拉取分支进行修复；
+
+测试对此时的主干进行回归测试；
+
+测试完毕后（包括修完bug），测试或开发（优先由测试操作）对master打tag，并完成发布；
+
+## Feature发布后
+
+合并主干或发布完成后，如果突然出现了紧急运营问题或者bug，应该从最新的主干分支创建分支，分支命名规则为quickfix开头；
+
+在quickfix分支上修复bug，完毕后，紧急验证；
+
+验证完毕后，将quickfix分支合并master分支打tag，并发布线上；
+
+发布完毕后，quickfix_feature1分支不再重复使用；
+
+## 研发全流程
+
+定期清理中央仓库分支
+
+定期清理中央仓库Tag
+
+
+## git命令
+
+### 清理所有旧分支
+```shell
+git branch --merged origin/master | egrep -v "(^\*|master|dev)" | xargs git branch -d
+git branch -r --merged origin/master | egrep -v "(^\*|master|dev)" | sed -e 's/origin\///g' | xargs -n 1 git push  origin --delete
+git fetch -p
+```
+
+### 清理本地已经合并到master分支的无用分支
+```
+git branch --merged origin/master | egrep -v "(^\*|master|dev)" | xargs git branch -d
+```
+
+### 清理远程已经合并到master分支的无用分支
+```shell
+git branch -r --merged origin/master | egrep -v "(^\*|master|dev)" | sed -e 's/origin\///g' | xargs -n 1 git push  origin --delete
+```
+
+### 如果远程分支已经被删除,则清理本地的分支追踪.  
+``` shell
+git fetch -p
+```
+

规范制度/代码规范.md

@@ -0,0 +1,61 @@
+# 代码规范
+
+## 工具安装
+
+### 阿里云编码规范IDEA插件
+1. 使用IntelliJ IDEA, 安装`阿里编码规范`插件.
+2. 打开insecption,点击`Ali-Check`
+![media/编码规范-01.png](media/编码规范-01.png)
+3. 按照下图对报警级别进行修改, 然后保存
+![media/编码规范-02.png](media/编码规范-02.png)
+![media/编码规范-03.png](media/编码规范-03.png)
+4. `git commit`之前, 需要对所有修改的代码进行浏览.确认无误,再commit. 不准无脑commit.
+![media/编码规范-04.jpg](media/编码规范-04.jpg)
+
+
+### IDEA-java-style
+clone checkstyle项目
+将 `SQ-JAVA-IDEA-Style.xml` 导入到IDEA
+`preferences -> editor -> code style -> java -> import`
+
+### check style
+clone checkstyle项目
+把checkstyle中的所有文件,复制到文件夹`/Users/${you-name}/.checkstyle/`下
+把pre-commit复制到每个项目的`.git/hooks/`文件夹下
+
+### git commit 规范
+执行以下命令安装
+```shell
+npm install -g commitizen cz-conventional-changelog
+echo '{ "path": "cz-conventional-changelog" }' > ~/.czrc
+```
+
+使用git提交代码时执行`git cz`, 然后根据提示执行.
+
+
+## 编码规范
+除了阿里编码规范,再补充以下规范
+
+### 代码提交
+代码提交前需要格式化整个project
+   ![media/编码规范-05.jpg](media/编码规范-05.jpg)
+
+### xxljob
+所有的任务都应该有参数,并且在代码中提供默认参数配置, 允许空参运行.
+参数尽量使用json格式
+在该job内定义内部类作为参数模型
+
+### rabbtimq
+发送消息,尽量直接发送对象,而不是json字符串.
+
+反例
+```
+amqpTemplate.send(exchange, queue, JsonUtils.toJson(object));
+```
+正例
+```
+amqpTemplate.convertAndSend(exchange, queue, object);
+```
+
+如果发送json, 则消费端需要使用String作为方法的入参,来获得消息体. 如果从Message中获取body,得到的字符串将会多两个引号. 所以不推荐使用这种方式.
+如果发送Object, 则消费者直接使用Object作为方法的入参,也可以从Message中获取body再反序列化.

规范制度/工作规范.md

@@ -0,0 +1,49 @@
+
+## 基本要求
+有责任
+有计划
+有反馈
+
+## 职责明确
+1 主动解决问题
+2 事项闭环
+以上过程需要有信息落地, 形式为:邮件/需求管理工具/聊天记录.
+
+## 沟通
+工作相关,尽量群聊,不要私聊.
+
+反馈与沟通中的重要信息,尽量有信息落地. 形式为:邮件/需求管理工具/聊天记录.
+
+## 文档
+* 文件协作. 使用云效进行文件协作,主要用于以下场景
+  * 需求梳理前期
+  * 需求界面设计前期
+  * 项目排期
+  * 其他严重依赖协作的场景
+    
+* git. 使用git进行文档沉淀,除了使用语雀的场景之外, 其他全部使用git. 包括但不限于以下场景
+    * 需求方案设计
+    * 需求转为知识
+    * 数据库设计
+    * 规范
+    * 接口文档
+    * 服务器与部署
+
+## 反馈
+* 反馈
+工作中可能出现的问题, 应该及时反馈. 问题出现之后才反馈是没有意义的.
+
+* 周会
+周会,分享自己本周所有工作,并对主要工作进行详细说明. 让其他人了解功能, 并知道对自己负责模块的影响.
+
+* 周报
+周六晚上12点之后, 在`git/doc/项目管理/`文档中汇总周报.
+
+周报最低要求 **其他人可以看懂事项** .
+
+周报内容包括
+
+    * 本周事项. 原计划排期,当前进度,未来节点排期.
+    * 本周问题. 导致事情没有按照原计划或正常情况运行的,都是问题. 问题描述,造成音响,解决方案.
+    * 下周计划.
+

规范制度/微服务项目规范.md

@@ -0,0 +1,53 @@
+# 微服务项目规范
+
+## base-pom
+公司所有项目依赖统一管理.
+任何服务中引入新的依赖后,需要在base-pom中添加依赖管理
+
+## common
+common-core:提供了基本的公共类.
+
+common-spring:各种中间件或工具与spring融合的增强
+
+common-mvc:与springmvc相关的技术的增强和配置
+
+## 微服务结构
+project是maven主项目, 以base-pom为parent.
+
+controller,service,persistence,model是module,以project为parent.
+
+## model
+model分为entity,DTO,VO
+* entity:常规模型,通常与数据库对应(不绝对).
+* DTO:服务间数据传输,临时对象,都可以使用DTO.
+* VO:展示层数据传输
+
+除了以上三种,不能有更多model命名方式.
+
+## persistence
+依赖model层.
+简单查询可以直接使用mybatisplus中提供的`IService`或`BaseMapper`进行查询,不需要写sql;
+
+复杂查询,在mapper.xml中写sql;
+
+每个服务只能连接自己的数据库, 不能直连其他数据库, 如果需要从其他数据库读写数据, 应该通过其他服务器的接口.
+
+## service
+主要代码都在该层. 所有service必须有接口.
+`config`spring相关配置
+`constant`全局通用静态变量
+`consumer`服务调用者,使用feign
+`job`任务调度
+`listener`消息队列消费者
+`dto`数据模型
+`model`数据模型
+`impl`service接口实现
+
+## controller
+控制器层,分为web控制器和api控制器.
+web控制器用于对外接口,api控制用于内部接口
+
+该层只做数据路由, 不能包含主要逻辑.
+
+## provider
+提供可供其他服务调用的api.

规范制度/数据库规范.md

@@ -0,0 +1,105 @@
+#### 一、基础规范
+1) 表存储引擎必须使用InnoDB
+
+2) 表字符集utf8mb4
+
+3) 禁止使用存储过程，视图，触发器，Event
+
+4) 禁止在线上环境做数据库压力测试
+
+#### 二、命名规范
+1) 库名，表名，列名 必须见名知义.所有库名、表名、字段名、枚举名 全部用小写字母，单词之间用下划线\_分隔。
+
+2) 表的命名: 推荐以'业务名称\_具体表名'为模板，如具体表名含义复杂，在具体表名后再增加含义如：'模块名称\_具体表名_xxxxx'。例如'project\_approval'表名。
+
+3) 字段命名
+    * 对于本模型字段, 例如 `order`表中的订单编号, 推荐使用`item_no`, 而不是`order_item_no`.
+    * 对于非本模型字段, 例如 `payment`表中的订单编号, 推荐使用`order_item_no`,而不是`item_no`
+
+
+#### 三、表设计规范
+1) 每个表必须建立主键
+
+2) 禁止使用外键
+
+3) 根据业务区分使用char/varchar
+
+4) 每个表中必需要有 `create_at` (插入时间) 和 `update_at` （更新时间）字段，
+
+     * create_at 使用datatime, 语法： DATETIME  NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间'
+     * update_at 使用datatime ，语法： DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '最后更新时间'
+     
+ 如果涉及操作人/更新人, 统一使用 `create_user_id`,`create_user_name`, `update_user_id`, `update_user_name`
+     
+5)  新建字段必须为NOT NULL，并设默认值为非null值
+
+6) 字段类型长度应设置为保证正常使用需求下的最小长度。
+
+7) 禁止删除列
+
+8) 合理使用字段冗余, 禁止过分冗余.
+
+9) 合理设计表的水平拆分, 禁止过分拆分.
+
+10) 对于命名简单的字段, 可以不写注释. 对于命名复杂或难以理解的字段, 应该添加注释. enum字段必须添加注释.对应的代码中应该使用Enum或静态常量.
+
+
+#### 四、索引规范
+
+1) 唯一索引使用uniqe_[字段名]来命名,eg:unique_asset_item_no
+
+2) 非唯一索引使用idx_[字段名]来命名,eg:idx_asset_create_at
+
+3) 单张表索引数量建议控制在5个以内
+
+4) 对于大表，至少在一个时间字段上建立index.
+
+5) 不建议在频繁更新的字段上建立索引(eg：尽量避免在update_at上建立index)
+
+6) 非必要不要进行JOIN查询，如果要进行JOIN查询，被JOIN的字段必须类型相同，并建立索引
+
+7) 理解组合索引最左前缀原则，避免重复建设索引，index（part1,part2,part3）,相当于建立了 index(part1),index(part1,part2)和index（part1,part2,part3）三个索引.
+
+#### 五、数据操作规范
+1) 禁止使用select *
+
+2) insert必须指定字段，禁止使用insert into T values()
+
+3) 隐式类型转换会使索引失效，导致全表扫描（select uid from user where phone=13811223344  --phone varchar(20) 为什么不能命中phone字段index)
+
+4) 禁止在where条件列使用函数或者表达式 
+(select uid from where date(user_create_at)='2018-01-01' -- 为什么不能命中user_create_at index)
+
+5) 同一个字段上的OR必须改为 IN，IN的值必须少于50个
+
+6) 禁止 drop table/database/column ，truncate table
+
+
+#### 六、SQL语句优化规范 ：  
+     使用mysql explain 对sql执行效率进行检测 
+
+1）使用方法：在select语句前加上explain即可 。
+
+2）explain 分析结果形式如下：  table | type | possible_keys | key | key_len | ref | rows | Extra explain 分析结果形式中各属性含义： 
+table ：显示这一行的数据是关于哪张表的  type ：这是重要的列，显示连接使用了何种类型。从最好到最差的连接类型为const、eq_reg、ref、range、indexhe和ALL  。
+
+possible_keys ：显示可能应用在这张表中的索引。如果为空，没有可能的索引。可以为相关的域从WHERE语句中选择一个合适的语句。
+
+key ：实际使用的索引。如果为NULL，则没有使用索引。很少的情况下，MYSQL会选择优化不足的索引。这种情况下，可以在SELECT语句中使用USE INDEX（indexname）来强制使用一个索引或者用IGNORE INDEX（indexname）来强制MYSQL忽略索引。
+
+key_len：使用的索引的长度。在不损失精确性的情况下，长度越短越好。
+
+ref：显示索引的哪一列被使用了，如果可能的话，是一个常数。
+
+rows：MYSQL认为必须检查的用来返回请求数据的行数。
+
+Extra  ：返回的描述的意义。
+
+#### 七、本项目规范
+* sku在其他表中的外键, 全部只能使用`sku_id`, 不得冗余`sku`
+* user_id 为varchar(10) ; user_name 为 varchar(30)
+
+#### polarDB
+polarDB数据一致性说明 https://help.aliyun.com/document_detail/99093.html?spm=a2c4g.11186623.6.639.36d66fb6V0UroR#title-ijd-kdt-8hk
+我们当前使用会话一致性. 如果在写入数据库, 希望马上读取到, 需要保证这两个操作在同一个会话中, 即开启事务. 
+

规范制度/研发流程.md

@@ -0,0 +1,40 @@
+# 研发流程
+
+## 需求评审
+
+
+## 方案设计
+* 设计文档由以下部分
+    * 基本设计
+    * 流程
+    * 详细逻辑
+    * 数据库表设计以及sql
+    * 注意点
+    * 测试方案
+    * 上线方案. 遇到 影响范围较大, 灰度, 平滑升级 等情况时, 必须在开发前设计上线方案.
+
+## 方案评审
+* 开发者需要完全了解需求, 发现需求中可能存在的问题,与现有功能或技术架构冲突.
+* 如果需求不清晰,开发者有权利决绝.
+
+## 需求估时
+* 开发者
+  开始时间: 开发编码的时间, 不包括方案设计与方案评审时间.
+  结束时间: 完成自测时间.
+
+在开发过程中, 如果发生需求变更,方案不完善等问题导致需要延期, 开发者需要至少提前1天申请延期, 否则必须按时上线.
+
+## 开发
+* 当出现需求变动, 方案设计不完善, 需求不清晰等与原问题时, 不应该个人决定, 应该提出来,共同解决.
+* 在合适的时间点, 应该反馈开发进度.
+
+## 测试
+
+## 上线
+上线时间为每天北京时间9:30(UTC 1:30). 上线前一天,需要准备好上线的所有事项.
+
+## 上线后
+* 跟踪功能使用情况
+* 如果功能中涉及大数据量或者大量cpu计算, 需要跟踪服务器运行情况, cpu,内存, JVM
+* 如果功能对数据库可能产生压力, 需要跟踪数据库运行情况.
+* 需求总结为业务知识,成文档.

规范制度/绩效评定.md

@@ -0,0 +1,47 @@
+# 绩效评定
+## 绩效评定等级
+| 评定等级 | 说明 | 绩效系数 |
+|----|-----|----| 
+|C| 没有达到预期, 如果连续两次被评为C, 则劝退|0|
+|B-| 基本符合预期,稍有不足|0.7|
+|B| 符合预期|0.8|
+|B+| 符合预期,并有所进步,对团队做出贡献|1|
+|A-|超出预期|1.15
+|A| 超出预期| 1.3 |
+|A+| 超出预期| 1.45 |
+|S| 对公司有突出贡献|2|
+
+## 评定范围
+* 业务能力
+对公司业务的贡献
+对其他部门的业务支援
+需求开发,部署,上线
+开发文档与日志
+**需求发现,梳理,设计**
+**发掘新的业务需求,运营流程优化**
+
+* 专业能力
+有足够的技术,保证任务按时按量完成
+项目质量可靠
+维护项目的正常运行
+解决技术难题
+在要求下,按时完成技术调研与落地
+**主动引入新的技术**
+**主动分享技术见解**
+**主动对当前使用的技术进行较大优化**
+
+* 影响力
+团队建设:技术分享/帮助新人/开发流程优化/开发工具优化
+沟通能力
+对其他部门的影响
+
+## 评定流程
+1. 个人自评
+2. 直属领导评定
+3. 个人与直属领导评定达成一致
+4. 公司确定最终绩效
+
+## 绩效计算
+年终绩效 = 个人月薪 * 个人绩效基数 * 入职时间 * 绩效系数
+最终到手,需扣除税款
+