|
@@ -27,7 +27,7 @@ go-zero 包含极简的 API 定义和生成工具 goctl,可以根据定义的
|
|
|
|
|
|
## 1. go-zero框架背景
|
|
|
|
|
|
-18年初,晓黑板后端在经过频繁的宕机后,决定从`Java+MongoDB`的单体架构迁移到微服务架构,经过仔细思考和对比,我们决定:
|
|
|
+18年初,我们决定从`Java+MongoDB`的单体架构迁移到微服务架构,经过仔细思考和对比,我们决定:
|
|
|
|
|
|
* 基于Go语言
|
|
|
* 高效的性能
|
|
@@ -36,7 +36,7 @@ go-zero 包含极简的 API 定义和生成工具 goctl,可以根据定义的
|
|
|
* 极致的部署体验
|
|
|
* 极低的服务端资源成本
|
|
|
* 自研微服务框架
|
|
|
- * 个人有过很多微服务框架自研经验
|
|
|
+ * 有过很多微服务框架自研经验
|
|
|
* 需要有更快速的问题定位能力
|
|
|
* 更便捷的增加新特性
|
|
|
|
|
@@ -45,12 +45,13 @@ go-zero 包含极简的 API 定义和生成工具 goctl,可以根据定义的
|
|
|
对于微服务框架的设计,我们期望保障微服务稳定性的同时,也要特别注重研发效率。所以设计之初,我们就有如下一些准则:
|
|
|
|
|
|
* 保持简单
|
|
|
+* 弹性设计,面向故障编程
|
|
|
+* 工具大于约定和文档
|
|
|
* 高可用
|
|
|
* 高并发
|
|
|
* 易扩展
|
|
|
-* 弹性设计,面向故障编程
|
|
|
-* 尽可能对业务开发友好,封装复杂度
|
|
|
-* 尽可能约束做一件事只有一种方式
|
|
|
+* 对业务开发友好,封装复杂度
|
|
|
+* 约束做一件事只有一种方式
|
|
|
|
|
|
我们经历不到半年时间,彻底完成了从`Java+MongoDB`到`Golang+MySQL`为主的微服务体系迁移,并于18年8月底完全上线,稳定保障了晓黑板后续增长,确保了整个服务的高可用。
|
|
|
|