4 规范
(Must have)
规范一：非数据服务做到无状态，避免同一集群内的节点间有功能差异；
做到实例可以被随时停止、重启、增加，并且完全不依赖于本地磁盘或者内存
规范二：服务具备优雅重启
规范三：服务提供的API建议采用http\grpc, json\pb规范，不建议其他自定义格式
规范四：线上服务最小集群单元2个实例，避免单点服务；如无法避免，则应该在设计阶段考虑到单点故障的的处理方案
规范五：服务的所有依赖库或者服务都要有明确的负责人；依赖需要有完备SLA
规范六：服务需要有明确能衡量容量的指标清单；在达到服务上限时具备自我保护能力（限流、降级）
规范七：每个服务都需要自证服务健康度（增加metrics接口）；
能够输出每秒内完成的请求总量、正常请求总量、异常请求总量，或者是输出单次请求的信息后由监控系统进行统计；
以及耗时的平均值，最大值，最小值，分位值
规范八：业务服务每个请求默认实现一条业务日志；线上日志级别默认开启在Info级别（Fatal > Warning > Info > Debug）
规范九：每个服务具备排查问题，异常错误监控和报警能力；报警内容清晰明确
规范十：服务之间通过API进行交互，禁止通过数据存储层（redis\mysql）进行交互
规范十一：服务之间的访问禁止环路调用（A->B->C->A）
规范十二：服务需要具备故障隔离能力，依赖方异常需要有应对措施，具备自动熔断能力或通过配置中心实现的快速开关能力；
规范十三：redis作为缓存使用，每个key都要设置默认的过期时间；强烈不建议redis作为存储使用
规范十四：数据具备多副本的能力，建立数据备份机制，数据重要度分级、备份周期等信息
规范十五：避免对数据库锁表或者锁库的操作
(Nice to Have)
规范十六：所有请求的超时设置建议是99线的3倍
规范十七：服务的线程数建议是cpu核数的1.5倍
规范十八：服务发现通过名字服务进行发现，公司推荐使用Consul作为服务发现；
禁止将对方服务IP写在配置中进行访问，不建议通过（SLB、VTM）以及内网域名进行服务发现
规范十九：服务访问需要提供标识和token, 供服务提供方进行验证
规范二十：访问下游失败时进行有限的重试，快速failover
规范二十一：服务按照DDD模型进行设计和划分，尽量做到高内聚低耦合