前言

相信大家工作几年后，或多或少都会碰到技术选型问题。
“我们这个前端用Vue开发还是用React”
“我们用原生开发还是跨平台开发，跨平台开发用Flutter还是用RN”
“我们后端用xx语言开发”
“我们这个功能用xx框架（或中间件）实现吧”
凡此种种，如果选错那就是给自己挖坑

挖坑

我们这个项目太大了，用微服务拆分一下吧

这个我之前接到的一个需求。
因为目前项目使用的是Golang开发，按照以前Java的开发习惯（SpringCloud全家桶），那肯定上GoMicro、GoKit了
于是，开始了挖坑之路

Golang微服务框架 - GoMicro

  • 坑一
    GoMicro框架算是挺成熟的一套东西了，可是这个V2版本目前更新还是比较频繁的，并且还没有任何要发release版的迹象。
  • 坑二
    基于目前github上面的代码，居然没有附带go.mod（golang官方的包管理，类似前端的package.json，Java的maven）。于是苦哈哈的执行
    1
    2
    go mod init
    go get .
    居然还有各种依赖错误，其中一个就是grpc的版本问题。解决一个又一个，实在看不到希望。放弃

Golang微服务框架 - GoKit

  • 坑一
    跟GoMicro一样，没有附带go.mod

依赖问题顺利的解决，附带的demo也跑通了。在写注册发现的示例的时候，碰到了一个不大不小的麻烦（要写一部分多余的代码）。卒

吐槽

为什么这么多开源项目都不带go.mod呢，如果不是开发者本人，那么谁知道你要用哪个版本呢

峰回路转

为什么上面会放弃通过多余的代码来实现注册发现呢，因为之前参加了蚂蚁金服的一次开发者会议，对Service Mesh的各种特性都很眼馋。渐进式升级、无感注册发现等

既然要用Service Mesh那必然要使用kubernetes了。于是，申请了一台海外服务器开始了搞机之旅

什么？作为技术人居然不知道kubernetes
最近摆地摊挺火的，觉得可以考虑一下转型