- 目录 -
单体应用时代
接口定义
持续集成(CI)
微服务时代
服务拆分原则
框架选择
架构改造
自动化部署
链路跟踪
运维监控
容器化时代
架构改造
Spring Cloud与k8s的融合
CI的改造
小结
- 前言 -
- 单体应用时代 -
- 接口定义 -
版本,统一跟在 /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的操作
- 架构改造 -
自动化部署
链路跟踪
- 运维监控 -
在容器化之前,采用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的时候,
CI的改造
- 总结 -
作者:Dean
来源:
deanwangpro.com/2019/02/18/road-of-microservice