来源 | deanwangpro.com/road-of-microservice
接口定义
版本,统一跟在 /api/后面,例如
/api/v2
以资源为中心,使用复数表述,例如
/api/contacts
,也可以嵌套,如/api/groups/1/contacts/100
url中尽量不使用动词,实践中发现做到这一点真的比较难,每个研发人员的思路不一致,起的名字也千奇百怪,都需要在代码Review中覆盖。
动作支持,
POST / PUT / DELELE / GET
,这里有一个坑,PUT和PATCH都是更新,但是PUT是全量更新而PATCH是部分更新,前者如果传入的字段是空(未传也视为空)那么也会被更新到数据库中。目前我们虽然是使用PUT但是忽略空字段和未传字段,本质上是一种部分更新,这也带来了一些问题,比如确有置空的业务需要特殊处理。接口通过swagger生成文档供前端同事使用。
持续集成(CI)
服务拆分原则
框架选择
zuul作为gateway,分发不同客户端的请求到具体service
erueka作为注册中心,完成了服务发现和服务注册
每个service包括gateway都自带了Hystrix提供的限流和熔断功能
service之间通过feign和ribbon互相调用,feign实际上是屏蔽了service对erueka的操作
架构改造
自动化部署
链路跟踪
spring cloud sleuth + zipkin
,国内有美团的CAT等等。其目的就是当一个请求经过多个服务时,可以通过一个固定值获取整条请求链路的行为日志,基于此可以再进行耗时分析等,衍生出一些性能诊断的功能。不过对于我们而言,首要目的就是trouble shooting,出了问题需要快速定位异常出现在什么服务,整个请求的链路是怎样的。运维监控
telegraf + influxdb + grafana
的方案。telegraf作为探针收集jvm,system,mysql等资源的信息,写入influxdb,最终通过grafana做数据可视化。spring boot actuator
可以配合jolokia暴露jvm的endpoint。整个方案零编码,只需要花时间配置。架构改造
CI中多了构建docker image的步骤
自动化测试过程中将数据库升级从应用中剥离单独做成docker image
生产中用k8s自带的service替代了eruka
Spring Cloud与k8s的融合
eureka.client.enabled` 设置为 false,停止各服务的eureka注册
`ribbon.eureka.enabled` 设置为 false,让ribbon不从eureka获取服务列表
以服务foo为例,`foo.ribbon.listofservers` 设置为 `http://foo:8080`,那么当一个服务需要使用服务foo的时候,就会直接调用到`http://foo:8080