世界上只需要 Nginx 和 HAProxy 足矣

Nginx 有多好?对大多数人来说,只需要编辑下配置文件就可以了,只需要保证逻辑正确,客户端的请求能被正确的 proxy 到 合适的 upstream 就可以了。

Nignx 哪里不好用?如果有的话,估计就是配置语法太多记不住,有些坑自己不亲自趟是看不出深浅的。尽管如此,也挡不住 nginx 势如破竹的普及趋势。

就当我们利用 nginx 做各种反向代理之时,努力学习通过 lua 对 Nginx / Openresty 进行扩展的时候,咣,又出来个 service mesh 的概念,以及各种如雨后春笋般出现的 Envoy 、istio 、Cilium 和 Conduit ?

不可否认,微服务确实是趋势,K8s 也基本成了构建 PaaS 以及集群调度平台的标准实现方式,随着这些基础设施以及 cloud native 的渐入人心, service mesh 的出现也没法说完全不能理解。

好处就不说了,说说不好的地方,微服务不好调试,出了问题定位难,管理成本高,K8s 部署复杂,未知的坑比较多。Istio 就能解决这个问题?

Service mesh 的一个功能就是实现系统的可观测性,对系统整体的运行状态有所把控,其涵盖范围要大于传统的监控和报警;而且,对系统的可观测性,要求对系统内部的实现非常了解。那我的问题就来了,这个配置文件谁来写?Dev?Ops?还是 DevOps ?

商品、服务或是软件,制作者都应该让用户变成“傻瓜”,让用户用起来简单。

开发工具和框架已经正在逐渐把软件工程师变成“码农”,很多应用程序就是 CRUD 而已,基本设计的时候就能把代码生成了; IaaS 以及 PaaS 等各种 XaaS,也大大简化了运维工作以及难度,从这两点来说,开发和运维都在变得越来越傻瓜。同一件事,在其他方面都一样的情况下,一定是最简单的最后胜出。

其实我也不清楚 service mesh 到底应该做成什么样才好,但是最近对一些事挺有感触的。比如不要干一件事提供 n 种方案,让用户选择也是负担,再比如 gofmt 和 go fmt 不应该放一块更好些么?

Docker 之所以这么火,还不是把 10 条 lxc 的命令合成了一条 docker run ?简单的话入手就快,当然普及会更快。然而 K8s 并不是走的这条线,在我看来,g 家的号召力,以及其强大且全面的功能,是很多人选择的关键因素,当然其核心是社区的强大之处,这也和 Docker 公司的哲学有些相悖,所以 Docker 公司最近两年一直被唱衰。

Docker swarm 曾经是个好东西,但是我想我也不会再去研究它,至少现在没这个打算。因为我知道,跟 K8s 应该不会太差,工作好找,收入也不会低,算是软件工程师的必备技能之一,在某些公司或者职位来说,可能是关键的决定性技能。

我们真的都需要 PaaS 么?CaaS 或 Serverless ,都有其优点,简单的代价就是可控性差,灵活度低,在别人的框架里写代码。以前接触过代码生成工具,就是从设计流程,自动生成源代码,可以理解为 UML 图生成类,但是比这负责,能生成业务逻辑的代码,也许将来有一天,我们本地都不需要 IDE,直接在服务提供商的页面拖拖拽拽就能组装自己的应用程序了。

这时不得不说到 full managed service,简单来说,就是所有基础设施都由平台方提供,自己只写业务代码,比如 PaaS 和 Serverless 都是这样的,IaaS 实际上除了虚拟机实例,也提供了类似的服务。自己不需要管理数据库、缓存和消息队列,只需要出 money 就可以了。

穷惯了就不敢进行高质量的消费,编写软件也应该适时偷懒,能用钱办到的事情,尽量别自己去做,别人更专业,自己更省心。

懒人真希望世界上只有 HAProxy 。

当然,一涉及到企业级,以上都全作废。

发表评论

电子邮件地址不会被公开。 必填项已用*标注