微服务开发规范
微服务设计原则
- 原则一：服务独立、自治
- 服务独立交付
- 服务并行启动、停止
- 通过配置方式定制服务能力
- 原则二：服务无状态
- 数据不写入本地jvm、文件系统
- 支持多实例集群部署
- 支持至少一种负载均衡模式
- 定时任务外置到Cron服务或者分布式任务调度平台
- 原则三：服务前后向兼容
- 接口是对外服务的唯一方式
- 以restful风格定义服务接口
- 接口语言无关
- 原则四：分层依赖
- 高可用服务不能依赖于低可用服务
- 不同服务之间只能通过对外接口通讯，禁止跨服务包引用
微服务SLA规范
SLA：服务等级协议（简称：SLA，全称：service level agreement）
- 请求成功率
- 含义: 测量周期内服务成功应答的请求占总请求数的百分比
- 测量方法: (成功应答请求数/总请求数据)*100
- 示例: >99%
- 可用性
- 含义: 测量周期内，服务可用时间所占百分比，可用性分为三个等级
- Lv1：可用性要求最高的核心服务，这类公共服务会被其他大部分服务调用，不可用会影响到用户的使用，例如用户账号、会话登录相关的服务，可用性范围为100%，年不可用时间为0秒
- Lv2：出现不可用会导致部分业务的用户服务突然中断，是面向业务用户的服务，例如用户产品列表、用户新闻列表服务等，可用性范围为99.999% ~ 99.9999，年不可用时间为5.256分钟 ~ 31.536秒
- Lv3：出现不可用不会导致用户的服务突然中断，一般是辅助性的服务，例如数据统计、线路校验服务等，可用性范围为99.99% ~ 99.999，年不可用时间为52.56分钟 ~ 5.256分钟
- (服务在线时间/统计周期总时间)*100
- Lv1
- 吞吐量
- 含义: 每秒钟处理的请求数(接口)，对于服务集群建议给出吞吐量的计算公式，例如集群吞吐量=吞吐量*服务实例数
- 统计服务每秒钟处理的请求数据
- 200
- TP75请求时延
- 含义: 指服务运行周期内75%的请求时延低于定义的值
- 使用百分位数方式计算
- 200ms
- TP95请求时延
- 含义: 指服务运行周期内75%的请求时延低于定义的值
- 使用百分位数方式计算
- 180ms
- TP99请求时延
- 含义: 指服务运行周期内75%的请求时延低于定义的值
- 使用百分位数方式计算
- 100ms
SLA示例：以SessionSvr为例，服务的SLA定义如下
| SLA项 | 定义 |
|---|---|
| 请求成功率 | 99% |
| 可用性 | Lv1 |
| 吞吐量 | 单实例：1000qps<br>双实例：1800qps |
| TP75请求时延 | 420ms |
| TP95请求时延 | 300ms |
| TP99请求时延 | 200ms |
微服务架构原则
| 类别 | 检查项目 | 级别 |
|---|---|---|
| 服务自治 | 有独立的代码仓库，根目录与服务名称相同 | 强制 |
| 服务自治 | 能被单独部署，部署过程中不依赖于其他服务必须运行 | 强制 |
| 服务自治 | 禁止与其他服务共用数据库 | 强制 |
| 服务自治 | 服务业务功能完善，粒度适中，不耦合太多业务功能 | 强制 |
| 服务无状态 | 支持多实例部署，实例可部署到不同节点 | 强制 |
| 服务无状态 | 服务集群在线伸缩，不影响业务运行 | 建议 |
| 服务无状态 | 外网调用接口采用异步调用，请求超时不会影响服务吞吐量 | 强制 |
| 服务无状态 | 业务处理能力线性扩展，增加集群实例可同比增加业务处理能力 | 强制 |
| 服务无状态 | 具备容灾能力，随机杀死集群某个实例，服务业务功能不受影响 | 强制 |
| 服务无状态 | 具备故障自动切换能力，无需人工介入 | 建议 |
| 服务前后向兼容 | 服务接口向后兼容，接口只增、不删，废弃接口按计划灰度回收 | 强制 |
| 服务前后向兼容 | 从新版本回滚到老版本后（数据存储不回滚），老版本的业务功能正常 | 强制 |
| 分层依赖 | 禁止服务间的循环调用 | 强制 |
| 分层依赖 | 禁止依赖低于自身可靠性等级要求的服务 | 强制 |
微服务接口设计规范
- 标准操作
- REST风格规定针对资源而执行的操作通过HTTP规范定义
- 核心操作为GET、PUT、POST、DELETE，对资源的操作可归为增删改查（CRUD）
- 获取资源：GET
- 创建一个新资源：向一个URL发送POST
- 替换已有资源：PUT
- 删除已有资源：DELET
- 【规则】所请求的URL不支持该请求操作，返回状态码405（Method Not Allowed）
GET
- 【规则】GET操作用于获取资源的场景
- 【规则】GET操作必须具备安全性和幂等性<br> 说明：安全指经过操作后不改变服务器状态，幂等性指不允许对资源状态做相对改动
- 【规则】GET操作成功返回状态码200（OK）
- 【示例】获取用户信息：GET /acct/854，获取id为854的用户信息
POST
- 【规则】POST操作用于用于新建资源的场景
- 【规则】POST操作成功返回状态码200（OK）
- 【示例】添加用户信息：POST /acct
PUT
- 【规则】用于场景资源的更新，若资源不存在则创建
- 【规则】PUT操作必须具备安全性和幂等性
- 【规则】PUT操作成功返回状态码200（OK）
- 【示例】更新用户信息：PUT /acct/854，更新id为854的用户信息
DELETE
- 【规则】DELETE操作用于用于删除资源的场景
- 【规则】DELETE操作必须具备安全性和幂等性
- 【规则】DELETE操作成功返回状态码200（OK）
- 【示例】删除用户信息：DELETE /acct/854，删除id为854的用户信息
- 消息体设计原则
- 【规则】服务接口至少支持JSON格式作为HTTP消息体
- 【规则】JSON格式消息体中，KEY值采用JSON通用的小驼峰风格
- 【规则】消息体返回JSON格式如下：
{
"code": 200,
"message": "",
"timestamp": 9880213099,
"result": {...}
}