项目稳定规范

说到项目稳定性，我们应该说些什么呢？我觉得应该是我们所有的流程规范，以及代码规范、日常保障的总和，只有我们做好所有的要求才能很好的保障我们的项目稳定。
下面我们主要从下面几个点来讨论下为了达到项目稳定性规范，我们还可以做些什么：

1. JVM 基本规范
2. 基本Java代码规范
3. 数据库规范
4. RPC调用规范

JVM基本规范

1. 基本参数设置

一般很多低级错误都是在上线的业务初期我们错误的设置了JVM的内存大小，然后一直没有人关注，直到有一天线上爆炸后我们才想起来去更改相关的设置。

目前来说我们需要设置基本的xms 和xmx参数，一般根据业务默认2g左右大小。

2. 如何预估Xmx的值

一般我们预估Xmx的值，都是根据相关的项目经验，或者设置一个较大的值，等待项目上线后，观察对应的grafana设置，再次进行缩容，确保项目内存在一个相对合理的水平

基本的Java代码规范

1. 合理使用多线程

确保多线程使用在合理的范围，创建合理的线程数以及设置合理队列，防止无界队列对内存的影响。

数据库规范

1. 表设计

a. 合理的索引
表设计初期必须设置合理必须的索引，很多时候我们遇到业务挂掉了才发现没有设计索引，或者在初期就有人说等上线后再加索引，往往这些都是风险点。

b. 分库分表
老业务我们需要根据历史的订单等数据合理估算当前业务可能的数据量，合理的进行必要的分库分表。
新业务 在代码初期我们需要考虑到后期可能的扩容需求，以及设计的功能能否很好的支撑后期的分库分表操作。

c. 业务设计需要限制业务量
部分业务设计需要做好限制，比如助手之前有个用户导入联系人信息，没有任何限制，也没有时间限制，导致部分用户联系人超过100万，很容易产生瓶颈拖垮整体业务。

2. 大表查询

a. limit分页
分页时，如果是大量的分页，比如limit 100000, 100，建议根据id重新切割查询，防止深翻页导致的性能问题

b. order by file sort问题
在很多慢sql中，我们经常发现时file sort问题引起的，所以我们再业务sql中，需要不断的去查看对应的sql语句，尽可能的避免file sort的写法，比如

select * from user order by created desc;

如上的sql，我们可以改写为

select * from user order by id desc;

RPC调用规范

1. 基本配置

一个RPC调用，我们需要考虑的基本设置包括 超时时间、重试次数，一般我们建议配置在服务端，而且需要严格注意重试次数的配置。

2. 基本的熔断和限流策略

一般我们如果引入一个RPC服务，那么我们需要考虑一个核心问题就是，这个业务挂了，是否会导致我的核心流程挂掉？
如果答案是是，那我们就需要改造，直到我们的答案是否。