这是我参与11月更文挑战的第4天，活动详情查看：2021最后一次更文挑战。
面试官: 技术方案一般要遵守哪些原则？ 候选人： SOLID 原则？
此时，脑海中浮现出这么一张图：
言归正传：
API 设计原则有哪些？
Rest API 设计中，要正确使用 Http Verb。
http 的 verb 语义：
# GET：读取（Read）
# POST：新建（Create）
# PUT：更新（Update）
# PATCH：更新（Update），通常是部分更新
# DELETE：删除（Delete）
错误码返回规范：datatracker.ietf.org/doc/html/rf…
API 设计中一般需要向前兼容， 一般需要遵守如下原则：
- 不要删除已有字段
- 新增字段，必须是
optional(选填） thrift定义的idl序号不允许变更- 字段类型不允许变更
- 整数全部使用有符号类型，不要使用无符号类型
- 除了定义正常的网络
status Code还要定义业务的Error Code
常用的错误状态码如下：
400 Bad Request：服务器不理解客户端的请求，未做任何处理
401 Unauthorized：用户未提供身份验证凭据，或者没有通过身份验证
403 Forbidden：用户通过了身份验证，但是不具有访问资源所需的权限
404 Not Found：所请求的资源不存在，或不可用
405 Method Not Allowed：用户已经通过身份验证，但是所用的 HTTP 方法不在他的权限之内
410 Gone：所请求的资源已从这个地址转移，不再可用
415 Unsupported Media Type：客户端要求的返回格式不支持。比如，API 只能返回 JSON 格式，但是客户端要求返回 XML 格式
422 Unprocessable Entity ：客户端上传的附件无法处理，导致请求失败
429 Too Many Requests：客户端的请求次数超过限额
500 Internal Server Error：服务器内部错误
503 Service Unavailable：服务不可用
数据库怎么设计?
数据库使用原则
- 尽可能避免分布式事务， 主要是分布式事务代价很高， 能避免就避免吧
- 不要在数据库事务中做比较耗时的操作，比如不要在事务中做
RPC服务
db.Transaction(func(tx *gorm.DB) error {
tx.Create(xxxxx)
tx.Update(xxxxx)
rpc.Service1() //!!!!call rpc in a transaction
return nil
})
- 一般不要使用
select *避免select出不需要的字段， 提高性能。如果数据表中有大字段， 查询出来却不使用，会给服务器带来内存的压力，也会给应用服务带来 GC 压力。 - 数据库查询，需要返回列表的， SQL 语句中必须有
LIMIT， 因为无法预计线上列表是否会有大列表。 - 拒绝未使用索引的慢查询，必须要对代码中的 SQL 进行审核，最好养成看执行计划，
explain的习惯。 - 对业务一致性比较敏感的业务，不要读从库， 主从有延迟，但是要评估对主库的读写压力。
数据表设计原则
- 尽量不使用自增字段做主键，可以新搞一个主键，否则分库分表情况下会带来一些影响。
- 对于状态字段，可以采用数字类型，不要使用字符串或者 char 类型。
数据库变更原则：
- 数据库表也要做兼容， 不要删除字段
- 新增字段， 要允许为
null, 或者NOT NULL但有默认值，需要兼容次存量数据 - 一般不允许新增唯一索引， 因为有可能会违反唯一约束。
- 设计复合索引时，区分度最大的索引字段必须放到前面
